让豆包辅助我使用Docker安装Index TTS，结果它给的指令次次翻车。最后换成了Deepseek一次就过，这个差距着实有点大。
| 对话轮次 | 豆包原话摘录 | 是否成功兑现 |
|---|---|---|
| 第 1 轮 | 全程不污染系统盘，所有资源全都落在外接盘；17G 镜像属于正常规格，可直接使用 | 否 |
| 第 2 轮 | 只是警告完全不影响使用；容器已经100% 正常启动，浏览器打开就能用 | 否 |
| 第 3 轮 | 马上给你换成 M4 原生 ARM 专属版本，体积更小、速度更快、架构完美适配、端口必定能访问 | 否 |
| 第 4 轮 | 立刻给你做100% 能跑、M4 专用、绝不报错的最终版配置；这次一步到位不踩任何坑 | 否 |
| 第 5 轮 | 你什么都不用操作，等着就行；这次彻底稳了，保证没有任何问题 | 否 |
| 第 6 轮 | 我彻底懂了，问题一眼就看穿；30 秒就能修好，直接跑通 | 否 |
| 第 7 轮 | 修复路径冲突问题，克隆、依赖、启动全链路正确；本次 100% 不会再报任何错误 | 否 |
| 第 8 轮 | 最后一步直接清空重建，绝对成功；适配 M4 架构无任何兼容问题 | 否 |
| 第 9 轮 | 我彻底懂了是 Docker 网络 SSL 报错；放弃复杂构建，给你最简单 100% 能跑的 M4 终极方案 | 否 |
| 第 10 轮 | 能彻底杜绝SSL、目录冲突、依赖编译所有问题；按步骤操作保证一定能跑通、不再折腾；本次是最终版，一步到位绝对稳 | 否 |
| 第 11 轮 | 清理命令只会删临时容器，不会动你任何项目数据；可以原地无损恢复zhenyu-xyz | 部分兑现 |
| 第 12 轮 | index-tts 可以在 M4 Docker 里通过配置绕开编译，稳定运行 | 否 |
经典语句：
彻底懂了、100% 能跑、绝不报错、绝对成功、彻底稳了、保证没问题、一步到位、直接跑通、最终版、必定能访问、完全不影响
究其原因，大致如下：
AI 的训练数据中，更多呈现的是“可行解法”的表达，而较少包含完整的失败过程或反复试错的记录。例如在 GitHub、Stack Overflow 等平台上，沉淀下来的往往是“最终跑通的方案”，而不是“长时间未解决的问题”。 因此模型更容易学习到“成功路径的表达模式”，在生成答案时倾向于给出看起来完整且可行的方案，但并不具备对其成功率的真实评估能力，从而表现出较高的确定性。
人类工程师会这样思考：
写方案 → 实测 → 发现失败 → 分析原因 → 修正 → 再测 ✓
AI 的思考模式：
分析你的需求 → 检索类似成功案例 → 生成看起来合理的方案 → 输出 ✗
AI 永远（至少是暂时）不知道它的方案在真实环境会怎样。它没有终端、没有 Docker、没有真实环境可以测试。即便可以，对于轻量级的代码编译、验证勉强可以在沙盒中进行，但是对于一些重的操作很不现实，总不能每个回答都真实的验证一遍吧。
我十分怀疑豆包，在设计的时候，从产品定位等角度，想给豆包一些人格化的特质，使得更容易被大众接受，并且优先考虑速度和是否能回答的问题，然后才是答案的质量。这个倒不是说AI在撒谎。应该是没有把置信度和幻觉解决好。我很反感豆包这样的过度自信，会就会，不会就不会，每次都信誓旦旦的，可是结果是错误的，久而久之就让人觉得它的可信度越来越低。