私活代码交付，要不要留一手
早年我接过一个单，尾款拖了两个月，我当时想的是「早知道留个远程开关」。后来我没留，那笔钱是要回来了，但过程很难看。私活代码交付要不要留一手，我的答案是：不埋后门，但要在代码之外留三手。
最贵的一课：后门不是筹码，是证据
先说清楚为什么不埋。
埋后门这件事，在你的代码里留下的是一条明确的、可被检测的、指向你的证据链。 客户只要找人审一遍代码，或者拿它去打官司，你从有理变成没理。
更实际的是：后门几乎从来没有帮你把钱要回来过。 真到要用后门的那一步，关系已经崩了，客户宁可重做也不会付钱。
它是负资产——平时用不上，出事时反咬你一口。
坑一：把源码和尾款绑成了两件独立的事
现象是：客户说「先把代码给我，我内部走个流程就付款」。你一心软，给了。
为什么踩：你怕显得不信任对方，也想快点推进。
怎么避：把源码交付和验收确认绑在同一个动作上。演示阶段给部署链接和测试账号，验收通过那一笔款到账之后再给仓库权限。 这不是不信任，是流程。
我在私活交付分几个节点，我排了四个里把这件事排成了第四个节点，理由是它必须是最后一个。
坑二：以为「留一手」只能靠技术手段
现象是你觉得除了后门没有别的办法保护自己。
为什么踩：程序员的第一反应总是技术方案，但商业风险往往要用商业手段解决。
怎么避：真正管用的是这三样，全在代码之外。
第一手：合同里的授权范围
源码交付的到底是所有权还是使用权，这两件事差别很大。
约定清楚：客户能不能二次销售、能不能转给第三方、能不能用在别的项目上。写得越具体，你后面越省事。
这一手的前提是合同必须签。 没签合同的单子，后面所有保护措施都是空的，具体见接私活不签合同有什么风险。
第二手：交付时的确认记录。
源码给出去的那一刻，要让客户明确回复收到。
做法是把交付清单发过去，请他逐项确认。清单内容可以照着私活交付要交哪些东西，列个清单来。
这条记录的作用是：以后争议时，你能证明交付了什么、什么时候交的、对方确认过。
第三手：把杠杆放在服务上，不是代码里。
最有效的杠杆不是「我能让你系统瘫痪」，而是「你还需要我」。
具体做法：把持续价值留在交付之后——后续的功能扩展、部署维护、性能优化、小改动支持。客户越依赖你的持续服务，越不会在尾款上赖账。
这比任何技术手段都稳，而且完全不违规。
代码层面该做什么、不该做什么
该做的：
- 提交记录写清楚，注释规范，证明是你的原创
- 保留完整的开发过程记录
- 交付前自己跑一遍干净环境，确保能跑起来
- 把依赖和版本固定住，别留「以后再说」的坑
不该做的：
- 远程开关、定时失效、隐藏校验
- 故意留 bug 等后续收费
- 混淆代码来藏东西
- 用客户不知道的第三方服务做依赖
前四条是专业，后四条是自毁。
如果客户已经拿到源码还不付尾款。
不要动用任何技术手段，按流程走。
先书面通知，说明交付内容和待结款项；再暂停后续服务；然后评估金额和追偿成本。 金额不大时，把精力放到下一个客户身上更划算。
这里有个心态问题：很多人在这种时候会想「我一定要讨回来」，结果搭进去的时间远超尾款。算一次账，答案往往很清楚。
至于合同效力、著作权归属、违约追偿这些事，以合同约定和当地法律法规为准，建议找专业人士确认，我不给判断。
常见问题
Q：私活代码交付要不要留后门？
A：不要。后门是可被检测的证据，实际很少能帮你要回钱，反而会让你从有理变没理。保护自己应该靠合同、确认记录和后续服务。
Q：不留后门，怎么保证尾款能收到？
A：把源码交付和尾款绑在同一个动作上，验收通过再给仓库权限；同时把持续服务作为长期杠杆。
Q：客户拿到源码后不付钱怎么办？
A：按流程走——书面通知、暂停服务、评估追偿成本。金额和精力不成比例时，及时收手。具体主张以合同约定和当地法律法规为准。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」