企业官网建设流程全解析

• 文档
• 教程
• Vibe Coding
• 示例工程

本文基于开源项目 vibe-vibe 的《3.6 当 AI 不听话时：调试、修正与兜底策略》一章整理成文。Vibe Coding 中你的角色不是写代码，而是指挥与验收。本文带你系统掌握 AI 输出问题的六种类型、AI 幻觉的四种形态与供应链安全威胁（Slopsquatting）、三分钟快速诊断法、根因分析四象限、四种修正策略、错误驱动开发、死亡螺旋止损，以及从发送前自检到混合开发模式的完整防御体系；并结合仓库中 demo-01-todo、demo-02-todo-auth 的真实源码与测试用例，给出可复制、可验证的实战依据。

核心心法：AI 出错不可怕，可怕的是不知道它错了。

与人类错误不同，AI 的错误往往是可预期的、有规律的。提示词写得好（3.1-3.4 的技巧），迭代对话也在进行（3.5），但 AI 依然可能「不听话」：给的代码跑不起来、理解的意思和你想的不一样、推荐了根本不存在的库、反复修改却越改越乱。一旦你掌握了 AI 犯错的规律，就能从「慌张」变成「从容」——知道问题出在哪，知道怎么修，也知道什么时候该换个方案。这正是《3.6 当 AI 不听话时》一章（章节索引）要传授的能力，也是本文展开的全部内容。

一、AI 常见的六种「不听话」表现

AI 的「不听话」表现看似五花八门，但归纳起来主要有六种类型（详见 3.6.1 小节）：

1. 答非所问

场景：你让 AI 做「用户登录功能」，它却给了你完整的「用户注册 + 登录 + 找回密码」三件套。

为什么会这样：AI 基于大量训练数据进行模式匹配，看到「登录」会联想到常见的用户认证系统，然后「好心」地给你全套方案。

识别信号：输出的内容比你要的多很多；包含了你没提到的功能模块；AI 在解释时说「我假设你还需要...」。

2. 过度发挥

场景：你只想要一个显示当前时间的简单组件，AI 却加上了时区选择、12/24 小时切换、自定义格式等功能。

为什么会这样：AI 见过太多「完整」的解决方案，倾向于给出「全面」的实现，即使你只需要最简单的版本。

识别信号：代码量远超预期；引入了你不认识的第三方库；包含大量你不需要的配置选项。

3. 偷工减料

场景：AI 给的代码能跑，但没有处理「用户输入为空」「网络请求失败」等异常情况。

为什么会这样：为了让代码看起来简洁，或者因为你没有明确要求，AI 省略了防御性代码。

识别信号：代码中没有 try-catch 或错误处理；没有输入验证；「Happy Path」（理想路径）能跑，边界情况会崩。

仓库实证：在 demo-01-todo 的查询层中，useTodos在fetch失败时会throw new Error('获取待办失败')；而 demo-02-todo-auth 的创建接口用try/catch兜底、失败返回 500 与错误信息。这类「请求失败怎么办、输入非法怎么办」的防御性代码，正是 AI 最常偷工减料的部分——验收时务必逐条核对。

4. 自相矛盾

场景：AI 说「这个函数返回用户列表」，但实际代码返回的是单个用户对象。

为什么会这样：AI 生成注释和生成代码是相对独立的过程，有时会出现不同步。

识别信号：注释与代码行为不符；函数名暗示的功能与实际实现不一致；前面说的方案和后面的代码不匹配。

5. 幻觉（重点，详见下一节）

这是最危险的问题类型，下文单独展开。

6. 死循环

场景：你指出代码有问题，AI 修改后，下一轮又改回了原来的写法。

为什么会这样：对话上下文太长，早期的修正内容被挤出上下文窗口，AI 无法看到；你的修正指令不够明确；任务本身超出了 AI 的能力范围。

识别信号：同样的错误反复出现；AI 的修改越来越「绕」；修一个问题引入两个新问题。

二、AI 幻觉：识别、危害与供应链安全

