@haaaiawd/anws 1.1.0 → 1.2.1

package/templates/.agent/skills/design-reviewer/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: design-reviewer
+description: 使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档。产出按严重度分级的发现，关联到具体文档段落。
+---
+
+# 设计审查大师手册
+
+> "代码之前发现的设计缺陷，能省下一百个 Bug。  
+> 对设计严厉，代码才能优雅。"
+
+你是**设计审查大师**，负责系统性审查架构和系统设计文档。你的三维框架确保没有任何一类风险被遗漏。
+
+---
+
+## ⚡ 任务目标
+
+1. **加载文档 (必须)**: 读取 `02_ARCHITECTURE_OVERVIEW.md`、所有 `04_SYSTEM_DESIGN/*.md` 以及所有 `03_ADR/*.md`。
+2. **深度理解**: 使用 `sequentialthinking`（3-5 步）在批判之前先理解设计意图。
+3. **Pre-Mortem**: 想象项目在 6 个月后失败了——倒推根因。
+4. **三维审查**: 系统性执行全部 3 个维度。
+5. **假设验证**: 识别隐藏假设并尝试证伪。
+6. **生成发现**: 为每条发现标注严重度，并关联到具体文档段落。
+
+## 🛑 硬约束
+
+- **证据为本**: 每条发现**必须**有具体文档引用 + 推理链。"可能有性能问题"这种没有分析的说法禁止出现。
+- **质量优于数量**: 3 条真实发现 > 10 条猜测。
+- **尊重 ADR 决策**: 如果 ADR 明确选择了某个权衡并附有文档化的理由，不要翻旧账。仅在出现新证据反驳原有理由时才标记。
+- **不涉及实现细节**: 审查的是*设计*，不是假想的代码。
+
+---
+
+## 🔍 三维审查框架
+
+### 维度 1: 系统设计 (System Design)
+
+**目标**: 验证架构的完整性、一致性和边界清晰度。
+
+| # | 检查项 | 关注要点 |
+|---|--------|---------|
+| SD-1 | **架构一致性** | 同一组件在 PRD、Architecture、System Design 中的描述是否矛盾？ |
+| SD-2 | **边界清晰度** | 每个系统的职责范围是否明确？是否存在职责重叠？ |
+| SD-3 | **依赖合理性** | 系统依赖是否无环？是否存在隐藏耦合？ |
+| SD-4 | **接口完整性** | 所有跨系统接口是否完整定义（输入/输出/错误/协议）？ |
+| SD-5 | **状态管理** | 系统状态转换是否清晰定义？边缘状态是否处理？ |
+| SD-6 | **数据模型完整性** | 实体关系是否跨文档一致？是否存在孤儿实体？ |
+
+**思考提示**（配合 `sequentialthinking` 使用）:
+1. "这个架构背后的核心假设是什么？"
+2. "如果假设 X 不成立，什么会崩？"
+3. "系统边界定义是否存在歧义？"
+4. "接口是否覆盖了所有边界情况？"
+
+---
+
+### 维度 2: 运行模拟 (Runtime Simulation)
+
+**目标**: 在脑中"运行"系统，发现时序、状态和并发问题。
+
+> 本维度**必须**使用 `sequentialthinking`（3-5 步）。运行时问题藏在序列中。
+
+| # | 检查项 | 关注要点 |
+|---|--------|---------|
+| RS-1 | **时序一致性** | 时序模型是否合理？是否存在"必须先于"的矛盾？ |
+| RS-2 | **状态同步** | 分布式状态下，副本是否可能发散？最终一致性在这里是否可接受？ |
+| RS-3 | **并发处理** | 两个操作冲突时会怎样？是否有解决策略？ |
+| RS-4 | **边界条件** | 空状态、满状态、溢出——各自如何处理？ |
+| RS-5 | **故障传播** | 组件 A 故障时如何影响 B、C？是否存在级联风险？ |
+| RS-6 | **Happy Path 偏见** | 只设计了正常路径？错误/超时/部分失败路径呢？ |
+
+**思考提示**:
+1. "端到端追踪一个典型操作，经过哪些步骤？"
+2. "每一步产生什么状态变更？什么可能出错？"
+3. "如果两个用户同时做同一件事会怎样？"
+4. "崩溃后 30 秒，系统是什么样子？"
+
+---
+
+### 维度 3: 工程实现 (Engineering Implementation)
+
+**目标**: 验证设计可构建、可测试、可维护。
+
+> 本维度**必须**使用 `sequentialthinking`（3-5 步）。
+
+| # | 检查项 | 关注要点 |
+|---|--------|---------|
+| EI-1 | **可测试性** | 核心逻辑能否被单元测试？是否有 Mock 的接缝？ |
+| EI-2 | **可维护性** | 如果需求变更，需要改多少文件？ |
+| EI-3 | **性能瓶颈** | 设计中是否隐藏了 N+1 查询、无界循环或 O(n²)？ |
+| EI-4 | **安全面** | 认证边界是否清晰？敏感数据静态/传输加密？输入校验？ |
+| EI-5 | **可观测性** | 凭设计中的日志/指标方案能否调试生产问题？ |
+| EI-6 | **技术栈契合度** | 选定的技术是否真正支持所需功能？版本兼容性？ |
+
+**思考提示**:
+1. "如何为核心逻辑写单元测试？"
+2. "如果需要修改功能 X，影响范围多大？"
+3. "性能热点在哪？能否后续优化？"
+4. "这个设计暴露了哪些攻击向量？"
+
+---
+
+## 🎚️ 严重度分级
+
+| 等级 | 判定标准 | 所需行动 |
+|:----:|---------|---------|
+| **Critical** 🔴 | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High** 🟠 | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
+| **Medium** 🟡 | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
+| **Low** 🟢 | 润色项或轻微不一致。 | P3 — 后续跟踪 |
+
+---
+
+## 📊 输出格式
+
+按以下结构生成发现，适合纳入 `07_CHALLENGE_REPORT.md`：
+
+```markdown
+## 🔍 设计审查发现
+
+### 摘要
+
+| 维度 | 发现数 | Critical | High | Medium | Low |
+|------|:------:|:--------:|:----:|:------:|:---:|
+| 系统设计 | — | — | — | — | — |
+| 运行模拟 | — | — | — | — | — |
+| 工程实现 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+---
+
+### [维度] — [ID]: [标题]
+
+**严重度**: Critical / High / Medium / Low
+**文档位置**: [精确的文件和章节引用]
+
+**问题**:
+[详细描述，引用具体文档内容]
+
+**证据**:
+- 文档分析: [来自 PRD/Architecture/ADR 的具体内容]
+- 推理链: [基于 sequentialthinking 的分析]
+- 类比: [其他系统中的类似已知失败，如适用]
+
+**影响**:
+- [不修复会发生什么]
+
+**建议**:
+[修复方式，可提供多个选项]
+```
+
+---
+
+## 💡 审查质量清单
+
+交付发现前，确认：
+- [ ] 每条发现有具体文档引用（不是笼统的"架构文档"）
+- [ ] 每条发现有明确的影响说明
+- [ ] 没有纯猜测性的发现（缺乏推理链条）
+- [ ] Critical/High 发现经过 `sequentialthinking` 验证
+- [ ] ADR 中已记录的权衡被尊重（没有在无新证据的情况下重复质疑）
+- [ ] 发现可操作（审查者能根据建议进行修复）

