15. 给当前能力画边界

这本书这套做法，在一类项目上足够用：验收先行、判定器循环、Diff 审查、真实使用、上线检查，串起来能把一个低风险、可回退的工具做到能上线。换一类项目，同样这套方法就不够了，因为错误的代价变了。删错一张报价表能重来，删错一笔转账不能。

这一章不教新技术，教一件判断：怎么看清手上的项目落在能力边界的哪一侧。

五个维度给项目分级

同样是「做个工具」，风险差别可能很大。先用五个维度给它量一量：

维度	代价低的一端	代价高的一端
数据敏感度	公开或脱敏数据	身份证号、病历这类敏感个人信息
资金影响	不碰钱，或可对账可退	直接发起支付、划转资金
用户数量	自己或几个人用	大量用户、需要扛并发
可逆性	做错能重来	操作不可逆，做错收不回
监管要求	无特殊监管	医疗、金融、安全等受监管领域

一个项目在五个维度里越往右，错误的代价越高，需要的专业能力和合规条件也越多。报价整理器几乎全在左端：脱敏数据、不碰钱、少数人用、能重做、无特殊监管。这也正是它适合当主线的原因。

三个区：可做、需要协助、暂不做

按上面的量法，把项目分进三个区：

• 当前可做：五个维度基本都在左端。像报价整理器这样，一个人用这本书的方法就能负责到底。
• 需要协助：出现了共享状态、需要账户、涉及一定资金但可对账可退这类情况。方法还是这套，但要引入专业能力，比如后端、安全或测试工程，不该一个人硬扛。
• 暂不做：支付、敏感个人信息、多租户、高并发、医疗或安全关键决策、无人确认的不可逆操作。这些需要另一套工程和合规体系，超出这本书这套方法能负责的范围。

划分不是一次定死。一个「暂不做」的项目，把敏感部分交给专业方、自己只做低风险的那块，可能就落回「需要协助」甚至「当前可做」。边界跟着项目的实际形态走。

克制不是失败

把一个项目放进「暂不做」，是判断力的一部分。知道一件事现在不该由一个人、用这套方法独自完成，本身就是这本书想教会的判断之一。

反过来也一样，「当前可做」不等于「简单」或「没价值」。一个能真正解决自己重复劳动的小工具，做到能上线、经得起找茬，已经是完整的一件事。边界图的作用是让每个项目待在它该待的位置。

拿真实候选项目量一遍

抽象的五个维度，拿两个真实候选项目量一遍更看得清楚区别在哪：

维度	报价整理器	第 0 章「游戏灯光」MOD 念头
数据敏感度	脱敏后的报价数据	游戏内部状态信号，不涉及个人信息
资金影响	不碰钱	不碰钱
用户数量	作者及身边几个人	作者自己
可逆性	解析错了，重新粘贴原文件即可	灯没反应或者反应错，重启一下就好
监管要求	无	无

两个项目在五个维度上几乎全部落在代价低的一端，这也是为什么它们都被这本书选中：报价整理器当了正文主线，游戏灯光那个念头留在第 0 章当了对照例子。换一个例子更能看出边界在哪。假设报价整理器要处理的不是内部报价，而是要直接对接供应商的自动扣款流程，「资金影响」这一项立刻从左端跳到右端，仅仅这一处变化，就足以把它从「当前可做」推进「需要协助」，即使数据敏感度、用户数量这些维度完全没变。分级的算法是：任何一个维度单独跳到高代价一端，都要重新评估，不是把五个维度加总打一个总分。

留下什么产物

这一章的产物是一张项目边界图：把手上的候选项目，连同第 0 章记下的那些念头，各自放进「当前可做、需要协助、暂不做」三个区，并在旁边写一句落在这里的理由。

第四幕到这里收束：工具进了真实环境，也知道了它的边界在哪。