01-G7用户价值门转化.md

结论先行

建议新增 G7 用户价值门，但当前只能形成“待原则原文对齐的执行草案”，不能认定已完成《产品原则 v2》到 R8 的正式转化。

依据：材料中“10 条设计纪律、4 条不可售卖红线、双指标、两道闸门”均只有占位说明，没有实际条文；现有功能实现、测试结果和运行数据也未提供。

因此本次交付分三部分：

  1. 纪律三分类规则及落地方式：可直接用于逐条拆解；具体条目归类待原文补齐。
  2. 四红线核查台账：逐条标记“风险未定级、验收阻断”，不把缺证据误判为低风险或已触碰。
  3. G7 草案 8 条：明确验证方式、责任席和阻断规则，可先建验收任务。

以下新增机制均为建议方案，不是材料中已存在的能力。

① 纪律条目三分类：按“最小约束”拆，不强迫整条单选

判断：一条纪律可以同时产生自动化判据、人工口径和设计期约束。

依据：原则通常同时包含行为要求、价值判断和方案限制；整体只归一类，容易漏掉可验证部分。具体十条是否如此，材料未涉及。

分类与转化规则

分类归类条件可执行交付物验收或前置通过条件
自动化判据输入、预期结果及边界条件可明确，且结果可由系统观测测试用例、固定数据、脚本断言、结果报告指定范围全部断言通过；缺样本、未执行不能算 PASS
人工验收口径涉及用户理解、任务完成、信息表达等判断，不能可靠地只靠脚本确认明确任务、操作步骤、正反例、通过条件、证据模板指定验收人按统一口径完成核对，并留存可复查证据
设计期约束约束商业模式、能力边界、架构或方案选择，需要在施工前决定派工单前置 checklist、方案审批记录、禁止项未完成审批不得开工；方案变更后重新审查

设计期约束不在 G7 中重新做一遍方案评审，但应检查审批记录是否存在、交付是否偏离审批。

依据：用户已明确这类约束应进入派工单前置；仅做前置而不检查交付偏离，则无法形成闭环。

十条纪律的当前归类状态

原文条目当前状态必须补齐的内容
D01—D10，共十条逐条归类待定，不能据标题猜测原文、适用用户与业务域、禁止/必须行为、例外条件

建议直接建立一张转化表，每个“最小约束”占一行：

纪律编号 → 原文片段 → 适用域/用户角色 → 最小约束
→ 自动化/人工/设计期 → 通过条件 → 正反例
→ 责任席 → 证据位置 → 对应门禁

与 G1—G6 的关系：复用工程证据，不重复建设同类门禁。

依据：材料已明确 G1—G6 覆盖交易链、租户上下文、白标、DSL、发布、回退。若某纪律涉及这些能力，G7 引用对应测试结果，再补用户价值判据即可；工程通过本身不等于用户价值通过。

② 四红线逐条风险评级：当前均“未定级”，不得直接认定触碰

当前可给出的正式判断

红线条文及功能映射触碰结论风险评级当前处置
R01材料未涉及无法判断已触碰或临近触碰U：未定级阻断红线合规结论，补原文与实现证据
R02材料未涉及无法判断已触碰或临近触碰U：未定级同上
R03材料未涉及无法判断已触碰或临近触碰U：未定级同上
R04材料未涉及无法判断已触碰或临近触碰U：未定级同上

依据：四条红线原文、功能清单及实现证据均缺失。U 是证据不足状态，不是低风险，也不是已经违规。

建议规则：U 不允许签署“红线检查通过”，但不阻断与该结论无关的工程施工。

补齐材料后采用的评级口径

等级明确判定条件动作
严重：已触碰有证据证明当前实现或可售卖配置违反红线原文禁止相关能力售卖/发布；已上线则立即进入处置流程
高：临近触碰已存在进入禁止状态的配置或操作路径，且缺少强制拦截补控制与负向测试后再放行
中：控制脆弱暂未发现违规，但主要依赖人工约定，或关键防护未经验证整改并补证；是否放行由已确认红线口径决定
低：已验证受控正常、异常及绕过路径均有证据证明不会进入禁止状态纳入回归监测
U：未定级原文、范围或实现证据不足不得以“未发现问题”代替通过

材料点名的两个功能面：先核查，不预判

这两个例子不能替代四条红线，也不能假设分别对应哪一条。

