@haaaiawd/anws 1.0.0

package/templates/.agent/skills/git-forensics/scripts/git_hotspots.py

@@ -0,0 +1,118 @@
+import os
+import argparse
+import subprocess
+import json
+import csv
+from datetime import datetime
+try:
+    import lizard
+except ImportError:
+    print("Error: lizard not installed. Run: pip install lizard")
+    exit(1)
+
+def get_git_churn(repo_path: str, days: int) -> dict:
+    cmd = [
+        "git",
+        "-C", repo_path,
+        "log",
+        f"--since={days}.days.ago",
+        "--name-only",
+        "--format="
+    ]
+    try:
+        result = subprocess.check_output(cmd, encoding='utf-8')
+    except subprocess.CalledProcessError as e:
+        print(f"Git command failed: {e}")
+        return {}
+        
+    churn_map = {}
+    for line in result.splitlines():
+        if line.strip():
+            file_path = line.strip()
+            churn_map[file_path] = churn_map.get(file_path, 0) + 1
+            
+    return churn_map
+
+def get_complexity(repo_path: str, files: list) -> dict:
+    complexity_map = {}
+    for file_rel_path in files:
+        full_path = os.path.join(repo_path, file_rel_path)
+        if not os.path.exists(full_path):
+            continue
+            
+        try:
+            analysis = lizard.analyze_file(full_path)
+            # Use average cyclomatic complexity (CCN) or max CCN
+            # Max CCN is often a better indicator of "scary code"
+            max_ccn = 0
+            for func in analysis.function_list:
+                if func.cyclomatic_complexity > max_ccn:
+                    max_ccn = func.cyclomatic_complexity
+            
+            # File length is also a complexity factor
+            nloc = analysis.nloc
+            
+            complexity_map[file_rel_path] = {
+                "max_ccn": max_ccn,
+                "nloc": nloc,
+                "avg_ccn": analysis.average_cyclomatic_complexity
+            }
+        except Exception as e:
+            # lizard might fail on non-code files
+            pass
+            
+    return complexity_map
+
+def analyze_hotspots(repo_path: str, days: int, output_file: str):
+    print(f"Analyzing git churn for past {days} days...")
+    churn_data = get_git_churn(repo_path, days)
+    
+    print("Analyzing code complexity...")
+    # Only analyze files that exist and have churn
+    target_files = [f for f in churn_data.keys()]
+    complexity_data = get_complexity(repo_path, target_files)
+    
+    hotspots = []
+    for file, churn in churn_data.items():
+        if file in complexity_data:
+            comp = complexity_data[file]
+            hotspots.append({
+                "file": file,
+                "churn": churn,
+                "max_ccn": comp["max_ccn"],
+                "nloc": comp["nloc"],
+                # Simple score: Churn * CCN. 
+                # Prompts usually care about this metric.
+                "debt_score": churn * comp["max_ccn"] 
+            })
+    
+    # Sort by debt score descending
+    hotspots.sort(key=lambda x: x["debt_score"], reverse=True)
+    
+    # Output
+    result = {
+        "analysis_date": datetime.now().isoformat(),
+        "period_days": days,
+        "total_files_analyzed": len(hotspots),
+        "hotspots": hotspots[:50] # Top 50
+    }
+    
+    if output_file:
+        with open(output_file, 'w') as f:
+            json.dump(result, f, indent=2)
+        print(f"Hotspot analysis saved to {output_file}")
+    else:
+        print(json.dumps(result, indent=2))
+
+def main():
+    parser = argparse.ArgumentParser(description="Git Hotspot Analysis (Churn vs Complexity)")
+    parser.add_argument("--repo", default=".", help="Repository path")
+    parser.add_argument("--days", type=int, default=180, help="Analysis period in days")
+    parser.add_argument("--output", "-o", help="Output JSON file")
+    
+    args = parser.parse_args()
+    
+    analyze_hotspots(args.repo, args.days, args.output)
+
+if __name__ == "__main__":
+    main()

