developer-docs-editing-review

开发者文档编辑审查

在草稿完成后，使用此技能改进开发者文档。它将编辑视为验证和重构：检查文档是否准确、完整、结构合理、清晰、简洁且便于审阅。

此技能源自 Docs for Developers: An Engineer's Field Guide to Technical Writing，尤其是第 4 章“编辑文档”。此外，还结合了 Christopher Gales 和 Splunk Documentation Team 合著的 The Product Is Docs: Writing Technical Documentation in a Product Development Group 中经过改述的指导，尤其是第 15 章“技术编辑”和第 16 章“技术验证”。请勿在面向用户的输出中照抄书中的文字。来源：https://link.springer.com/book/10.1007/978-1-4842-7217-6

快速入门

1. 加载 guidelines.md，选择最精简且有用的参考资料集。
2. 确定文档类型、受众、事实来源和发布风险。
3. 分别检查技术准确性、完整性、结构、清晰度和简洁性。
4. 如果流程、迁移、安全、数据或生产变更需要正式验证，请使用 workflows/verify-technical-doc.md。
5. 完整编辑时，请使用 workflows/edit-developer-doc.md。
6. 用户要求审查时，先返回问题；用户要求编辑时，返回修订后的文本。

默认输出

审查文档时，请返回：

1. 问题 - 按对读者的风险排序，并尽可能注明文件和章节。
2. 缺失的验证 - 尚未核查的命令、示例、截图、API 事实或来源声明。
3. 验证方案 - 自测、主题专家审查、QA 测试或发布阻碍项。
4. 建议修改 - 具体修改内容或重写稿。
5. 审查人员安排 - 指明应由谁验证技术细节。
6. 剩余风险 - 编辑后仍存在的假设。

直接编辑时，请返回修订后的文档，以及简要的修改摘要和未解决的问题。

目录

需求	从这里开始
了解编辑步骤	references/core/knowledge.md
应用审查规则	references/core/knowledge.md
查看编辑和反馈示例	references/core/knowledge.md
完整编辑	workflows/edit-developer-doc.md
验证高风险技术文档	workflows/verify-technical-doc.md
根据任务选择流程	guidelines.md

核心原则

• 将写作与编辑分开；不要在未经验证的问题上润色。
• 优先处理影响读者的问题，而非风格偏好。
• 向合适的技术负责人提出具体的审查请求。
• 将高风险流程视为发布阻碍项，直至完成验证或明确接受风险。
• 根据用户需求整合反馈，而非根据审查者级别或评论数量。