package/templates/.agent/skills/spec-writer/SKILL.md

@@ -18,6 +18,8 @@ Your job is to kill ambiguity.
     *   Draft clarifying questions
 3.  **Interrogate**: Present questions to user. DO NOT proceed without answers.
 4.  **Draft PRD (MANDATORY)**: Use `view_file references/prd_template.md` then `write_to_file` to create `genesis/v{N}/01_PRD.md`.
+5.  **Ambiguity Scan (MANDATORY)**: After drafting, run the 10-Dimension Ambiguity Scan (see below). Fix issues inline or mark `[ASSUMPTION]`.
+6.  **US Quality Gate (MANDATORY)**: Verify every User Story passes the quality checklist (see below).
 
 ## 🛑 Mandatory Steps
 Before creating the PRD, you MUST:
@@ -26,6 +28,11 @@ Before creating the PRD, you MUST:
 3. Clarify "Vibe Words" with the user (What does "Fast" mean to you? What does "Modern" imply?).
 4. Use `write_to_file` to save output. DO NOT just print to chat.
 
+After creating the PRD, you MUST:
+5. Run the 10-Dimension Ambiguity Scan — fix or mark all `Partial`/`Missing` items.
+6. Verify every User Story has: Priority / 独立可测 / 涉及系统 / 边界情况.
+7. Ensure `[NEEDS CLARIFICATION]` tags ≤ 3 (hard limit). Excess → use reasonable defaults + `[ASSUMPTION]` tag.
+
 ## ✅ Completion Checklist
 - [ ] PRD file created: `genesis/v{N}/01_PRD.md`
 - [ ] Contains User Stories, Acceptance Criteria, Non-Goals
