0
异步视界/agentic-coding-classics/jesse-vincent-fulltext
· AGENTIC-CODING-CLASSICS · 2026.05.06 · 9 MIN ·

Jesse Vincent《我在 2025 年 9 月怎么用编程 Agent》(完整翻译版)

Superpowers 框架(GitHub 15 万 stars)的前传。Jesse Vincent 2025-10-05 发布,描述他用 git worktree + Claude Code 同时跑 3-4 个并行项目的工作流。逐段全译。 · by fancyoung
AI · HERO seed:4620260506 Superpowers 框架(GitHub 15 万 stars)的前传。Jesse Vincent 2025-10-05 发布,描述他用 git worktree + Claude Code 同时跑 3-4 个并行项目的工作流。逐段全译。
FIG.00 — cover · ai-generated · placeholder

原文:How I’m using coding agents in September, 2025 作者:Jesse Vincent (obra) —— Superpowers 框架作者、Prime Radiant 创始人 CEO、Perl 社区资深贡献者 原发布:2025-10-05 本译版定位:完整逐段中文翻译(配少量译注)。对应另一份精读版 02b-jesse-vincent-精读版.md(若有需要)。如需快速了解请读精读版,本文是给”想读完整原文中文版”的读者准备的。

译者前言

这是 Superpowers 方法论的前传 —— GitHub 15 万 stars 的 Superpowers 框架,把这一篇里描述的工作流工程化。建议你先把原文从头到尾读完,再回头看精读版的金句和点评。

下面是逐段翻译。所有方括号 [] 内是 Jesse 自己写的元注;所有 🟢 译注: 是我加的。

[眼尖的读者会注意到,我在写这篇时已是 2025 年 10 月。本文记录的是我两周前的做法。它依然有效,我依然推荐。]

自我夏初上次写这个话题以来,我用 AI 编程助手的方法论又演进了一些。这是一个时间切片记录 —— 写下当下对我相当有效的一套工作流。我目前主要还是用 Claude Code。

首先,这是我此刻在用的 CLAUDE.md。它把一堆流程文档和规则编码在一起,在让 Claude 不跑偏这件事上做得相当不错。

当我要在一个已有项目里开始一个新任务时,我会想方设法用 git worktree 把这个工作和其他任务隔离开。 这件事对我越来越重要,因为我经常在同一个 codebase 上同时跑 3-4 个并行项目。

cd the-project
mkdir .worktrees       # 第一次时建
cd .worktrees
git worktree add some-feature-description
cd some-feature-description
npm install            # 或者其他项目设置命令
npm lint
npm test               # 确保从一个干净的基线开始
claude

🟢 译注:worktree 是这套打法的物理基础。一旦你开始并行跑 Claude,文件冲突是头号杀手。worktree 给每个任务独立目录,从根本上消除冲突。

Claude Code 启动后,我会用我的 “头脑风暴 prompt”:

我有一个想法想跟你聊一下。我希望你帮我把它变成一个完整的设计和规格(并最终变成一份实施计划)。

先看看我们工作目录里项目当前的状态,理解我们从哪里出发,然后向我提问 —— 一次问一个问题 —— 来帮我细化这个想法。

最理想是多选题,但开放性问题也可以。别忘了:每条消息只问一个问题。

当你确信你理解了我们要做什么之后,停下来,把设计描述给我听,**每次描述大概 200-300 字**,每段之后问我 "到目前为止看起来对吗?"

最后一段特别关键。我发现 AI 模型一旦觉得 “做完了”,就特别爱甩一大段文字给我。而面对 agent 写出来的一大段文字,我就特别容易扫一眼然后想 “看起来还行吧”。通过命令 Claude 一次只输出 200-300 字,我更可能真正读进去并参与判断。

🟢 译注:把 “信息密度” 当作人机协作的可控变量,这是这篇里最朴素也最深刻的洞察之一。

走完头脑风暴后,我对自己要做什么、Claude 要做什么,通常已经清晰得多。Claude 会把设计写到 docs/plans/ 某个地方。

它经常很想直接跳进实现,但那不是我想要的工作方式。有时它会在我能阻止它之前就开始写代码。这种时候我按几下 ESC,把对话回退一点抓住它。最近我对 CLAUDE.md 的更新显著降低了它这种倾向。

接下来是规划环节。我用的规划 prompt 是:

很好。我需要你帮我写一份完整的实施计划。

假设这个工程师对我们的 codebase 一无所知,品味也存疑。把他需要知道的一切都文档化:每个任务要碰哪些文件、代码、测试、可能要查的文档、怎么测试它。

把整个计划拆成一口大小的任务给他。DRY、YAGNI、TDD、频繁 commit。

假设他是个熟练的开发者,但对我们的工具栈和问题域几乎一无所知。假设他不太懂好的测试设计。

请把这份计划完整、详细地写到 docs/plans/。

这会产出一份把所有事拆成微小步骤的计划,每一步都有清晰的指令和紧凑的上下文。这意味着到执行时,我通常不需要密切的逐步监督。

