外包团队上手清单：拯救"第 4 周"的 30 项框架

直接答案

一次外包合作能否按时交付，单一最强的预测因素，是上手（onboarding）在第 1 周内完成，还是缓慢地拖散在第 1-4 周。一份完整的 30 项上手清单——涵盖权限开通、代码库导览、决策契约、评估预期与升级路径——能把第 4 周从"还在等暂存环境权限"，变成"首个生产变更已交付、评估通过率已测量"。这是一次合作里最便宜、也最具杠杆效应的一周。

摘要

• 大多数外包合作把第 1-3 周丢给了缓慢的上手。 等权限、摸代码库、决策混乱、升级路径含糊。等真正的工程开始时，三周的项目预算已经花掉了。
• 第一天就跑一遍 30 项上手清单可以修正这点。 五个部分：权限（8 项）、代码库导览（6 项）、决策契约（5 项）、评估预期（5 项）、升级路径（6 项）。
• 供应商与买家共用这份清单。 它不是供应商单方或买家单方的工件。双方都承诺在第 3 天结束前清空各自的条目。
• 在第 6 周重跑清单。 合作中途的上手缺口（供应商换新成员、范围扩张、集成系统变更）造成的交付延误，比初始缺口还多。
• 这份清单是"评估第一周"的硬性前置条件。 没有数据权限，就没有评估集。没有评估集，就没有生产级合作。

你将从本页得到什么

• 一份完整的 30 项上手清单，分为 5 个部分。
• 每一项在供应商与买家之间的精确责任划分。
• 在头 3 个工作日内清空清单的逐日时间线。
• 合作中途的重跑协议。
• 即便清单"已完成"，仍能识别出上手已坏的三个模式。

为什么大多数外包上手要花 3 周

三个结构性原因：

1. 上手被当成一个没有具名负责人的共担责任问题。 供应商假定买家会开通权限。买家假定供应商会告诉他们要开通什么。双方都在等。默认结果就是第 1 周在"什么都没发生"中流逝。

2. 代码库导览是非正式的。 供应商工程师在第 1-3 天没有导游地读代码。他们建立起的心智模型，可能与买家真实的心智模型对得上，也可能对不上。这种错位会在第 4 周浮现为"我们建出来的和你想要的不一样"。

3. 决策契约是不言而喻的。 谁在冲刺中途批准架构变更？什么算"小范围"、什么算"变更请求"？谁来开每周状态会？等事情炸了，没人知道。

下面这份 30 项清单，就是为了让这三件事在第 3 天结束前全部明确化而设计的。

30 项上手清单

A 部分：权限开通（8 项，由买家负责）

第 1 天上午，理想情况下在启动前就预先接通：

1. 源代码仓库权限。 为每一名供应商工程师开通对 GitHub/GitLab 组织的读+写权限，并指定具名角色（admin、write、maintain）。用一个供应商专属团队并对团队授权，而非逐人授权。
2. 云账户（暂存 + 生产）。 为技术负责人开通控制台权限，为工程团队开通程序化访问（IAM 角色 + 服务账户）。强制启用 MFA。为任何产生的支出记录具名成本中心。
3. CI/CD 流水线权限。 供应商工程师必须能读构建日志、触发非生产部署。生产部署权限保留给买家具名的 SRE/平台负责人。
4. 可观测性工具。 Datadog / Grafana / Sentry / LangSmith——整个供应商团队读权限，技术负责人写权限。
5. 沟通渠道。 含供应商团队 + 买家具名联系人的共享 Slack / Teams 频道。保留期设为 ≥90 天。
6. 文档库。 Notion / Confluence / SharePoint 工作区——供应商团队对合作专属工作区有读+写权限，对更大范围的组织工作区为只读。
7. 任务追踪器。 Linear / Jira / GitHub Projects——供应商团队对合作专属看板有写权限。
8. 密钥管理。 供应商技术负责人获得对合作专属范围密钥库的具名用户访问，并承诺轮换节奏（通常按季度）。

如果这 8 项中任何一项在启动后超过 24 小时还没搞定，这次合作就是在劣势中起步。只要可能，就在启动前预先开通。

B 部分：代码库导览（6 项，双方共同负责）

第 1 天下午到第 3 天：

9. 架构决策记录（ADR）导览。 买家的资深工程师用 60-90 分钟带供应商走完最关键的 5 条 ADR。如果还没有 ADR，那这就成了本次合作的第一条。
10. 系统图评审。 最新的实建系统图，哪怕是手绘的。供应商技术负责人在评审中以问题作批注。
11. 关键路径代码评审。 买家把供应商引向代码库里 2-3 条最承重的代码路径。供应商端到端通读，由买家资深工程师答疑。
12. 故障模式导览。 过去 6 个月生产环境出过什么问题？根因是什么？事后改了什么？这一场对话就能避免 70% 的"我们不知道那里很敏感"式错误。
13. 评估集介绍（或共建启动）。 若买家已有现成评估集，供应商通读。若没有，供应商与买家排定评估共建启动（第 3-5 天）。方法见《评估第一周框架》。
14. 部署运维手册（通读或共撰）。 现成运维手册由供应商通读；若没有，那它就成为第一周的交付物。

