引言
"等等，我不是这个意思啊！"
如果你用过 Cursor 或者其他 AI 编程助手，这句话你一定喊过。你满怀期待地描述了需求，AI 信心满满地开始改代码，等你回过神来——好家伙，它把你精心设计的组件改得面目全非，甚至引入了新的 bug。
更可怕的是，有时候 AI 改的地方太多，你都不知道从哪里开始回滚。
这个问题的根源在哪里？不是 AI 不够聪明，而是沟通出了问题。
今天分享一个简单但极其有效的技巧：让 AI 先复述，确认后再动手。这招来自职场沟通的基本功，用在 AI 编程上效果出奇地好。
问题根源：AI 的"自以为是"
在剖析解决方案之前，我们先看看问题是怎么产生的。
场景重现
假设你有一个博客卡片组件，上方显示的是专栏名称（如 "LLM PRACTICE"），你想把它改成显示文章的标签（Tags）。你这样告诉 Cursor：
"博客板块，每个博客卡片的内容中，上方目前显示的是专栏名称，我需要你调整成不显示专栏名称而显示文章的标签。"
看起来很清楚对吧？但实际上，这段描述存在几个模糊点：
| 模糊点 | 可能的理解偏差 |
|---|---|
| "上方" | 是标题上方？还是整个卡片的上方区域？ |
| "专栏名称" | 是 Column Name？Category？还是其他字段？ |
| "文章的标签" | 是 frontmatter 中的 tags？还是自动生成的标签？ |
| "显示" | 显示单个标签？多个标签？怎么排列？ |
AI 不会告诉你它有疑问，它会假装自己都懂了，然后按照它的理解开始干活。
结果可能是：
- 改错了文件
- 改错了字段
- 改对了但方式不对
- 改得太多或太少
这不是 AI 的问题，是人的问题
说实话，这种沟通问题在人与人之间也经常发生。
想想你给新同事布置任务的场景："把那个报表的格式调一下。" 第二天交过来，完全不是你想要的样子。为什么？因为"调一下"这三个字，你们的理解可能差了十万八千里。
职场沟通有一个经典技巧：让对方复述任务，确保理解一致后再开始。
这招用在 AI 身上，同样有效。
解决方案：复述确认法
核心思路很简单：在 prompt 的最后加一句话，要求 AI 先复述它的理解，等你确认后再动手。
魔法句式
在你的需求描述后面，加上这段话：
请你理解我的任务重复你的理解，确保跟我达成一致了。等我确认后才能够开始修改。或者更正式一点：
在开始修改之前，请先：
1. 复述你对需求的理解
2. 列出你计划修改的文件和具体变化
3. 说明预期的效果
等我确认理解无误后，再开始执行。实战效果
看看实际的对话效果。
用户的 Prompt：
博客板块，每个博客卡片的内容中，上方目前显示的是"LLM Practice"这个应该是专栏名称对吧，我需要你调整成不显示专栏名称而显示是文章的标签。请你理解我的任务重复你的理解，确保跟我达成一致了。等我确认后才能够开始修改。
Cursor 的回复：
📋 我的理解
当前状态： 博客卡片的上方区域显示的是 专栏名称（Column Name），比如图片中显示的
"LLM PRACTICE"期望修改： 将博客卡片上方的显示内容从 专栏名称 改为 文章标签（Tags）
具体变化：
- ❌ 移除：专栏名称标签（如 "LLM PRACTICE", "ANDROID", "CAROS" 等）
- ✅ 新增：文章的标签列表（frontmatter 中的 tags 字段，如 "AI", "Transformer", "LLM" 等）
影响范围：
- 📍 主要修改位置：
apps/wonderlab/app/blog/page.tsx或apps/wonderlab/components/home/BlogSection.tsx中的博客卡片组件- 可能涉及：博客列表页和首页的博客展示区块
视觉效果预期： 从显示单个专栏标签变为显示多个文章标签（可能需要处理标签数量过多的情况）
请确认我的理解是否正确？ 如果一致，我将开始查看代码并进行修改。
看到没有？AI 把你的需求拆解得清清楚楚：
- 当前状态 - 它理解现在是什么样
- 期望修改 - 它理解你想要什么
- 具体变化 - 它会删什么、加什么
- 影响范围 - 它打算改哪些文件
- 视觉效果预期 - 改完会是什么样子
如果有任何一点不对，你可以立刻纠正。比如你可能会说："不对，tags 字段不在 frontmatter 里，而是在 meta 对象中。" AI 收到反馈后会更新理解，再次确认。
这比改完代码再发现问题，不知道省了多少时间。
为什么这招有效？
1. 强制 AI 慢下来
AI 的默认模式是"接到任务就干"。加上复述要求后，它必须先整理思路，这个过程本身就能暴露理解偏差。
2. 让模糊地带显性化
你的需求描述中可能有很多隐含假设，你自己都没意识到。AI 的复述会把这些假设摆到台面上——"你说的是这个意思吗？"
3. 建立双向确认机制
传统的 AI 交互是单向的：你说 → AI 做。加上复述后变成：你说 → AI 理解 → 你确认 → AI 做。多了一个校验环节，错误率大幅降低。
4. 减少返工成本
代码改错了再改回来，成本远高于多花 30 秒确认需求。尤其是当 AI 改了多个文件、涉及多处逻辑时，回滚的心理负担也很大。
进阶技巧
技巧一：提供上下文边界
除了让 AI 复述，你还可以主动限定它的活动范围：
需求：xxx
约束条件：
- 只修改 BlogCard 组件，不要动其他文件
- 保持现有的样式结构
- 不要引入新的依赖
请先复述你的理解，确认后再开始。技巧二：分步确认
对于复杂的修改，可以要求分步执行：
这个需求比较复杂，请分三步完成：
1. 先列出你要修改的所有文件和修改点，我确认后再开始
2. 先修改数据层逻辑，完成后暂停让我验证
3. 再修改 UI 层展示
每一步都等我确认后再进行下一步。技巧三：在 Cursor Rules 中预设
如果你经常使用 Cursor，可以在项目的 .cursorrules 文件中加入这个规则：
## 代码修改规范
在执行任何代码修改之前，必须：
1. 先复述你对需求的理解
2. 列出计划修改的文件清单
3. 说明每个文件的具体修改内容
4. 等待用户确认后再开始执行
如果用户的需求描述存在模糊之处，主动提问澄清，不要自行假设。这样每次 Cursor 接到任务，都会自动遵循这个流程。
什么时候可以不用这招？
凡事有度，不是所有场景都需要复述确认：
| 场景 | 建议 |
|---|---|
| 简单明确的任务（如"把这个变量名改成 xxx"） | 直接执行 |
| 有明确代码示例的任务 | 直接执行 |
| 涉及多文件、多逻辑的修改 | 必须复述确认 |
| 需求描述比较抽象的任务 | 必须复述确认 |
| 你对代码不够熟悉 | 必须复述确认 |
简单来说：不确定的时候，就让它先复述。
总结
今天分享的技巧只有一句话：
在 prompt 末尾加上"请先复述你的理解，确认后再开始"。
这招看起来简单，但它解决的是 AI 编程中最常见的痛点——需求理解偏差。
记住：
- AI 不会主动告诉你它不确定
- AI 会假装自己都懂了
- 代码改错的返工成本远高于多确认一次的时间成本
下次让 Cursor 改代码之前，试试这招。你会发现，那个总是"瞎改"的 AI，突然变得靠谱多了。
你有没有被 AI 改代码坑过的经历？欢迎在评论区分享你的"翻车"故事和应对技巧！