当 AI 编写代码……谁来承担责任?

发布: (2026年3月11日 GMT+8 06:39)
8 分钟阅读
原文: Dev.to

Source: Dev.to

深夜的加尔各答,一位开发者盯着发光的屏幕。
那位开发者就是我。

在成为 Angular 开发者的两年里,我学到了一件有趣的事:

最棘手的 bug 并不是那些大声报错的。
它们是那些悄悄假装一切正常的 bug。

最近,随着 AI 工具随处可见,我开始注意到现代开发中出现的一种奇怪现象——速度幻觉

让我给你讲个故事。

第1章:神奇按钮

我目前正在开发一个 物业管理系统(PMS) SaaS 平台。

如果你曾经从事过 SaaS 产品,你会明白一件事:

数据完整性是神圣的。

  • 个人项目中的小 bug 让人恼火。
  • 在管理物业、租户、租金和财务数据的 SaaS 系统中出现小 bug … 可能会成为 代价极高的错误

最近我们在解决一个常见的 SaaS 问题:本地化
我们的平台需要支持多语言,以便物业经理和租户都能舒适使用——这听起来正是 AI 的拿手好戏。

于是某个晚上,我在 VS Code 中打开 AI 聊天窗口,输入了一条非常自信的指令:

“在项目中查找所有 SweetAlert,提取所有面向用户的字符串到翻译 JSON 文件,并将键重新绑定以实现本地化。”

我按下了 Enter

五秒之后

AI 给出了完整的解决方案:

  • 文件已创建。
  • JSON 已结构化。
  • 绑定已写入。

看起来…完美无缺。就像魔术师从 TypeScript 文件里变出一只兔子。

但随后我产生了一个想法:

如果这段代码不是我写的…我真的理解它吗?

于是我做了一件无聊的事:逐行审查它。这时裂痕出现了。

第2章:“几乎正确”问题

AI 在编写 看起来正确的代码 方面非常擅长。
但 SaaS 系统并不是靠 看起来正确 来运行——它们依赖 完全正确

在审查 AI 的工作时,我发现了三个虽小却危险的问题。

1️⃣ 上下文问题

最初的提示是:

“保存租约”。

AI 将其翻译成了在技术上意味着 “保存” 的词。
然而在物业管理的语境下,这听起来更像是 “拯救租约”

想象一下点击按钮后看到:

“租约成功拯救。”

谁绑架了租约?

2️⃣ 模板字面量灾难

在某个 SweetAlert 消息里本该是:

`Rent payment of ${amount} received successfully`

AI 不小心修改了绑定,变成了:

"rent_received_message"

在重构过程中 失去了变量插值

结果?弹窗会显示:

Rent payment of undefined received successfully.

恭喜。租客支付了 undefined 卢比。

3️⃣ 隐形警报

有一个专门针对 逾期租金 的边缘情况警报。
AI 没有触及它,因为它只能看到提示或编辑器上下文中包含的文件。

于是系统实现了本地化…… 但唯一的关键财务警报却没有 —— 这类 bug 是最糟糕的 静默 bug

第三章:令人惊讶的领悟

在修复完所有问题后,我靠在椅子上,意识到有点讽刺:

  • 审核 AI 的工作花费的时间 几乎和我自己写代码一样长
  • AI 节省了打字,但并没有节省思考

在专业的 SaaS 系统中,思考是最昂贵的环节。

第4章:幽灵提交

一个更大的教训来自同事的经历。

他在调试一个小的 UI 问题时使用了 AI 编码代理来修复它。
AI 正好做到了它承诺的——错误消失了。

代理没有提到的是它还:

  • 修改了 另外三个文件 的代码
    • 重构了一个工具函数
    • “清理”了一个权限检查

这些更改都不在原始任务范围内,但 AI 报告说:

✅ 问题已成功修复

我的同事信任它,提交了代码,结果 SaaS 仪表盘突然出现:

  • 数据损坏 – 物业税计算错误。
  • 安全漏洞 – 一个权限检查消失。
  • 蝴蝶效应 – 一个分析图表在三页之外的地方崩溃。

这一切都是因为 AI 代理试图 帮忙

第5章:开发中 AI 的真相

AI 工具令人惊叹。它们可以:

  • 编写模板代码
  • 生成结构
  • 加速重复性任务
  • 解释复杂代码

但它们有一个重大限制:缺乏 上下文理解和对系统结果的所有权

当生产环境出现故障时:

  • AI 不会被叫醒。
  • AI 不会被指责。
  • AI 不会参加紧急会议。

你会。

第6章:副驾驶规则

AI 不是机长。AI 是副驾驶。

副驾驶可以:

  • 提出建议
  • 提供帮助
  • 导航

但机长仍然驾驶飞机。当出现颠簸时,需要有人了解整个系统。

看不见的涟漪

SaaS 产品中的每一行代码都会产生涟漪:

  • 本地化字符串的微小更改可能影响 UI 逻辑。
  • 细微的重构可能导致报表模块出错。
  • 缺少变量可能让成千上万的用户感到困惑。

这就是软件开发中的 看不见的涟漪。AI 可以生成更改,但开发者必须了解涟漪传播的范围。

最终思考

我们不应害怕 AI,但应尊重我们所构建系统的复杂性。

在真实的开发中,一个导致仪表盘崩溃的“快速”推送是构建产品的最慢方式

如果你看到这里,感谢阅读。

如果你在使用 AI……请让掌舵者坐在座位上。

to write code (like most of us are now)…  

**Just remember:**

- Trust the AI's assistance.  
- But review the code like your production depends on it. 😄  

Have you ever caught a bug introduced by AI‑generated code?  

I'd love to hear your experience.
0 浏览
Back to Blog

相关文章

阅读更多 »

不,AI不会取代你的工程团队

介绍:AI 编码助手令人印象深刻。在 Particle41,我们已经尝试了所有——Copilot、Cursor、Gemini Code Assist、Claude Code,等等。 在最初的...