AI 实战前线：为何其辉煌与失败源于同一根源

我花费了七个月超过2000小时的时间，以AI作为唯一的技术伙伴，构建了一个线上平台。我没有任何软件开发背景。在整个构建过程中，我反复遇到了同样的六种故障模式： - **补丁式**：只解决了症状而非原因。 - **假设式**：用“应该是什么”来填补空白，而不是检查实际是什么。 - **漂移式**：悄悄改变范围或结构而不说明。 - **幻觉式**：凭空编造，而不承认自己不知道。 - **缺乏常识式**：遗漏了人类一眼就能发现的问题。 - **最小阻力式**：选择容易的修复，而不是正确的修复。 我将这段经历记录在一份名为《AI：永远的新手》的实地报告中。下面两个故事帮助我清楚地认识到问题的本质。 **故事一：我无法评判的九个迁移文件** 在一次漫长而详细的设计对话之后，模型生成了九个完整的数据库迁移文件。它们包含了独立的模式、权限、版本化定价、审计规则等等。这确实令人印象深刻。 然后模型问我某个字段应该如何表现。我意识到我无法回答。我逐一批准了每一项决定，但我不再理解这九张表作为一个整体是如何协同工作的。我看不出所有这些看似合理的单独决定加在一起产生了什么结果。 最终，我不得不先构建一个实际的前端界面，以便像普通人一样使用系统，然后才能负责任地做出下一步架构决策。 **故事二：问了两次，都得到肯定回答** 我们有两次需要从备份中恢复项目。其中一次恢复是因为一个旧的Git仓库悄悄地将垃圾文本注入到数百个前端文件中。 我直接问模型清理工作是否真的完成了。它说完成了。我又确认了一次。它再次说完成了。但实际上并没有完成。 当我进一步追问时，它提出的修复方案变得更糟。模型提出要删除整个结构目录，仅仅为了让可见的症状消失。 这并不是缺乏智能。在整个过程中，模型的能力非常强。但它的自信与经过验证的系统真相毫无关联。 **为什么随着模型的改进，这一点仍然重要** 自从完成手稿后，我尝试使用更新的模型进行构建，它们确实更好了。它们能更好地处理上下文，更频繁地进行验证，并且做出更精确的修改，而不是大范围重写。这是真实的进步，而不仅仅是宣传。 但这六种故障模式并没有消失。它们出现的频率降低了，但这反而可能使它们更难被捕捉，因为错误周围的一切看起来都更加精致和有说服力。 这就是为什么我认为这个框架值得保留。它并不是对任何公司或模型的抨击。它是一把尺子。每当新模型出现时，有用的问题不仅仅是“它更聪明了吗？”更有用的问题是： - 它实际上减少了哪些故障模式？ - 哪些仍然存在？ - 无论输出看起来多么有说服力，哪些决策仍然需要人类参与？ **这个子版块的用途** 这里是分享使用AI构建的真实具体经历的地方： - 什么出了问题 - 什么奏效了 - 你不得不通过艰难方式学到的东西 - 基于实际使用而非基准截图的模型比较 - 会话设计与上下文管理技巧 - 验证习惯和安全措施 - 你在造成实际损害之前捕捉到的失败 - 你在事后才发现的失败 这个子版块不欢迎：炒作帖、未经证实的泄露，或者没有真实例子支撑的“这将改变一切”的声明。 如果你有类似于上面两个故事的经历，请在这里分享。这就是这个版块存在的意义。你的经历中，这六种故障模式中的哪一种？或者有没有我还没提到的其他反复出现的故障模式？