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 时代的软件工程，正在从“写代码”转向“设计可被智能体驾驭的系统”。
而复杂度分析，就是理解这一转变的第一步。
