企业官网建设流程全解析

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI

slice-progress.md是 openrig（Multi-agent harness，将 Claude Code 与 Codex 编排为同一系统的工程框架）在创建切片（slice）工作节点时，自动落盘的PROGRESS.md文件的官方模板。它定义了"切片的持久化验收状态"的标准书写契约：哪些内容属于本文件、哪些内容应留在工作 Agent 的 todo 工具中、验收完成的三个底线要素是什么。读完本文，你将掌握该模板的每个字段含义、{{sliceName}}占位符的渲染机制、rig scope如何用它生成节点，以及它如何与mission-slice-sop技能和 SDLC 约定协同工作，从而正确维护切片进度、顺利通过交接与验收。

模板全貌与逐行解读

模板文件位于 packages/cli/src/lib/scope-templates/slice-progress.md，完整内容如下：

# Progress — {{sliceName}} > Durable acceptance state for this slice. In-process steps belong in the > working agent's todo tool. See the `mission-slice-sop` skill and the > conventions SSOT (`docs/reference/sdlc-conventions.md` in the repo, > `$OPENRIG_HOME/reference/sdlc-conventions.md` when installed). ## Acceptance - [ ] Implementation complete - [ ] Tests passing - [ ] Review approved

模板虽短，却精确传达了四条关键约定：

1. 标题区：# Progress — {{sliceName}}中的{{sliceName}}是渲染时被替换的占位符，最终会显示为具体切片名称（例如# Progress — Payment Refund Flow）。
2. 定位声明（引用块第一句）："Durable acceptance state for this slice"——本文件只承载持久化的验收状态，即"这个切片是否做完、做到什么程度"的结论性记录。
3. 职责边界（引用块第二句）："In-process steps belong in the working agent's todo tool"——正在推进中的过程性步骤不属于这里，而应记录在工作 Agent 自己的 todo 工具中。这是"状态文件"与"过程清单"的根本区分，避免把 PROGRESS.md 写成流水账。
4. 知识来源指引（引用块第三句）：指明本约定是mission-slice-sop技能的浓缩教学面，完整约定 SSOT（单一事实来源）位于仓库内 docs/reference/sdlc-conventions.md，安装后对应$OPENRIG_HOME/reference/sdlc-conventions.md。
5. 验收区（## Acceptance）：三个复选框构成切片"完成"的最低门槛——实现完成、测试通过、评审通过。

模板还遵循mission-slice-sop的"比例原则"：进度文件服务于交付（shipping），本身不是工作本体；小型改动不应被繁琐的书架式流程拖累。

占位符渲染机制：{{sliceName}} 从何而来

{{sliceName}}并非前端运行时替换，而是在 CLI 脚手架阶段由模板渲染函数完成的。核心实现位于 packages/cli/src/lib/scope/templates.ts#L159-L162：

export function renderSliceProgressTemplate(sliceName: string): string { const raw = fs.readFileSync(resolveTemplate("slice-progress.md"), "utf8"); return raw.replace(/\{\{sliceName\}\}/g, sliceName); }

该函数只做一件事：读出slice-progress.md原文，然后把所有{{sliceName}}全部替换为传入的切片名称。它是全局替换（g标志），即使模板未来出现多个同名占位符也能一次性处理。

模板文件的加载遵循一套多候选根目录解析策略（templates.ts#L18-L40），按顺序命中第一个存在文件的目录：

• 开发环境：packages/cli/src/lib/scope/的上级../scope-templates（即模板与源码同目录存放，可直接按普通文档编辑）；
• 构建产物：dist/lib/scope/上溯两级后的lib/scope-templates；
• 兜底：编译后 dist 目录再上溯的源码树src/lib/scope-templates（当源码随包发布时）。

若全部候选目录都找不到模板，会抛出ScopeCliError，并给出明确的修复动作：重装@openrig/cli，或确保从包含packages/cli/src/lib/scope-templates/的检出运行。这种"调用时解析、第一个存在的目录胜出"的设计，让模板在本地开发与发布包布局之间保持稳健。

rig scope：模板如何落盘为 PROGRESS.md

renderSliceProgressTemplate的调用点在 packages/cli/src/commands/scope.ts#L397-L401。当用户在某个 mission 下执行切片创建命令时，CLI 会为切片目录生成一套完整的"工作节点四件套"：

