Agnet使用心得
Vibe Coding 复盘：我让 Agent 把系统越改越好，却离目标越来越远
一件说出来有点丢人的事
过去三周，我在用 GPT-5.6 配合一个国产 Agent 做 Vibe Coding。每天的节奏差不多是：早上提一句需求，Agent 啪啪改一堆代码，跑测试，全绿，我看着 diff 觉得挺合理，提交，收工。
到第三周末尾，我开始觉得不对劲。
代码行数比第一周涨了大概一倍半，模块拆得更细，测试覆盖率数字也好看，Validator 跑得比谁都稳。但当我把最新版本拿去对着最初那版业务需求核对时，发现它正在做的事情，已经和我真正想要的东西对不上了——不是功能少了，而是它在一个我早就不再关心的方向上，努力地做对了每一件事。
那种感觉很奇怪。你没法指着某一段代码说"这里写错了"，每一行单看都合理；可把整个系统拼起来，它就是一辆被反复改装、轮胎换成了赛车胎、引擎刷了一阶程序，结果目的地早就改到另一个城市的车。
这次复盘想记下来的，就是这件事是怎么发生的，以及后来我想明白的一个道理。
一开始，系统其实没什么问题
最初的 pipeline 很朴素，五层：
需求输入 → 计划 → 执行 → 验证 → 输出
那会儿业务需求简单，流程清晰，连"怎么算做对了"这件事大家也没什么争议。Agent 在这条流水线上表现得相当顺手：给它一个目标，它拆计划，写代码，跑验证，过了就往下走。前两周我甚至有点上头，觉得 Vibe Coding 大概就是这么回事——人提需求，Agent 干活，人当 review。
现在回头看，那不是因为流程多先进，而是因为需求、流程、验证标准这三件事，那会儿恰好是同一件事的三种说法。只要这三者对齐，整个系统怎么跑都顺。问题恰恰出在它们开始对不齐的那一刻。
滑坡是怎么发生的
业务变了。具体新需求是什么不重要，重要的是：当第一个新需求进来时，我的处理方式是——
打开 Agent，说"把这个需求加进去"，让它改实现层，然后用原来那套验证跑一遍，过了就合。
这个动作单次看完全合理，甚至可以说很"敏捷"。但它有个隐藏的前提：旧的验证体系仍然是对的。
问题是，新需求之所以叫新需求，往往就是因为旧的验证不再能覆盖它。于是系统开始长出一种很隐蔽的结构：
- 新业务逻辑加进来了；
- 旧业务逻辑没删，因为旧验证还在逼着系统满足它；
- 中间又长出一层兼容层，负责让新旧两套逻辑和平共处。
三周下来，系统的真实形态变成了：
新逻辑
+
旧逻辑（还在被旧验证守护着）
+
一层谁也说不清为什么存在的兼容胶水
最讽刺的是，这个阶段的 Agent 表现"越来越好"。因为旧验证标准清晰、可量化、跑起来快，Agent 天然会把优化火力集中到那里。它不是在故意和我作对，它只是忠实地、一丝不苟地，把我喂给它的评价函数优化到了极致。
直到有一天我意识到：它优化得越努力，系统离新业务目标就越远。
顿悟的那个下午
我把这三周的对话记录和 commit log 翻出来对比，突然看到了那条一直被我忽略的规律：
评价指标决定了搜索空间。
这是个 optimization 里的常识，我以前居然把它忘了。在一个优化系统里，如果 Validator 本身定义错了，那么优化算法再强、再勤奋、再不知疲倦，也只会把系统朝错误的方向收敛得更快、更彻底。
Agent 不会自己跳出来说一句："等等，你让我优化的这个东西，好像不是你真正想要的吧？" 它甚至没有这个概念。你给它什么 Validator，它就把什么当真理。Validator 说旧流程正确，它就会日复一日地琢磨"怎么把旧流程跑得更漂亮"，而不是"怎么实现你嘴里那个新业务目标"。
那一刻我才明白，这三周的问题根本不是 Agent 写代码不行。恰恰相反，它太行、太听话、太不知疲倦了。真正掉链子的是我这个在外面提需求、却忘了同步更换裁判的人。
正确的重构顺序，和我一直在用的错误顺序
我把两种做法并排写下来，差距一目了然。
我一直在用的错误顺序：
旧系统
→ 改实现层，把新需求塞进去
→ 想办法让它继续通过旧验证
→ 堆兼容层
每一步单独看都"高效"，合起来就是在旧地基上加盖违章建筑。
应该走的顺序：
新的业务目标
→ 先重新定义"什么叫做对了"（Validator）
→ 再据此重新设计数据模型
→ 再重新设计系统架构
→ 最后才轮到重构实现层
→ 删旧逻辑，不留兼容层
关键在于顺序。Validator 必须第一个动，实现层必须最后一个动。 一旦反过来——先改代码、再回头补验证——你就又滑回了那条"新逻辑 + 旧逻辑 + 兼容层"的老路。
这件事说出来像是常识，但在 Vibe Coding 的节奏里特别容易被跳过：Agent 改代码太快了，快到你还没想清楚新 Validator 长什么样，它已经把实现层改了八版。人很容易就跟着它的节奏走，把"定义问题"这一步悄悄省略掉。
怎么判断该"微调"还是该"重构"
踩完这个坑，我给自己立了一张判断表，以后每次接到需求先过一遍，不再凭感觉动手。
可以继续微调优化的情况：
- 业务目标本身没变，只是想让它更快、更稳、更省资源；
- 当前架构能表达新需求，只是某个模块实现得不够好；
- 旧的验证标准和业务目标仍然对齐。
这种场景下，Vibe Coding 非常舒服：局部改代码 → 跑验证 → 看指标 → 继续调。Agent 擅长的就是这个。
必须停下来做底层重构的情况：
- 业务目标本身变了；
- 老流程的形状已经表达不出新需求，怎么改实现都别扭；
- 旧的验证指标跑完全绿，但业务方一句话就能戳破"这不是我要的"。
只要踩中后两条中的任何一条，就别再往实现层加代码了。这时候正确的下一步不是让 Agent 再改一版，而是坐下来，把"新业务目标到底长什么样""什么才算做对了"重新写清楚。Validator 没换之前，后面所有的优化都是在给错误的方向加速。
人在 Agent 工作流里，到底该干什么
这次复盘还有一个副产品：我想明白了人在 Vibe Coding 里真正不可替代的位置。
Agent 擅长的事情很明确——执行一个已经定义清楚的任务、改代码、跑测试、根据错误信息自我修正。这些它做得比人快、比人耐心、比人稳定。
但 Agent 不会做下面这个判断：当前这个问题，到底是——
- 一个 bug？
- 一个参数调优？
- 一个模块级别的优化？
- 还是一次业务目标层面的架构重构？
这个分类没有标准答案，它依赖对业务上下文的理解，依赖"我当初为什么要做这个系统"这种上下文，而这些东西根本不在代码里。三周前我就是在这里失守的：我把一个"需要换 Validator 的架构问题"，当成了一个"加个新功能的实现问题"丢给了 Agent，然后眼睁睁看着它把错误的答案越写越精致。
所以现在我给自己定了三条人工职责，每次启动一轮 Vibe Coding 之前都要自问：
- 业务目标从上次对齐到现在，变了没有？
- 现在的 Validator，还在衡量我真正在乎的东西吗？
- 这个需求到底是在现有边界内，还是已经需要重新画边界？
这三个问题 Agent 答不了，也不该让它答。它答了，我也不敢信。
以后打算怎么干活
把上面这些落到一张新的工作流图上，和我以前习惯的做法对比一下：
旧的、踩坑的做法：
我随口说个需求
→ Agent 执行
→ 我看一眼结果、解释一下
→ 提下一个需求，继续改
新的、打算长期用的做法：
业务需求发生变化
→ 我先停下来，重新审查验证体系还对不对
→ 判断这到底是微调还是要重构
→ 如果是重构：先更新 Validator，再更新数据模型
→ 这之后才把任务交给 Agent
→ 让 Agent 去验证"新目标"，而不是旧目标
差别就在于：把人从"解释结果"的角色，挪回到"定义问题"的位置。 Agent 跑多快不重要，重要的是它起跑前，方向是人定的。
最后
这次最大的收获，真的不是"Agent 写代码能力还有哪里不行"——相反，它比我预期的能干得多。
真正的教训是：在一个复杂系统被反复迭代的过程中，最容易出的错从来不是"代码写错了"，而是评价体系本身错了。代码写错了，测试会告诉你；Validator 错了，测试会给你发一张全绿的喜报。前者容易发现，后者最隐蔽，也最致命。
所以现在我对"重构"这件事的理解变了。重构的第一步，从来不是打开编辑器，也不是跟 Agent 说"我们来改架构吧"。
重构的第一步，是重新定义什么叫"正确"。
Validator 不和业务目标对齐之前，数据模型、计划层、执行层怎么调都是白费——你只是在一辆开往错城市的车上，把座椅和空调调得越来越舒服。
等验证层和业务目标重新对上了，后面那些 Agent 最擅长的事，才有意义。
浙公网安备 33010602011771号