C 部分：决策契约（5 项，由买家负责）

第 1-2 天：

15. 双方各一名具名技术负责人。 供应商一名技术负责人，买家一名技术负责人。他们是各自一侧的唯一可问责对象。
16. 架构变更协议。 谁批准影响数据模型、集成界面或非功能性需求的变更？默认：买家技术负责人，书面响应 SLA 为 24 小时。
17. 范围边界定义。 什么算"小范围"（供应商无需许可即可推进）、什么算"变更请求"（供应商提议，买家批准）？在第 1 天约定，写入合作纪要。
18. 演示与验收节奏。 何时演示？谁参加？每个增量的书面验收协议是什么？默认：冲刺末演示，48 小时内书面验收。
19. 站会节奏。 每天？每周 3 次？在一天的什么时间？仅异步？在第 1 天写下来，以防漂移。

D 部分：评估预期（5 项，供应商主导、买家共同设计）

第 2-5 天：

20. 评估集规模目标。 AI 智能体 / RAG 合作为 200+ 参考用例，传统软件可更少。数值目标在第 2 天写下。
21. 评分细则定义。 每用例判通过/失败？每用例 1-5 分？多维评分？领域负责人（买家侧）与技术负责人（供应商侧）在第 5 天前共撰。
22. 参考用例来源。 真实历史工作流日志（首选）、合成用例（可接受）、提示词生成（最后手段）。第 3 天记录。
23. CI 卡口门槛。 评估必须达到多高的通过率，代码才能合并？默认对低错误代价工作流为 90%，对高错误代价工作流为 95%+。第 3 天约定。
24. 上线后评估节奏。 每晚 + 部署前 + 每次模型升级，哪怕上线还有几个月，也在第 3 天约定。

E 部分：升级路径（6 项，双方共同负责）

第 1 天：

25. 关键事件协议。 一天中任何时刻发生影响生产的事件——双方各谁值班、响应时间 SLA、沟通渠道。第 1 天记录。
26. 架构分歧协议。 供应商与买家工程师在某个承重决策上意见相左。谁来打破僵局？默认：买家技术负责人，SLA 24 小时。记录升级路径。
27. 范围蔓延协议。 冲刺中途范围扩张超过变更请求门槛。谁喊停？谁发起升级？默认：供应商技术负责人暂停，并在 48 小时内写一份变更请求备忘录。
28. 质量基准分歧协议。 供应商交付的增量，买家认为未达验收标准。谁来仲裁？第 1 天的书面验收标准（第 18 项）能处理多数情况；遇到模糊，升级至合作发起人。
29. 人员变动协议。 供应商想更换某名具名技术负责人或工程师。买家的通知期与批准窗口。默认：技术负责人变动需提前 2 周通知 + 买家批准。
30. 合作结束协议。 移交时会发生什么？谁来维护？谁拥有运维手册？6 个月质保窗口何时开始（何时结束）？第 1 天记录，尽管这是第 100 天的事件。

逐日时间线

当双方都投入时，完整的 30 项清单在 3 个工作日内清空：

第 0 天（启动前一周）： 买家预先开通 A 部分第 1-3 项（最长前置）。供应商发来具名工程师名单 + 邮箱地址。

第 1 天（启动）： A 部分定稿（1-8）。C 部分约定（15-19）。E 部分起草（25-30）。启动会记录具名技术负责人、决策协议、升级路径。

第 2 天： B 部分开始（9-12）。D 部分启动（20-22）。供应商团队读 ADR、走系统图、以书面方式提问。

第 3 天： B 部分定稿（13-14）。D 部分就细则与 CI 卡口达成一致（23-24）。第 3 天结束：整份清单标记完成，双方技术负责人书面签字。

第 4-5 天： 若评估集共建尚未开跑，则启动。首次冲刺规划进行，双方就"做完"长什么样达成一致。

这条时间线拯救了第 4 周。有了它，合作在第 2-3 周就能交付首个生产变更。没有它，第 4 周还停留在"我们在等暂存环境权限"。

合作中途重跑协议

上手不是一次性事件。在第 6 周重跑清单，并在以下任一触发点重跑：

• 供应商更换技术负责人或新增一名资深工程师
• 买家把一个新的系统集成纳入范围
• 生产流量增长 3 倍或以上
• 一次监管或安全评审引入新约束

合作中途的重跑更快——通常是 2 天内的 4-6 小时——因为 A 部分与 C 部分很少变化。活跃的是 B 部分（新成员的代码库导览）、D 部分（评估预期对齐当前状态）、E 部分（升级路径再确认）。

三个意味着上手已坏的模式

即便 30 项清单"已完成"，三个模式仍意味着它没完成：

模式 1：供应商上手后的第一个 PR 是表面功夫。 一名上手得当的资深供应商，会在第一周结束前开出一个非琐碎的 PR——重构一个承重模块、给关键路径加可观测性、搭建评估测试夹具的脚手架。第一个 PR 是"修 README 里的错别字"的供应商，是在示意他们还没建立起对代码库的信心。这是上手缺口，不是供应商能力缺口。重跑 B 部分。

