代码写完只是上半场：vibe 项目的客户交接实战

朋友老陈去年接了个单：给一家线下连锁门店做会员预约小程序。两周写完，微信发了个压缩包，客户回了句"收到，辛苦"。三个月后凌晨一点，老陈被电话吵醒——系统登不上，门店明天开业活动全指着这个小程序。他花了两小时才想起来：服务器是他自己名下的，域名续费邮件发到了他的垃圾箱，SSL 证书上周过期了。

这就是 vibe coder 接单最典型的死法：代码写完了，但项目从来没有真正"交出去"。AI 把写代码的时间从两个月压到两周，交付却还是十年前的手工作业——发压缩包、口头说"有问题找我"、权限全留在自己手里。你以为交的是项目，实际交的是一颗定时炸弹，倒计时结束时先炸的是你自己的睡眠。

这篇讲"交接"这件事本身。不是教你怎么写代码，是教你怎么把代码干净地交到别人手里，然后睡安稳觉。

先说为什么 vibe 时代交接比过去重要三倍。第一，交付速度变了：过去两个月的项目，客户有充分的时间在过程中熟悉系统；现在两周交付，客户对系统的认知几乎为零，交接是他唯一一次系统学习的机会，错过了就只能永远问你。第二，代码量变了：AI 一天生成的代码，出了问题连你自己都要查半天，没有文档的交接等于把"黑盒"交出去。第三，接单半径变了：以前接单靠本地熟人，出了问题上门一趟；现在社群、平台接全国的单，全靠远程，书面文件是唯一的信任载体。三个变化指向同一个结论：代码生成得越快，交接越要重。

一、交接失败的三种死法

先统一认知：交付 ≠ 发代码。交付的完成标准只有一条——没有你，客户的系统照样转。对照这三种死法，看看你中了几个：

死法一：文档缺失。客户拿到代码，但不知道怎么重启服务、备份在哪、第三方账号密码是什么。第一次出问题只能找你，第二次也是，第十次你成了终身免费客服。vibe 项目尤其危险：AI 一天生成的代码量顶过去一个月，文档却还是零——AI 不会主动给你写"给非技术人员看的重启手册"。

死法二：权限没移交。域名在你名下、服务器在你账号里、支付回调用的还是你的 Stripe key。客户名义上拥有项目，实际上所有命脉都攥在你手里。这不叫交付，这叫人质交换——只不过人质是你自己：客户半夜找你不是因为你重要，是因为只有你能续费。

死法三：口头维护承诺。"有问题随时找我"——这句话的成本是无限的。没有边界，没有期限，没有"什么算问题"的定义。三个月后客户让你"顺手加个导出 Excel"，你做不做？做了，这次免费下次呢？不做，"当初不是说有问题找你吗"？所有扯皮都源于交接那一刻没有把边界写下来。

记住一句话：交接的质量，决定了这个项目在未来一年里还要吃掉你多少时间。下面六节，就是把这句话落成可执行的动作。

算一笔账就知道交接有多值钱。假设你接单的时薪是 300 元，一次潦草交接在未来半年里平均会吃掉你 20 个小时的"免费售后"（重启服务、找密码、解释"顺便加个功能"为什么收费）——那就是 6000 元的隐性成本。而一次认真的交接，会前准备加会议总共约 8 小时，2400 元。里外里差出 3600 元，还不算半夜被吵醒的精神损失。更狠的是机会成本：那 20 个小时本可以拿去接下一个单，或者让 AI 帮你写下一个产品。所以交接不是成本，是 ROI 最高的一次投入——花 8 小时，买断未来半年的纠缠。

还有一个 vibe 时代特有的坑：AI 生成的代码，交接难度是手写代码的三倍。手写代码你至少记得每个模块为什么这样写；AI 一天吐出来的三万行，你自己都没全读过。客户问"这个定时任务是干嘛的"，你答不上来，信任当场打折。所以 vibe 项目的交接文档要比传统项目更厚一点——不是因为你懒，是因为代码的"知识半衰期"更短。开工第一周就建一个 HANDOVER.md，想到什么记什么，比最后一周突击补要轻松十倍。

