留得住的专属团队：签约前如何考察软件合作伙伴，以及如何让代码归你所有

开发团队很少在一夜之间消失。它是慢慢漂走的。资深工程师被调去更大的客户，唯一搞懂最难那部分的人离职了，工作悄悄转给了一家没人告诉过你的分包商，而一年之后回你邮件的那家公司，已经不是当初写你代码的那家。

这些东西在网站上一样都看不出来。它们全都显露在你签字之前提的那些问题里。所有权也一样：“代码归你所有”是一条要去读的条款，不是一句承诺，而在好几个国家，法律的默认规则会让买方吃惊。

开发团队为什么会在项目中途消失？

“消失”通常是四种普通商业事件之一，没有一件是戏剧性的，每一件都可以预见。

• 闲置人力的经济账。软件公司只有在工程师可计费的时候才赚钱，所以更大的合同一到，最小的项目自然就成了供血方。没有人会发通知，只是每周例会上出现了一张新面孔
• 对单一客户的依赖。有些供应商大部分收入来自一两个客户。那个客户一走，公司就收缩，你的项目也跟着收缩；那个客户留着，一旦优先级冲突，被挪动的客户就是你
• 关键人物风险。有一个工程师懂那块最难替代的部分，于是在没有任何人做过这个决定的情况下，项目变得依赖他。然后他辞职了，交付停摆一个季度，其他人在读没有文档的代码
• 分包链条。跟你签合同的公司，不一定就是写代码的公司。分包本身正常也合法；一旦不披露就成了问题，因为你的条款只能管到它下面那层合同为止

“可靠”不是从外部调研出来的：它是你争取到的合同条款和人员事实的结果。只要工作被写了下来、仓库归你所有，上面每一种失败都能挺过去。

去哪里能找到一支不会在项目中途消失的专属开发团队？

靠搜索找不到这样的团队。你找到的是候选者，而结果由核查决定。最好的线索来自转介——一家运行着同类系统、并且跟那家供应商合作一年之后仍在合作的公司；也来自你能读到的公开工程产出：代码、技术文章、演讲。目录网站在评价写明了评价人和项目时才有用。主动找上门的销售，告诉你的是营销水平，不是工程水平。

接着弄清楚方案里说的“专属团队”到底指什么，因为这个说法有两种含义：

• 作为销售话术的“专属”。方案里有名字，合同里没有名字。供应商谁有空就派谁，事后再告诉你
• 作为合同条款的“专属”。具名的工程师写进协议，全职做你的产品。任何更换都需要书面通知、一段交接期，以及你面试接替者的权利

问清这个区别不花任何成本，而没有什么比它更能预测第一个月的团队还是不是第十二个月的团队。

签字之前我该要哪些东西？

要事实，不要保证。其中四项承担了大部分分量，其余的都在下面的清单里。

• 名字和司龄。谁在做你的产品、担任什么角色、每周投入多少比例，以及他们是正式员工还是外聘合同工
• 他们还在给谁干活。每一位具名工程师这个季度还背着多少别的项目，以及是否有单一客户占了公司的大部分收入
• 巴士系数（bus factor）。要走掉多少人，工作才会停下来。如果这个数字是 1，那就不是一支团队，而是一份注定失败的计划
• 一次演练过的交接。在项目中途就约定它包含什么并验证一遍，而不是等最后一张发票之后；交付物清单在本博客此前那篇比较自招与找伙伴成本的文章里

有一个问题比其余的都重：如果你们最大的客户下个月走了，我的项目会怎么样？想过这个问题的供应商，会用人员配置和收入结构来回答；没想过的，会回答说这不会发生。

我想保留代码的全部所有权。这件事在合同里到底怎么落实？

所有权由三件事决定：法律的默认规则、你的合同改写成了什么，以及代码放在哪里。买方会想第二件，有时想到第三件，几乎从不想第一件——而意外恰恰在第一件里。