package/templates/.agent/skills/report-template/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: report-template
+description: 综合 Scout 阶段所有分析（build-inspector, runtime-inspector, git-forensics, concept-modeler），生成决策就绪的系统风险报告。
+---
+
+# 综合者手册 (The Synthesizer's Manual)
+
+> "数据不是信息。信息不是知识。知识不是智慧。" —— T.S. Eliot
+
+你的目标是将原始分析数据转化为**架构师可用的智慧**。
+
+---
+
+## ⚠️ 强制自检 (Mandatory Self-Correction)
+
+> [!IMPORTANT]
+> 在生成报告之前，你**必须**进行自我检查：
+> 1.  "build-inspector 发现的构建边界和 runtime-inspector 发现的 IPC 边界是否一致？"
+> 2.  "git-forensics 发现的高耦合文件对是否跨越了构建边界？"
+> 3.  "concept-modeler 识别的缺失组件是否与已发现的风险相关？"
+> 4.  "这份报告是否足够完整？"
+
+---
+
+## ⚡ Quick Start
+
+1.  **读取模板 (MANDATORY)**: 使用 `view_file references/REPORT_TEMPLATE.md`。你的报告**必须**完全匹配此结构。
+2.  **综合所有发现**: 汇总来自以下来源的输出：
+    *   `build-inspector` → Build Roots, Topology
+    *   `runtime-inspector` → IPC Surfaces, Contract Status
+    *   `git-forensics` → Coupling Pairs, Hotspots
+    *   `concept-modeler` → Entities, Missing Components
+3.  **起草报告**: 按照模板组织逻辑连接。
+4.  **发布 (CRITICAL)**: 你**必须**使用 `write_to_file` 保存到 `genesis/v{N}/00_SCOUT_REPORT.md`。**禁止**仅打印到聊天。确保 `genesis/v{N}/` 目录存在。
+
+---
+
+## ✅ 完成检查清单
+
+在进入下一阶段之前，验证：
+- [ ] 输出文件已创建: `genesis/v{N}/00_SCOUT_REPORT.md`
+- [ ] 包含: System Fingerprint, Component Map, Risk Matrix, Feature Landing Guide
+- [ ] 用户已确认发现
+
+---
+
+## 🛠️ 综合仪式
+
+### 1. 执行摘要 (Executive Summary)
+*   **电梯演讲**: 用 30 秒描述系统的健康状况。
+*   **聚焦点**: 技术债务、关键风险、可靠性。
+
+### 2. 暗物质检测
+*   不仅仅列出存在的东西。**列出缺失的东西**。
+*   检查清单: 日志？错误处理？CI/CD？密钥管理？版本握手？
+
+### 3. 交叉验证 (Cross-Verification)
+*   **build-inspector** 说 "Workspace 统一管理"？
+*   **git-forensics** 说 "高耦合跨越构建根"？
+*   **结论**: 发现隐藏的逻辑耦合 → **重构目标**。
+
+### 4. 人工检查点
+*   强制用户确认: "这份报告完整吗？"
+*   **在此报告签字前，禁止进入 Blueprint 阶段**。
+
+---
+
+## 🛡️ 老师傅守则
+
+1.  **禁止幻觉**: 每个声明必须链接到源文件。
+2.  **残酷诚实**: 直言不讳。如果是一团糟，就说是一团糟。
+3.  **行动导向**: 列出的每个问题都必须暗示一个解决方案 (重构/重写/保留)。
+
+---
+
+## 🧰 工具箱
+
+*   `references/REPORT_TEMPLATE.md`: 报告主模板。
+
+---
+
+## Consumers (消费者)
+
+这份报告的直接消费者是 `/blueprint` 阶段的:
+*   **System Architect**: 依赖你的风险清单来设计规避策略。
+*   **Complexity Guard**: 依赖你的发现来审计 RFC 复杂度。
+
+你的分析质量**直接决定**下一阶段的设计质量。

package/templates/.agent/skills/report-template/references/REPORT_TEMPLATE.md

