3.6 KiB
文档修改工作流
本流程适用于人工与 AI 作者。目标是把写作约定落实到每次修改，并避免无关文件或未经确认的语言决定进入提交。
1. 开始前
读取仓库 AGENTS.md、SKILL.md和目标主题的主要定义。保留已有修改；用户明确要求提交或推送时，再完成必要 Git 状态检查。独立安装的 skill 以指定目标仓库为准，不以当前目录猜测项目。
记录：
- 目标读者与本次阅读目标。
- 页面主要职责与本次改动范围。
- 适用的 DOC 规则 ID。
- 已确定语义、局部假设和未定设计。
- 预计需要同步的定义、示例、导航与状态。
2. 选择相关规则
先从任务索引选择路线，读取任务页及其指定方法、DOC 规则和案例。可合并任务；路线是本次工作的阅读范围，不是必须逐项填满的表单。
直接打开任务页列出的对应小节，实际阅读后再写作。纯错字修正走 edit；若出现语义强度变化，补 semantics；审查-only 走 review 并保持文件未改。
| 改动 | 最少阅读的相关规则 |
|---|---|
| 错字、链接或术语 | DOC-017、021 |
| 新增用法与示例 | DOC-004、009、010、012、013、015、021 |
| 新增或拆分章节 | DOC-001、002、005、006、007、008、021、024 |
| 外部资料研究 | DOC-020；再根据结论选相关规则 |
| AI 或跨电脑接续 | DOC-022、023；再选任务适用规则 |
本表概括常用规则；完整必读资源以所选任务页为准。引用规则页见规则索引。
3. 编辑
先修改主要定义，再同步依赖内容。使用适用的模板，但不要填满与主题无关的栏目。较大改动可用TPL-05 工作单记录读者目标、断言依据和影响页。
语法提案保持提案身份。涉及新的语言决定时，说明所需决定而不擅自补造语法。研究与作者规则放在 authoring，不混入读者语言主线。
4. 验证
默认人工核对示例计算、归属与引用、文法、链接及局部假设，并按审查标准走查相关读者任务。记录阻断问题是否消除、重要缺口是否处理、哪些检查不适用及原因。检查清单见 checklist.md。
只有用户明确要求执行代码时，才运行程序、脚本、测试或其他自动检查。已有工具、旧清单和完成目标都不构成执行授权；不擅自安装验证依赖。
工具只验证结构及有限约定，不证明语言可编译、程序正确或文档易懂。新工具的检查能力以 tools/README.md 为准。
5. 交付与提交
报告改动文件、目的、规则 ID、验证范围和未完成项目。用户要求提交或推送时：
- 检查暂存文件，排除无关编辑、个人配置与凭据。
- 使用仓库约定的作者与认证身份。
- 提交后核对提交文件与标识；推送后核对远端分支。
- 如被拒绝，保留本地提交并报告原因，不强推或改用其他账户。
6. 接续工作
另一作者从仓库文件和 Git 状态开始，不依赖聊天记忆。维护手册时保留 DOC、SRC 和 TPL 编号；新增来源先登记访问状态。
修改 skill 的任务入口、方法或核心约束后，选择评估场景走查实际任务与产物。人工结构核对、作者走查和独立测试分别记录；改进依据是观察到的决策缺口。