企业官网建设流程全解析

如何在5个工作日内完成技术尽职调查：面向并购与投资团队的实战清单

【免费下载链接】awesome-ctoA curated and opinionated list of resources for Chief Technology Officers, with the emphasis on startups项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-cto

技术尽职调查（Technical Due Diligence，TDD）是并购或投资前对目标公司的代码、架构、安全与工程流程做系统性审查，最终回答两个数字：估值该扣多少、交割前必须完成哪些事项。GitHub推荐项目精选（awesome-cto）是面向CTO的技术资源清单，覆盖CTO角色定位、招聘、架构、尽调等19个板块，其 Due Diligence 板块收录了4份TDD检查表与问题清单。本文基于该库搭建一套5个工作日的投资尽调执行方案，每个阶段都绑定可验证的交付物与验收门槛，你从D1起就可以直接发出数据索取清单。

D1-D2：数据盘点与范围锁定

范围直接决定工作量：一个12个服务的系统，尽调成本约为2个服务系统的3倍，D1不定死，后面全部被拖。因此第一个动作是D1上午发出数据索取清单，并约定D1 18:00前答复——未回复的条目一律记为"未提供"并写入备忘录。

数据索取清单（6项）

范围锁定的两步操作

1. 下发与设限：清单发给目标公司CTO及财务对接人，约定代码仓库以只读克隆或归档包形式提供，禁止现场逐库浏览。
2. 交叉验证：D2内将架构图与部署清单、云账单做交叉比对，计算服务不一致率。不一致率超过20%时立刻标记——这通常意味着目标公司呈现的系统边界与实物不符，范围备忘录需要返工。

交付物是一页纸的范围确认备忘录，列明范围内系统、范围外系统及三方确认人。某80人工业软件公司：首轮清单漏掉了核心引擎的SBOM，D5才发现引擎40%代码来自未获授权的商业组件，团队补做了3天排查，交易时间线整体延后2周。范围备忘录必须在D2签回，任何缺数据项都要按不确定性计价，而不是默认其无害。

D3-D5：架构与工程效能穿透

架构穿透回答两个数字：架构还能扛多大业务量、团队交付有多快。两个数字都是定价的直接输入，且必须在穿透期内自采数据，自述材料不作数。

架构穿透步骤

三个执行要点：依赖盘点阶段生成含版本与许可证的组件清单，GPL类与商用授权组件单独标红；单点识别阶段将依赖图与近12个月复盘记录交叉，某节点若一年内引发2次及以上P1/P2事故，记为高危单点；扩展性测算以3个月云账单与峰值QPS为输入，输出"支撑用户量增长10倍"的改造工作量估算，这个数字将直接进入后文的定价公式。

工程效能度量：3个指标

只看3个指标，2周数据即可：中位周期时间（PR创建到合入生产的间隔）、发布频率、每周生产事故数。健康团队的中位周期时间基准是3个工作日以内。某60人B2B SaaS公司：中位周期时间为11天，其中4天消耗在人工审批上；交割后买方将其审批流并入自有流水线，花了3.5个月，实际整合成本约210万元人民币——这笔钱如果在D3被度量出来，会直接进定价公式而不是进交割后预算。

D6-D8：安全与合规核验

安全是最常触发交易终止的维度，也是最容易被造假的：自述漏洞清单可以筛选，渗透测试报告可以外包美化。唯一可靠的办法是自己跑一遍扫描。

红绿灯分级标准

分级执行细则：Critical与高危以扫描引擎CVSS ≥9.0判定；"3个以上中危漏洞"按近12个月累计计数；修复预算公式中的1.3是预留系数，用于覆盖修复后必然发生的复验与回归测试成本。

数据合规核验三件事

涉及个人数据的交易，做三件核验：其一，调取数据分类清单，统计个人数据与敏感数据各自存储量；其二，绘制跨境数据流向图，逐条核对跨境传输机制（标准合同条款、安全评估备案等）是否落地；其三，实测账号注销能力——"用户提交注销 → 生产数据30天内完成脱敏删除"能否全链路走通。三项中任何一项无法当场演示，直接按🔴级处理，不给口头承诺留余地。

D9-D10：风险量化与定价调整

风险量化是TDD报告的核心环节，方法分两步：先把所有风险点按"发生概率 × 影响程度"分进四个象限，再把每个象限翻译成钱。

风险矩阵与处置规则

处置规则固定：交易关键区条目变成交割条件或终止理由；谈判区条目按修复成本扣价；整合区条目写入交割后整合路线图并带里程碑；可接受区仅备注。概率按"历史发生频次 + 现状证据"判定，影响按"直接损失金额 + 业务中断时长"判定，两个维度都要能写出数据来源。

评分模型与调价测算

综合得分 = Σ（维度得分 × 权重），用于横向比较不同标的。但定价不看综合得分，看高危项成本：技术尽职调查报告的输出是价差与交割条件清单，而不是一堆形容词。调价公式：

调价比例 = Σ（交易关键区与谈判区条目的预估修复成本 ÷ 交易前估值）× 1.3

测算示例：某跨境并购标的交易前估值3亿元，尽调识别出两条高危——核心数据中心无跨地域灾备（改造500万元、工期6个月）、开源许可证冲突（替换成本200万元）。调价比例 = 700万 ÷ 3亿 × 1.3 ≈ 3.0%。最终交易按3%扣价成交，并附加两条交割条件："灾备方案于D120前通过复验""许可证替换在整合启动前完成"。

从报告到D30：把结论变成交割条件与行动清单

TDD报告如果不能翻译成合同语言与里程碑，就只是一份咨询交付物。技术风险最终要落成三类可执行资产：调价、交割条件、整合路线图。

报告四段结构

固定四段：① 执行摘要（1页以内，只写调价比例、红绿灯结论、最重要的2条交割条件）；② 评分卡与风险矩阵（直接放本文的评分表与象限图）；③ 风险清单（按优先级排序，每条含责任人、成本估算与建议期限）；④ 交割条件清单（与交易关键区风险逐条对应，写明复验方式与截止日期）。不写"技术点评"章节——不带成本估算的点评会被业务方稀释掉。

30天行动清单

• 报告交付后3个工作日内，与法务、财务对账调价比例，锁定进交易合同
• 7天内把交易关键区与谈判区条目的整改拆成周级里程碑，指派责任人，输出整合路线图
• 14天内完成整合环境第一次联调：目标系统接入买方监控告警与权限体系
• 30天内对交割条件逐项复验，复验证据归档备查
• 设立交割后D30复盘会：实际整合成本对账TDD估算，用实际偏差修正1.3预留系数

资源库：awesome-cto 的用法

awesome-cto 仓库的 Due Diligence 板块 收录了技术尽职调查检查表、TDD问题清单、IT部门尽调清单、TDD生存指南共4份资源清单，D1 可基于它们生成自己的数据索取清单初稿；"Development process"与"Architecture"板块则用于评估目标公司CI/CD成熟度与架构水平，也是交割后整合的参照基线。需要本地化使用完整清单时：

git clone https://gitcode.com/GitHub_Trending/aw/awesome-cto

清单处于持续更新状态，建议每笔交易启动前重新核对一次版本，避免漏掉新增检查项。

【免费下载链接】awesome-ctoA curated and opinionated list of resources for Chief Technology Officers, with the emphasis on startups项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-cto