和共建伙伴合作的行业型创始人，迟早要请自己的 CTO。这个时间点通常在 A 轮前后：公司付得起资深工程师的薪水，也知道自己需要什么样的人。这也是共建关系真正接受检验的时刻。新 CTO 打开代码仓库，很快就会有判断：接手的是一块地基，还是一个烂摊子？
创始人担心被工作室的工程师绑定，这种担心很正常。而交接不可能在最后一个月临时拼凑，必须从第一次提交代码起就设计进去。真正拉开差距的是下面这几件事。
一、所有东西都登记在公司名下
代码仓库、云账号、域名、API 密钥、应用商店账号、监控和计费，都应该放在公司自己拥有的组织和账号里。共建伙伴拿的是访问权限，不是所有权。如果新 CTO 还得去找工作室“把某某东西转过来”，交接一开始就已经不顺了。
二、决策写下来，而不是记在脑子里
新 CTO 读得懂代码，读不出来的是为什么：为什么用这个数据库、这个智能体框架、这个模型，为什么控制器有 15% 的调整上限。决策当下就写好的简短架构决策记录（ADR），是成本最低的交接文档。
对 AI 产品来说，这一点更重要。智能体框架市场还没有定型，仍在积极维护、争抢同一类场景的框架至少有七个。一个周末做原型时随手挑的框架，可能不知不觉就成了整个系统的地基。新 CTO 需要知道，它是不是经过深思熟虑才选的。
三、评测体系跟代码一起交付
对 AI 产品来说，代码只是“能跑”的一半，另一半是评测体系：打过分的测试用例、及格阈值，以及每次模型或提示词改动都必须通过的回放测试集。只交代码、不交评测，新团队就没法安全地改任何东西，只能等客户发现问题，才知道自己改坏了什么。
四、运维有文档，而且演练过
部署、回滚、备份和恢复都要有操作手册，还要有最近一次真正做过恢复测试的记录。补丁计划、监控看板和告警路由也一样。新团队接手的，应该是一套正在运行的系统，而不是一份“如何把它跑起来”的说明书。
五、每个智能体都有具名负责人和预算
在生产环境的 AI 系统里，我们把没有负责人的智能体，当作没有鉴权的 API 端点来对待：它就是一个漏洞。交接时，负责人从工作室工程师换成公司团队里的人，一个智能体一个智能体地换。成本也一样：每个智能体或小组都应该有 token 预算和按结果计的成本记录，新 CTO 才知道“正常”是什么样。
六、模型版本锁定，数据流向有图
锁定的模型版本、每次升级的测试记录，以及一张标明个人数据流向（包括提示词和日志）的地图，能让新 CTO 在上任第一天、而不是第三个月，就答得上企业客户发来的第一份安全问卷。
交接期怎么安排
| 阶段 | 做什么 |
|---|---|
| 招聘之前 | 工作室协助定义岗位、对候选人做技术评估，并参与面试 |
| 并行期 | 新 CTO 先跟着发版，再由其主导发版，工作室工程师在旁支援 |
| 移交 | 智能体、告警和值班的负责权，一个领域一个领域地移交 |
| 之后 | 工作室继续提供支持、补充产能或专项能力，出于选择，而不是依赖 |
检验共建伙伴好不好，不是看公司离不离得开它，而是看公司会不会再选它一次。
我们的做法
我们从一开始就朝这次交接去建设。我们对外说得很明白：目标是现在就给项目提供资深工程能力，同时建立未来团队看得懂、接得住、扩得动的架构和工程纪律。wGrow Technologies 的兼职 CTO 服务也写着同样的原则：退出路径就是交接给内部团队。我们协助定义 CTO 岗位、主持技术面试，并带第一批工程师上手。