二、交接文档包：写给"下一个人"看

交接文档的读者不是你，是三种人：客户本人（非技术）、客户未来的技术人员、三个月后失忆的你。按这个读者画像，文档包只需要四件东西，多一件都是负担：

1. 给客户看的 README（非技术版）。不要写技术架构，写三板斧：系统挂了怎么重启、数据在哪怎么备份、常见问题怎么办。用客户能懂的话写，比如"如果小程序打不开了，先打开这个网址看状态灯是不是绿的"。附上所有第三方服务的登录入口和每月费用——客户有权知道他每个月在为什么付钱。

2. 架构一页纸。一张图 + 半页字：前端在哪、后端在哪、数据库在哪、关键第三方（支付/短信/地图）是谁。vibe 项目的架构通常不复杂，一页纸足够。目的是让"下一个人"（客户未来请的技术）半小时内看懂全貌，而不是去读 AI 生成的三万行代码。

一页纸的写法（照抄格式）：顶部画四个框——用户端（小程序/App/Web 写清楚）、应用服务（哪个云、什么配置）、数据库（类型、备份策略）、第三方（支付/短信/推送/地图各一行，写服务商+用途+月费）。底部三行字：代码仓库地址、线上环境地址、"如果只能记住一件事：先看状态页"。别写技术选型理由，客户不关心你为什么用 Supabase 而不用 Postgres，他只关心挂了找谁。

3. 账号与资产清单。表格，四列：资产名称、归属账号、移交状态、备注。包括域名、服务器/云账号、代码仓库、数据库、第三方 API（支付/短信/推送/地图）、监控告警、SSL 证书。每一行都要有"已移交/待移交"状态——这张表后面会变成签字确认书的附件。

4. 演示录像。15 分钟，录一遍核心流程：管理员怎么登录、日常操作怎么做、出问题看哪里。录像比文档更抗遗忘，客户遇到问题先翻录像，翻不到才找你。这是你睡眠的第一道防火墙。

录像前列个拍摄清单，避免录完发现漏了关键镜头：① 登录（管理员+普通用户各一遍）；② 核心业务流程完整走一遍；③ 后台数据查看与导出；④ "出问题怎么办"三板斧实拍（看状态页、重启、找备份）；⑤ 片尾 30 秒：你的联系方式、响应时效、"护航期 30 天"口播。手机录屏就行，不用剪辑，加个标题就行——客户要的是"能照着做"，不是宣传片。

vibe 项目交接前，建议对 AI 生成的代码做一次专项体检（30 分钟）：① 全仓库搜 sk-、AKIA、password、secret，确认没有硬编码密钥（有就轮换，见第三章）；② 把 AI 留下的 TODO/FIXME 全列出来，修不完的写进遗留问题清单，不要假装不存在；③ 检查有没有"魔法数字"（比如 if (retry > 3) 的 3 是哪来的），给每个加一行注释——AI 写代码不解释，你交接时必须解释，否则下一个人（或三个月后的你）只能靠猜。

文档写完自己读一遍，标准是：假设你失忆了，能不能靠这四件东西把系统救活。不能，就补。

非技术版 README 给你一个可以直接套的骨架（照着填空就行）：

# XX 系统使用手册（给老板看的版本）

## 系统挂了怎么办（按顺序做）
1. 打开状态页 https://status.xxx.com，看是不是绿灯
2. 如果是红灯，打电话给 XXX（电话），不要自己乱点
3. 如果状态页都打不开，重启服务器：登录 https://console.xxx.com → 点"重启"

## 每个月要看的三件事
- 每月 1 号：确认短信余额 > 500 条（登录 XX 平台查看）
- 每月 15 号：下载一次数据备份（点后台"导出"按钮，存到公司网盘）
- 域名/服务器续费日：__年__月__日（已设日历提醒）

## 常见问题
Q：客户说没收到短信？A：先查短信平台余额，再查手机号有没有填错
Q：后台登录不上？A：点"忘记密码"，验证码发到老板手机
Q：要加新功能？A：联系开发者走变更流程，不要找临时工改代码

