文档全生命周期管理 — 从零起草、审查已有文档、一键修正，全程按小白友好标准执行
文档全生命周期管理：起草 → 审查 → 修正 核心原则：文科背景、技术零基础的团队成员，拿到文档能独立完成操作
/doc-review --write [主题] # 起草模式：从零写一篇符合标准的文档
/doc-review [文件路径] # 审查模式：检查现有文档，列出所有问题
/doc-review [文件路径] --fix # 修正模式：审查 + 直接改好
自然语言也可以触发：
目标读者：文科背景、技术零基础、不懂命令行，但有学习意愿的团队成员
合格标准：把文档交给这样的人，他能按文档独立完成操作，不需要额外解释。
所有模式都以这 10 条为基准：
| # | 标准 | 检查方式 |
|---|---|---|
| 1 | 专业术语首次出现必须解释 | 找所有英文词、缩写、技术名词，看有没有中文说明 |
| 2 | 命令参数必须注释（-t、-s、-g、--background 等） | 找所有带 - 或 -- 的参数，看有没有解释 |
| 3 | 键盘操作和终端命令必须分开写 | 找 bash 代码块里有没有混入 Ctrl+b、Enter 等键盘操作 |
| 4 | 快捷键说明先后顺序，不能只写按键组合 | 找快捷键说明，看有没有"先按…再按…"的说明 |
| 5 | # 注释必须是人话，不是技术备注 | 读每个 # 注释，判断完全不懂技术的人能否理解 |
| 6 | 类比/比喻先于技术定义 | 找复杂概念，看是否先用生活比喻再给技术解释 |
| 7 | 前提条件放在章节最前面 | 找每个操作章节，看有没有说"使用前提是…" |
| 8 | 英文缩写必须给出全称 | 找所有大写缩写（API、CLI、SSH 等），看有没有解释 |
| 9 | 流程步骤必须完整，不能跳步 | 找操作流程，模拟零基础人跟着做，看能不能走通 |
| 10 | 名词在文档中保持一致 | 同一个东西看有没有混用不解释 |
适用场景： 从零开始写一篇新文档，直接按小白标准生成，不需要事后再审查修正。
Step 1：理解需求
收集以下信息（没有的就根据主题合理推断）：
Step 2：确认结构
输出文档大纲，格式如下，等用户确认再开始写：
📋 准备起草：[文档主题]
建议结构：
1. 新手先读这里（是什么、为什么用、核心概念）
2. [章节1]
3. [章节2]
4. 常用操作速查
5. 常见问题
读者定位：[文科背景团队成员 / 其他]
预计篇幅：[长 / 中 / 短]
确认结构，还是要调整？
Step 3：起草文档
严格按以下写作规则生成：
写作规则（逐条执行）：
① 开头必须有"新手先读"板块，包含：
② 每个术语首次出现时立刻解释，格式：
术语（= 中文解释）> **X 是什么**：……③ 所有命令参数必须注释，格式：
# 参数说明：每个参数单独一行注释
# -s = session name，给会话取名字用的
# -t = target，告诉命令要操作哪一个
tmux new -s dev
④ 键盘操作和终端命令分开：
键盘操作：先按住 Ctrl+b 松开，再按 %⑤ 操作流程必须完整：
⑥ 必须有常见问题章节，收录真实会遇到的困惑，不是假设性问题
⑦ 文档头部必须有：创建日期、作者、适用对象
Step 4：自审
写完后，对照 10 条标准默默过一遍，发现问题直接改，不要输出有明显缺陷的版本。
Step 5：询问存储位置
✅ 文档起草完成。
存储建议：~/Documents/MyAIClone/80_工具箱/手册与文档/[文档名].md
确认存这里吗？还是指定其他路径？
适用场景： 检查已有文档，找出所有不符合小白标准的地方。
Step 1：读取文档
用 Read 工具读取指定文件。
Step 2：逐条扫描
按 10 条标准逐一扫描，记录每个问题：
Step 3：输出审查报告
## 📋 文档小白友好度审查报告
**文件**：[文件路径]
**审查时间**：[日期]
**整体评分**：[X / 10 条标准通过]
---
### ✅ 做得好的地方
- [列出已经符合标准的部分，给正向反馈]
### 🔴 必须修正（影响理解）
**问题 1**：[章节名]
- 原文：`[原文内容]`
- 问题：[为什么小白看不懂]
- 建议：[具体怎么改]
### 🟡 建议优化（可以更好）
**问题 X**：...
---
**总结**：[一句话说整体状态]
**下一步**：运行 `/doc-review [路径] --fix` 自动修正所有 🔴 问题
适用场景： 审查 + 直接改好，不需要手动逐条处理。
Step 1：内部完成审查（不输出报告）
Step 2：逐一修正
| 问题类型 | 修正方式 |
|---|---|
| 术语无解释 | 在术语后加括号说明，或加 > **X 是什么**：... |
| 参数无注释 | 在代码块内对应行加 # 参数 = 含义 |
| 键盘操作混在代码块 | 拆出来改成普通文本，注明"键盘操作：…" |
| 快捷键缺顺序说明 | 改成"先按住…松开，再按…" |
# 注释看不懂 | 用人话重写 |
| 缺比喻 | 在技术解释前加一句生活类比 |
| 缺前提条件 | 在章节开头加 > **使用前提**：… |
| 缩写无全称 | 首次出现改成"全称（缩写）"格式 |
| 步骤跳跃 | 补上缺失的中间步骤 |
Step 3：输出修正摘要
## ✅ 修正完成
**共修正 X 处：**
1. [章节] — [改了什么]
2. [章节] — [改了什么]
...
**需要你判断的地方：**
- [列出无法自动处理、需要人工决策的内容]
文档已更新，最后修改日期已同步。
参照文档：~/Documents/MyAIClone/80_工具箱/手册与文档/Claude_Code/Claude-Codex-协作桥接手册.md
术语解释密度参照：
attach → "附加/走进，像走进一个一直开着的房间"-t → "target，目标，告诉命令要操作哪一个"--background → "后台运行，不等结果，你可以继续做别的"repo → "repository 缩写，用 git 管理的项目文件夹"|| → "读作'或者'，前面失败了就做后面这个"比喻密度参照：
代码注释密度参照：
# alias = 别名。给一长串命令取一个短名字
# attach = 附加、走进
# -t dev = target（目标）是名叫 dev 的那个会话
# || = 读作"或者"
每一个参数、每一个关键词都要有注释，不能跳过。
在输出文档前，默默对照以下清单：
-x / --xxx 参数都有注释吗？8 条全过才算合格，否则继续改。