使用 AI Agent 做开发时，还有一种很常见的问题：

需求其实还没有说清楚，Agent却已经开始改代码了。

比如只说一句：

把这个登录流程优化一下。

Agent可能马上开始：

• 重构认证逻辑；
• 调整接口返回；
• 修改状态管理；
• 新增缓存；
• 改动多个文件。

最后代码确实改了很多，但开发者一看却发现：

我说的“优化”，根本不是这个意思。

这类问题的核心不是Agent执行能力不够，而是：

它在缺少关键信息时，自动替你补齐了大量假设。

一、“模糊需求”真正缺的是什么？

例如一句：

把这里优化一下。

里面至少缺少：

• 优化什么？
• 速度还是代码结构？
• 当前真正的问题是什么？
• 哪些行为不能改变？
• 是否允许改接口？
• 是否允许调整数据库？
• 完成以后怎么判断真的更好？

如果这些信息没有定义，Agent仍然可以继续执行。

但它只能依赖：

自己的推测。

问题就在这里。

二、Agent为什么喜欢自己补齐缺失条件？

因为它的任务通常是：

尽量完成用户要求。

当信息不完整时，它会根据当前代码、常见实践和上下文推断一个“合理目标”。

例如看到重复代码，就可能认为：

用户说的优化，大概是重构。

看到接口慢，就可能认为：

应该加缓存。

这些推断不一定错。

但：

合理假设不等于真实需求。

一旦最开始的假设错了，后面的代码越多，返工成本越高。

三、开始写代码前先列“假设清单”

对于模糊任务，可以让Agent先明确：

已确认事实

例如：

• 当前接口平均响应2秒；
• 问题集中在用户查询阶段。

当前假设

例如：

• 可能是重复数据库查询导致；
• 用户所谓“优化”可能主要指性能。

需要验证

例如：

• 是否允许加缓存；
• 是否要求保持现有接口完全不变。

这样就能提前看到：

哪些东西是代码已经证明的，哪些只是Agent自己猜的。

这一步非常重要。

四、不是所有不确定信息都需要问开发者

前置验证并不等于：

每一步都停下来提问。

很多问题Agent可以自己通过项目验证。

比如：

这个接口有没有调用方？

可以搜索代码。

当前测试要求是什么？

可以读取测试文件。

哪个查询最慢？

可以查看日志或执行性能分析。

是否存在现有缓存机制？

可以检查项目结构。

所以更好的流程不是：

不知道 → 立即问人

而是：

不知道 → 先从代码和环境找证据 → 找不到再确认。

这样不会让Agent工作流变得过于碎片化。

五、真正危险的是“关键假设未经验证”

有些假设一旦错了，会直接改变整个方案。

例如：

• 认为可以修改公开API；
• 认为旧客户端已经不用了；
• 认为数据库Schema可以调整；
• 认为性能比兼容性更重要；
• 认为这个模块只有当前页面调用。

这类假设应该在真正执行大规模修改前确认。

因为它们属于：

高影响假设。

不是所有假设风险都一样。

六、先给出执行计划，再真正修改

复杂任务可以先让Agent输出：

目标理解：
解决登录过程响应慢的问题。

根因假设：
可能存在重复查询。

预计修改：
auth.service.ts、user.repository.ts。

验证方式：
对比修改前后查询次数和响应时间。

不主动修改：
公开API、数据库Schema、认证协议。

这样开发者一眼就能判断：

方向有没有理解错。

如果执行计划已经偏了，现在纠正成本非常低。

总比改完十几个文件后再推倒重来要好。

七、“前置验证”最重要的是证明问题真的存在

例如用户说：

这个接口太慢了，帮我优化。

Agent不应该直接开始加缓存。

更稳的方式是先确认：

• 真的慢吗？
• 慢在哪里？
• 数据库查询占多少时间？
• 是否是第三方接口拖慢？
• 有没有重复调用？
• 问题是否能够稳定复现？

如果根因其实是外部服务超时，给数据库加缓存可能完全没有意义。

所以好的执行计划应该建立在：

已经验证的问题

而不是：

看起来可能的问题。

八、什么情况下应该停止直接执行？

如果出现下面这些情况，Agent更适合先停下来确认：

• 需求存在多个完全不同的理解；
• 不同方案会影响公开接口；
• 需要删除数据或修改Schema；
• 修改范围明显超过预期；
• 用户目标和技术目标无法对应；
• 没有办法验证“完成”意味着什么。

这时候继续写代码并不是高效率。

反而是在：

用更多代码放大不确定性。

九、可以直接给Agent增加这套前置流程

以后遇到模糊需求，可以直接要求：

开始修改前先不要写代码。

请先列出：

1. 你对当前需求的理解；
2. 已经从代码中确认的事实；
3. 当前仍然存在的关键假设；
4. 哪些假设可以通过代码、测试或日志自行验证；
5. 预计修改范围；
6. 完成条件。

先验证高影响假设，再给出执行计划。只有方向和边界明确以后，再开始修改代码。

这样Agent就不会把：

“我猜用户应该是这个意思”

直接变成大量代码。

最后

AI Agent拿到模糊需求后直接开始写代码，本质上不是它行动太快。

而是：

工作流缺少“执行前确认方向”的阶段。

更稳的流程应该是：

理解需求 → 区分事实和假设 → 验证关键假设 → 给出执行计划 → 明确完成条件 → 再开始修改。

Agent真正强大以后，最重要的能力不只是：

接到任务以后马上动手。

还包括：

知道哪些事情已经确定，哪些只是推测，以及什么时候应该先验证再行动。

因为一个错误假设如果只停留在计划里，修改成本很低。

一旦变成几十个文件的代码，纠正成本就完全不同了。

---

持续更新 Codex、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。