注意最后一行——"不要找临时工改代码"不是开玩笑。很多交接后的烂摊子都源于客户找了个便宜外包"小改一下"，改崩了回头找你背锅。提前写进手册，等于给未来的自己买保险。

账号清单的表格建议再加两列，变成六列：资产名称、归属账号、登录方式、移交状态、月费用、备注。"登录方式"写清楚是"邮箱+密码"还是"微信扫码"还是"硬件密钥"——扫码登录和硬件密钥的移交最容易被遗漏，因为它们不在密码管理器里。"月费用"列让客户第一次看清这个系统的真实持有成本，避免他半年后抱怨"怎么每个月扣这么多钱"。

三、权限与资产移交：把命脉还给客户

这是交接里最容易"下次再说"的部分，也是出事后最痛的部分。原则：所有权归客户的东西，交接日当天必须全部过户，不要留"先放我这儿"的尾巴。

代码仓库：transfer，不是 fork。GitHub/GitLab 都有 Transfer Ownership 功能，把仓库整个转给客户的组织。Fork 会留下"你是上游"的隐患，transfer 才是真正的交接。转之前打最后一个 tag（如 v1.0-handover），转之后你只保留只读 collaborator 权限（护航期用），护航期结束即退出。

域名过户。在注册商处做所有权转移（Change of Ownership），不只是改 DNS 解析。很多纠纷都卡在这里：解析指过去了，但域名还在你名下，续费、实名认证、转移密码全都得找你。过户完成后让客户确认 WHOIS 信息已变更。

云与支付账号过户。服务器/数据库尽量迁到客户自己的云账号；实在迁不动，至少把 IAM 子账号给客户、把账单告警抄送客户。支付（Stripe/微信支付/支付宝）的商户号必须是客户的——钱的事不能"先走我的账"，一分钱都不要经你的手，这是红线。

API Key 全量轮换。开发期用过的所有 key（AI 模型、短信、推送、地图、监控）在交接时全部轮换一遍：旧 key 作废、新 key 交给客户。原因很简单：你的本地 .env、聊天记录、AI 对话历史里都躺过这些 key，不轮换等于把后门留给全世界。轮换方法见《vibe 项目密钥管理指南》，这里只强调时机——交接日就是轮换日。

双因素认证交接。凡是绑了你个人手机/验证器的账号，逐个解绑重绑到客户手机。别嫌麻烦，这一步漏了，三个月后客户登录不上，你还得半夜起床收验证码。

GitHub 仓库 transfer 的具体操作（3 分钟，但顺序别错）：Settings → General → Danger Zone → Transfer ownership → 输入目标组织名 → 客户那边点确认邮件。注意两个坑：一是 transfer 之前先把 Actions 的 secrets 清空或轮换，别把你其他项目的 key 留在仓库的 secret 里；二是确认客户的组织是付费/免费席位足够，私有仓库转给免费组织如果超了协作者数会当场锁死，提前问一句能省一小时 debug。

域名过户最容易踩的坑是"只改了 DNS 没过户"。正确的完整链条是：注册商后台发起所有权转移 → 客户确认转移邮件 → 客户完成实名认证 → 你验证 WHOIS 的 registrant 已变更 → 把域名的自动续费打开（用客户的支付方式）。整个流程走完通常要 3-5 天（含注册商审核），所以域名过户要在 T-7 就启动，不要等到交接会当天。60 天内刚注册或刚转移过的域名会被锁转移，提前查一下注册日期。

云账号实在迁不动时的折中方案：给客户开 IAM 管理员子账号，把 root 账号的 MFA 换成客户的硬件密钥或手机，账单告警邮箱改成客户的财务邮箱。然后在交接确认书上加一条："服务器暂由乙方代管，__年__月__日前完成迁移，代管期间费用由甲方承担"。代管要有期限，没有期限的"暂放"就是永久。

四、验收：把"做完了"变成"客户认了"

"口头说可以"不算验收。这是交接里最反直觉的一条：客户在微信里说"挺好的"，两周后说"这个跟我想的不一样"，你一点办法都没有——因为没有书面标准。所以验收标准要在签合同（或开工）时就写好，交接时只是"对着标准打勾"。

