2 篇博文 含有标签「engineering-process」

大多数工程团队对待伦理问题，就像他们过去对待安全问题一样：在功能发布之后、有人投诉之时才去处理。这种类比令人不安。2004年，SQL注入还是个"以后再修"的问题。如今，每个正规团队的CI中都有自动注入检测。AI伦理审查正处于同样的拐点——不提前建立门控机制的团队，终将以惨痛教训明白它存在的意义。

问题不在于初衷，而在于结构。安全审查有20年的标准化先发优势：OWASP清单、CVE评分、渗透测试、上线前的强制审批。伦理审查则没有这些规范。大多数团队既没有定义明确的触发条件，也没有清单、退出标准，更没有指定的责任人。结果是：一个医疗算法将黑人患者被识别为需要护理的比例降低了超过50%——不是因为工程师心怀恶意，而是因为没有人在上线前运行分组准确率分析。一个招聘模型系统性地降低了含有"女性"一词的简历排名——用历史数据训练，未经公平性审查就发布，几个月后才在生产中被发现。这些不是边缘案例，而是在伦理作为上线后没有牙齿的复选框时必然发生的结果。

一位资深工程师打开了一个由 Agent 编写的 PR。Diff 非常整洁。测试通过了。命名规范一致。他们大致扫了一眼，点了个赞，然后合并。两个月后，另一位资深工程师正在重写那个模块，因为该模块引入的抽象在三个调用点悄悄泄露了状态，而测试套件从未发现这一点，因为它只断言了代码在做什么，而不是规范（Spec）的要求。

这种模式是 2026 年代码审查（Code Review）中占主导地位的失败模式。那些适用于人类编写 PR 的审查直觉——探究作者的意图、寻找他们没想到的 Bug、检查测试是否反映了设计——在 Agent PR 上失效了，因为 Bug 聚集在不同的地方，且审查者看到的产物不再是真正重要的产物。

数据支持这一直觉。CodeRabbit 在 2025 年 12 月对 470 个 GitHub PR 的分析发现，AI 协作编写的代码产生的问题大约是人类编写代码的 1.7 倍，其中逻辑和正确性错误是 1.75 倍，安全发现是 1.57 倍，算法和业务逻辑错误是人类的 2.25 倍。严重问题增加了 1.4 倍，重大问题增加了 1.7 倍。Diff 读起来很流畅，而这种流畅性恰恰就是问题所在。