@@ -56,3 +63,46 @@ Before creating the PRD, you MUST:
 
 ## 🧰 The Toolkit
 *   `references/prd_template.md`: The Product Requirements Document template.
+
+## 🔍 10-Dimension Ambiguity Scan
+
+After drafting the PRD, you **MUST** systematically scan it against these 10 dimensions. This replaces ad-hoc "any questions?" with a **repeatable, exhaustive** sweep.
+
+For each dimension, mark status: `Clear` ✅ / `Partial` ⚠️ / `Missing` ❌
+
+| # | Dimension | What to Check | Status |
+|---|-----------|--------------|:------:|
+| 1 | **Functional Scope & Behavior** | Core objectives / success criteria / explicit exclusions / user role distinctions | |
+| 2 | **Domain & Data Model** | Entities, attributes, relationships / uniqueness rules / lifecycle & state transitions / data volume assumptions | |
+| 3 | **Interaction & UX Flow** | Key user journeys / error, empty, loading states / accessibility & i18n | |
+| 4 | **Non-Functional Quality** | Performance / scalability / reliability / observability / security & privacy / compliance | |
+| 5 | **Integration & External** | External service failure modes / import-export formats / protocol version assumptions | |
+| 6 | **Edge Cases & Failure** | Negative scenarios / rate limiting / concurrency conflict resolution | |
+| 7 | **Constraints & Tradeoffs** | Technical constraints / explicit tradeoff records / rejected alternative archives | |
+| 8 | **Terminology Consistency** | Canonical glossary / synonym normalization across PRD | |
+| 9 | **Completion Signals** | Acceptance criteria testability / quantifiable DoD | |
+| 10 | **Placeholders** | TODO markers / unquantified vague adjectives (fast, scalable, secure, intuitive, robust) | |
+
+**Rules**:
+- `Partial` or `Missing` items → rank by **Impact × Uncertainty**, pick **top 5** to ask user
+- Ask **one question at a time**; provide your recommended answer; user can accept or customize
+- After user answers → **atomically write** the answer into the corresponding PRD section (never leave contradictory text)
+- **NEEDS CLARIFICATION hard limit ≤ 3** — if more remain, fill with reasonable defaults + `[ASSUMPTION: ...]` tag
+- **Do NOT ask about these reasonable defaults**: industry-standard data retention, standard web/mobile performance expectations, user-friendly error messages with fallbacks, standard session-based or OAuth2 auth
+
+## ✅ User Story Quality Gate
+
+Every User Story in the PRD **MUST** pass these checks before the PRD is considered complete:
+
+| Check | Requirement |
+|-------|------------|
+| **Unique ID** | Has `[REQ-XXX]` identifier for traceability |
+| **Priority** | Marked P0 / P1 / P2 — P0 stories listed first |
+| **独立可测** | Describes how this story can be **independently** demonstrated and verified |
+| **涉及系统** | Lists specific system IDs (must align with `02_ARCHITECTURE_OVERVIEW.md`) |
+| **Acceptance Criteria** | At least 1 Given-When-Then + at least 1 Error Case |
+| **边界情况** | At least 1 boundary condition identified |
+| **No Vibe Words** | No unquantified adjectives (fast → <100ms p99, scalable → support N users) |
+| **User Value** | One sentence describing value to end user |
+
+If any User Story fails a check → fix it before delivering the PRD.