验收标准长什么样？不需要法律术语，三列就够：功能点、验收方式、通过标准。举例：

• 会员预约——验收方式：用测试账号完整走一遍预约流程——通过标准：收到短信确认，商家后台能看到订单
• 导出报表——验收方式：导出最近 30 天数据——通过标准：Excel 能打开，数字与后台一致
• 并发——验收方式：50 人同时预约——通过标准：无报错，响应 3 秒内

每一条都必须是可操作的动作 + 可判断的结果，不能写"系统稳定运行"这种无法证伪的话。

UAT（用户验收测试）流程：交接前 3 天，把测试环境（或生产环境）交给客户，让他亲自把核心流程走一遍。你在旁边看，不许动手——客户卡住的地方，就是文档要补的地方。UAT 发现的问题分两类：验收标准内的，当天修；标准外的，记下来走"新需求"流程（见第六节），不要当场答应。

验收单签字模板（打印两份，双方签字，各留一份）：

项目验收确认单
项目名称：________    验收日期：________
验收结论：□ 通过  □ 有条件通过（遗留问题见附件）  □ 不通过
遗留问题清单：（编号/描述/约定解决日期）
1.
验收人（客户）签字：________
交付人签字：________

"有条件通过"是给小项目留的活路：不影响主流程的小瑕疵，写进遗留问题清单、约定解决日期，先签字让尾款流动起来。没有这一档，小问题会拖住整个交接。

UAT 当天给客户一张"测试脚本"（别让他自由发挥，自由发挥测不出东西）：

UAT 测试脚本（客户亲手操作，开发者只看不帮）
□ 场景1：新会员注册 → 预约明天下午3点 → 收到确认短信
□ 场景2：商家后台 → 找到刚才的订单 → 点击"完成服务"
□ 场景3：后台 → 导出本月报表 → 用 Excel 打开核对数字
□ 场景4：手机断网 → 重新打开小程序 → 提示是否友好
□ 场景5：连续下 3 个订单 → 库存/名额是否正确扣减
每完成一项，客户在后面签字。有问题当场记录，不现场改代码。

"开发者只看不帮"是 UAT 的灵魂。你一动手，测出来的就是"在你帮助下能跑通"，不是"客户自己能跑通"。客户卡住超过 5 分钟，记下来——这是文档要补的地方，不是你可以直接上手的地方。UAT 结束当场出两份东西：通过的项打勾签字，有问题的项进遗留清单并约定解决日期。不要"回去再约时间"，当场定死。

遗留问题清单有个处理原则：数量超过 5 个，或有任何一个 P0/P1，就不签"通过"，签"有条件通过"并冻结一部分尾款——比如留 10% 等遗留问题清零再付。这不是为难客户，是保护你自己：没有冻结的遗留清单，解决日期就是"有空再说"。反过来，遗留问题全部清零后，主动把验收单拍照发客户，并提醒尾款日期。主动、准时、留痕，这三件事做到位，尾款纠纷少一半。

五、钱的事：尾款与维护期怎么报价

钱的部分只有三件事：尾款什么时候结、质保金留多少、以后维护怎么收费。全部要在交接前谈好，交接会上只签字不谈判。

尾款结算节点。小项目（5 万以下）推荐 3-3-4：开工 30%、中期演示 30%、验收签字 40%。不要 5-5——前 50% 拿到手后动力衰减是人性，尾款 40% 才够让你认真做完交接。大项目可以 3-2-3-2，多一个"UAT 通过"节点。验收单签字后 3 个工作日内结清尾款，写进合同，交接会上提醒一次。

质保金。有些客户会要求留 10% 做质保金，3-6 个月后付。可以接受，但要封顶：质保金只保"bug"，不保"新需求"（判定标准见第六节），且质保期一到自动支付，不需要客户"确认无问题"——否则质保金会变成永久尾款。

维护期三种报价模型（三选一，写进交接确认书）：

