用 Agent 改 Vue 项目，怎么避免越改越像另一个项目？

让 Agent 写一个 Vue 页面，要求说清楚，往往很快就能看到样子。

但把任务换成“在现有项目里加一个功能”，事情就没那么简单了。页面有了，却绕过了项目的请求封装；弹窗能打开，样式和其他地方不一样；表格也做了，但项目里原本就有一套。

单独看这份代码，可能没什么大问题。放回项目里，你还是得花时间把它改成大家熟悉的样子。

我更关心的是这段时间：Agent 帮我们写得快，接回来以后，能不能也少整理一点？

先给它找个“邻居”

接手现有 Vue 项目时，我倾向于先让 Agent 看一个最接近当前需求的页面。

有筛选和分页，就找现成的列表页；需要表单和校验，就找正在使用的编辑页。它们比一句“遵循项目规范”具体得多。

让它沿着这个页面往下看：引用了哪些组件，接口从哪里调用，状态放在哪里，路由是怎样接进来的。顺手确认项目的 Vue 版本、主要写法，以及本次涉及目录的实际约定。

这一步并不是要求整个仓库只有一种写法。老项目里有不同年代的代码很正常，关键是找到这次修改真正应该参考的部分。

我会把任务的开头写成这样：

先在项目里找一个与本次需求接近的页面，读它引用的组件和接口方法。说明哪些地方可以复用，再开始修改。如果现有实现和需求有冲突，把冲突说清楚。

只看目标文件，很容易把任务当成一道独立的代码题。看过它的“邻居”，才知道新功能应该放进什么位置。

最容易多写的，是项目里已经有的东西

我会重点看 Agent 有没有重新造三样东西：公共组件、请求方法和共享状态。

比如，项目已经封装了请求客户端，在里面统一处理登录信息和错误提示。Agent 却在新页面里直接发请求。接口也许调通了，但登录失效怎么办、错误提示由谁弹，就可能和其他页面走了两套逻辑。

所以“复用请求封装”还不够，最好让它找到实际导出的方法，看看参数和返回值。不要凭空假设所有接口都是 res.data.list，再围绕这个猜测补一堆字段。

组件也一样。已有的表格究竟接收哪些 props、发出什么事件，要看定义和现有调用方。名字叫 DataTable，并不能说明它一定支持某个分页参数。

这里还有一个很具体的 Vue 细节：组件事件不会自动冒泡。 如果 Agent 在两层组件之间新加了一层包装，原来直接监听子组件事件的父组件，可能就收不到通知了，需要明确转发。Vue 的组件事件文档对这一点有说明。

这类问题靠看静态页面很难发现。按钮还在，点击之后的数据却不更新了。

至于状态放在哪里，也不必一上来就新建全局 store。先判断它只属于当前组件、需要父子组件协调，还是多个页面共同使用，再沿用项目现有的方式。

多写一份实现，眼前看着省事，后面就多一处需要一起维护的地方。

需求里补上“怎么才算改好了”

“加一个筛选功能”描述了要做什么，却留下了不少行为细节。

条件变化以后立即查询，还是点按钮再查？换了条件，页码是否回到第一页？没有结果、请求失败、正在加载，页面分别显示什么？从详情页回来，之前的条件还要不要保留？

这些没有统一答案，要跟着产品要求和现有页面走。没有说清楚，Agent 就只能替你选一个。

不用为每次小改动写很长的文档。把容易误解的几项提前补上就有用：

本次只增加筛选能力，沿用现有表格和请求方法。
修改条件时不立即查询；点击查询后，从第一页加载结果。
加载中、空结果、请求失败的表现，参考项目中已有的列表页。
改完后实际检查筛选和翻页；如果接口条件不具备，说明哪些结果还没验证。

这只是一个写法示例。改表单、补路由、调整组件交互，都可以用同样的方法，把“用户做什么，页面应该发生什么”讲清楚。

第一次交付的范围也可以小一点：先把一条操作流程接通，确认复用方式合适，再补剩余分支。尤其涉及公共组件时，先看一轮文件差异，比最后面对一大包改动更容易判断。

多轮修改时，把模型连接和项目代码分开看

读组件、查调用方、改代码、看检查结果，Agent 往往要来回工作好几轮。除了任务是否清楚，模型调用能否顺畅继续，也会影响使用体验。

如果你用的编程 Agent 支持自定义模型服务，服务地址、API Key 和模型名称应该配置在编程工具这一侧。Agent 通过它分析和修改 Vue 项目，Vue 页面本身不需要增加调用模型的代码，模型密钥也不该写进前端。

模型请求报错时，先确认失败发生在哪里。组件已经改好了，只是下一轮分析没收到响应，就不必让它为了这个错误继续修改页面代码。

这类连续调用，也可以利用模型服务提供的自动选路能力。拿我们 XylemNode 的 Auto 分组来说，它会根据通道健康状态选择调用路径，通道异常时支持跨组重试，调用方仍使用原来的模型名称。这里的通道，可以理解为处理模型请求的一条路径。

它能把服务侧的选路和重试接过去，减少需要人手动切换连接的情况。至于已经修改了哪些文件、哪个命令执行到一半，仍然要看 Agent 的工具记录和项目状态；模型请求重试，不等于把整个开发任务重新做一遍。

最后按用户的操作走一遍

代码改完以后，我会先看改动有没有偏离原来的范围。只加了一处筛选，却多出一套请求工具、改了几个公共组件，值得追问一下原因。

然后执行项目已有的相关检查。类型检查、构建和测试各自能发现一部分问题，但构建成功并不能证明页面交互符合要求。

回到浏览器里，把这次涉及的操作走一遍：点查询、翻页、修改条件，再看看空结果和失败状态。动过公共组件，还要看原来的调用页面是否受到影响。

Vue 的测试指南也建议围绕组件的输入、输出和用户交互验证行为。项目已有测试时，可以让 Agent 补上这次真正变化的行为；暂时没有，就先留下具体的手动检查结果，别把“代码看起来没问题”写成“已经验证”。

如果 Agent 没有浏览器操作能力，就让它把待检查的页面和步骤列出来，由人完成这部分。

我希望 Agent 交回来的结果是：功能已经接进原来的项目，相关操作检查过，没确认的地方也说得明白。下次再改这个页面，无论交给同事还是另一个 Agent，都能顺着现有代码继续做。

这样省下来的，才不只是第一轮写代码的时间。

作者：XylemNode 团队。

本作品采用《CC 协议》，转载必须注明作者和本文链接