package/templates/.agent/skills/spec-writer/references/prd_template.md

@@ -1,174 +1,177 @@
-# Product Requirements Document (PRD) v2.0
+# 产品需求文档 (PRD) v2.0
 
-**Project**: [Project Name]
-**Title**: [Feature/Requirement Name]
-**Status**: Draft | Review | Approved
-**Version**: 1.0
-**Author**: [Author Name or Agent]
-**Date**: [YYYY-MM-DD]
+**项目名称**: [项目名称]
+**功能名称**: [功能/需求名称]
+**文档状态**: 草稿 (Draft) | 评审中 (Review) | 已通过 (Approved)
+**版本号**: 1.0
+**负责人**: [作者名字或 Agent]
+**创建日期**: [YYYY-MM-DD]
 
 ---
 
-## 1. Executive Summary
-<!-- Context Compression: State the "Why" and "What" in < 50 words. -->
-<!-- ⚠️ CRITICAL: This is the "elevator pitch". Must be < 50 words. -->
+## 1. 执行摘要 (Executive Summary)
+<!-- 上下文压缩：在 50 字以内说明"为什么做"和"做了什么"。 -->
+<!-- ⚠️ CRITICAL: 这是"电梯演讲"，必须控制在 50 字以内。 -->
 
-[Briefly describe the problem being solved and the proposed solution. Focus on value.]
+[简明扼要地描述要解决的问题以及所提出的解决方案，请聚焦于核心价值。]
 
 ---
 
-## 2. Background & Context
-<!-- ⭐ 新增: 提供充分背景，帮助后续System Design阶段理解 -->
+## 2. 背景与上下文 (Background & Context)
+<!-- 提供充分的业务和背景知识，帮助后续架构和系统设计阶段更好地理解上下文。 -->
 
-### 2.1 Problem Statement (问题陈述)
-- **Current Pain Point**: [用户面临的具体问题]
-- **Impact Scope**: [受影响的用户群体/业务范围]
-- **Business Impact**: [对业务的影响，如收入、用户满意度、效率]
+### 2.1 问题陈述 (Problem Statement)
+- **当前痛点**: [用户当前面临的具体问题]
+- **影响范围**: [受影响的用户群体/业务范围]
+- **业务影响**: [对业务的实际影响，例如收入损失、用户流失、效率低下等]
 
-### 2.2 Opportunity (机会)
-[如果解决这个问题，能带来什么价值？定量描述]
+### 2.2 核心机会 (Opportunity)
+[如果成功解决这个问题，能带来什么积极价值？请尽量定量描述。]
 
-### 2.3 Reference & Competitors (参考与竞品) - 可选
-<!-- 了解市场已有解决方案，避免重复造轮子 -->
-- **Competitor A**: [特点、优缺点]
-- **Competitor B**: [特点、优缺点]
-- **Our Differentiation**: [我们的独特价值]
+### 2.3 竞品与参考 (Reference & Competitors) — 可选
+<!-- 了解市场已有的解决方案，避免在成熟领域重新发明轮子。 -->
+- **竞品 A**: [特点、优缺点]
+- **竞品 B**: [特点、优缺点]
+- **我们的护城河**: [与竞品的差异化优势/独特价值]
 
 ---
 
-## 3. Goals & Non-Goals
+## 3. 目标与范围 (Goals & Non-Goals)
 
-### 3.1 Goals
-<!-- ⚠️ CRITICAL: 必须使用 SMART 原则 (Specific, Measurable, Achievable, Relevant, Time-bound) -->
+### 3.1 目标 (Goals)
+<!-- ⚠️ CRITICAL: 必须使用 SMART 原则 (明确、可衡量、可实现、相关性强、有时限) -->
 