• 按次收费：每次问题 500-2000（按项目体量定），先报价后动手。适合系统稳定、客户 IT 能力尚可的项目。优点是边界最清晰，缺点是客户报问题前会犹豫，小问题攒成大问题。
• 包月维护：每月固定费用（通常为项目总额的 5%-10%），含 N 次响应+小修。适合业务变化快、客户完全不懂技术的项目。注意包月只包"维护"，不包"新功能"，新功能单独报价。
• 不包维护：护航期（30 天）结束后不再提供维护，客户另请人。适合一次性小项目。选这条必须在交接会上明确说出来，并推荐 1-2 个可接手的同行——客户不会觉得你绝情，反而觉得你专业。

三种模型没有优劣，只有"适不适合这个客户"。判断标准就一个：客户的技术自理能力。他能自己重启服务，选按次；他连后台都不敢点，选包月；项目小到不值得，选不包——但一定要说清楚。

谈维护费时最常见的话术陷阱是客户说"先免费维护三个月看看"。标准回答："护航期 30 天内 bug 全免费，这是包含的；30 天之后按次/包月，二选一。"不要让步到 90 天——免费期的长度决定了客户对"你随叫随到"的心理定价，90 天免费期结束后再收费，客户会觉得你"变脸"。30 天是行业 sweet spot：足够覆盖上线初期的磨合 bug，又短到不会形成依赖。

包月定价给个参考锚：项目总额 3-5 万的，包月 1500-3000；10 万左右的，包月 3000-6000。包含内容写死：每月 X 次远程响应、bug 免费修、小调整（改字、换图、调参数）每月 Y 次。超出部分按次另算。把"小调整"的次数写死非常重要，否则"改个字"这种 5 分钟活会以每月 20 次的频率出现——单次看都不好意思收费，加起来就是一周的工作量。

最后一条铁律：所有收费承诺都要有书面载体。微信里谈好的维护费，交接会上复述一遍，写进交接确认书，双方签字。口头报价在三个月后会变成"我记得你说的是免费"，而签字的文件不会失忆。

最坏的情况：客户验收签字了，但尾款拖着不付。预防比追讨重要三招：① 尾款比例不要低于 30%，低于这个数你就没有谈判筹码；② 大额项目（10 万以上）走第三方托管（猪八戒/云片/escrow 类服务），验收签字后平台放款，不经过客户的"心情"；③ 交接确认书上写清逾期条款（"逾期每日 0.05% 滞纳金"看着吓人，实际作用是让客户把付款排上日程）。真遇到老赖，顺序是：书面催款函 → 停止维护响应（护航期内的 bug 修完即止，新需求一律停）→ 律师函。注意不要以"关停系统"相威胁——系统已经是客户的了，关停等于违法，筹码要用在"停止后续服务"上。

反过来，如果你是客户视角（找人给你做 vibe 项目），这篇文章反着读就是"验收乙方"的指南：要他的文档包、要他当面改密码、要书面验收单。交接是双向的，好乙方不怕被验收，怕的是没标准。

平台单和私单的交接轻重不一样。走猪八戒/Upwork 这类平台，平台本身提供了托管和纠纷仲裁，交接可以轻一点：文档包+权限移交+验收单三件套够用，尾款有平台背书。但私单（朋友介绍、社群认识）恰恰要更重：没有平台兜底，所有的边界都得靠你自己的书面文件撑起来。中国式接单还有个特色——"先做后补合同"，开工时没签合同，交接时更要补签验收单和交接确认书。没签合同不可怕，可怕的是到最后连验收单都没有，那时候你手里一张牌都没有。

项目体量也决定交接的颗粒度。5000 块的小单：文档包可以压缩成一页纸+一个 5 分钟录像，交接会 20 分钟电话搞定，但"权限移交+书面确认"两项不能省——小单的纠纷率反而更高，因为双方都没当回事。5 万左右的中单：按本文全套走。20 万以上的大单：加两条——① 代码走查会（你讲，客户的技术顾问听，1 小时）；② 试运行期（先并行跑两周，旧系统不下，确认无误再切）。体量越大，交接越要"慢"，慢就是快。

六、维护边界：bug 和新需求的判定树

所有交接后的扯皮，90% 都是这一句："这个到底算 bug 还是新需求？"所以不要讲道理，给一张判定树，贴在交接文档第一页：

