Agent 时代的模糊需求哲学

几乎所有 AI 使用指南都会告诉你同一件事：prompt 要具体、要清晰、要把需求描述得越精确越好。

这没错。但不完整。

在 Agent 时代，有些场景下你说得模糊，反而能拿到更好的结果。这不是偷懒，这是一种刻意策略。听起来反直觉对吧？让我把这事儿掰开了说。

为什么 Agent 能处理模糊需求

关键在上下文来源的区别。

用 Chat 的时候，你的描述就是全部上下文。你不说，它不知道。所以你当然得把话说清楚，不然它只能瞎猜。

但 Agent 不一样：

Chat：你的描述 = 全部上下文
Agent：你的描述 + 项目代码 + 文件结构 + git 历史 + CLAUDE.md = 上下文

Agent 能读到你没说、但代码里已经有的约定。你的项目用什么分页库、API 返回什么格式、命名风格是驼峰还是下划线——这些它自己就能从代码里看出来。

举个例子：你跟 Agent 说 给订单列表加上分页。就这么一句，够模糊吧？但 Agent 会自己去翻项目代码，看看现有的分页是怎么做的——用的什么组件、前后端怎么配合、页码参数叫什么——然后保持一致地实现出来。

换成 Chat 模式，这句话就不够用了。它没有项目上下文，只能给你一个泛泛的分页实现，大概率和你项目的风格对不上。

所以模糊需求给了 Agent 空间去找最合适的实现方式，而不是被你限定在一条可能不是最优的路径上。

这不是说从此以后都可以含糊其辞了。关键在于判断场景。这里有一个决策框架：

左边这一列的共同特点是：Agent 有足够的信息自己做判断，而且就算判断偏了，代价也不大。右边那一列则相反——要么 Agent 没有参考，要么试错成本太高，你必须把路径说死。

再看一组具体对比，感受会更直观：

模糊但有效（项目里已有分页实现可参考）：
> 给订单列表加上分页

具体且必要（做法和现有模式不同）：
> 给订单导出加上异步处理，用 Redis 做任务队列，
  完成后通过 WebSocket 通知前端，不要用轮询

第一条之所以能模糊，是因为分页在项目里早就有成熟实现，Agent 有样板可循。第二条之所以必须具体，是因为异步处理方案有好几种，Redis + WebSocket 这个组合是你的明确选择，Agent 猜不到你想要哪种。

模糊不等于随便。有几个技巧能让模糊需求既保持灵活，又不跑偏。

第一，让 Agent 先说方案再动手。

“先分析一下有哪些实现方式，列出利弊，我选了再做”

这相当于在正式开工之前加了一个确认环节。Agent 发散探索完了给你选项，你拍板之后它再执行。自由度和控制权都有了。

第二，给方向不给路径。

"优化这个接口的性能" 比 "给这个查询加索引" 能得到更全面的方案。

前者让 Agent 自己去分析瓶颈在哪，它可能会发现问题根本不在索引上，而是 N+1 查询或者缺了缓存。后者直接把它限定在加索引这条路上，即使有更好的解法它也不会去探索。

第三，让项目配置兜底。

CLAUDE.md 写得越清楚，模糊需求的风险越低。你把编码规范、架构约定、常用命令、团队踩过的坑都写进去，Agent 即使收到一句很模糊的需求，也能在这些约定的边界内做出合理的决策。

这其实就是 Context Engineering 的思路——你影响的不只是”你说的那句话”，而是 Agent 能看到的所有信息的质量。

有一个组合你必须警惕：模糊需求 + 高风险操作 = 危险。

涉及支付、权限、数据删除这类不可逆操作的时候，绝对不能模糊着来。模糊需求给了 Agent 更大的自由度，但自由度越大，出错时的影响面也越大。

实操原则很简单：高风险场景下，务必让 Agent 先出方案、你确认后再执行。看清楚它打算怎么做，再放手让它去做。

模糊需求放大了 Agent 的自主性，你的审查责任也相应放大。这不是可选的，是必须的。

模糊不是偷懒，是对 Agent 上下文理解能力的信任。但这种信任不能裸奔——它需要基础设施来支撑（写好 CLAUDE.md、维护项目规范），也需要纪律来保障（养成 review 习惯、高风险场景先审后动）。

掌握了什么时候该放手、什么时候该收紧，你和 Agent 的协作效率会上一个台阶。

本文是 AI Agent 系列文章之一，更多内容见从会聊天到会指挥——AI Agent 改变工作方式的本质。想深入了解如何构建”让模糊需求安全”的上下文基础设施，推荐从 Prompt Engineering 到 Context Engineering。