-- **[G1]**: [可衡量的目标，如: 用户登录成功率 > 95%]
-- **[G2]**: [可衡量的目标，如: 页面加载时间 < 2s]
+- **[G1]**: [可衡量的业务目标，如: 用户登录转化率提升至 95% 以上]
+- **[G2]**: [可衡量的技术目标，如: 列表页 P95 加载时间 < 1.5s]
 
-### 3.2 Non-Goals (Out of Scope)
-<!-- Crucial for preventing scope creep -->
+### 3.2 非目标 (Non-Goals)
+<!-- 明确"不做"什么，这是防止需求蔓延（Scope Creep）的关键。 -->
 
-- **[NG1]**: [暂不考虑的功能，如: 第三方OAuth登录]
-- **[NG2]**: [未来版本的考虑，如: 多因素认证]
+- **[NG1]**: [由于范围限制暂不考虑的功能，如: 第三方 OAuth 快捷登录]
+- **[NG2]**: [属于未来版本规划范围的事项，如: 强制多因素认证 (MFA)]
 
 ---
 
-## 4. User Stories (The "What")
-<!-- Format: As a [User], I want to [Action], so that [Benefit] -->
-<!-- ⚠️ CRITICAL: 每个User Story必须有唯一ID [REQ-XXX]，用于追溯链 -->
-
-### US01: [Title] [REQ-001]
-*   **Story**: As a [role], I want to [feature], so that [value].
-*   **Acceptance Criteria (AC)**:
-    *   [ ] **Given** [context], **When** [action], **Then** [outcome].
-    *   [ ] **Error Case**: When [failure condition], show [specific error message].
-*   **Priority**: P0 (Must Have) | P1 (Should Have) | P2 (Nice to Have)
-*   **Estimation**: [Story Points 或 天数] - 可选
-
-### US02: [Title] [REQ-002]
-*   **Story**: ...
-*   **Acceptance Criteria (AC)**:
+## 4. 用户故事与需求清单 (User Stories)
+<!-- 格式要求: 作为一个 [角色]，我想要 [动作]，以便于 [价值/收益]。 -->
+<!-- ⚠️ CRITICAL: 每个 User Story 必须有唯一 ID [REQ-XXX]，这是整个系统防腐和追溯的核心。 -->
+<!-- ⚠️ CRITICAL: 必须按用户价值优先级排序 (P0 核心路径 → P1 重要体验 → P2 锦上添花)。 -->
+<!-- ⚠️ CRITICAL: 每个 User Story 必须具备独立可测性——完成后可以脱离其他 Story 独立演示。 -->
+
+### US-001: [任务标题] [REQ-001] (优先级: P0)
+
+*   **故事描述**: 作为一个 [角色]，我想要 [功能/动作]，以便于 [获得的好处]。
+*   **用户价值**: [一句话说明该 Story 对于最终目标的核心价值]
+*   **独立可测性**: [该任务完成后，测试/产品可以在不依赖其他功能的情况下如何验证？]
+*   **涉及系统**: [列出将会涉及的系统 ID，如: `frontend-system`, `backend-api` — 必须与 `02_ARCHITECTURE` 中的名字对齐]
+*   **验收标准 (Acceptance Criteria)**:
+    *   [ ] **Given** [初始上下文], **When** [触发动作], **Then** [预期结果].
+    *   [ ] **异常处理**: 当 [发生何种异常] 时，系统必须 [具体的回退或提示行为].
+*   **边界与极限情况**:
+    *   [边界条件1 — 如: 超大数据量、断网重连、权限骤变等极端情况如何处理]
+    *   [边界条件2]
+
+### US-002: [任务标题] [REQ-002] (优先级: P1)
+
+*   **故事描述**: ...
+*   **用户价值**: ...
+*   **独立可测性**: ...
+*   **涉及系统**: ...
+*   **验收标准 (Acceptance Criteria)**:
     *   [ ] ...
-*   **Priority**: P0/P1/P2
+*   **边界与极限情况**:
+    *   ...
 
-<!-- 继续添加更多User Stories... -->
+<!-- 根据需求规模继续添加 User Stories... -->
 
 ---
 
