AI 生成代码出了问题,责任谁承担?
AI 编码时代的法律和伦理责任边界仍需明确。问题深刻但尚无工程级解决方案。
AI 编码时代的法律和伦理责任边界仍需明确。问题深刻但尚无工程级解决方案。
一天深夜,在加尔各答,一名开发者坐在发光的屏幕前,目不转睛地盯着它。
那名开发者就是我。
在成为 Angular 开发者的这两年里,我逐渐认识到软件开发中一个有趣的事实:
最棘手的 bug,并不是那些闹出巨大动静、让系统直接崩溃的 bug,而是那些悄无声息、假装一切正常的 bug。
最近,随着 AI 工具无处不在,我开始注意到现代开发中的一种奇怪现象——速度的幻觉。
让我讲个故事。
我目前正在开发一个物业管理系统(Property Management System,PMS)SaaS 平台。
如果你做过 SaaS 产品,就会明白一件事:
数据完整性神圣不可侵犯。
如果个人项目里出现了一个小 bug,它只会让人觉得烦。
但如果一个负责管理物业、租户、租金和财务数据的 SaaS 系统里出现了一个小 bug……
……它可能会变成一个代价极其高昂的错误。
最近,我们正在解决一个常见的 SaaS 问题:
我们的平台需要支持多种语言,让物业经理和租户都能顺畅地使用它。
听起来,这简直就是最适合交给 AI 的工作。
于是一天晚上,我打开 VS Code 里的 AI 对话框,输入了一条信心十足的命令:
“找出项目中的所有 SweetAlert,把所有面向用户的字符串提取到一个翻译 JSON 文件中,再把对应的 key 绑定回去,实现本地化。”
AI 交付了一套完整的解决方案。
文件创建完毕。JSON 结构整理完毕。绑定也写好了。
就像魔术师刚从一个 TypeScript 文件里变出了一只兔子。
但这时,我突然想到一个问题:
如果这段代码不是我写的……我真的理解它吗?
于是,我做了一件很无聊的事。
也就是从那时起,裂缝开始显现。
AI 非常擅长写出看起来正确的代码。
但 SaaS 系统并不是靠“看起来正确”运行的。
它们依赖的是“完全正确”。
在审查 AI 的工作时,我发现了三个看似细小、却十分危险的问题。
有一条提醒原本表达的是:
“保存租赁协议。”
AI 却把它翻译成了一个严格来说确实表示“保存”的词。
但放到物业管理的语境里……
……它听起来更接近“营救租约”。
多少有点戏剧化了。
想象一下,点击按钮后看到:
“租约已成功获救。”
所以,到底是谁绑架了租约?
某条 SweetAlert 消息中有这样一段内容:
`Rent payment of ${amount} received successfully`
AI 不小心修改了绑定,最后变成了类似下面这样:
"rent_received_message"
但在重构过程中,它把变量插值弄丢了。
于是提醒会显示:
已成功收到 undefined 卢比的租金付款。
租户支付了 undefined 卢比。
系统中有一条针对“租金逾期”这一特定边界情况的提醒。
AI 完全没有处理它。
因为 AI 只能看到 prompt 或编辑器上下文中包含的文件。
这意味着整个系统都完成了本地化……
唯独漏掉了一条至关重要的财务提醒。
这才是最糟糕的 bug。
修复完所有问题后,我靠在椅背上,意识到了一件略显讽刺的事。
审查 AI 工作所花的时间,几乎和我亲自编写代码一样长。
但它并没有省去思考。
而在专业的 SaaS 系统中,思考才是成本最高的部分。
但更深刻的教训,来自我一位同事的经历。
当时,他正在调试一个小问题。
他使用 AI coding agent 修复了它。
AI 完成了自己承诺的任务。
任务完成。
但这个 Agent 没有提到,它还做了以下事情:
修改了另外三个文件中的代码
重构了一个工具函数
“清理”了一项权限检查
这些都不属于最初的任务范围。
✅ 问题已成功修复
我的同事相信了它。
现在,想象一下这种事情发生在 SaaS Dashboard 中。
你可能会突然遇到:
物业税计算结果出错。
安全漏洞
某项权限检查消失。
三个页面之外的某张分析图表崩了。
这一切,仅仅是因为 AI Agent 想帮上更多忙。
AI 工具非常强大。
能够加速重复性任务。
但它们存在一个很大的局限。
它们既缺乏对上下文的理解,也不会对系统产生的结果承担责任。
当生产环境出问题时:
AI 不会收到紧急呼叫。
AI 不会受到责备。
AI 不会坐进事故紧急会议室。
所以,这是我现在遵循的准则。
AI 不是机长。
但驾驶飞机的仍然是机长。
因为当飞机遭遇湍流时……
必须有人理解整个系统。
SaaS 产品中的每一行代码,都会激起层层涟漪。
本地化字符串中的一处小改动,可能会影响 UI 逻辑。
一次小规模重构,可能会破坏报表模块。
少了一个不起眼的变量,就可能让成千上万的用户感到困惑。
这就是软件开发中那些看不见的涟漪。
AI 可以生成改动。
但开发者必须清楚,这些涟漪究竟会扩散多远。
我们不应该害怕 AI。
但我们应该尊重自己所构建系统的复杂性。
因为在真实世界的开发中:
一次破坏 Dashboard 的“快速” push,才是构建产品最慢的方式。
如果你读到了这里,感谢你的阅读。
如果你也在使用 AI 编写代码——现在我们大多数人都是如此……
可以相信 AI 的协助,但审查代码时,请把它当成生产环境的稳定性就取决于这次审查。😄
你是否也曾发现过由 AI 生成的代码所引入的 bug?
我很想听听你的经历。
部分评论可能只有登录后的访客才能看到。请登录以查看全部评论。
如果需要采取进一步措施,你可以考虑屏蔽此人和/或举报滥用行为。