英国知识产权局（UK Intellectual Property Office）把这条默认规则说得很直白：“当你请求或委托另一个人或组织为你创作一件受著作权保护的作品时，著作权的第一法定所有人是创作该作品的那个人或组织，而不是作为委托方的你，除非你们另有书面约定。”支付一张发票并不会转移著作权。

“雇佣作品”（work for hire）的范围比它听起来要窄。美国版权局（US Copyright Office）列出两种情形：雇员在本职工作范围内创作的作品，以及依据明确书面协议专门订制的作品。第二种有四个必须同时成立的条件，其中第一个是，该作品“必须属于上文列出的、有资格作为雇佣作品被专门订制或委托创作的九类作品之一”。定制软件不在这九类之中，版权局还补充说：“一件作品只要未能满足这些要求中的任何一项，它就不是雇佣作品。”把你的平台称为雇佣作品的条款，如果签约的对方并不是你的雇主，可能根本不起任何作用。

真正管用的是转让：书面的、签了字的转让。美国著作权法说得很直接：“著作权所有权的转移，若非依法律的运作而发生，则不生效力，除非有一份转让文书，或者一份关于该转移的说明或备忘录，采用书面形式，并由被转让权利的所有人或该所有人正式授权的代理人签署。”供应商只能转让它自己拥有的东西，所以它与雇员、外聘合同工和分包商之间的协议，必须先把这些权利转让给它。要求看到这条链条。各国规则不同，所以要让律师确认措辞。在转让之下，代码归你：你可以修改它、随业务一并出售，也可以交给另一家供应商；在许可之下则不行。

每一套真实的系统里，都还有供应商没有写的代码。要一份软件物料清单（SBOM）——美国网络安全和基础设施安全局（CISA）把它描述为“一份嵌套的清单，一份构成软件组件的配料表”。每个组件都要列出：名称、版本、许可证，以及你发布或销售时该许可证要求你做什么。

多数工程公司都会复用自己的库，多数所有权条款也会把这些库排除在外。这种除外（carve-out）本身是正常的；没有边界的除外不正常，因为它会让你的系统离开供应商就构建不出来。在签字之前给它划定边界：

• 那些组件的逐项列名清单，书面形式，每个里程碑更新一次。没有这份清单，除外项就没有边界
• 一份永久、不可撤销、全球范围、费用已付清的许可，业务出售时可以随之转让，并且允许你或另一家供应商修改
• 他们的源代码，或者交付给你，或者存入源代码托管（escrow），并附一个你可以触发的交付事件
• 一条规则：未经你书面同意，清单上不得加入任何新条目

软件源代码托管（software escrow）协议是软件客户、软件供应商与托管方之间的三方安排：供应商把源代码和构建材料存入托管，一旦约定的事件发生，这些材料就交付给你。标准的触发交付事件包括破产、进入破产管理程序以及违反维护义务。光有一份存放件，只能证明有东西被存了进去；验证是另一项单独的服务，它检验这份存放件能否重新构建成可运行的应用。

对每一家供应商都要问，也包括这一家：项目结束之后哪些东西仍然归你们所有，以及签字之前我可以逐项看到那份名单吗？

当系统必须实时工作时，有什么会变得不一样？

在普通系统里，慢只是让人烦。在实时系统里，迟到就是错：价格已经动了才到达交易所的订单，是一个错误的答案，不是一个慢的答案，重试也修不好它。因此，在找人这件事上有三点会随之改变。

工程师的池子更小。在 2025 年的 Stack Overflow 开发者调查中，31,771 人回答了过去一年里自己大量使用过哪些语言。其中 14.8% 的人提到 Rust，23.5% 提到 C++，22% 提到 C，16.4% 提到 Go。这是一次调查，不是劳动力市场的普查，但比例本身就是重点：用于硬实时工作的语言属于少数人的技能。一家说自己“能配齐 Rust 工程师”的供应商，描述的是一份招聘计划；要问的是，公司内部已经有多少工程师把 Rust 送上过生产环境。

