交付源码,其实是最后一步

行途导读：客户付钱买走的从来不是代码，是「你们走了以后，他自己团队还能带着 AI 改系统」的能力。源码在这套交付里排最后，前面三样——知识清单、工程体系、统一 AI 入口——才是真正值钱、也最容易被供应商藏着不交的东西。

这篇能给你什么：① 看懂 AI 时代交付物清单为什么变了、源码为什么排最后；② 抄走给甲方的四个问题，下次评估外包直接问；③ 交接清单上「最值钱那串东西放在哪、谁能碰、多久换一次」这行为什么必须写。

目录：

1. 开场：客户那一句「接得住吗」2. 传统交付：源码加人天，人走活就凉3. AI 时代，交付物清单变了4. 为什么知识清单比代码值钱5. 交付过程：敏捷和瀑布为什么混着用6. 交接清单上，不能只有源码7. 给甲方的四个问题8. 我押这个注9. 工具与信源

1. 开场：客户那一句「接得住吗」

去年一个项目收尾，客户方负责人跟我吃饭时说了句让我坐直了的话：「你们交付的这些东西，我们团队以后能接住吗？」

我当时愣了一下。因为按老规矩，交付就是验收代码、签个字、团队撤场。他这一问，问的不是代码，是代码之外的东西。

回去我想了很久。这几年我们一直在做 AI 落地，交付的东西其实已经悄悄变了，可合同里写的还是「交付源码」。

客户那句「接得住吗」，问破了一层窗户纸：源码交出去了，能力交出去了吗？

2. 传统交付：源码加人天，人走活就凉

传统外包的逻辑很简单：交付源码、按人天算钱，项目结束、团队撤场。

这套逻辑在以前没大问题，因为系统改起来慢、需求也稳。但放到 AI 时代，它有个致命问题：客户拿到了代码，却接不住。

代码躺在服务器上，真正的能力躺在你们团队脑子里。客户要改个需求，只能再花钱找人，从读代码开始。

读半天还读不顺——当初为什么这么设计、哪些坑不能踩，全在开发的记忆里，没写下来。

说白了，交付的不是能力，是个半成品。这其实是甲方和乙方都亏的买卖：甲方花了钱，没买到能自己跑的东西；乙方做完一锤子买卖，也攒不下下一次合作。

3. AI 时代，交付物清单变了

我们这几年做 AI 落地，交付范式变了一次。现在真正交付的不是源码，是四样东西，源码还排在最后：

第一样，完备的知识清单。项目涉及的领域知识、业务规则、当初踩过的坑、为什么这么设计的决策理由，全部文档化，让客户团队照着能上手。

第二样，工程体系的整套做法。我们内部怎么用 AI 干活的——需求怎么拆、怎么审、怎么验证、质量怎么把关——这套规则、流程和工具链，打包交给客户。

这里得说清楚，它不是一堆规范文档。我自己的 AI 工作区分四层：一个真身源、一层给各家工具读的镜像、一层跨项目通用件、一层项目专用件，加起来两百多个技能。管这些的不是自觉，是一条白名单同步链——什么能往外走、出去之前过哪几道检查，全写死在流程里。

比清单更要紧的，是一个能自己跑红的体检脚本。它一次跑六项，比如四层规模对不对得上、镜像有没有跟源悄悄分叉、对外仓里有没有带出不该带的东西、三个地方的计数一致不一致。任何一项不对，它红给你看，可以直接挂进 CI。

所以客户拿过去，不只是拿到一个系统，是拿到一套能自己持续演化的生产方式——而且这套方式是能自证的，不用听我讲故事。

第三样，一个统一的 AI 入口。客户公司的人，买完就能上手用，不用自己从零去搭大模型、接数据、配权限。

第四样，才是源码。

源码反而是最后交付的。因为真正值钱的从来不是代码本身，是「代码是怎么长出来的」那一套东西。

代码会过时、会重写，但那套生产方式，客户学会了就是他自己的。

4. 为什么知识清单比代码值钱

