引子：我们不是被 AI 打败，而是被“失控的速度”打败

You realize you can no longer trust the codebase. Worse, you realize that the gazillions of unit, snapshot, and e2e tests you had your clankers write are equally untrustworthy. The only thing that’s still a reliable measure of “does this work” is manually testing the product. Congrats, you fucked yourself (and your company).

过去两年，AI 工具像走马灯：大模型迭代、Agent 平台爆发、开源项目一波接一波（无论是 OpenClaw、OpenFang，还是其他新框架，名字会变，趋势不会）。
企业高层焦虑“会不会错过时代红利”，一线开发和测试焦虑“会不会被替代”。

真正的问题常常不是“AI 会不会替代你”，而是：

• 你是否还掌控系统的正确性？
• 你是否还知道每次发布的风险在哪里？
• 你是否有能力把 AI 产能转化为可持续交付，而不是技术债滚雪球？

那句粗粝但扎心的话正是在提醒我们：
如果代码和测试都不可信，团队就会退化为手工验证工厂。

---

一、先统一一个认知：AI 不是“更快的程序员”，而是“概率型协作者”

传统软件工程默认“确定性工具链”：
编译器、静态检查、测试框架，输入固定，输出可复现。

而大模型/Agent 的核心特性是“概率生成 + 上下文驱动”：

• 同样的需求，可能给出不同实现；
• 可以高效补齐样板代码，也可能引入隐蔽缺陷；
• 能加速局部最优，却不天然理解系统级约束。

工程含义：
你不能只升级“写代码速度”，必须同步升级“验证、治理、追责”体系。

图1：信任崩塌链路

---

二、人和 AI 的关系：从“替代叙事”转向“责任分层”

1）谁负责产出，谁负责正确性？

可以让 AI 写代码，但不能让 AI 独自定义“正确”。
组织里必须明确：

• AI 负责：生成候选方案、重复劳动、跨语言迁移、测试样例草稿。
• 人负责：需求边界、架构权衡、安全合规、最终验收与上线签字。

2）“人机协作”最怕的不是能力差，而是责任悬空

常见失败模式：

• 需求模糊 -> AI 生成“看起来对”的代码；
• 评审者只看风格不看语义；
• 测试数量暴涨，但断言质量下降；
• 最后只能靠人工回归兜底。

这不是 AI 的错，是责任链断了。

图2：责任分层矩阵

---

三、编程范式正在变：从“手写实现”到“约束驱动开发”

AI 时代，代码价值重心在变化：

• 过去：写出代码本身。
• 现在：写出约束、上下文、验收标准，并驱动 AI 产出实现。

可以把新范式理解为四层：

1. Intent（意图）：业务目标和不变量（不能破坏什么）。
2. Constraints（约束）：性能、安全、成本、兼容性。
3. Generation（生成）：AI 产出可选实现。
4. Verification（验证）：自动化 + 人工关键路径验收。

如果只做第 3 层，不做 1/2/4，灾难几乎是必然的。

图3：约束驱动开发四层范式

---

四、交付模式在变：从“代码交付”到“证据交付”

过去上线看“功能完成了没”。
现在更应看“证据是否完整”：

• 需求证据：为何这样做，边界是什么；
• 实现证据：关键设计决策和替代方案；
• 质量证据：测试覆盖的是哪些风险，而不是跑了多少条；
• 运行证据：灰度指标、回滚路径、异常预案。

一句话：AI 提速后，交付物不再只有代码，必须包含“可审计的正确性证据”。

---

五、三个真实场景：AI 用得越猛，越要重视“可信工程”

场景 1：测试数暴涨，但线上故障更频繁

团队让 AI 一周生成了几千条单测/快照测试，覆盖率好看。
上线后支付流程仍频繁出错。

根因：

• 测试在验证“当前实现细节”，不是验证“业务不变量”；
• 快照测试大量固化了错误行为；
• 缺少端到端关键路径和异常路径验证。

改法：

• 把“金额不可为负、库存不可超卖、幂等键不可重复消费”写成高优先级性质测试；
• 减少脆弱快照，增加业务语义断言；
• 关键交易路径保留人工探索式测试。

---

场景 2：AI Agent 自动改代码，PR 通过快但回滚也快

Agent 自动修复告警，提交 PR，评审 5 分钟合并。
两天后出现性能雪崩，只能紧急回滚。

根因：

• 改动跨越模块边界，但缺少架构守卫；
• 评审关注“能跑”，没评估“系统级副作用”；
• 没有分层灰度和指标门禁。

改法：

• 设“高风险目录白名单”：核心链路禁止全自动合并；
• 引入发布门禁：P95 时延、错误率、资源成本必须达标；
• Agent 产出必须附带“变更影响说明 + 回滚脚本”。

---

场景 3：管理层要求“全员 AI 化”，一线效率反而下降

每人都被要求上 AI 工具，但没有统一规范。
结果：提示词各写各的，代码风格和架构分裂，返工增多。

根因：

• 缺少组织级 Prompt/Skill/代码规范资产；
• 缺少 AI 产出验收标准；
• 把“会用工具”误当成“建立能力”。

改法：

• 统一可复用资产：项目技能库、模板、守则；
• 设最小验收标准：可读性、可观测性、可回滚、可测试；
• 训练的重点从“怎么问 AI”转为“怎么定义问题与约束”。

图4：三场景对比

---

六、给企业和团队的可执行建议（不喊口号版）

• 先立规矩，再上规模：先选 1~2 条业务线试点，沉淀 SOP，再推广。
• 用 AI 拉高下限，不要赌上限：先用于脚手架、文档、测试草稿、重构建议。
• 建立“可信度预算”：自动生成比例越高，验证强度必须同步提高。
• 关键系统坚持“双轨验证”：自动化测试 + 关键路径人工验收。
• 把“不会被替代”的能力制度化：领域建模、系统设计、风险判断、跨团队协同。

---

七、给开发与测试个人的建议：避免两种极端

两种极端都危险：

• 极端 1：盲目崇拜 AI，认为“能生成就等于能交付”；
• 极端 2：像当年惧怕蒸汽机一样惧怕 AI，拒绝学习。

更稳的路径是：

1. 把自己从“代码生产者”升级为“系统正确性负责人”；
2. 学会写高质量约束与验收标准（这比写语法更值钱）；
3. 把 AI 当副驾驶，不当自动驾驶；
4. 对每次 AI 产出都问一句：“证据在哪里？”

图5：个人升级路径

---

结语：变化快不是问题，失去判断力才是问题

“不是我不明白，是世界变化太快。”
这句话放在今天特别真实。

但工程世界从来不是比谁更快写出代码，而是比谁更稳定地交付价值。
AI 会持续重塑工具、岗位和流程，但不会改变一个底层事实：

真正稀缺的，不是写代码的手速，而是定义问题、约束系统、证明正确性的能力。

当你把这三件事抓在手里，AI 不是威胁，而是杠杆。