用AI把PRD拆解成可执行的技术方案

产品需求与工程实现之间，向来隔着一道翻译的鸿沟。这句话说了很多年，但落到每个具体项目里，该踩的坑一个都不会少。产品经理在PRD里写“自动调节湿度”，工程师得读出来“怎么做状态机、怎么定滞环、怎么处理掉电”。更麻烦的是，PRD的载体五花八门——Excel表格、Word文档、Axure原型、Figma设计稿……要把这些东西统一转换成开发团队能直接用的技术方案，光是信息提取这一步，就够喝一壶的。

先直接说结论：这套流程的核心思路，是把“人肉翻译PRD”这件事，拆成三步——拍平格式、AI提炼需求、人工补位审核。每个箭头之间，人做审核和决策，AI做初稿和防遗漏。不是让AI替你想，而是让它帮你把想的过程摊开来。下面用“智能加湿器新增自动湿度模式”这个虚构但贴近真实的案例，完整走一遍流程。

PRD怎么喂给AI

在讲AI怎么提取需求之前，先说一个现实问题：产品给的PRD格式五花八门，来之能战、战之能喂的寥寥无几。梳理一下常见的几种载体，以及它们各自的问题。

是最常见的。产品经理在Excel里列需求列表，每行一个功能点，列包括“功能名称/描述/优先级/备注”。好处是结构清晰，坏处是缺乏上下文。你只看到一行“支持自动湿度模式”，但不知道跟其他功能的关联关系。

用来写详细描述。通常包含背景、用户故事、交互流程、异常处理等。信息量大，但格式不统一，段落之间的逻辑关系需要人肉理解。

定义UI交互。哪个页面有哪些按钮、状态怎么切换、提示语怎么显示，都在原型里。对前端和APP开发很直观，但固件工程师关心的“底层逻辑”往往藏在交互细节里（比如“切换模式时先关旧的再开新的”这种时序约束，可能只能从原型的页面跳转顺序里推断出来）。

越来越多团队在用。跟Axure相比，Figma多了一层信息：组件变体（Variants）。一个按钮组件可能有default/active/disabled三个变体，这直接对应设备的状态枚举。Prototype模式下的页面连线则定义了状态转换逻辑。这些信息比PRD文字更精确，但容易被当成“只给前端看的东西”而忽略。

AI吃的是文本。要利用AI的能力，第一步是把各种格式“拍平”成它能理解的输入。这一步很关键——喂得好，后面的需求提取和技术拆解能省一半力气；喂得差，AI从一开始就会跑偏。

处理Excel

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交互说明#012
F-013 | 睡眠模式    | 高 | 见Sheet2交互说明#013
Sheet2-交互说明:
#012: 用户在APP设置目标湿度(40~80%, 步进5%)，设备自动调节...
#013: 一键开启睡眠模式，降低雾量+关闭灯光+降低噪音...
Sheet3-约束:
C-012-1: 与睡眠模式互斥
C-012-2: 目标湿度掉电保持

转换后（喂给AI的文本）：

## F-012 自动湿度模式（优先级：高）
- 描述：用户在APP设置目标湿度(40~80%，步进5%)，设备自动调节雾量(1~3档)
- 交互：达到目标湿度后停止出雾，低于目标时恢复；手动调节雾量则退出自动模式
- 约束：与睡眠模式(F-013)互斥；目标湿度掉电保持
- APP显示：当前湿度、目标湿度、当前模式

## F-013 睡眠模式（优先级：高）
- 描述：一键开启，降低雾量+关闭灯光+降低噪音
- 约束：与自动湿度模式(F-012)互斥

区别在哪？每个功能点的描述、交互、约束都聚合在一起了，不用在多个Sheet之间跳转。AI一眼就能看到“F-012和F-013互斥”这个关键约束。

处理Word

Word文档的问题不是格式，而是

。一份20页的PRD，前5页是市场背景和竞品分析，中间8页是功能描述，后面7页是排期和审批记录。固件工程师只需要中间那8页。操作建议：

1. 只提取这些章节：功能描述、交互流程、业务规则/约束、接口定义（如有）
2. 删掉：市场背景、竞品分析、排期计划、审批记录、UI视觉规范
3. Word里的嵌入表格和流程图：表格复制为文本，流程图截图备用
4. 如果文档超过3000字，按功能模块拆分，每次只喂一个模块

有一种情况要特别注意：Word里的“自然语言描述”经常有歧义。比如“设备自动调节雾量大小”，其中“大小”是指档位（离散值）还是具体数值（连续量）？这种歧义在Excel里不太会出现（因为表格强制你写具体），但在Word里很常见。遇到这种情况，在喂给AI之前先人工标注歧义点，或者在提示词里让AI把不确定的地方列出来。

处理Axure原型

