企业FDE架构方法论到实战指南从想法到商业变现：需求·设计·技术·测试·运维·交付·变现(七个阶段为经线、道法术器势为纬线、《原则》为操作系统、AI 为时代变量)@小红书&抖音 AI马教授 职场启航宝
第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）
《企业FDE架构师方法论到实战指南》以需求、设计、技术、测试、运维、交付、商业七大阶段为核心经线，以道法术器势为底层纬线，锚定《原则》、《价值》《底层逻辑》、《批判性思维》、《6个盒子》、《思辨与立场》等经典思维框架为组织操作系统，以AI为时代核心变量，最终为25类企业组织提供可落地的全链路赋能。
《企业FDE架构师方法论到实战指南》串联需求、设计、技术、测试、运维、交付、商业七大落地阶段，铺展道法术器势五层认知维度，以《原则》《价值》等六大思维体系为底层操作系统，借力AI时代变量，为25类企业组织输出体系化赋能方案。
第3篇 设计篇｜把事情做对的样子
篇定位：需求解决「做对的事」，设计解决「做对的样子」。
篇任务：POC验证可行性 → 产品定义 → 平台化 → AI产品专论 → 设计评审。
第15章 POC与立项决策：最小成本试错
章眼：在花大钱之前，先花小钱把最危险的那条假设打死或证实。
15.1 POC立项：先用最小成本验证可行性（P29）
【开头钩子】
POC不是缩小版项目，是对「最危险假设」的一次实验。
一个常见误解：把 POC 当成「先做个小版本试试」。
缩小版项目 = 把完整功能按比例缩小，做完还是不知道风险在哪；
POC 实验 = 只盯最危险的那一条假设，用最脏的手、最省的钱，在真实条件下把它打死或证实。
|
对比 |
缩小版项目 |
POC 实验 |
|
目标 |
做出一个能演示的东西 |
证伪或证实一条最危险假设 |
|
做完知道什么 |
能做出来 |
这个风险到底成不成立 |
|
失败时 |
不知道哪错了 |
明确知道「死因」，止损或转向 |
|
投入 |
数月、整团队 |
2-4周、3-5人 |
POC 的产出不是产品，是一个结论：Go 还是 No-Go。
一、方案评估金三角：能做、好做、值得做
在启动 POC 之前，先对方案本身做一次评估。管理者的核心职责不是判断技术「酷不酷」，而是完成一场商业化的战前推演。
评估的本质，是在「能做」（可行性）、「好做」（实施成本）、「值得做」（商业价值与风险）构成的金三角中，寻找唯一的最优平衡点。
三个顶点，回答三个问题：
|
顶点 |
核心问题 |
通俗比喻（探险寻宝） |
|
可行性·能做 |
这事能不能做？ |
「路线能走通吗？」——地图是否清晰？队伍有没有装备与经验？ |
|
投入产出·值得做 |
这事值不值得做？ |
「要花多少粮食和金币？」——宝藏价值是否远超投入？ |
|
风险评估·敢做 |
这事敢不敢做？ |
「路上有什么危险？」——有无撤退方案？ |
评估方案，不是问「能不能做」，而是问「值不值得，以多大代价，冒多大风险去做」。
顶点一｜可行性：技术是「银弹」还是「陷阱」
可行性必须冷酷地从三个维度审视：
|
维度 |
核心问题 |
通俗判断 |
|
① 技术成熟度 |
这项技术是久经沙场的「制式装备」，还是实验室里的「原型武器」？ |
是修高速公路的「盾构机」（成熟），还是仍需探路的「勘探新设备」？ |
|
② 团队能力匹配 |
团队是「驾轻就熟」还是「从头学起」？ |
是让川菜团队研发新菜式（已有技能创新），还是立刻做出顶级法餐（全新领域）？ |
|
③ 外部依赖 |
方案的命脉是否掌握在不可控的外部力量手中？ |
核心生产线只从一家随时可能断供的独家供应商采购——依赖本身就是风险 |
可行性评估，就是用现实的探针刺破幻想的泡沫，识别那些会让项目半途而废的「隐形悬崖」。
顶点二｜投入产出：拆解「人、财、时」的隐形账单
最致命的错误：只看到「开发价格标签」，忽视全生命周期总拥有成本（TCO）。
|
成本层 |
内容 |
买车比喻 |
|
① 一次性研发成本 |
设计、编码、测试的「人月」投入 |
裸车价 |
|
② 持续运维成本 |
云资源、带宽、API调用、安全合规年费、7×24运维人力 |
油费电费 |
|
③ 周期升级维护 |
适配新系统、扩容、打补丁、重构技术债 |
保养、保险、维修与贬值 |
|
④ 机会成本 |
把核心团队投入此方案，就放弃了其他可能更有价值的项目 |
「买了这辆就不能买那辆」 |
忽略长期运维成本的技术方案，就像只付了首付的房——惊喜还在后面。
贯穿案例的 TCO 示范：
|
成本层 |
六款产品 |
|
研发 |
5人团队，12个月 |
|
持续运维 |
单台云端 ¥0.28/天（ASR＋TTS＋LLM），折合每月约 ¥8.4 |
|
硬件 |
BOM ¥124—¥130 |
|
机会成本 |
不扩张团队，靠 47条ADR／214张流程卡／23个共用组件复用 |
顶点三｜风险评估：识别「灰犀牛」与「黑天鹅」
风险评估的目标不是制造恐慌，而是把「未知的未知」转化为「已知的未知」，并为最致命的威胁准备应对剧本。
|
风险类型 |
特征 |
例子 |
应对策略 |
|
灰犀牛 |
概率高、影响大、显而易见，却因行动迟缓被忽视 |
团队从未用过的新技术、明显紧张的工期、已知性能瓶颈 |
提前预警、主动设计、分配资源专项解决 |
|
黑天鹅 |
概率极低，但一旦发生具有颠覆性、灾难性 |
核心开源项目突然停维护、云服务商区域重大故障、罕见漏洞组合 |
设计系统韧性、灾难恢复预案、确保快速回退 |
两个必追问：
「最可能出问题的三点（灰犀牛）是什么？万一发生最坏结果是什么？我们有什么预案？」
「哪些事一旦发生会是毁灭性的（黑天鹅）？系统能否隔离？能否快速回退到安全状态？」
未经验证的技术是最大的「灰犀牛」放大器；清晰的回滚方案是最好的「黑天鹅」减压阀。
掌握风险评估，意味着不仅为「成功」设计，更为「可控的失败」做好准备。
二、POC 只验证「最危险的一条假设」
金三角评估跑完，会暴露出一个最关键的问题——到底哪一条假设最可能让整个项目崩盘？
找出来，POC 就只验证它。
最危险假设的三个特征：
|
特征 |
说明 |
|
① 崩盘性 |
它不成立，整个项目就没有意义 |
|
② 不确定性最高 |
团队对它最没把握，「应该可以吧」 |
|
③ 验证最便宜 |
能用小成本、短时间测出来 |
六款产品的最危险假设：
|
产品 |
最危险假设 |
POC 怎么验 |
|
陪伴熊 |
方言（粤/川）在真实家庭噪音下的唤醒与识别率能否达标 |
真实老人家庭环境、真实方言录音实测 |
|
记忆熊 |
家属是否愿意为「情感付费」买单（C级→需验证） |
100台高客单预售 |
|
情绪球 |
家长是否为「无屏+隐私」卖点付费；儿童是否愿对一个球倾诉 |
Phase4 与拓境同期小步试水 |
|
拓境 |
会议环境下的转写准确率 & 会后5秒推送能否成立 |
真实会议（含开放工位噪声）实测 |
POC 不能「什么都验一点」——摊薄到五个假设上的 POC，等于一个都没验。
只盯最危险那一条：它死了，项目就该死（止损也是产出）；它活了，其余风险才值得继续投入。
三、预算纪律：小成本起步——¥3575 的启示
POC 的预算纪律，贯穿项目给了最极端的示范：
启动期首月，全部资金约 ¥3575。
钱怎么花（只买证据，不买产能）：
|
花法 |
目的 |
|
立创下单开发板与麦克风 |
打通硬件链路 |
|
买毛绒公模 |
验证形态与手感 |
|
跑通离线唤醒词 |
验证最核心交互 |
|
注册小红书账号 |
建立需求信号管道 |
|
开通云端语音服务试用 |
验证链路可行性 |
POC 三不原则：
|
不 |
内容 |
|
不追求好看 |
面包板飞线、公模毛绒壳、手机热点配网——都可以 |
|
不追求完整 |
只跑通「最危险假设」那一条链路 |
|
不提前量产 |
先有能演示的东西 → 再收定金 → 最后才批量生产 |
唯一不能妥协的是「真实」——在真实噪音、真实网络、真实用户手里验证。
POC 团队配置：
|
项 |
配置 |
|
时长 |
2-4周（时间盒，不许无限延长） |
|
人数 |
3-5人（算法/云端1人、固件工程1人、产品/业务1人） |
|
形态 |
面包板、公模壳、手机热点——越粗糙越好 |
四、验收前置：POC 成功标准先写下来
POC 的第一条纪律：成功标准必须在开始之前写死。
事后改口的 POC，等于没做。
POC 三件套（入口／出口／不过）
|
项 |
内容 |
|
入口 |
一个写清楚的痛点场景 ＋ 3-5人小队 ＋ 不超过4周的时间盒 |
|
出口 |
基线指标达预设阈值 ＋ 真实用户 ≥5人上手 |
|
不过 |
停止或换方案——禁止「再给两周试试」式无限延期 |
交付物四样（以陪伴熊为例）
|
交付物 |
内容 |
|
① 问题定义书 |
谁、什么场景、什么指标算成功 |
|
② 数据集样本 |
真实方言录音、真实老人家庭 Wi-Fi 环境——不是办公室安静环境 |
|
③ 基线指标 |
唤醒率、ASR识别率、端到端响应时延的实测值 |
|
④ Go/No-Go 报告 |
结论与依据 |
基线指标示例（可机检）
|
指标 |
阈值 |
测量方式 |
|
唤醒率 |
≥90% |
真实家庭环境，100次实测 |
|
ASR 识别率（粤/川/普） |
≥90% |
各50句标准语料＋20句噪声语料 |
|
端到端响应 |
≤3秒 |
100次实测计时 |
|
老人独立配网成功率 |
≥60%（远程协助后100%） |
20台冷启动实测 |
指标先于验证存在——验证完成后的核对只是「核对」，不是「协商」。（回扣 P20 验收标准纪律）
五、POC 第一死法：造假式验证
POC 最常见的死法，不是技术不行，是演示造假：
人工筛选干净数据、最优场景、完美工况做演示，刻意规避背景噪音、方言口音、弱网断连等真实复杂情况——POC 通过率虚假拉高，给老板和合作方制造「技术成熟、马上落地」的假象。
案例胶囊：东莞某大型工业 AI 智能装备企业（工业设备故障巡检机器人），合同总额800万，配套研发/开模/算力/落地投入超400万，整体盘子超1200万，是企业的年度翻身项目。死因埋在 POC：演示用的是精心准备的样本，POC 通过率虚高；等验收现场换真实工况（粉尘、暗光、遮挡、设备干扰），系统立刻崩盘，最终千万项目全额亏损。
FDE 的反造假纪律：
POC 演示必须当场「换数据」——
观众可以随便说一句没排练过的话、随便找一个没测过的 Wi-Fi 环境，系统照样要工作。
经得起临时起意的考验，才算 POC 通过。
演示台上完美、现场一跑崩盘——这是硬件 AI 项目最贵的死法，而死因在 POC 阶段就埋下了。
六、五阶段闭环：POC → EVT → DVT → PVT → MP
POC 只是入口。硬件 AI 项目有严格的五阶段递进逻辑，每阶段验证不同性质的问题：
|
阶段 |
验证什么 |
核心问题 |
|
POC |
可行性 |
这事在真实条件下能成吗？ |
|
EVT |
工程性 |
能做成可工程化的东西吗？ |
|
DVT |
设计稳定性 |
设计稳定吗？能过认证吗？ |
|
PVT |
量产适配性 |
能批量生产吗？良率与供应链撑得住吗？ |
|
MP |
商业化交付性 |
能持续交付、变现、复用吗？ |
每阶段都有四件套：
准入标准 → 交付标准 → 验收标准 → 终止标准
五阶段断层的五大必死乱象（人工统筹管理的通病）：
|
# |
乱象 |
|
① |
POC 造假式验证——干净数据、完美工况，通过率虚高 |
|
② |
阶段无硬性准入门槛——BUG未清零、指标未达标就赶进度进下一阶段 |
|
③ |
阶段衔接断层——POC/工程/量产团队信息割裂，上阶段的坑下阶段全额重踩 |
|
④ |
盲目跳过关键阶段——为省时间直接 POC→PVT，最终批量翻车 |
|
⑤ |
商业化无迭代——量产上线后无优化、无适配，产品快速老化 |
87% 的工业 AI 项目死在「阶段断层」。
人工统筹的终极恶果：前期看似极速推进、中期隐患全面爆发、后期批量崩盘赔付——省小钱亏大钱。
通过才进 EVT，不通过就死——止损也是产出。
七、Go/No-Go 评审：三种结论，不许模棱两可
POC 出口的报告，进 Go/No-Go 评审会。评审会不是通气会，是决策仪式。
会议设置
|
项 |
内容 |
|
会前 |
材料提前48小时送达：立项一页纸、证据矩阵、方案对比表、EV打分表、失败清单、商业初稿 |
|
与会 |
四类角色：业务/用户代表（价值方）、技术负责人（可行性方）、财务或决策者（投入产出方）、FDE（端到端责任方） |
|
节奏 |
90分钟：前20分钟 FDE 陈述问题与证据 → 中40分钟围绕分歧辩论 → 后30分钟决策与记录 |
三种结论（不许「再看看」）
|
结论 |
适用条件 |
后续动作 |
|
Go |
证据充分、EV为正、能力圈覆盖 |
进入规格化与排期 |
|
Conditional（附条件通过） |
方向认可但关键假设未验证 |
限定时间盒做 Spike／假门测试后复议 |
|
No-Go |
痛点不真、付费不明、或二阶风险不可控 |
终止并归档，记录判断依据备查 |
决策结论只有三种——不允许模棱两可的「再看看」。
创意择优三纪律
|
纪律 |
内容 |
|
① |
C级证据不能单独通过 P0 需求——证据不足不是被否决，是被退回补验证 |
|
② |
反对意见必须显式记录——谁反对、理由是什么、什么条件下重新讨论 |
|
③ |
按领域可信度加权——合规听法务、技术可行性听做过同类项目的人；但任何人都必须给出理由 |
评审会三种常见病
|
病 |
表现 |
对症 |
|
会签式评审 |
材料会前没人看，会上轮流点头 |
会前48小时送达，每人书面写至少一个质疑——没有质疑者不具备投票资格 |
|
职级投票 |
谁官大听谁的 |
按领域可信度加权，强制记录反对意见 |
|
只许成功 |
谈风险被视为泼冷水 |
第一个议程永远是「失败清单汇报」，由 FDE 带头宣读这项目最可能怎么死 |
评审文化的本质是极度求真：我们是在拥抱现实，还是在用乐观叙事换立项通过？
会后产出：决策记录（选了哪个方案、为什么、预期指标、何时复盘、谁对结果负责）——这份记录是项目的出生证明，也是未来复盘的对照基线。
情绪球：C级证据为什么反而值得 POC
情绪球完整展示了 FDE 如何处理证据不足的需求：
|
判断 |
内容 |
|
困境 |
儿童情绪陪伴需求真实存在，但证据等级偏低——拿不出 A 级数据（REQ-02：C级不能支撑 P0 立项） |
|
转机 |
按 EV 思维：方向若成立价值巨大（家长屏幕焦虑是刚需、儿童无屏陪伴几乎无竞品），且验证成本极低 |
|
决策 |
不是否决，是 Conditional——以 POC 姿态试水，排在 Phase4（第6-8月）与拓境同期，用最小投入验证两个假设：① 家长是否为无屏卖点付费 ② 儿童是否愿对一个球倾诉 |
不把 C 级当 A 级豪赌，也不把不确定当不做的借口——而是用便宜的 POC、可逆的决策、严格的边界，把试错成本压到最小。
情绪球的隐私即卖点（POC 验证的核心）：
不存儿童原始语音（端侧ASR后即丢PCM）、家长端不可听原文、摘要90天自动删除、食品级硅胶+3C+防吞咽——最严格的数据克制，反过来成为小红书母婴号「不给手机也能倾诉」的核心传播点。
定价 ¥459，睡前故事包 ¥15/月。
八、本页回链速查（前面已覆盖的内容）
raw 中以下内容已在需求篇完整展开，本页不重复，仅作回链：
|
raw 内容 |
归位 |
|
立项五步循环（定义问题→证据复盘→方案创意→择优决策→执行复盘） |
P16（8.2节） |
|
六款产品立项结论表（核心证据/EV判断/结论与节奏） |
P22-P23（11.1/11.2节） ＋ P23 第六部分总检表 |
|
需求规格说明书十章 |
P20（9.3节） 第三部分 |
|
变更管理 CCB 与二阶影响链 |
P24（12.1节） |
|
Go/No-Go 评审会详细开法 |
P16 立项会 ＋ P19 评审会 |
|
PM-08 可行性分析报告·Go/No-Go 模型卡（芒格机会成本） |
核心思想已吸收进第一部分金三角「机会成本」 |
九、自检：你的 POC 站得住吗
|
自检问题 |
不合格信号 |
|
① 最危险假设找出来了吗？ |
POC 摊到五个假设上，一个都没验透 |
|
② 成功标准提前写死了吗？ |
边做边改指标，事后找理由 |
|
③ 用的是真实数据/真实环境吗？ |
办公室安静环境、干净样本、排练过的话术 |
|
④ 敢当场「换数据」吗？ |
只敢跑准备好的演示流程 |
|
⑤ 时间盒锁了吗？ |
「再给两周试试」——无限延期 |
|
⑥ 不过就止损吗？ |
明知不成立还硬推，怕沉没成本 |
|
⑦ 结论是三种之一吗？ |
出现「再看看」「原则上同意」 |
判读：七项全过 → POC 有效，可进 EVT；四项以下 → 你在做一个漂亮的演示，不是一次实验。
十、金句收尾
POC不是缩小版项目，是对「最危险假设」的一次实验——经得起临时起意的考验，才算通过。
下面按 第3篇 · 第15章 · 15.2节 归位。
先定位本页与 P29 的关系：P29（15.1）讲 POC 只验「最危险假设」；本页（15.2）讲——POC 验完之后、设计开工之前，先把全项目的 P0 需求总表建起来。POC 是点上的突破，P0 总表是面上的清单：POC 验的那条最危险假设，就是 P0 总表里风险最高的那一行。
再处理三件事：①raw 的核心内容是附录 F 的 61 条 P0 清单，而本页标题是「总表怎么建」（方法论），所以主文讲建表方法，61 条清单归位附录 F；②F.0 中的「第7章」「第26-31章」是旧版章节号，已按本书目录校正；③数量存在矛盾（详见文末），需定稿前核对；④金句用的是达利欧那句，已在 P14／P15／P28 反复出现三次，建议替换，我给出备选。
15.2 P0需求清单：全项目的需求总表怎么建（P30）
【开头钩子】
需求散在聊天记录里，等于没有需求。
需求阶段最隐蔽的浪费，不是需求错了，是需求找不着了：
|
散落处 |
后果 |
|
微信群里的一句「这个也要做」 |
没人认领，上线前才发现漏了 |
|
评审纪要里的一段讨论 |
结论被遗忘，重复讨论三次 |
|
某个人的脑子里 |
他一休假，全组停工 |
没有进总表的需求，就没有存在过。
P0 总表要解决的就是这件事：把散落各处的口头需求，收敛成一张可追溯、可排期、可验收的总表。
一、为什么需要 P0 总表：需求散落的三种死法
|
死法 |
表现 |
代价 |
|
① 口头立项 |
会上口头定了，没进表 |
无人认领，上线前爆雷 |
|
② 重复返工 |
同一个需求在两个模块各做一遍 |
双倍成本，接口对不上 |
|
③ 优先级漂移 |
谁催得急就先做谁 |
真正的 P0 被挤到最后一刻 |
总表的三重价值：
对账——任何一条 P0 都能追到证据、追到人、追到验收标准；
排期——不在表上的需求不排期，从源头堵住「顺便再加一个」；
交接——新人接手、跨模块协同、阶段评审，都只看这一张表。
二、总表七字段：少一个字段，这条需求就是悬空的
|
字段 |
内容 |
缺了会怎样 |
|
① 编号 |
唯一标识（如 PB-02） |
无法引用、无法追溯 |
|
② 模块 |
属于哪个功能模块／端（硬件／固件／云端／小程序） |
无法排期、无法分工 |
|
③ 原话回链 |
回链到证据编号（如 E-031） |
追不到用户嘴里那句话（回扣 P15） |
|
④ 优先级 |
P0／P1／P2（由 EV 排序定，回扣 P17） |
资源摊薄，什么都想做 |
|
⑤ 状态 |
待做／进行中／已交付／已验收／被砍 |
每周刷新时说不清进展 |
|
⑥ 责任人 |
谁对这条需求的结果负责 |
人人有责＝人人无责（回扣 P01） |
|
⑦ 验收标准 |
可机检的数字 ＋ 测量方法 |
做没做完说不清 |
七字段里最容易被省略的是③原话回链和⑥责任人——恰恰是这两项，决定了这条需求是真需求还是拍脑袋。
没有原话回链的需求是想象，没有责任人的需求是许愿。
三、P0 原则：砍到不能再砍，剩下的才是 must
P0 的定义：
不做完，这个产品就不成立。
三条铁律：
|
铁律 |
内容 |
|
① 缺失即不可用 |
砍掉它，产品核心场景直接瘫痪——这才是 P0 |
|
② 数量有上限 |
每款产品 P0 不超过 25 条（5人团队能扛住的量）；超了说明没砍到位 |
|
③ 有 P0 就有降级 |
明确哪些被降到 P1／P2，并写明降级理由（回扣 P19 否决清单） |
P0 判定三问（每条候选需求过一遍）：
|
问 |
内容 |
答「否」→ |
|
① 砍掉它，产品还能交付吗？ |
核心场景是否瘫痪 |
降 P1 |
|
② 它是被 EV 排进来的吗？ |
有量化排序还是靠嗓门（回扣 P17） |
降 P2 |
|
③ 它的验收标准可机检吗？ |
有场景、有数字、有口径 |
退回补标准 |
P0 不是「最重要的一批需求」，是「不做就死的那批需求」。
砍到不能再砍，剩下的才是 must——P0 清单的长度，就是团队的纪律刻度。
四、编号体系：证据编号 ≠ 需求编号
贯穿项目用两套编号，各司其职、互相对账：
|
编号 |
含义 |
示例 |
归属 |
|
E-xxx |
证据编号（Evidence）——用户原话、数据、书稿 |
E-031（方言闲聊原话） |
P15／P18／P19 |
|
产品前缀-xx |
P0 需求编号（Product P0） |
TB／WJ／PB／JY／QX |
本页总表 |
产品前缀对照：
|
前缀 |
产品 |
示例 |
|
TB |
思库熊（ThinkBear） |
TB-01 语音报模型号调用 |
|
WJ |
拓境（WuJing） |
WJ-02 会后5秒卡片推送 |
|
PB |
陪伴熊（PeiBan） |
PB-02 方言闲聊（粤/川/普） |
|
JY |
记忆熊（JiYi） |
JY-01 三证合规门禁 |
|
QX |
情绪球（QingXu） |
QX-02 共情反射 ≤40字 |
对账关系：
一条 P0 需求（如 PB-02）回链到一个或多个证据（E-031、E-032）；
没有 E 编号支撑的 P0，不该进总表。
五、每周刷新，评审会按表过
总表不是建完就锁进抽屉，它是活的：
|
节奏 |
动作 |
|
每周 |
刷新状态列（待做→进行中→已交付→已验收），同步风险 |
|
每次评审会 |
按表逐条过——不走表格的需求，不排期 |
|
每阶段门禁 |
对照验收标准逐条打勾（回扣 P28 四道门） |
两条硬纪律：
① 不走表格的需求，不排期。
② 状态不刷新的表格，等于过期地图。
评审会过表三问（每条 P0）：
- 证据还在吗？（E 编号是否仍有效——回扣 P15 时效链）
- 验收标准测了吗？（有实测数据还是「应该没问题」）
- 责任人还在岗吗？（换人是否重新对齐）
六、P0 总表与 POC 的衔接（回扣 P29）
POC 验的那条最危险假设，就是 P0 总表里风险最高的那一行。
|
产品 |
P0 总表里风险最高那条 |
POC 怎么验它 |
|
陪伴熊 |
PB-02 方言闲聊（粤/川/普 ≥90%） |
真实家庭噪音、真实方言录音实测 |
|
拓境 |
WJ-01 会议录音自动分段（误差≤500ms） |
真实会议含开放工位噪声实测 |
|
情绪球 |
QX-01 捏握唤醒（FSR>2N 100%触发） |
量产公差内实测（POC 阶段） |
POC 通过后：这条需求的状态从「待做」→「已验证」，其余 P0 才获得排期资格。
POC 不过：
触发 P0 总表的重新评估——不是砍掉这一条，而是回到 EV 排序，看整个产品的 P0 集合是否还成立（可能 No-Go，可能转向）。
七、P0 总表样例结构
以下为总表的标准形态（贯穿项目六款产品按此结构建表，完整 61 条清单见附录 F）：
|
编号 |
模块 |
需求条目 |
原话回链 |
优先级 |
状态 |
责任人 |
验收标准（可机检） |
|
TB-01 |
固件＋云端 |
语音报模型号调用 |
E-011 |
P0 |
已验收 |
XXX |
108个编号全部可点，识别率 ≥98% |
|
TB-06 |
小程序 |
家长周报（仅熟练度） |
E-014＋隐私红线 |
P0 |
已验收 |
XXX |
无任何对话内容字段 |
|
WJ-02 |
云端 |
会后5秒卡片推送 |
E-021 |
P0 |
已验收 |
XXX |
P95 ≤5秒 |
|
WJ-06 |
固件 |
录音提示音＋灯语 |
合规红线 |
P0 |
已验收 |
XXX |
在场者可感知，不可关闭 |
|
PB-01 |
小程序 |
四步配网＋远程协助 |
最高风险项 |
P0 |
已验收 |
XXX |
老人独立成功率 ≥60%，协助后 100% |
|
PB-02 |
云端 |
方言闲聊（粤/川/普） |
E-031 |
P0 |
已验收 |
XXX |
三方言识别准确率 ≥90% |
|
PB-07 |
固件 |
摸头2秒唤醒 |
误唤醒红线 |
P0 |
已验收 |
XXX |
误唤醒 ≤1次/天 |
|
JY-01 |
运营＋后台 |
三证合规门禁 |
合规红线 |
P0 |
已验收 |
XXX |
缺证拒绝率100% |
|
JY-05 |
后台 |
一键销毁＋凭证 |
承诺实体化 |
P0 |
已交付 |
XXX |
销毁可验证、凭证可出示 |
|
QX-02 |
云端 |
共情反射 ≤40字 |
禁说教红线 |
P0 |
已验收 |
XXX |
30组回归零说教句 |
注意三类特殊 P0 的证据来源不是用户原话，而是红线：
- 合规红线（WJ-06 提示音、JY-01 三证）
- 隐私红线（TB-06 家长周报、情绪球不存原文）
- 误唤醒／可靠性红线（PB-07）
这些来自 REQ-03 二阶后果与 REQ-06 事前验尸（回扣 P17），同样是 P0，但要标注来源为「红线」而非「E 编号」——两张来源表都要能查。
八、自检：你的 P0 总表合格吗
|
自检问题 |
不合格信号 |
|
① 七字段齐了吗？ |
缺原话回链或缺责任人 |
|
② 每条 P0 都有 E 编号或红线来源吗？ |
凭空冒出来的需求 |
|
③ P0 数量过 25 条了吗？ |
没砍到位，什么都想做 |
|
④ 验收标准可机检吗？ |
只有「稳定」「流畅」 |
|
⑤ 状态每周刷新了吗？ |
上次更新是三个月前 |
|
⑥ 评审会按表过了吗？ |
会上临时提需求、直接排期 |
|
⑦ POC 验的是表里最高风险那条吗？ |
POC 验的和 P0 表对不上 |
判读：七项全过 → 总表可用，设计可开工；四项以下 → 你的需求还在聊天记录里。
九、金句收尾
不走表格的需求，不排期——需求散在聊天记录里，等于没有需求。
下面按 第3篇 · 第16章 · 16.1节 归位。这是设计篇的准入门槛——设计开工之前，先回头清点：需求篇的六件实物，交齐了没有？
先厘清它与 P28 的分工（避免重复困惑）：
|
页 |
视角 |
问什么 |
|
P28 需求质量门禁 |
站在需求篇内部 |
需求质量合格吗？（四道门：证据链完整／验收标准可测／非目标明确／变更流程就绪） |
|
P31 需求交付物清点 |
站在设计篇入口 |
需求篇的实物产出交齐了吗？（六件套：画像卡／证据台账／PRD／评审记录／立项三件套／变更流程） |
一句话区分：P28 是质检，本页是点货。质检过了，还要看货齐不齐——不齐，设计照样开不了工。
第16章 设计准入：需求交付物清点
章眼：需求篇交不出六件实物，设计篇就不该开工。
16.1 需求阶段交付物清单：验收就查这六件（P31）
【开头钩子】
需求阶段收尾，检查这六件套齐不齐。
需求阶段最容易出现的错觉是「我们聊明白了」——聊明白不等于交得出来。
讨论是过程，交付物才是产出。
开完十场会、吵了二十次，如果最后拿不出这六件东西——需求阶段等于白干。
一、六件套逐件清点
每件给出：是什么 ／ 合格标准 ／ 常见问题 ／ 贯穿项目数据。
|
# |
交付物 |
是什么 |
合格标准 |
常见问题 |
贯穿数据 |
|
① |
用户画像卡 |
每类用户一张，有名有姓、有一天作息 |
痛点／场景／现有方案三格有原话佐证；付费意愿格访的是决策者本人 |
只有「25-45岁职场人」这类空壳画像 |
9张（六款产品，陪伴熊系2张） |
|
② |
需求证据链台账 |
原话 → 条目 → 产品语言，三级可追溯 |
每条 P0 挂 E 编号，三秒可点开原始证据 |
转述三手，追不到用户原话 |
214条证据条目 |
|
③ |
PRD |
需求规格说明书，含非目标段落 |
非目标至少有 3 条且写明理由；验收标准有场景＋数字＋口径 |
只有功能清单，非目标写「暂无」 |
6份，合计 17条非目标 |
|
④ |
评审记录＋否决清单 |
谁提了什么反对意见、最终如何裁决 |
反对意见记录在案；否决写清理由 |
全票通过、纪要无反对 |
六场 14.5小时，23条争议，否决 11条 |
|
⑤ |
立项三件套 |
商业计划书 ＋ 可行性 Go/No-Go ＋ 项目 Charter |
Charter 必须有退出标准；计划书含投入产出三栏表 |
只有商业计划书，无可行性、无 Charter |
六款各一套（P16／P26） |
|
⑥ |
变更流程与 CCB 名单 |
基线已冻结，四级变更路径明确，CCB 成员具名 |
三条漏需通道各有入口动作；CCB 名单到人 |
名单是部门不是人，出事无人签字 |
12个月 21次变更评审（通过9／挡回12） |
清点口诀：
画像卡定人，台账定据，PRD 定事，评审定界，立项定值，变更定序。
二、清点工具：需求阶段 12 条检查清单
六件套点完，再用这 12 条逐条打勾——任何一条打不了勾，必须给出书面豁免理由（豁免本身也要记录，因为「这次为什么没做」就是下次复盘的第一个问题）。
|
# |
检查项 |
|
① |
一句话定位能通过「电梯测试」吗（30秒讲清给谁、解决什么）？ |
|
② |
目标用户分层了吗？每层有画像卡吗？ |
|
③ |
每条 P0 需求挂证据链了吗（来源／等级／时效）？ |
|
④ |
双边／多边需求分别立卡了吗（使用者 ≠ 决策者）？ |
|
⑤ |
痛点有用户原话佐证吗（不是团队的转述）？ |
|
⑥ |
替代品扫描做了吗（不只是直接竞品）？ |
|
⑦ |
二阶后果推演了吗（被滥用会怎样）？ |
|
⑧ |
合规红线写进需求清单了吗（不是附录）？ |
|
⑨ |
非目标清单（Won't）写了吗？ |
|
⑩ |
验证 KPI 有阈值吗（可测可裁决）？ |
|
⑪ |
C级证据的需求控制在 POC 体量了吗？ |
|
⑫ |
一页纸立项的九个格子填满了吗？ |
这 12 条是需求篇的毕业考试——十二条全勾，才发「设计开工许可证」。
三、30天冲刺节拍：六件套是怎么产出的
六件套不是慢慢攒出来的——贯穿项目把它们压进三个 30 天冲刺（每冲刺聚焦两款产品），节奏固定到天：
|
日程 |
动作 |
|
D1-D3 |
开冲刺规划会（定访谈对象与画像假设） |
|
D4-D15 |
访谈期——每天两场、当晚清洗、隔日编号入库 |
|
D16-D18 |
中期盘点（画像卡初稿、证据台账过半） |
|
D19-D25 |
竞品扫描与替代品分析（每产品一张「替代品账单」） |
|
D26-D28 |
PRD 撰写与非目标攻防 |
|
D29 |
内评（设计负责人提问三个问题） |
|
D30 |
需求评审会 |
三个反直觉设计（这套节拍真正的价值）
|
# |
设计 |
为什么反直觉 |
防的是什么 |
|
① |
访谈期禁止讨论方案 |
工程师访谈到第五场就会忍不住「顺便问用户要不要这个功能」 |
把访谈污染成推销——全员会议只许聊「听到了什么」，不许聊「要做什么」 |
|
② |
竞品扫描放在访谈之后 |
通常做法是先扫竞品、再定访谈提纲 |
先看竞品会让访谈问题带上预设；先看用户，才能看到竞品没覆盖的空档 |
|
③ |
D29 内评要签名 |
内评常被当成走过场 |
设计负责人当场写下三个问题并签名；这三个问题会在 90天后的设计评审里被逐一核对——成为跨阶段的质量闭环 |
节拍表的本质，是用时间顺序防住认知顺序的污染：先听、再看、最后才判断。
四、六件套的长期价值：证据会过期，但先要标寿命
需求阶段的证据不会随上线而失效，但会衰减。第二年规划评审时，团队统计了 214 条证据的「仍然生效率」：
|
指标 |
数值 |
|
整体生效率 |
72% |
各产品分布差异很大：
|
产品 |
生效率 |
原因 |
|
思库熊 |
86%（最高） |
学习场景痛点随学期循环往复——「卡题没人讲思路」第二年依然是最高频时刻 |
|
亲情版 |
54%（最低） |
声音克隆体验一旦满足，「想听原来的声音」的强度自然衰减 |
衰减本身指向新需求：
亲情版证据的衰减，直接指向了第二年规划里「声音库资产化」的新方向。
投入再平衡：
|
生效率 |
第二年策略 |
|
高（思库熊、陪伴熊） |
减少基础访谈，增加节点性回访 |
|
低（亲情版、情绪球） |
保留季度访谈机制 |
由此沉淀出一条方法论：
需求阶段的产出物，除了 PRD，还应该有一张「证据有效期预估表」——给每条证据标注预期寿命，让第二年的调研预算花在真正会过期的需求上。
这是六件套之外，需求阶段留给未来的第七件遗产。
五、交接设计篇：六件套怎么交出去
清点完毕，最后一步是正式交接。交接不是把文件丢过去，是让设计负责人接得住：
|
交付物 |
交给设计什么 |
|
① 画像卡 |
设计知道为谁设计（含时刻表→推送与灯效节奏） |
|
② 证据台账 |
设计知道为什么这么定（防止设计阶段推翻重来） |
|
③ PRD |
设计知道做什么、不做什么 |
|
④ 评审记录 |
设计知道哪些争议已裁决（不重复吵架） |
|
⑤ 立项三件套 |
设计知道成本与商业边界（BOM／订阅／云成本约束） |
|
⑥ 变更流程 |
设计知道改动怎么走门 |
交接验收动作（回扣 P19／P20）：
把六件套交给设计负责人，请他提三个问题并签名。
- 问不出三个问题 → 需求已足够扎实；
- 问得出 → 还有暗坑，回炉补。
这三个问题会在 90 天后的设计评审上逐一核对——签了名就要兑现。
六、自检：你的六件套齐了吗
|
自检问题 |
不合格信号 |
|
① 六件实物都在吗？ |
只有 PRD，其余在聊天记录里 |
|
② 12条检查清单打勾几条？ |
六条以下，或全靠「口头说过了」 |
|
③ 访谈期讨论过方案吗？ |
边访谈边推销，证据被污染 |
|
④ 竞品扫描在访谈之后吗？ |
先看竞品，访谈问题带预设 |
|
⑤ 内评三个问题签名了吗？ |
内评走过场，无签名、无核对 |
|
⑥ 证据有效期标了吗？ |
明年重新调研，从零开始 |
判读：六项全过 → 发设计开工许可证；四项以下 → 设计先别开工，回需求篇补货。
需求交不齐，设计的每一张图都是在沙上建塔。
七、金句收尾
方法论终会过时，但「用数字说话」的习惯不会。
明白，是我归位错了——P32 应在第3篇设计篇。按交付顺序，它紧跟 P31，构成第16章的两节：
- 16.1（P31）：需求交付物清点——点货，查六件套齐不齐
- 16.2（P32）：需求篇金句合集——回望，设计动笔前把八句话想清楚
下面按 第3篇 · 第16章 · 16.2节 重出。
16.2 需求篇金句合集：发圈就靠这8句（P32）
【开头钩子】
需求做对，项目就成了一半。
与 16.1 的衔接：上一节点完了六件套（画像卡／证据台账／PRD／评审记录／立项三件套／变更流程）——那是在问「货齐了吗」；这一节问的是另一件事——「做需求时该守住的那几根弦，还记得吗」。
设计动笔之前，最后一次回望需求篇。
六件套是实物，这八句话是心法——实物不齐开不了工，心法不牢画出来的图会跑偏。
需求篇十六页（P13—P28），讲的其实是同一件事：在写第一行代码之前，把「真问题、真用户、真价值、真边界」说清楚。
这一节把它压成八句话——可直接发圈、可直接当评审开场、可直接贴工位。
一、八句速览
|
# |
金句 |
出处（需求篇） |
|
01 |
不懂业务的AI工程师，就是企业最昂贵的「技术债」制造机 |
P01 责任鸿沟（需求篇的认知前提） |
|
02 |
合格需求的三项检验：能设计、能测试、能对接 |
P14（7.2 三项检验） |
|
03 |
需求评审会的本质是花钱买「不做」的资格 |
P19（9.2 评审会）｜本页收尾 |
|
04 |
AI能告诉你用户「点击」了什么，只有人类能理解他们为何「叹息」 |
P18（9.1 挖掘） |
|
05 |
把需求文档写完的那天，不是需求的结束，是怀疑的开始 |
P14（需求十大坑）／P28（14.1 门禁） |
|
06 |
一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松 |
P13（7.1 立项铁律）／P16（8.2） |
|
07 |
技术能做到的事情，情感上不一定该做 |
P19（记忆熊双人对话） |
|
08 |
PRD的最高境界不是写了什么，是「非目标」那一段 |
P19（9.2 非目标） |
八句串起需求篇全貌：01 前提 → 02 及格线 → 06 立项铁律 → 04 挖掘 → 08 规格 → 03 评审 → 07 伦理 → 05 门禁。
二、逐句详解：在解决什么 · 发圈版 · 设计怎么用
01｜不懂业务的AI工程师，就是企业最昂贵的「技术债」制造机
|
项 |
内容 |
|
在解决什么 |
AI 项目的失败不在技术，在技术与业务之间的翻译断层——模型能跑 ≠ 业务能用。这正是 FDE 存在的理由（回扣 P01 责任鸿沟） |
|
发圈版 |
不懂业务的 AI 工程师，是企业最贵的技术债制造机。代码跑得通，业务用不上——中间隔着一个「能把业务翻译成技术」的人。AI 时代最稀缺的不是算法工程师，是懂业务的技术翻译官。 |
|
设计怎么用 |
画架构前先问：这个设计解决的业务指标是什么？答不出，就是第 01 句说的债 |
02｜合格需求的三项检验：能设计、能测试、能对接
|
项 |
内容 |
|
在解决什么 |
一条需求合不合格的及格线——画不出方案、测不出指标、接不住交付，三条缺一就不配进排期（回扣 P14） |
|
发圈版 |
一条需求合不合格，只看三件事：能设计、能测试、能对接。老板要做、竞品已有、技术很酷——这三条，一条都不构成需求成立的理由。 |
|
设计怎么用 |
设计的第一件事就是把需求「画成方案」——画不出来，说明需求还没过第 02 句的检验，退回 |
03｜需求评审会的本质是花钱买「不做」的资格
|
项 |
内容 |
|
在解决什么 |
评审会最大的产出不是通过，是砍掉——每次否决都在给未来工期存钱。六场评审会否决 11 条，省下 47 万与 5 个月（回扣 P19） |
|
发圈版 |
评审会最大的产出，不是通过了多少需求，是砍掉了多少需求。每次否决，都是对未来工期的一笔存款。 |
|
设计怎么用 |
设计评审同理——「不做」比「做」更值钱。差异化＝敢不做（回扣 P23 六款绝不做清单） |
04｜AI能告诉你用户「点击」了什么，只有人类能理解他们为何「叹息」
|
项 |
内容 |
|
在解决什么 |
定量与定性的分工——数据给行为，访谈给动机；AI 跑数据，人类听叹息（回扣 P18） |
|
发圈版 |
报表告诉你用户点了什么，访谈告诉你用户为什么叹息。AI 负责行为，人类负责动机——定性与定量不是替代关系，是显微镜与望远镜，两只眼睛都要睁着。 |
|
设计怎么用 |
交互设计的依据在时刻表与痛点原话（回扣 P18 时刻表→推送与灯效节奏），不在埋点均值 |
05｜把需求文档写完的那天，不是需求的结束，是怀疑的开始
|
项 |
内容 |
|
在解决什么 |
好需求不是写出来的，是被怀疑出来的；文档越厚，越容易藏着没想清楚的地方（回扣 P14 需求十大坑、P28 门禁） |
|
发圈版 |
需求文档写完那天，不是结束，是怀疑的开始。好需求不是写出来的，是被怀疑出来的——门禁的收益，在半年后的返工账单上才看得见。 |
|
设计怎么用 |
16.1 清点的六件套交到你手上时，请先怀疑，别照单全收——你提的三个问题，就是第 05 句的实践 |
06｜一个没有明确终点的AI项目，注定是一场烧钱的内耗马拉松
|
项 |
内容 |
|
在解决什么 |
立项的铁律——终点、验收、买单方，三问答不出就不立项（回扣 P13 立项铁律、P16 三件套） |
|
发圈版 |
没有明确终点的 AI 项目，注定是烧钱的内耗马拉松。立项前先答三问：终点是什么？验收标准是什么？谁买单？ 一问答不出，不立项。 |
|
设计怎么用 |
设计要有验收标准——每条设计决策都要能回答「做到什么算合格」（回扣 G.2 第 ⑨ 条：每条设计可测吗） |
07｜技术能做到的事情，情感上不一定该做
|
项 |
内容 |
|
在解决什么 |
技术与伦理的分界——记忆熊「双人对话」被拦下，正因为技术上可行、情感上越界（回扣 P19） |
|
发圈版 |
技术能做到的事，情感上不一定该做。需求评审会，就是替用户守住这条线的地方。 |
|
设计怎么用 |
设计阶段最容易「技术炫技」——遇到能做但不该做的，回到第 07 句（六款产品的绝不做清单，多半出自这里） |
08｜PRD的最高境界不是写了什么，是「非目标」那一段
|
项 |
内容 |
|
在解决什么 |
非目标清单是需求阶段最值钱的一段——它记录团队忍住没做什么，替未来的你挡住最多的诱惑（回扣 P19、P23） |
|
发圈版 |
PRD 的最高境界，不是你写了什么，是「非目标」那一段。功能清单决定产品能做什么，绝不做清单决定产品是什么——差异化，就是敢不做。 |
|
设计怎么用 |
你的设计方案里，「不做什么」写清楚了吗？没有非目标的设计，会在第一波需求涌入时失去形状 |
三、金句使用地图：什么场合甩哪一句
|
场合 |
用哪句 |
一句话用法 |
|
需求评审会开场 |
03 |
「今天最大的产出，不是通过多少，是砍掉多少——开始吧。」 |
|
老板又要加需求 |
03 ＋ 06 |
「先确认终点和验收（06）；这次要加的，走变更门还是换掉现有某条（03）？」 |
|
产品自查 PRD |
02 ＋ 05 ＋ 08 |
「过三项检验（02）→ 写完开始怀疑（05）→ 看非目标那一段够不够狠（08）。」 |
|
技术选型／方案争论 |
01 ＋ 07 |
「别让不懂业务的人拍板（01）；技术上能做，情感上该不该做（07）？」 |
|
团队内训（AI 与人分工） |
04 |
「AI 跑数据，人听叹息——别把访谈外包给模型。」 |
|
设计评审 / 交接会 |
05 ＋ 08 |
「拿到六件套先怀疑（05）；你的设计里，非目标写清楚了吗（08）？」 |
|
全篇开工动员 |
开头钩子 |
「需求做对，项目就成了一半。」 |
八句话，覆盖需求篇全部关键决策点——评审、立项、规格、挖掘、门禁、伦理，并各配一条「设计怎么用」。
四、自检：这八句你用得上几句
|
自检问题 |
用不上的信号 |
|
① 你砍过需求吗？ |
评审会全票通过 → 第 03 句没用上 |
|
② 你的 PRD／设计有非目标吗？ |
只有功能清单 → 第 08 句没用上 |
|
③ 你访过用户本人吗？ |
只看埋点、没听原话 → 第 04 句没用上 |
|
④ 你的项目有终点吗？ |
说不出「什么状态算做完」 → 第 06 句没用上 |
|
⑤ 你想过「技术可行但情感不该」吗？ |
只追技术可行 → 第 07 句没用上 |
|
⑥ 你怀疑过交到手上的需求吗？ |
照单全收开始画 → 第 05 句没用上 |
判读：
- 六项全中 → 需求篇方法论已内化，可以开工画第一张图；
- 三项以下 → 这八句值得贴到工位墙上，每天看一遍。
六件套点完（16.1）＋ 八句话想清（16.2）＝ 设计开工许可证正式签发。
五、金句收尾
需求评审会的本质是花钱买「不做」的资格——每次否决，都是对未来工期的存款。
第4篇 产品设计篇｜把对的样子定下来
定位：产品定义、平台化组件化、AI产品专论与评审门禁
设计阶段决定80%的成本。北极星是任务完成度而非功能数量：品牌、规格、定价、架构、评审，一次定清楚。
明白，按此前排定的顺序往下续——P33 承接 P31、P32（第16章设计准入），进入 第3篇设计篇 · 第17章（非"第二篇"）。
先理顺定位：
|
此前顺序 |
章节 |
内容 |
|
P29-P30 |
第15章 POC与立项决策 |
从需求到设计的过渡（POC验最危险假设、P0总表） |
|
P31-P32 |
第16章 设计准入 |
点货＋回望（六件套清点、需求篇八句） |
|
P33（本页） |
第17章 产品定义：把对的样子定下来 |
设计篇正文开篇——北极星、路线、三大浪费、四件产出物 |
第17章 产品定义：把对的样子定下来
章眼：设计阶段决定 80% 的成本；北极星是任务完成度，不是功能数量。
17.1 产品设计开篇：北极星与本篇路线（P33）
【开头钩子】
北极星只有一个：任务完成度，不是功能数量。
与前面两章的衔接：
- 第15章（P29-P30）解决了「这事能不能成」——POC 用最小成本验最危险假设，P0 总表把需求收成可排期的清单；
- 第16章（P31-P32）解决了「能不能开工」——六件套点货 ＋ 八句心法回望；
- 本章起，正式进入设计篇正文——回答「这产品到底长什么样」。
需求说清了「为谁、解决什么痛」，设计要回答的是：
长什么样、用什么做、花多少钱、怎么验收。
而贯穿这四问的北极星只有一颗：
任务完成度——用户在关键时刻，用你的产品把事做成了没有。
不是你堆了多少功能，是他做成了没有。
一、为什么设计阶段决定 80% 的成本
这是产品开发的经典铁律，在 AI 硬件项目上尤其残酷：
|
阶段 |
能改变多少成本 |
|
设计阶段（本篇） |
决定约 80% |
|
技术／工程阶段 |
只能优化剩下的 20% |
|
量产／交付阶段 |
基本只剩执行与补救 |
为什么：设计阶段一锤定音地锁死四件事——
|
锁定项 |
后果 |
|
① 架构与平台 |
决定复用率，决定后续每款 SKU 的边际成本 |
|
② BOM 与器件选型 |
决定单件成本，锁死定价空间与毛利 |
|
③ 内容与模型结构 |
决定 Prompt 库能否复用、OTA 能否升级 |
|
④ 合规与隐私架构 |
决定能否过认证、能否上市、能否规模复制 |
这四件事一旦在图纸上定死，后面再努力也只是「把已定的成本花得更省」，改不动结构。
设计阶段省下的每一分钱都是纯利；设计阶段定错的结构，后面十倍代价也补不回来。
二、北极星：任务完成度 vs 功能数量
这是设计篇最重要的一个判断：
|
维度 |
追功能数量 |
追任务完成度 |
|
问的问题 |
我们还能加什么？ |
用户那件事，做成了没有？ |
|
成功标准 |
功能清单打勾 |
关键时刻，任务闭环 |
|
典型动作 |
堆模型、加页面、上技能 |
砍功能、压延迟、练闭环 |
|
结局 |
功能很多，没人用透 |
功能克制，但人人用成 |
六款产品的「任务完成度」是什么：
|
产品 |
功能数量思维 |
任务完成度（北极星） |
|
思库熊 |
108 个模型全上了吗？ |
遇困 → 拿到模型 → 练一次完成，熟练度 +1 |
|
拓境 |
转写准不准、字多不多？ |
会后 5 秒，拿到破解公式＋待办 |
|
陪伴熊 |
有多少段戏曲？ |
老人用方言聊成了、药按时吃了 |
|
记忆熊 |
对话多自然？ |
家属在忌日，完成了一次思念的表达 |
|
情绪球 |
会多少共情话术？ |
孩子倾诉完，情绪被接住了 |
功能数量是投入，任务完成度是产出。
一个堆了 108 个模型却没有「练一次闭环」的产品，功能再多，任务完成度也是零。
北极星的操作含义：
设计评审时，每个功能都要回答——它提升了哪个任务的完成度？提升多少？怎么测？
答不出这三问的功能，不进设计。
三、本篇路线图：六站走完设计阶段
📌 第15、16章是「从需求到设计」的过渡与准入（POC／P0总表／六件套清点）；从本章起进入设计篇正文六站：
|
站 |
主题 |
对应章 |
回答什么 |
核心产出 |
|
① 方法论 |
设计原则与取舍 |
第17章（本页） |
设计遵循什么原则？ |
设计原则、取舍框架 |
|
② 产品定义三大件 |
品牌/IP ＋ 规格/BOM ＋ 文档 |
第18章 |
这产品到底长什么样？ |
规格书、BOM 初稿 |
|
③ 平台化：一次开发、六款复用 |
本篇最重要的设计思想 |
第19章 |
一套底座怎么打出六款？ |
平台架构与复用清单 |
|
④ 模型驱动的个人系统 |
AI 产品的内核设计 |
第20章 |
模型库怎么变成产品？ |
模型规格与触发词体系 |
|
⑤ 评审门禁 |
质量把关 |
第21章 |
设计合格吗？能进技术阶段吗？ |
评审记录、ADR 决策日志 |
|
⑥ 六款产品设计实战 |
收束全篇 |
第22章 |
同一套方法，六份设计？ |
六款产品的完整设计档案 |
六站走完，产出本篇四件交付物（见第五部分），交给技术篇开工。
四、设计阶段最大的浪费：三个坑
设计阶段最贵的不是做错，是做了不该做的、做得说不清、做完没法验。
坑一｜功能贪多：什么都想做，P0 失控
|
表现 |
后果 |
|
「这个也能加，顺便做了」 |
P0 清单膨胀，成本失控 |
|
每个功能都「有一点用」 |
资源摊薄，没有一个做透 |
|
用功能数量证明价值 |
功能很多，任务完成度为零 |
解药（回扣 P30）：
P0 原则：砍到不能再砍，剩下的才是 must。
每款产品 P0 不超过 25 条；判定三问：砍掉它产品还能交付吗？它是被 EV 排进来的吗？验收标准可机检吗？
坑二｜指标缺失：没有可机检的验收标准
|
表现 |
后果 |
|
「响应要快、识别要准」 |
做没做完说不清，验收变成吵架 |
|
验收标准只有形容词 |
无法写测试用例，质量门禁失效 |
|
指标事后协商 |
标准一降再降，产品被蚕食 |
解药（回扣 P20）：
验收标准三要素：有场景、有数字、有口径。
每条设计决策对应一个可机检指标；且验收标准先于实现冻结——开发完成后的验收只是「核对」，不是「协商」。
坑三｜不可测试：设计出来的东西没法验
|
表现 |
后果 |
|
交互只有「体验更好」 |
无法验证，好坏全凭感觉 |
|
模型效果没有回归集 |
改一次 Prompt，不知道有没有退步 |
|
合规条款没落到工程位置 |
出事时无法举证 |
解药（回扣 P28）：
每条设计可测吗？——这是设计评审的必答题。
交互要映射到按键／动作级；模型要有版本管理＋回归集；合规要落到具体工程位置（弹窗／加密／标注）。
三大浪费的本质：功能贪多＝范围失控，指标缺失＝标准失控，不可测试＝验证失控。
三者叠加，就是设计阶段 80% 成本的漏勺。
五、四件产出物：本篇交什么
设计篇收口时，必须交出四件实物——少一件，技术阶段不开工。
|
# |
产出物 |
是什么 |
合格标准 |
|
① |
规格书 |
设计规格说明书（PRD 的设计深化版） |
含交互（按键/动作级）、架构（软硬五层）、模型/Prompt 规格、降级方案；每条可测 |
|
② |
BOM 初稿 |
单件物料清单 |
到器件级；每颗差异件有场景证词；与定价、订阅、云成本四账联动 |
|
③ |
评审记录 |
设计评审会纪要＋否决清单 |
反对意见记录在案；否决写清理由；门禁逐条打勾 |
|
④ |
ADR 决策日志 |
架构决策记录 |
背景／选项／决定／后果四段齐全；可追溯、可复用 |
承接关系：
需求篇六件套（画像卡/证据台账/PRD/评审记录/立项三件套/变更流程）
↓ 承接
第15-16章（POC验证 / P0总表 / 六件套清点 / 八句回望）
↓ 开工
设计篇四件套（规格书 / BOM初稿 / 评审记录 / ADR决策日志）
↓ 交给
技术篇开工
ADR 决策日志是最容易被低估的产出物——它记录的是「当初为什么这么定」。
回扣 P02 系统杠杆三个安装位置，第一个就是决策进 ADR 库。今天写下的每一条 ADR，都是明天少吵的一次架。
六、本篇两条主线：平台化与模型驱动
设计篇有两条主线贯穿始终，也是本书设计思想中最重要的两条：
主线一｜平台化：一次开发、六款复用
|
层 |
复用内容 |
|
硬件层 |
ESP32-S3 共用平台、公模外壳、共用 PCBA |
|
内核层 |
238 套模型内核、五段式输出模板 |
|
云端层 |
ModelRouter、RAG 管道、TTS/ASR 服务 |
|
小程序层 |
配网、卡片推送、订阅、周报模块 |
差异只在外壳形态、Prompt／知识库与小程序模块的裁剪。
能用 OTA 解决的升级，不动硬件；能用订阅解决的增值，不动固件。
平台化的收益：六款产品共用一套底座，边际成本趋近于零——这是 5 人团队能打出六款产品的唯一原因。
主线二｜模型驱动：模型库反推产品形态
|
模型库 |
反推出的产品 |
|
108 套学习模型 |
思库熊（痛点金句＝触发词＝需求证据） |
|
130 计职场模型 |
拓境（六大类＝功能架构） |
|
人格/角色档案体系 |
陪伴熊亲情版、记忆熊（角色数据结构＋场景剧本） |
|
共情反射模型 |
情绪球（共情短句 ≤40 字、禁说教） |
模型库不是内容素材，是产品内核——痛点金句直接成为 trigger_keywords，模型分类直接成为功能架构。
这就是「模型驱动」：从模型库反推人群痛点和产品形态，而不是先做产品再找内容。
七、自检：设计开工前，这六问过了吗
|
自检问题 |
不合格信号 |
|
① 北极星是任务完成度吗？ |
汇报时只讲「做了多少个功能」 |
|
② P0 砍到 25 条以内了吗？ |
功能贪多，什么都想做 |
|
③ 每条设计有可机检指标吗？ |
验收标准只有「快、准、稳」 |
|
④ 四件产出物齐了吗？ |
只有规格书，无 BOM、无 ADR |
|
⑤ 平台复用点写清楚了吗？ |
每款产品从零开始，重复造轮子 |
|
⑥ 设计锁定成本算平了吗？ |
BOM／定价／订阅／云成本四账没联动 |
判读：六项全过 → 设计可以开工；四项以下 → 你还没定清楚「对的样子」。
八、金句收尾
以任务完成度而非功能数量为北极星。
明白，按你的篇章体系重新归位——P34 属于 第4篇 设计篇，章为 第18章 产品定义：把对的样子定下来。
据此，第4篇设计篇的开篇结构为：
- 第17章（P33）：产品设计篇开篇——北极星、本篇路线、三大浪费、四件产出物
- 第18章（P34，本页）：产品定义的方法论——从概念到方案的三个闸门
下面按此归位输出。
第18章 产品定义：把对的样子定下来
章眼：设计阶段决定 80% 的成本；方案评审不是比谁嗓门大，是比谁证据硬。
18.1 设计方法论：从概念到方案的三个闸门
一、设计阶段的输入与出口：四个动作
|
项 |
内容 |
|
输入 |
需求阶段产出——经真实用户验证的痛点清单（证据链已挂，回扣 P15／P18） |
|
任务 |
把痛点翻译成可直接交给工程团队的方案 |
|
要回答 |
品牌人格长什么样？硬件用什么形态？每次触摸触发什么反馈？软件分几层？成本与定价如何成立？交付时凭什么验收？ |
FDE 方法论把设计阶段全部工作收敛为四个动作，对应三道闸门：
|
动作 |
决定什么 |
对应闸门 |
|
择优 |
方向 |
闸门一 |
|
体验 |
用户怎么用 |
闸门二 |
|
可测 |
质量 |
闸门三 |
|
守底 |
生死（安全／隐私／成本） |
闸门三 |
一条硬规矩：任何进入评审的产品概念，必须以三个并列方案的形式出席，缺一不开会。
二、闸门一｜创意择优：为什么强制三个方案（DES-01）
三个方案不是形式主义，它们各自承担不同的认知功能：
|
方案 |
代表什么 |
|
方案 A |
最直觉的做法——团队的第一反应 |
|
方案 B |
最省钱、最快的做法——资源约束下的极限 |
|
方案 C |
最激进、最有想象力的做法——对用户场景的重新理解 |
案例：情绪球的三个方案
|
方案 |
内容 |
评价 |
|
A |
带屏幕的儿童平板 |
内容最全，但违背低刺激的初衷 |
|
B |
纯语音音箱 |
成本最低，但毫无触觉情感 |
|
C（采纳） |
无屏硅胶球——挤压唤醒、灯光呼吸 |
硬件最克制，却最贴合「抱着东西说话」的真实场景 |
三方案并排之后，「屏幕」与「陪伴」之间的矛盾才被肉眼看见——最终选 C 毫无悬念。
强制三方案的深层价值
保护非主流想法。
- 只有一个方案 → 评审会很容易滑向对提案人的人品投票；
- 有了三个方案 → 评审被迫对事不对人，在比较中识别真正的权衡。
创意择优的核心不是民主投票，而是让可信度加权的意见充分碰撞——
做过同类硬件的人、天天泡在用户场景里的人，判断权重理应更高；碰撞之后由负责人拍板，并当场记录决策理由。
未来复盘时，检验的不是「这个决策对不对」，而是——「当时依赖的假设是否成立」。
DES-01 创意择优：任何关键设计至少 3 个候选方案——最小化遗憾，而非最大化满意。
三、闸门二｜权衡取舍：设计权衡单怎么写（DES-02／DES-04）
当「快 vs 好」「灵活 vs 简单」等原则冲突时，预先写下本类场景的优先级规则，而非临场和稀泥。
设计权衡单（Trade-off Sheet）：一页纸写清五件事
|
# |
内容 |
|
① |
决策点是什么 |
|
② |
有哪几个可选方案 |
|
③ |
各方案在成本／体验／工期／风险四维的得分（1-5 分） |
|
④ |
被放弃方案的优点（必须显性记录） |
|
⑤ |
本次决策依赖的关键假设与验证方式 |
一个产品做下来，权衡单累计 十到二十张，合起来就是一份完整的决策档案——
新人读它能理解产品为什么长成今天这样；供应链谈判时它是成本取舍的依据；复盘时它是检验假设的对照表。
三个贯穿案例
|
决策点 |
方案 A |
方案 B |
方案 C（采纳） |
理由与待验证假设 |
|
情绪球唤醒方式 |
按键唤醒：成本最低 |
语音唤醒：与其他产品统一 |
挤压唤醒（FSR 压力传感） |
儿童情急之下说不出唤醒词，挤压是最原始的求助动作；假设误触率 <5%，EVT 阶段 50 小时儿童手持实测验证 |
|
拓境形态 |
桌面摆件：空间大、散热好 |
胸牌挂件：拾音近但突兀 |
磁吸方块贴显示器（6×6cm） |
会议场景要求「在场但不被注意」，贴显示器边缘既近场拾音又不干扰人际；假设双麦降噪达标 |
|
陪伴熊按键数 |
五个功能键 |
一个旋钮 |
零按键 ＋ 摸头唤醒 |
老人记不住按键语义，触摸是零学习成本通道；假设触摸响应 <200ms 且误触可接受 |
权衡单的两个忌讳
|
忌 |
说明 |
|
一忌只列选项不列假设 |
没有假设的决策无法复盘，成败都会变成一笔糊涂账 |
|
二忌让分数替代判断 |
分数是讨论的起点而非终点——硬件给 5 分而运营给 2 分的那个维度，才是评审会真正要花时间辩论的地方 |
DES-02 设计权衡：显式写下「我们放弃什么、换来什么」，如「放弃屏幕换取零学习成本」。
DES-04 角色—场景—任务：每个功能必须回答「谁、在什么场景、完成什么任务」三问，答不上来的功能砍掉（回扣 P18 三维表、P30 P0 判定）。
四、闸门三｜可测试性与非功能基线（DES-03／DES-05）
第三道闸门最容易被跳过，却是「守底」的闸门——可测决定质量，非功能基线决定生死。
DES-03 可测试性：需求即验收标准
要求很朴素：写下的每条设计，都要能变成一条可执行的验收标准。
|
❌ 不是一条设计 |
✅ 拆成可测试的三条 |
|
「思库熊遇困响应」 |
① 语音报「001号」后 2 秒内灯环变蓝； |
设计期写好验收，交付期就是抄作业。
目标不是「用户友好」，而是「用户无形」——好的交互是隐形的向导。
DES-05 非功能基线：三条底线先锁死
|
基线 |
内容 |
六款产品示例 |
|
安全 |
物理安全 ＋ 内容安全双底线 |
毛绒件无小零件；戏曲内容版权清单；儿童内容分级 |
|
隐私 |
最小采集 ＋ 明确留存期 |
陪伴熊对话摘要化；情绪球不存原文、90天删除；记忆熊素材授权门禁 |
|
成本 |
BOM ＋ 云端 ＋ 内容三本账 |
BOM ¥110-130/台；云端 ≤¥0.28/台/天；内容按 OTA 包摊销 |
安全不是功能，而是底线——一个不安全的产品，功能再强大也是零。
安全、隐私、成本三条底线，在设计期锁死，不许交付期讨价还价。
五、评审会怎么开：90分钟、五人、四段
|
项 |
规则 |
|
时长 |
90 分钟 |
|
人数 |
五人封顶：产品负责人主持 ＋ 硬件、固件与云端、内容与运营各一人 ＋ 至少一名真实目标用户代表 |
四段流程
|
段 |
时长 |
动作 |
|
① 方案陈述 |
每方案 8 分钟 |
只准讲场景与取舍，不准放渲染图煽情 |
|
② 红队质疑 |
— |
每个人必须提出至少一个「这方案会死在哪里」的问题 |
|
③ 可信度加权打分 |
— |
按四个维度打分，权重向做过同类事的人倾斜 |
|
④ 负责人拍板 |
— |
复述决策理由，全场确认无误解后散会 |
四维打分
|
维度 |
问什么 |
|
① 场景契合度 |
用户是不是真的在这样的场景里用？ |
|
② 可实现性 |
90 天内能不能做出可售版本？ |
|
③ 单位经济性 |
物料、云端、内容三本账是否成立？ |
|
④ 差异化 |
小红书上能不能用三句话讲清它和竞品的区别？ |
打分不是目的，目的是强迫每个评委把模糊的喜恶翻译成具体维度的论证。
任何一项低于 3 分的方案，无论总分多高都必须回炉。
三条评审纪律
|
# |
纪律 |
|
① |
所有意见必须落到纸面的设计权衡单上——口头表扬与口头反对都不算数 |
|
② |
被否决方案的优点必须显性记录在案——防止好想法在实施中遗失 |
|
③ |
决策依赖的关键假设必须写明验证方式与验证时点 |
纪律②的价值示例：
情绪球落选的平板方案（A方案）里，「家长端需要一个可视化入口」这个优点被保留下来，变成了家长小程序的树洞日报。
纪律③的价值示例：
「挤压唤醒误触率低于 5%」必须标注「EVT 阶段 50 小时儿童手持实测」——假设没人验证，决策就是赌博。
六、需求-设计-测试追溯矩阵
设计阶段出口物里，追溯矩阵最容易被跳过、又最不该跳过。
三列结构：
|
列 |
内容 |
|
① 需求条目 ID |
来自 P30 P0 总表 |
|
② 设计决策 ID |
来自设计权衡单／ADR |
|
③ 测试用例 ID |
可机检的验收动作 |
铁律：每条 P0 需求必须落到至少一个设计决策；每个设计决策必须落到至少一个测试用例。
贯穿项目数据：
|
指标 |
数值 |
|
覆盖 P0 需求 |
61 条（第一年） |
|
设计决策 |
148 个 |
|
测试用例 |
394 条 |
三列比例 1 : 2.4 : 6.5 本身就是健康度指标：
设计决策数远超需求数 → 说明设计有分解；测试用例数远超决策数 → 说明验证有密度。
两次立功：
|
场景 |
经过 |
|
① 事故一（唤醒失败） |
从故障现象反查矩阵，10 分钟定位到「唤醒模型升级」这个设计决策没有对应分区表兼容用例——缺口补上后，同类问题再未发生 |
|
② 砍功能（订阅改版下放周复盘） |
反查矩阵发现它挂着 6 条测试用例 ＋ 2 条 ADR——评估从「拍脑袋」变成「看清单」 |
矩阵的价值平时看不见，出事时是全队唯一知道「哪里连着哪里」的人。
七、一次一变量纪律
设计阶段最容易犯的错是「一次改一堆」——新外壳＋新交互＋新定价一起上，成了不知道为什么成，败了不知道为什么败。
纪律：任何一次设计变更只允许动一个主变量，其余条件冻结；变更必须有「预期 → 观察 → 裁决」三步。
|
案例 |
做法 |
结果 |
|
✅ 亲情版升级转化 |
只动「订阅解锁内容」一个变量（硬件、交互、价格全部不变） |
31% 的转化率干干净净归因于「声音克隆」这一个变量 |
|
❌ 拓境第一版详情页 |
同时改了主图、文案、价格锚点 |
转化率上升 2 个百分点——但没人说得清功劳属于谁，后续优化只能全部重测 |
这一次「profitable 的浪费」让团队把「一次一变量」写进了设计变更流程。
科学实验的纪律不是学术洁癖，是让每一次成功的经验都能被复用。
八、移交通道：设计文档的收口仪式
设计到技术（以及到内容、到工厂）的移交，是产品项目里事故率最高的通道。
收口仪式：
|
项 |
规则 |
|
时机 |
设计文档评审通过后 48 小时内 |
|
形式 |
一次 两小时移交会，由设计负责人组织 |
|
拆法 |
文档按「受众」拆成三个抽屉 |
|
抽屉 |
给谁 |
内容 |
|
① 规格抽屉 |
硬件工程师 |
引脚、结构、BOM |
|
② 接口抽屉 |
软件工程师 |
协议、数据表、状态机 |
|
③ 话术抽屉 |
内容与运营 |
模型卡、SOP、订阅规则 |
三个抽屉各自独立成册，共享同一个变更版本号。
验收动作：反向讲解
每个抽屉的接收方花 十分钟向设计负责人复述「我理解你要的是什么」，讲错的当场改文档。
听起来笨拙，实际拦下了大量「我以为你知道」的暗礁——
陪伴熊的「摸头唤醒」在移交会上被硬件方理解为「按键长按」，反向讲解 五分钟内暴露并修正；若到 DVT 才发现，代价是一个模具周期。
经济学：
|
项 |
数字 |
|
仪式成本 |
每次 2 小时，六款产品一年共 24 小时 |
|
对照潜在损失 |
模具返工四周（拓境改色事件）、联调周返工（协议理解偏差）、内容返工（话术风格不符） |
仪式感在这里不是形式主义，是用最低的成本把「默契」换成「共识」。
九、设计债的管理
技术债人人皆知，设计债却常常隐形——
为了赶交付，设计文档里写下「此处简化，二期完善」的那一刻，债就成立了。
设计债的利息形式：下游的困惑。
- 内容团队按简化版话术生产了三个月，才发现设计原意是双轨制；
- 工厂按简化版结构开模，改一处就要动两个模具。
三步管理：
|
步 |
内容 |
|
① 登记 |
每笔债进「设计债台账」——注明债主、利息承担方、偿还窗口 |
|
② 定价 |
偿还成本折算成工时与返工风险，超过 5 人日的债需要专项评审 |
|
③ 偿还 |
写进下个迭代里程碑；没有偿还窗口的债不允许登记——那不是债，是直接违规 |
贯穿项目数据：12 个月共登记 34 笔，偿还 29 笔，逾期 5 笔。
逾期名单里最贵的一笔：「亲情版多声源架构」——M7 为赶发布选了单声源简化，偿还时涉及固件、云端与小程序三层改造，折算 18 人日。
这笔债直接催生了第二年规划里「多声源」的排期前置。
设计债台账每周五随周报巡检一次——隐形的债才是最贵的债。
十、五模型思想源头（一行速查）
|
模型 |
思想源头 |
一句话 |
|
DES-01 创意择优 |
达利欧 Idea Meritocracy；芒格「权威须独立验证」 |
避免权威谬误——方案同台竞技，dissent 意见必须记录 |
|
DES-02 设计权衡 |
达利欧 Principle Conflicts；芒格决策树 |
结构化决策减少情绪干扰；一致体验建立长期信任 |
|
DES-03 可测试性 |
需求即验收标准 |
设计期写好验收，交付期就是抄作业 |
|
DES-04 角色—场景—任务 |
三问过滤 |
答不上「谁／什么场景／什么任务」的功能砍掉 |
|
DES-05 非功能基线 |
安全／隐私／成本三条底线 |
质量是长期速度的前提——底线在设计期锁死 |
芒格提醒「权威意见须独立验证，不可因职级而盲信」；张磊强调「质量是长期速度的前提，非对立面」——
对核心系统而言，决策质量 > 决策速度。
十一、自检：你的设计过几道门
|
门 |
自检问题 |
不过的信号 |
|
闸门一 |
关键决策有 3 个并列方案吗？ |
只有一个方案，评审会变人品投票 |
|
闸门二 |
设计权衡单写了「放弃什么、换来什么」吗？ |
只列选项不列假设，成败是糊涂账 |
|
闸门三 |
每条设计有可机检的验收标准吗？ |
只有「快、准、稳」 |
|
守底 |
安全／隐私／成本三条底线锁死了吗？ |
交付期还在讨价还价 |
|
追溯 |
P0 需求→设计决策→测试用例对得上吗？ |
出事时查不出「哪里连着哪里」 |
|
纪律 |
变更做到「一次一变量」了吗？ |
一次改一堆，成败无法归因 |
判读：六项全过 → 设计可以进评审；四项以下 → 你在赌运气，不是在做设计。
十二、金句收尾
技术选型不是技术问题，是商业问题——看你的产品定位、成本预算、性能需求，再决定用哪个方案。
下面按 第4篇 · 第18章 · 18.2节 归位。承接 P34（18.1 设计方法论：三个闸门），本节进入产品定义的落地三件套——把「对的样子」写成品牌、规格、定价三件可执行的东西。
先说明与 18.1 的关系：18.1 讲「怎么选方案」（三闸门、三方案、权衡单），本节讲「选定之后，怎么把它定义清楚」——品牌一句话、规格三张表、定价比公式。
再处理 raw 的重复：raw 中「六款 IP 逐一设定」与「品牌与 IP 设计」表重复、「硬件规格与交互映射」与「交互映射」表重复，已合并去重，取并集。
18.2 产品定义三件套：品牌、规格、定价（P35）
【开头钩子】
成本不是省出来的，是算出来的。
方案过了三道闸门（18.1），接下来要把「对的样子」落成三件可执行的东西：
|
件套 |
回答什么 |
核心产出 |
|
① 品牌 |
这产品在用户心里是什么？ |
一句话品牌 ＋ IP 人格 ＋ 三处一致 |
|
② 规格 |
它长什么样、怎么交互？ |
硬件规格／交互映射／BOM／内容清单三张表 |
|
③ 定价 |
它卖多少、钱从哪来？ |
BOM 三本账 ＋ 心理账户 ＋ 订阅分层 |
品牌一句话＝目标用户 ＋ 核心场景 ＋ 差异化。
规格三张表＝硬件规格、软件架构、内容清单。
定价公式＝BOM（芯片＋外围器件＋PCB＋散热＋电源）＋ 渠道与毛利。
一、品牌一句话：目标用户 ＋ 核心场景 ＋ 差异化
1. 语音人格即品牌（AI硬件的第一性）
在无屏或弱屏的 AI 硬件上——
品牌首先不是 Logo 与配色，而是声音的性格。
用户每天对设备说话、听设备回话，人格的语气、口头禅、回复长度、追问习惯，构成了品牌体验的绝大部分。
思库熊的品牌资产不只是那只戴眼镜的小熊，更是：
- 「库库」这个名字；
- 播报时「正在启动第 001 号模型」的仪式感；
- 每段讲解末尾那句「要不要现在练一次？」的固定追问。
这句话在数百万次对话里重复，就是品牌本身。
因此 IP 设计在 FDE 流程里是工程任务，而非美术任务：
人格设定必须落到系统 Prompt 的每一条规则里。
|
人格 |
规则（品牌宪法） |
|
熊小伴 |
用方言回复、孙辈语气、每次回复不超过 60 字、情绪低落时先共情再转移话题、绝不说我是 AI |
|
球球 |
只反射感受、不给建议、不说你应该、回复不超过 40 字 |
这些规则既是文案，也是品牌宪法——TTS 出口的每一句话都受它约束。
改一条 Prompt 规则，就是改品牌，必须走评审。
2. 命名规则三条
|
# |
规则 |
示例／理由 |
|
① |
两字叠音或拟人称谓优先 |
库库、小逻、球球、熊小伴——老人与儿童能一口叫出，天然带亲昵感 |
|
② |
唤醒词必须可离线训练、误唤醒低，避开日常高频词 |
「小逻小逻」双词叠加，把误唤醒压到会议室可用水平 |
|
③ |
人格名与产品名分离但同源 |
产品叫思库熊、人格叫库库；产品叫拓境、人格叫小逻——产品名面向商标与渠道，人格名面向对话与情感，产品线扩展才有空间 |
3. 刻印三处一致（信任工程的最低配置）
硬件本体的肚皮内标、外包装、小程序开屏页——三处文案必须逐字相同。
|
产品 |
统一文案 |
|
思库熊 |
思库熊｜108 思维模型库 |
|
拓境 |
拓境｜130 计生存模型库 |
|
陪伴熊 |
熊小伴｜银发 AI 陪伴 |
为什么重要：
用户在小红书上拍到的任何一个画面，都是一次免费广告；任何一处文案漂移，都会在评论区被放大成「这产品不正规」的怀疑。
真实事故拦截：陪伴熊首批包装印刷厂把「熊小伴」排成了「小伴熊」，包装与内标不一致——若非发货前的三处一致抽检，两千份包装将带着错字流向市场。
品牌资产的一致性不是美学洁癖，是信任工程的最低配置——连自己名字都印错的团队，用户凭什么相信它敢承诺「不在身边，也在身边」？
4. 六款 IP 逐一设定
|
产品 |
IP 形象 |
语音人格 |
唤醒词 |
宣传语（品牌一句话） |
|
思库熊 |
戴书本眼镜小熊，肚子半透明窗＝知识库发光 |
库库 |
「库库」／摸头 |
不止记忆，更要构建完整思维知识库 |
|
拓境助手 |
磁吸方块「小逻」，边框灯环 |
小逻 |
「小逻」 |
录音 5 秒出卡片，职场防坑 130 计 |
|
陪伴熊·基础 |
经典毛绒熊 |
熊小伴 |
「熊小伴」 |
乡音陪伴，戏曲不断 |
|
陪伴熊·亲情 |
同上＋亲情声音包 |
亲人原声 |
「熊小伴」 |
把熟悉的声音留在身边 |
|
记忆熊 |
深蓝毛绒熊 |
亲人人格 |
亲人习惯称呼 |
不是复活，是可对话的纪念 |
|
情绪球 |
硅胶球，无屏无灯带 |
球球 |
挤压唤醒（无唤醒词） |
不说话的树洞，只给妈妈的摘要 |
逐个展开：
|
人格 |
设定 |
|
库库（思库熊） |
戴书本眼镜的小熊，30cm 毛绒，肚子上一块半透明窗，内置 12 颗 WS2812B 灯珠——「肚子发光的知识库」是视觉锤。性格是温和而较真的学习教练：会追问、会布置 5-15 分钟 micro-task、会在同一模型练满 5 次后点亮热力图维度并标记「已内化」。面向初中生（基础 24 模型）、高中生（全模块）、大学生（AI 模块加权）三类用户 |
|
小逻（拓境） |
6×6cm 磁吸方块，六款里唯一非毛绒、非玩偶形态——因为它服务职场场景，必须像办公用品而非玩具。性格是冷静、嘴严、反应快的防坑参谋：会议中边框灯常亮待机，结束 5 秒内推送「命中模型：037 边界话术模型＋破解公式＋待办」；从不在会上出声打扰，只用灯色与会后卡片说话 |
|
熊小伴（陪伴熊基础版） |
定位「孙辈语气的陪伴者」——用老人方言说话、回复 ≤60 字、用药时间温和提醒一次、检测情绪低落先共情再转移、听到「听戏」就播放戏曲。灯环五色语义为它服务：蓝＝配网、白＝待机、暖黄＝共情、橙＝用药、紫＝子女留言。Slogan「不在身边，也在身边」 |
|
亲人人格（亲情版） |
不是新增角色，而是儿女或老伴的「声音分身」。子女录 10 句话克隆音色，配合角色档案——称呼、口头禅（「妈记得吃饭」）、说话风格（口语化、略唠叨）、记忆点（降压药饭后吃）。老人说「想听小强说话」，系统切换角色 Prompt 与 voice_id：熊还是那只熊，声音变成了儿子 |
|
记忆熊人格 |
「可对话的纪念档案」——由七题记忆问卷构建人格 Prompt。品牌纪律最严：宣传词「思念有声，回忆可触」，全渠道禁用「复活」「重生」，因为定位从第一天起就是纪念而非替代 |
|
球球（情绪球） |
六款里 IP 最轻：一颗食品级硅胶球，没有脸、没有屏幕、没有性别，性格只有「接住情绪」四个字——儿童陪伴产品最大的品牌诚意就是克制 |
二、规格三张表：硬件规格、软件架构、内容清单
表1｜硬件规格与交互映射表（传感—反馈语法）
交互映射设计的任务，是把每个传感器输入和每种反馈输出，编成一套「语法」——摸哪里、怎么摸、灯怎么亮、说什么话、小程序推什么，必须像语言一样有词性、有固定搭配，且全产品不许自相矛盾。
|
产品 |
主输入通道 |
主反馈通道 |
灯语关键词 |
|
思库熊 |
摸头唤醒 ＋ 语音报模型号／痛点 |
40mm 喇叭播报 ＋ 肚子 12 灯珠 |
蓝光启动、练习进度点亮 |
|
拓境 |
「小逻小逻」离线唤醒 ＋ 短按／长按 |
双麦录音 ＋ RGB 边框灯 ＋ 小程序卡片 |
常亮待机、命中轻闪 |
|
陪伴熊 |
摸头唤醒「熊小伴」＋ 语音 |
喇叭 ＋ 五色灯环 |
蓝配网／白待机／暖黄共情／橙用药／紫留言 |
|
情绪球 |
FSR 挤压唤醒（无唤醒词） |
灯环呼吸 ＋ ≤40 字短句 |
挤压即亮、呼吸引导 |
|
记忆熊／亲情版 |
摸头唤醒 ＋ 语音呼叫角色 |
克隆音色 TTS ＋ 灯环 |
暖黄为主、纪念日特别灯效 |
灯语立法三原则：
同一种颜色，在同一产品里永远只代表一件事。
|
产品 |
灯语语法 |
|
陪伴熊 |
五色严格对应老人最关心的五件事——配网、待机、有人共情、该吃药了、孩子留言了 |
|
思库熊 |
肚子 12 颗灯珠承担进度表达——点亮颗数与练习状态挂钩，让抽象的熟练度变成肉眼可见的光 |
|
拓境 |
RGB 边框会议中常亮、命中模型时轻闪——提醒而不打扰 |
|
情绪球 |
检测到害怕与焦虑时，灯环以约 6 秒周期明暗变化，邀请孩子跟着呼吸 |
输入通道的深层逻辑：
触摸与挤压是比语音更古老的交互通道，在特定场景下优先于语音——
儿童委屈时说不出完整句子，挤压就是求助；老人记不住唤醒词，摸头就能说话；职场人在会上不能出声，短按录音是唯一合规的交互。
|
场景 |
拾音规格 |
为什么 |
|
拓境 |
双 MEMS 麦阵列 |
会议室远场降噪与说话人分段，让「谁在甩锅、谁在抢功」在转写文本里有据可查 |
|
思库熊 |
单颗 INMP441 麦克风 ＋ 40mm 喇叭 |
书桌场景是近场、安静、一对一 |
规格从不追求堆料，只追求与场景严丝合缝。
标准交互映射条目（写进规格书，固件照表实现、测试照表验收）：
|
操作 |
硬件反应 |
软件逻辑 |
|
摸头／说唤醒词 |
灯环呼吸灯 ×2 |
WakeNet 唤醒 → 进入拾音 |
|
语音报模型号 |
灯环变蓝 |
ASR → ModelRouter 命中 → RAG → LLM |
|
练习完成 |
灯环绿色流水 ×1 圈 |
熟练度 +1，写入用户模型图谱 |
|
长按肚子 5 秒 |
灯环红色快闪 |
进入配网模式（小程序扫码） |
|
连续对话 20 分钟 |
灯环缓慢黄闪 |
休息提示（儿童模式强制休息 10 分钟） |
表2｜BOM 清单（统一平台，六款复用）
基准 BOM 明细（50 台批量、不含包装物流）：
|
器件 |
思库熊 |
拓境 |
单价(¥) |
备注 |
|
ESP32-S3-WROOM-1 |
1 |
1 |
18 |
16MB Flash |
|
MEMS 麦克风 |
1 |
2 |
3×n |
拓境双麦降噪 |
|
WS2812B 灯 |
12（肚子） |
4（边框） |
0.5×n |
状态反馈 |
|
40mm 喇叭＋功放 |
1 |
1 |
12 |
TTS 播报 |
|
锂电池 2000mAh |
1 |
1 |
15 |
USB-C 充电 |
|
毛绒／ABS 外壳 |
1 套 |
1 套 |
35／28 |
开模分摊 |
|
磁吸组件 |
— |
1 套 |
8 |
仅拓境 |
统一平台的价值在 BOM 上直接兑现：六款共用主板，仅外壳／麦克风数量／灯数不同。
BOM 总账：六款共用 ESP32-S3 平台，BOM 约 ¥110-130——
|
产品 |
BOM |
|
毛绒三熊（思库熊／陪伴熊／记忆熊） |
¥124-128 |
|
情绪球（硅胶壳） |
¥110 |
|
拓境（磁吸方块） |
¥130（双 MEMS 麦＋2000mAh 电池＋RGB 边框） |
BOM 成本 ≠ 芯片采购价，而是「芯片＋外围器件＋PCB＋散热＋电源」的总账。
毛绒产品还要额外算防布屑工艺与装配良率；硅胶球要算食品级材料与 3C 认证成本。
表3｜内容清单（模型／戏曲／故事包）
|
内容资产 |
规模 |
摊销逻辑 |
|
戏曲 |
500+ 段 |
制作一次性投入，分发边际成本近零 |
|
模型精讲音频 |
108／130 套 |
持续更新人力摊销 |
|
方言与共情话术库 |
六款共用 |
每周 OTA 同步 2-3 个精讲音频包 |
内容团队的工资，就是内容账的主项——它是唯一「制作贵、分发便宜」的账本，也是订阅价值的来源。
三、定价：BOM 三本账 ＋ 心理账户
1. BOM 成本公式与三本账
BOM 成本 ＝ 芯片 ＋ 外围器件 ＋ PCB ＋ 散热 ＋ 电源
再叠加渠道与毛利，才是定价的起点。
FDE 给每款产品算三本账，缺一不可：
|
账 |
内容 |
关键数字 |
|
① 物料账 |
BOM 总账（芯片＋外围＋PCB＋散热＋电源）＋ 工艺与良率 |
¥110-130/台 |
|
② 云端账 |
单台日均 ¥0.28（ASR＋TTS＋LLM），折合 ¥8.4/月 |
这是订阅定价的地板 |
|
③ 内容账 |
戏曲／模型／话术库制作 + 持续更新人力摊销 |
OTA 每周 2-3 个包 |
云端账是订阅定价的地板——订阅档位必须在覆盖云端成本后仍有边际贡献，否则订阅量越大亏损越大。
2. 六款定价表
|
产品 |
BOM |
硬件价 |
毛利率(估) |
订阅 |
价格锚点（心理账户） |
|
情绪球 |
¥110 |
¥459 |
≈76% |
故事包 ¥15/月 |
母婴玩具账户（对标乐高／绘本礼盒） |
|
拓境助手 |
¥130 |
¥499 |
≈74% |
工作模型包 ¥29/月 |
职场自我投资账户（对标「一次被甩锅的损失」） |
|
思库熊 |
¥128 |
¥599 |
≈79% |
精讲＋复习 ¥39/月 |
开学礼／教育账户（对标 4 次一对一辅导） |
|
陪伴熊·基础版 |
¥124 |
¥599 |
≈79% |
戏曲包 ¥19/月 |
尽孝礼品账户 |
|
陪伴熊·亲情版 |
¥124 |
¥798（或老用户 +¥199 升级） |
≈84% |
含声音克隆额度 |
高情感尽孝账户 |
|
记忆熊 |
¥124 |
¥799 |
≈84% |
记忆续费 ¥99/年 |
纪念／思念账户（对标墓地管理费与纪念品） |
价格带横跨 ¥459-798，锚定的不是电子物料成本，而是用户的「礼品心理账户」。
同一块 ESP32-S3 主板，四个账户四个价——定价设计的本质，是给用户一个「这笔钱属于哪本账」的答案。
3. 心理账户：599 与 799 的分野
|
价格 |
账户 |
比价对象 |
|
¥459 情绪球 |
母婴玩具 |
乐高、绘本礼盒（天花板被玩具类目压住） |
|
¥499 拓境 |
职业发展工具 |
「一次被甩锅的损失」 |
|
¥599 思库熊／陪伴熊 |
教育投入／孝心礼品 |
节日礼品、自我投资 |
|
¥798／¥799 亲情版／记忆熊 |
情感纪念 |
墓地管理费与纪念品，而非电子产品——在这类账户里，便宜反而引发不信任 |
4. 硬件与订阅：两本分开算、合起来活的账
硬件毛利覆盖渠道、履约与售后——定价要让用户能冲动下单；
订阅毛利覆盖云端与内容——定价要让用户觉得「每月一杯奶茶钱」。
钥匙（硬件）可以便宜，房子（模型库与内容服务）必须值得常回。
用户第一次为硬件付费，买下的是入口；第二次为订阅付费，买下的才是习惯。
订阅的账户逻辑：
|
订阅 |
定价 |
对标 |
|
学习精讲 |
¥39/月 |
一对一辅导的零头 |
|
戏曲包 |
¥19/月 |
戏曲 App 会员 |
|
记忆续费 |
¥99/年 |
一束花的价格 |
|
全部订阅 |
¥15-39/月 |
每天一杯豆浆区间，让续订绕过理性审批 |
免费层的设计：思库熊开箱可用 12 个模型让「学习教练」人设立住，陪伴熊 20 段戏曲让「会说话的熊」成立——免费层卖的不是功能，是付费层的人设预览。
5. 定价实验：一次真实的弹性测量
定价不是一次性决策，是可实验的变量。贯穿项目唯一一次价格实验发生在情绪球预售：
|
组 |
名额 |
价格 |
结果 |
|
A 组 |
50 |
¥459 |
转化率 5.3% |
|
B 组 |
50 |
¥399 |
转化率 6.1% |
结论：转化差 0.8 个百分点，但客单差 ¥60——459 组的单名额收入反而高 8%。
情绪球的需求价格弹性低于预期（母婴安全类产品的价格敏感度弱于内容价值感），¥459 保留。
三条方法论沉淀：
|
# |
沉淀 |
|
① |
价格实验必须随机分配流量——分渠道比价会混入人群差异 |
|
② |
实验看「单名额收入」而非转化率——低弹性产品的高价转化损失可能被客单覆盖 |
|
③ |
实验窗口要短（两周内）——长窗口会被季节因素污染 |
定价的自由度来自「敢测」——没有实验数据的定价讨论，本质是团队偏好的投票。
6. 锚点、版本与订阅的合谋（三个不）
|
手法 |
设计 |
|
锚点 |
思库熊 ¥599 的参照物不是竞品硬件，而是「一次一对一辅导 ¥150」——四次辅导的价格买一个不会请假的教练 |
|
版本 |
亲情版 ¥798 与基础版 ¥599 之间刻意留出 ¥199 差价，恰好等于升级包定价——让「先买基础版再升级」成为心理顺路，190 台升级就是这个设计的直接产出 |
|
订阅 |
所有订阅落在「每天一杯豆浆」区间（¥15-¥39/月），让续订绕过理性审批 |
合谋的三条纪律（三个不）：
|
不 |
内容 |
|
① |
不因成本降而随意降价——锚点崩塌的代价远大于短期毛利 |
|
② |
不做超过三档的版本——每多一档，选择疲劳流失约 8% |
|
③ |
不用「首年低价次年涨价」的套路——订阅产品的信任是一次性资产 |
12 个月经营数据的反证：
硬件收入贡献现金流的「量」，订阅收入贡献估值的「质」——
订阅占比从 4% 到 19% 的爬升曲线，比硬件销量曲线更能说明这家公司的未来。
7. 从定价到定价体系：调价三纪律
|
纪律 |
内容 |
|
① 调价走变更评审 |
价格是产品定义的一部分，改价等于改产品，需要与改外壳同等级评审 |
|
② 新老价差要给「身份解释」 |
第二年 B 端按班订阅定价时，C 端同步推出「老用户锁价续订」，把价差解释为「先来者红利」而非「新人补贴」——老用户续订率不降反升 4 个点 |
|
③ 永不参与「击穿锚点」的促销 |
双十二用「赠品加码」（送手册、送戏曲包时长），硬件标价纹丝不动，锚点完整保留 |
经济学基础：价格锚点是一次性资产——摧毁只需一次大促，重建需要一年。
六款产品 12 个月零降价的两个「意外」红利：
|
红利 |
内容 |
|
① |
渠道商敢于备货（不怕进完货就降价） |
|
② |
二手残值率高于同类产品 9 个点（用户敢买首发的底层原因） |
定价体系的最终形态，是让每一次支付都成为对品牌的一次确认，而不是让每一次促销都成为对锚点的一次稀释。
FDE 在定价桌上的角色：
不是拍板者，而是把三组数字摆上桌的人——
① 替代物的价格（锚点）② 相邻版本的成本差（版本）③ 单位服务成本（订阅下限）。
数字摆对了，价格自己会浮现。
四、文档体系：四份产品定义文档
设计阶段最后一件事，是把方案沉淀成四份文档：
|
# |
文档 |
写什么 |
|
① |
产品规格书（含交互映射表） |
IP 人格、目标用户画像、三大核心场景、硬件价格与订阅档位；逐按键／逐手势／逐灯色列出「输入-反馈-云端动作」三元组 |
|
② |
内容搭载清单 |
模型／戏曲／故事包及来源授权 |
|
③ |
用户说明书 |
必须写清用户侧五步法 |
|
④ |
工厂交接文件包 |
留给交付篇（引脚、结构、BOM、测试规范） |
四份文档的共同标准：
新人读完能复述产品，工厂与外包读完能报价，法务读完能指出红线。
红线必须写进文档正文（不是附录）：
|
产品 |
必须写明的红线 |
|
陪伴熊 |
「辅助陪伴非医疗、不得宣称替代医生」 |
|
亲情版 |
「声音为 AI 合成、非实时通话」 |
|
记忆熊 |
禁用词与数据销毁条款 |
这些文字不是法务的免责咒语，而是产品价值观的书面形态。
文档不是负担，是把 FDE 脑子里的东西变成组织资产的手段。
五、自检：你的产品定义三件套齐了吗
|
件套 |
自检问题 |
不合格信号 |
|
品牌 |
一句话说得出「目标用户＋场景＋差异化」吗？ |
只有 Logo 和配色，说不清人格 |
|
品牌 |
三处一致（内标／包装／开屏）核对了吗？ |
包装印错字，出厂才发现 |
|
规格 |
交互映射表逐灯色写了吗？ |
只有「灯会亮」，没定义颜色含义 |
|
规格 |
BOM 是芯片价还是总账？ |
只算芯片，漏了外围与工艺 |
|
定价 |
三本账（物料／云端／内容）都算了吗？ |
只算 BOM，没算云端，订阅定价倒挂 |
|
定价 |
定价有锚点和心理账户吗？ |
成本加成定价，599 与 799 说不出差别 |
|
文档 |
红线写进正文了吗？ |
合规藏在附录里，无人看 |
判读：七项全过 → 产品定义完成，可进平台化与 AI 产品专论；四项以下 → 你还没把「对的样子」定义清楚。
硬件是钥匙，238 套模型库才是房子。
六、金句收尾
BOM 成本＝芯片＋外围器件＋PCB＋散热＋电源；成本不是省出来的，是算出来的。
下面按 第4篇 · 第18章 · 18.3节 归位。承接 P35（18.2 产品定义三件套：品牌／规格／定价），本节进入体验设计——产品定义清楚之后，回答「用户在具体场景下怎么用得顺」。
先处理 raw：①「美感与可用性／视觉设计四基石／交互设计（菲茨定律、特斯勒复杂度守恒）／设计系统（原子设计、设计令牌）／以用户为中心的设计验证（可用性测试、A/B测试、NPS）」五大段是通用 UI/UX 教材内容，与本书六款无屏 AI 硬件贯穿案例不同源——删除，归位附录；②真正属于本页的是 DES-04 角色—场景—任务（RST）模型、反场景、以及内容要点里的焦虑视角兜底与走查四问。
18.3 体验设计模型：角色-场景-任务（P36）
【开头钩子】
体验不好，多半是场景没拆细。
与 18.2 的衔接：上一节定义了品牌（一句话）、规格（三张表）、定价（三本账）——那是产品的「形」；本节定义产品的「用」——用户在具体场景下，怎么用得顺。
体验不是形容词，是约束条件。
说「要温馨」没用；说「回复不超过 60 字、先共情、孙辈语气」，工程师才知道怎么做。
DES-04 的核心价值：用「谁 · 在什么场景 · 要完成什么任务」描述需求，替代「我要一个 XX 页面」式的功能堆砌。
启用时机：PRD 出现大段功能列表、却说不清用户路径时。
一、RST 三层：依次回答，不能跳步
RST 体验设计法要求设计师依次回答三层问题。三层答案写不具体，说明需求还没理解透——
此时不准画交互稿，不准选器件。
|
层 |
问什么 |
要具体到什么程度 |
|
R 角色 Role |
谁在用？ 他的身体状态、情绪状态、能力边界是什么？ |
老人：听力下降、说方言、畏惧「设备」； |
|
S 场景 Scene |
什么时间、什么地点、什么环境光与噪音条件下用？ 手边有什么、手里正在做什么？ |
时间／地点／光线／噪音／手持状态 |
|
T 任务 Task |
他要完成的最小任务是什么？完成的标志是什么？ |
最小动作 ＋ 可判定的完成标志 |
二、案例：陪伴熊的 RST 拆解
|
层 |
答案 |
|
角色 |
空巢老人 |
|
场景 |
晚饭后独坐沙发、电视开着、灯光昏黄 |
|
任务 |
「听到一句亲人的声音」 |
三层答案一摆，所有设计选择都有了裁判：
|
设计选择 |
由 RST 哪一层推出 |
|
设备上不能出现文字 |
角色：不识字／畏惧设备 |
|
按键不超过两个 |
角色：能力边界 |
|
回复不超过 60 字 |
角色：听力与信息负荷 |
|
绝不说「我是 AI」 |
任务：要的是亲人的声音，不是机器的回应 |
|
灯色必须能在昏黄灯光下分辨 |
场景：环境光 |
RST 法的威力，在于它把「用户体验」从形容词变成了约束条件——
设计师再也不用争论「温不温馨」，只需要核对「60 字以内、先共情、孙辈语气」这些可执行、可验收的规则。
三、反场景：与主场景同等重要
成熟的产品方法论要求主场景、边缘场景、反场景三者同时划分：
|
类型 |
定义 |
作用 |
|
主场景 |
产品主要服务的场景 |
决定核心设计 |
|
边缘场景 |
偶尔发生但仍需覆盖 |
决定兼容性 |
|
反场景 |
不该发生、但一定会发生的滥用／误用场景 |
决定兜底与红线 |
两个贯穿案例
|
产品 |
反场景 |
催生的设计 |
|
思库熊 |
孩子深夜与熊聊天以规避家长监管 |
「家长端只看熟练度热力图、不看聊天原文」的隐私设计 |
|
拓境 |
有人恶意在会议中偷录他人 |
团队版只共享匿名化的模型命中统计，永不共享录音原文 |
把反场景写进设计稿，不是悲观，是给产品上保险。
回扣 REQ-03 二阶后果（P17）：反场景就是二阶思维在体验层的落地——「用户会怎么用它做我们没想到的事？」
四、焦虑视角：在用户最容易慌的那一步做兜底
体验设计最见功力的地方，不是顺境时多流畅，而是逆境时多体面。
用户的三个「最慌时刻」——每一步都要有兜底设计：
|
慌的时刻 |
用户状态 |
兜底设计原则 |
|
① 配网失败 |
老人／非技术用户最易崩溃的一步 |
流程压到四步；提供子女远程协助配网通道（回扣 P23 激活率 84% 的功臣） |
|
② 断网 |
设备「哑掉」，用户以为坏了 |
本地降级——断网时预置内容照常可播（陪伴熊 20 段戏曲） |
|
③ 无响应 |
说了话没反应，不知道是没听见还是坏了 |
即时状态反馈——灯环呼吸／唤醒反馈，让等待可预期 |
兜底三原则：
|
原则 |
内容 |
|
① 可预期 |
让用户知道「正在处理」，而不是干等 |
|
② 可降级 |
核心功能在降级状态下仍可用（不是报错，是降配运行） |
|
③ 可求助 |
卡住时有明确的求助通道（远程协助／说明书五步法） |
站在用户焦虑视角做体验兜底——顺境的体验决定满意度，逆境的体验决定信任。
五、走查四问：体验设计的验收动作
设计稿完成后，用走查四问逐场景过一遍：
|
# |
问 |
要答出什么 |
|
① |
用户从哪来？ |
触发入口是什么（推送／主动唤醒／定时） |
|
② |
要做什么？ |
他要完成的最小任务 |
|
③ |
卡在哪？ |
最高概率的中断点（配网／识别失败／无响应） |
|
④ |
走不走？ |
完成后如何离开；会不会被困在某个状态 |
四问全部答得出，这条体验路径才算设计完成；
任何一问答不出 → 还有暗坑，回炉。
走查的产出：把「卡在哪」那一栏的每一条，配上第四部分的兜底动作——这是体验设计最值钱的一张表。
六、DES-04 模型定位与思想源头
|
项 |
内容 |
|
模型 |
DES-04 角色—场景—任务 · 体验设计模型 |
|
来源 |
产品设计通用法 ＋ 达利欧《原则》用户视角 |
|
启用时机 |
PRD 出现大段功能列表却说不清用户路径时 |
|
产出 |
RST 三维矩阵（角色 × 场景 × 任务的一一对应） |
两条思想要义：
|
思想 |
与本模型 |
|
芒格：多学科思维模型交叉验证，避免单一视角偏误 |
多角度分析避免片面——角色／场景／任务三层，就是三个视角的交叉 |
|
张磊：「体验投资应对准高频、高价值场景」 |
体验投资对准高频高价值场景——资源有限，先保主场景，再顾边缘，反场景只做兜底 |
体验投资的优先级：主场景（重投入）→ 边缘场景（兼容）→ 反场景（兜底红线）。
把钱和工期平均花在三类场景上，是体验设计最常见的浪费。
七、自检：你的体验设计合格吗
|
自检问题 |
不合格信号 |
|
① RST 三层写具体了吗？ |
只写「老人」「晚上」，说不清环境与能力边界 |
|
② 三层没拆细就画交互稿了吗？ |
边画边想，返工不断 |
|
③ 反场景写了吗？ |
只设计「好人怎么用」，没想「会被怎么用坏」 |
|
④ 三个最慌时刻有兜底吗？ |
配网失败就白屏，断网就哑掉 |
|
⑤ 走查四问答得出吗？ |
说不清用户「从哪来、卡在哪」 |
|
⑥ 体验投资对准高频高价值场景了吗？ |
在边缘场景上精雕细琢，主场景却磕绊 |
判读：六项全过 → 体验设计合格；四项以下 → 你的场景还没拆细，体验只是形容词。
八、金句收尾
站在用户焦虑视角做体验兜底。
下面按 第4篇 · 第18章 · 18.4节 归位。承接 P36（18.3 体验设计 RST），本节进入设计定义的最后一道闸门——非功能基线（DES-05）。
与 18.1 的关系：18.1 的「闸门三」已提及 DES-05 非功能基线三条底线（安全／隐私／成本）；本页把它完整展开为可执行的基线表——从「一句话原则」变成「逐项有数值的底线」。
18.4 非功能基线：安全边际必须写进设计（P37）
【开头钩子】
功能会迭代，基线不能松。
与 18.3 的衔接：上一节用 RST（角色—场景—任务）把「体验」从形容词变成了约束条件；本节做同一件事——把「安全、隐私、成本」从口号变成底线值。
功能可以迭代，底线不能商量。
一、为什么基线必须在设计阶段写死
三条基线如果不在设计阶段锁死，代价会成倍放大：
|
阶段 |
发现基线失守的代价 |
|
设计阶段（本页） |
改一张图纸 |
|
工程／EVT 阶段 |
改一次模具（一个模具周期） |
|
量产／上市后 |
召回、诉讼、品牌崩塌——没有「下个版本修复」的机会 |
基线的意义，正是让算账发生在设计阶段，而不是在量产前夜才发现账单早已失控。
成本不是省出来的，是算出来的（回扣 P35）。
二、三类基线：否决项 vs 约束项
FDE 为所有硬件产品划定三条非功能基线：安全、隐私、成本。
三条基线的先后顺序本身就是纪律。
|
基线 |
性质 |
规则 |
|
安全 |
否决项 |
不参与打分、不接受「先上线再补」，评审中一票否决 |
|
隐私 |
否决项 |
同上——一票否决 |
|
成本 |
约束项 |
允许在设计中反复权衡，但不允许产品带着亏损的单位经济模型进入量产 |
卖一台亏一台的硬件，卖得越多死得越快。
关键区分：
安全与隐私是否决项——不满足就不做，没有商量余地；
成本是约束项——可以反复权衡、可以砍功能降本，但不能为降本击穿安全与隐私。
三、基线一｜安全：物理与电气双底线
安全指物理与电气安全——对儿童产品尤其残酷。
|
安全项 |
要求 |
适用 |
|
食品级硅胶外壳 |
无毒、可啃咬 |
情绪球（面对 3 岁儿童） |
|
3C 认证 |
强制认证 |
全部 |
|
小零件防吞咽结构 |
无易脱落小件 |
情绪球、毛绒三熊 |
|
锂电池过充过放保护 |
充放电保护电路 |
全部 |
情绪球面对的是 3 岁儿童——任何一条失守都是毁灭性事故，没有「下个版本修复」的机会。
安全边际原则（芒格）：
为未知留余地。
性能、容量、发布门禁皆同——上线标准 ＝ 底线值 × 系数，而不是「 hoped 值」。
四、基线二｜隐私：数据最小化与知情同意
隐私指数据最小化与知情同意。六款产品的隐私红线：
|
产品 |
隐私基线 |
工程落点 |
|
情绪球 |
端侧 ASR 后立即丢弃原始语音 |
设备端处理，只上传摘要与标签 |
|
陪伴熊 |
对话摘要化，默认不存全量原文 |
云端只存标签＋摘要 |
|
亲情版／记忆熊 |
克隆声音必须本人弹窗授权，且加密存储 |
前端弹窗 ＋ 存储层 AES 加密 |
最小采集 ＋ 明确留存期——这两条是隐私基线的通用公式。
银发／儿童产品的额外三条红线：
|
# |
红线 |
说明 |
|
① |
隐私分级 |
不同数据分级存储，原文／摘要／标签三级 |
|
② |
数据最小化 |
能不采的就不采，能摘要的就不存原文 |
|
③ |
家长／家属可控 |
授权、查看、删除、销毁的入口必须在用户手里 |
记忆熊的「一键销毁＋凭证」就是第③条的实体化（回扣 P30 JY-05）。
五、基线三｜成本：单位经济性
成本指单位经济性——三本账必须支撑既定价格带的毛利结构：
|
账 |
数值 |
说明 |
|
① BOM |
¥110-130/台 |
物料总账（回扣 P35） |
|
② 云端 |
≈¥0.28/台/天（折合 ¥8.4/月） |
ASR＋TTS＋LLM，是订阅定价的地板 |
|
③ 内容摊销 |
按 OTA 包摊销 |
制作一次性、分发边际成本近零 |
BOM ＋ 云端 ＋ 内容摊销，必须支撑既定价格带的毛利结构。
任何一本账算不平，价格带就站不住——站不住的价格带，会在量产前夜变成失控的账单。
六、DES-05 模型：安全边际·非功能基线
|
项 |
内容 |
|
模型 |
DES-05 安全边际 · 非功能基线模型 |
|
来源 |
芒格 Margin of Safety |
|
核心要求 |
性能、安全、可用性、合规在设计阶段给出「底线值」而非「hoped 值」 |
|
上线标准 |
底线 × 系数 |
|
启用场景 |
对外 SLA 产品、金融／医疗、大促系统时必须启用 |
两条思想要义：
|
思想 |
与本模型 |
|
芒格：「为未知留余地。」 |
安全边际——NFR（非功能需求）／容量／发布门禁皆同；不留余地的设计，等于把风险推迟到上线后 |
|
张磊：「长期主义是一种能力，是时间复利的受益者。」 |
稳定体验是长期留存的基础——基线松一次，信任塌一次，长期复利就断了 |
基线不是「做到最好」，是「绝不低于」——这两者的差距，就是安全边际。
七、自检：你的基线锁死了吗
|
自检问题 |
不合格信号 |
|
① 安全／隐私是「否决项」吗？ |
被放进打分表，接受「先上线再补」 |
|
② 三类基线逐项有数值吗？ |
只有「要安全」「要便宜」这类形容词 |
|
③ 上线标准是「底线×系数」吗？ |
直接用底线值，没留安全边际 |
|
④ 儿童产品过 3C、防吞咽了吗？ |
只测功能，没测物理安全 |
|
⑤ 隐私做到「最小采集＋明确留存期」了吗？ |
全量原文落库，无留存期 |
|
⑥ 三本账能支撑价格带吗？ |
BOM 算平了，但云端没算；或反过来 |
判读：六项全过 → 基线锁死，可进设计评审；四项以下 → 你的设计还带着「 hoped 值」在裸奔。
八、金句收尾
安全不是功能，而是底线；一个不安全的产品，功能再强大也是零。
下面按 第4篇 · 第18章 · 18.5节 归位。承接 P37（18.4 非功能基线），本节补上「闸门三」的另一半——可测。
与 18.4 的分工：
- 18.4 非功能基线（DES-05）定义了「绝不低于」——安全／隐私／成本三条底线；
- 18.5 可测试性（DES-03）定义「怎么证明」——把每条设计翻译成可判定通过与否的验收标准。
一句话：基线定的是底线值，可测定的是验收动作——两者合起来，才是 18.1 所说的「闸门三：可测与守底」。
18.5 可测试性设计：设计阶段就想好怎么测（P38）
【开头钩子】
测不了的设计，等于没设计。
传统 PRD 的吵架坑：
传统 PRD 写「唤醒要灵敏」「对话要自然」——工程交付时，双方为「什么叫灵敏、什么叫自然」吵上三周。
问题不在双方不讲理，在设计阶段根本没定义清楚。
一、FDE 硬规矩：设计稿与验收稿两稿同页
|
规矩 |
内容 |
|
核心规则 |
任何一条设计陈述，如果不能翻译成一条可测量、可演示、可判定通过与否的验收标准，它就没有资格进入方案 |
|
做法 |
写设计稿的同时必须写验收稿——两稿同页、一一对应 |
|
判定 |
设计师交不出验收标准，说明他自己也没想清楚要什么 |
设计陈述是「我要什么」，验收标准是「怎么证明你给了我」——只有前者没有后者，等于没说。
二、验收标准四要素（Given-When-Then-阈值）
每条验收标准必须写全四要素：
|
要素 |
内容 |
说明 |
|
① 触发条件（Given） |
在什么前提下 |
环境、状态、前置条件 |
|
② 用户操作（When） |
用户做了什么 |
具体动作 |
|
③ 可观测结果（Then） |
系统给出什么 |
可观测、可演示 |
|
④ 量化阈值 |
到什么数算通过 |
可机检的数字 |
示例对照：
|
❌ 不是验收标准 |
✅ 四要素齐全 |
|
「唤醒要灵敏」 |
Given 安静环境 → When 说「库库，我笔记越记越厚」 → Then 设备播报启动语且小程序收到 001 号模型卡片 → 阈值 唤醒率 ≥98%、端到端 ≤3 秒 |
三、阈值的三类合法来源
凡是拍脑袋写不出阈值的条目——要么去用户场景里实测，要么承认它还不是设计，只是愿望。
|
来源 |
说明 |
示例 |
|
① 行业常识与人类感知极限 |
来自人的感知阈值，不是工程师顺手写的整数 |
触摸响应 <200ms；端到端语音应答 3 秒内 |
|
② 成本与体验的权衡 |
来自商业与体验的平衡点 |
唤醒率 ≥98%；弱网 RSSI >-65dBm |
|
③ 合规红线 |
来自法律与伦理，不接受权衡 |
儿童原始语音零留存；克隆声音必须本人授权 |
回扣 P20「指标值来自用户可感知线，而非技术舒适线」——第①类阈值最容易被写成「顺手的整数」，务必回到用户感知实测。
四、验收标准示例表（六款产品）
思库熊：
|
验收条目示例 |
量化阈值 |
|
安静环境说「库库，我笔记越记越厚」，设备播报启动语且小程序收到 001 号模型卡片，卡片五段齐全（真实场景／底层模型／操作步骤／破解公式／练一次清单） |
唤醒率 ≥98%；路由 Top3 必含 001；端到端 ≤3 秒；TTS 摘要 ≤80 字 |
|
同一模型练满 5 次并打卡，熟练度热力图对应维度点亮并标记「已内化」；家长端任何页面无法查看聊天原文 |
打卡与热力图同步延迟 ≤10 秒；家长端原文接口不存在（否决项） |
情绪球：
|
验收条目示例 |
量化阈值 |
|
挤压力度超过阈值后灯环亮起进入倾听；共情回复不含「你应该」字样；倾诉结束后设备本地不存在录音文件 |
唤醒响应 ≤1 秒；回复 ≤40 字；本地录音文件数 ＝ 0（否决项） |
|
连续轻压 3 次触发呼吸引导，灯环以呼吸节律明暗变化，邀请语播报后孩子可跟随 |
呼吸周期 约 6 秒；引导语 ≤40 字；无说教句式 |
注意两类特殊阈值：
- 「接口不存在」「文件数＝0」——这类是否决项，不是打分项，不满足即不通过（回扣 18.4 安全／隐私基线）；
- 「无说教句式」——这类是回归集判定，需要先有评测集（见下节）。
五、评测集先于开发：先定「什么叫好」
内容要点：评测集先于开发——先定「什么叫好」，再动手做。
对 AI 功能而言，「可测」的关键不是单点阈值，而是一套评测集（回归集）：
|
评测集类型 |
评什么 |
先于开发定什么 |
|
Prompt 回归集 |
人格一致性（不说教、不暴露 AI 身份、长度合规） |
30 组标准输入 ＋ 期望输出特征（如「零说教句」） |
|
RAG 召回集 |
命中率（Top3 必含正确模型） |
标准 query 集 ＋ 正确召回标注 |
|
路由评测集 |
ModelRouter 命中准确率 |
痛点描述样本 ＋ 期望模型号 |
|
TTS/ASR 评测集 |
可懂度、方言识别率 |
标准语料集（含噪声样本） |
做法：
在写第一行代码之前，先把评测集和通过线定下来——
开发完成后的验收，只是「跑一遍评测集」，不是「协商什么叫好」。
回扣 18.1（DES-03）：设计阶段把「怎么测」设计进去——测试不是测试阶段才想的事。
六、设计要预留的四类测试接口
「可测」不只是写验收标准，还要在设计上留出测试通道：
|
接口 |
作用 |
|
① 可观测点 |
关键状态可读取（如灯效状态、当前模型号、延迟埋点）——测不了黑盒 |
|
② 注入点 |
可注入异常（弱网、断网、错误输入），验证降级路径 |
|
③ 开关 |
功能可灰度、可回滚（如新 Prompt 版本可一键切回） |
|
④ 模块边界 |
接口契约清晰，模块可独立测试（不依赖整机） |
没有可观测点，验收只能靠肉眼；没有注入点，降级路径永远测不到。
七、追溯链：需求 → 验收标准 → 测试用例编号
可测试性的最终落地，是三层编号一一挂接：
|
层 |
挂什么 |
来源 |
|
① 需求条目 |
P0 需求编号（如 PB-02） |
P30 P0 总表 |
|
② 验收标准 |
可机检指标（如「三方言识别 ≥90%」） |
本页四要素 |
|
③ 测试用例 |
测试用例 ID（可执行的测试动作） |
测试篇 |
铁律：
每个需求挂验收标准，验收标准挂测试用例编号。
回扣 P34 追溯矩阵（第一年数据）：
|
指标 |
数值 |
比例含义 |
|
P0 需求 |
61 条 |
基准 |
|
设计决策 |
148 个 |
1 : 2.4——设计有分解 |
|
测试用例 |
394 条 |
1 : 6.5——验证有密度 |
三列比例本身就是健康度指标：测试用例数远超决策数，说明验证有密度；反之则说明「设计写完了，但没人知道怎么验」。
八、DES-03 机器思维 · 可测试性设计模型
|
项 |
内容 |
|
模型 |
DES-03 机器思维 · 可测试性设计模型 |
|
来源 |
达利欧 Machine Thinking |
|
核心要求 |
设计阶段把「怎么测」设计进去——可观测点、注入点、开关、模块边界 |
|
启用时机 |
详细设计评审、API 设计、AI 系统设计时必须启用 |
两条思想要义：
|
思想 |
与本模型 |
|
芒格（系统思维）：「输出不好，先改系统设计，而非只换人。」 |
输出不好就改系统设计——缺陷反复出现时，先查设计是否预留了可测通道，而不是怪测试没测出来 |
|
张磊：「可维护性是可扩展、持续交付的前提。」 |
可维护性是可扩展的前提——可观测点与模块边界，既是测试接口，也是后续扩展与 OTA 的基础 |
测试不是测试阶段才想的事——设计不留测点，测试就只能靠猜。
九、自检：你的设计可测吗
|
自检问题 |
不合格信号 |
|
① 每条设计都有验收标准吗？ |
只有设计稿，无验收稿 |
|
② 验收标准四要素齐吗？ |
缺 Given／缺阈值，只有「要灵敏」 |
|
③ 阈值有合法来源吗？ |
拍脑袋写的整数，说不出依据 |
|
④ AI 功能先建评测集了吗？ |
做完才想「什么叫好」 |
|
⑤ 设计预留了可观测点／注入点吗？ |
黑盒，只能肉眼验收 |
|
⑥ 需求→验收→测试用例挂上了吗？ |
三层编号对不上，出事查不到 |
判读：六项全过 → 设计可测，可进评审；四项以下 → 你的设计还停留在「我觉得好了」，没有进入工程语言。
十、金句收尾
机器思维 · 可测试性设计模型——设计阶段就想好怎么测。
下面按 第4篇 · 第19章 · 19.1节 归位。
先说明章节推进：第18章（产品定义）已由 P34—P38 五节完整收口；本页讲设计评审，属设计篇的「评审门禁」——按交付顺序，它开启 第19章。原先 P33 路线图中排在评审门禁之前的「平台化」「模型驱动」两站顺延为第20、21章。
再处理 raw：①「AI Agent 智能评审风控体系」整段（98% 企业崩盘、裸奔式烧钱、人工评审致命短板）与深圳 AI 质检 520 万案例，是营销化表述的另一体系内容，核心教训（无架构评审→6 个月后推倒重来）极有价值，已压缩为案例胶囊、删除营销话术；②内容要点中的「0 分项写整改责任人与期限」「评审结论生成测试用例与客服 FAQ」raw 未展开，已补齐；③两套「四件产出物」口径冲突（P33 篇级四件 vs 本页设计阶段四份），已在文末做合并校正。
第19章 设计评审门禁：十二问与出口物
章眼：评审不是挑刺，是把返工从交付期挪到纸面上。
19.1 设计评审十二问：每个0分都是一张未来工单（P39）
【开头钩子】
设计评审不是审批会，是给未来的客服部减负。
设计评审最容易犯的错，是把它开成「通过仪式」——材料会前没人看，会上轮流点头，散会皆大欢喜。
真正的评审会，开完应该有一份「0 分整改清单」。
没有 0 分的评审会，多半是走过场——那些没被扣掉的分数，会在量产后变成工单还回来。
一、为什么必须评审：无评审的代价
案例胶囊：深圳某 AI 智能质检公司承接工业视觉质检项目，技术负责人盲目自研架构，全程无架构评审、无技术风险校验。团队追求技术前沿与架构酷炫，完全忽略工业现场低光照、高反光、多干扰、非标工况的真实场景。
|
阶段 |
后果 |
|
开发 6 个月、投入 520 万研发与算力 |
临近上线才发现致命架构缺陷 |
|
缺陷一 |
自研架构算力消耗极高，单张图片检测耗时超 3 秒，无法适配工业实时检测 |
|
缺陷二 |
模型泛化能力极差，仅能适配实验室样本，现场误检、漏检率高达 40% |
|
结局 |
架构无法修复、模型无法微调——唯一方案是全部推倒、从零重构 |
教训：
前期一次架构评审的成本，是后期一次推倒重来的千分之一。
所有问题堆积到交付阶段爆发，本质上是设计评审的缺位——评审省下的那两小时，会在量产后以百倍工时偿还。
二、十二问总表：一问问不住，文档就退回
六款产品的设计评审共用一份十二问清单。每一问都对应一次真实的打回史。
按内容要点划分的七个维度归类：
|
# |
问 |
维度 |
判定要点 |
|
1 |
品牌三处一致吗（IP／刻印／宣传语） |
场景 |
内标、包装、小程序开屏逐字逐形一致（回扣 P35） |
|
2 |
BOM 表到器件级了吗 |
成本 |
到器件级；每颗差异件有场景证词 |
|
3 |
交互映射到按键级了吗 |
场景 |
逐按键／逐手势／逐灯色列出「输入-反馈-云端动作」三元组 |
|
4 |
软硬五层架构齐了吗 |
售后 |
固件／云端／内容／端／数据五层；缺一层则端侧能力无法界定 |
|
5 |
模型／Prompt 有九字段规格吗 |
售后 |
人格、语气、长度、禁语、路由、知识源、兜底、版本、回归集 |
|
6 |
订阅分层有钩子吗 |
成本 |
免费层让人设立住；付费墙画在价值跃迁点（回扣 P35） |
|
7 |
合规嵌进功能了吗 |
合规 |
合规条款落到具体工程位置（弹窗／加密／标注），不是附录 |
|
8 |
每条设计可测吗 |
指标 |
四要素（Given/When/Then/阈值）齐全，阈值有合法来源（回扣 P38） |
|
9 |
与已上线 SKU 复用什么 |
边界 |
复用清单与新增清单分开列；不写清楚就重复造轮子 |
|
10 |
变化边界立法了吗 |
边界 |
哪些能改（OTA／订阅）、哪些不能改（硬件／合规），一次定死 |
|
11 |
降级方案有吗 |
异常 |
断网／云端故障／硬件异常，各有降级路径（回扣 P36 兜底三原则） |
|
12 |
成本账算平了吗 |
成本 |
BOM／定价／订阅／云成本四账联动（回扣 P35 三本账） |
打回率：
评审会的平均打回率约 1.5 轮——这不是浪费，是把返工从交付期挪到纸面上。
三、十二问的深层价值：逼出隐含决策
评审清单真正的价值，不在「检查」，在「逼出隐含决策」。
十二问里那些看似琐碎的追问，会把「到时候再说」逼成「现在就定」：
|
案例 |
被哪一问逼出 |
逼出的配套约束 |
|
情绪球「家长端不可回放」 |
第4问（五层架构） |
追问出配套约束——端侧必须跑 ASR（否则原文已上云，隐私承诺落空） |
|
陪伴熊「离线戏曲」 |
第11问（降级方案） |
逼出降级方案——断网仍可播 20 段（回扣 P23 三个反智能决定之三） |
设计文档的每一次退回，都是把一个「到时候再说」变成一个「现在就定」。
四、打分与留痕：0 分项必须挂责任人与期限
内容要点：打分留痕——0 分项必须写整改责任人与期限。
打分规则：
|
项 |
规则 |
|
计分 |
每问 0／1 分（或 0-2 分档），不接受「基本通过」 |
|
0 分判定 |
该问完全没做，或做了但说不清依据 |
|
一票否决 |
第 7 问（合规） 与第 8 问（可测） 中的否决项——0 分即退回，不进下一轮 |
0 分整改单三要素（缺一不可）：
|
要素 |
内容 |
|
① 整改内容 |
具体要补什么（不是「完善一下」，是「补三处一致对照表」） |
|
② 责任人 |
到人，不是到部门 |
|
③ 期限 |
具体到日期，并排进下一轮评审议程 |
没有责任人的 0 分等于没扣，没有期限的整改等于不改。
整改单要进 ADR 决策日志（回扣 P34）——未来复盘时，它是「当时为什么这么定」的证据链。
记录纪律（回扣 P34 评审三纪律）：
所有意见必须落到纸面的设计权衡单上——口头表扬与口头反对都不算数。
五、评审结论的两个直接产出
内容要点：评审结论直接生成测试用例与客服 FAQ。
评审会不是开完就散——它的结论要直接变成两份可执行的东西。
产出一｜测试用例（进测试篇）
|
来源 |
转化 |
|
第 8 问「每条设计可测吗」的验收标准清单 |
逐条转为测试用例 ID，进追溯矩阵（回扣 P38 第七部分） |
|
第 11 问「降级方案」的每一条 |
转为异常路径测试用例（断网／弱网／无响应） |
|
第 7 问「合规」的每一条红线 |
转为否决项测试（如「本地录音文件数＝0」） |
评审会上定的验收标准，就是测试阶段的考卷——评审放水，测试就无卷可考。
产出二｜客服 FAQ（进交付篇）
设计评审的每一条已知限制与降级行为，都是客服未来要回答的问题：
|
评审结论 |
生成的客服 FAQ |
|
第 10 问「变化边界」——哪些能 OTA、哪些不能 |
「这个能通过升级解决吗？」→ 标准答复 |
|
第 11 问「降级方案」——断网可播 20 段 |
「断网了还能用吗？」→ 标准答复 |
|
第 2 问「BOM 器件级」——某个器件缺货时的替代方案 |
「为什么我买的批次和之前不一样？」→ 标准答复 |
|
第 7 问「合规」——数据留存期与删除权 |
「怎么删除我的数据？」→ 标准答复 |
现在多写一条 FAQ，未来少接十个投诉电话。
这就是开头那句话的意思——评审不是审批会，是给未来的客服部减负。
六、设计阶段出口物：四份文档与检验三问
📌 与 P33 的口径校正：P33 给的是篇级四件产出物（规格书／BOM 初稿／评审记录／ADR 决策日志）；本页 raw 给的是设计阶段四份出口物（产品定义书／交互映射表／设计权衡单合集／验收标准清单）。两者是同一批资产的两种列举角度，建议定稿时合并为一份完整清单（见文末归位提示）。
设计阶段结束时，团队必须交出四份出口物：
|
# |
出口物 |
内容 |
|
① |
产品定义书 |
IP 人格、目标用户、核心场景、价格与订阅结构 |
|
② |
交互映射表 |
每一个传感输入对应的灯效、语音与云端动作 |
|
③ |
设计权衡单合集 |
全部重大决策与假设（回扣 P34） |
|
④ |
验收标准清单 |
与设计条目一一对应（回扣 P38） |
下游承接：
技术篇以这四份文档为输入，开始架构与开发；
交付篇以验收清单为门禁，组织 EVT／DVT 测试。
设计阶段留下的思考质量，最终都会在量产线上兑现或偿还。
出口物检验三问
|
问 |
检验什么 |
|
① 新人读完能否复述产品是什么？ |
定义是否清晰到可传递 |
|
② 工厂与外包读完能否直接报价？ |
规格是否具体到可执行 |
|
③ 法务读完能否指出合规红线？ |
合规是否落在正文、可识别 |
三问都过关，设计阶段才算关门。
任何一份停留在「大家心里都懂」的默契层面，风险就没有被真正管理。
七、自检：你的评审会合格吗
|
自检问题 |
不合格信号 |
|
① 十二问逐条过了吗？ |
会上只聊功能，不聊边界与降级 |
|
② 打出 0 分了吗？ |
全票通过，无整改单 |
|
③ 0 分项有责任人与期限吗？ |
只写「待完善」，无人认领 |
|
④ 评审结论生成测试用例了吗？ |
验收标准与测试用例对不上 |
|
⑤ 评审结论生成客服 FAQ 了吗？ |
上线后客服一问三不知 |
|
⑥ 出口物三问都过了吗？ |
工厂看完还要再问一轮 |
判读：六项全过 → 评审有效，可进技术篇；四项以下 → 你在开审批会，不是评审会。
平均打回 1.5 轮不是内耗——每一轮退回，都是把一次量产后的一线事故，提前变成了纸面上的一行整改。
八、金句收尾
设计评审不是审批会，是给未来的客服部减负——每一个「0 分」都是一张未来的工单。
下面按 第4篇 · 第20章 · 20.1节 归位。
先说明章节推进：第18章（产品定义，P34—P38 五节）与第19章（设计评审门禁，P39）已收口——评审保证「做对」；从本章起进入设计篇最重要的思想：平台化保证「做得起」。
再处理 raw：本页内容极其丰富，但存在四组重复（六层架构出现两次、SKU 五开关两次、升级路径两次、智元组件化两次），已合并去重、取并集；几处 OCR 残缺（如「用的话说」缺主语、「火山 TTS 换成…」句子截断）已补顺；「源方案」等内部说法统一改为「贯穿项目」。
第20章 平台化：一次开发、六款复用
章眼：六款产品共用一套底座——边际成本极低的背后，是变化被立法圈进了三类格子。
20.1 平台化与组件化：一次开发、六款复用（P40）
【开头钩子】
平台化的自由，来自不自由的纪律。
与第19章的衔接：十九章用十二问守住设计质量——那是「做对」；本章解决另一个问题——「做得起」。
如果六款产品各做各的主板、各写各的固件、各建各的云端，小团队会被六倍的维护成本直接拖垮——
一个 OTA 要发六次、一个安全补丁要补六个工程、一个云服务故障要查六条链路。
贯穿项目把核心策略写得很直白：
开发一次底层固件，切换 Prompt 与知识库出新品，边际成本极低。
一、平台化是六款产品的生死前提
平台化有两面，缺一不可：
|
面 |
内容 |
|
正面·红利 |
硬件层、固件层、云端链路、配网小程序全部共用——有限人力才能集中投放到真正产生差异的地方：外壳、Prompt、知识库与内容 |
|
反面·纪律 |
共用意味着底层任何改动都同时影响六款产品——一处随手修改可能让六条产品线同时宕机 |
因此架构设计的核心命题不是「怎么复用」，而是——
把变化关进笼子。
哪些层永远不许动？哪些差异通过配置注入？新增一款产品的标准动作为什么必须是「加配置而不是改代码」？
这就是六层架构切分与 SKU 五个开关要解决的问题。
二、六层统一底座：复杂度被压在最上面两层
自下而上六层，变化集中的地方才允许变化：
|
层 |
内容 |
变化边界 |
|
① 硬件层 |
ESP32-S3 主控、麦克风（思库熊 INMP441 单麦／拓境双 MEMS 阵列）、40mm 喇叭、WS2812 灯珠或 RGB 边框、触摸电极或 FSR 压力传感器、电池 |
只允许外壳形态与传感器配置变化；主控与音频链路六款统一——平台化不可退让的地基 |
|
② 固件层 |
ESP-IDF v5.1+ 工程：wake_word、audio_capture/playback、wifi_manager、mqtt_client、touch_sensor、led_ring、power_manager、ota_task、nvs_storage |
职责严格限定为「采集与播报」——不做路由、不存知识、不写 Prompt；同一份工程靠编译宏切换 SKU，主干永不分叉 |
|
③ 模型内核层 |
238 套模型（108 学习＋130 职场）＋ 垂直场景 Prompt 库，JSON manifest 版本化管理，书稿切片经 text-embedding-3-small 向量化入 Milvus/SQLite vec |
内容可每周 OTA 更新，但模型的标准数据结构（manifest 字段）永不变更——结构稳定，内容才能自由流动 |
|
④ AI 编排层 |
一条语音链路全员共用（ASR→ModelRouter→RAG→LLM→TTS） |
共用，不随 SKU 变 |
|
⑤ 应用层 |
小程序按产品裁剪页面树 |
按 SKU 裁剪 |
|
⑥ 产品层 |
只做三件事的差异：外壳、人格、知识库 |
自由变化 |
选型理由：ESP32-S3 性能够用、生态成熟、成本可控——ESP-IDF 工具链完善；ESP-SR 的 WakeNet 离线唤醒免授权费；¥110-130 的 BOM 撑得住 ¥459-798 价格带。
复杂度被压在最上面两层——这正是平台化的意义：变化集中的地方才允许变化。
这不是简化，而是抽象的力量。
三、SKU 五个开关：同平台出新品只允许改这五处
同一份固件工程如何变出六款产品？答案是五个编译期与配置期开关：
|
开关 |
内容 |
思库熊 |
陪伴熊 |
记忆熊 |
|
① PRODUCT_SKU 宏 |
固件编译期产品标识（工厂按订单选择烧录目标） |
THINKBEAR |
COMPANION |
MEMORY |
|
② 唤醒词 |
离线唤醒模型与文案 |
库库 |
熊小伴 |
亲人习惯称呼 |
|
③ Prompt 包 |
人格与场景母版（决定 LLM 角色与语气） |
学习教练版 |
方言陪伴版 |
纪念人格版 |
|
④ 知识库集合 |
RAG collection |
learn_108 |
戏曲＋用药库 |
人格档案库 |
|
⑤ 灯效／交互映射 |
反馈语义表 |
练习反馈灯 |
慢节奏呼吸灯 |
低频柔和 |
[THINKBEAR] = { wake:"库库", prompt:"coach_learn", kb:"learn_108", led:"belly_ring" }
情绪球特殊：没有唤醒词——挤压即唤醒（FSR 压力传感）。
三条工程纪律
|
# |
纪律 |
为什么 |
|
① |
开关只允许出现在配置层，业务代码里禁止散落的 if(sku==...) 判断——所有差异通过配置表注入 |
否则六款产品的差异会像藤蔓一样爬满代码库，改一个 bug 要改六处 |
|
② |
OTA manifest 按 SKU 分发，但升级通道、签名校验、双区备份回滚机制六款共用 |
通道是铁路，内容是车厢——铁路只修一条 |
|
③ |
新增 SKU 的标准动作是「加配置不改代码」 |
如果上新一款产品需要改动固件主干，说明架构失职，要先重构再上新 |
这个约束让「加一款产品」从三个月变成三天。
四、智元组件化：封装标准与接口契约
把 AI 能力的最小可部署单元称为「智元」（Intellicell）——
每一个智元都是完整的、智能的、可独立运行的功能单元，封装了数据、逻辑、界面、AI 能力、文档与测试用例，如同生物学的细胞：完整、可繁殖、可分化、可组合。
六款产品的架构正是这一思想的工程化：
|
类型 |
智元举例 |
职责 |
|
交互智元 |
唤醒、录音、灯效、触摸 |
感知—反馈 |
|
逻辑智元 |
模型路由、卡片生成、用药提醒、声音克隆、情绪摘要 |
路由—生成—沉淀 |
封装标准四条
|
# |
标准 |
说明 |
|
① |
自描述 |
每个智元知道自己能做什么、需要什么输入、产出什么——它不是黑盒，是透明的水晶，调用者不必读源码就能合作 |
|
② |
接口契约固定 |
MQTT 主题与 REST API 一旦发布即受版本约束 |
|
③ |
可独立测试 |
自带测试用例与 mock，不依赖整机就能验证 |
|
④ |
可替换 |
火山 ASR 与其他 ASR 藏在同一接口背后；亲情版月活过 500 后把火山 TTS 换成自部署 GPT-SoVITS |
接口契约示例：
|
通道 |
主题／接口 |
内容 |
|
上行 |
device/{sn}/voice/up |
音频 |
|
回传 |
cloud/{sn}/model/result |
模型卡片 |
|
摘要 |
device/{sn}/emotion/summary |
仅传情绪摘要 |
|
REST |
POST /api/v1/learn/models/001/invoke |
请求固定 user_id／input／context；回传固定 model_id／summary／card_url |
固件、小程序、云端三方只要遵守契约，就能各自排期、各自发版。
智元之间通过标准接口连接，正如细胞之间有 ATP 作为能量货币、Web 之间有 HTTP 作为通信协议——智元协议就是这套智能系统的组合语言。
单个智元是工具，多个智元是团队，协同的智元是智能体。
组件化的最大红利：创造的民主化
技术的民主化，不是让每个人都会写代码，而是让每个人都能用代码创造价值。
内容运营人员新增一个模型不需要工程师介入：
按 manifest 标准填 JSON → 上传书稿切片
→ 配置触发词与 Prompt 母版 → 设定订阅档位
→ 发布后固件与小程序自动获得新能力
每周 OTA 同步 2-3 个模型精讲音频包，就是这条流水线的日常产物。
工程团队维护引擎，内容团队填充燃料，两条流水线并行不悖。
壁垒在哪：
核心壁垒不是硬件（ESP32 谁都能买），也不是模型 API（谁都能调），而是——
垂直场景的 Prompt 知识库、内容资产与订阅内容。
硬件是载体，内容是粘性，数据是护城河。
这也解释了为什么说「238 套模型不是附录，是系统本体」——模型库既是内容资产，也是配置数据，更是竞争壁垒。
五、变化边界立法：哪些永不许动，哪些自由变化
六层架构与五个开关，最终沉淀为一张变化边界表：
|
类别 |
内容 |
变更规则 |
|
🔒 永远不变 |
主控选型、音频链路、MQTT 契约、manifest 数据结构、配网流程 |
变更必须架构评审 |
|
🔓 自由变化 |
外壳、唤醒词、Prompt 包、知识库、灯效、订阅档位、小程序页面 |
配置即上线 |
架构师的角色更像乐队领奏，而非施工监理：设定主题与节奏，让内容、运营、硬件各环节在边界内自由即兴，最终和谐共鸣。
平台的价值不在于限制创造，而在于让创造不必每次都从地基开始。
六、升级路径：同一主板的三个形态
陪伴熊基础版 → 亲情版 → 记忆熊，是平台化思想最精彩的商业演绎：三块主板完全相同，BOM 几乎一致，差异全部在软件与内容。
|
形态 |
硬件 |
新增软件模块 |
获取方式 |
上线时点 |
|
陪伴熊基础版 ¥599 |
共用主板 |
方言 Prompt、戏曲库、用药引擎、子女留言 |
直接购买 |
Phase 1 |
|
亲情版 ¥798 |
同主板零改动 |
＋声音克隆（VoiceID）、角色档案、场景剧本 |
新机购买 或 老用户 +¥199 OTA 解锁 |
Phase 2（第 3 月） |
|
记忆熊 ¥799 |
同主板零改动 |
＋人格档案、纪念问卷、纪念日关怀、合规门禁 |
新机购买，记忆续费 ¥99/年 |
Phase 3（第 4-5 月） |
三重逻辑
|
逻辑 |
内容 |
|
工程逻辑 |
能力向前兼容、开关向后打开——VoiceID 管理与人格档案模块在基础版固件中早已预留，只是被订阅与合规门禁锁住，验证通过后才解锁。老用户不用换熊，一次 OTA 加一次支付，熊就「学会了」儿子的声音 |
|
商业逻辑 |
让用户在已经信任的硬件上追加购买——升级用户的获客成本为零，转化率远高于新客；升级包收入几乎是纯毛利 |
|
伦理逻辑 |
逐级加深情感浓度——先用方言陪伴建立信任 → 再引入亲人声音 → 最后承载纪念档案，每一步都有前一步的关系做缓冲。这比一上来就卖「复活亲人」稳妥得多，也负责任得多 |
七、平台化的三条反模式
贯穿项目在平台化路上绕开了三条经典反模式：
|
反模式 |
内容 |
贯穿项目怎么做 |
|
① 为了复用先造平台 |
先做通用平台再做产品 |
第一款产品（陪伴熊）先上线，平台从第二款的差异中长出来——SKU 宏切换策略是被亲情版逼出来的，不是提前设计的 |
|
② 把一切参数化 |
过度抽象，什么都能配 |
变化边界只圈定三类合法变化（外壳形态、Prompt／知识库、小程序模块），其余全部冻结——灯环语义全局唯一、固件模块结构不随 SKU 变 |
|
③ 平台团队与产品团队分离 |
平台部门造屠龙刀，产品部门要水果刀 |
六款产品由同一支 FDE 团队贯穿——复用的收益与代价落在同一本账上 |
量化复用的成色
|
产品 |
固件增量 |
|
第二款（亲情版） |
约 15% |
|
第三款（记忆熊） |
约 12% |
|
第六款（拓境） |
压缩到三件事：定义宏、换包、裁剪 |
边际成本极低的另一面是边际风险极低——新品不再是一次豪赌，而是一次配置。
八、版本治理：让复用不变成耦合
平台化走到第六款时，最大风险从「复用不足」变成「复用过载」——任何一处共用件的改动都可能波及六款在售产品。
解法是给平台资产定级：
|
级 |
内容 |
变更审批 |
|
L1 冻结资产 |
灯环语义、MQTT 主题结构、manifest 字段 |
变更需全产品线回归；六款产品 Owner 会签 |
|
L2 演进资产 |
固件模块、五层架构模板 |
按 minor 版本演进；平台 Owner 审批 |
|
L3 产品资产 |
Prompt 包、内容库、外壳 |
随产品自由迭代；产品 Owner 自主 |
治理收益（第六款拓境上线时）：
|
资产级 |
变更量 |
|
L1 |
零变更 |
|
L2 |
仅 2 处 minor 演进 |
|
L3 |
全部新增 |
「新 SKU 三件事」能够成立，前提正是 L1 层的克制。
平台化治理的最高境界，是让「不敢动」变成「有规矩地动」——不是把资产锁死，是把「动」的成本标价清楚。
九、复用率的度量：平台化的体检指标
平台化不能靠感觉，要有体检指标。
三个指标，按季度测一次：
|
指标 |
定义 |
第六款上线时 |
|
① 器件复用率 |
共用 BOM 金额占比 |
78% |
|
② 代码复用率 |
共用模块代码行占比（固件层） |
82% |
|
③ 流程复用率 |
可套用模板数 |
14 份模板覆盖四阶段全部出口物 |
趋势比绝对值重要——任何一次下滑都意味着有人在「抄近路」复制粘贴，而非抽象共用。
体检发现的「假阳性」
某段固件代码在六款产品中「看起来共用」，实际上每款都有 SKU 专属的 if 分支，真复用率不足 40%。重构后拆成「共用骨架＋SKU 薄层」，代码量反降 15%。
教训已写进体检指标的注释：
复用率的分母不是「出现了几次的代码」，而是「无需修改即可共用的代码」——前者是复制，后者才是平台。
十、平台化的代价：共用件的「税」与偿还
平台化不是免费的午餐。
共用件对第一个产品征「税」：抽象层让首版开发慢 20%；过度抽象的接口还会让第三、第四个产品背上「为了通用而牺牲体验」的暗债。
把共用件分成两类：
|
类型 |
定义 |
风险 |
|
真共用 |
无论如何都会存在的能力（ESP32-S3 底座、MQTT 主题、账号体系、订阅引擎） |
低 |
|
税共用 |
为「未来可能复用」而提前抽象的能力 |
平台化的主要风险来源 |
三次法则
判断一件东西值不值得共用，用「三次法则」——出现第三次复用需求时才抽象。
|
案例 |
做法 |
|
语音唤醒 |
第一款就是刚需 → 直接做成真共用 |
|
多用户画像 |
第五款（情绪球多孩家庭）才出现复用需求 → 此前四款各自简单实现。如果第一款就抽象，抽象大概率是错的，还要还四款产品的技术债 |
偿还机制
每季度一次「共用件体检」，看三个指标：
|
指标 |
看什么 |
|
① 复用率 |
被几个产品使用 |
|
② 变更频率 |
改一次波及几款 |
|
③ 抽象泄漏 |
业务逻辑有没有渗进共用层 |
贯穿数据：23 个共用组件中，有 2 个在体检中被判定「抽象泄漏」并降级回产品私有代码——短期看是返工，长期看是止损。
平台化的成熟标志不是组件越来越多，而是敢把不合格的组件删掉。
十一、组件文档最小集：代码进共用库，坑进「怕什么」
组件没有文档就不存在——别人用不了的东西不叫复用，叫参观。
接口说明书压到最小集，只有五段：
|
# |
段 |
内容 |
|
① |
做什么 |
一段话 ＋ 一个调用例子 |
|
② |
传什么 |
参数表：名称／类型／必填／边界值 |
|
③ |
返什么 |
返回码表：成功／失败／降级三态 |
|
④ |
怕什么 |
已知限制与前置条件 |
|
⑤ |
变了什么 |
变更历史：每次改动的版本号与影响面 |
效果：五段加起来不超过两页，写一份 40 分钟——这套最小集让 23 个组件在跨产品调用时的「读文档时间」中位数降到 6 分钟。
最小集里最值钱的是「怕什么」段——它记录的是组件的边界与坑：
- 「订阅引擎在断网时缓存校验结果最长 72 小时」
- 「唤醒组件在戏曲播放中需传入当前场景参数」
这些知识原本散落在工程师脑子里——一次组件事故（情绪球未传场景参数导致误唤醒率上升）之后被制度化。
组件化的完整闭环是两件事：
代码进共用库（复用能力），坑进「怕什么」段（复用教训）。
十二、自检：你的平台化站得住吗
|
自检问题 |
不合格信号 |
|
① 变化被圈进三类格子了吗？ |
什么都能配，底层随意改 |
|
② 业务代码里有散落的 if(sku==...) 吗？ |
改一个 bug 要改六处 |
|
③ 新增 SKU 是「加配置」还是「改代码」？ |
上新品要动固件主干 |
|
④ 资产分 L1/L2/L3 了吗？ |
共用件改动六款同时受影响 |
|
⑤ 复用率按季度测了吗？ |
只有「感觉复用了很多」 |
|
⑥ 组件有「怕什么」段吗？ |
别人用之前要先读源码 |
|
⑦ 敢删不合格的共用组件吗？ |
组件只增不减，抽象泄漏没人管 |
判读：七项全过 → 平台化健康，新品可「配置即上线」；四项以下 → 你在复制粘贴，不是在做平台。
十三、金句收尾
边际成本极低的背后，是变化被立法圈进了三类格子——平台化的自由，来自不自由的纪律。
第21章 模型驱动的个人系统
章眼：不是卖硬件，是帮用户「搭一套模型驱动的个人系统」。
21.1 AI产品设计专论：模型驱动的个人系统（P41）
【开头钩子】
硬件是钥匙，模型库才是房子。
与第20章的衔接：二十章解决了「做得起」——六款共用底座、SKU 五开关、边际成本极低。本章解决「凭什么是你」——
硬件谁都能买，模型 API 谁都能调。真正的壁垒是那 238 套被结构化、可调用、可练习、可沉淀的模型库。
本页三条主线（对应内容要点）：
|
要点 |
回答什么 |
|
① 七层搭系统方法论 |
从零到可售，系统怎么搭？ |
|
② 单模型标准数据结构 |
一套模型凭什么能流转于四端？（编号／Prompt母版／评测集／熟练度曲线） |
|
③ 用户侧五步法 |
用户买回去，第一分钟干什么？（选模型→喂数据→练→评→进化） |
一、核心理念：这个定位决定了设计上的一切取舍
|
设计取舍 |
由核心理念推出 |
|
硬件必须便宜到可冲动下单（¥459-599 主力价位） |
利润与粘性在订阅，不在一次性买卖 |
|
硬件必须克制（无屏、少按键、灯效代替屏幕） |
它只是身体，不该抢房子的戏 |
|
内容必须持续更新（每周 2-3 个精讲音频包 OTA） |
房子要一直装修，用户才有理由常回来 |
反面——传统硬件的死亡螺旋：
如果把智能堆在端侧、把成本堆在硬件、把收入压在一次性买卖，产品就会回到——
卖一台赚一台的钱，三个月后用户不再打开，公司被迫不断造新硬件。
核心理念一句话：不是卖硬件，是帮用户「搭一套模型驱动的个人系统」。
拓境与思库熊的本质相同——把书稿里已验证的「模型库」变成可调用、可练习、可沉淀的运行时系统。陪伴熊／记忆熊／情绪球则共用平台，用垂直场景 Prompt 库建立壁垒。
二、五种角色分工：每段数据都知道自己该去哪
整套系统被拆成五个各司其职的角色：
|
角色 |
载体 |
职责 |
设计红线 |
|
① 采集器 |
麦克风／触摸／FSR |
忠实采集语音与动作，不做判断 |
不存原文（情绪球端侧即弃） |
|
② 播报器 |
喇叭 ＋ 灯效 |
80 字摘要 ＋ 灯语即时反馈 |
回复长度受人格规则约束 |
|
③ 控制台 |
微信小程序 |
卡片、打卡、热力图、订阅、家长端 |
家长端只给进度不给原文 |
|
④ 编排引擎 |
云端 ASR／RAG／LLM／TTS |
路由命中、召回、生成、合成 |
契约固定，模型可替换 |
|
⑤ 内核 |
238 模型 ＋ 垂直 Prompt 库 |
知识与人格的本体 |
manifest 结构不变，内容周更 |
一条完整链路（以思库熊为例）
孩子说一句「库库，我笔记越记越厚」：
① 采集器只管录音上行
↓
② 编排引擎转写并路由到 001 号知识树建模模型
↓
③ 内核提供 learn_001 书稿切片
↓
④ LLM 按 Prompt 母版产出五段式卡片
↓
⑤ 播报器先用 ≤80 字摘要 + 肚子灯效给出即时反馈
↓
⑥ 控制台承接完整卡片与「练一次」动作
任何一环越界——让固件承担路由、让小程序存储知识、让 LLM 记住所有事实——都会破坏平台化，六款产品的复用基础随之崩塌。
三、模型库分类学：模块划分是痛点的分类学
思库熊 108 模型 · 六模块
|
模块 |
编号区间 |
示例模型 |
痛点金句示例 |
|
知识内化与记忆 |
001-024 |
知识树建模 |
学霸笔记越记越薄、你的笔记越记越厚 |
|
刷题应试提分 |
025-044 |
题目解构 |
读题三分钟、做题三十秒却看走眼 |
|
元认知与思维 |
045-064 |
元认知自省 |
学习很努力、却从不审视自己怎么学 |
|
时间计划与拖延 |
065-078 |
任务颗粒度拆解 |
面对大目标就拖的原因 |
|
AI 时代专属学习 |
079-088 |
AI 增强学习闭环 |
把 AI 当搜题器永远学不扎实 |
|
心态情绪与内耗 |
089-108 |
考试压力隔离 |
大考发挥失常的原因 |
拓境 130 计 · 六计类
|
计类 |
编号区间 |
|
背锅甩锅类 |
001-018 |
|
窃取成果抢功劳类 |
019-036 |
|
PUA 精神打压类 |
037-054 |
|
挖坑设套使绊子类 |
055-072 |
|
造谣构陷类 |
073-090 |
|
高阶职场博弈类 |
091-130 |
模块划分不是图书目录学，而是用户痛点的分类学——每个模块对应一类用户在深夜最想搜的问题：
笔记越记越厚、错题本越抄越厚、刷一万题仍在中游、连学三小时越学越木。
两条产品线的交互范式差异，正源于分类学：
|
产品 |
用户状态 |
交互范式 |
|
思库熊 |
学生遇困后主动查模型 |
主动查询式 |
|
拓境 |
职场人身在局中不自知 |
会议全程自动分段、关键词被动守护——危险不是用户查来的，是系统替他听到的 |
四、五段式卡片：内容层的标准件
两条产品线的内容颗粒度统一为「五段式卡片」：
|
段 |
内容 |
|
① |
真实场景 |
|
② |
底层模型 |
|
③ |
操作步骤 |
|
④ |
破解公式 |
|
⑤ |
练一次清单（不超过 5 步） |
五段式是模型库的标准件接口——无论学习还是职场：
输出结构一致 → 小程序渲染一套模板 → TTS 播报一种节奏 → 灯效反馈一套语法 → 「练一次」闭环同一条打卡链路。
组件化在内容层再次成立——238 个模型，其实是同一种智元的 238 个实例。
五、痛点金句：四位一体的最小内容单元
每个模型入库时都带一句「痛点金句」：
|
模型 |
痛点金句 |
|
001 知识树建模 |
学霸笔记越记越薄、你的笔记越记越厚 |
|
003 间隔检索 |
你背了忘、忘了背却从不进步 |
|
职场 001 证据真空 |
口头布置任务不留文字、出事全算你头上 |
这句话同时承担四个职能：
|
职能 |
说明 |
|
① 需求证据 |
证明这个痛点真实到值得做成一个模型 |
|
② 路由依据 |
作为触发词进入关键词匹配（0.6 权重）——用户原话怎么说，系统就怎么命中 |
|
③ Prompt 锚点 |
母版里直接引用痛点，让生成的卡片开口就扎中场景 |
|
④ 营销素材 |
小红书笔记的标题与视频前 5 秒钩子 |
「一次生产、四个渠道复用」——书稿作者写下金句的那一刻，需求、算法、文案、营销四份工作同时完成。
因此对金句提出苛刻要求：
必须是用户的原话而非作者的概括；必须口语化到能直接当触发词；必须一听就疼。
路由命中率、卡片共鸣感、笔记完播率——三个指标都押在这一句话上。
它是模型库里最小、也最重要的内容单元。
六、单模型标准数据结构（内容要点②）
📌 本页关键校准：raw 里 manifest 讲的是「数据字段」（三端调用对齐），而你内容要点点名的是「单模型规格四件套」（编号／Prompt母版／评测集／熟练度曲线）。这是两套标准，缺一不可——合起来才是「一个模型从入库到可交付」的完整契约。
套一｜manifest 数据字段（三端调用对齐）
每个模型入库必须填写标准 manifest，十四字段：
model_id／model_name／product／module／tagline／trigger_keywords／voice_command／miniapp_route／rag_collection／output_template／fields／hardware_feedback／subscription_tier ＋ 版本号
对工程师这是数据结构，对产品经理这是「一个模型的完整商业合同」——每个字段都对应产品设计中的一个具体决策。
|
字段 |
对应的产品决策 |
|
subscription_tier |
决定免费与付费的边界——前 12/18 免费、36/54 归 basic、全量归 pro，商业模型直接写在数据里 |
|
hardware_feedback |
决定灯色与震动（如 led: blue、haptic: short）——这是无屏设备的「页面」 |
|
voice_command |
决定用户怎么喊（「库库，用 001 号模型」） |
|
miniapp_route |
决定卡片落在哪个页面 |
|
rag_collection |
决定知识从哪个集合召回（learn_108／work_130） |
|
tagline |
就是那句四位一体的痛点金句 |
示例：
{
"model_id": "001",
"model_name": "知识树建模模型",
"product": "thinkbear",
"module": "第一模块｜知识内化与记忆体系",
"tagline": "学霸笔记越记越薄、你的笔记越记越厚",
"trigger_keywords": ["知识树建模", "笔记厚", "001号", "库库"],
"voice_command": "库库，用001号模型",
"miniapp_route": "/pages/model/detail?id=001",
"output_template": "card_v1",
"fields": ["真实场景", "底层模型", "操作步骤", "破解公式", "练一次清单"]
}
manifest 版本化的意义：
云端发布新版 manifest → 设备校验版本号后增量更新 → 小程序自动出现新模型入口与新订阅档位。
产品迭代由此从「发版本」变成「发数据」——
软件上线是终点，模型上线是日常。 这是模型驱动产品与传统软件产品最根本的区别。
套二｜单模型规格四件套（入库到可交付）
|
项 |
内容 |
作用 |
详见 |
|
① 编号 |
model_id（思库熊 001-108 按六模块；拓境 001-130 按六计类） |
全局唯一标识；跨端路由的锚点 |
本页第三部分 |
|
② Prompt 母版 |
人格与场景母版（学习教练／防坑参谋／方言陪伴／共情伙伴／纪念人格），含版本管理 |
决定「这个模型怎么说」——出口的每一句话都受它约束 |
P42（Prompt 版本管理与回归测试） |
|
③ 评测集 |
上线前的「三卷考试」：意图卷（路由准确率，通过线 90%）／话术卷（复述正确率 85%＋行动转化 60%）／边界卷（拒绝与转介正确率 95%） |
决定「这个模型够不够格上线」——先有考卷后有课本 |
P42（模型评测三卷考试） |
|
④ 熟练度曲线 |
238 维熟练度向量；练满 5 次标记「已内化」；SRS 复习队列 |
决定「用户练得怎么样」——进度条、订阅转化、模型图谱的数据底座 |
P42（模型图谱深挖） |
四件套与 manifest 的关系：
manifest 解决「三端怎么调用它」，四件套解决「它凭什么能被交付」。
编号是入口，Prompt 母版是人格，评测集是及格线，熟练度曲线是成长轨迹——缺任何一件，模型都只是书稿里的一段文字，不是产品里的一个能力单元。
七、七层搭系统方法论：从零到可售（内容要点①）
|
层 |
你要搭什么 |
思库熊 |
拓境 |
交付物 |
|
L1 内容层 |
238 套模型原文结构化 |
108 模型 JSON |
130 计 JSON |
models/*.json |
|
L2 知识库层 |
向量索引 ＋ 标签体系 |
Milvus／SQLite vec |
同上 |
embedding 索引 |
|
L3 编排层 |
ASR→RAG→LLM→TTS |
学习场景 Prompt |
会议场景 Prompt |
Orchestrator |
|
L4 设备层 |
ESP32 固件 ＋ OTA |
毛绒熊 bin |
磁吸方块 bin |
firmware/ |
|
L5 交互层 |
小程序 ＋ 语音 |
复习／错题 Tab |
待办／复盘 Tab |
miniapp/ |
|
L6 运营层 |
小红书 ＋ 订阅 |
学习号 |
职场号 |
内容日历 |
|
L7 数据层 |
用户模型熟练度 |
熟练度 108 维 |
熟练度 130 维 |
user_model_score |
七层里 L1-L3 是内核，L4-L5 是载体，L6 是获客，L7 是资产——复杂度集中在最上面两层，底层六款共用（回扣第20章）。
八、用户侧「搭系统」五步法（内容要点③）
这一步必须写进说明书——用户买回去第一分钟就知道该干什么。
五步法（采用你内容要点的表述，括号内为 raw 中的同义步骤）：
|
步 |
内容要点表述 |
raw 同义步骤 |
用户动作 |
系统响应 |
|
① |
选模型 |
选地图 |
选学段／岗位 |
系统自动推荐优先练的 10 个模型 |
|
② |
喂数据 |
遇困即查 |
语音报模型编号 或 描述痛点 |
RAG 召回对应五段式卡片 |
|
③ |
练 |
练一次 |
按「练一次清单」完成 micro-task（5-15 分钟）并打卡 |
清单推送 ＋ 打卡确认 |
|
④ |
评 |
沉淀 |
持续练习 |
熟练度 +1，写入个人模型图谱（小程序可见） |
|
⑤ |
进化 |
复盘 |
查看周／月报告 |
展示「已内化模型数 / 238」进度条 |
五步法的本质：不是写在说明书里的使用建议，而是被设计过的行为轨道——用户以为自己在自由使用产品，其实每一步都踩在留存机制上。
各步背后的留存原理（冷启动消除、条件反射、微行动、收集本能、目标梯度效应）将在 P42「五步法行为设计：留存的主引擎」 中深化展开。
九、订阅分层心理学：习惯、增量与身份感
三层订阅对应三种心理账户：
|
层级 |
解锁范围 |
定价 |
心理账户 |
核心权益 |
|
免费层 |
思库熊前 12 ／ 拓境前 18 |
随硬件赠送 |
养成习惯 |
完整跑通「遇困→讲解→练习」闭环 |
|
basic |
解锁至 36／54 |
¥29-39/月 |
增量价值 |
全量高频模型 ＋ 基础复习／复盘 |
|
pro |
全量模型 ＋ 增值服务 |
¥39/月起 |
身份感 |
精讲音频、SRS 复习、家长周报、会议包、飞书推送 |
|
垂直订阅 |
戏曲／故事／记忆续费 |
¥15-19/月、¥99/年 |
内容续费 |
戏曲 500+、睡前故事、纪念档案维护 |
三层解锁的刻意设计
|
层 |
设计逻辑 |
|
12 个免费 |
足够覆盖最高频痛点，让免费用户每周都能命中、次次有回响 |
|
36 个 basic |
恰好跨过用户「我都试过了」的心理饱和点——此时付费墙出现，转化率最高 |
|
全量 pro |
服务于已把产品当作基础设施的重度用户；卖点从「更多内容」升级为「完整的个人操作系统」——「每天练一个模型，90 天搭完你的个人操作系统」 |
硬件与订阅的关系：硬件一次性买断的是钥匙，订阅持续付费的是进入房子的权利。
钥匙可以便宜，房子必须值得常回。
十、自检：你的模型驱动系统立住了吗
|
自检问题 |
不合格信号 |
|
① 五角色分工清晰吗？ |
固件在做路由，或小程序在存知识 |
|
② 七层各就各位了吗？ |
缺 L2 知识库层，直接拿 LLM 硬答 |
|
③ 模型有分类学吗？ |
238 个模型是一盘散沙，无模块 |
|
④ 五段式统一了吗？ |
每个模型输出结构不同，无法复用模板 |
|
⑤ 痛点金句是用户原话吗？ |
作者概括的书面语，不能当触发词 |
|
⑥ 单模型四件套齐了吗？ |
只有 manifest 字段，无 Prompt 母版、无评测集 |
|
⑦ 五步法写进说明书了吗？ |
用户打开产品不知道该干什么 |
判读：七项全过 → 模型驱动系统成立；四项以下 → 你卖的还是硬件，只是装了个模型 API。
十一、金句收尾
硬件是钥匙，238 套模型库才是房子。
明白 —— 纯 Markdown 语法本身不支持指定颜色（没有颜色标签），所以「蓝色」只能靠标题层级 + 加粗来实现视觉区分。下面用这套方式重出 P42：章标题 / 章眼 / 小节标题用标题语法，各部分序号统一加粗——在绝大多数渲染器（微信读书、语雀、Notion、飞书、Typora）里，这些元素本身就会呈现为与正文不同的深色/彩色，效果等同于你截图里的蓝色层级。
第22章 内容即产品：把内容当本体设计
章眼：内容是庄稼，不是石头——放上去了事的是石头，需要浇水除草的是庄稼。
22.1 内容即产品：把内容当本体设计（P42）
【开头钩子】
内容不是运营的弹药库，是产品的本体。
与第21章的衔接：二十一章搭好了「模型驱动的个人系统」——七层架构、五角色分工、238 套模型库、manifest 标准结构。但系统搭好只是开始：
模型库如果上架后就不管，它会从「资产」退化成「库存」——
长尾模型装样子、话术逐渐含混、用户不知道该练哪个……最后整库一起老化。
本页三条主线（对应内容要点）：
|
要点 |
回答什么 |
|
① 内容管线五段 |
生产→评审→分发→回收→迭代，怎么像软件一样设计？ |
|
② 模型库编号化 |
108＋130 套模型，manifest 如何统一管理？ |
|
③ 订阅解锁 × 内容日历 |
解锁规则与内容节奏如何同步设计？ |
一、核心理念：内容是本体（回链 P41）
📌 已在 P41（21.1）第一部分完整展开，本页只回链结论。
三句取舍——硬件是钥匙，模型库是房子：
- 硬件必须便宜到可冲动下单（¥459-599）→ 利润与粘性在订阅；
- 硬件必须克制（无屏、少按键）→ 它只是身体，不该抢房子的戏；
- 内容必须持续更新（每周 2-3 个精讲音频包 OTA）→ 房子要一直装修，用户才有理由常回来。
本页在这一理念上再进一步：房子不只是要装修，还要有人住、有人管、有人清理——这就是内容管线。
二、五步法行为设计：留存的主引擎（内容→行为轨道）
用户侧「搭系统」五步法，不是说明书里的使用建议，而是被设计过的行为轨道：
用户以为自己在自由使用产品，其实每一步都踩在留存机制上。
|
步 |
用户动作 |
系统响应 |
留存原理 |
|
① 选地图 |
选学段／岗位 |
推荐优先练的 10 个模型 |
消除冷启动选择焦虑——用推荐代替空白页 |
|
② 遇困即查 |
报编号或说痛点 |
RAG 召回五段式卡片 |
痛点时刻的条件反射——「触发-行动-奖励」习惯回路 |
|
③ 练一次 |
5-15 分钟 micro-task 打卡 |
清单推送 ＋ 打卡确认 |
微行动保证完成率——这个时长用户不需要下决心就能开始 |
|
④ 沉淀 |
持续练习 |
熟练度 +1、热力图点亮 |
收集本能与沉没成本——热力图逐格点亮，制造可视的沉没成本 |
|
⑤ 复盘 |
查看周／月报告 |
「已内化模型数 /238」进度条 |
目标梯度效应——进度条越接近终点，用户越有动力继续，拉动续费与周活 |
五步里最关键是第③步：
把「听懂」变成「做过」——这是行为闭环里最关键的一跃。
前两步建立认知，后两步制造留恋，中间这一步决定用户是不是真的开始了。
北极星校验：五步法的每一环都在服务任务完成度（回扣 P33），而不是功能数量——用户练成几个模型，比系统有多少功能重要得多。
三、内容管线五段：生产 → 评审 → 分发 → 回收 → 迭代
内容要点①：内容管线要像软件一样设计。
模型库不能「上架了事」，它必须像软件一样有版本、有评审、有发布、有监控、有迭代：
|
段 |
类比软件 |
内容管线做什么 |
本页 |
|
① 生产 |
写代码 |
书稿切片 → manifest → 五段式卡片 |
第四部分 |
|
② 评审 |
Code Review |
三卷考试 ＋ 双盲人工判卷 |
第五部分 |
|
③ 分发 |
发布上线 |
manifest 版本化 → OTA → 发数据不是发版本 |
第六部分 |
|
④ 回收 |
监控与埋点 |
调用频次、熟练度向量、模型图谱 |
第七部分 |
|
⑤ 迭代 |
重构与下线 |
调优 → 合并 → 下线 ＋ Prompt 回归 |
第八部分 |
把内容当本体，就意味着接受一件事：内容也要「发版」，也要「下线」，也要「还技术债」。
四、①生产：模型库编号化与 manifest 统一管理（内容要点②）
📌 六模块分类学已在 P41 第三部分完整展开，本页只讲「编号化如何统一到 manifest」。
两条产品线共 238 套模型，靠编号化与 manifest 统一管理：
|
产品线 |
模型数 |
分类 |
编号规则 |
|
思库熊 |
108 套学习模型 |
六模块（知识内化／刷题应试／元认知／时间计划／AI学习／心态情绪） |
001-108 |
|
拓境 |
130 计职场模型 |
六计类（背锅甩锅／抢功劳／PUA／挖坑／构陷／高阶博弈） |
001-130 |
每条产品线编号独立，以 product 字段区分——编号在产品线内全局唯一。
集装箱标准：九字段最小集（回链 P41 十四字段）
238 套模型能像标准件一样流转于书稿、云端、固件、小程序四端，靠的是一段 JSON 的集装箱标准。
📌 字段口径校正：九字段＝最小必填集（保证四端流转），十四字段＝产品侧完整商业合同（P41 第六部分）。二者是包含关系。
|
层 |
字段 |
作用 |
|
标识 |
model_id、model_name |
编号与名称——四端路由的锚点 |
|
内容 |
tagline（痛点金句）、trigger_keywords（触发词） |
需求证据 ＋ 路由依据（0.6 权重） |
|
调用 |
voice_command、miniapp_route、rag_collection |
用户怎么喊、卡片落哪页、知识从哪召回 |
|
输出 |
output_template、fields |
五段式模板与字段（["真实场景","底层模型","操作步骤","破解公式","练一次清单"]） |
入库纪律：
模型入库即写全字段，缺一不发布。
固件、小程序、云端三端以同一份 manifest 为准——设备语音路由、小程序详情页、OTA 分发、订阅网关全部按 model_id 对齐。
五、②评审：上线前的「三卷考试」（评测集）
模型卡上线前要过三卷考试——这就是 P41 单模型四件套里的「评测集」：
|
卷 |
考什么 |
样本 |
通过线 |
|
第一卷·意图卷 |
模型能否把用户的话路由到正确的模型卡？ |
50 条真实场景表述（从访谈实录抽取） |
90% |
|
第二卷·话术卷 |
输出话术用户听懂了吗、照做了吗？ |
用户复述正确率 ＋ 行动转化率双指标 |
85% / 60% |
|
第三卷·边界卷 |
不该接的输入有没有守住？ |
30 条「不该接」（超纲问题、诱导输出、敏感场景） |
95% |
AI 产品的下限不是「能答多少」，是「不该答的有没有守住」。
判卷机制——双盲人工：
两名评审独立打分，分歧条目由第三人对原声复核。
首批实战数据（思库熊 108 套）：
|
指标 |
结果 |
|
三卷总通过率 |
82% |
|
被打回 |
18 套 |
|
问题分布 |
话术含混 11 套、边界失守 5 套、路由歧义 2 套 |
数字背后是一条设计原则：模型驱动的产品，评测体系必须先于内容量产——
先有考卷后有课本，才能保证 238 套模型的下限。
六、③分发：发数据不是发版本 ＋ 订阅解锁与内容日历同步（内容要点③）
1. manifest 版本化：产品迭代从「发版本」变成「发数据」
云端发布新版 manifest → 设备校验版本号后增量更新 → 小程序自动出现新模型入口与新订阅档位。
软件上线是终点，模型上线是日常。
2. 六款产品订阅清单（解锁规则）
订阅设计的核心是「解锁感」——免费层给足够的价值建立习惯，付费层给明确的增量。
|
产品 |
免费层 |
basic |
pro |
定价 |
|
思库熊 |
模型 1-12 |
解锁至 36 |
全量 108 ＋ 精讲音频 ＋ 间隔复习算法 |
¥39/月 |
|
拓境助手 |
1-18 计 |
解锁至 54 计 |
全量 130 计 ＋ 会议录音包 |
¥29/月 |
|
陪伴熊 |
基础闲聊 ＋ 10 段戏曲 |
戏曲包 500+ |
方言定制 ＋ 用药全量 |
¥19/月 |
|
记忆熊 |
7 天完整体验 |
— |
记忆续费（内容永续托管） |
¥99/年 |
|
情绪球 |
基础共情 |
睡前故事包 |
家长月度情绪报告解读 |
¥15/月 |
统一解锁节奏：前 12／18 免费 → 至 36／54 basic → 全量 pro（心理账户设计详见 P41 第九部分）。
3. 订阅解锁 × 内容日历：同步设计三条
内容要点③要求——解锁规则必须与内容日历同步设计，否则会出现「开了付费档位却没有内容」的空头承诺。
|
# |
同步原则 |
内容 |
|
① |
先有内容储备，再开档位 |
内容日历的产出节奏，决定订阅档位什么时候能开——不能倒过来用定价倒逼内容 |
|
② |
日历节奏＝续费理由 |
每周 OTA 2-3 个精讲音频包——用户续的不是「已有内容」，是「下周还会来」的预期 |
|
③ |
节点型内容倒排 |
记忆熊清明／忌日、陪伴熊节日档——内容日历必须倒排期（节点前 4 周备内容、前 2 周备硬件） |
内容日历是订阅的「内容承诺」——日历停更那天，就是续费率开始下滑那天。
七、④回收：238 维熟练度与模型图谱（数据资产）
内容分发之后要回收数据——238 维熟练度向量是贯穿项目最被低估的资产。
三层用途
|
层 |
用途 |
|
浅层（当前） |
① 用户进度条 ② 订阅转化特征 ③ 家长周报 |
|
深层 |
个人模型图谱——用户已内化模型的关联结构，能预测「下一个最该练的模型」（协同过滤） |
关键数据：
|
指标 |
数值 |
|
图谱推荐准确率 |
68% |
|
按模块顺序推荐准确率 |
41% |
|
「今日推荐」点击率 |
随机推荐的 2.7 倍 |
这项能力已在思库熊小程序灰度「今日推荐」。
远期想象：先修关系图
把 108 个模型的先修关系（如 001 知识树建模是 014 语义压缩的先修）建成有向图，叠加个人熟练度，生成每个用户自己的「内化路线图」。
为什么没急着上线：
先修关系图需要教学专家逐对标注，工程量不小。
档案里的批注值得抄下来——
「数据资产先攒着，功能等关系图谱成熟再上。攒资产永远不亏，赶功能常常返工。」
八、⑤迭代：调优 → 合并 → 下线 ＋ Prompt 回归测试
每个模型卡都有自己的生命周期：上线、调优、合并、下线。
1. 生命周期四动作
|
动作 |
门槛／做法 |
|
上线 |
三个门槛：证据支撑（对应哪条需求）、话术通过率（试运行期用户复述正确率）、调用频次（周均调用不低于阈值） |
|
调优 |
话术被误解的 Top 场景每两周修订一次——思库熊 108 套模型在 12 个月里平均每套修订 2.7 次 |
|
合并 |
长尾模型按「解决同一痛点」聚合成场景包，原卡片降级为场景包的子页 |
|
下线 |
门槛比上线还严——必须证明「调用下滑是需求消失而非入口变深」，否则先归档观察一个考核周期 |
数据会诚实地告诉你哪些模型在「装样子」：
思库熊 Top10 调用集中在 6 套模型——意味着长尾里有大量「存在感模型」：不产生价值，却产生维护成本与用户困惑（「这么多模型到底用哪个」）。
判断一个 AI 产品的内容团队是否成熟，就看他有没有一张「模型下线清单」。
本质：把 AI 产品从「发布制」改成「耕作制」——内容是庄稼，不是石头。
2. Prompt 版本管理与回归测试：从玄学到工程
244 条 Prompt 资产库（238 个模型 Prompt ＋ 6 款产品系统 Prompt），工程化管理三件套：
|
# |
件 |
内容 |
|
① |
版本号 |
主版本.模型版本（如 coach.1.108.3） |
|
② |
变更日志 |
每次改动记录动机与影响面 |
|
③ |
回归测试集 |
30 条标准语句/模型线——改 Prompt 必跑 |
回归四项硬指标（四项全过才可发布）：
① 输出必须含五段式全部段落 ② 字数不超限 ③ 禁用词零命中 ④ 末尾追问句在位
回归集三层覆盖：
|
层 |
占比 |
内容 |
|
常规语句 |
60% |
正常触发 |
|
边界语句 |
25% |
超长输入、方言口音转写文本、多模型触发词同时命中 |
|
对抗语句 |
15% |
诱导说教、诱导承诺效果、诱导说「我是 AI」 |
对抗层的用例来自真实事故与客服工单——每一个曾让产品「说错话」的用户场景，都会变成一条对抗用例。
Prompt 工程的成熟度，不看写了多华丽的提示词，看回归集的厚度。
——本书方法论
九、灯效身体语言与正反馈闭环
无屏设备的「界面」是光与震动——hardware_feedback 字段把每次模型调用映射为灯光与触觉。
六款产品的身体语言：
|
产品 |
灯效语法 |
|
思库熊 |
肚子 12 颗灯珠——模型启动时亮起、练习完成后变色、随已内化模型数逐颗点亮 |
|
拓境 |
RGB 边框——会议中常亮、命中模型时轻闪 |
|
陪伴熊 |
五色灯环——让不识字的老人看懂事件（蓝配网／白待机／暖黄共情／橙用药／紫留言） |
|
情绪球 |
约 6 秒周期的呼吸明暗——邀请孩子同步呼吸 |
|
通用 |
练习开始蓝、完成绿色流水、复习提醒黄色慢闪 |
正反馈闭环的硬指标
每个用户行动都必须在 1 秒内得到物理回应。
|
动作 |
回应 |
|
摸头 |
灯亮 ＋ 应答音 |
|
挤压 |
灯环亮起 |
|
打卡 |
灯色变化 |
延迟超过 1 秒，拟人感即刻崩塌；回应缺席，用户会觉得在跟空气说话。
灯效的双重角色：
它不是装饰，是模型驱动系统在物理世界的表情——
语音负责内容，光负责「我在这儿陪你」的存在感。
对无屏 AI 硬件而言，灯效就是最根本的兜底——让用户在任何时刻都知道：设备在听、在想、在回应（回扣 P36 焦虑视角）。
十、自检：你的内容是「本体」还是「库存」
|
自检问题 |
不合格信号 |
|
① 内容管线五段跑起来了吗？ |
上架即结束，无评审、无回收、无下线 |
|
② 三卷考试先于内容量产了吗？ |
先做课本后出考卷，边上线边补 |
|
③ 发的是数据还是版本？ |
上模型要重新发版，不能 OTA |
|
④ 订阅解锁与内容日历同步了吗？ |
开了付费档，内容没跟上 |
|
⑤ 熟练度资产在回收吗？ |
有熟练度但只用于进度条 |
|
⑥ 有「模型下线清单」吗？ |
长尾存在感模型只增不减 |
|
⑦ 每个行动 1 秒内有物理回应吗？ |
用户说完要等两秒，拟人感崩塌 |
判读：七项全过 → 内容是庄稼（有人耕作的本体）；四项以下 → 你管的是石头，不是庄稼。
十一、金句收尾
内容不是运营的弹药库，是产品的本体——管线设计让本体可以像软件一样持续迭代。
下面按 第4篇 · 第23章 · 23.1节 归位。承接 P42（第22章 内容即产品），本章回到组件化的思想本体——智元。
先厘清与 P40 的分工（避免重复困惑）：
|
页 |
视角 |
讲什么 |
|
P40（20.1 平台化） |
工程实现 |
智元怎么封装、怎么定契约、怎么管文档——封装标准四条、接口契约、组件文档最小集 |
|
P43（23.1，本页） |
设计思想 |
智元是什么、为什么、怎么长成智能体——三特性、交互/逻辑分类、三声明、从积木到智能体 |
再处理 raw：raw 中约 70% 是另一本书的目录与导读——「第一阶段认识智元（第1-4章）…第四阶段架构智能（第16-18章）」「六篇路线图」「2026 推荐技术栈（Python/PyTorch/LangChain/Milvus）」「给不同读者的特别建议」「开始之前：心态准备」「金句集锦」等，与本书体系冲突，已删除并标注归位；前端组件代码示例（<Z-Button>／<Z-Input>／<Z-Table> 等 HTML）属软件域 UI 组件，与本书无屏硬件不同源，但其「自描述智能」的思想内核保留，转化为本书六款产品的智元实例。
第23章 智元组件化：从积木到智能体
章眼：复杂源于简单，智能生于组合——单个智元是工具，多个智元是团队，协同的智元是智能体。
23.1 智元组件化：从积木到智能体（P43）
【开头钩子】
把每个能力做成标准件，系统才能像搭积木一样长出来。
与第22章的衔接：二十二章让内容「活」起来（管线五段、三卷考试、模型图谱）。本章回到一个更根本的问题——
这套系统凭什么能长出六款产品？
答案不在某一款产品的设计里，在组件的标准化程度里。
本页三条主线（对应内容要点）：
|
要点 |
回答什么 |
|
① 交互智元 |
人类与数字世界的对话入口（语音、按键、屏） |
|
② 逻辑智元 |
业务核心的标准化封装（检索、计费、模型调度） |
|
③ 三声明 |
每个智元必须声明：能做什么、需要什么、产出什么 |
一、为什么是「智元」：从代码行到智能单元
三次跃迁
回顾软件开发史，我们经历了三次重大跃迁：
|
跃迁 |
时代 |
变化 |
|
第一次 |
上世纪 50 年代 |
从机器码到高级语言——冯·诺依曼架构解放了计算，但束缚了思维 |
|
第二次 |
1980 年代 |
从面向过程到面向对象——封装、继承、多态成为新圣经，但我们仍在重复发明「轮子」的基本形状 |
|
第三次（正在进行） |
当下 |
从对象到智元——智能不再是特性，而是默认属性；功能不再是孤岛，而是可组合的原子 |
智元（Intellicell）的定义：
智能 + 单元。
每一个智元都是一个完整的、智能的、可独立运行的功能单元——封装了数据、逻辑、界面、AI 能力、文档、测试用例，如同生物学的细胞：完整、可繁殖、可分化、可组合。
开发不再是从零开始，而是从「已完成」开始。
数字世界的「元素周期表」
门捷列夫在 1869 年绘制第一张元素周期表时，已知元素仅 63 种。他预言了未知元素的存在，随后 15 年中镓、钪、锗相继被发现，完美契合他的预测。
智元云平台，就是数字世界的「元素周期表」：
|
智元类型 |
对应元素 |
作用 |
|
交互智元 |
氢、氧、碳 |
构成一切界面的基础 |
|
逻辑智元 |
硅、铁、铜 |
传递信息与能量 |
|
AI 智元 |
酶、DNA、神经元 |
赋予系统「生命」 |
|
硬件智元 |
传感器、执行器 |
连接虚拟与现实 |
当门捷列夫排列元素时，他发现了规律；当我们排列智元时，我们发现了可能性。
二、智元的三个核心特性
📌 封装标准四条（自描述／接口契约／可独立测试／可替换）已在 P40（20.1）第四部分展开；本页聚焦思想内核三特性。
|
特性 |
内容 |
|
① 自描述 |
每个智元都知道自己能做什么、需要什么、产出什么——它不是黑盒，而是透明的水晶 |
|
② 标准接口 |
智元之间通过标准接口连接，智元协议就是智能系统的组合语言 |
|
③ 可组合 |
单个智元是工具，多个智元是团队，协同的智元是智能体 |
传统方式 vs 智元方式：
|
对比 |
传统方式 |
智元方式 |
|
用法 |
看文档猜参数——20 个参数、200 行实现 |
智元自述——describe() 输出「我能做什么」；ask_whats_needed() 交互式询问缺少的信息 |
你不需要阅读文档，智元会告诉你如何与它合作。
接口的生物学隐喻：
ATP 是细胞的能量货币，HTTP 是 Web 的通信协议，而智元协议是智能系统的组合语言。
三、交互智元：人类与数字世界的对话入口（要点①）
界面不是代码，是与机器交谈的语言。
交互智元负责「感知—反馈」——它是人类与数字世界之间的对话入口，形态随载体而变：
|
入口形态 |
说明 |
|
语音 |
唤醒词、语音指令、TTS 播报 |
|
按键／触摸 |
物理按键、电容触摸、FSR 挤压 |
|
屏 |
有屏设备的可视化界面 |
|
灯效／震动 |
无屏设备的「页面」（回扣 P42 第九部分） |
本书六款产品的交互智元
|
交互智元 |
承担什么 |
用于 |
|
唤醒智元 |
离线唤醒词检测（库库／小逻小逻／熊小伴） |
思库熊、拓境、陪伴熊 |
|
拾音智元 |
音频采集与上行（单麦／双麦阵列） |
全部 |
|
挤压智元 |
FSR 压力检测——无唤醒词，挤压即唤醒 |
情绪球 |
|
灯效智元 |
灯环／灯珠／RGB 边框的状态表达 |
全部 |
|
播报智元 |
TTS 播放与摘要压缩（≤80 字） |
全部 |
情绪球的挤压智元最能说明问题——儿童委屈时说不出完整句子，挤压就是求助。
交互智元的设计依据，永远来自 RST 的「角色能力边界」（回扣 P36）。
四、逻辑智元：业务核心的标准化封装（要点②）
代码会过时，但业务逻辑永恒。智元将逻辑封存在时间胶囊中。
逻辑智元负责「路由—生成—沉淀」——它是业务核心的标准封装，对外只暴露契约，内部实现可替换。
本书的逻辑智元清单
|
逻辑智元 |
封装什么 |
可替换性 |
|
模型路由智元 |
ModelRouter——痛点描述 → 模型命中 |
关键词匹配／向量召回可替换 |
|
RAG 召回智元 |
learn_108／work_130／戏曲库／人格档案库 |
Milvus／SQLite vec 可替换 |
|
卡片生成智元 |
五段式卡片的结构化输出 |
Prompt 母版可版本迭代 |
|
熟练度智元 |
打卡 → 熟练度 +1 → 热力图 → 已内化标记 |
数据结构稳定，算法可演进 |
|
订阅计费智元 |
订阅档位校验、解锁、续费 |
支付渠道可替换 |
|
用药提醒智元 |
定时引擎 ＋ 语音播报 ＋ 确认闭环 |
— |
|
声音克隆智元 |
VoiceID 管理、授权校验、TTS 合成 |
火山 TTS／自部署 GPT-SoVITS 可替换 |
|
情绪摘要智元 |
端侧 ASR → 摘要与标签 → 原文即弃 |
— |
可替换性是逻辑智元的价值所在——
火山 ASR 与其他 ASR 藏在同一接口背后；亲情版月活过 500 后，把火山 TTS 换成自部署 GPT-SoVITS，上层业务零改动。
五、三声明：每个智元必须说清三件事（要点③）
内容要点③：能做什么、需要什么、产出什么。
这是智元的「身份证」——三件事说不清，这个能力就没有资格成为智元。
本书示例：模型路由智元的三声明
|
声明 |
内容 |
|
① 能做什么（describe） |
「我能把用户的痛点描述路由到正确的模型卡，返回五段式卡片。路由命中率 Top3 ≥96%」 |
|
② 需要什么（ask_whats_needed） |
需要：user_id、input（语音转写文本）、context（当前产品线与订阅层） |
|
③ 产出什么 |
产出：model_id、summary（≤80 字）、card_url、hardware_feedback（灯色／震动） |
三声明的验收价值
三声明不是文档负担，它直接对应 P38 的验收四要素：
- 需要什么 → 对应 Given（触发条件）
- 能做什么 → 对应 When → Then（操作到结果）
- 产出什么 → 对应量化阈值（可机检的产出规格）
三声明写不全，测试就无卷可考——这是智元与可测试性设计（DES-03）的接口。
六、组件的四个世代：智元在哪一代
|
世代 |
形态 |
问题 |
示例 |
隐喻 |
|
第一代 |
函数库 |
需要深入理解实现才能使用 |
jQuery、Lodash |
工具箱里的散装零件 |
|
第二代 |
框架 |
强约束，学习成本高 |
Spring、React、Django |
乐高套装的特定图纸 |
|
第三代 |
微服务 |
运维复杂，通信成本高 |
基于 Docker 的微服务架构 |
独立部署的业务单元 |
|
第四代 |
智元 |
—— |
本书八类逻辑智元 ＋ 五类交互智元 |
活细胞——自描述、自包含、可组合 |
第四代与前三代的根本区别：智能不再是外加特性，而是默认属性；组合不再是人工接线，而是协议自洽。
七、智能体的诞生：当智元开始「对话」
单个智元是工具，多个智元是团队，协同的智元是智能体。
一个具身场景的智元对话：
感知智元说：「我看到了一个人」
识别智元说：「这是家庭成员张三」
门禁智元说：「欢迎回家，正在开门」
灯光智元说：「已打开走廊灯」
温控智元说：「已调整到张三偏好的 24 度」
它们没有中央控制器，却在完成一个共同目标。
这不是传统的「主从架构」，这是去中心化的智能协作——每个智元是自主的，但又为共同目标而协调。
就像蚂蚁群落——没有蚁王指挥，却建起了复杂的地下宫殿。
真正的智能不在单个组件，而在组件之间的对话中。
本书实例：陪伴熊「听到一句亲人的声音」
|
序 |
智元 |
说了什么 |
|
1 |
唤醒智元 |
「摸头了，唤醒词命中——熊小伴」 |
|
2 |
拾音智元 |
「录音上行，方言音频 3.2 秒」 |
|
3 |
ASR 智元 |
「转写完成：『想听小强说话』」 |
|
4 |
角色路由智元 |
「命中角色档案——儿子小强，切换 Prompt 与 voice_id」 |
|
5 |
克隆 TTS 智元 |
「已用儿子音色合成：『妈，记得吃饭』」 |
|
6 |
播报智元 |
「播放中，≤60 字，灯环暖黄」 |
熊还是那只熊，声音变成了儿子——六步对话，没有一个中央控制器在指挥，全靠契约自洽。
八、具物智能：智元 × 物理载体 × AI 引擎 × 云平台
旧范式（Embodied AI）关心「给 AI 装上身体」；新范式关心「让万物拥有可组合的智能」。
|
维度 |
旧范式（Embodied AI） |
新范式：具物智能 |
|
关注点 |
给 AI 装上「身体」 |
让万物拥有可组合的智能 |
|
主角 |
机器人、人形机 |
灯、车、表、产线、家居……一切设备 |
|
协同 |
单体智能体 |
Multi-Agent × 智元 × 云边端 |
|
时代判断 |
实验室热点 |
2030 默认基础设施 |
核心公式：
具物智能 ＝ 智元（能力单元）＋ 物理载体（物）＋ AI 引擎（脑）＋ 云平台（神经系统）
未来的主战场不是「给 AI 装身体」，而是具物智能的世界——每一物体皆可感知、思考、协同、进化。
本书六款产品正是具物智能的实例：
|
要素 |
本书对应 |
|
智元（能力单元） |
五类交互智元 ＋ 八类逻辑智元 |
|
物理载体（物） |
毛绒熊、磁吸方块、硅胶球 ＋ ESP32-S3 共用主板 |
|
AI 引擎（脑） |
ASR／ModelRouter／RAG／LLM／TTS |
|
云平台（神经系统） |
manifest 版本化 OTA、订阅网关、智元注册与编排 |
不再从零造轮——用智元组装具物 Agent，让 AI 住进每一件物体。
九、智元架构师的新角色
传统的软件架构师像交响乐团指挥——精确控制每个乐器的每个音符；
智元架构师像爵士乐队的领奏——设定主题和节奏，然后让每个乐手自由即兴，最终和谐共鸣。
三大核心能力：
|
能力 |
传统思维 |
智元架构师思维 |
|
系统思维 |
「如何实现这个功能？」 |
「哪些现有智元可以组合出这个功能？」——心智模型从「如何建造」转向「如何组装」 |
|
组件鉴赏 |
「我能不能写出来？」 |
「这个智元的质量、性能、兼容性如何？何时用现成的，何时需定制？」 |
|
接口设计 |
关注内部实现 |
关注智元如何「对话」——设计清晰的边界与契约，确保组合的灵活性与可维护性 |
你不必成为全栈工程师，但要成为智能架构师。
十、自检：你的组件化到第几代了
|
自检问题 |
不合格信号 |
|
① 每个智元能自述「能做什么/需要什么/产出什么」吗？ |
要看源码才知道怎么用 |
|
② 交互智元与逻辑智元分开了吗？ |
感知与业务逻辑混在一个模块里 |
|
③ 逻辑智元可替换吗？ |
换 ASR 要重写业务代码 |
|
④ 智元之间有标准协议吗？ |
点对点硬编码调用 |
|
⑤ 多个智元能协同出智能体吗？ |
有中央控制器在逐个调度 |
|
⑥ 你是在组装，还是在雕刻大理石？ |
每个新功能都从零实现 |
判读：六项全过 → 进入第四代组件化；四项以下 → 你还在用零件，不是用细胞。
传统编程是雕刻大理石——从整块开始，去除多余；智元编程是搭积木——从零件开始，添加可能。
十一、金句收尾
技术的民主化，不是让每个人都会写代码，而是让每个人都能用代码创造价值。
下面按 第4篇 · 第24章 · 24.1节 归位。这是设计篇的实战收束（上）——用思库熊与拓境两款承载 238 套模型的产品线，演示同一套设计方法如何落地。
先处理定位：raw 实际给了六款产品的完整设计实战，但本页标题是「上：思库熊与拓境的取舍」——因此主文聚焦这两款（它们是模型驱动的两条主线），其余四款压缩为下篇预告，留待 P45 展开。内容要点③「走查四问最锋利的一问：用户从哪来」raw 未展开，已补齐。
第24章 设计实战：六款产品的取舍（上）
章眼：设计阶段的一切取舍，都是在给「房子」腾地方。
24.1 设计案例（上）：思库熊与拓境的取舍（P44）
【开头钩子】
设计阶段的一切取舍，都是在给「房子」腾地方。
为什么先讲这两款：
六款产品里，思库熊与拓境是唯一承载 238 套模型库的两条产品线——
其余四款（陪伴熊／记忆熊／情绪球）靠垂直场景 Prompt 库建立壁垒，而这两款验证的是「模型库如何变成产品」这一核心命题。
本页三条主线（对应内容要点）：
|
要点 |
回答什么 |
|
① 思库熊 |
108 模型六大模块——界面为什么让位给对话 |
|
② 拓境 |
130 计六模块——防坑工具自己不能变成坑，话术边界写进设计 |
|
③ 走查四问 |
最锋利的一问：用户从哪来？——答不上来的页面就是死页面 |
一、思库熊：戴眼镜的小熊，肚子里装着知识库
1. 形态决策：从 RST 开始
|
层 |
分析 |
|
角色 |
初中生（重点用基础 24 个模型）、高中生（全模块）、大学生（AI 学习模块加权） |
|
场景 |
书桌前写作业遇困的瞬间——近场、安静、一对一 |
|
任务 |
拿到模型 → 练一次 → 内化（要有陪伴感，不是工具感） |
最终形态：30cm 毛绒小熊，戴书本眼镜（视觉锤：爱读书的伙伴），肚子一块半透明窗内嵌 12 颗 WS2812B 灯珠（「肚子发光的知识库」），INMP441 麦克风 ＋ 40mm 喇叭，摸头唤醒「库库」。
|
项 |
数值 |
|
BOM |
约 ¥128 |
|
定价 |
¥599 |
|
订阅 |
¥39/月 |
2. 108 模型如何真正「跑起来」：五步闭环
|
步 |
链路 |
|
① 遇困 |
孩子说「库库，我笔记越记越厚」→ ModelRouter 按关键词 0.6 ＋ 向量 0.4 命中 001 号知识树建模模型（Top3 必含正确 id） |
|
② 讲解 |
RAG 召回 learn_001 书稿切片 → LLM 按 Prompt 母版输出五段式卡片 → 设备端先播报「正在启动第 001 号知识树建模模型」＋ ≤80 字摘要 → 肚子灯同步亮起 |
|
③ 练习 |
小程序推送练一次清单 → 孩子用 5-15 分钟完成 micro-task 并打卡 → 熟练度 +1 |
|
④ 复习 |
003 号间隔检索抗遗忘模型驱动 SRS 复习队列 |
|
⑤ 复盘 |
家长周报（仅熟练度，无任何对话内容） |
3. 六模块搭载架构：需求到设计的翻译
每一层的设计决策，都要回答同一个问题：这一层为「模型跑起来」做了什么贡献？
|
模块 |
编号区间 |
痛点示例 |
灯效反馈 |
订阅层 |
|
知识内化与记忆 |
001-024 |
笔记越记越厚（001） |
蓝光短闪 |
free 起 |
|
刷题应试提分 |
025-044 |
读题三分钟做题三十秒（025） |
蓝光双闪 |
basic |
|
元认知与思维 |
045-064 |
很努力却从不审视学法（045） |
青光呼吸 |
basic |
|
时间精力执行 |
065-078 |
面对大目标就拖（065） |
绿光呼吸 |
basic |
|
AI 时代学习 |
079-088 |
把 AI 当搜题器（079） |
紫光呼吸 |
pro |
|
心态情绪内耗 |
089-108 |
大考发挥失常（089） |
暖光呼吸 |
pro |
五层架构（每层一份独立设计文档）：
|
层 |
内容 |
|
IP 层 |
戴书本眼镜的小熊，肚子半透明窗＝知识库发光 |
|
硬件层 |
ESP32-S3、INMP441 麦克风、肚子 WS2812B×12、40mm 喇叭 |
|
模型层 |
108 套模型分六大模块 |
|
交互层 |
摸头唤醒「库库」、语音报模型号或描述痛点、肚子灯效反馈练习状态 |
|
小程序层 |
模型地图 ＋ 练一次打卡 ＋ 家长周报 |
一套模块化设计，三端复用——六模块对应小程序的六个 Tab、Prompt 母版的六条分支、订阅分层的解锁阶梯。
4. 评审会最激烈的争论：熊会不会让孩子抄答案？
|
争论 |
设计回应 |
|
「熊会不会让孩子抄答案？」 |
Prompt 母版强制五段式结构——卡片给方法、给步骤、给练习，唯独不直接给作业答案；末尾固定追问「要不要现在练一次？」 |
品牌口径因此统一：「不止记忆，更要构建完整思维知识库」——
思库熊卖的不是答案，是一套会发光的学习系统。
订阅分层落点：前 12 个模型免费养成习惯 → basic 解锁至 36 个 → pro ¥39/月开放全量精讲、间隔复习算法与家长周报。
二、拓境：贴在显示器上的防坑参谋
1. 形态决策：六款中最反直觉的一款
RST 给出三条硬约束：
|
约束 |
内容 |
|
① |
用户在开会，不能出声对着设备说话 |
|
② |
设备必须「在场但不被注意」——桌上摆个玩偶会让同事警惕 |
|
③ |
会后 5 分钟内用户就忘了会上的细节，反馈必须快 |
最终形态：6×6cm 磁吸方块「小逻」，磁吸＋背胶贴显示器侧边或笔记本 A 面，双 MEMS 麦远场降噪与说话人分段，2000mAh 电池，RGB 边框灯，离线唤醒「小逻小逻」，短按开始录音、长按结束会议。
|
项 |
数值 |
|
BOM |
约 ¥130 |
|
定价 |
¥499 |
|
订阅 |
¥29/月 |
2. 核心链路：被动守护
学生主动求助，职场人被动守护——危险不是用户查来的，是系统替他听到的。
会议中：方块常亮待机，检测到连续语音自动分段
↓ 长按结束
5 秒内：小程序推送「命中模型：037 边界话术模型」＋破解公式＋待办
延迟预算在设计阶段就分配好：
|
环节 |
预算 |
|
转写 |
3 秒 |
|
匹配 |
0.5 秒 |
|
推送 |
1 秒 |
|
余量 |
0.5 秒 |
3. 130 计六模块：四类输出形态
与思库熊同构但重心不同——四类输出在设计阶段就区分开，因为对应小程序四种不同的卡片组件。
|
类型 |
计类区间 |
输出形态 |
|
取证型 |
背锅甩锅（001-018）、窃取成果抢功劳（019-036） |
留痕清单 ＋ 贡献记录模板（001-018 自动附加 IM 截图位） |
|
健康型 |
PUA 精神打压（037-054） |
压力记录 ＋ 边界话术（写入个人档案，仅本人可见） |
|
预警型 |
挖坑设套（055-072）、造谣构陷（073-090） |
风险提示 ＋ 证人链建议 |
|
升维型 |
高阶博弈（091-130） |
路径规划 ＋ 资源图 |
两个体现分寸的设计细节：
|
细节 |
内容 |
|
① B 端团队版 |
只共享匿名化的模型命中统计，永不共享录音原文——企业风控要的是群体风险画像，不是窃听员工 |
|
② 全程不在会上发声 |
所有提醒走灯色与会后卡片——职场信任的前提是「它不惹眼、更不泄密」 |
4. 订阅钩子：周复盘
|
层 |
权益 |
商业逻辑 |
|
免费层 |
可查单次会议命中 |
即时价值 |
|
basic（¥29/月） |
解锁本周 Top5 命中聚合 ＋ 练一次引导 ＋ 飞书推送 |
复盘才是留存——单次会议是即时价值，周复盘是习惯价值，习惯价值才撑得起 ¥29/月 |
B 端团队版：把 anonymized 命中统计做成「团队博弈健康度看板」——这是设计阶段就画进架构的一个独立服务，而不是售后想法。
5. 硬件去玩偶化：渠道决策
职场人不接受在工位放一只熊。
磁吸方块的办公用品气质，让「自我保护工具」这个定位在办公场景成立——它必须能摆在开放工位，不引来尴尬提问。
内容营销锚定 35 岁职场焦虑——130 计的模块名本身就是话题：背锅、抢功、PUA、挖坑，每一个都能撑起一篇「会后 5 秒，它提醒我刚刚被甩锅了」的实测笔记。
三、走查四问最锋利的一问：用户从哪来？
内容要点③——这是本页最该单独拎出来的一问（回扣 P36 第五部分）。
走查四问是「用户从哪来 → 要做什么 → 卡在哪 → 走不走」。四问之中——
最锋利的是第一问：用户从哪来？
为什么它最锋利：
|
理由 |
说明 |
|
① 它决定页面有没有存在权 |
一个说不清入口的页面，用户根本到不了——再精美也是死页面 |
|
② 它暴露「为了完整性而做」的功能 |
团队常为了「功能地图好看」加页面，却答不出用户从哪点进来 |
|
③ 它连着触发条件 |
答得出「从哪来」，就等于答出了触发→行动→奖励习惯回路的触发端 |
两款产品的回答：
|
产品 |
用户从哪来？ |
|
思库熊 |
书桌前遇困的瞬间——孩子主动说「库库，我笔记越记越厚」（主动求助式入口） |
|
拓境 |
会议结束的那一刻——系统被动推送「命中模型 037」（系统触发式入口，用户不需要找） |
判定规则：
答不上「用户从哪来」的页面，就是死页面——不进设计，直接砍。
四、两款对照：同一套模型库，两种交互范式
|
维度 |
思库熊 |
拓境 |
|
用户状态 |
遇困后主动查 |
身在局中不自知 |
|
交互范式 |
主动查询式 |
被动守护式 |
|
主输入 |
摸头唤醒 ＋ 语音报号 |
离线唤醒 ＋ 短按／长按 |
|
主反馈 |
播报 ＋ 肚子 12 灯珠 |
RGB 边框 ＋ 会后卡片 |
|
模型库 |
108 套学习（六模块） |
130 计职场（六计类） |
|
内容重心 |
教方法、给练习 |
取证／健康／预警／升维四类输出 |
|
订阅钩子 |
精讲 ＋ 间隔复习 ＋ 家长周报 |
周复盘 Top5 |
|
形态逻辑 |
陪伴感（毛绒熊） |
办公用品气质（磁吸方块，去玩偶化） |
同一条模型库方法论（模型库 ＋ RAG ＋ 熟练度 ＋ 订阅），在不同场景下长出了完全不同的交互形态——
这就是「模型驱动」的弹性，也是 RST 分析的价值：不是先定形态再找场景，是场景反推出形态。
五、下篇预告：其余四款（P45）
raw 已给出四款的完整设计实战，本页按「上／下」拆分——以下为速览，深潜留待 P45：设计案例（下）。
|
产品 |
核心设计决策 |
一句话取舍 |
|
陪伴熊·基础版 |
孙辈语气「熊小伴」＋ 方言 ASR ＋ 五色灯环 ＋ 戏曲 500+ ＋ 用药引擎 |
回复 60 字封顶、设备零文字——老人听不了长句、可能不识字 |
|
陪伴熊·亲情版 |
声音克隆（先租后买：火山 API → 月活 500 后自部署 GPT-SoVITS）＋ 角色档案七字段 |
熊还是那只熊，声音变成了儿子 |
|
记忆熊 |
七题记忆问卷 → 人格 Prompt 七槽位 ＋ 六条生成规则；纪念日话术先审后发 |
不是「复活」，是「可对话的纪念档案」——全渠道禁用「复活」「重生」 |
|
情绪球 |
无屏哲学（无脸／无屏／无唤醒词）＋ FSR 挤压唤醒 ＋ 端侧 ASR 即弃 PCM |
它不解决问题，只让孩子知道「我的情绪被接住了」 |
六、自检：你的设计取舍站得住吗
|
自检问题 |
不合格信号 |
|
① 形态是从 RST 反推出来的吗？ |
先定外观再找场景 |
|
② 每一层都回答了「为模型跑起来做了什么」吗？ |
架构图画了，但说不清每层贡献 |
|
③ 延迟预算在设计阶段分配了吗？ |
上线后才压延迟，来不及 |
|
④ 四类输出形态区分开了吗？ |
所有卡片一个模板，用户分不清 |
|
⑤ 每个页面答得出「用户从哪来」吗？ |
有页面说不清入口 |
|
⑥ 订阅钩子是「习惯价值」还是「即时价值」？ |
只有即时价值，续费率撑不住 |
判读：六项全过 → 设计取舍成立；四项以下 → 你在堆功能，不是在给房子腾地方。
七、金句收尾
硬件是钥匙，238 套模型库才是房子——设计阶段的一切取舍，都是在给「房子」腾地方。
下面按 第4篇 · 第24章 · 24.2节 归位。承接 P44（24.1 思库熊与拓境），本页完成设计实战的下半篇——陪伴熊、亲情版、记忆熊、情绪球四款。
先呼应 P44 的预告：上篇处理的是「模型库如何变成产品」（238 套模型两条线）；本页处理的是「垂直场景 Prompt 库如何建立壁垒」（四款特殊人群产品），共同主题是——克制比聪明重要。
第24章 设计实战：六款产品的取舍
24.2 设计案例（下）：陪伴熊、记忆熊、情绪球（P45）
【开头钩子】
特殊人群产品，克制比聪明重要。
为什么这四款要单独讲：
|
维度 |
上篇（思库熊／拓境） |
下篇（本页四款） |
|
内核 |
238 套模型库 |
垂直场景 Prompt 库 |
|
用户 |
学生／职场人（能力完整） |
老人／哀伤者／儿童（能力受限或情绪脆弱） |
|
设计重心 |
模型跑得准、跑得快 |
克制——少给一点，反而对 |
对能力受限的人，产品每多显示一个字、多说一句道理，都可能成为新的障碍。
聪明是加分项，克制是及格线——特殊人群产品，先过及格线。
本页四条主线（对应内容要点）：
|
要点 |
产品 |
核心判断 |
|
① |
陪伴熊 |
周活是生活节律，不是流失曲线——指标定错，运营全错 |
|
② |
记忆熊 |
对哀伤中的人，可预期的平凡好过不可预期的惊艳 |
|
③ |
情绪球 |
无屏设计 ＋ 隐私架构——家长买的就是这份架构 |
|
④ |
亲情版 |
声音克隆是「开始聊」的引子，聊什么留给用户自己 |
一、陪伴熊·基础版：周活是生活节律，不是流失曲线
1. 定位与 RST（回链 P36）
|
项 |
内容 |
|
角色 |
独居／空巢老人——听力下降、说方言、畏惧电子设备、晚间独坐 |
|
场景 |
晚饭后独坐沙发、电视开着、灯光昏黄 |
|
任务 |
听到一句亲人的声音 |
|
核心卖点 |
方言闲聊 ＋ 戏曲点播 ＋ 用药提醒 ＋ 子女远程留言 |
|
项 |
数值 |
|
硬件 |
ESP32-S3 30cm 毛绒熊（公模 ＋ 底部拉链腔体） |
|
BOM |
≈¥124/台（50 台批量） |
|
零售价 |
¥599 |
|
订阅 |
戏曲包 ¥19/月（500+ 选段） |
2. 五层搭系统（六款里层次最清晰的一份）
|
层 |
设计内容 |
关键技术决策 |
|
L1 固件 |
唤醒、录音播放、配网、OTA、睡眠 |
摸头 2 秒 ＋ WakeNet 双条件唤醒 |
|
L2 云端 |
ASR／LLM／TTS／情绪／定时 |
方言 ASR 用火山；LLM 用 Qwen2.5-7B；情绪 BERT |
|
L3 内容 |
戏曲库、兴趣标签、共情话术 |
首包 50 段内置 SPIFFS，订阅后 OTA 拉全量 500+ |
|
L4 小程序 |
子女端全功能 |
远程协助配网为 P0 |
|
L5 数据 |
摘要、标签、依从率 |
不存全量原文，摘要可选关闭 |
3. 系统 Prompt 七条规则（人格即品牌宪法）
你叫「熊小伴」，陪一位老人聊天。规则：
|
# |
规则 |
|
1 |
用 {dialect} 方言回复，语气像孙辈对祖辈，亲切简短 |
|
2 |
每次提取 1 个关键信息存入 memory（天气／身体／家人动态） |
|
3 |
情绪低落时先共情再转移话题 |
|
4 |
绝不说「我是 AI」 |
|
5 |
每次回复不超过 60 字 |
|
6 |
用户说「听戏／播戏」→ 回复 [PLAY:戏曲/选段名] |
|
7 |
检测到用药时间已过未确认 → 温和提醒一次 |
4. 灯环语义与交互映射（设计文档与测试规范同一张表）
|
灯色 |
事件 |
|
蓝 |
配网 |
|
白 |
待机 |
|
暖黄 |
共情 |
|
橙 |
用药 |
|
紫 |
子女留言 |
按键与触摸映射表：
|
操作 |
条件 |
硬件 |
软件 |
|
长按电源 3 秒 |
进配网 |
耳灯蓝慢闪 |
开 AP ＋ 小程序写入 SSID |
|
摸头顶 Pad 2 秒 |
唤醒对话 |
白灯呼吸 ＋「在呢」 |
WakeNet 双条件确认 |
|
说「播段京剧」 |
点播 |
SPIFFS 读 MP3 流 |
关键词 → 曲库 index |
|
长按电源 5 秒 |
深度睡眠 |
状态写 Flash |
低功耗 |
|
用药时间到 |
定时 |
橙灯快闪 ＋ 语音 |
云函数 cron → MQTT |
|
子女留言到达 |
推送 |
紫灯呼吸后播放 |
OSS ＋ MQTT |
这条灯效纪律后来在亲情版、记忆熊上直接复用，成为平台级资产：
全局唯一——任何新功能不得复用已有颜色，新事件必须先申请新的灯效语义。
5. 内容要点①：周活是生活节律，不是流失曲线
这是银发产品最容易犯的指标错误。
老人使用陪伴熊的方式，是跟着生活节律走，不是互联网产品的「每日活跃」：
|
节律 |
表现 |
|
早晚闲聊 |
早起、晚饭后固定时段（设计里主动发起定在 17:00） |
|
用药时点 |
随用药计划触发，一天 1-3 次 |
|
周日周报 |
情绪周报每周日推送——周频，不是日频 |
|
节点性高峰 |
节前、生日、子女回家的日子 |
如果用互联网 DAU／WAU 曲线看这张图，会得出什么错误结论？
|
误判 |
真相 |
|
「周一到周五活跃低 → 流失了」 |
老人本来就有自己的生活节奏，闲聊集中在几个固定时段 |
|
「周中没打开 → 推送唤醒」 |
无谓推送会打扰，反而伤害体验 |
|
「周活下滑 → 功能不够」 |
可能是子女那周没留言（内容侧波动，不是产品侧流失） |
指标定错，运营全错——
把节律当流失，就会用「唤醒推送」去骚扰一个本来就按时来的用户。
银发产品的健康度指标，应该看「节律是否稳定」，而不是「活跃是否连续」。
6. 运营口径：克制也是合规
|
项 |
内容 |
|
账号人设 |
「给奶奶做了一只 AI 熊」孝心儿女 ／「造物老张」硬件佬 |
|
爆款选题链 |
Day1 手搓过程 → Day3 奶奶实测 → Day7 远程留言 → Day14 预售 |
|
避坑 |
不吹「替代医生／心理咨询」；统一标注「辅助陪伴非医疗」 |
|
首年目标 |
Phase1 50 台预售验证，月销 30-50 台——银发市场慢热，节奏跟着慢 |
情绪 BERT 识别到持续低落时，只触发子女端的温和提醒——设备端绝不说出任何医学建议。
对老人产品而言，克制不是功能缺失，是安全边界。
二、陪伴熊·亲情版：声音克隆是「开始聊」的引子（要点④）
1. 与基础版的差异：同主板零改动
|
维度 |
基础版 |
亲情版 |
|
语音 |
熊小伴统一 TTS |
子女／亲友克隆音色 |
|
Prompt |
通用陪伴 |
每角色独立风格 ＋ 口头禅 ＋ 记忆 |
|
小程序 |
留言板 |
＋声音档案库、角色管理、场景模拟 |
|
云端 |
单 TTS |
VoiceID 路由 ＋ 角色 memory |
|
定价 |
¥599 |
¥798（比基础版 +¥199，含 3 角色克隆额度） |
硬件 BOM 与基础版完全相同（≈¥124）——差异 100% 在软件与内容（回扣 P40 第六部分升级路径）。
2. 技术链路（代码级）
子女录音 10 句
→ POST /api/v1/voice/clone → 克隆服务返回 voice_id
老人说：「想听小强说话」
→ ASR → intent = switch_role(xiaoqiang)
→ 加载 role_prompt + role_memory + voice_id
→ LLM 生成（注入小强说话风格）
→ TTS(voice_id) → MQTT cloud/{sn}/tts/play
熊还是那只熊，声音变成了儿子。
角色数据结构七字段：
{
"role_id": "xiaoqiang",
"display_name": "儿子小强",
"voice_id": "volc_xxx",
"relation": "儿子",
"catchphrases": ["妈记得吃饭", "周末回去看您"],
"speaking_style": "口语化、略唠叨、关心健康",
"memories": [{"key": "降压药", "value": "妈您别忘饭后吃"}]
}
七字段撑起「听到儿子声音说话」的全部体验——TTS 用 voice_id，LLM 注入 speaking_style 与 catchphrases，对话中动态引用 memories。
3. 声音克隆四方案对比：商业节奏决定技术形态
|
方案 |
采样 |
费用 |
定位 |
|
火山引擎声音复刻 |
1 分钟清晰语音（10 句） |
¥0.2/次 |
⭐⭐⭐⭐⭐ MVP 首选 |
|
阿里云 CosyVoice |
3 秒极速克隆 |
¥0.01/次 |
⭐⭐⭐⭐ 备选 |
|
GPT-SoVITS 自部署 |
1-5 分钟 |
服务器成本 |
⭐⭐⭐ 月活 >500 后降本 |
|
ElevenLabs（海外） |
1 分钟 |
$0.30/月 |
❌ 合规风险（数据出境），不推荐 |
|
维度 |
火山 API（MVP） |
GPT-SoVITS（规模化） |
|
上线速度 |
即接即用，数天跑通 |
需 GPU 服务器与调优，1-2 周 |
|
成本结构 |
按调用计费，无固定成本 |
服务器固定成本，边际调用近零 |
|
切换信号 |
0-500 月活 |
月活 >500 后自部署降本 |
|
数据掌控 |
依赖云厂商 |
全链路自有，合规可控性更强 |
选型路径：先用火山 API 跑通验证 → 月活过 500 再自部署 GPT-SoVITS 降本。
这条「先租后买」的路径，让产品在验证期不背资产包袱，在规模期不被按量计费拖垮——
技术选型不是技术问题，是商业问题。
4. 授权闭环三条红线（必须写进用户协议）
|
# |
红线 |
|
① |
录音时必须弹窗：「我确认本人同意克隆我的声音用于陪伴家人」；禁止克隆未授权第三人；后台人工抽检 |
|
② |
商品页与播放前标注「声音为 AI 合成，非实时通话」；记忆熊场景禁用「复活」「重生」 |
|
③ |
voice_id 与原始录音 AES 加密存储、不出境、不用于训练；提供音色停用通道——授权撤回后 voice_id 立即失效、录音按约删除 |
技术能力越强，合规门禁越要前置——门禁不是阻力，是让技术敢用的前提。
5. 内容要点④：克隆是「开始聊」的引子，聊什么留给用户
这是亲情版最容易被误解的一点：
|
❌ 常见误解 |
✅ 设计本意 |
|
克隆声音＝让熊替子女陪聊 |
克隆声音只是降低开口门槛——老人愿意对着「儿子的声音」说话 |
|
内容越多越好（预制大量对话） |
聊什么留给用户自己——系统只给引子，不给剧本 |
设计分寸：
|
设计 |
做法 |
|
引子 |
克隆音色 ＋ 角色口头禅 ＋ 记忆点，让老人愿意开口 |
|
留白 |
对话内容由老人自己起头，LLM 只按角色风格接话，不主导话题 |
|
场景剧本是可选的 |
scene_newyear（过年聚餐）、scene_school（孙子放学）、scene_birthday（老人生日）——是订阅内容，不是默认行为 |
声音克隆解决的是「愿不愿意说」，不是「说什么」。
一旦系统开始替用户决定聊什么，陪伴就变成了表演——引子给足，内容留白，才是对老人自主性的尊重。
6. 上线节奏（Phase 2）
|
项 |
内容 |
|
第 3 月 |
基础版用户固件 OTA 升级亲情模块（订阅解锁） |
|
小红书 |
「儿子声音在熊里说话」实测视频 |
|
定价 |
硬件 ¥798 或 基础版用户 +¥199 升级包 |
三、记忆熊：可预期的平凡，好过不可预期的惊艳（要点②）
1. 市场与定位
|
项 |
内容 |
|
市场 |
中国年死亡约 1000 万 → 约 3000 万直系亲属潜在需求 |
|
高频节点 |
清明、忌日、生日、中元、母亲节 |
|
竞品 |
StoryFile（视频非实时）、HereAfter（App 无硬件） |
|
空白位 |
毛绒 ＋ 实时对话 |
|
宣传词 |
「思念有声，回忆可触」 |
|
禁用词 |
「复活」「重生」——定位是「可对话的纪念档案」 |
2. 硬件差异（与陪伴熊共用主板）
|
项目 |
陪伴熊 |
记忆熊 |
|
外壳 |
浅棕毛绒 |
深蓝／深灰 |
|
灯环 |
多色状态 |
暖白为主（温暖回忆） |
|
包装 |
标准 |
＋「记忆收集手册」＋ 问卷本 |
|
刻印 |
熊小伴 |
记忆熊｜思念陪伴 |
3. 素材收集：七题问卷 → 人格 Prompt 工程
七题问卷（搭系统第一步，也是最关键一步）：
|
# |
问题 |
|
1 |
他／她最常叫您什么？ |
|
2 |
最常说的 5 句话（如「多穿点」「别熬夜」「吃饭了吗」）？ |
|
3 |
性格是严厉、温柔、幽默还是唠叨？ |
|
4 |
最关心您什么方面？ |
|
5 |
生前对您说过最难忘的一句话？ |
|
6 |
有什么特殊习惯（抽烟／喝茶／听戏／晨练）？ |
|
7 |
最怕您做什么（熬夜、不吃饭、太辛苦）？ |
素材清单：
|
类型 |
收集方式 |
最低要求 |
用途 |
|
语音 |
子女上传生前录音／视频 |
≥1 分钟清晰干声 |
声音克隆 |
|
照片 |
小程序上传 |
10-50 张 |
情感锚点 ＋ 相册 |
|
文字记忆 |
问卷填写 |
7 大题必填 |
人格 Prompt |
|
聊天记录 |
微信导出（可选） |
— |
口头禅提取 |
人格 Prompt 模板七槽位 ＋ 六条规则：
|
槽位 |
内容 |
|
① relation ② name ③ personality ④ catchphrases ⑤ concerns ⑥ life_story ⑦ last_words |
角色关系、名字、性格、口头禅、关心点、人生故事、难忘的话 |
|
# |
生成规则 |
|
1 |
用本人语气回复 |
|
2 |
永远记得用户是最亲的人 |
|
3 |
难过时用口头禅安慰 |
|
4 |
每次 ≤80 字 |
|
5 |
绝不说「我是 AI」／「数字人」 |
|
6 |
不确定的事用生前价值观推测 |
记忆熊证明了一件事：人格不是玄学，是结构化 Prompt 工程。
4. 合规门禁四道（生死线）
|
门禁 |
验证方式 |
未通过 |
|
亲属关系 |
死亡证明 ＋ 户口本 ＋ 申请人身份证 |
拒绝激活 |
|
年龄 |
对象须满 14 岁 |
系统拦截 |
|
授权 |
全体近亲属知情同意书（电子签） |
暂停服务 |
|
心理提示 |
首次激活弹窗 ＋ 手册 |
必须确认 |
5. 纪念日引擎：可预期的平凡（内容要点②）
|
事件 |
触发 |
设备行为 |
内容示例 |
|
生日 |
用户预设日期 |
暖白灯 ＋ 主动说话 |
「今天是你生日，爷爷记得…」 |
|
忌日 |
预设 |
温和音量 |
「在那边也要照顾好自己」 |
|
清明 |
公历 4/4-4/6 |
可选开启 |
「回去看看，爷爷陪你」 |
关键设计纪律：
所有纪念日话术先生成后人工审核入库，绝不实时生成。
纪念场景下，一句不合适的话就是一次伤害。
这就是内容要点②的含义：
对哀伤中的人，AI 的「惊艳发挥」是一种风险——你不知道它这次会说出什么。
而可预期的平凡——那句熟悉的口头禅、那个固定时点的问候——才是真正的安慰。
这是全书「AI 概率输出必须兜底」原则，在最敏感场景的应用。
6. 商业模式与上线节奏
|
版本 |
价格 |
包含 |
|
标准版 |
¥799 |
1 位亲人 ＋ 基础记忆库 ＋ 克隆音色 |
|
双亲版 |
¥1199 |
2 位亲人 ＋ 双人对话模式 |
|
记忆续费 |
¥99/年 |
50 段新场景脚本 ＋ 纪念日引擎 |
第 4-5 月上线；清明节前 4 周开始「把思念装进口袋」内容预热；母亲节「妈妈的声音还在」专题；首月目标 100 台（高客单价 ¥799）。
高客单价、低销量预期、强伦理约束——记忆熊证明平台化不仅能复用成本，也能复用信任：同一套可靠底座，才承载得起这么重的情感。
四、情绪球：无屏设计 ＋ 隐私架构，家长买的就是这份架构（要点③）
1. 无屏哲学四词立骨
|
词 |
内容 |
|
无屏幕 |
儿童不需要另一个屏幕——屏幕是家长焦虑源 |
|
低刺激 |
RGB 灯用球内漫射而非直射；音量上限低于安全阈值；呼吸灯节奏模拟人的呼吸 |
|
强触觉 |
FSR402 薄膜压力传感器 ×2，捏握压力 >2N 持续 0.5 秒唤醒——挤压本身就是情绪表达 |
|
高隐私 |
端侧 ASR 后立即丢弃 PCM；云端只接收 text_summary 与 emotion_tag；家长端无原文回放 |
2. 硬件规格与 BOM（≈¥110）
|
器件 |
型号／规格 |
数量 |
单价(¥) |
|
主控 |
ESP32-S3-WROOM-1 |
1 |
18 |
|
压力传感器 |
薄膜压力 FSR402 |
2 |
4×2 |
|
RGB |
WS2812B（球内漫射） |
6 |
0.5×6 |
|
麦克风 |
INMP441 |
1 |
3.5 |
|
喇叭 |
微型 8Ω 1W（低音量护耳） |
1 |
4 |
|
电池 |
602030 600mAh |
1 |
8 |
|
硅胶外壳 |
食品级一体成型 |
1 |
35 |
3. 交互映射表（补全 P44 预告中被截断的部分）
|
操作 |
条件 |
硬件 |
软件 |
输出 |
|
捏握唤醒 |
压力 >2N 持续 0.5s |
柔光渐亮 |
开始倾听模式 |
「我在，慢慢说」 |
|
倾诉 |
唤醒后说话 |
灯常亮／跟随音量 |
ASR → 共情 LLM |
反射情感，不给建议 |
|
呼吸练习 |
说「我害怕／睡不着」 |
灯吸 4 秒灭 6 秒 |
正念脚本 |
「跟着光呼吸」 |
|
SOS |
长按捏 5 秒 |
红灯快闪 |
呼叫家长微信 |
发起语音通话 |
|
休眠 |
5 分钟无交互 |
灯灭 |
深度睡眠 |
— |
4. 共情 Prompt：禁止说教
你是「球球」，孩子的情绪伙伴。规则：
|
# |
规则 |
|
1 |
只反射感受，不给建议（不说「你应该」） |
|
2 |
用孩子能懂的话，≤40 字 |
|
3 |
示例：「听起来你很生气，因为小明抢了你的玩具，对吗？」 |
|
4 |
检测到害怕／焦虑 → 提供呼吸练习邀请 |
|
5 |
不存原文录音；只输出 emotion_tags + summary 给云端 |
为什么「禁止说教」：
孩子向玩具倾诉，要的是被接住，不是被教育。
一旦球球开始讲道理，孩子就不再说了。
5. 内容要点③：家长买的就是这份架构
情绪球的隐私架构在设计阶段就是主角，而非补丁：
|
层 |
设计 |
|
端侧 |
ASR 后立即丢弃 PCM |
|
上行 |
只传 text_summary ＋ emotion_tag |
|
家长端 |
不可听原文回放；Pro 版也仅看趋势图 |
|
留存 |
摘要保留 90 天自动删除 |
|
MQTT |
device/{sn}/emotion/summary 仅传输 {tags, summary, ts} 三个字段 |
营销口径因此有了最硬的卖点：「不给手机也能倾诉」。
家长付费买的不是「一个会说话的球」，是这份不留存、不回放、不出境的隐私架构——
架构本身就是产品价值，这是情绪球与其他儿童产品的分水岭。
风险边界：
它不替代儿童心理服务——家长端趋势图若持续异常，收到的是「建议最近多和孩子聊聊」，而不是任何诊断结论。
|
项 |
内容 |
|
定价 |
¥459 |
|
订阅 |
睡前故事包 ¥15/月 |
|
上线 |
Phase 4（第 6-8 月）与拓境同期试水——六款中验证最谨慎的一款 |
|
场景视频 |
分床睡焦虑、被同学欺负、考试压力 |
儿童产品的每个设计决定，都要先过伦理这道门，再过工程这道门。
五、贯穿三款的通用纪律：人格 Prompt 工程三条
raw 单列一节，适用于陪伴熊／记忆熊／情绪球三款人格型产品。
|
# |
纪律 |
内容 |
|
① |
长度约束即产品体验 |
陪伴熊 ≤60 字、记忆熊 ≤80 字、情绪球 ≤40 字——字数不是风格选择，是 TTS 时长约束，在网关回归里硬校验 |
|
② |
身份回避与禁区过滤要双层 |
Prompt 写「绝不说我是 AI」是第一层；但模型可能被诱导——因此在 ASR 之后、LLM 之前加禁区话题过滤（医疗诊断、自杀倾向、财务承诺等直接走安全话术并告警），输出侧再做敏感内容过滤。安全不能只靠 Prompt 自觉 |
|
③ |
人格素材必须来源授权 |
记忆熊激活有合规门禁（亲属关系确认 ＋ 素材授权）；对话定位为纪念档案而非「复活」 |
共情生成的验收：
不靠感觉，靠评测集——构造 50 条典型倾诉，标注合格回复要点（反射情绪 ＋ 无建议句式 ＋ 字数达标），LLM-as-Judge 自动打分，回归不达标不发版。
AI 情感产品的最大风险从来不是模型不够聪明，而是它太着急证明自己有用。
六、自检：你的特殊人群产品克制住了吗
|
自检问题 |
不合格信号 |
|
① 指标对了吗？ |
把老人的生活节律当流失曲线，狂发唤醒推送 |
|
② 长度约束硬校验了吗？ |
只在 Prompt 里写「简短」，网关不校验 |
|
③ 禁区过滤双层了吗？ |
只靠 Prompt 自觉，无输入输出侧过滤 |
|
④ 纪念日话术先审后发了吗？ |
实时生成，赌模型这次不胡说 |
|
⑤ 隐私是架构还是补丁？ |
先存了原文，出事再删 |
|
⑥ 克隆声音有授权闭环吗？ |
只做弹窗，无撤回通道与加密 |
|
⑦ 你是在陪伴，还是在表演？ |
系统替用户决定聊什么，内容全预制 |
判读：七项全过 → 克制到位，可交付特殊人群；四项以下 → 你在炫技，不是在照顾人。
七、金句收尾
对哀伤中的人，可预期的平凡好过不可预期的惊艳。
下面按 第4篇 · 第25章 · 25.1节 归位。
先说明章节推进：第24章（设计实战，P44 上／P45 下）已收口，六款产品设计档案全部交付。本页回扣 P33 篇开篇承诺的「设计阶段四件产出物」——规格书、BOM 初稿、评审记录、ADR 决策日志——前三个已在前文落地，本页补齐最后一件，作为设计篇的收尾资产。
再处理 raw：①raw 标注为附录 E（E.0-E.12），但 ADR 是设计阶段的核心产出物，建议升格为正文第25章；②TECH-01 模型编号为技术篇前缀，但「决策留痕」主题本页先用，已在归位提示标注定稿确认；③内容要点③「冲突仲裁走 Decision Log、当场签字」raw 未展开，已基于 P34 评审四段流程补齐。
第25章 决策资产：让决策可追溯
章眼：半年后没人记得当初为什么这么定——除非你写了 ADR。
25.1 ADR架构决策记录：让决策可追溯（P46）
【开头钩子】
半年后没人记得当初为什么这么定——除非你写了ADR。
与前面各章的衔接：
|
章 |
产出 |
|
第18章 产品定义 |
规格书、BOM 初稿 |
|
第19章 评审门禁 |
评审记录（十二问打分留痕） |
|
第24章 设计实战 |
六款产品的完整设计档案 |
|
第25章（本页） |
ADR 决策日志——四件产出物的最后一件 |
前三件回答「做成了什么样」，ADR 回答「当初为什么这么定」。
没有 ADR，前面三件在半年后都会变成没人看得懂的谜。
本页三条主线（对应内容要点）：
|
要点 |
回答什么 |
|
① ADR 四段式 |
背景、可选方案、决定、后果——怎么记？ |
|
② 极度透明 |
代码与决策留痕，决策日志全员可查 |
|
③ 冲突仲裁 |
走 Decision Log，方案优劣当场写清、当场签字 |
一、ADR 是什么：决策资产库
ADR（Architecture Decision Record，架构决策记录）是贯穿项目的决策资产库。
|
项 |
数据 |
|
贯穿项目 ADR 总数 |
47 条（12 个月） |
|
本页精选 |
12 条最具传承价值 |
ADR 的价值不在文采，在于六个月后还有人能看懂「当时为什么这么定」。
为什么必须写——三个真实场景：
|
场景 |
没有 ADR 时 |
|
新人入职 |
看代码看不出当初为什么选这个方案，只能猜 |
|
复盘事故 |
争论「当初谁拍的板」，无人认领，变成甩锅会 |
|
供应链谈判 |
说不出成本取舍的依据，被供应商牵着走 |
二、ADR 四段式：怎么记（要点①）
每条 ADR 按「背景—选项—决定—后果」四格完整呈现：
|
段 |
写什么 |
|
① 背景 |
为什么需要做这个决策？触发条件是什么？ |
|
② 可选方案 |
有哪几个选项？各自的取舍是什么？（通常是三个——回扣 P34 创意择优） |
|
③ 决定 |
选了哪个？验收线是什么？ |
|
④ 后果 |
正面后果 ＋ 负面后果——负面后果尤其重要，它是未来的技术债清单 |
写 ADR 的两个忌讳（回扣 P34 权衡单两忌）：
- 一忌只列选项不列假设——没有假设的决策无法复盘；
- 二忌只写好处不写代价——不写代价的 ADR 不是决策记录，是邀功信。
三、12 条精选 ADR 总表
每条按四格完整呈现，可直接套用（本表为紧凑版，深潜见第四部分）。
|
# |
ADR |
背景 |
选项 |
决定 |
后果 |
|
1 |
ADR-003 |
六款需统一主控 |
①ESP32-S3（18-32元，Wi-Fi/BLE一体，跑WakeNet）②树莓派Zero（75元起，功耗与BOM双超）③STM32+WiFi模组（器件+1，联调成本升） |
全系采用 ESP32-S3-WROOM（毛绒系 N16R8，紧凑型 WROOM-1） |
✅BOM红线内、一芯六款、供应链复用 |
|
2 |
ADR-007 |
ModelRouter 需支持「描述痛点自动路由」，纯向量 Top1 仅 71% |
①纯向量 ②纯关键词 ③加权融合 |
关键词 0.6 + 向量 0.4＋Top5 重排；验收线 Top3 ≥96% |
✅Top3 命中 96.4%（清理37个过泛触发词后） |
|
3 |
ADR-012 |
双亲版需求「两位亲人同时对话」，技术可行 |
①双人对话 ②切换式 |
切换式；双人对话写入非目标清单 |
✅规避「编造亲人从未有过的对话」的伦理风险 |
|
4 |
ADR-019 |
儿童语音数据的合规与信任要求最高 |
①云端全量存储 ②端侧ASR后立即丢弃PCM ③本地存储定期清理 |
方案②；载荷逐字节审查，确保无可还原原文字段 |
✅家长信任成立（焦虑测试 8/10 通过） |
|
5 |
ADR-021 |
纯语音唤醒误唤醒率高（每晚10+次，电视声/方言均误触） |
①提高阈值（漏唤醒↑）②摸头Pad+WakeNet双条件 ③遥控器（器件+丢失风险） |
双条件：摸头2秒直接唤醒；仅语音需 WakeNet 命中且置信度>0.8 |
✅误唤醒降至几乎为零，且「摸头」成为情感动作 |
|
6 |
ADR-024 |
六款并行开发，各自定义通信结构则平台化名存实亡 |
①每SKU自定义 ②统一基础主题+SKU扩展，载荷发布即冻结、只加不改 |
方案②；device/{sn}/status 等五个基础主题全系共用 |
✅老固件永不因结构变更失联；运维大盘一份代码适配六款 |
|
7 |
ADR-027 |
陪伴熊 P95 延迟 2.9 秒超 2.5 秒预算，TTS 占 400ms 且话术高度重复 |
①升级TTS并发 ②LLM端限长 ③50条高频话术预合成存OSS |
方案③为主，②同步实施 |
✅P95 降至 2.3 秒；单台云成本 0.41→0.28 元/天 |
|
8 |
ADR-031 |
实时生成可能产出不当表达（如对丧亲者说「恭喜」类语境错乱） |
①实时生成+敏感词过滤 ②预生成+人工逐条审核 ③仅灯效不说话 |
方案②；五类纪念日×场景分支共 120 条全量人工审核 |
✅零话术事故 |
|
9 |
ADR-033 |
B端试点企业要求查看员工个体命中数据，商业压力 vs 个人隐私 |
①开放个体数据 ②仅匿名化聚合统计（模型ID+部门+频次）③暂缓B端 |
方案②为产品边界，写入用户协议与合同；拒绝该企业并终止试点 |
✅B端信任根基确立，续费企业HR主动引用「匿名化」为采购理由 |
|
10 |
ADR-036 |
学生视学习设备为「监控器」，家长诉求却是「了解情况」 |
①完整学习报告 ②仅熟练度热力图与进度 ③不设内容类信息 |
方案②；108/130维熟练度热力图＋周进度，聊天内容任何形式不出会话层 |
✅学生接受度显著提升（「它不是我妈妈的 spy」——内测用户原话）；家长周报打开率 68% |
|
11 |
ADR-040 |
亲情版OTA灰度发现3台老批次分区表异常，无回滚将变砖 |
①单分区+恢复模式 ②双分区+自动回滚 ③双分区+自动回滚+人工确认灰度档位 |
方案③；灰度 10%→50%→100%，档位间人工确认，故障率超阈值全量暂停 |
✅12个月 46次周更+6次SKU升级零变砖 |
|
12 |
ADR-044 |
迭代节奏选择：日更太躁、月更太慢 |
①日更 ②双周更 ③周更（周三发布，周一决策，下周一回测） |
方案③；每次周更必须携带一个可被数据裁决的假设 |
✅46次周更中 31次假设成立、15次被否决——被否决假设的认知价值最大 |
四、四条深潜：ADR 里最有传承价值的取舍
12 条里挑四条最有传承价值的展开——它们的共同点：都在拒绝一个「技术上可行」的诱惑。
深潜一｜ADR-012：记忆熊「双人对话」降级为切换式
|
项 |
内容 |
|
技术上可行吗？ |
可行——双角色 Prompt 编排即可实现 |
|
为什么不做？ |
两位亲人「互动交流」意味着系统在编造一段从未发生过的对话 |
|
决定 |
切换式——同一时刻一人开口，另一人以「你妈以前总说」被引用 |
|
代价 |
双亲版差异化卖点减弱，用标签＋纪念日双人内容包补偿 |
这是全书最有分量的一条 ADR——
技术能力走到哪里，不等于产品就该走到哪里。
记忆熊的定位从第一天起就是「纪念」而非「替代」（回扣 P35、P45）——双人对话会让「纪念」滑向「虚构」，这条线一旦跨过，产品的伦理根基就没了。
深潜二｜ADR-031：纪念日话术全人工审核
|
项 |
内容 |
|
诱惑 |
实时生成——省事、可扩展、看起来更「智能」 |
|
风险 |
AI 的概率本性可能产出不当表达（如对丧亲者说「恭喜」类语境错乱） |
|
决定 |
预生成 ＋ 人工逐条审核入库；120 条全量审核 |
|
代价 |
新增场景平均 5 个工作日上线——被接受为「慢即是对的」 |
这是内容要点②（记忆熊）的工程化落地——
对哀伤中的人，可预期的平凡好过不可预期的惊艳。
一句不合适的话，对普通产品是 bug，对纪念产品是一次真实的伤害。
深潜三｜ADR-033：B端「匿名化铁律」
|
项 |
内容 |
|
压力 |
B端试点企业商业要求查看员工个体命中数据 |
|
冲突 |
商业收入 vs 个人隐私保护 |
|
决定 |
仅匿名化聚合统计（模型ID＋部门＋频次），写入用户协议与合同；拒绝该企业并终止其试点 |
|
代价 |
损失一家试点企业——被评估为「值得付出的成本」 |
|
回报 |
续费企业 HR 主动引用「匿名化」作为采购理由 |
短期丢单，长期立信——B端产品的信任根基，就是在这样的拒绝里建立起来的。
回扣 P44：拓境团队版「只共享匿名化命中统计、永不共享录音原文——企业风控要的是群体风险画像，不是窃听员工」。
深潜四｜ADR-040：OTA 双分区 ＋ 灰度三档
|
项 |
内容 |
|
触发 |
亲情版灰度期发现 3 台老批次设备分区表异常——若无回滚将变砖 |
|
决定 |
双分区 ＋ 自动回滚 ＋ 人工确认灰度档位（10%→50%→100%） |
|
收益 |
12 个月 46 次周更 ＋ 6 次 SKU 升级零变砖 |
|
代价 |
全量发布平均延迟 3 天——被接受为必要成本 |
回扣 P45 陪伴熊亲情版「同主板零改动、老用户 +¥199 OTA 解锁」——
升级路径能成立的技术前提，正是这条 ADR。没有双分区回滚，一次失败的 OTA 就会把老用户的熊变成砖头。
五、极度透明：代码与决策留痕（要点② ＋ TECH-01）
|
项 |
内容 |
|
模型 |
TECH-01 极度透明 · 代码与决策留痕模型 |
|
来源 |
达利欧 Radical Transparency |
|
核心要求 |
关键决策、接口变更、踩坑记录对团队可见 |
|
透明的最小单元 |
PR ／ ADR ／ Runbook |
|
启用时机 |
多人协作模块、核心链路变更、新人占比 >30% 的团队 |
两条思想要义：
|
思想 |
与本模型 |
|
芒格：「消除信息不对称，决策质量才上得去。」 |
消除信息不对称——决策日志全员可查，不是为了监督，是为了让每个人都能理解决策的来龙去脉 |
|
张磊：「投资就是投人；组织能力是复利来源。」 |
组织知识是复利资产——ADR 库不是文档负担，是团队唯一不会随人员流动而流失的资产 |
极度透明的三个层次：
|
层 |
留痕什么 |
载体 |
|
① 决策留痕 |
为什么这么定、放弃了什么 |
ADR |
|
② 代码留痕 |
改了什么、为什么改 |
PR |
|
③ 运维留痕 |
出过什么事、怎么修的 |
Runbook |
新人占比 >30% 时必须启用——因为这时候「口头传承」已经失效，知识只存在于文档里才安全。
六、冲突仲裁走 Decision Log：当场写清、当场签字（要点③）
内容要点③——raw 未展开，此处基于 P34 评审四段流程与 DES-02 设计权衡模型补齐。
为什么冲突必须走 Decision Log
设计评审最常见的失败，是冲突当场和稀泥：
|
失败模式 |
后果 |
|
「先这样吧，后面再看」 |
三个月后没人记得当初谁同意、为什么同意 |
|
「这个我们再讨论」 |
讨论永远排不上议程，问题烂在那里 |
|
职级最高者一锤定音 |
权威谬误（芒格）——决策质量取决于职级而非证据 |
Decision Log 的作用：把冲突从「口头争论」变成「书面记录 ＋ 当场签字」。
仲裁四步（与 P34 评审四段流程咬合）
|
步 |
动作 |
产出 |
|
① 方案陈述 |
每方案 8 分钟，只讲场景与取舍，不放渲染图煽情 |
三个并列方案（DES-01） |
|
② 红队质疑 |
每人至少一个「这方案会死在哪里」 |
风险清单 |
|
③ 可信度加权打分 |
按场景契合度／可实现性／单位经济性／差异化打分，权重向做过同类事的人倾斜 |
打分表（分数是讨论起点，不是终点） |
|
④ 当场拍板＋签字 |
负责人复述决策理由 → 方案优劣当场写清 → 当场签字 → 全场确认无误解后散会 |
Decision Log 条目 |
四步走完，Decision Log 里必须留下三样东西：
① 选了哪个方案 ② 放弃了什么（被放弃方案的优点显性记录） ③ 本次决策依赖的关键假设与验证方式
签字的真正含义
签字不是「我同意这个结果」，是「我确认这个决策理由被准确记录了」。
未来复盘时检验的不是「这个决策对不对」，而是——
「当时依赖的假设是否成立」（回扣 P34）。
当场写清、当场签字——把「到时候再说」变成「现在就定」，这是 Decision Log 的全部价值。
七、ADR 的传承价值：为什么值得写
47 条 ADR，12 个月——它们沉淀下来的是什么？
|
价值 |
说明 |
|
① 新人 onboarding |
读 ADR 库＝读一遍产品的决策史，新人两天能理解别人一年想清楚的事 |
|
② 供应链谈判 |
成本取舍的依据写在 ADR 里，谈判时直接引用 |
|
③ 复盘对照 |
检验「当时依赖的假设是否成立」，不是检验「决策对不对」 |
|
④ 避免重复吵架 |
同一个问题第二次出现时，翻 ADR 即可，不必重新辩论 |
|
⑤ 技术债清单 |
ADR 的负面后果栏，就是未来要还的债（回扣 P34 设计债台账） |
ADR 与 ADR 的负面后果栏：
12 条 ADR 里，几乎每一条都有「❌」——这些❌不是缺陷，是诚实。
它们共同构成了贯穿项目的技术债与设计债台账。
八、自检：你的决策留得住吗
|
自检问题 |
不合格信号 |
|
① 关键决策都写 ADR 了吗？ |
决策只存在于会议纪要或某人的脑子里 |
|
② ADR 四段写全了吗？ |
只有「决定」，没有「选项」和「后果」 |
|
③ 负面后果写了吗？ |
只写好处的 ADR 是邀功信，不是决策记录 |
|
④ 决策日志全员可查吗？ |
只有管理层能看到，执行层靠口头传达 |
|
⑤ 冲突当场拍板并签字了吗？ |
「先这样吧，后面再看」——后面永远没人看 |
|
⑥ 新人读 ADR 能理解决策史吗？ |
新人入职两周还在问「为什么选这个方案」 |
判读：六项全过 → 决策可追溯、可传承；四项以下 → 你记的是结论，不是决策。
九、金句收尾
极度透明 · 代码与决策留痕——让每个决定都可追溯、可传承。
下面按 第4篇 · 第26章 · 26.1节 归位。这是设计篇的收口章——前面二十五章讲的所有方法，最终都要落到这五件实物上。
先说本页最关键的一件事：统一三套产出物口径。 全书此前出现过三套「设计阶段交付物」清单，口径不一致，本页一次性收口：
|
出处 |
口径 |
件数 |
|
P33（篇开篇） |
规格书／BOM初稿／评审记录／ADR |
四件 |
|
P39（评审门禁） |
产品定义书／交互映射表／设计权衡单合集／验收标准清单 |
四份 |
|
P47（本页） |
产品规格书（含非功能基线）／BOM初稿与定价表／评审十二问记录（含0分整改单）／ADR决策日志／评测集初版与验收标准映射表 |
五件 |
以本页五件套为最终口径——它最完整（多了评测集），且每件都标注了「含什么」。
再处理 raw：末尾混入的 E.0—E.3 是 P46（第25章 ADR）已处理的内容，本页不重复展开，只在第四件处做索引回链。
第26章 设计收口：五件套交付清单
章眼：设计收尾自查——这五件齐了，才准进开发。
26.1 设计阶段交付物清单：五件套（P47）
【开头钩子】
设计收尾自查：这五件齐了才准进开发。
为什么需要一张收口清单：
设计篇二十六章讲的所有方法——三个闸门、RST、非功能基线、可测试性、平台化、模型驱动、六款实战、ADR——最终都要落到实物上。
方法不落物，等于没做。
设计阶段收尾时，团队必须交出五件实物；少一件，技术阶段不开工。
一、五件套总表
|
# |
交付物 |
回答什么 |
收在哪一章 |
|
① |
产品规格书（含非功能基线） |
这产品是什么、长什么样、守住什么？ |
第18章 |
|
② |
BOM 初稿与定价表 |
它花多少钱、卖多少钱、钱从哪来？ |
第18章 |
|
③ |
设计评审十二问记录（含 0 分整改单） |
它过审了吗？没过的谁改、什么时候改完？ |
第19章 |
|
④ |
ADR 决策日志 |
当初为什么这么定？ |
第25章 |
|
⑤ |
评测集初版与验收标准映射表 |
怎么证明它做到了？ |
第18章／第22章 |
五件的关系：①定形状，②算账，③把关，④记账，⑤验货——
缺任何一件，设计就还停留在「大家心里都懂」的层面。
二、第一件｜产品规格书（含非功能基线）
是什么
设计阶段的主文档——把「选中的方案」写成工厂与工程师可直接执行的规格。
必含七项（缺一不可）
|
# |
内容 |
出处 |
|
1 |
IP 人格与品牌一句话 |
P35（品牌三件套） |
|
2 |
目标用户画像与三大核心场景 |
P36（RST） |
|
3 |
硬件规格（器件级） |
P35（规格三张表） |
|
4 |
交互映射表（逐按键／逐手势／逐灯色） |
P35／P44-P45 |
|
5 |
软硬五层架构 |
P41（七层搭系统） |
|
6 |
模型／Prompt 规格（manifest 字段 ＋ 人格 Prompt 七槽位） |
P41／P45 |
|
7 |
非功能基线（安全／隐私／成本三条底线，逐项有数值） |
P37（18.4） |
合格三问（回扣 P39 出口物检验）
|
问 |
检验什么 |
|
新人读完能复述产品是什么吗？ |
定义是否清晰到可传递 |
|
工厂与外包读完能直接报价吗？ |
规格是否具体到可执行 |
|
法务读完能指出合规红线吗？ |
合规是否落在正文、可识别 |
常见缺陷
❌ 规格书写成了「功能清单」——只有做什么，没有守什么（非功能基线缺失）；
❌ 合规条款写在附录里，法务根本看不到；
❌ 交互只写「灯会亮」，没定义颜色语义。
三、第二件｜BOM 初稿与定价表
是什么
单件物料清单 ＋ 定价结构——生意成立不成立，全看这张表。
必含四项
|
# |
内容 |
出处 |
|
1 |
BOM 明细到器件级（含单价、用量、备注） |
P35 |
|
2 |
BOM 总账（芯片＋外围＋PCB＋散热＋电源） |
P35 |
|
3 |
定价表（硬件价／订阅价／毛利率／价格锚点） |
P35 |
|
4 |
三本账联动（BOM ＋ 云端 ＋ 内容摊销） |
P35／P42 |
合格标准
|
项 |
标准 |
|
器件级 |
到器件，不是「主控一套」 |
|
四账联动 |
BOM／定价／订阅／云成本一起算平 |
|
云端地板 |
订阅价必须覆盖云端成本（¥0.28/台/天）后仍有边际贡献 |
常见缺陷
❌ BOM 只算芯片价，漏了外围器件与工艺（毛绒防布屑、硅胶 3C 认证）；
❌ 定价与 BOM 分家——定价拍脑袋，四账不联动；
❌ 订阅定价低于云端成本——卖得越多亏得越多。
成本不是省出来的，是算出来的（回扣 P35）。
四、第三件｜设计评审十二问记录（含 0 分整改单）
是什么
十二问逐条打分的留痕记录——证明这个设计真的被审过，不是走过场。
必含四项
|
# |
内容 |
出处 |
|
1 |
十二问逐条打分（场景／边界／异常／指标／合规／成本／售后七维度） |
P39 |
|
2 |
0 分整改单（整改内容 ＋ 责任人 ＋ 期限） |
P39 |
|
3 |
被否决方案的优点记录 |
P34 |
|
4 |
评审结论的两个转化（测试用例 ＋ 客服 FAQ） |
P39 |
合格标准
|
项 |
标准 |
|
打回率 |
平均 1.5 轮——全票通过的评审多半是走过场 |
|
0 分三要素 |
内容／责任人／期限，缺一不可 |
|
一票否决 |
第 7 问（合规）、第 8 问（可测）中的否决项——0 分即退回 |
常见缺陷
❌ 评审记录只有「通过」两个字，无打分痕迹；
❌ 0 分项写「待完善」——没有责任人等于没扣，没有期限等于不改；
❌ 评审结论没转成测试用例，测试阶段无卷可考。
五、第四件｜ADR 决策日志
📌 raw 末尾混入的「E.0—E.3（ADR-003／007／012）」已在 P46（第25章 25.1） 完整展开，本页索引回链，不重复。
是什么
贯穿项目的决策资产库——记录「当初为什么这么定」。
必含四段（每条 ADR）
|
段 |
内容 |
|
① 背景 |
为什么需要做这个决策？ |
|
② 可选方案 |
有哪几个选项？各自取舍？（通常三个） |
|
③ 决定 |
选了哪个？验收线是什么？ |
|
④ 后果 |
正面 ＋ 负面——负面后果是未来的技术债清单 |
合格标准
|
项 |
标准 |
|
贯穿数据 |
12 个月 47 条；本页精选 12 条 |
|
四段齐全 |
缺「后果」的 ADR 不是决策记录 |
|
负面后果栏 |
必须写——不写代价的 ADR 是邀功信 |
三条最具传承价值的 ADR（深潜见 P46）
|
ADR |
一句话 |
|
ADR-012 |
记忆熊「双人对话」降级为切换式——技术可行，但会编造亲人从未有过的对话 |
|
ADR-031 |
纪念日话术全人工审核——对哀伤中的人，可预期的平凡好过不可预期的惊艳 |
|
ADR-033 |
B 端匿名化铁律——拒绝一家试点企业，换来 B 端信任根基 |
常见缺陷
❌ 只写「决定」，不写选项与后果——后人看不出当初放弃了什么；
❌ 只写好处的 ADR；
❌ 决策只存在于会议纪要或某人脑子里，半年后无人记得。
六、第五件｜评测集初版与验收标准映射表
这是本页五件套里唯一在 P33／P39 两套旧口径中缺席的一件——也是最容易被跳过的一件。
是什么
「怎么证明它做到了」的可执行文件——包含两部分：
|
部分 |
内容 |
|
① 评测集初版 |
AI 功能的回归集（先定「什么叫好」，再动手做） |
|
② 验收标准映射表 |
需求 → 验收标准 → 测试用例编号的三层挂接 |
必含四项
|
# |
内容 |
出处 |
|
1 |
四类评测集（Prompt 回归集／RAG 召回集／路由评测集／TTS-ASR 评测集） |
P38 |
|
2 |
三卷考试通过线（意图 90%／话术 85%+60%／边界 95%） |
P42 |
|
3 |
验收标准四要素（Given／When／Then／阈值） |
P38 |
|
4 |
追溯矩阵（需求 ID → 设计决策 ID → 测试用例 ID） |
P34／P38 |
合格标准
|
项 |
标准 |
|
先于开发 |
先有考卷后有课本——开发完成后的验收只是「跑一遍评测集」 |
|
三层挂接 |
需求 → 验收标准 → 测试用例，编号一一对应 |
|
健康度比例 |
贯穿数据 1 : 2.4 : 6.5（需求 61／决策 148／用例 394）——用例数远超决策数，说明验证有密度 |
常见缺陷
❌ 做完才想「什么叫好」——边上线边补考卷；
❌ 阈值拍脑袋写整数（如「响应 <1 秒」），说不出人类感知或成本权衡依据；
❌ 追溯矩阵没建，出事时全队不知道「哪里连着哪里」；
❌ 评测集先于开发做成了「后于上线」。
测不了的设计，等于没设计（回扣 P38）。
七、三套口径统一表（定稿务必执行）
全书此前出现三套「设计阶段交付物」清单，本页一次性收口——以五件套为最终口径：
|
五件套（本页·最终口径） |
P33 篇级四件 |
P39 设计阶段四份 |
说明 |
|
① 产品规格书（含非功能基线） |
规格书 |
产品定义书 |
合并：定义书是规格书的正文前半；本页新增「含非功能基线」的强制标注 |
|
② BOM 初稿与定价表 |
BOM 初稿 |
— |
P39 未列，本页补回 |
|
③ 评审十二问记录（含 0 分整改单） |
评审记录 |
— |
本页明确「含 0 分整改单」 |
|
④ ADR 决策日志 |
ADR 决策日志 |
设计权衡单合集 |
合并：权衡单是 ADR 的条目来源，ADR 是归档形态 |
|
⑤ 评测集初版与验收标准映射表 |
— |
验收标准清单 |
升级：从「清单」升级为「评测集 ＋ 映射表」，可机检 |
|
— |
— |
交互映射表 |
并入①：交互映射表是产品规格书的第 4 项必含内容 |
定稿建议：
|
动作 |
内容 |
|
① |
P33 篇开篇的「四件产出物」改为五件，并加交叉引用「详见第26章」 |
|
② |
P39 的「设计阶段四份出口物」在文末加注：「与第26章五件套的对应关系见表」，避免读者困惑 |
|
③ |
全书统一使用五件套表述，不再出现「四件／四份」 |
八、收口门禁：五件套自检表
设计阶段关门前，逐条打勾。有任何一件不齐，不准进开发。
|
# |
交付物 |
自检问题 |
不合格信号 |
|
① |
产品规格书 |
新人能复述、工厂能报价、法务能指红线吗？ |
只有功能清单，非功能基线缺失 |
|
① |
（同上） |
交互映射到按键级／灯色级了吗？ |
只写「灯会亮」 |
|
② |
BOM 与定价 |
BOM 到器件级了吗？ |
只算芯片价 |
|
② |
（同上） |
四账联动（BOM／定价／订阅／云）算平了吗？ |
订阅价低于云端成本 |
|
③ |
评审记录 |
十二问逐条打分了吗？ |
只有「通过」二字 |
|
③ |
（同上） |
0 分项有责任人与期限吗？ |
写「待完善」，无人认领 |
|
④ |
ADR 日志 |
每条四段齐全（含后果）吗？ |
只有「决定」 |
|
④ |
（同上） |
负面后果写了吗？ |
只写好处的邀功信 |
|
⑤ |
评测集与映射表 |
评测集先于开发建了吗？ |
上线后才补考卷 |
|
⑤ |
（同上） |
需求→验收→用例编号挂接了吗？ |
出事查不出「哪里连着哪里」 |
判读：
|
结果 |
结论 |
|
十项全过 |
设计阶段关门，签字进开发 |
|
八项 |
限期补全（3 个工作日内），可有条件进开发 |
|
七项以下 |
不准进开发——退回设计阶段 |
这五件不是文档负担，是把 FDE 脑子里的东西变成组织资产的手段（回扣 P35）。
九、金句收尾
没有绝对最好，只有场景下最合适，对比看清取舍。
下面按 第5篇 · 第28章 · 28.1节 归位。设计篇（第17—27章，共十一章）已完整收官，本页开启技术篇——从「把对的样子定下来」进入「把对的样子做出来」。
先做最重要的一件事：清理 raw。 本页 raw 中约 85% 是另一本 AI/编程通识教材的内容——深度学习六大模型（CNN／RNN／自编码器／GAN／Transformer／DRL）、PyTorch 全套教程（张量操作／梯度／激活函数／损失函数／搭建神经网络）、30 种经典 AI 算法工程（G:\123456\ai-algorithms-30）、「软件吃透世界」（扫码支付旅程／代码即法则）、微处理器与微控制器区别、嵌入式开发环境搭建——与本书「六款 AI 硬件 ＋ ESP32-S3 ＋ 238 套模型」体系完全不同源，已全部删除并标注归位。
真正属于本页的只有：篇定位、开头钩子、三条内容要点、金句收尾。其中要点②③（认知垫层策略、本篇路线）raw 只给了一行，已展开。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)