核查对象当前判断与依据立即索取的证据建议责任席
评价体系／防伪评价U；材料只提出问题，未说明是否有机制评价写入入口、资格校验规则、代写/导入/修改权限、审计记录；按原文测试伪造与绕过路径评价域负责人＋测试负责人
曝光／竞价U；材料未说明是否按竞价，也未给相关禁售口径排序规则、付费权益、配置开关、运营调整权限、排序决策证据；对比付费与非付费路径排序域负责人＋商业化产品负责人

责任席为建议角色，实际任职者材料未涉及。

③ G7 用户价值门草案：8 条判据

定位：G7 检查“交付是否兑现已确认的用户价值与产品边界”，不替代 G1—G6。

依据：材料明确现有门禁缺用户价值维度；但价值定义必须来自原则原文，不能由验收脚本自行发明。

下表责任席均为建议设置；冈子的依据是材料明确其承接原则定稿，小齐的依据是其维护现有验收脚本。

编号判据及 PASS 条件验证方式责任席
G7-01 原则覆盖完整十条纪律和四红线全部拆解、映射到适用范围与验收/前置约束，无悬空条目；不适用项有书面依据自动化检查映射完整性；人工确认映射语义冈子／产品原则责任席
G7-02 用户任务兑现本次范围内，每个适用用户角色均有经产品确认的核心任务；在约定起点、步骤限制和完成条件下，代表性用户能完成任务，无阻断性失败人工任务测试为主，辅以端到端脚本；保留记录业务域产品负责人
G7-03 用户理解一致对适用的关键结果、限制及商业条件，用户能按预先定义的答案要点正确说明；界面承诺与实际结果一致人工任务后核对；脚本辅助检查界面与配置一致性用户研究／体验责任席
G7-04 四红线不可进入每条红线均完成入口与权限映射，正常、异常、配置切换及绕过用例全部通过；不得存在 U 或未关闭违规项自动化负向测试＋人工商业方案审查产品原则责任席；各域研发提供证据
G7-05 双指标可复核原文规定的两项指标均有定义、计算公式、数据源、观察窗口及通过阈值；样本可重算且读数符合已批准标准自动化重算；人工确认口径和阈值数据负责人＋产品负责人
G7-06 两道闸门生效原文规定的两道闸门均明确触发条件、放行权限和拦截行为；满足及不满足条件的测试均符合预期系统闸门做脚本测试；流程闸门做人工演练产品原则责任席＋对应流程负责人
G7-07 设计约束未偏离所有设计期约束均有施工前审批；交付与审批版本一致，变更已重新审批人工差异核对，脚本辅助校验版本关联产品交付架构师
G7-08 适用域证据齐全本次交付域逐域完成适用性判断；适用判据全部有本域证据，不适用有批准依据；白标、配置变化不破坏用户价值判据自动化聚合域级结果；人工审核不适用项各域负责人；小齐负责脚本接入

三项必须显式保留的待补内容

直接派工与放行规则

派工顺序

  1. 冈子／产品原则责任席：补齐并冻结原则基线。

交付原文、十条纪律编号、四红线编号、双指标及两道闸门定义。依据：这是全部判据的来源。

  1. 产品交付架构师＋各域负责人：完成约束拆解与功能映射。

先核查评价、曝光两个已被点名的功能面，再覆盖本次施工域。依据：材料已提示这两个核查方向，但未证明风险事实。

  1. 测试及数据责任席：补齐通过条件、正反例与证据模板。

未定义阈值的项目保持“待定义”，不能进入执行后再解释。依据：R8 要求脚本可验或人工口径明确。

  1. 小齐：将 G7 结果聚合接入 acceptance_gate.py。

人工判据由签署记录输入，脚本检查记录完整性，不以“文件存在”冒充内容合格。

建议门禁规则

PASS    = 所有适用判据通过，且证据与责任签署完整
FAIL    = 任一明确判据不满足
BLOCKED = 原文、阈值、证据或必要签署缺失
N/A     = 经批准的不适用；不是 PASS

R8 放行条件建议为：G1—G6 全通过，且 G7=PASS。 若现有脚本仅支持二值输出，则将 BLOCKED 映射为非通过，并保留原因码。

最后一项范围提醒：38 人日只被说明为“38 域适配”估算已批，是否包含 G7 新增工作，材料未涉及。 应把新增测试、数据埋点和人工验收工作单独列为增量评估，不能默认原预算已覆盖。