把周报从一次 prompt 变成可回归流程

提示词完全一样，结果为什么还是每周变

你把上周那段 prompt 原样复制。只是输入表少了一列，周报的风险区、进度口径和负责人格式全部漂移。

复制文本不是复用流程，只是重复一次性运气。

可重复性来自输入契约、质量门和失败回归，不来自 prompt 被粘贴多少次。 这节课会把周报拆成事实层与生成层，先连续人工跑通，再决定是否封装或定时。

可重复不等于每周复制同一个提示词

稳定流程需要：

输入契约 → 预检 → 事实层 → 成品层 → 质量门 → 人工批准 → 版本与回归

如果输入缺失、指标口径变化或来源冲突，流程应停止，而不是更快地产生一份流畅但错误的周报。

第一步：建立练习目录

weekly-brief/
  inputs/
    weekly-input-pack.md
  rules/
    regression-fixture.md
    audience.md
    brief-template.md
  output/
  run-log.md

从 weekly-brief-readme.md 复制 audience 与 template 初始内容。所有材料虚构，不连接 Drive、Slack 或邮件。

第二步：定义输入契约

把 weekly-input-pack 拆成五类：

输入	必需字段	缺失时
project plan	目标、里程碑、批准日期	停止
metrics	指标名、值、口径、截止时间	停止或标 stale
decisions	决定、决定人、日期	不得补猜
risks	风险、信号、owner	owner 缺失则阻塞发布
team updates	来源人、事实、下一步	与计划冲突时并列

在 README 写清“必需输入”和“允许缺失”。契约是流程判断，不应埋在长 prompt 中。

第三步：先跑 preflight，不生成正文

只读检查 inputs/ 与 rules/，生成 output/preflight.md。

检查
- 必需文件与字段是否存在；
- 指标截止时间是否覆盖本周；
- 决定与计划是否冲突；
- 下一步是否缺 owner 或 due date；
- 是否含未脱敏个人/客户字段；
- regression-fixture 的关键事实能否从输入找到。

若存在 blocker，只报告并停止，不生成周报。

预期

starter 中有一个风险缺 owner，且一个指标更新时间过旧。preflight 应阻塞“可直接发送”状态，但可以在人工确认后生成带警告的草稿。

若 Codex仍生成正文，说明停止条件没有被实现。

第四步：建立事实层

确认允许生成草稿后，先输出 facts.json 或 facts.md：

reporting_period:
approved_milestones:
observed_metrics:
decisions:
risks:
next_steps:
conflicts:
missing:
source_map:

每个字段保留来源段落。事实层不写“进展顺利”“风险可控”等评价。

检查点 1

将事实层与 regression-fixture 对照：

• 已批准日期不能被会议建议覆盖；
• 指标值必须带口径和时间；
• 风险缺 owner 必须仍然可见；
• 来源冲突不能被合并。

第五步：从事实层生成受众化成品

audience.md 说明读者是部门负责人，关注：

1. 需要决定的事项；
2. 相对计划的变化；
3. 指标与风险；
4. 有 owner 和日期的下一步。

只根据已审核的 facts.md 生成 output/weekly-brief-draft.md。
结构严格使用 brief-template.md。

边界
- 不访问 inputs 之外的新来源；
- 不把 missing 或 conflict 改写成确定事实；
- 不新增 owner、due date 或批准状态；
- 只生成草稿，不发送、不发布。

完成前
- 每个下一步有 owner 和 due date，否则进入缺口；
- 每个数字可回到 source_map；
- 决定与建议措辞不同；
- 报告 blocker 和未验证项。

第六步：建立质量门

自动或机械检查：

• 必需标题存在；
• 数字与 facts.md 一致；
• 下一步表格无空 owner/due；
• 没有禁止字段；
• 草稿没有“已发送/已发布”等执行声明；
• 来源映射覆盖所有数字和决定。

人工检查：

• 信息优先级符合受众；
• 推断没有伪装成事实；
• 语气没有掩盖风险；
• 敏感信息最小化；
• 需要批准的决定没有被代做。

第七步：用固定失败样本做回归

regression-fixture.md 记录过去失败：

系统曾把“建议 8 月 15 日发布”写成“发布日期已调整为 8 月 15 日”。

每次改 prompt、模板或流程后，用相同 fixture 重跑，检查：

旧基线日期仍保留；
建议日期进入 proposed change；
批准状态为待确认；
草稿没有宣称已调整。

回归样本测试的是行为，不是要求每次文字完全相同。

第八步：记录版本与运行

run-log.md：

run_id:
input_period:
input_files_and_hashes:
rules_version:
template_version:
prompt_version:
preflight_result:
quality_checks:
human_approver:
external_actions:
known_limitations:

版本让你知道退化来自输入、规则、模板还是 prompt，而不是把所有问题都归为“AI 不稳定”。

第九步：何时才能做 skill 或定时任务

OpenAI best practices 建议：重复可靠的方法可封装为 skill；手动流程稳定后再考虑 scheduled task。

进入自动化前至少满足：

• 连续三次人工运行 preflight 和质量门可靠；
• blocker 会真正停止；
• 回归 fixture 通过；
• 外部数据源权限最小；
• 输出仍是待审核草稿；
• 有负责人处理失败和过期输入。

如果每周仍需大量 steer，先改输入契约或 skill，不要定时放大问题。

第十步：故障与恢复

指标过期但草稿写成当前

恢复 facts 层的 updated_at，状态设 stale，阻塞指标结论。让数据 owner 更新或在草稿中明确缺口。

模板升级导致风险段消失

对照 regression fixture，回退 template_version 或补回必需段，再重跑全部质量门。

自动化试图发送

停止任务，检查 prompt、skill 和连接权限；移除发送动作，只保留 draft 文件和人工批准点。

第十一步：迁移练习

新增受众“项目执行团队”，他们更需要具体依赖而非高层摘要。保留同一 facts 层，只新增 audience-team.md 和对应模板。

提示：

1. 事实层不应改变；
2. 可以改变排序和详细度；
3. 决定与风险的来源不能丢；
4. 两种草稿都不能自动发送。

用 rubric 检查后查看参考答案。

连续两周跑通，再谈自动化

用两周结构不同的脱敏输入执行同一流程。记录缺失字段、失败样本、人工修改和最终验收。

第二周需要重新解释的规则，就是还没有进入运行契约的隐性知识。把它补齐以后，流程才真正开始可复用。

完成检查

• 输入契约定义必需、允许缺失与停止条件
• preflight 在生成前发现 starter 中两个问题
• 事实层与受众化成品分开
• 质量门同时包含机械与人工检查
• 固定失败样本可以阻止已知退化
• 流程有版本、运行记录和人工批准
• 自动化前置条件不满足时不会强行定时