夜雨聆风方法论
技术需求书模板v2.0：经过20个项目验证的7个必填字段
7个字段写全，对接成功率超过70%——缺一个，链子就断了
上一篇"一份技术需求书，三方写出了三个版本"发出后，好几个人问我：那到底该怎么写？
我说别急，我给你一个模板。
过去三年，我经手了20个技术对接项目——有成的有散的。成的项目，需求书都有一个共同特征：7个字段写全了。散的项目，缺的不是一两个字段，是根本不知道还有这些字段要填。
今天把模板交出来。每个字段附一个"错误写法 vs 正确写法"对照，供大家参考。
字段一：业务场景描述
注意，是"业务场景"，不是"技术需求"。
90%的技术需求书开头就写错了——上来就写"需要一种XX技术，具备XX功能"。这是技术需求，不是业务场景。
业务场景回答的问题是：你在什么业务中，遇到了什么问题，这个问题不解决会怎样？
技术需求书不是给技术人员看的——至少第一段不是。第一段是给决策者看的，让他判断"这事跟我有没有关系"。决策者不懂技术细节，但他懂业务痛点。你用业务语言描述，他三秒钟就知道这个需求跟自己有没有关系。
❌ 错误写法
需要一种基于深度学习的表面缺陷检测技术，能够识别金属表面的划痕、凹坑、裂纹等缺陷类型，检测精度达到99%以上。
✅ 正确写法
我们是一家线缆制造企业，年产各类线缆12万吨。当前铜杆拉丝工序的表面质量全靠人工目检，一条线3个检验员三班倒，每年人工成本约80万。但人工目检的漏检率在8%左右——每个月因此产生的退货损失约15万。我们需要一种能替代人工目检的自动化检测方案。
为什么正确写法好？因为它说了三件事：你是谁、问题有多大、不解决每年亏多少钱。决策者看完第一段就知道这个需求值不值得接。
字段二：现有方案及痛点
这个字段解决一个信任问题：你不是第一次想解决这个问题。
很多人在需求书里直接写"我们需要XX技术"，好像这个问题是突然冒出来的。但评审专家或技术供方看到这种描述会想：你之前没试过别的方法？还是试了但没成？如果没试过，你确定你真的需要？如果试了没成，为什么没成？
现有方案及痛点就是回答这些问题。关键要求：量化。
"效率低"不是痛点。"每条线3个人三班倒，年成本80万，漏检率8%"是痛点。
❌ 错误写法
目前采用人工检测，效率低、成本高、准确率不稳定。
✅ 正确写法
现有方案：人工目检。3人/线/班次，三班倒，年人工成本约80万/线。实测漏检率8%（2025年Q4连续30天抽检数据），误判率12%。主要痛点：1）夜间疲劳导致漏检率升高至15%；2）培训周期长达3个月，人员流失后缺口难补；3）无法形成数字化质检记录，售后追溯困难。
量化到什么程度？量化到"如果你换了方案，这些数字能不能变成对比基准"。没有基线数据，验收的时候你拿什么比？
字段三：期望技术指标
这个字段最容易被写成愿望清单。
"精度高、速度快、稳定性好"——这不是技术指标，这是形容词。
技术指标必须满足两个条件：可测试、可验收。
可测试意味着有明确的测试方法和测试条件。可验收意味着达到这个数字就算通过，达不到就不算——没有模糊空间。
❌ 错误写法
检测精度高，检测速度快，系统稳定可靠，操作简便。
✅ 正确写法
1. 检测精度：对≥0.1mm的表面缺陷，检出率≥98%（误判率≤5%）；对＜0.1mm的缺陷，检出率≥90%。2. 检测速度：线速度≥300m/min时，实时检测无延迟。3. 测试条件：在正常车间照明（≥300lux）下，铜杆表面温度40-80℃，线径范围8-20mm。4. 验收方法：连续运行72小时，抽取10万米线材样本，以人工复检结果为基准对比。
你看正确写法，每个指标都附了测试条件。0.1mm的缺陷检出率98%——在什么条件下？光线多少？温度多少？线径多少？不写条件，供方回去一测，条件跟你现场完全不同，数据漂亮但到了你车间全废。
验收方法也要写。连续运行72小时、抽10万米——这是可执行的验收方案，不是"双方协商确定"这种废话。
字段四：不期望什么
这是7个字段里最反直觉的一个。
大部分需求书只写"我要什么"，不写"我不要什么"。结果供方按照自己的理解塞了一堆你不想要的东西——你看方案觉得哪哪都好，但价格翻了三倍，因为你没说"不需要云端部署""不需要移动端APP""不需要对接ERP"。
排除项的价值在于控制方案边界，让供方把精力集中在你要的东西上，而不是铺摊子。
❌ 错误写法
（这一栏通常空白，没人写"不期望什么"）
✅ 正确写法
1. 不需要云端部署——质检数据涉及生产工艺参数，不出厂区局域网。2. 不需要移动端APP——车间操作工只看产线终端大屏，不需要手机操作。3. 不需要对接现有ERP——质检数据独立存储，后续由我们自行对接。4. 不需要设备维保服务——我们有设备科，只需要提供技术培训和备件清单。5. 不接受需要专用耗材的方案——必须是通用配件可替代的方案。
五条排除项，直接砍掉了供方至少30%的方案设计空间，但也砍掉了30%的报价水分。
字段五：预算范围与时间约束
预算和时间，是需求书里最扭捏的部分。
甲方不愿意写预算——怕写高了被宰，写低了没人接。乙方不愿意问预算——怕问低了甲方觉得你只认钱。
但不写预算的后果更严重：供方按高端方案报价，甲方嫌贵；供方按低端方案报价，甲方嫌差。双方在价格上拉锯三周，最后发现根本不在一个层次上对话。
我的建议：写预算区间，不写精确数字。区间给供方一个量级参考，不暴露你的底牌。
❌ 错误写法
预算面议。时间要求：尽快。
✅ 正确写法
预算区间：80-150万（含硬件、软件、部署、培训、一年维保）。如方案技术路线显著优于预期，可追加预算至200万，但需提供详细技术论证。时间约束：合同签订后6个月内完成部署调试，第7个月进行验收测试。如遇春节等不可抗力，时间顺延但不超过2周。付款节奏建议：30%（合同签订）+ 40%（部署完成）+ 30%（验收通过）。
"尽快"是最没信息量的时间约束。你说的尽快是下个月还是下个季度？供方理解的尽快可能是一年后。写死节点，双方都省心。
付款节奏也写上——这比预算数字更能体现你的诚意。30-40-30是行业惯例，但也有些甲方写"验收后一次性付清"，这种条件直接吓跑一半供方。
字段六：知识产权归属预期
这个字段，90%的需求书要么不写，要么写一句"知识产权归甲方所有"。
不写，双方在后期一定会吵。写了但写错，双方在后期也吵。
知识产权不是非黑即白的——不是"全归你"就是"全归我"。它是一组权利的集合：专利申请权、专利所有权、使用权、改进权、再许可权。不同部分可以拆开归属。
❌ 错误写法
项目产生的所有知识产权归甲方所有。
✅ 正确写法
1. 甲方原有技术、数据、工艺参数的知识产权不因本项目而改变，仍归甲方。2. 乙方在项目中使用的自有技术（需在方案中列明），知识产权仍归乙方，甲方获得本项目场景下的永久使用权。3. 项目中双方共同开发的新技术，专利申请权共有，专利所有权按甲方60%、乙方40%共有。甲方在自有产品线上有免费使用权；乙方在其他客户场景下使用需经甲方书面同意，收入按50:50分成。4. 乙方不得将甲方提供的生产数据、工艺参数用于其他客户项目。
这段写的不是法律条款——是知识产权的边界框架。你把这个框架给到双方律师，他们有明确的起点去细化条款，不用从零开始扯。
字段七：验收标准
验收标准是需求书的最后一道防线，也是最容易糊弄的一个字段。
"双方协商确定验收标准"——这句话等于没写。到了验收阶段，甲方说"没达到我的预期"，乙方说"你没写清楚预期是什么"，扯皮就这么开始了。
验收标准要在需求书阶段就写清楚，而且要跟字段三的"期望技术指标"呼应——指标是靶心，验收标准是打靶规则。
❌ 错误写法
系统上线运行稳定后，双方共同组织验收。
✅ 正确写法
验收分三个阶段：1. 功能验收（部署后2周内）：按字段三的4项技术指标逐项测试，每项指标连续测试3天，取3天平均值。4项指标全部达标视为功能验收通过。2. 稳定性验收（功能验收后4周）：系统连续运行30天，统计期间故障次数、停机时长、误报次数。故障次数≤3次、累计停机≤4小时、误报率≤5%视为稳定性验收通过。3. 最终验收（稳定性验收后）：甲方组织内部评审，7个工作日内出具验收报告。如甲方未在7个工作日内提出书面异议，视为自动通过。
三个阶段，每个阶段有明确的量化标准、时间窗口和通过条件。到验收那天，打开需求书对着打勾就行——达标了过，没达标不过，没有解释空间。
橙色解法条：7个字段的共同特征——把模糊的主观判断变成可执行的客观标准。需求书不是说明书，是契约。写不清楚的，后面全变成扯皮的材料。
模板怎么用
7个字段不是7个填空题。它们之间有逻辑关系：
字段一（业务场景）定义了"为什么做"字段二（现有方案及痛点）定义了"为什么现在做"字段三（期望指标）定义了"做成什么样"字段四（不期望什么）定义了"不做成什么样"字段五（预算与时间）定义了"花多少钱、花多久"字段六（知识产权）定义了"做完了归谁"字段七（验收标准）定义了"怎么算做完了"
七个字段串起来，就是一条完整的决策链。缺任何一个环节，链子就断了。
模板不是万能的。但模板的价值在于：它把"写需求书"这件事从"发挥题"变成了"填空题"。发挥题的质量取决于写的人的水平，填空题的质量取决于模板的设计——而模板是可以迭代的。
技术需求书模板v2.0 · 7字段自查清单
7个勾全打上，再发出去：
□ 业务场景描述：用了业务语言，说了"是谁、什么问题、不解决亏多少" □ 现有方案及痛点：量化了，有具体数字，能作为验收对比基线 □ 期望技术指标：每条指标附了测试条件，可测试、可验收 □ 不期望什么：列了至少3个排除项，控制了方案边界 □ 预算范围与时间约束：写了区间（不是精确数字），写了时间节点和付款节奏 □ 知识产权归属预期：区分了原有技术、乙方自有技术、共同开发技术的归属 □ 验收标准：分阶段验收，每阶段有量化标准和时间窗口
转发提示：这份模板适合发给正在写技术需求书的同事。转发到工作群，让大家都按同一个标准写——省下来的沟通时间，够你多跑两个客户。
聊聊你的情况 你写过的技术需求书，缺了哪几个字段？ 后来踩了什么坑？ 评论区说说。