判定逻辑说人话就是四条：

• 验收时能复现、现在行为变了 → bug，免费修。这是你的锅，认。
• 验收时就这样、当时签字了 → 新需求，收费。客户说"我当时没注意"，答案是：验收单签了字，没注意也是认了。这就是第四节坚持书面验收的原因。
• 第三方挂了（支付/短信/云）→ 按维护协议走。你负责第一时间帮客户提工单、切备用方案，算一次维护响应；但第三方本身的故障不是你的 bug，不要为此道歉，更不要免费"补偿"。
• "顺便加个" → 一律新需求。没有"顺便"，所有加法都走变更单：先报价，客户确认，再动手。护航期内也不例外——护航期只保 bug，不保"顺便"。

响应时效分级（写进维护协议）：P0（系统完全不可用）4 小时内响应、24 小时内给 workaround；P1（核心功能受损）24 小时内响应；P2（体验问题）3 个工作日内响应。注意是"响应"不是"解决"——先让客户知道你收到了，比闷头修三天更有安抚效果。

30 天护航期规则：交接会之后 30 天为护航期，护航期内 bug 免费修、响应时效按 P0/P1/P2 走。第 30 天发一封"护航期结束信"：总结修了哪几个 bug、系统当前状态、后续维护三种模型请客户三选一。这封信是仪式，也是边界——从此"有问题找我"正式到期。

讲两个真实发生过的扯皮，你就知道判定树为什么必须前置。案例一：客户说"订单导出的 Excel 里金额少了一列"，开发者查了发现是验收时客户自己说"先不要金额列，以后再说"。按判定树，这是"验收时就这样+签字了"= 新需求。但因为没有书面验收单，双方各执一词，最后开发者免费加了——2 天工作量，还落了埋怨。案例二：客户说"小程序变慢了"，开发者一看是客户上传了 200MB 的原图当轮播图。按判定树，"按文档操作能复现吗"——文档写了图片要压缩，客户没照做，这不算 bug，是使用问题，远程指导 10 分钟解决，不收费。有判定树，这两个电话 5 分钟结束；没判定树，每个都是半天的情绪劳动。

响应时效建议做成一张小卡片，随文档包一起给客户：

故障响应承诺（护航期及包月维护期内有效）
P0 系统完全不可用 → 4 小时内响应，24 小时内给临时方案
P1 核心功能受损   → 24 小时内响应，3 天内修复或给方案
P2 体验/显示问题   → 3 个工作日内响应，排期修复
响应 = 回复确认收到并给出判断，不是修好。节假日顺延半天。

最后一行"节假日顺延半天"是过来人的血泪：不写这句，春节初一早上 7 点你会收到"系统有点慢"的微信。写了，客户至少会等到初二。

七、交接仪式：60 分钟的会议议程

交接要有一个明确的"时刻"，而不是在微信里慢慢淡出。安排一次 60 分钟的交接会（线上也行），议程固定：

• 0-15 分钟：演示。你操作，客户看，核心流程走一遍。重点演示"出问题怎么办"：重启在哪看、备份在哪下、状态页网址是什么。
• 15-30 分钟：文档移交。逐项过第二章的四件东西，账号清单现场改一遍密码（客户看着你改），确认他能登录每一个系统。
• 30-45 分钟：边界确认。把第六章的判定树和响应时效念一遍，确认维护模型三选一的结果，确认尾款金额与支付日期。丑话说在前面，是最高级的体贴。
• 45-60 分钟：签字。验收单 + 交接确认书，双方签字（电子签也行），拍照存档。

不要小看"签字"这个动作。签字确认书的仪式感是纠纷防火墙：白纸黑字签过"护航期 30 天、之后按次收费"的人，三个月后不好意思半夜打电话让你免费加功能。人性需要台阶，签字就是台阶。

交接确认书模板（验收单管"做完了"，这张管"交清楚了"）：

