产品经理说"加个自动湿度功能"，你脑子里闪过十几个问题——传感器多久采一次？PID 还是滞环？断网了怎么办？目标值存哪？这些问题不落到纸上，AI 帮你写出来的代码大概率是错的。做开发的都知道，产品给的 PRD 和工程师实际要做的事之间有一道鸿沟。PRD 写的是："设备支持自动湿度模式，用户设置目标湿度后，设备根据环境湿度自动调节雾量大小。" 一句话，干净利落。- 湿度传感器的采样周期多少？太快浪费 CPU，太慢响应迟钝
- "自动调节雾量"——硬件支持几档？连续调还是分档？
- 云端要同步哪些状态？APP 端怎么显示当前是自动模式？
这些问题如果不在写代码之前理清楚，让 AI 帮你实现"自动湿度功能"，它大概率会给你一个能编译通过但逻辑漏洞百出的版本。改三轮就烦了。所以核心矛盾是：PRD 说的是"用户要什么"，工程师要回答的是"系统怎么做"。这个翻译过程，才是 AI 真正能帮上忙的地方。一个可行的做法是把这个翻译过程拆成一条明确的链路，每一步都让 AI 先出初稿、人来审核：每个箭头之间，人做审核和决策，AI 做初稿和防遗漏。不是让 AI 替你想，而是让它帮你把想的过程摊开来。下面会用"智能加湿器新增自动湿度模式"这个虚构但贴近真实的案例，把每一步走一遍。在讲 AI 怎么提取需求之前，先聊一个现实问题：产品给的 PRD 格式五花八门。- Excel 表格是最常见的。产品在 Excel 里列需求列表，每行一个功能点，列包括"功能名称/描述/优先级/备注"。好处是结构清晰，坏处是缺乏上下文。你只看到一行"支持自动湿度模式"，但不知道跟其他功能的关联关系。
- Word 文档用来写详细描述。通常包含背景、用户故事、交互流程、异常处理等。信息量大，但格式不统一，段落之间的逻辑关系要人肉理解。
- Axure 原型定义 UI 交互。哪个页面有哪些按钮、状态怎么切换、提示语怎么显示，都在原型里。对前端和 APP 开发很直观，但固件工程师关心的"底层逻辑"往往藏在交互细节里（比如"切换模式时先关旧的再开新的"这种时序约束，可能只能从原型的页面跳转顺序里推断出来）。
- Figma 设计稿越来越多团队在用。跟 Axure 相比，Figma 多了一层信息：组件变体（Variants）。一个按钮组件可能有 default / active / disabled 三个变体，这直接对应设备的状态枚举。Prototype 模式下的页面连线则定义了状态转换逻辑。这些信息比 PRD 文字更精确，但容易被当成"只给前端看的东西"而忽略。
AI 吃的是文本，要利用 AI 的能力，第一步是把各种格式"拍平"成它能理解的输入。这一步很关键，喂得好，后面的需求提取和技术拆解能省一半力气；喂得差，AI 会从一开始就跑偏。Excel 是最常见的 PRD 载体，但直接丢给 AI 有几个坑：坑一：合并单元格。 产品经理喜欢合并单元格做分组，但导出 CSV 后合并信息就丢了，AI 会把空单元格理解为"无内容"。解决办法：导出前先取消合并、填充空白格。坑二：多 Sheet 交叉引用。 "功能列表"在 Sheet1，"交互说明"在 Sheet2，"接口定义"在 Sheet3，它们之间用编号关联。直接导出单个 Sheet，AI 看不到关联关系。解决办法：把相关 Sheet 合并成一段文字，用编号把它们串起来。坑三：表格太宽。 一行 15 个列，从"功能编号"到"测试用例"全在里面。AI 不需要全部列。只保留跟固件开发相关的列：功能名称、描述、优先级、交互说明、约束条件。"市场背景"、"竞品对比"、"UI 标注"这些列删掉。1. 取消所有合并单元格，用"填充空白格"补全2. 只保留关键列：功能编号 | 功能名称 | 描述 | 优先级 | 交互说明 | 约束/备注3. 如果有多个 Sheet，按编号合并到一个文本里4. 导出为 CSV 或直接复制粘贴（Cursor/ChatGPT 都能识别制表符表格）
转换前（Excel 原始内容，5 个 Sheet 共 80 行）：Sheet1-功能列表:F-012 | 自动湿度模式 | 高 | 见 Sheet2 交互说明 #012F-013 | 睡眠模式 | 高 | 见 Sheet2 交互说明 #013Sheet2-交互说明:#012: 用户在 APP 设置目标湿度(40~80%, 步进5%)，设备自动调节...#013: 一键开启睡眠模式，降低雾量+关闭灯光+降低噪音...Sheet3-约束:C-012-1: 与睡眠模式互斥C-012-2: 目标湿度掉电保持
## F-012 自动湿度模式（优先级：高）- 描述：用户在 APP 设置目标湿度(40~80%, 步进5%)，设备自动调节雾量(1~3档)- 交互：达到目标湿度后停止出雾，低于目标时恢复；手动调节雾量则退出自动模式- 约束：与睡眠模式(F-013)互斥；目标湿度掉电保持- APP 显示：当前湿度、目标湿度、当前模式## F-013 睡眠模式（优先级：高）- 描述：一键开启，降低雾量+关闭灯光+降低噪音- 约束：与自动湿度模式(F-012)互斥
区别在哪？每个功能点的描述、交互、约束都聚合在一起了，不用在多个 Sheet 之间跳转。AI 一眼就能看到"F-012 和 F-013 互斥"这个关键约束。（2）处理 Word
Word 文档的问题不是格式，是信息噪音太多。一份 20 页的 PRD，前 5 页是市场背景和竞品分析，中间 8 页是功能描述，后面 7 页是排期和审批记录。固件工程师只需要中间那 8 页。操作建议：
1. 只提取这些章节：功能描述、交互流程、业务规则/约束、接口定义（如有）2. 删掉：市场背景、竞品分析、排期计划、审批记录、UI 视觉规范3. Word 里的嵌入表格和流程图：表格复制为文本，流程图截图备用4. 如果文档超过 3000 字，按功能模块拆分，每次只喂一个模块
有一种情况要特别注意：Word 里的"自然语言描述"经常有歧义。比如"设备自动调节雾量大小"，其中"大小"是指档位（离散值）还是具体数值（连续量）？这种歧义在 Excel 里不太会出现（因为表格强制你写具体），但在 Word 里很常见。遇到这种情况，在喂给 AI 之前先人工标注歧义点，或者在提示词里让 AI 把不确定的地方列出来。
（3）处理 Axure 原型
Axure 原型里藏着大量"隐性需求"，即页面跳转顺序暗示了状态机逻辑，按钮的可见/不可见条件暗示了业务规则。但 AI 没法直接读 .rp 文件。操作建议：
1. 导出关键页面为 PNG/PDF（重点：状态切换页面、设置页面、异常提示页面）2. 如果用 Claude/GPT-4o 等支持图片的模型：直接贴截图 + 一句话引导 "这是自动湿度模式的 APP 交互原型，请提取其中涉及设备端的功能需求和状态切换逻辑"3. 如果模型不支持图片：手动写一段交互描述 "页面A：模式选择（手动/自动/睡眠三个按钮互斥高亮）→ 点击自动 → 页面B：目标湿度设置（滑动条 40~80%）→ 确认 → 回到页面A（显示当前湿度和目标湿度）"4. 重点关注：状态切换的触发条件和顺序、异常提示的触发条件、按钮在什么条件下不可点击
Axure 里有一个特别容易被忽略的信息：按钮的灰显/不可点击条件。比如"水箱未安装时自动模式按钮灰显"，这意味着固件需要判断水箱状态并在上报数据里体现，产品可能觉得这是"显而易见"的，但 PRD 文字里不一定会写。越来越多团队用 Figma 代替 Axure 做交互设计。Figma 对固件工程师的价值在两个地方：交互原型（Prototype 模式下的页面跳转和动画）和设计规范（Design Spec 里的组件状态和属性标注）。跟 Axure 不同，Figma 有几个特点需要注意：- Figma 的组件变体（Variants）藏着状态定义。 比如一个"模式按钮"组件有 state=default / active / disabled 三个变体，对应的就是手动/自动/不可用三种设备状态。这些变体信息不容易从截图里看出来，但对固件的状态机设计非常关键。
- Prototype 连线定义了状态转换。 Figma 的 Prototype 模式可以看到"点击按钮 A → 跳转页面 B → 触发动画 C"，这本质上就是一个状态转换图。固件工程师需要把它翻译成"事件 → 状态变迁 → 动作"的逻辑。
1. 导出方式（按优先级）： a. Figma Dev Mode：直接看组件属性、变体列表、间距标注 → 把关键组件的变体名和触发条件抄下来 b. Prototype 演示：录屏或逐页截图关键交互流 → 重点捕捉页面跳转的触发条件和方向 c. 批量导出 Frame 为 PNG：选中关键页面 → Export
2. 喂给 AI 的方式： - 截图 + 组件变体清单（文字）效果最好 - 示例： "以下是加湿器 APP 的模式切换页面截图。 组件变体信息： - ModeButton: default / active / disabled - HumiditySlider: visible(自动模式) / hidden(其他模式) - StatusBadge: auto / manual / sleep 请提取涉及设备端的状态定义和切换逻辑。"
3. 重点关注： - 组件变体 → 设备状态枚举 - Prototype 连线 → 状态转换条件 - 条件可见/隐藏的元素 → 上报字段依赖 - Auto Layout 约束 → 不直接相关，可忽略
一个常见的误区：把 Figma 当成"只给前端看的东西"。实际上 Figma 里的组件变体命名往往比 PRD 文字更精确。PRD 写"支持三种模式"，但 Figma 的变体列表里可能已经定义了 `mode=auto | manual | sleep | off`，多了一个 `off` 状态，这就是一个 PRD 文字里遗漏但设计稿里隐含的需求。不管是哪种格式，建议先跑一轮"提炼"，再跑后续的需求提取：你是嵌入式 IoT 固件工程师。以下是产品给的原始 PRD 材料，格式可能包含表格、自然语言描述和交互说明。
请帮我提炼一份面向固件开发的简化版 PRD，要求：1. 按功能模块组织，每个功能包含：描述、交互逻辑、约束条件2. 去掉跟固件无关的内容（市场背景、UI 视觉规范、排期等）3. 把模糊的描述改写为具体的条件（如"自动调节"改为"根据湿度差值切换 1/2/3 档"）4. 标注你觉得有歧义或信息不足的地方，用 [待确认: xxx] 标记
原始 PRD 材料：（粘贴内容）
人工审核这份简化版，重点看 AI 标记的 [待确认] 项和它改写后的具体条件是否准确。确认无误后，它就是后续所有步骤的输入基准。下面用经过上述流程处理后的简化版 PRD 做演示：功能名称：自动湿度模式
功能描述：用户在 APP 上设置目标湿度（40%~80%，步进 5%），开启自动模式后，设备根据当前环境湿度自动调节雾量档位（1~3 档），达到目标湿度后自动停止出雾，低于目标湿度时恢复出雾。
交互说明： - APP 端显示当前湿度、目标湿度、当前模式（手动/自动/睡眠） - 自动模式下用户仍可手动调节雾量，但调节后自动退出自动模式 - 设备端指示灯显示当前模式状态
其他要求： - 目标湿度掉电保持 - 支持定时关闭自动模式 - 与睡眠模式互斥（开启睡眠模式时自动模式关闭）
你是一名嵌入式 IoT 固件工程师。请阅读以下 PRD，按格式提取所有需求点。
要求：1. 每个需求点独立编号（REQ-001, REQ-002...）2. 区分功能性需求（F）和非功能性需求（NF）3. 标注优先级（P0=必须/P1=应该/P2=可选）4. 写出验收标准（可测试的条件，用 WHEN/THEN 格式）5. 如果 PRD 中有模糊或遗漏的地方，单独列出"待澄清项"
PRD 内容：（粘贴 PRD 原文）
输出格式：| 编号 | 类型 | 优先级 | 需求描述 | 验收标准 ||------|------|--------|----------|----------|
| | | | |
|---|
| | | 用户可设置目标湿度，范围 40%~80%，步进 5% | WHEN 用户在 APP 设置 55%，THEN 设备收到目标值 55 |
| | | | WHEN 当前湿度 < 目标值-5%，THEN 雾量为 3档；差值在 5% 内 THEN 2档 |
| | | | WHEN 湿度 >= 目标值，THEN 雾量 0；WHEN 湿度 < 目标值-3%，THEN 恢复出雾 |
| | | | WHEN 自动模式中用户设雾量 2档，THEN 模式切换为手动 |
| | | | WHEN 开启睡眠模式，THEN 自动模式关闭；反之亦然 |
| | | | WHEN 设备断电重启，THEN 目标湿度恢复为断电前的值 |
| | | | WHEN 定时到期，THEN 自动模式关闭，切回手动 |
| | | | WHEN 设备处于自动模式，THEN APP 实时显示三项数据 |
| | | | WHEN 自动模式开启，THEN 指示灯呈对应颜色/闪烁 |
- 传感器采样频率 PRD 未提及，建议 5~10 秒一次。
- "达到目标湿度后停止"的回差值未定义，需要定义滞环宽度，否则会频繁开关。
- 雾量档位与湿度差值的映射规则 PRD 只说了"自动调节"，需要明确控制策略。
- 容易漏的：异常路径。传感器坏了怎么办、WiFi 断了目标湿度能不能改、水箱空了自动模式怎么处理，PRD 一般不写这些，但固件必须处理。
- 容易多加的：过度推断。比如 AI 可能会加一条"支持多设备联动自动调湿"，PRD 没提，不要替产品做决定。看到这种就删掉，或者标记为待确认。
这一步是整个流程最有价值的环节：把需求点映射到具体的代码模块、接口和数据结构。你是嵌入式 IoT 固件架构师。请基于以下需求清单，结合项目模块结构，输出每个需求对应的技术影响面分析。
项目模块结构： - HAL 层：硬件抽象（GPIO、I2C、ADC、UART 等） - 外设驱动：传感器驱动、电机驱动等 - 应用层：业务逻辑（云端交互、Flash 存储、模式管理）
已有关键接口： - device_report() — 状态上报 - flash_write/read() — NVS 读写 - i2c_sensor_read() — I2C 传感器读取
需求清单：（粘贴上一步审核后的需求表格）
输出格式（每个需求一条）：| 需求编号 | 影响模块 | 改动类型 | 具体改动 | 风险点 ||----------|----------|----------|----------|--------|
（2）AI 输出
| | | | |
|---|
| | | 新增 auto_humidity_target 字段，范围校验 40~80 步进 5 | |
| | | 上报协议新增 target_humidity 字段 | |
| | | | |
| | | | |
| | | 实现滞环控制逻辑：上阈值=目标值，下阈值=目标值-3% | |
| | | 手动设雾量时检测当前模式，若为 auto 则切回 manual | |
| | | 模式切换逻辑增加互斥判断（sleep<->auto） | |
| | | NVS 新增 auto_target_humidity 键，启动时读取恢复 | |
| | | | |
| | | 新增 work_mode、current_humidity、target_humidity 上报字段 | |
| | | | |
（3）人工审核要点
这一步最容易出问题的是改动类型判断。AI 可能把"复用现有接口"误判为"需要新增"，也可能漏掉跨模块的连锁影响。比如：
- REQ-002 的自动控制任务需要创建 FreeRTOS task，栈大小怎么定？这是嵌入式的常见坑，AI 不一定会提醒。
- REQ-006 的 NVS 写入频率，如果每次目标湿度变化都写 Flash，SPI Flash 寿命会是问题。应该加防抖或只在模式退出时写入。
- REQ-004 的竞态，自动调节任务正在设雾量，用户同时手动改了雾量，谁覆盖谁？需要加锁或用事件队列。
这些风险点 AI 列出来了一部分，但不一定全。工程师的价值就在这里：补全 AI 看不到的隐性约束。拆解完成后，需要把结果整理成下游可消费的格式。如果团队用 OpenSpec，这份文档就是 `proposal.md`。（1）提示词模板
请将以下需求清单和技术拆解结果，整理为 OpenSpec proposal 格式。
格式要求：#（1-2 段，说清楚为什么做这个变更）
#（用列表描述变更内容，每条对应一个技术改动点）
##- `<能力名>`: <简述>#- `<能力名>`: <简述修改点>
#（受影响的代码模块、接口、依赖，以及风险提示）
输入：（粘贴需求清单 + 技术拆解表格）
（2）AI 输出
## Why
当前加湿器仅支持手动 3 档雾量控制，用户需要频繁根据体感调节。产品侧希望新增自动湿度模式：用户设定目标湿度后，设备根据环境湿度自动调节雾量，达标后停雾、回落后恢复，减少用户干预。
## What Changes
- 新增自动湿度控制任务：周期读取 SHT30 传感器，根据滞环策略 计算目标雾量档位- 新增目标湿度配置：范围 40%~80%，步进 5%，NVS 掉电保持- 修改模式管理：新增 auto 模式，与 sleep 模式互斥，手动操作 触发自动退出- 修改云端协议：新增 target_humidity/work_mode 上报与下发字段- 复用定时模块：支持定时关闭自动模式
## Capabilities
### New Capabilities- `auto-humidity-control`: 基于环境湿度的自动雾量调节能力
### Modified Capabilities- `work-mode-management`: 模式管理增加 auto 模式及互斥逻辑- `cloud-report-protocol`: 上报协议新增自动湿度相关字段- `nv-storage`: NVS 新增目标湿度持久化键
## Impact
- 应用层：新增自动控制模块，修改模式切换逻辑- 上报模块：协议字段扩展- 定时模块：复用，无需改动- 外设驱动（温湿度传感器）：复用，需确认采样频率支持- 风险：NVS 写入频率需控制；自动控制任务与用户操作的竞态需用 事件队列消解；滞环参数需实测调优
审核通过后，这份 proposal 可以直接提交到：openspec/changes/auto-humidity/proposal.md。
从这里开始，在基于Cursor + OpenSpec 的开发工作流 讲过的流程就接上了：
npx openspec new change auto-humidity
/opsx-continue /opsx-continue /opsx-continue /opsx-apply
关键点在于：因为 proposal 已经写得足够结构化，后续每一步 AI 的输出质量都会明显提升。举个对比例子：不用结构化 proposal 时，让 AI 写 design，它可能给你一个泛泛的"用 PID 控制加定时器"。但有了上面那份 proposal，AI 知道：- 具体要用 SHT30 传感器，通过 I2C 读取。
- 雾量是 3 档离散值，不是连续控制，所以 PID 没意义，滞环更合适。
这些约束都在 proposal 和 specs 里写着，AI 生成的 design 自然就靠谱得多。把上面三个环节的提示词存成 Cursor 的自定义命令或者 `.cursor/commands/` 文件，团队成员可以直接调用：
角色：嵌入式 IoT 固件工程师任务：从 PRD 提取需求点输出格式：表格（编号/类型F|NF/优先级P0|P1|P2/描述/WHEN-THEN验收标准）额外要求：列出 PRD 中模糊或遗漏的"待澄清项"
角色：嵌入式固件架构师输入：需求清单 + 项目模块结构 + 已有关键接口列表输出格式：表格（需求编号/影响模块/改动类型(新增|修改|复用|无改动)/具体改动/风险点）额外要求：标注跨模块依赖和嵌入式特有风险（栈大小、Flash磨损、竞态、中断安全）
角色：技术文档工程师输入：需求清单 + 技术拆解表格输出格式：OpenSpec proposal（Why / What Changes / Capabilities / Impact）额外要求：Impact 中必须列出风险项和降级策略建议
回顾整条链路做的事情，可以用一句话概括：把工程师脑子里的翻译过程外显出来，变成可审核、可追溯、可被 AI 消费的文档。但是在走完整套流程之后，有几件事值得多说一嘴。- AI 提需求的时候，异常路径几乎一定会漏。PRD 不会写"传感器坏了怎么办"，但固件必须处理。我的做法是在提示词末尾固定加一句："请补充 PRD 未提及但固件必须处理的异常场景"，如传感器故障、通信中断、存储满、低内存，这些让 AI 替你查漏补缺。
- 技术拆解那一步，AI 最大的盲区是硬件约束。它不知道你的 MCU 只有 300KB RAM，也不知道 Flash 只能写 10 万次。所以提示词里必须把硬件参数喂进去，哪怕只是一句"ESP32-S3, 8MB Flash, 512KB SRAM, FreeRTOS"，效果就完全不一样。
- proposal 不是写完就定稿了。到 specs 和 design 阶段经常会发现新问题，应该回来更新 proposal。OpenSpec 的 change 目录就是为此设计的，所有制品在归档之前都可以改。
最后，AI 的初稿正确率大概在七八成。剩下的两三成恰好是最容易出事的部分，如边界条件、竞态、资源约束。所以每一步的人工审核不能省，这是整条链路里人的价值所在。文章开头提到的那道鸿沟：产品说"用户要什么"，工程师要答"系统怎么做"。本质上是信息在不同载体之间传递时的损耗。PRD 在各种格式的文档里，工程师的答案在脑子里，而AI 能读的只有文本，把这三者打通，需要一道桥梁。这套流程就是在搭这座桥：先把散落在各种格式里的 PRD 拍平成文本，让 AI 帮你提取需求、拆解技术影响、输出结构化的 proposal，再交给 OpenSpec 和 Cursor 去做后续的设计和实现。每一步的输出都是下一步的输入，信息在流转过程中不被稀释。如果你也厌倦了"产品扔来 PRD，人肉翻译，让 AI 写代码，写歪了再改"这种循环，不妨试试把翻译这一步拆开、显式化。多花半小时在需求和技术拆解上，能省掉后面好几轮返工。这是我这段时间跑下来的体会。
粤ICP备14082021号
免费POC，
零成本试错