@@ -0,0 +1,100 @@
+# System Context Report
+
+**Generated Date**: {{DATE}}
+**Analysis Target**: {{SCOPE}}
+
+## Executive Summary
+> [One sentence summary of the system's state, e.g., "A robust Python backend with some technical debt in the Auth module."]
+
+---
+
+## 1. Component Inventory
+
+### 1.1 Existing Components
+| Component | Type | Path | Description |
+|---|---|---|---|
+| [Name] | [Service/UI/DB] | [Path] | [Brief Desc] |
+
+### 1.2 Missing Components (Dark Matter)
+> [!WARNING]
+> The following components are missing but critical for production readiness.
+
+| Component | Category | Why Needed | Impact if Missing |
+|---|---|---|---|
+| Error Handling | Infrastructure | No central error boundary found | Debugging will be difficult |
+| Logging | Observability | No structured logging | Blind in production |
+| Config Mgmt | Ops | Hardcoded secrets detected | Security risk |
+
+---
+
+## 2. Dependency Topology
+
+### 2.1 Build Boundaries (Build Inspector)
+> [Insert findings from `build-inspector`: Build Roots, Topology, Sidecar Warnings]
+
+```mermaid
+graph TD
+    A[Module A] --> B[Module B]
+```
+
+### 2.2 Logical Coupling (Git Forensics)
+> [Insert Hotspot Matrix or Coupling Table]
+
+| File A | File B | Coupling | Risk |
+|---|---|---|---|
+| auth.py | user_db.py | 85% | HIGH |
+
+---
+
+## 3. Risks & Warnings
+
+### 3.1 IPC Contract Risks (Runtime Inspector)
+> [!CAUTION]
+> [List IPC surfaces with weak/no contracts found by `runtime-inspector`]
+
+### 3.2 God Modules
+> [List modules with excessive Ca (Afferent Coupling)]
+
+### 3.3 Tech Debt Hotspots
+> [List files with High Churn + High Complexity]
+
+---
+
+## 4. Implicit Constraints (Invariant Hunter)
+
+### 4.1 Business Invariants
+> [Rules that must never be broken]
+- Order total must be >= 0
+- User must verify email before payment
+
+### 4.2 Assumptions
+> [Unwritten assumptions found in code]
+- "Network is always reliable" (No retry logic)
+- "ID is always an integer"
+
+### 4.3 Hardcoded Values
+- API Keys
+- Timeout values
+
+---
+
+## 5. Conceptual Model (Concept Modeler)
+
+### 5.1 Ubiquitous Language
+| Term | Definition |
+|---|---|
+| User | A registered end-user (not an admin) |
+| Order | A purchase request |
+
+### 5.2 Data Flows
+> [Describe key flows]
+
+---
+
+## 6. Human Checkpoints
+> [!IMPORTANT]
+> Please confirm the following before proceeding to Blueprint Phase:
+
+- [ ] Is the Component Inventory complete?
+- [ ] Are the identified Risks acceptable for now?
+- [ ] Have all Invariants been captured?

package/templates/.agent/skills/runtime-inspector/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: runtime-inspector
+description: 分析运行时行为、进程边界和 IPC 机制，检测"协议漂移"风险和进程生命周期问题。
+---
+
+# 窃听者手册 (The Wiretapper's Casebook)
+
+> "代码会骗人，但进程不会。一个 `.spawn()` 暴露的比一千行注释还多。" —— 老窃听者箴言
+
+本技能的工作是**追踪进程间的通信线路**。
+
+**老师傅核心定律**: 如果两个进程说话，但没人规定它们说什么语言、什么版本、什么格式，那就是一场等待爆发的**协议漂移 (Protocol Mismatch)** 灾难。
+
+---
+
+## ⚠️ 强制深度思考
+
+> [!IMPORTANT]
+> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具，视情况进行 **3—5 步**推理。
+> 思考内容例如：
+> 1.  "这个项目有多少个入口点（`main` 函数）？它们是一个进程还是多个？"
+> 2.  "进程之间用什么通信？Pipe？HTTP？共享数据库？"
+> 3.  "如果我只更新了 A 进程的通信模块，B 进程会崩吗？有版本握手吗？"
+
+---
+
+## ⚡ 任务目标
+识别**运行时边界 (Runtime Boundaries)** 和 **通信契约 (Communication Contracts)**。
+
+---
+
+## 🧭 探索流程 (The Investigation)
+
+### 第一步：识别入口点 (Identify Entry Points)
+每个 `main` 函数可能代表一个独立的进程。
+*   **搜索目标**:
+    *   Rust: `fn main()`, `#[tokio::main]`
+    *   Python: `if __name__ == "__main__":`
+    *   Node: `require.main === module`, package.json 的 `bin`
+    *   Go: `func main()`
+*   **老师傅直觉**: 找到多个入口点？立刻问："它们是独立运行的，还是被一个父进程管控的？"
+
+### 第二步：追踪生成链 (Trace Spawning)
+如果进程 A 拉起了进程 B，这就是一条"血缘线"。
+*   **搜索目标**:
+    *   Rust: `Command::new(...)`, `std::process::Stdio`, `tauri-plugin-shell`
+    *   Python: `subprocess.Popen`, `multiprocessing.Process`
+    *   Node: `child_process.spawn`, `child_process.fork`
+*   **老师傅警报 (Lifecycle Risks)**:
+    *   ⚠️ "父进程死了，子进程知道吗？有心跳吗？" -> **僵尸进程风险 (Zombie Child)**
+    *   ⚠️ "子进程崩溃了，父进程会重启它吗？还是静默失败？" -> **静默故障风险**
+
+### 第三步：窃听通信 (Tap the Wire)
+进程之间用什么"说话"？协议在哪里定义？
+
+*   **搜索 Channels (通道)**:
+    *   `Pipe`, `NamedPipe`, `unix_stream`, `zmq`
+    *   `TcpListener`, `UdpSocket`, `websocket`, `http::server`
+*   **搜索 Protocols (协议)**:
+    *   `Handshake`, `Version`, `MagicBytes`, `schema`
+    *   `protobuf`, `serde_json`, `JSON.parse`, `enum Message`
+
+*   **老师傅核心判断 (Contract Status)**:
+
+    | 发现 | 状态 | 老师傅建议 |
+    | :--- | :---: | :--- |
+    | 找到 Channel + 找到 `enum Message` 或 Protobuf 定义 | 🟢 **Strong** | 契约存在，相对安全。 |
+    | 找到 Channel + 找到 `Version` 或 `Handshake` 检查 | 🟢 **Strong** | 有版本协商，很好。 |
+    | 找到 Channel + 只有 raw JSON/字符串 | 🟡 **Weak** | 无显式契约。改动一端可能炸另一端。 |
+    | 找到 Channel + 无任何协议定义 | 🔴 **None** | **通信黑洞！** 这是高危风险。 |
+
+---
+
+## 🛡️ IPC 风险模式速查 (来自安全研究)
+
+| 风险模式 | 检测特征 | 老师傅建议 |
+| :--- | :--- | :--- |
+| **协议漂移 (Protocol Mismatch)** | Channel 存在，但无 Handshake/Version | 在新功能规划中**强制添加版本握手任务** |
+| **僵尸进程 (Zombie Child)** | `spawn` 存在，但无 `Kill on Drop` 或心跳 | 标记进程生命周期管理风险 |
+| **单点故障 (SPOF)** | 一个进程管控所有 IPC，无容错 | 建议添加重连/重启逻辑 |
+| **Named Pipe 权限漏洞 (Windows)** | 使用 Named Pipe 但未显式设置 Security Descriptor | 🔴 高危：默认可能允许 Everyone 访问！ |
+| **竞态条件 (Race Condition)** | 多进程快速交互，无明确的消息顺序控制 | 建议添加消息序列号或锁机制 |
+
+---
+
+## 📤 输出清单
+
+1.  **Process Roots**: 发现的入口点列表（文件路径、角色）。
+2.  **Spawning Chains**: 进程生成关系 (A spawns B)。
+3.  **IPC Surfaces**: 发现的通信通道（类型、关键词、位置）。
+4.  **Contract Status**: `[Strong / Weak / None]`，并说明依据。
+5.  **Lifecycle Risks**: 僵尸进程、静默崩溃等风险。
+6.  **Security Flags (Windows)**: 如果是 Named Pipe，是否有 ACL 设置？

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

@@ -0,0 +1,58 @@
+---
+name: spec-writer
+description: Transforms ambiguous user requests into rigorous Product Requirements Documents (PRDs). Use when requirements are vague or high-level.
+---
+
+# The Detective's Guide (需求侦探手册)
+
+> "The hardest part of building software is deciding precisely what to build."
+
+Your job is to kill ambiguity.
+
+## ⚡ Quick Start
+
+1.  **Read Request (MANDATORY)**: Use `view_file` or context to identify "Vibe Words" (Fast, Modern, Easy).
+2.  **Deep Think (CRITICAL)**: You MUST call `sequential thinking` with 3-7 reasoning steps (depending on complexity) to:
+    *   Extract User Stories (As a X, I want Y, so that Z)
+    *   Identify ambiguities
+    *   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`.
+
+## 🛑 Mandatory Steps
+Before creating the PRD, you MUST:
+1. Extract at least 3 clear User Stories.
+2. Define at least 3 Non-Goals (what we're NOT building).
+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.
+
+## ✅ Completion Checklist
+- [ ] PRD file created: `genesis/v{N}/01_PRD.md`
+- [ ] Contains User Stories, Acceptance Criteria, Non-Goals
+- [ ] Every requirement is testable/measurable
+- [ ] User has approved the PRD
+
+## 🛠️ The Techniques
+
+### 1. Socratic Interrogation (苏格拉底追问)
+*   **User**: "I want it to be fast."
+*   **You**: "< 100ms p99? Or just UI optimistic updates?"
+*   *Goal*: Turn adjectives into numbers.
+
+### 2. Context Compression (上下文压缩)
+*   **Input**: 500 lines of chat history.
+*   **Action**: Extract the *User Stories*. "As a User, I want X, so that Y."
+*   **Discard**: Implementation details discussed too early (e.g., "Use Redis").
+
+### 3. Non-Goal Setting (画圈)
+*   Define what we are **NOT** doing.
+*   *Why*: Prevents scope creep. Prevents "What about X?" later.
+
+## ⚠️ Detective's Code
+
+1.  **Contract First**: If you can't test it, don't write it.
+2.  **No Solutions**: Describe *what*, not *how*. Leave *how* to the Architect.
+3.  **User Centric**: Every requirement must trace back to a user value.
+
+## 🧰 The Toolkit
+*   `references/prd_template.md`: The Product Requirements Document template.

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

@@ -0,0 +1,174 @@
+# Product Requirements Document (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]
+
+---
+
+## 1. Executive Summary
+<!-- Context Compression: State the "Why" and "What" in < 50 words. -->
+<!-- ⚠️ CRITICAL: This is the "elevator pitch". Must be < 50 words. -->
+
+[Briefly describe the problem being solved and the proposed solution. Focus on value.]
+
+---
+
+## 2. Background & Context
+<!-- ⭐ 新增: 提供充分背景，帮助后续System Design阶段理解 -->
+
+### 2.1 Problem Statement (问题陈述)
+- **Current Pain Point**: [用户面临的具体问题]
+- **Impact Scope**: [受影响的用户群体/业务范围]
+- **Business Impact**: [对业务的影响，如收入、用户满意度、效率]
+
+### 2.2 Opportunity (机会)
+[如果解决这个问题，能带来什么价值？定量描述]
+
+### 2.3 Reference & Competitors (参考与竞品) - 可选
+<!-- 了解市场已有解决方案，避免重复造轮子 -->
+- **Competitor A**: [特点、优缺点]
+- **Competitor B**: [特点、优缺点]
+- **Our Differentiation**: [我们的独特价值]
+
+---
+
+## 3. Goals & Non-Goals
+
+### 3.1 Goals
+<!-- ⚠️ CRITICAL: 必须使用 SMART 原则 (Specific, Measurable, Achievable, Relevant, Time-bound) -->
+
+- **[G1]**: [可衡量的目标，如: 用户登录成功率 > 95%]
+- **[G2]**: [可衡量的目标，如: 页面加载时间 < 2s]
+
+### 3.2 Non-Goals (Out of Scope)
+<!-- Crucial for preventing scope creep -->
+
+- **[NG1]**: [暂不考虑的功能，如: 第三方OAuth登录]
+- **[NG2]**: [未来版本的考虑，如: 多因素认证]
+
+---
+
+## 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)**:
+    *   [ ] ...
+*   **Priority**: P0/P1/P2
+
+<!-- 继续添加更多User Stories... -->
+
+---
+
+## 5. User Experience & Design (用户体验) - 可选
+<!-- ⭐ 新增: 描述关键的UX流程，帮助前端系统设计 -->
+
+### 5.1 Key User Flows (关键用户流程)
+<!-- 使用Mermaid流程图描述关键用户旅程 -->
+
+```mermaid
+graph LR
+    A[用户访问登录页] --> B[输入邮箱密码]
+    B --> C{认证}
+    C -->|成功| D[跳转Dashboard]
+    C -->|失败| E[显示错误提示]
+    E --> B
+```
+
+### 5.2 Design Guidelines (设计规范)
+- **UI Style**: [现代化、简洁、专业等]
+- **Color Palette**: [主色调、辅助色]
+- **Interactions**: [动画、反馈机制]
+
+---
+
+## 6. Constraint Analysis
+<!-- Derived from /scout report or /challenge -->
+<!-- ⭐ 增强: 分类更详细，便于后续System Design继承约束 -->
+
+### 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.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.3 Time & Budget (时间与预算)
+*   **Deadline**: [交付时间，如: 2026-03-01]
+*   **Budget**: [预算限制] - 可选
+*   **Team**: [团队规模和技能] - 可选
+
+---
+
+## 7. Success Metrics (成功指标)
+<!-- ⭐ 新增: 如何衡量成功，便于后续验证 -->
+
+| Metric | Target | Measurement Method |
+|--------|--------|-------------------|
+| 用户登录成功率 | > 95% | Google Analytics |
+| 页面加载时间 (p95) | < 2s | Lighthouse/监控 |
+| 用户满意度 (NPS) | > 4.5/5 | 用户调研 |
+
+---
+
+## 8. Definition of Done (完成标准)
+
+*   [ ] 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.
+
+---
+
+## 9. Appendix (附录) - 可选
+
+### 9.1 Glossary (术语表)
+- **[Term 1]**: [Definition]
+- **[Term 2]**: [Definition]
+
+### 9.2 References (参考资料)
+- [Link 1]
+- [Link 2]
+
+### 9.3 Change Log (变更日志)
+| Version | Date | Changes | Author |
+|---------|------|---------|--------|
+| 1.0 | 2026-01-08 | Initial version | XXX |
+
+---
+
+<!-- ⚠️ CRITICAL 使用指南 -->
+<!-- 
+**PRD撰写原则 (Amazon 6-pager风格)**:
+1. **精炼至上**: 总长度最多6页（约3000-4000字）
+2. **Executive Summary < 50字**: 电梯演讲
+3. **每个User Story < 100字**: 简洁清晰
+4. **数据驱动**: 所有目标和指标必须可衡量
+5. **追溯链**: 每个User Story有唯一ID [REQ-XXX]
+
+**章节使用指南**:
+- **必需章节**: 1, 2.1, 3, 4, 6, 8
+- **可选章节**: 2.3 (竞品分析), 5 (UX设计), 7 (成功指标), 9 (附录)
+- **小项目**: 可省略 2.3, 5, 9，但结构保持一致
+-->