CCClaude Code中文喂饭教程

实战：让 CC 写 README 和文档

Claude Code 写文档教程：写 README 和项目文档不能编故事，必须基于真实项目结构、真实脚本和真实限制。

直接复制

让 CC 写文档之前，先让它读项目事实。文档最怕编造命令、编造部署方式、编造项目能力。

请帮我补充项目 README 或使用说明。

要求：
1. 先只读分析项目结构、README、package.json、配置文件和入口文件。
2. 不要编造不存在的命令。
3. 不要写没有依据的部署方式。
4. 不要暴露 API Key、Token、账号或内部地址。
5. 标出哪些信息来自项目文件，哪些需要人工确认。
6. 文档面向第一次接手这个项目的人。

文档必须包含

不同文档的重点不一样。README 要让新人快速启动项目；接口文档要让调用方知道请求和响应；交接文档要让下一位接手者知道已经做了什么、还剩什么风险。

文档不是越长越好，重点是读者能完成任务：

文档目标完成标准
README新人知道项目是什么、怎么启动、怎么检查
使用教程用户能按顺序完成操作
API 文档调用方知道参数、响应和错误
部署说明发布人知道环境、构建、回滚
交接总结接手者知道现状、风险、下一步

文档类型怎么选

先判断读者是谁

写文档前先让 CC 判断读者，否则很容易写成泛泛说明。

请先判断这份文档的读者是谁。

文档目标：
【README / 接口说明 / 使用教程 / 交接总结 / 部署说明】

请回答：
1. 读者是谁。
2. 读者最关心什么。
3. 哪些内容必须写。
4. 哪些内容不应该写。
5. 需要从项目文件确认哪些事实。

不同文档的写法

文档类型必须回答的问题
README这是什么项目，怎么启动，怎么检查
使用教程用户按什么顺序操作，失败了怎么办
API 文档怎么请求，返回什么，错误码是什么
部署说明环境、配置、构建、回滚、风险
交接总结做了什么，改了哪里，怎么验证，剩什么

先让 CC 读事实

请先只读收集写文档需要的事实。

请输出：
1. 项目用途从哪里确认。
2. 技术栈从哪里确认。
3. 可用脚本从哪里确认。
4. 入口文件和关键目录。
5. 哪些信息还需要人工确认。
6. 哪些内容不能写进文档。

生成 README 模板

请基于已确认事实生成 README 草稿。

结构：
1. 项目简介。
2. 技术栈。
3. 目录结构。
4. 本地启动。
5. 构建和检查。
6. 常见问题。
7. 注意事项。

要求：
1. 不要编造命令。
2. 不要暴露密钥或内部地址。
3. 未确认内容标记为“待确认”。
4. 文字面向新人。

写使用教程模板

请基于当前项目写一份使用教程草稿。

要求：
1. 面向第一次使用的人。
2. 按学习或操作顺序写。
3. 每一步说明目的。
4. 只写已经确认的功能。
5. 常见失败情况要给排查方向。
6. 不要写“很简单”“显然”这类跳步骤的话。

写交接总结模板

请生成本次任务交接总结。

必须包含：
1. 原始目标。
2. 已完成内容。
3. 修改过的文件。
4. 已经验证的内容。
5. 未验证和剩余风险。
6. 下一步最小动作。
7. 不要继续采用的方案。

更新已有文档时

请更新已有文档，而不是重写整篇。

要求：
1. 保留原文中仍然正确的内容。
2. 只修改过期或缺失的部分。
3. 不要改变文档风格。
4. 标出新增内容依据。
5. 最后列出需要人工确认的地方。

新增文档后的同步检查

如果新增了文档，请检查是否需要同步：
1. 左侧导航或目录。
2. 学习路线。
3. 上一篇 / 下一篇链接。
4. sitemap 或索引。
5. 首页或专题入口。

文档验收

请验收刚才写的文档。

检查：
1. 是否包含编造命令。
2. 是否有敏感信息。
3. 新人能否按步骤启动项目。
4. 是否区分已确认和待确认。
5. 链接是否有效。
6. 是否和当前项目结构一致。

常见文档问题

文档收尾报告

请总结这次文档修改。

请说明：
1. 修改了哪些文档。
2. 新增内容依据是什么。
3. 是否有待确认内容。
4. 是否检查了链接、目录和学习路线。
5. 是否建议进入提交前检查。

验收结果

下一篇：补测试