Files
git-learn/skill-workbench/generated-skills/skills/value-scan/assets/候选清单模板.md
T
zhuyongxin fddefab0c9 Add value-scan and value-dig skills for reverse-engineering value points
- value-scan: read-only breadth inventory of mechanisms in delivered code,

  stopping at the human selection gate

- value-dig: depth write-up of chosen points (feature list, design review,

  refactor plan) with templates and mechanical checkers

- Add skill-workbench design doc for the pair
2026-09-18 18:23:23 +08:00

5.8 KiB
Raw Blame History

⟨域⟩ 域 · 候选价值点(S1 产物)

阶段:S1 枚举(只产出亮点;缺陷不在此阶段——它是深入链路时自然浮现的副产物) 域:⟨模块名⟩(走 S0 ⟨快路 / 慢路⟩:⟨域清单来源⟩) 结构:域 → 链路 → 链路上的机制节点 三层 筛选标准(三条,全过才进):① 是否核心链路 ② 是否符合高级工程师的设计 ③ 写到简历上够不够硬 深度闸门:允许「这个点在讲什么」的业务语言说明;禁止围栏代码块(行内反引号可用)、禁止逐层拆解、禁止取舍复盘(那些属深度阶段) 取材:① 设计说明类文档 ② git log ③ 图查询 / 结构统计 ④ 关键字 grep


闸门状态

本节是 S2 门控的证据——没有它,"停在第几段"无法核查。

段 状态 说明
S0 定范围 ✅ ⟨范围声明一句话⟩
S1 枚举 ✅ 已完成 候选 ⟨N⟩ 条(亮点)+ 剔除 ⟨M⟩ 条
S2 勾选 ⏸ 待人工勾选 请从下面挑 3–6 条;本文件到此为止,未做深度产出

勾选/否决后回写本表(保持 3 列不压列),两种回写形状:

| **S2 勾选** | ✅ 已勾选 | ⟨勾了哪些(★N…)/ 谁日期⟩ → 产出《⟨产物名⟩》 |
| **S2 勾选** | ↩️ 被否决改向 | 否决原因:⟨用户原话摘要⟩ → 改挖 ⟨新目标⟩(入口 A′) |

一、链路总览

一句话:⟨统领句——不是复述流程,而是给出这条链路的主线判断。例:"这条链路的每一段都在把外部系统给的不确定,收敛成我方的确定状态"⟩

读法:⟨一条端到端链路 = …→…→…;下面每个机制都挂在这张图的某个位置上⟩ 图例:★ = 入选的机制节点;未标 ★ 的链路仍属本链路的一环(见第二、三节),只是未列为独立机制。

端到端链路图(★ = 入选的机制节点)

flowchart LR
    subgraph PA["链路 A · ⟨链路名⟩"]
        A1["⟨起点⟩"] --> A2["⟨机制节点⟩ ★1"]
        A3["⟨兜底 / 分支⟩ ★2"]
    end
    subgraph PB["链路 B · ⟨链路名⟩"]
        B1["⟨起点⟩"] --> B2["⟨机制节点⟩ ★3"]
        B2 --> B3["⟨机制节点⟩ ★4"]
    end
    subgraph PC["链路 C · ⟨链路名⟩"]
        C1["⟨起点⟩"] --> C2["⟨终点⟩"]
    end
    A2 --> B1
    A3 -.-> A2
    B3 --> C1
    C2 -.-> A2

⟨可选⟩关键差异表(若这条链路的核心是"几种结果后果完全不同",用一张表压住)

⟨维度⟩ ⟨取值1⟩ ⟨取值2⟩ ⟨取值3⟩
⟨例:对方结果⟩
⟨例:可逆性⟩
⟨例:处置⟩

二、链路上的机制节点(⟨N⟩ 个 ★)

按链路分组。每点 4 段,段落式(不要压成表格——"做了什么"常是 5–7 条,塞进单元格必然被简化)。

链路 ⟨A⟩ · ⟨链路名⟩

★1 · ⟨机制名⟩

核心内容:⟨1 句:这个机制是什么,把它的"形状"说清(一把锁 + 三级短路 + 一条条件更新)⟩

这个点在讲什么

  • 业务场景:⟨谁在什么时刻触发了什么,为什么这事难;点出"同一时刻还有谁在改同一行数据"⟩
  • 做了什么(⟨用一句话概括做法⟩):
    1. ⟨…⟩;
    2. ⟨…⟩;
    3. ⟨…⟩。
  • 解决了什么问题:⟨不做会怎样⟩

一句话价值:⟨1 句,可讲述;说清"判断权 / 控制权"落在谁手里⟩

锚点:⟨简写⟩/⟨路径⟩#⟨方法名⟩


★2 · ⟨机制名⟩

⟨同 ★1 的 4 段结构⟩


链路 ⟨B⟩ · ⟨链路名⟩

★3 · ⟨机制名⟩

⟨同 ★1 的 4 段结构⟩


链路 ⟨C⟩ · ⟨链路名⟩(⟨依附型,未列为独立机制 / 未入选⟩)

本链路 0 个独立机制,但说明不可省——否则图上有个框、没人知道里面在干嘛。

核心内容:⟨它是什么⟩

这个点在讲什么

  • 业务场景:⟨…⟩
  • 做了什么:⟨…⟩
  • 依附关系:⟨它的哪几个设计决策其实是 ★N 在另一个方向 / 另一个域上的复用;判不清就按独立节点处理,不要为了凑数强行依附⟩
  • 为什么未入选 / 为什么依附:⟨★ 必须写清⟩

锚点:⟨…⟩


三、已剔除(附理由,供复核筛选口径)

被剔除的点不丢弃——注明未过哪条标准。

「未过的标准」建议取值:①核心链路 · ②非设计决策(框架常识 / 通用工程质量) · ③简历不硬 · 机制格填不出 · 示例数据 / 字典表 / 配置装配

# 被剔除的点 未过的标准 理由
1 ⟨例:key 命名约定⟩ ①核心链路 不落在业务闭环上
2 ⟨例:Redis GETDEL 用法⟩ ②非设计决策 框架常识用法,非设计决策
3 ⟨例:契约模式 / CI / Checkstyle⟩ ②非设计决策 通用工程质量,无设计含量
4 ⟨例:表 CRUD / 单表封装⟩ 机制格填不出 弱候选,并入本表待复核

四、待确认 / 覆盖缺口

# 项 说明
1 ⟨链路名⟩ 0 个节点 ⟨先问"真没亮点,还是采样不到位"(回看该链路的触发者与写类接口);判不清就写明理由⟩
2 ⟨路径⟩#⟨方法名⟩ 【待确认】⟨拿不准的锚点必须标出,禁止猜⟩
3 文档 vs 代码分叉 ⟨设计文档写的方案在代码里是否落地?不落地本身就是高价值点⟩