译：我在 2025.09 如何使用 Code Agent
原文： https://blog.fsck.com/2025/10/05/how-im-using-coding-agents-in-september-2025/
作者： Jesse Vincent
译者： Gemini 2.5 Pro
[眼尖的读者会注意到，我写这篇文章时已经是 2025 年 10 月了。本文记录的是我几周前的工作方式。这套方法依然很棒，我仍旧推荐它。]
自从夏天初我写上一篇文章以来，我使用 AI 编程助手的方法有了一些演进。这算是一份阶段性总结，记录了一套对我而言相当有效的工作流。
我主要使用的还是 Claude Code。
首先，这是我写本文时在用的 CLAUDE.md。它包含了一整套流程文档和规则，能很有效地让 Claude 保持在正轨上。
当我想在一个现有项目上开始一项新任务时，我总是尽量用 git worktree 来将这项工作与其他任务隔离开。这对我越来越重要，因为我发现自己经常在一个代码库上同时推进 3-4 个并行的项目。
设置一个 worktree 的步骤如下：
cd the-project
mkdir .worktrees # the first time
cd .worktrees
git worktree add some-feature-description
cd some feature-description
npm install # or whatever the setup task for the project is
npm lint
npm test # to make sure I'm starting from a clean baseline
claude
一旦 claude code 运行起来，我就会用我的“头脑风暴” prompt：
I've got an idea I want to talk through with you. I'd like you to help me turn it into a fully formed design and spec (and eventually an implementation plan)
Check out the current state of the project in our working directory to understand where we're starting off, then ask me questions, one at a time, to help refine the idea.
Ideally, the questions would be multiple choice, but open-ended questions are OK, too. Don't forget: only one question per message.
Once you believe you understand what we're doing, stop and describe the design to me, in sections of maybe 200-300 words at a time, asking after each section whether it looks right so far.
我有个想法想和你聊聊。我希望你帮我把它变成一个完整的设计和规范（并最终形成一份实现计划）。
先查看我们工作目录中项目的当前状态，了解我们的起点，然后一次只问我一个问题，帮我完善这个想法。
最好是多选题，但开放式问题也可以。别忘了：每条消息只问一个问题。
一旦你认为自己理解了我们在做什么，就停下来，把设计方案描述给我听，每次说大约 200-300 字，每说完一段就问我目前看起来是否正确。
最后那一点尤其关键。我发现 AI 模型特别容易在它们认为“搞定”的时候，丢给我一整面“文字墙”。而当我面对智能体写出的一大堆文字时，我也容易走神，心想“大概没问题吧”。通过告诉 Claude 每次输出限制在几百字，我才更有可能真正去阅读和思考。
走完头脑风暴流程后，通常我和 Claude 对要做的事情都有了清晰得多的认识。Claude 会把设计方案写到 docs/plans/ 目录下的某个地方。
它常常想直接跳到实现阶段，但这并不是我想要的工作方式。有时它会抢在我阻止之前就开始写代码。如果发生这种情况，我会按几下 escape 键，把对话回滚一点，把它“抓”回来。最近对 CLAUDE.md 的更新显著减少了这种倾向。
下一步是规划。这是我一直在用的规划 prompt：
Great. I need your help to write out a comprehensive implementation plan.
Assume that the engineer has zero context for our codebase and questionable taste. document everything they need to know. which files to touch for each task, code, testing, docs they might need to check. how to test it.give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. assume they don't know good test design very well.
please write out this plan, in full detail, into docs/plans/
很好。我需要你帮忙写一份全面的实现计划。
假设接手的工程师对我们的代码库一无所知，而且品味堪忧。记录下他们需要知道的一切：每个任务要动哪些文件，需要检查哪些代码、测试、文档，以及如何测试。把整个计划分解成小块任务交给他们。遵循 DRY、YAGNI、TDD 原则，并且要频繁提交。
假设他们是一位技术娴熟的开发者，但对我们的工具集或问题领域几乎一无所知。假设他们不太懂好的测试设计。
请把这份计划非常详细地写到 docs/plans/ 目录里。
这会生成一份计划，把所有事情都分解成非常小的步骤，每一步都有清晰的指令和高度相关的上下文。这意味着在执行阶段，我通常不需要进行严密的、一步步的监督。
接下来，我会在同一个工作目录下打开一个新标签页或窗口，再启动一个 Claude 实例。我告诉它类似这样的话：Please read docs/plans/this-task-plan.md and <whatever we named the design doc>. Let me know if you have questions.
它通常会说计划制定得非常好。有时它也会指出一些错误或不一致之处。这时我就戴上 PM 的帽子，转头去让那个“架构师”会话澄清或更新计划文档。
一旦我们解决了计划中的问题，我就会告诉“实现者” Claude：Please execute the first 3-4 tasks. If you have questions, please stop and ask me. DO NOT DEVIATE FROM THE PLAN.
然后这个实现者就会开始埋头干活。
等它完成后，我会切回到“架构师”会话，告诉它：实现者说它完成了任务 1-3。请仔细检查它的工作。
我会再次扮演 PM 的角色，在两个会话之间复制粘贴审查意见和问答。一旦架构师确认通过，我就会让实现者更新计划文档，标记出当前进度。
然后，我不会用 /compact。而是用 /clear 清空实现者的会话，然后重新开始对话，告诉它从任务 4 开始。
当它完成下一批工作后，我再切回架构师。我通常会按两下 ESC 键，将架构师重置到上一个检查点，然后让它审查到当前最新的检查点。这样做能减少“架构师”的上下文膨胀，并让它能不受之前实现的影响，重新审视代码。
（我有些朋友不使用多会话，他们坚信只要求实现者用 with fresh eyes 审视自己最近的工作就足够了。确实，这句咒语似乎相当强大。但我仍然认为，让两个不同的角色来分工更好。）
当实现者最终完成所有工作，并且架构师也确认通过后，我就会让实现者把代码推送到 GitHub 并创建一个 pull request。
这会触发 CodeRabbit 的代码审查。我通常发现 CodeRabbit 在挑出小毛病和逻辑问题上很在行，但有时在理解项目真正的设计意图或约束方面有所欠缺。这导致 CodeRabbit 会提出一些糟糕的建议。
CodeRabbit 的审查会提供用于修复问题的 prompt，但要把所有这些 prompt 反馈给你的编程智能体可能很麻烦，因为你需要一个一个地复制，而且它只为某些类型的问题提供 prompt。为了解决这个问题，我写了一个工具 coderabbit-review-helper。它会遍历 CodeRabbit 审查中所有不同类型的评论，并将它们格式化成一大段文本，供你的编程智能体处理。
这类工具唯一的问题是，我们的机器人伙伴相当轻信。如果你粘贴一串更新代码库的指令，Claude 会完全照单全收，即使你要求它做的事情既疯狂又错误。
我目前避免这种情况的最佳技巧，是进行一点角色扮演，给编程智能体一个理由，让它不要盲目相信代码审查。每次审查，我都会加上下面这段前缀：
A reviewer did some analysis of this PR. They're external, so reading the codebase cold. This is their analysis of the changes and I'd like you to evaluate the analysis and the reviewer carefully.
1) should we hire this reviewer
2) which of the issues they've flagged should be fixed?
3) are the fixes they propose the correct ones?
Anything we *should* fix, put on your todo list.
Anything we should skip, tell me about now.
一位审查员对这个 PR 做了一些分析。他是外部人员，所以对代码库并不熟悉。这是他对代码改动的分析，我希望你仔细评估这份分析以及这位审查员。
1) 我们该不该雇佣这位审查员？
2) 他们指出的问题中，哪些应该修复？
3) 他们提议的修复方案正确吗？
任何我们*应该*修复的，都加到你的待办事项里。
任何我们应该跳过的，现在就告诉我。
CodeRabbit 的“审查员”通常会得到“强烈推荐雇佣”的评价，但 Claude 给出这样的报告也并非闻所未闻：“这位审查员技术上似乎相当娴熟，但没有花时间去理解我们的项目，提出了许多错误的建议。不予雇佣。”
如果你打算试试这套方法，或者你已经有了更适合自己的、效果更好的方法，请写邮件给我 jesse@fsck.com。