程序员会为 Claude 编写文档,却不会为彼此编写。
Programmers will document for Claude, but not for each other

原始链接: https://blog.plover.com/2026/03/09/#documentation-wins-2

程序员常抱怨,同事们在为 Claude 这类 AI 工具编写文档时,比为人类同事编写文档要积极得多。然而,作者建议转换视角:将 AI 生成的文档视为宝贵的项目资产。 作者现在会指导 Claude 在整个项目生命周期中维护“交接”文档。在每个项目结束时,他们会要求 Claude 生成一份结构化的高层级摘要,概述所解决的问题及实施的变更。在审阅和编辑这些摘要(确保其达到与人工编写文档相同的标准)后,作者会将它们提交到代码仓库中。 这一流程大幅提升了效率:人工原本需要一小时才能完成的任务,AI 只需几秒钟即可起草完毕,且人类仅需极少的时间进行审阅。通过归档这些 AI 生成的摘要,开发者为未来的团队成员留下了有价值的记录,有效地弥合了机器辅助开发与协作知识共享之间的鸿沟。作者建议将这些 AI 输出视为专业工作成果,确保其经过核实并整合进项目的永久记录中。

这篇 Hacker News 讨论探讨了一个讽刺现象:程序员们越来越愿意为 Claude 等 AI 模型编写文档,尽管他们历来在为人类同事编写文档时往往表现怠慢。 贡献者们从多个角度解读了这种转变: * **实用性**:开发者们认为,为 AI 编写文档更具“生产力”,因为与人类同事不同,Claude 确实会解析这些指令。 * **“垃圾信息”问题**:持怀疑态度的人指出,以 AI 为中心的文档(如 `CLAUDE.md` 文件)往往容易过时、不准确,或导致对项目架构产生“幻觉”,从而陷入“垃圾进,垃圾出”的循环。 * **效率质疑**:一些用户质疑花费在调整提示词(Prompt)和维护 AI 配置上的时间是否真的提高了生产力,还是仅仅演变成了一种替代实际编码的新型拖延方式。 归根结底,虽然开发者们认可 AI 能够有效利用技术文档,但他们仍对维护负担以及因引入不可靠的、以 AI 为中心的指令而导致代码库被污染的风险保持警惕。
相关文章

原文

Programmers will document for Claude, but not for each other

A couple of days ago I recounted a common complaint:

I keep seeing programmers say how angry it makes them that people are willing to write detailed CLAUDE.md and PROJECT.md files for Claude to use, but they weren't willing to write them for their coworkers.

For larger projects, I've taken to having Claude maintain a handoff document that I can have the next Claude read, saying what we planned to do, what has been done, and other pertinent information. Then when I shut down one Claude I can have the next one read the file to get up to speed. Then I have the Claude !!n+1!! update it for Claude !!n+2!!.

After seeing the common complaint enough times I had a happy inspiration. I'd been throwing away Claude's handoff documents at the end of each project. Why do that? It's no trouble to copy the file into the repository and commit it. Someone in the future, wondering what was going on, might luckily find the right document with git grep and learn something useful.

I'm a little slow so it took me until this week to think of a better version of this: at the end of the project I now ask Claude to write up from scratch a detailed but high-level explanation of what problem we were solving and what changes we made, and I commit that. Not just running notes, but a structured overview of the whole thing.

I review these overviews carefully and make edits as necessary before I check them in. It's my signature on the commit, and my bank account receiving the paycheck, so nothing goes into the repository that I haven't read carefully and understood, same as if Claude were a human programmer under my supervision.

But Claude's explanations haven't required much editing. Claude's most recent project summary was around as good as what I could have written myself, maybe a little worse and maybe a little better. But it took ten seconds to write instead of an hour, and it didn't take anything like an hour to review.

The serious thing I had to fix the last time around was that Claude had used a previous, related report as a model, and the previous report had had a paragraph I had added at the end that said:

# Approved-by

Claude abstracted these notes from our discussions of the issue. Mark Dominus has read, reviewed, edited, and approved these notes.

Claude's new document had an identical section at the end. Oops! Fortunately, by the time I saw it, it was true, so I didn't have to delete it. I had Claude add a sentence to CLAUDE.md to tell it not to do this again.

My advice for the day:

  1. If you have Claude write down notes, check them into the repo when you're done. It probably can't hurt and it might help.

  2. Have Claude write a project summary, and then check it into the repo.

Maybe this is obvious? But it wasn't obvious to me. I'm still getting used to this new world.

[Other articles in category /tech/gpt] permanent link


联系我们 contact @ memedata.com