企业FDE架构方法论到实战指南从想法到商业变现：需求·设计·技术·测试·运维·交付·变现-小红书&抖音 AI马教授 职场启航宝

企业 FDE 架构方法论到实战指南

从想法到商业变现：需求·设计·技术·测试·运维·交付·变现

第1篇　认知篇｜FDE是谁

第1章　困局：90%的AI项目死在哪一步

章眼：失败不在某一点，而在需求、交付、价值三道断层。

• 1.1 90%的AI项目都死在哪一步？（P01）
• 1.2　三道断层：需求断层 / 交付断层 / 价值断层（P01）
• 1.3 20个致命坑自检表：勾一条即预警（P01）
• 1.4　五个最烧钱的坑与六大避坑指南（P01）

📌 扩容提示：1.1---1.4 内容密度极大（含五大死法、多Agent认知筑基、三种思维），单页承载过重，建议拆为 P01a---P01d，或将序言之「五大死法」「20坑自检」前移至卷首。

第2章　破局者：FDE是谁

章眼：AI项目缺的不是更强的模型，是一个对最终结果负责的人。

• 2.1 FDE是谁：驻扎在业务一线的全链路工程师（P02）
• 2.2　未来程序员的新画像：最会提要求的脑＋最会做判断的眼（P03）

第3章　能力模型：π型选手与五层思维框架

章眼：一专多能不是样样通，而是有一根主心骨。

• 3.1 FDE能力模型：一专多能的π型选手（P04）
• 3.2　道法术器势：FDE的五层思维框架（P05）

第4章　一天与一生：FDE的实战切片与职业路径

章眼：把一天过明白，才谈得上把一年过明白。

• 4.1 35岁的两条路：成本，还是资本（P06）
• 4.2　一个FDE的24小时：全天角色穿越实录（P07）

第5章　价值与土壤：FDE为什么属于中小企业

章眼：大厂有分工，中小企业只有结果。

• 5.1　课程总地图：从想法到现金流的六步闭环（P08）
• 5.2 2026职场价值公式：你会算吗（P09）
• 5.3 FDE交付的三种价值：商业、管理、效率（P10）
• 5.4　中小企业为什么最适合FDE模式（P11）

第6章　使用说明书：一页一更，学完就做

章眼：这本书不是用来读的，是用来做的。

• 6.1　这门课怎么用：一页一更，学完就做（P12）

第2篇　需求篇｜把企业业务需求梳理清楚

第7章　需求观：真需求与伪需求

章眼：伪需求做得越完美，浪费越彻底。

• 7.1　需求篇开篇：做对的事，比把事做对更重要（P13）
• 7.2　真需求还是伪需求：三项检验过一遍（P14）

第8章　证据链与立项：把想法变成项目

章眼：没有证据链的需求，只是情绪。

• 8.1　需求证据链：从用户原话到产品语言的三级转译（P15）
• 8.2　需求立项五步循环：把想法变成项目（P16）
• 8.3　需求优先级：别平均用力，算期望价值（P17）

第9章　挖掘、评审与规格化

章眼：评审会的价值，是花钱买「不做」的资格。

• 9.1　需求挖掘实操：画像、访谈与AI辅助（P18）
• 9.2　需求评审会：花钱买「不做」的资格（P19）
• 9.3　需求规格说明书：写给两年后接手的人（P20）

第10章　B端与C端需求实战

章眼：B端讲流程，C端讲人性。

• 10.1 B端需求：把企业业务流程一次梳理清楚（P21）
• 10.2 C端需求实战（上）：思库熊与拓境是怎么立项的（P22）
• 10.3 C端需求实战（下）：陪伴熊、记忆熊、情绪球（P23）

第11章　变更与质量门禁

章眼：需求变更不是不能变，是必须走门。

• 11.1　需求变更：不是不能变，是要走门（P24）
• 11.2　需求质量门禁：写完那天，怀疑才开始（P28）

第12章　AI需求工具箱

章眼：让AI替你做需求的第一轮粗筛。

• 12.1 AI需求工具箱（一）：分析与决策场景（P25）
• 12.2 AI需求工具箱（二）：投入产出与目标对齐（P26）

第13章　市场验证与POC立项

章眼：先用最小成本，买一个「此路不通」的权利。

• 13.1　竞品分析与市场验证：别闭门造车（P27）
• 13.2 POC立项：先用最小成本验证可行性（P29）

第14章　需求总表与交付物清单

章眼：验收就查这六件，少一件都不算收口。

• 14.1 P0需求清单：全项目的需求总表怎么建（P30）
• 14.2　需求阶段交付物清单：验收就查这六件（P31）

◆ 第2篇 · 金句卡：需求篇金句合集（P32）

---

第3篇　产品设计篇｜把对的样子定下来

第15章　设计总纲：三个闸门与产品定义

• 15.1　产品设计篇开篇：把对的样子定下来（P33）
• 15.2　设计方法论：从概念到方案的三个闸门（P34）
• 15.3　产品定义三件套：品牌、规格、定价（P35）

第16章　体验与基线：非功能需求前置

章眼：安全边际不是补丁，是设计输入。

• 16.1　体验设计模型：角色-场景-任务（P36）
• 16.2　非功能基线：安全边际必须写进设计（P37）
• 16.3　可测试性设计：设计阶段就想好怎么测（P38）

第17章　设计评审十二问

章眼：每个0分，都是一张未来的工单。

• 17.1　设计评审十二问：每个0分都是一张未来工单（P39）

第18章　平台化与组件化

章眼：一次开发、六款复用，才是真效率。

• 18.1　平台化与组件化：一次开发、六款复用（P40）

第19章　AI产品设计专论

章眼：AI产品设计的本体，是模型驱动的个人系统。

• 19.1 AI产品设计专论：模型驱动的个人系统（P41）
• 19.2　内容即产品：把内容当本体设计（P42）
• 19.3　智元组件化：从积木到智能体（P43）

第20章　设计案例：六款产品的取舍实录

• 20.1　设计案例（上）：思库熊与拓境的取舍（P44）
• 20.2　设计案例（下）：陪伴熊、记忆熊、情绪球（P45）

第21章　决策留痕与交付物

章眼：没有记录的决策，等于没做过的决策。

• 21.1 ADR架构决策记录：让决策可追溯（P46）
• 21.2　设计阶段交付物清单：五件套（P47）

◆ 第3篇 · 金句卡：设计篇金句合集

---

第4篇　技术篇｜通过Agent把对的样子做出来

第22章　架构总纲与FDE跨界地图

章眼：架构定终身------改架构的成本，是改代码的十倍。

• 22.1　技术篇开篇：FDE的跨界地图（P49）
• 22.2　架构总纲：架构定终身（P50）

第23章　多Agent系统：从话痨到团队

章眼：没规划的Agent，只是一个能说会道的话痨。

• 23.1　多Agent系统：一支AI数字工作团队（P51）
• 23.2　没规划的Agent只是话痨（P52）

第24章　11层工程架构全景

• 24.1 11层工程架构全景（P53）

第25章　Agent工程实现四件套

章眼：状态图、路由、检索、记忆------缺一层，闭环就断一环。

• 25.1 LangGraph实现规范：状态图怎么搭（P54）
• 25.2　模型路由与降级链（P55）
• 25.3 RAG五层检索与知识库工程（P56）
• 25.4　记忆系统：16步记忆流水线（P57）

第26章　Agent协同：总线、循环与编排

章眼：Agent之间怎么说话，决定系统能跑多远。

• 26.1 A2A消息总线：Agent之间怎么说话（P58）
• 26.2　四类运行循环：Agent什么时候干活（P59）
• 26.3 PMO舵盘编排器：任务怎么流转（P60）

第27章　工程环境与硬件底座

章眼：芯片是这个时代的战略石油。

• 27.1　工程环境速通：一天搭好开发台（P61）
• 27.2　芯片选型：技术世界的战略石油（P62）
• 27.3　硬件底座：ESP32-S3统一底座（P63）

第28章　固件、OTA与软硬一体联调

章眼：硬件最难的不是做出来，是升级不出事。

• 28.1　固件状态机：七个状态管稳定（P64）
• 28.2 OTA双分区与灰度升级（P65）
• 28.3　软硬一体集成与端云联调（P66）

第29章　数据底座：五表与向量检索

章眼：没有数据底座的智能，只是一次性烟花。

• 29.1　数据底座：五张核心表（P67）
• 29.2　数据库与向量检索落地（P68）

第30章　工程效率：AI辅助编程与调试方法论

章眼：从写代码到审架构，是FDE的分水岭。

• 30.1 AI辅助编程：从写代码到审架构（P69）
• 30.2　调试方法论：假设-验证-排除（P70）

第31章　技术债、安全合规与成本工程

章眼：省钱的架构，才是能长期活着的架构。

• 31.1　技术债四象限：什么时候还债（P71）
• 31.2 AI安全与合规底线（P72）
• 31.3　成本工程：把省钱写进代码（P73）

第32章　联调实录与交付物

• 32.1　技术阶段贯穿案例：联调周实录（P74）
• 32.2　技术阶段交付物清单：六件套（P75）

◆ 第4篇 · 金句卡：技术篇金句合集

---

第5篇　测试篇｜用数据证明做对了

第33章　测试观与分层策略

章眼：人工测试的隐性账单，迟早要还。

• 33.1　测试篇开篇：人工测试的隐性账单（P77）
• 33.2　测试金字塔：分层策略（P78）

第34章　测试设计：分级、边界与生产等价

章眼：测试的主战场，永远在边界与异常。

• 34.1　缺陷分级：极度求真的严重度标尺（P79）
• 34.2　边界与异常：测试设计的主战场（P80）
• 34.3　生产等价：测试环境对齐（P81）

第35章　质量门禁与AI评测集

章眼：AI系统没有"通过测试"，只有"达到阈值"。

• 35.1　质量门禁：发布准入五道闸（P82）
• 35.2　评测集建设：AI系统怎么算「好」（P83）

第36章　端云联调、体验与安全对抗

• 36.1　端云联调测试规范：主表＋差异表（P84）
• 36.2　延迟与体验验证（P85）
• 36.3　对抗审计与安全测试（P86）

第37章　测试自动化与灰度发布

章眼：灰度不是保守，是把损失控制在可承受范围内。

• 37.1 AI驱动测试自动化（P87）
• 37.2　灰度发布：小步快跑（P88）

第38章　测试阶段交付物

• 38.1　测试阶段交付物清单：六件套（P89）

◆ 第5篇 · 金句卡：测试篇金句合集

---

第6篇　运维篇｜让系统越用越准

第39章　运维观与可观测性

章眼：看不见的系统，一定管不好。

• 39.1　运维篇开篇：从救火队到先知（P91）
• 39.2　可观测性三板斧（P92）

第40章　SLO、故障复盘与变更管理

章眼：没有复盘的故障，会换一种形式再来一次。

• 40.1 SLO与错误预算（P93）
• 40.2　故障复盘五步反思（P94）
• 40.3　变更管理三分法（P95）

第41章　成本、MLOps与数据飞轮

章眼：越用越准，才是AI系统唯一的护城河。

• 41.1　容量与成本：FinOps三控（P96）
• 41.2 MLOps：模型版本与运维（P97）
• 41.3　数据飞轮：越用越准（P98）

第42章　运营体系：工单、周历、月报

章眼：用固定节奏，对抗不确定。

• 42.1　客服SOP与工单分级（P99）
• 42.2　四线周历：内容、设备、用户、商业（P100）
• 42.3　数据盘点与月报制度（P101）

第43章　隐私伦理与交付物

章眼：最脆弱的用户，优先被保护。

• 43.1　隐私与伦理：最脆弱的用户优先（P102）
• 43.2　运维阶段交付物清单：六件套（P103）

◆ 第6篇 · 金句卡：运维篇金句合集（P104）

---

第7篇　交付篇｜把做出来的变成收入与口碑

第44章　交付观与五阶段门禁

章眼：交付的敌人不是难度，是阶段之间的缝隙。

• 44.1　交付篇开篇：把做出来的变成收入与口碑（P105）
• 44.2　五阶段门禁详解（P106）
• 44.3 87%死在阶段断层（P107）

第45章　交付物体系

• 45.1　每阶段交付物清单（P108）

第46章　硬件交付与BOM谈判学

章眼：BOM表里藏着整个项目的毛利。

• 46.1　硬件交付：BOM、外包与知识产权（P109）
• 46.2 BOM表里的谈判学（P110）

第47章　软件交付、成本与协同机制

章眼：周会只要45分钟，责任却要365天清楚。

• 47.1　软件交付：迭代与OTA节奏（P111）
• 47.2 FinOps：管好每一分算力钱（P112）
• 47.3　跨部门协同：RACI与45分钟周会（P113）

第48章　人机协同与全生命周期管理

章眼：未来的项目组，是人带着Agent干。

• 48.1　人+Agent协同工作流（P114）
• 48.2　大型AI项目全生命周期管理（P115）

第49章　风险、资金与合规红线

章眼：红线不是限制，是让项目活到变现那天。

• 49.1　风险管理：从登记到预警（P116）
• 49.2　资金与合规红线（P117）

第50章　交付贯穿案例与知识沉淀

• 50.1　交付贯穿案例：六款产品的交付节奏（P118）
• 50.2　项目复盘与知识沉淀（P119）

第51章　规模化、总账与信任

章眼：总账算得清，信任才留得下。

• 51.1　试点到规模化：Phase 5（P120）
• 51.2　总账与信任（P121）

◆ 第7篇 · 金句卡：交付篇金句合集（P122）

---

第8篇　商业变现篇｜三种价值与现金流闭环

第52章　变现观与ROI一页纸

章眼：讲不清ROI的AI项目，预算迟早被砍。

• 52.1　商业篇开篇：从想法到变现的最后一公里（P123）
• 52.2 ROI汇报一页纸（P124）

第53章　商业价值：定价、订阅与内容获客

• 53.1　商业价值：定价与订阅设计（P125）
• 53.2　内容获客：种草与售卖闭环（P126）

第54章　效率价值与管理价值度量

章眼：省下来的时间和少掉的救火，都是钱。

• 54.1　效率价值度量：人效比（P127）
• 54.2　管理价值度量：从救火到看板（P128）

第55章　成本黑洞与组织保障

章眼：海星组织------砍掉一块，还能长回来。

• 55.1　成本黑洞扫描（P129）
• 55.2　组织保障：海星组织与三支柱（P130）

第56章　团队搭建、绩效飞轮与商业闭环

章眼：招错一个博士，浪费三年；用错一个团队，葬送一个赛道。

• 56.1 FDE团队怎么搭：必招与慎招（P131）
• 56.2　绩效飞轮：考核人机团队（P132）
• 56.3　商业闭环：AI产品的成本收入与增长（P133）

第57章　产品档案、第二年规划与试错机制

章眼：不允许试错的组织，做不出AI。

• 57.1　六款产品商业档案速览（P134）
• 57.2　第二年规划：资产复利（P135）
• 57.3　允许试错：AI落地的前提（P136）

第58章　90天行动路线图与年度节奏

章眼：90天能验证的，别用一年去赌。

• 58.1 90天行动路线图（P137）
• 58.2　把90天变成年度节奏（P138）

第59章　尾声：FDE是一种活法

章眼：不是你选择了这份职业，是这份职业重新定义了你。

• 59.1　尾声：FDE是一种活法（P139）

◆ 第8篇 · 金句卡（收官）：现金流闭环的8句话（P140）

卷首

作者简介

AI马教授，12年AI技术架构师与团队管理者，长期深耕大模型、多Agent协同、具身智能、计算机视觉与云原生AI架构领域，专注AI技术从0到1的工程落地、团队体系搭建与传统项目的AI转型。2014年毕业于国内知名工科名校，从底层研发岗位起步，做过分布式架构与高并发系统优化，也较早尝试把AI算法用进业务调度、资源优化和智能决策场景；后擔任技术经理，主导团队架构升级与流程规范化，牵头组建AI专项研发小组，完成AI能力从探索到业务赋能的第一轮闭环。担任AI技术负责人，统筹60人跨职能AI团队，覆盖算法、开发、测试、运维全链路，期间与清华、MIT等背景的科研人员长期共事，主导参与多项重点AI项目，牵头制定AI技术规划并搭建标准化研发管理体系，落地领域驱动设计、国产化适配与高可用架构方案。此后自主创业，操盘商业地产AI运营数据平台，从产品设计、架构搭建到研发、交付、变现全流程走了一遍。这些年踩过的坑比做成的案例多，本书写的多是踩坑之后的复盘，风格务实，少谈概念，多谈怎么把事做成。

前言：90%的AI项目亏损，不是技术不行，是团队和管理烂

一、先推翻一个行业共识

复盘大量企业AI转型失败案例，我们首先推翻一个被普遍接受的误诊：

绝大多数AI项目折戟沉沙，从来不是算力不足、不是模型不够先进、不是资金短缺、也不是赛道不好。

企业手握开源模型、顶级算法人才、充足预算、成熟业务场景，却依旧做不出可落地、可增效、可变现的AI成果------因为病根从一开始就被找错了地方。

二、七大病灶

核心病根始终聚焦在七个词：

组织臃肿 · 团队错配 · 流程僵化 · 协同断裂 · 管理失效 · 文化松散 · 效能低下

AI是全新的技术赛道，更是全新的组织赛道、管理赛道、协同赛道。

三、用工业时代的规矩，管智能时代的仗

传统数字化、软件研发、项目交付的管理逻辑，适配的是需求固定、流程标准、结果可控、迭代稳定的确定性业务。

而AI项目天生具备六大特质：高不确定性、高试错性、高动态迭代、强场景依赖、强数据驱动、跨域强协同。

用工业时代的流水线规则，去约束智能时代的创新作战------结局必然是全员内耗、技术空转、落地失效、持续亏损。

四、终极竞争是组织战斗力

当下最荒诞的现状是：无数企业把AI转型的重心压在「技术堆叠」上，疯狂追逐模型精度、算法创新、学历背书、算力规模，却完全忽略了------

AI竞争的终极本质，是组织战斗力的竞争。

同样的模型、同样的场景、同样的预算：有的团队三个月落地商业化功能、实现降本增效，有的团队深耕一年只剩PPT Demo和实验室数据。同样的AI赛道：有的企业靠小而精的铁军团队快速迭代、持续变现，有的企业靠庞大臃肿的科研团队持续烧钱、颗粒无收。

二者的核心差距，从来不是技术，而是团队搭建逻辑、组织架构形态、跨域协同机制、项目管理体系、团队作战文化的全方位差距。

认知筑基：看懂多Agent时代

本篇任务：先破认知、避内卷、建立工程落地思维，为后续技术学习定方向。彻底纠正开发者「追模型、堆参数、玩Demo」的无效学习误区------帮技术人建立抗周期成长逻辑，帮企业管理者看懂AI真实落地路径。

---

一、智能革命4.0：从单模型内卷到多Agent自主时代

1. 技术迭代：从单点能力到系统自主

AI四十年的迭代，本质是从「人工驱动」走向「系统自主」的质变。

|-----------------------|-----------------|--------------------------------------------------------|
| 代际 | 核心逻辑 | 能力边界 |
| 第一代·符号智能​ | 靠人工写死规则 | 只能解决固定、简单、标准化问题，无泛化能力、无法应对复杂业务 |
| 第二代·机器学习​ | 依赖人工特征工程＋数据训练 | 能做小范围智能化，但极度依赖数据质量、 调参，落地成本高、复用性差 |
| 第三代·大模型​ | 靠海量参数与预训练 | 实现通用生成能力，大幅降低AI使用门槛； 但始终被动应答、单次执行，只能做单点任务，无法独立完成复杂业务闭环 |
| 第四代·多Agent协同​ | 多智能体分工、通信、协作、复盘 | 自主拆解任务、闭环执行、持续优化， 是当前唯一能落地企业复杂业务、规模化降本增收的终极形态 |

AI迭代的终极归宿，不是参数更强，而是系统更能自主解决复杂业务问题。

技术迭代淘汰的从来不是工具，而是只会使用单一工具的人。

AI赛道的终极竞争，从来不是模型参数比拼，而是系统协同落地能力的竞争。

2. 大模型瓶颈：单模型做不了企业级复杂业务

市面90%的AI落地失败，根源不是模型不够先进，而是过度神化单模型、无视四大底层硬伤：

|------------------|-----------------------------------------------|
| 硬伤 | 具体表现 |
| 能力边界受限​ | 只会问答、生成、简单推理，无法独立完成「需求拆解→工具调用→流程执行→结果校验」全链路工作 |
| 幻觉无法根除​ | 天生存在虚假生成、逻辑漏洞、数据错误；无人工校验、无闭环纠错，无法落地企业核心业务 |
| 上下文窗口有限​ | 超长文档、复杂流程、海量数据无法一次性加载，撑不起企业级复杂场景 |
| 无自主闭环能力​ | 只能被动接指令、单次输出，不会规划、分工、复盘、优化，无法7×24小时自主作业 |

|---|---|
| | |
| | |
| | |
| | |
| | |

单模型只能解决「简单问题」，企业复杂业务落地，天然需要多智能体闭环体系兜底。

单大模型只能做「辅助工具」，多Agent系统才是「业务生产力」。

企业不要为单点模型溢价买单，要为闭环落地能力付费。

3. 范式转移：告别参数内卷，拥抱Agent生产系统

2026年起，AI行业彻底告别「参数越大、模型越新、能力越强」的伪内卷。

• 过去：开发者沉迷追新模型、跑分对比、堆砌概念，看似精进，实则技能可替代、无壁垒、快速贬值。
• 现在：行业转向以业务结果为核心、以多Agent系统为载体，从「人指挥AI做事」升级为「AI自主组队、分工协作、完成全流程业务」，是企业降本增效、规模化落地的唯一突破口。

模型跑分是纸面价值，业务落地是真实价值。

参数内卷是短期红利，系统落地是长期壁垒。

会调模型的人遍地都是，会搭建自主AI生产系统的人凤毛麟角。

4. 多Agent核心内涵：感知、规划、分工、协作、执行、复盘

（1）不是模型拼凑，是企业级AI团队

六大核心能力，完全复刻真实企业工作流：

|--------------|---------------------|
| 层级 | 职责 |
| 感知层​ | 接收需求、读取数据、识别痛点 |
| 规划层​ | 任务拆解、优先级排序、资源分配 |
| 分工层​ | 角色匹配、专人专岗、各司其职 |
| 协作层​ | 消息通信、状态同步、冲突消解 |
| 执行层​ | 调用工具、处理数据、输出结果 |
| 复盘层​ | 结果校验、错误修正、流程优化、模型迭代 |

多Agent不是多个模型的简单拼凑，而是一套可落地、可商业化的AI数字化工作团队。

多Agent的核心价值不是「技术炫酷」，而是把人工复杂工作，变成AI标准化、自动化、可量化的闭环工作。

1. 产业格局：基础模型同质化，竞争在落地

|-------------|------------|-----------------------------------|
| 层级 | 角色 | 特征 |
| 顶层​ | 基础大模型厂商 | 通用、同质化、无业务壁垒 |
| 中层​ | AI系统工程服务商 | 模型部署、微调、系统搭建------核心溢价环节​ |
| 底层​ | 企业应用层 | 靠多Agent赋能业务 |

未来3---5年不会有模型颠覆式革命，竞争聚焦三件事：场景落地、系统协同、商业变现，覆盖办公、客服、数据分析、工业运维、具身交互等全行业。

---

第1篇　认知篇｜FDE是谁

篇定位：为什么需要FDE、FDE是什么、这门课怎么用

先回答三个问题：90%的AI项目为什么死？FDE凭什么能救？这门课怎么一页一页学完就落地？

开篇立论：认知不统一，后面全是内耗。

---

第1章　困局：90%的AI项目死在哪一步

章眼：失败不在某一点，而在需求、交付、价值三道断层。

1.1　三道断层（P01）

【开头钩子】

烧钱、亏损、烂尾、闲置------九成企业的AI转型，最后都成了无效试错。

AI项目很少死于技术难题。真正难的技术问题，反而总有解法。它死在三个更隐蔽的地方：

|---------------------|---------------------|-----------------|
| 断层 | 本质 | 后果 |
| 死因第一层·需求断层​ | 做了不该做的需求 | 钱全花在伪需求上 |
| 死因第二层·交付断层​ | 87%的项目死在阶段与阶段之间的缝隙里 | 每个环节都合格，整体却交付不了 |
| 死因第三层·价值断层​ | 东西做出来了，没人买单、没法变现 | 有成果，没收益 |

需求决定做不做，交付决定成不成，价值决定活不活。三层全断，再多算力也救不回来。

自检前置：20个致命坑自检表------招错人、无验收标准、无数据闭环......勾中一条即预警。

唯一解：三层断层，加人、加钱、加模型都补不上。解法只有一个角色------

FDE：把需求、产品、技术、交付缝成一条线的人。

---

1.2　死因解剖：五大典型死法

死法一｜需求模糊、频繁变更，项目无限延期

绝大多数企业AI项目从启动之初就注定夭折，核心根源并非技术不足，而是业务需求完全模糊------无边界、无标准、无闭环。

企业老板仅凭行业热点、竞品动态、个人主观认知启动AI项目，没有梳理核心业务痛点、没有明确落地目标、没有量化验收标准。项目启动后，业务端随时改需求、随时加功能、随时变方向：今天要智能巡检，明天要智能分析，后天要自动决策，版本迭代毫无章法。

技术团队反复推翻重做、重复开发、无效加班，大量时间消耗在需求对齐和代码重构上，核心功能始终无法落地。最终项目陷入「做一半、改一半、废一半」的死循环，周期无限拉长、预算持续超支、团队身心俱疲，最后不了了之------投入的人力、财力、时间全部白费。

一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松。

当需求文档比源代码还厚，你的AI项目已经病入膏肓。

死法二｜技术与业务脱节，做出来的产品没人用

这是90%企业AI项目崩盘的核心通病：技术团队埋头造轮子，业务团队冷眼旁观。

企业盲目追求前沿技术、顶级模型、复杂架构，一味堆砌高端AI能力，却从未深度调研一线业务流程、一线员工操作习惯、行业真实痛点与合规要求。

技术团队基于理论、Demo、实验室数据开发产品，模型在测试环境准确率高达90%以上，汇报演示效果惊艳，看似成果满满。但一旦落地真实业务场景，立刻漏洞百出：适配不了复杂现场环境、满足不了业务实操需求、解决不了核心痛点、操作繁琐反而加重员工负担。

最终出现极其尴尬的局面------技术完美、产品无用、团队忙碌、业务不用，花费重金打造的AI系统沦为摆设，闲置吃灰。

实验室里再完美的模型，也抵不上车间里一线工人的一个真实痛点。

不懂业务的AI工程师，就是企业最昂贵的「技术债」制造机。

死法三｜跨部门推诿扯皮、责任空白、忙闲不均

企业AI项目从来不是单一技术团队的工作，需要业务、产品、技术、运维、运营多部门协同。但绝大多数企业完全没有搭建AI项目协同机制，直接陷入权责真空、全员内耗的死局。

技术团队认为：业务需求不清晰、数据不交付、配合不到位。

业务团队认为：技术落地慢、效果差、不贴合场景。

管理层：无明确权责划分，出现问题无人担责、人人甩锅。

干活的人累死，摸鱼的人无事可做；核心技术人员长期高压加班，职能部门全程躺平，团队忙闲严重不均。遇到问题互相推诿、互相抱怨、内耗严重，没人主动解决问题，所有人都在等待别人推进，微小卡点被无限放大。

最终项目停滞、进度崩盘、团队人心涣散------原本用来赋能企业的AI项目，反而变成了企业内部最大的内耗源。

当所有部门都觉得自己是裁判时，AI项目就永远没有赢家。

协同不是开个会，而是让每个人都知道：做成了有奖励，做砸了有人担。

死法四｜盲目堆算力、堆人力，投入巨大无产出

多数传统企业、转型中的中小企业，对AI落地完全没有认知，陷入「重投入、轻落地、重硬件、轻工程」的致命误区。

老板普遍存在认知偏差：只要花钱堆算力、买顶配服务器、开通高额模型接口、扩招大量AI人员，就能做出成熟的AI项目。

于是企业不计成本投入：采购高额GPU算力、订阅高价模型服务、扩招十几人AI团队，每月人力成本、算力成本、运维成本居高不下。但因为没有成熟的落地方法论、没有标准化的工程体系、没有贴合业务的落地方案，所有投入全部沦为无效成本。

算力闲置浪费、人力重复内耗、资金持续烧损。投入百万级成本，最终没有落地一个可商用、可增效、可变现的AI功能------只烧钱、不产出，只投入、无回报。

买最贵的算力，招最贵的人，做最烂的项目------这是90%企业AI转型的魔咒。

当你的GPU集群比业务系统还忙，就说明AI项目已经开始失控了。

死法五｜盲目迷信大厂光环、博士学历------螺丝钉式学术人才泛滥

（行业最亏钱、内耗最重的核心大坑）

这是当下95%软件企业、AI创业公司、传统数字化转型企业，AI项目崩盘、巨额亏损、团队瘫痪、持续内耗的第一隐形死穴；也是所有老板、HR、技术负责人踩得最多、亏得最惨、最难以复盘的顶级大坑。

第一层：畸形风气

AI风口火热，管理层盲目迷信「高学历＝高技术、博士＝能落地、论文＝能赚钱」。绝大多数企业完全分不清****「学术科研型AI人才」**** 与****「企业落地型AI工程师」****的核心区别，一味追捧名校博士、大厂研究院履历、顶会论文成果，将其等同于商业落地能力。

老板为了撑门面、讲故事、报项目、拿融资、对外宣传AI转型，不惜砸重金、开天价年薪，疯狂招聘985博士、顶会论文作者、高校实验室研究员、博士后团队。认为只要团队学历够高、头衔够大、简历够光鲜，AI项目就一定能落地、一定能变现、一定能降本增效。

但真实的企业落地真相，完全相反：学历越高、科研越深、落地越弱、成本越高、亏损越严重。

第二层：能力错配

学术型博士、科研人才的核心能力是「发论文、刷精度、做实验、跑数据集、堆算法」，适配高校、实验室、大厂研究院的科研场景；但完全不适配中小企业、软件公司、传统企业的工程落地、业务适配、系统集成、稳定交付、商业化变现场景。

这类人才的致命短板：不懂软件工程、不懂前后端对接、不懂数据库读写、不懂私有化部署、不懂脏数据处理、不懂业务流程、不懂迭代优化、不懂故障排查。

他们能做出99%精度的实验室Demo，却永远做不出一套能稳定跑在企业生产环境、能给业务赋能、能产生实际价值的AI产品。

第三层：大厂螺丝钉陷阱

目前市面上大量高薪跳槽的AI博士、科研人才，大多来自头部大厂研究院、高校实验室。在大厂体系内，他们本质只是标准化技术螺丝钉------分工极度细化，有人专门负责数据清洗、有人专门负责模型预训练、有人专门负责调参、有人专门负责论文迭代、有人专门负责工程部署。

大厂的流水线造出了零件，企业却误以为买到了整台机器。

1.3　为什么这个时代需要FDE

五大死法，表象是五个问题，实质是同一个：

需求、产品、技术、交付、变现，这五个环节被拆给了五个部门，中间没有人负责缝合。

AI项目缺的不是一个更强的模型，是一个对最终结果负责的人。

FDE------前置部署架构师：驻扎在业务一线，把需求、产品、技术、交付、变现缝成一条线，对「从想法到现金流」的全过程负责。

这不是一个岗位，是一条从想法到变现的责任线。

---

1.4　企业AI项目落地高频避坑指南

结合多年百人团队大型AI项目落地经验，总结多Agent项目最高频、最致命的落地坑点，全部为实战踩坑总结，可直接规避风险、减少90%项目烂尾概率。

|-------------------------|----------------------------------------|---------------------|
| 坑 | 症状 | 正确做法 |
| 坑1·需求贪大求全​ | 一期想做完所有功能，流程复杂、角色过多、开发周期拉长，最终全面延期、效果拉胯 | 小闭环快速验证，迭代放大价值 |
| 坑2·过度依赖单模型能力​ | 不做校验、不做复盘、不做纠错，任由模型幻觉输出，导致业务出错、客户不信任 | 多Agent互相校验，流程闭环兜底 |
| 坑3·不做成本预判​ | 上线后Token暴涨、算力超标、成本失控，项目盈利倒挂 | 上线前限流、缓存、复用、分层算力策略 |
| 坑4·架构临时堆砌​ | 为赶工期乱开发，后期无法迭代、无法扩展、无法复用 | 架构先行、模板沉淀、标准化开发 |
| 坑5·重开发、轻运维、轻迭代​ | 上线即放任不管，模型漂移、知识库陈旧、效果持续下滑 | 常态化数据更新、模型迭代、效果监控 |
| 坑6·忽视安全与风控​ | Prompt注入、越权访问、数据泄露、违规输出 | 权限隔离、内容审核、行为审计、沙箱执行 |

AI落地不是比谁做得多，而是比谁烂尾少、谁稳定久、谁持续产出价值。

1.5　认知篇｜为什么AI项目会亏：20个致命坑自检表

（勾选即预警）

|-----------|-------------|--------------|------------------|
| # | 致命坑 | 典型信号 | 立刻动作 |
| 1 | 需求模糊 | 无量化验收标准 | 写清谁、什么场景、什么指标算成功 |
| 2 | 技术业务脱节 | 一线不用、骂声多 | 先蹲现场3天，再写代码 |
| 3 | 跨部门扯皮 | 出问题无人认 | 上RACI矩阵 |
| 4 | 堆算力堆人 | GPU空转、人效低 | 先POC验证，再扩容 |
| 5 | 迷信博士学历 | 论文多、上线少 | 招落地型全栈AI工程师 |
| 6 | 大厂螺丝钉 | 只会单模块 | 面试考端到端交付案例 |
| 7 | 唯精度至上 | 0.1%精度换3周 | 定够用阈值＋Deadline |

自测结论 ：勾选 ≥8项 → 高危 ；≥5项 → 预警 ；≤4项 → 重点优化勾选项。

自检表不是用来存档的，是用来逼自己动手的------勾一条，就改一条。

1.6　五个最烧钱的坑（优先治理）

|---------------|--------------------|
| 坑 | 后果 |
| 招错人​ | 科研型博士做企业落地 → 年亏百万级 |
| 没协同​ | 部门各自为战 → 项目停滞 |
| 没验收​ | Demo当交付 → 业务拒用 |
| 没迭代​ | 瀑布硬扛不确定性 → 无限延期 |
| 没ROI​ | 讲技术不讲钱 → 预算被砍 |

1.7　招错人：一张表看懂（行业第一隐形死穴）

|---------------|---------------|-----------------------|
| 维度 | 学术科研型 | 企业落地型（你要的） |
| 核心能力​ | 论文、精度、实验 | 工程、集成、交付、兜底 |
| 评价标准​ | 顶会、专利 | 上线指标、业务采纳、ROI |
| 典型短板​ | 不懂业务、排斥脏活 | 算法深度可能一般 |
| 适配场景​ | 研究院、大厂单点 | 中小企业全链路落地 |
| 薪资​ | 2---3倍 | 合理 |
| 面试三问​ | --- | 0→1案例 / 线上事故 / 需求冲突取舍 |

招错一个博士，浪费三年；用错一个团队，葬送一个赛道。

1.8　三大底层思维：FDE的认知底座

案例1｜目标思维------成果导向与问题导向

成果性目标体现的是成果导向的思维，即目标思维。它强调在项目实施过程中要取得的具体成果和要实现的目标，关注的是项目的最终产出是否符合预期和满足需求。

这种思维方式以实际结果为导向，注重实际效果和实际价值，追求项目的成功，而不仅仅是解决项目实施过程中的困难和挑战。设定明确的成果性目标，可以帮助项目团队和相关干系人更好地进行决策和规划，并将资源和注意力集中在真正重要的事情上。

反面：受害者思维

当你频繁冒出这些念头时，就要警惕了------

• 「领导为什么总是针对我？」
• 「当初要不是朋友叫我跳槽，我现在已经在原公司享受分红，实现财务自由了。」
• 「项目工作做得很好，但项目失败了？这事我可不背锅。」

受害者思维又称弱者思维，典型表现是「我没有错」「都是你们害的」。

目标思维问的是「我要什么结果」，受害者思维问的是「这该怪谁」。

一个盯结果的人会找到路，一个盯责任的人只会找到理由。

案例2｜平衡思维------权衡取舍与弹性调整

项目的约束性目标包括质量约束、成本约束、时间约束，三者共同体现了项目管理的平衡思维。

如果把平衡思维比喻成一把天平------天平两端物体重量相等才能保持平衡，平衡思维也要求我们在不同选择之间寻找平衡点，避免过度偏向某方而产生不想要的后果。

权衡取舍是平衡思维的重要组成部分 。就像在天平两端放置不同重量的物体，我们需要根据实际情况尽可能使两端保持平衡：有时需要牺牲一些东西来换取更大的利益，有时则需要主动减速来换取确定性。

项目管理没有最优解，只有约束条件下的最优权衡。

会做加法的是工程师，会做减法的是架构师。

案例3｜系统思维------牢笼困境与全局思考

系统思维作为一种全面、综合的思考方式，强调从整体角度审视问题，关注各要素之间的相互联系和相互作用。

然而在实践过程中，个体或组织往往陷入牢笼困境------难以突破固有的思维模式和框架，导致无法有效应对挑战和变革。你越是用力优化局部，整体反而越僵化。

因此，全局思考在这一背景下显得尤为迫切：先看森林，再看树木；先理关系，再谈优化。

局部最优的累加，从来不等于全局最优。

困住项目的往往不是难题本身，而是解决难题时没人抬头看全局。

1.9　金句收尾

市面90%的AI项目最终都陷入烧钱、亏损、烂尾、闲置的困境，九成企业的AI转型，最终都沦为无效试错与成本浪费。

第2章　破局者：FDE是谁

章眼：AI项目缺的不是更强的模型，是一个对最终结果负责的人。

2.1 FDE是谁：驻扎在业务一线的全链路工程师（P02）

【开头钩子】

售前只讲不做，研发只做不懂业务，PM只管不落地------总得有人全链路负责。

一、一句话定义与四域贯通

FDE ＝ Forward Deployed Engineer，前沿部署工程师------人扎在客户现场与业务一线。

四域贯通：需求甄别 → 产品设计 → 技术实现 → 交付变现，一条龙闭环。

一句话画像：

既听得懂老板的商业语言，也写得懂工程师的技术语言。

二、为什么需要FDE：最后一公里断层

1. 一组让人坐不住的数字

行业复盘给出的基线数字是：

• 市面上约 90% 的AI项目，最终陷入烧钱、亏损、烂尾、闲置；
• 约 95% 的企业AI亏损烂尾，第一原罪不是没有战略口号，而是没有可落地的战略拆解；
• 90% 的企业AI项目烂尾、研发内耗、合规被罚、人才流失，根源不是技术不够牛，而是研发体系失控、流程无序、管控空白。

这些数字共同指向一个结论：

AI项目的失败率，已经高到不能用「执行不力」来解释------它是一种结构性的、体系性的失败。

2. 更值得玩味的，是失败发生的位置

绝大多数失败项目并不缺技术：它们手握开源大模型、顶配GPU、硕博团队和充足预算。

某大型集团的千万级智能审批项目，团队在标准合同、标准报表、标准单据上把模型准确率做到了 97%，演示完美、评审通过；可一旦进入真实办公场景------历史单据格式混乱、手写扫描件模糊、合同条款非标、财报数据缺失------模型立刻不堪一击。

97%与不堪一击之间的距离，就是最后一公里。

它不在实验室里，不在论文里，而在脏数据、旧流程、方言口音、使用习惯和部门墙里。

3. 为什么传统分工填不上这道沟

因为最后一公里的工作，有三个反传统特征：

|-----------------|-------------------------------------------------------------|
| 特征 | 表现 |
| 高度跨域​ | 一个AI硬件产品的需求，同时涉及算法、嵌入式、云服务、供应链、内容运营和法务合规------任何单一岗位的视野都不够用 |
| 高度不确定​ | 需求模糊、数据没准备、验收标准不存在，你无法在项目开头把一切写死，只能小步试错、持续验证 |
| 高度依赖现场​ | 真相不在会议室和报表里，而在用户的原话、犹豫和放弃使用的动作里 |

用工业时代流水线的职能分工去应对这种工作，就像用管理20世纪流水线工人的方式管理21世纪的知识工作者------错配是必然的。

三、断层解剖：Demo与生产环境之间的三道鸿沟

第一道：场景鸿沟

实验室里的输入是干净的、分布是均衡的、用户是配合的；现场的输入是嘈杂的、长尾的、充满意外的。

陪伴熊的语音识别在普通话测试集上表现优异，但老人一句带着浓重乡音的「我想听俺们老家那段戏」，就能让系统掉线。

场景鸿沟的本质，是开发者用想象中的用户替代了真实的用户。

填这道沟没有捷径，只能靠人到现场去------把真实环境的噪声、方言、光线、网络、操作习惯，全部变成需求的一部分。

第二道：责任鸿沟

传统分工里：算法对准确率负责，研发对功能负责，产品对需求文档负责，交付对验收单负责------看起来人人有责，实际上出了问题人人无责。

模型识别错了，算法说是现场数据太差；数据太差，业务说是技术没提前说；项目延期，研发说是需求天天变。

最后一公里需要的，恰恰是一个对系统在用户手里真正跑通负全责的人，一个没有借口可找的角色。

这正是FDE在组织设计上的核心价值：把分散在六个部门的责任，收敛到一个对端到端结果负责的位置上。

第三道：价值鸿沟

技术团队衡量成功的单位是模型精度、功能数量、上线日期；业务方衡量成功的单位是人工节省、收入增加、风险下降。

两套语言之间没有翻译器，于是「技术完美、产品无用」的荒诞剧反复上演。

某团队为零售客户上AI客服，最初方案是对标竞品做「大模型＋RAG」。回到工单数据一看：60%是查物流、20%问退换货政策，只有15%需要复杂推理。真问题不是没有AI，而是简单问题占用了人工。最后用低成本规则加知识库覆盖80%工单，人工占比从45%降到22%。

价值鸿沟只能由既懂技术、又懂业务、还能把技术翻译成钱的人来跨越。

---

四、FDE模式的由来：从Palantir到OpenAI

FDE作为一种制度化角色，最早成熟于 Palantir。

Palantir的客户是情报机构、军方、大型银行和医疗机构------数据混乱、流程涉密、需求无法被标准化产品覆盖。Palantir发现：把通用软件卖给客户，然后等他们自己用起来，是行不通的。于是反其道而行：

把最好的工程师直接派到客户现场，和分析师坐在一起办公，在真实数据上改代码、在真实流程里调系统，把平台部署成针对该客户的解决方案。

这些工程师既写产品代码，也做现场集成；既理解平台能力，也理解客户业务。他们的交付物不是安装包，而是客户业务问题的消失。

大模型时代，这一模式被重新发现并放大。OpenAI在服务大型企业客户时同样设立了Forward Deployed Engineer岗位，职责是深入客户业务，把通用大模型转化为具体场景里可靠运行的系统------从提示词工程、知识库构建，到业务流程对接、效果评估，一包到底。

模型能力越强、越通用，落地时需要的现场翻译工作反而越重。

一个什么都能做的模型，等于什么都不会替你做；必须有人在现场把它约束、编排、喂数据、设护栏，它才能变成业务能力。

模型通用性与落地具体性之间的张力，就是FDE存在的根本理由。

企业FDE的三条铁律

|---------------|---------------------------------------------------------------|
| 铁律 | 内涵 |
| 驻场洞察​ | 需求调研在业务现场完成，不在会议室里想象 |
| 小步交付​ | 每两周交付一个可用增量，拒绝半年憋大招 |
| 领域建模​ | 把业务黑话翻译成模型可执行的结构（提示词、知识库、工作流）------这是FDE与普通全栈工程师的分水岭​ |

五、FDE不是什么：与三个相邻角色的边界

1. 与产品经理相比

产品经理的核心产出是需求文档与方案决策，主要工作语言是用户价值和商业逻辑；FDE的核心产出是在真实环境中运行的系统------他不仅要定义问题，还要亲手或指挥AI把方案实现出来。

产品经理可以不懂技术实现细节，FDE不能：他必须知道ESP32-S3的算力边界、知道7B模型端侧跑不动要降到1.8B量化、知道语音克隆涉及哪些合规红线。

产品经理对「做什么」负责，FDE对「做出来、跑起来、有人用」负责。

2. 与架构师相比

架构师的舞台在设计阶段------定义系统结构、技术选型与非功能指标，追求方案的正确与优雅；FDE的舞台在现场和全周期------他要在脏数据、紧工期、跨部门扯皮中让架构落地，并为架构在真实约束下的变形负责。

架构师可以说「这个需求技术上不可行」，FDE必须接着问「那什么方案在现有约束下可行」。

架构师帮团队画定能力圈，FDE则要带着Spike去圈外探路，把「不可行」变成「有数据支撑的可行或放弃」。

3. 与交付工程师相比

交付工程师接收已定稿的方案，负责安装、部署、集成与验收，工作起点是产品完成之后 ；FDE的工作起点远在产品定义之前------他参与需求挖掘、立项决策、方案权衡，并把交付阶段发现的现场问题持续反哺到需求与设计。

交付工程师面对的是确定性的部署任务 ，FDE面对的是不确定性的价值创造。

交付工程师是把标准化武器送到前线并教会使用的人；FDE是跟着部队冲锋、根据战况改装武器、并直接对战役结果负责的人。

1. 四角色对照总表

|-----------------|--------------|-------------|---------------|----------------------------|
| 对比维度 | 产品经理 | 架构师 | 交付工程师 | FDE（三合一） ​ |
| 核心产出​ | 需求文档、方案 | 架构设计、选型 | 部署集成、验收 | 从需求到回款的全链路结果​ |
| 工作起点​ | 需求收集 | 方案设计 | 产品定稿后 | 需求定义之前​ |
| 技术深度​ | 懂边界即可 | 最深 | 熟悉部署 | 懂实现，且懂业务​ |
| 现场卷入​ | 间歇性调研 | 基本不在现场 | 交付期在现场 | 全程驻留现场​ |
| 责任范围​ | 做什么 | 怎么搭 | 装得上 | 跑通，且产生价值​ |
| 成功标准​ | 需求文档通过评审 | 系统稳定／性能达标 | 按期上线 | 用户付费与留存​ |
| 与AI的关系​ | 用AI写文档 | 用AI生成代码 | 用AI做运维 | AI是四域共用的一次性员工​ |
| 组织位置​ | 职能竖井 | 项目外派 | 项目外派 | 业务最前线的常驻节点​ |

FDE不是要取代这三个岗位，而是指出：在AI杠杆加持下，一个复合型个体可以同时承担三者的核心职责。

---

六、六款产品的启示：一个FDE就是一条产品线

六款产品本身就是FDE方法论的具象化------共用一个硬件平台，靠Prompt知识库和内容资产构筑壁垒。

|-----------------------|----------------------|--------------------------------------------------------------------------------------|
| 产品 | 启示 | FDE动作 |
| 思库熊​ | 需求证据可以从书稿中来 | 把108个学习模型书稿变成可语音调用的知识库------****书稿就是知识库，FDE的工作是把它「装进系统」****​ |
| 拓境​ | 换Prompt包即换产品 | 把130计职场模型装进同一套内核，换一个Prompt包与小程序页面树，就是全新产品 |
| ****陪伴熊（基础版／亲情版）****​ | 双边需求必须双边满足​ | 老人要的是说方言、听戏曲、有人提醒吃药；子女要的是远程留言、情绪周报、知道爸妈安好------缺一边产品都不成立；再靠声音克隆升级出亲情版 |
| 记忆熊​ | 高敏感场景必须合规先行​ | 面对年死亡约1000万、约3000万直系亲属的潜在市场，团队没被市场规模冲昏头，而是把「不是复活、是可对话的纪念档案」作为定位，把禁用词、声音授权、数据销毁写进产品基因 |
| 情绪球​ | 隐私可以成为卖点​ | 儿童原始语音在设备端转写后立即丢弃，家长只能看摘要不能听原文，数据90天自动删除------最严格的隐私架构，反而成了家长付费的理由​ |

关于护城河：

核心壁垒不是硬件（ESP32谁都能买），不是模型（API谁都能调），而是垂直场景Prompt知识库、内容资产与订阅内容。

硬件是载体，内容是粘性，数据是护城河。

---

七、组织学本质：为什么不能新设一个部门

有人会问：传统组织里能不能新设一个部门来承担这些工作？

实践给出的答案是否定的。最后一公里的工作天然抗拒部门墙：

• 放进产品部 → 缺技术实现力；
• 放进研发部 → 缺业务话语权；
• 放进交付部 → 介入太晚，需求早已定型。

更要命的是，跨部门协作的交易成本会吃掉AI项目本就微薄的利润：需求在产品、算法、工程、业务之间来回传递，每传一次就失真一次，等信息走完流程，现场早已变化。

FDE模式的组织学本质，是把跨部门的外部协调，压缩成一个角色的内部整合------让一个对结果负责的人，同时握有判断需求、设计方案、动手实现、推动上线的完整信息与权力。

传统组织用「翻译链」对抗断层，每多一级翻译就多30%的信息损耗。FDE的思路相反：

取消翻译链，让一个被AI武装过的人直接站到业务现场，从需求一直做到交付。

八、三条行业真相：失败率的另一种读法

行业数据常被引用，却很少被读透。

|----------------------------------------|---------------------------------|----------------------|
| 真相 | 解读 | 对应解法 |
| 95%的AI项目失败，不是技术做不出来，是人工管不住全流程​ | 把失败主因从技术侧拉回管理侧 | FDE就是那个「管得住全流程」的角色 |
| 87%的工业AI项目死在阶段断层​ | 需求到设计、设计到技术、技术到交付，每条断层带都在批量吞噬项目 | 四阶段方法论的本质，就是给每条断层带架桥 |
| 90%的AI项目死在最后一公里规模化​ | POC的虚假繁荣，是最昂贵的自我欺骗 | 五阶段门禁专门对付它 |

三条真相合在一起，给出FDE的时代坐标：

技术不再是最稀缺的，把技术穿过四个阶段送达收入与口碑的能力才是。

这也是为什么本书的七篇结构（需求、设计、技术、测试、运维、交付、变现）不是七个学科的拼盘，而是一个角色的一套动作：

FDE不是四分之一个产品经理加四分之一个架构师加四分之一个项目经理，而是一个能在多个语言体系之间自由切换的完整的人。

---

九、从人力杠杆到系统杠杆：FDE时代的效率公式

传统组织的效率公式是加法：人手 × 工时 = 产出

AI时代的效率公式是乘法：产出 = (人 + AI) × 系统杠杆

其中，系统杠杆指的是把判断固化为流程、把流程固化为AI工作流的程度。

六款产品的5人团队之所以能跑出传统12---15人的产出，杠杆不在个人能力，而在三处系统化：

|--------------|----------------------------------|
| 位置 | 系统化内容 |
| 需求侧​ | AI访谈转译管道------87份访谈自动变214条结构化条目 |
| 内容侧​ | 卡片生产管线------每周20个模型的微调产能 |
| 运营侧​ | 周报与工单AI工作流------人类只处理例外​ |

系统杠杆的构建规律：

先把人的判断写清楚，再把判断交给AI。

反过来做（先上AI再想流程）的组织，得到的是「自动化的一团糟」------AI只是把混乱的流程跑得更快而已。

这也是本书把FDE定义为「角色」而非「工具使用者」的原因：杠杆的支点是人脑里的方法论，AI只是把力臂加长。

AI不是来辅助你的员工的，它是来重新定义「工作」本身的。

---

十、系统杠杆的三个安装位置

把判断固化为流程、把流程固化为AI工作流，说来一句话，装到组织里却有三个明确的安装位置：

|---------------|-------------------|------------------------|---------------|
| 安装位置 | 触发条件 | 产物 | 落入资产库 |
| 决策入口​ | 凡是被问过三次的判断 | 决策卡------背景、选项、决定、后果四格 | ADR库 |
| 流程节点​ | 凡是按固定顺序执行过三次的任务 | 流程卡------输入、步骤、验收标准三栏 | SOP库 |
| 复用界面​ | 凡是被两个以上产品或客户用过的能力 | 组件------接口、参数、边界三件套 | 组件库 |

三个位置对应三种典型的组织病症：

• 决策不落卡 → 陷入「换人就换判断」的循环，老员工的经验随离职蒸发；
• 流程不落卡 → 陷入「开会对接」的循环，协作成本随人数指数上涨；
• 能力不落组件 → 陷入「重复造轮子」的循环，第二个产品永远和第一个一样贵。

贯穿项目五人团队能做六款产品，靠的不是全能的人，而是三个位置都装了杠杆：12个月积累47条ADR、214张流程卡、23个共用组件。

【读者自检】

你的组织里，最近一次「同样的判断被重新争论」发生在什么时候？

如果答案是一周内​ → 系统杠杆还没有装上；

如果答案是「想不起来」​ → 杠杆已经在运转。

这就是FDE时代，组织与组织的真正差距。

---

十一、硬件创业的门槛塌陷：FDE时代的机会窗口

贯穿项目用 3575元启动资金 ​ 与 5人团队​ 做出了六款硬件产品------这在十年前是不可想象的。

门槛塌陷的三根支柱：

|------------------------|-----------------------------------|
| 支柱 | 具体表现 |
| 开发板与模组的白菜价​ | ESP32-S3模组 18元 |
| 云端能力的按量付费​ | ASR 0.006元/15秒、LLM 0.004元/千tokens |
| AI工作流对重复劳动的替代​ | 内容生产、客服初筛、数据周报 |

三根支柱共同把硬件创业的固定成本压到了个人可承受的量级------剩下的门槛只有一根：能不能像FDE一样贯通四个阶段。

单台成本参考：硬件BOM约124---130元，单台日均云端成本约0.28元。

一个人加一套AI工具链，就是一支队伍。

FDE在这个意义上不是大厂专属岗位，而是AI时代每一个想把事情做成的技术人的通用身份。

机会窗口的另一面，是竞争的同步塌陷：你能做的别人也能做。

贯穿项目的应对写在它的资产结构里------垂直场景Prompt知识库（书稿资产的结构化）、小红书内容资产（六周铺垫的复利）、订阅内容（戏曲／模型／记忆场景的持续供给）。

硬件与模型API都是公共的，这三样是私有的。

门槛塌陷时代的护城河公式：公共能力 × 私有资产 = 差异化。

---

十二、AI硬件创业自检七问

在动手做第一款AI硬件之前，先用七个问题自检------这是贯穿项目复盘时反推出来的「入场检查」。

|-------------|----------------------------|----------------------------|
| # | 自检问题 | 答不上来的后果 |
| 一问​ | 目标用户的关键时刻，现在用什么将就？ | 替代品账单空着，需求就是猜的 |
| 二问​ | 你的模型库／内容库，为什么比通用大模型更懂这个场景？ | 答不出私有沉淀，产品就是套壳 |
| 三问​ | 单台设备的全生命周期云成本算过吗？ | 设计阶段不算，交付阶段就变成惊吓 |
| 四问​ | 合规四文件里的授权链，你的产品需要哪几环？ | 涉他人声音、涉未成年人、涉逝者------越早想越好 |
| 五问​ | 五阶段门禁的第一道闸（POC）定在多少天？ | 超过60天的POC，大多在掩盖方向不清 |
| 六问​ | 首个量产批次卖不掉30%，现金流能撑几个月？ | 13周滚动表的红线，想清楚再下单 |
| 七问​ | 团队里谁负责把判断写成文档？ | 答不出人名，第一年结束后你只剩一堆产品，没有一家公司 |

七问里答不上来三个以上的，建议先补课再立项。

不是劝退，是把最贵的学费（量产之后才发现），换成最便宜的学费（动笔之前的自问）。

---

十三、金句收尾

不懂业务的AI工程师，就是企业最昂贵的「技术债」制造机。

明白了，保持 P02＝2.1、P03＝2.2，同属第2章「破局者：FDE是谁」 。下面是 2.2 节被截断后的完整续篇，接着「病毒三」往下写。

---

第2章　破局者：FDE是谁

2.2　未来程序员的新画像：最会提要求的脑＋最会做判断的眼（P03）

承接上文：已完成「价值坐标迁移」「提要求的三个硬功夫」「判断力的三个来源」，以及病毒一（勤奋的驴）、病毒二（技术原教旨）。

---

四、三种思维病毒：认知手术刀（续）

病毒三｜自证清白（知识囤积 ＝ 价值黑洞）

案例胶囊 ：Michael 是一家支付公司的「神」，核心系统每一行关键代码都经他的手。他不写文档（「说了你们也听不懂」），反对标准化（「我的方案就是最好的标准」）。心脏放了两个支架、刚从鬼门关被拉回来，团队群仍在疯狂@他------他成了公司最大、也最脆弱的单点故障。CTO 的评估只有一句：「这个人风险太高，得找个备份。」

病灶：把知识锁在大脑的私密金库里，用「没我不行」换取安全感。

知识囤积者的结局，是过劳死，或是被「冗余备份」后淘汰。你守着的不是金山，是即将引爆你自己的军火库。

三重后果：

|---------------|-----------------------------------------------------------------------------------|
| 陷阱 | 表现 |
| 能力陷阱​ | 你解决问题的能力越强，就有越多问题被送到你面前。你像永不疲倦的「人肉补丁」，哪里漏了堵哪里，直到自己千疮百孔 |
| 价值黑洞​ | 你的价值被绑定在「解决重复性问题」上。你永远在救火，没有时间去规划消防系统。你的时间单价，被无穷尽的「琐事救援」摊薄到极限 |
| 信任孤岛​ | 老板依赖你，但不敢提拔你------你「不可替代」也意味着「不可晋升」，你走了这一摊子谁管？同事需要你，也暗暗怨恨你------你的「留一手」，让他们永远无法独立 |

解药：立即搭建你的知识资产库

案例胶囊 ：Robert，核心推荐系统唯一能搞定的人。蹲在急诊室外，手里攥着脑梗早期的 CT 报告，手机仍在震动------团队在找他。他突然意识到：他四十多年赖以生存的经验，全锁在这个刚被医生宣判「随时可能宕机」的大脑硬盘里，一旦损毁，资产清零，且没有备份。

这不是「生病了」，这是整个「公司」的核心技术部门即将物理性损毁。

你以为你在用大脑创造价值，实际上，你是在用你唯一且不可再生的「生物硬盘」，为老板存储随时可以调用的「生产资料」。硬盘坏了，你的价值就归零了。

知识破产的三个现场：

1. 无复利------你熬夜解决的灵异 Bug，三个月后新人又踩进去，你不得不再熬一个通宵。你的经验，没有产生任何复利。
2. 无能见度------你做了关键决策救了项目，述职时只能说「我当时觉得...」；而善于写文档的同事，用清晰的决策框架拿走了荣誉。
3. 无法自证------被裁员后面对面试官，你说不出过去五年到底「厉害」在哪里。十年，只剩几个苍白的项目名和一堆过时的技术名词。

没有沉淀的知识，就像握在手里的沙。你握得越紧，它流失得越快，最终摊开手，一无所有。

对应动作：这正是上一节「系统杠杆三个安装位置」的落地------决策进 ADR 库、流程进 SOP 库、能力进组件库。

---

五、硬通货清单：投资这些抗周期的技术资产

案例胶囊：Joseph，45岁，前「CTO」，死于心梗。病床旁手机上的最后一条消息是：「服务器又挂了，这次真的找不到原因。」他死时账户里只有三万块，欠着六个月房贷。三年前那家靠营销裂变的公司倒闭后，他的「CTO」头衔和那套拼凑出来的「亿级用户架构」在求职市场无人问津------去面试时，年轻人问他 K8s 集群网络排查思路、JVM 调优如何关联业务漏斗，他只能重复「当年我们用户量很大」。

这就是技术资产的残酷分化：

绝大多数人用最宝贵的职业生涯，投资了一堆「框架熟练度」「业务逻辑背诵」这类随时贬值的泡沫资产。公司最先抛售的，就是这些无法穿越周期的装饰品。

而极少数人，早年默默投资了技术硬通货------他们在任何冬天，都是被争夺的战略物资。

硬通货一｜性能深度：你是成本杀手，还是资源黑洞？

所有人都在讨论「用哪个缓存框架」。如果你只能参与这种讨论，你就是个 API 调用员。

但如果你能一眼看出：

• 性能瓶颈不在缓存，而在 TCP 拥塞窗口设置不合理，导致长连接吞吐量上不去；
• 或者，是 JVM 的 GC 策略在高峰期引发 Stop The World，导致上游超时雪崩；

------你就是能从财务报表上直接抹掉一笔巨额服务器开支的财神。

当公司要「降本增效」时，优化业务的人可能被优化，而优化掉服务器成本的人，会成为老板的自己人。

在商业世界，能直接帮公司省钱的人，永远比只会帮公司花钱的人，活得更久、更稳。

硬通货二｜架构与决策能力：从写代码到定标准

路径升级：写代码 → 定标准 → 带项目 → 对结果负责。

这正对应 FDE 的四域贯通：不是你会写多少行代码，而是你能否在模糊、跨域、紧工期的约束下，给出一个能落地、能验收、能算清 ROI​ 的方案。

会做加法的是工程师，会做减法的是架构师，会做取舍并承担后果的，是 FDE。

硬通货三｜领域建模能力（FDE 的分水岭）

把业务黑话翻译成模型可执行的结构------提示词、知识库、工作流。

这是 FDE 与普通全栈工程师的分水岭。

硬通货四｜把判断固化为系统的能力

回到上一节的效率公式：产出 = (人 + AI) × 系统杠杆

系统杠杆的构建规律只有一条：先把人的判断写清楚，再把判断交给 AI。

反过来做（先上 AI 再想流程）的组织，得到的是「自动化的一团糟」------AI 只是把混乱的流程跑得更快而已。

---

六、本节小结：一张对照表

|-----------------|----------------|-----------------------|
| 维度 | 过去的程序员 | 未来的程序员（FDE画像） |
| 核心能力​ | 写得快、写得对 | 会提要求、会做判断​ |
| 与AI的关系​ | 竞争对手 | 指挥官​ |
| 价值来源​ | 代码产量 | 业务数据＋用户现场＋复盘沉淀 |
| 成功标准​ | 功能上线 | 用户付费与留存​ |
| 风险点​ | 写得不够快 | 陷入假经验／伪深度／知识囤积 |

做 AI 的指挥官，不做 AI 的竞争对手。

把价值可视化------汇报、数据、案例，一个都不能少。

---

七、金句收尾

未来的顶尖程序员，不再是最能写的手，而是最懂「提要求」的脑和最会「做判断」的眼。

第3章　能力模型：π型选手与五层思维框架

章眼：一专多能不是样样通，而是有一根主心骨。

3.1 FDE能力模型：一专多能的π型选手（P04）

【开头钩子】

什么都学一点叫浮躁，一专多能叫护城河。

【核心公式】

π型能力 ＝ 深度（专业）＋ 广度（业务／管理）＋ AI协同 ＝ 抗周期组合

一句话定义：

一个主赛道深度精通，其余赛道掌握边界逻辑------不求平均用力。

---

一、从T型到π型：多出来的那一竖是什么

1. T型结构：一横一竖的修炼心法

「一横」是技术雷达与认知广度

它代表你对技术生态全局的理解宽度。你无需成为每个领域的专家，但必须建立起一个动态更新的认知地图。

每月投入固定时间，像阅读财经新闻一样，扫描AI、云计算、边缘计算等领域的大趋势、关键术语和代表性公司。目标不是「精通」，而是------

能对话、懂关联、可判断。

这确保你在战略讨论中，不因对「大模型」「端侧推理」等概念茫然无知而陷入被动，并能洞察不同技术间的协同可能。

「一竖」是专业探钻与能力深度

它代表你在自身核心角色之上，选择 1---2个与业务紧密结合的技术领域​ 进行纵深学习和实践，直到能解决真实问题。

例如：一位产品负责人，可以围绕「用户体验」这个核心，把「前端技术」或「数据分析」作为其「一竖」，深入研究交互实现原理、性能指标或用户行为分析方法------目标是从「能提需求」升级到「能与工程师讨论实现优劣」。

广度决定你的视野半径，深度决定你的专业海拔。

无广度易坐井观天，无深度则流于空谈。

2. π型：多出来的第二竖

T型人才解决的是「能不能做 」；π型人才还解决「值不值得做、能不能变现」。

|-------------|-------------------|------------------|------------------------------------|
| 结构 | 第一竖（专业深度） | 一横（认知广度） | 第二竖（AI协同 × 商业变现） ​ |
| T型​ | 有 | 有 | 无 |
| π型​ | 有 | 有 | 有------把深度转化为结果的能力​ |

第二竖包含三层：

1. AI协同------把AI当成四域共用的一次性员工，你的产能不再等于你的工时；
2. 财务翻译------能把「接口响应从200ms降到50ms」翻译成「年省服务器成本250万」；
3. 价值能见度------让关键人物相信你正确（详见本节第五部分）。

深度决定你能不能进场，宽度决定你能不能兜底，AI协同决定你能不能一个人打完一场仗。

---

二、四域技能栈：一横的具体展开

π型的「一横」不是漫无目的的博学，而是四域边界逻辑------每个域你都要懂到「能对话、能判断、能兜底」的程度。

|--------------|---------------|---------------------------------------------|
| 域 | 核心技能 | 你要掌握的边界逻辑 |
| 需求域​ | 访谈、甄别、证据链 | 能判断真伪需求、能算期望价值、能写出可验收的量化标准 |
| 设计域​ | PRD、规格、取舍 | 能定非功能基线、能写清安全边际、能在评审会上说出「不做」的理由 |
| 技术域​ | 全栈、Agent、软硬一体 | 能跑通端到端、知道ESP32-S3的算力边界、知道7B模型端侧跑不动要降到1.8B量化 |
| 交付域​ | 门禁、商业、ROI | 能守五阶段门禁、能算清单台全生命周期云成本、能讲清这笔投入多久回本 |

四域不是四门课，是一个人的四副面孔------对老板是商业面孔，对业务是场景面孔，对工程是实现面孔，对客户是交付面孔。

时间分配参考：需求30% · 设计20% · 技术30% · 交付20%

---

三、底层操作系统：120个复合工程师心智模型

四域技能会过时，底层操作系统不会。这套操作系统由四类心智模型构成：

|--------------|--------------------|----------------------------|
| 类别 | 核心模型 | 用途 |
| 学习类​ | 分层解构、场景匹配、费曼检验 | 面对任何新技术，知道从哪个维度提问、关注哪些核心风险 |
| 调试类​ | 假设---验证---排除 | 线上故障、模型幻觉、效果下滑时的通用求解路径 |
| 成本类​ | 够用阈值、分层算力、ROI换算 | 在上线前就算清Token、算力与回本周期 |
| 复聚类​ | ADR决策卡、SOP流程卡、组件复用 | 把个人判断沉淀为组织资产 |

框架熟练度会贬值，心智模型不会------前者是资产，后者是生产资产的能力。

---

四、三种修炼方法：怎么长出π型

方法一｜构建你的「外接第二大脑」

在技术信息爆炸的时代，「知道什么」已远不如「如何连接与调用知识」重要。

三大支柱：

|----------------|--------------------------------------------------------------|
| 支柱 | 做法 |
| 卡片笔记法​ | 把获取的信息，用自己的语言提炼成一张张独立的、原子化的知识卡片 |
| 知识图谱​ | 主动建立连接------新建「边缘计算」卡片时，主动链接到「云计算」「5G网络」「物联网终端」，让知识从「点」连成「网」 |
| 费曼学习法​ | 用最简单的语言向非技术朋友解释清楚「容器化」，讲不清的地方就是你理解的盲区 |

你不是简单地收藏网页和文章（那是数字垃圾场），而是像一位严谨的图书管理员：采购编目 → 建立关联 → 调阅输出。

方法二｜在项目中完成认知跃迁（行动学习）

真正的FDE能力，无法在纯粹的阅读和思考中炼成。从「为学习而学习」，转向「为解决问题而学习」。

随身携带一份「技术思维实践清单」，在每个场景中主动激活它：

• 参加需求评审时自问：这个炫酷功能，背后的技术实现逻辑可能是什么？需要调用哪些数据和服务？
• 听取技术方案时追问：选A而非B，核心权衡是什么？是牺牲性能换开发速度，还是增加复杂度换扩展性？
• 处理线上故障时探究：从架构上看，这个单点故障是否可以避免？该如何建立更可靠的安全网？
• 规划新业务时思考：这对我们的技术能力储备提出了什么新要求？需要提前布局什么？

这就像在游泳中学会游泳------你不必先读完流体力学再下水，而是直接跳进泳池，在划水中感受浮力与阻力。

最好的练习场不在书本里，而在你下一个要解决的业务问题中。

方法三｜从输入者，转为输出者与连接者

个人的学习终有瓶颈，生态的智慧无穷无尽。

• 向内分享 ：就一个你研究清楚的新技术趋势，在团队内做一次简短分享------为了讲明白，你必须彻底学透；
• 向外输出：写一篇技术商业分析短文。写作是思维的终极整理，能暴露逻辑漏洞，并吸引同频者；
• 跨界共创：用业务方的语言，解释技术方案背后的用户价值、实现成本与风险，并提出建设性替代思路。

教是最好的学。

独行快，众行远。在技术的世界里，连接的价值远超独享，分享的回报远超索取。

---

五、能力必须被看见：从「沉默的武器」到「持剑的统帅」

案例胶囊：James，43岁，前首席架构师。半年前的技术评审会上，新来的年轻总监提出一个在他看来「充满架构异味、注定埋雷」的方案。他从CAP理论讲到故障案例，逻辑严密；对方只轻松一笑，转向CEO：「James说得有道理，但我们更要考虑业务敏捷性------我的方案虽然不完美，但能保证比竞品早一个月上线。」CEO点了点头。半年后，James坐在星巴克最便宜的角落改第87版简历。

病灶：绝大多数技术高手的悲剧，都死于「实力」与「权力」的错位------

你通宵论证，他一句话定性；

你修复了最难的Bug，他在汇报时轻描淡写；

你预见了所有风险，他说你「缺乏魄力」。

在职场，正确不重要，让「关键人物」相信你正确，才重要。

你的技术是矛，话语权是握矛的手。手没了，再锋利的矛，也只是地上的一根铁棍。

三重跃迁 ：实现者 → 仲裁者 （能定义什么是好方案）→ 布道者（能让别人相信你的定义）

|--------------|------------------------|--------------|
| 层级 | 话语 | 组织定位 |
| 实现者​ | 「这个我能做」 | 可被替代的执行资源 |
| 仲裁者​ | 「这个方案在现有约束下不可行，但B方案可以」 | 技术判断的权威 |
| 布道者​ | 「我们要做的是B，因为它在三个月内能带来X」 | 影响决策的合伙人 |

把价值可视化------汇报、数据、案例，一个都不能少。

---

六、自检：你现在站在π型的哪个位置

|---------------------------|-------------------------------------|
| 自检问题 | 检查点 |
| ****① 你的主赛道是什么？****​ | 能否说出一个别人替代不了你的技术纵深？ |
| ****② 你的边界逻辑覆盖到哪几个域？****​ | 需求／设计／技术／交付四域，每个域能否做到「能对话、懂关联、可判断」？ |
| ****③ 你的第二竖长出来了吗？****​ | 能否把技术成果翻译成财务语言？你的贡献，关键人物看得见吗？ |
| ****④ 你的判断沉淀了吗？****​ | 过去一年，你留下了多少张ADR、SOP、组件？ |
| ****⑤ 你的经验产生复利了吗？****​ | 你熬夜解决的Bug，三个月后新人还会再踩一次吗？ |

判读标准：

• 五问全答得出 → π型已成型
• 只能答出①② → 仍是T型，第二竖缺失
• 连①都答不出 → 尚未建立主赛道，当务之急是选定并深钻

---

七、金句收尾

复合工程师不是平均用力，而是一个主赛道深度精通，其余赛道掌握边界逻辑。

下面按 第1篇 · 第3章 · 3.2节 ​ 归位。这页原文有个必须先说明的问题：主体内容（DAO-01～SHI-03 共约20个模型编号、《原则》/芒格/《价值》三段式对照、以及"第八篇补齐产品能力""第九篇以《原则》为第一性原理"）来自另一套技术管理手册的模型库索引，与本体系的 8篇59章 目录不对应------本书全书只有8篇，不存在"第八篇跨域产品经理""第九篇研发全生命周期"。

我的处理：五层框架本体全部保留并展开，把散落其中的高价值素材（五步流程、管理节奏、极度求真话术、原则库维护）吸收为五层的运转机制，模型库索引部分转为归位提示。

---

3.2　道法术器势：FDE的五层思维框架（P05）

【开头钩子】

为什么有人做项目越做越顺？因为他们把这五层想清楚了。

---

一、为什么需要五层框架

多数人学方法，只学「术」------拿走一个模板、一张清单、一套提示词。用得好，能解决一个点；用不好，三天就打回原形。

术能救一次火，道法术器势能让你不必天天救火。

FDE要面对的是跨域、不确定、强现场的工作，单点能力必然失效。你需要一个自上而下的完整框架：

|------------|--------------------|-----------------------------|
| 层 | 回答的问题 | FDE语境 |
| 道​ | 为什么做、相信什么​ | 使命愿景决定项目会不会半途而废 |
| 法​ | 怎么协作​ | 流程、制度、RACI------让团队不靠自觉，靠机制 |
| 术​ | 具体怎么办​ | 访谈模板、评审清单、门禁标准 |
| 器​ | 用什么放大​ | Agent、工具链、平台------让1个人顶1个团队 |
| 势​ | 何时做、顺什么风​ | 行业周期与技术节奏 |

道是方向盘，法是路网，术是驾驶技术，器是车，势是风向。

五层缺一层，车都能开，但开不远。

---

二、道：为什么做、相信什么

道解决的是「这件事值不值得做、做不做得完」。

使命愿景价值观（MVV）不是墙上的标语，而是招聘、绩效、晋升、淘汰的裁判标准。

技术管理者必须能完成一次翻译：

公司使命 → 技术团队今年要打赢什么仗。

翻不出来，团队就会陷入「看起来很忙、年底说不清贡献了什么」的困境。

三条检验（任何「法／术／器」上线前必问）：

1. 是否简化了协作？
2. 是否对齐了 MVV？
3. 是否为了管理而管理？

三条不过，砍掉。

流程是手段，不是政绩。

建设时机：团队>50人、并购整合、文化冲突、新人占比>40%/年时，道层必须优先重建。

有道无术，术尚可求；有术无道，止于术。

---

三、法：怎么协作

法解决的是「不靠自觉，靠机制」。

1. 双流程模型

|---------------|------------|-------------|
| 流程 | 牵头 | 内容 |
| 项目流程​ | PMO | 立项、评审、发布、事故 |
| 人事流程​ | HRBP | 招、用、养、留、去 |

两条流程都从复盘抽象出标准流程，再用工具落地。

输出不好，先改系统设计，而不是只换人。

2. 制度库：把规范沉淀成可检索的资产

Wiki/Confluence 沉淀：DB规范、分支规范、发布规范、安全规范、测试规范......变更走 PR 式 review。

飞行员清单式的严谨，可以避免低级错误。

制度不是约束，是把「踩过的坑」变成「后来人的护栏」。

3. 标准化五一体化

技术／业务／监控／运维／管理五一体化，核心是统一选型、统一脚手架、统一协议、统一结构。

4. 流程初心检验（奥卡姆剃刀）

每条流程都要用两把尺子验收：

• 是否降低了协作成本？
• 是否提升了效能？

如无必要，勿增实体------流程与架构同理。

员工抱怨「流程太多」的那天，就是流程审计的启动日。

---

四、术：具体怎么办

术解决的是「手上有没有可执行的动作」。

FDE的术，覆盖五类场景：

|-------------|--------------------------|
| 场景 | 工具 |
| 需求​ | 访谈模板、证据链转译表、灵魂三问 |
| 设计​ | PRD模板、设计评审十二问、ADR决策卡 |
| 技术​ | 状态图规范、评测集、调试假设树 |
| 交付​ | 五阶段门禁、RACI矩阵、45分钟周会 |
| 团队​ | 招用养留去------胜任力模型、双通道、AB角 |

关于「人」的四条硬规矩：

1. 招：招对人是ROI最高的投资。标准化面试＋胜任力模型＋试用期考核闭环。
2. 用 ：30人职能型 → 50人产品型 → 100+混合矩阵，权责与KPI双轨清晰。
3. 养：P/M双通道＋内部分享＋成长预算。人才是长期资产，不是消耗品。
4. 留／去 ：工程师重成就------挑战性工作＋认可＋合理薪酬；激励向奋斗者倾斜，负向激励慎用。

冗余原则：

核心岗位必须 A+B 角，互相备份。关键系统要冗余，关键的人也要。

核心TL／架构师／On-call 只有一个人熟，就是组织最大的单点故障。

---

五、器：用什么放大

器解决的是「让1个人顶1个团队」。

FDE的器，有三层：

|-----------------|-----------------------|-----------------|
| 层级 | 内容 | 效果 |
| Agent层​ | 多Agent协同、RAG知识库、记忆流水线 | 把重复判断交给系统 |
| 工具链层​ | 访谈转译管道、卡片生产管线、周报工单工作流 | 人类只处理例外 |
| 平台层​ | 五一体化平台、统一脚手架、组件库 | 第二个产品只有第一个的零头成本 |

器之戒：

工具服务于人，不是人服务于工具。

先上AI再想流程的组织，得到的是「自动化的一团糟」------AI只是把混乱的流程跑得更快而已。

正确顺序只有一条：

先把人的判断写清楚，再把判断交给AI。

---

六、势：何时做、顺什么风

势解决的是「时机对不对、风往哪吹」。

|-------------|--------------------------------|-------------------------|
| 类型 | 内容 | 观察方式 |
| 外势​ | 行业周期、技术节奏、政策与合规走向 | 扫描AI、云计算、端侧推理的大趋势与代表性公司 |
| 内势​ | 天时（公司战略窗口）、地利（资源与数据）、人和（团队与协同） | 季度Steering复盘、年度架构演化路线图 |

顺势而为，不是投机；造势而成，才是本事。

在风口上，猪都能飞；但风停之后，摔死的也是猪。势与实力，缺一不可。

长期主义是势层的底层心法：

长期主义不是一种选择，是一种能力------是时间复利的受益者。

---

七、五步流程：五层框架的运转引擎

五层框架不是静态的陈列，它靠一个五步循环持续运转：

|---------------------------|-----------------------------|
| 步骤 | 研发场景对照 |
| ① 设定目标 Goals​ | 商业计划、Charter、OKR、成功指标 |
| ② 识别问题 Problems​ | 监控表、blocker、缺陷趋势、velocity下降 |
| ③ 诊断根因 Diagnoses​ | RCA、5 Whys、贡献模型低分原因 |
| ④ 设计方案 Designs​ | ADR、WBS、Remediation、架构方案 |
| ⑤ 执行任务 Tasks​ | Sprint、PR、Runbook、行动项闭环 |

两条铁律：

不要在②未完成时跳到⑤------问题没看清就动手，是最大的浪费。

不要在③含糊时开始④------根因没诊断清，方案只是另一场试错。

---

八、管理节奏：把五层装进日历

|-------------|-------------------------------------------|-------------|
| 周期 | 动作 | 对应层 |
| 日​ | 站会只报事实与 blocker；blocker 超 SLA 按升级路径 | 法·极度求真 |
| 周​ | Top10 风险＋问题日志新增项 review | 法·机器思维 |
| 双周​ | 设计／架构会，输出 ADR 或 Decision Log | 术·可信度加权 |
| 月​ | Steering：Dashboard RAG＋CPI/SPI；原则违背案例复盘1条 | 道·痛苦＋反思 |
| 季​ | 原则库更新发布；绩效／晋升对照 MVV 与贡献模型 | 道·人岗匹配 |
| 年​ | 外势扫描＋架构演化路线图 | 势·拥抱现实与进化 |

---

九、极度求真：管理者的五句话

|------------|-------------------------------|
| 场景 | 话术 |
| 面对模糊判断 | 「我不确定，数据是什么？」 |
| 面对一致同意 | 「反对意见是什么？谁最可信？」 |
| 面对追责 | 「这是改人 还是改机器？」 |
| 面对冒险决策 | 「如果失败，我们会在问题日志里写什么？」 |
| 面对短期诱惑 | 「二阶后果是什么？」 |

技术管理者每日应问：今天团队是在「求真」，还是在「好看」？是在「改机器」，还是在「怨人」？

---

十、原则库：让组织原则像代码一样版本化

达利欧的原则同样适用于工程组织：组织原则应像代码一样版本化。

|---------------|------------------------------------------------------------|
| 机制 | 规则 |
| 触发更新​ | 每次P0／重大项目偏差后 48小时内​ 提案更新 |
| 定期合并​ | 季度 Principles Review：合并重复、删除过时 |
| 新人必读​ | 本季10条原则 ＋ 2个违背案例 |
| 分区维护​ | Life Principles / Work Principles / Engineering Principles |

原则不写下来，就只是管理者心情的别名。

---

十一、自检：你的五层缺哪一层

|------------|-----------------------|--------------|
| 层 | 自检问题 | 缺失信号 |
| 道​ | 团队今年要打赢的那一仗，能用一句话说清吗？ | 年底说不清贡献了什么 |
| 法​ | 出问题有RACI吗？流程有专人维护吗？ | 靠人盯、靠自觉、靠加班 |
| 术​ | 关键场景有可复用的模板和清单吗？ | 每次从头开始 |
| 器​ | 有把判断固化成AI工作流的资产吗？ | 人一走，能力归零 |
| 势​ | 知道行业下一个周期在哪吗？ | 跟风选型、追新模型 |

五层全有 → 项目越做越顺；

缺道 → 半途而废；缺法 → 全靠人治；缺术 → 每次重来；缺器 → 规模上不去；缺势 → 逆风狂奔。

---

十二、金句收尾

道解决为什么做、相信什么；法解决怎么协作；术解决具体怎么办；器解决用什么放大效能；势解决何时做、顺什么风。

下面按 第1篇 · 第4章 · 4.1节 ​ 归位。这一页的核心矛盾我先说清楚：你给出的素材里，真正属于 P06 的只有「性价比公式 + 成本/资本 + 三级台阶 + 向上管理 + 权力地图 + 路径抉择」这一条主线，其余大部分（Kevin/Robert/David/George/Luke/William/Benjamin/Michael/Samuel 九段苦情小说、「职场暗礁图·人情世故」「抖音网红秀才」「李佳琦」「羡慕老爷的狗腿子」）要么是重复渲染，要么与本书专业定位冲突。

我的处理：主线全部保留并结构化，九段小说压缩为5个案例胶囊，厚黑学与跑题素材单列建议删除。

---

第4章　一天与一生：FDE的实战切片与职业路径

章眼：把一天过明白，才谈得上把一年过明白。

4.1 35岁的两条路：成本，还是资本（P06）

【开头钩子】

年龄不是问题，性价比才是。

---

一、性价比公式：分母正在变大

公司计算一个人的价值，从来只用一道题：

性价比 ＝ 产出 ÷（薪资 ＋ 管理成本 ＋ 风险）

AI时代，这道题的分母被重新计算了：

|---------------|------------|-------------------|
| 变量 | 过去 | 现在 |
| 薪资​ | 随年限递增 | 35岁后进入高位区 |
| 管理成本​ | 沟通成本低 | 需求模糊、跨部门协同，沟通成本陡增 |
| 风险​ | 稳定性尚可 | 家庭、健康、精力分配的不确定性上升 |

35岁不是魔法数字，是HR表格里「成本／产出比」开始倒挂的拐点。

分母变大，路只有一条------改分子。

分子由三项构成：产出价值 × 可见度 × 不可替代性。

内卷卷的不是努力，是同质化的低价竞争。

AI替代的不是人，是不会用AI、只会重复劳动的「旧版本的你」。

---

二、两条路：成为成本，还是成为资本

|---------------|----------------------|----------------------|
| 维度 | 成本 ​ | 资本 ​ |
| 能力结构​ | 只会执行、可被AI替代的单一技能 | 能整合需求、产品、技术、交付的复合能力 |
| 计价方式​ | 按工时零售 | 按结果批发 |
| 时间曲线​ | 越用越贬值 | 越用越增值（复利） |
| 组织定位​ | 可被替换的资源 | 不可或缺的合伙人 |
| 典型画像​ | 熟练的「API调用员」 | 能定义问题并跑通闭环的人 |

成本是一次性消耗品，资本是能生息的资产。

35岁，要么成为成本，要么成为资本。中间没有缓冲地带。

FDE路径：

π型技能 × 商业思维 ＝ 从劳动力到资本的身份转换

---

三、升维作战：从任务到项目到势力

案例胶囊：David，部门公认的「救火队长」。老板说明天上线，他熬通宵；同事说有诡异Bug，他放下手头的活。三年后他因急性心肌炎住院，第三天公司就找来外包顶替了他。妻子离开时留下一句话：「这个家是你的旅馆，而你是公司的永动机。」

病灶：困在「任务地狱」第一层，把职场活成一张无限拉长的待办清单。

三级台阶

|-----------------|---------------------------|---------------------------|------------------------------------------------------------|
| 层级 | 状态 | 思考方式 | 结局 |
| 第一层·任务​ | 老板派活，你接活 | 「这个怎么做？」 | 成为「好用」的工具------越可靠，越收到更紧急的任务，直到被更年轻、更便宜的棋子替换​ |
| 第二层·项目​ | 从被动接Bug，到主动发起「Bug源头治理」 | 「为什么总有这种Bug？能否系统解决？价值多大？」 | 你从「手」变成「脑」，开始创造可量化的超额价值（如「故障排查效率提升50%」） |
| 第三层·势力​ | 不只解决问题，而是经营这个问题领域 | 「围绕这个领域，我能连接谁、建立什么规则？」 | 你连接运维、测试、业务方，建立虚拟组织，制定协同规则------成为分配任务的人，而不是接任务的人​ |

在任务层，你的勤奋，是你为自己亲手戴上的、最华丽的枷锁。

学会做项目，是把你的时间从「零售」变成「批发」------你不再卖小时，开始卖解决方案。

你用健康的砖，砌的是别人晋升的墙。

---

四、向上管理：交付「感知」与「安全感」

案例胶囊：George 连夜修复了导致核心交易链路瘫痪的重大Bug------那是他本周解决的第三个P0。早会上他汇报完通宵成果，老板却皱眉打断：「所以，为什么系统总是出这种问题？下次怎么能保证不再发生？」一个月后，部门优化名单上有他，理由是「很勤奋，但感觉总在救火，不能从根本上让我放心」。

感知错位：

|-----------------|-----------------------------|
| 你认为 | 老板认为 |
| 我搞定了最难的Bug，我是英雄 | 为什么总有这种Bug？能不能提前预防？下次还会不会有？ |

结果 ：你的功劳是「止血成功」，你的「过错」是让老板「失血受惊」。在老板的情感账户里，你存了一笔小钱（解决事），却透支了巨额的安全感 和信任。

在职场，你提供的不仅仅是代码，更是你老板的「情绪稳定性」。

你让他安心，他让你安全；你让他焦虑，他就会想换掉你这个「焦虑源」。

向上管理的两件核心交付：

1. 交付「感知」 ------把复杂的技术工作，翻译成老板听得懂的商业价值语言 和风险控制结果。用周报、专项汇报、数据看板，让他「看见」你的价值。
2. 交付「安全感」------不只汇报「发生了什么」，更要回答「下次怎么不发生」。

没有感知的功劳，等于没有发生。你的苦劳，只是你个人的行为艺术。

工具：SCQA 故事化汇报

|---------------|------------------|---------------|
| 结构 | 内容 | 要点 |
| S 背景​ | 1---2句无可争议的事实 | 简洁、客观，建立共同认知 |
| C 冲突​ | 突发事件、障碍、与预期不符的转折 | 故事的引擎，要足够尖锐 |
| Q 问题​ | 自然引出的核心开放式疑问 | 精准，直指决策点 |
| A 答案​ | 你的核心建议或请求 | 直接回应问题，具有可操作性 |

示例：

「领导，A项目已按计划完成第一阶段开发，原定下周进入测试（S）。但我们刚发现第三方关键数据接口无法调通，对方表示修复至少需一周（C）。如果等待，上线必然延迟，可能错过市场窗口------我们是被动等待，还是主动找替代方案？（Q）我建议启动备用方案：由小张用两天自建模拟接口先保障测试，需临时从B任务抽调他，并申请约XXX元云端数据服务预算，请您授权协调（A）。」

汇报的本质是说服，而最好的说服，是讲一个好故事。

背景冗长是大忌------背景不是历史课，超过3句就会失焦。

---

五、价值分配器：测绘你的权力地图

案例胶囊：Robert 带着两个新人，熬了无数通宵攻克老板 David 力推的「技术创新项目」，技术评审满堂彩，他觉得晋升稳了。年终架构调整，整个小组被优化。他去找 CTO 申诉，只得到一句：「工具很好，但公司明年战略是降本增效，所有不能直接看到业务增长的项目，预算都要砍掉。」

病灶 ：价值分配器盲症------你以为在为公司创造价值，实际上只是在为你「以为」的重要人物创造价值。

在职场，看不清「水阀」在哪里的努力，本质是一种方向性自杀。

给唐僧打工，你要会取经；给曹操打工，你要能打仗。你对着唐僧炫耀攻城略地，结局就是被逐出师门。

不画权力地图的三重后果：

|---------------------|---------------------------------------|
| 后果 | 表现 |
| ****你成为「代价」****​ | 部门需要有人为失败负责时，最不懂权力关系、最不会辩解的你，是完美的「代价」 |
| ****你的价值被「清零」****​ | 项目若不是权力核心人物关心的，在公司的价值评估体系里账面价值就是零 |
| 你被「信息孤岛」隔离​ | 战略调整、资源倾斜、人事变动的关键信息都会绕过你，你总是最后一个知道 |

在职场，你的价值不是你创造的价值，而是「关键人物」认为你创造的价值。看不清谁手握天平，你的一切努力，都无法上秤。

行动：列出你的「命运董事会」5人名单

回答三个问题：

1. 谁的预算变化会直接影响你的项目存亡？
2. 谁在晋升会上能为你的名字背书？
3. 谁的一句话，能让你的优先级从第5位跳到第1位？

---

六、破局工具：复盘SOP

无复盘，无翻盘。真正的成长，发生在对过去的深度凝视之中。

五步复盘法：

|-----------------|---------------------------------------------------------------------------------------------------|
| 步骤 | 内容 |
| ① 回顾目标​ | 清晰、准确地回顾初始目标或期望结果（尽可能量化） |
| ② 评估结果​ | 客观陈述实际达成，与目标对比，明确达成、未达成部分及意外发现 |
| ③ 分析原因​ | 深挖成功关键因素与失败根本原因，追问至流程与系统层面，而非仅归因于个人 |
| ④ 总结规律​ | 固化（To Keep） ​ 哪些有效做法应坚持推广／改进（To Improve） ​ 哪些可优化／****停止（To Stop）****​ 哪些错误行为须立即终止 |
| ⑤ 形成文档​ | 整理成文档，同步相关方，归档至团队知识库 |

四原则：量化目标 · 对事不对人 · 深度归因（至少追问5个「为什么」）· 行动导向

这与 P02「系统杠杆三个安装位置」完全咬合：决策进ADR库、流程进SOP库、能力进组件库------复盘就是把个人经验转化为组织资产的动作。

---

七、四条路径的天性裁决

案例胶囊：William，42岁，前首席架构师。厌倦「务虚」、羡慕管理者的「威风」，跳槽任CTO。结果：无法忍受向毫无技术背景的CEO解释「为什么需要三天而不是三小时」，怒摔电脑；把架构师的完美主义灌输给团队，代码评审变成人格羞辱，三个月逼走一半核心成员。两年后，胃癌晚期，病床上收到前妻的抚养费强制执行传票。

核心诊断：

职业路径的选择，不是追求「我应该成为什么」，而是判定「我本质上是什么」。

选错职业路径，是成年人对自己的终极暴力------选错公司是伤筋动骨，选错路径是选错物种。

用「本能厌恶」反向导航：

以下哪件事，会让你在持续经历时，产生灵魂级的厌恶与窒息感？

|-----------------------------------------|--------------------------------------------------------|---------------------------------------------|
| 选项 | 你的画像 | 适配路径 |
| A.​ 反复向毫无技术背景的人，解释一个在你看来简单至极的问题 | 你是纯度的信徒------快感来自与复杂逻辑和精密系统的对话，而非与混沌人性和模糊需求的周旋 | 领域专家／深度架构师（管理、产品、创业路上遍布此类场景，那是你的地狱） |
| B.​ 长时间独自面对一个狭窄难题，无人交流、无即时反馈 | 你是连接的信徒------能量来自人与人的碰撞与协同放大 | 技术管理／FDE​ |
| C.​ 在资源不足、方向不明时，仍要拍板并为结果兜底 | 你是确定性的信徒------需要在清晰边界内做到极致 | 专家／架构，慎入创业 |

四条路径对照

|-----------------|--------------|--------------|-------------------------------------------------------------|
| 路径 | 核心能力 | 变现方式 | 致命陷阱 |
| 领域专家​ | 垂直深耕＋持续输出 | 咨询变现 | 「深井效应」------你挖的井被时代填平，你便被活埋；越精通，越被绑死在那台「老爷机」上 |
| 架构师​ | 系统设计与权衡 | 项目主导／技术负责人 | 完美主义暴力------把架构洁癖强加给团队与业务，忘了「够用阈值＋死线」 |
| 技术管理​ | 搭系统、责任到人 | 组织效能 | 系统性精神衰竭------每天16小时，12小时在开会、扯皮、安抚情绪；你的时间属于所有人，除了你的家 |
| 创业/FDE​ | 四域贯通＋商业闭环 | 产品与现金流 | 三条路全都要------既想A的纯粹，又想B的影响力，还觊觎C的财富，最终在撕裂中耗尽生命力 |

路径三·业务＋技术复合------最抗裁的翻译官：懂业务的技术人、懂技术的业务人。这正是 FDE 的定位，已在 P02、P04 完整展开。

---

八、FDE路径：完成身份转换

回到本节主线------35岁破局，FDE给出的答案是一个公式：

π型技能（一专多能）× 商业思维（算得清ROI）× 系统杠杆（AI协同）＝ 从劳动力到资本

|-------------|------------------|--------------------|
| 维度 | 转换前（劳动力） | 转换后（资本） |
| 计价​ | 时薪 × 工时 | 项目价值分成／产品收益 |
| 产出​ | 线性（1个人1份活） | 指数（1个人＋AI＋组件库） |
| 风险​ | 单点被替换 | 掌握完整责任线，不可替代 |
| 身份​ | 执行者 | 对最终结果负责的人​ |

FDE不是让你更累地干活，是让你换一种计价方式。

---

九、自检：你现在站在哪条路上

|--------------------------|---------------|----------------|
| 自检问题 | 成本项信号 | 资本项信号 |
| ****① 你的产出能被AI替代吗？****​ | 多数能 | 需要现场判断与跨域整合 |
| ****② 你按什么计价？****​ | 时薪、工时 | 项目价值、商业结果 |
| ****③ 你在第几层台阶？****​ | 任务层 | 项目层／势力层 |
| ****④ 关键人物看得见你的价值吗？****​ | 靠代码说话 | 有数据看板与商业语言 |
| ****⑤ 你知道水阀在谁手里吗？****​ | 只认识直属老板 | 有完整的「命运董事会」地图 |
| ****⑥ 你的经验产生复利了吗？****​ | 每次从头开始 | 有ADR／SOP／组件库沉淀 |

判读 ：≥4项落在「成本项」→ 高危，优先补②和⑥ ；≥4项落在「资本项」→ 已在FDE路径上。

---

十、金句收尾

35岁，要么成为成本，要么成为资本。中间没有缓冲地带。

下面按 第1篇 · 第4章 · 4.2节​ 归位。

先说明：你粘贴的内容里，P07 真正的新素材只有「开头钩子 + 五条时间线（上午/午间/下午/傍晚/晚间）」 ；其余约 2000 字（Kevin、Robert 两段小说、「AI时代多一层绞杀」「版本V2.0/全书300页」）与 P06（4.1节）完全重复，我在上一节已完整处理，此处不再重复收录。

另外，你给的【金句收尾】「实验室里再完美的模型，也抵不上车间里一线工人的一个真实痛点」是 P01 死法二​ 已用过的句子，放在 P07 收不住「24小时全天穿越」的主题，我在文末给了替换建议。

---

4.2　一个FDE的24小时：全天角色穿越实录（P07）

【开头钩子】

一个人怎么同时干需求、设计、技术、交付四件事？

答案不是「他比别人更能熬」，而是------他把一天切成了四个域，每个域用不同的脑子，且域与域之间有明确的交接物。

下面这张时间表，是贯穿项目里一个普通周二的真实切片。

---

一、全天时间表总览

|-------------|-----------|-----------------------------|------------------|
| 时段 | 域 | 核心动作 | 产出物 |
| 上午​ | 需求域 | 客户现场访谈，只记原话不下结论；回程完成证据链三级转译 | 证据链卡片、A级需求条目 |
| 午间​ | 设计域 | 15分钟走查四问，第一问永远是「用户从哪来」 | PRD增量、设计决策卡 |
| 下午​ | 技术域 | 架构评审30分钟 ＋ Agent联调，问题当场上墙 | 状态图、Agent联调记录 |
| 傍晚​ | 交付域 | 跨部门周会45分钟、工单分级处理、更新13周现金流表 | RACI更新、工单分级、现金流表 |
| 晚间​ | 复盘域 | 当天问题沉淀为ADR与评测集，写一条下周就生效的新机制 | ADR、评测集增量 |

一个人跑四域，靠的不是「全能」，是每个域都有明确的输入物与交接物------上一个域的产出，就是下一个域的输入。

---

二、上午｜需求域：蹲现场，只记原话不下结论

地点：客户现场（不是会议室）

动作要点：

1. 只记原话，不下结论------用户说「我想听俺们老家那段戏」，你就记「我想听俺们老家那段戏」，不要当场翻译成「需要方言语音识别」。翻译是回程的事，现场一翻译，信息就开始失真。
2. 记录三层信息 ------用户的原话 、他的犹豫 、他放弃使用的动作。真相往往不在原话里，在后两者里。
3. 打开「灵魂三问」火力侦察 ：
   • 这个需求解决哪个业务指标的什么问题？
   • 完美实现后，期望指标提升多少？有历史数据或行业基准吗？
   • 上线后如何衡量成功？看哪几个数据、观察多久？

回程动作｜证据链三级转译：

用户原话 → 场景痛点 → 产品语言

|-------------------|-------------------------------------|
| 层级 | 示例 |
| 第一级·原话​ | 「我想听俺们老家那段戏」 |
| 第二级·痛点​ | 老人不会用标准普通话指令，现有语音交互在方言场景直接失能 |
| 第三级·产品语言​ | 方言ASR前置模块 ＋ 戏曲内容库检索，识别率≥85%，响应≤1.5s |

产出物：证据链卡片、A级需求条目（进 P0 需求清单）

现场不翻译，是纪律。你在会议室里替用户想的每一个「他应该是想说......」，都是需求的污染源。

---

三、午间｜设计域：15分钟走查四问

时间盒：15分钟。超过就说明需求没吃透，回去补。

走查四问（顺序不能变）：

|--------------|-----------------|----------------------------------------------------|
| 问序 | 问题 | 为什么是第一问？ |
| 第一问​ | ****用户从哪来？****​ | 不知道用户从哪个入口进来，后面三问全是空转------没有入口的需求，等于没有用户​ |
| 第二问​ | 他要在几步之内拿到结果？ | 定义任务路径与体验基线 |
| 第三问​ | 出错了怎么兜底？ | 定义非功能基线与降级方案 |
| 第四问​ | 这个方案的成本上限在哪？ | 定义够用阈值，防止过度设计 |

为什么第一问永远是「用户从哪来」：

大量AI产品的死因，不是功能不够，是用户根本找不到入口。陪伴熊的第一版设计把语音助手藏进了二级菜单，老人三天没找到------功能全对，路径全错。

产出物：PRD增量、设计决策卡（进ADR候选池）

会做加法的是工程师，会做减法的是架构师；而减法最快的一刀，是砍掉那些「用户根本走不到」的功能。

---

四、下午｜技术域：30分钟评审 ＋ Agent联调

上半场：架构评审30分钟

铁律：不开没有 prepared material 的评审会，30分钟硬切断。

评审四查：

1. 查链路------需求拆解 → 工具调用 → 流程执行 → 结果校验，全链路是否闭合？
2. 查兜底------模型幻觉、超时、降级，每一环有没有 fallback？
3. 查成本------Token、算力、端侧内存，上线前的估算值是多少？
4. 查风控------Prompt注入、越权访问、数据留存，有没有硬边界？

下半场：Agent联调，问题当场上墙

上墙规则：

|--------------|--------------------------|
| 问题类型 | 上墙处理 |
| 能当场改的 | 当场改，不进清单 |
| 需要跨模块协同的 | 上墙写明「责任人＋时间点」，当日不清零则次日升级 |
| 需要外部依赖的 | 上墙并同步至工单系统，标记 SLA |

问题不上墙，就会上床------你回家躺下了，它还在脑子里转。

产出物：状态图、Agent联调记录（进技术阶段交付物六件套）

---

五、傍晚｜交付域：三件事，一小时收口

事项一：跨部门周会 45分钟

硬规则：

• 只报事实与 blocker，不报进度流水账；
• blocker 超 SLA 按升级路径走，不在会上求人；
• 会前发材料，会上只做决策。

协同不是开个会，而是让每个人都知道：做成了有奖励，做砸了有人担。

事项二：工单分级处理

|-------------|------------|--------------|
| 级别 | 判定 | 响应 |
| P0​ | 核心链路不可用 | 立即处理，30分钟内同步 |
| P1​ | 主要功能受损 | 当日处理 |
| P2​ | 次要功能／体验问题 | 本周排期 |
| P3​ | 建议／优化 | 进需求池，下次评审 |

事项三：更新13周现金流表

为什么是FDE亲自更新：

交付域的终点不是「验收单签字」，是钱能不能回来、下个季度还撑不撑得住。

现金流表是FDE唯一不能外包的表格------外包了它，你就从「对结果负责的人」退化成「对交付负责的人」。

产出物：RACI更新、工单分级清单、13周现金流表

---

六、晚间｜复盘域：把今天变成明天的资产

三件事，缺一不可：

1. 当天问题 → ADR

凡是今天出现的需要判断的取舍 ，写成决策卡四格：背景、选项、决定、后果，进 ADR 库。

2. 当天错误 → 评测集增量

模型今天说错的每一句话、Agent 走错的每一步，都进评测集------今天的错，就是明天的测试用例。

3. 写一条「下周就生效」的新机制

这是全天最重要的一条。复盘不落到「下周就改的具体动作」，就是抒情。

|--------------------|-------------|--------------------|
| 今天发生的事 | 沉淀为 | 下周生效的机制 |
| 客户临时改了三次需求 | ADR | 需求变更走「门」：超三次触发重新立项 |
| Agent把A用户的记忆串给了B用户 | 评测集增量 | 记忆检索增加用户ID硬隔离校验 |
| 周会上扯皮15分钟无结论 | SOP | 会前发材料，会上只做决策 |

无复盘，无翻盘。

一天结束时，如果你只带走了一身疲惫，那这一天就被消费掉了；如果你带走了一张卡，这一天就变成了资产。

---

七、底层心法：四域切换为什么不精神分裂

一个人一天跑四个域，靠三样东西不崩：

|--------------|-----------------------------------|
| 支撑 | 作用 |
| 时间盒​ | 每个域有硬边界（15分钟／30分钟／45分钟），防止一个域吃掉整天 |
| 交接物​ | 上一域的产出是下一域的输入，切换有实物抓手，不靠记忆 |
| 沉淀库​ | ADR／SOP／组件库承接当天判断，第二天从资产接着跑，不从零开始 |

四域不是四个人的活塞进一个人，而是一条责任线在一天里的四个切面。

FDE的24小时，不是「加倍辛苦」，是用系统杠杆把一天切成四份，每份都产出可交接的资产。

---

八、自检：你的24小时，落在哪个域

|-------------------------|--------------------------|
| 自检问题 | 危险信号 |
| ****① 你今天有蹲现场吗？****​ | 全天没出过工位 → 需求域缺失，你在做假设 |
| ****② 你有问「用户从哪来」吗？****​ | 直接讨论功能细节 → 入口没定义，功能是空中楼阁 |
| ****③ 你的问题上墙了吗？****​ | 问题停留在脑子里或聊天记录里 → 交付域失守 |
| ****④ 你看过现金流表吗？****​ | 说不清项目回本周期 → 你在交付，不是在经营 |
| ****⑤ 你今天留下卡了吗？****​ | 一天结束什么都没沉淀 → 这一天被消费掉了 |

判读：

• 五问全有 → 你在跑完整的FDE闭环；
• 只有③④ → 你是交付工程师，需要补需求与设计域；
• 只有①② → 你是产品经理/顾问，需要补技术与交付域。

---

九、金句收尾

你原稿给的收尾句「实验室里再完美的模型，也抵不上车间里一线工人的一个真实痛点」已在 P01 死法二​ 用过，放在本节（24小时全天穿越）不贴题。建议替换为：

• 「FDE的一天，不是把四个人的活干完，而是把一条责任线从头走到尾。」（推荐，回扣开头钩子）
• 「判断一天有没有白过，只看一件事：你留下了卡，还是只留下了疲惫。」

---

下面按 第1篇 · 第5章 · 5.1节​ 归位。

先说这一页最需要处理的问题：你给的内容里有三处体系冲突 ------①「六步闭环」是本节标题，但正文写的是「四阶段流水线」；②「七层架构」出现了两套不同版本（固件层/云端层/小程序层 vs 编排层/设备层/交互层，同一套东西两种拆法）；③章节引用（第4-6章、第26-31章、附录K/G/J/E）与本书 8篇59章 目录不对应。我在下面统一校正。

---

第5章　价值与土壤：FDE为什么属于中小企业

章眼：大厂有分工，中小企业只有结果。

5.1　课程总地图：从想法到现金流的六步闭环（P08）

【开头钩子】

这门课只有一条主线：把企业业务需求梳理清楚 → 用Agent开发出来 → 变成三种价值 → 现金流闭环。

---

一、六步闭环：全书的一条主线

全书七篇，收敛为一条六步闭环：

|--------------|----------------|-------------|----------------------|-------------------|
| 步 | 阶段 | 对应篇 | 干的事 | 出口 |
| 第1步​ | 需求​ | 第2篇 | 甄别真需求 | P0需求清单​ |
| 第2步​ | 设计​ | 第3篇 | 定下品牌、规格、架构与北极星 | 设计五件套​ |
| 第3步​ | 技术​ | 第4篇 | 多Agent系统把它做出来 | 可运行三端闭环​ |
| 第4步​ | 测试​ | 第5篇 | 评测集＋门禁证明它是对的 | 质量门禁报告​ |
| 第5步​ | 运维​ | 第6篇 | 可观测＋数据飞轮让它越用越准 | SLO＋数据飞轮​ |
| 第6步​ | 交付＋变现​ | 第7、8篇 | 五阶段门禁送到客户手里，三种价值变成现金 | 回款与复购​ |

六步不是六个学科，是一个角色的六个动作。

需求决定做不做，设计决定长什么样，技术决定做不做得出，测试决定对不对，运维决定能不能久，交付变现决定活不活。

---

二、四阶段流水线：方法论的主干

六步是目录主线 ，四阶段是方法论主干。两者是同一条河------六步是水面上的六座桥，四阶段是水下的四段河道。

四阶段流水线：需求 → 产品设计 → 技术 → 交付

理解它的关键，不是记住四个名字，而是看清每个阶段的入口、出口和最大陷阱。

|-----------------|--------------|------------------------|----------------|
| 阶段 | 入口条件 | 出口交付物 | 最大陷阱 |
| ① 需求​ | 一个待验证的痛点假设 | 需求规格书 ＋ 立项 Go/No-Go 结论 | 把「想要的」当「愿意付钱的」 |
| ② 产品设计​ | 立项结论通过 | 品牌/IP手册、规格与BOM、产品架构图 | 功能堆砌，没有平台化分层 |
| ③ 技术​ | 设计基线冻结 | 可运行的三端闭环（固件／云／小程序） | 追新框架，忘了架构三原则 |
| ④ 交付​ | DVT通过 | 量产交接包、OTA通道、售卖与订阅闭环 | 原型验证成功的虚假繁荣 |

阶段之间的闸门管理，正是FDE区别于野蛮开发的核心纪律。

规划不是官僚，没有规划才混乱。

四阶段详解

① 需求阶段

• 入口：一个模糊的业务诉求或市场机会
• 出口：一份经过证据分级、EV排序、Go/No-Go评审的需求规格说明书
• 要回答四真：真问题、真用户、真价值、真边界
• 三大陷阱：把老板意志或竞品功能当作需求证据（C级观点单独支撑立项）；跳过问题诊断直接写功能清单（把解决方案当成需求）；需求无边界、无验收标准（为后续无限延期埋雷）

需求阶段是整条流水线最便宜的纠错点------这里一小时的求真，能省下后面一百小时的返工。

② 产品设计阶段

• 入口：规格化的需求
• 出口：冻结的方案权衡、接口契约、体验路径与非功能指标
• AI产品的两个特殊命题 ：
  1. 为概率性输出设计兜底体验------承认模型会错，用流程设计消化不确定性；
  2. 可测试性必须前置------每个模块预留观测点、注入点和开关，避免机器造好才发现测不了。
• 典型陷阱：过度设计追求架构优雅；只有一个方案走形式评审。

创意择优要求至少两个可行方案同台竞技，反对意见必须记录在案。

③ 技术阶段

• 入口：冻结的设计
• 出口：通过验证的系统------固件、云端、模型、内容在实验室里跑通主链路
• 能力圈纪律：团队真懂的技术才承诺日期；圈外部分必须做 Spike 或引外部专家；承诺分「确定交付」与「探索交付」两档。
• 典型陷阱：销售先承诺日期、研发后补锅；圈外需求不做验证直接开发。

④ 交付阶段

• 入口：实验室可用系统
• 出口：用户持续使用、指标可验证、运营可循环的运行态产品
• 典型陷阱 ：验收即终点------AI系统交付后会漂移、会遇到长尾场景、需要内容更新和模型再训练。

交付其实是长期运营的起点。

AI在四阶段中全程贯穿：

|------------|--------------------|
| 阶段 | AI的作用 |
| 需求 | 画像聚类、伪需求过滤 |
| 设计 | 生成方案初稿与评审清单 |
| 技术 | 多Agent工程本身就是AI系统工程 |
| 交付 | 测试、监控与内容运营 |

---

三、七层搭系统方法论：从零到可售的架构视图

四阶段是时间维度 的流水线，七层是空间维度的系统架构。

遇到问题时，知道它属于哪一层；规划产品时，知道哪一层是壁垒。

|------------------|-------------|-----------------------------------------------------------|----------------|
| 层 | 职责 | 贯穿案例实例 | 产出物 |
| L1 内容层​ | 把原始书稿／知识结构化 | 238套模型 → JSON（108学习模型／130职场计策） | models/*.json |
| L2 模型层​ | 内容的结构化运行时 | 238套模型的 manifest、ModelRouter 关键词路由、RAG切片召回 | 触发词表＋路由表 |
| L3 固件层​ | 采集器与播报器 | ESP32-S3：ESP-IDF固件、WakeNet离线唤醒、I2S录音播放、MQTT通信、OTA升级 | firmware/ |
| L4 云端层​ | 模型编排引擎 | ASR（含方言）→ LLM → TTS、情绪BERT分类、定时用药引擎，单台日均成本约0.28元​ | Orchestrator服务 |
| L5 小程序层​ | 控制台与关系枢纽 | 配网绑设备、模型卡片推送、熟练度热力图、家长周报、子女留言、情绪日报 | miniapp/ |
| L6 运营层​ | 增长与变现引擎 | 小红书内容日历、博主寄样置换、订阅分层解锁、预售闭环 | 内容日历＋订阅网关 |
| L7 数据层​ | 用户数据资产（护城河） | 熟练度数据、情绪标签、用药依从率、对话摘要 | 熟练度热力图 |

📌 【口径合并】 ​ 原文另有「L2知识库层／L3编排层／L4设备层／L5交互层」的拆法，与上表是同一套三端架构的两种命名 （编排=云端、设备=固件、交互=小程序）。本表采用更贴合硬件实践的固件／云端／小程序三端命名，另一种命名建议不再单独出现，避免读者混淆。

三层的特别说明

L1内容层是壁垒的源头

六款产品的核心壁垒不在硬件 （ESP32谁都能买），不在模型（API谁都能调），而在这一层：108个学习模型、130计职场策略、500多段戏曲、记忆人格问卷------都是长期沉淀、对手难以速成的资产。

硬件是载体，内容是粘性，数据是护城河。

L3固件层：一套代码，六款产品

六款产品共用同一套 ESP32-S3 工程，编译时用 PRODUCT_SKU 宏切换唤醒词与Prompt包------「库库」「小逻」「小伴」各不相同，底层却是一套代码。

L4云端层：三原则

能力可替换、成本可核算、故障可降级。

L7数据层：必须与合规一体设计

情绪球端侧转写后立即丢弃原始语音、数据90天自动删除、家长只能看摘要不能听原文------数据收集的克制，反而强化了信任。

最严格的隐私架构，反而成了家长付费的理由。

---

四、manifest十四字段：让系统可配置的契约

七层中，L1与L2之间的关键契约是模型 manifest------每个模型入库时的标准数据结构。它保证硬件、小程序、云端三端对同一套模型有一致的理解和调用方式。

|---------------------------------|---------------------------------------------------------------|
| 字段 | 解决的问题 |
| model_id / model_name | 身份------001号模型在三端必须指向同一个东西 |
| product / module | 归属------thinkbear还是workplace、属于六大模块中的哪一个，决定固件分发与小程序归类 |
| tagline | 痛点金句------既是路由关键词来源，也是内容营销素材 |
| trigger_keywords | 命中------用户怎么说才能命中这个模型 |
| voice_command | 显式调用------「库库，用001号模型」 |
| miniapp_route / rag_collection | 落地路径------推到小程序哪个页面、从哪个RAG集合召回 |
| output_template / fields | 输出一致性------六款产品统一五段式输出 |
| hardware_feedback（led / haptic） | 多端反馈------命中模型时肚子亮蓝灯、短震动，无屏设备也有回应感 |
| subscription_tier | 变现------free／basic／pro，决定开箱可用还是订阅解锁 |

实例：

{

"model_id": "001",

"model_name": "知识树建模模型",

"product": "thinkbear",

"module": "第一模块｜知识内化与记忆体系",

"tagline": "学霸笔记越记越薄、你的笔记越记越厚",

"trigger_keywords": "笔记厚", "知识树", "梳理",

"voice_command": "库库，用001号模型",

"miniapp_route": "/models/001",

"rag_collection": "learn_108",

"output_template": "card_v1",

"fields": "真实场景", "底层模型", "操作步骤", "破解公式", "练一次清单",

"hardware_feedback": {"led": "blue", "haptic": "short"}

}

统一输出五段式：真实场景 → 底层模型 → 操作步骤 → 破解公式 → 练一次清单

十四个字段合起来，把一套内容资产变成了一台可运营的机器。

这是平台化的最小契约------没有它，第二个产品永远和第一个一样贵。

---

五、用户侧五步法：系统视角之外的用户视角

七层是工程师视角的系统，用户视角被浓缩为搭系统五步法------这五步要直接写进产品说明书。

|-----------------|----------------------------|--------------------------------------|
| 步 | 动作 | 设计原理 |
| ① 选地图​ | 输入学段或岗位，系统自动推荐优先练习的10个模型 | 降低启动门槛，消除冷启动的选择焦虑 |
| ② 遇困即查​ | 语音报模型编号或直接描述痛点，RAG召回对应模型卡片 | 场景触发而非功能罗列，让求助路径短到一句话 |
| ③ 练一次​ | 按「练一次清单」完成5---15分钟微任务 | 费曼输出闭环的微缩版------知识必须变成动作才算内化 |
| ④ 沉淀​ | 熟练度加一，写入个人模型图谱 | 禀赋效应与进步可视化------让进步可见 |
| ⑤ 复盘​ | 周月报告展示「已内化模型数／238」进度条 | 间隔重复与长期反馈------用游戏化节奏维持长期使用 |

好的产品设计不是堆功能，而是设计一条用户愿意反复走的路径。

六款产品中，家长端只看进度不看聊天、子女端留言异步推送，都是同一原理在不同关系上的应用：

每个角色看到什么、看不到什么，都是被刻意设计的。

---

六、六款贯穿案例产品：一本书的六个验证样本

六款产品（V3.1）共用 ESP32-S3 平台 ​ 与 238套模型内核，差异在外壳形态、Prompt／知识库与小程序模块。它们覆盖「学习、职场、银发、亲情、纪念、儿童」六大人群场景，构成方法论的多变量验证样本。

|-----------|------------------|--------------|-------------------|--------------|-------------|------------|---------------|
| # | 产品 | 目标人群 | 核心内核 | 硬件形态 | BOM | 定价 | 订阅 |
| 1 | 思库熊​ | 初高中／大学生 | 108思维模型库（学习教练） | 戴眼镜毛绒熊 | ¥128 | ¥599 | 精讲＋间隔复习 ¥39/月 |
| 2 | 拓境​ | 25-45岁职场人 | 130计生存模型库（职场博弈） | 磁吸方块「小逻」 | ¥130 | ¥499 | 工作模型包 ¥29/月 |
| 3 | 陪伴熊·基础版​ | 独居老人 | 方言Prompt＋戏曲库＋用药引擎 | ESP32-S3毛绒熊 | ¥124 | ¥599 | 戏曲包 ¥19/月 |
| 4 | 陪伴熊·亲情版​ | 异地儿女＋老人 | 声音克隆＋角色档案＋场景剧本 | 同上 | ¥124 | ¥798 | 基础版升级包 ＋¥199 |
| 5 | 记忆熊​ | 失去亲人的人 | 人格档案＋纪念内容＋合规门禁 | 深蓝毛绒熊 | ¥124 | ¥799 | 记忆续费 ¥99/年 |
| 6 | 情绪球​ | 儿童＋家长 | 无屏共情＋呼吸引导＋隐私架构 | ESP32-S3硅胶球 | ¥110 | ¥459 | 睡前故事包 ¥15/月 |

核心策略：

开发一次底层固件，切换 Prompt／知识库出新品，边际成本极低。

两条产品线的品牌定位：

|-----------------|-----------------------|-------------------|
| 维度 | 思库熊 ThinkBear | 拓境 AI职场助手 |
| IP​ | 戴书本眼镜小熊，肚子是知识库 | 磁吸方块「小逻」 |
| Slogan​ | 不止记忆，更要构建完整思维知识库 | 会议结束，130计模型已在手 |

---

七、贯穿案例的数据面：四个阶段的底片

|-------------|--------------------------------------------------------|--------------------------|
| 阶段 | 关键数据 | 产出本质 |
| 需求​ | 63场访谈、214条带编号证据、17条「非目标」、评审会否决率65% | ****不是文档，是「不做什么的资格」****​ |
| 设计​ | 108套与130套两个模型库全量搭载、31个小程序走查问题、两轮设计评审 7/12 → 11/12 打分曲线 | ****不是图纸，是「可测试的承诺」****​ |
| 技术​ | 43个联调问题四级分级、五张核心数据表、七个固件状态、双分区OTA | ****不是代码，是「异常路径的穷举」****​ |
| 交付​ | 1945台出货、124万硬件收入、1140户在订、3214张工单四级分流 | ****不是货物，是「可循环的运营态」****​ |

四个「最容易被跳过」的陷阱，各一句教训：

需求阶段跳过证据链，设计就会建立在想象上；

设计阶段跳过异常路径，客服就会成为默认的架构师；

技术阶段跳过联调分级，问题就会在量产夜集中爆发；

交付阶段跳过账本复算，增长就会变成无法归因的玄学。

---

八、12个月执行节奏：Phase 1---5

|------------------|------------|----------------------|--------------------|
| 阶段 | 时间 | 动作 | 目标 |
| Phase 1​ | 第1-2月 | 陪伴熊基础版（验证硬件链路＋小红书转化） | 50台预售 → 发货 → 回收现金流 |
| Phase 2​ | 第3月 | 上线亲情版（声音克隆叠加，同硬件换固件） | 新增SKU，复用用户群 |
| Phase 3​ | 第4-5月 | 推记忆熊（清明／母亲节节点）＋思库熊内测 | 高客单价＋108模型验证 |
| Phase 4​ | 第6-8月 | 情绪球＋拓境试水 | 扩品类，130计模型全搭载 |
| Phase 5​ | 第9-12月 | 订阅规模化＋第二代硬件迭代 | 年销45-55万中枢目标 |

四阶段 × 七层在实战中纵横交叉------每一次阶段推进，都是七层完整性的一次再检查：

|------------|------------------------|
| 阶段 | 重点检查层 |
| 需求 | L1内容层是否有独家资产、L7数据层是否合规 |
| 设计 | 冻结L2模型契约与L5小程序边界 |
| 技术 | 打通L3固件与L4云端 |
| 交付 | 启动L6运营，沉淀L7数据 |

FDE手里最常用的管理工具，就是一张四阶段 × 七层的交叉检查表------哪个格子是空的，风险就藏在哪里。

---

九、角色阅读路径：不同人怎么用这张地图

|--------------------|-------------------|------------|-----------------------|
| 你是谁 | 必读 | 选读 | 读完你能 |
| 创业者／独立开发者​ | 第1-3篇、第7-8篇 | 第4篇技术篇 | 用 ¥3575 启动资金跑通第一款产品 |
| 工程师转型FDE​ | 第1篇、第4篇技术篇、第7篇交付篇 | 第2篇需求篇 | 独立搭通软硬一体三端闭环 |
| 产品经理​ | 第2-3篇（需求与设计） | 第4篇技术篇 | 写出带 manifest 的可执行 PRD |
| 企业主／高管​ | 第1篇、第7篇交付篇、第8篇商业篇 | 贯穿案例节 | 判断该不该立项、团队怎么搭 |
| 运营与增长​ | 第6篇运维篇、第8篇商业篇 | --- | 掌握订阅分层、内容日历与合规边界 |

FDE本人 ：全书贯通，重点是四阶段闸门 × 七层架构的交叉视图------任何一个需求变更，他都要能同时判断它影响哪个阶段、哪一层。

业务负责人与高管不需要读工具细节，但要读懂三件可以用机制锁定的事：

1. 证据分级制度------C级观点不能单独立项；
2. Go/No-Go评审的决策纪律；
3. 四阶段的入口出口标准。

---

十、三遍读法与「工具直查」路径

厚书要薄读，给三条路径：

|-------------------|---------------------------|----------------|------------|
| 遍次 | 读法 | 目标 | 用时 |
| 第一遍·故事线​ | 按章节顺序读案例与复盘，跳过全部模板 | 建立「四阶段长什么样」的直觉 | 约6小时 |
| 第二遍·方法论线​ | 读每章的方法论主体与ADR引用 | 把「直觉」换成「为什么」 | 约10小时 |
| 第三遍·工具线​ | 不读只查------做哪个阶段，就翻哪个阶段的工具 | 对着检查清单干活，用时随取 | 随取 |

一个善意的提醒 ：第三遍的读者请抵制住「跳过方法论直接抄模板」的诱惑------模板是方法论的尸体 。只抄模板不读方法，等于拿别人的骨架拼自己的项目，拼得越像，死得越快。

团队共读的三周排课表：

• 第一周：读方法论章，各自写下「本岗位最痛的一章」；
• 第二周：对照案例章，找出贯穿项目里与本公司处境最像的一款产品；
• 第三周：用实战章的表单（PRD骨架、BOM母版、门禁清单）套一个真实在办项目。

三周下来，方法论从纸面进入工作流------这是本书作为「实战指南」而非「认知读物」的使用方式。

---

十一、方法论的边界：四种失效场景

诚实的方法论必须先讲失效场景。

|----------------------------|---------------|----------------------|
| 场景 | 为什么失效 | 调整 |
| 技术不确定性主导（核心算法尚未突破） | 「需求先行」失效 | 先跑技术POC，方法论让位于探索 |
| 强监管突变（如医疗AI新规落地） | 需求基线可能一夜作废 | CCB变更管理升级为战略级重估 |
| 单点创意驱动（纯艺术表达） | 证据分级与KPI会扼杀灵感 | 方法论只适用于其交付与合规部分 |
| 团队<3人且产品极简​ | 四阶段文档开销大于收益 | 只保留门禁与账本两件套​ |

识别失效的四个信号：

1. 需求评审连续三轮无新信息 → 探索不足
2. 门禁通过率长期100% → 门禁形同虚设
3. 账本数字与系统表对不上 → 纪律松弛
4. 团队成员说不出「我们在验证什么假设」 → 目标丢失

方法论不是信仰，是工具箱------知道工具什么时候不管用，是使用工具的最高素养。

---

十二、从方法论到肌肉记忆：21天训练法

读完全书不等于会用。

|--------------|-------------------------------------|------------|--------------|
| 周次 | 练习 | 每天 | 训练能力 |
| 第一周​ | 用「三刻度」（概率／代价／可逆性）重读一条团队近期决策，写成三行ADR | 40分钟 | 判断力​ |
| 第二周​ | 选一个在办项目，补做「非目标清单」与「证据分级表」（各一小时） | 40分钟 | 需求力​ |
| 第三周​ | 把一份在办的周报改写成「假设-回测」格式，跑一次完整周闭环 | 40分钟 | 迭代力​ |

设计依据：贯穿项目团队自己的成长史------第一批ADR写得生硬、第一张证据分级表漏洞百出、第一次周回测被数据打脸。

能力从来不是读会的，是按着模板笨拙地做三遍之后长出来的。

方法论书籍的正确用法是****「对照着错」****，不是「背下来」。

---

十三、金句收尾

用户买的不是玩具或录音笔，是一套可运行、可练习、可进化的个人操作系统。

下面按 第1篇 · 第5章 · 5.2节​ 归位。

先说这一页的处理：真正属于 P09 的素材集中在「价值公式 + AI替代边界 + 两种程序员 + 三种病毒 + 个人价值审计」这条线上 ；另有三类内容需剔除------①「技术迭代四代／大模型瓶颈／范式转移」与 P01 认知筑基完全重复 ；②Python 基础语法教程（print／变量／运算符／input／if嵌套／模块导入）是另一本编程入门书的内容，与 FDE 方法论无关；③Mike／Alex／Sarah 三段小说需压缩。

另外注意：本节的三种病毒（勤奋的驴／技术原教旨／自证清白）与 P03（2.2节）是同一分类框架 ，但案例不同------P03 聚焦能力陷阱 （假经验、伪深度、知识囤积），本节聚焦价值陷阱（为什么你的产出不值钱），两者互为补充。

---

5.2 2026职场价值公式：你会算吗（P09）

【开头钩子】

AI时代不是内卷，是「多一层绞杀」------先会算价值，再谈努力。

---

一、价值公式：分子分母都换了

新旧公式对照

|--------------------|--------------------------------------|
| 版本 | 公式 |
| ****旧公式（过去十年）****​ | 价值 ≈ 加班时长 × 技术深度 × 忠诚度 |
| ****新公式（2026）****​ | 价值 ≈ 不可替代性 × AI杠杆 × 商业结果可见度​ |

注意：旧公式是加法思维 （多加班就多一点），新公式是乘法思维 ------任意一项为零，结果归零。

三因子详解

|----------------|-------------|-----------------------|
| 因子 | 旧版本 | 新版本 |
| 不可替代性​ | 我会修祖传代码 | 我懂业务＋能决策＋能带人​ |
| AI杠杆​ | 不存在 | 我用AI 10倍提效​ |
| 可见度​ | 领导应该看到 | 我主动让价值被量化​ |

FDE公式：

价值 ＝（技术深度 ＋ 业务理解）× AI杠杆

杠杆为零，全白干。

单一技能正在贬值，复合整合能力，才是技术人终身的职业护城河。

AI不会取代程序员，但会取代不会提要求、不会做判断的程序员。

---

二、AI会取代什么，不会取代什么

|----------------|----------------------------------------|
| | 内容 |
| AI会取代​ | 重复文档、基础代码、标准客服、一切可SOP化的执行环节​ |
| AI难取代​ | 人性判断、跨部门协调、业务定义、信任与背锅、0→1方向选择​ |

AI替代的不是人，是不会用AI、只会重复劳动的「旧版本的你」。

规则明确、可复制的执行环节，正在被批量接管；而定义问题、跨域整合、现场判断、承担责任------这四件事，AI一样都做不了。

---

三、案例：两种程序员，同一种裁员潮

|----------------|--------------------------|-------------------------|
| | 旧版·小李 ​ | 新版·小王 ​ |
| 年龄／司龄​ | 38岁，司龄8年 | 36岁 |
| 日常​ | 凌晨修Bug，随叫随到 | AI辅助 ＋ 主导AI知识库项目 |
| 结果​ | Legacy系统裁撤，第一个走​ | 帮业务降本20%，不在名单里​ |

差别不在努力程度------小李加的班比谁都多。差别在：

• 小李的价值绑定在即将被抛弃的历史系统上；
• 小王的价值绑定在业务正在发生的降本上。

他们淘汰的不是你的技能，是你的性价比。

你引以为傲的系统，在招聘市场里，可能只是一个过时的技术名词。

---

四、内卷的本质：不是人多，是价值公式变了

看懂游戏规则，才能停止无效狂奔。

内卷的表象是「100人抢10个坑」，本质是------90人看起来差不多，而 AI 把「差不多」的定价压到了地板。

AI做60分，公司为什么要用3倍价钱买你的80分？

你的职业，可能正运行在一个即将崩溃的单体架构 上：高度耦合于一家公司、单一依赖技术变现、容错能力为零------一次裁员，等于一次全局宕机。

你用「勤奋地写代码」，逃避「战略地想未来」。

你精心打磨每一行业务逻辑，却从未为自己的人生，设计过一套抗风险的「系统架构」。

---

五、三种思维病毒：为什么你的产出不值钱

📌 与 P03（2.2节）呼应 ：P03 讲能力陷阱 （假经验／伪深度／知识囤积），本节讲价值陷阱------两者是同一套框架的上下半篇。

病毒一｜勤奋的驴：用「被需要」的幻觉，喂养「怕失去」的恐惧

案例胶囊 ：Mike，38岁，司龄8年，技术栈停留在五年前的「稳定版本」。凌晨三点被报警叫醒，两小时恢复系统，业务方发来一句「谢谢Mike，救了大命」。他揉着颈椎，在凌晨五点的死寂里感受到一种病态的满足------「没我不行」。裁员邮件到达那天，理由是「Legacy Platform Modernization项目组整体裁撤」。他冲进老板办公室：「那些系统离了谁都能转吗？！」老板像看一台折旧率超标的旧设备：「公司要活下去，钱必须投向能建设未来的地方，而不是无限期地修补过去。」

病灶 ：「我很重要」的幻觉------其实你只是「很好用」。

你的重要性，绑定在那些陈旧、脆弱、充满技术负债的系统上。你不是在守护宝藏，你是在看守一座早已计划爆破的旧楼。

你的「不可替代」，恰恰是你最大的可替代性------一旦旧楼被炸，看门人第一个失业。

墓志铭：

他解决的所有问题，都是公司急于抛弃的历史。

公司为你开欢送会时流的泪，远不如财务省下你薪资时笑得甜。

病毒二｜技术原教旨主义：只信代码，不信人性与商业

案例胶囊 ：Alex 花一个月，把纠缠五年的遗产代码重构成层次清晰、接口优雅的艺术品，每天只睡四小时，妻子埋怨他不管高烧的孩子，他甩出一句「你不懂！我在创造未来！」。上线前夜，营销总监在Slack咆哮：「黑五明早9点开抢！」他淡定回复「在跑压测，新架构并发是旧的十倍，为了未来值得等」。一个兼容性Bug让上线推迟6小时------竞品同类活动席卷市场，公司押注百万的营销战役彻底哑火。复盘会上他试图解释架构图，CEO指着亏损数字打断：「你的『未来』很好。但公司的『现在』死了。」一周后他离开，那套重构一新的系统因无人熟悉且不再有流量，成了新团队口中又一个「技术负债」。

病灶 ：「我在做对的事」的幻觉------其实你在「自我感动」。

你追求的「优雅解耦」「完美抽象」，在业务生死时速面前，可能是一种残忍的过度设计。

在初创公司的温饱线上追求代码的「诗和远方」，是对团队和公司资源的犯罪。

你把技术当成了目的，忘记了它只是实现商业目的的手段。

病毒三｜自证清白：用自我牺牲，配合他人对你的剥削

案例胶囊：Sarah，35岁，某AI初创公司技术骨干。怀孕后陷入恐慌，开启了一场向所有人证明「我不是负担」的表演：产检谎称见客户、凌晨跨洋电话会一场不落、孕七月主动向老板表忠心。直到她倒在开放办公室的工位上，身下涌出的鲜血染红地毯------孩子提前三个月出生，NICU一天费用近万。她躺在病床上收到裁员通知，HRBP不忍看她的眼睛，只重复一句：「it's just business.」

病灶 ：在被剥削的绝境里，依然试图用「配合剥削」换取一丝虚幻的安全感。

你不敢病、不敢休、不敢表现出一丝疲惫------你把「有用」演成了「耗材」。

三种病毒的共同源代码：

他们毕生都在回答 「How to do it?」 ，却从未追问 「Why are we doing this?」 ​ 以及 「For whom are we creating value?」

他们是职场最昂贵的****「人肉执行器」****------输入需求，输出代码；至于价值流向哪里，他们不知道，也不被认为需要知道。

直到断电（裁员）那天来临，他们才发现：自己除了耗电（薪资）惊人，在系统架构图上，没有任何不可替代的节点位置。

---

六、解药：安装「价值导向」思维操作系统

案例胶囊 ：Robert 连续第三周凌晨下班，屏幕上是一个精妙的算法优化，把某后台任务性能提升了15%。技术人的自豪感涌起一秒，随即被空虚吞没------这个需求来自一封模糊的Jira ticket，他甚至不清楚这个任务最终服务于哪个业务功能。而此刻，那些知道这些「零件」用来组装什么、能卖多少钱的人，早已安然入睡。

病灶 ：只运行 Task Completion OS（任务完成操作系统）。

你燃烧自己，照亮别人通往财富和晋升的道路，最后只剩一地冰冷的灰烬，和一张「性价比不足」的判决书。

三种病毒的结局，一句话总结：

|----------------|---------------|-----------------------------------------------------------|
| 人物 | 完成了什么 | 破坏了什么 |
| Mike​ | 优化了无数代码 | 优化不了自己被裁员的命运------他把「完成任务」当作忠诚，公司把「完成历史任务的他」当作历史​ |
| Alex​ | 完成了惊世骇俗的重构 | 搞砸了公司活下去的营收------他完成了技术任务，却破坏了商业任务​ |
| Sarah​ | 超额完成了孕期所有工作安排 | 最终被勾掉的，是她自己的岗位和健康 |

升级路径：

从「How to do it?」→ 到「Why are we doing this?」→ 再到「For whom are we creating value?」

---

七、第一把手术刀：执行你的「个人价值审计」

想象这个场景：深夜，你摊开一张白纸，回答第一个问题------

「过去半年，我的工作为公司直接带来了多少收入增长？」

笔尖悬在空中，十分钟，一个字也写不出来。你脑子里闪过无数个加班的夜晚、一行行精巧的代码、一个个被修复的P0事故......但「Revenue Growth」？

你想起了那个优化后 P99 延迟降低30% 的微服务接口------它属于一个早已下线的边缘产品。

你想起了那个你严防死守避免的线上支付事故------但它从未发生，所以你的「功劳」无从计算。

额头开始冒汗。你发现，过去六个月的职业生涯，折算成商业价值......

这就是****个人价值审计（Personal Value Autopsy）****的残酷开端。

它不是年终总结，而是一场对你职业生命体的「财务清算」------你要算的不是你有多「辛苦」，而是你有多「值钱」。

三大血淋淋的职场真相

真相一：你的「苦劳」，在商业世界的记账科目是「费用」，不是「资产」。

• 你维护了1000小时系统稳定？公司只会把这视为「必须支付的运维成本」。
• 你修复了500个Bug？这说明系统质量欠佳，你的工作是「弥补缺陷产生的额外开支」。

当你无法证明自己创造了增量价值，你所有的付出，在CFO的报表上，都是一个需要被尽力压缩的「成本中心」。

真相二：你的「经验」，若无法被定价和调用，就是一堆占内存的「缓存垃圾」。

你知道那个最诡异的报错怎么解决------这很厉害。但如果你只是自己知道，只在出问题时被临时呼叫，那么你的经验就像一段晦涩的、没有注释的祖传代码：它有价值，但价值无法转移，且会随你的离开而彻底消失。

不能产品化、不能规模化的个人经验，是一种昂贵的、不可持续的「手工艺品」。

真相三：你的产出若无法被「关键人物」看见，等于没有发生。

你的价值不是你创造的价值，而是「关键人物」认为你创造的价值。

---

八、行动清单：把努力切换到正确的因子上

|----------------------------|--------------|----------------------------------|
| 行动 | 对应因子 | 具体做法 |
| 把重复工作写成SOP交给Agent​ | AI杠杆 | 凡执行过三次的任务，写成流程卡；凡两个产品共用的能力，沉淀为组件 |
| 把省下的时间投入现场与复盘​ | 不可替代性 | 蹲现场拿原话；每次事故出一篇复盘，每次决策留一张ADR |
| 让价值可量化、可见​ | 商业结果可见度 | 把「接口200ms→50ms」翻译成「年省服务器成本250万」 |

AI不是来辅助你的员工的，它是来重新定义「工作」本身的。

把重复工作交给Agent，把省下的时间投入现场与复盘------这不是偷懒，这是把工时从零售改成批发。

---

九、自检：你的价值公式得分

|----------------|-----------------|---------------|
| 因子 | 自检问题 | 得分信号 |
| 不可替代性​ | 你走了，哪条业务线会停？ | 答不出 → 高危 |
| AI杠杆​ | 你有多少工作是Agent在跑？ | 0 → 分母未被放大 |
| 可见度​ | 关键人物能量化你的贡献吗？ | 只能说「我很努力」→ 归零 |

判读 ：三项中任一为零，乘积即为零------这就是乘法公式最残酷也最公平的地方。

你无法阻止分母变大，但你可以让分子大到分母失去意义。

---

十、金句收尾

单一技能正在贬值，复合整合能力，才是技术人终身的职业护城河。

下面按 第1篇 · 第5章 · 5.3节​ 归位。

先说这一页的问题：P10 的核心其实只有四个要点（商业／管理／效率／度量纪律），但你给的内容里混入了大量"组织重构与AI赋能"的长篇案例 （CloudNova 85人膨胀、OmniBrands 内容团队转型、Michael 西雅图公司、William Chen 新加坡分享会，合计约4000字），还有附录J金句卡、另一本书的上下篇结构、分步操作规范------这些都不属于本节。我把主线抽出、案例压缩，其余单列归位。

---

5.3 FDE交付的三种价值：商业、管理、效率（P10）

【开头钩子】

老板不关心你用了什么模型，只关心这三种价值涨没涨。

---

一、三种价值：一张对照表

|---------------|----------------|--------------------|--------------|
| 价值 | 定义 | 看得见的形态 | 谁最关心 |
| 商业价值​ | 新增收入、毛利提升、订阅续费 | 能进财务报表的 | CEO／投资人 |
| 管理价值​ | 成本可视、风险可控、决策有据 | 账本与看板​ | 高管／COO |
| 效率价值​ | 人效比提升、周期缩短 | 10人干40人的活​ | 一线负责人 |

讲不清这三种价值，技术再先进也只是成本项。

三者的关系：

效率价值是过程，管理价值是抓手，商业价值是终点。

只有效率没有商业 → 你在帮公司省钱，但省下的钱不会自动变成你的价值；

只有商业没有管理 → 一次成功不可复制，第二款产品还是从零开始。

---

二、商业价值：能进财务报表的那部分

三个来源：

|---------------|-----------------|---------------|
| 来源 | 说明 | 度量指标 |
| 新增收入​ | 新产品线、新客户、新订阅 | 客单价 × 销量 × 复购 |
| 毛利提升​ | 成本工程、算力优化、BOM谈判 | 单台成本降幅、毛利率变化 |
| 订阅续费​ | 内容持续供给带来的长期现金流 | 续费率、LTV／CAC |

贯穿案例数据（六款产品首年）：

• 1945台出货 ，124万硬件收入；
• 1140户在订，订阅构成第二曲线；
• ¥3575启动资金 → 首年跑通全链路。

硬件是一次性收入，订阅是持续性收入，数据是复利式收入。

商业价值的终极形态，不是卖出一个产品，是拥有一条会自己生钱的管道。

---

三、管理价值：账本与看板

三个转变：

|-------------|-----------|----------------------------------------|
| 转变 | 从 | 到 |
| 成本​ | 看不见、说不清 | 成本可视------每一分算力钱、每一台BOM成本都可追溯 |
| 风险​ | 出事才知 | 风险可控------五阶段门禁、RACI矩阵、13周现金流表 |
| 决策​ | 拍脑袋、凭直觉 | 决策有据------ADR库、证据分级、评审打分曲线 |

三件管理者可以用机制锁定的事（回扣 P08）：

1. 证据分级制度------C级观点不能单独立项；
2. Go/No-Go 评审的决策纪律；
3. 四阶段的入口出口标准。

管理价值不是管得更多，是把不确定性关进制度的笼子。

一个没有账本的项目，增长就是无法归因的玄学。

反面案例：

案例胶囊：Michael，西雅图一家60人软件公司创始人。为省下5000美元的法律服务年费，用廉价线上模板处理用户协议------一个协议漏洞导致公司在数据纠纷中败诉，直接损失一个价值200万美元的大客户，并面临75万美元赔偿。另一头，他拒绝了开出25万美元年薪的架构师（"这够我雇5个初级工程师了"），转而组建廉价但平庸的团队。结果系统像纸板糊的塔，维护成本高到惊人，而那位架构师帮竞争对手把迭代速度做到了他的三倍。

你省下了一个架构师的薪水，却被迫为你拙劣的系统支付了百倍的「愚蠢税」和「机会成本」。

---

四、效率价值：10人干40人的活

1. 为什么"堆人力"是效率最低的增长方式

案例胶囊：CloudNova（凤凰城），创始人David拿到融资后疯狂扩招，18个月内团队从10人膨胀到85人。结果：一个功能改动需要五个部门开2小时「对齐会」，会议纪要没人看，结论模糊不清；一个简单的服务器权限申请要过四道审批、走三天------三年前只需要在Slack里吼一嗓子。David自己80%的时间消耗在内耗中，从创始人变成了「全职会议主持人」。

死亡螺旋：

项目增加 → 人手增加 → 管理成本飙升 → 利润摊薄 → 老板累垮

协同损耗的真相：

• 5个人：5条沟通链路；
• 85个人：3570条沟通链路。

你不是在创造价值，你是在制造「会议」和「文档」。

你的成本，就是对手用AI武装后的净利润。

2. 效率革命的底层逻辑：从加法到乘法

传统增长是加法：人手 × 工时 = 产出

AI时代是乘法：

综合效能跃迁 ＝ 个体人效提升300% × 协同损耗降低50% × 流程自动化70%

三个杠杆：

|-------------------------|--------------|----------------------------------------------------------------------------------|
| 杠杆 | 内涵 | 效果 |
| ****杠杆一：个体人效提升300%****​ | 从「工人」到「指挥官」 | 营销专员：一天2篇 → 策划主题＋生成20个初稿；程序员：一天200行 → 架构设计＋指挥AI生成1000行；产品经理：一周画原型 → 一天3个高保真可点击原型 |
| ****杠杆二：协同损耗降低50%****​ | 砍掉「组织摩擦力」 | 进展实时上协同看板、AI自动生成会议待办并分配、跨部门沟通被文档与自动化工作流替代 |
| ****杠杆三：流程自动化70%****​ | 把重复劳动交给Agent | 内容生产、客服初筛、数据周报------人类只处理例外​ |

当一个人的工具从「锄头」换成「挖掘机」，产出提升300%是一个极其保守的估计。

3. 案例：从「买文字」到「买线索」

案例胶囊 ：OmniBrands（班加罗尔），创始人Priya有5个内容创作者，产出跟不上需求，试过让员工偶尔用AI生成灵感，效果零星。转机来自一个致命的问题："我买的到底是『写出来的文字』，还是『最终带来的客户线索和品牌影响力』？" ​ 她砍掉传统内容团队，组建3人「战略与优化」小组：策略师用AI 10分钟生成50个爆款选题报告（过去1人分析2天）→ AI自动生成20个不同风格初稿（过去5人写一整天）→ 3名优化专家用人类的品味与洞察筛选、雕琢、发布。结果：内容产出量是过去的8倍。

关键洞察：

AI真正的威力，不在于替代某个具体的员工，而在于重新定义「工作」本身，重塑整条价值链。

工具，是你手的延伸；而「劳动力」，是一个可以融入业务流程、承担明确职责的「虚拟岗位」。

你把一台超音速飞机当自行车骑，然后抱怨它不如摩托车快------这不是AI的问题，这是你想象力的问题。

4. 贯穿项目的实证

|---------------|--------------|------------------------------------------------------------|
| 维度 | 传统模式 | 贯穿项目 |
| 团队规模​ | 12---15人 | 5人，12个月未扩张​ |
| 产品数​ | 1款 | 6款​ |
| 杠杆来源​ | 个人能力 | 需求侧AI访谈转译（87份→214条）、内容侧卡片生产管线（每周20个模型）、运营侧周报工单工作流​ |

5个人做6款产品，靠的不是全能的人，是三个位置都装了杠杆------47条ADR、214张流程卡、23个共用组件。

---

五、度量纪律：每个Agent上线都绑一个指标

这是本节最重要的一条纪律：

每个Agent上线，都必须绑定一个可验证的指标；跑不出指标的下线。

执行三问：

|-------------------|-----------------------------------------------------------------|
| 问 | 内容 |
| ****绑什么指标？****​ | 商业指标（转化率／ARPU）／效率指标（人效比／周期）／质量指标（准确率／幻觉率）------三者至少绑一个​ |
| ****多久验证一次？****​ | 周度看趋势，月度看结论，季度决定是否继续投入 |
| ****跑不出来怎么办？****​ | 降级（缩小scope）→ 转探索交付 → 下线​ |

度量纪律的意义：

没有指标绑定的Agent，是一次技术自嗨；跑不出指标的Agent，是一笔持续失血的投入。

AI落地不是比谁做得多，而是比谁烂尾少、谁稳定久、谁持续产出价值。

---

六、自检：你的项目能交出几种价值

|-------------|----------------------------|----------------|
| 价值 | 自检问题 | 答不出的后果 |
| 商业​ | 这个项目带来多少收入／省下多少成本？能进财务报表吗？ | 预算被砍 |
| 管理​ | 成本可视吗？风险可控吗？决策有据吗？ | 一次成功不可复制 |
| 效率​ | 人效比提升了多少？周期缩短了多少？ | 规模上不去 |
| 度量​ | 每个上线的Agent绑了什么指标？跑出了吗？ | 持续失血不自知 |

判读：

• 只能答出效率 → 你在帮公司省钱，但说不清省下的钱去哪了；
• 只能答出商业 → 一次成功，不可复制；
• 三项全答得出 ＋ 指标全绑 → 这才是FDE的交付标准。

---

七、金句收尾

AI不是来辅助你的员工的，它是来重新定义「工作」本身的。

下面按 第1篇 · 第5章 · 5.4节​ 归位。这一页是第5章的收口，也是回答「为什么FDE属于中小企业」的关键一页。

原文里五个案例（印度精密部件、柏林工业智能、硅谷QuickStock、柏林FinTrust、悉尼HomeSmart，合计约4000字）都很有价值，但情节重复且过长，我压缩为胶囊；另有「分步操作规范」「AI工具使用规范」「B.中台·研发AI赋能（第13～17章）」属其他章节，单列归位。

---

5.4　中小企业为什么最适合FDE模式（P11）

【开头钩子】

大厂拼预算，小团队只能拼结构。

---

一、结构，是中小企业唯一的杠杆

大厂可以靠预算解决问题：招五个专家、买十台服务器、外包三条业务线。

中小企业没有这个选项------你只有5个人、3575元启动资金、12个月。

|---------------|--------------|----------------------|
| 维度 | 大厂打法 | 中小企业打法 |
| 资源​ | 充足，可堆人堆算力 | 受限，每分钱都要算ROI |
| 组织​ | 职能分工、层级清晰 | 一个人必须是一条责任线​ |
| 风险​ | 容错空间大，可并行试错 | 容错为零，一次失败就出局 |
| 核心杠杆​ | 预算 | 结构​ |

大厂的AI项目死在协同成本，中小企业的AI项目死在资源不足------而FDE模式，恰恰同时解决这两个问题。

为什么是中小企业先跑通：

大厂有分工的本钱 ，中小企业只有结果的压力。

大厂可以把FDE拆成五个岗位各管一段；中小企业做不到------它必须让一个人从头走到尾。

于是，「被迫全链路」反而成了中小企业的结构性优势。

---

二、为什么传统科层制在AI项目上必然失效

案例胶囊 ：印度班加罗尔，精密部件制造公司。质检员维卡斯在内部系统提交红色警报------P-348批次部件热处理可能存在隐患，附照片与数据，建议立即封存全检。这份救命报告此后经历了7天「公文漂流」：第1天转技术员复核 → 第3天发起线上会签 → 第5天被生产部打回（质疑采样方法、怕影响绩效）→ 第7天升级至副总裁，而副总裁正在去机场的路上。第8天，德国客户三条组装线停产12小时，终止全部合同并启动2100万美元索赔。

病灶 ：不是没有人才，是信息阻滞。

传统科层制的三大致命伤

|---------------|------------------|------------------|
| 致命伤 | 表现 | AI项目中的后果 |
| 信息阻滞​ | 一线警报7天到不了决策者 | 现场问题永远晚于损失 |
| 决策缓慢​ | 一个简单的权限申请走四道审批三天 | 需求变更慢一拍，现场早已变化 |
| 人才窒息​ | 每个人只精通自己那一小片 | 跨域需求无人能兜底 |

案例胶囊 ：柏林，工业软件公司 IndustrialMind。创始人汉斯设计了8个层级、20多个部门，每个岗位有几十页JD，把开发团队拆成前端、后端、算法、数据等孤立「深井」。一个大客户项目需要跨井协作，结果：前端等后端API、后端等算法数据模型、算法抱怨数据质量、数据说需求变来变去......6个月拿不出一个可演示的MVP，客户解约，骨干成群离职。汉斯的复盘：「我把一群雄鹰关进了各自的小笼子，然后责怪他们为什么不能协同作战。」

深井效应的本质 ：每个井里的人都只对自己的KPI负责，没有人对最终结果负责。

这正是 P01「责任鸿沟」的组织学根源------看起来人人有责，实际上出了问题人人无责。

AI项目的三大反传统特征（回扣 P02）：高度跨域、高度不确定、高度依赖现场。

用工业时代的金字塔，去接智能时代的跨域需求------错配是必然的。

---

三、海星组织：一个战略中枢 ＋ 若干自驱动战斗细胞

海星没有头也能活------砍掉一块，还能长回来。这正是中小企业需要的组织形态。

|------------------|-------------|-----------------------|
| 组成 | 职责 | 对应能力 |
| 战略中枢​ | 定方向、配资源、守门禁 | 使命愿景、Go/No-Go 决策、现金流表 |
| 自驱动战斗细胞​ | 对一条完整业务线负责 | 需求→设计→技术→交付，全链路闭环 |

核心设计原则：

听得见炮火的人自主决策，创造价值的人获得激励。

但扁平化不是「取消中层」这么简单------

案例胶囊 ：硅谷，仓储机器人公司 QuickStock，150人时官僚主义初现。创始人萨拉读完几篇去中心化文章后热血沸腾，周五全员大会宣布：「下周一开始彻底扁平化！取消所有中层经理头衔，大家自治！」台下掌声雷动。灾难在周一早上9点降临。

两个致命错误：

|---------------|-----------------------------------|--------------------------|
| 错误 | 表现 | 教训 |
| 只破不立​ | 头衔取消了，但谁定优先级、资源怎么分、冲突谁调解，全无新规则 | 权力真空 → 嗓门大的抢占资源​ |
| 粗暴混编​ | 顶尖算法工程师＋普通设计师＋应届销售，自由组合成「智能仓视觉小组」 | 鸡同鸭讲，寸步难行​ |

你砸碎了旧监狱的墙，却没有给任何人建造新家园的图纸和工具------结果就是所有人在自由的废墟上，开始无规则的野蛮争夺。

你以为把不同零件随机扔在一起就能拼出跑车？不，你得到的是一堆昂贵的、互相冲突的废铁。

正确做法：

扁平化的前提，是沿着价值流进行精密的「特种部队」式重组------而不是一场民主过家家。

120天后 QuickStock 分崩离析。扁平化不是目的，是手段。

---

四、三支柱重构：精简后台、加固中台、增强前台

|-------------|------------|--------------------------------------|------------------|
| 支柱 | 定位 | 动作 | 目的 |
| 后台​ | 管理与支持 | 精简------能自动化的自动化，能外包的 | 降低成本，不养闲人 |
| 中台​ | 能力与复用 | 加固------ADR库、SOP库、组件库、RAG知识库 | 让第二个产品只有第一个的零头成本 |
| 前台​ | 业务与交付 | 增强------FDE战斗细胞，直面客户与现场 | 让听得见炮火的人有决策权 |

后台瘦身省钱，中台沉淀复用，前台增强拿结果。

中小企业最常犯的错，是后台臃肿、中台空空、前台缺人------钱花在了不产生价值的地方。

---

五、人机分工新边界：人管例外，AI管规则与重复

这是本节最关键的一条边界。

案例胶囊 ：柏林，金融科技初创 FinTrust。创始人本杰明为降本，裁撤整个QA团队和一半中级开发，理由是「AI写代码速度是人的10倍，跑测试是人的100倍」。信贷风控模型重大更新时，骨干工程师在AI辅助下一周完成原需一月的重构，AI测试跑了上万条用例全绿通过 ，随即上线。72小时后，黑客利用一个隐蔽逻辑漏洞攻击，直接损失800万美元。

漏洞成因 ：AI严格遵循指令，却错误理解了一段涉及资金结转边界条件 的业务逻辑；AI自动化测试基于历史用例生成，完全无法覆盖这个由新逻辑创造出的、前所未见的场景 ；而QA被裁，没有了经验型测试人员去设计「破坏性」和「探索性」用例。

这个漏洞，如同银行金库墙上有一道仅存在于概念中的「暗门」------被AI亲手建造，又被AI自信地宣布为「安全」。

人机分工的三条边界

|-------------|-----------------|--------------|
| | 人负责 | AI负责 |
| 判断​ | 例外、边界条件、0→1方向选择 | 规则明确、可复制的执行 |
| 质量​ | 设计破坏性用例、做探索性测试 | 跑历史用例、做回归验证 |
| 责任​ | 对结果负责、承担后果 | 提供选项、放大产能 |

人管例外与决策，AI管规则与重复。

用AI彻底取代人类的专业判断，是这个时代最具诱惑力、也最致命的错误。

AI跑得越快，人类刹车的位置就越重要。

工具投入上，别犯「省小钱亏大钱」的错

案例胶囊 ：悉尼，智能家居公司 HomeSmart。创始人卢卡斯为了每年省不到5万美元的软件订阅费：拒绝2.5万美元的Copilot企业版，逼团队用一堆难维护的免费工具（工程师每天3小时耗在环境配置上）；拒绝资深设计师，让应届生用廉价AI画图工具产出平庸设计稿；拒绝1.5万美元的行为分析平台，改用后台自己看日志------产品上线后对用户如何挣扎、为何流失一无所知，像在黑暗中朝空气挥拳。18个月里亏损超200万美元，永远失去成为市场领导者的机会。

为了省下每年5万美元，亏掉200万美元和整个未来。

工具不是成本中心，是产能杠杆------砍工具预算，等于砍掉团队的乘法因子。

---

六、FDE就是那个「细胞核」

回到本章主题------中小企业为什么最适合FDE模式？

因为海星组织要活，需要每个细胞都具备完整的生命機能 ；而FDE就是那个能独当一面的细胞核：

|-------------------|---------------------------|
| FDE特质 | 对应组织需求 |
| ****一专多能（π型）****​ | 一个人顶一条业务线，不需要凑齐五个岗位 |
| 全链路闭环​ | 从需求做到回款，中间没有交接损耗 |
| 驻场判断​ | 听得见炮火，能自主决策 |
| 系统杠杆​ | 用AI与组件库放大产能，5人跑出12-15人的产出 |

大厂用五个岗位的分工 完成一条责任线；中小企业用一个FDE完成同一条责任线。

分工产生协同成本，闭环不产生。这就是中小企业唯一的结构性优势------也是它唯一能赢大厂的地方。

贯穿项目的实证：5人团队、12个月未扩张、6款产品、¥3575启动资金 → 首年1945台出货、124万硬件收入、1140户在订。

靠的不是五个全能的人，是三个位置都装了杠杆：47条ADR、214张流程卡、23个共用组件。

---

七、组织诊断五问（启动变革前必做）

|----------------|-----------------------|-------------------------|
| # | 诊断问题 | 危险阈值 |
| ① 人效比​ | 每增加100万营收，需要增加几个全职人力？ | 线性增长 → 没有杠杆 |
| ② 会议比​ | 核心团队每周花在会议上的时间占比？ | ****>30%****​ → 协同损耗过高 |
| ③ 等待比​ | 需求从提出到开始开发，平均等待几天？ | 持续变长 → 中台能力不足 |
| ④ 信息比​ | 一线发现的问题，多久能到决策者？ | 超过3天 → 科层制已僵化 |
| ⑤ 复用比​ | 做第二款产品的成本，是第一款几成？ | ****>70%****​ → 中台是空的 |

五问里三问踩线，说明你缺的不是人，是结构与杠杆。

---

八、自检：你的组织是金字塔还是海星

|-------------------------|---------------|--------------|
| 自检问题 | 金字塔信号 | 海星信号 |
| ****① 一线问题多久能到决策层？****​ | 数天，且层层衰减 | 当天，直达中枢 |
| ****② 有人对最终结果负责吗？****​ | 各管一段，无人兜底 | 每个细胞有一条完整责任线 |
| ****③ 第二个产品便宜吗？****​ | 和第一个一样贵 | 只有零头成本 |
| ****④ 人在做例外还是在做重复？****​ | 大量重复劳动 | 重复交给AI，人管例外 |

判读：

• 四项全落在金字塔 → 先补结构与杠杆，别急着招人；
• 四项全落在海星 → 你已具备FDE生长的土壤。

---

九、金句收尾

扁平化不是目的，而是手段------让听得见炮火的人自主决策，让创造价值的人获得激励。

下面按 第1篇 · 第6章 · 6.1节​ 归位。这是第1篇的收官页。

先说明处理：①作者简介 按你的要求压到最低调（去掉全部评价性表述）；②原稿的「30天速通软硬件开发」「技术翻译官」两节，本质是非技术背景读者怎么用这本书 ，我并入第七部分；③「周期盲症／天象／水大鱼大／战略总图／三原色」五个职业战略长案例，与 P05（势）、P06（35岁路径）同源，我压缩整合为第八部分「长期续航」，不再单独展开；④****「黑暗森林生存法则」「人情世故」「全书目录（另一本书）」****属厚黑学内容，单列建议删除。

---

第6章　使用说明书：一页一更，学完就做

章眼：这本书不是用来读的，是用来做的。

6.1　这门课怎么用：一页一更，学完就做（P12）

【开头钩子】

收藏不等于学会，看懂不等于会用。

---

关于作者

马释远，12年AI技术架构师与团队管理者，长期深耕大模型、多Agent协同、具身智能、计算机视觉与云原生AI架构领域，专注AI技术从0到1的工程落地、团队体系搭建与传统项目的AI转型。

2014年毕业于国内知名工科名校，从底层研发岗位起步，做过分布式架构与高并发系统优化，也较早尝试把AI算法用进业务调度、资源优化和智能决策场景；后担任技术经理，主导团队架构升级与流程规范化，牵头组建AI专项研发小组，完成AI能力从探索到业务赋能的第一轮闭环。2019---2023年任AI技术负责人，统筹60人跨职能AI团队，覆盖算法、开发、测试、运维全链路，期间与清华、MIT等背景的科研人员长期共事，主导参与多项重点AI项目，牵头制定AI技术规划并搭建标准化研发管理体系。此后自主创业，操盘商业地产AI运营数据平台，从产品设计、架构搭建到研发、交付、变现全流程走了一遍。

这些年踩过的坑比做成的案例多，本书写的多是踩坑之后的复盘，风格务实，少谈概念，多谈怎么把事做成。

---

一、本书为什么存在

2026年，AI行业早已告别「模型参数竞赛」的浅层内卷，正式迈入多Agent协同与具身工程化落地的全新周期。

过去几年，大量开发者与企业技术团队陷入一个普遍误区：沉迷调参、追逐新模型、堆砌前沿概念------耗费大量研发成本落地的AI项目，大多沦为演示Demo，无法适配真实业务、无法沉淀复用价值、更无法实现商业增收。

市面绝大多数AI书籍与课程，普遍存在三大痛点：

|---------------------|-------------------|
| 痛点 | 表现 |
| 重理论轻工程​ | 讲清了原理，讲不清怎么跑进生产环境 |
| 重Demo轻落地​ | 实验室效果惊艳，现场一跑漏洞百出 |
| 重单点技术轻系统架构​ | 会调一个模型，搭不起一条闭环 |

鲜有内容完整覆盖「模型部署→微调定制→Agent开发→多角色协同→企业高可用架构→商业化交付」的全链路工程体系------这正是大量技术人学完依旧无法独立落地企业级项目、企业AI转型屡屡失败的核心原因。

本书的核心立场：

AI的核心价值从来不是技术炫酷，而是用工程化手段解决真实业务痛点，用多Agent系统实现降本、提效、增收、控险的商业闭环。

本书彻底摒弃无效理论与过时知识点，完全贴合2026年AI落地图景，聚焦多Agent协同、大模型工程化、私有化部署、轻量化微调、具身交互落地五项核心能力。

---

二、全书怎么用：从想法到现金流的七篇

不同于常规技术书籍的碎片化教学，本书遵循循序渐进、工程优先、落地为王的逻辑，按一条真实落地流程层层递进：

|------------------|-------------------|-----------------|
| 篇 | 内容 | 回答的问题 |
| 第1篇 认知篇​ | FDE是谁、能力模型、五层框架 | 为什么需要FDE？我该怎么长？ |
| 第2篇 需求篇​ | 真需求甄别、证据链、立项规格 | 做对的事 |
| 第3篇 设计篇​ | 产品定义、平台化、AI产品专论 | 对的样子长什么样 |
| 第4篇 技术篇​ | 多Agent、11层工程、软硬一体 | 怎么把它做出来 |
| 第5篇 测试篇​ | 测试金字塔、评测集、质量门禁 | 怎么证明做对了 |
| 第6篇 运维篇​ | 可观测、SLO、数据飞轮 | 怎么越用越准 |
| 第7篇 交付篇​ | 五阶段门禁、协同与风险、规模化 | 怎么交出去、收回钱 |
| 第8篇 变现篇​ | 三种价值、ROI、90天行动 | 怎么持续变现 |

全程规避伪需求、无效开发与纸上谈兵------每一个知识点、每一套方案都可直接复用、直接落地、直接产生业务价值。

---

三、每页三个标准件：直接当口播稿

本书每一页，都是一个完整知识点，采用统一三段式结构：

|---------------|------------------------|
| 段 | 作用 |
| 钩子开场​ | 一句话点破痛点，让你知道这一页解决什么问题 |
| 要点拆解​ | 拆成可执行的动作、表格或清单 |
| 金句收尾​ | 一句话记住，可以直接拿去汇报、发圈、说服老板 |

每页独立成篇，可直接当口播稿、可直接当培训讲义、可直接当评审发言提纲。

---

四、最小闭环学习法：学一页，做一个动作

核心原则：大目标拆成可交付的小闭环。

不要想着「我要学会AI落地」------这个目标太大，大到你永远启动不了。

把它拆成：学一页 → 做一个动作 → 拿到一个反馈。

最小闭环的三要素：

|----------------|-------------|-----------------|
| 要素 | 说明 | 示例 |
| 一个小目标​ | 一页能装下 | 写出一条带证据的需求 |
| 一个交付物​ | 做完有实物 | 一张卡片、一张图、一张表 |
| 一个反馈​ | 有人或数据告诉你对不对 | 评审打分、用户原话、跑通/跑挂 |

闭环越小，启动越快；反馈越快，迭代越准。

用一年的大计划换一天的瞎忙，是低效；用一天的小闭环换一年的复利，是FDE。

---

五、输出倒逼输入：每页配一个落地动作

这是本书最重要的使用纪律------每页读完，必须产出一个实物。

|--------------|---------------------------|
| 篇章 | 落地动作示例 |
| 需求篇​ | 写一条带编号的需求证据；列一份「非目标」清单 |
| 设计篇​ | 画一张架构图；写一张 ADR 决策卡 |
| 技术篇​ | 搭一个 Agent 状态图；建一张数据表 |
| 测试篇​ | 建一条评测集用例；定一道质量门禁 |
| 运维篇​ | 定一个 SLO；画一张数据飞轮闭环图 |
| 交付篇​ | 填一张 RACI 矩阵；更新一次 13 周现金流表 |
| 变现篇​ | 算一次 ROI；写一页给老板看的汇报 |

没有产出的阅读，是消费；有产出的阅读，才是投资。

你读十页不落一笔，这十页就是别人的；你读一页留一张卡，这一页就是你的。

---

六、踩坑沉淀：每一次报错都是成长资产

AI项目里，报错是常态，不报错才是异常。真正的差距不在谁不踩坑，而在谁把坑变成了资产。

沉淀三库（回扣 P02 系统杠杆三个安装位置）：

|----------------|-----------------|------------------|
| 库 | 装什么 | 触发条件 |
| ADR 库​ | 决策卡：背景／选项／决定／后果 | 同一个判断被问过三次 |
| SOP 库​ | 流程卡：输入／步骤／验收标准 | 同一件事按固定顺序做过三次 |
| 组件库​ | 接口／参数／边界三件套 | 同一能力被两个以上产品或客户用过 |

落地动作 ：每一次报错、每一次线上故障、每一次需求返工，当天写进个人知识库。

今天的错，就是明天的测试用例。

你踩过的坑不写下来，就只是疤；写下来，就是资产。

方法论书籍的正确用法，是「对照着错」，不是「背下来」。

---

七、非技术背景读者怎么用：做「技术翻译官」

如果你不是工程师，而是创业者、管理者、HR 或业务负责人------你不需要成为专家，但需要成为「技术翻译官」。

为什么需要技术认知

技术早已不是成本中心，而是驱动业务增长的核心引擎。但对非技术背景的人来说，这个最重要的引擎像一个无法理解的「黑盒」：

• 评审会上，技术团队侃侃而谈「微服务」「容器化」，你只能通过表情和语气猜测真实风险；
• 面试中，你无法判断候选人「重构了核心架构」的背后，是扎实成就还是技术包装；
• 制定战略时，你分不清一项新技术是颠覆机遇还是转瞬噱头。

这种与核心技术的「脱节」，带来的不仅是沟通隔阂，更是战略判断力的丧失和决策风险的飙升。

重新定义「懂技术」

本书所倡导的「懂技术」，绝非让你去编写代码、调试程序。恰恰相反，它的核心是「去技术化」的。

目标是为你提供一种深刻的理解力------穿透技术术语的迷雾，直击商业本质的认知能力。

从「被动倾听」到「主动提问」：

|---------------|----------------------|
| 过去的提问 | 升级后的提问 |
| 「实现难度大不大？」 | 「为什么选这个数据库？高可用怎么保障？」 |
| 「开发周期要多久？」 | 「这个方案的长期维护成本是多少？」 |
| 「能不能做？」 | 「不做会怎样？做了能验证哪个假设？」 |

技术选型不是技术问题，是商业问题。选错了，产品可能「卡顿」或「太贵」；选对了，才能「丝滑」又「便宜」。

不懂技术，你只能听工程师说「做不了」；懂技术，你才能问「为什么做不了」。

从「门外汉」到「技术合伙人」，不是要你写代码，而是要你懂「为什么这么写」。

---

八、长期续航：周期、赛道与三原色

读完方法论，最后要回答的是****「我这五年往哪走」****。三个自检维度：

1. 周期：你在浪潮之巅，还是退潮沙滩

在职业生涯的牌桌上，你无法控制会发到什么牌（行业周期、公司命运），但你可以控制如何出牌（你的选择）。

职业风投尽职调查------用投资人的冷酷审视每一个机会：

• 赛道尽调：你投的是「趋势」，还是「噪音」？
• 天象尽调 ：监管与政策是「天」，资本是「地」，技术是地上跑的车。不抬头看天、不低头看地，车开得再快也可能在悬崖边飙车。
• 水量尽调 ：是「太平洋」还是「游泳池」？------在太平洋里当小虾米，跟着洋流也能周游世界；在游泳池里当最大的鱼，也活不过换水消毒的那一天。

在错误的赛道上，「优秀」是你对自己最残忍的诅咒。

2. 战略总图：你现在在哪，五年后要在哪

用一张 A3 纸，画你的《5年人生战略总图》：

|---------------|-------------------|
| 模块 | 问题 |
| 自我认知​ | 我是什么「物种」？我无法忍受什么？ |
| 价值定位​ | 我的独特尖刀是什么？ |
| 商业模式​ | 我的收入应如何组合？ |
| 杠杆规划​ | 如何放大我的价值？ |
| 网络蓝图​ | 我需要谁？谁需要我？ |
| 能量管理​ | 我如何可持续地战斗？ |

没有战略的人生，是一连串精美且合理的「战术动作」，最终导向一场不可挽回的「战略溃败」。

你用战术上的勤奋（加班、学习），掩盖战略上的懒惰（从不思考5年后你是谁）。

3. 三原色：财务（蓝）、能力（红）、生活（黄）

|---------------|-------------|---------------|
| 颜色 | 目标 | 缺失的代价 |
| 蓝·财务​ | 被动收入覆盖基础开支 | 抗风险能力为零 |
| 红·能力​ | 持续打磨不可替代的手艺 | 市场竞争力归零 |
| 黄·生活​ | 健康、家庭、能量可持续 | 换来一堆「颜色鲜艳的废纸」 |

你用透支生命（黄）和荒废真本事（红）换来的金钱（蓝），在死亡和孤独面前，不过是一堆颜色鲜艳的废纸。

三原色缺一，人生的画就是残缺的------缺哪一笔，哪一笔就会在最贵的时候向你讨还。

---

九、自检：你在「学会」还是「收藏」

|---------------------------|-----------------------|
| 自检问题 | 危险信号 |
| ****① 你今天产出了什么？****​ | 读完一页，纸上空白 |
| ****② 你的闭环有多小？****​ | 目标是「学会AI落地」，不是「写一条需求」 |
| ****③ 你踩的坑写下来了吗？****​ | 同一个坑这个月踩了第二次 |
| ****④ 你能问出「为什么做不了」吗？****​ | 只能听工程师说「做不了」 |
| ****⑤ 你的战略图上有几个颜色？****​ | 只有财务（蓝），能力与生活空白 |

判读：五项全过 → 这本书才真正开始发挥作用；五项全败 → 你只是把书放进了收藏夹。

收藏不等于学会，看懂不等于会用。

---

十、金句收尾

看懂属于浅层认知；动手调试、踩坑、排错、完成交付，才是真正内化。

第 二 篇　需求篇｜把企业业务需求梳理清楚

定位：甄别真需求、证据链转译、立项与规格化

需求是全链路第一张多米诺。本篇从伪需求过滤讲到P0需求清单，产出能设计、能测试、能对接的需求资产。

---

第7章　需求观：真需求与伪需求

章眼：伪需求做得越完美，浪费越彻底。

7.1　需求篇开篇：做对的事，比把事做对更重要（P13）

【开头钩子】

AI落地最大的成本，不是算力，是做了不该做的需求。

---

一、需求是全链路的第一张多米诺

需求错了，后面全错------这不是修辞，是数学。

|---------------|---------------------|
| 阶段 | 纠正一个错误的相对成本 |
| 需求阶段​ | 1​ |
| 设计阶段 | 10 |
| 技术阶段 | 100 |
| 交付／上线后 | ****1000+****​ |

需求阶段是全链路最便宜的纠错点------这里一小时的求真，能省下后面一百小时的返工。

需求阶段的产出不是文档，是一句话：

「不做什么」的资格。

把这句话立住，后面的设计、技术、测试、交付才有锚点；立不住，执行越快，死得越快。

方向错了，执行越快死得越快。

---

二、本篇路线：七步走完需求全链路

第2篇把需求工作压缩为七步，每一步都有明确的方法、工具和出口交付物：

|------------------|-------------------|-------------|-------------|----------------|
| 步 | 动作 | 对应章 | 页 | 出口交付物 |
| ① 甄别​ | 真需求还是伪需求：三项检验 | 第7章 | P13-P14 | 需求判定结论 |
| ② 挖掘​ | 画像、访谈与AI辅助 | 第9章 | P18 | 画像卡​ |
| ③ 转译​ | 从用户原话到产品语言的三级转译 | 第8章 | P15 | 证据链台账​ |
| ④ 立项​ | 五步循环＋优先级（期望价值排序） | 第8章 | P16-P17 | 立项书​ |
| ⑤ 规格​ | 需求规格说明书：写给两年后接手的人 | 第9章 | P20 | PRD​ |
| ⑥ 评审​ | 花钱买「不做」的资格 | 第9章 | P19 | 评审记录​ |
| ⑦ 变更与收口​ | 变更走门、质量门禁、P0总表 | 第11、14章 | P24、P28、P30 | 变更台账＋P0清单 |

六款产品实战贯穿全过程，在第10章（P21---P23）用同一套方法，输出六份完全不同、但同样扎实的需求定义。

---

三、本篇五件产出物

读完第2篇，你手上必须留下这五件东西------少一件，都不算需求收口：

|------------------|------------------------|--------------------------|
| 产出物 | 是什么 | 验收标准 |
| ① 画像卡​ | 目标用户是谁、关键时刻、现在用什么将就 | 能说清「替代方案」和「付费的人是谁」 |
| ② 证据链台账​ | 从用户原话到产品语言的三级转译，带编号 | 每条需求都能追到一句真实原话 |
| ③ PRD​ | 写给两年后接手的人看的规格说明 | 陌生人读完能独立开工 |
| ④ 评审记录​ | 谁提了什么反对意见、最终如何裁决 | 反对意见必须记录在案，不得抹掉 |
| ⑤ 立项书​ | 目标、非目标、验收指标、Go/No-Go结论 | 有明确的终点和可量化的成功标准​ |

这五件东西，是需求阶段唯一的硬通货------其余的会议、讨论、脑暴，都是过程，不是产出。

---

四、一条铁律：没有明确终点的项目，不立项

没有明确终点的项目，不立项。

这条铁律有三个硬指标，缺一不可：

|--------------|--------------|----------------|
| 硬指标 | 检验问题 | 答不出的后果 |
| 终点​ | 什么状态算「做完了」？ | 无限延期，做一半改一半废一半 |
| 验收​ | 哪个指标达到多少算成功？ | Demo当交付，业务拒用 |
| 非目标​ | 明确「不做什么」了吗？ | 需求无边界，团队疲于奔命 |

配套三问（面对任何需求，启动「灵魂三问」火力侦察）：

|--------------|-----------------------------|----------------|
| 问 | 内容 | 答不出的信号 |
| 问战场​ | 这个需求解决哪个业务指标的什么问题？ | 说不清 → 大概率是伪需求 |
| 问战果​ | 完美实现后，期望指标提升多少？有历史数据或行业基准吗？ | 没量化 → 功劳无法衡量 |
| 问验尸​ | 上线后如何衡量成功？看哪几个数据、观察多久？ | 无闭环 → 无底洞式加班 |

一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松。

当需求文档比源代码还厚，你的AI项目已经病入膏肓。

---

五、六款产品的需求得失速览

方法论不是空谈------六款产品用「五件做对的事与三个坑」的复盘，为需求篇提供了六个真实样本。

📌 完整版归位 ：每款产品的「五件做对＋三个坑」完整复盘，见第10章 P22（思库熊、拓境）与 P23（陪伴熊、记忆熊、情绪球）。此处先立骨架。

|------------------|----------------------------------------------------|--------------------------------------------|----------------------------------------------------|
| 产品 | 最关键的「做对」 | 最贵的那个「坑」 | 产品哲学（金句） |
| 思库熊​ | 把书稿当需求金矿------痛点金句成为触发词、tagline与营销语料的三合一资产 | 语音报号使用率仅31%------学生爱翻不爱说，二代需加触屏 | ****学生不是不爱学习，是不爱被「学习设备」定义------思库熊卖的是伙伴，不是教具。****​ |
| 拓境​ | 「会后5秒」硬指标倒逼出流式转写＋多模匹配＋预渲染三项真优化 | 一半卡片未被点开------首版高估了用户的主动点击意愿 | ****防坑工具自己不能变成坑。****​ |
| 陪伴熊·基础版​ | 双边画像分开立卡------「老人觉得好＋子女愿买单」才是完整需求 | 16%未激活------子女没空远程协助，配网的教育对象搞错了半辈子 | ****老人不怕被机器照顾，怕的是不会用；子女不怕花钱，怕的是不知道爸妈过得好不好。****​ |
| 陪伴熊·亲情版​ | 零硬件成本的升级路径------同主板＋OTA＋订阅解锁，边际成本趋近于零 | 微信语音样本压缩严重，第一周克隆投诉集中 | ****克隆声音卖的不是技术，是「开始聊」的引子------聊什么，留给用户自己。****​ |
| 记忆熊​ | 三证门禁的克制------首月拒掉11单，换来零伦理事故 | 清明档备货120台只售100台，节点型产品备货要再保守20% | ****思念有声，回忆可触------但技术必须知道自己在纪念面前的位置。****​ |
| 情绪球​ | 「对家长说不」写进非目标栏------孩子的树洞不被偷听，是产品存在的全部前提 | 「孩子当球玩」的误购退货------详情页首屏应放场景视频 | ****孩子的树洞一旦可以被偷听，树洞就死了。****​ |

六条复盘的三个共性：

1. 需求的第一现场永远在用户那里------书稿金句、会议5秒、老人怕不会用、孩子的树洞，都来自现场，不来自会议室。
2. 「不做」比「做」更值钱 ------拓境把纪要降级为Should、情绪球对家长说不、记忆熊首月拒11单，都是差异化＝敢不做。
3. 坑都长在「我以为」上------我以为学生爱说、我以为用户会点卡片、我以为子女有空配网、我以为清明能卖120台。

需求调研的颗粒度，决定 Prompt 的场景权重。

每一条被写进「非目标」的内容，都是未来省下的一百小时返工。

---

六、自检：你现在的需求站得住吗

|----------------------------|----------------------------|
| 自检问题 | 危险信号 |
| ****① 这条需求能追到一句用户原话吗？****​ | 只有「老板觉得」「竞品有」→ C级观点，不能单独立项 |
| ****② 有明确的终点吗？****​ | 说不出「什么状态算做完」 |
| ****③ 有可量化的验收指标吗？****​ | 只有「提升智能化水平」这类形容词 |
| ****④ 写下「非目标」了吗？****​ | 需求无边界，随时加功能 |
| ****⑤ 反对意见记录了吗？****​ | 评审全票通过 → 多半是走过场 |

判读 ：五项全过 → 需求可以立项；三项以下 → 先补需求，别急着写代码。

先蹲现场3天，再写第一行代码。

---

七、金句收尾

AI落地最大的成本，是做了不该做的需求。

下面按 第2篇 · 第7章 · 7.2节​ 归位。

先说这一页的处理：P14 的核心是「三项检验 + 三问排序 + 甄别工具」，但你给的内容里混入了大量属其他页面的素材------成本评估五维度（属技术篇 P73）、多Agent架构五原则（属技术篇 P50-51）、商业化四阶段迭代（属变现篇）、六大避坑指南（与 P01 重复）、「概率核心」（属技术篇模型基础）。我把主线抽出，其余单列归位。

---

7.2　真需求还是伪需求：三项检验过一遍（P14）

【开头钩子】

老板说要做、竞品已经有了、技术很酷------都不是需求成立的理由。

---

一、三项检验：合格需求的硬门槛

一条需求要成立，必须同时通过三项检验。任一项不过，就不进入排期。

|------------------|-----------------|------------------|
| 检验 | 问什么 | 答不出的后果 |
| 检验一·能设计​ | 这个需求能画成具体的方案吗？ | 停留在口号，研发无法开工 |
| 检验二·能测试​ | 做成什么样算成功？指标是什么？ | Demo当交付，业务拒用 |
| 检验三·能对接​ | 研发、供应链、售后接得住吗？ | 做出来交不出去，或交出去没人维护 |

合格需求的三项检验：能设计、能测试、能对接。

「老板要做」解决不了设计，「竞品有」回答不了指标，「技术很酷」接不住对接------这三条，一条都不构成需求成立的理由。

---

二、三问排序：从「真实」到「可售卖」

通过三项检验只是及格线。需求还要按三问排序，逐级收敛：

|--------------|---------------------|-----------------|
| 序 | 问题 | 这一问筛掉什么 |
| 第一问​ | ****这个问题真实存在吗？****​ | 筛掉想象出来的痛点 |
| 第二问​ | ****用户愿意为它付费吗？****​ | 筛掉「需要但不买单」的需求 |
| 第三问​ | ****可售卖版本怎么开发？****​ | 筛掉「能做但卖不出去」的需求 |

第一问决定真伪 ，第二问决定价值 ，第三问决定形态。

三问全过，才配叫 P0；只过第一问，最多算个观察项。

---

三、需求分层：三类需求，三种处置

企业需求必须分层拆解------80%的企业需求是伪需求或低效需求，必须三层筛选、精准过滤。

|-----------------|-------------------------------------------------|---------------------------------------------------------|
| 层级 | 特征 | 处置 |
| ① 伪需求​ | 锦上添花、无痛点、无效率提升、无成本节约、无增收、纯跟风 | 直接放弃、禁止开发------不立项、不开发、不投算力人力 |
| ② 低效需求​ | 有效果、但价值低、复用差、受众小、难规模化、不可单独收费 | 轻量化实现------仅用 Prompt、简单RAG、低代码快速实现，不定制、不重构、不大投入 |
| ③ 付费刚需​ | 业务高频、人工成本高、重复劳动量大、出错率高、可量化降本、可直接增收、客户愿付费、可规模化复制 | 核心深耕、重点投入​ |

典型对照：

|------------|----------------------------------------------|
| 类型 | 例子 |
| 伪需求 | 为AI而AI、页面美化、无闭环问答、无法量化价值的展示功能 |
| 低效需求 | 低频长尾的辅助功能 |
| 付费刚需 | 智能办公自动化、数据智能分析、知识库问答、工单流转、智能客服、垂直行业风控、具身智能作业 |

真实刚需公式：

真实刚需 ＝ 高频重复劳动 ＋ 高人力成本 ＋ 可量化降本 ＋ 可稳定闭环 ＋ 可规模化复制

AI落地最大的成本，是做了不该做的需求。

AI让「做出来」变得太容易，团队反而更容易跳过「该不该做」------这正是伪需求成为AI时代第一隐形杀手的原因。

---

四、证据分级：C级观点不能单独立项（REQ-02）

1. 三级证据

|-------------|-------------|-------------------------|
| 等级 | 定义 | 例子 |
| A级​ | 可验证的数据或实验结果 | 埋点漏斗、工单分布、预订数据、假门测试点击率 |
| B级​ | 一线观察与深度访谈 | 用户原话、现场观察、回访记录 |
| C级​ | 观点、推测与口号 | 「用户肯定需要」「领导说要做」「AI时代必备」 |

2. 铁律

C级证据不能单独支撑立项，必须配验证计划。

为什么：

确认偏误是人类最顽固的认知缺陷------人们只看见想看见的。需求评审里最危险的句式是「用户肯定需要」和「领导说要做」，它们听起来像事实，其实只是C级观点。

极度求真的文化，要求把事实与观点显式分开。

3. 怎么用

1. 每条核心需求标注证据等级；
2. C级需求必须在两周内配假门测试、访谈或数据分析；
3. 评审会上禁止仅凭C级证据通过P0需求；
4. 上线后回溯证据等级与实际结果的相关性，校准团队判断力。

案例胶囊 ：某SaaS团队评估「AI写周报」功能，支撑证据只有 VP 一句「AI时代必备」（C级）和5人访谈中4人说「也许有用」（B级偏弱）。假门测试显示按钮点击率8%，但数据显示用户写周报本身只花3分钟------痛点不足，功能降级为P2。这个案例的价值不是省了一个功能，而是建立了「观点必须过堂」的肌肉记忆。

贯穿案例印证 ：记忆熊面对3000万亲属的巨大市场仍坚持先做100台验证；情绪球因证据偏C级而定位为POC试水------都是证据分级纪律的体现。

我需要独立的事实依据，以及极度求真、极度透明的文化，才能做出最好的决策。------瑞·达利欧《原则》

---

五、伪需求过滤器：七个问题过一遍

日常接需求时需要一道快速安检 。下面七问，任何一问答不上来或答案可疑，需求就应退回补充证据，而不是进入排期。

|------------|---------------------------------------|--------------|
| # | 问题 | 筛掉什么 |
| ①​ | 这个需求的证据等级是什么？有数据（A）、有访谈（B），还是只有观点（C）？ | 无证据的想象 |
| ②​ | 谁在什么场景下遇到这个问题？****他现在是怎么解决的？****​ | 没有替代方案的「伪痛点」 |
| ③​ | 这个问题发生的频率和强度如何？ | 低频伪高频 |
| ④​ | 用户愿意为什么付费？****谁为这个需求的商业结果买单？****​ | 无人买单的需求 |
| ⑤​ | 如果不做会怎样？用户会流失、会投诉，还是其实无人在意？ | 自嗨型需求 |
| ⑥​ | 这个需求在我们的能力圈内吗？圈外部分的Spike计划是什么？ | 做不出来的需求 |
| ⑦​ | 它的二阶后果是什么？上线后可能引发什么我们不想要的适应行为？ | 副作用未评估的需求 |

两个使用技巧：

1. 把问题写进需求模板，强制回答------空白即退回。制度比自觉可靠。
2. 重点倾听第②问和第⑤问的答案 ：
   • 用户现有的笨拙替代方案（用微信群留言、用便签记吃药）是真实痛点的铁证；
   • 答不上来「不做会怎样」的需求，九成是自嗨。

案例胶囊 ：某工厂「质检智能化」需求过筛时发现，一线已有成熟的人工抽检流程且并无不满，提需求的是参观了展会的厂长------C级证据 ＋ 无替代痛点，项目当场搁置，避免了数百万的无效投入。

---

六、需求的「三层噪音」过滤法

需求挖掘的最大敌人是噪音。三层噪音各有过滤器：

|---------------|---------------------------------|------------------------------------|
| 噪音层 | 表现 | 过滤器 |
| 礼貌噪音​ | 访谈对象碍于情面的客套------「挺好的呀」「还不错」 | 痛点复现提问------要故事，不要评价 |
| 想象噪音​ | 团队把用户的将信将疑脑补成强烈需求------「他说可能会买」 | 行为证据------预订金／内测留存／回访频次 |
| 嗓门噪音​ | 最响亮的声音被当成最普遍的需求------社群里活跃分子的意见 | 抽样对齐------回访必须随机，不能只回访意见领袖 |

案例胶囊 ：某500人用户群里，十几个活跃用户连续一周要求「增加闹钟功能」，团队险些排期，被回访抽样拦下------随机50位真实用户的回访里，只有3位提到闹钟，且都是「有也行没有也行」。

社群的声量与市场的需求是两个分布------FDE的耳朵要长在随机样本上。

---

七、真需求的三个反直觉定律

贯穿项目十二个月，验证了三条反直觉定律：

|--------------|----------------------------------------------------------------------|-------------------------------|
| 定律 | 内容 | 操作含义 |
| 定律一​ | 需求强度与表达频度成反比 ------说得最凶的需求往往最弱，因为强需求的表现是沉默的习惯而非激烈的抱怨 | 访谈少问「你要什么」，多问「你现在怎么办」 |
| 定律二​ | 付费意愿与使用意愿来自不同的人------付钱的人常常不是用的人 | 文档少写「用户画像」，多写****「决策链图谱」​ |
| 定律三​ | 最好的需求验证是「取消测试」------把功能撤掉三天，看谁真的难受 | 验证少看「满意度」，多做取消测试****​ |

定律一的证据 ：银发用户从没说「要方言闲聊」，但他们每天对着收音机自言自语------这条沉默的习惯才是真需求的本体。

定律二的数据 ：陪伴熊 71% ​ 订单来自子女代购，思库熊订阅决策 三分之二 ​ 由家长完成。需求文档若只写「用户」不写「决策链」，定价与渠道就会全线跑偏。

定律三的实践：贯穿项目对「用药提醒」做过一次意外取消（服务故障48小时），外呼与工单的反馈密度证明了它是真需求；而「天气播报」取消后几乎无人问津，第二个月即下线。

需求阶段的全部技巧，说到底是学会把耳朵从「表达」移到「行为」。

---

八、真需求核验的「三个再问」

证据链解决「需求从哪来」，三个再问解决「需求配不配做」。

|--------------|---------------------------------------|-----------------------------------------------------------------------------------|
| 再问 | 内容 | 例子 |
| 第一问​ | 用户已经为它付出了什么？（时间、金钱、替代方案的将就程度） | 陪伴熊的子女们已自费买过收音机、戏曲机、监控摄像头------这就是付出证据​ |
| 第二问​ | 拿掉它谁会睡不着？（取消测试的组织形态） | 「有点用」和「离不开」的差距，只在拿掉那一刻显形 |
| 第三问​ | 它的反面是不是也成立？（伪需求的镜像检验） | 「老人需要陪伴」的反面是「老人需要独处」------两者同时成立时，需求定义必须收窄到具体场景（异地子女不在场的白天），否则产品会在两个方向上摇摆 |

评审会用法：过三关------每条P0需求当场过三问，任一问答不上来就降级为P2待观察。

贯穿项目数据 ：六款产品首轮P0共 91条 ，过三关后剩 68条。23条被降级的需求里：

• 11条后来被证明确实是伪需求（或时机未到）；
• 9条在需求变化后重新升级为P0；
• 只有 3条属于误杀。

三关的误杀率控制在 5%以内 ------这个成绩支撑了「宁可错杀不可放过」之外的第二种选择：让子弹飞一个季度。

---

九、证据链体检：立项前的最后一道工序

立项前，把一页纸立项文档里的每个结论向回追溯，直到原始证据。体检走三条链：

|--------------|----------------------------|-----------------------------------------------------|
| 链 | 检查什么 | 例子 |
| 强度链​ | 结论能否一路「点开」上溯到原始证据 | 「方言闲聊是高频需求」→ 周均使用11.6次的预售数据 → 三场访谈的原声时间戳 |
| 覆盖链​ | 证据是否覆盖了全部用户类型 | 陪伴熊初期证据全来自城市老人，补做两场乡镇访谈后发现「电视音量当闹钟」场景，直接影响唤醒音量默认值设计 |
| 时效链​ | 证据采集时间与立项时间差超过两个季度的，必须重新抽验 | 需求会过期，尤其是政策与渠道相关的需求​ |

产出：证据链健康表 ------每条P0需求标注 绿（三链全通）／黄（有一链需补验）／红（断链）。

贯穿项目数据 ：六款产品立项时健康表为 绿61%、黄31%、红8% ------红灯需求全部降级为待验证，没有一条带病立项。

体检耗时约一个工作日。对照的价值是：第二年规划评审时，同一个团队只用了半天，且红灯为零------体检做两次，就内化成了习惯。

---

十、需求十大坑：贯穿项目的「坑位图」

把六款产品的需求档案反着读，就是一张坑位图。

绕开的：

• 思库熊没有做「全年龄学习机」（伪大而全）
• 拓境没有做「通用会议纪要笔」（伪高频刚需）
• 陪伴熊没有承诺「健康监测」（伪技术浪漫）

踩过再爬出来的：

• 记忆熊初版文案用了「复活」一词，内测即被试用户纠正，改为「思念有声」
• 情绪球初版家长端设计了原文回放，评审时被隐私红线拦下

|-----------|--------------------------------|------------------|
| # | 坑 | 解药 |
| ① | 伪大而全：一个产品服务所有人 | 分层用户卡（思库熊三层） |
| ② | 伪高频：把低频场景包装成日活刚需 | 频次实测（拓境按会议实测） |
| ③ | 伪技术浪漫：用「因为做得出」论证「所以该做」 | 二阶后果推演 |
| ④ | 单边需求：只看使用者不看决策者 | 双边画像（陪伴熊） |
| ⑤ | 合规后置：先把功能写满再想红线 | 合规并列需求清单（亲情版） |
| ⑥ | 指标虚荣：用PV／下载替代留存与完成率 | 「练一次完成率」这类行为指标 |
| ⑦ | 访谈引导：拿原型问「喜欢吗」 | 痛点复现实验 |
| ⑧ | 竞品盲区：只看直接竞品不看替代品 | 替代品扫描 |
| ⑨ | 节点错觉：全年市场当成匀速市场 | 节点排期（清明／开学季） |
| ⑩ | 证据错级：拿C级证据做A级投入 | 证据分级表（情绪球用小步POC） |

把需求文档写完的那天，不是需求的结束，是怀疑的开始。

---

十一、REQ 六模型：需求阶段的武器库索引

需求阶段共有六件武器，各归其位：

|-----------------------|----------------------|-----------------------|
| 模型 | 要义 | 归属页 |
| REQ-01 立项五步​ | 定义→复盘→创意→择优→执行 | P16（需求立项五步循环） |
| REQ-02 证据分级​ | 实测 > 行为 > 访谈 > 猜测 | 本节第四部分​ |
| REQ-03 二阶后果​ | 追问「然后呢？」 | 本节第五部分第⑦问 |
| REQ-04 EV优先级​ | EV ＝（价值 × 成功概率）÷ 成本 | P17（需求优先级） |
| REQ-05 能力圈​ | 只在优势区出手 | 本节第五部分第⑥问 |
| REQ-06 逆向思维​ | 先想怎么失败 | 本节第十部分（十大坑） |

EV 示例（完整版见 P17）：记忆熊上线前三个候选需求------

• 「多音色选择」：价值3、概率0.9、成本5人日 → EV=0.54
• 「忌日提醒仪式」：价值8、概率0.8、成本3人日 → EV=2.13
• 「情感陪伴长对话」：价值9、概率0.4、成本20人日 → EV=0.18

答案显然是先做忌日提醒------高频节点场景的价值密度，远高于长对话的技术炫技。

EV不是精算，而是让优先级比较诚实。

---

十二、自检：你的需求过几关

|----------------|--------------------|---------------|
| 关卡 | 自检问题 | 不过的后果 |
| 三项检验​ | 能设计？能测试？能对接？ | 及格线都没过 |
| 三问排序​ | 真实？付费？可售卖？ | 无人买单 |
| 证据分级​ | 是A／B还是C？C级配验证计划了吗？ | 观点当事实 |
| 伪需求七问​ | 七问都答得上来吗？ | 退回补证据 |
| 三个再问​ | 付出过什么？拿掉谁难受？反面成立吗？ | 降级P2 |
| 证据链体检​ | 绿／黄／红？ | 红灯不得立项 |

判读 ：六关全过 → 可进 P0；三关以下 → 先补需求，别急着写代码。

数据不是信息，信息不是洞察。

真问题不是「没有AI」，而是「简单问题占用人工」------抄竞品会过度建设。

---

十三、金句收尾

合格需求的三项检验：能设计、能测试、能对接。

下面按 第2篇 · 第8章 · 8.1节​ 归位。

先衔接一下：P14（7.2节）已立起证据分级的「规矩」 （A／B／C三级、C级不能单独立项），本节讲这套规矩怎么落地------即「三级转译 + 挂链 + 标色管理」，把每条需求的「出身」变成三秒可查的资产。

---

第8章　证据链与立项：把想法变成项目

章眼：没有证据链的需求，只是情绪。

8.1　需求证据链：从用户原话到产品语言的三级转译（P15）

【开头钩子】

「我听懂了」和「我讲得出来」是两回事。

需求工作里最危险的错觉，就是以为自己听懂了------直到写PRD时才发现，你脑子里剩下的只有一句被咀嚼过三遍的「用户想要智能陪伴」。

需求死在转述里。用户说的一句原话，经过业务转述、产品翻译、技术理解，每传一级失真30%------传到第三级，剩下的只是你的想象。

证据链要解决的，正是这件事。

---

一、为什么需要证据链

证据链 ，是把「这条需求哪来的」从口头传统 变成可审计资产的管理动作。

没有证据链时，需求评审会是这样的：

「我觉得用户肯定需要。」------「我觉得不需要。」------「老板说要做。」

有了证据链之后，它变成这样：

「041号需求，C级推演，无行为数据支撑，建议降级。」------「同意，按证据等级裁。」

需求评审会从「我觉得」的辩论场，变成「证据说」的核验场。

贯穿项目的数据 ：六款产品共沉淀 214条带编号的需求条目 ，全部挂链------任何一条需求的「出身」，三秒可查。

---

二、三级转译：从原话到PRD

三级转译是证据链的主干。每一级都不能跳，跳一级就丢一层真。

|-------------------|---------------------------------|-------------|
| 级 | 内容 | 纪律 |
| 第一级·用户原话​ | 只记录、不加工，注明场景与身份 | 当场不翻译 |
| 第二级·需求条目​ | 原话 → 痛点 → 期望结果，一条一行可追溯​ | 带编号，可回链 |
| 第三级·产品语言​ | 转译成 PRD 条目，回链到原话编号​ | 每条PRD都能点回原话 |

第一级：用户原话------只记录，不加工

纪律只有一条：

现场只记原话，不做翻译。

用户说「我想听俺们老家那段戏」，你就记这一句------不要当场翻译成「需要方言语音识别」。翻译是回程的事，现场一翻译，信息就开始失真。

记录三要素：

|-------------|-------------------|
| 要素 | 内容 |
| 原话​ | 逐字记录，包括口音、语气词、犹豫 |
| 场景​ | 什么时间、什么地点、在做什么 |
| 身份​ | 谁说的（年龄、角色、与产品的关系） |

第二级：需求条目------原话 → 痛点 → 期望结果

把原话拆成一条可追溯的条目，格式固定为三列：

原话 → 痛点 → 期望结果

每条单独一行、单独编号（如 E-031），确保任何时候都能从编号点回原话。

第三级：产品语言------转译成 PRD 条目

把需求条目翻译成研发能执行的产品语言，并回链到原话编号。

【完整示例】陪伴熊：一句方言，走完三级

|-----------------|---------------------------------------------------------------------------------------------------|
| 级 | 内容 |
| ① 用户原话​ | 「我想听俺们老家那段戏。」------说话人 ：72岁，独居，河南籍；场景：晚饭后，对着收音机自言自语 |
| ② 需求条目​ | 原话 → 我想听俺们老家那段戏；痛点 → 老人不会用标准普通话指令，现有语音交互在方言场景直接失能；期望结果→ 用家乡话点播戏曲，能听懂、能播出来 |
| ③ 产品语言​ | 方言ASR前置模块 ＋ 戏曲内容库检索（E-031）；识别率≥85%，响应≤1.5s；回链编号：E-031​ |

三步走完，一句原话变成了一条可设计、可测试、可对接的PRD条目------而且任何时候点开 E-031，都能看见那位老人说的原话。

另外两条贯穿案例：

|--------------|---------------------|--------------|---------------------|
| 产品 | 原话 | 痛点 | 产品语言 |
| 思库熊​ | 「学霸笔记越记越薄、你的笔记越记越厚」 | 学生不会把零散知识结构化 | 知识树建模模型（001号），五段式输出 |
| 拓境​ | 「会议结束，130计模型已在手」 | 职场人开会抓不住博弈关键 | 流式转写＋多模匹配，会后5秒出卡片 |

注意：思库熊与拓境的「原话」来自书稿金句 ------这是被出版物验证过的痛点，属 A级证据（详见本节第四部分）。

---

三、证据链四要素

每条挂链的需求，必须标全四个要素。缺一个要素，链条就是断的。

|---------------|-------------------|-------------------------------|
| 要素 | 内容 | 例子 |
| ① 来源​ | 访谈／数据／法规／竞品／推演 | E-031 来源＝访谈（现场原声） |
| ② 等级​ | A 近实证／B 强类比／C 弱推演 | E-031 等级＝A级​ |
| ③ 时效​ | 采集时间与有效期 | 采集于预售前第3周；超两个季度需重新抽验​ |
| ④ 状态​ | 有效／被推翻／被合并 | 有效 |

四条要素齐了，需求的「出身」才算完整；缺任何一条，它就是一条随时会被推翻的口头传说。

---

四、证据分级与投入姿态

📌 规矩回顾 ：A／B／C 三级的定义与铁律，已在 P14（7.2节）第四部分 立好。本节补充的是等级决定投入姿态。

|------------------|-----------------|------------------------------|------------------------|
| 等级 | 定义 | 贯穿项目实例 | 投入姿态 ​ |
| ****A级（近实证）****​ | 可复现的数据／法规／已验证痛点 | 108模型书稿金句、用药提醒时段数据、周均使用11.6次 | 重仓进入 Must​ |
| ****B级（强类比）****​ | 邻近市场已验证的模式 | 声音克隆在陪伴场景的接受度 | 小步快跑验证​ |
| ****C级（弱推演）****​ | 推演／直觉／小样本 | 儿童需要AI情绪伙伴 | 只允许 POC 级投入​ |

三条铁律：

A级可以重仓，B级先验证，C级只配 POC。

拿 C 级证据做 A 级投入，是需求阶段最贵的错误。

---

五、证据强度三档：行为 ＞ 付费 ＞ 口头

除了 A／B／C 的可信度轴 ，证据还有一条强度轴------按「用户付出了什么」排序：

|-------------|------------------|-----------------------------------|----------------------|
| 强度 | 类型 | 含义 | 标色 ​ |
| 最强​ | 用户行为​ | 已经用脚投票------预购、留存、使用频次、取消测试反应 | �� 绿​ |
| 次之​ | 付费承诺​ | 愿意掏钱或付出时间成本------预订金、代购订单、自费买过替代品 | 🔵 蓝​ |
| 最弱​ | 口头抱怨／评价​ | 嘴上说要／说好／说想要 | �� 黄​ |

为什么这么排：

说「挺好的呀」是礼貌，说「我想要」是客套，付了钱、留下来、天天用才是证据。

需求强度与表达频度成反比------说得最凶的需求往往最弱。

两条轴的交叉用法：

|-------------|---------------|---------------|---------------|
| | 行为（绿） | 付费（蓝） | 口头（黄） |
| A级​ | 最强证据，直接进Must | 强证据，进Must | 需补行为验证 |
| B级​ | 可进Should | 小步验证 | 待观察 |
| C级​ | 补数据后可升B | 只做POC | 不立项​ |

标色管理的价值 ：一张证据矩阵摊开，绿蓝黄的分布一眼可见------满屏黄色说明你只有一堆客套话，项目该停了。

---

六、证据链真正的收益：砍需求时才显现

证据链最贵的时候不是建它的时候，是用它的那一刻------尤其是砍需求的时候。

没有证据链时，砍需求是一场立场之争：

「我觉得这个要做。」------「我觉得不用。」------吵两小时，谁也没说服谁。

有证据链时，它降维成一场规则之辩：

「把041号需求砍掉」的争论，在证据链面前变成「041的C级推演与009的A级数据冲突，按证据等级裁」------争论从立场之争降维为规则之辩。

贯穿项目数据：

• 首轮 P0 共 91条 ，过「三个再问」后剩 68条；
• 23条被降级的需求里，后来 11条 证明确实是伪需求，9条 在需求变化后重新升级为P0，只有 3条误杀。

需求阶段最贵的不是做错需求，是让团队在需求上消耗判断力。

证据链把判断力省下来，留给真正的分歧。

---

七、REQ-02 极度求真·需求证据分级模型

📌 模型索引 ：REQ-02 的完整定义见 P14（7.2节） 。此处只补它的思想源头------为什么证据分级必须配一套反偏误机制。

|---------------------------|------------------------------------|--------------------------|
| 来源 | 核心思想 | 与本模型的关联 |
| 瑞·达利欧《原则》·极度求真​ | 需要独立的事实依据，以及极度求真、极度透明的文化，才能做出最好的决策 | 把事实与观点显式分开​ |
| ****芒格·人类误判心理学（确认偏误）****​ | 人们只看见想看见的；须主动找反证 | 主动找反证，防止只收集支持性证据 |
| 张磊《价值》·长期主义​ | 长期主义是时间复利的受益者 | 真需求才配长期研发投入​ |

启用时机：

需求评审中出现「用户肯定需要」「领导说要做」「AI时代必备」等表述时，立即启用证据分级。

反模式：

• ❌ 只收集支持立项的证据，不找反证；
• ❌ 把 C 级观点包装成 A 级数据汇报；
• ❌ 评审会上凭资历压人，而非凭证据等级裁决。

确认偏误是需求工作的头号敌人------它让你在错误的需求上，越论证越自信。

---

八、需求来源的四条渠道

证据从哪来？四条渠道，决定证据的采集方向。

|---------------|----------------------------------------------------------|--------------|
| 渠道 | 内容 | 证据强度 |
| ① 用户​ | 访谈、观察、客服工单、退款理由------离行为越近，数据等级越高​ | 最强 |
| ② 业务​ | 一线员工的重复劳动、部门间的扯皮节点、老板报表上的成本黑洞 | 强（常直接对应预算） |
| ③ 竞品​ | 功能列表只能提示方向；真正的信号是竞品评论区的差评与弃用原因------那是对手花钱帮你做的调研 | 中 |
| ④ 数据​ | 埋点漏斗、使用频次、流失节点，以及书稿、课程、社群内容这类被验证过的内容资产​ | A级富矿 |

贯穿项目的渠道分布：

• 思库熊、拓境 → 主要靠第四条（书稿痛点库，直接是A级证据）；
• 陪伴熊、情绪球 → 主要靠第一条（访谈与现场观察）。

四条渠道交叉验证过的需求，才值得进入评审。

只用一条渠道得出的需求，无论听起来多合理，都只是单腿站立。

---

九、自检：你的证据链断在哪

|---------------------------------|--------------------------|
| 自检问题 | 断链信号 |
| ****① 每条PRD能点回一句原话吗？****​ | 点不回去 → 第三级转译失真 |
| ****② 原话注明场景与身份了吗？****​ | 只有一句话，没有场景 → 无法判断代表性 |
| ****③ 四要素（来源/等级/时效/状态）齐了吗？****​ | 缺等级 → 无法裁决；缺时效 → 需求可能已过期 |
| ****④ 你的证据是什么颜色？****​ | 满屏黄（口头） → 只有客套话 |
| ****④ 砍需求时，你在争立场还是查等级？****​ | 还在吵「我觉得」 → 证据链没真正用起来 |

判读：

• 五项全过 → 你的需求可以被审计；
• 三项以下 → 你手上不是需求，是一堆转述。

---

十、金句收尾

你「听懂了」却「讲不出」------需求文档里每一条痛点，都必须能在用户嘴里找到原话。

下面按 第2篇 · 第8章 · 8.2节 ​ 归位。这是需求篇的立项收口页。

先处理这一页的混内容：①「技术方案设计核心思维／需求澄清／技术选型／架构设计／方案评估／社区团购实战工作坊」属设计篇/技术篇 ，其中「社区团购」案例与本书六款硬件贯穿案例完全无关，是另一课程的内容；②「需求规格说明书十章写作指引」归位 P20；③「认知筑基四大模块（01-30／31-70／71-100／101-120）」是另一本书的目录；④REQ-01／PM-07／PM-09 的达利欧/芒格/张磊三段式卡片已在多页重复出现，本次精简吸收。

另外，你给的【内容要点】五步（识别→验证→评估→立项→复核）与正文「立项五步」（陈述难题→圈定采用者→解法对照→商业初稿→定义验证）是同一流程的两种表述，我以要点五步为主干，把正文素材完整嵌入------其中「评估」一步合并了正文的「解法与能力对照＋商业初稿」两个动作。

---

8.2　需求立项五步循环：把想法变成项目（P16）

【开头钩子】

拍脑袋立项的钱，最后都变成了烂尾的学费。

---

一、立项的本质：不是批准花钱，是强制看清现实

立项是需求阶段的收口动作。它的本质不是批准花钱，而是------

强制团队在投入之前，把现实看清楚。

立项要治的病只有一个：跳步病。

人类面对需求时最自然的反应，是直接跳进解决方案------业务方说要上AI客服，团队立刻开始选型比价。

本节这套五步循环，是达利欧五步流程在立项场景的落地（达利欧原版五步见 P05）。它把「接到需求→掏钱开工」这段最短也最危险的直线，改成一个每步留痕、每步可回头的循环。

不要在问题未识别时跳到执行；不要在诊断含糊时开始设计。

跳过诊断的项目，注定用正确的方法解决错误的问题。

---

二、五步循环：识别 → 验证 → 评估 → 立项 → 复核

|---------------|----------------|-----------------|--------------|
| 步 | 动作 | 关键产出 | 不达标则 |
| ① 识别​ | 陈述难题与市场 | 一页纸问题陈述（标注证据等级） | 退回补证据 |
| ② 验证​ | 圈定早期采用者并设计访谈 | 首批买单者画像＋访谈提纲 | 退回重做访谈 |
| ③ 评估​ | 解法与能力对照 ＋ 商业初稿 | 能力清单＋至少两方案＋财务测算 | 补Spike或重算账 |
| ④ 立项​ | 定义验证与 Go/No-Go | 成功指标、观察周期、止损条件 | 不进评审 |
| ⑤ 复核​ | 每一步留痕，三件套归档 | 立项档案＋回溯记录 | 不得开工 |

五步不是五道审批，是五次强制思考------每步都回答一个「如果不讲清楚，后面一定会炸」的问题。

---

第一步·识别：陈述难题与市场

用一页纸说清三件事：待解决的问题、受影响的人群、粗略的市场容量。

铁律 ：全部标注证据等级（A／B／C，见 P14）。

|--------------|----------------------------------------------------------------|--------------|
| 产品 | 难题与市场陈述 | 证据来源 |
| 记忆熊​ | 中国年死亡约 1000万人 ，对应约 3000万直系亲属------丧亲家庭的纪念与思念需求 | 宏观统计数据（A级） |
| 情绪球​ | 儿童需要无屏陪伴；家长对屏幕时间的焦虑 | 访谈与现场观察（B级） |

识别阶段不写解决方案，只写「谁、在哪、痛在哪」。

一上来就写功能清单的立项书，本质是在用篇幅掩盖没想清楚。

---

第二步·验证：圈定早期采用者并设计访谈

不要服务所有人，先锁定首批买单者的具体画像，然后带着访谈提纲到现场去。

硬件方法论的三段忠告（回扣 P14 三问排序）：

先确认问题是否真实存在 → 再确认用户是否愿意付费 → 最后才推进可售卖版本。

|------------|------------|------------------|
| 顺序 | 问题 | 这一问没过的后果 |
| 第一问 | 问题真实存在吗？ | 伪需求，做了没人要 |
| 第二问 | 用户愿意付费吗？ | 需要但不买单 |
| 第三问 | 可售卖版本怎么开发？ | 能做但卖不出去 |

产出物：首批买单者画像 ＋ 深度访谈提纲（带编号，可回链到证据链）

先蹲现场3天，再写第一行代码。

访谈少问「你要什么」，多问「你现在怎么办」。

---

第三步·评估：解法与能力对照 ＋ 商业初稿

这一步是两个动作，技术人最容易跳过的是第二个。

动作A｜解法与能力对照

1. 列出解决该问题需要的能力点清单；
2. 对照团队能力圈 ------圈外部分立即规划 Spike 或引入外部资源；
3. 同时给出至少两个方案，且必须包含「不做」方案。

架构师可以说「这个需求技术上不可行」，FDE必须接着问「那什么方案在现有约束下可行」。

创意择优要求至少两个可行方案同台竞技，反对意见必须记录在案。

动作B｜商业初稿（最容易跳过、最致命的一步）

用数字说话：保守估计销量与渗透率 → 搭建收入与现金流假设 → 核算单件物料与制造开销 → 推算毛利与盈亏平衡 → 再定调性、估价位、写电梯演讲。

硬件算账必须细到单件：

|------------------|--------------------------|-----------------------|
| 产品 | 单件成本 | 说明 |
| 毛绒类（思库熊／陪伴熊／记忆熊） | BOM 约124---128元​ | 共用 ESP32-S3 平台 |
| 情绪球 | 硅胶壳 约110元​ | |
| 拓境 | 磁吸方块 约130元​ | |
| 六款共用​ | 云端约0.28元/台/天​ | ASR＋TTS＋LLM，折合每月约8.4元 |

在此之上叠加包装、认证、打样、物流与渠道分成，才能反推出定价空间。

最终定价不是成本加价这么简单------它对应的是各自人群的「付费心理账户」：

|--------------|------------|---------------------|
| 产品 | 定价 | 心理账户 |
| 思库熊​ | ¥599 | 学生家长为学习方法付费 |
| 拓境​ | ¥499 | 职场人为防坑付费 |
| 陪伴熊​ | ¥599 | 子女为尽孝付费 |
| 记忆熊​ | ¥799 | 家属为纪念付费 |
| 情绪球​ | ¥459 | 家长为安心付费 |

定价不是成本加一个利润率，是找到那群人心里本来就有的那个钱包。

技术人最容易犯的错，是算得清BOM，算不清「谁为什么掏钱」。

---

第四步·立项：定义验证与 Go/No-Go

明确三件事，然后开评审会做决策：

|---------------|-------------|
| 要素 | 内容 |
| 成功指标​ | 什么数字达到多少算成功 |
| 观察周期​ | 看多久才下结论 |
| 止损条件​ | 什么情况立即停止 |

贯穿案例：陪伴熊首年目标克制地定为------

50台预售验证，月销30---50台。

立项书写得越保守，执行越可能超预期。

把首年目标写成「50台」不是没野心，是把假设压缩到可以用一次预售证伪的规模。

---

第五步·复核：每一步留痕，三件套归档

前四步每步的产出物全部留痕归档，形成立项档案。这一步的意义在半年后显现------

复核不是走形式，是把「当初为什么这么定」变成可回溯的资产。

体检做两次，就内化成了习惯（回扣 P15 证据链体检：第一年一天，第二年半天，红灯为零）。

归档内容：立项一页纸、证据矩阵、能力圈对照表、商业测算表、失败清单与规避项、成功指标表。

---

三、立项三件套

立项的正式产出，是三件套依次生成：

|-----------------------------|--------------------|-----------------------------------------------|--------------------------|
| 件套 | 回答什么 | 核心内容 | 何时用 |
| ① 商业计划书（PM-07） | ****做这件事值不值？****​ | 市场／用户、商业模式、竞争、3年财务预测、关键假设与验证计划 | 新产品线、新业务、融资／董事会审批、年度战略项目 |
| ② 可行性 Go/No-Go​ | ****能不能做？做不做？****​ | 技术可行性、能力圈对照、成本估算、风险评估、Go／No-Go 结论 | 商业计划书通过之后 |
| ③ 项目 Charter（PM-09） | ****谁来做？边界在哪？****​ | 目标、范围、里程碑、预算、RACI 、成功标准、退出标准​ | 可行性 Go 之后，负责人任命之前 |

三件套的顺序不能颠倒：

先算值不值，再判能不能，最后才定谁来做。

反过来------先任命人、再补商业计划------是人治，不是立项。

Charter 必须写「退出标准」：

只写成功标准不写退出标准的 Charter，等于只许胜不许败------那不是项目，是赌局。

---

四、每个立项必须回答三个问题

立项会的最后，用三句话收口。任何一句答不上来，不立项。

|---------------------|--------------|----------------|
| 问题 | 检验什么 | 答不出的后果 |
| ****① 终点是什么？****​ | 什么状态算「做完了」 | 无限延期，做一半改一半废一半 |
| ****② 验收标准是什么？****​ | 哪个指标达到多少算成功 | Demo当交付，业务拒用 |
| ****③ 谁买单？****​ | 付费的人是谁、为什么付 | 做出来没人要，或要的人不付钱 |

一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松。

配套：立项前先做一次「死亡推演」（REQ-06 逆向思维）

假设三年后它失败了，讣告上写的死因是什么？常见五种：

|--------------|------------|
| 死因 | 说明 |
| 伪需求​ | 没人真付费 |
| 伪壁垒​ | 竞品两周抄走 |
| 伪场景​ | 一年用一次 |
| 伪合规​ | 政策一夜清零 |
| 伪团队​ | 关键人离职即停摆 |

把死因列表贴在工位上，每季度对照一次。

先想怎么失败，是立项阶段最便宜的保险。

---

五、自检：你的立项过了几关

|----------------|--------------------------|---------------|
| 关卡 | 自检问题 | 不过的信号 |
| 识别​ | 难题与市场的证据等级标了吗？ | 只有「我觉得市场很大」 |
| 验证​ | 首批买单者画像有了吗？访谈做了吗？ | 目标用户是「所有人」 |
| 评估·解法​ | 有至少两个方案吗？含「不做」吗？ | 只有一个方案，走形式评审 |
| 评估·商业​ | 单件BOM、云端成本、定价心理账户算了吗？ | 只算了大账，没算单件 |
| 立项​ | 成功指标、观察周期、止损条件都有吗？ | 只有「尽快上线」 |
| 复核​ | 五步产出物归档了吗？Charter有退出标准吗？ | 开完会就散了，没留痕 |

判读 ：六关全过 → 可以开工；三关以下 → 拍脑袋立项的钱，最后都会变成烂尾的学费。

---

六、金句收尾

一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松。

下面按 第2篇 · 第8章 · 8.3节 ​ 归位。这是需求篇的排序与决策页------四个模型（EV、二阶后果、能力圈、逆向思维）在这里汇成一套「先算、再想、再划界、最后预演失败」的决策链。

处理说明：①你给的【金句收尾】是芒格「Invert, always invert」的原句，它更适合作为 REQ-06 逆向思维的模型引文，而非本节收尾（本页讲的是四模型并用，收尾应收在「排序」上），我在文末给了替换建议；②达利欧／芒格／张磊三段式卡片在 P05、P14、P15、P16 已重复四轮，本次精简为「思想源头一行表」，不再逐条铺陈英文残句；③REQ-03～REQ-06 在 P14 已作为「武器库索引」出现过，本节是它们的完整版正文。

---

8.3　需求优先级：别平均用力，算期望价值（P17）

【开头钩子】

需求列表越长，资源越摊越薄------用EV模型排序。

需求阶段最常听到的抱怨是「资源不够」。但真相往往是------

不是资源不够，是所有需求都被标成了 P0。

没有量化排序时，优先级由嗓门决定：谁更会争、谁更资深、谁跟老板更近，谁的需求就排在前面。EV 模型的作用，就是让排序从「谁声音大」回到「谁更值」。

---

一、决策链：四个模型，四道闸

需求进入排期前，要连过四个模型。顺序不能颠倒------先算值不值，再想副作用，再划能力边界，最后预演失败。

|------------|-------------------------|--------------|--------------|
| 序 | 模型 | 回答什么 | 核心动作 |
| ①​ | REQ-04 预期价值 EV​ | 值不值？排第几？ | 用公式量化排序 |
| ②​ | REQ-03 二阶后果​ | 上线后会引发什么？ | 追问三层后果 |
| ③​ | REQ-05 能力圈​ | 我们做得到吗？ | 圈外先 Spike |
| ④​ | REQ-06 逆向思维​ | 怎么做一定会死？ | 事前验尸，写失败清单 |

EV 决定优先级，二阶后果决定敢不敢做，能力圈决定能不能承诺，逆向思维决定怎么防。

四个模型跑完，一个需求才算「想清楚了」。

---

二、REQ-04｜预期价值：让优先级比较变诚实

1. 公式

优先级得分 ＝ Σ（概率 × 影响）− 成本 − 风险

概率要进一步拆成三个乘数：

概率 ＝ 技术可行概率 × 用户采纳概率 × 业务配合概率

影响统一折算为货币或分值，让不同性质的需求可以横向比较。

2. 为什么需要它

EV 不是精算，它的真正作用是让藏在感觉里的假设显形。

当你被迫为「AI助手」写出 ****40%****​ 的采纳概率时，争论就从「要不要做」变成了------

「凭什么是40%，而不是20%？」

这一问的价值，远大于算出来的那个数字。

3. 计算示例

某团队 Q3 只能做两个大项，候选三个：

|---------------|---------------|------------|----------------|---------------------|
| 候选需求 | 影响(万) | 概率 | 成本(人月) | EV 判断 |
| 支付重构​ | 避免损失 500 | 90% | 4 | 高，优先做​ |
| AI助手​ | 增收 200 | 40% | 6 | 中，做MVP并设阈值​ |
| 国际化​ | 增收 800 | 25% | 10 | 不确定，只预研​ |

敏感性分析：AI助手的概率若只有 20%，EV 立即垫底。

最终决策：

• 支付重构 ＋ AI助手MVP；
• 国际化只做预研，不出代码；
• AI助手设采纳率30%的复盘阈值，未达则 Q4 收缩。

这就是概率思维 ＋ 安全边际在需求排期上的落地：

资源投给长期EV最高的结构性机会，同时为不确定性留出止损线。

4. 贯穿案例（记忆熊三候选）

记忆熊上线前有三个候选需求：

|-----------------|------------|------------|------------|----------------------|
| 候选需求 | 价值 | 概率 | 成本 | EV ​ |
| 多音色选择 | 3 | 0.9 | 5人日 | 0.54​ |
| 忌日提醒仪式​ | 8 | 0.8 | 3人日 | 2.13​ |
| 情感陪伴长对话 | 9 | 0.4 | 20人日 | 0.18​ |

答案 ：先做忌日提醒仪式------高频节点场景的价值密度，远高于长对话的技术炫技。

技术炫技型需求最容易在 EV 面前现原形：价值9分又怎样，概率0.4、成本20人日，EV 只有0.18。

5. 启用时机

一个迭代／季度的需求****超过团队承载力150%****时，强制启用 EV 排序。

---

三、REQ-03｜二阶后果：追问「然后会怎样」

1. 三层后果

|-------------|-----------------------------|
| 层 | 追问什么 |
| 一阶​ | 功能直接影响谁、什么指标 |
| 二阶​ | 用户、员工、合作方会如何适应和反制​ |
| 三阶​ | 品牌、合规、组织信任受到什么长期影响​ |

一阶后果往往是诱惑，二阶后果才是真相。

经典链条：砍测试省时间 → 一阶是提前上线 → 二阶是线上故障 → 三阶是客户流失、品牌受损。

2. 为什么需要它

手上有锤子，看什么都是钉子------不用多模型追问，团队就会沉迷于一阶KPI的快感。

3. 怎么用（HR自动筛简历案例）

HR 要求 AI 自动筛简历、淘汰50%：

|-------------|-------------------------------|
| 层 | 后果 |
| 一阶​ | 初筛效率翻倍 |
| 二阶​ | 候选人投诉黑箱、优质候选人因关键词不匹配流失、HR技能退化 |
| 三阶​ | 劳动合规风险与雇主品牌受损 |

缓解措施：

• AI 只打分排序，不自动淘汰；
• 提供可解释理由；
• 每月偏见审计；
• 保留人工 override；
• 法务签字后才立项。

需求范围修订：从「自动淘汰」改为「辅助排序」。

这不是退让，而是二阶思维把项目从合规地雷上救了回来。

4. 启用时机

凡涉及数据、AI自动化决策、降本裁员类的需求，强制启用。

FDE口头禅：

「这个功能上线之后，用户会怎么用它做我们没想到的事？」

---

四、REQ-05｜能力圈：圈外必须先 Spike

1. 铁律

团队「真懂」的技术和领域，才承诺确定的交付日期；

能力圈外的需求，必须降低范围、引入外部专家，或先做 Spike（时间盒探索）。

为什么：

知道边界在哪里，比盲目自信重要得多。

AI项目最大的交付风险，来自销售先承诺日期、研发后补锅------承诺时没人知道怎么做，到期时只能靠加班和谎言维持。

承认「我不知道」并去求证，不是软弱，而是头脑极度开放的表现。

2. 怎么用

1. 列出团队过去12个月成功交付过的类似项目 ，圈外部分标红；
2. 圈外需求安排一到两周 Spike，输出可量化的验证数据；
3. 承诺分确定交付 与探索交付两档；
4. Spike结束后，据数据更新需求与日期。

3. 案例（端侧7B模型）

客户要求手机端离线跑 7B 大模型，团队擅长云端RAG但无移动端量化经验------典型的圈外。

Spike 结果：两周实测 llama.cpp 与两款机型后发现------

7B 不可行，1.8B 量化可接受。

需求修订 ：1.8B ＋ 云端兜底；工期从 8 周改为12周确定 ＋ 4周优化。

客户接受了修订 ------因为 Spike 报告里有数据，而不是口头信心。

4. 对 FDE 个人的映射

|---------------|--------------------------------------|
| 能力圈概念 | FDE 对应 |
| 圈内 | 你的主赛道（π型的那一竖） |
| 圈外识别 | 四域边界逻辑帮你认出圈外 |
| Spike能力 | 让你敢于探圈，把「不可行」变成「有数据支撑的可行或放弃」 |

架构师帮你画定能力圈，FDE 要带着 Spike 去圈外探路。

---

五、REQ-06｜逆向思维：先写「如何确保失败」

1. 什么是事前验尸

立项前做一次 pre-mortem（事前验尸）：

头脑风暴「怎样做一定让这个项目惨败」→ 列出十条失败模式 → 每条反推为带负责人和截止日期的主动规避项​ → 纳入立项评审必查清单。

2. 为什么需要它

要明白如何成功，先研究如何必然失败。

达利欧指出，失败是进化的天然副产品------预写失败清单，等于在付出代价之前完成「痛苦＋反思」。

避免永久性损失，优先于追逐暴利。

3. 案例（第三次立项的数据平台）

一个历史上失败过两次的跨部门数据平台，第三次立项时先开死亡推演会，列出六条死法：

|-----------|------------------|
| # | 死法 |
| ① | 业务方不出 Data Owner |
| ② | 没有统一指标口径 |
| ③ | 各部门各建看板 |
| ④ | 无 SLA |
| ⑤ | 安全不前置 |
| ⑥ | 做成大仓库没人用 |

六条规避项随即成为立项门槛：

• 业务方必须指定 Data Owner 并绑定 KPI；
• 指标字典 v1 先于开发；
• 单一入口 MVP；
• 安全评审在第二周完成；
• MVP 成功标准定为三个业务方周活。

结果 ：第三次立项四个月MVP上线、六个月推广到八个部门。

4. FDE 的逆向心法

把乐观用在执行，把悲观用在规划。

立项时想象尸检报告，交付时才能参加庆功宴。

FDE 逆向思维不是悲观，是------

在付出代价之前，先把代价想清楚。

---

六、四模型思想源头（一行速查）

|----------------------|-----------------------------------|------------------------------------|
| 模型 | 思想源头 | 一句话 |
| REQ-03 二阶后果​ | 达利欧 Second-Order Thinking；芒格「铁锤人」 | 「然后会怎样」------避免手上有锤子看什么都像钉子 |
| REQ-04 预期价值​ | 达利欧 Expected Value；芒格概率思维与安全边际 | 用概率而非确定性决策，安全边际补偿不确定性 |
| REQ-05 能力圈​ | 芒格 Circle of Competence | 知道边界在哪，比盲目自信重要；对交付诚实＝长期信任​ |
| REQ-06 逆向思维​ | 芒格 Inversion；价值投资「避免永久性损失」 | 先写失败清单；避免永久性损失优先于追逐暴利​ |

---

七、四模型联合用法：一条作业链

四个模型不是四个孤岛，接到需求后按这条链跑：

① 伪需求七问（P14）→ 快速过滤

↓

② 五步循环立项（P16）→ 展开分析

↓

③ REQ-04 EV → 排序，确定做哪个

↓

④ REQ-03 二阶后果 → 查副作用，修订范围

↓

⑤ REQ-05 能力圈 → 识别圈外，安排 Spike

↓

⑥ REQ-06 逆向思维 → 失败清单，纳入评审

↓

⑦ Go/No-Go 决策收口（P16 立项会）

---

八、自检：你的排期经得起追问吗

|--------------|-----------------|-----------------|
| 模型 | 自检问题 | 答不出的信号 |
| EV​ | 这个需求的概率是拍的还是算的？ | 「应该能成吧」→ 概率未显形 |
| 二阶​ | 上线后用户会怎么「用坏」它？ | 只想一阶收益 → 副作用未评估 |
| 能力圈​ | 这个技术我们真做过吗？ | 「应该不难」→ 圈外未标红 |
| 逆向​ | 它最可能怎么死？ | 说不出死法 → 没做过事前验尸 |

判读 ：四问全答得出 → 排期站得住；两问以下 → 你不是在排期，是在许愿。

---

九、金句收尾

📌 你原稿给的收尾句 ------「如果要明白人生如何得到幸福，先研究如何获得痛苦；反向思考，总是反向思考。」------是芒格 Inversion 的原句，更适合作为 REQ-06 的模型引文（已放在第六部分）。作为本节收尾，它只覆盖了四个模型中的一个。

下面按 第2篇 · 第9章 · 9.1节 ​ 归位。这是需求篇的挖掘工具页------把「广大用户」逼成有名有姓的具体的人。

处理说明：①原文中「5W2H画像」「AI辅助三组公式」「竞品拆解」各出现了两次（略有不同版本），已合并去重、取并集；②「Spring Boot Actuator」是技术篇监控组件，与本节无关，删除；③你给的【金句收尾】与【开头钩子】高度呼应（点击／叹息），是本轮少见的天然配套，直接保留为主收尾。

---

第9章　需求挖掘与规格：访谈、评审与PRD

章眼：没有画像的需求，是在为想象中的人做产品。

9.1　需求挖掘实操：画像、访谈与AI辅助（P18）

【开头钩子】

报表告诉你用户点了什么，访谈告诉你用户为什么叹息。

两类数据的分工：

|---------------|-------------------|---------------|
| 类型 | 回答什么 | 工具 |
| 定量数据​ | 有多少、多频繁 | 埋点、漏斗、问卷、用药记录 |
| 定性访谈​ | 为什么、怎么发生​ | 深度访谈、现场观察 |

定性与定量不是替代关系，是显微镜与望远镜 的关系------FDE要两只眼睛都睁着。

---

一、画像：把「广大用户」逼成具体的人

画像的价值不在于写得漂亮，而在于逼团队承认用户不是抽象的人。

1. 5W2H：最朴素也最耐用的骨架

七个维度，各有不可替代的诊断功能：

|---------------------|----------------|-------------------------|-------------------------------|
| 维度 | 要回答的问题 | 陪伴熊示例 ​ | 思库熊示例 ​ |
| Who​ | 谁在用？谁付费？ | 70-80岁独居老人，方言为主 | 家长付费、学生使用（双边需求） |
| Why​ | 核心动机与情感驱动 | 子女远程尽孝、老人怕孤单 | AI搜索让孩子更不爱思考，家长焦虑升级 |
| When/Where​ | 什么时刻、什么场景 | 白天在家、用药时间、想听戏时 | 考试前2周、每天晚自习后；书桌（须无干扰、可语音、免打字） |
| What​ | 要完成什么任务 | 聊天、听戏、吃药提醒、收留言 | 「笔记越记越薄」的学习掌控感​ |
| How​ | 现在怎么凑合解决 | 收音机、记性、电话、微信群 | 说话即可，5-15分钟 micro-task |
| How much​ | 谁付费、愿付多少 | 子女付费，¥599硬件＋¥19/月 | 硬件≤¥600，订阅≤¥40/月 |

Why 这一栏最容易写错：

子女买陪伴熊的动机不是让老人聊天 ，而是远程尽孝的焦虑与无法亲自陪伴的愧疚。

动机错了，功能就错------正因为动机是「尽孝」,才有了「不在身边，也在身边」的文案和情绪周报。

2. 画像必须落到「有名有姓、有一天作息」的人

5W2H 写完，画像必须收敛成一个虚拟人物：

张奶奶，74岁，山东菏泽人，高血压，儿子在深圳......

六款产品画像卡全集（统一骨架：基础属性／一天时刻表／痛点Top3／现有替代方案／付费决策链／隐私敏感度）：

|---------------------|----------------|---------------|-----------------|
| 画像卡 | 基础属性 | 关键时刻 | 付费决策链 |
| 小雨·初三学生​ | 15岁，住校两周回家一次 | 晚自习卡题、周日补笔记 | 自己选 → 妈妈付款 |
| 陈奕辰·大三​ | 21岁，考研＋秋招双线 | 图书馆效率低谷、导师催论文 | 自己决策 |
| 老周·32岁项目经理​ | 大厂8年，跨部门协作重灾区 | 会议后甩锅、季度述职 | 自己决策 |
| 王奶奶·74岁​ | 独居，子女在外地，粤语使用者 | 晚饭后孤独感峰值、晨起用药 | 子女全权决策​ |
| 李女士·42岁​ | 异地女儿，母亲独居 | 每周通话2次、愧疚感 | 自己付款 |
| 追思者·38岁​ | 父亲去年离世 | 清明、忌日、深夜 | 自己决策＋家人共识 |
| 朵朵妈·35岁​ | 女儿6岁分床睡焦虑期 | 睡前哭闹、放学情绪爆发 | 妈妈决策 |

两张最值得细读的卡------它们揭示了陪伴类产品的两条铁律：

|--------------|--------------------------------------|------------------------|
| 卡 | 隐私敏感度 | 设计后果 |
| 王奶奶​ | 低------老人不怕被听，怕被忘 | 陪伴熊存摘要即可​ |
| 朵朵妈​ | 极高------家长怕的不是数据被存，是孩子的世界被窥视 | 情绪球连摘要都要90天删除​ |

同样是语音交互，两条产品线的隐私设计因此走向完全相反的方向。

画像卡不只是需求素材，它直接决定架构走向。

3. 九宫格填法：两条军规

|--------------|--------------------------------------------------|
| 军规 | 内容 |
| 军规一​ | 痛点／场景／现有方案三格必须有访谈原话佐证，禁用想象填充​ |
| 军规二​ | 付费意愿／决策链两格必须访谈决策者本人，而非使用者（陪伴熊的子女、思库熊的家长） |

精度原则 ：一产品一主线人物精填九格；边缘人物（如拓境的HR视角、记忆熊的其他家属）只填三格 ------画像的精度要与它对决策的影响成正比。

4. 时刻表：最容易被省略、却最值钱的一栏

|-------------|--------------------------------------------------------------------|-------------------------------------|
| 画像卡 | 时刻表发现 | 转化为规格 |
| 老周​ | 会议高峰10:00-12:00与14:00-17:00；防坑需求集中在会后10分钟内；晚21:00后是「复盘焦虑期」 | 周复盘推送定在周日20:30​ |
| 小雨​ | 晚自习19:00-21:30是卡题高峰，但学校禁用电子设备​ | 思库熊「语音报号」设计成可盲操作，回家后小程序补看卡片 |

时刻表数据后来直接变成了推送策略与灯效节奏的规格。

---

二、访谈：三不原则与核心手艺

访谈三不原则：

不引导、不辩护、不推销------只追问原话。

1. 访谈前准备决定质量上限

|-----------------|--------------------------------------------------|
| 准备 | 要点 |
| 明确假设​ | 访谈不是聊天，你是带着证据分级任务去的：把C级观点升级为B级观察，或证伪 |
| 招募对的人​ | 优先找正在用笨拙替代方案解决问题的人，而不是「表示感兴趣」的人 |
| 半结构化提纲​ | 主干问题5-8个，留出一半时间追着意外走​ |
| 选对场景​ | 能去现场就不去会议室------老人在自己家沙发上说的话，比在访谈室里真实十倍​ |

说「我会买」的人不可信；正在为此花钱、花时间、忍受痛苦的人才可信。

2. 提问技巧：问行为，不问观点

|----------------------|--------------------------------|
| ❌ 不要问 | ✅ 要问 |
| 「您会喜欢AI陪伴吗」（得到礼貌的假话） | 「您上一次感到孤单是什么时候、那天做了什么」（得到真实行为） |
| 「您是不是觉得很麻烦」（引导） | 「那个过程您感觉怎么样」（中性） |

经典问法：

• 讲一次最近发生的具体经历；
• 上次遇到这个情况您是怎么处理的；
• 有没有哪次觉得特别麻烦／特别感动；
• 如果有魔法棒，您最想改变哪件事。

3. 七问脚本

现在的做法 → 最近一次具体经历 → 最痛的一刻 → 花过的代价 → 如果不解决会怎样 → 如果你做一个东西它必须做到什么 → 愿意付多少

4. 倾听与追问：三层追问法

沉默是工具 ------用户停顿时不要急着填补，最好的信息往往出现在五秒沉默之后。

|----------------|-------------|
| 层 | 追问 |
| 对方说了判断 | 「这东西不好用」 |
| 追具体事实​ | 「是哪一步、什么时候」 |
| 追到原因​ | 「当时您期望发生什么」 |

钉死模糊词：「经常」是一周几次？「麻烦」是多花了时间还是多花了钱？

记录非语言信息 ：犹豫、苦笑、下意识的动作------老人摸熊头的自然程度，比任何口头评分都说明问题。

5. 反例收集：高级访谈者的标志动作

确认偏误会让用户和访谈者合谋：用户挑你爱听的说，你只听到想听的。

对抗方法------主动找反证：

• 有没有哪次这个问题没发生？
• 有没有谁是不需要这个东西的？
• 您身边有没有人用了类似产品但放弃了？

负向信息的价值远高于正向好评。

一个说「我妈用了三天就不碰了」的子女，能帮你避免整个错误方向。

6. 三套可直接套用的话术模板

|----------------|--------------------------|---------------|
| 模板 | 话术 | 适用 |
| 痛点复现式​ | 「说说上一次被这件事卡住的具体经过，越具体越好」 | 思库熊学生访谈 |
| 双边对账式​ | 「如果只能满足你或爸妈一边的需求，你选哪边」 | 陪伴熊子女访谈 |
| 红线探测式​ | 「什么情况下你会立刻停用这个产品」 | 记忆熊家属、情绪球家长访谈 |

三套话术的共同骨架是------「要故事不要观点」：观点会迎合，故事不会。

访谈后纪律 ：24小时内 输出结构化纪要，按痛点／场景／现有方案／付费意愿／反例五类聚类，每条标注证据等级。

---

三、敏感场景：记忆熊七题问卷

高敏感场景的信息采集，既要技术可用 ，又要情感可敬。

|-----------|--------------------|-------------------|----------------------|
| # | 问题 | 采集什么 | 系统落点 |
| ① | 他/她最常叫您什么 | 称呼 | 对话开场真实感锚点 |
| ② | 最常说的5句话 | 口头禅（多穿点／别熬夜／吃饭了吗） | RAG命中率最高的部分​ |
| ③ | 性格关键词（严厉/温柔/幽默/唠叨） | 人格参数 | 人格Prompt基调 |
| ④ | 重要纪念日（生日/忌日/结婚纪念） | 高情感价值时刻 | 纪念日主动关怀 |
| ⑤ | 生前说过最难忘的一句话 | 高情感价值语料 | 关键时刻关怀 |
| ⑥ | 特殊习惯（抽烟/喝茶/听戏/晨练） | 生活质感 | 话题库 |
| ⑦ | 禁区话题清单 | 绝对不提的内容 | 安全护栏 |

三条设计逻辑：

1. 只问行为事实与具体语言，不问抽象评价------用户答不出「父亲的人格特质参数」，但答得出他常说的话；
2. 每题直接映射系统字段 ------采集即生产，没有一个问题是为填表而问；
3. 问卷本身就是合规与情感缓冲------它在用户最脆弱的时刻提供了一个结构化的怀念动作，同时为声音授权、禁用「复活」承诺、数据销毁规则预留告知节点。

当熊里传来爷爷的声音说「别太辛苦」------产品的情感价值达到顶点。

---

四、样本量：最小可用线

「要访谈多少人才够」，贯穿项目给出的工程化答案：

|---------------|---------------|-----------------------------------------|
| 场景 | 样本线 | 判据 |
| 痛点发现​ | 12人​ | 新增痛点出现率低于1/12即饱和 |
| 双边需求​ | 每组9人​ | 使用者与决策者各9 |
| 付费意愿​ | 20人​ | 含5名「拒绝者」------拒绝者的理由比购买者的理由更值钱​ |

六款产品共 87份访谈，完全按这三条线铺开。

比样本量更重要的是「负样本」的刻意引入：

每个访谈批次必须包含 ****20%****​ 的「不符合目标画像」者------他们的「无感」是产品边界最诚实的探测器。

案例胶囊：思库熊访谈中最有价值的一句话，来自一位负样本家长：「这东西挺好，但我儿子缺的不是方法，是想要他学的心。」------这句话催生了第六模块（心态情绪内耗89-108号）的优先级上调。

样本要覆盖角色光谱 ：陪伴熊的访谈名单里必须同时有健康老人、慢病老人、独居老人、与子女同住老人，以及异地子女和同城子女------任何一边的缺席都会让画像失真。

---

五、AI辅助三件套

AI改变的不是「要不要访谈」，而是访谈的工程化程度。

1. AI访谈工程三件套

|---------------------|--------------------------------------------------|-----------------------------------|
| 件套 | 内容 | 效果 |
| ① 访谈提示词库​ | 破冰、追问、沉默应对、偏离拉回四类共 38条提示词，供访谈者在现场耳机里实时参考 | 把新手访谈者的水平托到平均线以上​ |
| ② 实录自动清洗管线​ | 转写后AI完成「去口头语、分段、主题标注、证据候选打标」四步 | 一场60分钟访谈的整理时间 从3小时压到25分钟​ |
| ③ 证据编号机器人​ | AI从清洗后的实录里识别「行为证据」与「表达证据」，分别打上E编号候选 | 人工只做确认与驳回​ |

三条纪律保证AI辅助不变成AI幻觉：

1. 证据编号必须由人工确认后生效------AI只有提名权，没有决定权（214条证据全部有原始录音时间戳可回溯）；
2. 转写文本与录音必须双存档------任何引用可一键回到原声，避免「转写失真」层层放大；
3. 月度抽样复核------随机抽10%的AI打标做人工盲审，准确率低于90%就回滚提示词版本。

经济学：

63场访谈按传统方式需189小时整理，AI辅助后约78小时，省下的111小时相当于半个全职人力。

对五人团队而言，AI工作流不是锦上添花，是把「做不完」变成「做得完」的那根杠杆。

2. 三组提问公式（可直接复制）

共同结构：角色 ＋ 任务 → 输入材料 → 输出格式 → 质量标准

公式一｜访谈纪要与痛点聚类

你是资深需求分析师。下面是N份用户访谈转录稿，请：1）提取所有痛点，按频次排序；2）每个痛点标注典型原话、发生场景、现有替代方案；3）区分高频与偶发；4）标注证据等级（A数据/B访谈/C推测）；5）输出三个最值得验证的需求假设。

效果 ：十份纪要的处理时间从两天压到两小时 ------但FDE必须回听关键段落校验，AI会礼貌地把用户的客气话提炼成需求。

公式二｜画像与场景生成

你是跨域产品专家。基于以下产品事实，请生成：1）核心用户与付费用户各一份5W2H画像，具体到有姓名的一天；2）三个高频场景和两个边缘场景；3）反场景（什么情况下绝不该打扰用户）；4）每个场景给出触发时刻、用户任务、产品应有反应。

公式三｜需求质量审查

你是苛刻的需求评审委员，信奉极度求真。请审查这份需求草案：1）每条需求的证据等级，C级有哪些；2）找出三个伪需求特征（无场景、无付费方、无替代方案痛点）；3）二阶后果分析；4）用伪需求七问逐条提问；5）给出Go/No-Go建议。

这组公式的价值在于AI不会照顾任何人的面子------让AI先充当那个说「皇帝没穿衣服」的人，评审会上的真问题会少一大半。

3. 人机分工

AI负责生产素材，人负责校验、追问与决策。

AI是执行工具，不是决策大脑。

访谈材料的处理纪律：

原话不可改写，只能标注------LLM的每一次「润色」都是对证据的污染。

---

六、访谈伦理与样本偏差的三个修正

伦理三则

|-----------|---------------------------------------------------|
| 则 | 内容 |
| ① | 录音必须逐场口头确认并留痕​ |
| ② | 涉未成年人的访谈必须有监护人在场且单独授权​ |
| ③ | 哀伤相关人群（记忆熊）经公益组织转介、由心理背景成员主访、访谈后提供心理支持资源​ |

案例胶囊 ：记忆熊的8组家庭访谈里，有2组在访谈中情绪失稳，主访者当场终止访谈转入陪伴流程------这两组数据后来一条都没用，但品牌的信任正是从「我们没用」里长出来的。

样本偏差的三个修正

|-------------------|-----------------------------------------------|
| 修正 | 内容 |
| ① 极端用户配额​ | 每轮样本强制纳入20%重度将就者（替代方案用得最狠的人），他们的痛感最真实 |
| ② 沉默用户回补​ | 流失用户与拒绝访谈者各占10%配额------他们的不参与本身就是证据​ |
| ③ 访谈者轮换​ | 同一受访者至少被两名不同风格的访谈者接触过一次，消除单人风格的系统性诱导 |

效果 ：63场访谈经三重修正后，证据台账里「访谈引出」类证据的复现率从64%提升到81%------高出17个百分点。

这就是方法论的含金量。

---

七、竞品与替代品扫描

四步拆解法

|---------------------|-------------------------------------------------------------------------------------|
| 步 | 动作 |
| ① 定问题​ | 本次拆解要回答的核心问题不是竞品长什么样 ，而是市场空白在哪里、我们凭什么赢​ |
| ② 拆定位与人群​ | StoryFile面向海外有家族影像传统的高知家庭；HereAfter面向习惯App订阅的年轻用户------两者都未覆盖中国家庭对实体寄托物的偏好​ |
| ③ 拆功能与体验链路​ | 录什么、怎么交互、付费点在哪、放弃点在哪​ |
| ④ 提炼策略空白​ | 视频非实时、App无硬件------毛绒实体＋实时对话的组合无人占据​ |

记忆熊赛道扫描：

|-----------------------|------------|------------|---------------------------|
| 竞品 | 形态 | 定价 | 弱点＝你的机会 ​ |
| StoryFile​ | 录制访谈视频库 | 按次/订阅 | 录制门槛高，仪式感强但日常陪伴弱 |
| HereAfter AI​ | App语音问答 | 订阅制 | 无实体寄托，老人不会用App​ |
| 国内AI纪念小程序 | 纯软件对话 | 免费＋打赏 | 无硬件载体，情感浓度低，合规粗放​ |

记忆熊定位由此清晰：

不是复活，是可对话的纪念档案 ------宣传用「思念有声、回忆可触」，严格禁用「复活」「重生」等字眼。

六条赛道的替代品思维

替代品才是需求的真正对手。

|---------------|---------------|-----------------------|---------------------------------------------|
| 赛道 | 直接竞品 | 替代品 ​ | 差异化卡位 |
| 学习​ | 词典笔与学习机（硬件红海） | 搜题App＋人工辅导​ | 思库熊卡位「方法论内化」------竞品都不做的练习闭环 |
| 职场​ | 录音转写笔 | 自己忍着​ | 拓境卡位「会后5秒防坑卡片」，把录音笔的「记录价值」升级为「应对价值」 |
| 银发陪伴​ | 智能音箱 | 收音机、电话、微信群 | 方言＋戏曲＋用药引擎＋子女双向通道 |
| 亲情​ | --- | 微信视频 | 声音克隆＋角色档案＋场景剧本 |
| 纪念​ | 纪念App/小程序 | 手机里不敢删的语音 | 七题问卷＋实体寄托＋合规门禁 |
| 儿童情绪​ | 故事机 | 家长自己哄​ | 无屏共情＋隐私架构（家长只看摘要） |

竞品功能表只能作参考，不能当需求证据------对手做了不代表用户需要（REQ-02证据分级的明确要求）。

---

八、三级转译实战：六段原话走完全链

📌 规矩回顾 ：三级转译的骨架见 P15（8.1节）。此处补六段贯穿案例的完整示范。

|--------------------------------------|------------------------|-----------------------------------------------|
| 访谈原话 | 需求条目 | 落点模型／功能 |
| 「我错题本抄得可认真了，但抄完就再也没翻开过。」 | 错题必须带闭环动作​ | 004错题溯源归因＋003间隔检索，错题本从「抄写物」变成复习队列生成器​ |
| 「会上明明说好了，会后群里他就不认了，我说什么？」 | 口头共识需要即时固化​ | 006口头共识消散模型，会议结束5秒内推送共识要点＋留痕清单 |
| 「我每周给我妈打电话，她永远说『挺好的你忙吧』，我根本不知道她好不好。」 | 状态感知需要非侵入通道​ | 情绪周报（标签＋摘要，不含原文）------子女「知道但不偷听」 |
| 「我爸手机里还有300多条语音，我不敢删，也不敢听。」 | 纪念素材需要被温柔地结构化​ | 七题记忆问卷＋语音素材提干声服务 |
| 「孩子跟谁都不说。」 | 低门槛倾诉出口​ | 捏握唤醒＋共情反射 |
| 「戏听一半就睡着。」 | 内容主动降级​ | 入睡检测 → 音量渐弱 |

三级转译的人机分工：

|--------------|---------------|---------------------|
| 层 | 谁做 | 纪律 |
| 原话层​ | 只记录 | ****不许改写（证据保真）****​ |
| 条目层​ | LLM批量抽取 | 效率 |
| 产品层​ | 人工拍板​ | 判断 |

贯穿项目数据 ：87份访谈 → 214条需求条目 ​ → 其中 61条进入P0清单、38条进入模型库触发词、22条成为Prompt约束。

访谈不是新闻采风，是产品语言体系的原料矿。

---

九、自检：你的挖掘站得住吗

|------------------------|---------------|
| 自检问题 | 危险信号 |
| ****① 你的画像有名有姓吗？****​ | 只有「25-45岁职场人」 |
| ****② 痛点三格有原话佐证吗？****​ | 靠想象填充 |
| ****③ 你访谈了决策者本人吗？****​ | 只访使用者，付费方是猜的 |
| ****④ 样本里有负样本吗？****​ | 全是「感兴趣」的人 |
| ****⑤ 你问的是行为还是观点？****​ | 问了「您会喜欢吗」 |
| ****⑥ 你找过反例吗？****​ | 只收集支持性证据 |
| ****⑦ 原话被AI改写了吗？****​ | 转写稿「润色」过 |

判读 ：七问全过 → 你的需求有地基；四问以下 → 你在为想象中的人做产品。

---

十、金句收尾

AI能告诉你用户「点击」了什么，但只有人类能理解他们为何「叹息」。

下面按 第2篇 · 第9章 · 9.2节 ​ 归位。这是需求篇的评审收口页。

这一页原文质量很高，几乎全部属于本节------我只做了三处处理：①P13 的「五件产出物」（立项视角）与本节的「五件套」（需求收口视角）是两套清单，我在第六部分做了衔接说明，避免读者混淆；②六场评审会纪要表只列出6条，而正文说「23条争议」，已标注为节选；③「第12章两轮设计评审」是旧版章节号，已按本书目录校正。

---

9.2　需求评审会：花钱买「不做」的资格（P19）

【开头钩子】

评审会最大的产出，不是通过了多少需求，是砍掉了多少需求。

需求评审会不是审批会，是甄别真需求的最后一道闸门。它的产品不是「通过／不通过」，而是------

把「技术能做到」与「情感上该不该」分开裁决的能力。

---

一、评审会的四条会议纪律

|--------------------|-------------------------------------------------|
| 纪律 | 内容 |
| ① 带证据来​ | 每条需求必须带证据等级来，没证据的回去补------空白即退回，制度比自觉可靠 |
| ② 反对必记录​ | 反对意见必须记录在案，不得抹掉；创意择优要求至少两个方案同台竞技 |
| ③ 谁背结果谁权重​ | 不是谁声音大听谁的，是谁为结果负责，谁的权重高​ |
| ④ 否决要写理由​ | 每次否决连理由一起归档------不做清单同样进文档​ |

没有否决记录的评审会，多半是走过场。

门禁通过率长期100%，本身就是门禁形同虚设的信号。

---

二、PRD 的最高境界：是「非目标」那一段

PRD 的最高境界是「非目标」那一段------它替未来的你挡住最多的诱惑。

六款产品的 PRD 用同一副骨架，好处是评审会可以横向对比：

|--------------------------|-------------------------|
| 栏 | 内容 |
| 一句话定位 | 产品是什么 |
| 目标用户与关键时刻 | 谁、在什么时刻需要它 |
| ****真需求 Top3（附证据编号）****​ | 痛点是什么、证据在哪 |
| ****非目标（明确不做）****​ | ****记录的是「我们忍住没做什么」****​ |
| 成功指标 | 激活／周活／订阅转化三线 |

六款 PRD 头两栏对照

|------------------|---------------------|-------------------------------------------|
| 产品 | 一句话定位 | 真需求 Top3（证据编号） |
| 思库熊​ | 把108套学习模型变成可语音调用的教练 | 卡题没人讲思路（E-011）／笔记越记越厚（E-014）／复习无节奏（E-017） |
| 拓境​ | 上场前的最后一次彩排 | 向上沟通没回音（E-021）／要不到资源（E-023）／述职没抓手（E-026） |
| 陪伴熊·基础版​ | 不在身边，也在身边 | 方言没人聊（E-031）／戏曲没入口（E-032）／吃药靠记性（E-034） |
| 陪伴熊·亲情版​ | 团圆的存档键 | 想听原来的声音（E-041）／异地缺席感（E-042） |
| 记忆熊​ | 可对话的纪念档案 | 思念有处安放（E-051）／忌日更难熬（E-053） |
| 情绪球​ | 孩子发脾气时的伙伴 | 情绪无处安放（E-061）／家长缺方法（E-062） |

17条非目标里最著名的五条

六款产品合计写下 17条非目标，这五条最有代表性：

|--------------|------------|-----------------------------|
| 产品 | 不做 | 为什么 |
| 思库熊​ | 「拍照解题」 | 不想成为抄答案工具 |
| 拓境​ | 「职场八卦分析」 | 合规与伦理双风险 |
| 陪伴熊​ | 「健康监测」 | 医疗资质门槛 |
| 记忆熊​ | 「自由双人对话」 | 二次伤害风险 |
| 情绪球​ | 「屏幕」 | 42分钟 vs 18分钟的数字（有屏反而缩短互动时长） |

非目标清单是需求阶段最值钱的一段------它记录的是团队忍住没做的那些事。

每一条被写进「非目标」的内容，都是未来省下的一百小时返工。

---

三、技术能做到 ≠ 情感上该做：记忆熊双人对话之辩

为了展示需求评审的真实质感，这里还原一场有分歧的评审纪要。

议题：记忆熊标准版是否包含「双人对话模式」（同时模拟两位已故亲人对话）。

|-------------|---------------------------------------------------------------------------------------------------|
| 方 | 最强论点 |
| 正方​ | 双亲家庭场景真实存在，客单价可上探至1199元；技术上仅是Prompt编排从单角色改双角色，增量成本低​ |
| 反方​ | 双人对话的「戏剧感」会放大失真风险------两位亲人从未有过的对话被AI编造出来，情感伤害不可逆 ；且双角色的价值观冲突（父母生前若观念不合）没有任何兜底方案​ |

关键转折------一位有丧亲经历的顾问说了一句话：

「你们在替他们说话，一次可以；同时说两个，就是在演他们。」

最终决议：

|-----------|---------------------------------------------------------|
| 项 | 结论 |
| 双亲版 | 保留​ |
| 双人对话 | 降级为「双人间切换」------同一时刻只有一位亲人开口，另一位以「你妈以前总说」的方式被引用 |
| 相互对话功能 | 标记 Won't，写入非目标清单 |
| 归档 | 决议连同理由进决策日志（ADR-012），并同步给设计篇的Prompt槽位约束 |

三个月后，决议的价值显现：

亲情版上线后收到一条用户留言------「熊用我妈的口气劝我爸戒烟，把我爸听哭了」。

这条留言提示：单角色＋引用式提及，已经是情感安全边界。记忆熊若当初上了双人对话，风险敞口不可估量。

技术能做到的事情，情感上不一定该做------需求评审会是替用户守住这条线的地方。

---

四、反例库：三个被打回的真实提案

|----------------|---------------------------------|-------------------------------|
| 被打回的提案 | 打回理由 | 后来发生了什么 ​ |
| 给思库熊加「错题拍照OCR」 | 解决的是「省事」不是「学会」，且OCR准确率达不到语音闭环体验 | ****竞品做了，差评区前三条全是「识别错答案」****​ |
| 给陪伴熊加「健康手环监测」 | 医疗级数据触发器械资质，5人团队无法承担 | 另一家创业公司因此卡在注册证上14个月​ |
| 给记忆熊做「AI复活直播」 | 伦理红线 ＋ 不可控幻觉 ＝ 双重事故源 | 行业同类产品两次登上负面新闻​ |

反例库最贵的价值，是那句「后来发生了什么」------它证明了当初的否决不是保守，是先见。

---

五、六场评审会：真需求是被辩出来的

六款产品各开一场需求评审会，合计 14.5小时 ，留下 23条争议记录。以下是六条代表性交锋（节选）：

|------------------|----------------------|-----------------|-------------------------|--------------------------|
| 会议 | 争议焦点 | 增长侧最强论点 | 需求侧最强论点 | 最终决议 |
| 思库熊 D18​ | 要不要做「拍照解题」 | 家属学生的刚需入口，引流利器 | 解决「省事」不解决「学会」，与产品价值观冲突 | 否决，写入非目标第一条 |
| 思库熊 D19​ | 108模型一次全上还是分批 | 内容多才好卖 | 分批上线可按调用数据迭代话术 | 折中：内测72套，正式前全量 |
| 拓境 D16​ | 目标用户定「职场新人」还是「全体职场人」 | 盘子大 | 新人痛点锐利但付费力弱；老手付费力强但工具多 | 定位「入职1-8年」，13计优先 |
| 拓境 D17​ | 要不要语音之外加App文字输入 | 安静会议室场景刚需 | 双输入路径翻倍开发量，MVP不做 | 否决，二期评估 |
| 陪伴熊 D20​ | 方言优先级怎么排 | 粤语用户多、消费力强 | 川渝识别数据最成熟，先啃能赢的 | 川渝／粤语首发，吴语二期​ |
| 陪伴熊 D22​ | 用药提醒要不要接「秒手」外呼 | 误报影响信任 | 外呼通道成本高，先做设备本地＋子女App双通道 | 双通道方案，外呼暂缓​ |

23条争议的分布规律

|--------------|----------------------------------------------------|
| 数据 | 数值 |
| 增长侧发起的提案 | 17条 ，被否决 11条 （否决率65%） |
| 需求侧发起的提案 | 6条，被否决 0条 ------但为换共识平均让步1.4项设计细节​ |
| 被否决的11条若全部执行 | 事后估算将多烧47万元与5个月工期 ，超过全年硬件利润的三分之一​ |

健康的评审会不是谁声音大听谁的，而是「谁背结果谁权重」。

否决率65%不是内耗，是把47万和5个月从悬崖边拉了回来。

---

六、需求阶段收口：交付物五件套

📌 与 P13 的衔接 ：P13 列出的是立项视角 的五件产出物（画像卡／证据链台账／PRD／评审记录／立项书）；本节是需求阶段收口视角的五件套。两者是同一批资产的两种组织方式------立项书在 Go 决策时生成，其余四件贯穿需求全程。

六款产品的需求阶段各产出五件套：

|------------------|------------|
| 件套 | 内容 |
| ① 画像卡​ | 9张 |
| ② 证据台账​ | 214条 |
| ③ PRD​ | 6份（含非目标） |
| ④ 优先级矩阵​ | P0-P2 三级 |
| ⑤ 验收标准​ | 每条P0配可测试数字 |

装配顺序有讲究：

① 画像卡（锁定是谁）

↓

② 证据台账（锁定为什么）

↓

③ PRD（锁定做什么）

↓

④⑤ 优先级矩阵 ＋ 验收标准（锁定先做什么、做到什么算完）

顺序不能颠倒------顺序错了，就是在不知道为谁做的时候，先决定了做什么。

验收标准：五件套里最容易被敷衍的一件

三个正例：

|------------|----------------------------------------------|
| 产品 | 验收标准 |
| 思库熊 | 晚自习卡题场景下，从提问到给出思路引导完成，端到端不超过5秒（P95）​ |
| 陪伴熊 | 用药提醒连续7天送达率不低于97%​ |
| 陪伴熊 | 方言闲聊场景首字响应不超过800毫秒​ |

共同点 ：有场景、有数字、有口径。

对照一个反例：

「响应速度快、识别准」------这不是验收标准，是愿望清单。

总装后的验收动作

只有一个 ：把五件套交给设计阶段的负责人，请他提三个问题。

|------------|------------|
| 结果 | 含义 |
| 问不出三个问题 | 需求文档已经足够扎实 |
| 问得出 | 还有暗坑 |

需求阶段的债，利息全部记在设计阶段。

设计篇两轮设计评审里，第一轮被打回的5个0分，有3个的根源都能追溯回需求文档的模糊地带。

---

七、自检：你的评审会合格吗

|-----------------------------|---------------|
| 自检问题 | 不合格信号 |
| ****① 这次否决了几条？****​ | 一条没否 → 走过场 |
| ****② 否决理由写进文档了吗？****​ | 只在会上说了，没留痕 |
| ****③ 非目标那一段有几条？****​ | 空白或只有一句「暂无」 |
| ****④ 有技术可行但情感不该做的议题吗？****​ | 从未讨论过这条线 |
| ****⑤ 验收标准有场景、数字、口径吗？****​ | 只有「快、准、稳」 |

判读 ：五项全过 → 你的评审会在替未来省钱；三项以下 → 你在开审批会，不是评审会。

---

八、金句收尾

需求评审会的本质是花钱买「不做」的资格------每次否决，都是对未来工期的存款。

下面按 第2篇 · 第9章 · 9.3节 ​ 归位。这是需求篇的规格化收口页------把评审通过的结论，变成一份两年后失忆的自己也能看懂的规格书。

处理说明：①原文给出「立项一页纸」两个版本（九格完整版 vs 五栏精简版），我整合为同一张纸的两种用法 ，并保留 90 秒复述测试这个高质量工具；②P16 归位时留下的「PRD 十章写作指引」 ​ 与本节原文的「思库熊六章骨架」是同一份文档的两种颗粒度，已整合------六章是贯穿项目实战收敛版，十章是跨域 AI 产品完整版；③「需求基线 WBS」「冻结窗口」原属交付/项目治理，但规格冻结是需求收口的动作，保留在本节并标注与 P28（变更走门）的衔接。

---

9.3　需求规格说明书：写给两年后接手的人（P20）

【开头钩子】

文档不是写给开发看的，是写给未来失忆的自己看的。

与 P19 的衔接 ：需求评审会的产出是「通过／否决」的结论（五件套之三、四、五）；把这些结论展开成研发能开工的规格，就是本节的工作------PRD（需求规格说明书）。

评审会决定做什么，PRD 决定怎么做完。

---

一、从立项一页纸到 PRD

立项一页纸（P16 立项会的出口物）是结论 ，PRD 是展开。在展开之前，先把一页纸本身写硬。

1. 一页纸的两副骨架

|----------------|------------------------|------------|
| 骨架 | 用途 | 特点 |
| 五栏极简版​ | 贴墙、对齐、90秒复述测试​ | 只装最核心的判断 |
| 九格完整版​ | 立项评审正式文档 | 装上全部数字与承诺 |

五栏极简版：

|-----------|-------------------------|
| 栏 | 内容 |
| ① 一句话定位 | 给谁、在什么时刻、替代什么 |
| ② 真需求三行 | 各带证据编号​ |
| ③ 赢的依据 | 为什么是我们、为什么是现在 |
| ④ 赚的路径 | 定价、订阅、成本框架三行数字​ |
| ⑤ 不做清单 | 至少三条非目标​ |

五栏之外的一切------竞品分析、技术方案、组织分工------都放附件。一页纸本身打印出来贴墙。

九格完整版（在五栏基础上补全）：

|-----------|------------------|
| # | 格子 |
| 1 | 一句话定位 |
| 2 | 目标用户（含分层） |
| 3 | 核心场景 Top3 |
| 4 | 证据等级与来源​ |
| 5 | 边界与非目标 Top3 |
| 6 | 合规要点 |
| 7 | 商业模型（定价／BOM／订阅） |
| 8 | 验证 KPI |
| 9 | 资源与周期 |

一页纸写不下的内容，不属于立项范围------这个残酷的字数限制，是立项评审效率的全部秘密。

2. 记忆熊一页纸示例（九格完整版）

|-------------------|-----------------------------------------------------------|
| 格 | 内容 |
| 一句话定位​ | ****「可对话的纪念档案，不是复活」****​ |
| 非目标 Top3​ | 不做医疗替代、不做实时通话、不做未成年人主申请人 |
| 验证 KPI​ | 清明档 100台 、退货率 <10% 、素材完整率 ****>80%****​ |

九个格子全部可验收 ------立项评审会上没有形容词的位置，只有数字与承诺。

3. 90秒复述测试：全项目成本最低、命中率最高的质量工具

测试方法：

拿给一个完全不知情 的同事读 90秒，然后请他复述三件事------

① 这产品给谁用？② 凭什么赢？③ 不做什么？

|------------|---------------|
| 结果 | 判定 |
| 三问全中 | 立项通过 |
| 有一问答不上 | 回炉重写​ |

贯穿项目数据 ：六款产品的立项一页纸平均返工 1.3 次。

最贵的一次返工------亲情版：

初版把「AI聊天」写进定位，复述者把产品说成了****「智能音箱」**** ，当场暴露定位失焦；重写为------「团圆的存档键」。

90秒的复述测试，换来的是定位不跑偏的整个项目周期。

---

二、每条需求的五要素

PRD 的需求清单，每条需求必须五要素齐全------缺一个，这条需求就无法被独立执行和验收。

|-----------------|--------------------|------------------------|
| 要素 | 内容 | 作用 |
| ① 编号​ | 唯一标识（如 R-014） | 可追溯、可引用 |
| ② 原话回链​ | 回链到证据链编号（如 E-014） | 能追到用户嘴里那句话​ |
| ③ 验收标准​ | 可机检的数字 + 测量方法 | 能写测试用例 |
| ④ 优先级​ | P0／P1／P2（由 EV 排序定） | 决定先做什么 |
| ⑤ 责任人​ | 谁对这条需求的结果负责 | ****消灭「人人有责＝人人无责」****​ |

思库熊需求清单示例：

|------------|-------------|
| 需求 | 优先级 |
| 遇困即查 | P0 |
| 练一次清单 | P0 |
| SRS 复习 | P0 |
| 熟练度热力图 | P1 |
| 家长周报 | P1 |

没有责任人的需求，等于没有需求------它只是在文档里占了个位置。

---

三、PRD 骨架：六款产品共用的六章（思库熊实例）

六款产品的需求文档最终收敛到同一副六章骨架：

|-------------------|-----------------------------------|----------------------------|
| 章节 | 思库熊实例内容 | 写作要点 |
| ① 背景与机会​ | 学习工具红海，但「方法论内化」空白；108模型书稿已验证 | 机会必须绑定自有资产​ |
| ② 用户与场景​ | 初高中／大学生三层；遇困5秒内获得模型卡片 | 场景写到触发动作级​ |
| ③ 需求清单​ | 遇困即查／练一次清单／SRS复习／熟练度热力图／家长周报 | 每条带优先级 P0-P2（含五要素） |
| ④ 边界与非目标​ | 不做搜题、不做内容播放器、不做社交 | 非目标与目标同样重要​ |
| ⑤ 合规与风险​ | 家长隐私（只看熟练度）、未成年人语音数据最小化 | 合规写在功能旁边，不单独放附录 |
| ⑥ 验证 KPI​ | 200内测：周练一完成率≥40%、周报打开率≥60%、NPS≥40 | KPI 可测且有阈值​ |

六份 PRD 并排检视的规律

|----------------------------|-------------------------|
| 产品基因 | PRD 重心 |
| 越是没有先例的产品（记忆熊、情绪球） | 合规与风险章节写得越早、越重​ |
| 越是竞争激烈的产品（思库熊、拓境） | 边界与非目标写得越狠​ |

需求文档的结构相同，重心因产品基因而异------这正是「模板可复用、判断不可复用」的鲜活注脚。

【完整版】跨域 AI 产品的十章骨架

📌 六章是贯穿项目的实战收敛版 ；若你的项目跨域程度更高（含模型效果、护栏、埋点、排期），建议展开为十章完整版。

|-----------|---------------------------------------------------------------|
| 章 | 内容 |
| 一 背景与目标 | 为什么现在做；SMART目标 ＋ Out of Scope |
| 二 用户画像与场景 | 5W2H画像、角色---场景---任务三维表、主场景／边缘场景／反场景​ |
| 三 需求清单与证据 | 每条编号、描述、证据等级、优先级（EV分）------即五要素 |
| 四 功能需求 | 按用户故事写（作为谁／在什么场景／我要做什么／以便达成什么）；AI功能要写明意图---槽位---反馈链路​ |
| 五 非功能需求 | 性能、成本、可靠性、安全合规；AI产品必须额外写明模型效果指标（准确率、接管率）与护栏规则​ |
| 六 边界与异常流 | 不做什么、降级策略、模型答错时怎么办​ |
| 七 验收标准 | 能设计、能测试、能对接------三项检验 |
| 八 数据与埋点 | 采集什么、不采集什么、看板长什么样 |
| 九 合规与伦理 | 授权弹窗、儿童隐私、禁用词、数据销毁规则 |
| 十 里程碑与排期 | 阶段闸门、WBS与关键路径 |

---

四、验收标准写作法：从形容词到数字

需求规格的质量分水岭在验收标准：形容词写不出测试用例，数字才能。

三条写作法

|----------------|--------------------------------------|
| 条 | 内容 |
| ① 可机检​ | 每条 P0 至少一个可机检指标（准确率／延迟／成功率） |
| ② 有方法​ | 每个指标有测量方法------谁测、用什么测、测多少样本 |
| ③ 用户线​ | 指标值来自****「用户可感知线」****，而非「技术舒适线」 |

例 ：断句误差 ≤200ms，来自用户对「抢话」的感知阈值------不是工程师顺手写的整数。

正反对照表

|---------------------|---------------------------------------------------------|
| ❌ 反面写法（形容词） | ✅ 正面写法（数字＋方法） |
| 配网要简单易用 | 四步配网 ，老人独立成功率 ≥60%，远程协助后 100%（20台冷启动实测） |
| 语音识别要准确 | 粤／川／普三方言识别 ≥90%（各50句标准语料＋20句环境噪声语料） |
| 回复要快 | 唤醒到播报 P95 ≤2.5s （100次实测计时） |
| 界面要友好 | 卡片打开完成率 ≥85%，打卡按钮热区 ≥44pt（单手操作） |

最后一课：验收标准先于实现存在

贯穿项目要求验收标准在进入开发前冻结 ；开发完成后的验收只是「核对」，而非「协商」。

这条看似苛刻的规矩，实际保护的是开发者的判断自由：

标准定了，怎么实现随便你；标准不定，实现过程中每一句「差不多就行了」都在蚕食产品。

---

五、需求基线与 WBS：从立项到排期

1. 基线三件套

立项通过后，需求基线（Scope Baseline）随之冻结：

|------------|------------|
| 件套 | 内容 |
| ① P0 清单 | 做什么 |
| ② 验收标准 | 做到什么算完 |
| ③ 非目标清单 | 明确不做什么 |

此后任何增改，走 CCB（变更控制委员会）------详见 P28「变更走门」。

2. WBS：分解到「一个人一周内可交付」

基线的工程化落地是 WBS（工作分解结构）：

• 把每条 P0 需求分解到****「一个人一周内可交付」****的任务颗粒；
• 任务之间标注依赖关系 ，形成关键路径。

贯穿项目数据：

|--------------|---------------|
| 指标 | 数值 |
| 第一年 WBS 任务节点 | 312个​ |
| 关键路径上的任务 | 47个​ |

管理颗粒度只花在关键路径上------其余任务周会扫一眼即可。

3. 基线管理的常见病灶：基线冻了、需求照漏

漏进来的通道通常有三条，每条配一个入口动作：

|----------------------|---------------------|
| 漏需通道 | 封堵入口动作 |
| 老板随口一句​ | 进决策日志（ADR）​ |
| 大客户一条消息​ | 进需求池评审​ |
| 团队自己的「顺手做了」​ | 事后必须补基线变更单​ |

封堵的解法不是不接需求，是给每条通道配一个入口动作。

需求基线的本质不是拒绝变化，是让每一次变化都留下成本痕迹。

---

六、冻结窗口：何时停止变更

需求文档最危险的时刻不是写不出来，而是****「永远可以再改」****。

制度

|---------------|-------------------------------------------------------|
| 项 | 规则 |
| 冻结期​ | 每个阶段的规格文档在评审通过后冻结30天​ |
| 变更评审​ | 期间任何变更，由提出者写清****「变更理由、影响面、回滚成本」**** ，三方会签才生效 |

贯穿项目数据 ：12个月里发起 21次变更评审------

|-------------------|--------------|
| 结果 | 次数 |
| 通过 | 9次​ |
| 被自己的制度挡回​ | 12次​ |

挡回案例（思库熊 EVT 期）

变更提案：「把108模型的语音话术全部重写成对话式」。

|-------------|-----------------------------|
| 评估 | 结论 |
| 理由 | 正当，体验更好 |
| 影响面 | 全部内容资产 ＋ 已完成的SRS联调​ |
| 回滚成本 | 极高 |
| 决议​ | ****「列二期，一期冻结」****​ |

三个月后 ：对话式话术在二期如期上线 ，而一期按时交付。

冻结不是拒绝变化，是给变化排队。

冻结窗口三要素（不可省）

|-------------------|-----------------------|
| 要素 | 内容 |
| ① 冻结要有公告​ | 全员知晓 |
| ② 变更要有成本​ | 写清影响面 |
| ③ 例外要有通道​ | 紧急变更走口头＋事后补卡​ |

没有冻结窗口的项目不是敏捷，是漂流------每一个「顺手改一下」都在透支交付日历。

---

七、AI 辅助起草：三招与一条纪律

AI 可以把 PRD 起草效率提升数倍，但前提是你会用它补结构，而不是替你做判断。

三招

|--------------------|---------------------------------------------------|
| 招 | 做法 |
| ① 5W2H 补全​ | 把访谈材料喂给 AI，补全画像里缺失的维度（尤其是 When／Where／How much 三格） |
| ② 金字塔结构组织​ | 用 AI 把零散要点组织成「结论先行、以上统下」的章节结构 |
| ③ 模板套用​ | 把立项材料喂给模型，按六章（或十章）结构生成初稿​ |

提示词公式（可直接复制）

把以下需求要点改写为 PRD 的「功能需求 ＋ 验收标准」两栏格式；每条验收标准必须可测试：{要点列表}

一条纪律

用 AI 起草、人工校验------每个数字必须对过源文件。

原话与证据的处理纪律（回扣 P18）：

原话不可改写，只能标注------LLM 的每一次「润色」都是对证据的污染。

写作三条实操建议：

|--------------------------|--------------------------------------------------------|
| 建议 | 内容 |
| ① 规格书要薄不要厚​ | 当需求文档比源代码还厚，项目往往病入膏肓------厚文档的本质是没想清楚，只能用篇幅掩盖​ |
| ② AI 功能必须承认技术上限​ | 明确哪些是确定性功能、哪些是概率性输出；概率性输出必须配兜底体验​ |
| ③ 用 AI 起草、人工校验​ | 效率可提升数倍，但每个数字必须人工对过源文件 |

---

八、规格书自检：换个人能写出一样的测试用例吗

这是本节唯一的自检动作，也是最硬的一道：

把 PRD 交给一个没参会的工程师，请他独立写测试用例。

他能写出和你一样的测试用例吗？

|------------|------------|
| 结果 | 含义 |
| 能写出一样的 | 规格够硬，可以进开发 |
| 写不出／写出来不一样 | 还有暗坑，回炉补 |

配套双保险：

|--------------|--------------------------------|------------|
| 层 | 测试 | 工具 |
| 立项层​ | 90秒复述测试（给谁用／凭什么赢／不做什么） | 一页纸五栏 |
| 规格层​ | 测试用例复现测试（换个人写得出一样的吗） | PRD 验收标准 |

自检清单

|-----------|-------------------|---------------|
| # | 自检问题 | 不过的信号 |
| ① | 每条需求五要素齐了吗？ | 缺原话回链或缺责任人 |
| ② | 验收标准有数字＋方法吗？ | 只有「快、准、稳」 |
| ③ | 非目标那一段几条？ | 空白或「暂无」 |
| ④ | 合规写在功能旁边了吗？ | 塞在附录里无人看 |
| ⑤ | 基线三件套冻结了吗？ | 还在随时加需求 |
| ⑥ | AI 起草的数字你核对过源文件吗？ | 直接复制了 AI 给的估算 |

判读 ：六项全过 → 规格书合格，可进设计阶段；三项以下 → 你写的是愿望清单，不是规格书。

需求阶段的债，利息全部记在设计阶段。

---

九、金句收尾

需求文档不是写给开发看的，是写给两年后接手的人看的------包括未来那个已经忘记当初为什么这么决定的你自己。

下面按 第2篇 · 第10章 · 10.1节​ 归位。

先说明三处处理：①需求篇到此分岔 ------P13---P20 以六款硬件产品为「C端载体」建立需求方法论，从 P21 起进入「B端企业需求」方法论（二者共用同一套证据链与EV内核，但挖掘对象不同）；②原文的「前言/导读」（增长的诅咒、5秒前请先回答、WorkBuddy→OrgBuddy推广语气）是白皮书营销话术，删除后保留 OrgBuddy 作为扫描框架；③25部门×356职能全量表过于庞大、直接铺进正文会淹没方法论，已提炼为骨架表＋规律洞察，完整清单归位附录工具库。

---

第10章　B端需求：把企业业务流程一次梳理清楚

章眼：企业客户说不出需求，但说得出流程------痛点在流程里，不在清单里。

10.1 B端需求：把企业业务流程一次梳理清楚（P21）

【开头钩子】

企业客户说不出需求很正常------他们的痛点藏在自己的流程里。

C端需求靠访谈，B端需求靠扫流程。企业客户往往只能说「我要一个AI客服」，却说不清真正的问题------

真正的问题藏在流程里：他的客服流程中，简单问题占用了80%的人工工时。

FDE 的价值，不是等客户提需求，而是从他的业务流程里，把需求挖出来。

---

一、为什么B端需求必须「扫流程」

|---------------|--------------|------------------------|
| 维度 | C端需求 | B端需求 ​ |
| 需求来源​ | 用户原话、现场观察 | 业务流程节点​ |
| 表达方式​ | 用户自己说得出 | 客户说不出，只说得出流程​ |
| 付费逻辑​ | 个人为体验买单 | 部门为KPI买单​ |
| 交付对象​ | 一个用户群 | ****一个岗位（或一条业务线）****​ |

B端需求不在会议室里，在流程图里。

客户口中的「需求」往往是解决方案假设（「我要AI客服」），真需求要回到流程里去找------哪一步慢、哪一步贵、哪一步错、哪一步没人管。

---

二、扫描地图：25部门 × 356职能（OrgBuddy框架）

1. 从 WorkBuddy 到 OrgBuddy

|--------------------|------------------------------------|
| 工具 | 解决什么 |
| WorkBuddy​ | 个人战场------一个人的产能杠杆 |
| OrgBuddy​ | 组织战场------25个部门、356个职能统一调度 |

2. 与本书框架的映射

|------------------|------------------------------|
| 本书概念 | OrgBuddy 映射 |
| 海星组织​ | 25部门 Agent Mesh ＋ PMO 舵盘 |
| π型特种兵​ | 人 ＋ OrgBuddy ＋ Sub-Agent |
| 90天效能革命​ | 0-3月 MVP → 3-6月全覆盖 → 6-12月生态 |

OrgBuddy 不是一个软件，是一套把企业业务流翻译成AI可执行任务的扫描坐标系。

3. 部门扫描骨架表（12个核心部门示例）

扫描表的结构：部门 → 主智能体 → 职能清单 → AI形态 → 优先级与阶段。

|----------------|-------------|--------------|------------------------|--------------|-------------------|
| 部门 | 职能数 | 主智能体 | 核心职能举例 | AI形态 | 优先级·阶段 |
| 战略管理部​ | 12 | 战略舵手 | 市场调研与行业分析、经营数据监控、竞品对标 | 智能体·ReAct | P0·一期MVP​ |
| 人力资源部​ | 25 | 人力舵手 | 招聘需求收集与分析、简历筛选、雇主品牌 | 智能体·ReAct | P0·一期MVP​ |
| 研发部​ | 30 | 研发舵手 | 前端/后端/移动端开发、API接口、性能优化 | 混合·工作流 | P1·二期 |
| 产品部​ | 17 | 产品舵手 | PRD撰写、用户研究、竞品分析、需求评审 | 智能体·ReAct | P2·三期 |
| 销售部​ | --- | 销售舵手 | 大客户开发、需求调研、商务谈判、渠道赋能 | 混合·工作流 | P1·二期 |
| 财务部​ | --- | 财务舵手 | 账务处理、报表编制、资金计划、税务申报 | 混合·工作流 | P1·二期 |
| 运营部​ | 21 | 运营舵手 | 用户增长与留存、分层运营、活动策划 | 智能体·ReAct | P2·三期 |
| 市场部​ | 15 | 市场舵手 | 品牌策略、内容生产、自媒体矩阵、投放优化 | 智能体·ReAct | P2·三期 |
| 数据部​ | 13 | 数据舵手 | 数仓建设、数据治理、BI报表、数据安全 | 混合·工作流 | P2·三期 |
| 供应链部​ | --- | 供应链舵手 | 供应商评估、采购执行、来料检验、仓储 | 智能体/混合 | P2·三期 |
| 法务部​ | 14 | 法务舵手 | 合同起草审核、合规体系、数据隐私、反垄断 | 智能体·ReAct | P2·三期 |
| 信息安全部​ | 10 | 安全舵手 | 安全监控、漏洞管理、等保测评、数据脱敏 | 智能体·事件驱动 | P2·三期 |

其余13个部门 （生产制造、质量、实施交付、设计、品牌公关、风控、行政等）结构完全相同，完整356职能清单归位附录工具库。

4. 三条扫描规律（从职能表里读出来的）

|---------------------------------|---------------------------------------------|
| 规律 | 内容 |
| ****① 分析创作类 → 智能体（ReAct对话）****​ | 调研、分析、写作、创作、评审------目标开放，适合智能体自主推理 |
| ****② 流程执行类 → 混合（工作流）****​ | 开发、合同、订单、报销、招聘流程------有固定步骤，人机协同执行 |
| ③ 强流程/强监管/低频 → 传统​ | 银行流水、入库管理、访客登记、合同归档------规则刚性、责任重大，AI只做辅助记录 |

AI形态选错了，再好的需求也落不了地------分析岗上工作流、执行岗上纯智能体，都是错配。

MVP 切入点 ：P0 集中在战略管理部 （调研/经营分析/竞品）与人力资源部（招聘需求）------高频、数据驱动、痛点明确，是B端AI落地的最佳首战。

---

三、四步梳理：画流程 → 标痛点 → 定数据 → 找指标

拿到部门职能后，对每个核心职能走四步。每步产出一张表。

|----------------|------------------------------|-------------------------------------|-----------------------|
| 步 | 动作 | 产出物 ​ | 关键 |
| ① 画流程​ | 把部门业务流画出来（AS-IS现状 → TO-BE未来） | 《业务流程图》（泳道图，按岗位分泳道） | 必须画到岗位级，不是部门级 |
| ② 标痛点​ | 在流程节点上标痛点（用五问诊断） | 《流程痛点表》（节点／岗位／痛点／五问命中） | 每条痛点带节点编号​ |
| ③ 定数据​ | 每个痛点需要什么数据支撑 | 《数据依赖表》（痛点／所需数据／数据源系统／数据现状） | 分清「有数据／无数据／数据脏」 |
| ④ 找指标​ | 痛点的量化指标（基线值 → 目标值） | 《指标基线表》（节点／当前值／目标值／测量方式） | 基线值必须实测，不能估​ |

四步走完，一个职能就从「一段文字描述」变成了「一组可执行、可验收的AI任务」。

---

四、五问诊断：在流程节点上找真痛点

画完流程图后，对每个节点连问五问。命中两问以上，即为高价值改造点。

|---------------------|------------|--------------|---------------------------------|
| 问 | 维度 | 含义 | B端示例 ​ |
| ****① 哪一步最慢？****​ | 时间 | 耗时最长的节点 | 合同审批平均 5天，卡在法务会签 |
| ② 哪一步最贵？​ | 成本 | 人力/资源消耗最大的节点 | 客服人力成本占营收12%，其中60%是重复问题 |
| ③ 哪一步最容易错？​ | 质量 | 出错率最高的节点 | 订单录入错误率3%，导致每月返工200单 |
| ④ 哪一步没人管？​ | 责任 | 责任空白或扯皮的节点 | 跨部门交接无人负责，需求丢失没人认 |
| ⑤ 哪一步数据缺失？​ | 数据 | 该记录却没记录的节点 | 客户流失原因无记录，无法归因改进 |

五问的优先级含义：

• 命中 ①② → 效率型需求（降本增效，最容易算ROI）
• 命中 ③ → 质量型需求（纠错止损）
• 命中 ④ → 治理型需求（明确责任，往往是组织问题而非AI问题）
• 命中 ⑤ → 数据型需求（先补数据，再谈AI）

注意：第④问（没人管）往往不是AI能解决的，先补RACI；第⑤问（数据缺失）要先补埋点，不要急着上模型。

没数据就上AI，等于让模型在黑暗里开车。

---

五、产出：业务需求清单 ＋ 优先级，回链到部门与岗位

四步梳理的成果，收敛为一张业务需求清单：

|----------------|--------------------------|
| 列 | 内容 |
| 需求编号​ | 唯一标识（如 B-R-014） |
| 部门-岗位​ | 回链到具体部门与岗位（B端核心） |
| 流程节点​ | 来自哪张流程图、哪个节点 |
| 痛点描述​ | 五问命中情况 |
| 数据依赖​ | 所需数据与现状（有／无／脏） |
| 验收指标​ | 基线值 → 目标值，可机检 |
| 优先级​ | EV排序（价值×概率÷成本） |
| 责任人​ | 该岗位的负责人（买单的人） |

B端需求的核心纪律：回链到岗位KPI

需求编号的终点，是某个岗位的KPI。

没有岗位承接、不挂在KPI上的B端需求，只是一句「正确的废话」------没人会为它买单，也没人会为它负责。

示例：

|------------|---------------|--------------|----------------|-----------------------|-------------|-------------|
| 编号 | 部门-岗位 | 流程节点 | 痛点（五问） | 验收指标 | 优先级 | 责任人 |
| B-R-014 | 销售部-大客户销售 | 需求调研与方案呈现 | 最慢：方案撰写平均3天 | 方案初稿产出 ≤4小时​ | P0​ | 销售总监 |
| B-R-021 | 客服部-一线客服 | 工单分派与应答 | 最贵：60%工单是重复问题 | 人工占比 ****45%→22%****​ | P0​ | 客服经理 |
| B-R-035 | 财务部-应收会计 | 对账与催收 | 最容易错：对账错误率2% | 差错率 ****≤0.5%****​ | P1 | 财务经理 |

B端需求的验收指标，必须是该岗位本来就关心的那个数字------销售关心成单周期，客服关心人力占比，财务关心差错率。

用他的KPI说话，需求才有预算。

---

六、自检：你的B端需求梳理合格吗

|------------------------|-----------------|
| 自检问题 | 不合格信号 |
| ****① 你画流程图了吗？****​ | 只有文字描述，没有泳道图 |
| ****② 痛点标到节点了吗？****​ | 痛点在部门层面，不在流程节点上 |
| ****③ 五问命中几条？****​ | 一条都没命中 → 不是真痛点 |
| ****④ 数据依赖查清了吗？****​ | 说不清数据在哪、是否干净 |
| ****⑤ 指标有基线值吗？****​ | 只有目标值，没有实测基线 |
| ****⑥ 回链到岗位KPI了吗？****​ | 需求无人认领，或认领人不买单 |

判读 ：六项全过 → 可进 EV 排序与立项；三项以下 → 你还在听客户「讲故事」，没有进流程。

---

七、金句收尾

企业客户说不出需求很正常------FDE的价值，就是从他的流程里，把需求挖出来。

下面按 第2篇 · 第11章 · 11.1节​ 归位。

先说明本页的范围处理 ：你的标题是「C端需求实战（上）：思库熊与拓境是怎么立项的」，但粘贴内容里还包含了陪伴熊基础版、亲情版、记忆熊、情绪球 以及六案复盘总检表 。为保持「上／下」两页的节奏与体量均衡，我把 P22 聚焦为思库熊与拓境两款（上半场） ，陪伴熊系列、记忆熊、情绪球及六案总检表归位 P23（下半场）------它们会在 P23 完整展开，不会丢。

另外，P21 是 B端需求（第10章），从本页起进入第11章：C端需求实战（六款产品需求深潜）。

---

第11章　C端需求实战：六款产品是怎么立项的

章眼：同一套方法论，六份完全不同的需求定义。

11.1 C端需求实战（上）：思库熊与拓境是怎么立项的（P22）

【开头钩子】

学生不是不爱学习，是不爱被「学习设备」定义。

思库熊卖的不是学习机，是一个伙伴------这个定位不是拍脑袋来的，是从一句书稿金句里长出来的。

---

一、案例地图：一个平台，六场需求实战

先交代贯穿全案的一个战略前提------团队从第一天就没有把宝押在硬件上。

ESP32-S3 开发板谁都能买，模型 API 谁都能调。

真正的壁垒被定义为三层：

|----------------------------|----------------------------|
| 壁垒层 | 内容 |
| ① 垂直场景 Prompt 知识库​ | 108学习模型／130计职场／500段戏曲／记忆人格 |
| ② 小红书内容资产​ | 内容日历、人设号矩阵、持续获客 |
| ③ 订阅内容​ | 戏曲包／模型精讲／记忆场景，持续变现 |

这个判断直接塑造了所有产品的需求取向：

功能需求可以克制，内容需求必须丰厚；硬件可以公模，Prompt 库必须独家。

启动条件：

|-----------|------------------------|
| 项 | 数字 |
| 启动资金 | 约 ¥3575​ |
| 首月目标 | 焊出第一台打通全链路的原型 ＋ 发出预售笔记 |

轻到一个人可以启动，重到方法论必须完整------这就是贯穿案例的起点。

---

二、思库熊：书稿痛点金句就是 A 级需求证据

思库熊面对的是一个看似红海的市场：学生学习工具。

需求挖掘没有从问卷开始，而是从一部书稿开始。

《AI时代高效学习体系：108套完整模型》在成书过程中沉淀了 108个学习痛点，每个模型都绑定一句刀刀见血的痛点金句：

|-------------------|
| 书稿痛点金句 |
| 学霸笔记越记越薄、你的笔记越记越厚 |
| 你听懂了却讲不出 |
| 你背了忘、忘了背却从不进步 |
| 错题本越抄越厚、分数却纹丝不动 |
| 你刷一万题仍在中游徘徊 |

这些不是团队的 C 级推测 ------它们被出版物验证、被无数学生对号入座。在 REQ-02 证据分级里，这是接近 A 级的需求富矿。

1. 证据转译：金句 → 触发词 → 产品内核

FDE 做了一次漂亮的证据转译：

痛点金句直接成为 trigger_keywords与 tagline****，模型库成为产品内核。****

|-----------------|-----------------------------|
| 级 | 内容 |
| ① 用户原话​ | 「学霸笔记越记越薄、你的笔记越记越厚」 |
| ② 需求条目​ | 学生不会把零散知识结构化，笔记越记越厚却用不上 |
| ③ 产品语言​ | 知识树建模模型（001号），五段式输出 |

2. 用户分层：5W2H 快速清晰化

|--------------|--------------------------|-----------------|----------------|
| 用户分层 | 激活模型子集 | 核心场景 | 家长周报侧重 |
| 初中生​ | 基础 24个（第一模块为主） | 笔记整理、背诵遗忘 | 熟练度进度条 |
| 高中生​ | 全模块 108个​ | 刷题失分、时间管理、考试压力 | 模块覆盖热力图 |
| 大学生​ | 第五模块加权（AI时代学习模型） | 论文检索、AI工具链、自学规划 | 周练一模型数 |

三层用户共用一只熊，但激活的模型子集、Prompt 母版与家长周报呈现方式完全不同------这是「同一硬件、分层需求」的第一个样本。

3. 需求旅程：遇困 → 查模型 → 练一次 → 沉淀 → 复盘

核心场景是遇困时刻------自习时笔记越记越厚的焦虑瞬间、考试失利后的归因时刻。

需求收敛为一条核心链路：

① 摸头唤醒「库库」

↓

② 语音描述痛点

↓

③ ModelRouter 命中模型（001知识树建模）

↓

④ RAG 召回 learn_001 书稿切片

↓

⑤ LLM 按五段式输出 ≤300字卡片

（真实场景/底层模型/操作步骤/破解公式/练一次清单）

↓

⑥ 小程序推送 5-15分钟微任务

↓

⑦ 完成后熟练度 +1

↓

⑧ 003 间隔检索抗遗忘模型 → SRS 算法自动排复习队列

这条链路里的每一环，都是需求阶段就定下的规格，而不是技术阶段的临时发挥。

4. 需求边界：不做什么是关键

|------------------------------|------------------|
| 不做 | 原因 |
| 不做搜题工具​ | 红海中的红海，且与学习方法论冲突 |
| 不做无练习闭环的内容播放器​ | 内容必须变成动作 |
| 家长周报只看熟练度热力图、不看聊天内容​ | 隐私即定位 |

5. 二阶后果审查催生的关键设计

家长端只看进度，不看聊天内容。

这一条是二阶思维的直接产物------如果家长能看到孩子的全部对话，产品就变成了监控工具，会直接破坏学生的自主感，进而毁掉整个产品的使用意愿。

思库熊卖的是伙伴，不是教具；伙伴的前提是不被监视。

6. 三个「痛点复现」实验（替代传统问卷）

访谈验证阶段，团队设计了三个实验：

|---------------|-----------------------------|-----------------------|
| 实验 | 方法 | 结论 |
| ① 学生​ | 复述上周被卡住的一次学习经历，看是否命中108模型金句 | 命中率约七成​ |
| ② 家长​ | 描述「最想看到孩子什么改变」 | 家长更关心趋势而非单次得分 |
| ③ 老师​ | 评价「练一次清单」的可布置性 | 老师愿意把清单当课后任务​ |

三个结论直接写进需求规格：支撑了「家长端只看熟练度、不看聊天」的隐私边界，也支撑了清单化练习的产品形态。

7. 商业需求

|-----------|------------------------------|
| 项 | 数字 |
| BOM | 约 ¥128​ |
| 定价 | ¥599​ |
| 订阅 | ¥39/月（解锁全量精讲与间隔复习算法） |
| 免费层 | 开箱可用；基础订阅解锁第13号模型起的深度内容 |

思库熊的案例证明：当你拥有被验证过的内容资产，需求挖掘的成本可以极低------关键是把内容结构化为可调用的系统。

---

三、拓境：130计从书稿到工位

拓境的需求证据是 130计。职场人的痛点与学生不同：

他们不会在书桌前求助，而是困在会议里、微信中、汇报后 ------被背锅、被抢功、被 PUA、被挖坑的时刻，往往当时反应不过来，事后才想明白。

1. 反常识起点：取证型需求

拓境需求规格的焦点不是「教130计」，而是「在事件发生后5秒内给出对应模型卡片」。

这是典型的取证型需求 ：证据（录音转写）在事件里，帮助（破解公式＋待办）必须贴着事件给。

产品形态由此决定 ：不是桌面摆件，而是 6×6厘米磁吸方块「小逻」，贴在显示器侧边或笔记本A面。

2. 场景旅程：会前 → 会中 → 会后

|-------------|-------------------------------------------|
| 阶段 | 动作 |
| 会中​ | 磁吸方块常亮待机，双MEMS麦检测到连续语音自动分段，长按结束会议 |
| 会后​ | 5秒内小程序推送「命中模型：037边界话术模型」＋破解公式＋待办 |

3. 130计六大类：痛点分类本身就是需求架构

|--------------------|-----------|---------------------------------------------------------|
| 类别 | 计 | 功能映射 |
| 背锅甩锅类​ | 1-18 | 自动附加留痕清单 模板（邮件／IM截图位）------防背锅的本质是证据管理​ |
| 窃取成果抢功劳类​ | 19-36 | 贡献记录 |
| PUA与精神打压类​ | 37-54 | 触发压力记录写入个人档案------应对精神打压需要时间线证据 |
| 挖坑设套类​ | 55-72 | 场景识别与预警 |
| 造谣构陷类​ | 73-90 | 溯源与应对 |
| 高阶博弈类​ | 91-130 | 策略推演 |

周复盘 ：聚合本周 Top5 命中模型，引导「练一次」闭环------130计不是查完就走的字典，是有熟练度进阶的模型库。

4. 场景需求与风险对照

|------------|--------------|----------------|--------------|
| 场景 | 需求要点 | 对应能力 | 需求风险 |
| 被口头派活 | 任务无文字留痕 | 001证据真空模型＋留痕清单 | 录音合规 |
| 成果被吞 | 贡献无法自证 | 019层级掠夺模型＋贡献记录 | 取证边界 |
| 被无限放大失误 | 情绪压力无出口 | 037偏差放大模型＋压力记录 | 档案隐私 |
| 跨部门背锅 | 权责边界模糊 | 003权责模糊洼地模型 | 对立激化 |
| 会议信息过载 | 要点抓不住 | 说话人分段＋卡片推送 | 转写准确率 |

5. 二阶后果：三条红线写死

一个教人识别职场陷阱的设备，若被滥用为窃听工具或引发同事对立，就是灾难。

需求规格因此写死三条红线：

|------------|------------------------------------------------------------------|
| # | 红线 |
| ①​ | 只在用户本人参与的会议中录音，且开头有提示音 |
| ②​ | 卡片与待办仅本人可见 ；B端团队版只共享匿名化的模型命中统计 ，不共享录音原文​ |
| ③​ | 产品话术定位 「防坑自卫」 ，****不做「整人攻略」****​ |

这三条红线在后续技术篇转成了具体工程约束：提示音写进固件、匿名化写进聚合服务、话术写进 Prompt 审查清单。

6. B端扩展（需求阶段即预见）

团队版共享匿名化模型命中统计 ，但绝不共享录音原文。

7. 商业需求

|-----------|-----------------|
| 项 | 数字 |
| BOM | 约 ¥130​ |
| 定价 | ¥499​ |
| 订阅 | ¥29/月​ |

8. 方法论回扣

职场人不会在问卷里承认自己被 PUA------问行为不问观点。

而书稿里 130 种博弈场景的高传播度，本身就是 B级以上证据。

35岁「要么成为成本、要么成为资本」的集体焦虑，为产品提供了最深厚的需求土壤。

---

四、两款产品的立项逻辑对照

|---------------|--------------------------|------------------------|
| 维度 | 思库熊 ​ | 拓境 ​ |
| 证据来源​ | 108模型书稿痛点金句（近A级） | 130计书稿（A级） |
| 验证方式​ | 三个痛点复现实验（命中率约七成） | 书稿传播度（B级以上）＋社区验证 |
| 核心场景​ | 遇困时刻（自习/考后归因） | 会后5秒（被坑后的取证时刻） |
| 需求形态​ | 伙伴（陪伴式学习教练） | 防坑自卫工具（取证型） |
| 二阶红线​ | 家长端不看聊天（防监控） | 三红线（防窃听／防对立／防整人） |
| 定价​ | ¥599 ＋ ¥39/月 | ¥499 ＋ ¥29/月 |
| 验证姿态​ | 首发重仓​ | 首发重仓​ |

共同的立项逻辑

先确认问题真实存在（书稿／访谈＋社区验证）→ 再验证付费意愿（预售）。

两款产品都跳过了「问用户要不要」这一步，直接从已被验证的内容资产里挖需求------这是需求挖掘成本最低、命中率最高的一条路。

共同的优先级策略

先做平台共用底座，再做单款 SKU。

两款产品共用 ESP32-S3 平台 ＋ 238套模型内核 ＋ 五段式输出模板，差异只在外壳形态、Prompt／知识库与小程序模块。

硬件是载体，内容是粘性，数据是护城河。

需求阶段的全部努力，就是在写第一行代码之前，确保这条护城河里流的是真问题、真用户、真价值。

---

五、自检：你的C端需求立得住吗

|-----------------------|-------------------|
| 自检问题 | 不合格信号 |
| ****① 你的痛点原话从哪来？****​ | 团队脑暴，非用户／非验证内容 |
| ****② 证据是A级还是C级？****​ | 只有「我觉得用户需要」 |
| ****③ 用户分层了吗？****​ | 目标用户是「所有学生／所有职场人」 |
| ****④ 二阶后果想过吗？****​ | 没想过产品会被怎么「用坏」 |
| ****⑤ 非目标写了吗？****​ | 只有功能清单，没有「不做」清单 |
| ****⑥ 平台底座复用在哪？****​ | 每款产品从零开始 |

判读 ：六项全过 → 可进预售验证；三项以下 → 你在做一个 Demo，不是一个产品。

---

六、金句收尾

学生不是不爱学习，是不爱被「学习设备」定义------思库熊卖的是伙伴，不是教具。

下面按 第2篇 · 第11章 · 11.2节 ​ 归位。这是第11章的下半场，也是需求篇六款产品实战的收官页。

先衔接 P22：上半场讲了思库熊与拓境 （靠书稿金句起家，首发重仓）；下半场这三款（陪伴熊含亲情版、记忆熊、情绪球）的共同点是------它们都必须在「做」之前先回答「绝不做」：陪伴熊不吹医疗、记忆熊禁用复活、情绪球不存原文。

---

11.2 C端需求实战（下）：陪伴熊、记忆熊与情绪球（P23）

【开头钩子】

老人不怕被机器照顾，怕的是不会用；子女不怕花钱，怕的是不知道爸妈过得好不好。

这句话同时说出了两个买家的心思------陪伴熊的全部需求结构，就藏在这半句对半句里。

---

一、需求阶段的时间与资金纪律

六款产品的需求阶段，还示范了一种稀缺的纪律：用极小的资金和极快的节奏买真实反馈。

1. 启动期第1个月：约 ¥3575 怎么花

钱完全围绕需求验证花，不买产能：

|-------------|------------|
| 花法 | 目的 |
| 立创下单开发板与麦克风 | 打通硬件链路 |
| 买毛绒公模 | 验证形态与手感 |
| 跑通离线唤醒词 | 验证最核心的交互 |
| 注册小红书账号 | 建立需求信号采集管道 |
| 开通云端语音服务试用 | 验证链路可行性 |

2. 精益三板斧：本周／本月／下月

|-------------|-----------------------------|
| 节奏 | 动作 |
| 本周​ | 焊通第一台原型的全链路 |
| 本月​ | 配网小程序 ＋ 14篇笔记 ＋ 申请软著 ＋ 开店预售 |
| 下月​ | 收50台定金 → 下50片 PCB → 寄样博主 |

注意顺序：

先有能演示的东西，再收定金，最后才批量生产。

这正是硬件立项方法论的精益三板斧：

先确认问题真实存在 → 再确认用户愿意付费（定金是比任何问卷都硬的证据） → 最后才推进可售卖版本。

需求阶段的每一笔钱都花在买证据上，而不是买产能。

3. 内容运营不是附属品，是需求验证的主渠道

小红书前8周日历：

|----------------|--------------------------|
| 周 | 动作 |
| W1-W2​ | 注册账号、建群、备素材 |
| W3-W4​ | 日更手搓过程、奶奶实测、远程留言、技术拆解、预售 |
| W5-W6​ | 寄样五个博主并测试投放 |
| W7-W8​ | 发货、售后、收集 UGC |

内容数据本身就是需求证据流：

哪条痛点视频爆了、哪个功能被反复问起、哪类人群下单------全部回流为需求优先级调整的依据。

对 FDE 而言，需求阶段的出口物不只是文档，还包括一份能持续采集真实需求信号的内容与运营管道。

---

二、陪伴熊·基础版：一笔账要两边算

陪伴熊是六款产品中双边需求结构最典型的样本：

|-----------------|-----------------------|
| 角色 | 要什么 |
| 使用者·老人​ | 有人说话、有戏听、别忘吃药 |
| 付费者·子女​ | 知道爸妈今天状态还行、有事我能第一时间知道 |

两个角色的需求清单几乎不重叠------任何一边被砍，产品就塌。这是双边需求的第一铁律。

1. 双边需求对照表

|-------------|--------------|--------------------------|--------------|
| 需求边 | 核心痛点 | 功能映射 | 证据来源 |
| 老人​ | 独居没人说话 | 摸头唤醒闲聊 ＋ 主动发起（每日17:00） | 用户访谈＋社区调研 |
| 老人​ | 娱乐匮乏 | 戏曲点播（首包20段 ＋ 订阅500＋） | 戏曲偏好问卷 |
| 老人​ | 忘吃药 | 用药定时提醒（橙灯快闪＋语音） | 子女访谈 |
| 子女​ | 不知老人状态 | 情绪周报（标签＋摘要，不含原文） | 子女访谈 |
| 子女​ | 突发联系不上 | 紫灯留言通道（录音→OSS→MQTT推送） | 场景推演 |

2. 老人侧：三个「反智能」决定

这三个决定值得所有做老年产品的团队抄写十遍：

|------------|-----------------------------------------------------------|------------------------------------------|
| # | 决定 | 原因 |
| ①​ | 唤醒不用纯语音 ------定为「摸头顶 Pad 两秒」＋WakeNet 双条件​ | 纯离线唤醒词误唤醒率高；双条件后误唤醒从每晚十几次降到几乎为零​ |
| ②​ | 回复长度限制 60 字以内​ | 长回复对老人是负担，写死在 Prompt 里​ |
| ③​ | 断网降级------Wi-Fi 断连时本地预置戏曲照常可播 | 产品不能因为云端挂了就「哑掉」 |

三个决定都在需求阶段 写进规格------避免了技术阶段的返工。

3. 子女侧：配网必须能远程帮

「老人不会配网」是概率评估里最高的风险项，需求阶段就定了两条对策：

|-------------------|------------------------------------------------------------------|
| 对策 | 内容 |
| 压缩配网流程​ | 开机配网压到四步（撕绝缘贴 → 长按电源三秒 → 手机连热点 → 输家里 Wi-Fi 密码），配一分钟短视频教程 |
| 子女远程协助配网​ | 绑定设备的动作由子女在小程序完成，老人只负责长按电源 |

成效 ：这条需求后来成为****激活率 84%****​ 的直接功臣------

那缺失的 16% ，基本都是子女没空远程协助的。（回扣 P13 速览表的「坑一」）

4. 需求阶段的克制：不做医疗承诺

|--------------|----------------------------|
| 明确不做 | 表述 |
| 医疗健康承诺 | 所有内容标注「辅助陪伴非医疗」 |
| 运营红线 | 避坑清单写明不吹替代医生／心理咨询​ |

5. 商业与验证姿态

|-----------|------------------------------------|
| 项 | 数字 |
| 定价 | ¥599 ，戏曲包 ¥19/月​ |
| 首年目标 | 50台预售验证，月销 30-50台 |
| EV 逻辑 | 不追求首发规模，追求双边需求在真实家庭里的留存验证​ |

小红书人设与内容节奏（需求证据的持续采集器）：

• 人设：给奶奶做了一只AI熊的孝心儿女 ＋ 造物老张硬件佬
• 节奏：Day1 手搓 → Day3 奶奶实测 → Day7 远程留言 → Day14 预售

---

三、陪伴熊·亲情版：声音背后的合规清单

亲情版的需求诞生于一个观察：基础版上线后，子女留言功能使用频次远超预期，留言区最高频的一句评价是------

「要是能天天听儿子声音就好了。」

异步留言升级为「声音在场」，这就是亲情版的全部需求内核：

子女录10句话 → 克隆音色 → 老人点名「想听小强说话」

→ 设备用 克隆音色 + 角色口头禅 + 角色记忆 生成回复

1. 需求清单多出的三样东西

|-------------------|---------------------|
| 新增 | 内容 |
| ① 声音档案库​ | 存储克隆 voice_id 与原始录音 |
| ② 角色数据结构​ | 角色档案与说话风格 |
| ③ 场景剧本​ | 过年聚餐、睡前问候等三轮对话模板 |

2. 真正让它与众不同的：合规清单与功能清单 并列出现

声音克隆的法律与伦理红线被逐条写进需求规格：

|------------|---------------------------------------------|--------------|
| # | 合规需求 | 工程落点 |
| ①​ | 录音时必须弹窗「我确认本人同意克隆我的声音用于陪伴家人」 | 前端弹窗 |
| ②​ | 禁止克隆未授权第三人声音，后台人工抽检 | 运营抽检 |
| ③​ | 商品页标注「声音为 AI 合成，非实时通话」 | 详情页标注 |
| ④​ | voice_id 与原始录音 AES 加密存储，不出境、不用于训练外泄 | 存储层加密 |

需求阶段写不清的合规，交付阶段一定还不起。

3. 成本分层（能力圈指导下的确定与探索分档）

|---------------------|-------------------|
| 阶段 | 方案 |
| MVP​ | 先用火山引擎 API 跑通 |
| 月活 >500 后​ | 自部署 GPT-SoVITS 降本 |

4. 商业

|-----------|---------------------------------------------|
| 项 | 数字 |
| 定价 | ¥798 （或基础版用户 ＋¥199​ OTA 升级） |
| 节奏 | 第三月通过固件 OTA​ 向基础版用户解锁订阅 |

同一个硬件平台上，需求挖掘永不停止------而每一次需求升级，合规清单必须先走一步。

---

四、记忆熊：宏大市场里的三个克制

记忆熊是一场「市场宏大与内心敬畏」的平衡术。

1. 市场推演与空白点

|-----------|-----------------------------------------------------------------------------------|
| 项 | 内容 |
| 市场盘子 | 中国年死亡约 1000万人 ，对应约 3000万直系亲属​ |
| 高频节点 | 清明、忌日、生日、中元、母亲节 |
| 竞品空白 | StoryFile 有视频但非实时 ；HereAfter 有对话但无实体 ------「毛绒＋实时对话」无人占据​ |

2. 三个需求克制（面对巨大市场反而更保守）

|-----------------|------------------------------------------------------------------------------|
| 克制 | 内容 |
| ① 定位克制​ | 不是复活、不是重生，是****「可对话的纪念档案」**** ；宣传词定为「思念有声，回忆可触 」；复活／重生列为禁用词​ |
| ② 门槛克制​ | 激活必须过合规门禁 （死亡证明＋户口本＋申请人身份证三证核验 ），宁可流失灰单​ |
| ③ 语气克制​ | 人格 Prompt 禁用「我是 AI」 ，但也禁止编造生前未有的承诺；不确定的事用生前价值观推测 |

定位克制是 REQ-03 二阶后果的直接产物------避免对用户 grief（哀伤）过程的误导性承诺。

3. 素材收集：搭系统第一步，也是最关键一步

七题记忆问卷把家属的怀念结构化为角色档案：

|-----------|--------------|
| # | 采集内容 |
| ① | 他/她最常叫您什么 |
| ② | 最常说的五句话 |
| ③ | 性格 |
| ④ | 最关心什么 |
| ⑤ | 最难忘的一句话 |
| ⑥ | 特殊习惯 |
| ⑦ | 最怕您做什么 |

语音素材要求至少1分钟清晰干声用于克隆。

4. 预期管理：把「素材质量」写成用户承诺

需求阶段就把「素材质量决定对话质量 」写成了用户预期管理------问卷填写越认真，熊的声音越像。

效果：大幅降低了「不像」类差评------

用户在填写问卷时，就已经完成了情感投入的第一步。

5. 验证姿态

|-----------|--------------------------------------------|
| 项 | 数字 |
| 首月目标 | 仅 100台​ |
| 定价 | ¥799 ，续费 ¥99/年​ |
| 排期 | Phase3（第4-5月），清明前四周启动「把思念装进口袋」内容预热 |

用高客单价小批量验证情感付费的真实性，而非用大市场自我催眠。

---

五、情绪球：把「不存原文」写成第一需求

情绪球的需求文档用了一个非常规的排序：

隐私架构写在功能清单之前。

理由 ：儿童产品的信任一旦塌掉就没有第二次机会，而信任的前提是------家长的偷听焦虑为零。

1. 四条硬约束

|------------|-----------------------------------------|
| # | 约束 |
| ①​ | 不存儿童原始语音------设备端 ASR 后立即丢弃 PCM |
| ②​ | 家长端不可听原文回放，只看情绪标签与摘要趋势 |
| ③​ | 摘要数据保留 90 天自动删除​ |
| ④​ | 外壳食品级硅胶 ＋ 3C认证 ＋ 小零件防吞咽结构​ |

约束反过来塑造技术选型：

端侧必须跑得动轻量 ASR；云端只需接收 text_summary 与 emotion_tag。

2. 儿童侧：三个高情绪时刻 ＋ 低门槛交互

|---------------|-----------------------------------|
| 高情绪时刻 | 交互 |
| 分床睡焦虑 | 挤压唤醒（FSR 压力 >2N 持续 0.5秒） |
| 被同学欺负 | 共情反射短句 ≤40字​ |
| 考试压力 | 可选呼吸引导 |

3. 最精彩的一条：「禁止说教」的 Prompt 约束

「听起来你很生气，因为小明抢了你的玩具，对吗？」

只反射感受，不给建议。

这条约束让情绪球与传统「讲道理玩具」在需求层面就分道扬镳。

4. 家长侧：「知道但不知道得太细」

树洞日报 每晚 22:00 推送，内容是情绪标签分布 ＋ 一句摘要（如「今天提到了两次『不想上学』」），Pro 版仅看趋势图。

颗粒度经过一轮真实调参：

|-------------|---------------|
| 颗粒度 | 后果 |
| 太粗 | 家长焦虑（「到底怎么了」） |
| 太细 | 孩子感觉被监视 |

最终口径（需求评审时定下）：

标签 ＋ 频次 ＋ 一句摘要 ；事件细节只有孩子主动告诉家长时，才由孩子自己讲。

产品在亲子之间做的是****「翻译情绪」，不是「传递证据」****。

---

六、六案复盘：需求方法论一张总检表

把六款产品并排放在 REQ 六模型的检视图上，方法论的一致性一目了然。

|------------------|-------------------|----------------------|--------------------|
| 产品 | 证据等级 | 关键需求决策 | 验证姿态 |
| 思库熊​ | A（书稿痛点） | 内容结构化，不做搜题​ | 首发重仓​ |
| 拓境​ | A（130计书稿） | 会后5秒卡片，不留原文​ | 首发重仓​ |
| 陪伴熊·基础版​ | B（双边访谈） | 双边功能齐备，不吹医疗​ | 50台预售验证​ |
| 陪伴熊·亲情版​ | B＋合规审查​ | 声音克隆合规前置​ | OTA 升级解锁 |
| 记忆熊​ | A市场／C付费​ | 定位纪念档案，合规门禁​ | 100台高客单验证​ |
| 情绪球​ | C（假设待验） | 隐私即卖点，无屏无原文 | POC 最小试水​ |

四个模型的体现：

|----------------------|-----------------------------------------------------------------------------|
| 模型 | 六案体现 |
| REQ-02 证据分级​ | 思库熊、拓境用书稿金句（近A级）重仓首发；陪伴熊用双边访谈（B级）支撑50台验证；记忆熊市场大但坚持100台小批量；情绪球证据偏C，降级为POC |
| REQ-03 二阶后果​ | 思库熊不做监控、拓境明示录制状态、亲情版声音授权、记忆熊禁用复活、情绪球隐私架构------每个产品都在需求阶段预演了最坏的适应行为​ |
| REQ-05 能力圈​ | 声音克隆先API后自部署；端侧模型先 Spike 再承诺 |
| REQ-06 逆向思维​ | 陪伴熊的不吹医疗、记忆熊的数据销毁、情绪球的防吞咽------全是事前验尸写出的规避项​ |

共同的商业纪律

|-----------|---------------------------|
| 项 | 数字 |
| 硬件定价 | ¥459---¥799​ |
| BOM | ¥124---¥130​ |
| 订阅 | ¥15---¥39/月​ 分层解锁 |
| 单台云端成本 | ¥0.28/天​ |

需求规格里的每一个商业数字，都服务于一个人也能跑通的现金流模型。

贯穿所有产品的需求哲学

硬件是采集器与播报器，小程序是控制台，云端是编排引擎------内容与数据才是护城河。

FDE 在需求阶段的全部努力，就是在写第一行代码之前，确保这条护城河里流的是真问题、真用户、真价值。

---

七、共性方法：先写「绝不做清单」，再写功能清单

六案最深的一条共同纪律------每款产品在写功能清单之前，先把「绝不做清单」写死：

|------------------|----------------------------------------------------|
| 产品 | 绝不做清单 |
| 思库熊​ | 不做搜题（红海且与学习方法论冲突）、不做无练习闭环的内容播放器、家长端不看聊天内容​ |
| 拓境​ | 不做「整人攻略」、不共享录音原文、不做无提示录音 |
| 陪伴熊·基础版​ | 不吹替代医生／心理咨询，不做医疗承诺 |
| 陪伴熊·亲情版​ | 不克隆未授权第三人声音、不标注为实时通话 |
| 记忆熊​ | 禁用「复活」「重生」、不编造生前未有的承诺 |
| 情绪球​ | 不存儿童原始语音、家长不可听原文、禁止说教 |

功能清单决定产品能做什么 ；绝不做清单决定产品是什么。

六款产品的差异化，几乎全写在「绝不做」那一段里------差异化就是敢不做。

---

八、自检：你的需求有「绝不做清单」吗

|---------------------------|---------------|
| 自检问题 | 不合格信号 |
| ****① 双边需求两边都立卡了吗？****​ | 只访使用者，付费方是猜的 |
| ****② 合规清单与功能清单并列了吗？****​ | 合规是事后补丁 |
| ****③ 隐私写进需求第一条了吗？****​ | 隐私放在附录里 |
| ****④ 绝不做清单有几条？****​ | 空白或只有「暂无」 |
| ****⑤ 验证姿态与证据等级匹配吗？****​ | C级证据却重仓首发 |
| ****⑥ 每一笔钱是买证据还是买产能？****​ | 需求阶段就下大批量订单 |

判读 ：六项全过 → 需求可以进设计阶段；三项以下 → 你在赌运气，不是在做产品。

---

九、金句收尾

思念有声，回忆可触。

下面按 第2篇 · 第12章 · 12.1节 ​ 归位。这是需求篇的收官页 ------前面十一页把需求「挖出来、立上项、写成规格」，这一页回答最后一个问题：需求冻不住，怎么办？

处理说明：①「某项目甲方变更27次无留痕」案例在 P14 ​ 已用过，此处作为「无序变更代价」的引子回扣，不重复展开；②内容要点第三点「每迭代只追1个核心指标」原文未展开，我补为第五部分「变更冲动的源头治理」------因为大部分变更不是外部强加的，是团队自己「顺便再加一个」加出来的；③PM-20 模型卡的芒格／张磊三段式已重复多轮，精简吸收进第一部分与第七部分。

---

第12章　需求收口：变更走门与篇末总装

章眼：需求冻不住是正常的，冻不住还不留痕才是灾难。

12.1　需求变更：不是不能变，是要走门（P24）

【开头钩子】

需求随便改的项目，最后都死在「顺便再加一个」上。

需求变更在AI项目里是常态，不是意外------模型能力在变、现场反馈在变、竞争环境在变，指望需求冻结、一次成型，本身就不现实。

无序变更才是万恶之源。

回扣 P14 的那个数字：某项目甲方前后变更需求 27次 ，无书面留痕、无评估流程，仅算力成本就额外损耗180万------这些损耗的种子，全在需求阶段没有建立纪律。

解法不是禁止变更，而是------

给变更开一扇正门：变更控制委员会（CCB）与分级变更流程。

---

一、两种变更方式对比

|--------------|------------------------|-----------------------------|
| 维度 | 口头拍板 ​ | CCB 变更委员会 ​ |
| 成本​ | 看起来免费 | 贵（要开会、要评估、要留痕） |
| 速度​ | 快，一句话 | 慢，走流程 |
| 可见性​ | 无痕，事后说不清 | 全程留痕，可复盘 |
| 对团队​ | 技术被随意插队，疲于奔命 | 技术有依据拒绝口头插队 |
| 对项目​ | 范围无声蔓延，工期失控 | 范围可控，每次蔓延都有代价 |
| 结局​ | 初期快，后期崩​ | 初期慢，活得久​ |

CCB 贵，但它买的是「活得久」。

口头拍板省下的那次开会时间，会在交付前夜以十倍的返工还回来。

一个反直觉的判断------沉没成本不应绑架决策：

芒格提醒「已投入成本不应绑架未来决策」。变更审批最容易犯的两个错：

• ❌ 因为已经投了很多，拒绝必要的变更（被沉没成本绑架）；
• ❌ 因为已经投了很多，强行推进错误的变更（同上，另一个方向）。

正确姿势：只看增量成本与增量价值，不看过往投入。

---

二、变更四步：申请 → 评估 → 审批 → 回链

流程分四步，每步都有明确产出：

|------------------|-------------------------------------------------------------------|---------------------|
| 步 | 动作 | 产出 |
| ① 提出​ | 任何变更书面提交------说明原因、影响范围、期望时间 | 变更申请单（口头无效） |
| ② 评估​ | FDE牵头，评估对四阶段的影响------需求／设计／技术／交付各受什么冲击，追加多少人月与成本，影响哪些验收指标 | 影响面评估报告 |
| ③ 审批​ | 按变更分级走不同闸门（见第三部分） | 审批结论 |
| ④ 留痕与同步​ | 变更记录归档，所有干系人书面确认，需求基线版本号升级 | 变更台账＋基线升版 |

第四步「回链更新文档与用例」最容易被跳过------改了基线却没改测试用例，等于没改。

记住：每一次变更，都要同步回链到 PRD、验收标准、WBS、测试用例​ 四处，缺一处就是埋雷。

---

三、变更四级：按影响面分权

变更按影响面分四级，对应不同的审批权限------这是 CCB 可执行的关键。

|--------------|-------------------|----------------------|---------------|
| 级别 | 典型情形 | 审批路径 | 是否改基线 |
| 微调级​ | 话术、灯效、文案、Prompt措辞 | FDE批准，记录备查​ | 不改 |
| 小改级​ | 单模块功能、小程序页面、内容包增补 | 技术＋产品双签​ | 小版本升号 |
| 大改级​ | 范围／成本／排期／合规变化 | CCB 集体评审​ | 基线升级并通知全员 |
| 重构级​ | 目标人群或商业模式变化 | 重走 Go/No-Go​ | 重新立项​ |

判定要点：

微调级 = 不影响范围与指标（如话术调整、灯效颜色）；

小改级 = 影响单一模块或单一端（如小程序增加一个页面）；

大改级 = 影响范围、成本、排期或合规（如记忆熊新增一种声音授权方式）；

重构级 = 动摇了立项时的核心假设 （目标人群变了、定价模型变了）------本质上等于新项目，必须重走 Go/No-Go。

大部分团队只分了「改」和「不改」两级------没有中间层，就只剩「走后门」和「一刀切」两个选项。

---

四、每迭代只追1个核心指标：变更冲动的源头治理

前面三步都是在「变更发生后」设卡。但真正的解法在源头------

大部分变更不是外部强加的，是团队自己「顺便再加一个」加出来的。

纪律：

每迭代只追 1 个核心指标，禁止「顺便再做五个功能」。

|----------------|-------------------------|-------------------------------|
| 对比 | multi-target 迭代 | 单指标迭代 ​ |
| 本迭代目标​ | 「优化体验、加三个功能、修一批Bug」 | 「把方言识别率从88%提到92%」​ |
| 变更倾向​ | 随时插入新需求，目标漂移 | 任何不服务该指标的需求进池子，不进本迭代​ |
| 验收​ | 说不清做完没有 | 指标达成即完成，达成不了即失败 |

为什么这条能治变更：

当团队只有一个指标时，任何新需求进来都要先回答一个问题------

「它服务于本迭代那个指标吗？」

答「是」→ 替换掉现有某条需求（有进有出）；

答「不是」→ 进需求池，下个迭代再说。

没有「顺便」二字------要么换，要么等。

目标越多，变更的入口就越多；锁定一个指标，就是把变更的窗户关到只剩一扇门。

---

五、架构弹性：用 SKU 与订阅分层消化变更冲动

CCB 是制度接口，架构上还需要一个技术接口------六款产品用 SKU 与订阅分层消化变更。

新需求不一定要改硬件。

多数新需求可以通过以下方式实现，固件不变、变更成本趋近于零：

|---------------------------|--------------|
| 方式 | 适用 |
| OTA 下发新 Prompt 包​ | 话术、人设、模型路由规则 |
| 新增订阅内容​ | 戏曲包、故事包、模型精讲 |
| 小程序页面增补​ | 新功能入口、新看板 |

典型示例：

|----------------|--------------|--------------------------------------------------|
| 变更 | 传统做法 | 贯穿项目做法 |
| 陪伴熊要加「亲情版声音克隆」 | 重新开模、改硬件 | 同主板 ＋ OTA ＋ 订阅解锁（亲情版 ¥798，或基础版 ＋¥199 升级） |
| 思库熊要加「对话式话术」 | 重写全部内容资产 | 列二期，一期冻结（回扣 P20 冻结窗口案例） |

这种架构上的弹性 ，是 FDE 在设计阶段为变更预留的最重要的制度性技术接口。

能用 OTA 解决的变更，不要动硬件；能用订阅解决的变更，不要动固件。

---

六、CCB 的深层价值：保护团队，也保护业务

CCB 机制的价值不在流程本身，在它同时保护了三方：

|-----------------|---------------------------------|
| 保护对象 | 保护方式 |
| 保护业务方​ | 让业务方知道变更是有成本的，从而减少随意拍脑袋 |
| 保护技术团队​ | 让技术有依据拒绝口头插队，不必靠吵架挡需求 |
| 保护项目​ | 让每一次范围蔓延留下可供复盘的证据​ |

张磊强调「可验证的交付建立长期信任」------CCB 保护的就是交付承诺本身。

一个每次都能按承诺交付的团队，比一个什么都答应、什么都延期的团队，长期拿到更多资源。

---

七、自检：你的变更走门了吗

|--------------------------------|--------------------|
| 自检问题 | 不合格信号 |
| ****① 变更是书面提交的吗？****​ | 群里一句话、会上口头一提就算数 |
| ****② 影响面评估做了吗？****​ | 只说「应该不难」，没有四阶段影响分析 |
| ****③ 变更分级了吗？****​ | 只有「改」和「不改」两级 |
| ****④ 回链更新文档与用例了吗？****​ | 基线改了，测试用例还是旧的 |
| ****⑤ 本迭代有几个核心指标？****​ | 三个以上 → 变更入口敞开 |
| ****⑥ 能用 OTA／订阅解决的，动硬件了吗？****​ | 改了个话术就重新打样 |

判读 ：六项全过 → 变更在走正门；三项以下 → 你在开后门，而且后门正在变成大门。

---

八、需求篇收官：从模糊诉求到共同语言

到这里，需求阶段完整闭环：

模糊诉求

↓ ① 甄别（P14 三项检验／七问／证据分级）

↓ ② 挖掘（P18 画像／访谈／AI辅助）

↓ ③ 转译（P15 三级转译／证据链）

↓ ④ 立项（P16 五步循环／三件套／P17 EV排序）

↓ ⑤ 规格（P20 PRD／验收标准／WBS）

↓ ⑥ 评审（P19 非目标／否决清单）

↓ ⑦ 实战（P21 B端扫流程／P22-P23 六款C端产品）

↓ ⑧ 变更（本节 CCB 走门）

↓

全团队可执行、可验收、可追溯的共同语言

需求阶段的全部努力，就是在写第一行代码之前，把「真问题、真用户、真价值、真边界」四件事说清楚。

收官三句话：

1. 需求篇的产出不是文档，是「不做什么」的资格。
2. 伪需求做得越完美，浪费越彻底。
3. 需求变更不可怕，没留痕的变更才致命。

📌 后续衔接 ：需求篇的五件套（画像卡／证据台账／PRD／优先级矩阵／验收标准）在此收口。P28（质量门禁） ​ 将在测试篇承接「验收标准如何变成门禁」，****P30（P0需求总表）****​ 将在交付篇承接「验收如何对齐交付」------两者都是本节验收标准的下游。

---

九、金句收尾

需求变更不可怕，没留痕的变更才致命。

下面按 第2篇 · 第13章 · 13.1节 ​ 归位。这是需求篇的AI工具箱开篇 ------前面十二章讲的是方法论，这一章给的是可以直接复制使用的 AI Prompt 武器。

先说这一页最需要处理的事 ：你粘贴的内容里，约 70% 属于另一本书 （《特种部队式团队搭建 × 38场景落地 × AI项目管理实战》V5.3）------包括「你为什么需要这本书」营销话术、场景1-13的索引目录、以及「算力FinOps成本优化」「ROI价值量化」「向上汇报」三大块（带「超级惨烈真实案例」）。这些我全部单列归位，不进本页。

同时，你【内容要点】里点名的 场景14（5W2H）与场景16（金字塔原理） ，正文里恰好没有给内容 ------我按本书体系补齐（5W2H 回链 P18，金字塔原理回链 P10 的 SCQA），并给每个场景配上可直接复制的 AI 提问公式。

---

第13章　AI需求工具箱

章眼：方法论告诉你怎么想，Prompt 让它立刻跑起来。

13.1 AI需求工具箱（一）：分析与决策场景（P25）

【开头钩子】

这5个AI场景，覆盖需求分析90%的场合。

需求工作里有大量结构化的重复思考------拆要素、扫环境、推演失败、找根因、组织结论。这五件事，AI 都能替你完成第一稿，你只负责校验与决策。

|------------------------------|--------------------|-------------------|
| 场景 | 一句话 | 需求篇落点 |
| ① 第一性原理（场景3） | 回到问题本质，砍掉惯性功能 | 伪需求过滤、方案僵局 |
| ② 事前验尸（场景4） | 假设项目已失败，倒推死因写进风险清单 | REQ-06 逆向思维 |
| ③ SWOT＋PESTLE（场景7/8） | 内外环境一次扫清 | 立项论证、赛道选择 |
| ④ 5W2H（场景14） | 把模糊诉求拆成七要素 | 用户画像（P18） |
| ⑤ 金字塔原理（场景16） | 结论先行，论据分层 | 汇报与PRD组织（P10/P20） |

AI负责生产，人负责校验、追问与决策------这是全书工具箱的通用纪律。

---

零、万能底座：向AI提问的七步公式

其余五个场景的 Prompt，都建立在这个公式之上。

|-----------|-------------|------------------------------|
| 步 | 要素 | 说明 |
| 1 | 角色​ | 定制角色（资深需求分析师／苛刻的评审委员／跨域产品专家） |
| 2 | 任务​ | 做什么事（拆解／分析／审查／生成） |
| 3 | 步骤​ | 分几步走，每步输出什么 |
| 4 | 模型​ | 指定模型（如用Claude 3） |
| 5 | 数据​ | 填入你的项目数据 |
| 6 | 条件​ | 约束（字数／格式／禁止项） |
| 7 | 需求​ | 最终要什么产出 |

结构化提问 ＝ 结构化输出。

缺数据就先用占位符 { }，再二次追问补全------不要因为数据不全就不问。

---

一、场景3｜第一性原理：回到本质，砍掉惯性功能

|----------------|------------------------------------------------|
| 项 | 内容 |
| 一句话​ | 问「根本原因是什么」，打破方案僵局 |
| 什么时候用​ | 技术选型争论、方案反复推翻时 |
| 核心追问​ | 去掉这个假设，还成立吗？​ |
| 做法​ | 从第一性原理重建最小方案​ |
| 适用边界​ | 适合 POC 阶段找最简可行路径 ；不适合已上线系统的细调​ |

第一性原理的通俗说法：

像科学家一样思考------先问「我们绝对确定什么是真的？什么已经被证明了？」，然后一路深挖，直到只剩基本真理，再由此重建路径。

需求篇的落点 ：当团队争论「该不该做这个功能」时，用第一性原理砍掉惯性功能------

|--------------|-----------------------------|------------------------|
| 惯性思维 | 第一性原理追问 | 结论 |
| 「竞品都有拍照解题」 | 用户真正的任务是什么？是「知道答案」还是「学会方法」？ | 学会方法 → 砍掉拍照解题​ |
| 「要做个搜索功能」 | 用户找不到的根因是没搜索，还是导航太深？ | 导航太深 → 优化信息架构​ |

AI 提问公式：

你是资深产品架构师。针对以下需求，用第一性原理分析：

1）我们要解决的【根本问题】是什么？请剥掉所有既有方案假设；

2）列出当前方案中被当作「理所当然」的3个假设，逐一追问

「去掉这个假设，需求还成立吗？」；

3）从基本真理出发，重建一个最小可行方案（MVP）；

4）指出哪些功能是「惯性添加」、可以砍掉。

需求描述：{粘贴需求}

约束：只保留服务于根本问题的功能，不超过5项。

---

二、场景4｜事前验尸法：假设已失败，倒推死因

|----------------|------------------------------------------|
| 项 | 内容 |
| 一句话​ | 假设项目已失败，倒推原因，重大决策前必做​ |
| 什么时候用​ | 千万级立项、方向性变更、上线前 |
| 产出​ | 死因清单 → Top5 → 逐条转成带负责人与截止日期的规避项​ |

做法三步：

1. 写「项目已失败」的新闻标题；
2. 团队独立列出失败原因（5-10分钟，不许讨论）；
3. 汇总 Top5，逐条提前设防。

📌 回扣 ：这套动作就是 REQ-06 逆向思维（P17 第五部分）------芒格「Invert, always invert」，达利欧「失败是进化的天然副产品」。

需求篇的落点：六款产品的「绝不做清单」，几乎全是事前验尸写出来的------陪伴熊的不吹医疗、记忆熊的禁用复活、情绪球的防吞咽（回扣 P23 第七部分）。

AI 提问公式：

你是苛刻的项目评审委员。我们将执行以下方案，请做事前验尸：

1）假设一年后的今天，这个项目已惨败，请写出1条新闻标题；

2）独立列出导致失败的10条原因（按可能性排序）；

3）从中挑出Top5，逐条反推为「带负责人+截止日期」的规避动作；

4）指出哪3条死因在需求阶段就能提前布防。

方案描述：{粘贴方案}

约束：不许说「资源不足」这类空话，死因必须具体到可验证的事件。

---

三、场景7＋8｜SWOT ＋ PESTLE：内外环境一次扫清

两个模型分工不同，通常联用：

|---------------------|-------------|----------------------------------------------------------------------------------|
| 模型 | 扫什么 | 四／六要素 |
| SWOT（场景7） | 内外部竞争态势 | 优势 Strengths／劣势 Weaknesses（内部 ）＋ 机会 Opportunities／威胁 Threats（外部） |
| PESTLE（场景8） | 宏观环境红线 | 政治／经济／社会文化／技术／法律／环境 |

SWOT：战略方向一页纸

|----------------|--------------------------------------|
| 项 | 内容 |
| 一句话​ | 快速做SWOT，战略方向一页纸 |
| 什么时候用​ | 选赛道、定AI转型方向、竞品对比 |
| 做法​ | 给AI公司／产品背景 → 要求 SWOT ＋ 交叉策略​ |

交叉策略才是 SWOT 的产出：SO（优势×机会）如何进攻、ST（优势×威胁）如何防御、WO（劣势×机会）如何补强、WT（劣势×威胁）如何收缩。

需求篇的落点：记忆熊的竞品拆解（P18 第七部分）就是 SWOT 的实战版------StoryFile 有视频但非实时（威胁／机会），「毛绒＋实时对话」是无人占据的空白（SO 进攻点）。

PESTLE：避免踩政策／技术红线

|----------------|--------------------------------------|
| 项 | 内容 |
| 一句话​ | 宏观环境扫描，避免踩政策／技术红线 |
| 什么时候用​ | 出海、政企、强监管行业的AI项目 |
| 做法​ | PESTLE 六维度各写2-3点，标注对项目的影响等级​ |

|-----------------------------|--------------------------|
| 维度 | 需求阶段要问什么 |
| Political 政治​ | 监管政策是否支持？（如 AI 纪念、儿童产品） |
| Economic 经济​ | 目标人群的付费能力？订阅接受度？ |
| Sociocultural 社会文化​ | 文化禁忌？（如记忆熊禁用「复活」） |
| Technological 技术​ | 技术成熟度？是圈内还是圈外（能力圈）？ |
| Legal 法律​ | 合规红线？（声音克隆授权、儿童隐私、数据不出境） |
| Environmental 环境​ | 硬件环保与材料认证？（食品级硅胶、3C） |

PESTLE 是「天象雷达」------回扣 P09「政策与资本天象」：不抬头看天，车开得再快也可能在悬崖边飙车。

六款产品里，****记忆熊（合规门禁）与情绪球（儿童隐私）****​ 是 PESTLE 扫描最重的两款------越是强监管、高敏感场景，PESTLE 越要在需求阶段前置。

AI 提问公式（联用）：

你是战略分析师。基于以下产品背景，做一次完整环境扫描：

【SWOT部分】

1）列出内部优势/劣势各3条、外部机会/威胁各3条；

2）给出交叉策略：SO进攻、ST防御、WO补强、WT收缩；

【PESTLE部分】

3）六个维度各列2-3点，并标注「高/中/低」影响等级；

4）指出哪些是必须在需求阶段就写进「绝不做清单」的红线。

产品背景：{粘贴背景}

约束：SWOT要具体到可验证的事实，PESTLE红线必须有明确出处或法规依据。

---

四、场景14｜5W2H：把模糊诉求拆成七要素

📌 完整骨架见 P18（9.1节） ------那里讲 5W2H 如何用于用户画像 。此处作为 AI 工具，讲它如何拆解模糊诉求。

|----------------|---------------------------|
| 项 | 内容 |
| 一句话​ | 把一句模糊的话，拆成七个可回答、可验证的要素 |
| 什么时候用​ | 接到老板一句话需求、客户口头诉求、竞品抄作业需求时 |
| 产出​ | 一张七要素表，空白项即「需要回去补的证据」 |

七要素与需求场景的对应：

|-------------------|-------------------|------------------------|
| 要素 | 追问 | 空白意味着什么 |
| Who​ | 谁使用？****谁付费？****​ | 付费方不明 → 回链 P18 决策链 |
| Why​ | 核心动机与情感驱动？ | 动机错 → 功能全错 |
| When​ | 什么时刻触发？频次？ | 无法排优先级、无法定推送时机 |
| Where​ | 什么场景／地点？ | 场景不定 → 形态定不了 |
| What​ | 要完成什么任务？ | 任务清单＝功能清单的种子 |
| How​ | 现在怎么凑合解决？ | 没有替代方案 → 痛点不真​ |
| How much​ | 愿付多少？决策链是谁？ | 无法定价、无法算 ROI |

七要素里 How****（现有替代方案）最关键****------用户说不出「现在怎么办」，所谓痛点多半是想象。

回扣 P14 伪需求七问第②问：没有替代方案的痛点往往不痛。

AI 提问公式：

你是资深需求分析师。以下是一句模糊的业务诉求，请用5W2H拆解：

1）逐项回答 Who/Why/When/Where/What/How/How much；

2）每一项标注：该结论的证据等级（A数据/B访谈/C推测）；

3）标出「回答不上来」的项------这些就是必须回去补的证据；

4）基于 What（任务清单），列出候选功能，并用 EV 公式粗排序。

模糊诉求：{粘贴诉求}

约束：不许编造答案，答不上来的项必须明确写「待补证据」。

---

五、场景16｜金字塔原理：结论先行，论据分层

|----------------|-------------------------------------------|
| 项 | 内容 |
| 一句话​ | 结论先行、以上统下、归类分组、逻辑递进 |
| 什么时候用​ | 写 PRD、写立项书、向老板汇报、组织评审材料 |
| 四条原则​ | ① 结论先行 ② 以上统下 ③ 归类分组（MECE）④ 逻辑递进​ |

与 SCQA 的关系（回扣 P10 第四部分）：

|----------------|----------------------------------|--------------|
| 模型 | 作用 | 适用场景 |
| SCQA​ | 讲故事的钩子------背景→冲突→问题→答案 | 向上汇报、申请资源、说服 |
| 金字塔原理​ | 组织材料的骨架------结论在上，论据分层支撑 | PRD、立项书、评审材料 |

SCQA 负责「让人愿意听」，金字塔负责「让人听得懂」。

需求篇的落点：

• PRD 十章结构（P20）本身就是金字塔------第一章「背景与目标」是塔尖结论，后面各章是分层论据；
• 立项一页纸（P20 第一部分）是金字塔的极简版------五栏就是五层论据支撑一个结论。

AI 提问公式：

你是结构化写作专家。请把以下零散材料，按金字塔原理重组：

1）先给出一句话核心结论（塔尖）；

2）列出3-5个支撑论据（归类分组，做到MECE不重不漏）；

3）每个论据下挂2-3条事实/数据/证据；

4）检查：是否结论先行？是否以上统下？是否有遗漏？

5）如果是向老板汇报，请额外用SCQA改写一版开场。

零散材料：{粘贴材料}

约束：结论必须一句话说清，不许用「综上所述」这类套话开头。

---

六、五场景速查与联用

|----------------------|--------------|------------------------------|
| 场景 | 解决什么 | 需求篇最常用在哪一步 |
| 第一性原理​ | 砍掉惯性功能 | 伪需求过滤（P14） |
| 事前验尸​ | 提前布防死因 | REQ-06 逆向思维（P17）→ 绝不做清单（P23） |
| SWOT＋PESTLE​ | 扫清内外环境与红线 | 立项论证（P16）、竞品拆解（P18） |
| 5W2H​ | 拆模糊诉求 | 用户画像（P18）、B端扫流程（P21） |
| 金字塔原理​ | 组织材料与汇报 | PRD（P20）、立项一页纸（P20） |

联用组合包：

|------------------|----------------------------------------------|----------------|
| 组合 | 场景链 | 产出 |
| A 立项论证​ | PESTLE（扫红线）→ SWOT（找定位）→ 5W2H（拆需求）→ 事前验尸（写死因） | 一份完整立项材料 |
| B 伪需求过滤​ | 5W2H（拆要素）→ 第一性原理（砍惯性）→ 事前验尸（推演失败） | 一条需求的 Go/No-Go |
| C 汇报要资源​ | 金字塔（组织材料）→ SCQA（改写开场） | 一页说服老板的汇报 |

---

七、自检：你的AI用对了吗

|------------------------------|-------------------------|
| 自检问题 | 用错了的信号 |
| ****① 你用AI「补结构」还是「替答案」？****​ | 直接问AI「这个需求该不该做」并照抄结论 |
| ****② AI给的证据你回听／回查了吗？****​ | 原话被AI润色过（P18 纪律：原话不可改写） |
| ****③ 数据不全时你用占位符了吗？****​ | 因缺数据就放弃用AI |
| ****④ 事前验尸是团队独立写的吗？****​ | 一起讨论后写 → 从众效应，失去意义 |
| ****⑤ 金字塔是结论先行吗？****​ | 铺垫三页才说结论 |

判读 ：五项全对 → AI 是你的杠杆；两项错误 → AI 在替你思考，而你不该把思考外包。

AI 不会取代你，但会用 AI 的同行会。

工具箱的正确用法：让 AI 跑第一稿，让人做最后一道判断。

---

八、金句收尾

AI负责生产，人负责校验、追问与决策------让AI跑第一稿，让人做最后一道判断。

下面按 第2篇 · 第13章 · 13.2节 ​ 归位。这是 AI 需求工具箱的下半场 ------上一节（P25）讲「分析与决策」（拆要素、扫环境、推演失败、找根因、组织结论），本节讲立项前必须完成的四件对齐工作：算账、定标、量化、对齐 ，最终产出立项输入包。

先处理三件事：①场景6/26 投入产出分析 的正文，原文散落在 P25 的素材里（「项目投入产出分析决策」），本页按内容要点要求整合，并补足「成本、收益、周期三栏表」；②P26 素材中重复出现场景14（5W2H）与场景16（金字塔） ------这两场景已在 P25 完整覆盖，本页不重复展开；③深圳 SaaS 的 OKR 悬空案例保留了核心教训，但删除了「科研型人才擅长造假数据」等贬损性表述，改为中性的「科研式研发」风险表述。

---

13.2 AI需求工具箱（二）：投入产出与目标对齐（P26）

【开头钩子】

立项前先算账：这笔投入多久回本？

需求通过评审，只说明「值得做对」；要立项，还必须回答------值不值得投、多久回本、做到什么算成功、谁来认这个结果。

本节四个场景，正好对应这四问：

|--------------------------|-----------------|------------------------|
| 场景 | 回答什么 | 产出 |
| ① 投入产出分析（场景6／26） | 值不值得投？多久回本？ | 成本／收益／周期三栏表​ |
| ② OKR（场景15） | 目标怎么拆到季度？ | O ＋ 可量化 KR​ |
| ③ SMART（场景20） | 验收标准怎么量化？ | 可验收的 SMART 指标​ |
| ④ 共识目标会（场景21） | 老板／业务／研发口径怎么拉齐？ | 共识目标书​ |

四个场景跑完，产出立项输入包------商业计划书 ＋ 可行性 ＋ Charter（回扣 P16 立项三件套）。

---

一、场景6／26｜投入产出分析：成本、收益、周期三栏表

|----------------|-----------------------|
| 项 | 内容 |
| 一句话​ | 用投入产出报告说话，立项续投不拍脑袋 |
| 什么时候用​ | 老板问值不值得投、POC 转正式、预算评审 |
| 核心产出​ | 成本／收益／周期三栏表​ |

1. 三栏表（本页核心工具）

|---------------|-------------------------------------|----------------------------------------------------------------------------------------|
| 栏 | 要填什么 | 贯穿案例示例 |
| ① 成本​ | 研发人力（人月）、算力／Token、硬件 BOM、内容生产、运维与合规 | 六款产品 BOM ¥124---¥130 ；单台云端成本 ¥0.28/天 （ASR＋TTS＋LLM）；启动资金 ¥3575​ |
| ② 收益​ | 硬件收入、订阅收入、降本金额、止损金额（均折算为货币） | 首年 1945台出货、124万硬件收入 ；1140户在订 ；订阅分层 ¥15---¥39/月​ |
| ③ 周期​ | 投入节奏、回本节点、回收节奏 | Phase1 50台预售 定金即回收现金流；首年硬件＋订阅形成持续现金流；不追求首发规模，追求留存验证（陪伴熊月销30---50台） |

收益栏最容易漏的是「降本」与「止损」------AI 项目的价值不只在增收，还在把人工占比、故障损失、合规风险压下去。

回扣 P17 的 EV 示例：支付重构「避免年损失500万」，就是典型的止损型收益。

2. 做法三步

1. 让 AI 生成投入产出报告模板；
2. 填入真实人力／算力／时间（BOM、云端、订阅、内容排期）；
3. 二次追问出结论与建议------给出 Go／No-Go 倾向与回本周期。

3. AI 提问公式

你是资深商业分析师。请基于以下项目信息，生成一份投入产出分析报告：

1）按【成本/收益/周期】三栏输出，每栏至少5行，金额统一折成人民币；

成本含：研发人力、算力Token、硬件BOM、内容生产、运维合规；

收益含：硬件收入、订阅收入、降本金额、止损金额；

周期含：投入节奏、回本节点、回收节奏。

2）计算回本周期（累计收益覆盖累计成本的月份）；

3）做敏感性分析：若销量/订阅率下降30%，回本周期如何变化；

4）给出Go/No-Go建议与三个必须监控的指标。

项目信息：{粘贴产品定价、BOM、云端成本、目标销量}

约束：不许只给乐观值，必须给出保守/基准/乐观三档。

---

二、场景15｜OKR：目标与关键结果对齐到季度

|----------------|---------------------------------------|
| 项 | 内容 |
| 一句话​ | 战略目标拆成可执行的 OKR |
| 什么时候用​ | 年度规划、季度对齐、POC 转正式后的目标续接 |
| 铁律​ | KR 必须可量化 ＋ 有 Deadline ＋ 有责任人​ |

1. AI 项目 OKR 失效的四种典型

传统软件目标清晰（完成功能、交付上线、修复 Bug 即可验收）；AI 项目是探索性工作，若照搬传统考核，必然出现四种悬空：

|---------------------|------------------------|
| 典型 | 表现 |
| ① 目标宏大无法落地​ | 只喊「AI 赋能业务」「提升产品竞争力」 |
| ② 指标模糊无法量化​ | 没有数字，只有「效果更好」「体验提升」 |
| ③ 结果悬空无法验收​ | 无阶段节点，做一半改一半废一半 |
| ④ 责任分散无人兜底​ | 人人有责＝人人无责（回扣 P01 责任鸿沟） |

探索性 AI 项目的特殊风险 ：若只考核技术参数（模型精度、论文复现、专利申报），团队容易陷入****「科研式研发」****------过程很漂亮，但无商业产出。

2. 案例胶囊（深圳某 ToB SaaS 公司）

2024 年顶层战略「AI 赋能 SaaS，实现智能数据分析／填报／风控三大能力升级」，年度预算 500万 。但管理层只给模糊目标------「把 AI 功能做出来、提升产品竞争力」，无量化指标、无阶段节点、无验收标准、无止损机制。

结果：团队全年刷模型精度、复现前沿论文、申报技术专利，PPT 汇报次次「重大突破、进展顺利」，但客户续费与溢价能力未提升，无商业产出。

教训：

AI 的 OKR 必须绑定商业结果（续费率、溢价、渗透率），不能只追技术参数。

KR 若不可量化、无 Deadline，OKR 就是一份漂亮的摆设。

3. OKR 写法示例（陪伴熊方言引擎）

|----------------|-------------------------------------------------|
| 层级 | 内容 |
| ****O（目标）****​ | 让方言闲聊成为陪伴熊的核心留存引擎 |
| KR1​ | 唤醒到播报 P95 ≤2.5s（100次实测），11月底达成 |
| KR2​ | 粤／川／普三方言识别率 ≥90%（各50句标准语料＋20句噪声），12月底达成 |
| KR3​ | 老人日均主动交互 ≥3次（200台内测），春节前达成 |
| KR4​ | 用药提醒 连续7天送达率 ≥97%，负责人：XXX |

4. AI 提问公式

你是OKR教练。请把以下战略/项目目标拆解为季度OKR：

1）写出1个方向性目标O（鼓舞人心、不包数字）；

2）列出3-5个KR，每条必须：可量化（有数字）+ 有Deadline + 有责任人；

3）指出哪些KR属于「技术参数」、哪些属于「商业结果」，并确保至少

一半KR绑定商业结果（收入/留存/降本/客户满意）；

4）标出若KR未达成的止损条件。

目标描述：{粘贴战略或项目目标}

约束：禁止出现「提升」「优化」这类无数字动词。

---

三、场景20｜SMART：验收标准必须可量化

|----------------|-------------------------------------|
| 项 | 内容 |
| 一句话​ | 模糊目标变 SMART，可验收 |
| 什么时候用​ | 领导口头布置任务后；每条 P0 写验收标准时​ |
| 落点​ | 回扣 P20 验收标准三要素：有场景、有数字、有口径​ |

1. SMART 五要素与需求篇落点

|---------------------------|------------------|---------------------------------|
| 要素 | 含义 | 需求篇落点 |
| S 具体 Specific​ | 场景与任务明确 | 场景写到触发动作级（如「方言闲聊首字响应」） |
| M 可衡量 Measurable​ | 有数字与测量方法 | P95 ≤800ms，100次实测计时​ |
| A 可达成 Attainable​ | 在能力圈内；圈外先 Spike | 回扣 P17 能力圈（REQ-05） |
| R 相关 Relevant​ | 对齐业务指标与付费方 KPI | B端回链岗位 KPI（P21）；C端对齐付费心理账户（P16） |
| T 有时限 Time-bound​ | 有 Deadline 与观察周期 | 回扣 P16 成功指标／止损条件 |

2. AI 产品的 SMART 扩展

除传统五要素，AI 功能验收还要额外写明：

|------------------|--------------------------------|
| 扩展项 | 内容 |
| 模型效果指标​ | 准确率、召回率、接管率、幻觉率 |
| 护栏规则​ | 禁用词、兜底话术、合规红线（回扣 P20 十章「护栏规则」） |
| 概率性输出兜底​ | 模型答错时怎么办（降级／转人工／温和提醒） |

3. 正反对照

|----------------|-------------------------------------------------------------------|
| ❌ 模糊目标 | ✅ SMART 改写 |
| 「提升识别率」 | 粤／川／普三方言识别率 ≥90% （各50句标准语料＋20句噪声语料），12月底前，负责人 XXX |
| 「配网要简单易用」 | 四步配网 ，老人独立成功率 ≥60% ，远程协助后 100%（20台冷启动实测） |

4. AI 提问公式

你是需求分析师。请把以下模糊目标改写为SMART验收标准：

1）逐条按 Specific/Measurable/Attainable/Relevant/Time-bound 五项拆解；

2）每项给出：场景、数字、测量方法（谁测/用什么测/测多少样本）、Deadline；

3）若属AI功能，额外补充：模型效果指标、护栏规则、答错时的兜底动作；

4）标出原目标中「无法量化、需要回去补证据」的缺口。

模糊目标：{粘贴目标}

约束：禁止出现「快速」「友好」「稳定」等形容词。

---

四、场景21｜共识目标会：拉齐老板、业务、研发三方口径

|----------------|---------------------------------|
| 项 | 内容 |
| 一句话​ | 目标会对齐，减少理解偏差 |
| 什么时候用​ | 多干系人、目标各说各话（立项前、季度 OKR 制定、重大变更） |
| 产出​ | 《共识目标书》（三方签字） |

1. 三方口径天然不同

|-------------|---------------|----------------|
| 方 | 关心什么 | 典型诉求 |
| 老板​ | 回本周期、ROI、战略卡位 | 「多久回本？为什么现在投？」 |
| 业务​ | 增长、留存、客户满意 | 「能不能带来续费和口碑？」 |
| 研发​ | 可行性、工期、技术风险 | 「做不做得出来？要多久？」 |

三方不拉齐，需求阶段就会埋雷------老板要规模、业务要体验、研发要工期，最后谁也没得到。

2. 共识目标会四步

|-------------------|-----------------------------------|-----------------------------|
| 步 | 动作 | 关键 |
| ① 独立写目标​ | 三方各自写下本季度目标，不许讨论​ | 避免从众与权威压制 |
| ② 摆冲突​ | 把分歧摊开（规模 vs 体验 vs 工期） | 冲突是共识的起点 |
| ③ 折算同一单位​ | 用 EV／投入产出表把目标折成钱或同一指标 | 不能通约就无法裁决 |
| ④ 出共识目标书​ | 目标／非目标／验收指标／责任人／时间点，三方签字​ | 回扣 P19 非目标、P16 Charter 退出标准 |

共识目标书的最后一行，永远是「退出标准」------什么情况下停止，比什么情况下继续更重要。

3. AI 提问公式

你是资深项目教练。以下是老板/业务/研发三方的目标诉求，请主持一场

共识目标会并输出结论：

1）列出三方诉求的差异点与冲突点；

2）用EV或投入产出口径，把三方目标折算为同一单位（金额或核心指标）；

3）给出折中方案：必须保留什么、可以让步什么；

4）输出《共识目标书》草稿，含：目标、非目标、验收指标（SMART）、

责任人、Deadline、退出标准。

三方诉求：{粘贴老板/业务/研发的原话}

约束：非目标栏至少3条；退出标准必须可触发、可验证。

---

五、产出：立项输入包（商业计划书 ＋ 可行性 ＋ Charter）

📌 回扣 P16 立项三件套。本节四个场景，分别 feeding 三件套：

|----------------------|-----------------------------|-------------------------------------|
| 场景 | 对应件套 | 回答什么 |
| 投入产出分析​ | ① 商业计划书（PM-07） | 做这件事值不值？（市场／用户／商业模式／3年财务预测） |
| OKR ＋ SMART​ | ② 可行性 Go/No-Go​ | ****能不能做？做到什么算成功？****​ |
| 共识目标会​ | ③ 项目 Charter（PM-09） | ****谁来做？边界在哪？成功／退出标准？****​ |

装配顺序：

算账（投入产出） → 定标（OKR） → 量化（SMART） → 对齐（共识会）

↓

立项输入包：商业计划书 ＋ 可行性 ＋ Charter

立项输入包清单：

|-----------|---------------------------|----------------|
| # | 组件 | 来源 |
| 1 | 立项一页纸（五栏／九格） | P20 |
| 2 | 投入产出三栏表（成本／收益／周期） | 本节场景6／26 |
| 3 | OKR 表（O ＋ 可量化 KR） | 本节场景15 |
| 4 | SMART 验收标准表​ | 本节场景20（落点 P20） |
| 5 | 共识目标书（三方签字） | 本节场景21 |
| 6 | 证据链体检表（绿／黄／红） | P15 |
| 7 | 非目标清单 | P19 |

立项输入包不齐，就不进 Go/No-Go 评审。

七件里最容易被跳过的是第2件（投入产出）------而它恰恰是老板唯一真正会看的那一张表。

---

六、场景速查与联用

|----------------------|-------------|-------------|---------------------|
| 场景 | 一句话 | 产出 | 需求篇落点 |
| 投入产出分析（6／26） | 用投入产出报告说话 | 成本／收益／周期三栏表 | P16 商业初稿、P17 EV |
| OKR（15） | 战略拆成可执行目标 | O ＋ 可量化 KR | P16 成功指标、P23 验证姿态 |
| SMART（20） | 模糊目标变可验收 | SMART 验收标准 | P20 验收标准三要素 |
| 共识目标会（21） | 拉齐三方口径 | 共识目标书 | P19 非目标、P16 Charter |

联用组合包：

|--------------------|-----------------------------------------|----------------------|
| 组合 | 场景链 | 产出 |
| A 立项材料​ | 投入产出 → OKR → SMART → 共识目标会 | 完整立项输入包​ |
| B 向老板要资源​ | 金字塔（P25 组织材料）→ 投入产出（算账）→ 共识目标会（对齐口径） | 一页说服老板的汇报 |
| C POC 转正式​ | 投入产出（回本周期）→ SMART（POC 验收指标）→ OKR（下阶段目标） | POC 转正式的 Go/No-Go 结论 |

---

七、自检：你的账与目标对齐了吗

|---------------------------------------|-----------------------|
| 自检问题 | 不合格信号 |
| ****① 投入产出三栏表填全了吗？****​ | 只有成本，没有收益与回本周期 |
| ****② 回本周期算出来了吗？****​ | 只说「长期看好」，算不出月份 |
| ****③ OKR 的 KR 可量化且有 Deadline 吗？****​ | 只有「提升 AI 能力」这类目标 |
| ****④ 验收标准过 SMART 了吗？****​ | 只有「快、准、稳」 |
| ****⑤ 三方口径拉齐了吗？****​ | 老板／业务／研发各说各话，无签字 |
| ****⑥ 立项输入包三件套齐了吗？****​ | 只有商业计划书，无可行性与 Charter |

判读：

• 六项全过 → 可进 Go/No-Go 评审；
• 三项以下 → 你在许愿，不是在立项。

算不清投入、收益与回本周期，就不要谈立项。

---

八、金句收尾

算不清投入、收益与回本周期，就不要谈立项------立项输入包的第一页，永远是账本。

下面按 第2篇 · 第13章 · 13.3节 ​ 归位。这是 AI 需求工具箱的第三组场景 ，也是需求篇工具箱的收口------前面两节（P25 分析与决策、P26 投入产出与目标对齐）解决「怎么想清楚、怎么算清楚」，本节解决****「你怎么知道这不是别人已经做过、或已被市场证伪的东西」****。

先说这一页的重复处理 ：你粘贴的 raw 里，场景22（竞品分析）是本页主线；但 场景23（用户画像）已在 P18 完整覆盖、场景24（需求变更）已在 P24 覆盖、场景25（需求挖掘）已在 P18 覆盖、场景26（投入产出）已在 P26 覆盖、场景27（PRD编写）已在 P20 覆盖 ------这五个场景本页不重复展开 ，统一在第六部分做「归位速查表」。另外 raw 中场景22 的 AI 示例是「中国洗发水市场」，与本书六款 AI 硬件贯穿案例无关，已替换为记忆熊／拓境的贯穿案例。

---

13.3　竞品分析与市场验证：别闭门造车（P27）

【开头钩子】

你以为的差异化，可能只是你没看过竞品。

需求阶段最危险的一句自我安慰是------

「这个市场没人做。」

真相往往是：你没找到，不等于没有。闭门造车做出来的「差异化」，常常只是信息差造成的幻觉。

竞品分析在需求篇的位置很明确：它不是市场部的工作，而是需求验证的对照组------

竞品验证需求是否存在，空白点定义你的差异化。

---

一、竞品是需求的对照组

竞品分析对需求工作的三重价值：

|-------------------|-------------------------------------------|
| 价值 | 说明 |
| ① 验证需求存在​ | 竞品活着，说明需求真实；竞品死了，要看死因 |
| ② 暴露需求边界​ | 竞品「没做」的功能，可能是坑，也可能是空白 |
| ③ 提供免费调研​ | 竞品评论区的差评与弃用原因，是对手花钱帮你做的调研（回扣 P18） |

竞品功能表只能作参考，不能当需求证据------对手做了不代表用户需要（REQ-02 证据分级要求）。

但竞品的差评区 ，是 A 级证据的金矿：那是真实用户用真金白银投出的反对票。

---

二、场景22｜竞品分析：功能矩阵 ＋ 定价 ＋ 口碑三张表

|----------------|----------------------------------|
| 项 | 内容 |
| 一句话​ | 竞品分析快速出稿，三张表看清格局 |
| 什么时候用​ | 立项、产品规划、需求评审前 |
| 产出​ | 功能矩阵表 ＋ 定价对比表 ＋ 口碑（差评）表​ |

📌 raw 中场景22 的示例是「中国洗发水市场」，与本书无关；以下三张表改用****贯穿案例（记忆熊／拓境）****填充。

表一｜功能矩阵表

|-------------|-------------------|----------------------|-----------------|---------------------------|
| 功能项 | StoryFile | HereAfter AI | 国内纪念小程序 | 记忆熊（我们） ​ |
| 视频／影像 | ✅ 预录制视频 | ❌ | ❌ | ❌（不做） |
| 实时对话 | ❌ 非实时 | ✅ | ✅ | ****✅****​ |
| 实体载体 | ❌ | ❌ | ❌ | ✅ 毛绒熊​ |
| 素材采集门槛 | 高（专业录制） | 中 | 低 | ****低（七题问卷）****​ |
| 合规门禁 | --- | --- | 粗放 | ✅ 三证核验​ |

表二｜定价对比表

|-----------------------|------------|-----------------------|---------------------------|
| 竞品 | 形态 | 定价模式 | 弱点＝你的机会 |
| StoryFile​ | 录制访谈视频库 | 按次／订阅 | 录制门槛高，仪式感强但日常陪伴弱​ |
| HereAfter AI​ | App 语音问答 | 订阅制 | 无实体寄托，老人不会用 App​ |
| 国内 AI 纪念小程序 | 纯软件对话 | 免费＋打赏 | 无硬件载体，情感浓度低、合规粗放​ |
| 记忆熊​ | 毛绒实体＋实时对话 | ¥799 ＋ ¥99/年​ | 七题问卷＋实体寄托＋合规门禁 |

表三｜口碑（差评）表------最有价值的一张

|------------|-----------------------|-----------------------------|
| 竞品 | 差评／弃用原因（金矿） | 我们的对策 |
| StoryFile | 「只能回答录制过的问题，问新的就答不了」 | 实时对话（RAG＋人格 Prompt） |
| HereAfter | 「父母不会用 App，最后还是我在操作」 | 零学习成本实体（摸头唤醒／灯环） |
| 小程序类 | 「感觉像在和一个客服聊天，没有亲人的感觉」 | 人格档案＋口头禅＋禁区话题 |

差评区前三条，就是你的需求清单前三条。

竞品的优点告诉你「需求成立」，竞品的差评告诉你「差异化在哪」。

AI 提问公式（场景22）

你是资深竞品分析师。请针对以下赛道做一次竞品拆解，输出三张表：

【表1 功能矩阵】列出4-6个主要竞品 × 8-10个核心功能项，逐格标注

有/无/部分，并高亮「所有竞品都缺失」的格子（=空白点）；

【表2 定价对比】每个竞品的形态、定价模式、价格区间，

并标注「弱点=我们的机会」；

【表3 口碑差评】从竞品评论区/应用商店/社交媒体提取Top3差评与

弃用原因，逐条给出我们的应对设计；

【结论】用一句话写出我们的差异化定位（格式参考：

「不是XX，而是YY」）。

赛道与竞品：{粘贴赛道与竞品名单}

约束：功能矩阵必须标注数据来源，禁止凭印象打分；差异化定位

必须落在竞品的「缺失项」或「差评项」上，不许自说自话。

---

三、环境扫描工具箱：市场研判先于方案设计

竞品分析是微观 扫描；做市场研判，还要配中观＋宏观两层。三层工具各司其职：

|-------------|----------------------|--------------------------------------------|---------------|
| 层 | 工具 | 扫什么 | 回链 |
| 宏观​ | PESTLE​ | 政治／经济／社会文化／技术／法律／环境------红线在哪​ | P25 第三部分 |
| 中观​ | SWOT​ | 优势／劣势／机会／威胁------定位与策略​ | P25 第三部分 |
| 微观​ | 替代品扫描 ＋ 三张表​ | 直接竞品、间接竞品、替代品 ------差异化在哪​ | P18 第七部分 ＋ 本节 |

三层扫描的纪律：宏观看天（政策／监管），中观看地（竞争／资本），微观看人（竞品差评／替代品）。

市场研判先于方案设计------在想「怎么做」之前，先确认「这个市场值不值得进、我们凭什么赢」。

替代品的提醒 （回扣 P18）：替代品才是需求的真正对手------拓境的直接竞品是录音笔，但真正的替代品是****「自己忍着」**** ；情绪球的替代品是****「家长自己哄」****。看不清替代品，就会把「没人做」误判成「没需求」。

---

四、验证三问：竞品之外的市场验证

竞品表看完，还要回到用户本身。三个问题按顺序问------顺序不能反：

|------------|--------------------|----------------|--------------------------------|
| 序 | 验证三问 | 这一问验什么 | 答不出的后果 |
| ①​ | ****用户现在怎么解决？****​ | 现有替代方案（痛点真实性） | 没有替代方案 → 痛点多半是想象（回扣 P14 七问第②问） |
| ②​ | ****愿意为什么付费？****​ | 付费意愿与决策链 | 需要但不买单 → 无人付费 |
| ③​ | ****替代品是谁？****​ | 真正的竞争对手 | 只看直接竞品 → 死于替代品 |

三问的贯穿案例印证

|--------------|-------------------------|------------------------|-----------------|
| 产品 | ① 现在怎么解决 | ② 谁为什么付费 | ③ 替代品是谁 |
| 陪伴熊​ | 收音机听戏、靠记性吃药、打电话问候 | 子女为尽孝付费（71%代购） | 微信视频、戏曲机、监控摄像头 |
| 记忆熊​ | 手机里不敢删也不敢听的300多条语音 | 家属为纪念付费 | 纪念 App／小程序 |
| 拓境​ | 自己忍着（被坑后事后才想明白） | 职场人为防坑付费 | 录音转写笔、自己复盘 |
| 情绪球​ | 家长自己哄 | 家长为安心付费 | 故事机、家长陪伴 |

三问全过，才配叫「需求成立」；只过第一问，最多算观察项。

回扣 P16「三问排序」与 P23「精益三板斧」------这三问，就是硬件立项的验证主轴。

---

五、产出：竞品拆解报告 ＋ 差异化定位一句话

1. 竞品拆解报告四步（回扣 P18 第七部分）

|---------------------|---------------------------------------------------------|
| 步 | 动作 |
| ① 定问题​ | 本次拆解要回答的核心问题不是竞品长什么样 ，而是市场空白在哪里、我们凭什么赢​ |
| ② 拆定位与人群​ | 竞品各自面向谁？谁被忽略了？ |
| ③ 拆功能与体验链路​ | 录什么、怎么交互、付费点在哪、放弃点在哪​ |
| ④ 提炼策略空白​ | 所有竞品都缺失的那一格 |

报告结构（可直接使用）：

1. 赛道与竞品清单（直接/间接/替代品）

2. 三张表：功能矩阵 / 定价对比 / 口碑差评

3. 竞品各自的目标人群与放弃点

4. 策略空白：所有竞品都缺失的那一格

5. 差异化定位一句话

6. 对需求清单的影响：哪些需求该加、哪些该砍

2. 差异化定位一句话：格式「不是 XX，而是 YY」

这是竞品拆解最有价值的一行产出------它同时定义了「做」和「不做」：

|-----------------|--------------------------------------------|
| 产品 | 差异化定位一句话 |
| 记忆熊​ | 不是「复活」，而是「可对话的纪念档案」（宣传词：思念有声、回忆可触） |
| 陪伴熊基础版​ | 不是智能音箱，而是****「不在身边，也在身边」​ |
| 陪伴熊亲情版​ | 不是 AI 聊天，而是「团圆的存档键」​ |
| 拓境​ | 不是录音转写笔，而是「上场前的最后一次彩排」​ |
| 思库熊​ | 不是学习机，而是「把108套学习模型变成可语音调用的教练」​ |
| 情绪球​ | 不是故事机，而是「孩子发脾气时的伙伴」****​ |

「不是 XX」砍掉的是伪定位，「而是 YY」立起的是真差异。

这一句话写不出来，说明竞品拆解还没做到位------或者这个产品本就不该做。

90秒复述测试（回扣 P20）：把这句话拿给不知情的同事读，请他复述「这产品给谁用、凭什么赢、不做什么」。三问全中，定位才算立住。

---

六、场景速查与归位

本页主线是场景22（竞品分析）＋验证三问＋竞品拆解报告 。raw 中其余五个场景已在前面页面完整覆盖，不重复展开：

|------------------------|----------------|--------------------------------------------------|
| 场景 | 一句话 | 归位 |
| 场景23 用户画像​ | 用户画像清晰，模型不跑偏 | ****P18（9.1节）****​ 第一部分 5W2H 画像＋九宫格＋9张画像卡 |
| 场景24 需求变更两种方式​ | 既不全接也不全拒 | ****P24（12.1节）****​ 第一部分 口头拍板 vs CCB 对比＋四级变更 |
| 场景25 需求挖掘​ | 需求挖深一层，避免伪需求 | ****P18（9.1节）****​ 第二部分 访谈三不原则＋七问脚本＋反例收集 |
| 场景26 投入产出分析​ | 变更值不值得做，算清楚再答 | ****P26（13.2节）****​ 第一部分 成本／收益／周期三栏表 |
| 场景27 编写PRD​ | PRD初稿2小时出，人再精修 | ****P20（9.3节）****​ 第三部分 PRD 六章／十章骨架＋第七部分 AI 辅助起草 |

五个场景的核心纪律统一回扣：AI 出初稿，人做校验与决策（P18 第五部分、P25 开头）。

---

七、自检：你的竞品分析站得住吗

|--------------------------|---------------------|
| 自检问题 | 不合格信号 |
| ****① 三张表都填了吗？****​ | 只有功能矩阵，没有定价与差评 |
| ****② 你扫了替代品吗？****​ | 只盯直接竞品，没想过用户「现在怎么忍」 |
| ****③ 差评区前三条用了吗？****​ | 只抄竞品优点，没看用户骂什么 |
| ****④ 宏观中观微观三层扫了吗？****​ | 只看竞品，没看政策与监管红线 |
| ****⑤ 差异化定位一句话写得出吗？****​ | 说不清「不是什么、而是什么」 |
| ****⑥ 验证三问按顺序过了吗？****​ | 先问「怎么收费」再问「现在怎么解决」 |

判读 ：六项全过 → 差异化立得住，可进立项；三项以下 → 你以为的差异化，可能只是你没看过竞品。

---

八、金句收尾

先确认问题是否真实存在，再确认用户是否愿意付费，最后推进可售卖版本的开发。

下面按 第2篇 · 第14章 · 14.1节 ​ 归位。这是需求篇的最后一页 ------前面十五页把需求「挖出来、立上项、写成规格、挡住变更、配好工具」，这一页做总验收：需求能不能进设计阶段，就看这四道门。

先说两件事 ：①raw 里的场景22-25 已在前面页面完整覆盖（场景22→P27 主线、场景23→P18、场景24→P24、场景25→P18），本页不重复展开 ；②本页标题虽叫「门禁」，但它同时承担需求篇总收官的职责------文末会做全篇总装，并把五件套交接给设计篇。

---

第14章　需求篇收官：质量门禁与总装

章眼：写完那天不是结束，是怀疑的开始。

14.1　需求质量门禁：写完那天，怀疑才开始（P28）

【开头钩子】

好需求不是写出来的，是被怀疑出来的。

需求文档写完的那一刻，团队最容易松一口气。但真正的风险恰恰从这里开始------

文档越厚，越容易藏着没想清楚的地方。

厚文档的本质是没想清楚，只能用篇幅掩盖（回扣 P20）。

门禁不是挑刺，是在付利息之前，先把本金看清。

需求阶段的债，利息全部记在设计阶段。

---

一、门禁的两条底层原则

门禁不是一张检查表，它建立在两条原则之上------都来自达利欧《原则》，也是贯穿全书的认知底座。

原则一｜独立事实依据

每条需求，至少一个可验证的数据源。

|--------------|---------------------------------------------------|
| 要求 | 内容 |
| 独立​ | 证据不能来自「提需求的人自己」------业务方说「用户需要」，不算独立 |
| 可验证​ | 能点开、能回听、能复现------A级有数据，B级有原话与时间戳，C级有验证计划​ |
| 可追溯​ | 每条 P0 都能回链到证据链编号（回扣 P15） |

反面清单：

|-----------------|-------------------|
| ❌ 不合格依据 | 问题 |
| 「领导说要做」 | C级观点，非独立事实 |
| 「竞品都有」 | 对手做了≠用户需要（REQ-02） |
| 「我觉得用户肯定需要」 | 确认偏误 |
| 「大家都这么说」 | 嗓门噪音（回扣 P18 三层噪音） |

没有独立事实依据的需求，不是需求，是愿望。

原则二｜极度求真、极度透明

评审会上，允许任何人挑战任何条目。

|---------------|------------------------------------------|
| 要素 | 内容 |
| 极度求真​ | 把事实与观点显式分开------「我觉得」和「数据显示」必须标明 |
| 极度透明​ | 反对意见记录在案，不得抹掉；否决要写理由（回扣 P19） |

两条会议纪律：

1. 任何人可以挑战任何条目------不论资历、不论职级、不论谁提的；
2. 被挑战者必须回应证据，不能回应态度------「你不懂业务」不是反驳，「E-031 的采样只有城市老人」才是。

达利欧那句话值得贴在评审室墙上：

「我需要独立的事实依据，以及极度求真、极度透明的文化，才能做出最好的决策。」

反面信号：

|--------------|-------------------------------|
| ❌ 信号 | 含义 |
| 评审会全票通过 | 多半是走过场（回扣 P01：门禁通过率100%＝门禁失效） |
| 只有提需求的人在讲 | 没有独立挑战 |
| 反对意见没记进纪要 | 透明度失效 |

---

二、四道门禁：进设计阶段前的最后检查

四道门，逐条打勾。每道门给出：检查什么、合格标准、不合格怎么办。

门禁一｜证据链完整

|-----------------|-----------------------------------------------------|
| 项 | 内容 |
| 检查什么​ | 每条 P0 需求的证据链四要素（来源／等级／时效／状态）齐全，且能回链到原始证据 |
| 合格标准​ | 证据链健康表无红------绿／黄可过，红必须降级（回扣 P15 第九部分） |
| 不合格怎么办​ | 红灯需求降级为待验证，不得带病立项​ |
| 贯穿数据​ | 六款产品立项时健康表：绿61%、黄31%、红8%------红灯全部降级，无一带病立项 |

快速验证 ：随机抽一条 P0，要求三秒内点开原始证据（访谈原声／埋点数据／书稿出处）。点不开，就是断链。

门禁二｜验收标准可测

|-----------------|--------------------------------------------|
| 项 | 内容 |
| 检查什么​ | 每条 P0 的验收标准------有场景、有数字、有口径​ |
| 合格标准​ | 换一个没参会的工程师，能写出一样的测试用例（回扣 P20 第八部分） |
| 不合格怎么办​ | 退回补数字与方法；「快、准、稳」这类形容词一律打回 |

三要素检查：

• 有场景（什么场景下的什么指标）
• 有数字（P95、≥90%、≤2.5s）
• 有口径（谁测、用什么测、测多少样本）

「响应速度快、识别准」------这不是验收标准，是愿望清单。

门禁三｜非目标明确

|-----------------|------------------------------------|
| 项 | 内容 |
| 检查什么​ | 「绝不做清单」是否写死------每款产品至少3条​ |
| 合格标准​ | 功能清单之前先有非目标；每条非目标有明确理由 |
| 不合格怎么办​ | 空白或「暂无」→ 退回重写（回扣 P19、P23） |

六款产品的绝不做清单（回扣 P23 第七部分）：

|------------|------------------|
| 产品 | 绝不做 |
| 思库熊 | 不做搜题、家长端不看聊天内容 |
| 拓境 | 不做「整人攻略」、不共享录音原文 |
| 陪伴熊基础版 | 不吹替代医生／心理咨询 |
| 陪伴熊亲情版 | 不克隆未授权第三人声音 |
| 记忆熊 | 禁用「复活」「重生」 |
| 情绪球 | 不存儿童原始语音、禁止说教 |

功能清单决定产品能做什么；绝不做清单决定产品是什么。

没有非目标的产品，会在第一波需求涌入时失去形状。

门禁四｜变更流程就绪

|-----------------|---------------------------------------------|
| 项 | 内容 |
| 检查什么​ | 需求基线已冻结，CCB 四级变更路径明确，变更入口已配置 |
| 合格标准​ | 基线三件套（P0清单／验收标准／非目标）冻结；三条漏需通道各有入口动作（回扣 P24） |
| 不合格怎么办​ | 未冻结就进设计阶段 → 需求边做边改，设计返工 |

三条漏需通道的封堵检查：

|------------|---------------------|
| 通道 | 入口动作 |
| 老板随口一句 | 进 ADR 决策日志​ |
| 大客户一条消息 | 进需求池评审​ |
| 团队「顺手做了」 | 事后补基线变更单​ |

没有冻结窗口的项目不是敏捷，是漂流。

---

三、门禁判读：四门怎么算过

|--------------------|------------|-------------------------------|
| 结果 | 判读 | 处置 |
| 四门全绿​ | 需求合格 | 放行，进设计阶段 |
| 一门黄​ | 有瑕疵但可控 | 带条件放行------限期补正，指定责任人 |
| 两门黄 或 一门红​ | 风险显著 | 退回补做，重新评审 |
| 两门及以上红​ | 需求不成立 | 暂停立项，回到证据采集 |

一条铁律：

****红灯需求不得带病过门。****​ 今天放过去的红，明天会以十倍返工还回来。

门禁的经济学（回扣 P19）：

六场评审会留下的 23 条争议，否决 11 条。若全部执行，事后估算将多烧 47 万元与 5 个月工期 ------超过全年硬件利润的三分之一。

门禁的收益，在半年后的返工账单上才看得见。

---

四、需求篇总装：五件套 ＋ 立项输入包 ＋ 门禁结论

到这里，需求阶段完整闭环。总装清单如下：

【需求五件套】（P13/P19-P20）

① 画像卡（9张）

② 证据台账（214条）

③ PRD（6份，含非目标）

④ 优先级矩阵（P0-P2）

⑤ 验收标准（每条P0配可测试数字）

【立项输入包】（P16/P26）

⑥ 商业计划书（投入产出三栏表）

⑦ 可行性 Go/No-Go

⑧ 项目 Charter（含退出标准）

【门禁结论】（本页）

⑨ 证据链健康表（绿/黄/红）

⑩ 门禁检查表（四门打勾）

⑪ 变更台账与基线版本号

装配顺序（顺序错了，就是在不知道为谁做的时候先决定做什么）：

画像卡（谁）→ 证据台账（为什么）→ PRD（做什么）

→ 优先级矩阵 + 验收标准（先做什么、做到什么算完）

→ 立项输入包（值不值、能不能、谁来做）

→ 门禁检查（能不能放行）

总装后的最后一道动作（回扣 P19/P20）：

把全套文档交给设计阶段的负责人，请他提三个问题。

• 问不出三个问题 → 需求已足够扎实；
• 问得出 → 还有暗坑。

---

五、交接设计篇：需求篇的出口，是设计篇的入口

需求篇交付的不是文档，是三个确定性：

|-----------------|--------------------------------|
| 确定性 | 交给设计篇什么 |
| 做对的事​ | 真需求、非目标、验收标准------设计不必再猜「该不该做」 |
| 为谁做​ | 画像卡、决策链、时刻表------设计知道「为谁设计」 |
| 做到什么算完​ | SMART 验收标准------设计知道「什么算合格」 |

需求篇解决「做对的事」，设计篇解决「把事做对的样子」。

需求阶段的债，利息全部记在设计阶段------所以门禁必须严，严在设计之前，而不是返工之后。

---

六、自检：你的需求过几道门

|--------------|--------------------|------------------|
| 门 | 自检问题 | 不过的信号 |
| 原则一​ | 每条 P0 有独立可验证的数据源吗？ | 依据是「领导说」「竞品有」 |
| 原则二​ | 评审会上有人挑战过吗？反对记录了吗？ | 全票通过，纪要无反对意见 |
| 门一​ | 证据链健康表有红吗？ | 抽一条 P0，三秒点不开原始证据 |
| 门二​ | 换个人能写出一样的测试用例吗？ | 验收标准只有形容词 |
| 门三​ | 绝不做清单有几条？ | 空白或「暂无」 |
| 门四​ | 基线冻结了吗？漏需通道有入口吗？ | 还在随时加需求 |

判读：

• 六项全过 → 放行，进设计阶段；
• 四项以下 → 退回，需求还没写完。

---

七、金句收尾

把需求文档写完的那天，不是需求的结束，是怀疑的开始。

下面按 第3篇 · 第15章 · 15.1节 ​ 归位。这是设计篇的开篇页 ------需求篇（P13---P28）解决了「做对的事」，从本页起进入设计篇，第一步不是画图，而是先用最小成本验证「这事到底能不能成」。

先说这一页的处理 ：①raw 里约 60% 是前面页面的回顾 ------立项五步循环（→P16）、需求规格十章（→P20）、变更CCB（→P24）、Go/No-Go评审会（→P16/P19），这些我压缩为「回链速查」，不重复展开；②****「实战工作坊：评估一个智能推荐系统」（电商平台推荐系统）**** 是另一门课的内容，与六款硬件贯穿案例无关，删除；③东莞工业AI装备亏损1200万案例 是硬件 POC 造假的血泪教训，保留但压缩为案例胶囊；④真正属于本页的新内容------方案评估金三角、灰犀牛/黑天鹅、POC定义与纪律、五阶段闭环------完整保留并重构。

---