8 周 · 61 篇核心阅读 · 8 个实战输出。进度与笔记只保存在这台设备的浏览器中，每个 PDF 均可直接打开。
完成 7 篇核心资料后，我对硬件产品经理的理解，从“负责提出功能需求的人”，升级为“以用户和商业目标为起点，协调多专业资源，对产品全生命周期结果负责的人”。
硬件产品经理的核心工作，是在用户价值、技术可行性、成本、周期与质量之间持续做取舍，并推动一个产品从机会判断走到稳定量产、上市运营和生命周期管理。
我的理解：纵向要推动阶段向前，横向要管理 ID/结构、电子、嵌入式、App/云、供应商与生产的协同；每个阶段都必须有清晰的输入、输出、负责人和退出标准。
| 维度 | 软件产品 | 硬件 / 智能硬件 | 对我的工作要求 |
|---|---|---|---|
| 开发方式 | 敏捷、小步迭代 | 重规划、长周期、阶段冻结 | 尽早验证关键假设，建立变更机制 |
| 成本结构 | 边际成本接近于零 | 每台都有物料、制造、物流与售后成本 | 规格、BOM、售价和毛利必须联动 |
| 质量风险 | 多数问题可发版修复 | 缺陷可能导致返修、退货或召回 | 量产前验证完整性和可靠性 |
| 用户决策 | 试用成本较低 | 购买是相对重决策 | 价值、价格与用户购买力要匹配 |
| 协作范围 | 设计、研发、测试、运营 | 增加 ID、结构、电子、采购、工厂、品控和售后 | 提升跨专业沟通与资源整合能力 |
| 规划视角 | 可通过多个版本逐步实现 | 要判断上市时的需求和竞争力 | 为半年到两年后的市场做决策 |
第一阶段让我看清了地图，但还没有回答“用户为什么需要戴它”。进入模块 02，我要重点验证：目标人群是谁、最高频和最痛的场景是什么、手机为何不能替代、现有方案哪里不足，以及用户愿意为多大的价值支付多少钱。
从场景约束到完整需求判断：识别需求来源，通过消费者研究与现场访谈验证认知和行为，再用电商信号与实物评测交叉验证市场、产品价值和竞争机会。
先还原用户在什么时间、什么空间使用产品，再让场景约束功能与参数；不能被场景证明的需求要谨慎保留，被场景强制要求的能力必须进入产品定义。
| 场景问题 | 需要确定的需求 | 可能牵动的硬件 / 方案 |
|---|---|---|
| 卧室到洗手间有多远？是否已有照明？ | 覆盖距离、安装位置、是否需要多个产品 | 灯体数量、光学设计、安装结构 |
| 夜间需要多亮？ | 例如 50 / 100 / 250 lux，不刺眼但能安全行动 | LED规格、驱动、电池容量与散热 |
| 需要什么色温？ | 暖光、分档或无级调节 | 灯珠组合、驱动与控制算法 |
| 如何供电？ | 干电池、锂电池或 AC，续航与充电方式 | 低功耗 MCU、充电保护、LDO / DCDC、整流滤波 |
| 如何开启和关闭？ | 物理按键、手机控制、墙体开关或自动感应 | 按键、蓝牙 / Wi-Fi、光感、人体或距离传感器 |
| 何时触发？ | 睡前、夜间起床、早晨或其他时段采用不同规则 | 传感器融合、定时逻辑、联网与离线策略 |
关键经验：功能列表不是分析起点。先问场景条件，才能判断是否需要联网、屏幕、某种传感器或更高性能处理器，并避免“为了智能而智能”。
说明：原文以“时间 + 空间”为核心。这里加入用户状态、触发、资源、异常和验证，是我面向可穿戴 AI 产品的复用增强。
建议把功能需求改写为：
这句话可以同时指导 PRD、技术方案和测试用例。
| 可穿戴场景 | 关键约束 | 可能导出的产品需求 |
|---|---|---|
| 通勤步行时使用 AI 耳机 | 风噪、车流、双手占用、网络波动 | 抗风噪、语音唤醒、低时延、离线指令和安全提示 |
| 会议中使用 AI 眼镜 | 公共空间、旁观者隐私、长时间佩戴 | 录制指示、权限控制、低温升、轻量化和静默交互 |
| 运动时使用手表/戒指 | 汗液、震动、动作伪影、无法持续看屏 | 防护等级、传感器稳定性、触觉反馈和异常数据过滤 |
| 睡眠时持续监测 | 整夜续航、贴肤舒适、弱感知交互 | 低功耗、材料安全、自动识别和早晨集中反馈 |
用户给出的是信息，不一定是真实需求；产品经理要从用户、场景、业务和市场中找到原始需要，再判断它是否具有足够的群体价值、实现价值和商业价值。
两篇文章的关系：上一篇的“场景约束”是一把需求显微镜；本篇给出的是从获取、分析到选择的完整管道。
| 阶段 | 主要需求渠道 | 核心工作 | 需要升级的判断 |
|---|---|---|---|
| 初级 | 领导指示、产品迭代、用户/同事反馈 | 澄清细节、确认实现、推动交付 | 不能只问“怎么做”，要理解“为什么做” |
| 中级 | 用户研究、竞品分析、头脑风暴、产品数据 | 主动挖掘需求并转化为功能和价值 | 产品能满足谁、优势是什么、如何提升竞争力 |
| 高级 | 行业、市场、用户、数据、技术、政策 | 规划产品/产品线、商业化、壁垒与矩阵 | 判断条件与时机是否成熟、需求是否值得投资 |
我的启发：成长不是接触更多渠道，而是从“执行已知需求”逐渐升级到“发现机会并决定不做什么”。
复用经验：不要机械地给四个格子填词。要找到每个因素发生变化后，产品必须怎样变化，以及它是否会引出新的功能、硬件或工作模式。
只有四层证据能相互解释时，才适合进入硬件产品定义。
| 对象 | 核心价值 | 关键分析维度 | 主要风险 |
|---|---|---|---|
| B 端 | 盈利、增效、减负 | 性价比、定制化、模块化、通用性、场景 | 一次性定制无法复用；通用过度导致成本和竞争同时上升 |
| C 端 | 特定人群愿意购买的核心体验 | 精准用户、场景、用户体量、核心需求聚焦 | 用户选错难以靠迭代修复；小众需求不足以覆盖硬件固定成本 |
先问价值是否大于成本；再判断是真定制还是潜在通用需求。能复用的差异优先通过通信、供电、安装和产品形态的模块化解决，但模块化本身也必须计算成本收益。
硬件很难做到千人千面，应先选择足够精准、体量又能支撑盈利的用户群，再围绕大多数人的核心需求定义统一产品。
优先级 = 用户覆盖 × 场景频次 × 痛点强度 × 支付/业务价值 ÷ 实现成本与风险
说明：上式是我根据文章观点整理的评审工具，并非原文给出的数学公式；它用于强迫团队暴露判断依据，不追求虚假的精确分数。
UA 研究不是为了生成一份厚报告，而是系统回答：市场是否有机会、目标消费者是谁、如何做出购买决策、现有产品哪里没满足，以及下一代产品应该向哪里创新。
复用经验：产品经理应先组织内部团队对研究问题达成一致，再与外部机构沟通；不能把“定义研究问题”的责任外包。
如果背景不能指向明确的决策，就不应直接开始访谈；否则很容易收集大量“有趣但不可行动”的信息。
| 研究模块 | 要回答的问题 | 最终用于什么决策 |
|---|---|---|
| 市场概况与趋势 | 规模、品牌占比、竞争、价格带及未来 1–3 年趋势 | 是否进入、品类定位和产品节奏 |
| 消费者整体态度 | 关注度、困扰、替代方案、购买和使用原因 | 价值主张与市场教育 |
| 用户画像 | 人口/社会属性、生活形态、消费状态、审美偏好 | 目标人群、设计和渠道 |
| 需求挖掘 | 认知、真实行为、满足程度和未满足需求 | 功能、形态与体验定义 |
| 现有产品评价 | 功能、外观、价格、服务及替代性 | 改进点与差异化 |
| 方向输出 | 关键洞察能推导出哪些产品、营销和服务建议 | 立项和方案优先级 |
案例里的地域、性别和收入比例是电动剃须刀研究示例，不应直接迁移到其他品类。
我的理解：先问态度容易得到“正确答案”，先还原具体行为更容易发现真实权衡。因此访谈时应多问最近一次经历、具体动作和实际选择。
决策路径的价值，是同时连接产品和增长：同一个障碍可能需要产品改进，也可能需要内容教育、渠道体验或售后服务解决。
复用原则：画像不是给用户起昵称、贴性格标签。每个字段都应能解释需求、购买、使用或审美为何不同；不能影响决策的字段可以删除。
| 研究发现 | 需要继续判断 | 可形成的行动 |
|---|---|---|
| 目标人群与典型画像 | 体量、支付能力、可触达性是否成立 | 产品定位、定价、渠道选择 |
| 决策路径与购买驱动 | 哪个触点最影响成交或流失 | 卖点、内容、体验和推广策略 |
| 满意点与未满足需求 | 频次、痛感、替代方案、付费意愿 | 功能优先级和下一代产品定义 |
| 产品/服务评价 | 问题来自产品、认知还是服务 | 体验优化、服务设计、用户教育 |
| 创新机会 | 技术、成本、供应链和市场时机 | 概念测试、MVP 和立项验证 |
耳听不一定为实，眼见也不能自动解释原因。只有把用户的行为、原话、当时场景和追问结果放在一起，产品经理才有机会接近真实需求。
作者用“包装是否吸引购买”和“安装过程是否顺畅”作为两个明确目标，说明一次访谈不宜试图解决所有问题。
| 准备项 | 文章经验 | 我沉淀的检查问题 |
|---|---|---|
| 研究目标 | 具体、有限，避免目标过大导致过程失焦 | 访谈结束后要决定什么？最多列 1–2 个主目标 |
| 目标用户 | 必须来自产品真正的目标人群 | 哪些经历、行为或角色是筛选条件？谁不应该进入样本？ |
| 研究组合 | 定性深挖原因，定量验证普遍性，两者结合 | 这次访谈探索什么？后续用什么样本验证？ |
| 环境与物品 | 尽量还原真实使用环境，工具也用用户平时能获得的 | 实验室环境会不会改变行为？缺了哪些真实约束？ |
| 访谈提纲 | 口语化、预估时长、为每题准备深入追问 | 问题是否暗示答案？体验与访谈时间是否合理？ |
| 演练 | 正式执行前反复排练 | 主持、记录、观察如何分工？设备和流程哪里可能出错？ |
| 行为 | 表达 | 判断 |
|---|---|---|
| 顺利 | 满意 | 优势较可信，继续追问价值与替代性 |
| 困难 | 没问题 | 可能礼貌、未意识到或已习惯，应结合行为深挖 |
| 顺利 | 不满意 | 可能是情绪、审美、期待或其他场景问题 |
| 困难 | 不满意 | 高优先级问题候选，但仍需验证覆盖面和严重度 |
| 记录字段 | 示例 | 作用 |
|---|---|---|
| 场景与任务 | 首次安装，在模拟家庭环境中完成固定 | 限定结论适用条件 |
| 客观行为 | 阅读说明 12 秒后放下，连续尝试两个方向 | 保留未解释的事实 |
| 用户原话 | “我以为这个面应该朝外” | 保留认知线索 |
| 追问所得 | 依据常见产品经验判断方向 | 寻找行为背后的原因 |
| 团队假设 | 造型与标识造成方向误判 | 明确这是推断而非事实 |
| 设计机会 | 增加防呆结构或方向标识 | 连接产品动作 |
| 待验证项 | 换样本与真实家庭环境复测 | 避免一次访谈直接定案 |
奖励建议在体验和访谈结束后再给，降低用户为了奖励“配合回答”的可能性。
重点观察：用户在哪里停顿、什么时候摘下设备、何时转而使用手机、AI 失败后是否愿意重试，以及用户嘴上说“可以接受”的隐私和订阅成本是否真的影响选择。
先明确用户要解决的问题和评测决策，再选择有代表性的价格带与产品；从外到内拆解，以统一条件测量，用真实体验解释数据，最终判断产品价值是否配得上定位与价格。
| 层级 | 主要观察项 | 要回答的产品问题 |
|---|---|---|
| 工业设计 | 包装、内部布局、主机、细节、材料、内部部件与结构 | 价值感、制造质量、可靠性、可维护性是否匹配定位？ |
| 性能参数 | 尺寸、重量、噪声、振幅、实际频率、电池、电机 | 宣传数据是否真实？关键性能由什么结构与器件决定？ |
| 产品体验 | 操作、模式、附件拆装、握持、防滑、售后与差异化亮点 | 用户能否顺利完成任务？亮点是真价值还是展示性功能？ |
结论应标明数据来源。官方信息和实测不一致时，不能只选对自己观点有利的一边；要检查测试方法、样本差异和测量误差。
| 维度 | 可测指标 | 需要解释的因果关系 |
|---|---|---|
| 佩戴与结构 | 重量、重心、夹持力、尺寸、温升、防护 | 电池/芯片/材料/结构如何影响舒适与可靠性 |
| 续航与连接 | 典型任务续航、待机、充电、断连与恢复 | 功能负载、网络方式和端云策略如何影响功耗 |
| AI 任务 | 成功率、延迟、误触发、失败恢复、离线能力 | 模型、麦克风/摄像头、算力和网络如何共同决定体验 |
| 交互体验 | 上手时间、单手/免手操作、反馈、纠错成本 | 状态设计与输入输出方式是否符合移动场景 |
| 隐私与服务 | 提示、授权、数据删除、订阅、质保与售后 | 信任成本是否与产品价值和品牌承诺匹配 |
排名告诉我市场在买什么，价格与排名变化帮助观察销售规律，售前问答暴露购买阻碍，售后评价揭示使用结果；四类证据必须结合，才能转化为产品、定价和卖点决策。
| 数据 | 可以支持的判断 | 不能直接下的结论 |
|---|---|---|
| 品类排名 | 哪些产品值得作为代表样本，热度如何变化 | 排名不等于精确销量，也不自动代表用户满意 |
| 价格 × 排名历史 | 价格带、促销反应、淡旺季和发布日期参考 | 相关变化不一定由价格单独造成 |
| 售前 Q&A | 购买前最担心什么、哪些信息页面没有讲清楚 | 提问多不一定代表所有用户都需要该功能 |
| 售后评价 | 满意点、痛点、质量问题、功能替代与改进机会 | 评论可能存在选择偏差、操纵或版本混杂 |
| 观察到的信号 | 可能解释 | 下一步验证 / 动作 |
|---|---|---|
| 降价后排名改善 | 价格弹性、促销流量或季节共同影响 | 对照多个时间段、竞品与促销事件后再定价 |
| 反复询问某功能 | 购买阻碍、页面不清晰或需求分层 | 优化信息表达；验证是否值得新增/调整功能 |
| 某问题集中差评 | 设计缺陷、批次质量、误用或预期错配 | 按版本/批次/场景拆分，结合售后和实物复测 |
| 高价产品仍领先 | 品牌、质量、独特体验、服务或渠道优势 | 寻找溢价证据，不能只复制规格表 |
| 自家排名持续下降 | 定价、替代品、品质、评价或竞争变化 | 同步检查价格、评论、竞品动作与库存状态 |
资料边界：前四篇覆盖场景约束、需求判断、UA研究与用户访谈；第五篇用筋膜枪拆解演示工业设计、性能和体验评测；第六篇用Amazon榜单、价格、问答和评论分析爆品。页面中的优先级公式、证据等级、偏差控制、竞品验证闭环与可穿戴迁移，是我在六篇方法基础上的产品化整理。
从机会证据、5W2H 和风险验证，到硬件 MVP、原子化需求与完整 PRD：把想法收敛成可研发、可测试、可生产、可追踪、可定价和可迭代的系统定义。
硬件产品定义的最终成果，不是一份“大而全”的文档，而是一套分层一致的决策系统：业务有依据、MVP有边界、需求可验收、架构能协同、生产可落地、变更可追踪。
原文强调：Word、Excel、PPT 都可以，MRD 与 PRD 也可以合成 MPRD；名称和工具不是重点，思路、内容和表达清晰度才是重点。
理解方式：MRD 负责证明“方向值得做”，PRD 负责说明“产品怎样落地”。两者可以分开，也可以合并，但七个问题之间不能相互矛盾。
需求定义不是把用户意见抄进文档，而是把“用户想要什么、产业能做什么、渠道卖得动什么、竞品已经做到什么”交叉验证后，收敛成产品边界。
| 调研对象 | 原文给出的方法 | 需要带回产品定义的结论 |
|---|---|---|
| To C 用户 | 社交媒体问卷、有奖问答、咨询公司约访、线下门店一对一沟通。 | 真实场景、用户语言、偏好、痛点、感知价值与购买阻力。 |
| To B 客户 | 约见核心渠道客户；其需求往往汇集了大量终端用户信号。 | 渠道经营方式、套餐或补贴条件、目标客群、定制与交付要求。 |
| To B to C | 同时研究渠道客户背后的终端用户，理解不同营销方案对应的人群。 | 谁购买、谁使用、谁付费，以及产品如何与渠道方案共同成交。 |
| 用户认知 | 智能电视案例显示，普通用户的价值判断可能与专业人员的客观成本认知不同。 | 卖点和组合方式要匹配用户“觉得值不值”，不能只讲参数是否先进。 |
我的判断：渠道客户的意见可以提高调研效率，但不能自动等同于终端用户真相；最好把渠道信号与直接访谈、行为数据和购买结果交叉验证。
| 对象 | 可以获得的关键信息 | 写回定义的字段 |
|---|---|---|
| 代工厂 / 方案商 | Turn-key成熟度、公模公板、器件组合、能力栈、账期和交付方式。 | 方案边界、定制深度、开发周期、供应分层和制造风险。 |
| 核心芯片厂 | 可靠方案商、友商规划、首单和生命周期量、核心器件成本、未来 1-2 年 Roadmap。 | 平台选型、BOM假设、供货能力、技术代际和上市窗口。 |
| 算法 / 软件 / 云服务商 | 麦克风阵列、ASR、NLP、TTS、App、底层软件、设备后台、账号后台及内容服务能力。 | 端云分工、供应商责任、接口依赖、内容生态、服务成本与长期维护。 |
| 下游渠道 | 利润空间、套餐档位、补贴上限、软件接入、ID/包材定制、备货、退换和备用机要求。 | 渠道版本、目标成本、价格体系、库存、交付和售后规则。 |
可复用经验：供应商调研不只是“询价”，而是在确认能力归属、技术路线、交付条件和成本结构；这些信息会直接改变 WHAT、HOW、WHEN 与 HOW MUCH。
| 渠道 | 原文中的经营特征 | 定义阶段要提前处理 |
|---|---|---|
| 线下渠道 | 分销层级和经营成本更高，通常需要更充足的利润空间，但可以下沉覆盖更广市场。 | 渠道毛利、价格体系、区域客群、陈列、人员讲解、ID/包材定制与售后。 |
| 运营商渠道 | 产品可与话费、宽带等营销案绑定，通过补贴或签约周期完成成交。 | 套餐人群、补贴上限、账号/设备平台接入、通话等专属能力和首批铺货。 |
| 线上渠道 | 整体运营成本相对低，适合利润较薄的产品，但平台仍可能要求账期、核心仓备货和退换备用机。 | 平台费用、库存节点、履约时效、退换货成本、详情页表达和价格一致性。 |
原文建议深入拆解 1-2 款成功产品。我的补充是：再加入一个同价位普通样本或失败样本，避免只从赢家身上总结“成功公式”。
| 决策项 | 用户证据 | 产业 / 平台证据 | 渠道 / 竞品证据 | 结论与下一步 |
|---|---|---|---|---|
| 目标人群与场景 | 访谈、观察、问卷、行为 | 技术是否支持场景 | 渠道客群、竞品覆盖 | 结论、置信度、反证 |
| 核心功能与规格 | 价值、频次、容忍阈值 | 器件、算法、成本、周期 | 竞品基线、差异空间 | 目标值与测试计划 |
| 价格与销售方式 | 感知价值、支付意愿 | BOM、服务费、账期 | 渠道毛利、补贴、售价 | 价格假设与市场实验 |
| 首批量与上市窗口 | 潜在需求和采用阻力 | 产能、交期、Roadmap | 首铺、退换、竞争节奏 | Forecast与风险预案 |
详细计划不是为了假装一切已知，而是用尽可能低的成本，把最可能击穿项目的未知提前暴露、拆小并验证。
| 载体 | 最适合验证 | 不能替代什么 |
|---|---|---|
| 泡沫 / 3D 打印模型 | 尺寸、握持/佩戴、操作位置、机械空间；也能促使工程团队提前发现结构和电子问题。 | 通常不能完整呈现最终功能、材质手感和准确颜色。 |
| 2D / 3D 渲染图 | 外观比例、颜色、细节与方案沟通。 | 无法直接接触，不能证明人体工学、装配与功能可行。 |
| 用例 / 流程图 | 用户任务、交互步骤、状态与软件开发工作量。 | 不能证明硬件性能、器件供货和真实环境体验。 |
| 需求 / 规格文档 | 必须实现的功能和量化边界，例如“电池至少运行一年”。 | 文档里的目标仍需样机、测试或数据证明可以实现。 |
复用判断：选原型前先问“我要消除哪个未知？”低保真模型不是低价值，只有与问题不匹配的原型才是浪费。
原文边界图用 BOM、总投入、缺陷率、蓝牙连接失败率和上市时间等指标围住设计空间。关键不在图形本身，而在于把“做一个好产品”改写成团队可以权衡、测量和评审的条件。
迁移到可穿戴 AI：“更轻、更薄、全天候、实时 AI”往往同时牵动电池、散热、传感质量、计算量和联网方式；应优先验证其中最脆弱的组合，而不是先做完整 App 和漂亮外壳。
| 重大未知 | 失败后果 | 最小验证 | 通过标准 | 回写项 |
|---|---|---|---|---|
| 目标续航下能否持续采集与推理 | 尺寸、功能或商业承诺被推翻 | 开发板 + 目标传感器功耗实测 | 典型/极端场景均低于功耗预算 | 电池、算法频率、外形、BOM |
| 佩戴状态下信号是否可靠 | 核心数据无效、用户不信任 | 低保真佩戴件 + 多人多场景采样 | 覆盖率、误差和丢失率达到阈值 | 结构、传感器位置、算法、提示 |
| 端侧 / 云侧 AI 能否满足体验 | 延迟、费用、隐私或断网体验失控 | 关键链路原型 + 真实网络测试 | 准确率、P95延迟、费用和失败率过线 | 端云分工、芯片、订阅与兜底 |
硬件 MVP 是产品的第一个可交付版本：功能足够少，以便尽快进入市场；核心体验又必须足够好，让早期客户愿意购买、使用并提供真实反馈。
| 载体 | 核心问题 | 完成标准 | 不应该承担 |
|---|---|---|---|
| POC / 原理验证 | 最关键的技术是否可行？ | 目标条件下关键指标被证明。 | 完整体验、量产质量和商业销售。 |
| 交互 / 外观原型 | 用户是否理解、愿意使用，形态是否合理？ | 关键流程与形态假设得到反馈。 | 真实器件性能和批量制造。 |
| 硬件 MVP | 早期客户是否愿意为核心解决方案付费？ | 可生产、可交付、可使用、可收款并采集数据。 | 满足所有人、承载所有规划功能。 |
| 小批试点 | 产品与交付系统在受控规模下是否稳定？ | 验证良率、履约、激活、售后、退换和运营指标。 | 一开始就做大规模分发。 |
这张对照表是我结合第 3、4 篇做的阶段化整理；原文重点在概念验证和硬件 MVP，并未使用“小批试点”这一独立分类。
原文的智能门锁案例中，团队同时开发蓝牙、蓝牙钥匙、密码、指纹和远程 Wi-Fi 等开锁方式；后台数据却显示 90% 以上客户主要使用指纹，投入巨大的蓝牙安全开锁几乎没有被使用。
原则：在看到真实数据之前，不把任何一格当作事实；每格都要对应访谈、原型、预售、小批交付或使用数据等验证方式。
| 功能类型 | 处理方式 | 原因 |
|---|---|---|
| 高用户优先级 + 低成本 / 低复杂度 | 优先纳入 MVP | 能快速提升核心价值，又不显著推高制造和时间成本。 |
| 低用户优先级 + 高成本 / 高复杂度 | 从 MVP 删除 | 既不重要，又明显增加延期、售价和质量风险。 |
| 高优先级 + 高成本 / 高复杂度 | 单独验证与降级 | 寻找更简单方案、降低交付级别，或先验证用户是否真愿意付费。 |
| 低优先级 + 低成本 / 低复杂度 | 默认不加 | “顺手能做”仍会产生测试、文档、售后和认知负担。 |
| 能提高销量或利润率的功能 | 评估其增量利润 | 售价提升或销量增长必须超过研发、制造和质量成本。 |
我的功能评分字段：用户证据、场景频次、核心任务影响、开发成本、开发时间、BOM增量、质量风险、售价提升、销量提升、可逆性。
| 阶段 | 可穿戴 AI 例：会议记录设备 | MVP 需要回答 |
|---|---|---|
| Before | 购买、开箱、佩戴、授权、配对、隐私告知 | 哪些准备动作若失败，用户将无法进入核心场景？ |
| During | 启动、录音、状态反馈、断网、低电、多人说话、隐私暂停 | 核心任务最低可接受的准确率、时延、续航和失败提示是什么？ |
| After | 同步、摘要、编辑、分享、删除、充电、数据导出 | 哪一步决定用户是否感知到完整价值并愿意再次使用？ |
客户旅程的目的不是为每个问题都做最高级方案，而是从左到右为每个核心问题选择 MVP 的解决层级，保证整条价值链不断裂。
原文立场：真正的硬件 MVP 不是用来寻找业务模型，而是向客户快速交付简单出色的产品，并依靠现金流使产品持续变好。这一表述与常见软件精益创业语境不同，应用时要先确认团队对“MVP”的定义。
MVP 可以删掉次要功能、降低实现复杂度，却不能删掉让产品在目标场景中成立的核心指标；否则得到的只是更快完成的错误方案。
| 当时判断 | 暴露的事实 | 错过的转向点 | 复用经验 |
|---|---|---|---|
| 选择非主流 Sony 芯片，以更低成本做差异化设备。 | 产品交付后，夜间图像清晰度这一核心指标无法满足公安/交管最终用户。 | 开发约两个月的第一版已经发现差距，本应带原型找客户验证。 | 先定义不可妥协的场景指标，再谈芯片价格和算法补偿。 |
| 继续加补光设备和算法优化，有机会追平。 | 多次试验与竞品对比后，集成商仍只能更换其他厂商设备。 | 团队受信念和既有投入驱动，在错误方向上继续加码。 | 验证失败应触发方案重选或停止，而不是自动进入“再优化一次”。 |
物联网产品选用的 MCU 只有 32KB Flash，单机基本功能可以运行；但需求没有把集群规模推演到极值，设备数量增加后程序复杂度上升，内存接近极限，只能牺牲部分功能赶项目上线。
精益画布来自原文引用的方法，用于快速暴露前期假设；它不能代替后续的指标测试、供应链核实和财务模型。
| 坑 | 为什么危险 | 定义阶段的动作 |
|---|---|---|
| 核心芯片没有演进余量 | 下一轮功能、规模或软件增长很快撞到资源上限。 | 结合行业路线和产品演进预估 CPU、Flash、RAM、接口与算力余量。 |
| 以 MVP 为由跳过关键步骤 | 关键性能到量产或客户现场才暴露，修改周期长。 | 至少完成样机评审、关键单元测试和市场核心指标对比。 |
| 被沉没成本绑架 | 投入越多越不愿改，最终把更多资源压在已被推翻的假设上。 | 预设停止/转向阈值，让客户事实和测试数据触发决策。 |
| 版本之间没有传承 | 结构、构思完全重来，无法复用验证、代码、供应链和工具。 | 技术选型、硬件框架和结构尽量模块化、标准化，再做芯片与功能升级。 |
| 用非正规器件追求速度 | 高仿、批次不一致、不稳定和知识产权问题让验证结论失真。 | 通过原厂、授权代理与可追溯渠道采购，前期可适当放宽样件成本。 |
工程师选器件、画原理图之前，要先把功能、行为、操作条件与预期性能形式化；否则设计会替团队偷偷做出尚未讨论的产品决策。
| 概念 | 定义 | 续航例子 | 管理方式 |
|---|---|---|---|
| 需求 Requirement | 产品上市前必须做到、可量化的事情。 | 连续供电不少于 5 小时。 | 必须验证；不满足就不能判定通过，或需要正式变更。 |
| 目标 Goal | 希望尽量做到，但较难量化或不一定能达到的方向。 | 争取达到 7 小时。 | 用于引导优化，不应伪装成发布门槛。 |
| 规格 Specification | 开发和测试后，对产品实际能力的量化描述。 | 满电可可靠运行 6 小时。 | 用于手册、宣传和选型；也可能成为下一版需求。 |
关键区别：需求是承诺，目标是方向，规格是事实。三者可能相互转化，但在同一版本中必须标清身份。
| 类型 | 回答的问题 | 例子 |
|---|---|---|
| 功能需求 | 系统应该执行或提供什么能力？ | 移动电源能够测量电池温度；指纹 U 盘支持录入和识别指纹。 |
| 非功能需求 | 系统必须具备哪些属性、质量或运行约束？ | 产品可在 0-40℃ 工作；目标可靠性、安全、尺寸、寿命与性能阈值。 |
| 属性 | 作用 | 检查问题 |
|---|---|---|
| 标题 + 唯一 ID | 让讨论、变更和缺陷引用同一对象。 | 是否唯一、稳定、易检索？ |
| 需求正文 | 描述产品必须做什么及适用条件。 | 是否原子、明确、无隐含方案？ |
| 来源 + 理由 | 说明来自客户、合同、法规或内部决策，以及为什么存在。 | 来源是否可靠？删除会造成什么影响？ |
| 优先级 + 安全标记 | 处理冲突、范围裁剪和安全关键需求。 | 不实现时能否发布？是否影响人身/数据安全？ |
| 验证方法 | 规定用测试、分析、检查还是现场验证证明。 | 谁在何种条件下用什么阈值判定？ |
| 跟踪与版本信息 | 连接设计、测试、结果、变更历史和责任人。 | 能否追到上游依据和下游实现？ |
我的产品化句式：“[系统/角色] 应在 [条件] 下完成 [可观察行为]，并达到 [量化阈值]；通过 [验证方法] 判定。”这是对原文规则的结构化整理，不是原文规定的唯一模板。
原文用“必须使用可更换 5 号电池”说明过度约束：它会锁定最小尺寸、电池仓盖、材料、成型工艺、内部布局与散热。除非“随时更换电池”本身是核心价值，否则更好的需求可能是尺寸、重量、续航和恢复供电时间。
| 过早指定方案 | 更聚焦结果的表达 | 何时可以指定方案 |
|---|---|---|
| 设备必须使用某型号可更换电池。 | 在目标使用模型下续航 ≥ X 天，补能后 Y 分钟内恢复，重量 ≤ Z g。 | 法规、兼容、维护、采购或用户场景确实强制时。 |
| 必须用某款芯片在端侧运行模型。 | 断网时完成某任务，P95延迟 ≤ X，能耗 ≤ Y，准确率 ≥ Z。 | 已有平台、授权、供应或安全架构构成硬约束时。 |
把“怎么做”留给设计团队，不代表需求不技术化；条件、接口、性能、安全和验证阈值仍要足够具体。
| 模糊说法 | 可验证改写 | 验证方式 |
|---|---|---|
| 产品应该是安全的。 | 产品应符合目标销售地区适用的全部安全法规，并列明具体标准。 | 认证、审查与法规测试。 |
| 产品应该适合装进口袋。 | 尺寸不超过 8×10×2 cm；或目标市场 90% 用户认为可轻松放入和取出。 | 尺寸测量；或按样本方案进行用户测试。 |
| 可穿戴设备佩戴舒适。 | 目标用户连续佩戴 2 小时后，≥90% 的样本舒适度评分达到预设阈值，且无规定等级以上皮肤不适。 | 受控佩戴测试 + 问卷 + 皮肤观察。 |
| AI 摘要准确、响应快。 | 在已定义测试集和场景下达到指定质量分、事实错误率与 P95 端到端时延。 | 离线数据集评测 + 真实网络端到端测试。 |
第三、四行是我依据原文“清晰、量化、可验证”原则所做的可穿戴 AI 示例，具体阈值必须通过用户研究和工程验证确定。
原文提醒：“使用蓝牙/USB”只规定了通信管道，不代表高层数据、协议和供电已经清楚；接口应尽早提出、尽早联调，并持续完善测试子系统。
原文指出，需求完成前可能修改原始内容的 50% 以上；这一比例应理解为经验性提醒，重点是建立协同、影响分析、历史记录和可追溯机制。
硬件 PRD 不只描述功能，还要让设计、研发、测试、生产和合作方理解同一产品：为何做、在哪用、由什么组成、达到什么性能、怎样验证、如何生产，以及谁负责什么。
| 层级 | 章节 | 核心输出 |
|---|---|---|
| 背景与边界 | 01 项目简介 02 使用场景 03 产品原则 | 为什么做、是什么、任务在哪里发生，以及选择时遵循什么原则。 |
| 系统与能力 | 04 硬件组成及关系 05 功能需求 06 性能需求 | 系统框图、部件关系、功能职责和量化性能。 |
| 数据与连接 | 07 接口需求 08 存储需求 | 内部/外部接口、协议、兼容替代，以及容量、速度、寿命和擦写。 |
| 安全与工程 | 09 安全需求 10 机械/电子设计 11 环境要求 12 设计约束 | 人身/产品保护、结构电气、温湿度/海拔/电磁环境、成本功耗和最低指标。 |
| 制造与验证 | 13 可生产性 14 可测试性 15 外购元器件 | 装配效率、定位配合、测试覆盖/状态可观测、器件型号与性能信息。 |
| 协同与固件 | 16 内外部技术合作 17 嵌入式固件 | 团队职责、负责人/接口人，以及逻辑、控制、安全、OTA、监控和恢复机制。 |
17 项是原文给出的思路清单，不是所有项目必须逐章照抄的固定模板；应根据品类、阶段、法规、组织与读者灵活增减。
| 因素 | 定义 | 可穿戴 AI 追问 |
|---|---|---|
| 硬环境 | 看得见、摸得着的物理元素，例如放置/佩戴地点。 | 室内外、光线、噪声、动作、汗液、碰撞、遮挡和充电条件。 |
| 软环境 | 看不见、摸不着但影响产品的条件，例如温湿度。 | 网络、隐私、法规、组织制度、社交接受度和账号生态。 |
| 时间因素 | 使用发生的时段、持续时间、频次与生命周期。 | 全天佩戴、连续任务、待机、同步窗口、离线时长与升级时机。 |
| 参与对象 | 场景中的人、设备和系统。 | 使用者、旁观者、手机、耳机、云、企业后台、家庭成员和服务人员。 |
场景章节要明确“在什么条件下由谁完成什么任务”，再把结果传导到功能、性能、接口、结构、安全和测试。
| 类型 | 作用 | 例子 | 写法要求 |
|---|---|---|---|
| 产品原则 | 概念性的选择依据和产品性格。 | 小巧轻便、经济实惠、性能优先、隐私默认。 | 原则冲突时要有优先顺序，并说明服务的用户价值。 |
| 设计约束 | 具体限制设计空间的硬边界。 | BOM上限、最大功耗、最低效果、重量、上市时间。 | 必须量化、有来源、可验证，并标明改变约束的审批机制。 |
| 读者 | 重点内容 | 不应缺少 |
|---|---|---|
| 设计 / 结构 / 电子 | 场景、原则、系统框图、尺寸、环境、性能和约束。 | 需求来源、冲突优先级和验收边界。 |
| 固件 / App / 云 / AI | 业务流程、状态、接口、数据、异常、安全、OTA与监控。 | 端云职责、协议版本、失败兜底和测试环境。 |
| 测试 / 认证 | 功能、性能、安全、环境、接口、寿命和可测试性。 | 需求 ID、条件、阈值、验证方法与样本。 |
| 供应商 / 代工厂 | 与其交付相关的规格、器件、装配、测试、质量和接口。 | 版本基线、变更通知、责任边界和保密等级。 |
| 销售 / 支持 / 客服 | 场景、价值、规格、限制、安装、故障和服务流程。 | 不能承诺的边界、兼容性和升级政策。 |
裁剪的是可见内容，不是制造多个互相矛盾的真相；所有视图应来自同一需求基线并受版本控制。
| 第 6 篇 | 第 7 篇 | 我的合并规则 |
|---|---|---|
| 强调单条需求原子、明确、可验证、可追溯。 | 给出整份文档从场景到固件的内容地图。 | 先用章节保证覆盖，再用质量规则检查每一条需求。 |
| 强调需求写 WHAT，避免过早指定 HOW。 | 功能章节会写供电、通信、传感器、处理器等实现信息。 | 把用户/系统需求与架构/设计约束分层；只有被兼容、法规、供应或已批准架构锁定时才指定 HOW，并记录理由。 |
| 强调需求持续变化与接口早测。 | 强调外购器件、合作团队和嵌入式要求。 | 用统一 ID 和追踪矩阵连接需求、器件、接口、责任人、测试与版本。 |
| 成果 | 最小内容 | 完成标志 |
|---|---|---|
| 一页 Product Brief | 证据、5W2H、业务目标、价格/BOM、风险和成功指标。 | 团队能据此判断是否立项、为谁做和边界是什么。 |
| MVP 功能矩阵 | 场景、价值证据、功能、复杂度、成本、质量风险、收入影响和版本。 | 每个纳入项都有理由，每个删除项都有边界。 |
| 硬件 PRD 基线 | 17 个方向按项目裁剪；系统图、原子需求、接口、性能与验证。 | 研发能设计、测试能写用例、项目能估算、供应商能交付。 |
| 追踪与风险矩阵 | 需求 ID → 来源 → 设计/器件 → 测试 → 结果 → 版本；重大未知 → POC → 决策。 | 任何变更都能判断影响，任何发布门槛都有证据。 |
| 产品角色 | 原文中的核心业务目标 | 对产品定义的启发 |
|---|---|---|
| 量产品 | 跑出足够大的销量、快速获得用户，利润处于次要位置。 | 价格和体验要降低采用门槛，并设计用户如何进入后续高毛利业务。 |
| 利产品 | 获得足够大的产品利润，可承接已有品牌、渠道和用户流量。 | 价值差异、目标毛利与付费理由要足以支撑价格。 |
| 名产品 | 提升品牌形象和知名度，销量与利润不是首要目标。 | 创新表达、品牌势能和标杆体验比大众覆盖更关键。 |
| 周转产品 | 缩短资金从设计、生产到销售回流的周期，提高资产周转效率。 | 优先考虑设计简单、物料通用、备料可控和更容易销售的方案。 |
复用经验：“功能优先级”之前先明确“业务目标优先级”。同一个功能，放在量产品、利产品、名产品或周转产品中，是否值得投入可能完全不同。
| 对象 | 原文范围 | 迁移到可穿戴 AI 产品时应继续量化 |
|---|---|---|
| 外观 | 产品外观的详细定义与说明 | 重量、尺寸、佩戴位置、舒适性、材质、颜色与操作方式 |
| 硬件 | 硬件特性与实现说明 | 传感器、芯片、连接、存储、电池、续航、充电、防护与散热 |
| 软件 / AI | 智能硬件还会涉及 App 或后台，可能由软件 PM 定义 | 端云边界、模型能力、准确率、延迟、失败提示、隐私和离线兜底 |
| 包装 | 包装也是产品定义的一部分 | 清单、说明书、运输保护、环保、渠道陈列与开箱体验 |
| 测试 | 测试内容需要进入详细定义 | 指标、条件、方法、阈值、样本量和责任人，确保后续可验收 |
第三列是我结合“可研发、可测试”的学习目标所做的产品化迁移，不是原文逐项列出的字段；后续阅读还要继续校正和补齐。
原文示例：同样投入 100 万、单次利润率 30%，一年周转 1 次回收 130 万；每 4 个月周转一次并持续复投，年末可达 219.7 万，约为前者的 1.69 倍。
前七格来自第一篇的 5W2H；第二篇提醒我为每格补上调研证据。“成本 / 定价”和“验收 / 风险”是为满足本周目标增加的执行字段，仍需在后续五篇资料中继续验证。
资料边界：七篇资料依次覆盖 5W2H 产品定义、调研证据、风险验证、硬件 MVP、MVP 失败复盘、单条需求质量和完整 PRD 内容地图。页面中的知识树、阶段对照、结构化句式、可穿戴 AI 示例、评分/登记/追踪模板和四份最终成果，是我在逐篇精读后形成的产品化整理。
建立从设备硬件、驱动、操作系统和应用服务，到感知、处理、存储、通信、供电、结构、工业设计与生产的系统视角；能把体验要求翻译为资源、接口、任务优先级、实时性与功耗约束。
ID 评审不是审美投票，而是一项分层证据审查：先确认产品定位，再验证外部体验，最后检查内部工程、成本、合规与量产。效果图只能证明视觉意图，不能单独证明好用、可造或可靠。
“智能”不是一个孤立功能，而是一条跨层链路：感知和执行发生在设备端，连接依赖通信与协议，能力编排发生在平台和服务端，最终由用户端形成可感知体验。
| 层级 | 原文描述 | 产品经理要验证 |
|---|---|---|
| 营销标签型 | 冠以“智能”名称，但没有可证明的智能能力。 | 用户价值是否真实，还是只换了宣传语言？ |
| 联网操作型 | 通过网关或连接实现远程操作，例如部分智能家居。 | 连接是否比本地操作更有价值？额外硬件和配网成本是否值得？ |
| 识别与自动化型 | 用算法或机器学习实现语音、图像识别和简单自主操作。 | 准确率、延迟、数据、算力、功耗和失败兜底能否同时成立？ |
| 半自主系统型 | 融合语音、图像、雷达、惯导等多种器件和算法完成复杂操作。 | 传感融合、安全冗余、责任边界和极端场景是否可控？ |
这是作者用于理解智能化程度的经验分类，不是行业统一的成熟度标准；使用时应改写成可测量的自动化能力和人工介入边界。
原文示例把功能表与硬件、电源、结构、工作环境、认证和外观规格结合起来。对 PM 来说，真正可沟通的规格需要同时说明场景、目标值、测试条件和版本边界。
| 规格域 | 需要明确 | 工程对话问题 |
|---|---|---|
| 功能与版本 | 定位、远程、通话、报警等能力及不同版本支持关系。 | 功能由哪层实现？需要哪些器件、协议、平台和权限？ |
| 电子与电源 | 主控、传感器、连接、天线、电压、电池、充电与续航。 | 典型/峰值功耗是多少？资源和接口是否留有余量？ |
| 结构与可靠性 | 尺寸、重量、材料、防护、跌落、按键、装卡和装配。 | 指标对应什么场景？结构方案如何影响天线、散热和可制造性？ |
| 环境与认证 | 温湿度、海拔、电磁环境及目标市场认证。 | 测试等级和标准版本是什么？设计前置条件有哪些？ |
| 对象 | 我需要问 | 期望拿到的输出 |
|---|---|---|
| 电子 / 嵌入式 | 资源、接口、功耗、通信、异常、升级和测试点在哪里？ | 系统框图、功耗预算、接口表、状态机与风险清单。 |
| ID / 结构 | 用户场景如何转为尺寸、材料、CMF、装配、防护和人体工学？ | ID方向、结构堆叠、材料工艺、手板和评审结论。 |
| 供应链 / 制造 | MOQ、交期、替代料、良率、工装、测试和付款条件是什么？ | 成本拆解、交期路径、供应风险、DFM和试产计划。 |
| 测试 / 质量 | 每项规格怎样验证？抽检、认证、可靠性和售后门槛是什么？ | 测试矩阵、AQL/质量标准、认证清单与问题闭环。 |
嵌入式系统是为特定产品或应用服务的专用系统；它不追求“全能”，而是用受限的计算、存储、功耗和接口资源，可靠地完成规定任务。
| 层级 | 主要职责 | PM 对话重点 |
|---|---|---|
| 硬件层 | 处理器、MCU、存储、电源、总线、I/O、传感器和执行器。 | 资源、功耗、接口、电气边界、供货与硬件测试点。 |
| 驱动 / 硬件接口层 | 让系统访问网络、USB、显示、串口、按键等具体设备。 | 器件是否有成熟驱动？初始化、参数、错误和版本如何暴露？ |
| 内核 / 操作系统层 | 时钟、电源、进程/任务、内存、文件、中断和基础资源管理。 | 任务调度、资源上限、启动时间、故障恢复和实时性。 |
| 系统 / 应用接口层 | 以模块和标准 API 提供文件、设备、网络等可复用系统能力。 | API契约、权限、兼容、错误码、跨模块依赖和可扩展性。 |
| 应用 / 服务层 | 组合系统能力实现产品业务、状态、交互与规则。 | 用户流程、状态机、异常路径、数据策略和验收指标。 |
PM 不必计算电路，但应能追问资源是否足够、峰值是否冲突、接口是否被占用、功耗与热是否符合场景，以及未来版本是否还有余量。
| 方式 | 含义 | 产品影响 |
|---|---|---|
| 不可抢占 | 任务获得处理器后持续执行，直到结束或主动等待。 | 实现简单，但耗时任务可能阻塞关键响应。 |
| 可抢占 | 高优先级就绪任务可以打断当前低优先级任务。 | 适合关键事件及时响应，但必须管理优先级、共享资源和饥饿风险。 |
| 时间片轮转 | 相同优先级任务按时间片轮流获得 CPU。 | 提升公平性，但切换开销和时间片会影响延迟。 |
原文用调度方式解释 RTOS；实际系统可以组合多种策略，具体行为要以所选系统和配置为准。
| 体验语言 | 工程化问题 | 可验收输出 |
|---|---|---|
| 抬腕马上亮屏 | IMU中断、唤醒链路、任务优先级、屏幕驱动和峰值功耗如何配合？ | P95 / 最大亮屏时延、误触发率和单次能耗。 |
| 跌倒后及时求助 | 采样、识别、确认、定位、联网和发送各自的截止时间与离线兜底是什么？ | 端到端告警时延、召回/误报、发送成功率和失败策略。 |
| 全天续航 | 各任务频率、CPU占用、传感器模式、无线窗口和睡眠唤醒如何预算？ | 分场景功耗表、典型/极端续航和低电策略。 |
| 升级不能变砖 | 下载、校验、切换、断电、失败回滚和版本兼容由哪层负责？ | 升级成功率、异常用例、回滚时间和数据保全。 |
一个联网硬件的最小系统视角，不是“主控加几个传感器”，而是一条完整闭环：输入被感知，数据被处理和保存，信息在设备内外流动，执行器产生结果；电源维持所有环节，看门狗与恢复机制处理异常。
| 模块 | 承担什么 | PM 评审时要问 |
|---|---|---|
| 传感器 / 输入 | 把环境、人体或用户动作转成可处理的信号。 | 量程、精度、采样率、噪声、安装位置和校准条件是什么？ |
| 处理器 | 运行固件与算法，协调各器件和任务。 | 典型与峰值算力、内存、接口、功耗和软件生态是否匹配？ |
| 存储 | 保存程序、配置、日志、模型和离线数据。 | 容量、速度、擦写寿命、掉电保护和数据保留周期是多少？ |
| 设备内通信 | 让主控、传感器、存储和执行器交换模拟或数字信号。 | 电气层、接口/总线、速率、距离、器件数量和抗干扰要求是什么？ |
| 设备外通信 | 通过蓝牙、Wi-Fi、蜂窝等连接手机、网关或云。 | 距离、吞吐、时延、功耗、覆盖、资费、配网与断连策略如何权衡？ |
| 执行器 / 输出 | 以灯、声音、振动、电机或其他动作反馈结果。 | 响应时间、力度/亮度、峰值电流、噪声、安全和寿命如何验收？ |
| 电源系统 | 供电、充电、变换、保护并匹配不同电压轨。 | 典型/峰值/休眠功耗，充电、温升、保护和续航预算能否闭环？ |
| 硬件看门狗 | 监测程序失控，在超时后触发复位或进入恢复流程。 | 谁喂狗、什么条件复位、复位后状态如何恢复、日志如何保留？ |
原文建议把显著影响产品目标、性能或成本的部件定义为“核心元器件”，由产品经理参与评估与确认；电阻、电容等非关键通用料可由工程团队完成细节选型。把它产品化后，我会用下面的矩阵组织决策：
| 决策维度 | 需要形成的证据 | 典型产品风险 |
|---|---|---|
| 体验 / 性能影响 | 与场景指标相连的参数、样机实测、极限工况。 | 精度、延迟、稳定性或续航达不到承诺。 |
| 成本影响 | 阶梯价、MOQ、配套电路、测试与制造成本。 | 只看器件单价，忽略系统成本。 |
| 供货与生命周期 | 交期、产能、原厂状态、第二来源和替代验证量。 | 缺料、停产或被单一供应商锁定。 |
| 软件与集成生态 | 驱动/BSP、SDK、文档、样例、维护者和已量产案例。 | 硬件参数够用，但调试周期失控。 |
| 可靠性 / 合规 | 温度等级、认证、失效数据、质量体系和追溯方式。 | 实验室可用，量产或目标市场不可用。 |
后面三项是基于原文“性能、成本、资料渠道”继续补充的量产决策维度，不是原文逐项列出的表格。
| 指标 | 它回答什么 | 验证提醒 |
|---|---|---|
| 可充电性 | 能源补充方式、用户维护成本和设备工作形态。 | 同时考虑充电频率、接口/触点、防水、寿命和安全。 |
| 能量密度 | 同等体积或重量下可以存多少能量。 | 对穿戴尺寸与重量关键，但不能脱离封装、安全和倍率。 |
| 自放电 | 设备不工作时电池自身损失电量的速度。 | 还要与整机待机漏电分开测量。 |
| 放电曲线 | 不同荷电状态与负载下，电压如何变化。 | 关注系统最低工作电压、峰值负载和低温掉压。 |
| 实际可用容量 | 标称容量中，整机在真实条件下能用到多少。 | 以温度、老化、负载、截止电压和转换损耗下的整机测试为准。 |
| 峰值能力与安全 | 无线发射、屏幕、电机等瞬时大电流能否被支撑。 | 补充循环寿命、温升、保护、膨胀与认证要求。 |
原文特别提醒：能统一器件工作电压时，可减少电源处理电路，降低复杂度、成本和故障点；但是否统一仍要由整机效率、信号质量和器件可选范围共同决定。
这样讨论时，需求不再停留在“支持 AI 健康提醒”，而会落到器件、链路、异常、功耗与验收责任人。
性能定标是一道约束题：先满足安全、合规和产品目标，再在成本与设计寿命允许的范围内，把资源投入到用户能感知、市场能表达的指标上；其余指标达到可靠底线即可。
| 性能域 | 原文涉及的指标 | PM 应形成的成果 |
|---|---|---|
| 电子 / 电源 / 安全 | 器件等级、静电、输入电压、电流余量、反接、漏电/短路、功耗、阻燃。 | 电气边界、功耗预算、保护策略、热与安全测试矩阵。 |
| 环境适应性 | 高低温、湿度、腐蚀性气体、水下、暴晒、雨淋和温差变化。 | 来自真实场景的环境剖面、存储/工作条件和通过标准。 |
| 机械 / 材料可靠性 | 运输振动、使用振动、跌落、冲击、壳体或硅胶变色。 | 材料与结构指标、预处理条件、跌落面/次数、外观限度样。 |
| 功能 / 链路性能 | 通信功耗、速率、距离，以及采集上报或指令执行的响应时间。 | 端到端场景指标，不只测试单个模块的理想参数。 |
| 市场准入 / 证明 | IP、CCC（原文称 3C）、CE、CQC、质检报告。 | 国家/地区—品类—法规/标准—证据—责任人—时间/费用清单。 |
这个重组让清单从“想到什么测什么”变成五条可分工、可追踪的验证主线。
| 写法层级 | 示例 | 为什么 |
|---|---|---|
| 不可验收 | “连接稳定”“响应快”“防水”“续航长”。 | 没有边界，不同团队会按不同理解实现。 |
| 只有目标值 | “蓝牙距离 10 m”“续航 24 h”。 | 缺少环境、负载、手机、佩戴、信号和统计口径。 |
| 可执行指标 | 规定场景、配置、样机版本、测量仪器、阈值、样本量、次数与通过规则。 | 可以进入 DVP、实验室测试和版本放行。 |
性能不是 PM 单方面“拍数字”；输入被收齐后，再由产品、研发、测试、质量、认证与供应链联合评审。
“标准”规定要求或测试方法，“测试报告”记录证据，“合格评定/认证/声明/标志”是不同的市场准入机制，不能混称为一个动作。
| 用户承诺 | 需要拆出的系统指标 | 必须锁定的测试条件 |
|---|---|---|
| 全天可戴 | 典型/极端续航、皮肤接触温升、重量、佩戴压力与材料耐汗。 | 功能开启组合、采样/同步频率、环境温度、人群和老化状态。 |
| 洗手淋雨不摘 | 外壳防护、按键/孔位/充电处密封、湿后功能和腐蚀风险。 | 目标 IP 代码对应的标准方法、样机状态、预处理与测试后判定。 |
| 提醒及时可靠 | 感知—算法—通信—振动/显示的端到端延迟、成功率与误报。 | 信号质量、并发任务、弱网/断网、电量和最坏负载。 |
| 日常磕碰可用 | 跌落、冲击、振动后外观、密封、传感精度与内部连接。 | 跌落高度、方向、接触面、次数、温度和合格判定。 |
| 连接稳定 | 配对成功率、重连时延、有效距离、吞吐、丢包和共存性能。 | 手机/系统版本、人体遮挡、干扰环境、方向、功耗与统计口径。 |
| 层级 | 定义 | 资源策略 |
|---|---|---|
| P0 合规 / 安全底线 | 法规、标准、严重安全风险和核心功能不可失败条件。 | 必须满足，没有成本换取豁免的空间。 |
| P1 产品目标 | 目标用户完成核心任务所需的最低可接受表现。 | 作为立项、设计冻结和量产放行门槛。 |
| P2 体验目标 | 让大多数用户感到顺畅、可靠、舒适的目标水平。 | 根据成本和技术风险进行联合权衡。 |
| P3 差异化领先 | 能被用户感知、被营销清晰表达且有证据支撑的优势。 | 集中资源做少数关键指标，不追求全面参数竞赛。 |
“两化四性”把方案从当前版本拉到产品族、生态、供应链、量产与风险生命周期：模块化管理差异，开放化创造连接，扩展性容纳变化，通用性形成复用，稳定性保证持续可用，安全性守住人、数据与环境。
只有当差异长期存在、组合频率明确且复用收益大于新增复杂度时，模块化才成立；它不是“多留几个接口”。
| 原文启发 | 产品化补全 | 需要的交付物 |
|---|---|---|
| 平台 / 中枢像“大脑” | 定义设备模型、接入规则和生态边界，避免只追求接入数量。 | 设备能力模型、接入规范、认证流程与生态指标。 |
| 传感器 / 控制器像“肢体” | 让能力易被发现、调用、组合和诊断，同时限制危险操作。 | API/协议、SDK、示例、错误码、权限和沙箱策略。 |
| 统一协议与数据格式 | 还需版本、向后兼容、废弃策略、限流、身份、加密与审计。 | 接口契约、版本政策、安全模型和开发者文档。 |
开放程度应分层：只读数据、受控写入、设备控制、固件/管理权限的风险完全不同，不能用一个“支持开放 API”覆盖。
| 维度 | 扩展性 | 通用性 |
|---|---|---|
| 要解决的问题 | 未来功能、器件、容量或外部设备变化时，系统能否低代价演进。 | 当前多个产品、供应商或用户能否共享器件、接口、配件和方法。 |
| 常见手段 | 预留算力/存储/接口/空间/电源，采用标准协议、抽象层和可升级架构。 | 共用料、标准件、统一连接器/充电器、平台化 PCBA、替代料设计。 |
| 主要价值 | 降低未来改版、集成和客户适配成本。 | 聚合采购量、减少 SKU、降低维修门槛和供应风险。 |
| 主要风险 | 为不确定未来过度预留，增加体积、功耗、成本和攻击面。 | 为了共用而牺牲关键体验、尺寸、效率或差异化。 |
| 决策证据 | 明确的演进路线、发生概率、改版成本与预留成本对比。 | 共用量、替代供应、NRE/库存节省与性能损失对比。 |
原文强调“元器件稳定性、方案设计、加工品质”，我把售后现场闭环补成第四段：量产检验能拦截已知缺陷，却不能替代可靠设计，也不能证明长期故障率。
| 风险面 | 可穿戴 AI 典型风险 | 产品要求 |
|---|---|---|
| 机械 / 材料 | 小件脱落吞咽、锐边、过敏、长期皮肤接触、佩戴夹伤。 | 人群与可预见误用、材料证据、结构防护和警示。 |
| 电池 / 热 / 电气 | 充电异常、短路、挤压、进水后故障、皮肤接触温升。 | 保护、热设计、故障测试、充电附件边界和安全状态。 |
| 功能安全 | 健康提醒漏报/误报、定位或求助失败导致用户错误依赖。 | 用途声明、风险分级、降级与人工确认、失败提示和兜底。 |
| 网络安全 | 账号接管、恶意控制、固件篡改、接口滥用和供应链漏洞。 | 身份、最小权限、加密、签名升级、密钥管理、日志与漏洞响应。 |
| 隐私 / 数据 | 生理、位置、语音和行为数据泄露或被超范围使用。 | 最小采集、明确同意、端云边界、保留/删除、访问与导出机制。 |
工业设计不是“画一个漂亮外壳”。它把目标用户的动作、环境和情绪转译为物理交互与形态，再用材料、颜色和表面工艺形成感知品质；同时为主板、电池、天线、传感器、结构强度、装配与模具留出真实空间。
| 原文四要素 | 要观察什么 | 可能转成的 ID 要求 |
|---|---|---|
| 角色 | 年龄、身体尺寸、能力限制、惯用手、审美、经验与照护关系。 | 尺寸范围、操作力、字体/图标、圆角、防误触与包容性设计。 |
| 场景 | 地点、湿滑/灰尘/光照/噪声、衣着、随身物、隐私与社交氛围。 | 防滑、密封、可视/可听/可触反馈、低打扰形态与清洁方式。 |
| 时间 | 白天/夜晚、紧急/从容、短时/全天、首次/重复、季节变化。 | 亮度、提醒强度、佩戴舒适、学习成本、耐久和补能节奏。 |
| 任务 | 用户的目标、步骤、双手是否空闲、关键错误和任务后动作。 | 抓握/佩戴方式、控件位置、单手操作、防遗忘和状态可见性。 |
原文的浴室门锁与自助机读卡器案例说明：脱离环境与后果，单看形态无法判断设计好坏。看似“省力”的设计可能增加遗失风险，看似“漂亮”的球形把手也可能在湿手场景失效。
PM 给的是问题、用户证据、边界和优先级，不应把个人审美伪装成唯一设计答案。
原文用插座说明“美感建立在能用、易用之上”，又用难开模造型说明：可渲染、可 3D 打印的概念并不等于可规模制造的产品。
| 维度 | 要评估 | 样件 / 证据 |
|---|---|---|
| 材料 Material | 强度、重量、柔软、散热、透波、皮肤接触、老化、回收与成本。 | 材料规格、样条、法规/生物相容证据、环境与机械测试。 |
| 颜色 Color | 品牌、场景、视觉体积、批次色差、耐汗/耐 UV/耐迁移和搭配。 | 色板、标准光源评审、色差范围与上下限度样。 |
| 表面 Finish | 光泽、纹理、手感、防滑、指纹、耐脏、耐刮、印刷耐磨和修复性。 | 工艺样板、真实曲面件、摩擦/化学品/汗液/清洁剂测试。 |
| 工艺 Process | 模内纹理、喷涂、丝印/移印、激光、抛光、拉丝等适配性与良率。 | 供应商能力、制程窗口、成本、良率、产能与检验方法。 |
原文“手感好但半天变脏”的接收器案例提醒：首触惊喜若没有耐脏、耐磨和长期触感，很快会变成退货理由。
| 专项 | 与 ID / 结构 / 电子共同确认 | 验证方式 |
|---|---|---|
| 佩戴与人体工学 | 覆盖人体尺寸、贴合曲率、压力点、重量分布、动态滑移、单手穿戴和衣物冲突。 | 多尺寸人群、静态 + 运动、长时间佩戴与主观/客观数据。 |
| 传感可靠 | 光学窗/电极的位置、接触压力、遮光、汗液、毛发、肤色、运动伪影与清洁。 | 不同人群和运动场景下信号质量、脱腕检测与重复佩戴一致性。 |
| 全天接触 | 皮肤接触材料、边缘、缝隙、积汗、温升、过敏、清洁剂与气味。 | 接触材料证据、温升、汗液/化学品、耐久与皮肤体验测试。 |
| 通信与能量 | 人体遮挡下天线净空，电池体积与形变防护，充电方式、防水和误吸附。 | 多方向佩戴射频、充电容错、温升、跌落/挤压和进水后安全。 |
| 低打扰交互 | 显示、灯、振动、声音、按键/冠/触控在会议、夜间和运动中的可感知与隐私。 | 环境光/噪声、手套/湿手、运动中操作和提醒辨识度。 |
| 外观寿命 | 表带、涂层、文字、金属、透光件在汗液、护肤品、日晒和反复摩擦后的变化。 | 老化后与限度样比较，并复测密封、传感和装配。 |
沟通质量不由会议数量决定，而由“信息是否足够、判断标准是否一致、决策是否记录、问题是否闭环”决定。ID 不应在定位模糊时直接出图，工程也不应在效果图冻结后才第一次发现空间、工艺或成本冲突。
| 原文交流 | 本阶段要决策 | 会后必须留下 |
|---|---|---|
| 1 · 产品价值传递 | 用户、场景、售价、品牌、竞品、核心功能和设计价值排序。 | 经确认的 ID Brief、关键词/情绪板方向、疑问与研究清单。 |
| 2 · 风格与详情对接 | 概念方向、外露接口/器件、尺寸包络、材料工艺和硬约束。 | 方向选择依据、完整接口表、约束包、下一轮方案任务书。 |
| 3 · 第一版联合初评 | 定位、场景、堆叠、电子/射频/声学、工艺、成本是否同时可行。 | 问题清单、风险等级、责任人、修改要求、替代方案和截止日。 |
| 4 · 修改方案收敛 | 上轮问题是否关闭，残余取舍是否接受，能否进入详细设计。 | 选定方案、决策理由、未决风险、冻结边界和版本号。 |
| 5 · 需求文件同步 | 结构、采购、专利、品牌/营销分别拿到何种受控文件。 | 交付物清单、文件版本、所有者、接收人和用途/保密边界。 |
| 6 · 工程修改微调 | 器件、结构、材料或工艺变化对体验、外观、成本和进度的影响。 | 变更单、影响评估、批准记录、更新文件和回归验证计划。 |
原文提出售价、客群、习惯、功能、竞品，以及造型、材质、表面工艺等准备项；这里补入工程包络、法规、证据和决策边界，使 ID 能在真实空间内发散。
| 低质量反馈 | 可执行反馈 | 判断证据 |
|---|---|---|
| “感觉不高级” | 目标气质是哪几个词；哪些比例、分件、光泽、色彩或细节偏离；参考与禁例是什么。 | 品牌原则、目标用户访谈、同价位样机和 CMF 样板。 |
| “按钮再舒服一点” | 谁、在何种姿态/衣着/运动中操作；目标操作力、行程、触达、辨识和误触边界。 | 人体尺寸、功能样机、任务成功率和主观量表。 |
| “这里不能开孔” | 是防水、审美、卫生、结构还是品牌原因；允许移动的范围和替代交互是什么。 | 性能目标、结构/声学/射频验证和场景优先级。 |
| “成本太高” | 目标成本与超支来自材料、工艺、良率、装配还是二次加工；体验损失边界是什么。 | 供应商报价、工艺路径、良率预测和价值工程方案。 |
| 角色 | 重点检查 | 不应只回答 |
|---|---|---|
| 产品 / 用户研究 | 定位、场景、任务、可理解性、差异化和体验优先级。 | “我喜欢 / 不喜欢”。 |
| ID | 形态语言、比例、交互、CMF、品牌一致和细节完整性。 | “效果图能实现”。 |
| 结构 / 制造 | 堆叠、分件、强度、密封、装配、模具、维修、工艺和良率。 | “大概能开模”。 |
| 电子 / 嵌入式 | 器件包络、接口、天线、声学、传感窗口、热、电池、充电与测试点。 | “主板后面再改小”。 |
| 采购 / 成本 | 材料与工艺供应能力、MOQ、NRE、交期、成本、替代和风险。 | “看起来应该不贵”。 |
| 质量 / 法规 | 材料、安全、可靠性、标识、目标市场要求和可验证性。 | “后面送检再说”。 |
| 接收方 | 原文交付物 | 交接时补充控制 |
|---|---|---|
| 结构工程 | ID 3D 文件、CMF 图。 | 基准坐标、外观控制面/不可改区、关键尺寸、间隙段差、版本和变更权限。 |
| 采购 / 资源开发 | CMF 工艺图。 | 材料牌号/性能、颜色/光泽/纹理、工艺路线、样板、验收与替代审批。 |
| 知识产权 | 线框六视图。 | 由专利专业人员确认制图与申请策略；管理公开时间、发明人和相似设计检索。 |
| 品牌 / 市场 | 着色效果六视图。 | 明确“概念效果”与“量产实物”的差异、颜色基准、功能声明和保密期限。 |
| 质量 / 制造 | 原文未单列。 | 外观检验规范、限度样、关键特性、包装防护、工装与追溯要求。 |
项目群可以用于提醒和讨论，但影响基线的决定不能只留在聊天记录里。
评审顺序的意义在于控制返工：定位不成立时，不必继续优化细节；外部体验不成立时，不应急着锁工艺；内部方案、成本与合规没有证据时，也不能因为效果图好看就冻结。
| 检查项 | 不是问“像不像” | 而是要回答 |
|---|---|---|
| 目标用户 | 年龄、收入或文化标签是否被主观套用。 | 人体、能力、行为、审美和购买证据如何转成具体设计要求。 |
| 核心场景 | 渲染图放在场景里是否好看。 | 用户能否在关键环境、姿态、衣着和时间压力下完成任务。 |
| 价格与品牌 | 是否“显贵”“像某品牌”。 | 比例、细节、材料、工艺和产品族语言如何支撑品牌与成本结构。 |
| 价值排序 | 每个卖点都在外观上被强调。 | 哪个价值必须第一眼被感知，哪些能力应克制、隐藏或低打扰。 |
| 差异与风险 | 是否足够特别。 | 差异是否可用、可保护、可制造，并避免混淆、侵权或过度学习竞品。 |
定位门不通过时，结论应是回到 Brief 与概念方向，而不是继续修改颜色和圆角。
| 维度 | 评审问题 | 所需证据 |
|---|---|---|
| 尺寸 / 比例 / 人体 | 长宽高、曲率、重量、重心、触达、抓握/佩戴是否适配场景与人群。 | 1:1 模型、人体数据、场景任务和多尺寸试用。 |
| 材料 / 颜色 / 工艺 | 视觉、触感、耐污、耐指纹、耐汗、耐磨、耐 UV 与清洁是否满足寿命。 | CMF 实物样板、规格、老化/摩擦/化学品测试和限度样。 |
| 交互 / 认知 | 按钮、触控、灯、图标、声音和振动是否可发现、可理解、可反馈、防误触。 | 可交互样机、关键任务成功率、错误观察和可访问性测试。 |
| 外露开口 | 充电、麦克、扬声器、传感窗口、按键和维护接口的位置是否兼顾使用与防护。 | 真实附件/线缆操作、湿手/戴手套、声学、射频、防水和清洁测试。 |
| 缝隙 / 段差 / 边缘 | 是否积污、夹毛、刮肤、漏光、进水，批量波动是否仍可接受。 | 2D 公差、外观规范、极限样与装配统计。 |
原文按大小、工艺、功能与外露接口展开；本页将“看效果图”补成了需要实物或功能样机才能验证的用户任务。
| 证据层级 | 能证明 | 不能单独证明 |
|---|---|---|
| E1 草图 / 渲染 / 动画 | 设计意图、比例方向、视觉语言和交互概念。 | 真实大小、触感、人体工学、可制造性、性能和成本。 |
| E2 1:1 外观模型 / CMF 样板 | 体量、握持/佩戴、视觉、材质和表面方向。 | 内部堆叠、功能性能、真实装配和可靠性。 |
| E3 功能手板 / 工程样机 | 交互、器件布局、初步性能、结构和装配问题。 | 量产工艺、批量公差、良率和长期一致性。 |
| E4 DFM / 报价 / 模流 / 测试 | 工艺路径、模具、供应、成本、可靠性与主要风险。 | 实际量产稳定性，仍需试模和试产验证。 |
| E5 试模 / 试产 / 认证证据 | 量产件外观、装配、性能、良率与市场准入状态。 | 长期现场表现，仍需量产监控和售后闭环。 |
| 结论 | 适用条件 | 下一步 |
|---|---|---|
| 通过 | 本阶段必备证据完整，P0/P1 问题关闭，残余风险已被明确接受。 | 冻结对应基线并进入下一阶段。 |
| 有条件通过 | 没有阻塞性 P0；少量 P1 有清晰方案、Owner、期限与复验门槛。 | 限制可开展工作范围，条件关闭前不得完全冻结。 |
| 不通过 | 定位偏离，存在安全/合规阻塞，核心体验失败，工程不可行或关键证据缺失。 | 回到相应上游修改，明确复评输入。 |
| 成果 | 核心内容 | 主要协作者 |
|---|---|---|
| 1 · 系统全景图 | 设备、App、平台、云、用户和数据/控制闭环。 | 产品、架构、软件、硬件。 |
| 2 · 设备系统框图 | 感知—处理—存储—通信—执行—电源—恢复及责任层。 | 电子、嵌入式、算法。 |
| 3 · 资源 / 功耗 / 接口预算 | CPU/RAM/Flash、任务、典型/峰值功耗、内部与外部接口余量。 | 电子、嵌入式、射频。 |
| 4 · 性能与验证矩阵 | 场景、指标、阈值、条件、方法、样本、判定、标准和责任人。 | 测试、质量、法规、研发。 |
| 5 · 核心器件决策表 | 体验、成本、供货、生态、可靠性、替代方案与验证证据。 | 电子、供应链、质量。 |
| 6 · 两化四性评审表 | 模块/开放/扩展/通用/稳定/安全的收益、代价、风险和路线图。 | 架构、研发、安全、业务。 |
| 7 · ID 设计任务书 | 用户场景、品牌、交互、硬约束、人体、CMF、制造、成本和验收。 | ID、结构、电子、品牌。 |
| 8 · CMF 规格与样板计划 | 材料、颜色、光泽、纹理、工艺、耐久、色差、限度样和供应商。 | ID、CMF、采购、质量。 |
| 9 · ID 评审报告 | 定位、外部体验、内部工程、证据等级、问题分级与阶段结论。 | ID、MD、EE、制造、法规。 |
| 10 · 决策 / 变更台账 | 事实、选项、影响、决策、Owner、版本、验证和关闭证据。 | 项目全体。 |
| 对象 | 我要抓住的主线 | 带走的输出 |
|---|---|---|
| 电子工程师 | 器件、接口、电源、峰值、射频/声学/传感、保护、堆叠和供货。 | 框图、器件方案、功耗/接口预算、原理风险与测试点。 |
| 嵌入式工程师 | 责任层、任务、优先级、截止时间、资源、驱动、升级、日志和恢复。 | 状态机、任务/资源表、接口契约、异常策略与验收条件。 |
| ID 工业设计师 | 用户动作、品牌、形态、人体、CMF、交互、外露件和长期外观体验。 | 概念方向、模型/渲染、CMF、受控 3D 与设计说明。 |
| 结构工程师 | 堆叠、分件、强度、密封、散热、装配、模具、公差、维修与良率。 | 结构方案、堆叠、DFM/DFA、2D 公差、风险和样机计划。 |
我的角色不是替工程师给出实现答案，而是让问题、边界、优先级和通过标准清楚，使不同专业能在同一产品目标下做判断。
| 层级 | 表现 | 本模块完成标准 |
|---|---|---|
| L1 · 能识别 | 看懂系统、器件、嵌入式、性能、ID、CMF 与制造基本术语。 | 能用自己的话解释，并指出原文边界。 |
| L2 · 能提问 | 根据场景向电子、嵌入式、ID 和结构提出有边界的问题。 | 问题包含条件、影响、证据和期望输出。 |
| L3 · 能产出 | 独立制作系统图、指标矩阵、ID Brief、评审报告和问题台账。 | 其他角色可据此评估、实现或验证。 |
| L4 · 能取舍 | 组织跨专业评审，在体验、性能、成本、周期、安全和制造之间决策。 | 决策有事实、选项、影响、Owner 与回归验证。 |
本模块真正的学习成果，不是我记住了多少技术名词，而是我能否把一个模糊的体验愿望，推进成跨专业可评估、可验证、可量产的产品决定。
阅读进度 8 / 8。八篇已全部精读：从硬件系统、嵌入式、方案、性能与长期架构，一路推进到 ID 场景、CMF、协同和证据化评审；每篇都保留原文边界与产品化补全。
把硬件、固件、App、云与 AI 看成一条完整体验链：从用户目标和系统状态出发，设计跨端操作、反馈、异常、异步任务与智能能力的可理解闭环。
多模态不是给设备多装一个摄像头，而是让语音、视觉、触控、动作与内容在同一儿童任务中各司其职：一种通道负责发现和输入，另一种补充上下文与反馈；所有采集都服从儿童最佳利益、可感知、最小化和可退出。
交互的目的，是让人更容易实现自己的目的。物联网扩大了参与者：不仅有人与设备，还存在设备—设备、设备—云、App—云之间的信息与控制；但设计判断仍要回到用户任务、场景与后果。
| 原文维度 | 产品化解释 | 可测问题 |
|---|---|---|
| 距离 | 物理距离、步骤/层级、理解门槛、网络可达、能力与动机距离。 | 完成任务要几步/多久？设备与手机多远仍可用？跨协议是否可达？ |
| 大小 | 体积之外，还包括显著性、优先级、敏感度和情绪影响。 | 关键状态能否被及时注意？提醒强度是否匹配风险，又不过度打扰？ |
| 多少 | 参与对象、选项、提醒和信息数量，以及注意力如何分配。 | 同时有几个入口/通知/设备响应？哪些应合并、静默或分级？ |
| 反馈 | 触发是否被接收、进度如何、结果是什么、失败为何及如何补救。 | 即时反馈、过程反馈和最终反馈分别在哪端？超时与失败说清了吗？ |
| 分布 | 功能、信息和控件在设备、App、云、空间与时间中的组织关系。 | 能力应放本地还是 App？关联项是否成组？跨端入口和状态是否一致？ |
| 顺畅 | 主流程清晰、安全有保障，异常醒目并能恢复。 | 关键路径是否无死路？中断后能否续做？危险操作是否确认与撤销？ |
| 体验 | 六维诊断 | 应形成的指标 |
|---|---|---|
| 抬腕看健康提醒 | 距离短、信息少、优先级明显；设备即时反馈，详情分布到 App。 | 抬腕识别率、亮屏时延、单屏信息量、误触发和查看完成率。 |
| 语音记录事项 | 输入自然但环境噪声是距离；必须有收音、处理中、成功/失败反馈。 | 唤醒/识别成功率、端到端时延、打断率、离线策略和纠错成本。 |
| 跌倒求助 | 提醒显著性高但不能制造恐慌；人、设备、App、云和联系人形成分布式链路。 | 识别—确认—发送时延、误报/漏报、撤销窗口、送达状态和失败兜底。 |
| 设备配网 / 绑定 | 步骤、权限、蓝牙/网络和账号形成多重距离；状态不一致最容易卡死。 | 首次成功率、完成时长、失败点分布、重试成功率和客服求助率。 |
温控器案例说明：按钮、旋钮或整机按压没有绝对高下。输入动作要匹配指令性质，界面与设备反馈要告诉用户“怎么操作、当前是多少、是否生效、下一步是什么”；交互形式会进一步塑造产品外观。
| 指令类型 | 典型任务 | 设计重点 | 风险控制 |
|---|---|---|---|
| 启动 / 终止 | 开关机、开始运动、停止录音、启用 SOS。 | 可发现、状态清楚；按压/拨动/旋转/提拉应与频次和空间匹配。 | 按后果决定防误触、预告、二次确认、撤销和安全终止。 |
| 性能调节 | 音量、亮度、强度、时长、目标值。 | 方向和幅度有对应关系；连续/分档与所需精度、范围和场景匹配。 | 显示当前值与边界，避免突变；重要参数可“调节 + 确认”。 |
| 连续互动输入 | 密码、配网、分步设置、连续语音/手势。 | 每一步有有效性反馈，保留进度，错误定位明确，结束条件可理解。 | 兼顾隐私与安全；失败不清空无关输入，限制重试并给恢复路径。 |
| 形式 | 适合表达 | 主要限制 | 必须补的反馈 |
|---|---|---|---|
| 按压 | 离散触发、确认、快速高频动作。 | 小空间多义、误触、戴手套/运动中触达。 | 清晰行程/触感 + 视觉/声/振动状态确认。 |
| 旋转 | 连续或多档参数调节，也可沿轴按压确认。 | 占空间、双手/抓握要求、机械寿命与防水。 | 方向、刻度、当前值、边界和变化速率反馈。 |
| 拨动 / 滑动 | 二态开关、档位、方向明确的变化。 | 行程与空间限制，可能误拨或状态与软件不同步。 | 物理位置与真实状态一致；远程改变时处理冲突。 |
| 语音 / 手势 | 手被占用、远距离、无屏或快捷命令。 | 噪声、隐私、可发现性、误识别、文化/能力差异。 | 唤醒、收听、理解、执行、失败五段反馈与替代入口。 |
| 屏幕 / 触控 | 动态选项、复杂配置、可视化信息。 | 功耗、尺寸、湿手/运动、视力与注意力占用。 | 触控响应、焦点、进度、状态与物理设备同步。 |
| 指令特征 | 建议交互 | 示例 |
|---|---|---|
| 低风险、频繁、可逆 | 一步触发，即时反馈，避免重复确认。 | 翻页、查看卡片、普通音量微调。 |
| 中风险、可恢复 | 预览结果或短撤销窗口，保留原状态。 | 结束运动、清除单条记录、切换模式。 |
| 高风险、低频、不可逆 | 动作差异化、明确后果、二次确认或组合输入。 | 恢复出厂、删除全部数据、解除安全监测。 |
| 紧急、高风险、时间敏感 | 入口显著且可快速触发，同时提供短暂取消与送达反馈。 | SOS、跌倒求助、医疗紧急呼叫。 |
确认越多不等于越安全；频繁弹窗会形成“无脑确认”。确认强度要由后果、可逆性、频率与时间压力共同决定。
| 场景 | 主通道 | 辅助 / 兜底通道 | 关键验证 |
|---|---|---|---|
| 运动中开始记录 | 大尺寸物理键或清晰手势。 | 语音快捷命令；振动 + 声音确认；App 查看详情。 | 盲操作成功率、误触、汗液/手套、启动时延。 |
| 安静会议中提醒 | 可区分节奏的低噪振动。 | 屏幕/灯显示类别；稍后在 App 展开。 | 辨识率、旁人可感知度、打扰与漏看率。 |
| 语音问健康状态 | 语音输入与简短语音/屏幕回答。 | 按键启动、App 文本；不确定时澄清而非猜测。 | 噪声、隐私、延迟、误答、打断与替代路径。 |
| 高风险设置 | App 完整说明与确认。 | 设备端显示/振动最终状态；必要时实体操作。 | 理解正确率、跨端状态一致、撤销和审计记录。 |
文字流程容易遗漏分支，也容易让产品、嵌入式、App、云和测试对“当前状态”产生不同理解。状态图用有限状态、允许的转换和触发事件说明系统如何响应；状态表则系统性遍历可能的转换，帮助发现死路、非法事件和缺失恢复。
| 元素 | 定义 | 可穿戴 AI 示例 |
|---|---|---|
| State 状态 | 系统在一段时间内稳定保持、并决定如何响应事件的行为模式。 | 待机、运动记录中、暂停、同步中、低电保护、升级中。 |
| Event 事件 | 发生在某一时刻、可能触发转换的信号、调用、变化或时间事件。 | 按键点击、收到开始命令、网络恢复、电量低于阈值、30 秒超时。 |
| Guard 条件 | 事件发生后，转换允许执行必须满足的布尔条件。 | [已佩戴且电量≥10%且存储可用且账号授权有效]。 |
| Effect 转换动作 | 转换发生时执行的一次性行为。 | 创建记录、启动传感器、振动确认、上传状态版本。 |
| Entry / Do / Exit | 进入状态、处于状态期间、退出状态时的行为。 | 进入记录中亮图标；持续采样；退出时落盘并释放传感器。 |
| 状态描述字段 | 需要回答 | 价值 |
|---|---|---|
| 名称 / 范围 | 状态属于哪个对象，进入后系统对哪些事件有不同响应？ | 避免把页面、步骤、选项误当状态。 |
| Entry / Do / Exit | 谁执行、多久、能否中断、失败与清理方式是什么？ | 产品行为可落到模块和责任人。 |
| 用户可见反馈 | 设备、App、通知、声光振分别如何表达当前状态？ | 跨端状态一致且可理解。 |
| 数据 / 权限 | 状态期间读写什么，谁是真实源，版本和权限如何校验？ | 减少覆盖、重复和越权。 |
| 超时 / 恢复 | 最长停留多久，重启/断网/低电后恢复到哪里？ | 防止永远“处理中”。 |
转换表以“当前状态 × 事件”更便于工程实现和测试；原文使用“状态 × 目标状态”矩阵遍历状态对，也可用于发现遗漏。实际项目应选择团队最容易保持一致的表格，并明确方向。
| 状态类型 | 建议权威源 | 同步原则 |
|---|---|---|
| 物理事实 | 设备：佩戴、传感器、充电、电量、真实执行状态。 | App/云展示设备上报时间与新鲜度，不凭本地按钮猜结果。 |
| 本地任务 | 实际执行任务的设备/手机进程。 | 使用任务 ID、幂等命令、版本号和断线重连后的状态查询。 |
| 账号 / 权限 | 云端账号与授权系统。 | 设备缓存有有效期；撤权、离线和恢复时明确降级。 |
| AI 结果 | 产生该版本结果的端/云模型服务。 | 关联输入版本、模型版本、置信度与生成时间，防迟到覆盖。 |
| 用户偏好 | 按设置作用域定义设备/账号/家庭级真实源。 | 冲突策略、离线编辑、合并与最后修改者对用户透明。 |
| 覆盖类型 | 检查内容 |
|---|---|
| 状态覆盖 | 每个状态至少进入、执行、退出一次，用户反馈与数据不变量正确。 |
| 转换覆盖 | 每条合法转换在 Guard 真/假、边界值和不同入口下均被验证。 |
| 非法事件 | 当前状态不允许的按键、命令、重复请求被安全忽略、提示或拒绝。 |
| 时间与恢复 | 超时、重试上限、取消、重启、断网、低电和恢复点符合预期。 |
| 并发 / 竞态 | 设备与 App 同时控制、旧消息迟到、重复回调、顺序颠倒不会破坏状态。 |
原文以车载硬件和公众号为案例，先比较 App、平台入口等实现形式，再从硬件本身、硬件数据与第三方接口推导功能；进一步提出软件与硬件应互为主被叫、双向联动并完整展示状态。
| 载体 | 优势 | 限制 | 适合任务 |
|---|---|---|---|
| 原生 App | 系统权限、蓝牙、后台、推送、离线、复杂体验和长期扩展能力强。 | 下载安装与更新成本高，双平台开发维护，低频用户留存难。 | 设备核心控制、高频数据、持续连接、复杂账号/家庭/机构管理。 |
| 小程序 / 平台入口 | 触达快、免安装、已有账号/支付/分享，低频任务摩擦小。 | 能力受平台政策、运行时、后台/蓝牙与审核限制，存在平台依赖。 | 激活、一次性服务、轻量查询、分享、售后或补充入口。 |
| Web | 跨平台、更新快、适合大屏数据与后台管理。 | 设备权限与离线能力受限，移动端持续连接体验弱。 | B 端管理、报表、配置中心、客服/运营与开放平台。 |
| 无独立软件 | 用户负担最低，隐私与维护面更小。 | 复杂配置、历史、更新与服务能力有限。 | 设备可独立完成核心任务，软件价值不足以覆盖成本时。 |
最终选择可以是组合：原生 App 承担核心，Web 管理后台，小程序负责轻服务；但每增加一个端，都要承担账号、状态、版本和体验一致性成本。
| 来源 | 典型功能 | 产品判断 |
|---|---|---|
| 硬件能力 | 发现、激活、绑定、配置、控制、状态、诊断、OTA。 | 哪些必须近场完成，哪些可远程；断网/低电/版本不兼容如何处理。 |
| 硬件数据 | 历史、趋势、分析、提醒、报告、自动化和 AI 解释。 | 数据是否准确、可解释、有行动价值；采集与使用是否得到授权。 |
| 第三方生态 | 地图、支付、健康平台、家庭平台、客服、内容与开放 API。 | 用户价值、权限、数据责任、故障归属、成本和退出方案。 |
| 服务与运营 | 账号/家庭/机构、订阅、耗材、保修、客服、反馈与生命周期管理。 | 是否服务核心体验，还是为了运营堆功能；对无障碍和售后是否友好。 |
| 层级 | 定义 | 验收问题 |
|---|---|---|
| 基础必备 | 设备可被激活、绑定、配置、控制、查看状态和恢复。 | 首次成功率、日常任务成功率、异常恢复和可访问性是否达标？ |
| 体验增强 | 减少步骤、提升理解、主动提醒、历史与跨端衔接。 | 是否真实降低时间/错误/认知成本，而非只换 UI 主题？ |
| 设备 / 行业专有 | 由独有传感、算法、数据或业务流程带来的能力。 | 软硬件是否双向配合，价值能否在真实场景闭环？ |
| 个性化与安全 | 多人权限、私密数据、自动化、偏好与风险控制。 | 谁可看/可控/可分享，默认值、撤权、审计和误操作如何处理？ |
原文借马斯洛需求层次对应功能等级，这里保留“基础—共性差异—专有/私密”思路，但优先级应以任务证据、风险和商业价值确定。
| 端 | 适合承担 | 不应承担 |
|---|---|---|
| 穿戴设备 | 即时感知、低延迟反馈、紧急入口、离线核心能力和物理真实状态。 | 长文本、复杂权限、重配置和需要大量注意力的任务。 |
| 手机 App | 配对、深度配置、历史解释、纠错、多人/隐私、更新与客服。 | 把每次核心操作都强迫用户掏手机完成。 |
| 云 / AI | 跨设备账号、重模型、长期分析、远程服务、通知与运营。 | 让安全关键功能完全依赖网络且没有降级。 |
| 第三方平台 | 用户已使用的健康、家庭、支付或机构工作流。 | 未经理解与授权扩散敏感健康、位置或语音数据。 |
原文用 Kano 分类讨论功能排序，并指出功能属性会随产品阶段和核心诉求动态变化；迭代需求来自用户、技术支持、运营、生产等关键节点，需要经历“问题收集—汇总分析—转为需求—升级为功能”。
| 类型 | 用户反应 | 版本判断 |
|---|---|---|
| 必备型 | 没有会强烈不满，做到只觉得应该。 | 优先守住核心任务、可靠性、安全、隐私与售后底线。 |
| 期望型 | 表现越好，满意度通常越高。 | 选择影响任务成功和竞争力的关键性能，设连续指标。 |
| 魅力型 | 没有未必不满，做好会形成惊喜。 | 小范围验证真实使用与留存，防止“演示惊艳、日常闲置”。 |
| 无差异型 | 做与不做对满意度影响很小。 | 默认不进版本；只有合规、平台、运维或战略依赖才另行评估。 |
| 反向型 | 能力越强，部分用户反而越反感。 | 核对细分人群、默认值与可关闭性，避免通知、广告和自动化越界。 |
原文把“基本功能 + 无差别功能”放进首期，这不是可直接复用的排序规则；无差异功能通常应延后或删除。Kano 还要与战略匹配、风险、证据强度、工作量和依赖共同评估。
| 来源 | 能看到什么 | 常见偏差 | 应补字段 |
|---|---|---|---|
| 用户反馈 / 研究 | 目标、场景、理解、情绪与替代流程。 | 自选择、表达与样本偏差；声音大不等于人数多。 | 人群、任务、环境、频次、后果、原话和可复现步骤。 |
| 客服 / 技术支持 | 高频故障、说明盲点、恢复与售后成本。 | 只看求助者；同一根因被不同话术重复记录。 | 机型/版本、日志、根因、处理时长、解决率和重复联系。 |
| 运营 / 商务 | 转化、流失、渠道、活动和客户承诺。 | 短期指标、个别大客户或销售承诺挤压产品逻辑。 | 目标人群、漏斗、合同范围、长期价值与机会成本。 |
| 研发 / 测试 / 生产 | 技术债、性能、器件波动、良率、可测性与可维护性。 | 用实现便利代替用户价值，或到量产才暴露约束。 | 失效模式、发生率、影响、检测方式、修复窗口与版本依赖。 |
| 设备 / App / 云数据 | 真实路径、错误码、延迟、功耗、掉线和功能使用。 | 埋点缺失、口径漂移、幸存者偏差与相关性误判。 | 数据定义、版本、时间、分群、基线、隐私授权与质性解释。 |
| 阶段 | 产出 |
|---|---|
| 问题证据 | 按环境、网络、机型和固件分群：收音失败、上传中断、转写超时、结果入口难找分别占多少。 |
| 版本目标 | 优先提高“发起后得到可理解结果”的完成率，而不是先增加摘要模板。 |
| 最小切片 | 端侧可靠落盘 + 明确处理中状态 + 断点续传 + 失败重试/找回；再逐步优化识别模型。 |
| 指标护栏 | 完成率、端到端时延、重试恢复率；同时观察功耗、存储、云成本、误转写投诉与隐私退出。 |
| 发布策略 | 限定机型/版本灰度，保持旧链路可回退，客服能查任务 ID 和各阶段状态。 |
原文以人员资料批量下发考勤闸机为例：操作员点击后立刻去现场验证，却因设备执行滞后误以为失败；解绑失败没有被展示，重复提交又造成状态紊乱。改进方案是显示设备级进度与失败原因，自动重发网络类失败，并在完成时通知。
| 判断维度 | 同步式体验 | 异步式体验 |
|---|---|---|
| 完成时间 | 短且稳定，用户可合理等待。 | 耗时长或波动大，等待会阻塞其他任务。 |
| 参与节点 | 单端本地处理，结果立即可知。 | 设备、手机、云、AI、第三方等多节点协作。 |
| 连接条件 | 节点在线且连接可靠。 | 设备可能休眠、离线、弱网或稍后唤醒。 |
| 任务规模 | 单对象、单步骤、原子操作。 | 批量对象、多阶段、可部分成功或需后台计算。 |
| 用户需求 | 必须马上知道最终结果才能继续。 | 收到受理凭证后可离开，稍后查看或被通知。 |
同步与异步是调用和交付方式，不等于“快/慢”。即使系统内部异步，也可在很短时间内返回最终结果；产品真正要判断的是用户是否需要持续等待，以及何时能承诺最终事实。
| 机制 | 产品约束 | 用户体验表达 |
|---|---|---|
| 任务 ID / 关联 ID | 一次业务意图贯穿 App、云、消息与设备日志。 | 客服可查，历史可追踪，通知能返回正确任务。 |
| 幂等与去重 | 同一幂等键重复提交不重复产生副作用。 | 重复点击显示原任务，不生成多个互相冲突的任务。 |
| 超时 | 分别定义受理、排队、执行、回传和总任务超时。 | 超时不武断等于失败；可显示“结果未知，正在核对”。 |
| 重试 | 仅对临时故障，指数退避 + 抖动，设次数/时限上限。 | 展示自动重试状态；参数错误、权限问题不做无效重试。 |
| 取消 / 补偿 | 约定可取消阶段；不可逆动作设计补偿或人工处置。 | “取消请求已受理”与“设备已停止”必须区分。 |
| 版本与顺序 | 用版本号/序列处理旧消息迟到、乱序和覆盖。 | 不让旧设置覆盖新设置，冲突时给出可信当前值。 |
| 可观测性 | 各阶段埋点、错误分类、延迟、积压与成功率可查。 | 异常能被主动发现，支持能定位到具体节点。 |
| 场景 | 错误做法 | 正确做法 |
|---|---|---|
| 10 台设备下发配置 | 只显示“任务失败”，用户不知道 7 台其实已完成。 | 显示 7/10 成功；保留成功，列出 3 台失败原因并支持仅重试失败项。 |
| 解绑 / 删除 | 前台立即移除对象，设备仍保留权限。 | 先显示解绑中；由设备/权威源确认，失败则恢复展示并提高风险提示。 |
| 跨端配置更新 | 以 App 本地值当最终状态。 | 显示期望值与设备已应用值，带版本和更新时间，回读后再确认完成。 |
| 批量 AI 处理 | 一个样本错误导致全批次重做。 | 逐项记录输入、模型版本与结果；失败项可重跑且不覆盖已确认结果。 |
| 任务 | 权威完成信号 | 关键异常与兜底 |
|---|---|---|
| OTA 升级 | 设备重启后上报新版本并通过健康检查。 | 低电、断连、包校验、回滚；用户能继续核心任务或知道不可用时段。 |
| 语音转写 / 摘要 | 输入版本对应的结果已保存，可查看和纠错。 | 上传断点、云超时、低置信度、旧结果迟到、用户删除后的任务取消。 |
| 健康数据同步 | 指定时间范围和数据版本在手机/云确认入库。 | 重复数据、时区、缺口、离线、权限撤回；显示最近同步时间和缺失范围。 |
| SOS / 联系人通知 | 服务端/联系人通道明确回执；设备显示送达状态。 | 弱网、定位慢、联系人不可达；多通道重试与本地声光求助，不能只转圈。 |
原文把场景分为非关键与关键：前者容忍一定误识，用于称呼和内容推荐；后者涉及权限、控制或支付，需要更强验证。注册应考虑入口、采集设备、距离与语料；关键操作可采用随机口令与活体检测，降低录音冒用。
| 能力 | 回答的问题 | 产品输出 | 典型风险 |
|---|---|---|---|
| 语音识别 ASR | 说了什么？ | 文本、置信度、时间戳。 | 内容听错、专有词、噪声与口音偏差。 |
| 说话人验证 1:1 | 是声称的这个人吗？ | 与指定模板的相似度/通过结果。 | 冒用、误拒绝、重放/合成声音与模板泄露。 |
| 说话人识别 1:N | 已注册的 N 人中最像谁？ | 候选人、相似度、未知人。 | N 增大后混淆；把陌生人硬匹配为家庭成员。 |
| 说话人分离 / 聚类 | 一段音频里谁在何时说？ | 说话人片段或匿名聚类。 | 多人重叠、距离变化；聚类标签不等于真实身份。 |
产品文档必须写明是哪一种任务，以及是否允许输出“未知 / 无法判断”。家庭设备的 1:N 识别不能自然升级为高风险身份认证。
| 等级 | 场景 | 声纹角色 | 失败策略 |
|---|---|---|---|
| L0 无身份 | 天气、计时、通用问答。 | 不需要采集身份；默认匿名使用。 | 直接完成，不因“AI 能做”增加生物特征处理。 |
| L1 低风险个性化 | 称呼、音乐偏好、显示个人卡片。 | 作为软信号，允许未知与纠错。 | 采用中性结果，用户一句话切换；不暴露私密内容。 |
| L2 隐私访问 | 个人日程、消息摘要、健康趋势。 | 与已解锁设备、账号或在腕佩戴状态组合。 | 不确定就隐藏内容，转手机确认或输入 PIN。 |
| L3 高风险操作 | 支付、门锁、医疗处置、删除数据。 | 不应作为唯一凭证；只作为多因素或风险信号。 | 明确二次认证、交易确认、限额、审计与撤销。 |
原文强调注册与验证尽量采用同一设备/声学通道，避免信道失配。可复用原则是“按真实使用分布采集与评测”，不是固定要求每个人在 0.5、3、5 米各录一次。
| 指标 | 含义 | 产品影响 |
|---|---|---|
| FAR / 误接受率 | 冒用者被错误通过的比例。 | 决定隐私与安全风险；高风险场景优先压低，但会增加误拒绝。 |
| FRR / 误拒绝率 | 本人被错误拒绝的比例。 | 影响可用性、重试与客服；生病、年龄变化和环境会抬高。 |
| EER | 在某阈值下 FAR 与 FRR 相等的对比点。 | 便于模型比较，不是实际业务阈值，也不能代表所有人群。 |
| 未知人误识别 | 开放环境中陌生人被分配给已注册成员。 | 1:N 家庭识别必须显式测试“未知”拒绝能力。 |
| 攻击通过率 | 录音回放、变声、合成/克隆声音等被通过。 | 活体不能只验证用户念了随机数字，还要对真实攻击集评测。 |
| 延迟与失败率 | 采集—决策时长、超时、无结果与重试。 | 决定交互节奏、功耗、云成本与替代入口出现时机。 |
阈值不是模型团队的固定常数：它对应具体的风险、设备、环境和人群。上线前要画 FAR–FRR 权衡，并由产品、安全、法务和算法共同确认工作点。
| 场景 | 建议 | 关键验证 |
|---|---|---|
| 耳机自动加载个人偏好 | 通常设备已与个人账号绑定，声纹增益可能不足；先用佩戴/连接身份。 | 是否真有多人共用，声纹能否减少步骤而不增加收音与功耗。 |
| AI 眼镜多人共享 | 声纹可做快速候选，但隐私内容仍需可信设备或手机二次确认。 | 开放环境未知人、旁人语音、风噪、说话距离与账号切换。 |
| 手表读取健康摘要 | 在腕检测 + 已解锁状态通常比声纹更直接；声纹可作为额外上下文。 | 是否会当众读出敏感信息，误识和低置信度如何静默降级。 |
| 语音支付 / 门锁 | 不以声纹单因素放行；采用交易确认、限额、手机/密码/实体因素。 | 误接受、语音克隆、胁迫、撤销、异常告警与审计。 |
原文认为语音 + 音频内容已成为儿童硬件基础能力，但入口不易发现、内容价值难展示；视觉可承接拍照识物、绘本朗读、坐姿距离、学习与视频内容，并把手机上验证过的应用迁移到手表、带屏音箱等设备。
| 模态 | 擅长 | 局限 | 可互补方式 |
|---|---|---|---|
| 语音 / 音频 | 免手、自然提问、故事与即时反馈。 | 命令不可见、噪声/隐私、多人混淆、长内容定位弱。 | 屏幕给入口和字幕，摄像头提供指代对象，按键兜底。 |
| 视觉输入 | 物体、页面、姿态、手势、环境与指向上下文。 | 光照、遮挡、视角、误识别；持续采集隐私敏感。 | 语音澄清“你要问哪一个”，灯/屏显示相机状态和识别区域。 |
| 屏幕 / 图像 | 能力可发现、步骤、选项、图示、字幕和创作结果。 | 注意力与视力负担、成瘾/内容风险、功耗与小屏限制。 | 音频减少盯屏，实体活动承接练习，家长端配置边界。 |
| 触控 / 实体物 | 低门槛选择、盲操作、卡片/书本与现实世界映射。 | 配件丢失、误触、机械与供应链成本。 | 声光振确认，视觉识别实体内容，App 管理资源。 |
| 动作 / 传感 | 步态、佩戴、距离、姿势、运动和生理信号。 | 噪声、个体差异、误报与健康解释风险。 | 语音/视觉澄清，趋势而非单次判断，必要时由成人介入。 |
| 原文方向 | 任务化定义 | 主要风险与指标 |
|---|---|---|
| 拍照识物 / 查单词 | 孩子指向现实对象并提问；设备确认目标，给适龄解释与继续探索。 | 错误知识、拍到旁人/敏感信息；首轮成功率、澄清率、纠错与后续行动。 |
| 绘本朗读 | 识别当前书与页面，跟随翻页；朗读、提问、角色互动，鼓励回到实体书。 | 版权、页面误识、替代亲子共读；页面识别、跟随稳定、理解与主动阅读。 |
| 坐姿 / 距离提醒 | 在明确学习时段检测距离趋势，用温和提醒帮助调整，必要时交给成人。 | 持续摄像、误报羞辱、医学化承诺；有效提醒率、忽略率、误报与相机关闭率。 |
| 作业搜题 | 识别题目后先引导理解、提示步骤和自我检查，不直接替代思考。 | 答案依赖、错误/越级内容、拍摄个人信息；学习完成、自主解题和家长/老师认可。 |
| 滤镜 / 表情互动 | 孩子进行安全创作并在受控关系中分享。 | 人脸数据、外貌焦虑、陌生人社交与商业诱导；创作而非消费、举报与权限有效性。 |
| 视频 / 直播课 | 为明确课程提供稳定、适龄且可控的视听入口，并支持休息与线下练习。 | 屏幕时长、内容/广告、摄像头、互动安全；完成、理解、时长、退出和监护负担。 |
| 角色 | 核心诉求 | 必须拥有的控制 |
|---|---|---|
| 儿童 | 好理解、有趣、能自主完成任务、不过度打断或被监控。 | 知道何时采集、暂停/退出、纠错、求助；适龄说明而非只让家长同意。 |
| 监护人 | 安全、适龄、隐私、时间与消费可控，真正有学习/健康价值。 | 权限、内容来源、联系人、购买、数据保存/删除、报告粒度与异常通知。 |
| 老师 / 机构 | 教学目标、课堂秩序、可解释评估和低管理负担。 | 机构与家庭数据隔离、最小必要访问、班级设备管理与退出。 |
| 旁人 / 同伴 | 不被儿童设备无意拍摄、识别、上传或公开。 | 明显采集提示、限制后台拍摄、分享前检查与删除/举报渠道。 |
“家长付费”不意味着只优化家长控制；儿童既是使用者，也是数据主体和受影响者。产品要同时评审儿童收益、儿童自主性、监护责任与旁人边界。
| 层级 | 应测内容 | 不能只看 |
|---|---|---|
| 单模态质量 | ASR、视觉识别、距离/姿态、触控与传感各自准确、覆盖和延迟。 | 实验室平均准确率。 |
| 跨模态对齐 | “这个/这页/他”是否绑定正确对象，语音与画面时间是否一致。 | 各模型独立指标相加。 |
| 冲突与缺失 | 语音说 A、画面像 B；镜头遮挡、多人说话、无网和低电如何降级。 | 正常路径成功率。 |
| 儿童分群 | 年龄、身高、语言发展、口音、发音、动作能力和特殊需要的差异。 | 成人数据或单一年龄样本。 |
| 业务后果 | 误报/漏报对学习、自信、隐私、求助和家长行为的影响。 | 点击率、使用时长或拍照次数。 |
| 恢复体验 | 孩子是否理解错误、能澄清/撤销，家长是否能修复而不过度介入。 | 模型重试后的技术成功。 |
| 增加能力 | 连带变化 | PM 必问 |
|---|---|---|
| 摄像头 / 屏幕 | BOM、厚度、防护、跌落、功耗、热、续航、指示灯与认证。 | 收益能否覆盖整机代价？佩戴角度与手持姿态是否真的拍得到？ |
| 端侧视觉 / 多模态模型 | 算力、内存、启动时延、模型更新、量化精度与热管理。 | 哪些端侧、哪些云端？断网是否可用，模型失败如何降级？ |
| 视频与内容 | 带宽、存储、版权、审核、推荐、缓存、CDN 与订阅成本。 | 儿童是否需要屏幕？内容来源、广告、购买与退出如何受控？ |
| 跨端家长 App | 账号/家庭、远程权限、通知、报告、客服与数据生命周期。 | 家长能控制什么，不能远程窥视什么；孩子何时被告知？ |
| 知识层 | 核心问题 | 对应阅读 | 沉淀物 |
|---|---|---|---|
| 1 用户任务 | 谁在何时何地要完成什么，失败后果是什么？ | 01 交互起点 | 场景任务卡、参与者地图、六维交互审计。 |
| 2 交互形式 | 什么输入/反馈组合最省认知、注意力与动作成本？ | 02 交互形式 | 模态矩阵、风险—确认规则、交互技术采用闸门。 |
| 3 系统状态 | 设备、App、云各在什么状态，事件如何改变它？ | 03 状态转换 | 状态图/表、状态所有权、异常与测试覆盖。 |
| 4 软件编排 | 能力放哪一端，软件载体与软硬边界如何定义？ | 04–05 配套软件 | 载体矩阵、端侧分工、消息契约、动态迭代闭环。 |
| 5 跨端可靠性 | 长链路如何让用户可感知，并在失败后恢复？ | 06 异步任务 | 任务状态、ID/幂等/重试/超时、部分成功与通知。 |
| 6 AI 与多模态 | 不确定模型怎样在风险、隐私和儿童边界内创造价值？ | 07–08 声纹/视觉 | 风险分级、阈值指标、安全闸门、分群评测与替代路径。 |
| 层 | 拥有的事实 | 核心职责 | 关键接口 / 验收 |
|---|---|---|---|
| 硬件 / ID | 物理输入、传感、灯屏声振、佩戴、供电与执行器。 | 触达、人体工学、传感质量、物理隐私指示与安全动作。 | 按键/麦克风/相机参数，盲操作、环境、跌落、防护与续航。 |
| 固件 / 端侧 | 真实设备状态、资源、电量、连接与本地任务。 | 状态机、驱动、协议、缓存、离线、端侧 AI、恢复与 OTA。 | 状态/事件/错误码、幂等命令、时延、重启恢复和版本兼容。 |
| App | 手机本地 UI 状态与用户输入，不替设备宣告物理完成。 | 激活配置、复杂交互、历史解释、权限、纠错、通知与客服入口。 | 任务 ID、状态新鲜度、跨端一致、无障碍、取消/重试和埋点。 |
| 云 / 服务 | 账号、授权、远程任务、同步版本与服务端记录。 | 消息编排、数据、远程控制、通知、审计、第三方与运维。 | 鉴权、队列、超时/重试、顺序、删除、SLA 与可观测性。 |
| AI / 模型 | 指定输入与模型版本产生的预测，不拥有现实真相。 | 识别、生成、融合、置信与安全策略，持续评测和回退。 | 输入/输出契约、阈值、分群表现、延迟、成本、攻击与模型版本。 |
| 运营 / 支持 | 用户沟通、内容/策略配置、工单与人工处置记录。 | 异常响应、内容治理、灰度、客服诊断、反馈闭环和生命周期。 | 任务查询、告警、策略审计、回滚、响应时限与问题归因。 |
这 8 份资产不是 8 个孤立文档：用统一的场景 ID、任务 ID、状态名、错误分类和指标名贯穿，才能避免产品、设计、研发、测试与客服各说一套。
| 维度 | 验收问题 | 示例指标 |
|---|---|---|
| 任务价值 | 相比非 AI 方案，是否更快、更少步骤或解决了原本做不到的事？ | 任务成功、耗时、使用/复用、替代率、人工介入。 |
| 模型质量 | 在真实环境、关键分群和长尾输入上，错误类型与后果如何？ | 准确/召回、FAR/FRR、未知拒绝、幻觉/不当结果。 |
| 交互可理解 | 用户知道 AI 在做什么、如何表达、不确定时怎样纠错吗？ | 首轮成功、澄清、纠错、放弃、替代入口完成率。 |
| 端到端性能 | 从触发到最终可用结果的延迟、稳定和离线表现是否可接受？ | P50/P95 延迟、超时、任务积压、掉线恢复、离线成功。 |
| 硬件代价 | 传感、算力和联网对续航、热、BOM、空间和寿命的影响？ | 单次/日均耗电、温升、内存、带宽、云推理成本。 |
| 安全隐私 | 误识别、越权、攻击、敏感输出与数据生命周期如何控制？ | 攻击通过、越权、误通知、删除完成、审计与响应时限。 |
| 公平可访问 | 年龄、语言、能力、设备和环境分群是否存在不可接受差距？ | 分群差异、无障碍任务成功、替代路径和投诉。 |
| 商业可持续 | 价值、成本、内容/模型运维、客服和风险能否长期成立？ | 单位任务成本、订阅/留存、故障与客服成本、模型更新频率。 |
| 评审 | 参加者 | 必须过的问题 |
|---|---|---|
| 交互与任务评审 | PM、设计、用户研究、硬件/ID、客服。 | 核心任务、模态选择、设备/手机分工、可发现、反馈、无障碍和真实场景。 |
| 状态与可靠性评审 | PM、固件、App、云、测试、运维。 | 状态所有权、消息、异步、幂等、超时、断网/低电、版本、部分成功和回滚。 |
| AI 风险与发布评审 | PM、算法、数据、安全、隐私/法务、内容/儿童专家。 | 风险等级、阈值、分群、攻击、采集必要性、替代路径、灰度护栏和停止条件。 |
三场评审的输入名称要一致；交互稿中的“处理中”，必须能在状态表、接口字段、埋点、告警和客服工具中找到同一个含义。
| 能力 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 任务 | 只有功能 | 有场景 | 有人群、替代、后果与指标 |
| 跨端 | 只有 App 页 | 列出端 | 状态、所有权、消息与反馈一致 |
| 异常 | 只画正常 | 列错误 | 超时、恢复、取消、竞态可验收 |
| AI | 写“智能识别” | 有准确率 | 阈值、错误后果、分群与替代路径 |
| 隐私安全 | 未考虑 | 有权限 | 必要性、可感知、最小化、删除与攻击 |
| 验证 | 无法衡量 | 有指标 | 端到端、硬件、护栏、灰度和停止条件完整 |
达标线：9 分且“隐私安全”不得为 0。达到后，这份作业可以作为面试作品集中的一个跨端智能硬件案例骨架。
模块已完成 8 / 8。八篇均已逐篇精读并形成独立总结；另完成知识树、跨端体验链、责任矩阵、8 份 PM 交付物、AI 验收表、三场评审与实战自评标准。
把产品定义转成多专业协同、可验证、可量产的研发计划：明确阶段目标、输入输出、冻结基线、依赖关系、评审门、变更代价与问题闭环。
0→1 不是“研发完成即结束”，而是从立项证据一路延伸到供应商、整机验证、生产基线、上市承诺、售后响应和现场迭代。产品经理要让每次移交都有配置、标准和责任，让用户/市场信号最终回灌需求、质量和下一版决策。
原文从硬件、软件、ID/结构与互联网平台四条主线展开，解释产品定义通过技术评审后，各专业如何方案设计、详细设计、打板/开模、联调、试产，再进入 EVT、DVT、PVT；项目经理通过任务排期和行动清单持续跟踪。
| 主线 | 关键产出 | 主要依赖 / 接口 |
|---|---|---|
| ID / CMF | 草图、2D/3D 外观、颜色材质工艺、样件与签样。 | 产品定位、人机尺寸、关键器件与结构堆叠、工艺和成本。 |
| 结构 / 模具 | 堆叠、结构 3D/2D、板框、模具资料、试模修模与结构 BOM。 | ID 外形、PCB/器件、电池/屏幕/摄像头/声学、散热、防护和装配。 |
| 电子硬件 | 方案、原理图、PCB Layout/Gerber、样板、硬件 BOM 与测试报告。 | 结构板框、器件交期、天线/射频、功耗、EMC、固件驱动和产测。 |
| 固件 / 算法 | BSP、驱动、系统/应用、算法、版本包、日志与升级/恢复机制。 | 板卡、传感器、协议、App/云接口、测试夹具、量产烧录与版本兼容。 |
| App / 云 / 服务 | 后台、账号、协议、App/小程序、OTA、监控与运营支持。 | 设备协议和状态、数据模型、权限、网络、第三方服务和发布节奏。 |
供应链、测试、认证、质量和制造不是最后才加入的“第六条线”，而是贯穿五条主线的共同约束与验证者。
| 阶段 | 核心问题 | 典型样机 / 输出 | 退出证据 |
|---|---|---|---|
| EVT 工程验证 | 方案在工程上能否实现，关键风险与设计问题在哪里？ | 工程样机、关键模块/整机验证、方案比较、风险关闭计划。 | 核心功能跑通；关键器件与接口可行；主要风险已暴露；具备进入详细设计/开模依据。 |
| DVT 设计验证 | 接近最终设计的整机是否满足规格、可靠性、安全与法规？ | 试模整机、正式 PCB/结构/软件版本、全量验证和认证样机。 | 需求—测试可追踪；高优问题关闭；设计与测试结果支持冻结；认证风险受控。 |
| PVT 生产验证 | 最终设计能否被稳定、重复、经济地制造和检验？ | 小批量、量产 BOM/软件、SOP、治具、烧录/产测、签样与良率数据。 | 工艺、节拍、良率、一致性、追溯和质量控制达标；工厂文件与物料齐套。 |
| MP 量产 | 产能、质量、交付和市场版本能否持续稳定？ | 正式量产、出货检验、问题响应、版本与供应保障。 | 放量策略、质量监控、售后/OTA/召回机制和变更控制持续运行。 |
不同公司会使用 Proto、Alpha、Beta、T0、T1、Pilot Run 等名称。真正需要统一的是样机配置、验证范围、退出标准和基线版本。
| 计划层 | 要回答的问题 | 建议产物 |
|---|---|---|
| 里程碑 | 何时完成可验证的成熟度跨越，谁做 Go/No-Go 决策？ | 立项、方案冻结、投板/开模、EVT/DVT/PVT、认证、MP 节点。 |
| 工作分解 WBS | 需要哪些可交付任务，完成定义是什么？ | 按专业与阶段拆到可估算、可验收的工作包。 |
| 依赖网络 | 哪个输出是哪个任务的输入，关键路径在哪里？ | 前置/后置、接口里程碑、外部物料与认证周期。 |
| 滚动计划 | 近端要细到行动，远端保留不确定性与缓冲。 | 2–4 周详细任务 + 阶段级远期计划 + 风险缓冲。 |
| 行动清单 | 今天谁做什么决策或输出，何时回报？ | Owner、承诺日、状态、阻塞、下一动作和证据链接。 |
| 节奏 | 重点 | 输出 |
|---|---|---|
| 每日 / 短会 | 关键路径、今日交付、阻塞与跨团队支持。 | 下一动作、Owner、承诺时间；不展开无关技术争论。 |
| 每周项目会 | 里程碑偏差、风险、资源、变更、测试和供应状态。 | 一页状态、RAID 更新、决策需求与升级事项。 |
| 专题评审 | 方案、堆叠、原理图/Layout、结构、测试、认证或量产准备。 | 输入版本、问题清单、结论、条件和签署记录。 |
| 阶段门 | 成熟度证据是否足以投入下一阶段高代价资源。 | Go / Conditional Go / Rework / Stop 与基线冻结。 |
状态汇报要写“事实—影响—方案—需要的决策”，避免只报“完成 80%”。没有完成定义和剩余工作，百分比无法用于判断。
原文将 IPD 概括为市场驱动、跨部门端到端协同、结构化并行、平台/CBB 复用、技术开发与产品开发分离，并用 Charter—设计与计划—T0—EVT—DVT—PVT—MP 串联决策点、准出与技术评审。
| 内容 | 关键问题 | 最小证据 |
|---|---|---|
| 竞争环境与优势 | 替代什么，凭什么赢，竞争反应与差距是什么？ | 竞品/替代方案、客户决策准则、差异可持续性。 |
| 战略定位 | 抢先发布、替代旧品、扩展品类还是进入新市场？ | 公司战略、组合位置、进入/退出逻辑与优先级。 |
| 客户价值 | 客户获得什么结果，谁使用、谁购买、谁受影响？ | 场景证据、价值假设、痛点强度与支付/采用意愿。 |
| 市场与客户 | 细分市场多大、增长如何、目标客户和渠道是谁？ | 容量口径、可获得份额、渠道/区域和生命周期假设。 |
| 目标与范围 | 时间、质量、成本、财务与不做什么分别是什么？ | 里程碑、目标成本、收益假设、质量红线和范围边界。 |
| 关键风险 | 市场、技术、供应、法规和交付中最可能推翻项目的是什么？ | 风险清单、预研/验证计划、触发阈值与止损条件。 |
| 跨职能团队 | 谁对商业成功负责，哪些资源已承诺？ | 核心团队、角色权限、资源负荷、决策者与质量保证。 |
使用方法：让目标客户对各维度重要度排序，再比较自身、竞品与替代方案的表现；不能由内部团队凭感觉打分后当作需求结论。
| 角色 | 从早期承担的责任 | 决策证据 |
|---|---|---|
| 市场 / 产品 | 机会、客户价值、需求、产品包、范围、上市与生命周期。 | 场景/市场证据、竞争、价值与需求优先级。 |
| 研发 / 技术 | 架构、可行性、平台复用、实现计划、技术风险与质量。 | 预研、方案、估算、原型、评审和测试结果。 |
| 供应链 / 制造 | 物料、供应商、模具、工艺、产能、成本与交付。 | 询价、交期、替代料、DFM、试产和良率。 |
| 质量 / 测试 / 法规 | 质量目标、验证策略、认证、过程质量与发布准入。 | 需求追踪、测试覆盖、缺陷、认证和风险接受。 |
| 财务 / 商务 | 预算、目标成本、收益、现金、合同与投资回报。 | 单位经济、预算消耗、敏感性与止损点。 |
| 服务 / GTM | 渠道、交付、内容、客服、售后、培训和退市。 | 上市准备、服务能力、备件、反馈与生命周期计划。 |
团队“重量级”不等于人数多，而是核心成员代表职能做承诺，有明确决策权限，并以产品商业结果而非部门局部指标为共同目标。
| 类型 | 目标 | 准入产品项目前的证据 |
|---|---|---|
| 技术预研 / 平台 | 解决高不确定的新器件、算法、射频、材料、工艺或基础平台问题。 | 性能边界、成熟度、接口、成本/功耗、供应、风险与可复用资产。 |
| 产品开发 | 在明确市场窗口、成本、质量和交付约束下集成已达标能力。 | 需求与架构、资源、计划、平台/技术依赖和未决风险可管理。 |
每个复用决策都要记录“复用 / 适配 / 新建”的业务理由、差异清单、验证范围和长期维护成本。
| 关口 | 回答什么 | 主要参与者 | 结论 |
|---|---|---|---|
| DCP 决策评审 | 机会和计划是否仍值得投资，是否匹配战略与组合优先级？ | 投资/组合决策者 + 跨职能项目负责人。 | 继续、带条件继续、调整、暂停或终止投资。 |
| TR 技术评审 | 需求、架构、设计、集成、样机和小批证据是否达到技术基线？ | 相关技术、测试、质量、供应与制造专家。 | 通过、整改后通过、补证或不通过；输出技术风险。 |
| 阶段准出 | 本阶段退出标准是否满足，下一阶段输入是否齐套？ | 项目团队、质量/PMO 与下一阶段接收方。 | 准出、条件准出或返回；冻结相应配置与遗留项。 |
技术评审通过并不自动代表值得继续投；商业机会很好也不能跳过技术和质量证据。DCP 使用 TR、财务、市场、供应和上市准备等综合输入。
越晚变更，已投入的模具、物料、认证、软件兼容、测试覆盖和上市承诺越多。紧急安全/法规问题仍必须变，但要升级决策并明确回退与客户影响。
| 保留机制 | 轻量实现 |
|---|---|
| 任务书 / Charter | 一页纸写机会、产品包、目标、范围、经济性、风险、团队与止损条件。 |
| 跨职能核心组 | 产品、研发、供应/制造、质量/测试、财务/GTM 每类一个可承诺的代表。 |
| 三类评审 | 方案/TR、阶段准出、投资/DCP 分开；复用同一证据库，避免重复做 PPT。 |
| 基线与变更 | 用版本库 + 简单变更单记录需求、BOM、图纸、软件和计划的影响与批准。 |
| 停止机制 | 每个阶段写 Go/Stop 指标，允许及时中止，把资源还给更有价值的项目。 |
原文依次梳理 ID、结构、硬件和软件设计，并以指纹加密 U 盘的市场失利、结构公差与多轮修模为例，说明“设计完成”不是某个部门交图，而是价值、外观、堆叠、电子、软件、工艺和验证共同达到可交付状态。
| 判断层 | 产品经理要问 | 进入设计前的证据 |
|---|---|---|
| 目标场景 | 用户在什么时刻需要它，现有做法为何不够？ | 真实任务、频率、痛点强度与当前替代方案。 |
| 目标客户 | 谁使用、谁付费、谁影响购买，ToB 成功能否迁移到 ToC？ | 细分用户、决策链、采用阻力和渠道触达。 |
| 差异价值 | 比软件、通用品或竞品多创造什么结果？ | 可感知优势、不可替代性和关键指标验证。 |
| 商业边界 | 目标成本、售价、教育成本与服务成本能否成立？ | 单位经济、价格测试、供应报价和最小销量假设。 |
| 重投入条件 | 什么时候值得投入定制 PCB、结构、模具和认证？ | 最危险假设已用低成本原型验证，停止条件明确。 |
形态与 CMF 在真实项目中经常并行迭代。PM 的工作不是把步骤机械串行化，而是为每轮方案明确输入约束、比较维度、否决红线和签署版本。
| 接口 | 共同确认项 | 冻结证据 |
|---|---|---|
| 结构 × 硬件 | 板框、孔位、连接器、器件高度、排线、测试点和拆装。 | 受控 DXF/3D、堆叠报告、PCB 约束与评审纪要。 |
| 结构 × 射频 | 天线空间、净空、金属/电池距离、人体遮挡与接地。 | 天线约束图、仿真/样机数据和最差姿态测试。 |
| 结构 × 热 / 电池 | 热源、传热路径、表面温升、电芯膨胀、保护与安全间距。 | 热方案、温升数据、电池规格与安全风险评审。 |
| ID × 结构 / 工艺 | 曲面、分型线、拔模、壁厚、装饰件、表面处理与装配缝。 | DFM、CMF 样板、尺寸公差与外观限度样。 |
| 硬件 × 软件 | 器件驱动、引脚、协议、状态、日志、升级、产测与版本兼容。 | 接口文档、联调版本、状态机和测试用例。 |
接口表必须有 Owner、版本、变更通知对象和验证方法；“已经口头对过”不是工程基线。
原文案例通过高反差处理弱化指纹模块与铝壳间隙的视觉感知，这可以是体验优化，但不能替代公差根因、制程能力和批量一致性治理。
| 试模前 | 试模中 | 试模后 |
|---|---|---|
| 冻结本轮图纸、材料、工艺参数与样机配置。 | 按样本量记录尺寸、外观、装配、功能与制程条件。 | 问题分级，区分模具、设计、材料、工艺与装配根因。 |
| 定义要验证的风险、CTQ、量具、标准和通过阈值。 | 保留良品/不良品、照片、测量数据和批次追溯。 | 形成改模方案、责任人、影响分析、费用和下一轮验证项。 |
| 确认供应商、结构、质量和 PM 的决策权限。 | 现场问题先事实化，不凭单个样件或主观手感下结论。 | 签署通过、带条件通过或继续整改，并更新基线。 |
| 基线 | 典型冻结内容 | 冻结后的主要代价 |
|---|---|---|
| 产品 / 体验 | 目标用户、核心场景、关键规格、成本和范围。 | 需求、商业与各专业方案全面重排。 |
| 架构 / 堆叠 | 关键器件、形态包络、板框、接口和空间分配。 | ID、结构、PCB、天线、热和采购连锁返工。 |
| 详细设计 | 3D/2D、原理图/Layout、软件接口、BOM 与测试规格。 | 重投板、重打样、软件兼容与验证回归。 |
| 工装 / 认证 | 开模数据、治具、认证样机与正式物料。 | 改模、呆料、认证重测、交付延期和现金损失。 |
| 生产基线 | 量产 BOM、图纸、软件、SOP、检验与签样。 | 停线、批次切换、返工、追溯、售后与客户影响。 |
原文用“构思—设计—工程—验证”组织硬件开发：构思确认问题与方案假设，设计优化完整体验，工程把规格变成可靠、可负担的功能，验证则从 EP、EVT、DVT、PVT 逐步收敛到 MP。
| 阶段 | 要消除的不确定性 | 核心输出 | 退出条件 |
|---|---|---|---|
| 构思 | 问题是否真实，目标客户、价值与解法方向是否成立？ | 问题证据、细分客户、假设清单、POC 与学习结论。 | 关键假设有证据；失败条件明确；值得进入体验与工程探索。 |
| 设计 | 用户能否理解、完成任务并愿意持续使用？ | 体验流程、线框/状态、外观与 CMF 原型、包装与反馈。 | 核心任务可完成；高风险体验问题收敛；设计意图可被工程承接。 |
| 工程 | 功能能否可靠实现，并达到尺寸、功耗、成本和可制造约束？ | 工作规格、选型、功能原型、PCB/结构、固件/App/云联调。 | 核心功能与关键指标达标；主要技术风险关闭；配置可追踪。 |
| 验证 | 合体设计是否满足全量要求，生产过程能否稳定复制？ | EP/EVT/DVT/PVT 样机、验证报告、量产资料与发布结论。 | 需求、法规、可靠性、质量和制造证据支持 MP。 |
四阶段不是严格串行：设计与工程通常并行迭代，但每次并行都要共享同一份需求、接口和样机配置。
| 原型 | 主要回答 | 可以牺牲 | 不能用来证明 |
|---|---|---|---|
| POC 概念验证 | 关键技术、感知价值或场景假设是否可能成立？ | 外观、体积、集成度、成本与长期可靠性。 | 完整体验、量产成本和设计可靠性。 |
| 体验 / 外观原型 | 形态、佩戴、信息、交互、CMF 和完整旅程是否可理解？ | 真实电子、最终材料、内部结构和性能。 | 功能性能、续航、射频和制造能力。 |
| 功能原型 | 核心功能、器件、PCB、算法、结构与软件链路能否达到规格？ | 最终外观、量产工艺、体积优化与包装。 | 最终用户体验和生产一致性。 |
| EP 工程原型 | 设计意图与工程功能合体后，整机是否可装、可用、可报价？ | 量产工具、极致成本和大样本统计。 | 全量法规/可靠性与稳定生产。 |
| EVT / DVT / PVT | 从工程正确、设计符合到生产稳定逐级形成发布证据。 | 仅允许与阶段目标一致的非关键临时项。 | 超出本轮配置与覆盖范围的任何结论。 |
原文提醒包装容易被遗漏。对可穿戴 AI 产品，还要把授权、数据删除、模型/服务不可用、订阅变化和旧设备兼容加入全旅程。
轻量不等于少写关键约束。小团队可以用一个共享的“活文档”，但需求必须可验证、版本化，并与设计、测试和变更建立追踪。
自下而上适合定位底层问题，但不能等底层全部完成才验证用户链路；关键场景应尽早用模拟器、开发板和桩服务并行做端到端冒烟。
| 阶段 | 核心判断 | 重点证据 | 高代价承诺 |
|---|---|---|---|
| EP | 外观体验与功能工程能否合体，DFM 和报价输入是否可用？ | 整机功能、装配空跑、初版 BOM/图纸、关键性能与风险。 | 准备正式设计收敛、供应商报价与工装决策。 |
| EVT | 工程方案和核心功能是否满足规格？ | 生产环境首次组装、功耗/热/EMI 等工程测试与设计修正。 | 正式工具、设计细化与下一轮验证物料。 |
| DVT | 接近最终设计是否覆盖法规、环境、可靠性和外观要求？ | 量产工艺样机、完整设计验证、认证样机与缺陷关闭。 | 设计冻结、认证、量产物料和生产准备。 |
| PVT | 正式设计和全套产线能否稳定复制、检验与追溯？ | 节拍、良率、返工、SOP、治具、培训、QA/QC 与包装出货。 | 放量、渠道交付和现场质量责任。 |
每阶段样机数应由测试覆盖、置信度、失效率目标、认证要求和生产风险决定；不能用文章中的“常见数量”倒推项目成熟度。
原文从智能摄像头项目出发，强调硬件迭代周期长、牵一发而动全身；软件版本要跟随硬件交付与接口变化，预留软硬件联调和兼容风险，并把主机、配件、质量、生产、产能和供货作为完整产品共同管理。
| 层 | 影响检查 | 典型证据 |
|---|---|---|
| 硬件 / 结构 | 器件、PCB、连接、功耗、天线、热、堆叠、模具和配件。 | 图纸/BOM 差异、样机配置、工程测试和供应变更。 |
| 固件 / 算法 | 驱动、状态、协议、资源、数据、诊断、产测、升级与回退。 | 接口版本、固件包、日志、单元/板级/整机测试。 |
| App / 云 | 能力识别、页面/入口、权限、账号、服务、埋点和错误提示。 | 功能开关、设备能力模型、API、配置与发布说明。 |
| 测试 / 质量 | 需求追踪、兼容组合、回归、可靠性、数据安全与缺陷。 | 测试矩阵、覆盖率、缺陷结论和风险接受。 |
| 制造 / 供应 | 物料、治具、烧录、SOP、检验、产能、旧料和批次切换。 | ECN、量产资料、试产数据、切换计划与追溯。 |
| 用户 / 服务 | 购买识别、设置、兼容提示、客服、退换、数据与售后。 | 说明/包装、支持脚本、监控、通知与客户影响。 |
例如去掉夜视模块，不只是删除一个器件：设备能力上报、App 入口、提示文案、SKU 识别、测试用例、包装说明和客服判断都要同步变化。
| 工作类型 | 板卡到达前 | 真实硬件到达后 | 准出条件 |
|---|---|---|---|
| 独立软件 | 页面、账号、云服务、业务逻辑和自动化测试。 | 与设备状态、性能和异常场景整机回归。 | 独立测试 + 目标配置整机测试通过。 |
| 接口依赖 | 协议评审、Mock/模拟器、契约测试和错误码。 | 真实时序、丢包、重试、断电、升级和兼容测试。 | 协议基线、契约与端到端测试一致。 |
| 强硬件依赖 | 开发板/样机、算法数据、测试设计和风险预案。 | 性能、功耗、热、射频、稳定性与长稳联调。 | 关键指标和目标样机配置达标。 |
| 量产依赖 | 烧录/产测方案、治具接口、追溯数据和 SOP 草案。 | 产线节拍、误判漏判、重测、恢复与批次追踪。 | 试产数据支持 PVT/MP。 |
联调时间不是计划尾部的一块“缓冲”。应分板级、设备协议、App/云、整机、生产和现场多层推进，每层都写准入、目标配置、问题 Owner 与退出标准。
| 维度 | 示例 | 发布前要定义 |
|---|---|---|
| 设备 | SKU、区域、PCBA/BOM、存量批次和替代器件。 | 能力差异、最低版本、不可升级组合与识别方式。 |
| 固件 | Bootloader、正式/灰度固件、算法模型与配置。 | 升级路径、跨版本策略、断电恢复和回退边界。 |
| 客户端 | iOS/Android、OS 版本、App 版本和区域商店。 | 最低支持、强更/弱更、旧客户端行为与提示。 |
| 云与协议 | API、消息协议、账号系统、区域服务和配置。 | 向前/向后兼容、灰度路由、降级与数据迁移。 |
| 配件 / 环境 | 底座、充电器、网关、Wi‑Fi/蓝牙和第三方系统。 | 支持清单、限制、检测、异常提示与客服口径。 |
原文的配件圆角导致无法装配，是“未把附件纳入同等级 DFM、样件验证与签样”的典型系统性遗漏；手工修整只能应急，之后仍需闭环图纸、模具和检验标准。
| 事实字段 | 必须记录 | 帮助回答 |
|---|---|---|
| 配置 | 序列号/SKU、硬件、固件、App、云配置、账号与配件版本。 | 是否为特定组合或批次问题？ |
| 环境 | 网络、手机/OS、电量、温度、位置、权限与外设。 | 是否由环境或前置条件触发？ |
| 时间线 | 用户动作、设备状态、消息、API、重启/升级和服务器事件。 | 链路在哪一步首先偏离？ |
| 日志 / 指标 | 统一时间、关联 ID、错误码、关键状态、性能和崩溃。 | 能否跨设备—App—云串起证据？ |
| 数据安全 | 最小采集、授权、脱敏、访问控制、保留期与删除。 | 诊断是否在保护用户数据的前提下进行？ |
原文以上篇形式覆盖项目立项、需求确认、方案规划，以及业务流程、ID 概念、产品原型和硬件结构设计，反复强调产品经理要连接老板、产品、销售、设计与硬件，并让意图在上下游之间保持一致。
SWOT 可以帮助罗列内部与外部因素，但不能自动证明机会成立；关键是证据质量、假设因果和可执行决策标准。
| 会前输入 | 会议议程 | 会后输出 |
|---|---|---|
| 机会/场景证据、目标、范围候选与不做清单。 | 先对齐决策问题与评价标准。 | 范围、优先级和接受/拒绝理由。 |
| 初步架构、依赖、关键器件、成本/周期和风险。 | 按争议与关键路径讨论，不逐条念需求。 | 里程碑、工作包、Owner、支持者和承诺日。 |
| 资源负荷、供应/法规约束和需高层决策事项。 | 逐项处理冲突、假设、缺口与升级。 | 接口、基线、RAID、决策日志和下次检查点。 |
项目工具用于透明协作与风险闭环，不是“追责到人”的终点。Owner 负责推动结果，组织也必须解决资源、依赖和决策阻塞。
| 层级 | 用途 | 需要表达 |
|---|---|---|
| L1 业务骨架 | 让团队一眼理解产品服务谁、解决什么、主要价值链和系统边界。 | 角色、核心任务、前后端系统、关键状态、价值时刻与主链路。 |
| L2 场景流程 | 支撑交互、协议、异常、测试、研发估算和验收。 | 前置条件、用户/设备/App/云动作、分支、失败恢复、数据和结束状态。 |
先快速确认 L1 再深入 L2，但不能把“快速”理解成跳过异常、离线、权限、低电、OTA、数据删除等会决定硬件体验的关键场景。
| 接收方 | 需要从原型得到什么 | 配套材料 |
|---|---|---|
| 管理 / 业务 | 核心价值、范围、主流程、差异与关键取舍。 | 场景故事、目标指标、范围与里程碑。 |
| UI / 交互 | 信息层级、状态、组件、导航、文案与交互原则。 | 流程、状态机、异常、内容与设计约束。 |
| 硬件 / 固件 | 物理输入输出、灯声屏、时序、状态和设备能力。 | 接口、事件/状态表、功耗与响应指标。 |
| App / 云 | 账号、数据、API、配置、离线/同步与多设备关系。 | 数据流、权限、协议和兼容策略。 |
| 测试 / 质量 | 可观察结果、边界、失败恢复和验收路径。 | 需求追踪、场景用例和通过标准。 |
低保真与高保真应由验证问题决定。产品经理的不可替代性不来自画得更精美，而来自让价值、约束、决策和验收在各专业间一致。
| 产品选择 | 工程连带影响 | PM 决策证据 |
|---|---|---|
| 屏幕 / 交互 | 尺寸、触控/按键、功耗、结构、成本、供应和软件布局。 | 任务效率、可读性、人群、环境、续航与单位经济。 |
| 运动机构 | 电机、电源、噪声、寿命、夹伤、走线、公差与维护。 | 用户价值、速度/精度、可靠性、安全和成本目标。 |
| 供电 | AC/DC、电池、适配器、功率、充电、热、安全与区域认证。 | 使用场景、移动性、续航、峰值负载和法规。 |
| 线束 / 接口 | 信号完整性、EMC、弯折、装配、维修和连接可靠性。 | 数据/电流、环境、寿命、空间和产线测试。 |
| 材料 / 器件 | 强度、重量、外观、工艺、价格波动、交期和替代。 | CTQ、目标成本、供应风险和验证计划。 |
原文续写辅件接入、UI、产品研发、测试验收和工厂生产，并把后期扩展到营销、售后和迭代；其可复用价值在于提醒产品经理：外接设备、工厂校准、出厂软件、售后工单和销售反馈都属于产品系统。
“同行没用过”不是选择优势。成熟供应商和通用件可能降低风险；应按差异价值、验证证据、总成本和供应韧性决策。
| 评审 | 主要问题 | 输入 / 输出 |
|---|---|---|
| 视觉方向 | 品牌、目标人群、可读性、场景、硬件显示与无障碍是否匹配？ | 设计原则、多方向探索、关键页面 → 选定方向与修改条件。 |
| 完整设计 | 状态、组件、信息、动效、异常、离线、加载和多端一致性是否完整？ | 全流程、状态稿、交互说明 → 设计基线与未决问题。 |
| 研发走查 | 真实设备上的尺寸、性能、字体、颜色、动效、交互和资源是否一致？ | 目标版本/设备、实现包 → 差异清单、修复与接受偏差。 |
| 用户验证 | 目标用户能否理解并完成关键任务，失败时能否恢复？ | 可用版本、任务脚本 → 行为证据、严重度和迭代决定。 |
动效必须服务状态反馈、空间关系、等待感知或品牌表达，同时受设备帧率、内存、功耗和无障碍约束；不能以“更丰富”作为唯一理由。
| 活动 | 判断什么 | 主要责任 | 输出 |
|---|---|---|---|
| 验证 Verification | 设计实现是否符合规格、接口、法规、可靠性和制造要求？ | 测试/质量 + 各专业工程。 | 需求追踪、测试报告、缺陷与技术风险。 |
| 确认 Validation | 目标用户在真实场景中是否能获得预期价值？ | 产品/研究 + 用户 + 业务相关方。 | 场景结果、可用性、采用与未满足需求。 |
| 业务验收 | 约定范围、商业/运营/服务和上市材料是否就绪？ | 产品、GTM、服务、运营与项目决策者。 | 接受/拒绝/条件接受、遗留项与承诺。 |
| 发布批准 | 综合质量、供应、法规、生产、市场和售后风险能否对外承诺？ | 跨职能发布委员会 / 授权决策者。 | Go / Conditional Go / Hold / Stop 与回退计划。 |
让市场、销售和运营“体验一下”可以补充视角，但不能替代专业测试、目标用户验证和可追踪的发布准入。
“不合格就重新组装”不能取代根因和过程能力治理。重复失败要触发停线/隔离、原因分析、纠正预防和验证。
| 对象 | 用途 | 最低内容 |
|---|---|---|
| ECR 工程变更申请 | 提出问题/机会并请求跨专业影响分析和决策。 | 原因、现状、建议、紧急度、受影响基线、用户/法规/质量风险。 |
| 影响分析 | 比较实施、不实施、延后或替代方案的全链路代价。 | 设计、软件、BOM、工装、测试、认证、库存、供应、客户和计划。 |
| CCB 决策 | 由授权角色决定批准、拒绝、补证或分期。 | 结论、条件、预算、版本/批次、生效点、验证和回退。 |
| ECN 工程变更通知 | 把已批准变更下发到所有受控文件和执行方。 | 新旧差异、文件/BOM/软件、切换日期、旧料、通知与培训。 |
| 关闭 | 确认变更按批准内容实施且效果达成。 | 首件/回归、批次验证、库存处理、现场监控与关闭签署。 |
| 问题 | B2C 重点 | B2B 重点 |
|---|---|---|
| 客户 / 用户 | 购买者与使用者常重合，关注认知、价格、开箱与留存。 | 购买、使用、管理、IT/安全、财务等多角色决策。 |
| 价值证据 | 可感知结果、评测、口碑、退货原因和真实使用。 | 试点成效、TCO/ROI、集成、合规和服务 SLA。 |
| 渠道 | 电商、零售、内容/社区、广告与合作渠道。 | 直销、合作伙伴、集成商、经销、展会和招投标。 |
| 交付 | 库存、物流、激活、客服、退换与订阅。 | 合同、实施、培训、验收、运维、备件与续约。 |
| 发布门 | 产品可用性、产能/库存、合规、定价、渠道物料、客服与监控同时就绪。 | |
| 信号源 | 优势与偏差 | 进入路线图前的验证 |
|---|---|---|
| 行为 / 遥测 | 覆盖广、客观；但只能看到被记录的行为，因果可能不清。 | 事件质量、分群、场景、访谈与实验。 |
| 售后 / 质量 | 故障事实强；容易被高情绪、特定批次和渠道放大。 | 发生率、严重度、根因、批次与用户影响。 |
| 销售 / 市场 | 接近购买阻力与竞品；可能偏向短期成交或大客户。 | 丢单数据、细分市场、可复制性和单位经济。 |
| 用户研究 | 能解释动机和场景；样本规模与招募会产生偏差。 | 行为任务、代表性、多方法交叉和可测试假设。 |
| 内部 / 战略 | 连接平台、成本与长期方向；可能脱离真实用户。 | 战略假设、客户价值、机会成本和阶段性验证。 |
| 法规 / 安全 | 通常具有强制性或高损失；不是普通功能排序。 | 适用性、风险等级、法律/质量意见和截止时间。 |
| 关口 | 主要证据 | 分层冻结 / 承诺 | 决策 |
|---|---|---|---|
| Charter / 概念门 | 机会、客户、替代、产品包、经济性、预研与风险。 | 目标市场、价值主张、项目边界和探索预算。 | 是否值得进入定义与计划。 |
| 需求 / 计划门 | PRD/规格、架构、成本、资源、WBS、供应与验证策略。 | 核心场景、需求基线、目标成本、里程碑和止损条件。 | 是否承诺产品项目与长周期资源。 |
| 方案 / 投板开模门 | ID/堆叠、选型、原理图/PCB、结构 DFM、软件接口、POC。 | 关键器件、外形包络、板框接口、设计输入与 BOM 路线。 | 是否投入 PCB、模具、长交期物料。 |
| EVT 准出 | 工程样机、核心功能、功耗/热/射频、集成与主要风险。 | 工程方案、接口、样机配置与 DVT 验证计划。 | 工程设计能否进入完整验证。 |
| DVT / 认证门 | 全量规格、可靠性、安全、法规、用户确认与缺陷关闭。 | 设计、量产 BOM 候选、软件发布候选和认证样机。 | 是否冻结设计并投入量产准备。 |
| PVT / 发布门 | 工艺、良率、节拍、产测、SOP、追溯、供应、服务/GTM。 | 生产基线、签样、批次切换、发布包和售后承诺。 | 是否放量、对外发货与灰度发布。 |
| MP / 生命周期门 | 销量、质量、退货、现场故障、成本、供应和客户结果。 | 改版/ECN、平台复用、扩产、维持或退市计划。 | 继续投入、优化、换代或退市。 |
冻结对象和决策门不是同一件事：一个阶段可能冻结多类基线；一次决策也会综合技术、财务、市场、供应和客户证据。
| 资产 | 核心字段 | 维护时机 |
|---|---|---|
| 01 Charter / 产品包任务书 | 机会、客户、产品包、目标、经济性、范围、风险、团队、止损。 | 立项与每次投资门。 |
| 02 需求—验证追踪矩阵 | 需求、来源、优先级、指标、设计、测试、版本和结果。 | 定义到发布持续更新。 |
| 03 架构 / 接口控制文档 | 系统框图、机械/电气/协议/数据接口、Owner 与版本。 | 方案、集成与每次接口变更。 |
| 04 里程碑 / WBS / 依赖网 | 交付物、完成定义、责任、日期、依赖、关键路径与缓冲。 | 周滚动与阶段门。 |
| 05 RAID + 决策日志 | 风险、假设、问题、依赖、决策、影响、Owner 与证据。 | 日常项目节奏。 |
| 06 配置 / 兼容矩阵 | SKU、硬件/BOM、固件、App、云、配件、区域与支持状态。 | 样机构建、联调、生产与发布。 |
| 07 验证主计划 | 阶段目标、样本/配置、环境、方法、标准、覆盖与报告。 | 定义、EVT/DVT/PVT 与变更回归。 |
| 08 变更单 ECR/ECN | 原因、影响、方案、批准、切换、旧料、验证和通知。 | 任何受控基线改变。 |
| 09 量产 / 发布准备清单 | BOM/软件、SOP、产测、质量、供应、认证、GTM、服务、回退。 | PVT、MP 与每次重大发布。 |
| 10 现场质量 / 复盘 | 工单、批次、根因、CAPA、指标、客户影响和经验回灌。 | 上市后持续运行。 |
| 维度 | 领先指标 | 升级触发器 |
|---|---|---|
| 价值 / 范围 | 关键假设证据、需求稳定性、MVP 覆盖与价值验证。 | 核心场景不成立、范围持续增长或验收无法定义。 |
| 进度 / 依赖 | 关键路径里程碑、承诺兑现、缓冲消耗和外部依赖。 | 关键路径滑动、长交期失约或连续两期无恢复方案。 |
| 技术 / 集成 | 高风险验证完成率、接口稳定、端到端冒烟和性能余量。 | 核心指标无余量、接口频繁破坏或集成不可重复。 |
| 质量 / 合规 | 需求覆盖、严重缺陷、可靠性、认证与 CAPA 关闭。 | 安全/法规问题、严重缺陷未关闭或验证配置不一致。 |
| 供应 / 生产 | 物料齐套、替代料、良率、节拍、产测和追溯。 | 单一关键料中断、良率/节拍不达标或版本混料。 |
| 商业 / 上市 | 目标成本、单位经济、渠道/服务准备和首批客户。 | 成本失控、上市承诺无交付能力或服务能力未就绪。 |
周报只写红黄绿也不够：每个黄/红项必须带事实、影响、Owner、恢复计划、所需决策和下次验证时间。
| 领域 | 需要形成的基线 | 必须验证 |
|---|---|---|
| 佩戴 / 人因 | 尺寸、重量、重心、接触材料、热感、操作和日常场景。 | 多体型/长时佩戴、运动、汗液、皮肤接触和误触。 |
| 传感 / 数据 | 传感器、采样、时间同步、校准、数据质量与缺失处理。 | 真实人群/环境、漂移、噪声、偏差与可追溯。 |
| AI 能力 | 模型/提示、端云分工、版本、输入输出、置信与失败兜底。 | 准确/任务成功、延迟、鲁棒、公平、安全和不可用场景。 |
| 功耗 / 热 | 用例功耗预算、唤醒、无线、推理、充电与热策略。 | 典型/最差用例、老化电池、环境温度和表面温升。 |
| 隐私 / 安全 | 采集提示、同意、最小化、端云加密、权限、保留和删除。 | 旁观者、丢失设备、账号接管、日志脱敏和数据生命周期。 |
| 服务连续性 | 离线能力、云/模型不可用、订阅、地区和 EOL 承诺。 | 断网/限流、降级、恢复、迁移和产品失去云服务后的行为。 |
| 维度 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 价值 / 范围 | 只有功能清单。 | 有场景和目标。 | 有证据、产品包、边界与 Go/Stop。 |
| 系统 / 接口 | 只画硬件或 App。 | 列出多端。 | 端到端状态、接口、版本和 Owner 完整。 |
| 计划 / 冻结 | 只有日期。 | 有阶段节点。 | 有交付物、退出证据、依赖、基线与决策者。 |
| 验证 / AI | 只验功能。 | 有部分指标。 | 覆盖体验、AI、功耗、热、可靠性、隐私和生产。 |
| 变更 / 风险 | 没有机制。 | 有风险清单。 | 有 RAID、ECR/ECN、触发阈值、回退和关闭证据。 |
| 量产 / 生命周期 | 止于研发完成。 | 提到量产。 | 覆盖追溯、发布、售后、现场质量、迭代与 EOL。 |
模块已完成 7 / 7。七篇均已逐篇精读并形成独立总结；另完成 0→1 知识树、里程碑与冻结点地图、阶段门决策卡、十份项目资产、健康仪表盘、可穿戴 AI 特殊冻结项、实战作业与自评标准。
把“做出样机”推进到“能够稳定交付”：用验证计划证明产品符合需求，用供应链与成本模型约束商业可行性，用生产测试、质量控制和量产爬坡保证批量一致性。
本模块最终形成一套“稳定交付 + 可持续经营”的闭环：先把产品承诺转成验证证据，再把风险前移到 DFT、供应商与料号准入；用 PVT/MRR 证明批量复制能力，用追溯和良率数据推动爬坡；最后用全生命周期成本、渠道净收入和用户价值共同确定价格，而不是让样机成功、最低报价或 BOM 加成替代经营判断。
原文指出，无论产品来自自研、外包定制还是外部引入，都要通过测试证明应用实现符合规划、质量符合设计要求、真实环境使用符合业务需要；规划上覆盖功能、性能、可靠性和政策/准入标准，并在不同成熟阶段持续加深。
| 目标 | 核心问题 | 典型证据 |
|---|---|---|
| 符合规划 | 功能、流程、状态、数据和跨端行为是否实现产品定义？ | 需求—用例追踪、功能/接口/状态测试与差异记录。 |
| 符合设计与质量 | 性能、可靠性、安全、寿命和一致性是否达到工程规格？ | 实验室数据、可靠性/安规报告、失效分析和质量指标。 |
| 符合真实业务 | 目标用户在目标环境与流程中能否稳定获得预期结果？ | 场景验证、试运行、用户行为、业务验收和现场问题。 |
验证“做对了产品”和验证“把产品做对了”不能互相替代。前者偏用户与业务确认，后者偏规格符合和工程验证。
| 类型 | 覆盖内容 | PM 关注点 |
|---|---|---|
| 功能 | 功能、流程、状态、显示、数据、接口、异常和恢复。 | 用户场景是否完整；正向、反向、边界和跨端状态是否覆盖。 |
| 性能 | 功耗/续航、充电、精度、延迟、吞吐、并发、射频和抗干扰。 | 指标来自何处；典型与最差场景；与竞品/体验目标的余量。 |
| 可靠性 / 安全 | 温湿度、跌落、振动、防护、寿命、ESD、电源冲击和材料环境。 | 任务剖面、失效模式、样本与统计口径是否支持产品承诺。 |
| 法规 / 准入 | 安规、EMC/射频、环保、计量、行业和地区市场准入。 | 适用法规、版本/样机一致性、实验室计划、整改与证书有效范围。 |
| 阶段 | 主要目的 | 测试重点 | 准出证据 |
|---|---|---|---|
| 样板 / DEMO | 关键技术与电路是否可行。 | 板级电气、器件、核心性能、射频/功耗和技术风险。 | 关键假设有数据；致命方案风险关闭或有明确路径。 |
| 样机 | 结构与软硬件合体后是否满足核心体验。 | 静态功能、性能、初步可靠性、跨端集成和用户使用。 | 核心场景跑通；主要问题可收敛；配置支持系统验证。 |
| 测试机 | 接近正式设计是否满足完整规格和法规。 | 全量功能/性能、可靠性、认证预检/送检和大样本回归。 | 需求可追踪；严重缺陷关闭；达到试产准入。 |
| 试产 / 试运行 | 生产和真实业务是否能稳定复制。 | 工艺、产测、良率/节拍、入库出货、现场使用和业务验收。 | 生产与现场风险可控；发布条件、遗留项和责任明确。 |
原文使用“样板—样机—测试机—试产”命名，企业也可能采用 Proto、EVT、DVT、PVT。应以配置、验证目标和退出标准对齐，而不是只对齐名称。
原文以 PCBA 外发漏做 AOI、整机未老化、工装依赖人工导致漏检为反例，说明测试设计不能等量产再补：PCB 测试点、烧录接口、夹具机械定位、自动化程序、操作界面和备份治具都要提前纳入设计。
| 环节 | 主要发现 | 不能替代 |
|---|---|---|
| 裸板电测 | 开短路、网络连通和板厂制造缺陷。 | 不能证明元件贴装和功能正确。 |
| AOI | 元件缺失/偏移/极性、可见焊点和外观缺陷。 | 不能充分看到 BGA 底部，也不能证明电气性能。 |
| X-Ray | BGA/QFN 等隐藏焊点、空洞、桥连和焊接异常。 | 不能证明软件、功能和长期可靠性。 |
| ICT / 飞针 | 网络、电阻电容、电源和部分器件装配值。 | 不能覆盖完整用户功能和整机环境。 |
| FCT 板级功能 | 供电、控制器、信号、传感、通信和接口功能。 | 不能替代结构装配后的整机终测。 |
| 整机终测 / 老化 | 跨模块功能、装配、间歇问题、早期失效与出厂配置。 | 不能补救前序质量失控；只能作为最后拦截。 |
| 设计维度 | 验收问题 |
|---|---|
| 机械重复性 | 定位、防呆、压合、探针行程和寿命是否保证每次接触一致？ |
| 电气与安全 | 供电、负载、隔离、过流/反接、ESD 和操作员防护是否可靠？ |
| 软件 / 界面 | 一键执行、步骤锁定、错误码、权限、版本和结果保存是否清晰？ |
| 测量能力 | 治具/仪器精度、重复性与再现性是否足以区分合格与不合格？ |
| 节拍 / 产能 | 单机时间、并行工位、换型、重测率和操作动作是否匹配产能？ |
| 运维 / 备份 | 黄金样点检、校准、探针更换、备件/备机和版本兼容是否到位？ |
原文把生产测试与研发阶段的设计验证区分开来：产测关注加工、装配、器件和过程波动是否让单台产品偏离设计，并以缺陷发生概率和流出后果决定投入。测试越靠近缺陷产生工序，定位与返修成本通常越低。
| 手段 | 核心目的 | 典型发现 | 主要边界 |
|---|---|---|---|
| ICT / 飞针 | 确认 PCBA 的网络与元件装配基础正确。 | 开短路、错值/反向、部分器件失效；也可承担烧录、校准。 | 依赖测试点与可达性，难覆盖完整软件、系统交互和真实负载。 |
| FCT | 在接近工作状态下确认板级或子系统功能。 | 处理器、存储、接口、传感、通信、控制输出与整合故障。 | 覆盖取决于测试固件、夹具和判定算法，不能证明长期寿命。 |
| 整机终测 | 确认装配完成后的用户可见功能与出厂配置。 | 跨板连接、结构装配、按钮/灯屏、无线、声学和配置问题。 | 越晚发现返修越贵，不能替代前序过程控制。 |
| 老化 / ESS | 通过温度、通电、循环或振动等应力暴露早期潜伏失效。 | 虚焊、边缘器件、间歇故障、热相关和装配应力问题。 | 过筛会损耗寿命并抬高成本；条件必须低于损伤合格品的界限。 |
每个工位都要定义输入配置、测试覆盖、量测阈值、节拍、误判/漏判、返修路径和准出规则。测试站通过并不等于“质量绝对合格”，而是该站已覆盖的风险获得了证据。
| 数据组 | 至少记录 | 用途 |
|---|---|---|
| 产品身份 | SN、物料编码、BOM/硬件版本、生产批次和关键器件批次。 | 确定问题影响范围，支持隔离、返工与召回。 |
| 制造上下文 | 线体/工位、时间、操作员、设备/治具编号、环境和班次。 | 识别工位、设备、人员和环境相关波动。 |
| 测试配置 | 测试程序、固件、限值版本、仪器与校准状态、黄金样结果。 | 保证结果可复现，避免版本变化制造“假改善”。 |
| 原始结果 | 关键量测值、日志、步骤结果、总判定、错误码和耗时。 | 分析趋势、过程能力、临界漂移、误判与漏检。 |
| 缺陷闭环 | 缺陷代码、失效分析、返修动作、复测结果、报废/放行审批。 | 从“测出问题”升级到根因消除与持续改进。 |
原文从硬实力、软实力、信条品格、同类经验和适配度五方面展开。真正有价值的判断不是“厂有多大、设备有多少”，而是它是否具备本项目所需的工艺和检测能力，管理体系能否让人按标准稳定执行，并能以诚信、审慎、守约的方式长期协作。
这一步把“找一个好供应商”改写成“找一个能补齐本项目约束的供应商”，也是后续 RFI/RFQ、审厂问题和评分权重的来源。
| 维度 | 建议权重 | 关键证据 |
|---|---|---|
| 质量体系与制程控制 | 25% | 体系证书范围、IQC/IPQC/OQC、SOP、追溯、计量、NCR/CAPA、真实质量趋势。 |
| 技术与同类经验 | 20% | 难点相似案例、关键人员、DFM/DFT 能力、失效分析和问题复盘。 |
| 制造与检测能力 | 15% | 工艺/设备匹配、设备状态、治具、自动化、过程能力与测量系统能力。 |
| 产能、交付与韧性 | 15% | 负荷/瓶颈、峰值产能、交付记录、关键物料、外协、备份产线与灾备。 |
| 成本与商务透明度 | 10% | BOM/加工/NRE/损耗拆分、MOQ、付款、降本规则、库存与售后责任。 |
| 项目协同与变更 | 10% | 响应、项目组织、承诺达成、版本/ECN、问题升级和跨部门协调。 |
| 合规、诚信与经营风险 | 5% | 廉洁、知识产权、数据安全、劳工环保、诉讼、财务和客户集中度。 |
权重是起点而非固定答案：医疗/安全产品应提高质量与合规，创新原型提高技术协同，成熟大货提高产能、成本与韧性。评分用于相对比较，不能覆盖红线。
| 红线类别 | 典型信号 | 建议动作 |
|---|---|---|
| 质量 / 安全造假 | 伪造检测、校准、认证或批次记录，隐瞒重大缺陷。 | 停止准入并升级质量/法务调查。 |
| 未经批准变更 | 私换料、换工艺、转外协、改程序或混批。 | 冻结出货、隔离影响批次，执行变更与再验证。 |
| 廉洁与利益冲突 | 回扣、私下利益、围标或不透明关联关系。 | 按公司合规流程报告，不以高评分抵消。 |
| 知识产权 / 数据风险 | 方案复制、图纸外泄、权限失控或来源不明物料。 | 限制资料、审查合同和权限，必要时淘汰。 |
| 经营连续性不可接受 | 现金流恶化、单一设备/客户/外协依赖且无恢复计划。 | 设置替代源、库存/产能保护或不予准入。 |
原文提出技术能力、供应商实力和合作内容三层判断：芯片/模组的存储、接口与 SDK 必须满足业务，供应商要有可持续供货与技术支持能力，最后再谈价格、交期、付款、质保、产能和紧缺时的保障。可进一步沉淀为独立的“料号资格认定”流程。
| 维度 | 需要定义 | 验证证据 |
|---|---|---|
| 算力与存储 | 峰值/持续算力、RAM/Flash、外存、带宽、启动与 OTA 双分区余量。 | 目标模型和完整软件栈的峰值内存、时延、热降频与压力测试。 |
| 接口与电气 | GPIO/ADC/PWM/UART/I²C/SPI/USB/音视频/调试口，电压域与复用。 | 原理图引脚分配、参考板实测、边界时序和外围兼容性。 |
| 功耗与热 | 各工作态/休眠态、唤醒、无线与 AI 负载的功耗和结温。 | 任务剖面电流曲线、温升/降频、续航模型和极端环境测试。 |
| 软件生态 | OS/BSP/驱动、SDK/API、模型工具链、OTA、安全和许可证。 | 源码/文档评审、Demo 复现、版本路线图、缺陷修复 SLA。 |
| 质量与合规 | 器件等级、可靠性、认证支持、可追溯性与失效率。 | 规格/质量报告、认证资料、PCN 记录、批次样品与失效分析能力。 |
| 供应生命周期 | 量产时间、产地/封测、交期、MOQ、产能、EOL/LTB 与第二来源。 | 书面供货计划、生命周期承诺、分配机制、替代路线和库存策略。 |
“Demo 跑起来”只证明参考配置可运行；量产资格必须由目标业务、目标板卡、目标环境和发布版本共同证明。
原文把量产风险归纳为合作伙伴不匹配、报价/付款不透明、需求与方案变更、模具和物料延期、来料与出货交接失控。共性原因是多方协作跨时很长，却缺少明确配置、责任、证据和变更约束。解决办法不是“盯得更紧”，而是建立可执行的准备度评审。
| 准出门 | 必须回答 | 最低证据 |
|---|---|---|
| 产品配置 | 将生产哪一个确定版本？还有哪些未冻结项？ | 签署的规格、图纸、BOM、色板、软固件和包装基线。 |
| 设计验证 | 规格、可靠性、安全、认证与核心场景是否通过？ | 追踪矩阵、DVT/认证报告、偏差与残余风险批准。 |
| 物料 / 供应 | 关键料是否认定、齐套、可追溯且有中断预案？ | AVL、料号认定、齐套表、长交期清单与第二来源计划。 |
| 工艺 / 产线 | 每一步能否按节拍稳定执行和防错？ | 流程图、SOP、工装、人员培训、PFMEA 与控制计划。 |
| 测试 / 质量 | 缺陷能否在流出前可靠发现、定位与追溯？ | 测试覆盖、GR&R/校准、限值、黄金样、检验与追溯方案。 |
| 试产结果 | PVT 是否证明良率、节拍、返修和过程能力可接受？ | FPY/RTY、缺陷 Pareto、Cpk、工时、停线与 CAPA 关闭。 |
| 交付 / 售后 | 包装物流、仓储验收和现场故障闭环是否就绪？ | 包装验证、OBA、箱唛/清单、RMA/FA、备件与服务流程。 |
| 商业 / 责任 | 成本、订单、付款、质保、损失和变更责任是否明确？ | 核准报价/PO、质量协议、SLA、变更条款与签字权限。 |
MRR 的结论应是通过、条件通过或不通过。条件通过必须写清数量上限、偏差期限、监控措施和停止放量的触发条件。
| 指标 | 定义 / 用途 | 异常时追问 |
|---|---|---|
| FPY / RTY | 工位一次通过率 / 全流程滚动一次通过率，观察真实制造能力。 | 哪一工位、料号、班次和失效模式贡献最大？ |
| 返修 / 报废 / 重测 | 揭示隐藏成本和“靠返工做出货”的风险。 | 根因是否关闭？重测是否掩盖接触或限值问题？ |
| 节拍 / UPH / OEE | 判断瓶颈、设备可用率和目标产能是否真实。 | 等待、换线、故障、缺料还是测试时间过长？ |
| 缺陷 Pareto | 按数量与严重度聚焦首要失效模式。 | 设计、物料、制程、测试还是操作问题？ |
| Cpk / 趋势 | 对关键连续参数判断居中与波动，而非只看 Pass/Fail。 | 量测系统是否可信？过程是否稳定后才计算能力？ |
| 齐套 / WIP / 交付 | 识别欠料、堆积、在制品和承诺交付风险。 | 关键料何时到？是否影响配置、节拍或批次完整性？ |
原文用 BOM、BOM 外投入、渠道成本和利润解释为何“物料相加”不能推导产品售价，并提醒关注第三方授权、云资源、生产检测、换线、研发、认证、ID、模具、打样和试产。更严谨的实践是建立统一成本字典和逐级成本瀑布。
| 成本层 | 典型项目 | 回答的问题 |
|---|---|---|
| Material BOM | 电子、结构、光学/声学、电池、配件、包装和随箱文档。 | 组成一台产品的直接物料是多少钱？ |
| 制造转换成本 | SMT、组装、烧录、校准、测试、包装、工装摊销和工厂损耗。 | 把物料变成可出货成品要花多少钱？ |
| 出厂 COGS | BOM + 转换 + 按台授权/专利 + 正常报废返工与工厂管理分摊。 | 工厂交付一台合格品的可归属成本是多少？ |
| Landed cost | COGS + 头程物流、保险、关税、清关、入仓和必要本地化。 | 产品到达目标市场仓库的成本是多少？ |
| 服务后成本 | 云/流量、支付、质保准备、退货、维修、翻新、客服和逆向物流。 | 产品卖出并履约后，整个生命周期还要承担什么？ |
| 渠道 / 获客 | 平台佣金、经销折扣、仓配、促销、广告和销售激励。 | 从标价到公司净收入，中间被哪些环节拿走？ |
| 一次性投入 | 研发、ID、模具、认证、NRE、打样、试产与上市准备。 | 项目要先投入多少，以及多少销量能回收？ |
每个假设要标记来源、责任人、版本、更新时间和置信区间。做 Base / Upside / Downside 三套场景，比单一“精准数字”更适合早期决策。
原文提出两条定价路径：自上而下从用户购买动因、市场定位和替代品价格判断愿付区间；自下而上从完整成本、渠道与目标毛利倒推可生存的售价。二者不是二选一，而是共同构成“市场愿意付、企业值得做”的价格走廊。
| 边界 | 如何得到 | 关键输出 |
|---|---|---|
| 经济底线 | 按渠道倒推净收入，覆盖 landed COGS、服务/质保和变动费用，并达到目标贡献毛利。 | 各渠道最低可接受成交价、促销红线和回本销量。 |
| 竞争参照 | 比较相同用户任务的硬件、服务、人工方案和“不解决”的成本，而非只看同类外形。 | 参考价格带、可替代性、差异化理由和预期销量。 |
| 价值上限 | 量化节省时间/金钱、降低风险、提升效果与情感价值，并用真实购买行为校准。 | 目标客群愿付区间、价格敏感度和价值证据。 |
| 战略选择 | 结合品牌定位、进入策略、现金流、渠道、竞争反应和产品组合选择落点。 | MSRP、首发/常规成交价、折扣纪律和调价触发器。 |
若区间不存在，正确动作是调整价值、成本、渠道、功能范围或商业模式，而不是强行发布。
每个渠道单独建模。线上直营、平台、经销、运营商捆绑和企业项目的标价、账期、退货与服务责任不同，不能共用一条毛利率。
| 方法 | 能回答 | 防误判要点 |
|---|---|---|
| 概念 / 原型访谈 | 价值语言、使用情境、替代品和支付顾虑。 | 不把口头愿付价当真实需求，展示接近量产的体验与限制。 |
| Van Westendorp / Gabor-Granger | 感知贵/便宜边界和不同价格下的购买意向。 | 样本需匹配目标客群，结果用于形成假设而非直接定价。 |
| 落地页 / 广告测试 | 不同定位、版本与价格的点击、留资或预订倾向。 | 价格之外的页面差异要受控，并明确是否可购买。 |
| 可退款订金 / 预售 | 更接近真实的支付意愿和版本选择。 | 交付时间、退款、风险披露和适用法规必须清晰。 |
| 小批 Beta / 渠道询价 | 成交、退货、使用留存、服务成本和渠道毛利。 | 早期用户不代表大众市场，要结合扩量后的成本和需求曲线。 |
| 能力主干 | 我现在能产出的文档 | 决策问题 |
|---|---|---|
| 验证与质量 | 需求—测试追踪、验证矩阵、测试用例、缺陷/残余风险与放行报告。 | 产品承诺是否被可信证据证明？ |
| DFT 与生产测试 | 测试点/接口需求、ICT/FCT/EOL/ESS 架构、治具 URS 与追溯字段。 | 每一台产品如何低成本地防止缺陷流出？ |
| 供应商与料号 | 供应商需求书、审厂清单/评分卡、料号资格矩阵、质量/供货协议。 | 谁能稳定做？具体哪个方案能长期供？ |
| 试产与量产 | PFMEA/控制计划接口、PVT 计划、MRR 清单、爬坡看板与 ECN 流程。 | 这套设计和制程能否按节拍稳定复制？ |
| 成本与定价 | 成本字典/瀑布、渠道净收入、单位经济、价格走廊和版本/订阅模型。 | 每卖一台是否创造贡献，用户为何愿意付这个价？ |
| 交付与反馈 | OBA/出货标准、装箱交接、RMA/FA、批次追溯与质量复盘。 | 现场问题能否快速圈定、纠正并反哺下一批？ |
核心不是把测试做得越多越好，而是让每项关键风险都有预防、检测、追溯、责任与反馈，并把现场损失折回产品和经营决策。
| 周期 | 任务 | 成果物 |
|---|---|---|
| 第 1 周 · 证据 | 选 AI 耳机 / 手环 / 眼镜之一，定义 5 个核心承诺、5 个高风险失效和阶段验证。 | 需求—风险—测试追踪表；功能/性能/可靠性/法规矩阵。 |
| 第 2 周 · 供应 | 拆 3 个技术难点，比较 2 家供应商与 2 个核心料号，设计审厂取证和样品实测。 | 供应商评分卡；料号资格矩阵；技术/质量/交付红线。 |
| 第 3 周 · 量产 | 从 PCBA 到整机画产测流程，设计 SN 数据，模拟 300 台 PVT 与缺陷 Pareto。 | ICT/FCT/EOL 方案；MRR 清单；良率/节拍/缺陷看板。 |
| 第 4 周 · 经营 | 建立三种销量、两个渠道、硬件 + AI 服务的成本/价格情景并作出 Go/No-Go。 | 成本瀑布；单位经济；价格走廊；版本/订阅与回本分析。 |
模块 07 已完成 8 / 8。最终成果覆盖验证、产测、供应商与料号准入、PVT/MRR、量产爬坡、出货追溯、全生命周期成本、单位经济和价值定价。
把产品价值、利润模型、上市策略和迭代闭环连起来：从战略洞察到盈利模式设计，从成功要素拆解到失败复盘，让产品不仅做得出来，还能卖得出去、持续迭代。
硬件产品的成功，不只是技术和体验的胜利，更是商业逻辑的胜利。战略决定方向，盈利模式决定活法，数据驱动决定迭代效率，而复盘则是避免重复踩坑的唯一方式。
原文以互联网+医疗健康为例，提出智能硬件产品规划的两种方法论：广度优先遍历（全场景覆盖）与深度优先遍历（单点深挖），核心是把硬件嵌入用户业务流，而不是为了智能而智能。
原文以教育硬件「网课学习机」为例，拆解企业战略规划的四大步骤：市场洞察与产品定义、企业定位、经营策略、商业模式。战略不是口号，而是回答"做什么"和"怎么做"的决策框架。
| 判断维度 | 要回答的问题 | 决策依据 |
|---|---|---|
| 需求成熟度 | 网课是否到了需要专属设备的阶段？是短期风口还是长期刚需？ | 趋势数据、政策风险、用户付费意愿、竞品验证。 |
| 市场规模 | 目标人群有多大？付费转化率预期多少？ | 人口基数、渗透率、客单价、复购率测算。 |
| 竞争优势 | 为什么我能做？与大厂是互补还是竞争？ | 资源能力矩阵、渠道关系、技术壁垒、品牌认知。 |
| 政策风险 | 行业监管方向如何？是否会影响需求存续？ | 政策文件、合规要求、行业整顿历史。 |
| 现金流支撑 | 第二曲线孵化需要多少投入？第一曲线能否输血？ | 财务模型、融资能力、盈亏平衡点测算。 |
原文系统梳理了智能硬件的8种盈利模式：硬件销售、内容、服务、配件、耗材、广告、数据、混合。核心启示是——硬件的边际成本不为零，单靠硬件差价难以持续，必须构建多层收入结构。
| 模式 | 适用场景 | 关键成功要素 | 主要风险 |
|---|---|---|---|
| 硬件销售 | 品牌力强、供应链成熟、规模效应显著 | 品牌溢价、成本控制、渠道覆盖 | 价格战、库存积压、技术迭代 |
| 内容/服务 | 用户粘性高、内容/服务可持续更新 | 内容质量、付费转化、留存率 | 内容成本、版权风险、用户流失 |
| 配件/耗材 | 主产品市占率高、配件不可替代 | 绑定强度、配件多样性、复购率 | 第三方替代、兼容破解 |
| 数据变现 | 用户量大、数据维度丰富、合规可行 | 数据规模、分析能力、合作生态 | 隐私合规、数据安全、用户信任 |
| 混合模式 | 多数智能硬件的长期目标 | 各收入层协同、用户价值最大化 | 模式复杂、资源分散、执行难度 |
原文从产品经理与消费者双视角，提炼影响硬件产品成功的8个关键因素：平台、品牌、目标市场、需求与功能、直观感受、售价、差异化创新、宣传与营销。产品成功是系统工程，不是单点突破。
原文从用户和企业双主体诉求出发，提出"好"硬件产品的四个核心评价要素：好看（工业设计）、好用（用户体验）、好维护（可修复可升级）、好加工（成本可控）。四要素的平衡是产品经理的核心能力。
好看、好用是用户侧评价；好维护、好加工是企业侧评价。产品经理要在设计、成本、体验之间持续做取舍。
原文提出硬件产品日活月活的双维度统计：设备激活量（反映真实卖到用户手中的数量）和固件活跃量（反映产品工作状态和软件迭代效果）。对销售渠道长的硬件产品，激活数据比渠道销量更真实。
| 数据维度 | 反映什么 | 应用场景 |
|---|---|---|
| 设备激活量 | 真实卖到用户手中的数量 | 辅助生产备料、渠道健康分析、淡旺季判断、促销效果评估、新品潜力判断 |
| 固件活跃量 | 产品工作状态和软件迭代效果 | 发现升级推送问题、及时发现平台故障、按激活量支付第三方费用 |
渠道健康因子可粗略估算渠道库存销售周期，结合运输周期和周转周期判断库存是否合理。
原文从Keep的内忧外患分析其必须做智能硬件的必然性：用户增长瓶颈、存量活跃度下降、变现能力不足、手机无法覆盖运动场景、竞品硬件布局、科技化转型需求。硬件不是可选项，是战略必选项。
原文详细复盘了智能体温计从0到1的全过程：从创始人痛点出发，团队4人+50万启动资金，经历概念、设计研发、运营三阶段，最终因成本失控、资质缺失、备货过多而未能成功。
| 阶段 | 关键决策 | 踩过的坑 |
|---|---|---|
| 概念阶段 | 定位200元以内、有屏可独立使用、替代水银体温计 | 工程师采用外围合作模式，后期绑定利益期望，埋下协作隐患 |
| 设计研发 | 从10款设计选2款打板，最终确定一款 | BOM成本从80元飙到110元；售价从200元提到498元；未提前办理二类医疗器械资质 |
| 运营阶段 | 研发团队奔赴一线销售，坚守不刷单底线 | 错过销售热点和融资窗口；产品单一、复购率低；无法进入医院渠道 |
原文复盘了一个智能行车记录仪创业项目的失败经历：从蓝海判断到产品开发，从尴尬销量到两年苦撑，最终因公司层面（营销、人员、沟通）和执行层面（目标感、产品力、营销力）的多重问题而解散。
| 维度 | 体温计项目 | 行车记录仪项目 | 共同教训 |
|---|---|---|---|
| 成本 | BOM失控，售价翻倍 | 低价竞争，利润空间薄 | 成本是硬件的生命线，必须在定义阶段死磕 |
| 备货 | 1万台库存压死现金流 | 销量惨淡，库存周转慢 | 销量未验证前，小批量快跑，忌赌库存 |
| 营销 | 无资金做推广，靠电商平台 | 无系统营销计划，被动推广 | 硬件创业必须预留营销预算，酒香也怕巷子深 |
| 场景 | 目标群体过窄 | 忽略核心场景（安全感） | 必须回归用户真实场景，验证需求规模 |
| 团队 | 外围合作工程师，协作隐患 | 软硬件目标不一致，人员混乱 | 团队目标必须对齐，核心岗位不能将就 |
| 合规 | 未提前办理医疗器械资质 | 入门门槛低，但竞争门槛高 | 行业特殊要求必须前置调研，合规是底线 |