湿度传感器的采样周期多少？太快浪费 CPU，太慢响应迟钝 调节策略是什么？PID 控制还是简单的阈值滞环？ "自动调节雾量"——硬件支持几档？连续调还是分档？ 目标湿度存在哪？NVS？掉电要不要保持？ 跟手动模式怎么切换？切换瞬间会不会抖动？ 云端要同步哪些状态？APP 端怎么显示当前是自动模式？ 传感器故障了怎么办？要不要降级到手动模式？
在讲 AI 怎么提取需求之前，先聊一个现实问题：产品给的 PRD 格式五花八门。Excel 表格是最常见的。产品在 Excel 里列需求列表，每行一个功能点，列包括"功能名称/描述/优先级/备注"。好处是结构清晰，坏处是缺乏上下文。你只看到一行"支持自动湿度模式"，但不知道跟其他功能的关联关系。
Word 文档用来写详细描述。通常包含背景、用户故事、交互流程、异常处理等。信息量大，但格式不统一，段落之间的逻辑关系要人肉理解。
Axure 原型定义 UI 交互。哪个页面有哪些按钮、状态怎么切换、提示语怎么显示，都在原型里。对前端和 APP 开发很直观，但固件工程师关心的"底层逻辑"往往藏在交互细节里（比如"切换模式时先关旧的再开新的"这种时序约束，可能只能从原型的页面跳转顺序里推断出来）。
Figma 设计稿越来越多团队在用。跟 Axure 相比，Figma 多了一层信息：组件变体（Variants）。一个按钮组件可能有 default / active / disabled 三个变体，这直接对应设备的状态枚举。Prototype 模式下的页面连线则定义了状态转换逻辑。这些信息比 PRD 文字更精确，但容易被当成"只给前端看的东西"而忽略。
1. 取消所有合并单元格，用"填充空白格"补全2. 只保留关键列：功能编号 | 功能名称 | 描述 | 优先级 | 交互说明 | 约束/备注3. 如果有多个 Sheet，按编号合并到一个文本里4. 导出为 CSV 或直接复制粘贴（Cursor/ChatGPT 都能识别制表符表格）
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)互斥
（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. 重点关注：状态切换的触发条件和顺序、异常提示的触发条件、按钮在什么条件下不可点击
Figma 的组件变体（Variants）藏着状态定义。 比如一个"模式按钮"组件有 state=default / active / disabled 三个变体，对应的就是手动/自动/不可用三种设备状态。这些变体信息不容易从截图里看出来，但对固件的状态机设计非常关键。 Prototype 连线定义了状态转换。 Figma 的 Prototype 模式可以看到"点击按钮 A → 跳转页面 B → 触发动画 C"，这本质上就是一个状态转换图。固件工程师需要把它翻译成"事件 → 状态变迁 → 动作"的逻辑。
1. 导出方式（按优先级）：a. Figma Dev Mode：直接看组件属性、变体列表、间距标注→ 把关键组件的变体名和触发条件抄下来b. Prototype 演示：录屏或逐页截图关键交互流→ 重点捕捉页面跳转的触发条件和方向c. 批量导出 Frame 为 PNG：选中关键页面 → Export2. 喂给 AI 的方式：- 截图 + 组件变体清单（文字）效果最好- 示例："以下是加湿器 APP 的模式切换页面截图。组件变体信息：- ModeButton: default / active / disabled- HumiditySlider: visible(自动模式) / hidden(其他模式)- StatusBadge: auto / manual / sleep请提取涉及设备端的状态定义和切换逻辑。"3. 重点关注：- 组件变体 → 设备状态枚举- Prototype 连线 → 状态转换条件- 条件可见/隐藏的元素 → 上报字段依赖- Auto Layout 约束 → 不直接相关，可忽略
你是嵌入式 IoT 固件工程师。以下是产品给的原始 PRD 材料，格式可能包含表格、自然语言描述和交互说明。请帮我提炼一份面向固件开发的简化版 PRD，要求：1. 按功能模块组织，每个功能包含：描述、交互逻辑、约束条件2. 去掉跟固件无关的内容（市场背景、UI 视觉规范、排期等）3. 把模糊的描述改写为具体的条件（如"自动调节"改为"根据湿度差值切换 1/2/3 档"）4. 标注你觉得有歧义或信息不足的地方，用 [待确认: xxx] 标记原始 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 原文）输出格式：| 编号 | 类型 | 优先级 | 需求描述 | 验收标准 ||------|------|--------|----------|----------|
传感器采样频率 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 字段 | ||||
auto_target_humidity 键，启动时读取恢复 | ||||
work_mode、current_humidity、target_humidity 上报字段 | ||||
（3）人工审核要点
这一步最容易出问题的是改动类型判断。AI 可能把"复用现有接口"误判为"需要新增"，也可能漏掉跨模块的连锁影响。比如：
REQ-002 的自动控制任务需要创建 FreeRTOS task，栈大小怎么定？这是嵌入式的常见坑，AI 不一定会提醒。 REQ-006 的 NVS 写入频率，如果每次目标湿度变化都写 Flash，SPI Flash 寿命会是问题。应该加防抖或只在模式退出时写入。 REQ-004 的竞态，自动调节任务正在设雾量，用户同时手动改了雾量，谁覆盖谁？需要加锁或用事件队列。
（1）提示词模板
请将以下需求清单和技术拆解结果，整理为 OpenSpec proposal 格式。格式要求：## Why（1-2 段，说清楚为什么做这个变更）## What Changes（用列表描述变更内容，每条对应一个技术改动点）## Capabilities### New Capabilities- `<能力名>`: <简述>### Modified Capabilities- `<能力名>`: <简述修改点>## Impact（受影响的代码模块、接口、依赖，以及风险提示）输入：（粘贴需求清单 + 技术拆解表格）
（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# 把上面生成的 proposal 写入# 然后继续推进/opsx-continue # → 生成 delta specs/opsx-continue # → 生成 design（技术方案 + 选型决策）/opsx-continue # → 生成 tasks（可执行任务清单）/opsx-apply # → Cursor Agent 逐条实现
具体要用 SHT30 传感器，通过 I2C 读取。 雾量是 3 档离散值，不是连续控制，所以 PID 没意义，滞环更合适。 需要跟 sleep 模式互斥，模式管理有状态机。 NVS 写入要控制频率。
把上面三个环节的提示词存成 Cursor 的自定义命令或者 `.cursor/commands/` 文件，团队成员可以直接调用：
需求提取
角色：嵌入式 IoT 固件工程师任务：从 PRD 提取需求点输出格式：表格（编号/类型F|NF/优先级P0|P1|P2/描述/WHEN-THEN验收标准）额外要求：列出 PRD 中模糊或遗漏的"待澄清项"
技术拆解
角色：嵌入式固件架构师输入：需求清单 + 项目模块结构 + 已有关键接口列表输出格式：表格（需求编号/影响模块/改动类型(新增|修改|复用|无改动)/具体改动/风险点）额外要求：标注跨模块依赖和嵌入式特有风险（栈大小、Flash磨损、竞态、中断安全）
结构化文档
角色：技术文档工程师输入：需求清单 + 技术拆解表格输出格式：OpenSpec proposal（Why / What Changes / Capabilities / Impact）额外要求：Impact 中必须列出风险项和降级策略建议
AI 提需求的时候，异常路径几乎一定会漏。PRD 不会写"传感器坏了怎么办"，但固件必须处理。我的做法是在提示词末尾固定加一句："请补充 PRD 未提及但固件必须处理的异常场景"，如传感器故障、通信中断、存储满、低内存，这些让 AI 替你查漏补缺。
技术拆解那一步，AI 最大的盲区是硬件约束。它不知道你的 MCU 只有 300KB RAM，也不知道 Flash 只能写 10 万次。所以提示词里必须把硬件参数喂进去，哪怕只是一句"ESP32-S3, 8MB Flash, 512KB SRAM, FreeRTOS"，效果就完全不一样。
proposal 不是写完就定稿了。到 specs 和 design 阶段经常会发现新问题，应该回来更新 proposal。OpenSpec 的 change 目录就是为此设计的，所有制品在归档之前都可以改。
