技能介绍

解决什么问题

代码写完了，但文档常常是最后补上、甚至没人写的部分。手工维护文档会遇到几个具体麻烦：API 参考里同一个字段在十个接口里写法不一致；面向新手的教程跳过了前提配置，照着做就报错；变更日志只有一句话“修复若干问题”，回滚和升级时根本不知道影响面。这个技能负责把这些素材整理成结构稳定的技术文档，而不是替你宣传产品。

核心能力与工作方式

技能先判断文档类型和读者，再决定措辞与深度：新手教程要把每一步写清楚，给资深工程师的 API 参考则可以简短精确。之后收集权威来源，包括源码、OpenAPI/Swagger 规格、设计文档和提交历史，并设计对应类型的结构模板：API 参考使用统一的端点模板，架构文档使用 decision-record 的 context/decision/consequences 结构，教程按步骤递进。

写作阶段优先使用主动语态和短句，每个小节把最关键的信息放在开头，代码示例要求完整可运行，包含导入、变量声明和预期输出；表格用来描述参数与响应字段，长文档加上目录、锚点链接和 Next steps。最后一步是复核：确认代码示例可编译运行，端点路径、参数与响应结构与实现一致，教程每一步都能得到描述中的结果，文档里不留 TODO 或占位文本。

适用边界与注意点

素材不足时，技能会列出缺失项并要求补充，而不是猜测字段含义或补齐权限描述。涉及联网检索、接口调用，或发送、发布、部署、同步等外部写入时，会先说明目标、数据和影响，取得明确确认后再执行。命令和脚本默认只作为可审查的参考方案；只有在目标路径清楚、完成预检且用户明确要求时，才运行最小必要步骤。凭据仅用于用户指定的官方服务，不回显、不记录，也不写进交付物。无法验证的行为会被标为当前行为并提示工程团队确认。