十个人服务一百六十多个国家：小团队的交付面要砍到哪一步
一、”人效奇迹”这个读法是错的
据公开报道，有一支十人左右的团队，其做出来的产品被称覆盖了上百个国家。这类消息传开，最常见的解读是”AI 时代人效太高了，十个人能干过去一百人的活”。我们做软件交付和云服务的，看到这种读法会本能地警惕，因为它把一个工程决策问题读成了个人能力问题，而后者既不可复制，也不该复制。
真实的情况几乎相反：人少不是因为每个人干得多，而是因为交付面被主动、成建制地砍掉了一大片。一个产品能被一百多个国家的人使用，不等于它在一百多个国家都被”服务”过。使用和服务是两回事——服务意味着出了故障有人接、有人能看懂当地语言写工单、有一种当地能用的付款方式、有一处符合当地要求的数据存放位置。这些东西每一件都要养人，十个人养不起全套，所以他们没有养全套，而是把绝大部分交付面要么降级、要么直接不做，并且把”不做”这件事写在了明面上。这一条才是真正可学的，也是这一篇唯一想讲的东西：不是教你也凑十个人，而是教你在人力受限的时候，怎么把交付面一条条摊开、做取舍、并且把取舍如实讲给客户听。
二、五条交付面各自的成本形态
一个面向多地用户的产品，交付面大致是五条，每一条的成本结构不同，砍法也不同。先把它们的成本形态说清楚，后面才谈得上取舍。
- 多语言。成本的来源不是”翻译一遍界面”，而是”每一处文案变更都要重新翻一遍全部语言，并且有人校对”。可行的降级是机翻打底加有限人工校对，只覆盖高频路径；代价是必须对客户讲明不承诺术语准确性，法律、医疗、金融这类领域不在承诺范围内。
- 多平台。每个原生端（iOS、Android、桌面）都是一条独立的发布线、独立的审核、独立的崩溃排查。最省的砍法是只做 Web 加一个端，其余靠响应式网页兜。成本省在”少养几套构建与上架流程”，代价是放弃一部分只能靠原生拿到的能力和体验。
- 多区域合规。真正的贵项是数据驻留——某几个法域要求数据不能出境，就得在当地备一套存储与运维。可行的降级是只对少数强制法域做驻留，其余一律用统一隐私政策加免责说明。这一条不能”全部照做”，也不能”一个都不做”，只能挑强制的那几个。
- 支付。每接一种本地支付方式，就多一条对账链路、多一套退款与拒付处理、多一个需要维护的证书。最省的是只接一个聚合渠道，把长尾支付方式挡在外面，代价是部分地区”想用也用不了”。
- 支持。人工支持的边际成本是纯线性的——用户翻倍，支持的轮值就翻倍。可行的砍法是只用文档加自助，并且把响应时效上限写死，不做”随时找得到人”的承诺。
三、核心交付物：五条交付面的取舍决策表与对客措辞
把上面五条落成一张能用的表，关键是每一格不只写”做/降级/不做”，还要配一句能直接放进对外说明的措辞。取舍本身不丢人，含糊才丢人——客户能接受”我们不做这件事”，接受不了”我们做到了但一戳就破”。
| 交付面 | 做（花钱承诺） | 降级（有限做） | 不做（明确挡在门外） | 对客声明措辞 |
|---|---|---|---|---|
| 多语言 | 全语种人工翻译加术语库加审校 | 机翻加高频路径人工校对 | 仅界面语言，不译文档 | “界面提供多种语言，术语级准确性不在承诺范围内，重要用途请人工复核” |
| 多平台 | 原生 iOS 加 Android 加桌面 | 只做 Web 加一个原生端 | 其余端不提供 | “产品在网页与某端可用，其余系统通过浏览器访问，无原生离线能力” |
| 多区域合规 | 逐法域本地驻留加本地团队 | 仅强制法域驻留，其余统一政策 | 不做数据出境豁免 | “仅在若干有强制要求的地区驻留数据，其他地区适用统一数据处理政策” |
| 支付 | 接多种本地支付渠道 | 只接一个聚合渠道 | 不接长尾渠道 | “支持经聚合渠道处理的常见支付，部分地区可能无法完成付款” |
| 支持 | 全天候人工加多时区轮值 | 文档加自助加工作日响应 | 不做即时人工 | “以自助文档与工单为主，人工响应在约定时限内，非全天候” |
这张表的用法有两点要强调。第一，**”降级”和”不做”要分开写，不能混成”尽力而为”。客户对”降级”是能理解的（覆盖面有限但真实存在），对”我们尽量支持”这种含糊承诺反而最不满，因为它把责任在出问题时又推回给客户。第二，措辞要在客户成交之前就能看到**，写在定价页或能力矩阵里，而不是等他提了工单、发现没人回，才在对话里被迫承认。
四、三条砍不动的硬底线
交付面能砍，但有三类东西砍了就不是省钱、是埋雷，洹拓在给客户评估这类”极限压缩”方案时，先把这三条钉死再谈别的：
- 数据安全的正确性。界面可以只做一个端，语言可以只做机翻，但权限校验、传输加密、备份与恢复不能省——这一条一旦出事是灾难性的，且和团队规模无关，省下来的是假便宜。
- 不可逆操作的正确性。删除、扣款、批量改状态这类操作，可以少做功能，不能少做确认与留痕。人少的时候尤其容易把”二次确认””操作日志”当成冗余砍掉，而这些恰恰是十人团队最需要的护栏，因为他们没有余力去救一个删错库的事故。
- 法定义务。某些义务不是”交付面”而是”准入条件”——该做的资质、该留的记录、该响应的合法请求，不在可砍清单里，砍了不是降级，是违规。
这三条的共同点是：**它们不是”要不要给用户多一个功能”，而是”出了事谁来兜底”**。前者是产品范围，可以收窄；后者是责任边界，收窄了就是裸奔。十人团队能活，往往恰恰是因为他们在这三条上比大厂还保守，不是因为他们在这些地方偷了工。
五、必须自动化的四件事，以及为什么人工做会锁死规模
交付面砍到只剩这些之后，剩下的活里必须让机器干的是四件：发布、监控、账单、内容审核。这四件有一个共同特征——它们的调用量随用户数线性甚至超线性增长，一旦靠人工，人没加，规模就顶死了。
- 发布：手动发布意味着每次都要有人盯着、出问题要有人回滚，一天两次封顶。自动发布带健康检查和一键回滚，才可能一天几十次而不再加人。
- 监控：没有自动告警和自动初步分诊，夜里出事只能等天亮有人看屏幕。用户上百个国家时区，人工轮值等于把团队拖进全天候。
- 账单：按量计费和按用户计费如果靠人工核对，用户越多错得越多。账单必须自动生成、自动对账、异常自动标记，否则财务会成为增长瓶颈。
- 内容审核：只要产品接受用户生成内容，审核量就随活跃用户涨。纯人工审核不仅贵，而且没法在同一标准上保持一致，必须自动化优先、人工只复核高风险的那一小撮。
反过来说，这四件事只要有一件是纯人工的，它就会成为那根锁死规模的短木：团队不是不努力，而是每天被重复劳动填满，加人只是把瓶颈往后挪一格，永远追不上用户增长。这也是为什么”十个人能撑住”和”这十个人有没有把这四件事自动化”几乎是一回事。
六、把”不做”写进对外说明，以及它对乙方报价的现实意义
最后回到那句最朴素的提醒：用户自己发现你没做，比你先讲明白你没做，糟糕得多。所以要把限制写成公开对象，至少两份：一份能力矩阵（哪些语言/端/地区/支付是支持的、哪些是降级的、哪些是没有的），一份限制声明（已知不做什么、不承诺什么）。这不是自曝其短，而是把客户预期提前对齐，省去事后大量”我以为你们可以”的拉扯。
对做乙方、按项目报价的团队，这一套有直接的现实意义：报价的时候就把交付面一条条写清楚，不要按”全平台、全语言、全天候支持”那种默认假设去报。因为在甲方眼里，”你们做 Web 的”和”你们要覆盖所有设备”和”出了事半夜也要有人接”是三件完全不同的成本。不写清就签合同，后面每一条含糊都会在验收和运维阶段变成免费加班。我们内部的规矩是：交付前把这张取舍表当成合同附件的一部分，做哪几格、降级哪几格、不做哪几格、每一格对客户怎么表述，白纸黑字，双方签字。
需要说清边界：这不是”所有团队都该学十个人”的鸡汤，恰恰相反，绝大多数团队不该照搬这个配置。它值得学的地方只有一处——**把交付面当成一组可显式取舍的清单，而不是当成”用户变多以后自然会需要的东西”**。能不能在资源受限时主动砍掉大部分、并且诚实地对外说明砍了什么，决定了小团队是稳定运行，还是在一个用户投诉、一次合规检查之下就散架。