第 19 周：冻结 Capstone 的问题与风险合同

直接答案： 第 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-v1
decision: course_simulation_approved_with_conditions
scope: one_role_one_task_one_exception_one_approved_effect
conditions:
  - M1_negative_access_matrix_passes
  - no_missing_acl_document_enters_candidates
  - all_external_effects_require_fresh_approval
reopen_if:
  - role_or_data_scope_changes
  - frontline_workload_increases_beyond_agreed_boundary
  - a_forbidden_effect_or_access_leak_occurs
does_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 记录	批准、附条件、异议或停止决定

本周验收

常见失败与修复

失败	诊断信号	修复动作
目标是“完成 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、证据标签、周次和验收门是本课程的教学结构，不是行业统一标准。北辰案例、回放、指标和决定都是合成材料；没有真实组织授权时，不能外推为客户需求、采用、财务价值或生产许可。