你可能会说：交付文档不是老早就有的吗？

不一样。老交付文档是「说明书」，告诉你这个系统点哪个按钮、报表从哪查；现在的知识清单是「生产方式」，告诉你这套系统以后怎么被 AI 持续改进。

举个直白的例子。同样一个报表需求，传统做法是：客户提需求、乙方排期、开发、测试、上线，来回两周。中间客户得等着，乙方得排人。

有了知识清单和那套工程体系之后呢？客户自己的团队，带着 AI 就能把这个需求改了。

他们缺的不是程序员，是「怎么让 AI 把活干对」的方法。

知识清单交付的，就是这套方法：什么需求能让 AI 直接做、什么必须人工把关、改坏了怎么回滚、哪几条业务规则绝对不能碰。

交付的尽头不是代码，是客户团队自己能跑起来的能力。

这也是为什么我敢把知识清单排到代码前面。代码是结果，知识清单是让结果还能继续长的土壤。

5. 交付过程：敏捷和瀑布为什么混着用

再说一句交付过程本身。我们现在的交付模式，是敏捷和瀑布的混合体。

听起来矛盾，其实不矛盾。需求阶段用瀑布的严谨——目标、边界、验收标准，全部前置说清楚，不许模糊；执行阶段用敏捷的灵活——小步快跑、频繁验证、随时纠偏。

为什么要这么混？因为 AI 时代交付速度变快了，但交付质量的责任一点没变。

越是快，越要有人死死守在两道闸门上：一道是「目标定义」，别做着做着跑偏了；一道是「验收」，做完了得对得上当初说的目标。

这两道闸门，恰恰也是客户「接得住」的前提。你把验收标准和目标边界都白纸黑字留下了，他以后自己干，才知道往哪使劲、怎么算合格。

6. 交接清单上，不能只有源码

清单这件事，得从 10 月的一起事故说起。开源编程智能体 OpenCode 在 10 月 17 日披露：攻击者进去的是一套正在走下线流程的老系统，受影响的是它的托管控制台 OpenCode Console 约 1.4% 的用户——这些人把 OpenAI、Anthropic、Google 的 API 密钥存在了控制台的工作区里。披露当天就有用户在 X 和 Hacker News 自报支出告警，有人一夜之间被刷掉数百美元、个别超过一千美元（均为用户自报，厂商未逐笔确认）。

随后 Anthropic 官方确认已撤销受影响的 Claude 密钥；OpenCode 称正与三家模型厂商协作处置，退款在谈、尚未承诺。

这条里有两点跟「接得住」有关。第一，被攻破的不是它现在的主力系统，是一套「已经在退役路上」的系统——这类系统的优先级永远排在活跃开发后面，也因此长期处在没人看得最紧的状态。第二，按官方口径，受影响的只有 Console 这个托管服务——本地命令行工具的密钥存在用户自己电脑上，本来就不经过它的服务器。同一个产品，凭证放在本地和放在托管平台，风险不是一个量级。

所以我现在的交接清单上，除了知识清单、工程体系、统一 AI 入口这三样，还多写了两行：一是这个系统里最值钱的那串东西放在哪、谁能碰、多久换一次；二是交付完成前的对账回执——双方各验一遍、凭证对上，才算交完。 源码依然是最后一步，但交接清单上不能只有源码。

这两行不是我想出来的，是踩出来的。就这几天做盘点，我给一个对外开源的项目仓顺手做了次体检：一批内容按流程同步出去，把内部称谓带出 7 处，还有大半年前的旧账号名散在三百多个位置。没有一处是人眼看见的，全是脚本扫出来的。

所以我不再信「交出去之前我会再检查一遍」这句承诺。人会漏，只有把检查写成脚本、每次同步都自动跑一遍，那行交接记录才不是形式主义。你带不走我的记忆，但你能带走我的检查。

7. 给甲方的四个问题

如果你是甲方，下次评估外包供应商，别只问「代码写得怎么样」。问四个问题：

