程序员会为 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 等人工智能工具编写详尽的文档。 参与者指出了这种转变背后的几个现实原因: * **可靠性:** 与许多人类不同,Claude 确实会阅读、处理并根据提供的文档采取行动。 * **直接投资回报率(ROI):** 为人工智能编写文档可以通过减少幻觉并提高代码质量,带来直接且显著的生产力提升。相比之下,为人类编写文档往往是吃力不讨好的工作,因为同事经常无视书面指南、倾向于直接提问,或者认为这项工作“有失身份”。 * **职业激励:** 在许多企业环境中,编写文档并不是一项被认可的绩效指标;在某些情况下,同行竞争甚至会诱导人们通过囤积知识来保持优势。 虽然一些用户警告称,这种转变反映了科技文化中一种令人担忧的反社会倾向——即我们优先考虑机器交互而非人类协作,但另一些人则认为这是对更优工具的一种理性反应。归根结底,许多人现在将针对人工智能的“规范驱动开发”(spec-driven development)视为理清自身思路的一种方式,并确保项目无论对未来的开发者还是对自己而言,都能保持可维护性。
相关文章

原文

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