接下来,我在同一个工作目录开一个新的标签页或新窗口,启动另一个 Claude。我会跟它说类似:“请读 docs/plans/this-task-plan.md 和 <我们刚才命名的设计文档>。如果有问题告诉我。”

它通常会说计划写得很好。有时它会指出错误或不一致。这时我戴上 PM 的帽子,转回去让”架构师”那个 session 澄清或更新规划文档。

🟢 译注:“架构师 + 实施者”双 session 是这篇的核心机制。它本质上模拟了软件工程里”开发者 + 代码评审”的两人结构,只不过两人都是 Claude。

把计划的问题理顺之后,我让”实施者” Claude 执行:请执行前 3-4 个任务。如果有问题,停下来问我。绝对不要偏离计划。

实施者会埋头干活。

干完后,我切回 “架构师” session,告诉它:实施者说它做完了 1-3 任务。请仔细检查工作。

我又演 PM —— 在两个 session 之间复制粘贴评审和问答。等架构师签字通过,我让实施者把规划文档更新成当前状态。

然后,我不 /compact(压缩历史)。我直接 /clear 把实施者清空,从第 4 个任务开始重新对话。

🟢 译注:这一招是反直觉的关键。你以为长 session 保留上下文是好事,实际上 context 一长 LLM 就开始 “context rot”,质量越往后越差。每个任务块开始时清空 + 用规划文档做接力,反而保证每一轮都从满血状态出发。Ralph Loop 同样的物理原理。

下一块工作做完时,我切回架构师。我通常双击 ESC 把架构师重置到一个更早的检查点,告诉它评审到当前最新检查点。这降低架构师的 context 膨胀,让它没有上一轮实施带来的偏见重新看一遍。

(我有些朋友不用多 session,而是发誓只让实施者用 “以新鲜的眼光”(with fresh eyes)审一遍自己最近的工作就够了。这个魔法短语似乎相当有效。我还是认为有两个不同的 actor 更好。)

🟢 译注:with fresh eyes 是个很有意思的发现 —— 同一个 session 里,加这句话就能触发不同的注意力模式。

实施者最终干完、架构师签字之后,我让实施者推到 GitHub 创建 PR。

这会触发一次 CodeRabbit 代码评审。我发现 CodeRabbit 的评审在抓细节和逻辑问题上很好,但有时抓不住项目的真实设计意图或约束,会给出糟糕的建议。

CodeRabbit 的评审会给 AI agent 提供修复用的 prompt,但把这些 prompt 拿回到你的编程 agent 是件麻烦事 —— 你得一条条复制,而且它只对部分类型的问题给 prompt。我做了 coderabbit-review-helper 来解决这个问题:它把 CodeRabbit 各种类型的评审评论都挖出来,格式化成一大段文字给你的编程 agent 一口气啃。

唯一的问题是 —— 我们的机器人朋友相当好骗。你把一份指令清单粘给它,Claude 就照单全收 —— 哪怕你要求的事又疯又错。

我目前对此最好的应对是一点角色扮演,给编程 agent 一个不盲目相信代码评审的理由。每个评审前面我都加上这一段:

有一位评审者对这个 PR 做了一些分析。他是外部人,从零开始读 codebase。这是他对这次改动的分析,我希望你仔细评估这份分析和这位评审者本人。

1) 我们应不应该雇这位评审者?
2) 他标出来的问题里,哪些应该修?
3) 他提的修法是正确的修法吗?

任何应该修的,加到你的 todo list。
任何应该跳过的,现在告诉我。

CodeRabbit 这位 “评审者” 通常会拿到一个 “Strong hire”(强烈录用) 的评价。但偶尔 Claude 也会报告说**“这位评审者在技术上看起来相当熟练,但没花时间理解我们的项目,提了不少错误的建议。No hire(不录用)。”**

🟢 译注:绝妙。把 “评估代码评审” 重新框架成 “评估候选人面试表现”,一举把 Claude 从 “听话执行” 切换到 “批判判断” 模式。这是 prompt engineering 的高阶艺术 —— 不是改字句,是改任务身份。

如果你决定试试这套方法论,或者你搞出了对你更好用的别的方法,请发邮件给我:jesse@fsck.com。

© 1996–2026 Jesse Vincent. All rights reserved.

译者总评(发布时可作结尾)

读完这篇,你应该带走 5 件东西:

  1. Worktree 是物理基础 —— 没它,并行 agent 注定撞车
  2. 架构师/实施者双 session —— 单 session 是上一时代的事
  3. 每段输出限制在 200-300 字 —— 让人能读懂、读得进
  4. /clear > /compact —— 把每个任务块当作”全新员工 + 工作交接文档”
  5. 角色扮演重塑任务 —— “该不该雇这个评审者” 远远好过 “修不修这些 issue”

这篇的更深价值:它示范了一种 “人作为 PM” 的工作姿态。如果你还在用 “AI 是我的副驾驶” 心态,你已经落后了一年。

🔗 调研来源(可校验)