04 · 风险与边界

AI Coding 的风险很少是「模型突然变坏」，更多是 流畅感掩盖了错误。

1. 幻觉：最常见也最阴险

典型形态：

编造不存在的 API / 配置项 / 旗标
引用「常见最佳实践」却不适配你的版本
测试 greened 但断言在测错东西
注释与实现不一致，且注释更有说服力
安全地「修复」了表面问题，根因仍在

危险之处：

错误代码如果丑陋，人会警惕；错误代码如果优雅，人会合并。

缓解：

要求引用具体文件与符号，而不是空口建议
强制运行与观测，不只读 diff
对外部 API 以官方文档/类型定义为准
关键逻辑双人/双通道验证

2. 能力错觉与技能萎缩

用得越多，越可能：

不再能手写关键路径
读不懂自己合并的复杂 diff
调试时只会「再问模型」
设计能力退化成「选一个它给的方案」

这不是危言耸听，是工具依赖的经典曲线。
计算器没有毁掉数学，但 只按计算器、从不理解运算 的人，会在边界情况翻车。

建议：

定期无 AI 完成小任务，保持肌肉记忆
对核心模块保持「我能解释每一层」的标准
把 AI 输出当草稿，把理解当交付标准

3. 技术债加速器

AI 很擅长：

复制已有坏模式并扩散
用新抽象掩盖旧混乱
为了让测试通过而特化实现
增加「能跑」但难改的分支

如果仓库本身边界烂、测试虚、命名飘，AI 会成为 债务复利机器。

对策不是少用 AI，而是：

先修模块边界与测试可信度
把「禁止继续扩散」的模式写进规范
重构任务给 AI 时，必须有表征改进的验收（复杂度、重复、耦合指标）

4. 安全与供应链

新攻击面：

提示注入：恶意内容诱导模型执行危险操作
依赖幻觉：引入不存在或被抢注的包名
密钥泄露：把 .env、日志、生产配置贴进上下文
过度授权：agent 拥有改基础设施的权限
不经意的数据外传：把客户数据送进第三方模型

最低防线：

密钥扫描与预提交拦截
依赖变更单独审
生产数据默认不可进提示
工具权限最小化
对「安装包 / 改 CI / 改权限」高敏感

5. 合规、版权与归属

仍在演进的灰色地带：

生成代码与训练数据的关系
开源许可证污染风险
客户合同是否允许第三方模型处理代码
内部知识产权如何界定「作者」

工程团队至少应：

知道公司对模型供应商与数据驻留的政策
避免把高度敏感/未开源算法细节随意上传
在高合规行业保留更强的人工审计

6. 评估失灵

「感觉更快了」不等于「交付更好了」。

常见失灵：

用生成行数衡量产出
只看 demo 路径，不看失败路径
用模型自评「代码很好」当质量信号
忽略运维成本与认知负荷

更好的评价问题：

线上事故有没有因 AI 引入的隐蔽回归？
新人/其他同事能否维护这些代码？
同样需求，返工次数是升还是降？
关键模块的可理解性是升还是降？

7. 组织风险：责任真空

当人人都用 AI：

出了 bug，是提示写得差，还是模型不稳，还是评审失职？
没有明确 owner 时，容易变成「工具背锅、无人改进」

必须坚持：

合并者/服务 owner 对人肉责任负责，AI 没有责任能力。

流程上：

PR 必须有人类 assignee
生产变更有人类 approver
复盘关注「哪道人的闸门失效」，而不是骂模型

8. 模型与场景的硬边界（2026 视角）

当前仍然明显吃力的区域：

超大系统的全局一致性推理（跨很多隐含约束）
强实时/强正确性的硬核系统（无充分形式化时）
深度性能调优（需要测量文化，不是文采）
新颖研究型算法的可靠发明
高风险决策的最终拍板（医疗、金融核心、安全关键）

不是「永远不能」，而是：今天若无强验证闭环，不应把最终责任交给它。

9. 风险分级使用建议

风险等级	例子	建议
低	内部工具 UI、文档、脚本	大胆用，快速迭代
中	业务功能、常规 API	测试 + 评审后用
高	支付、权限、加密、数据删除	人设计 + AI 辅助实现 + 强化验证
极高	生产应急、不可逆迁移	AI 可参与分析，执行权严格人工

10. 一句话边界

AI 可以大幅降低「从想法到草稿」的成本，但无法免除「对现实世界负责」的成本。

下一篇：人的角色会怎样变