第一，你的交付物里有没有知识清单，还是只有源码和一本说明书？

第二，你们自己内部怎么用 AI 干活的这套做法，能不能原样交给我？

第三，我的人，在你们撤走之后，能不能自己带着 AI 改系统？

第四，你们有没有一个统一的 AI 入口直接给我用，还是让我自己再去从零买、从零搭？

前三个问题答不上来的供应商，交付的只是代码。答得上来的，交付的才是能力。

这四个问题其实也是一面镜子：它照出的不是供应商的技术高低，是他愿不愿意把「吃饭的家伙」交给你。

8. 我押这个注

我押「交付范式转变」这个注：AI 时代，外包交付的定价逻辑，会从「代码加人天」，转向「能力加生产方式」。

谁先把知识清单、工程体系、统一 AI 入口这三样做成标准交付物，谁就能在下一轮竞争里拿到溢价。

因为客户终于算明白了：他要的不是一堆代码，是一套离了谁都能转的能力。

今天凌晨我还吃了个很小的反面样本：要发的这篇稿子，草稿箱里躺着的是几天前的旧版本，靠发布前那道回查对账才发现。交付物做得再漂亮，发错了版本，价值就是零——清单上「对账回执」那一行，就是这么来的。

我们已经在这么交付了。这也是我写这个系列的原因——一线落地的价值，从来不在代码里，在「客户接得住」的那一层。

这周做一件事：拿第七节那四个问题，过一遍你手上正在收尾的项目——你的交付物里，除了源码，客户真正带得走的是什么？再顺手把交接清单补上那两行：最值钱的那串东西放在哪、谁能碰、多久换一次；以及交付前的对账回执由谁签。

你最近一次交付，客户接得住吗？评论区聊聊。

9. 工具与信源

本文是一线 AI 落地交付的实战观察，案例均来自我参与的真实项目，客户方信息已脱敏。

「报表需求来回两周」为典型场景示意，非单一项目的精确时长；「四样交付物」是我们团队的实际交付口径，不同团队的划分方式可能不同。

文中技能分层规模（四层两百多个）与体检项（六项）为我个人 AI 工作区的实测口径，按各层目录计数、镜像层与源层存在同名重叠，不是去重后的总数；「内部称谓 7 处」「旧账号名三百多个位置」为同一轮体检的实际扫描结果，只讲数量不指向具体内容。

本文结论来自一线交付现场的一手观察，不引用外部榜单或统计；文末所附公开报道仅作事件事实核验与延伸阅读，非榜单或统计引用。

延伸阅读（OpenCode 事件公开信源）：

• OpenCode 官方口径（2026-10-17）：官方 X 帖称「影响约 1.4% 的 Console 用户、已邮件通知全部受影响者、正与 Anthropic / OpenAI / Google 协作处置」；官方社区公告称正在下线的旧系统遭未授权访问，工作区内第三方密钥可能泄露，请撤销更换并检查用量。存档 · TechNews：https://infosecu.technews.tw/2026/10/21/opencode-hit-by-distillation-attack-api-keys-at-risk存档 · INSIDE：https://www.inside.com.tw/article/42669-opencode-console-breach-1-4-percent-distillation-attack-provider-keys

• Anthropic 官方回复（2026-10-18）：已主动撤销受影响的 Claude API 密钥，建议存过密钥的用户更换新钥。存档 · GIGAZINE：https://gigazine.net/gsc_news/en/20261019-opencode-leak

• 媒体与技术侧佐证：The Hacker News：https://thehackernews.com/2026/10/opencode-console-breach-may-have.html云安全联盟 CSA Labs：https://labs.cloudsecurityalliance.org/research/csa-research-note-opencode-console-provider-key-breach-20261

如果对你有启发，欢迎点赞、在看、转发；星标「行途」，第一时间收到下一篇。

谢谢你看我的文章，下篇见。

关键词：AI 交付 / 知识清单 / FDE / AI 项目交付 / 软件交付 / AI 落地 / 工程体系