AI 编程的现实主义：为什么是 2x 而不是 10x——兼谈重构的 Token 经济学
2026 年 7 月底，两篇关于 AI 编程的文章先后登上 Hacker News 首页：一篇是独立开发者 obryant 的《2x, not 10x: coding with LLMs in 2026》（214 分），另一篇是 Thoughtworks CTO Giles Edwards-Alexander 在 Martin Fowler 博客发表的《The Economic Benefit of Refactoring》（194 分）。
两篇文章放在一起读，恰好构成了 2026 年 AI 编程最完整的一幅现实图景：模型能力已经跨过「可用」门槛，但生产力红利的上限不是模型智商，而是工程系统——代码组织、反馈回路、工具链——的匹配度。 本文梳理两篇的论点，并用 Thoughtworks 实验中的真实数据，量化「重构 = 投资」的 Token 经济学。
一、2x 假设：楼梯模型与自动化反馈回路
obryant 的核心假设非常简洁：
LLM 在 2026 年被大规模采用，主要原因是它们已经可靠到能跑在自动化反馈回路里。一旦跨过这个门槛，模型能力的进一步提升对生产力的影响会远小于从前。
他用了一个楼梯类比：爬楼梯的前提是「一步能跨上一级台阶」，但「一步能跨两级三级」带来的提升远没有那么大。翻译成工程语言：
- 阈值之前：模型能否完成任务，决定生死（0 → 1）。
- 阈值之后：模型能以多快的速度在「写代码 → 验证 → 修正」的回路里迭代，决定效率（1 → 2）。
他观察到 LLM 擅长的是「产出满足明确、可客观验证验收标准的代码」——比如「做一个按钮，点击后做 X，然后点击它确认确实做了 X」。这套闭环可靠之后，效率提升是实打实的（他称之为「了不起的 2x 改进」）。
但有一类问题，LLM 至今无法可靠回答：「这个代码有没有更可维护的写法？」「这份文档该包含什么、不该包含什么？」 这些问题的答案无法用测试断言来验证，也就不在自动化反馈回路的覆盖范围内。
二、「完成」的定义变了
最有冲击力的一句观察是：
以前，一个能跑的实现意味着任务完成了 80%；现在，它只意味着完成了 20%。
代码能跑 ≠ 代码能交。obryant 的策略是让 LLM 只产出粗糙草稿，然后自己重度迭代结构；他甚至给自己加了一条 prompt 指令：
Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.（永远不要写 README、文档字符串或注释，我之后自己写。是的，我真的是这个意思。）
这背后的工程直觉是：LLM 生成的结构性文档会引入虚假的确定性，让维护者（包括未来的模型）在错误的地图上找路。代码的「组织」——模块边界、命名、抽象——仍是人类工程师的核心产出。
三、重构的 Token 经济学：Thoughtworks 的对照实验
如果说 obryant 提供的是定性判断，Thoughtworks 的实验则给出了罕见的量化数据。
3.1 实验背景
Giles 用 Agent（主要是 Claude Code，少量 Cursor）写了一个约 15 万行的生产级应用（Rust 约 12 万行 + TypeScript + Terraform），且全程不 review 代码。结果数据访问层长成了一个 17,155 行的单文件：每个查询都在重复同样的 HTTP 请求构建、同样的 JSON 编解码。
于是他把这个文件当作实验对象：严格按 Fowler《重构》第二版的方法论逐步重构，每完成一步，就用同一个 prompt 让一个全新 sub-agent 执行同一个代表性改动（新增一个 Firestore trait），并记录 token 消耗。关键设计：agent 不会从上一轮学到任何东西，因此这是干净的可重复实验。
3.2 结果：输入 token 悬崖式下跌
| 阶段 | 数据层 LoC | 最大文件 LoC | 输入 tokens/次改动 |
|---|---|---|---|
| Baseline | 17,155 | 17,155 | 159,564 |
| Step 7（拆 queries.rs） | 16,474 | 15,670 | 151,850 |
| Step 12（拆 store/） | 16,550 | 9,269 | 104,080 |
| 最终（19 个 Rust 文件） | 16,608 | 3,695 | 27,360 |
同一任务的输入 token 消耗从 159,564 降至 27,360，节省 83%（132,204 tokens）。按文章当时的 Sonnet 5 定价（$3/MTok）计算，每次改动省 39.7 美分——而且这是每次改动都会重复省下的钱。
两个反直觉的洞察：
- 省的是「读」不是「写」。输出 token 几乎没变（写同样的代码），省下的全是输入 token——因为 agent 需要读的代码变少了。而数据层总 LoC 其实基本没变（16,608 vs 17,155），关键在于 agent 能否识别出「最小必要读取子集」。
- 随机切文件没用。如果只是把大文件随机切成小块，agent 反而要在更多文件里翻找。真正起作用的，是先抽取重复逻辑、暴露内在结构，再沿结构边界拆分——这也解释了为什么最有价值的步骤（拆 store/ 子目录）在最后。
3.3 重构本身的开销
- 实验耗时约 8 小时，大部分无人值守；
- 重构全程的 token 消耗上限约 500 万（含制定计划、设计实验）；
- Claude 不擅长重构：无论是发现该做哪些重构，还是机械执行（作者用 grep/sed 脚本做机械重构，还经常被缩进搞乱）；
- 结论是必须由人类主导重构计划，agent 只做执行。
四、工程启示：把 Token 当成显式成本
把两篇文章合起来，对做 Agent 化研发的团队有三条可执行建议：
- 代码组织是经济决策，不是品味问题。在 agent 化开发中，模块边界直接决定每次改动的输入 token 消耗。值得为「agent 可读性」重构：内聚的模块、清晰的接口、克制的抽象层级。Thoughtworks 的数据表明，这种重构的 ROI 是可量化的——83% 的 token 节省。
- 为 agent 设计反馈回路，而不是追求更强的模型。obryant 的楼梯模型暗示：与其等「会游泳的模型」，不如把测试、lint、沙箱验证做扎实，让「能爬楼梯的模型」在回路里跑得更快。他本人从「LLM 当搜索引擎」演进到「写声明式规格 + 沙箱环境」，就是工具链先行。
- 把「tokens per change」纳入度量。当 agent 成为写代码的主力，单次改动的 token 消耗就是新的「代码复杂度」指标。它比 LoC 更接近真实成本——因为模型按 token 计费，而人按阅读量计费，两者高度相关。
结论
「2x 还是 10x」之争，本质是问：AI 编程的生产力瓶颈在模型还是系统？2026 年 7 月的这两篇文章给出了高度一致的答案：模型已经足够好，瓶颈在工程系统。 自动化反馈回路、代码组织、token 成本意识——这些 2025 年还被视为「软技能」的东西，正在成为硬核的经济学。下一个 10x，大概率不是来自下一代模型，而是来自围绕现有能力重造的开发工作流。
参考来源：
- 2x, not 10x: coding with LLMs in 2026（obryant.dev，2026-07-25）
- The Economic Benefit of Refactoring（Martin Fowler 博客，2026-07-30）
- HN 讨论帖 1 / HN 讨论帖 2
相关阅读：