docs(zh-CN): sync Chinese docs with latest upstream changes (#304)

* docs(zh-CN): sync Chinese docs with latest upstream changes

* update

---------

Co-authored-by: neo <neo.dowithless@gmail.com>

docs/zh-CN/commands/build-fix.md

@@ -1,29 +1,64 @@
 # 构建与修复
 
-逐步修复 TypeScript 和构建错误：
+以最小、安全的更改逐步修复构建和类型错误。
 
-1. 运行构建：npm run build 或 pnpm build
+## 步骤 1：检测构建系统
 
-2. 解析错误输出：
-   * 按文件分组
-   * 按严重性排序
+识别项目的构建工具并运行构建：
 
-3. 对于每个错误：
-   * 显示错误上下文（前后 5 行）
-   * 解释问题
-   * 提出修复方案
-   * 应用修复
-   * 重新运行构建
-   * 验证错误是否已解决
+| 指示器 | 构建命令 |
+|-----------|---------------|
+| `package.json` 包含 `build` 脚本 | `npm run build` 或 `pnpm build` |
+| `tsconfig.json`（仅限 TypeScript） | `npx tsc --noEmit` |
+| `Cargo.toml` | `cargo build 2>&1` |
+| `pom.xml` | `mvn compile` |
+| `build.gradle` | `./gradlew compileJava` |
+| `go.mod` | `go build ./...` |
+| `pyproject.toml` | `python -m py_compile` 或 `mypy .` |
 
-4. 在以下情况停止：
-   * 修复引入了新的错误
-   * 同一错误在 3 次尝试后仍然存在
-   * 用户请求暂停
+## 步骤 2：解析并分组错误
 
-5. 显示摘要：
-   * 已修复的错误
-   * 剩余的错误
-   * 新引入的错误
+1. 运行构建命令并捕获 stderr
+2. 按文件路径对错误进行分组
+3. 按依赖顺序排序（先修复导入/类型错误，再修复逻辑错误）
+4. 统计错误总数以跟踪进度
 
-为了安全起见，一次只修复一个错误！
+## 步骤 3：修复循环（一次处理一个错误）
+
+对于每个错误：
+
+1. **读取文件** — 使用读取工具查看错误上下文（错误周围的 10 行代码）
+2. **诊断** — 确定根本原因（缺少导入、类型错误、语法错误）
+3. **最小化修复** — 使用编辑工具进行最小的更改以解决错误
+4. **重新运行构建** — 验证错误已消失且未引入新错误
+5. **移至下一个** — 继续处理剩余的错误
+
+## 步骤 4：防护措施
+
+在以下情况下停止并询问用户：
+
+* 一个修复**引入的错误比它解决的更多**
+* **同一错误在 3 次尝试后仍然存在**（可能是更深层次的问题）
+* 修复需要**架构更改**（不仅仅是构建修复）
+* 构建错误源于**缺少依赖项**（需要 `npm install`、`cargo add` 等）
+
+## 步骤 5：总结
+
+显示结果：
+
+* 已修复的错误（包含文件路径）
+* 剩余的错误（如果有）
+* 引入的新错误（应为零）
+* 针对未解决问题的建议后续步骤
+
+## 恢复策略
+
+| 情况 | 操作 |
+|-----------|--------|
+| 缺少模块/导入 | 检查包是否已安装；建议安装命令 |
+| 类型不匹配 | 读取两种类型定义；修复更窄的类型 |
+| 循环依赖 | 使用导入图识别循环；建议提取 |
+| 版本冲突 | 检查 `package.json` / `Cargo.toml` 中的版本约束 |
+| 构建工具配置错误 | 读取配置文件；与有效的默认配置进行比较 |
+
+为了安全起见，一次只修复一个错误。优先使用最小的改动，而不是重构。

docs/zh-CN/commands/claw.md

@@ -0,0 +1,79 @@
+---
+description: 启动 NanoClaw 代理 REPL —— 一个由 claude CLI 驱动的持久、会话感知的 AI 助手。
+---
+
+# Claw 命令
+
+启动一个交互式 AI 代理会话，该会话将会话历史持久化到磁盘，并可选择加载 ECC 技能上下文。
+
+## 使用方法
+
+```bash
+node scripts/claw.js
+```
+
+或通过 npm：
+
+```bash
+npm run claw
+```
+
+## 环境变量
+
+| 变量 | 默认值 | 描述 |
+|----------|---------|-------------|
+| `CLAW_SESSION` | `default` | 会话名称（字母数字 + 连字符） |
+| `CLAW_SKILLS` | *(空)* | 要加载为系统上下文的技能名称，以逗号分隔 |
+
+## REPL 命令
+
+在 REPL 内部，直接在提示符下输入这些命令：
+
+```
+/clear      Clear current session history
+/history    Print full conversation history
+/sessions   List all saved sessions
+/help       Show available commands
+exit        Quit the REPL
+```
+
+## 工作原理
+
+1. 读取 `CLAW_SESSION` 环境变量以选择命名会话（默认：`default`）
+2. 从 `~/.claude/claw/{session}.md` 加载会话历史
+3. 可选地从 `CLAW_SKILLS` 环境变量加载 ECC 技能上下文
+4. 进入一个阻塞式提示循环 —— 每条用户消息都会连同完整历史记录发送到 `claude -p`
+5. 响应会被追加到会话文件中，以便在重启后保持持久性
+
+## 会话存储
+
+会话以 Markdown 文件形式存储在 `~/.claude/claw/` 中：
+
+```
+~/.claude/claw/default.md
+~/.claude/claw/my-project.md
+```
+
+每一轮对话的格式如下：
+
+```markdown
+### [2025-01-15T10:30:00.000Z] 用户
+这个函数是做什么的？
+---
+### [2025-01-15T10:30:05.000Z] 助手
+这个函数用于计算...
+---
+```
+
+## 示例
+
+```bash
+# Start default session
+node scripts/claw.js
+
+# Named session
+CLAW_SESSION=my-project node scripts/claw.js
+
+# With skill context
+CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
+```

docs/zh-CN/commands/evolve.md

@@ -51,7 +51,7 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [
 * `new-table-step2`: "当添加数据库表时，更新模式"
 * `new-table-step3`: "当添加数据库表时，重新生成类型"
 
-→ 创建：`/new-table` 命令
+→ 创建：**new-table** 命令
 
 ### → 技能（自动触发）
 
@@ -84,7 +84,7 @@ python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [
 * `debug-step3`: "当调试时，创建最小复现"
 * `debug-step4`: "当调试时，用测试验证修复"
 
-→ 创建：`debugger` 代理
+→ 创建：**debugger** 代理
 
 ## 操作步骤
 

docs/zh-CN/commands/learn-eval.md

@@ -0,0 +1,92 @@
+---
+description: 从会话中提取可重用模式，在保存前自我评估质量，并确定正确的保存位置（全局与项目）。
+---
+
+# /learn-eval - 提取、评估、然后保存
+
+扩展 `/learn`，在写入任何技能文件之前加入质量门和保存位置决策。
+
+## 提取内容
+
+寻找：
+
+1. **错误解决模式** — 根本原因 + 修复方法 + 可重用性
+2. **调试技术** — 非显而易见的步骤、工具组合
+3. **变通方法** — 库的怪癖、API 限制、特定版本的修复
+4. **项目特定模式** — 约定、架构决策、集成模式
+
+## 流程
+
+1. 回顾会话，寻找可提取的模式
+
+2. 识别最有价值/可重用的见解
+
+3. **确定保存位置：**
+   * 提问："这个模式在其他项目中会有用吗？"
+   * **全局** (`~/.claude/skills/learned/`)：可在 2 个以上项目中使用的通用模式（bash 兼容性、LLM API 行为、调试技术等）
+   * **项目** (当前项目中的 `.claude/skills/learned/`)：项目特定的知识（特定配置文件的怪癖、项目特定的架构决策等）
+   * 不确定时，选择全局（将全局 → 项目移动比反向操作更容易）
+
+4. 使用此格式起草技能文件：
+
+```markdown
+---
+name: pattern-name
+description: "Under 130 characters"
+user-invocable: false
+origin: auto-extracted
+---
+
+# [描述性模式名称]
+
+**提取日期：** [日期]
+**上下文：** [简要描述此模式适用的场景]
+
+## 问题
+[此模式解决的具体问题 - 请详细说明]
+
+## 解决方案
+[模式/技术/变通方案 - 附带代码示例]
+
+## 何时使用
+[触发条件]
+```
+
+5. **在保存前自我评估**，使用此评分标准：
+
+   | 维度 | 1 | 3 | 5 |
+   |-----------|---|---|---|
+   | 具体性 | 仅抽象原则，无代码示例 | 有代表性代码示例 | 包含所有使用模式的丰富示例 |
+   | 可操作性 | 不清楚要做什么 | 主要步骤可理解 | 立即可操作，涵盖边界情况 |
+   | 范围契合度 | 过于宽泛或过于狭窄 | 基本合适，存在一些边界模糊 | 名称、触发器和内容完美匹配 |
+   | 非冗余性 | 几乎与另一技能相同 | 存在一些重叠但有独特视角 | 完全独特的价值 |
+   | 覆盖率 | 仅涵盖目标任务的一小部分 | 涵盖主要情况，缺少常见变体 | 涵盖主要情况、边界情况和陷阱 |
+
+   * 为每个维度评分 1–5
+   * 如果任何维度评分为 1–2，改进草案并重新评分，直到所有维度 ≥ 3
+   * 向用户展示评分表和最终草案
+
+6. 请求用户确认：
+   * 展示：提议的保存路径 + 评分表 + 最终草案
+   * 在写入前等待明确确认
+
+7. 保存到确定的位置
+
+## 第 5 步的输出格式（评分表）
+
+| 维度 | 评分 | 理由 |
+|-----------|-------|-----------|
+| 具体性 | N/5 | ... |
+| 可操作性 | N/5 | ... |
+| 范围契合度 | N/5 | ... |
+| 非冗余性 | N/5 | ... |
+| 覆盖率 | N/5 | ... |
+| **总计** | **N/25** | |
+
+## 注意事项
+
+* 不要提取琐碎的修复（拼写错误、简单的语法错误）
+* 不要提取一次性问题（特定的 API 中断等）
+* 专注于能在未来会话中节省时间的模式
+* 保持技能聚焦 — 每个技能一个模式
+* 如果覆盖率评分低，在保存前添加相关变体

docs/zh-CN/commands/plan.md

@@ -106,9 +106,9 @@ Agent (planner):
 
 计划之后：
 
-* 使用 `/tdd` 以测试驱动开发的方式实施
-* 如果出现构建错误，使用 `/build-fix`
-* 使用 `/code-review` 审查已完成的实施
+* 使用 `/tdd` 通过测试驱动开发来实现
+* 如果出现构建错误，请使用 `/build-fix`
+* 使用 `/code-review` 来审查已完成的实现
 
 ## 相关代理
 

docs/zh-CN/commands/refactor-clean.md

@@ -1,28 +1,83 @@
 # 重构清理
 
-通过测试验证安全识别并删除无用代码：
+通过测试验证安全识别和删除死代码的每一步。
 
-1. 运行无用代码分析工具：
-   * knip：查找未使用的导出和文件
-   * depcheck：查找未使用的依赖项
-   * ts-prune：查找未使用的 TypeScript 导出
+## 步骤 1：检测死代码
 
-2. 在 .reports/dead-code-analysis.md 中生成综合报告
+根据项目类型运行分析工具：
 
-3. 按严重程度对发现进行分类：
-   * 安全：测试文件、未使用的工具函数
-   * 注意：API 路由、组件
-   * 危险：配置文件、主要入口点
+| 工具 | 查找内容 | 命令 |
+|------|--------------|---------|
+| knip | 未使用的导出、文件、依赖项 | `npx knip` |
+| depcheck | 未使用的 npm 依赖项 | `npx depcheck` |
+| ts-prune | 未使用的 TypeScript 导出 | `npx ts-prune` |
+| vulture | 未使用的 Python 代码 | `vulture src/` |
+| deadcode | 未使用的 Go 代码 | `deadcode ./...` |
+| cargo-udeps | 未使用的 Rust 依赖项 | `cargo +nightly udeps` |
 
-4. 仅建议安全的删除操作
+如果没有可用工具，使用 Grep 查找零次导入的导出：
 
-5. 每次删除前：
-   * 运行完整的测试套件
-   * 验证测试通过
-   * 应用更改
-   * 重新运行测试
-   * 如果测试失败则回滚
+```
+# Find exports, then check if they're imported anywhere
+```
 
-6. 显示已清理项目的摘要
+## 步骤 2：分类发现结果
 
-切勿在不首先运行测试的情况下删除代码！
+将发现结果按安全层级分类：
+
+| 层级 | 示例 | 操作 |
+|------|----------|--------|
+| **安全** | 未使用的工具函数、测试辅助函数、内部函数 | 放心删除 |
+| **谨慎** | 组件、API 路由、中间件 | 验证没有动态导入或外部使用者 |
+| **危险** | 配置文件、入口点、类型定义 | 在操作前仔细调查 |
+
+## 步骤 3：安全删除循环
+
+对于每个 **安全** 项：
+
+1. **运行完整测试套件** — 建立基准（全部通过）
+2. **删除死代码** — 使用编辑工具进行精确删除
+3. **重新运行测试套件** — 验证没有破坏任何功能
+4. **如果测试失败** — 立即使用 `git checkout -- <file>` 回滚并跳过此项
+5. **如果测试通过** — 处理下一项
+
+## 步骤 4：处理谨慎项
+
+在删除 **谨慎** 项之前：
+
+* 搜索动态导入：`import()`、`require()`、`__import__`
+* 搜索字符串引用：配置中的路由名称、组件名称
+* 检查是否从公共包 API 导出
+* 验证没有外部使用者（如果已发布，请检查依赖项）
+
+## 步骤 5：合并重复项
+
+删除死代码后，查找：
+
+* 近似的重复函数（>80% 相似）— 合并为一个
+* 冗余的类型定义 — 整合
+* 没有增加价值的包装函数 — 内联它们
+* 没有作用的重新导出 — 移除间接引用
+
+## 步骤 6：总结
+
+报告结果：
+
+```
+Dead Code Cleanup
+──────────────────────────────
+Deleted:   12 unused functions
+           3 unused files
+           5 unused dependencies
+Skipped:   2 items (tests failed)
+Saved:     ~450 lines removed
+──────────────────────────────
+All tests passing ✅
+```
+
+## 规则
+
+* **切勿在不先运行测试的情况下删除代码**
+* **一次只删除一个** — 原子化的变更便于回滚
+* **如果不确定就跳过** — 保留死代码总比破坏生产环境好
+* **清理时不要重构** — 分离关注点（先清理，后重构）

docs/zh-CN/commands/test-coverage.md

@@ -1,28 +1,69 @@
 # 测试覆盖率
 
-分析测试覆盖率并生成缺失的测试：
+分析测试覆盖率，识别缺口，并生成缺失的测试以达到 80%+ 的覆盖率。
 
-1. 运行带有覆盖率的测试：npm test --coverage 或 pnpm test --coverage
+## 步骤 1：检测测试框架
 
-2. 分析覆盖率报告 (coverage/coverage-summary.json)
+| 指标 | 覆盖率命令 |
+|-----------|-----------------|
+| `jest.config.*` 或 `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
+| `vitest.config.*` | `npx vitest run --coverage` |
+| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
+| `Cargo.toml` | `cargo llvm-cov --json` |
+| `pom.xml` 与 JaCoCo | `mvn test jacoco:report` |
+| `go.mod` | `go test -coverprofile=coverage.out ./...` |
 
-3. 识别覆盖率低于 80% 阈值的文件
+## 步骤 2：分析覆盖率报告
 
-4. 对于每个覆盖率不足的文件：
-   * 分析未测试的代码路径
-   * 为函数生成单元测试
-   * 为 API 生成集成测试
-   * 为关键流程生成端到端测试
+1. 运行覆盖率命令
+2. 解析输出（JSON 摘要或终端输出）
+3. 列出**覆盖率低于 80%** 的文件，按最差情况排序
+4. 对于每个覆盖率不足的文件，识别：
+   * 未测试的函数或方法
+   * 缺失的分支覆盖率（if/else、switch、错误路径）
+   * 增加分母的死代码
 
-5. 验证新测试通过
+## 步骤 3：生成缺失的测试
 
-6. 显示覆盖率指标的前后对比
+对于每个覆盖率不足的文件，按以下优先级生成测试：
 
-7. 确保项目整体覆盖率超过 80%
+1. **快乐路径** — 使用有效输入的核心功能
+2. **错误处理** — 无效输入、缺失数据、网络故障
+3. **边界情况** — 空数组、null/undefined、边界值（0、-1、MAX\_INT）
+4. **分支覆盖率** — 每个 if/else、switch case、三元运算符
 
-重点关注：
+### 测试生成规则
 
-* 正常路径场景
-* 错误处理
-* 边界情况（null、undefined、空值）
-* 边界条件
+* 将测试放在源代码旁边：`foo.ts` → `foo.test.ts`（或遵循项目惯例）
+* 使用项目中现有的测试模式（导入风格、断言库、模拟方法）
+* 模拟外部依赖项（数据库、API、文件系统）
+* 每个测试都应该是独立的 — 测试之间没有共享的可变状态
+* 描述性地命名测试：`test_create_user_with_duplicate_email_returns_409`
+
+## 步骤 4：验证
+
+1. 运行完整的测试套件 — 所有测试必须通过
+2. 重新运行覆盖率 — 验证改进
+3. 如果仍然低于 80%，针对剩余的缺口重复步骤 3
+
+## 步骤 5：报告
+
+显示前后对比：
+
+```
+Coverage Report
+──────────────────────────────
+File                   Before  After
+src/services/auth.ts   45%     88%
+src/utils/validation.ts 32%    82%
+──────────────────────────────
+Overall:               67%     84%  ✅
+```
+
+## 重点关注领域
+
+* 具有复杂分支的函数（高圈复杂度）
+* 错误处理程序和 catch 块
+* 整个代码库中使用的工具函数
+* API 端点处理程序（请求 → 响应流程）
+* 边界情况：null、undefined、空字符串、空数组、零、负数

docs/zh-CN/commands/update-codemaps.md

@@ -1,21 +1,73 @@
 # 更新代码地图
 
-分析代码库结构并更新架构文档：
+分析代码库结构并生成简洁的架构文档。
 
-1. 扫描所有源文件的导入、导出和依赖关系
+## 步骤 1：扫描项目结构
 
-2. 以以下格式生成简洁的代码地图：
-   * codemaps/architecture.md - 整体架构
-   * codemaps/backend.md - 后端结构
-   * codemaps/frontend.md - 前端结构
-   * codemaps/data.md - 数据模型和模式
+1. 识别项目类型（单体仓库、单应用、库、微服务）
+2. 查找所有源码目录（src/, lib/, app/, packages/）
+3. 映射入口点（main.ts, index.ts, app.py, main.go 等）
 
-3. 计算与之前版本的差异百分比
+## 步骤 2：生成代码地图
 
-4. 如果变更 > 30%，则在更新前请求用户批准
+在 `docs/CODEMAPS/`（或 `.reports/codemaps/`）中创建或更新代码地图：
 
-5. 为每个代码地图添加新鲜度时间戳
+| 文件 | 内容 |
+|------|----------|
+| `architecture.md` | 高层系统图、服务边界、数据流 |
+| `backend.md` | API 路由、中间件链、服务 → 仓库映射 |
+| `frontend.md` | 页面树、组件层级、状态管理流 |
+| `data.md` | 数据库表、关系、迁移历史 |
+| `dependencies.md` | 外部服务、第三方集成、共享库 |
 
-6. 将报告保存到 .reports/codemap-diff.txt
+### 代码地图格式
 
-使用 TypeScript/Node.js 进行分析。专注于高层结构，而非实现细节。
+每个代码地图应为简洁风格 —— 针对 AI 上下文消费进行优化：
+
+```markdown
+# 后端架构
+
+## 路由
+POST /api/users → UserController.create → UserService.create → UserRepo.insert
+GET  /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
+
+## 关键文件
+src/services/user.ts (业务逻辑，120行)
+src/repos/user.ts (数据库访问，80行)
+
+## 依赖项
+- PostgreSQL (主要数据存储)
+- Redis (会话缓存，速率限制)
+- Stripe (支付处理)
+```
+
+## 步骤 3：差异检测
+
+1. 如果存在先前的代码地图，计算差异百分比
+2. 如果变更 > 30%，显示差异并在覆盖前请求用户批准
+3. 如果变更 <= 30%，则原地更新
+
+## 步骤 4：添加元数据
+
+为每个代码地图添加一个新鲜度头部：
+
+```markdown
+<!-- Generated: 2026-02-11 | Files scanned: 142 | Token estimate: ~800 -->
+```
+
+## 步骤 5：保存分析报告
+
+将摘要写入 `.reports/codemap-diff.txt`：
+
+* 自上次扫描以来添加/删除/修改的文件
+* 检测到的新依赖项
+* 架构变更（新路由、新服务等）
+* 超过 90 天未更新的文档的陈旧警告
+
+## 提示
+
+* 关注**高层结构**，而非实现细节
+* 优先使用**文件路径和函数签名**，而非完整代码块
+* 为高效加载上下文，将每个代码地图保持在 **1000 个 token 以内**
+* 使用 ASCII 图表表示数据流，而非冗长的描述
+* 在主要功能添加或重构会话后运行

docs/zh-CN/commands/update-docs.md

@@ -1,31 +1,86 @@
 # 更新文档
 
-从单一事实来源同步文档：
+将文档与代码库同步，从单一事实来源文件生成。
 
-1. 读取 package.json 的 scripts 部分
-   * 生成脚本参考表
-   * 包含来自注释的描述
+## 步骤 1：识别单一事实来源
 
-2. 读取 .env.example
-   * 提取所有环境变量
-   * 记录其用途和格式
+| 来源 | 生成内容 |
+|--------|-----------|
+| `package.json` 脚本 | 可用命令参考 |
+| `.env.example` | 环境变量文档 |
+| `openapi.yaml` / 路由文件 | API 端点参考 |
+| 源代码导出 | 公共 API 文档 |
+| `Dockerfile` / `docker-compose.yml` | 基础设施设置文档 |
 
-3. 生成 docs/CONTRIB.md，内容包含：
-   * 开发工作流程
-   * 可用脚本
-   * 环境设置
-   * 测试流程
+## 步骤 2：生成脚本参考
 
-4. 生成 docs/RUNBOOK.md，内容包含：
-   * 部署流程
-   * 监控和警报
-   * 常见问题及修复
-   * 回滚流程
+1. 读取 `package.json` (或 `Makefile`, `Cargo.toml`, `pyproject.toml`)
+2. 提取所有脚本/命令及其描述
+3. 生成参考表格：
 
-5. 识别过时的文档：
-   * 查找 90 天以上未修改的文档
-   * 列出以供人工审查
+```markdown
+| Command | Description |
+|---------|-------------|
+| `npm run dev` | 启动带热重载的开发服务器 |
+| `npm run build` | 执行带类型检查的生产构建 |
+| `npm test` | 运行带覆盖率测试的测试套件 |
+```
 
-6. 显示差异摘要
+## 步骤 3：生成环境文档
 
-单一事实来源：package.json 和 .env.example
+1. 读取 `.env.example` (或 `.env.template`, `.env.sample`)
+2. 提取所有变量及其用途
+3. 按必需项与可选项分类
+4. 记录预期格式和有效值
+
+```markdown
+| 变量 | 必需 | 描述 | 示例 |
+|----------|----------|-------------|---------|
+| `DATABASE_URL` | 是 | PostgreSQL 连接字符串 | `postgres://user:pass@host:5432/db` |
+| `LOG_LEVEL` | 否 | 日志详细程度（默认：info） | `debug`, `info`, `warn`, `error` |
+```
+
+## 步骤 4：更新贡献指南
+
+生成或更新 `docs/CONTRIBUTING.md`，包含：
+
+* 开发环境设置（先决条件、安装步骤）
+* 可用脚本及其用途
+* 测试流程（如何运行、如何编写新测试）
+* 代码风格强制（linter、formatter、预提交钩子）
+* PR 提交清单
+
+## 步骤 5：更新运行手册
+
+生成或更新 `docs/RUNBOOK.md`，包含：
+
+* 部署流程（逐步说明）
+* 健康检查端点和监控
+* 常见问题及其修复方法
+* 回滚流程
+* 告警和升级路径
+
+## 步骤 6：检查文档时效性
+
+1. 查找 90 天以上未修改的文档文件
+2. 与最近的源代码变更进行交叉引用
+3. 标记可能过时的文档以供人工审核
+
+## 步骤 7：显示摘要
+
+```
+Documentation Update
+──────────────────────────────
+Updated:  docs/CONTRIBUTING.md (scripts table)
+Updated:  docs/ENV.md (3 new variables)
+Flagged:  docs/DEPLOY.md (142 days stale)
+Skipped:  docs/API.md (no changes detected)
+──────────────────────────────
+```
+
+## 规则
+
+* **单一事实来源**：始终从代码生成，切勿手动编辑生成的部分
+* **保留手动编写部分**：仅更新生成的部分；保持手写内容不变
+* **标记生成的内容**：在生成的部分周围使用 `<!-- AUTO-GENERATED -->` 标记
+* **不主动创建文档**：仅在命令明确要求时才创建新的文档文件