一家拥有 80 人的物流公司，服务多种 B2B 客户类型。三年间，内部产品需求持续累积 ——调度工具、报价流程、异常处理、客户门户——每一条都是业务团队的真实需要， 每一条都因为开发流程缺乏共同的规范层而陷入停滞。需求从提出到可用，往往需要 十二到十八周。大多数从未抵达终点。
我们没有从积压清单入手，而是从清单背后的规则入手。无论客户类型还是承运商， 每一份报价必须包含什么？哪些异常绝对不能绕过人工调度员自行处理？两条不变量 由此浮现。其余——功能优先级、原型排序、面向客户的配置——属人而定。不变量一旦 从桌上拿走，判断就快了。
两条不变量，一条清晰的边界
第一条不变量：任何影响服务水平协议的异常，必须路由至人工调度员。不是队列， 不是启发式规则，而是一个人。第二条：每份报价必须将成本、交期、承运商约束与 客户承诺记录在同一处——不分散在三个工具里，不从邮件中重新拼凑。
这两条规则从未被写下来。一旦写下，积压就变成了一个排序问题，而不再是判断问题。
“这是第一次，业务团队提的需求没有掉进黑洞。” ——匿名 COO
这套 harness
我们交付的不是一套优先级框架。我们交付的是一套运行的系统：一条将每条内部需求 引导经过决策追踪的规范到原型流水线——需求、规范、原型、上线——产品团队和业务 团队都看得到。追踪记录即审计档案；有了档案，同一决策就不必反复争论。
在 2026 年第一季度的 30 天集中投入中，约 120–150 条未关闭的 P0 和 P1 内部 需求被全部清空。从内部需求到可用原型的中位时间，从约 45 天降至 7 天以内。 客户满意度在上线后 60 天窗口内以客户成功调查衡量，从 70 分升至 93 分（满分 100）。 这不是一次冲刺的产物；它是两条不变量交给代码之后、属人的判断终于有了呼吸空间时， 自然发生的结果。