你有没有过这种体验？

跟 AI 说"帮我写一个登录表单"，它唰唰给你生成了一堆代码，你兴冲冲地跑起来一看——表单是有了，但样式跟你项目完全不搭，验证逻辑也不对，密码输入框居然没有隐藏密码的功能，报错信息直接 alert 弹窗……

然后你叹了口气，心想：AI 也不过如此嘛。

等等，先别下结论。这不是 AI 的问题，也不是你的问题——这就是 Vibe Coding 的正常工作流程。第一次生成的代码，就不该是完美的。

我第一次用 Cursor 做项目的时候，犯了一个新手都会犯的错误：我以为只要 Prompt 写得足够好，AI 就能一次给我完美的代码。所以我花了很长时间打磨第一条 Prompt，写了一大段详细的需求描述，然后满怀期待地按了回车。结果呢？生成的代码确实比随便写两句好很多，但依然有一堆需要改的地方。我当时还挺沮丧的。

后来我才想明白：写代码这件事本身就是迭代的。 即使是人类程序员，也不可能一次写出完美的代码。你写完第一版要跑一下、调一下、改几个 Bug、重构一些不优雅的地方。AI 生成代码也是一样的道理——它给你的是第一版草稿，你的工作是通过追问和反馈，把这个草稿迭代成成品。

新手 vs 老手的区别

说实话，"会不会追问"是区分 Vibe Coding 新手和老手最明显的标志。

你注意到了吗？老手的核心心态就一个字：迭代。他们不追求一步到位，他们追求每一轮对话都往正确方向推进一步。

追问的三个层次

追问不是随便说"这不对，改一下"。好的追问有三个层次，每个层次解决不同的问题：

第一层：定位问题——告诉 AI "哪里"出了问题。

这是最基础的。很多人追问的时候只说"有 Bug"或者"不太对"，AI 收到这种模糊反馈，只能瞎猜。你要做的是精确定位：是哪个文件？哪个函数？哪一行？什么错误信息？

举个例子，你让 AI 写了一个 Todo 列表，跑起来之后发现添加任务后列表不更新。差的追问是："列表不更新，帮我修一下。"好的追问是："点击添加按钮后，addTodo 函数执行了（我加了 console.log 确认），但 UI 没有重新渲染。我怀疑是 state 更新的方式不对——你用了 push 直接修改数组，React 检测不到引用变化。"

看到差别了吧？第二个追问不光说了"什么问题"，还说了"我已经排查到哪里了"和"我猜原因是什么"。AI 收到这种信息，几乎可以一次修对。

第二层：描述期望——告诉 AI "应该"是什么样。

有时候代码没有报错，但行为不符合你的期望。这种时候你要告诉 AI 两件事：现在的行为是什么，你期望的行为是什么。

比如："目前密码输入框是明文显示的，我需要默认隐藏密码，右边有一个小眼睛图标，点击可以切换显示/隐藏。"这就比"密码框不对"清楚得多。

第三层：给约束——告诉 AI 修改时"不要"动什么。

这个很多人会忽略，但特别重要。AI 在修 Bug 的时候，有时候会"牵一发动全身"——你让它改一个按钮的样式，它把整个页面布局都重构了。所以好的追问会加上约束："只修改 handleSubmit 函数的逻辑，不要改组件的 JSX 结构和样式。"

一个真实的追问链条

给你看一个我实际用过的追问过程。我让 Cursor 帮我做一个简单的 Markdown 编辑器：

第一轮（初始指令）： "用 React + TypeScript 做一个 Markdown 编辑器。左边输入 Markdown，右边实时预览渲染结果。"

AI 生成了代码，能跑，但有三个问题：用了一个我项目里没有的 markdown 解析库、没有处理 XSS 攻击、样式是内联的。

第二轮（修复依赖问题）： "不要用 marked 这个库，用 react-markdown，这是我项目已有的依赖。其他代码不用改。"

修好了。

第三轮（修复安全问题）： "预览区域需要做 XSS 防护。用 rehype-sanitize 插件过滤危险的 HTML 标签。"

修好了。

第四轮（修复样式）： "把内联样式改成 Tailwind CSS 类名。编辑器区域用等宽字体 font-mono，预览区域用 prose 排版。"

完成。四轮对话，每轮只解决一个问题，总共大概 3 分钟。如果我第一轮就把这些约束全写上去，Prompt 会非常长，而且 AI 可能顾此失彼。分步迭代反而更快。

这就是迭代的精髓：不是你写得不好，是你写完之后还愿意继续改。 大多数人的问题不是第一次写得差，而是第一次写完就停了。