客户对本地化的要求，很多年都没变过：
- 质量更高
- 周期更快
- 成本更低
这个三角并不新鲜。真正变化的是，旧的交付模式现在会更快在这种压力下失控。
当本地化交付被速度、质量和成本同时拉扯时，真正的瓶颈往往不是“人不够”，而是连接人、工具和复审决策的系统层设计不对。
这也是为什么，单纯加人头现在越来越不是一个强解法。
“自己做一套系统”很多时候是错误反应
当工作流开始出问题，很多团队的第一反应是：
“那我们自己做一套吧。”
这个冲动可以理解。现成工具很少和内部流程百分之百贴合。
但很多时候，完全重做并不是正确答案。尤其当团队试图自己重建这些东西：
- CAT 编辑器能力
- 工作流编排
- 术语系统
- 复审路由
- 报表层
很快就会从“优化交付”变成一个巨大的技术项目，而真正的内容流问题还在原地继续发生。
很多情况下，更好的答案不是“自己做还是买现成”，而是：
在现有工具之间建立一层更清晰的控制逻辑。
系统不对的时候，最先坏掉的是什么
当交付模型不对时，症状通常会非常明显：
- 速度还可以，但稳定性差
- 质量靠 PM 个人救火维持
- 术语跨项目漂移
- 复审意见很难追踪
- 团队不知道真正的延误是从哪里开始的
这些问题很容易被误判成：
- 供应商执行不行
- 工具不够强
- 译员质量不稳定
但更深一层往往是：工作流缺了一层真正的“交通控制”。
任务进入系统、流转、被复审、被退回，但中间缺少足够编排，所以不管参与者是内部、外部、人工、辅助自动化还是混合模式，最终都会被同样的摩擦拖住。
更好的系统，不是替换所有组件，而是把它们编排好
更强的交付模型通常是模块化的。
意味着：
- 保留已经做得好的核心系统。
- 在可见性和控制缺失的地方，加轻量工作流逻辑。
- 按内容风险和复审需求做不同路由。
- 把报表和决策追踪视为交付的一部分，而不是事后补。
这正是 middleware 或中间控制层真正擅长做的事。
它不是要变成所有工具，而是要让现有工具、人员和检查点组合得更有效。
所以今天更好的交付，不是简单“让机器替代人”，而是让人和系统之间的互动方式更合理。
真正的收益，是在压力下保持控制
更好的系统不会神奇地消灭这个三角。
但它会减少三角内部的浪费：
- 更少可避免的复审回路
- 更清楚的责任归属
- 更可复用的术语决策
- 更清晰的高风险/低风险内容分流
- 更透明的交付状态
这些收益不会让三角消失，但会让它更可控。
没有这一层，团队就只能反复用人工方式解决同一个问题。
当本地化交付看起来进入“不可能三角”时，答案往往不是加更多人，也不是推翻重建一切，而是在现有工具、工作流和复审决策之间补上一层更强的操作系统。
应该先从哪里问
如果你的交付模型已经在吃压，先问一句：
今天工作流到底是在哪一步开始失控的？
常见答案包括：
- intake 太松
- 路由不一致
- 复审责任不清
- 术语决策没复用
- 团队看不到延误真正发生在哪里
这些首先是系统问题，不只是 staffing 问题。
如果这听起来很熟，可以先把你现在的流程对照一下我们的如何交付，再用服务结构去看：你真正缺的，可能不是更多语言资源，而是更强的交付控制层。