当代码变成“概率”:AI 时代的软件工程危机

在一个月黑风高的晚上，一个熟悉的技术群聊里，某大厂 Manager 发了一张截图。

屏幕上显示着两条曲线：

• • 绿色：是开发效率
• • 红色：是线上故障数

随着 AI 编程工具的全面普及，绿色曲线飙升了 300%，而红色曲线也跟着翻倍了。

他在群里问了一句：“效率是上去了，但半夜告警的短信也多了，这账怎么算？”

群里沉默了很久。最后有人回了一句大实话：“问题不是代码写错了，而是没人知道哪一段代码是‘可靠的’，哪一段是‘赌运气’的。”

这句话，戳中了所有技术决策者的痛点。

过去十年，我们习惯了软件工程是“确定性”的：输入 A，逻辑 B，必然输出 C。但现在，当大模型介入编码，代码变成了一种“概率性生成物”。软件工程的基本假设，被打破了。

今天，我想抛开那些”AI 是否会取代程序员”的宏大叙事，从十年架构和 DevOps 的经验出发，聊聊当代码变成“概率”，我们该如何给工程加一道“保险丝”。

一、什么叫“代码变成概率”？

对于普通读者，这可能有点抽象。我们换个说法。

以前的代码，是“公式”。你写 1+1，计算机永远等于 2。编译器是确定的，逻辑是透明的，只要测试覆盖到位，上线就是稳的。

现在的 AI 代码，是“答案建议”。你让 AI 写一个“用户登录函数”，它给你生成了一段看似完美的代码。但它不是通过逻辑推导出来的，而是基于海量数据“猜”出来的。

从技术本质上讲，大模型做的是：基于概率分布预测下一个 token，而不是进行确定性的逻辑推导。这意味着：同一个需求，可能对应多种实现路径，每一次生成，都存在偏差，正确性不再是绝对，而是一个分布区间。

它猜对了，是惊喜；猜错了，是惊吓。

在工程视角下，这意味着 “技术债务”的积累速度变了。以前代码是资产，写一行积累一行；现在代码可能是负债，AI 生成越快，如果你没有能力识别其中的“概率错误”，系统崩溃的风险就积累得越快。

二、工程世界的三个核心变化

这种“概率性”，正在重塑软件工程的三个基石。这不是“写代码变快”这么简单，而是工程体系在变。

1. 测试范式的崩塌

以前，我们迷信“测试覆盖率”。只要单元测试覆盖到 90%，我们就敢上线。

但现在，覆盖率失效了。 AI 可以生成：

• • 能通过所有测试的错误代码
• • 在 Mock 环境正常、真实环境失败的逻辑

测试从验证“逻辑是否正确”，变成了验证“概率是否可接受”。

边界 Case 呈指数级爆炸，你无法穷举所有可能的“幻觉”。测试成本没有因为 AI 降低，反而因为需要验证“AI 有没有瞎写”而上升了。

2. Code Review 的失效

以前，Code Review（代码审查）是看“有没有 Bug”。资深工程师很容易发现代码中的问题点。

现在，Review 变成了：“这段代码我信不信？”

AI 生成的代码，风格统一、注释清晰、变量命名规范，看起来比人写的还漂亮。但 “可解释性”变差了。你很难判断这段逻辑是 AI 真的理解了业务，还是它“模仿”了某个开源项目的写法。审查者需要从“找错”变成“猜意图”，这比写代码还累。

很多团队反馈：“审查 AI 代码的时间，比自己写代码还长。”

3. 责任归属的模糊

这是一个非常现实的组织问题。

以前出了 Bug，找代码作者，责权清晰。现在出了 Bug：

• • 写 Prompt 的人说：“是模型生成的。”
• • 调模型的人说：“是提示词写得不够清楚。”
• • 审核的人说：“代码看起来没问题，是边界场景没覆盖。”

责任开始在流程中被“稀释”。

三、DevOps 的工程化应对：三道防线

既然“概率”无法消除，工程的目标就是 “控制风险”。具体做法如下：

1. 流水线升级：引入“概率过滤”网关

传统的 CI/CD 流水线只检查语法和单元测试。现在，我们在代码合并前，加了一道 “AI 代码网关”。

• • 静态分析增强（SAST）
• • 检查常见 AI 错误模式
• • 禁止硬编码密钥、敏感信息
• • 语义一致性校验
• • 对比需求文档与代码行为
• • 识别同步/异步、权限等偏差

工程代价： 构建时间增加了 5-10 分钟。工程收益： 拦截了 60% 的低级幻觉错误。

2. 代码分级：建立“可信度机制”

不要对所有代码一视同仁。我们将代码库分为 “核心区” 和 “非核心区”。

• • 核心区（支付、库存、权限）：禁止 AI 直接提交。 AI 只能生成单元测试或文档，核心逻辑必须由人手写，或经双人复核。
• • 非核心区（UI 样式、脚本、样板代码）： 允许 AI 生成，但必须通过自动化沙箱测试。

这就像机场安检：普通乘客快速通过，重点人物严格检查。 通过分级，我们在效率和安全之间找到了平衡点。

3. 全链路血缘追踪：让 AI 代码“可追溯”

这是最关键的一步。每一行 AI 生成的代码，必须带上“身份证”。 我们在提交规范中强制要求：

• • Model ID： 记录是用哪个模型生成的（如 GPT-5.3-Codex）。
• • Prompt Hash： 记录生成这段代码的提示词哈希值。
• • 版本号： 记录模型版本。

一旦线上出现故障，我们可以立刻反查：是哪次生成导致的？是哪个模型的版本问题？是不是 Prompt 有歧义？没有追溯，就没有改进。 只有知道错误从哪来，才能优化流程。

四、给读者的行动清单

写到这里，可能有人会觉得：“太复杂了，我只是想用 AI 提效。”

工程没有银弹，只有权衡。但无论你是谁，以下建议都值得参考。

给管理者：

1. 1. 别只问“能不能用 AI”，要问“有没有审计日志”。 没有日志的 AI 编程，就是裸奔。
2. 2. 重新定义“完成”。 代码生成不等于完成，通过安全审查和压力测试才算完成。

给开发者：

1. 1. 别直接 Copy 代码。 至少要读懂每一行，尤其是异常处理逻辑。
2. 2. 保留“手写能力”。 当你无法判断 AI 代码对错时，你的手写能力是最后的底线。

给架构师：

1. 1. 设计“熔断机制”。 当 AI 生成代码的错误率超过阈值，自动暂停 AI 权限，转入人工模式。
2. 2. 拥抱“混合模式”。 未来不是 AI 替代人，而是“人 +AI”替代“纯人”。架构师的核心能力，将从“写代码”转向“设计让 AI 安全写代码的系统”。

AI 不会淘汰任何人，但会用 AI 的工程师会淘汰不会用的（还在用古法编程的人）。

但请记住：技术可以是概率的，但工程必须是确定的。

企业引入 AI，是为了让它成为手中的利器，而不是让它成为系统的黑箱。当代码变成“概率”，技术人的价值，就在于给这道概率加上确定的“保险丝”。

这很难，但这正是工程的意义。