AI 正在快速降低代码生成的成本，但软件工程并没有因此变成“描述需求，然后等待答案”。真正困难的部分仍然存在：判断应该解决什么、识别系统中的关键风险、理解生成代码的行为，以及确认最终结果是否改善了客户体验。
Ben Greene 结合创业经历提出了一组适应这种变化的工程思维：从简单方案开始、保持对代码的理解、优先攻击困难问题，并用客户影响衡量工作。在代码越来越容易获得的环境里，这些能力反而更有区分度。
代码产量不再是核心指标
过去，工程师经常把“完成了多少功能”当作进度。AI 编码工具进一步放大了这种倾向：几分钟内生成接口、测试和数据模型，很容易制造一种项目正在高速推进的感觉。
但生成速度无法回答几个关键问题：
- 这个功能解决的是客户的真实阻塞，还是团队内部的想象？
- 代码失败时，团队是否理解它的状态变化和数据边界？
- 当前设计是否把一个简单问题包装成了复杂平台？
- 最难、最不确定的部分是否被推迟到了项目末尾？
因此，AI 时代更值得追踪的不是提交数量，而是被消除的不确定性。例如，一次小型实验确认第三方接口无法满足延迟要求，可能比生成十个业务模块更有价值。
从简单方案开始，但不要停止理解
“从简单开始”不是忽略质量，而是用最小成本验证最重要的假设。面对新需求，可以先实现一条完整但狭窄的业务路径：一个输入、一个核心决策、一个可观察的结果。只有当真实流量或业务规则证明有必要时，再引入队列、缓存、插件系统或复杂抽象。
AI 可以帮助快速搭建这条路径，但工程师仍应能够解释：
- 输入如何被验证；
- 数据在哪些位置发生变化；
- 失败如何暴露和恢复；
- 哪些假设没有被测试；
- 删除某个模块会产生什么影响。
一个实用做法是把“能够生成代码”与“能够接管代码”分开。合并 AI 生成的改动前，请提交者用自己的语言说明控制流、失败模式和回滚办法。如果这三件事说不清楚，代码就还没有真正成为团队可以维护的资产。
先攻击最困难、最不确定的问题
项目最危险的部分通常不是页面布局或常规 CRUD，而是团队最不愿意触碰的假设：模型准确率是否足够、外部服务能否承受峰值、迁移能否保持数据一致，或者客户是否愿意改变现有工作流。
可以把待办事项按“客户影响”和“不确定性”排序，而不是只按实现成本排序。下面是一个可直接运行的简化工具。它不是演讲中提供的 API，而是一种可以这样实践的任务筛选方法。
将以下内容保存为 prioritize.py，然后运行 python prioritize.py：
from dataclasses import dataclass
@dataclass
class Task:
name: str
customer_impact: int # 1-5，越高越影响客户结果
uncertainty: int # 1-5，越高越需要尽早验证
effort: int # 1-5，越高越昂贵
@property
def learning_priority(self) -> float:
# 奖励客户影响和风险消除；成本只作为温和的约束。
return (2 * self.customer_impact + 2 * self.uncertainty) / self.effort
tasks = [
Task('验证支付服务的峰值延迟', 5, 5, 2),
Task('重构后台筛选组件', 2, 2, 3),
Task('访谈流失客户并验证工作流', 5, 4, 1),
Task('生成完整插件框架', 2, 4, 5),
]
for task in sorted(tasks, key=lambda item: item.learning_priority, reverse=True):
print(f'{task.learning_priority:4.1f} {task.name}')
这里的公式不是通用标准。团队应根据业务调整权重，例如把合规风险、收入影响或恢复难度纳入评分。它的价值在于迫使团队公开讨论：“我们现在是在减少关键风险，还是只是在完成容易展示的工作？”
对排名靠前且不确定性高的任务，可以设计一个时间受限的探针：
mkdir -p experiments/payment-latency
printf '%s\n' '# Payment latency spike' '' '- Timebox: 4 hours' '- Success: p95 < 300 ms at expected peak load' '- Stop: archive results; do not turn the spike into production code' > experiments/payment-latency/README.md
探针的目标是获取证据，不是偷偷建立第二套生产系统。实验结束后，应记录结果、决策和仍未解决的问题，再决定扩展、替换还是停止。
同理心、主动性和实际问题解决仍不可替代
客户通常不会用完整的技术规格描述问题。他们可能说“系统很慢”，实际原因却是状态反馈不清晰；他们可能要求导出按钮，真正需要的是在审计前证明数据完整。识别这种差异需要观察工作流程、追问约束，并理解错误对人的实际影响。
这也是人的同理心仍然重要的原因。AI 可以提出实现选项，却不能代替团队承担产品判断。工程师需要主动走出任务描述：查看支持记录、复现客户路径、测量生产行为，并在发现目标错误时提出异议。
可以在每个重要改动的评审说明中加入四个问题：
- 哪类客户行为触发了这项工作？
- 最困难的假设是什么，我们如何验证它？
- 如果 AI 生成的实现出错，团队能否定位并回滚？
- 上线后用什么信号判断客户结果得到改善？
这些问题把代码评审从语法和风格检查，提升为对系统行为与产品结果的共同审查。
采用时的工程清单
AI 编码工具适合生成样板代码、探索备选实现、补充测试和缩短反馈周期，但不应成为跳过理解的理由。团队可以从以下约束开始：
- 先定义客户结果，再生成实现。
- 先验证高影响、高不确定性的假设。
- 保持首个方案足够小，避免过早的平台化设计。
- 要求代码所有者解释控制流、数据边界和失败模式。
- 用生产信号和客户行为验证结果，而不是用提交量证明进度。
- 对不可逆、涉及安全或高成本的决策保留人工审批。
当代码本身越来越便宜，工程价值会更多地来自选择、理解和负责。能把模糊问题变成可验证假设，再把证据转化为客户结果的工程师，不会因为自动化而失去作用；他们会成为决定自动化是否真正有用的人。