用 AI 做源码拆解：一篇可信教程应该留下哪些证据

教程不是源码摘要

源码摘要只能告诉读者“项目里有什么”，一篇可复用的教程还需要回答“为什么这样设计”“什么时候值得用”和“如何验证”。

AI 很适合承担第一轮阅读和整理，但它不应该成为事实的唯一来源。更稳妥的做法是给每一个重要结论都留下来源位置：文件路径、代码片段、官方文档、版本号或实际运行结果。

推荐的五步工作流

第一步：锁定版本

不要只写“当前仓库”。记录分支、commit 和核验日期。对于快速变化的项目，这一步决定了文章能否被复查。

第二步：先画结构图

先看入口、配置、核心目录和运行脚本，再进入细节。结构图的作用是帮助读者建立地图，而不是展示你读过多少文件。

第三步：把事实和判断分开

“README 明确写了什么”是事实；“我认为这种设计适合什么团队”是判断。两者都可以写，但不能混在同一句话里。

第四步：至少复现一个路径

哪怕只复现一个安装命令、一个 API 调用或一个最小示例，也比完全依赖静态阅读更可靠。复现失败本身也是文章内容的一部分。

第五步：人工做发布门禁

文章发布前，至少检查：

• 关键结论是否有出处；
• 命令是否与当前版本一致；
• 是否把“可能”写成了“已经”；
• 是否包含不应公开的 Token、路径或个人信息；
• 是否正确标注原项目许可证。

AI 最适合做什么

AI 可以快速生成目录树、术语表、问题清单和初稿，也可以帮助发现文章前后矛盾。但最终文章应该保留人的判断：为什么值得关注、对谁有用、有哪些限制。

这套流程的目标不是让文章看起来像 AI 写的，而是让写作者把更多时间用于验证和解释。