🔍 不会写代码，怎么验收？——看结果的三个信号与跑偏了怎么拉回来
上一篇讲了怎么切小一轮。这一篇解决那个最扎心的问题：
「我不会写代码，但我怎么知道它做得对不对？」
这是新手最大的心理障碍。也是大多数人翻车的地方——做完了，却没发现已经歪了。
先破除一个误解
很多人以为：
「要验收代码，我得看得懂代码才行。」
不需要。 你有比读代码更好的三个工具：
1. 打开看结果 —— 它长什么样
2. 按你的要求试 —— 它能不能做到
3. 看有没有报错 —— 它是不是真跑通了这三样你都会，而且比读代码可靠得多。
为什么？因为代码能跑 ≠ 对。你才是需求的唯一裁判，而你的验收方式就是「按你的要求试一遍」。
三个信号：判断「做得对不对」
信号一：结果长什么样（第一眼）
打开页面，问自己：
「这是我想要的那个东西吗？」
不需要懂代码。看结构对不对：
| 你要什么 | 页面该出现什么 |
|---|---|
| 一个输入框 + 一个按钮 | 就该只有这两个东西，不多不少 |
| 三列布局 | 该是三列，不是两列不是四列 |
| 深色主题 | 该是深色，不是浅色 |
新手最常见的失望来源：不是「做不出来」，而是「多了一堆我没要的东西」。
看到多余的，就直接说：
「这些我没要，去掉。只留 XXX。」
信号二：能不能做到（关键信号）
这是最重要的一步。 打开页面，按你的要求真的操作一遍。
| 你的要求 | 你该做的动作 | 该看到什么 |
|---|---|---|
| 添加待办 | 真的输入文字，点添加 | 列表里出现这一条 |
| 删除待办 | 真的点删除 | 这条消失 |
| 刷新不丢 | 真的按 F5 刷新 | 数据还在 |
| 校验手机号 | 输入「123」 | 提示格式不对 |
| 按钮禁用 | 条件不满足时看按钮 | 是灰的、点了没反应 |
为什么强调「真的按」？
因为「代码写了」和「功能成立」是两件事。AI 经常：
- 写了逻辑但没接到按钮上
- 加了校验但校验条件写反了
- 数据存了但没存对地方，刷新就没
这些你看代码很难发现，但动手点一下立刻就暴露。
💡 记住这句话：能跑 ≠ 能用。能用 ≠ 对。 必须真的按你的要求操作一遍，才算验收通过。
信号三：有没有报错（底线）
这一步只需要看一个地方：终端 / 浏览器控制台。
| 你看到 | 意思 | 怎么办 |
|---|---|---|
| 红色报错 | 跑挂了 | 别继续往下做，先让它修好 |
| 黄色警告 | 通常能跑，但有隐患 | 记下来，验收时问一句 |
| 干干净净 | 至少没崩 | 继续 |
新手大忌：看到报错了，先不管，接着做下一步。
这样堆下去，最后你手上是个「到处是错的、但每一步看起来都能跑」的东西。返工成本翻好几倍。
什么时候算「这轮过了」
给一个可执行的判断标准：
✅ 过了：你要的每一条都能做到 + 多余的都清掉了 + 没有报错
❌ 没过：有做不到的、有你没要的、或者有报错
三条里中任意一条，就别进入下一轮。先把这一轮收干净。
为什么这么严格？ 因为每一轮是建立在上一轮基础上的。带着问题进入下一轮，问题会滚雪球。
红线信号表：出现就要立刻停下来
这是本篇最实用的部分。这些信号意味着已经跑偏了，而你可能还没察觉。
| 🚩 信号 | 它意味着什么 | 你该说什么 |
|---|---|---|
| 你要的它没做 | 需求被误解或被忽略 | 「我要的是 X，Y 你没做上。补上。」 |
| 多了你没要的功能 | AI 自行扩大了范围 | 「这些我没要，全部去掉。」 |
| 改了你说「别动」的地方 | 边界没被遵守 | 「我说过只改 X，你改了 Y，把 Y 改回去。」 |
| 反复修同一个错 | 根因没找到，在打补丁 | 「停，别再改了。告诉我你为什么会出这个错。」 |
| 改了 10+ 个文件但你只说了一个改动 | 失控的前兆 | 「停。你改了太多，回退，只做我要的那一件。」 |
| 出现你没提过的技术名词 | 它在自作主张换方案 | 「我没说要换 XXX，为什么换？说清楚。」 |
| 它说「已完成」但你打开发现跑不起来 | 它没真跑过 | 「它说完成了但我这边是报错状态，你实际跑一遍给我看。」 |
其中「反复修同一个错」这一条特别值得记住。
新手遇到 bug 的本能反应是「让它再改改」。但如果连着两三轮还在修同一个错，说明方向错了——它没找到根因，只是在表面糊。
这时候正确的话是：
「先别改。你先告诉我你觉得错的原因是什么，说清楚再动手。」
跑偏了怎么拉回来：纠偏三招
第一招：先说清楚你到底要什么
❌ 不要说：「你搞错了」「不对」「不是我要的」
✅ 要说：「我要的是 X，现在是 Y，改成 X。」
为什么？ 「你错了」对它没有任何可执行的信息，它只能猜。而「我要 X」是明确的目标。
💡 通用句式： 「我要的是 X，现在看到的是 Y。请改成 X，只改这一处，其他的不要动。」
第二招：回退到最后一个好状态
如果已经改得面目全非了，别在坏基础上继续修。
「先别改。回到上一个能用的版本，然后我们重新开始，这一轮只做 XXX。」
这比「在现在这个基础上再修 5 处」快得多，也干净得多。
💡 顺便问一句：你的 Agent 有没有 git 或者自动备份？ 如果没有， 强烈建议让它先做上——能一键回退，是 vibe coding 的安全带。 👉 怎么把需求讲清楚 里也提到过「先备份再动手」。
第三招：换个更小的说法重来
有时候不是它理解错了，是你的表述有歧义。
| 你的原话 | 更有效果的写法 |
|---|---|
| 「做得简洁点」 | 「只保留输入框和按钮，其他都去掉」 |
| 「好看一点」 | 「用深蓝色背景 + 白色圆角按钮」 |
| 「快一点」 | 「别做额外优化，直接改这一处」 |
当纠偏超过两次还不对，就换个说法重来，而不是第四次纠偏。
一个自检清单
每轮验收时，照着过一遍：
□ 我要的每一条，都能真的做到吗？（动手试，不是看代码）
□ 有没有多余的东西？（我明确没要的东西）
□ 有报错吗？（终端 + 控制台）
□ 这一轮只改了我说的地方吗？
□ 我能不能一句话说清这轮做了什么？最后一条如果你答不上来，说明这轮失控了。
一个心理建设：验收不是找茬
最后说个心态问题，这比技术更重要。
很多新手验收时的心态是：
「我不太敢挑毛病，怕显得我不会用。」
这个心态会害了你。
因为 AI 不知道什么是对的——它只能猜。而你不说，它就会按自己的理解做到底。你沉默，它就认为默许了。
换个角度想：
验收不是挑错，是给方向。
你不是在给 AI 打分，你是在告诉它「我要往这个方向走」。
而且——你不需要一次说对。 迭代本来就是来回的事。V1 说「Agent 做个网页」，第 3 轮说「删掉多余的」，第 6 轮说「这才是我想要的」。
这不叫反复，这叫迭代。
下一步
你已经会验收和纠偏了。但还有一个问题没解决：
「怎么让这件事长期不失控？项目越做越大，聊到第 30 轮它开始忘事、开始重复劳动。」
「哪些事该我管，哪些事该它管？」