买代码还是买人？技术收购策略里那张常被漏看的图纸
去年秋天，南京雨花台软件大道边上一家咖啡馆，老周把电脑推到我面前。屏幕上是某家AI质检公司的代码仓库截图，十几万行，专利清单列了半页，报价在他看来不算离谱。他压低声音说，这回捡到宝了。我没接话，先问了三个问题：训练数据从哪来？标注规则谁定的？那台跑老版本CUDA的服务器还在不在？他愣住。说实话，这三个问题里任何一个答不上来，技术收购策略就得重写。
后来交割了，麻烦果然来了。仓库能编译，模型训不出来。数据管道脚本里硬编码着某台内网机器的路径，预处理逻辑躺在离职工程师的笔记本里，专利证书很漂亮，但有一块代码混进了GPL。老周原以为买的是技术资产，结果买到的是一堆需要考古的现场。技术收购策略这件事，真不是把代码打包带走那么直给。
仓库能跑，不等于技术能接管
很多收购方做技术尽调，习惯看三样：代码行数、专利数量、团队简历。看着挺像回事，对吧？可代码行数是个虚荣指标。十万行里有多少是生成代码，有多少是复制粘贴，有多少是没人敢动的祖传模块？不打开看，根本不知道。
我一般会要求目标团队做一次从零构建：拿一台干净机器，按文档把服务跑起来。注意，不是在他们现成的开发环境里演示，是干净机器。依赖版本、环境变量、数据库迁移、证书、密钥、第三方服务账号，全得从文档里找。这个过程像买二手房看水电图——装修能骗人，水管走向骗不了人。很多团队这时候就开始冒汗，因为README里写着“联系老王获取配置”，而老王上个月刚办完离职。
技术资产不是静态代码快照。它至少分四层：代码和模型权重是一层，数据和数据管道是一层，构建部署工具链是一层，团队脑子里的隐性知识又是一层。技术收购策略如果只盯着第一层，交割后就会陷入“能看不能改”的尴尬。改一个小需求，先花两周搭环境，再花三周猜逻辑，这账怎么算都不对。
软件技术收购代码仓库尽调流程图
还有个细节常被漏掉：可复现性。模型类资产尤其明显。训练脚本能跑通，不代表同样的数据能训出同样的指标。随机种子、框架版本、CUDA版本、甚至某张显卡的驱动，都可能让结果漂移。技术收购策略里应该写清楚：交割前做一次复现实验，误差范围写进验收标准。别嫌麻烦。等到交割后才发现模型效果对不上，扯皮成本比尽调高得多。
专利证书很漂亮，许可证可能咬人
专利清单好看，我承认。但技术收购里还有一张表更值得看：开源许可证清单。代码仓库里混进一段GPL，闭源产品再分发时可能触发开源义务；SaaS服务用到AGPL，网络交互也可能被要求提供源码。这不是吓唬人，是实实在在的合规成本。
做法不复杂。让目标公司提供SBOM，也就是软件物料清单，把直接依赖和间接依赖列清楚。再用扫描工具跑一遍许可证冲突。重点看三类：传染性许可证、商业授权限制、以及来源不明的代码片段。有些团队从论坛复制一段工具函数，没标出处，这种最麻烦。技术收购策略里可以加一条：交割前完成许可证清零计划，替换不掉的就隔离，隔离不了的就重新谈价。
软件技术收购开源许可证合规扫描界面
数据权利也别漏。训练数据是爬来的、买的、还是客户授权？标注规则有没有版本记录？数据里有没有个人信息？这些问题在技术尽调阶段不显眼，到了监管问询时就会集中爆发。我见过一家公司，模型效果挺好，但数据授权只覆盖“内部研究”，收购后想商业化，得重新谈一遍授权。那笔钱，可比代码值钱多了。
估值别按代码行数，按“改一行要多久”
估值别按代码行数，按“改一行要多久”
技术收购策略里，估值模型常把技术资产当固定资产折旧。可技术会腐烂。架构耦合、测试缺失、部署靠手工、故障恢复靠人肉，这些都是隐性负债。怎么量化？我有个土办法：让目标团队现场改一个小需求，从提分支到上线，计时。再看一次端到端故障恢复，从报警到服务恢复，计时。这两个时间比任何架构图都诚实。
比喻一下，买厨房不是看锅多，是看点火到上菜要多久。技术团队也一样。改一行代码要动五个模块，说明耦合重；每次发布都要停服，说明工具链欠账；监控靠眼睛盯日志，说明可观测性没建起来。这些不会写在专利证书上，但会写进你交割后的运维账单。
所以技术收购策略里，对价结构可以更技术化。别只对赌营收，可以对赌技术里程碑：关键模型复现误差低于约定阈值，核心服务构建时间降到可接受范围，许可证问题清零，关键人留任到知识转移验收。听起来琐碎，可这些条款能把“买代码”变成“买可接管的能力”。
交割不是终点，知识转移要写进日历
我见过挺可惜的案子。收购方看中一支算法团队，签字当天大家举杯，三个月后团队负责人被调去总部，剩下的人陆续提离职。买的是人，结果只买到工位。技术收购策略如果不在交割前设计留任机制，后面补锅很被动。
留任不是简单加钱。关键人得知道交割后向谁汇报、技术路线谁拍板、预算怎么走。还可以用反向归属、顾问期、知识转移奖金，把“把事讲清楚”变成可验收的交付物。文档要写，结对要排，代码所有权和权限要逐步移交。技术转移不是开一次会，是排进日历的连续动作。
技术收购后团队知识转移会议白板照片
还有权限。生产环境密钥、云账号、域名、证书、第三方API配额，交割清单里一项项勾。别笑，真有人交割后才发现模型推理服务绑在创始人个人云账号上。技术收购策略的落地，最后都落在这些不浪漫的清单里。
边界：有些技术不该买，该租或自研
边界：有些技术不该买，该租或自研
话说回来，技术收购不是万能钥匙。如果目标公司的优势来自数据飞轮，而飞轮绑在独家场景上，你买走代码也买不走飞轮。如果优势来自一两个关键人，签顾问协议可能比买公司便宜。如果优势来自许可证壁垒，先谈授权，别急着谈股权。
技术生命周期也得看。一个技术栈如果三年后大概率被开源方案抹平，收购溢价就得打折。监管敏感的数据资产，交割后能不能迁移、能不能合并，也要提前问清楚。技术收购策略的边界感，恰恰体现在知道什么时候不买。
老周后来补了条款：数据管道重写，关键人留任十八个月，许可证替换，知识转移按周验收。多花了四个月，但系统终于能接管。他跟我吐槽，说这哪是收购，简直是搬家。我说对啊，搬家不是把家具搬过去就完了，水电燃气得过户，物业得交接，钥匙得一把把试。技术收购策略里那张常被漏看的图纸，就是这些过户单。别只看房产证，图纸才是你住进去以后会不会跳闸的关键。