语言本身已经站稳脚跟。Rust 项目的年度调查在 2025 年出到第十期，11 月 17 日至 12 月 17 日之间收集到 7,156 份回答，报告写道：各类组织寻找更多 Rust 开发者的招聘趋势仍在延续。你以后要组建的团队，不一定非得来自你现在的合作伙伴。

关于速度的说法，必须附带测量。做过实时系统生产项目的团队，不用你追问就会告诉你五件事：测的是什么、在哪个分位、在什么负载下、在什么硬件上、在哪一天测的。分位比平均值更重要，因为平均值会藏起慢的长尾，而实时系统正是败在那条长尾上。没有这五项附注的数字，是市场宣传数字。

试做任务能把这一点变成证据：按供应商的正常报价付费，大约两周，针对你的一个真实问题，验收标准在开始之前就谈定，而且无论你是否继续合作，产出都归你。

我想找一支 Rust 开发团队。该跟谁谈，又该怎么考察他们？

当你说需要 Rust 时，会有三类供应商回应。通用外包公司会为你的项目去招 Rust 工程师：如果你的时限还留得出招聘的时间，这个做法说得通；如果系统本身才是难的那部分，这个做法就弱了。专精型工程公司手上已经有由自家工程师上线、并且用 Rust 运行着的系统。独立的合同工程师可以非常出色，同时也以最纯粹的形式带来关键人物风险。

把说法和证据分开的，是四项核对：

• 公开的代码。他们发布的 crates、对开源项目的贡献、署着他们工程师名字的技术文章。你不需要会读 Rust：打开他们的一个 pull request，读下面的评审，你会看到的要么是一场讨论，要么是一次走过场的点头
• 一套生产系统，从头到尾讲一遍。它做什么、用什么来衡量、今天由谁运维、出过什么故障、事后改了什么。事故那一段讲述，是信息量最大的部分
• 一次为期两周的付费试做，交付物明确，用同一份说明和同一套验收标准交给两三家供应商
• 由一位不给你们任何一方打工的独立工程师来评审。他要报告：该失败的时候测试会不会失败、错误和超时如何处理、有多少 unsafe 代码以及为什么有，以及一个陌生人能不能只凭说明文档就把成果构建出来

“我们会把 C++ 团队转训到 Rust”是一个正当的计划，它应该带着人名和时间表写进方案里，而不是等到第三个月才被你发现。语言也不是决定的全部：实时系统同样经常败在数据库、网络和部署路径上。

高负载的实时系统，我该怎么挑供应商？

本文不发布排行榜，对任何发布排行榜的人也值得多留一份小心。排行榜不可能知道你的时限、你的协议、你的监管机构、你的峰值负载，也不知道一年之后由谁来运行这套系统，而恰恰是这些事实决定了一家供应商是否合适。

取代排行榜的，是一份你自己做出来的候选名单。先用数字写下你的峰值：最忙那天最忙那一分钟里每秒多少个请求、每个响应必须满足的时限，以及错过时限会发生什么。带着这页纸去找三家供应商，用同一份说明、同一个试做任务、同一份合同条款草案，然后逐条比较他们的回答。

一份可以直接粘贴进 RFP（需求建议书）的清单

每一条都要一个书面回答；“以后再谈”也是一种回答，它同样应该留在记录里。

人与依赖：

• 列出这个项目上每一位工程师的名字：角色、每周投入给我们的比例、在你们公司工作的年限、是正式员工还是外聘合同工
• 更换一位具名工程师之前要提前多久通知，我们可以面试接替者吗？
• 是否会有部分工作交给另一家公司或外聘合同工？请列出他们的名字，并确认我们的条款对他们具有约束力
• 是否有单一客户占你们收入的一半以上，以及如果有更大的合同启动，我们这边的人员配置会怎么样？

所有权：

