宜博 / lemonboss

sample_verification.md 7.37 KB

自我验证样本 v1 — workgraph-planning-methodology-trial

对应任务书用户步骤6，套用 SKILL.md v1（100分定稿版）的决策流程。 两个样本复杂度梯度差异明显：样本1是全公司唯一与 Step4 裁剪例句直接可比的 真实历史案例，样本2是构造场景（非真实历史案例，下文已按要求显式标注）。

样本1：回归案例 C4（p-v1mpcl / T-mt1qx0c4-95bf，真实历史案例）

task-goal 原文（hunt/knowhow_v1.md C4 引用）：「读 lemonboss 仓库文档+代码， 产出 apple.com 风格的静态官网，讲清 why/how/what，含核心价值点、功能模块、 独特性说明，至少 3-4 张界面截图/示意图配说明」。

信号取值（复用 digest/complexity_signals_v1.md 自身给出的 C4 校准结果）

信号 取值 判定依据
S1 1 全部内容共享同一个网站、同一套验收标准，单一交付物
S2 是 "至少3-4张界面截图/示意图配说明"是可枚举的具体数值清单
S3 否 纯展示型静态页面描述，原文无持久化/多模块字样
S4 否 通篇没有提及需要说服的第二方（投资人/产品经理/安全团队等），单一执行链路
S5 否 未提及任何历史参照/复用指令

代入决策流程

  1. G2（S3门）：S3=否 → 不命中，继续。
  2. G3（S5门）：S5=否 → 不命中，继续（此样本写于 S1-S5 体系引入之前， 也不存在"先例"这个概念本身，即便 S5 被误判为是，也会因为找不到标注过 S1-S4 的先例记录而按 fallback 归为 S5=否）。
  3. 逐节点判定：
    • brd：查表 §2.1，S4=否, S1=1, S2=是 → 命中第3行 → 裁剪。
    • prd：§2.2 恒定 → 保留。
    • sdd：§2.3，S1=1（且已知S3=否） → 内容精简，节点保留。
    • benchmark：§2.4 恒定 → 保留。
    • validator：§2.5 恒定 → 保留。

最终结论：裁 brd，保留 prd/sdd(精简)/benchmark/validator。

与任务书给出的预期结论一致（"预期：裁brd，因为S1=1/S2=是/S3=否/S4=否"）。

应用 §四 连带修正清单，重新验算五项校验

裁剪后节点：prd, sdd, benchmark, validator（4个）。边：

from to condition 其他
prd sdd success produces:[prd]
sdd benchmark success produces:[sdd], needs:[prd]
benchmark validator success produces:[acceptance], needs:[{kind:brd,required:false}, prd, sdd]
sdd prd fail edgeKind:backward
benchmark sdd fail edgeKind:backward
validator prd fail edgeKind:backward, failReason:input_underspecified
validator sdd fail edgeKind:backward

（原 prd --fail--> brd 已按 §四 第2条删除。）

# 手工验算法 结果
1 划掉 backward 边，剩 prd→sdd→benchmark→validator，可排出拓扑序 通过
2 forward 入度为0的节点：仅 prd 通过（恰好一个）
3 从 prd 沿 forward 边 BFS 覆盖 sdd, benchmark, validator 通过（4个节点全覆盖）
4 sdd→prd、benchmark→sdd、validator→prd、validator→sdd 的 to 均排在拓扑序更早处，且都标了 backward 通过
5 除入口 prd 外：sdd 有 sdd→prd（空failReason）兜底边；benchmark 有 benchmark→sdd（空failReason）兜底边；validator 有 validator→sdd（空failReason）兜底边（另一条 validator→prd 带 failReason，不计入但不冲突） 通过

五项全部通过，prd 作为新入口按约束五例外条款无需额外配兜底边。

合理性检查

结论"裁brd、保留其余四个"符合直觉：这是一个单人产出、无需向第二方解释立项 理由、验收标准已经写清楚的静态网站任务，把"why"并入 PRD 前言段不会丢失信息 （原 C4 真实规划记录选择完整保留是"骨架字面结构对应"式判断，而非信号驱动， complexity_signals_v1.md S4 段已指出这一点——本表刻意不重复这个失效模式）。 没有出现"简单任务被误判为要保留全部/复杂任务被误判为可裁"的情况。

样本2：构造场景（非真实历史案例，用于压力测试规则的另一端）

task-goal 原文（构造）：「多租户 SaaS 后台，含权限体系（多角色 RBAC）与数据 导出功能，需要向产品经理和安全团队分别汇报设计方案」。

信号取值

信号 取值 判定依据
S1 1 "权限体系"和"数据导出功能"是同一个后台系统内的两个功能模块，原文没有说

它们各自有独立的验收标准或独立受众，按 complexity_signals_v1.md S1 判定法 （"两个产出物只有在验收标准不同或受众不同时才分别计数"），算同一个交付物 | | S2 | 否 | 原文只有"多角色RBAC""数据导出功能"这类定性描述，没有出现具体数字/ 可穷举清单（没有说"3种角色""导出为CSV/Excel两种格式"这类可点名的清单） | | S3 | 是 | "多租户""权限体系（多角色RBAC）""数据导出"均指向需要持久化存储 （租户数据、角色权限、待导出的业务数据）和多模块（权限模块+导出模块），命中 complexity_signals_v1.md S3 判定法里的"账号体系""对接接口/后端"类结构性字样 | | S4 | 是 | 原文显式提到"需要向产品经理和安全团队分别汇报设计方案"——两类需要 独立说服/汇报的第二方角色，命中 S4 判定法 | | S5 | 否 | 未提及任何历史参照/复用指令 |

代入决策流程

  1. G2（S3门）：S3=是 → 命中，直接判定全部5节点保留，决策终止， 不再往下走逐节点判定。

（补充核对：即便不走 G2 短路、继续假设走到逐节点判定，§2.1 BRD 表里 S4=是 那一行同样独立给出"保留"结论——S3 和 S4 两个独立信号在这个样本上 互相印证，没有矛盾，这也说明 G2 门的短路不是掩盖了一个本会冲突的判断， 只是提前给出了同一个答案。）

最终结论：全部5节点（brd/prd/sdd/benchmark/validator）保留，不裁剪。

与任务书给出的预期结论一致（"预期：全部5节点保留，不裁剪"）。

五项校验

因为没有任何节点被裁剪，图与 planner.json 骨架原样一致，五项校验天然 满足（骨架本身已验证合法，不需要重新手工验算）。

合理性检查（矫枉过正压力测试）

这个场景刻意设计了两个会让"裁剪判据"过度敏感的诱饵：

  • 如果规则集只看 S1/S2/S4 这类"内容形态"信号而忽略 S3，可能会因为"S4=是" 之外没有仔细检查 S1（单一后台系统，容易被误判成"简单交付物"）而错误地 在 benchmark/sdd 上打折扣；
  • 如果规则集的裁剪判据里没有把 S3 设成最高优先级的硬门，可能会在"这是一个 后台管理系统，描述听起来不算复杂"这种主观印象下裁掉不该裁的节点。

本表的 G2 门直接堵死了这两种矫枉过正的可能——只要 S3=是，不管 S1/S2/S4 如何组合，都不会进入任何裁剪分支，验证了 §五（benchmark_v1.md D5 矫枉过正 平衡）声称的"地基级约束不受信号组合影响"在这个复杂样本上确实成立，没有 出现"复杂场景被错误裁剪"的情况。