某消费品牌的客服项目，需求文档只有一页纸，核心一句：「希望用 AI 智能客服降低人工成本。」八周后系统上线，业务方却拒绝接手——因为没人能回答三个问题：现在人工的响应速度和一次解决率是多少？上线后应该好到什么程度才算成功？哪些问题是 AI 不该碰的？
项目最后不是失败在技术上，而是失败在无法证明价值。技术侧的指标全都达标，但业务方拿不出对比数据，财务不批下一年预算。
需求书写得粗，代价不会立刻出现，它会在选型、开发和验收三个阶段分别收一次费。我们总结的写法是六节结构。
六节结构：每一节回答一个问题
| 章节 | 必须回答的问题 | 缺失的后果 |
|---|---|---|
| 业务现状与基线 | 现在这件事由谁做、做多少、做得怎样 | 上线后无法证明效果，续投没有依据 |
| 目标与验收口径 | 多久之后、哪个指标、提升到多少 | 验收变成主观争论，双方各说各话 |
| 场景边界 | 做什么，明确不做什么 | 范围持续膨胀，工期与预算失控 |
| 数据与系统条件 | 知识来源、接口、权限现状与缺口 | 开发中期才发现拿不到数据，整体延期 |
| 运行方式 | 人工介入点、SLA、责任人与迭代机制 | 上线即无人维护，三个月后名存实亡 |
| 约束条件 | 合规、预算、时间、数据是否可出域 | 方案做到一半被合规或采购否决 |
第一节最常被跳过：没有基线，就没有成功
基线数据的作用不是好看，而是让「效果」这个词有可核对的定义。客服类项目我们只要求四项，缺一项都要在立项前补齐：
- 日均咨询量：按渠道拆分，并区分工作日与促销期峰值，否则容量设计会失真。
- 人工平均响应时长：取中位数而不是平均值，长尾会话会把平均值拉高到失真。
- 一次解决率：同一问题在 24 小时内是否被重复提起，这是最接近用户真实感受的指标。
- 转人工率：机器人拦截后仍流向人工的比例，直接决定人力节省的量级。
场景边界：用「不做什么」把范围钉死
写「覆盖售前咨询与售后服务」这类句子时，双方理解差距极大。边界要用否定句写清楚，越具体越有效。例如同一个客服场景，我们通常建议客户明确写下：不处理退款争议与赔付承诺、不修改订单与价格、不回答涉及医疗功效的问题、遇到投诉升级立即转人工并记录。
这四条否定句带来的价值是双向的：供应商能准确估算工作量，业务方也能在上线后判断某个错误是不是系统本该避免的。范围失控的项目，往往不是因为做得太少，而是因为一开始没说清哪些不做。
四个常见漏洞
漏洞一：把需求写成了方案。「要用某大模型 + 向量数据库 + 微服务架构」这类表述，等于在还没评估问题之前就锁定了答案。判断标准很简单：把需求书交给两家供应商，如果他们给出的范围与报价差异超过两成，说明写的是目标而不是需求。
漏洞二：把目标写成了口号。「显著提升客户满意度」无法验收。可核对的句式是：上线 90 天内，商品咨询类会话的自助解决率从 42% 提升到 65%，人工介入时长下降三成。数字可以估算，但必须有。
漏洞三：把数据条件写成一句「已有 ERP」。接口存在不等于可用。要写清楚：字段范围、权限模型、测试环境、调用限制、历史数据质量。我们遇到的项目里，真正拖期的多半是「接口有，但没有测试环境」和「数据有，但一半字段是空的」。
漏洞四：忽略运行期的人力。需求书只写了建设，没写上线后谁维护知识库、谁复核低置信度样本、谁处理误判投诉。没有运行责任人的项目，通常在三个月内悄悄停摆，然后在年中复盘时被重新立项一次。
立项评审检查表
| 检查项 | 通过标准 |
|---|---|
| 基线数据 | 四项指标齐全，并注明统计口径与取数来源 |
| 目标可核对 | 有时间期限、有指标名称、有当前值与目标值 |
| 边界明确 | 至少写出三条「不做」，且业务方确认 |
| 数据条件 | 逐条列出来源、权限、测试环境与已知缺口 |
| 接口现状 | 需要对接的系统已列清单，标注读写能力与限制 |
| 运行责任人 | 指定知识库维护、样本复核、投诉处理的责任岗位 |
| 约束前置 | 合规、预算、时间、数据出域要求写在正文而非附件 |
| 验收方式 | 评测集来源与判定标准已约定，不由供应商单方提供 |
常见问题
问：需求书写多细才算合适？
一个可操作的判断标准：把需求书交给两家供应商，看他们给出的方案范围与报价差异是否落在两成以内。差异过大，说明你写的还是目标而不是需求。合适的粒度是六节都写实——业务问题、量化目标、场景边界、数据与系统条件、运行方式、约束，然后把技术路线的选择权留给供应商。
问：没有历史基线数据怎么办？
先花两到四周做基线采集再立项，通常比直接开工更省时间。如果系统里确实取不到，可以抽样统计：每天随机抽取一定数量会话，由业务骨干判定是否真正解决，形成近似基线，并在需求书里注明这是抽样估计值。关键是让数字有出处、有口径，而不是留空。
问：需求书里要不要指定模型或厂商？
一般不建议。需求书应该写约束而不是写方案：数据能否出域、可接受时延、单次任务成本上限、必须对接哪些系统。指定具体模型会把评估范围提前锁死，而模型能力半年内会变化多次。确有技术偏好时，写进附件并说明理由，不要写成正文的强制条款。
最后一句经验：需求书里最贵的一页，是写基线数据那一页。它看起来只是记录现状，实际决定了后面所有环节能不能被判断——包括供应商的方案是否靠谱，以及项目上线后到底该不该继续投钱。
本文案例来自天辰平台需求评估与交付项目，已做脱敏与归一化处理。