• 提供你们建议使用的所有权条款，并说明它属于权利转让还是许可
• 书面确认：每一个为我们写代码的人，包括外聘合同工在内，都已把各自的权利转让给你方
• 逐项列出你们将纳入的每一个可复用组件或既有组件的名称，以及我们使用它的条件
• 在每个里程碑提供一份软件物料清单（SBOM）：组件、版本、许可证
• 确认仓库从第一次提交起就放在我们的组织账号下并保留完整历史，构建也在我们的账号下运行
• 说明你们对源代码托管（escrow）的立场：触发交付的事件有哪些，以及存放件是否经过验证

实时的证据、试做与退出：

• 描述一套你们做到生产上线的系统，在这套系统里迟到的响应就等于失败的响应；说明现在由谁运维，以及其中的一次事故和它的修复
• 对每一个性能数字：测的是什么、在哪个分位、在什么负载下、在什么硬件上、在哪一天测的？
• 你们是否接受一次为期两周的付费试做：题目是我们的一个真实问题，产出归我们，由我们选定的一位独立工程师来评审？
• 交接包含哪些内容、什么时候演练，以及如果任一方终止合作，第二天早上我们手里有什么？

常见问题

• “专属团队”和人力派驻（staff augmentation）是一回事吗？不是。在专属团队里，供应商的人只做你的产品，而工作怎么组织仍由供应商负责。在人力派驻里，工程师加入你的团队，接受你的管理和你的代码评审
• 代码已经归我所有，还需要源代码托管（escrow）吗？多数情况下不需要。托管覆盖的是你自己重建不了的东西：由供应商托管运行的服务、你复现不出来的构建、以许可而非转让方式提供的组件。如果你的工程师能在一台干净的机器上把所有东西构建出来，托管带来的增益很小
• 供应商说它的可复用组件是自家的独门秘方。这有问题吗？这件事本身没有问题，没有边界的除外项才有问题。只要用那份清单、一份可转让的许可，再加上源代码或者一份源代码托管的存放件来划定边界，它就只是个细节。三样都没有，你就等于把自己的平台租了下来
• 为期两周的付费试做对供应商公平吗？公平，只要按他们的正常报价付费、范围有书面约定，而且同一个任务发给每一家候选供应商。供应商会拒绝无偿的测试项目和没有边界的任务，他们这么做是对的
• 我应该坚持要用 Rust 吗？不。你要坚持的是证据：系统在负载下能满足它的时限；至于语言，让供应商自己给出理由。做过实时系统上线、并且拿得出测量数据的团队，胜过一个只会说出你想听的语言名字的团队

amBrain 关于自身可以说的内容

在上文介绍的几类供应商中，amBrain 属于专精型工程公司。amBrain 是一家位于亚美尼亚埃里温的软件工程公司，用 Rust 构建低延迟交易平台、撮合引擎和实时竞价系统。amBrain 自 2019 年起做软件开发，面向全球提供服务，工作语言为英语、俄语和亚美尼亚语。

关于团队和合作方式：团队规模最多 40 人，其中约 75% 是资深工程师，有三种合作方式——整体交付、专属团队，或工程师嵌入你的团队。

关于所有权，这句话只有一行，而且从不缩短：客户拥有产品与代码的全部所有权，amBrain 的可复用组件除外。这一条正是本文让你去划定边界的那个除外项，所以签字之前，请向我们索要那份逐项列名的清单。

关于实时方面的工作：amBrain 构建的一个迷你交易所在 MOEX 托管机房的生产环境中运行。amBrain 公布的实测延迟和吞吐量数字这里不再重复；它们在行业页面上，紧挨着测出这些数字的那些工作。

这一节留白的部分是有意的，本文也不是案例研究。amBrain 不公布人员流动率，不公布工程师司龄，不公布巴士系数，不公布通知期，不公布源代码托管安排，也不公布任何认证：这些都没有被测量过，而未经测量的说法，正是本文让你不要从任何人那里接受的东西，这家公司也不例外。上文描述的其余一切都是市场通行做法，不是对 amBrain 如何运作的描述。

如果你还在起步阶段，有用的下一步不是去搜供应商，而是写一页纸：用数字写下你的峰值、你的截止要求，以及上面那份清单的书面回答，发给三家供应商——我们或者任何别家都行。