三年前我接手过一个物流仓储系统的重构。团队老大拍板用外包，理由是“省人力”“快”。我们找了一家看起来挺正规的波兰公司，报价比国内低三成，TDD、CI/CD、Code Review全部写在合同里。我当时还觉得捡到了宝。结果呢？第一个里程碑就晚了三周，代码仓库commit信息乱七八糟，有三分之一是“fix bug”，没有配套测试。我们拿着合同去谈，对方表示“我们理解的定义可能不同”。后来我才明白，合同里写的是“交付源码”，但没说清“什么样算完成”。代码是能跑的，只是没法改。你没法说他没交，但你要的那种“可维护性”，根本不在交易范围内。
这件事让我开始重新想外包这件事。很多人说外包是买别人的技术，其实不对。外包真正买的，是对方愿意承担一部分你那边的“不确定性”的能力。但问题是，不确定性有两种：一种是技术上的，比如这个算法能不能实现，这个性能会不会瓶颈；另一种是认知上的，比如需求到底对不对，业务逻辑有没有漏洞。外包能帮你扛第一种，但第二种他们永远扛不动，甚至还会反过来增加你的成本。因为他们不在你的业务场景里，他们只能按你写的字面意思理解，你写着“支持退货”，他们做出来就是简单的状态翻转，而没想到退货还涉及库存、结算、防作弊。这不是他们蠢，是认知错位。
后来我学乖了。再找外包，我不再看他们的技术栈和报价单，而是看他们在需求评审现场问的问题。有一家越南团队让我印象很深，他们针对物流单号的唯一性问了我四十分钟，从并发问到多仓库，最后问出我们没考虑过的幂等场景。那一刻我突然意识到，外包团队的价值不在写码，而在于他们能替你把需求里的“我以为”变成“可验证”。但这种团队太难遇了。大多数外包是流水线式的，你给需求他就估点，你催进度他就加班，你提bug他就修，像一台没有温度的执行器。你很难怪他们，因为付的价格就是执行价格，你却指望他们带来超出定价的思考。这种矛盾，本质上是我们自己既想省钱又想要认知资源，怎么可能呢？
现在我处理外包的方式有点像买期权。我不再预设他们能理解业务，而是主动拆碎需求到最原子的逻辑单元，每一条都是一个明确的输入输出，甚至样例数据都备好。然后我会要求他们只做实现，不要做任何决定。同时我会在合同里写明“可运行”和“可演进”的区别，验收标准里包含注释规范、模块独立性、没有隐藏依赖。听起来很累，但比事后扯皮轻松。外包从来不是帮你省事的捷径，它只是把你要操的心提早打包了一下，你没付出的思考，后面都会以另一种方式找回来。