AI 自信地出错的 11 个迹象
AI 自信地出错的 11 个迹象：它对架构说错话时，语气和说对时一样笃定。学会识别危险信号，再用 4 步话术有力反驳，守住你的产品不翻车吧。
AI 很少在语法上出错。AI 自信地出错的迹象，全都出现在架构里。它会推荐今天能用、规模一上来就悄悄失效的捷径，而且出错时的笃定语气，和答对时一模一样。下面这 11 个危险信号，告诉你什么时候该停下来反驳。
在构建 FIKR Space 的 11 个月里，我和 Claude 争执了几百次。每一天都在争。它想走捷径，我坚持要结构。这些争执救了这个产品。下面是我希望第一天就拥有的清单——那些预示 AI 即将在你的产品里埋雷的具体措辞和遗漏。开始之前先说明一点：这些是 AI 建议中的警告信号，要在你接受之前抓住它们。AI 悄悄让一个已有代码库变质的四种更深层模式，是另一份清单——它在AI 如何破坏你的代码库里。
为什么 AI 会在架构上自信地出错？
它优化的目标和你不同。你的目标是可投入生产、能扩展、永远不用重建的软件。AI 的目标是让代码此刻能跑，并让你满意。它优化的是你当下的满意度，而不是你六个月后的成功——而你无法从它的语气里分辨出这一点。
它不了解你的系统。AI 只知道当前的对话和你给它看过的文件。它不记得你三周前定下的规则，也不记得你为什么做了某个特定选择。第一周立下的标准，到第五周就被它欢快地违反了。
它默认选“简单”。简单的方案通常是日后修起来贵十倍的那一个。现在的简单不等于以后的正确——而 AI 几乎从不主动说出这个取舍。
AI 自信地出错的 11 个迹象
| # | 危险信号 | 真正的含义 | 你的应对 |
|---|---|---|---|
| 1 | “为了简单起见……” | 技术债正在实时产生 | 坚持采用正确的结构——唯一的事实来源 |
| 2 | “为了性能……” | 过早优化；复制的值会逐渐失去同步 | 先要求拿出真实、可测量的问题证据 |
| 3 | “快速修复……” | 一个会变成永久的临时补丁 | 拒绝；追问根本原因和正确的修法 |
| 4 | 把选项列表写死在代码里 | 状态和类别被固化在代码中，没有开发者就改不了 | 把它们保留为可编辑的数据 |
| 5 | 把相关记录硬塞进一个大字段 | 数据再也无法搜索、关联或验证 | 要求记录之间建立真正的关系 |
| 6 | 新记录缺少客户标记 | 一个客户的数据可能泄露到另一个客户的账户 | 每条记录都必须标明它属于哪位客户 |
| 7 | 跳过索引 | 今天很快，真实数据一来就慢如蜗牛 | 给表与表之间的每个连接都建索引——永远如此 |
| 8 | 跳过数据库层面的访问规则 | 把安全寄托在运气和善意上 | 由数据库本身强制执行访问控制 |
| 9 | 创建近乎重复的表 | 同一种结构被重复，随时间渐行渐远 | 用一个共享结构处理所有情况 |
| 10 | 永久删除数据 | 错误无法恢复，也没有谁删了什么的记录 | 把记录标记为已删除；绝不销毁 |
| 11 | “针对这个问题的变通办法……” | “我不知道该怎么正确地修” | 追问真正的问题是什么；改去修那个 |
注意这个分野。前三条和最后一条是措辞——读一读就能抓到。中间七条是遗漏和习惯——AI 悄悄做了或漏掉的事。遗漏更危险，因为根本没有可抓的句子，只有一片空白。这就是为什么你要对照固定清单审查一切，而不是相信自己的直觉。
本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →三场救了我产品的真实争执
写死列表之战（第 2 个月）。Claude 想把任务状态直接写进代码里。我说不行：放进一张可编辑的表。Claude 反驳——“但这样更简单、性能更好。”我不在乎。结果是：一份状态列表，服务着一个增长到 964 张表的平台，每位客户都能自定义，新增状态不需要改代码。如果我当时接受了，最后会有 200 多个写死的列表散落在代码库各处，根本无法自定义。
重复的诱惑（第 3 个月）。Claude 想把项目名称复制进每一条任务记录，说这样查询会“更容易”。我强制改成引用项目。现在给项目改名只需更新一条记录，每个界面立刻显示新名字。如果我当时接受了，一次改名就意味着要更新几百行任务——总会漏掉几行，产品就在悄悄地自相矛盾。
大字段的诱惑（第 4 个月）。Claude 想把任务的负责人当成一大段文本存在任务本身里——“灵活，容易更新”。我强制在任务和人之间建立正式的关联。结果是：“给我看分配给这个人的所有任务”瞬间可得、结果可靠。如果我当时接受了，这个最基本的问题几乎无法回答。
还有两场争执每周都在重复：Claude 忘了给新表标记所属客户，还跳过索引。每张表，每一次。这两个问题我都是靠清单抓到的，不是靠直觉。
如何反驳：4 步话术
“这是错的，改掉”行不通——AI 不知道错在哪、为什么错，也不知道你想要什么。每次都用这个结构：
- 指出问题。“你把状态列表写死了。”
- 解释为什么不对。“状态会变化，客户需要在不改代码的情况下自定义它们。”
- 说明正确的方案。“把状态存成可编辑的数据，包含名称、颜色和排序。”
- 要求实现。“给我看更新后的版本。”
一个提醒：反驳会让人觉得不对劲。AI 又快又自信地给了你能跑的代码——拒绝它显得忘恩负义又拖沓。要顶住这种感觉。你的工作不是让 AI 开心，你的工作是交付可投入生产的软件。
什么时候该接受 AI 的建议？
AI 并不总是错——远非如此。当它生成重复、成熟的基础构件时，当它遵循你已经记录下来的模式时，当它推荐标准、广泛使用的工具时，以及当它对现有代码提出合理的整理时，尽管放心接受。经验法则是：AI 决定怎么敲出来，你决定要建什么、以及它是否站得住。这种分工就是全部的关键，它有自己的深度文章：你是建筑师，AI 是施工者。
12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →常见问题
如果我看不懂代码，怎么发现 AI 的糟糕建议？
11 个危险信号里，大多数是语言模式而不是代码：“为了简单起见”“为了性能”“快速修复”“变通办法”。其余是遗漏，你可以用一份固定的审查清单来检查——每条记录是否标记了所属者、连接是否建了索引、有没有东西被永久删除。你需要的是一份清单，不是计算机科学学位。
为什么 AI 会给出自信的错误答案？
因为它优化的是你此刻的满意度，而不是你六个月后的成功；因为它不记得你在之前会话里定下的规则；还因为它默认选择简单的答案，即使简单会在日后制造昂贵的问题。它的自信程度，对它的正确性不提供任何信息。
预防糟糕建议的最快方法是什么？
把你的规则一次写下来——写进 AI 在每次会话开始时都会读取的项目说明文件——并在违规发生的当下立刻纠正。事先写明的规则能预防大部分糟糕建议；即时纠正则处理本次会话里的其余问题。
反驳 AI 会拖慢构建速度吗？
只慢几秒钟——却能省下几周。每次纠正只需一条消息。而每一个被接受的捷径都会不断累积：失去同步的数据、泄露的账户、越来越难添加的功能。在 11 个月里，我反驳了几百次，这些争执就是产品从未需要重建的原因。
你到底被困得有多深？
完成职场窒息指数——这项免费测评告诉你是否已准备好成为独立创业者。