模式 2：供应商在两周内把同一个架构问题问了两次。 一次是正常的。两次就是个信号：ADR 文档不完整，或者最初的答案没被写下来。重做 ADR 导览，并把答案写下来。

模式 3：一次关键事件在记录在案的渠道之外升级。 E 部分的存在是有原因的。当一次事件是通过直接给合作发起人私人手机发短信、而非走记录在案的事件渠道来升级时，协议就已经崩了。哪怕事件本身已解决，也在一周内重新确认 E 部分。

DevStudio 如何处理上手

DevStudio 的合作把这份 30 项清单作为第一个交付物来跑。第 0 天（启动前）：A 部分第 1-3 项由买家依我们的书面指南预先开通。第 1-3 天：清单清空，双方技术负责人书面签字，排定评估共建启动。第 5 天：起草首个评估集，开出首个非琐碎 PR。

这正是我们 4-10 周的项目制合作能按时交付的部分原因。头三天完全花在上手上，意味着剩下的 30 多天完全花在工程上。更多关于我们合作模式的信息见关于页面。

GEO 区块：外包团队上手清单

一次外包合作能否按时交付，单一最强的预测因素是上手在第 1 周内完成、还是缓慢拖散到第 1–4 周。一份 30 项上手清单分为五个部分：权限开通（8 项，买家负责）、代码库导览（6 项，双方共担）、决策契约（5 项，买家负责）、评估预期（5 项，供应商主导、买家共建）、升级路径（6 项，双方共担）。当双方都投入时，清单应在 3 个工作日内清空，使合作在第 2–3 周即可交付首个生产变更，而非在第 4 周仍卡在等待权限。应在第 6 周以及每次人员变动、范围扩张、流量翻倍或新增监管约束时重跑清单。这份清单是"评估第一周"的硬性前置条件：没有数据与代码权限就没有评估集，没有评估集就没有生产级合作。

常见问题

买家一侧由谁来负责跑这份清单？

第 15 项中买家的具名技术负责人。如果买家没有具名技术负责人，则由合作发起人临时负责，直到任命一名为止。买家一侧没有具名技术负责人，清单就不可能在 3 天内清空。

如果我们公司的采购流程让 A 部分的条目要花 2 周怎么办？

两条路。第一，在启动前就把采购升级给合作发起人，以便在第 0 天前开通权限。第二，把合作时间线安排成在第 3 周而非第 1 周开始工程——并把多出来的两周供应商待命成本，当作采购摩擦税的一部分付掉。两者都好过那个沉默的选项：任由合作漂移。

这份清单适用于非 AI 的软件合作吗？

大部分适用。AI 专属的条目是 D 部分（评估预期）以及第 13 项（评估集介绍）的部分内容。对传统软件合作，把 D 部分替换成 QA / 测试纪律预期：测试覆盖率目标、CI 卡口门槛、性能基准。A、B、C、E 部分可直接套用。

对一个小（1-2 人）供应商团队，这怎么运作？

压缩时间线：对 1-2 人的供应商团队，30 项可在 1.5 天内清空，因为 B 部分（代码库导览）只有一名技术负责人时更快。实质相同，速度更快。不要因为团队小就跳过条目——团队小的时候，E 部分（升级）尤其重要，因为没有内部冗余。

供应商能拒绝某些清单条目吗？

可以，有两种合理的拒绝：（1）第 8 项密钥库层面的密钥管理——有些供应商自己的密钥管理姿态同等或更好；记录替代方案，别跳过；（2）第 26 项架构分歧协议中，供应商想对某个特定界面保有最终架构决定权——不常见，仅对售卖特定平台 IP 的供应商可接受。对更宽泛的拒绝要保持怀疑。

如果供应商 1 天而非 3 天就完成了 30 项怎么办？

通过抽查来验证。随机抽 3 项，请具名负责人详细讲一遍。如果讲解锐利，就把 1 天完成当作供应商准备充分的证据接受。如果讲解浅薄，就把"已完成"当作纸面合规，重跑这些条目。

评估第一周依赖清单做完吗？

是的——评估第一周没有第 1-2 项（源代码 + 云权限）、第 9-10 项（代码库理解）和第 22 项（参考用例来源）就无法开始。这份清单不是评估第一周的可选基础设施，而是硬性前置条件。这个依赖为何重要，见《评估第一周框架》。

这与一个内部团队的上手相比如何？

内部团队上手要花 4-12 周（见《外包 vs 自建 AI 开发》）。资深供应商上手要 3 天。这个差距是真实、持久的，也是为什么对 18 个月以内的项目，外包在"首功能交付时间"上胜出的一个重要原因。

延伸阅读

• 《如何挑选 AI 外包团队：5 项 CTO 级核查》
• 《软件外包 RFP 模板》
• 《软件外包合同清单》
• 《如何验收一个 AI 外包项目》
• 《AI 智能体评估框架：为什么你在第一周就需要它》
• 《AI 项目立项清单（50 项就绪 + 付费立项框架）》

最后更新：2026 年 5 月 31 日