一为什么要封装

原模板是一套提示词 SOP 产品：每个模块给你一大段标准话术，粘进模型， 每一步产出后自己判断，再回复「进入 stepN / 继续」推进。

它成熟、经过实战。但 人就是调度器 —— 这既是它的质量控制机制，也是它无法自动化的瓶颈。

二六项改造

每一行都是「原来靠人 → 现在靠系统」，且都有落地的文件。

三流水线

13 个产物的命名契约见 shared/产物契约.md；模块依赖关系定义在 workflow.json。

四成熟度（如实反映断点）

母本本身的「成熟」是不均匀的 —— A–F1 是经实战的完整话术，F2 之后在母本里是空的。封装没有掩盖这一点。

五怎么用

网页版控制台

python main.py web          # 或双击 run-web.bat
浏览器打开 http://127.0.0.1:8770/

在页面上可完成整条流程：看流水线进度 → 渲染当前步骤提示词（一键复制）→ 粘贴回答提交 → 放行 / 打回 → 看产物与留痕 → 跑确定性脚本。纯标准库，不依赖框架或 CDN，离线可用。

命令行

python main.py              # 仪表盘 + 数字菜单
python main.py init --project project/my-project.json
python main.py next
python main.py submit A --step step1 --file ans.md
python main.py approve      # 该步是 human 闸门时

六质量与留痕

七技术栈

Python 3纯标准库零第三方依赖 本地 Web 控制台状态机 + 断点续跑 产物契约闸门协议

八这件事真正难在哪

难的从来不是写一个编排器 —— 是判断哪些环节该自动化、哪些必须留给人。

原 SOP 之所以要人一步步回复「继续」，不是因为技术上做不到自动跳转， 而是因为每一步的产出质量需要人确认。所以正确的做法不是把人拿掉， 而是把人从「调度」挪到「把关」：

• 能确定性判定的（数据解析、打标、跑数）→ 交给脚本，自动化
• 需要判断质量的（选题、指标口径、结论）→ 声明为 human 闸门，人必须显式放行
• 需要交叉检查的（口径一致性、禁配规则）→ 声明为 check 闸门，自动校验后报告

三类闸门在 workflow.json 里是显式声明、可审计的 —— 而不是散落在提示词里的那句「请确认无误后再继续」。