项目交接确认书
项目名称：________    交接日期：________
一、已移交资产（见附件《账号与资产清单》，共 __ 项，均已验证可登录）
二、已交付文档（README/架构一页纸/演示录像/判定树卡片）
三、验收结论：□ 通过 □ 有条件通过（遗留问题 __ 项，见验收单）
四、财务：尾款 __ 元于 __ 年 __ 月 __ 日前支付；质保金 __ 元，__ 年 __ 月 __ 日到期自动支付
五、维护：□ 按次（__元/次） □ 包月（__元/月，含__次响应） □ 不包维护
六、护航期：__ 年 __ 月 __ 日至 __ 年 __ 月 __ 日（30 天），仅修 bug
移交人签字：________    接收人签字：________

远程交接（现在 80% 都是远程）多三个动作：一是屏幕共享时全程录屏，录像发客户一份——"你当时就是这么教的"是最好的防扯皮证据；二是密码移交用 1Password/Bitwarden 的共享 vault，不要发微信——微信聊天记录里的密码三个月后还在，那就是定时炸弹；三是签字用电子签（e 签宝/法大大/腾讯电子签都行），别让"打印签字拍照回传"的摩擦拖住尾款。

下面是交接六阶段的时间线总览，从开工倒数第 14 天就开始准备，不要堆到最后一周：

时间线里藏着一个关键设计：权限移交（T-7~T-3）发生在 UAT（T-3~T-1）之前。顺序不能反——客户必须用"自己的账号"做 UAT，而不是用你的账号。如果你用自己的账号帮客户点了一遍 UAT，等于什么都没验证：权限问题（客户账号没权限看某个后台菜单是最常见的坑）只有在客户自己的账号体系下才会暴露。交接的本质是"换人"，所有验证都必须在"换了人"的状态下做。

八、一页纸：18 项交接检查清单

打印出来，交接会前逐项打勾。六组，每组三项：

文档组

• □ 非技术版 README（含重启/备份/常见问题）已交付
• □ 架构一页纸已交付
• □ 15 分钟演示录像已交付

权限组

• □ 代码仓库已 transfer，旧权限已回收
• □ 域名已过户，WHOIS 已确认
• □ 所有 API Key 已轮换，旧 key 已作废

资产组

• □ 云/服务器账号已过户或 IAM 已移交
• □ 支付商户号为客户主体，无经手资金
• □ 双因素认证已解绑重绑到客户设备

验收组

• □ 验收标准书面化（功能点/验收方式/通过标准）
• □ UAT 已完成，遗留问题清单已确认
• □ 验收单双方已签字

财务组

• □ 尾款金额与支付日期已书面确认
• □ 质保金（如有）金额/期限/支付条件已确认
• □ 维护模型三选一已确认并签字

维护组

• □ bug/新需求判定树已交付客户
• □ P0/P1/P2 响应时效已书面确认
• □ 30 天护航期起止日期已确认

18 个勾打完，这个项目才算真正交出去。从此服务器报警找客户，域名续费找客户，半夜的电话——也不会再找你了。

清单的使用建议：第一次用，逐项过，一个都不要跳；第三次用，你会发现文档组和权限组已经形成了肌肉记忆，10 分钟搞定；第十次用，把这张清单直接发给客户，让他先自查一遍再开交接会——好的交接是双向的，客户参与得越深，事后扯皮越少。清单的终极形态不是你打勾，是客户主动问你要这张清单——到那天，你的交接就毕业了。

最后说一句：vibe 时代写代码越来越快，但"交干净"这件事快不起来，也不该快。AI 能帮你生成代码，生成不了信任。一次干净的交接，换来的是客户的下一次介绍——独立开发者的单子，一半都来自上一次交接时留下的好印象。把交接当成获客来做，这 18 个勾，每一个都值钱。

如果你现在手里就有一个"发了压缩包但还没交干净"的项目，别等，今天就做三件事：① 把域名、服务器、仓库的归属列出来，标出还在你名下的；② 给客户发微信约一次 30 分钟的交接电话；③ 把这篇的 18 项清单打印出来，电话里逐项过。亡羊补牢永远不晚，但"下次一定"是最贵的三个字。交接这件事，开始做了就完成了一半——剩下一半，是让客户在确认书上签下名字，然后你们握手告别。