写或改进 README 时：按读者与项目类型选择模板并补齐关…

适用于创建、补充、更新或审查 README，并根据开源、个人、内部、配置等读者类型提供对应内容。

适用场景

解决思路

1. 先问自己或用户：谁会读这个 README，他们需要知道什么？
2. 询问当前正在处理哪类 README 任务：创建、添加、更新还是审查。
3. 识别任务为创建：新项目且还没有 README 时，进入创建初始 README 流程。
4. 识别任务为添加：需要记录新内容时，进入添加章节流程。
5. 识别任务为更新：能力已变化、内容过时时，进入更新现有内容流程。
6. 识别任务为审查：检查 README 是否仍然准确时，进入审查/刷新流程。
7. 创建初始 README 时，确认项目类型（见项目类型表）。
8. 创建初始 README 时，用一句话说明这个项目解决什么问题。
9. 创建初始 README 时，找出最快达到“it works”的路径。
10. 创建初始 README 时，确认是否有值得突出的内容。
11. 添加章节时，确认需要记录什么内容。
12. 添加章节时，确认它应放在现有结构的哪个位置。
13. 添加章节时，确认谁最需要这个信息。
14. 更新现有内容时，确认什么发生了变化。
15. 更新现有内容时，阅读当前 README 并找出过时章节。
16. 更新现有内容时，提出具体修改建议。
17. 审查/刷新时，阅读当前 README。
18. 审查/刷新时，对照项目实际状态检查（如 package.json、主文件等）。
19. 审查/刷新时，标出过时章节。
20. 审查/刷新时，如果存在 Last reviewed 日期，更新它。
21. 草稿完成后，始终询问：“还有什么值得强调或包含、但我可能遗漏的内容吗？”
22. 开源项目：面向贡献者和全球用户，关键章节为 Install、Usage、Contributing、License，使用 templates/oss.md。
23. 个人项目：面向未来的你、作品集查看者，关键章节为 What it does、Tech stack、Learnings，使用 templates/personal.md。
24. 内部项目：面向队友、新员工，关键章节为 Setup、Architecture、Runbooks，使用 templates/internal.md。
25. 配置项目：面向未来困惑的你，关键章节为 What's here、Why、How to extend、Gotchas，使用 templates/xdg-config.md。
26. 如果不清楚项目类型，询问用户；不要对所有内容都默认采用 OSS 设置。
27. 所有类型 README 至少包含 Name：自解释标题。
28. 所有类型 README 至少包含 Description：用 1-2 句话说明是什么和为什么。
29. 所有类型 README 至少包含 Usage：如何使用，最好有示例。
30. 参考 section-checklist.md：按项目类型确定应包含哪些章节。
31. 参考 style-guide.md：了解常见 README 错误和行文指导。
32. 参考 using-references.md：获取深入参考资料的使用指南。

适用边界 · 注意事项

• 当读者和项目类型不明确且无法向用户确认时，不要直接套用默认模板，尤其不要默认采用 OSS 设置。
• 当任务不是编写或改进 README，而是其他类型文档（如 API 文档、代码注释）时，不适用。
• 当无法访问项目实际状态（如 package.json、主文件）时，审查/刷新 README 的流程会受限。