直接答案： 第 19 周先不集成更多技术。你要把前 18 周分散的商业、一线与工程证据，压缩成一个可以批准、附条件、反对或撤销的 Capstone M0 合同。合同的中心是“第 24 周要支持哪个业务决定、改变一线哪一步、哪些风险绝不能发生”，而不是“我要做一个 RAG + MCP 项目”。
M0 冻结什么，又不冻结什么
M0 冻结的是下一阶段必须共同遵守的问题和风险边界：
业务决定 ↕ 核对一线任务、异常与人工兜底 ↕ 约束数据、权限、安全、成本与参与者保护 → 第 20–24 周需要补齐的证据 → 继续 / 缩小 / 停止的条件
它不冻结技术实现。第 20 周发现数据边界无法成立时，可以缩小范围或停止；不能为了保住已经画好的架构而改写问题。
先给每项重要陈述加证据标签：
| 标签 | 含义 | 可以怎么写 |
|---|---|---|
| 事实 | 有可追溯来源、适用范围和日期 | “在 12 条脱敏回放中，7 条出现人工查找步骤” |
| 推断 | 由多个事实推导，但仍可能有别的解释 | “人工查找可能是主要等待点” |
| 假设 | 尚待验证的价值或行为机制 | “减少查找时间可能降低平均处理时长” |
| 未知 | 当前没有足够证据 | “真实任务频率与年度财务价值未知” |
“大家都需要”“一定能提效”“客户愿意用”如果没有来源，都应回到假设或未知。
先看完成品：北辰 Capstone M0
以下公司、流程、角色、数字和批准均为课程固定合成示例。
第 24 周要支持的决定
是否值得继续一个受限的“客服政策确认”试点：普通客服在回复客户前，查看当前且有权限的政策依据；遇到冲突、过期或无答案时升级；只有在客服逐次确认后，系统才可创建一张主管复核单。
这不是公司级上线批准，也不是“让 AI 自动处理客服”。
范围与非目标
| 项目 | M0 范围 |
|---|---|
| 主要角色 | A 业务单元普通客服 |
| 一个任务 | 回复前确认政策依据 |
| 一个异常 | 来源冲突时升级给政策所有者或主管 |
| 单一写效果 | 经逐次批准创建主管复核单 |
| 数据边界 | A/B 业务单元隔离；普通与主管角色隔离 |
| 非目标 | 自动回复、批量写入、自主审批、跨部门推广、真实生产部署 |
已知、假设与未知
| 陈述 | 标签 | 来源或下一步 |
|---|---|---|
| 固定回放中存在查找与升级断点 | 事实（教学样本内） | 第 2–4 周合成走查记录 |
| 检索与引用可减少部分查找步骤 | 假设 | 第 21、24 周观察 |
| 权限泄漏、错误政策和未批准写入不可接受 | 硬约束 | M0 风险回读 |
| 真实采用、任务频率、节省时间与财务价值 | 未知 | 只有授权试点才可能验证 |
M0 决定
decision_id: northstar-m0-v1decision: course_simulation_approved_with_conditionsscope: one_role_one_task_one_exception_one_approved_effectconditions: - M1_negative_access_matrix_passes - no_missing_acl_document_enters_candidates - all_external_effects_require_fresh_approvalreopen_if: - role_or_data_scope_changes - frontline_workload_increases_beyond_agreed_boundary - a_forbidden_effect_or_access_leak_occursdoes_not_authorize: - real_customer_data - production_deployment - autonomous_actions
这个例子合格，是因为价值仍被标为假设，真实采用仍是未知，课程模拟批准也没有被写成组织授权。
第一步：建立证据谱系，而不是复制旧文档
为前 18 周关键产物建立一张表：
| 证据 | 版本 / 日期 | 原来支持什么 | 当前范围仍匹配？ | 决定 | 局限或冲突 |
|---|---|---|---|---|---|
| Discovery Brief | v3 / 日期 | 问题与相关角色 | 部分 | 修订 | 新增了写操作风险 |
| RAG 评测报告 | v1 / 日期 | 固定语料上的失败分类 | 是 | 复用结构 | 不能代表 Capstone 新语料 |
| MCP 效果审计 | v1 / 日期 | 单一工具的审批与对账 | 是 | 复用控制 | 第 22 周必须重新集成验证 |
每项只能选一种主决定：
- 复用： 范围和版本仍适用；
- 修订： 核心可保留，但角色、数据或风险已经变化；
- 淘汰： 与新问题冲突或已经失效；
- 未完成： 还没有足够证据。
旧文件多不代表证据强。证据不能回答当前决定，就不要为了作品集完整感强行引用。
第二步：从老板的目标走到一线任务
用下面五个问题把两层对话接起来：
- 老板最终要作什么决定，而不是希望看到什么功能？
- 哪个一线角色的哪一个任务会影响这个决定？
- 正常路径、异常路径和人工兜底分别是什么？
- 系统改变哪一步，又必须保留谁的判断权？
- 哪个可观察结果会支持继续，哪个保护指标或硬风险会要求停止？
一页问题与风险合同模板
# Capstone M0 问题与风险合同 v1 ## 决定第 24 周，谁要根据哪些证据决定继续、缩小还是停止什么？ ## 当前一线任务- 主要角色：- 触发条件：- 正常步骤：- 一个关键异常：- 当前人工兜底与责任人：- 一线明确不愿失去的判断权： ## 范围- 一个任务：- 一个异常：- 一个允许的写效果（若有）：- 数据和角色边界：- 非目标： ## 指标与证据状态| 指标或主张 | 基线 | 类型：事实/推断/假设/未知 | 来源 | 第几周验证 || --- | --- | --- | --- | --- | ## 硬风险与停止条件| 风险 | 不可接受结果 | 检测证据 | 负责人 | 触发后的动作 || --- | --- | --- | --- | --- | ## 批准、异议与重开条件分别记录业务、一线、数据/安全和工程角色的结论；不要用一个统一签字代替不同责任。
第三步：把指标写成价值机制，而不是承诺
每个候选指标都回答六件事：
- 指标支持哪个决定；
- 适用角色和任务是什么；
- 分子、分母、时间窗和来源是什么；
- 当前基线是事实、模拟还是真实未知；
- 可能被什么替代解释影响；
- 哪个保护指标阻止“优化数字、伤害现场”。
例如，“平均处理时长下降”不能单独使用。更完整的机制是：
当前查找步骤与等待时间（待真实测量） → 有依据的政策候选减少部分查找 → 一线仍确认或升级 → 观察任务时长与返工同时保护：权限泄漏 = 硬停止；错误政策不得被更快地送达
没有授权流量时，基线保持未知。课程回放只能验证计算方法或暴露流程缺口。
第四步：进行四方回读并形成决定记录
同一份 M0 分别让四种责任视角回读：
| 视角 | 必须确认 | 不能替别人确认 |
|---|---|---|
| 业务负责人 | 要作的决定、价值机制、预算风险、停止条件 | 一线实际负担与数据授权 |
| 一线角色 | 当前任务、异常、人工兜底、保留的判断权 | 组织预算和安全例外 |
| 数据/安全负责人 | 数据范围、权限、保留、硬风险 | 业务价值和一线可用性 |
| 工程负责人 | 可实现边界、待验证控制、回滚与运维差距 | 客户接受和业务优先级 |
真实角色不可达时，可以角色扮演，但必须逐项标为模拟。记录不同意意见比追求一张“全部通过”的表更重要。
五天安排
| 学习日 | 建议时间 | 当天动作 | 离开前必须有的结果 |
|---|---|---|---|
| 第 1 天 | 1–2 小时 | 盘点上游版本、能力与局限 | 证据谱系和复用/修订/淘汰初稿 |
| 第 2 天 | 2 小时 | 固定一个决定、角色、任务和异常 | 一页问题与风险合同 |
| 第 3 天 | 1–2 小时 | 写价值机制、基线状态、保护指标与未知 | 指标卡和停止条件 |
| 第 4 天 | 2 小时 | 绘制第 20–24 周证据差距 | 每个风险都有验证周次和负责人 |
| 第 5 天 | 2 小时 | 完成四方回读与 M0 记录 | 批准、附条件、异议或停止决定 |
本周验收
- 合同中心是业务决定与一线任务，不是技术名称；
- 正常路径、一个关键异常、人工兜底和责任人清楚；
- 每项重要主张带事实、推断、假设或未知标签；
- 数据、权限、安全、成本和参与者保护进入硬约束；
- 一线保留的判断权和新增负担被明确记录；
- 每份旧证据被判定为复用、修订、淘汰或未完成；
- M0 明确列出第 20–24 周尚未完成的证据；
- 业务、一线、数据/安全和工程意见分别记录；
- 决定包含适用范围、条件、异议、复查日期与重开条件；
- 没有真实授权时只写“课程模拟批准”；
- M0 不授权真实数据、生产部署或自主写操作。
常见失败与修复
| 失败 | 诊断信号 | 修复动作 |
|---|---|---|
| 目标是“完成 RAG + MCP” | 无人知道第 24 周要作什么决定 | 改写成角色、任务和继续/停止决定 |
| 老板愿望直接成为需求 | 一线流程与异常没有证据 | 回到任务走查并标记矛盾与未知 |
| 一线抱怨直接成为功能 | 没有频率、替代方案或责任边界 | 补证或缩小为待验证假设 |
| 所有旧文件直接复用 | 版本、角色或范围互相冲突 | 逐项做复用/修订/淘汰判断 |
| 为完整感填写未知数字 | 指标没有来源或分母 | 恢复“未知”，指定授权取证路径 |
| 模拟批准写成客户批准 | 没有真实有权角色 | 修正标签并撤回外推结论 |
独立迁移：供应链异常 M0
把北辰客服案例换成“供应链异常确认”，但只保留：
- 一个老板要作的决定，例如是否继续受限的异常处理试点；
- 一个一线角色，例如采购运营；
- 一个任务，例如核对异常依据并形成建议；
- 一个异常，例如供应商状态冲突；
- 一个逐次批准效果，例如提交加急复核请求；
- 一个硬停止条件，例如跨供应商数据泄漏或重复采购效果。
先写 M0，再判断是否真的需要 RAG、MCP 或多租户。技术不是默认答案。
用同一份证据向三类人解释
- 老板版： 第 24 周要决定什么，价值怎样可能产生，当前事实、假设、未知和停止信号分别是什么。
- 一线版： 改变哪一步、保留哪些判断、异常时由谁接手、怎样拒绝、退出或回退。
- 工程版： 复用哪些版本、淘汰什么、硬边界是什么、每个剩余风险在哪周验证。
下一步
只有 M0 获得相应授权或明确标为课程模拟批准，才进入第 20 周：接通 Capstone 数据与访问边界。角色、数据范围或风险发生变化时，先版本化并重新回读 M0。
来源与事实边界
- GOV.UK Service Manual — Understand users and their needs：以用户任务和实际需要而不是预设方案开始研究的参考。
- NIST AI RMF Playbook：治理、映射、测量与管理 AI 风险的参考框架。
- Palantir — Forward Deployed Software Engineer：客户协作、问题拆解和端到端交付职责参考；岗位页面可能变化。
核验日期：2026-08-25。 M0、证据标签、周次和验收门是本课程的教学结构，不是行业统一标准。北辰案例、回放、指标和决定都是合成材料；没有真实组织授权时，不能外推为客户需求、采用、财务价值或生产许可。