需求原子化引擎

要解决的问题

需求文档里最常见的问题是粒度失控：一句「对数据做处理」可能对应校验、转换、入库、重试四件事；异常处理被悄悄塞进主流程，验收时才发现没人能说清楚失败态返回什么。这个技能要做的就是把需求压到「不可再分」的原子任务粒度，让每个任务都能独立测试、独立验收。

核心机制

每个原子任务必须写全 IPO 三要素：

• Input：启动所需的全部结构化信息，包括数据类型、来源、约束和边界值
• Process：单一核心处理步骤，且必须明确由 LLM 还是代码执行——分类、抽取、摘要、生成适合交给模型，精确计算、严格逻辑、数据库查询、外部 API 调用应留在代码里
• Output：结构化结果，成功态给出类型与结构，失败态给出错误码与消息

判定一个任务是否够「原子」，需要同时满足六条标准：单一职责、输入显式、处理完整、输出清晰、不可再分、可脱离上下文独立测试。

输出结构与执行流程

拆解结果固定为五部分：层级图、模块划分（2-5 个核心模块）、按执行顺序排列的原子任务清单、Mermaid 依赖图（实线为主流程、红色虚线为异常分支、同步节点标记并行任务）、以及一份验收清单，逐项核对输入边界、分支覆盖、成败态定义等六个问题。

执行时遵循六步：理解需求（有疑问先问）、识别模块、逐模块拆解、定义每个原子的 IPO、绘制依赖图、对照验收清单自查。

适用边界

三条红线值得注意：禁止模糊描述，「处理数据」必须写明处理什么、怎么处理；异常分支不得被主流程吸收，错误处理必须是独立原子；编排原子只做协调，不写业务逻辑。如果团队需要一份完整 PRD，应先走需求转 PRD 再进入本流程；拆解完成后接方案设计、PRD 转开发规范即可进入工程交付。