下载地址
https://api.skillhub.cn/api/v1/download?slug=%40org-0lub9joc%2Frequirement-to-dev-tasks1将提示词发送给你的 AI 安装该 skills
请根据 https://skillhub.cn/install/skillhub.md,安装 @org-0lub9joc/requirement-to-dev-tasks1。【罗斯蒙德需求拆解任务】南京罗斯蒙德基于已交付项目沉淀的需求拆解场景:把产品需求、业务描述、评审纪要、接口变更说明拆解成研发可执行的任务清单,输出需求摘要、影响范围、任务清单、任务优先级、风险点、待确认问题、验收建议七段式结构,自动校验六大环节覆盖度与配套工作遗漏,并导出可直接导入 Jira/Tapd/禅道的建卡文件。
全过程本地离线完成,零外网请求。触发词:需求拆解、研发任务拆解、需求拆任务、任务拆分、开发任务清单、需求转任务、排期拆解、影响范围分析、模块影响、依赖梳理、风险点识别、待确认问题、验收建议、建卡、评审排期、接口变更拆解、需求评审。
阅读全文 (展开查看完整说明)
概述
把需求材料拆成研发能直接排期、能直接建卡的任务清单。
一、适用场景
| 场景 | 输入 | 典型话术 |
|---|---|---|
| 需求评审前拆任务 | PRD、需求文档 | 「把这个需求拆成研发任务」 |
| 接口变更评估 | 接口变更说明、OpenAPI diff | 「这次接口改动影响哪些模块,要做什么」 |
| 评审纪要转任务 | 会议纪要、群聊摘录 | 「按纪要整理出任务清单和待确认问题」 |
| 技术方案落任务 | 技术方案文档 | 「把这份技术方案拆成开发计划」 |
| 排期前补全配套 | 已有的粗略任务表 | 「检查还漏了哪些配套工作」 |
二、痛点与解法
| 业务痛点 | 本技能的解法 |
|---|---|
| 需求信息分散在文档、群聊、纪要中,整理耗时 | 允许多份材料一起输入,统一归一到一份 IR;meta.source_files 记录来源便于追溯 |
| 不同研发对边界理解不一致,漏掉异常流程、权限、数据兼容、联调点 | 影响范围按 8 个维度强制枚举;配套工作反查表逐项扫「配置/存量数据/灰度/监控/回滚/权限/异常/一致性/文档」 |
| 拆任务只关注主流程,忽略配置、存量数据、灰度、监控、测试用例 | 六维度覆盖度校验(测试、发布为强制维度,缺失直接 ERROR);配套工作缺失逐项告警 |
| 新同学反复找人确认上下文,沟通成本高 | 每条任务强制写清「做什么 + 为什么 + 交付物」,描述过短即告警 |
| 排期前缺结构化输出,颗粒度不稳定 | 人日强制落在 0.5–5 区间并按 0.5 取整,超限判定为需再拆;输出依赖拓扑批次与可并行标记 |
三、工作流程
需求材料(文档/纪要/接口说明)
↓ AI 阅读理解(本步由模型完成)
ir.json(结构化任务拆解 IR)
↓ check_breakdown.py 校验与反查
核验报告 + 修正
↓ render_doc.py / export_cards.py
Markdown 文档 + 建卡 CSV/JSON第 1 步 · 读取材料PDF/Word 等二进制材料由你(模型)先提取正文,落盘为 .txt,再连同 IR 一起交给脚本做风险与配套反查。脚本只吃文本,不解析二进制。
第 2 步 · 填写 IR按 templates/task_ir_template.json 产出 ir.json。七段式:meta / summary / impact_scope / tasks / risks / open_questions / acceptance。字段口径见 references/task_schema.json。
关键纪律:
summary.problem用研发视角写,≥20 字;必须写non_goal,否则范围会蔓延。- 任务标题以动作开头(新增/改造/接入/编写/验证/执行/制定…)。
- 每条任务必填
deliverable;mitigation不得写「注意」「后续」这类空话。 estimate_days取 0.5–5,步长 0.5。- 依赖用
depends_on表达,不得成环;互不阻塞的标parallelizable: true。
第 3 步 · 校验
python scripts/check_breakdown.py --ir ir.json --source 需求原文.txt
--report 核验报告.md --stats stats.json有 ERROR 即退出码 1,按报告逐条修正后重跑,直到 ERROR 0。
第 4 步 · 出文档与建卡
python scripts/render_doc.py --ir ir.json --output 任务拆解.md
python scripts/export_cards.py --ir ir.json --csv 建卡.csv --json 建卡.json第 5 步 · 评审核验报告.md 里的「未覆盖的配套工作」与「待确认问题(阻塞项)」是评审会的议程清单。
四、输出规范
| 段 | 必填 | 门槛 |
|---|---|---|
| 一、需求摘要 | 是 | problem ≥20 字;含目标与非目标 |
| 二、影响范围 | 是 | 至少 2 个维度;services 必填 |
| 三、任务清单 | 是 | ≥6 条;六维度中 test/release 强制 |
| 四、任务优先级 | 是 | 至少 1 条 P0;P0 占比不宜 >60% |
| 五、风险点 | 是 | ≥3 条;缓解措施不得为空话 |
| 六、待确认问题 | 是 | ≥3 条;标注是否阻塞开工 |
| 七、验收建议 | 是 | ≥6 条;主流程/边界/异常/回归四类齐全 |
五、校验器拦什么(26 项断言已覆盖)
| 类别 | 拦截项 |
|---|---|
| 结构 | 七段缺失、任务 id 重复/格式错、维度值非法 |
| 颗粒度 | 人日超出 0.5–5、未取整、无交付物、标题无动作、描述过短 |
| 覆盖度 | 缺 test/release 维度、其它维度缺失且未声明不适用 |
| 风险 | 风险数不足、缓解措施为空话、原文命中风险关键词却未登记 |
| 待确认 | 问题数不足、未标阻塞、引用任务不存在 |
| 验收 | 四类场景不全、验收无预期结果、任务引用不存在的用例 |
| 依赖 | 依赖成环、自依赖、引用不存在的任务 |
| 配套 | 需求涉及配置/存量/灰度/监控/回滚/权限/异常/一致性/文档但任务里没体现 |
六、验收标准对照
| 你的验收标准 | 判据 | 示例实测 |
|---|---|---|
| 1 准确概括需求、不改变含义 | summary.problem 长度与非目标强制 | 通过 |
| 2 拆出主要任务、颗粒度可排期 | 任务数 ≥6、人日 0.5–5、交付物必填 | 18 条 / 25 人日 |
| 3 覆盖前端后端数据联调测试发布 | 六维度覆盖度(test/release 强制) | 六维度全覆盖 |
| 4 识别依赖、风险、待确认 | 风险 ≥3 + 反向反查、问题 ≥3 | 风险 7 / 问题 6 |
| 5 结构清晰,研发测试产品都看懂 | 七段式 + Markdown 表格化输出 | 七段齐全 |
| 6 可直接建卡排期 | CSV/JSON 导出含优先级、人日、依赖、负责人、验收关联 | 18 行建卡 |
| 7 相比人工减少遗漏与沟通 | 配套工作反查 + 坏样本拦截 | 12 类坏样本全部拦下 |
七、知识库(改规则不改代码)
| 文件 | 作用 |
|---|---|
references/task_schema.json | IR 字段定义与质量门槛 |
references/dimension_checklist.json | 六维度定义 + 9 项配套工作反查表 + 颗粒度规则 |
references/risk_taxonomy.json | 7 类风险、触发关键词、缓解措施提示 |
references/impact_scope.json | 影响范围 8 个维度与条目结构 |
references/priority_rules.json | P0/P1/P2 判定标准与人日口径 |
references/acceptance_scenarios.json | 四类验收场景模板与最少条数 |
templates/task_ir_template.json | IR 填写模板 |
examples/demo_需求原文.txt | 示例需求材料(文档加解密) |
examples/demo_ir.json | 示例拆解结果(18 任务 / 7 风险 / 6 问题 / 10 验收) |
examples/demo_任务拆解.md | 渲染出的研发任务拆解文档 |
examples/demo_建卡.csv / .json | 建卡导出产物 |
examples/demo_核验报告.md | 核验报告 |
八、使用纪律
- 不编造:任务、影响范围、风险必须能从输入材料推出;材料没提到的模块不要凭空列进影响范围。
- 不确定就进待确认:凡是影响方案选择但材料没写清的(灰度维度、数据量级、密钥来源、是否迁移存量),一律进
open_questions并标blocking,而不是替业务方拍板。 - 非目标必写:
non_goal是防止评审时范围蔓延最有效的一栏,材料没写就按方案边界推断并标注。 - 风险要写缓解措施:只写「需注意」会被校验器判 ERROR——写不出缓解措施说明这条风险还没想清楚。
- 人日是粗估不是承诺:输出的是相对量级,用于排期比较,实际工时以承接人评估为准。
九、已知限制
- 需求理解依赖模型:脚本只做结构化校验,不校验「拆得对不对」。业务判断错误、模块归属错误,校验器发现不了。
- 覆盖度是清单级而非语义级:能查出「没有测试任务」「没提监控」,但查不出「测试任务写得对不对」。
- 人日估算为经验粗估:不含联调等待、评审返工、环境搭建等隐性成本,排期时建议按团队历史系数放大。
- 影响范围靠材料推断:若材料未提及某模块,不会凭空补全;这类盲区应通过
open_questions显式提出。 - 示例为单一需求样本:
examples/里的文档加解密案例仅演示结构与深度,不代表所有需求类型。 - 无在线协同能力:不写入 Jira/Tapd/禅道,只产出可导入的 CSV/JSON,导入动作需人工执行。
十、快速开始
# 1. 用模板产出 ir.json(由模型填写)
# 2. 校验
python scripts/check_breakdown.py --ir ir.json --source 需求原文.txt --report 核验报告.md
# 3. 出文档与建卡
python scripts/render_doc.py --ir ir.json --output 任务拆解.md
python scripts/export_cards.py --ir ir.json --csv 建卡.csv --json 建卡.json
# 4. 一键验证本技能自身
python test/run_all.py