Skip to content
←

필사 모드: 与 AI 编程工具良好协作的五个习惯

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 数据已经出来，剩下的只有行动

在上一篇 AI 真的让开发者更快了吗 中，我谈到两个设计良好的随机对照试验给出了完全相反的答案。一边的开发者快了 55.8%，另一边却慢了 19%。

如果说那篇文章讲的是“什么被测量了”，那么这篇文章讲的就是 “那么明天早上，我该做点什么不一样的”。

下面五条不是偏好，而是规则。每一条都来自真实的研究，每一条都以一句你能在两周内反证的话收尾。

习惯 1 — 用熟悉度和验证成本来挑选任务

METR 把可能解释那 19% 减速的因素收敛到了五个。其中两个关乎 开发者与代码的关系。一个是对仓库的高度熟悉，另一个是隐性的仓库上下文 — 那些没有被写下来、模型无从触及的知识。

最锋利的一处发现是这个。开发者 在自己越熟悉的任务上，反而慢得越多。熟悉不是盾牌，而是税。

站在相反一端的是 Copilot 实验。绿地项目，规格明确，验证几秒钟就能完成。而收益 在经验较浅的开发者身上最大。

把两个结果压缩成一句话，就是：AI 在填补你所没有的上下文时取胜，在必须追赶你已经拥有的上下文时落败。 所以，轴有两条。

验证便宜（秒 / 分钟）验证昂贵（天 / 月）
不熟悉的领域最优区间。尽管放手去用。最危险的格子。 理解不了的东西，也评审不了。
熟悉的领域中庸。收益和损失都不大。METR 的格子。自己写更快。

右上角那一格才是真正的陷阱。从这里出来的 AI 产出会悄悄变成债务，而账单几个月后才寄到。

规则： 在委托之前，先用一行字回答两个问题。(1) 如果这是错的，我什么时候会发现？(2) 我能认出错误的答案吗？如果第 2 问的答案是“不能”，而第 1 问的答案是“几个月后”，那么你需要的不是工具，而是 先去学习。

习惯 2 — 无法评审的东西就不要合并

METR 的参与者最终接受的 AI 生成代码 不足 44%。而且 56% 的人表示，要把 AI 写的代码收拾干净，需要做大量修改。生成变便宜了，但阅读、判断、丢弃的时间原封不动地留了下来 — 而且什么产物都没留下。

2025 年的 Stack Overflow 调查（AI 部分为三万余份回答）从另一个角度讲了同一件事。

  • 最大的不满是 66% 的人指出的 “几乎正确，但并不完全正确” 的答案。
  • 第二位是 45.2% — 调试 AI 生成的代码反而更花时间。
  • 而 75.3% 的人表示，当他们无法信任 AI 的答案时，最终还是 去问人。

要点是这样的。明显错误的代码可以很便宜地被筛掉。 昂贵的是那些足以骗过评审、又错得足以让你付出代价的代码。也就是说，评审不是正事做完之后的杂务，评审 本身就是那件正事。

这里点出一个常见的自欺。让模型“解释一下你写的 diff”并不是验证。因为那份解释同样是生成物。真正的验证只有一种 — 运行它、测试它，并与你已知的不变量相互对照。

规则： 你对人写的 PR 设的体积上限，也照样施加到 AI 写的 PR 上。大到无法评审的 diff，就是无法合并的 diff。并且要把评审时间当作真正的预算，写进日历里。

如果验证是瓶颈，那么易读的代码就不是品味问题，而是吞吐量问题 — 正如 即使 AI 来维护你的代码，也要为人类而写 和 LLM 倦怠 中所论述的那样。

习惯 3 — 用机器护栏取代散文规则

Anthropic 的 Building Effective Agents 建议在工具设计中引入 防呆（poka-yoke）。也就是通过改变参数本身，让人“更难出错”。文档里的例子正是这种精神 — 如果模型总是搞错相对路径，那就不要在提示里叮嘱，而是 改变工具签名，强制要求绝对路径。同一份文档还说，要像投入人机界面（HCI）那样，同等地投入智能体界面（ACI），并且要真正把工具跑起来，观察模型会犯哪些错。

由此得出的原则很简单。规则文档里的一句话是请求，而失败的类型检查是事实。 散文只能被概率性地遵守，而编译器是被确定性地遵守。

// 散文规则: “不要用 raw number 表示货币值” -> 模型可能遵守，也可能不遵守。
// 机器护栏: 让它从一开始就通不过。
type Cents = number & { readonly __brand: 'Cents' }

export function charge(amount: Cents): Promise<Receipt> {
  /* ... */
}

charge(1000) // 类型错误。无论是人还是模型，都会在这里被拦住。
charge(toCents(1000)) // 通过。

这并不是 AI 时代才诞生的新原则。只是随着代码产量的增加，护栏的收益率陡然上升了 而已。

规则： 如果同一个错误你已经对模型指出过两次，就别再多写一行规则了，去 造一个检查。把它挪进类型、Lint 规则、测试、CI 门禁，或者更窄的函数签名之一即可。如果挪不进去，那它本来就是连人也没在遵守的规则。

习惯 4 — 给出正确的那一片，而不是全部

METR 列出的因素之一，是 隐性的仓库上下文。也就是那种存在于拥有五年经验的开发者脑子里、却哪里都没有写下来的知识。

