CSF

版本: v1.1 | 最后修订: 2026-07-07 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。 关键词: [W-重, W-轻, W-跳过, 外在交互对账, 业务语言放大, 消费者测试, 判据] 适用场景: 文档收尾检查、主题包验收、业务认知校准、跨spec一致性复检

W-协议（W-跳过 / W-轻 / W-重）

W 协议是检查协议。本质二分：Owner 不在场 = 工程性自查（W-跳过 / W-轻）；Owner 在场 = 业务认知回溯（W-重）。

元约束：守则 § 1 业务唯一裁判。任何”业务认知校准”必须走 W-重——脱离代码/设计语言转回业务语言由 Owner 在场捕捉张力。

§ 0 W 是什么（正式释义）

W = 外在交互对账。

通过业务过程描述、UI 交互推演、接口的服务（或交付）意义解释等手段，对模块或产品的外在交互进行对齐，从而尽可能以靠近业务原点的方式来发现潜在问题。

核心机制：强制把内部实现翻译回业务语言，让业务直觉能够捕捉张力。

Owner verbatim：「误解一旦脱离代码或设计语言，转变成业务语言，就会被放大。」

三档对应：

§ 1 三档定义

档 本质 Owner 在场 典型耗时 典型场景
W-跳过 0 新业务灵魂；纯机械/格式动作 否 0 重命名、迁移、commit、tag、纯排版
W-轻 参谋长自查；工程性/结构性检查 否 5~30 分钟 文档收尾回写自检、跨包 cross-ref 简检
W-重 Owner 参与；业务认知回溯；业务语言放大检验 是 1~多小时 业务红线复检、域模型分歧裁决、跨 spec 业务一致性回溯

§ 2 跳过判据（决定是否可走 W-跳过）

W-跳过的充分必要条件 = D1~D4 全过：

判据 内容
D1 改动不引入新的业务概念
D2 改动不涉及”业务方关心的字段”语义
D3 改动不改变跨包/跨域接口契约
D4 改动可被同一份 spec / domain 文档完全解释（无需 Owner 解读）

任一不过 → 至少 W-轻；涉及业务认知或跨域语义 → W-重。

§ 3 二分本质

W-轻和 W-重之间不存在”中间档”——区别在于「业务语言放大镜是否启用」：

Owner verbatim：

「误解一旦脱离代码或设计语言，转变成业务语言，就会被放大，被人敏锐地捕捉到。」

→ W-重 = 主动制造这次”翻回业务语言”的机会。Owner 不在场则放大镜失效，不允许 W-轻伪装成 W-重。

§ 4 W-轻 11 类自查样板（按出现频率）

# 场景 自查动作
1 文档收尾 收尾协议规定的回写自检（参见 cos-context.md §A 收尾协议）
2 spec 改完 cross-ref 4 形态自检（参见 跨包责任分隔与cross-ref.md）
3 新增设计决策 决策分类自检；落点正确性（DEVNOTES vs domain vs arch vs 方法论库）
4 任务书产出 架构依据节每条决策可追溯到来源
5 模块 spec spec-checklist 自检
6 业务文档修订 domain 索引同步更新 / 改动不破坏既有编号体系
7 大批量重命名 引用方同步更新 / link 不破
8 TP/SP 切换 任务窗口更新（参见 立项协议.md）
9 inbox 处理 顶部条目清空 / 已处理项搬入对应文件
10 CONTEXT 滚动 旧段降级为 log / 新段写入”当前状态”
11 PENDING 验收 业务层 vs 工程层分清；业务层归参谋长，工程层归开发者自查

W-轻清单不要求一次性走完所有 11 项——按本次动作触达哪些维度，只自查相关项即可。

§ 5 W-重样板（Owner 在场 / 业务回溯）

触发条件：

执行流程：

  1. 业务语言陈述：把当前认知用业务方听得懂的话陈述（脱代码 / 脱设计语言）
  2. Owner 在场审视：现场提问 / 现场捕捉张力
  3. verbatim 入册：Owner 拍板的核心句子 verbatim 写入设计决策记录 + 守则（如属元原则）/ 经验库（如属方法）+ 相关 spec 备注
  4. 三谱系归位：判定属哪条谱系（业务规则明文化 / 认知校准 / UI 显化，参见 D3-三谱系.md），按谱系决定落点
  5. 回写：业务文档 / 架构 / 任务窗口 verify 段对应更新；如触发新 cross-ref，同步前后包

禁止事项：

§ 5b 消费者测试执行档

