melech-roi

ROI

核心问题

用一个故事讲清楚：

你的水龙头在滴水。修法 A 是重新铺设整栋房子的管道，让这个水龙头不再滴水。修法 B 是更换这个水龙头里的垫圈。两种方法都能止住滴水。但只有一种会导致以后每个水管工都得先弄明白整栋房子新铺的管道，才能有朝一日修理另一个水龙头。

就是这么回事。这就是全部要点。它每次只问：

我们是在重新铺设整栋房子的管道，还是在更换垫圈？

• 更换垫圈 — 在确切的漏水点进行局部、范围明确的修复。
• 重新铺设整栋房子的管道 — 为解决一处滴水而触及共享边界、引入新的持久化状态或生命周期，或造成广泛影响。

melech-roi 的作用，是识别那些伪装成第一种、实则属于第二种的方案——无论是针对已有代码，还是尚未编写的想法。它评估眼前的方案；不会设计替代方案。

如果你交流的对象无法理解管道的比喻，同一个问题还有四种其他日常比喻（打包、装修许可、工具箱、衣物修改），见 references/analogies.md。

它评估什么

收益 — 滴水问题实际有多严重、影响有多广（涉及多少用户/路径）、出现频率如何、修复能持续多久，以及战略价值有多大。

负担 — 这次改造会影响房子的哪些部分：触及的共享边界、新增的持久化状态或生命周期、回归风险、未来维护者必须了解的新概念，以及可逆性。

结论 — 负担是否与收益相称，还是为了止住一处滴水而改造了整栋房子？

账单 — 方案的 ROI 从哪里赚得、又在哪里损失：问题影响范围与方案影响范围、获得的价值、付出的成本，以及最大的那笔成本。

可以让它评估的来源

• 现有 PR（差异 + 描述 + 讨论），
• 本地差异（已暂存/未暂存、分支与基准的对比），
• 仍只在对话中讨论的想法或方向——尚无差异，因此应降低置信度，并明确指出哪些内容属于假设。

根据上下文判断来源。只有在确实无法确定时才提问。

工作流

1. 说清滴水问题。 用一行说明正在追求的实际收益。如果收益本身不明确或尚未得到验证，应标记低置信度，并指出缺少哪些证据。不要默默编造收益。
2. 追踪涉及的范围。 对代码：共享模块、持久化状态、公共契约、新依赖、调用点、概念。对想法：建成后需要触及哪些部分。
3. 用相同的单位比较影响范围。 并列说明谁会遇到问题，以及谁必须承担方案带来的影响：路径、调用方、用户、作业、记录，或其他有依据的单位。用 unknown，不要伪造精确度。
4. 逐项列出账单。 列出实际获得的价值和永久付出的成本。将成本严重程度标记为 LOW、MEDIUM 或 HIGH。
5. 找出最大的一笔成本。 指出最明确的不成比例之处，或解释为什么广泛的影响范围是合理的。
6. 评定当前方案。 分数衡量的是比例是否恰当，而不是开发者离想象中的完美实现有多近。
7. 只对已有候选方案排序。 如果 PR 或讨论中已经包含多个具体方案，就对这些方案进行评估和排序。绝不要为了完成排序而编造替代方案。
8. 呈现账单。 使用视觉规范，并调整 references/output-examples.md 中的示例。

输出格式

默认输出为一份分项收据：

1. 方案名称；
2. ROI 评分和等级；
3. 仅当已提出两个或更多方案时，才给出排名；
4. 以可比较的单位显示问题影响范围和方案影响范围；
5. 获得的价值；
6. 收取的成本及其严重程度；
7. 最大的一项成本；
8. 用一句话评述当前方案。

收据用于诊断，不用于提出建议。不要添加替代设计、改进计划或“改为这样做”一节。

等级含义保持一致：

• A（85–100）： 负担与收益明显相称。
• B（70–84）： 值得采用，但存在实际且有限的成本。
• C（55–69）： 能解决问题，但影响范围或复杂度存在明显失衡。
• D（40–54）： 负担超过已证实的收益。
• F（0–39）： 严重失衡，或大多缺乏依据。

仅在等级边界附近时使用 + 或 −。开发者无需达到 100；等级要回答的是：此方案是否与其收益相称。分项成本会解释原因。

在输出结果之前，请阅读 references/output-examples.md。其中包含失衡、合理、运维成本高、有排名以及置信度较低的方案示例。

与其他技能的边界

• melech-distill-need — 当收益本身存疑时，确认问题是否确实存在。
• melech-8020 — 在 melech-roi 诊断出失衡后，设计更低成本的方案。melech-roi 本身不提出这种方案。
• melech-tidy — 在 melech-roi 对现有 diff 评级后，执行自适应 diff 缩减（清除无用残留、缩小接缝的影响范围，并精简臃肿的提示词）。melech-roi 负责评估；melech-tidy 负责修改。
• melech-challenge — 用开放式问题对整个方向进行压力测试。melech-roi 只问一个范围更窄的问题：被触及的部分是否与收益相称。

典型流程：melech-distill-need → melech-roi → melech-8020 / melech-tidy。

应做与不应做

应做： 将“一个提交入口”与“47 个请求路径”并列展示，然后把共享中间件、持久化状态和清理生命周期逐项列为成本。

不应做： 只写“ROI：58%”，却不提供收据说明 ROI 损失在哪里。

应做： “这个 Bug 会出现在每个提交数据的入口——在这里，共享修复确实匹配共享收益。这并未过度扩展；可以继续。”

不应做： 仅仅因为某个修复涉及共享代码，就硬给真正具有系统性的问题打低分。

应做： 对于尚未编码的讨论稿构想：“这仍只是一个方向，而非 diff——置信度较低。提案会产生的永久性共享服务成本，证据比能从中受益的工作流数量更充分。”

不应做： 在证据未提供依据时，编造精确的影响范围数量、候选方案或替代设计。