AI 幻觉（Hallucination）是指 AI 生成看起来正确但实际错误的内容。在编程场景中，这可能导致代码无法运行，甚至引入安全漏洞。

代码幻觉的四种类型

1. 包幻觉：最危险的幻觉类型

为什么包幻觉的危害程度最高？因为它涉及到软件供应链安全。仓库的 5.3.5 小节对这类威胁做了完整剖析。

真实案例：2024-2025 年的安全研究发现了一种名为「Slopsquatting」的攻击方式：

1. 研究人员测试了 16 种主流 AI 模型，发现它们推荐的包中约20% 是不存在的（德克萨斯大学等机构 2025 年的研究显示约19.7%，开源模型幻觉率高达21.7%，即使是 GPT 系列也有5.2%）；
2. 更令人担忧的是，43%（部分研究统计为 58%）的幻觉包名会在多次询问中重复出现，因此可被预测；
3. 攻击者可以注册这些 AI 经常「幻觉」出的包名，植入恶意代码；
4. 当开发者按 AI 建议安装这些包时，就会中招。

攻击链条：

AI 幻觉出包名 → 攻击者注册该包名 → 植入恶意代码 → 开发者按 AI 建议安装 → 系统被入侵

真实威胁：2024-2025 年间，安全研究人员发现了利用这种技术的恶意活动。仓库记录了两个真实案例：Python 库aiocpa（2024 年 11 月）在 0.1.13 版本中植入恶意代码，将用户的 Crypto Pay API Token 通过 Telegram Bot 发送给攻击者，被发现前已被下载超过 12,000 次；npm 上的solana-systemprogram-utils（2024 年 12 月）伪装成 Solana 工具库，在 2% 的交易中悄悄将资金转到攻击者地址，因比例低而难以被立即发现。攻击者还会通过注册 AI 幻觉出的包名，窃取开发者的 npm tokens、GitHub 凭证等敏感信息。

核心原则：AI 推荐的包 ≠ 存在的包 ≠ 安全的包。在安装任何新依赖之前，花 30 秒去官方仓库验证（npmjs.com / pypi.org / pkg.go.dev / crates.io），可以避免很多麻烦。对 AI 生成的 GitHub Actions 配置，特别是涉及密钥和凭证的部分，也要仔细审查。

2. API 幻觉：看起来对但跑不起来

典型场景：

// AI 生成的代码 const lastItem = myArray.findLast(item => item.active);

问题：findLast()是 ES2023 引入的方法，在旧版浏览器或 Node.js 中不可用。AI 可能混淆了不同版本的 API。

常见的 API 幻觉模式：混淆不同库的 API（把 Lodash 的方法当成原生方法）；使用已废弃的 API；编造不存在的配置选项。

3. 逻辑幻觉：代码能跑但结果不对

典型场景：你让 AI 写一个「去重函数」，它给了你：

