过去几周，Hacker News 上关于 AI 编程的讨论出现了一个有趣转向。话题不再只是“哪个模型写代码更强”，而是“为什么最会用 AI 的往往是本来就强的工程师”。Simon Willison 在关于 agentic engineering 的文章里反复强调，人不应该成为模型的“肉体代理”，也就是只负责把模型指令复制到终端。Lilian Weng 近期关于上下文工程的讨论也指向同一件事：AI 系统的效果越来越取决于外层工程，而不是单次 prompt 魔法。
这和很多人的直觉相反。早期叙事是“AI 会让不会写代码的人也能写软件”。这句话在原型阶段成立：一个非工程师确实可以用自然语言搭出网页、脚本或内部小工具。但当软件进入生产，问题就变了。模型能快速生成实现，却不能替你承担验证责任。它能降低代码生产成本，却常常提高审查、测试和架构判断的密度。
所以，AI 编程真正奖励的不是 prompt 技巧，而是验证能力。
代码生成变便宜之后，什么变贵了
传统开发里，写代码本身占据大量时间。开发者需要查 API、组织控制流、处理类型、补齐样板。AI 工具把这部分成本压低了：补全、重构、生成测试、写脚本都明显更快。
但软件交付的总成本不只来自写代码。至少还有这些部分：
| 环节 | AI 之前 | AI 之后 |
|---|---|---|
| 需求澄清 | 人主导 | 仍然人主导 |
| 架构边界 | 人主导 | 更需要人主导 |
| 代码生成 | 中高成本 | 低成本 |
| 测试设计 | 人主导 | 可辅助但需审查 |
| 质量判断 | 人主导 | 更需要人主导 |
| 生产责任 | 人承担 | 仍然人承担 |
当代码生成变便宜，团队会自然生成更多候选改动。每个候选改动都需要验证，于是瓶颈从“写不出来”转向“判断哪个能进主线”。这就是为什么专家收益更高：专家不是因为打字更快，而是因为他们更快知道哪些输出不该信。
一个高级工程师看到 AI 生成的数据库迁移，会立刻问：是否可回滚，是否锁表，是否影响旧版本服务，是否需要后台补数据，是否有灰度策略。一个新手可能只看到“代码能跑”。模型让两个人都能得到一段迁移脚本，但只有前者能判断它是否应该上线。
Agentic engineering 的核心不是自动化，而是闭环
“Agentic engineering”容易被误解成让 AI 自己跑更多步骤。实际上，步骤更多不等于系统更可靠。真正关键的是闭环：计划、执行、观察、修正、验证、提交，每一步都有工具结果和质量门槛。
一个可靠的代码 agent 工作流通常长这样：
1. 读取需求和仓库规范
2. 搜索相关文件和既有模式
3. 形成最小修改计划
4. 修改代码
5. 运行针对性测试
6. 根据失败结果修复
7. 运行全量检查
8. 生成可审查的变更说明这里最重要的不是第 4 步，而是第 2、5、6、7 步。没有仓库上下文，模型会发明风格；没有测试，模型会产生自信的错误；没有失败反馈，模型不会知道哪里偏了；没有全量检查，局部成功可能破坏整体。
这也是上下文工程和 agentic engineering 交汇的地方。上下文不是越多越好，而是要把正确的约束放在正确的位置。README、类型定义、错误日志、测试输出、代码规范、线上指标，这些都比一句“请写出高质量代码”更有价值。
“不会写代码也能做软件”的边界
这句话最大的问题是混淆了 prototype 和 product。
原型的目标是证明想法，允许大量隐藏债务。一个 landing page、一次性爬虫、内部数据清洗脚本，AI 的确可以让非专业人员快速完成。只要失败成本低，速度优先是合理选择。
产品的目标是长期运行。它需要权限、数据一致性、性能边界、可维护性、可观测性、部署回滚和安全响应。AI 可以帮助实现这些能力，但不会自动补齐它们。越是面向真实用户和生产数据，越不能把“能跑”当作“完成”。
因此，初级开发者使用 AI 的正确姿势不是“让它替我完成任务”，而是“让它把任务拆成我能验证的步骤”。例如：
请先不要写代码。
请阅读相关文件后列出这个修改会影响的模块、可能失败的边界条件、需要新增或更新的测试。
等我确认后，再做最小范围实现。这个 prompt 的重点不是措辞，而是工作流。它迫使模型先暴露假设，再进入实现。对新手来说，这比直接生成代码更有学习价值，也更容易避免大面积错误。
团队验证流程要升级
AI 编程普及后，团队最容易出现一种坏习惯：PR 数量变多，但验证深度没有增加。代码审查者面对大段生成代码，很容易疲劳；作者又可能默认“模型已经检查过”。结果是更多低质量改动进入主线。
解决方式不是禁止 AI，而是把验证要求制度化。
| 风险 | 建议门槛 |
|---|---|
| 大段新增代码 | 必须有测试和设计说明 |
| 数据迁移 | 必须有回滚策略和数据校验 |
| 权限逻辑 | 必须有负向测试 |
| 依赖升级 | 必须说明安全和兼容影响 |
| Agent 自动修改 | 必须保留工具 trace 和测试输出 |
代码审查也要换问题。以前常问“这段代码为什么这样写”，现在还要问：
- 这个实现是否符合仓库已有模式？
- 哪些边界条件是模型没有覆盖的？
- 测试是否验证行为，而不是只验证 happy path？
- 有没有引入新依赖、新权限或新状态？
- 如果线上出问题，能否定位和回滚？
这些问题不会因为代码由 AI 生成而改变。相反，AI 让改动速度更快，更需要这些问题挡住错误。
个人工作流：把 AI 当成候选生成器
我建议开发者把 AI 编程分成三种模式：
| 模式 | 适用任务 | 人的职责 |
|---|---|---|
| pair | 小改动、解释、补测试 | 实时判断 |
| agent | 多文件任务、迁移、脚手架 | 设定目标和验收 |
| reviewer | 审查、找 bug、列风险 | 决定取舍 |
不要让一个 agent 同时做所有角色。让生成者写代码，让 reviewer 找问题，让人类负责最终合并，这是当前更稳的分工。尤其在复杂任务里，可以故意让第二个模型审查第一个模型的输出，但最终仍要以测试、类型系统和人工判断收口。
一个实用习惯是要求 AI 每次改完都回答三个问题：
1. 你改了哪些行为？
2. 你运行了哪些验证？
3. 还有哪些没有被验证的风险？这三个问题能显著减少“看起来完成”的假象。模型可能仍然遗漏，但它至少会把工作从纯生成拉回交付语境。
对组织的长期影响
AI 编程会重塑工程组织，但不是简单替代 junior 或放大 senior。更准确地说，它会把团队能力往两端拉开：有验证文化的团队会变快，没有验证文化的团队会更快制造债务。
未来的优秀工程师会更像系统设计者、测试设计者和审查者。他们仍然写代码，但不再把写代码当作主要价值证明。他们的价值在于把模糊目标变成可执行计划，把模型输出变成可验证改动，把局部实现放进长期架构。
这也意味着工程教育要调整。学习者不能只学“如何让 AI 写出功能”，还要学：
- 如何读懂生成代码。
- 如何设计最小可验证测试。
- 如何识别安全和数据边界。
- 如何根据错误日志定位根因。
- 如何把一次修复沉淀成项目规则。
这些能力过去就重要，AI 时代更重要。
小结
AI 编程真正改变的是成本结构。写代码变便宜，验证变成中心。谁能更好地提出约束、拆解目标、设计测试、判断边界，谁就能从模型中获得更大收益。
所以，不要把 agentic engineering 理解成“让 AI 多做几步”。它是围绕 AI 生成能力重建软件交付闭环：上下文要准确，工具要可观测，测试要前置，权限要收紧，提交要可审查。模型可以是强大的执行者，但工程质量仍然来自清楚的目标和严格的验证。