---
name: worth-fix
description: 分析和判断任何论断、报告、想法或需求的真实性、价值与做法。当用户说"这个 bug 是真的吗"、"分析一下这个问题/这个报告/这个说法"、"这个修复值得做吗"、"帮我看下这个建议靠不靠谱"，或用户给出一个待评估的 bug 报告、文章摘录、设计提案时使用。先核验、复现、定级、讲清原理、判断是否值得做，而不是直接相信或直接动手改代码。也适用于评估"要不要重构"。
---

# Worth Fix（值得修吗——先验证，再判断）

## 核心态度

- **一切论断都是假说**。报告、博客、AI 输出、甚至自己的第一印象，都要过一遍"这是真的吗"。来源可信不等于内容正确。
- **实证优先于推理**。能跑就测，能复现就复现。读代码推断的"应该是这样"不如一次实测的"实际是这样"。只有说"我实测过"才有资格说"坐实"。
- **区分"属实"与"值得修"**。真不代表要动，假也不代表不用查——真实性判断与价值判断是两个独立维度，分开做。
- **敢证伪，也敢修正严重度**。报告夸大（如"栈溢出崩溃"实测只是报错）或缩小，都要如实修正，不将就原文结论。

## 工作流

**环节可裁剪性**：最小复现、核实前提、判定值得、留痕是必须环节；威胁建模、讲清原理、沟通格式按风险/规模裁剪——小 change、一眼看穿的修复可跳过重环节，不必走全套仪式。

### 1. 把论断转成可验证的命题

把"报告说 X 会崩"改写成"当条件 C 满足时，行为 B 是否发生"。一个论断拆成几个可独立验证的命题，逐个验证。

### 2. 最小测试直击真实代码路径

写最小复现（临时测试/脚本），**直接调用真实的生产函数**，不要测试模拟器或复制逻辑。用 `--nocapture` 打印关键中间证据（如"外部文件被复制 = true"）。

复现验证缺陷后，**把同一场景翻转断言固化为回归测试**（红→绿：先证明缺陷存在，修复后证明行为正确）——复现是回归测试的原材料，不是看完现象就扔。临时脚手架可删，场景必须留下。

**复现不可行时**：先评估是否缺少测试注入点（路径硬编码、函数不可注入）或会污染真实环境（写入用户目录、破坏真实数据）。评估后仍不可行，改用结构验证（代码控制流审查 + 全套测试无回归），并**把验证边界记录进交付物**（如 proposal 的 Impact：哪些实证、哪些审查、为什么）——"未实测"必须标注，不得以审查冒充实证。

### 3. 核实推理链上的每个前提

攻击面/缺陷的可达性由多个环节组成（如：归档保留软链 → 解压物化 → 复制跟随）。**每一环都单独验证**，不因"看起来显然"跳过。特别注意验证依赖库的真实行为（读库源码或构造输入实测），而不是按常识假设。

### 4. 判定"属实"程度

对每个命题给出结论分级：**坐实 / 部分属实（有夸大或缩小）/ 证伪**。逐条说明证据。区分"现象为真"与"影响为真"——现象成立但后果被夸大了，要如实修正定级。

### 5. 判定"值得修"

属实 ≠ 值得修。按四维评估：**触发概率、影响面、修复成本、不修的后果**。高成本低概率的排队，低成本高影响的立即做；报告里"属实但不值得修"的条目要明确列出，并说明为什么。不要为了显得勤快而修不值得修的。

四维之外，对**成本极低、影响不明**的项，用后悔不对称补充：将来它若造成影响，那时的后悔（"我明明早就知道"）是否超过现在顺手处理的成本？超过就做——这是"卫生级"修复（死配置键、未捕获的 rejection）成立的判据，纯期望值在此象限给不出答案。预演终局（"将来如何评价这个决定"）只用于不可逆或高成本的决定，且产出是"把最可能被质疑的点提前变成显式取舍"，不是预测结论。

### 6. 讲清原理再动手

动手改之前，先用最简单的话讲清楚根因（"这个 bug 是因为 A 用 stat 而 B 用 lstat，分支顺序错了"），确保听者能复述。讲不清原理就动手，是没想明白的信号。

### 7. 威胁建模

涉及安全/边界时，用攻击者视角推演完整链路：攻击者能控制什么 → 受害者做什么动作触发 → 每一步是否成立 → 最终后果。**诚实分层后果**：区分"确定发生"（无后续动作即成立）与"大概率发生"（还需一个后续步骤），不夸大（不说成自动外传）也不缩小（不说成纯理论）。说明现实摩擦（如需猜测路径、权限失败即回滚），让定级可信。

### 8. 定级与决策

- 定性：崩溃 / 数据损坏 / 越权读取 / 文案错误等，再给严重度（高/中/低）。
- **要不要重构**：先判断是"局部缺陷"还是"架构问题"。单函数内的顺序/解析错误 → 局部修复，明确说"不需要重构"并说明为什么（如"与发现阶段已有防护对齐，属补齐既有架构"）。只有多个模块共用的地基性问题才谈重构。
- 决策要给"一句话总结"：真实、可被谁触发、涉及什么、成本多高、是否需要重构。

### 9. 粒度切分

把大报告/大需求按"一个意图一句话能说清"切分。同意图的相邻小修合并成一个单元，互不相关的拆开；typo 级修复不配仪式（文档、多条需求），别过度工程化。粒度 = 一次 review 的自然单元。

### 10. 留痕

把证据、推理链、勘误（哪些被证伪、哪些被修正）写进项目文档（如 OpenSpec change 的 proposal），让后来的 agent 能复现你的推理，而不只是看到结论。

## 沟通格式（怎么讲清一个问题）

对"这是什么问题"，按此顺序讲，每层都简短：

1. **一句话说明**（用比喻也行，如"传送门文件被钻进去了"）
2. **具体触发链路**（分步，每步可验证）
3. **场景与后果分层**（最重/中等/最轻三档）
4. **不改会怎样**（是持续敞开还是自愈，根源是逻辑还是环境）
5. **小问题还是大问题**（按影响面与信任模型，不按修复成本）
6. **是否需要重构**（明确回答，不模棱两可）

## 反模式

- 盲信报告、引用、或"大家都这么说"
- 只读代码不实测，把推断当结论
- 复现不出就断言"不存在"（复现失败 ≠ 缺陷不存在，先缩小范围或改用结构验证并标注）
- 为复现而复现（复现成本远超收益仍强行复现）
- 现象坐实就顺手把影响也夸大
- 不验证就说"坐实"
- 小 bug 大手术（顺手重构相邻代码）
- 修完不留痕，后来者只能看到 git diff 猜动机
- 为显得勤快而修不值得修的条目

## 检查清单

- [ ] 论断是否已转成可验证命题？
- [ ] 是否写了直击真实代码路径的最小复现？
- [ ] 复现场景是否固化为回归测试（或已记录"复现不可行"的验证边界）？
- [ ] 推理链每一环是否都有实证？
- [ ] "属实"与"值得修"是否分开判定？
- [ ] 原理是否已用最简单的话讲清？
- [ ] 是否做了威胁建模并诚实分层后果？
- [ ] 是否明确回答了"要不要重构"？
- [ ] 低危项是否用后悔不对称审视过（而非仅看当前影响）？
- [ ] 结论是否已留痕（证据回填）？