核心立意（Owner verbatim）：「W-重在这里的核心方法是，前面的工作已经做了分拆和搬运，我们要检验分拆和搬运之后的结果是否能够为后面的设计和研发提供完备、准确的资料供给，且不带来业务的误导。」

§ 5b.1 与「议题清单审计」的区别

维度 议题清单审计（旧） 消费者测试（新）
视角 全知（参谋长对照 checklist 逐项确认） 受限（模拟下游开发者首次接手）
缺口发现方式 主动查找 / 易漏 checklist 外的盲区 自暴露 / 读不通即问
偏倚 已知问题导向 未知问题导向
Happy path 之外覆盖 取决于 checklist 完整性 直觉触发（”那如果取消怎么办”）

→ 消费者测试取代议题清单作为主要 W-重手段；议题清单退为补盘扫尾。

§ 5b.2 重型 — 双会话隔离消费者测试（标准 W-重）

适用：复杂横切主题包 / 商业模式底色级 / 跨 spec 业务一致性回溯 / 主题包体量 ≥ 15K。

预算：3-6 会话（第 1 会话装料 + 第 2 会话消费者 + 第 3 会话起设计者审阅 ± 复测）。

5 步流程：

  1. 装料会话（N）：参谋长全知视角起 TP / 写白名单（精确到段号，见 § 5b.4）/ 写开局指示 / 建 TP exec-log
  2. 消费者会话（N+1）：模拟开发者严格按白名单读 → 主动遗忘承诺 → Owner 触发后做业务复述 + 回问清单 + 反常识点 → 收尾落”原始基线证据”文件（不在后续会话中被修改）
  3. 设计者会话（N+2）：参谋长解除约束以全知视角宏观判断 = ① 输出质量评估 / ② 根因诊断 / ③ 对后续工作影响 / ④ 规避优化方法 / ⑤ 协作规范有效性评估（不必逐条审议消费者会话所有问题）
  4. 修订主题包（可独立会话或合并到设计者会话）：A 类内部矛盾立设计决策 + 反向修 arch；B 类信息缺口补主题包；C 类越界引用前置抽取
  5. 可选复测会话（N+k）：新会话再走一遍消费者复述，验证修订有效

双会话物理隔离：上下文一旦加载无法真正擦除，”遗忘”只能靠新 session 物理隔离。

§ 5b.3 轻型 — W-轻消费者复述清单（单会话内嵌）

适用：体量 < 15K 的常规主题包 / 主题包完工 gate / 不涉及商业模式底色但仍需检查”分拆搬运是否完备”。

预算：单会话内 5-15 分钟。无需双会话隔离。

流程（参谋长自查 / Owner 不在场）：

  1. 复述清单（参谋长基于本主题包资料自答 6 问）：
    • Q-a 「业务范围一句话」：下游开发者能用一句话讲清楚这个主题包管什么、不管什么吗？
    • Q-b 「角色 + 身份资格」：有几类角色？身份资格的判定字段是什么？是否存在多处口径？
    • Q-c 「主线流程端到端」：从入口到终态需要几步？每步落库什么？有没有”幽灵中间态”？
    • Q-d 「反常识点 3-5 条」：本主题包哪些设计与”常规直觉”相左？写代码不显式遵守必出 bug？
    • Q-e 「失败 / 取消 / 边界 3 个场景」：happy path 之外，每个外部输入是否都有 spec 描述？（强制扫”取消支付/未付订单/资质吊销/配额满”等高频盲区）
    • Q-f 「横向接口位列表」：本包向外开了多少口子？每个接口位对端的契约是否齐备？
  2. 自暴露：上述任一问回答不出 / 找不到唯一权威源 / 多处口径不一 → 即为缺口，登记到主题包 verify 文件
  3. 自查报告：完工时输出 6 问的 Yes/No + 缺口清单 → Owner 审阅 → 通过即可进下一阶段

§ 5b.4 弱信号修订：白名单段级化

消费者测试会话中，精确到段号的引用是否完全在白名单允许范围内，需做段级约束。长会话中”主动遗忘”可能渐进松弛。

修订：

§ 5b.5 与 § 5 标准 W-重的关系

§ 5 = W-重通用流程框架（5 步：业务陈述 → Owner 审视 → verbatim 入册 → 三谱系归位 → 回写）；本节 = W-重在「主题包出关验收」场景的具体执行模板。两者不替代关系：

§ 6 W 协议与开发执行的关系

W 检查 = FLDD 开发执行中的验收检查步（参见 FLDD-开发执行.md §5 验收）。本文件展开检查的判据与样板；FLDD 引用本文件作为验收锚点。

This site is open source. Improve this page.