Ask HN：AI 使用中最惨痛的教训——社区翻车经验汇总

2026 年 6 月 17 日，Hacker News 上出现了一个有点不一样的帖子：“Ask HN: What is your worst lesson learned from using AI?”

帖子不复杂，问题也很直接——用 AI 过程中，你最大的教训是什么？社区分享了几条值得仔细品味的故事。虽然回帖数量不多，但每条都击中了 AI 落地中最真实的痛点。

教训一：别让 AI 在代码库上跑野

*“有一天，我给了 AI 一个自认为简单的任务——重构一个稍大的源文件。我惊恐地看着它完全搞错方向，污染了两个大文件后才手动终止。由于修改是连续的小变更，无法撤销，我不得不从版本控制拉回干净代码，损失了几个小时的工作。” — **messel（11 小时前）

这是一个非常典型的”AI 信任过度”案例。问题不在于 AI 做错了——而在于你给了它超出你承受范围的权限。

这个教训的核心是责任边界：

• AI 每步修改看起来是合理的，但累积起来方向可能完全错
• 没有”撤销”的概念——小变更连续叠加后回退成本极高
• 无监督模式下，任何模型都不值得信任

“我现在永远不会让 LLM 做这个规模的任务。我知道有人喜欢让 Agent 在代码库上随便跑——但在我这，就算是最好的前沿模型，**也别想无监督地跑我的代码。”*

教训二：代码要用「护栏」，不是靠信任

“如果能用强类型语言，就用。单元测试不够，你还需要集成测试，如果适用的话再加上无头浏览器测试。这能自动捕捉 AI 的很多早期错误。” — vantareed（11 小时前）

这条教训来自一位显然经验丰富的开发者。他强调了两个关键点：

1. 工程护栏：强类型、单元测试、集成测试——传统的软件工程方法就是最好的 AI 护栏。AI 帮你写代码，你用测试来约束它。
2. 规则文件要固执：对代码组织方式要有明确的规则文件。他还分享了自己的模板：https://github.com/victusfate/scaffold

一个特别值得注意的观察：“我经常看到 AI 把简单的继承改成 switch-case。有时候只是一个一行代码的改动，它都要跑很久。”

这也引出了另一个原则——让 AI 动测试代码时要格外警惕，你需要在每个改动前追问它”为什么”。

教训三：95/5 的残酷现实

“AI 用 3 小时做完了前 95%，然后留给你 3 天去搞最后 5%。” — uberman（11 小时前）

这条回复只有一句话，但它是整个帖子里获共鸣最多的。它描述了一个几乎所有长时间使用 AI 的人都深有体会的现象：

最后 5% 通常包括：边界情况没处理好、代码能跑但有隐性问题、AI 做了一些你没注意到的假设、架构层面的设计缺陷在后期暴露。

启示：AI 提速的是从 0 到 80 分的路段。从 80 分到 100 分，仍然高度依赖人的判断和经验。如果能提前识别出那 5% 是什么，就能更好地规划时间。

教训四：API 调用不是魔法

*“想让 AI 从 500 词的文本里提取信息并格式化成表格，设了 10 条清晰的规则。调提示词修了一个 bug 就会引入新的。错误是随机的，多次测试不会重复出现。” — **zyruh（10 个月前，来自另一条类似线程）

这条经验来自一个更早的帖子（”Ask HN: What’s your biggest success–or failure–using AI?”），但它揭示的问题在今天仍然普遍。

AI 的结构化输出能力远没有看起来那么可靠。当你要求它严格遵循 10 条规则输出时：

• 规则之间的冲突会被 AI 以不可预测的方式解决
• 同一个问题在不同调用中可能得到不同的错误
• 你无法像对待传统代码一样”定位和修复”——因为错误不是确定性的

建议：对于需要严格格式化的输出，不要依赖 AI 的遵循能力。用确定性代码做格式校验和后处理，用 AI 只做内容理解的部分。

教训五：别让 AI 管你的导航

“有一次我坐在副驾，微软 Copilot 告诉我们在错误的高速出口下高速。教训：用 Google Maps / Apple Maps / OpenStreetMap 吧。” — aurenvale（11 小时前）

这条看起来有点搞笑，但它揭示了一个严肃的问题：AI 的自信和它的准确率是不相关的。

AI 不会说”我不确定”，它只会给出一个看起来很有道理的答案。当你把这个答案用在现实世界的决策时——无论是导航、财务建议还是医疗信息——代价可能不只是几个小时。

这些教训背后的共同模式

汇总这几条来自社区的教训，可以看到几个反复出现的主题：

1. 信任曲线错位

大多数人使用 AI 有个共同的错误轨迹：初期过度乐观 → 遇到重大失败 → 修正期望 → 找到有效边界。问题在于，第一阶段（过度乐观）造成的损失可能很大。

2. 确定性幻觉

AI 的输出看起来是有道理的，但不是确定性的。传统软件工程中，相同的输入永远得到相同的输出；AI 不是这样。这个差异被很多人低估了。

3. 低成本的前 80%，高成本的后 20%

无论是代码开发、数据提取还是文档撰写——AI 做前 80% 又快又好，但最后 20%（边界情况、异常处理、一致性）往往需要比从头做更多的时间。

4. 无监督是最大的风险

每一次让 AI “自己跑”的决定，都是在做一次风险赌注。赌 AI 不会偏离方向、不会引入 bug、不会做出错误假设。这些教训的共识是：不要赌。

实用建议

结合这些社区经验，整理了几条实用原则：

参考资料

• HN 原帖：Ask HN: What is your worst lesson learned from using AI?（2026-06-17，4 points）
• 相关讨论：Ask HN: What’s your biggest success–or failure–using AI?（2025-08-05）
• vantareed 的脚手架模板：scaffold