序言：程序员不愿意为同事写文档，却愿意为 Claude 写详细的 CLAUDE.md——这个抱怨在技术社区中越来越常见。Mark Dominus 没有停留在这个抱怨上，而是想到了一个建设性的做法：让 Claude 在项目结束时生成一份结构化的项目总结，审阅后签入仓库。或许 AI 时代的文档写作，出路不在于改变人性，而在于改变流程。
原文：Programmers will document for Claude, but not for each other（作者：Mark Dominus，发表日期：2026-03-09）
几天前我转述了一个常见的抱怨：
我不断看到程序员们说，他们非常愤怒——人们愿意为 Claude 写详细的
CLAUDE.md和PROJECT.md文件，却不愿意为他们的同事写这些。
对于较大的项目，我已经养成了让 Claude 维护一份交接文档的习惯，这样我就可以让下一个 Claude 阅读它，其中说明了我们计划做什么、已经完成了什么，以及其他相关信息。然后当我关闭一个 Claude 时，我可以让下一个 Claude 阅读这份文件来快速上手。接着我再让第 n+1 个 Claude 为第 n+2 个 Claude 更新它。
在足够多次看到这个常见抱怨之后，我有了一个愉快的灵感。我之前一直在每个项目结束时丢掉 Claude 的交接文档。为什么要那样做呢？把文件复制到仓库里并提交，完全不费事。将来有人想知道当时发生了什么，或许会幸运地用 git grep 找到正确的文档，并学到一些有用的东西。
我有点迟钝，所以直到这周才想到更好的做法：现在在项目结束时，我会让 Claude 从头写一份详细但高层次的说明，解释我们解决了什么问题、做了哪些改动，然后我把这个签入仓库。不只是运行笔记，而是对整个项目的结构化概述。
在签入之前，我会仔细审阅这些概述，并根据需要做出修改。提交上签的是我的名字，银行账户里收到的也是我的薪水，所以没有任何东西能在未经我仔细阅读和理解的情况下进入仓库——就像 Claude 是我手下一个人类程序员一样。
但 Claude 的解释并没有需要太多修改。Claude 最近一次的项目总结差不多和我自己写的一样好，可能稍差一点，也可能稍好一点。但它花了十秒而不是一小时来写，而审阅它也没花到一小时那么久。
上次我必须认真修复的问题是，Claude 用之前一份相关报告作为模板，而前一份报告末尾有一段是我当时加上去的，写着：
Approved-by
Claude 从我们对问题的讨论中提炼了这些笔记。Mark Dominus 已阅读、审阅、编辑并批准这些笔记。
Claude 新生成的文档末尾有一段一模一样的内容。糟了！幸运的是，当我看到它时，它已经是正确的了，所以我不用删掉它。我让 Claude 在 CLAUDE.md 中添加了一句话，告诉它以后不要再这样做。
我今天的建议是：
- 如果你让 Claude 写笔记，完成后签入到仓库里。这大概不会有坏处，可能会有帮助。
- 让 Claude 写一份项目总结，然后签入到仓库里。
也许这显而易见？但这对我来说并不显而易见。我还在适应这个新世界。