-## 5. User Experience & Design (用户体验) - 可选
-<!-- ⭐ 新增: 描述关键的UX流程，帮助前端系统设计 -->
+## 5. 用户体验与设计 (User Experience) — 可选
+<!-- 提供关键的用户交互设计指引，为前端/客户端的设计系统建立边界。 -->
 
-### 5.1 Key User Flows (关键用户流程)
-<!-- 使用Mermaid流程图描述关键用户旅程 -->
+### 5.1 关键用户旅程 (Key User Flows)
+<!-- 【推荐】使用 Mermaid 流程图直观表达主体业务流程。 -->
 
 ```mermaid
-graph LR
-    A[用户访问登录页] --> B[输入邮箱密码]
-    B --> C{认证}
-    C -->|成功| D[跳转Dashboard]
-    C -->|失败| E[显示错误提示]
+flowchart TD
+    A[用户访问登录页] --> B[输入邮箱与密码]
+    B --> C{后端服务认证}
+    C -->|校验成功| D[跳转 Dashboard 首页]
+    C -->|校验失败| E[输入框下方抛出错误指引]
     E --> B
 ```
 
-### 5.2 Design Guidelines (设计规范)
-- **UI Style**: [现代化、简洁、专业等]
-- **Color Palette**: [主色调、辅助色]
-- **Interactions**: [动画、反馈机制]
+### 5.2 交互规范 (Design Guidelines)
+- **视觉风格**: [现代化、极简、严肃专业等]
+- **响应模式**: [对页面加载骨架屏、按钮 Loading 状态等的要求]
+- **平台兼容**: [仅限 Web 端，是否需要兼顾移动/平板自适应？]
 
 ---
 
-## 6. Constraint Analysis
-<!-- Derived from /scout report or /challenge -->
-<!-- ⭐ 增强: 分类更详细，便于后续System Design继承约束 -->
+## 6. 约束与限制 (Constraint Analysis)
+<!-- 约束决定了技术选型的天花板。来自于 /scout 报告或立项时的不可抗力。 -->
 
-### 6.1 Technical Constraints (技术约束)
-*   **Legacy Systems**: [e.g., Must work with existing Auth system]
-*   **Performance**: [e.g., API response time < 200ms (p95)]
-*   **Scalability**: [e.g., Support 100k concurrent users]
+### 6.1 技术约束 (Technical Constraints)
+*   **遗留系统**: [例如: 必须兼容老版本的 MySQL 5.7 表结构]
+*   **性能底线**: [例如: API 响应时间 P95 < 200ms]
+*   **扩展性预期**: [例如: 设计上需要支撑 10 万并发在线]
 
-### 6.2 Security & Compliance (安全与合规)
-*   **Security**: [e.g., No PII in logs, HTTPS only]
-*   **Privacy**: [e.g., GDPR compliance]
-*   **Compliance**: [e.g., SOC 2 Type II]
+### 6.2 安全与合规 (Security & Compliance)
+*   **数据安全**: [例如: 日志中绝对不可包含明文 PII 信息]
+*   **网络要求**: [例如: 强制全站 HTTPS / API 仅内网可访]
+*   **合规审核**: [例如: 满足当地数据出境要求 / 通过特定等保审核]
 
-### 6.3 Time & Budget (时间与预算)
-*   **Deadline**: [交付时间，如: 2026-03-01]
-*   **Budget**: [预算限制] - 可选
-*   **Team**: [团队规模和技能] - 可选
+### 6.3 时间与资源 (Time & Resources)
+*   **交付死线**: [硬性 Deadline，如: 2026-03-01 必须全量上线]
+*   **其他限制**: [如依赖外部供应商接口的对接进度等]
 
 ---
 
-## 7. Success Metrics (成功指标)
-<!-- ⭐ 新增: 如何衡量成功，便于后续验证 -->
+## 7. 成功指标 (Success Metrics) — 可选
+<!-- 如何在功能上线后衡量我们的成功？ -->
 
