残值重构法

它解决什么问题

工程师启动新项目时的第一反应往往是采购：买新硬件、订阅付费 API、引入重型框架。但很多东西早就躺在抽屉里——旧手机、弃用的代码模块、免费的公开数据源——只是没人从功能角度重新拆解它们。更隐蔽的成本是试错恐惧：原料越贵，越不敢改；方案越复杂，越难在早期验证方向。

残值重构法（RVR）把这个问题拆成三层。第一，观念性依赖：多数“必须买 X 才能做 Y”是过度采购，极端约束下人会用日常品的隐藏属性替代。第二，经济闭环：东西做出来不等于有人用、有人愿意换或付钱。第三，功能维度混淆：一个需求往往由多个独立维度构成，笼统问“能不能替代”得不到有效答案。

技能如何工作

RVR 默认从丐版约束（极端）启动，再逐级放松到印度级（中度约束，要经济闭环）和普通级（轻度约束，解决自己的具体问题）。这个顺序不是苦行，是为了在接触真实资源前先堵住“给自己找理由买新东西”的口子。

核心循环是五步：

• 存量审计：列出边界内全部资源，逐项拆出 2–3 个隐藏属性。拆不出实用属性的资源说明残值耗尽，直接放弃。
• 功能拆解：把需求拆到不可再分的基本功能单元，每个单元标注最低可接受水平，而不是“最好能达到什么”。
• 属性-功能匹配：把隐藏属性与功能单元配对计算覆盖度。≥60% 可转化；40–60% 需要补充资源或进一步降级；<40% 换方向。
• 转化路径设计：编排“资源 → 加工动作序列 → 成品”，每步工具必须在边界内，每步有明确验证点。找到 ≥2 条路径就做比较，不押注唯一方案。
• 低代价迭代：每次只改一个变量，记录“什么不行”而不是“为什么不行”。连续 3 次达到最低可接受水平即达标；不达标就回到第 2 步继续拆细需求。

贯穿全程的是吝啬度检查清单：采购前逐条确认功能是否必须现在做、边界内是否有替代、能否降级绕过。全部不能才买，且只买最低配置。

三条原则支撑整个流程：任何物品都含未定价的隐藏属性（残值 = 物品属性总数 - 市场已定价属性数）；廉价原料换试错空间；功能降级到“能用”而非“好用”——好的服务器变成能跑脚本的旧手机，好的图表变成能传达数据的简单 HTML。

适用边界与注意点

RVR 有红线，安全和健康不可降级。 以下场景禁止使用：侵入性人体操作、食品安全失控（无法灭菌的发酵）、无绝缘的高压或裸线入水电路、破皮化学品接触、功能成功率不足的方案。红线场景不是“尽量小心一点”，而是此路不通。

适用：个人项目与独立开发、数据管道和量化模型原型、硬件原型验证、分析拆解类产出、副业冷启动。

不适用：合同交付、高频交易实盘、生产级 SaaS、合规行业（医疗/航空/金融）、任何涉及人身安全的实验。

RVR 不走完全程。 它的终点是“普通级的功能可用”——一张转化路径地图和一个能跑的原型。之后的产品迭代、规模化、工程化、合规化，应交给精益创业、敏捷开发、DevOps、行业标准认证等方法论，不要用 RVR 硬扛。

性价比评估时，首选参照是工厂批发价而非零售价，因为 RVR 要砍的是品牌、渠道、包装溢价。当外部正经方案被场景规则禁止时，参照物自动切换为“什么都不做”的基线状态，ROI 计算的重点是体验改善而非货币节省。

最后注意许可证传染：RVR 产出物的合规性由输入决定，输入了 GPL 代码则输出也必须遵守 GPL。