第一章：写代码变便宜了，但交付好代码依然昂贵
核心论点很直接：AI Agent 让「写出能跑的代码」这件事成本趋近于零，而我们过去几十年积累的所有关于时间和成本的直觉，正在集体失效。
过去做项目规划、功能评估、排期估时，底层假设都是「写几百行干净代码要花一整天」。具体到日常决策——要不要重构这段逻辑、要不要补一组边缘测试、要不要给调试流程建个可视化界面——每一个选择背后都在权衡「值不值那几个小时」。
现在这个权衡模型崩了。一个工程师可以同时让多个 Agent 并行跑：一个实现功能，一个重构，一个写测试，一个生成文档。成本从「人天」变成了「几分钟 + 几个 token」。
但这里有一个关键转折：写代码便宜了，交付「好代码」仍然昂贵。所谓好代码，意味着无 bug、可验证、解决的是正确的问题、优雅处理错误、简洁可读、测试覆盖完整、文档与代码同步、符合 YAGNI 原则且便于未来扩展，还要满足各种「-ility」——可测试性、可观测性、安全性等等。这些品质不会因为 Agent 能写代码就自动到位。
实践建议：当你的直觉说「这个不值得花时间做」的时候，直接丢给异步 Agent 去跑。最坏的情况不过是浪费几个 token，几分钟后检查一下结果就行。养成这个新习惯，是适应 Agentic Engineering 范式的第一步。
第二章：用红绿 TDD 锚定 Agent 行为
第二个模式非常具体且实用：给 Agent 一句简洁指令——「Use red/green TDD」，就能显著提升输出质量。
红绿 TDD 的完整含义是：
- 红阶段：先写自动化测试，运行确认测试失败（证明测试本身不是 trivially 通过的）
- 绿阶段：再实现功能代码，使测试通过
这个模式对 AI Agent 特别有效，原因在于 Agent 极其擅长写出「看起来能跑但实际不可靠」的代码，或者制造多余的抽象层来「满足」测试。强制先红后绿，能有效锚定 Agent 的行为——避免幻觉代码、确保测试真正覆盖了新功能、防止对已有功能的回归。长期积累下来，你会拥有一套完整的测试套件，成为项目的安全网。
给 Agent 的示例提示：
Build a Python function to extract headers from a markdown string. Use red/green TDD.
就这么一句话，Agent 会自动走完「先写测试 → 确认失败 → 实现功能 → 确认通过」的完整流程。
这两章的核心其实指向同一件事：AI Agent 把执行成本打下来了，但工程判断力反而变得更重要。过去你需要亲手写代码来验证想法，现在你需要学会定义「什么才算好」，然后让 Agent 在这个标准下去执行。对于独立开发者来说，这意味着一个人就能维持过去小团队的产出节奏——前提是你掌握了正确的协作模式。