fs.writeFileSync(readmePath, body, "utf8"); // SPEC.md（作用域与意图） fs.writeFileSync(progressPath, renderSliceProgressTemplate(title), "utf8"); // PROGRESS.md（本文主角） fs.writeFileSync(path.join(sliceAbs, "slice.yaml"), SLICE_MANIFEST, "utf8"); // slice.yaml（切片清单） fs.writeFileSync(path.join(sliceAbs, "PROOF.md"), proofBody, "utf8"); // PROOF.md（验证证据）

同时会创建proof/子目录用于存放证据媒体。命令执行期间，从依赖校验（如--depends-on必须是同 mission 下的兄弟节点点 ID）、到父 mission 持久化、再到四件套写入，都处于同一回滚边界内：任一步失败都会删除已创建的切片目录并恢复 mission 原始内容，保证不会留下半个节点。命令输出会回显新切片的id、template与path，方便后续追踪。

也就是说，你拿到手的PROGRESS.md是模板渲染 + 目录结构编排的组合产物：标题已被替换为真实切片名，验收三复选框作为"初始状态"等待 Agent 勾选。另外还有readmeOnly模式会在 SPEC 头部打上progress_rail: readme-only标记，用于仅以 README 承载的节点，此时不生成 PROGRESS.md（见 scope.ts#L388-L394）。

Acceptance 三要素：验收状态的持久化语义

模板末尾的三个复选框并非随意示例，而是被代码固化为"通用脚手架验收项"的常量。在 packages/cli/src/lib/scope/scaffold-placeholder.ts#L88-L96 中：

/** The generic acceptance triple scaffolded by * `packages/cli/src/lib/scope-templates/slice-progress.md` — exact trimmed * literals, sync-tested against the shipped template so constant/template * drift fails CI instead of silently reviving the bogus pristine count. */ export const GENERIC_SCAFFOLD_ACCEPTANCE: readonly string[] = [ "Implementation complete", "Tests passing", "Review approved", ];

注释说明了两点：

1. 这三个字符串必须与模板中的复选框文本逐字一致，且通过同步测试防止漂移——如果常量与模板文本不同步，CI 会直接失败，而不是悄悄产生错误的判定；
2. 它们服务于"pristine（原始未动）脚手架"识别：isPristineScaffoldSection（scaffold-placeholder.ts#L75-L86）会检查一个 section 是否每一行都是脚手架占位内容（裸占位行、或编号/复选框/子弹列表行且文本为占位）。一个"仅包含模板原始三复选框的 Acceptance 区"就是 pristine 状态，意味着还没有人真正书写验收结论。

对应的测试在 packages/daemon/test/scaffold-placeholder.test.ts#L117-L121（T6 用例）：读取随包发布的slice-progress.md，断言其确实包含## Acceptance区，从而验证"常量 ↔ 模板"同步关系成立。

这一机制的工程价值在于证明契约的来源选择：selectProofContractBody（scaffold-placeholder.ts#L111-L119）在选取 proof-contract 正文时，会跳过 pristine 的脚手架 section，优先采用"作者书写过的"SPEC、PRD、README 正文。换句话说，如果 PROGRESS.md 的 Acceptance 一直停留在模板原始状态，系统就知道"这还只是脚手架，不是真实验收记录"。

在 mission-slice-sop 中的使用规则：WHO / WHEN / HOW

slice-progress.md所生成的 PROGRESS.md，其生命周期由mission-slice-sop技能（packages/daemon/assets/plugins/openrig-core/skills/mission-slice-sop/SKILL.md）统一定义。该技能是随openrig-core插件统一交付的通用技能，测试 packages/daemon/test/mission-slice-sop-plugin-parity.test.ts 保证了它只有插件这一份来源、无冗余副本，且其检索描述控制在 500 字节预算内并保留 "starting / building / handing off / restoring / closing / mission / slice" 等检索症状词。

针对 PROGRESS.md，技能给出的规则是：

• WHO（谁写）：编排者（orchestrator）拥有§1（当前状态）；每个 Agent 记录自己的成果。
• WHEN（何时写）：在材料性的交付状态变化时、以及验收时更新。
• HOW（怎么写）：每个成果一行（一个复选框），细节向下链接展开；frontmatter 中的stage/verified字段必须保持诚实。