-| Metric | Target | Measurement Method |
-|--------|--------|-------------------|
-| 用户登录成功率 | > 95% | Google Analytics |
-| 页面加载时间 (p95) | < 2s | Lighthouse/监控 |
-| 用户满意度 (NPS) | > 4.5/5 | 用户调研 |
+| 核心指标 (Metric) | 目标值 (Target) | 测量方式 (Measurement Method) |
+| ----------------- | --------------- | ----------------------------- |
+| 业务: 注册转化率  | > 45%           | 数据看板/漏斗分析             |
+| 性能: 接口成功率  | > 99.9%         | APM 监控告警                  |
 
 ---
 
-## 8. Definition of Done (完成标准)
+## 8. 完成标准 (Definition of Done)
+<!-- 所有任务合并到主分支发布前，必须 100% 勾选的检查清单。 -->
 
-*   [ ] All Acceptance Criteria (AC) passed.
-*   [ ] Unit tests written and passing (coverage > 80%).
-*   [ ] Integration tests passing.
-*   [ ] No new lint errors.
-*   [ ] Documentation updated (API docs, user manual).
-*   [ ] Performance benchmarks met (if applicable).
-*   [ ] Security audit passed (if applicable).
-*   [ ] User acceptance testing (UAT) completed.
+*   [ ] 所有的验收标准 (AC) 全部测试通过。
+*   [ ] 包含足够的自动化单元测试 (行覆盖率 > 80%) 并且 CI 绿灯。
+*   [ ] 集成测试/E2E 关键路径全部顺畅。
+*   [ ] 代码 Lint 及格式化审查均无警告。
+*   [ ] 已更新相关技术文档 (如 OpenAPI 接口文档、Wiki 知识库)。
+*   [ ] 性能与安全隐患已经过 Review (若有前述相关的约束要求)。
+*   [ ] 产品验收环节 (UAT) 已通过。
 
 ---
 
-## 9. Appendix (附录) - 可选
+## 9. 附录 (Appendix) — 可选
 
-### 9.1 Glossary (术语表)
-- **[Term 1]**: [Definition]
-- **[Term 2]**: [Definition]
+### 9.1 术语表 (Glossary)
+- **[首字母缩写/术语 1]**: [明确定义，避免跨团队沟通歧义]
+- **[术语 2]**: [定义]
 
-### 9.2 References (参考资料)
-- [Link 1]
-- [Link 2]
-
-### 9.3 Change Log (变更日志)
-| Version | Date | Changes | Author |
-|---------|------|---------|--------|
-| 1.0 | 2026-01-08 | Initial version | XXX |
+### 9.2 参考资料 (References)
+- [URL 1]
+- [URL 2]
 
 ---
 
 <!-- ⚠️ CRITICAL 使用指南 -->
 <!-- 
-**PRD撰写原则 (Amazon 6-pager风格)**:
-1. **精炼至上**: 总长度最多6页（约3000-4000字）
-2. **Executive Summary < 50字**: 电梯演讲
-3. **每个User Story < 100字**: 简洁清晰
-4. **数据驱动**: 所有目标和指标必须可衡量
-5. **追溯链**: 每个User Story有唯一ID [REQ-XXX]
+**PRD 撰写原则 (精益规格要求)**:
+1. **去冗存精**: 抵制长篇大论，整个文档建议控制在阅读时间 10 分钟以内。
+2. **执行摘要 < 50字**: 用最少的话讲明白核心价值。
+3. **独立性**: User Story 粒度必须控制在"可单独交付验证"的级别。
+4. **追溯链 (Traceability)**: [REQ-XXX] 编号是神圣不可侵犯的，将贯穿架构、任务和代码。
 
 **章节使用指南**:
 - **必需章节**: 1, 2.1, 3, 4, 6, 8
 - **可选章节**: 2.3 (竞品分析), 5 (UX设计), 7 (成功指标), 9 (附录)
-- **小项目**: 可省略 2.3, 5, 9，但结构保持一致
+- **小型功能/迭代**: 可大胆删除 2.3, 5, 7, 9，保留骨架即可。
 -->