怎么描述清楚需求

1. 从一个模糊需求开始

你收到的第一条需求，大概率是这样的：

帮我做一个能自动整理资料并生成方案的系统，面向准备把 AI 引入内部流程的团队，要专业一点，别太像 AI 生成的。

这句话听起来清楚，但真交给模型，你会发现它漏掉了一堆关键信息：

• 用户是决策者、技术人员、产品经理还是运营？
• 产物是内部方案、技术文档、客户材料还是决策简报？
• 资料该从官方文档、论文、内部知识库还是历史项目里找？
• 交付前要检查事实、权限、敏感表达、格式和渠道约束吗？

需求里没有写出来的部分，最后都会变成系统的责任。

所以 Agent 开发不是从 Prompt 开始，而是从需求边界开始。先把模糊需求翻译成系统能理解的条件，后面的资料、结构、生成、审稿才有据可依。

2. 先认清 Prompt 能做什么、不能做什么

很多人拿到需求，第一反应是写一个很长的 System Prompt。但 Prompt 更像一把好用的螺丝刀：拧螺丝很快，但盖房子不够。

单个 Prompt 通常能做好这些事：

1. 根据主题生成初版产物。
2. 按指定对象调整语气。
3. 把材料整理成结构。
4. 改写局部内容。
5. 生成标题、摘要和说明文案。

这些适合低风险、一次搞定、质量由人判断的场景。核心假设是：任务可以一次性说清，材料都在上下文里，结果好坏你自己看。

但复杂产品会打破这些假设。一旦要稳定交付、多人协作、可复盘质量，Prompt 只是系统里一个可调参数。应该先定义目标，再用测试样例判断 Prompt 有没有变好。

3. 从需求到产品的七道鸿沟

一条模糊需求进入产品系统，至少要跨过七道坎。

鸿沟	需求里的表现	产品里需要补上的能力
需求澄清	「专业一点」「别太像 AI」含义不清	追问目标对象、场景、目标、禁区、篇幅和格式
资料来源	用户没说哪些资料可信	资料检索、来源分级、引用记录和过期检查
任务结构	产物容易顺着模型习惯铺开	先产出可审阅结构，再限制执行在结构内
事实核查	模型可能把猜测写成事实	抽取事实声明，逐条回查来源，标记无依据内容
验收标准	「好不好」很难稳定判断	按对象、证据、结构、术语、语气和风险拆成检查项
交付约束	不同场景格式和限制不同	生成多版本产物，检查长度、摘要、链接和元数据
可观测性	用户只看到成品	记录每次检索、生成、修改、驳回和人工审阅结果

这些问题不适合靠加长 Prompt 解决。把所有规则塞进一个 System Prompt，上下文会膨胀、规则互相挤压、失败时难以定位。产品系统需要从“一次生成”转成“一组有状态的步骤”。

4. 用职责边界拆开流程

多智能体的作用，是把不同性质的判断放到不同边界里。可以先拆成七个角色：

角色	输入	输出	主要失败模式
需求澄清 Agent	原始需求	任务单、缺失问题、风险提示	追问过多，或忽略关键约束
资料 Agent	任务单、检索范围	来源卡片、摘录、可信度标签	引用来源不权威，或资料过期
规划 Agent	任务单、来源卡片	结构、论点、节点意图	结构像模板，或论点没有材料支撑
执行 Agent	结构、来源卡片、风格要求	初版产物	空泛、堆概念、引用不落地
核查 Agent	产物、来源卡片	事实声明列表、依据、问题标记	漏掉隐含事实，或把观点当事实
审稿 Agent	产物、任务单、核查结果	修改建议、风险等级、可交付判断	只做表面润色，忽略产品目标
交付 Agent	终版、场景配置	场景版本、元数据、交付检查结果	格式错误，或遗漏场景约束

重点不是角色多，而是每个 Agent 输出结构化结果。下一步读取这些结构化结果，才能把质量问题定位到具体环节。

运行流程可以表示成这样：

原始需求
  -> 需求澄清
  -> 资料检索与来源卡片
  -> 结构生成与人工确认
  -> 产物生成
  -> 事实核查
  -> 审稿与修改
  -> 交付检查
  -> 观测与评测样本沉淀

其中「人工确认」应该作为流程节点设计。结构确认、敏感内容、事实争议和最终交付，都适合让人介入。系统负责把材料和风险整理清楚，人负责在高影响决策上做判断。

5. 资料系统决定产物能不能被信任

Agent 类产品容易先把注意力放在生成效果上，资料系统反而被推迟。模型可以写得很流畅，但可信度要回到来源上检查。

RAG 在 Agent 系统里，更适合承担证据组织工作：让每个重要判断都能回到可检查的来源。

资料系统至少要保存四类信息：

1. 来源身份：官方文档、论文、内部文档、访谈、用户上传材料或普通网页。
2. 时间信息：发布时间、更新时间、抓取时间和适用版本。
3. 可引用片段：与当前任务论点相关的摘录、页码、章节或链接。
4. 使用记录：产物中哪一段使用了哪一条来源，是否被核查 Agent 标记过。