常见的误解从这里开始。“那把所有东西都喂给它不就行了。”不对。把仓库里的 200 个文件塞进上下文，并不等于告诉了它不变量。不变量通常一句话就够了 — 这张表是只追加的、这个函数只在事务里被调用、这个缓存在部署时不会被清空。200 个文件不会告诉你这些，而一句话会。

Anthropic 的文档也指向同一个方向：从尽可能简单的方案开始，只在必要时才增加复杂度；很多情况下，配上检索和示例的单次调用就已经足够。上下文工程 不是往里塞更多的技术，而是决定拿掉什么的技术。

规则： 在动手之前，先写下 第一次看到这段代码的人可能会违反的 3~5 条约束。那份清单就是你的上下文。如果写不出来，那你正站在习惯 1 里那个危险的格子上。

还有一个副作用。那份清单通常可以原样用作团队文档。为了向模型解释而硬挤出来的隐性知识，其实也是你的同事所不曾拥有的知识。

习惯 5 — 别靠感觉，去测量自己的吞吐量

METR 里最令人不适的数字不是 19%。开发者们在开始前预测 AI 会让自己 快 24%。而在实际经历了慢 19% 之后，他们仍然估计自己 快了 20%。就连事后回顾，符号都是反的。经济学与机器学习专家的预测，也从方向上就错了。

原因很平常。因为生成是看得见的，而验证是看不见的。 模型在 3 秒内吐出 40 行的那一刻会留在记忆里；而读完它、丢掉一半的那 20 分钟，只会被感觉为“正在干活”。

所以在这个话题上，问卷与回顾是最不可信的工具。也正因如此，DORA 和 Stack Overflow 这类自我报告的数据，也应当假定它们偏向乐观来阅读。

规则： 两周，两列就够了。动手前写下预估时间，做完后写下实际时间以及是否用了 AI。但要测的 不是“到第一个 diff 为止”，而是“到合并并稳定下来为止”。因为“几乎正确，但并不完全正确”的代码，它的税永远是在初稿之后才寄来账单的。

AI 真正强大的地方

这篇文章要是被读成“别用 AI”就麻烦了，所以我要明确写下收益是真实的那些地方。

  • 规格明确的绿地项目。 Copilot 实验中的 95 名开发者用 JavaScript 写了一个 HTTP 服务器。Copilot 组平均耗时 1 小时 11 分，对照组是 2 小时 41 分。这个数字是真的。
  • 不熟悉的语言、API、框架。 模型比你读过更多那些文档。这是习惯 1 的最优区间。
  • 几秒钟就能验证的东西。 一次性脚本、脚手架、测试夹具、正则表达式、数据转换。错了立刻就看得出来。
  • 阅读方向的工作。 理解别人写的代码时。模型的说法可以当场与代码对照，所以验证很便宜。
  • 测试已经很密的区域里的机械性批量改动。 那是护栏已经立好的地方。

而且，经验越浅的开发者收益越大 — Copilot 实验的这个结果，正如作者们所说，对于想要转行进入软件开发的人来说是个好兆头。

为了不过度相信这些规则

METR 的局限。 16 名参与者、246 项任务、2025 年上半年的模型、成熟的大型开源仓库。作者们自己明确写道，这项研究并 没有 表明“AI 无法让大多数开发者更快”，也没有表明“没有办法把现有的 AI 用得更好”。

更重要的是，METR 自己正在改变实验设计这一事实。 在 2026 年 2 月的后续文章中，他们承认了严重的选择效应。有开发者即便每小时给 50 美元，也因为不愿意在没有 AI 的情况下工作而拒绝参与；30~50% 的开发者 根本就没有提交那些 AI 看起来会擅长的任务；而在同时运行多个智能体的工作流里，时间测量本身就失效了。新数据反而暗示了速度提升，但 METR 自己把它定性为“关于当前生产力效应的不可靠信号”。

Copilot 研究的局限。 任务只有一个，是绿地项目，而且测的是完成时间，既不是质量也不是可维护性。作者中包含 GitHub 的员工，这一点也值得记下来。

调查的局限。 Stack Overflow 是自我报告。而正是出于 METR 所展示的那个理由，自我报告在这个话题上是最难以采信的仪器。

所以上面这五条不是定律，而是 从当下可获得的最佳证据中提炼出来的经验法则。请用你自己的日志去反证它们。那也正是习惯 5 的要点。

结语

把五条缩成一句话，就是这样：AI 在填补你所没有的上下文时取胜，在必须追赶你已经拥有的上下文时落败。 剩下的四条，是这句话的操作细节 — 按这句话去挑选任务（1），把验证当作一等公民写进预算（2），把验证交给机器（3），把上下文压缩后再递过去（4），并测量它是否真的奏效（5）。

最后还有一条。这篇文章里的任何规则，都赢不过你两周份的日志。第五个习惯被放在最后，并不是偶然。

参考资料

현재 단락 (1/63)

在上一篇 [AI 真的让开发者更快了吗](/blog/2026-07-12-ai-developer-productivity-reality) 中，我谈到两个设计良好的随机对照试验给出了完全相反的答...

작성 글자: 0자원문 글자: 5,402자작성 단락: 0/63