worth-fix

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 猜动机
• 为显得勤快而修不值得修的条目

检查清单

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