快速交付，失去客户：为何 AI 加速的脆弱性并非工程

Source: Dev.to

两个叙事

在过去的一年里，软件界被划分为两种不兼容的叙事。

• 速度优先叙事 – AI 工具以机器速度生成代码，开发者凭“氛围感”快速推进功能，快速交付被视为新的相关性货币。招聘者奖励速度，社交媒体奖励速度。即使是被就业市场压得喘不过气的初级开发者，也紧抓速度作为唯一可控的可见信号。
• 客户优先叙事 – 如果架构不安全，速度毫无意义。一次泄露、一次曝光或一次疏忽就能抹去多年的好感。客户关心的是保护他们的业务、数据和客户，而不是某件事构建得有多快。

这两个世界现在正相撞，只有一个能在现实中存活。

扭曲的激励结构

当前的就业市场恐慌导致了扭曲的激励结构：

• “你交付的数量”被视为能力的代理指标。
• AI 生成的 PR 被赞誉，却没有人真正理解。
• 只要看起来惊艳，脆弱的代码库就被视为正常。
• 招聘者奖励产出量，而非架构。
• 开发者害怕被取代，于是优化可见度。

这不是工程学，而是生存戏码。

客户期望

• 客户会原谅进度慢，但不会原谅一次泄露。
• 客户可以容忍功能缺失，但不能容忍数据受损。
• 客户可以接受迭代开发，但不能接受架构疏忽。

“快速交付”文化在最简单的事实面前崩塌：如果供应商一次性失信客户，供应商将永远失去该客户。再快的交付也无法重建因疏忽而失去的信任。

AI 加速的工程 vs. 脆弱性

AI 让生成编排层、API 包装、数据管道、微服务、集成以及 UI 脚手架变得容易。然而，AI 并未让以下工作变得容易：

• 对架构进行推理
• 强制不变式
• 维护血统
• 防止漂移
• 保障数据流安全
• 设计可逆性
• 确保隐私
• 保证连续性

两种工程文化正在出现：

AI 加速的工程（可持续的）

• 负责任地扩展
• 优先进行架构审查、可审计性和隐私保障

AI 加速的脆弱性（不可持续的）

• 失信客户
• 缺乏治理和架构防护

这两种文化中只有一种能在下一轮监管周期中存活。

治理作为基底

AI 辅助开发本身并不危险；危险在于缺乏以下方面：

• 架构审查
• 漂移边界
• 可审计性
• 可逆性
• 隐私保障

治理是定义代理是什么、如何演化、如何漂移、如何被解释、逆转、审计和信任的基底。没有这层基底，“快速交付”就会变成“脆弱交付”。

正确的模型

市场总会向可靠性、连续性、安全性、信任、治理和架构方向修正。修正不会温和。快速交付却脆弱的供应商会失去客户。依赖氛围感而非理解的开发者会被淘汰。缺乏治理的组织将面临监管后果。

AI 加速了一切——包括错误决策的后果。

适当的做法是：

• 在边缘快速交付
• 在核心慢速交付
• 治理基底
• 保护客户
• 锚定架构
• 审查重要内容
• 自动化非关键部分

速度是一种工具。治理是基础。信任是产出。而信任无法通过氛围感来编码。