Vibe_Coding_系统重构方法论复盘有感

Vibe Coding 系统重构复盘：为什么持续优化却越来越偏离目标？

核心观点：在复杂系统的 AI
辅助开发过程中，真正决定优化方向的不是代码修改能力，而是"评价体系（Validator）是否与最终业务目标一致"。如果业务目标发生变化，而验证层没有同步重构，那么
Agent 会不断优化错误方向，最终形成新旧逻辑共存的混合系统。

---

一、背景：从快速构建到系统重构陷阱

最近使用 GPT-5.6 + 国产 Agent 进行 Vibe Coding
开发，在持续迭代项目的过程中发现一个典型问题：

最初系统可以运行，也能够实现部分业务需求；但是随着业务目标不断深化，代码修改越来越多，Token
消耗越来越高，系统复杂度不断增加，却发现最终结果距离理想业务模型越来越远。

最开始的开发模式是：

flowchart LR A[业务需求输入] --> B[数据输入层] B --> C[计划生成层] C --> D[任务执行层] D --> E[验证层 Validator] E --> F[输出结果]

这种架构在初始阶段没有问题，因为三个核心部分基本一致：

• 业务需求定义；
• 系统执行流程；
• Validator评价指标。

因此系统能够稳定运行。

但是，当业务需求发生变化时，问题开始出现。

---

二、真正的问题：把架构重构误认为功能优化

后续由于业务讨论和需求调整，发现原系统虽然完成了一定功能，但是距离理想目标存在偏差。

于是开始按照新的需求修改：

新的业务需求
↓
修改原有代码
↓
运行测试
↓
根据 Validator 调整
↓
继续修改

表面看，这是持续优化。

实际上，这个过程隐藏了一个严重问题：

新需求是在旧系统评价体系下进行优化。

也就是说，系统不断尝试：

"如何在旧规则下实现新目标"。

而不是：

"重新设计一个满足新目标的系统"。

最终产生：

flowchart TD A[新业务需求] B[旧系统架构] C[旧Validator] D[新增代码逻辑] A --> D B --> C D --> C C --> D C --> E[新旧逻辑不断兼容] E --> F[混合系统]

结果就是：

• 新逻辑无法完全发挥；
• 旧逻辑无法彻底删除；
• 系统越来越复杂；
• 每次修改都会引入新的兼容问题。

---

三、核心认知：Validator决定优化方向

在优化系统中：

评价指标决定搜索空间。

任何优化算法，本质都是在寻找：

"满足评价函数的最优解"。

因此：

如果 Validator 定义错误，即使：

• Agent能力强；
• 算法正确；
• 代码质量高；

最终也会收敛到错误方向。

例如：

旧系统认为：

满足旧流程 = 正确

那么 Agent 会不断寻找：

如何更好满足旧流程

而不是：

如何实现新的业务目标

所以很多时候，问题并不是：

"代码没有优化好"。

而是：

"评价什么叫正确，没有重新定义"。

---

四、微调优化与底层重构必须区分

这是 AI 辅助开发中最容易犯的错误。

1. 微调优化

适用于：

• 业务目标没有变化；
• 系统架构仍然正确；
• 只是性能、参数、实现细节需要调整。

流程：

flowchart LR A[现有系统] --> B[局部修改] B --> C[测试验证] C --> D[性能优化]

例如：

• 减少运行时间；
• 修复 Bug；
• 优化参数。

---

2. 底层重构

适用于：

• 业务目标变化；
• 原流程无法表达新需求；
• 原验证指标已经失效。

正确流程：

flowchart LR A[新的业务目标] --> B[重新定义正确标准] --> C[重构Validator] --> D[重新设计数据模型] --> E[重构系统架构] --> F[重新实现]

重点：

底层重构不是：

"在旧代码上增加更多功能"。

而是：

"重新定义系统应该如何工作"。

---

五、复杂系统正确重构顺序

过去容易采用：

实现层 → 修改代码 → 适配验证

但是正确顺序应该是：

flowchart TD A[业务目标] B[Validator评价体系] C[数据模型] D[系统架构] E[Planner/Generator] F[执行系统] A --> B B --> C C --> D D --> E E --> F

原因：

Validator实际上决定系统允许探索的方向。

如果Validator错误：

后面的所有优化都会被限制。

---

六、AI Agent开发中的人工职责

Agent非常擅长：

• 执行明确任务；
• 修改代码；
• 自动重构模块；
• 编写测试。

但是Agent不会主动判断：

当前问题到底属于：

类型 处理方式

---

Bug 修复代码
参数问题 调节参数
模块问题 局部重构
业务变化 重新设计架构

因此人工最重要的工作不是写代码，而是：

1. 判断业务目标是否变化；
2. 判断现有Validator是否仍然正确；
3. 判断当前任务属于优化还是重构。

---

七、未来 Vibe Coding 工作流

错误流程：

flowchart LR A[Agent执行] --> B[分析结果] --> C[继续修改] --> D[越来越复杂]

正确流程：

flowchart TD A[业务需求变化] --> B[重新分析目标] --> C[检查Validator] --> D[决定优化还是重构] --> E[更新评价体系] --> F[更新数据模型] --> G[Agent实现] --> H[验证新目标]

---

八、复杂系统重构的核心原则

原则1：先定义正确，再实现正确

不要先问：

"代码怎么改？"

应该先问：

"什么结果才算正确？"

---

原则2：Validator不是不可修改的

Validator不是法律。

它只是当前业务目标的数学表达。

当业务目标改变：

Validator必须同步变化。

---

原则3：不要让新系统适配旧评价体系

错误：

新系统
↓
适配旧Validator

正确：

新目标
↓
新Validator
↓
新系统

---

九、最终总结

这次最大的经验不是：

"Agent写代码能力不足"。

而是：

在复杂系统开发中，最危险的问题不是实现错误，而是评价体系错误。

如果业务目标已经改变，但仍然使用旧验证标准，那么所有优化都会被旧逻辑牵引。

最终结果不是系统越来越接近目标，而是：

修改越来越多
代码越来越复杂
逻辑越来越混乱
距离目标越来越远

因此：

系统重构的第一步，不是修改代码，而是重新定义什么叫正确。

只有业务目标、Validator、架构三者重新对齐，AI Agent
才能真正成为高效的工程工具，而不是不断堆叠复杂度的代码生成器。