这与模板"一行一个 outcome（checkbox），link down for detail"的注释完全对应：PROGRESS.md 是扁平化的状态索引，细节放在子文档/证据中，而不是把大段过程性描述堆进本文件。技能还强调"当前文件契约"——SPEC.md、PROGRESS.md、PROOF.md、proof/ 是工作的操作表面：在它们上面追踪、记录、交接、抗压缩（compaction）。但要记住它们的从属地位：它们服务于产品，不是产品本身。

与相邻模板的分工：mission-progress 与 proof

PROGRESS.md 并非孤立存在，它与同目录下的两个模板形成完整的状态表达体系：

mission 级进度模板packages/cli/src/lib/scope-templates/mission-progress.md 结构与 slice 模板同构（# Progress — {{missionName}}+ 引用块 +## Acceptance），但验收要素升级为 mission 级别：范围完成（所有 slice 已塑形）、实现进行中、QA/评审通过、合并/发布。它由renderMissionProgressTemplate（templates.ts#L154-L157）渲染，只做{{missionName}}替换。slice 的三复选框是"单个工作包的验收"，mission 的四要素是"整条任务线的验收"。

验证证据模板packages/cli/src/lib/scope-templates/proof.md 承载"这个 slice 证明了什么、如何证明的"：要求写明按效果验证（running it and looking at the result），证据媒体放入proof/并通过rig proof add {{id}} --artifact-type qa --verdict PASS --candidate-sha <tip> --money-evidence "<one line>" --evidences "1" --media "screenshot-01.png"落盘——drop 动词会写入 Living Notes DELIVERED 配对所依赖的 C1 头，手工放文件则会让交付物停留在unverified状态。它还要求诚实标注 residue（未覆盖的部分）。

三者关系可概括为：SPEC.md 定义"要做什么" → PROGRESS.md 记录"做到哪一步" → PROOF.md 证明"确实做完了"，mission 级模板在其上再做一层聚合。

状态流转与交接：从脚手架到验收的完整回路

围绕 PROGRESS.md 的完整生命周期可总结为四段式：SCAFFOLD → POPULATE → PROJECT → VERIFY：

1. SCAFFOLD（脚手架）：rig scope从模板生成 SPEC.md、PROGRESS.md、PROOF.md、slice.yaml 与 proof/（即本文第一、二节所述）；
2. POPULATE（填充）：Agent 按 WHO/WHEN/HOW 规则勾选验收项、记录成果行；
3. PROJECT（投影）：Living Notes UI 读取这些文件，投影为 INTENT → PLAN → DELIVERED 的视图（UI 侧对应的进度轨展示见 packages/ui/src/components/project/ScopePages.tsx#L1338 的slice-progress-rail-status）；
4. VERIFY（验证）：rig scope audit在 slice 关闭时运行确定性兜底检查——所有约定检查都是建议性 / fail-open的：记录并建议，永不阻塞写入。干净的审计分数不是继续前进的前提。

切片间的交接遵循"热土豆"（hot-potato）原则：每个回合结束都应通过rig queue handoff把球传给下一个 Agent。handoff 是事务性的：关闭源节点、为--to指定的继任者铸造新节点，接力棒不可能中途掉落，且 handoff 只能在编排者座位终止（由编排者判断 park 是否合理）。而rig queue create仅产生一条信息性记录，不携带交接义务——传真实工作用handoff，发通知用create。

验收自检清单（来自 mission-slice-sop 技能）：

• 开始一个 slice 时：是否知道它为何存在、完成长什么样？UI slice 是否附了 mockup？是否走在轻量路径上（除非 mission 所有者显式分配了 overlay）？
• 结束一个 slice 时：PROOF.md 是否按效果说明了实际验证了什么、以及未覆盖什么？PROGRESS.md 是否已更新？mission 的 NOTES.md 是否刷新？是否通过rig queue handoff交接？
• 压缩（compaction）时：先在 mission NOTES.md 中归档状态；恢复时读取它以及活动 slice 的 SPEC.md、PROGRESS.md、PROOF.md。

这套"自由书写 + 确定性验证"的设计，让多 Agent（Planner / Builder / QA，按需要可由同一 Agent 兼任）共享同一个可读、可审计、可抗压缩的进度真相，正是 openrig 让 Claude Code 与 Codex 协同推进工程任务的底层状态契约。

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI