启动智能硬件项目前，先准备好这份需求清单
从目标用户、使用流程到结构约束和交付成果，整理首次项目沟通最值得准备的信息，减少模糊需求带来的反复。
“想做一款有体感互动的产品”是一个可以开始讨论的方向，但还不足以直接进入开发。不同使用场景会影响传感方案、结构设计、交互方式与交付计划。首次沟通不需要准备几十页文档，只要能把关键问题讲具体，就能帮助团队判断哪些已经确定、哪些需要先验证。
用一段话描述一次真实使用
先说明谁在什么环境下使用、为什么开始、希望完成什么，以及怎样结束。比如“用户在手机上选择互动内容，设备在开始前完成准备，过程中根据输入给出响应，结束后可以查看本次记录”。这类描述比单独列出蓝牙、传感器、马达等器件更有利于明确产品边界。
把确定项与待验证项分开
已有结构尺寸、接口位置、材料和现成样机，可以作为已知约束。还没有证据支持的体验目标，例如希望隔着某种外壳识别输入，就应列为待验证问题。不要把尚未测试的想法写成已经确认的性能；可以先安排小范围验证，再决定是否进入完整开发。
| 信息 | 建议准备的内容 |
|---|---|
| 目标与用户 | 产品解决的问题、使用人群、主要场景 |
| 核心流程 | 开始、输入、反馈、暂停、结束与异常路径 |
| 现有资源 | 外观草图、结构文件、样机、已有软件与接口资料 |
| 约束条件 | 尺寸、供电、接触材料、通信与离线使用要求 |
| 交付预期 | 功能样机、工程样机、生产资料或长期维护范围 |
| 项目节奏 | 期望节点、已确定事项、允许先验证的问题 |
优先确认最容易返工的决定
感知方式、受力结构、供电布局与核心交互会互相影响。首次讨论应找出最可能影响整体方向的未知项，为它们约定验证方法和决策时间。外观、固件、App 不一定必须完全串行推进，但跨团队依赖需要明确，否则一个尺寸变化就可能让多方同时返工。
把“完成”写成能检查的结果
如果目标是功能样机，应说明需要演示的完整流程与允许保留的问题；如果目标是生产交付，应补充文件、测试、追溯与维护要求。验收时尽量使用预先约定的场景与记录，避免到了交付当天才发现双方对“支持某功能”的理解不同。
- 至少画出一条主流程和一条异常流程。
- 为关键功能写清输入条件、预期结果和验证方式。
- 把首版必须具备的功能与后续可选功能分开。
- 给尚未确定的问题安排负责人和下一次决策节点。
需求清单的价值不是一次写完后永远不变，而是让每次调整都能看清原因与影响。项目推进中，定期回看清单，把验证结果、已作决定和仍待确认的事项补充进去，团队就能在同一份事实基础上协作。