只有向量检索还不够。复杂任务经常需要精确匹配版本号、发布日期、产品名称、政策条款和引用位置。更稳妥的做法是混合检索：向量检索处理语义相近的材料，关键词和结构化字段处理精确事实，重排序和来源策略控制进入上下文的证据质量。

代价是系统更复杂，但换来的是来源选择、事实核查和交付审核都能复用同一组证据记录。

这一层也会反过来约束执行 Agent。没有来源支持的判断，可以写成待确认观点；来源不足的段落，可以进入人工补充资料；来源冲突的内容，需要在审稿阶段显式提示。

6. 审稿不是润色

很多工具把审稿简化成“改得更通顺”。对 Agent 产品来说，审稿更像一次质量门禁。

一个可交付产物，至少要检查这些问题：

1. 对象是否明确：产物是给决策者解释投入产出，还是给技术人员解释系统边界。
2. 论点是否有材料支撑：关键判断能否回到来源卡片、代码观察、数据或项目经验。
3. 结构是否能推进问题：各部分是否围绕同一个需求展开。
4. 术语是否稳定：同一个概念是否反复换名。
5. 风险是否被处理：不确定事实、过期资料、合规要求和版权约束是否被标出。
6. 场景是否匹配：不同渠道、不同对象对语气、格式和引用方式的要求不同。

因此，审稿 Agent 不应该只返回一段“优化后的产物”。它更适合返回问题列表、严重程度、建议修改位置、是否阻塞交付，以及需要人工确认的事项。

执行 Agent 根据这些结构化反馈修改产物，产品界面也能把问题直接展示给用户。审稿结果进入任务记录后，团队还能统计哪些问题频繁出现，再决定是补资料、改 Prompt，还是调整工作流。

7. 可观测性让系统可改进

用户说“这个结果不行”时，如果系统没有记录过程，团队只能猜问题来自哪里。

一个 Agent 项目至少要记录这些运行信息：

观测对象	可记录的信息	可用于回答的问题
需求澄清	追问次数、用户补充字段、跳过字段	用户最常漏填哪些约束
资料检索	查询词、命中来源、来源类型、过期状态	哪类主题最缺权威资料
结构	人工修改点、被删除节点、确认次数	模板化结构是否过多
执行	生成版本、引用使用率、产物长度	哪些部分最容易空泛
核查	事实声明数量、无依据声明、冲突来源	哪些 Agent 或主题最容易产生事实风险
审稿	问题类别、严重程度、返工次数	质量瓶颈在结构、资料还是语气
交付	场景检查结果、交付失败原因	哪些场景约束需要前移到执行阶段

持久化、Human-in-the-loop、状态记忆和调试追踪，是构建长期运行 Agent 的核心能力。每个任务都有状态、中间产物、人工介入点和可以进入评测集的失败样本。

评测可以从小集合开始。比如挑选 30 条历史需求，标注期望对象、必须引用的资料、禁用表达、事实核查规则和交付场景。每次改 Prompt、换模型、调整检索策略或拆分 Agent 后，都用这组样本跑一遍，看指标是否变好：

1. 需求字段补全率。
2. 权威来源命中率。
3. 无依据事实声明数量。
4. 审稿阻塞问题数量。
5. 人工修改比例。
6. 交付检查通过率。

这些指标不会替代人的判断，但能让团队区分：系统是否真的减少了事实、结构和交付风险，还是只是把生成速度提上去了。

8. 一个五层系统模型

把前面的拆解合在一起，Agent 产品可以分成五层。可以把需求进入系统后的旅程想象成一条流水线：

• 产品交互层：用户提交需求、补充资料、确认结构、查看审稿问题、选择交付场景。界面要让用户看见中间产物，而不是只等一个最终答案。
• 任务与工作流层：每个需求对应一个任务实例。任务保存状态、步骤、版本、人工确认点和失败原因。API 层负责鉴权、校验、任务查询和结果返回。
• Agent 编排层：需求澄清、资料、规划、执行、核查、审稿和交付 Agent 按状态机或图结构协作。每个节点有明确输入输出，失败后可以重试、跳过、回退或请求人工处理。
• 资料与证据层：保存来源卡片、向量索引、结构化元数据、引用关系和历史项目资料。检索策略同时考虑语义相关、来源可信、时间新鲜度和场景可引用性。
• 观测与评测层：记录每次运行的 trace、工具调用、人工修改、审稿问题和交付结果。稳定失败样本进入 eval 集，用来评估模型、Prompt、检索和工作流变更。

这五层共同回答同一个问题：当用户提出一个模糊需求时，系统怎样把它变成可澄清、可检索、可审阅、可核查、可交付、可复盘的生产过程。这也决定了后续实现边界：界面、API、Agent 节点、资料库和评测系统都要围绕同一份任务状态协作。

9. 总结

需求描述不是把 Prompt 写长，而是把模糊意图翻译成系统能执行、能检查、能复盘的条件。

一句话总结：清晰的需求 = 明确的目标对象 + 可信的资料来源 + 可审阅的结构 + 可检查的交付标准。