- 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
5.8 KiB
⟨域⟩ 域 · 候选价值点(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 · ⟨机制名⟩
⟨同 ★1 的 4 段结构⟩
链路 ⟨B⟩ · ⟨链路名⟩
★3 · ⟨机制名⟩
⟨同 ★1 的 4 段结构⟩
链路 ⟨C⟩ · ⟨链路名⟩(⟨依附型,未列为独立机制 / 未入选⟩)
本链路 0 个独立机制,但说明不可省——否则图上有个框、没人知道里面在干嘛。
核心内容:⟨它是什么⟩
这个点在讲什么
- 业务场景:⟨…⟩
- 做了什么:⟨…⟩
- 依附关系:⟨它的哪几个设计决策其实是 ★N 在另一个方向 / 另一个域上的复用;判不清就按独立节点处理,不要为了凑数强行依附⟩
- 为什么未入选 / 为什么依附:⟨★ 必须写清⟩
锚点:⟨…⟩
三、已剔除(附理由,供复核筛选口径)
被剔除的点不丢弃——注明未过哪条标准。
「未过的标准」建议取值:①核心链路 · ②非设计决策(框架常识 / 通用工程质量) · ③简历不硬 · 机制格填不出 · 示例数据 / 字典表 / 配置装配
| # | 被剔除的点 | 未过的标准 | 理由 |
|---|---|---|---|
| 1 | ⟨例:key 命名约定⟩ | ①核心链路 |
不落在业务闭环上 |
| 2 | ⟨例:Redis GETDEL 用法⟩ |
②非设计决策 |
框架常识用法,非设计决策 |
| 3 | ⟨例:契约模式 / CI / Checkstyle⟩ | ②非设计决策 |
通用工程质量,无设计含量 |
| 4 | ⟨例:表 CRUD / 单表封装⟩ | 机制格填不出 |
弱候选,并入本表待复核 |
四、待确认 / 覆盖缺口
| # | 项 | 说明 |
|---|---|---|
| 1 | ⟨链路名⟩ 0 个节点 | ⟨先问"真没亮点,还是采样不到位"(回看该链路的触发者与写类接口);判不清就写明理由⟩ |
| 2 | ⟨路径⟩#⟨方法名⟩ |
【待确认】⟨拿不准的锚点必须标出,禁止猜⟩ |
| 3 | 文档 vs 代码分叉 | ⟨设计文档写的方案在代码里是否落地?不落地本身就是高价值点⟩ |