AI 时代的软件项目复杂度
过去，我们分析一个软件项目的复杂度，通常会从代码量、文件数、模块数量、圈复杂度、耦合度开始。
这些指标并没有失效。
但在 AI Agent 参与软件工程之后，它们已经不够了。
因为代码不再只是人类写给机器执行的文本，也不再只是人类之间交接知识的文档。它正在变成一种新的协作媒介：人类描述意图，AI 探索项目，工具执行反馈，人类再判断结果是否可信。
于是，软件复杂度的核心问题发生了变化：
不是这个项目有多大，
而是它能否被 AI 理解、探索、修改、验证，
以及人类能否低成本信任这个过程。AI 时代的软件复杂度，本质上是 人类与智能体共同驾驭一个系统的成本。
1. 体量：从代码量到上下文压力
文件量、代码量、模块数量，仍然是复杂度的第一层。
但它们描述的不是复杂度本身，而是复杂度的载体。
一百万行结构清晰、模式重复的 CRUD 代码，未必比五千行高度压缩的算法、交易、风控或编译逻辑更难理解。
在 AI 时代，代码量首先意味着：
这个项目会消耗多少上下文？真正重要的不是项目总共有多少代码，而是为了理解一个具体任务，AI 需要读多少文件、跨多少模块、加载多少配置、追踪多少调用链。
因此，体量复杂度可以被重新理解为 上下文压力。
代码越多，不一定越复杂； 但如果一个小需求必须牵引出巨大的上下文包，它就已经复杂了。
2. 语义：从功能数量到可提示性
一个项目承载多少功能，也不是复杂度的全部。
更关键的是：这些功能能不能被清楚地说出来。
简单的功能可以被自然语言稳定描述：
用户提交订单，系统创建订单，扣减库存，支付成功后发送通知。复杂的功能往往只能这样描述：
大体是下单逻辑，但不同渠道、客户、历史版本、活动规则、异常状态和人工干预会走不同分支。这时，复杂度来自语言与代码之间的翻译损耗。
如果一个功能无法被人类清楚描述，它也很难被 AI 稳定实现。AI 可以生成代码，但它无法凭空补全那些没有被表达出来的业务边界、历史原因和异常约束。
所以，AI 时代的功能复杂度，可以叫做：
可提示性复杂度。一个功能越难被 Prompt 清楚描述，它就越难被 AI 理解、修改、测试和复刻。
3. 上下文：从能否探索到能否收敛
现在的 AI Agent 已经具备很强的自主探索能力。
它可以自己找入口，阅读 README，分析依赖，搜索调用链，运行命令，观察错误，再根据反馈继续修正。
所以问题已经不再只是：
AI 能不能探索这个项目？而是：
它的探索能不能收敛？如果一个项目有清晰的入口、稳定的构建方式、明确的错误反馈、可运行的测试和一致的目录结构，AI 即使一开始不了解，也能逐步建立项目地图。
但如果逻辑分散在代码、配置、数据库、脚本、队列、定时任务和历史补丁中，探索就会变成无边界漫游。
AI 会不断发现新上下文，却很难判断哪些是核心，哪些是噪音，哪些是必须遵守的约束。
因此，一个项目的复杂度不在于 AI 是否能探索，而在于：
AI 的探索是否有路径、有反馈、有终点。4. 边界：从模块耦合到状态纠缠
传统软件工程谈耦合度。
AI 时代更需要谈状态纠缠。
一个系统如果边界清楚，每个模块都有明确的输入、输出、依赖、副作用和验证方式，那么它就可以被拆成一个个相对独立的任务单元。
这样的模块适合交给 AI 处理。
因为 AI 可以围绕一个有限边界完成闭环：
理解需求
定位代码
修改实现
运行测试
根据反馈修正但如果一个功能依赖全局状态、隐式配置、历史数据、外部服务、特殊客户分支和没人敢删的 hack，它就不再是一个清晰模块，而是一团纠缠的状态。
这种系统中，AI 一动就可能牵一发动全身。
所以，复杂度不只是模块之间有没有依赖，而是：
一个局部改动会不会唤醒整个系统。状态越纠缠，系统越难被 AI 局部处理，也越难被人类安全审查。
5. 暗知识：从代码可见性到隐性上下文
AI 能读代码，能读文档，能读测试，能读日志。
但它读不到没有被写下来的东西。
很多软件项目真正的复杂度，不在仓库里，而在仓库之外：
为什么这里要 sleep 50ms？
为什么这个字段不能删？
为什么这个接口不能并发调用？
为什么这个丑陋的 if 分支一直保留？
为什么这个看似多余的校验绝不能移除？这些答案可能存在于老员工的记忆、事故复盘、聊天记录、客户合同、线上故障、历史迁移和一次又一次现实妥协里。
这就是暗知识。
暗知识越多，AI 越容易自信地犯错。
它可能会把一个历史补丁看成冗余代码，把一个特殊分支看成坏味道，把一个丑陋实现重构成更优雅但错误的版本。
因此，AI 时代的软件复杂度，很大程度上取决于：
系统正确运行所需的知识，有多少没有被显性化。不在代码、文档、测试和约束里的知识，对 AI 来说几乎等于不存在。
6. 验证：从生成成本到信任成本
AI 让生成代码的成本急剧下降。
过去，写一段复杂逻辑可能需要几天。现在，AI 可能几分钟甚至几十秒就能给出一个看似完整的实现。
但生成变便宜之后，真正昂贵的东西变成了验证。
它写得对吗？
它漏掉了什么？
它破坏了什么？
它的解释可信吗？
人类是否还需要重新读一遍源码？这就是验证不对称。
AI 生成一个方案很快，但人类确认这个方案在真实系统中不会出问题，可能仍然很慢。
如果一个项目缺少测试、缺少可观测性、缺少稳定环境、缺少清晰边界，那么 AI 的产出越多，人类的验证压力反而越大。
此时，复杂度已经不再是“代码写不写得出来”，而是：
写出来之后，能不能证明它是对的。所以，在 AI 时代，验证成本就是复杂度的核心标尺之一。
一个系统是否适合 AI 协作，最终取决于它能否让 AI 的修改被快速、可靠、低成本地验证。
一个简化公式
如果用一个公式来描述 AI 时代的软件项目复杂度，可以写成：
Project Complexity ≈
Semantic Density
× Context Span
× State Entanglement
× Implicit Knowledge
× Verification Cost
÷ Capsuleability也就是：
语义越密，越复杂；
上下文越长，越复杂；
状态越纠缠，越复杂；
暗知识越多，越复杂；
验证越贵，越复杂；
越能被胶囊化，越不复杂。这个公式不追求数学精确，而是表达一种判断方式：
复杂度不是代码的物理大小，
而是系统能否被描述、装入上下文、拆开处理、探索收敛、修改验证。重构与复刻：复杂度的终局指标
判断一个项目复杂不复杂，最后可以看两个问题：
能不能重构？
能不能复刻？重构要求我们在保持行为不变的前提下改善结构。
它考验的是：
行为边界是否清楚？
测试是否可信？
暗知识是否显性？
局部修改是否安全？复刻要求我们提取核心功能，并重新实现一个等价或近似等价的新系统。
它考验的是：
主要功能是否说得清？
业务规则是否完整？
数据模型是否可理解？
异常边界是否可枚举？有些项目代码很烂，但功能简单，所以难重构，却容易复刻。
有些项目代码看似规整，但业务规则、历史数据、异常状态和外部依赖极其复杂，所以局部重构不难，完整复刻却非常困难。
因此，重构和复刻不是普通指标，而是复杂度的最终显影。
它们会把体量、语义、上下文、状态、暗知识和验证问题全部暴露出来。
总结
AI 时代，软件项目复杂度可以被压缩成六个问题：
1. 它有多大的上下文压力？
2. 它的语义密度有多高？
3. 它能否被清楚 Prompt？
4. 它的探索能否收敛？
5. 它的状态是否可以被拆开？
6. 它的修改能否被低成本验证？更简洁地说：
复杂项目不是 AI 写不出代码，
而是 AI 写完之后，人类难以确认它是否真的理解、真的改对、真的没有破坏系统。这也引出了 Harness Engineering 关心的问题。
重点不只是让 AI 生成代码，而是如何设计一个工程环境，让 AI 能够理解上下文、遵守约束、探索系统、接收反馈、修正错误，并让人类能够低成本建立信任。
AI 时代的软件工程，正在从“写代码”转向“设计可被智能体驾驭的系统”。
而复杂度分析，就是理解这一转变的第一步。