30 秒判断：需求定义不是列功能清单，而是一套四步方法——① 写一句话产品定义；② 从定义正推问题空间；③ 划边界；④ 补质量属性。一句话概括：先把"用户要什么、做到什么程度算好"写死，再谈怎么建。反过来做，产品就会变成"技术上能做什么，产品就做什么"。
适合谁读：正在做 AI 产品／Agent、准备开工或已经开工但说不清"验收标准"的人；习惯从技术选型入手、回头发现需求是凑出来的团队；以及想把需求这一步做扎实的产品经理和工程师。
本文怎么读：每一个步骤都是同一个结构——先讲方法，再用一个真实实例演示。实例是"用户上传文档、基于文档＋模型知识回答学习问题"的 Agent。标着「实例｜」的段落可以跳过，不影响读方法；把产品换成你的，四步不变。
前置阅读：本文是《Agent 开发为什么要测试驱动升级版》的续篇。那篇讲了这套方法的五步流程，前两步就是产品定义与需求／问题空间；本文把那两步展开成可操作的四步。
结构速览：§0 四步一页；§1 为什么必须正推；§2 四步总览；§3–§6 逐步演示（方法＋实例）；§7 常见误用；§8 一页速查。
证据标记：✅ 实测＝有可复现实验数据支撑；🤔 推断＝由实测或机制推出的判断。没标的多为框架性表述。
先交代三个名词
- 问题空间：用户会提出哪些类型的问题或任务。它只谈问题域，不谈怎么解决。
- 取材范围：这一类问题的答案该去哪个范围取材——点名的某一篇？多篇之间？整批文档？还是"文档 ＋ 模型内置知识"？
- 质量属性：系统"做到什么程度"才算好（正确、完整、一致、快……）。它不在任何一条功能里，却基本决定了架构的形状。
0. 四步，一页
| 步骤 | 产出什么 | 怎么算这一步做对了 |
|---|---|---|
| ① 一句话产品定义 | 一句话定义 ＋ 一张"做／不做"表 | 删掉定义里任意一个词，产品形态会变 |
| ② 问题空间 | 问题类型清单，每类带取材范围 | 能覆盖用户真实会提的问题与任务；类型之间不重叠、不遗漏 |
| ③ 边界 | 承诺范围、明确不做、看似不做但实际要做的情形 | 任何一个新需求进来，你能一句话说出它在不在范围内 |
| ④ 质量属性 | 可度量项 ＋ 零违反的红线 | 每条质量属性都能回答"怎么算达标" |
顺序不能倒：先定义问题，再定验收，最后才谈架构。
1. 为什么必须"正推"
1.1 反推的代价
大多数 AI 产品的需求，是从已有实现反推出来的：手里有一套检索、有一个图谱、接了几个工具，于是需求就写成"支持知识图谱检索""支持工具调用"——这是技术本位主义：先定技术方案，再找它适用的产品问题。
它的问题不在于技术选错，而在于用"实现容易"当需求理由。真正要回答的那句"用户到底要什么、做到什么程度算做好了"，始终空着。
正推是反过来：从产品定义出发，推出"这类用户的目标该拆成哪些问题类型"，再问"每一类要做到什么程度"。
1.2 正推比反推多出什么
| 反推 | 正推 | |
|---|---|---|
| 起点 | 手里已有的实现与技术 | 一句话产品定义 |
| 产出 | 功能清单（支持检索、支持工具调用……） | 问题类型清单，每类带取材范围 |
| 什么时候发现漏了 | 用户问上来答不出，或者上线后才暴露 | 列类型的时候就看见"这一类没人管" |
| "什么算好"由谁定 | 没人定，事后凭感觉 | 每一步都有产出物和检验标准 |
| 典型结局 | 技术上能做什么，产品就做什么 | 缺什么，一眼看得见 |
一句话：反推的失败是滞后的——要等用户用脚投票；正推的失败是提前的——在纸上就能看出来。
2. 四步总览：为什么是这四个
| 步骤 | 它回答的问题 | 这步做歪了，后面会怎样 |
|---|---|---|
| ① 一句话定义 | 我们到底在做什么、不做什么 | 需求无限膨胀；任何人塞一个功能都"不算越界" |
| ② 问题空间 | 用户的目标要拆成哪些步骤 | 用例只能按实现凑，失败模式永远漏一片 |
| ③ 边界 | 哪些做、哪些不做、哪些看似不做却实际要做 | 把"不做"误当"不接"，或者把"实际要做"误当"要做到完美" |
| ④ 质量属性 | 每一类要"好到什么程度" | 没有验收标准；评测只能凭感觉 |
这四步是层层锁定的关系：定义锁定问题空间，问题空间锁定用例类型，边界决定合格线画在哪，质量属性决定怎么量。少一步，后面的结论就没有根。
3. 第 1 步：写一句话产品定义
3.1 方法
句式：
允许【谁】添加【什么】，然后基于【什么 ＋ 什么】，提供【什么能力】。
这句话的每一段都不是修辞，而是在锁定一个结构。判断标准很简单：把定义里任意一个词删掉，如果产品形态不变，那个词就是形容词，不是定义。
与这句话配套的还有一张做／不做表。"不做"那一栏比"做"那一栏更值钱——它决定了这个产品不会变成什么样子；没有它，任何需求都能被加进来。
一句话定义其实要干三件事：划定范围（做什么、不做什么）、决定问题怎么分（§4）、决定什么算答得好（§6）。多数人只做了第一件。
第三件最容易被漏掉。同一个问题，查资料的人要一个"是／否 ＋ 位置"，学习的人要"它是什么、为什么这么说"。 "好"的标准是从定义里长出来的，它最后会变成一条条可验收的质量属性（§6）。
3.2 我们的定义
实例｜一个文档学习问答 Agent
一句话：允许以学习为目的的用户添加各种文档，然后基于这些文档以及大模型内化的知识，提供学习方面的知识问答能力。
| 定义里的要素 | 它锁定了什么 |
|---|---|
| 以学习为目的的用户 | 问题范围被限死（不会出现办事、执行类问题）；也决定了该怎么分：问题自然应当沿"理解、判断、成体系、辨来源"展开；还决定了什么是答得好：不是信息齐全就行，而是要能理解、有解释与连接、覆盖成体系、判断带依据、来源分得清 |
| 添加各种文档 | 语料是用户自带的、多份的、形态各异的——不是我们准备的固定集合 |
| 基于这些文档以及大模型内化的知识 | 两个知识来源并列：文档内 / 模型内置 / 两者（这句话本身送来了一把现成的刀） |
| 知识问答（且不做学习指导） | 只出答案：不执行操作、不规划学习路径 |
| 内容 | |
|---|---|
| 做 | ① 接受用户自带的文档（多份、各种形态）；② 基于「用户文档 ＋ 模型内置知识」回答学习类知识问题；③ 允许用模型内置知识补全——但不得把模型补充说成文档内容 |
| 不做 | ① 不做学习方向／规划指导；② 不做操作执行（不写代码、不改文件）；③ 不做导航／办事类（不是搜索引擎，也不是任务代理） |
4. 第 2 步：从定义正推问题空间
4.1 方法
先别问"我们要支持哪些功能"，也别拿"另一类用户"来对比。参照物怎么选都是任意的：跟查数据的人比、跟做研究的人比、跟开发者比，比出来的清单各不相同，而且你还得先解释"为什么选它当参照"——这一步本身就没有依据。
正确做法是从用户目标出发，把它拆开：要达成这个目标，用户得依次完成哪些步骤？ 每一个步骤，就是一组问题；每组再落成具体问法。
产出物是一张问题类型清单，每一行至少包含三样：
- 类型名——用户在用哪种方式问；
- 示例问句——三句左右，尽量在"单篇／跨篇、事实／机制、直接问／情境问"上拉开；
- 取材范围——这一类该去哪个范围取材。
三条纪律：
- 步骤是拆出来的，不是比出来的。目标定了，步骤清单就能推出来。
- 组是步骤，类型是问法。组名要能回答"用户在做什么"，类型名要能回答"他在怎么问"。
- 取材范围比类型名更重要。类型名只说用户要什么，取材范围才说"该去哪个范围取材"——而范围直接决定了后面架构要不要"跨源"和"枚举"这两种能力。
4.2 15 类问题
实例｜一个文档学习问答 Agent
目标：学会一批材料。把它拆成步骤：
| 步骤 | 落成哪组问题 |
|---|---|
| 先定位一个点：有没有、是什么、在哪 | A 取一个点（1–3） |
| 再把它弄懂：为什么、怎么做、和谁有关 | B 求理解（4–6） |
| 把面铺开：有哪些、整体是什么、有没有冲突 | C 求全貌（7–9） |
| 形成判断：这个说法对吗、两个说法冲突时该听谁的 | D 求判断（10–11） |
| 补齐缺口：这里没讲的是什么、除此之外还有什么 | E 求补充（12–13） |
| 分清来源与形态：是文档说的还是你补的、换个形态重排 | F 求归属与形态（14–15） |
每个步骤再落成具体问法，并标注取材范围：
| 组 | # | 类型 | 答案的取材范围 |
|---|---|---|---|
| A 取一个点 | 1 | 有没有 | 用户上传的这批文档 |
| 2 | 是什么（取值／定义） | 被指名的某一篇 | |
| 3 | 在哪（出处） | 具体某篇的某一段 | |
| B 求理解 | 4 | 为什么 | 某一篇（可能需另一篇或常识补全） |
| 5 | 怎么做／怎么发生 | 某一篇的过程描述 | |
| 6 | 什么关系 | 一篇内的多个对象，也可能跨篇 | |
| C 求全貌 | 7 | 有哪些（要全） | 范围由提问限定（一篇或整批） |
| 8 | 整体是什么 | 多篇 | |
| 9 | 有没有冲突 | 多篇之间 | |
| D 求判断 | 10 | 对吗 | 某篇的观点（判断依据来自该篇） |
| 11 | 哪个对 | 多篇，或文档与模型内置知识 | |
| E 求补充 | 12 | 该处没讲的 | 该处未展开 ⇒ 从其它文档或模型知识补 |
| 13 | 还有什么 | 全部知识库文档 ∪ 模型内置知识 | |
| F 求归属与形态 | 14 | 是文档说的还是你补的 | 文档 vs 模型内置知识（要能准确归属） |
| 15 | 换个形态 | 指定范围（通常一篇或几篇） |
4.3 这一步的一条经验：题面默认指代明确
实例｜一次实测
✅ 实测：我们把一句口语模糊的题面——"我最近看了两篇讲 agent 实践的文章，一篇是 OpenAI 的、一篇是 Anthropic 的……能帮我横向捋一捋吗？"——丢进一个有四篇同类文档的库里跑，三套实现全部选错了文档对（都挑了另外两篇）。
错在对象，不在质量：它们是在照着另外两篇做对比，八个核心主题一个都没覆盖到；而且错得很隐蔽——答案本身可以很流畅。
所以口径是：示例问句默认指代明确（点篇名或作者），模糊只留给刻意设计的消歧题。
5. 第 3 步：划边界
5.1 方法
边界有三类，分开写，不要混：
| 类别 | 写法 | 容易犯的错 |
|---|---|---|
| 承诺范围 | 输入／输出／能力边界／形态／使用边界，逐项写清 | 只写"能做什么"，不写"范围到哪为止" |
| 明确不做 | 不做什么 ＋ 为什么不做 | 只写"不做"，不写理由，下次讨论又会被翻出来 |
| 看似不做、实际要做 | 做哪一部分 ＋ 合格线画在哪 | 把"不该由产品拍板的部分"误当成"整个请求都不接" |
第三类最容易被误判：它不属于"不做"，而是"做，但合格线画在别处"。判断方法很简单——把请求拆开，看哪一部分是产品能负责的：能负责的那部分要做，合格线就画在那上面；剩下不能负责的，明说，别硬编。
5.2 我们的边界
实例｜一个文档学习问答 Agent
① 承诺范围
| 维度 | 承诺 |
|---|---|
| 输入 | 用户以学习为目的添加的各种文档（多份、形态不限）；它与模型内置知识共同构成"可回答的范围" |
| 输出 | 知识问答：回答问题、给出依据；用户问起时区分来源 |
| 知识边界 | 答案可来自 ①用户文档 ②模型内置知识 ③两者；来源可分辨 |
| 形态 | 当前版本单轮问答（一问一答），后续再升级为多轮对话问答 |
| 使用边界 | 单用户 ＋ 单知识库 |
| 产品能力 | 查证入口：对某个说法有疑义时，可一键检索相关段落 |
② 来源口径（三句话才完整） ：不要求每条答案逐句标注来源；用户问起时必须能准确归属；自称来自文档的必须真能找到（红线）。只写第一句会变成"反正不用标"；只写第三句又会逼着句句带引注。来源分明是能力，不是格式要求。
③ 明确不做：学习方向／规划指导（那是学习安排，不是知识问答）；多用户与多知识库；操作执行与导航办事类。每条都附了产品理由，理由本身也是边界的一部分。
④ 照答但合格线不同：
| 类型 | 照答什么 | 合格线画在哪 |
|---|---|---|
| "两个说法冲突，该听谁的" | 两方各自怎么说 ＋ 各自的依据 | 不判"选了哪边" ；判"分歧是否被正确指出、双方依据是否准确" |
| "帮我整理成一张表" | 内容本身（按前面各类的方式正确给出） | 判"内容的重述是否忠实、完整、正确"；不判工件形态（排版、清单完备度留待后续） |
配套还有两处容易误读的边界： "这个说法对吗"留在范围内——它问的是"按某篇的观点，这个说法成立吗"，属知识核对，不是替用户裁决； "有哪些"与"换个形态"要分开——前者的清单是答案的自然形态，后者的"工件形态"不在本版验收范围内。
6. 第 4 步：补质量属性
6.1 方法
功能定义"做什么"，质量属性定义"做到什么程度" 。而它通常一条都不会出现在功能清单里——这就是它最容易被漏掉的原因。质量属性也不是凭空列出来的——它来自定义里那句"什么算答得好"（§3）。
每条质量属性都要给一个性质，二选一：
- 可度量：给出指标与目标（可以分档）；
- 红线：零违反——出现过一次就不合格，不能用"总体平均不错"盖过去。
还有一条必须写进产品承诺的限制：排除性验不全。原因不是工具不行，而是错误空间是开放的——"排除了所有错误"这件事本身无法验证。所以承诺里要明说"未知类型会漏" ，不能暗示"内容一定正确"。
6.2 我们的 8 条与 4 条红线
实例｜一个文档学习问答 Agent
| # | 质量属性 | 用户视角的含义 | 性质 |
|---|---|---|---|
| Q1 | 正确性 | 讲的东西是对的（与材料／事实一致） | 可度量（覆盖性）＋ 见下 |
| Q2 | 可信性（可核对） | 关键说法能回查到出处 | 能力 ＋ 红线 |
| Q3 | 完整性（覆盖） | 该说的说到；说不全要讲清漏了什么 | 可度量 ＋ 红线 |
| Q4 | 诚实性（不编造） | 不知道就说不知道；不把模型补充说成文档内容 | 红线 |
| Q5 | 一致性（稳定） | 同一个问题问几次，答案不该翻来覆去 | 可度量 |
| Q6 | 表达合适 | 讲得清楚，形态贴合问法 | 可度量 |
| Q7 | 边界合规 | 越界请求按任务类型处理 | 红线 |
| Q8 | 响应速度 | 等太久就不好用 | 可度量 |
四条红线：引用无伪证（凡给出引用承诺，来源必须真实存在、归属正确、内容吻合）、来源可回锚（自称来自文档的必须真能找到）、遗漏透明（要全的题没列全，必须具名说清漏了哪类）、边界合规（越界请求按任务类型处理）。
Q1 要拆成两半看：覆盖性（该有的都有）可以逐点核对，因为要点清单有界；排除性（不该有的不能有）只能按"已知错误类型清单"验，不追求全。所以产品承诺写的是"未知类型会漏"，而不是"内容一定正确"。
6.3 这一步的一条经验
实例｜这份清单只覆盖了一半
上面 8 条只覆盖"内容与体验"。成本、安全、隐私、可靠性降级、可观测性、可维护、可复现——这些一条都没写。它们不是不重要，而是不属于需求文档：它们是架构设计阶段要补的另一半清单。
这一步别急着补完，先把"知道还有一半"写下来，比假装清单已经全了要安全。
7. 常见误用
| 误用 | 出在哪一步 | 问题出在哪 |
|---|---|---|
| 从技术反推需求 | ① 定义 | 反推出来的是"技术做得到的"问题；需求变成实现清单 |
| 定义写成功能清单 | ① 定义 | 说不出用户目标要拆成哪些步骤，后面所有架构与评测都没有依据 |
| 拿"用户目的"当分类标签 | ② 问题空间 | 目的是拆解的起点，不是分类的标签——所有用户都是来学的，拿它当标签切出来只有一个桶 |
| 类型清单没有取材范围 | ② 问题空间 | 只知道用户要什么，不知道该去哪个范围取材 |
| 承诺越界 | ③ 边界 | 把不属于能力范围的事写进来，等于要求产品对不该负责的事有主张 |
| 把"不做"理解成"不接" | ③ 边界 | 有些请求恰恰要接，只是合格线画在"产品能负责的那一部分"上，而不是画在整条请求上 |
| 质量属性只写"正确" | ④ 质量属性 | 覆盖、一致、边界、速度全空着；到评测时才发现没有验收标准 |
| 暗示"内容一定正确" | ④ 质量属性 | 排除性本质验不全；不写这个限制，就是在给一个无法兑现的承诺 |
8. 一页速查
四步：一句话定义 → 问题空间 → 边界 → 质量属性。顺序不能倒。
一句话定义：允许【谁】添加【什么】，基于【什么 ＋ 什么】，提供【什么能力】；配一张做／不做表。检验法：删掉一个词，产品形态会不会变。
问题空间：不是问"支持哪些功能"，也不是拿另一类用户当参照；而是把用户目标拆成步骤，每个步骤落成一组问题，再标注取材范围。
边界：承诺范围 / 明确不做 / 看似不做、实际要做。第三类最容易被误判成"不做"。
质量属性：每条给"可度量"或"红线（零违反）"；并且明说排除性验不全。成本、安全这些不在需求文档里，属于架构阶段。
一句话：先把"用户要什么、做到什么程度算好"写死，再谈怎么建。
