从需求生成模块图

一句话

「新建 → 从需求生成模块图」把一段需求拆成一个个能独立验收的功能模块，并把模块依赖记进图里；生成后进编辑器审图，确认再运行。产物不是文档，是 Loop 本身。

两种模式，一份产物

模式	适合	怎么拆	产物差异
老项目建模	已有代码	先确定性取证（入口 / IPC / 路由 / 表 / 目录），再让模型在事实上归纳职责与依赖	paths、entrypoints 必须真实存在
新项目设计	还没有代码	从需求推导目标能力与边界	paths 是计划落点，可空

两种模式生成的是同一种图，所以下游（运行、验收、优化）完全一致。

产物长什么样

• 一个模块 = 一个 task 节点：id 就是模块 id（content.publisher 这种），prompt 里带职责、落点、上游产出与验收点。
• 依赖 = 边：每个 depends_on 生成一条 depends 边；执行时按拓扑序，上游先跑，下游 prompt 里能读到 {out.<上游>.summary}。
• 末尾一个验收节点：按模块逐条列验收标准（passIf=allCriteria、minScore=0.8），不通过把反馈带进下一轮。
• 需求缺口进 gaps：没有模块承接的需求不会被假装覆盖，验收会点名扣分。

生成前必过的校验

生成结果不是「模型说了算」，下面这些不过就带着问题重试一次，仍不过直接报错，不会落一张跑不动的图：

1. id 规范：ascii 小写点分、全图唯一。
2. 依赖闭合：只能指向本图模块或 external: 前缀，不允许悬空。
3. 依赖无环：有环直接拒绝（提示合并模块或抽公共模块）。
4. 职责与验收：每个模块必须有职责说明和至少一条可验收点。
5. 取证真实（老项目）：每个模块至少一个真实存在的路径，全不存在的算错误、部分缺失算告警。
6. 粒度：2–15 个模块，超过 12 个提示确认；把文件当模块会被上限拦住。

实测基线（本仓库，339 个文件 / 319 个源文件）

• 取证：入口 5 个、IPC 80 个、表 18 张，取证文本 6.8k 字符
• 生成：11 个模块 / 12 个节点 / 27 条边，一次通过校验；耗时约 112 秒
• 同时给出 6 条 gaps（定时发布、云端草稿、多平台开放状态等），不是只报喜

生成之后

1. 进编辑器看图：节点位置按依赖分层排，边是依赖关系；可直接改 prompt、增删节点。
2. 保存的是 draft，运行前可以改；运行后按模块记录步骤（agent_run_steps.module_id），运行详情里能「按模块」看每个模块完成还是失败。
3. 「模块清单」按钮导出 *.modules.json：项目、模式、需求、gaps、每条校验告警、全部模块（职责/落点/依赖/验收）和整张图，评审或交给上游直接用。
4. 拆解依据（模式、需求、取证统计、校验告警、第几版）记在 loop.meta.decompose，随时能查这张图是怎么来的。

限制

• 依赖只决定先后顺序，同层模块暂时串行；并行分轮还没做。
• 验收不通过是整轮重跑，还没有「只重跑失败模块」。
• 老项目取证只覆盖 JS/TS/Go 这类文本源码，二进制或生成代码要靠人补。
• 生成需要调用一次模型（实测约 1.4 美元/次，11 个模块），不免费。

和「模板」的区别

模板是固定的节点组合，只能选不能变；模块图是按需求生成的，节点数量、依赖关系、验收点都来自这次需求。模板仍然保留给图文创作、内容工厂、代码任务这类固定流程。