Axure原型里藏着大量“隐性需求”——页面跳转顺序暗示了状态机逻辑，按钮的可见/不可见条件暗示了业务规则。但AI没法直接读.rp文件。操作建议：

1. 导出关键页面为PNG/PDF（重点：状态切换页面、设置页面、异常提示页面）
2. 如果用Claude/GPT-4o等支持图片的模型：直接贴截图 + 一句话引导
   “这是自动湿度模式的APP交互原型，请提取其中涉及设备端的功能需求和状态切换逻辑”
3. 如果模型不支持图片：手动写一段交互描述
   “页面A：模式选择（手动/自动/睡眠三个按钮互斥高亮）→
    点击自动 → 页面B：目标湿度设置（滑动条40~80%）→ 确认 →
    回到页面A（显示当前湿度和目标湿度）”
4. 重点关注：状态切换的触发条件和顺序、异常提示的触发条件、按钮在什么条件下不可点击

Axure里有一个特别容易被忽略的信息：按钮的灰显/不可点击条件。比如“水箱未安装时自动模式按钮灰显”，这意味着固件需要判断水箱状态并在上报数据里体现，产品可能觉得这是“显而易见”的，但PRD文字里不一定会写。

处理Figma设计稿

越来越多团队用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 端显示当前湿度、目标湿度、当前模式（手动/自动/睡眠）
- 自动模式下用户仍可手动调节雾量，但调节后自动退出自动模式
- 设备端指示灯显示当前模式状态

其他要求：
- 目标湿度掉电保持
- 支持定时关闭自动模式
- 与睡眠模式互斥（开启睡眠模式时自动模式关闭）

三步拆解

1. 提取需求点

提示词模板：

你是一名嵌入式 IoT 固件工程师。请阅读以下 PRD，按格式提取所有需求点。

要求：
1. 每个需求点独立编号（REQ-001, REQ-002...）
2. 区分功能性需求（F）和非功能性需求（NF）
3. 标注优先级（P0=必须/P1=应该/P2=可选）
4. 写出验收标准（可测试的条件，用 WHEN/THEN 格式）
5. 如果 PRD 中有模糊或遗漏的地方，单独列出“待澄清项”

PRD 内容：
（粘贴 PRD 原文）

输出格式：
| 编号 | 类型 | 优先级 | 需求描述 | 验收标准 |
|------|------|--------|----------|----------|

AI输出：

编号	类型	优先级	需求描述	验收标准
REQ-001	F	P0	用户可设置目标湿度，范围40%~80%，步进5%	WHEN用户在APP设置55%，THEN设备收到目标值55
REQ-002	F	P0	自动模式下根据环境湿度自动调节雾量（1~3档）	WHEN当前湿度<目标值-5%，THEN雾量为3档；差值在5%内THEN 2档
REQ-003	F	P0	达到目标湿度后停止出雾，低于目标时恢复	WHEN湿度>=目标值，THEN雾量0；WHEN湿度<目标值-3%，THEN恢复出雾
REQ-004	F	P1	自动模式下手动调节雾量，自动退出自动模式	WHEN自动模式中用户设雾量2档，THEN模式切换为手动
REQ-005	F	P1	与睡眠模式互斥	WHEN开启睡眠模式，THEN自动模式关闭；反之亦然
REQ-006	NF	P0	目标湿度掉电保持	WHEN设备断电重启，THEN目标湿度恢复为断电前的值
REQ-007	F	P1	支持定时关闭自动模式	WHEN定时到期，THEN自动模式关闭，切回手动
REQ-008	F	P1	APP显示当前湿度、目标湿度、模式	WHEN设备处于自动模式，THEN APP实时显示三项数据
REQ-009	F	P2	设备指示灯显示模式状态	WHEN自动模式开启，THEN指示灯呈对应颜色/闪烁

待澄清项：这通常是AI自动发现的遗漏，比如：

• 传感器采样频率PRD未提及，建议5~10秒一次。
• “达到目标湿度后停止”的回差值未定义，需要定义滞环宽度，否则会频繁开关。
• 传感器故障时的行为未定义，建议降级到手动模式。
• 自动模式是否受童锁影响，需确认。
• 雾量档位与湿度差值的映射规则PRD只说了“自动调节”，需要明确控制策略。

人工审核要点：AI的提取通常有两类问题。一是容易漏的：异常路径。传感器坏了怎么办、WiFi断了目标湿度能不能改、水箱空了自动模式怎么处理——PRD一般不写这些，但固件必须处理。二是容易多加的：过度推断。比如AI可能会加一条“支持多设备联动自动调湿”，PRD没提，不要替产品做决定。看到这种就删掉，或者标记为待确认。审核完的需求清单就是下一步技术拆解的输入。

2. 技术拆解

这一步是整个流程最有价值的环节：把需求点映射到具体的代码模块、接口和数据结构。

提示词模板：