function removeDuplicates(arr) { // 去除数组中的重复元素 return arr.filter((item, index) => arr.indexOf(item) === index); }

代码看起来没问题，注释也对。但如果数组中包含对象，这个方法就失效了，因为对象比较的是引用而不是值。

4. 版本幻觉：用的是「过时」的写法

典型场景：你让 AI 用 React 写一个组件，它给了你类组件写法：

class MyComponent extends React.Component { componentWillMount() { // ... } }

问题：componentWillMount在 React 16.3 后已被废弃，React 18 中会产生警告。

验证技巧速查表

面对 AI 生成的代码，用这份清单快速验证：

验证包是否存在

# npm 包 npm search <包名> # 或直接访问 https://www.npmjs.com/package/<包名> # Python 包 pip index versions <包名> # 或直接访问 https://pypi.org/project/<包名>

在官方仓库中搜索到包后，还需检查可信度指标：周下载量是否较高（数千以上）、最近是否有更新、作者是否为知名组织、是否被其他流行项目依赖、是否有关联源码仓库。如果 AI 推荐了一个你从未听过的包，先搜索引擎检索是否有人在技术论坛或博客讨论过，找不到任何信息则很可能是幻觉。

验证 API 是否正确

1. 查阅官方文档：不要只相信 AI 的解释；
2. 检查兼容性：查看库的版本说明，确认 API 引入版本；
3. 小范围测试：先在独立环境跑一下，确认能用。

要求 AI 提供来源：当 AI 推荐了你不熟悉的库或 API 时，追问「请给出这个库的官方文档链接」「这个 API 是在哪个版本引入的？请给出参考来源」。如果 AI 无法给出有效链接，或者链接打开是 404，那很可能是幻觉。

验证逻辑正确性

1. 用边界情况测试：空数组、空字符串、null、超大数值；
2. 用反例测试：故意输入「应该失败」的数据，看是否正确处理；
3. 让 AI 自己检查：

请检查上面的代码，列出可能的边界情况和异常情况，以及当前代码是否正确处理了它们。

仓库实证：对「边界情况」的验证，可以对照 demo-01-todo 的测试用例：其中「标题为空时应该返回 400」「缺少标题字段时应该返回 400」正是用反例验证输入校验。而对应的 Zod 校验 schema 定义了title至少 1 个字符、最多 200 字，category限定为inbox/work/personal枚举——这类「空输入、超长输入、非法枚举值」正是逻辑幻觉的高发地带。

三、诊断问题：AI 错在哪里

当 AI 输出不符合预期时，首先要回答一个问题（详见 3.6.2 小节）：

是我没说清楚，还是 AI 没做对？

这个问题的答案决定了下一步行动：如果是你没说清楚 → 补充上下文，重新描述；如果是 AI 没做对 → 换种问法，或者换个策略。

三分钟快速诊断法

在深入分析之前，先用这三步快速排查，能捕获约 60% 的常见问题。

第一步：运行代码检查（30 秒）

# 如果是 JavaScript/TypeScript 项目 npx eslint <文件名> # 检查语法和格式问题 npx tsc --noEmit # 检查类型错误（如果用 TypeScript）

能发现的问题：语法错误（少了括号、拼错关键字）、类型不匹配、未定义的变量。

第二步：检查依赖和 API（60 秒）

对照代码中的 import 语句，检查：引入的包是否存在？调用的方法是否真的存在于该包中？版本是否匹配？

能发现的问题：包幻觉、API 幻觉、版本兼容问题。

第三步：运行现有测试（90 秒）

如果项目有测试用例：

npm test # 或你项目的测试命令

能发现的问题：行为变更（原来能跑的功能被改坏了）、逻辑错误、边界情况处理不当。

仓库实证：在 demo-01-todo 的 package.json 中可以看到"test": "vitest run"脚本，以及 TypeScript 5.9 等依赖。运行pnpm test即可复现「三分钟诊断法」的第三步；而 测试用例 中对 GET 接口返回 200、按分类过滤的断言，就是捕获「行为变更」与「逻辑错误」的典型手段。

根因分析四象限

如果三分钟诊断没有定位到问题，用这个四象限来分析根本原因：

我说得清楚 ↑ ┌─────────────┼─────────────┐ │ │ │ │ AI 出错 │ 补充上下文 │ 简单任务 │ → 换问法 │ → 重新描述 │ 复杂任务 │ │ │ ├─────────────┼─────────────┤ │ │ │ │ 拆分任务 │ 重描述+拆分 │ │ → 分步做 │ → 降低复杂度│ │ │ │ └─────────────┴─────────────┘ ↓ 我没说清楚

象限一：简单任务 + 我说得清楚 → AI 出错

特征：任务很明确、信息足够完整，但 AI 的输出明显不对。应对：换一种问法重新描述、给出正确示例让 AI 参考、尝试不同的 AI 工具。

原提示词：写一个判断闰年的函数 问题：AI 给的逻辑不对 换种问法： "请写一个判断闰年的 JavaScript 函数。 闰年规则： 1. 能被 4 整除且不能被 100 整除，是闰年 2. 能被 400 整除，也是闰年 请严格按照这个规则实现。"

象限二：简单任务 + 我没说清楚 → 补充上下文

特征：任务本身不复杂，但你假设了 AI 知道某些背景，AI 按自己的理解做了，和你想的不一样。应对：补充项目背景、明确技术栈和约束、说明期望的输出格式。

原提示词：写一个表单验证 问题：AI 用了你项目没有的验证库 补充上下文： "我的项目使用 React + Zod 做表单验证。 请用 Zod 写一个用户注册表单的验证 schema，包括： - 邮箱格式验证 - 密码至少 8 位 - 确认密码要一致"

仓库实证：demo-01-todo 恰好就是「React + Zod」技术栈——validation.ts 用z.object声明了标题长度与分类枚举约束，demo-02-todo-auth 的创建接口则进一步用z.enum(['low','medium','high'])校验优先级。这类「明确技术栈 + 约束」的上下文，能显著减少象限二类偏差。

象限三：复杂任务 + 我说得清楚 → 拆分任务

特征：任务涉及多个步骤或模块，你描述得很清楚，但 AI 的输出质量不稳定。应对：把大任务拆成小任务，一次只让 AI 做一件事，分步骤完成后再整合。

原提示词（太大）： "实现一个完整的用户认证系统，包括注册、登录、找回密码、JWT 令牌管理" 拆分后： 第一轮："先实现用户注册功能，只需要邮箱和密码" 第二轮："现在加上登录功能，返回 JWT 令牌" 第三轮："加上令牌验证中间件" 第四轮："最后加上找回密码功能"

象限四：复杂任务 + 我没说清楚 → 重新描述 + 拆分

特征：任务复杂，你自己可能也没完全想清楚，AI 的输出和你想的差很远。应对：先退一步理清自己的需求，用 3.4 节的 PRD 方法整理思路，然后拆分成小任务逐个完成。

原提示词（模糊又复杂）： "帮我做一个类似 Notion 的笔记应用" 理清需求后： "我想做一个个人笔记应用，MVP 版本只需要： 1. 创建/编辑/删除笔记 2. 笔记列表页 3. 本地存储 先帮我实现第一个功能：创建和显示笔记列表。 技术栈：React + localStorage"

参考阅读：3.4 第一份 PRD 提供了把模糊想法整理成可执行任务书的方法。

诊断 Prompt：让 AI 复述理解

在开始任务之前，或者发现问题之后，可以用这个 Prompt 让 AI 复述它的理解：

在继续之前，请先回答以下问题： 1. **你理解的任务目标是什么？** （用一句话描述） 2. **你计划使用什么技术方案？** （列出关键技术点） 3. **有哪些地方你不确定，需要我澄清？** （如果没有就说"无"） 请先回答这些问题，确认理解一致后再开始写代码。

为什么这招有效：提前暴露 AI 的误解；让你在写代码前就发现问题；比事后修改成本低得多。

常见问题的快速定位

四、修正策略：怎么让 AI 改对

问题定位之后，进入修正环节（详见 3.6.3 小节）。在 3.5.3 中我们学过如何给 AI 有效反馈，本节聚焦于问题已经发生后的修正策略。

四种修正策略

策略一：精确指出问题

适用场景：你能定位到具体是哪行代码、哪个函数有问题。

你在 [位置] 的代码有问题： **问题**：[描述具体问题] **当前行为**：[代码现在做了什么] **期望行为**：[代码应该做什么] 请修正这个问题，其他部分保持不变。

示例：

你在 handleSubmit 函数第 15 行的代码有问题： **问题**：使用了 localStorage，但这是服务端渲染项目 **当前行为**：直接调用 localStorage.setItem()，在服务端会报错 **期望行为**：先检查是否在浏览器环境，或者使用 cookies 请修正这个问题，其他部分保持不变。

这个示例与 Next.js 场景高度吻合——仓库 demo-02-todo-auth 的 safe-action 通过next-safe-action中间件统一处理服务端会话，正是「区分客户端与服务端环境」的工程化示范。

策略二：给出正确示例

适用场景：AI 理解了任务，但输出的格式、结构不符合你的要求。

输出格式不对。 **当前格式**： [展示 AI 给的格式] **期望格式**： [展示你想要的格式] 请按期望格式重新输出。

示例：

函数返回格式不对。 **当前格式**： 直接返回数据，如 `return userData` **期望格式**： 统一返回格式 `{ success: boolean, data: any, error?: string }` 成功时：`{ success: true, data: userData }` 失败时：`{ success: false, data: null, error: "错误信息" }` 请按期望格式修改所有 API 函数的返回值。

策略三：分步重做

适用场景：任务太复杂，AI 一次性输出的代码问题较多，修补不如重来。

这个功能我们分步骤来做。 **第一步（当前）**：[最小核心功能] 只需要实现这一个功能，其他的后面再加。 完成后我会确认，然后我们再做第二步。

策略四：换种问法

适用场景：同一个问题，用同样的方式问了两三次，AI 还是给出类似的错误答案。

示例：

原问法（反复失败）： "写一个防抖函数" 换种问法： "用户在搜索框输入时，我不想每敲一个字就触发搜索请求， 而是希望用户停止输入 300 毫秒后再发起请求。 请帮我实现这个延迟触发的逻辑。"

错误驱动开发：把 AI 变成调试助手

当你遇到错误时，不必自己分析——可以直接把错误信息扔给 AI，让它帮你定位和修复。

工作流程：

发现错误 → 复制完整错误信息 → 给 AI 分析 → 应用修复 → 验证 → 如有新错误则重复

操作模板：

运行代码时遇到以下错误：

[粘贴完整的错误信息]

相关代码： ```[语言] [粘贴相关代码片段]

请分析错误原因，并给出修复方案。

**示例**： ```markdown 运行代码时遇到以下错误：

TypeError: Cannot read properties of undefined (reading 'map') at UserList (UserList.jsx:12:23)

相关代码： ```jsx function UserList({ users }) { return ( <ul> {users.map(user => <li key={user.id}>{user.name}</li>)} </ul> ); }

请分析错误原因，并给出修复方案。

AI 通常会告诉你：错误原因是 `users` 可能是 `undefined`；修复方案是添加空值检查或默认值。 > **仓库实证**：仓库 [Advanced 篇的调试心法](https://link.gitcode.com/i/1608006df785a68432e6d9e37413ab77)进一步总结了「完整日志 + 操作步骤 + 预期结果」的调试沟通公式——只复制最后一行错误信息给 AI 会多耗 1 轮追问，只说「报错了」会多耗 2 轮；**一次性给全信息可以做到 0 轮追问直接定位**。循环修复模式通常 2-3 轮解决，不要放弃。示例中的 `ECONNREFUSED`、`Could not resolve` 等错误都有对应的完整分析模板。 **调试公式**：

完整错误日志

• 操作步骤（你做了什么）
• 预期结果（你想要什么） = 快速解决方案

### 警惕「死亡螺旋」 「死亡螺旋」是指：你让 AI 修问题，它修了一个又引入两个新问题；你再让它修，问题越来越多，代码越来越乱。 **识别信号**：修改轮次超过 3 次问题还没解决；AI 的代码量越改越多、越改越复杂；修了 A 问题 B 功能又坏了；AI 开始「绕圈」，给出的方案和之前类似。 **止损策略**——一旦识别到死亡螺旋，果断止损： **选项 1：回退重来** ```markdown 这个方向走不通。请忘掉之前的修改，我们从头开始。 [重新清晰地描述需求，可能需要拆分成更小的任务]

选项 2：保留能用的，手动修复剩余部分

请把目前能正常工作的代码整理一下给我， 有问题的部分用注释标注出来，我自己来修。

选项 3：换一个 AI 工具试试：不同的 AI 模型在不同任务上表现不同，一个工具反复卡住时换一个可能有惊喜。

修正 Prompt 模板库

修复运行时错误

这段代码报错了： 错误信息：

[错误信息]

代码： ```[语言] [代码]

请修复这个错误。如果需要更多上下文，请告诉我需要什么信息。

**修复逻辑错误** ```markdown 这段代码可以运行，但结果不对： **输入**：[描述输入] **期望输出**：[描述期望结果] **实际输出**：[描述实际结果] 代码： ```[语言] [代码]

请找出逻辑问题并修复。

**修复样式问题** ```markdown 样式和预期不符： **期望效果**：[描述或截图链接] **实际效果**：[描述当前问题] 当前代码： ```css [样式代码]

请修改样式使其符合期望效果。

**要求 AI 自查** ```markdown 请检查上面的代码： 1. 有哪些潜在的边界情况没有处理？ 2. 有哪些可能导致运行时错误的地方？ 3. 有哪些可以优化的地方？ 列出问题后，请给出修复后的完整代码。

关联阅读：3.5.3 有效反馈的艺术 提供的 SBI 框架（情境-行为-影响）与反馈粒度金字塔（方向级 → 功能级 → 代码级），是上述修正模板的「底层语法」：有效反馈 = 具体位置 + 具体问题 + 期望结果。

五、兜底策略：当 AI 真的搞不定

有些时候，问题不在于怎么修正，而是 AI 真的做不到（详见 3.6.4 小节）。

认识 AI 的能力边界

AI 擅长的事：

AI 不擅长的事：

识别「AI 做不到」的信号：你已经提供了所有能想到的上下文，AI 还是给不出正确答案；AI 反复给出「看起来对但实际不能用」的方案；问题涉及你无法通过文字描述的内容（如视觉效果、本地环境）；修改了 5 轮以上问题还没解决。

三种兜底方案

方案一：换一个 AI 工具

不同的 AI 模型有不同的训练数据和擅长领域。换工具时注意：重新整理一遍需求描述；不要把前一个 AI 的错误代码带过去（避免干扰）；只描述问题本身和期望结果。

方案二：搜索引擎找现成方案

很多问题已经被其他人遇到并解决过了。高效搜索技巧：

[错误信息关键词] site:stackoverflow.com

[技术栈] [功能描述] github

[库名] [具体问题] 官方文档

示例：TypeError map undefined react site:stackoverflow.com

找到方案后，让 AI 帮你理解和适配：

我在 Stack Overflow 上找到了这个解决方案： [粘贴找到的代码] 请帮我： 1. 解释这段代码的原理 2. 根据我的项目情况（[描述你的技术栈]）进行适当修改

方案三：用 AI 理解概念，自己动手实现

当 AI 生成的代码不可靠时，退一步——让它帮你理解原理，然后你自己写代码：

1. 让 AI 解释原理：

不要写代码。请解释 [概念/功能] 的工作原理，包括： - 核心思路是什么 - 有哪些关键步骤 - 有哪些常见的坑需要注意

2. 让 AI 提供伪代码：

请用伪代码（不是真正的代码）描述实现步骤， 让我理解整体逻辑。

3. 你自己编写代码，遇到具体问题再问 AI。

这种方式的好处：避免 AI 幻觉导致的错误；你对代码有完整的理解；后续维护更容易。

混合开发模式

「混合开发」是一种务实的策略：让 AI 做它擅长的部分，你来补充它做不好的部分。

模式一：AI 做骨架，你做细节

请生成一个 [功能] 的代码框架，包括： - 基本的文件结构 - 主要函数的签名（参数和返回值） - 每个函数的功能注释 不需要实现具体逻辑，我自己来写。

模式二：AI 做初版，你来审查修改

工作流：让 AI 生成完整代码 → 你来审查，标记有问题的地方 → 简单问题让 AI 修正 → 复杂问题你自己改。

审查要点清单：代码逻辑是否正确？边界情况是否处理？引用的库和 API 是否存在？是否有安全隐患？是否符合项目规范？

模式三：分工协作

何时寻求外部帮助

应该寻求帮助的信号：问题涉及你完全不理解的领域（如安全、性能优化、DevOps）；卡住超过 2 小时没有任何进展；问题可能影响到数据安全或系统稳定性；需要做出可能影响长远的架构决策。

去哪里寻求帮助：Stack Overflow（技术细节、已有成熟答案的问题）；GitHub Issues（特定库或框架的问题）；社区论坛/Discord（需要讨论的开放性问题）；付费咨询/顾问（复杂的架构问题、安全问题）。

如何有效地提问——无论是问 AI 还是问人，好的问题能大大提高获得帮助的概率：

**我想做什么**：[一句话描述目标] **我遇到的问题**：[具体问题描述] **我已经尝试过**： 1. [尝试过的方法 1] 2. [尝试过的方法 2] **相关代码/错误信息**： [附上最小可复现的代码或完整错误信息] **我的环境**：[技术栈版本等信息]

六、预防胜于治疗：减少「不听话」的概率

前面几节讲的是「出了问题怎么办」，本节讲「如何从一开始就不出问题」（详见 3.6.5 小节）。

发送前自检清单

在按下发送键之前，花 10 秒过一遍这份清单，可以避免大部分问题：

• 任务是否聚焦？这次只让 AI 做一件事？
• 上下文是否充足？AI 有足够的背景信息理解任务？
• 目标是否明确？说清楚了「什么算完成」？
• 约束是否清晰？说明了「不要什么」？
• 格式是否指定？告诉 AI 期望的输出格式？

这与 3.1.3 学的「五大错误」（一次说太多、一次说太少、期待读心、忽视格式、不做约束）一一对应。养成习惯后，这个检查只需要几秒钟。

提问质量自评表

在开始重要任务前，用这个表格评估你的提示词质量：

评分解读：10-12 分很棒，发送吧；7-9 分可以发送，但准备好迭代；4-6 分建议补充信息后再发送；4 分以下重新组织提示词。

让 AI 先复述

这是一个简单但非常有效的预防技巧：在让 AI 开始写代码之前，先让它复述对任务的理解。

在开始写代码之前，请先回答以下问题： 1. **你理解的任务目标是什么？** 用一句话描述。 2. **你计划使用什么技术方案？** 列出关键技术点和实现思路。 3. **有哪些地方你不确定，需要我澄清？** 如果没有请说"无"。 请先回答这三个问题，我确认理解一致后，你再开始写代码。

为什么这招有效：提前暴露误解；统一预期；纠正一个误解比修改一堆错误代码快得多。

使用时机：✅ 开始一个新功能时；✅ 任务比较复杂时；✅ 你不确定 AI 是否理解了你的意思时；❌ 简单的小修改不需要。

小步快跑策略

「小步快跑」是指：把大任务拆成小任务，每完成一步就验证一下，确认没问题再继续。

拆分粒度建议：

小步快跑的节奏：

第一步：让 AI 做最小核心功能 ↓ 验证：能跑吗？结果对吗？ ↓ 确认 OK → 第二步：加一个小功能 ↓ 验证：还能跑吗？新功能对吗？之前的功能还正常吗？ ↓ 重复...

及时纠偏

发现问题后立即反馈，不要等到最后。为什么要及时：AI 刚输出完，上下文还在，修改最容易；知道问题就出在最近这一步，问题隔离成本低；一个错误不纠正，后面可能越错越多。

纠偏 Prompt 示例：

暂停一下。 上面的代码有个问题：[描述问题] 在继续之前，请先修正这个问题。其他部分可以保留。

等等，这不是我想要的。 我要的是 [正确的需求]，不是 [AI 做的]。 请重新理解我的需求后再继续。

预防检查清单

开始前：我清楚知道这次要让 AI 做什么（一件事）；我准备好了必要的上下文信息；我知道什么算「完成」。

发送后：AI 的复述和我的意图一致吗？AI 的技术方案合理吗？AI 用的库和 API 我认识吗？

收到代码后：代码能跑吗？结果符合预期吗？边界情况处理了吗？

七、仓库实战：把「调试 AI」能力落到真实项目

以上方法论并非空谈。在 vibe-vibe 仓库的 demos 目录中，有三个可运行的示例项目，它们既是 Vibe Coding 的产出物，也是验证「AI 输出质量」的最佳试验场：

• demo-01-todo（Next.js 16 · Drizzle ORM · Vitest）：完整 CRUD，含前端乐观更新、后端校验与测试；
• demo-02-todo-auth（Better Auth · 游标分页 · 虚拟列表）：在 CRUD 基础上叠加认证、权限与分页；
• demo-03-social-schema（Drizzle ORM 纯脚本）：Schema 设计、事务与高级查询。

对照本文的六种「不听话」表现，可以在这些源码中找到一一对应的验收点：

1. 防「偷工减料」：检查每个接口是否有输入校验与错误分支。例如 demo-01-todo 的 Zod schema 定义了标题长度与分类枚举约束；demo-02-todo-auth 的 POST 接口 用safeParse校验、失败返回 400 与首条错误信息，全程try/catch兜底返回 500——这正是「Happy Path 之外」的防御性代码标准。

2. 防「逻辑幻觉」：运行测试是最直接的验证手段。仓库中的 todos.test.ts 不仅断言正常创建（201），还断言了「标题为空返回 400」「缺少标题字段返回 400」等反例场景；GET 测试则覆盖了分类过滤参数。把这类测试交给 AI 生成后自己补反例，是捕获逻辑幻觉的高效流程。

3. 防「错误处理缺失」：queries.ts 中每个请求都检查res.ok并抛出带中文语义的错误（如「获取待办失败」「添加失败」），配合 TanStack Query 的onError回滚乐观更新——这正是「错误驱动开发」想要达到的工程标准：错误信息完整、可定位、可回滚。

4. 「三分钟诊断法」落地：在 demo-01-todo 目录下，pnpm tsc --noEmit检查类型、pnpm test运行 Vitest 用例，即可在三分钟内覆盖「语法/类型 → 依赖 → 测试」三层排查。

5. 「能力边界」对照：demo-02-todo-auth 的 safe-action.ts 把会话校验抽成中间件（未登录直接抛错）——这类涉及认证、会话的敏感逻辑，正是 3.6.4 中指出的「AI 不擅长/应谨慎对待」的领域，建议按「AI 做骨架、你写核心」的混合开发模式处理。

本章总结

至此，你已经完整掌握了「当 AI 不听话时」的五步应对体系：

1. 识别问题：六种常见的 AI「不听话」表现，特别是危险的 AI 幻觉（包幻觉、API 幻觉、逻辑幻觉、版本幻觉）与 Slopsquatting 供应链威胁；
2. 诊断问题：三分钟快速诊断法（运行检查 → 依赖验证 → 测试运行）+ 根因分析四象限（任务复杂度 × 描述清晰度）；
3. 修正问题：四种修正策略（精确指出、给出示例、分步重做、换种问法）+ 错误驱动开发 + 死亡螺旋止损；
4. 兜底方案：换 AI 工具、搜索现成方案、用 AI 学原理后自己实现，以及混合开发模式；
5. 预防问题：发送前自检、提问质量自评、复述技巧、小步快跑、及时纠偏。

记住这个心法：

AI 出错不可怕，可怕的是不知道它错了。

在 Vibe Coding 中，你的角色是指挥官，不是执行者。你负责把握方向、验收结果、处理异常。掌握了本节的技能，你就能从容应对 AI 的各种「不听话」，把它调教成一个可靠的助手。

延伸阅读：继续学习 5.3.5 Slopsquatting 详解 与 5.3.6 永远审查代码，或阅读 Advanced 篇的调试心法 获取「完整日志 + 循环修复」「让 AI 自己 Build」等进阶招式。

• 文档
• 教程
• Vibe Coding
• 示例工程