你是嵌入式 IoT 固件架构师。请基于以下需求清单，结合项目模块结构，
输出每个需求对应的技术影响面分析。

项目模块结构：
- HAL 层：硬件抽象（GPIO、I2C、ADC、UART 等）
- 外设驱动：传感器驱动、电机驱动等
- 应用层：业务逻辑（云端交互、Flash 存储、模式管理）

已有关键接口：
- device_report()               — 状态上报
- flash_write/read()            — NVS 读写
- i2c_sensor_read()             — I2C 传感器读取

需求清单：
（粘贴上一步审核后的需求表格）

输出格式（每个需求一条）：
| 需求编号 | 影响模块 | 改动类型 | 具体改动 | 风险点 |
|----------|----------|----------|----------|--------|

AI输出：

需求编号	影响模块	改动类型	具体改动	风险点
REQ-001	应用层	新增	新增auto_humidity_target字段，范围校验40~80步进5	边界值校验遗漏
REQ-001	上报	修改	上报协议新增target_humidity字段	协议版本兼容
REQ-002	应用层	新增	新增自动控制任务，周期读传感器并计算雾量档位	任务栈大小、采样周期选择
REQ-002	外设驱动	无改动	复用现有驱动，确认采样接口可被周期调用	驱动是否支持高频调用
REQ-003	应用层	新增	实现滞环控制逻辑：上阈值=目标值，下阈值=目标值-3%	滞环宽度需实测调优
REQ-004	应用层	修改	手动设雾量时检测当前模式，若为auto则切回manual	状态切换竞态（用户操作 vs 自动调节同时触发）
REQ-005	应用层	修改	模式切换逻辑增加互斥判断（sleep<->auto）	切换顺序：先关旧模式再开新模式，避免中间态
REQ-006	应用层	修改	NVS新增auto_target_humidity键，启动时读取恢复	NVS写入频率控制（不要每次改都写，防磨损）
REQ-007	定时	复用	调用注册定时事件，回调里关闭auto模式	定时与模式切换的时序
REQ-008	上报	修改	新增work_mode、current_humidity、target_humidity上报字段	上报频率控制
REQ-009	应用层	修改	模式切换时调用LED控制接口更新指示灯状态	LED驱动兼容性

人工审核要点：这一步最容易出问题的是改动类型判断。AI可能把“复用现有接口”误判为“需要新增”，也可能漏掉跨模块的连锁影响。比如：

• REQ-002的自动控制任务需要创建FreeRTOS task，栈大小怎么定？这是嵌入式的常见坑，AI不一定会提醒。
• REQ-006的NVS写入频率，如果每次目标湿度变化都写Flash，SPI Flash寿命会是问题。应该加防抖或只在模式退出时写入。
• REQ-004的竞态，自动调节任务正在设雾量，用户同时手动改了雾量，谁覆盖谁？需要加锁或用事件队列。

这些风险点AI列出来了一部分，但不一定全。工程师的价值就在这里：补全AI看不到的隐性约束。

3. 输出结构化文档

拆解完成后，需要把结果整理成下游可消费的格式。如果团队用OpenSpec，这份文档就是proposal.md。

提示词模板：

请将以下需求清单和技术拆解结果，整理为 OpenSpec proposal 格式。

格式要求：
## Why
（1-2 段，说清楚为什么做这个变更）

## What Changes
（用列表描述变更内容，每条对应一个技术改动点）

## Capabilities
### New Capabilities
- `<能力名>`: <简述>
### Modified Capabilities
- `<能力名>`: <简述修改点>

## Impact
（受影响的代码模块、接口、依赖，以及风险提示）

输入：
（粘贴需求清单 + 技术拆解表格）

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。

接入OpenSpec

从这里开始，之前在基于Cursor + OpenSpec的开发工作流里讲过的流程就接上了：

# 创建变更
npx openspec new change auto-humidity

# 把上面生成的 proposal 写入
# 然后继续推进
/opsx-continue  # → 生成 delta specs
/opsx-continue  # → 生成 design（技术方案 + 选型决策）
/opsx-continue  # → 生成 tasks（可执行任务清单）
/opsx-apply     # → Cursor Agent 逐条实现

关键点在于：因为proposal已经写得足够结构化，后续每一步AI的输出质量都会明显提升。举个对比例子：不用结构化proposal时，让AI写design，它可能给你一个泛泛的“用PID控制加定时器”。但有了上面那份proposal，AI知道：

• 具体要用SHT30传感器，通过I2C读取。
• 雾量是3档离散值，不是连续控制，所以PID没意义，滞环更合适。
• 需要跟sleep模式互斥，模式管理有状态机。
• NVS写入要控制频率。

这些约束都在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写代码，写歪了再改”这种循环，不妨试试把翻译这一步拆开、显式化。多花半小时在需求和技术拆解上，能省掉后面好几轮返工。这是这段时间跑下来的体会。