用claude code在遗留项目中新增功能模块的模块划分争议

别吵了。当两个老程序员在会议室里争了40分钟，一个坚持“新增的风控模块必须按Claude Code建议的独立服务走”，另一个拍着桌子吼“你知不知道这个项目里订单表和用户表有多少隐式依赖”，而项目经理盯着他俩问了句：“那你们告诉我，什么时候该听AI的、什么时候不该听？”

这不是虚构场景。上个月在一个跑了9年的零售ERP项目里，我们给订单系统加实时反欺诈校验，Claude Code第一次给出的模块划分建议把团队劈成了两派，AB方案各有利弊，谁也说服不了谁。最后我们没靠“经验直觉”做决定，也没让AI替我们拍板，而是用了一套自己总结的评估方法，花18分钟就锁定了方案。

这篇文章不打算告诉你Claude Code好还是不好，也不会说“看情况而定”这种正确的废话。我想把这件事拆开揉碎了讲清楚：当你在遗留项目中用Claude Code新增功能模块时，模块划分的争议到底争的是什么、怎么量化这个争议、以及在不同场景下你该怎么选。

一、先把结论撂这儿：模块划分的争议，本质是三类信息的认知差

在聊具体方法之前，我先把我自己在7个项目里反复验证过的核心结论说出来，你可以把它当成本文的“总论点地图”：

Claude Code在遗留项目中给出的模块划分建议之所以引发争议，不是因为AI能力不足，而是因为三类信息存在严重不对称：

用一句话概括：Claude Code能理解你的代码长什么样，但理解不了你的代码“为什么长这样”。

而模块划分的争议，本质上是在争：我们是按“理想架构”来设计，还是按“现实约束”来妥协？Claude Code天然偏向前者，它只要见过足够多优秀的开源项目结构，就能生成一份“教科书级”的模块划分方案。但遗留项目之所以叫“遗留”，恰恰因为它身上背着一堆教科书不会写的债。

所以我的核心主张是：不要和Claude Code争对错，要和它对话，把它当成一个能快速生成“理想蓝图”的参谋，而你，才是那个拿着工程地形图做最终决策的指挥官。

二、争议的真实背景：遗留项目到底“遗留”了什么？

在展开方法论之前，我们必须先把“遗留项目”这个概念说清楚。很多人一说遗留项目就想到“老”“代码烂”“没人敢动”，但这几个词太模糊了，没法支撑决策。我需要你建立一套更精确的认知。

2.1 我定义的“遗留项目”四个特征维度

经过这些年接手的大小项目，我把遗留项目的特征归纳为四个可衡量的维度：

维度一：依赖混乱度

这不是“依赖多不多”的问题，而是“依赖有没有规则”。健康的项目依赖通常呈现清晰的分层或领域边界，而遗留项目的依赖图往往像一团乱麻。我见过最极端的一个PHP项目，一个处理“商品收藏”的业务方法，其调用链居然会穿透到“优惠券计算”、再跳转到“用户积分”，这三个属于完全不同的领域，但因为在三次需求迭代中，不同的开发者为了快速上线，直接复用了现有的查询逻辑，导致它们在代码层面耦合在了一起。

这种隐式耦合，Claude Code通过静态分析是很难完全识别的，因为它看起来就是正常的import关系。

维度二：全局状态渗透率

全局变量、静态工具类、未被封装的环境配置……这些是遗留项目里的“暗物质”。它们不做声，但无处不在。

我统计过手头一个5.2万行的Node.js老项目，全局状态（包括挂在global上、未被模块化的单例、通过process.env散落在各处的配置读取）的渗透率达到了34%，也就是说，每三个模块里就有一个，会以某种方式触及全局可变状态。

这对模块划分的影响非常大：如果你把其中一个模块拆出去，它可能悄无声息地依赖着某个全局变量；而Claude Code在建议拆分方案时，如果这个依赖没有被显式声明（比如通过参数传入），AI很容易误判为“这个模块没有依赖，可以独立”。

维度三：测试覆盖空洞

很多遗留项目的单测覆盖率是个“薛定谔的数字”，有测试文件，但不代表它们真的在验证核心业务逻辑。我见过有的项目单测覆盖率显示68%，但细看之下，绝大部分测试都在测工具函数和CRUD，核心业务流程完全靠“上线前手工点点”。

这意味着什么？意味着当你按照Claude Code的建议重构模块边界时，你没有安全网。AI生成的划分方案可能是逻辑自洽的，但如果缺少回归测试的保护，一个看似优雅的拆分可能导致线上P0事故。

维度四：非技术性边界

这一点很少有人提，但它往往是模块划分争议中最实际的卡点。

什么叫非技术性边界？比如：这个模块由A团队维护、那个模块归B团队，两个团队的绩效考核分别挂在不同的业务指标上；又比如：支付相关的代码必须部署在通过PCI-DSS认证的服务器上，你不能随便把它和普通业务模块混在一起；再比如：某一批接口的发布节奏必须跟着合作伙伴的排期走，不能独立迭代。

Claude Code完全感知不到这些约束。它在看代码的时候，不知道有一个模块之所以没有独立拆分，是因为组织架构决定了没人愿意接手它。

2.2 遗留项目里新增功能的三种典型场景

在明确了“什么叫遗留项目”之后，我们再把新增功能这个场景拆开。我发现很多争议其实是因为场景判断错误，人们把不同性质的新功能混在一起讨论，自然鸡同鸭讲。

我总结出三类场景，它们对模块划分策略的影响截然不同：

场景A：独立新增功能

特征：与现有业务逻辑几乎没有交集，你引入的新模块可以做到“只读旧数据、不写旧表、不改旧逻辑”。比如在一个成熟的电商后台里，新增一个“客户满意度分析看板”，它只从已有的订单表、售后表读取数据进行聚合分析，本身不修改任何核心业务流程。

这种场景下，Claude Code的建议通常高度可用，因为它只需要理解数据结构和查询接口，不需要处理复杂的业务耦合。

场景B：扩展现有功能

特征：不改变核心业务流程，但在现有逻辑链上插入新的处理节点。比如在订单状态机里增加一个“风控审核中”的状态，或者在用户注册流程后加入“实名认证”步骤。

这种场景最容易引发争议，因为扩展点和原有逻辑的交界面有多宽、扩展方式是用AOP还是硬编码插入、是否需要在多个模块中同步修改，这些都决定了代码的侵入程度。而Claude Code往往会被现有代码的写法“带偏”，如果原项目习惯硬编码插入，AI可能也依葫芦画瓢。

场景C：改造核心链路

特征：新功能会从根本上改变某个核心业务流程的走向。比如把原来的“下单即扣库存”改成“支付完成后才扣库存”、或者把同步调用的风控检查改成异步事件驱动。

这种场景下，我建议不要让Claude Code直接做模块划分，因为它理解不了业务流程为什么当初被设计成这样。你需要先做业务梳理，再把结论喂给AI去执行。

三、拆解四个最常见的模块划分误区

进入正题前，先扫一遍雷区。下面这四个误区，是我在带团队、审代码、甚至自己动手的时候反复碰到的。每一个我都痛过，所以希望你不用再痛。

误区一：“Claude Code给的划分很清晰，就按这个来吧”

这是最容易踩的坑，也是初级工程师最常犯的错。

Claude Code给你的模块划分建议，看起来总是很“干净”，分得清清楚楚，依赖方向统一，命名也规范。但它的干净是建立在“对隐性约束无知”的前提上的。你一旦真的按那个划分落地，上线之后可能会发现：某个看起来很独立的模块，居然在没人改动的情况下出Bug了，原因是它曾经隐性依赖了另一个模块里的静态方法，拆分之后找不到那个方法了。

所以我的原则是：Claude Code的输出永远是“草稿”，不是“终稿”。它没有资格替你做决定，但它有资格帮你快速完成80%的分析工作。

误区二：“手动划分一定更安全，毕竟我最了解这个项目”

这个误区通常发生在资深开发者身上，尤其是那些在这个遗留项目上耕耘了三四年的老人。但坦白说，我对这种自信是保持警惕的。

人对复杂系统的记忆是有选择性的，而且倾向于高估自己对全局的掌握程度。 我见过一个挺典型的案例：一位开发组长坚持“用户中心和订单中心之间只有查询依赖，不会产生写操作”，基于这个判断他手动设计了一套模块拆分方案。结果上线后，有个沉寂了两年的“订单完成自动更新用户等级”的逻辑被触发，产生了跨模块写操作，这个逻辑因为太久没被动过，连当初写它的人都忘了。

Claude Code的价值恰恰在于：它不会遗忘。 它可以通过全量代码扫描，帮你揪出那些人脑已经遗忘的隐式耦合点。所以手动划分不是不行，但你需要用AI来做“查漏补缺”的兜底。

误区三：“争议就是技术方案之争，让技术委员会投票决定”

这是最容易浪费时间的方式。我参加过太多次这种会议，几派人各自陈述理由，最后举手表决，少数服从多数。

但问题是：模块划分的取舍，本质上不是民主投票能解决的技术问题，而是一个需要权衡多方因素的工程决策问题。 投票只能得出“多数人认为哪个方案好”，不能得出“哪个方案在给定约束下最优”。你需要的是决策框架，而不是投票箱。

误区四：“先上线再说，划分错了大不了再重构”

这句话在不同语境下有截然不同的后果。如果你的新增功能是独立看板类需求，确实可以“先上线再优化”，因为破拆成本低。但如果你的改动涉及到核心交易链路，模块划分错误的一步，可能意味着三个月后的一次被迫全面返工，到那个时候，业务代码已经在错误边界的基础上又多迭代了好几轮，重构成本是指数级上升的。

所以“先上线再说”是否正确，取决于你的场景类型和项目的依赖复杂程度。后面我会给出具体的判断标准。

四、我的核心框架：三维评估法，把“吵架”变成“填表”

这节是全文最核心的部分。我把前面几节的分析收敛成一个可操作的决策框架，我管它叫“三维评估法”，不是什么高深的学术理论，就是我在多个项目里摸爬滚打后沉淀下来的一套打分和判断规则。

它的逻辑很简单：任何一个在遗留项目中使用Claude Code进行模块划分的决策，都可以从三个维度来量化，你不需要拍脑袋，你只需要填表。

4.1 维度一：现状依赖复杂度（S-Dependency Complexity）

这个维度衡量的是：你当前这个遗留项目，内部依赖到底有多乱。

我设计了一个简易的6项评分表，每一项0-2分，总分0-12分。你可以不需要任何工具，花15分钟手工完成初步评估：

评分项：

1. 循环依赖存在度（0分：无循环依赖；1分：偶有循环依赖但仅限工具类；2分：核心模块间存在循环依赖）
2. 全局状态渗透率（0分：<5%模块触及全局状态；1分：5%-30%；2分：>30%）
3. 隐式耦合点密度（0分：依赖关系全显式声明；1分：部分模块通过事件总线/中间件隐式依赖；2分：大量通过全局变量、静态方法、直接DB表访问传递依赖）
4. 最近一次重构距今时间（0分：1年内有过结构化重构；1分：1-3年；2分：3年以上或从未系统重构）
5. 原核心开发者在职率（0分：>60%原核心成员在职；1分：30%-60%；2分：<30%或全部离职）
6. 文档与注释覆盖率（0分：核心模块有架构文档；1分：有零散注释但无系统文档；2分：几乎没有有效文档）

总分判读：

• 0-3分：低复杂度，项目依赖关系相对清晰
• 4-7分：中复杂度，需要谨慎处理，部分模块间存在隐性依赖
• 8-12分：高复杂度，强制进入人工主导模式，此时不要指望任何AI工具能独立搞定模块划分

4.2 维度二：新功能的业务独立度（F-Function Independence）

这个维度回答的问题是：你要新增的这个功能，和现有业务的牵连有多深？

同样6项评分，每项0-2分，总分0-12分：

1. 数据写入范围（0分：仅写入新建表，不改动任何现有表结构；1分：需修改现有表字段或索引；2分：需修改现有核心业务表的主数据结构）
2. 流程插入性质（0分：完全独立的异步任务或批处理；1分：即在现有同步链路中插入新节点；2分：需改变现有核心流程的调用顺序与走向）
3. 跨模块影响面（0分：影响1个模块；1分：影响2-3个模块；2分：影响超过3个模块或涉及基础设施层）
4. 回滚成本（0分：可独立回滚，不影响任何现有功能；1分：回滚需同时回退关联模块；2分：回滚会导大量业务数据不一致）
5. 测试保护程度（0分：受影响模块有充分的自动化回归测试；1分：有部分测试但覆盖不足；2分：基本没有自动化测试保护）
6. 发布独立性（0分：可独立部署发布；1分：需与少量关联模块同步发布；2分：必须整体发布，受制于非技术因素如合规审查、合作伙伴排期等）

总分判读：

• 0-3分：高独立度，新增功能与现有业务松耦合
• 4-7分：中独立度，需关注边界处理
• 8-12分：低独立度，必须做影响面分析后再启动编码

4.3 维度三：Claude Code输出的稳定度（C-Consistency Score）

这个维度比较特殊，它不评项目也不评功能，而是评：你眼前的这个Claude Code版本，给你生成的模块划分建议，到底靠不靠谱？

为什么需要这个维度？因为我在实践中发现，Claude Code不同版本、不同会话、甚至同一个需求换个问法，给出的划分建议都可能不一样。这种不一致性本身就应该被纳入决策考量。

评分方式（每项0-2分，总分0-10分）：

1. 多次生成的划分方案一致性（0分：3次独立提问，划分方案核心结构一致；1分：方案差异但分歧点集中在非核心模块；2分：每次给出的核心模块边界都不一样）
2. 建议中包含具体依赖分析（0分：清晰列出每个模块的上下游依赖及原因；1分：只描述了模块职责但未详述依赖；2分：仅给出目录结构和命名，未说明划分逻辑）
3. 对遗留代码特殊性的适应（0分：能识别并尊重现有的全局状态、配置约定；1分：部分采纳现有约定，部分给出理想化建议；2分：完全忽视现有约定，按理想架构输出）
4. 风险感知能力（0分：主动提示高风险耦合点并给出替代方案；1分：提示了风险但未细化；2分：未提及任何划分风险）
5. 能否解释划分逻辑（0分：能解释“为什么这么划分”并关联业务语义；1分：能从技术角度解释，但不涉及业务；2分：无法解释划分原因或解释模糊）

总分判读：

• 0-3分：AI输出稳定度高，建议可信赖
• 4-6分：稳定度一般，需重点审查
• 7-10分：输出不稳定，仅作参考，不做决策依据

4.4 三维联动决策矩阵

有了三个维度的评分，接下来就是最关键的一步：综合决策。

我总结了一个决策矩阵，根据三维评分的组合，把应对策略分成四档：

这个矩阵的使用方法非常简单：

1. 先对项目和功能分别打分，得出S和F的值
2. 再对Claude Code的输出跑评分，得出C的值
3. 找到对应的策略档位
4. 按策略档位执行，不要越级

特别注意：S≥8或者F≥8时，无论C是多少，都不要把决策权交给AI。这不是保守，是工程责任。

五、三步落地法：从争论到代码入库

光有决策框架还不够，你得知道在实操中怎么一步步推进。下面是我总结的三步流程，每一步我都标注了具体动作、检查点和常见陷阱。

5.1 步骤一：跑一次依赖分析（30分钟内完成，不依赖Claude Code）

在让Claude Code帮忙做任何模块划分之前，你必须先对现有项目的依赖面貌有个客观认识。这一步的目的是：获取一个中立的依赖视图，避免被AI输出的自信表述带偏。

推荐工具（按语言选）：

• JavaScript/TypeScript: dependency-cruiser + madge
• Java: jdeps + ArchUnit（写几行规则检查循环依赖）
• Python: pydeps + import-linter
• PHP: deptrac 或 phpdcd
• Go: go mod graph + 自定义脚本

具体动作：

1. 生成当前项目的依赖关系图（建议导出为dot或svg格式）
2. 标记出所有循环依赖的节点
3. 标记出高频被引用节点（被超过10个模块引用的“基础模块”）
4. 识别“上帝模块”（代码行数超过平均模块3倍以上，承担过多职责的文件）

跑完这一步，你应该能画出一张类似下面的依赖现状图，它不漂亮，但它真实。把这张图保存在手边，后面你审查Claude Code的建议时，会反复对照它。

5.2 步骤二：用评分表决定AI参与度（10分钟，团队一起填）

召集相关开发人员，花10分钟填完4.1-4.3节的三张评分表。注意：这个评分过程必须团队一起做，不能一个人拍。 原因是不同成员对项目状态的认知可能差异极大，新人可能给“文档覆盖率”打高分（因为他不知道那些注释已经过期三年了），而老人可能给“循环依赖”打低分（因为他习惯了，不觉得那是问题）。

评分完后，对照4.4节的决策矩阵，确定你当前场景下AI应该参与多少。

做出决定后，把三个维度的总分和对应策略写下来，发给团队所有人。 这一步看似多余，但实际上非常关键：它把“我们为什么选择这种方式”的理由显性化、存档了。 将来如果有人质疑“为什么这次不用AI方案”，或者反过来“为什么这次没做人工审查”，你有据可查。

5.3 步骤三：执行评审，审查Claude Code输出的“坏耦合信号”

如果你的场景进入了“AI初稿”或“AI辅助”模式，那么你一定会拿到Claude Code的一份模块划分建议。此时你需要做的不只是“看一看觉得有道理就通过”，而是要进行系统化审查。

我总结了一个审查清单，专门用来检测AI建议中的“坏耦合信号”：

模块边界审查清单（6项必查）：

1. 跨模块写操作检查：AI建议的方案中，是否存在A模块直接写入B模块的数据库表？如果存在，这个边界划分很可能有问题，要么该表应该归属于A模块，要么这个写操作应该封装成B模块的接口被A调用。
2. 全局状态依赖检查：新模块是否依赖了原项目中的任何全局变量、静态工具类？如果依赖了，这个全局状态是否能被注入或参数化？
3. 循环引用预警：在新旧模块的依赖关系图中，是否出现了新模块→旧模块→新模块的循环路径？
4. 隐式契约检查：新模块是否依赖了旧模块中某个“碰巧工作”但未被正式约定的行为？典型信号：新模块的单元测试在本地通过但CI上失败，因为CI环境的某个全局配置不同。
5. 构建配置影响面：AI建议的目录结构是否打破了原有的构建脚本、打包规则、容器编排配置？比如一个Webpack多入口项目，AI建议新增一个子目录但没有同步更新entry配置。
6. 部署单元一致性：AI建议拆分的模块，在实际部署时是否必须在同一个进程中运行？如果是，拆分的意义需要重新评估，为了“代码整洁”而引入进程间通信的成本往往被低估。

审查规则：

• 如果6项全部通过，AI方案可以直接采纳
• 如果1-2项亮红灯，修改后可以采纳
• 如果超过3项亮红灯，放弃AI方案，人工重新划分

六、案例复盘：如果当初用了这套方法

下面我讲两个真实的脱敏案例，分别对应“AI方案大获成功”和“AI方案引发返工”两种走向。对照三维评估法回看，你会清晰地看到成功和失败背后的结构性原因。

6.1 正面案例：独立报表模块，5天完成、零返修

项目背景：一个运行了7年的服装行业进销存系统，后端Java + Spring，前端混杂JSP和Vue2。需求是在后台新增一个“滞销品预警看板”，从已有的订单表、库存表中读取数据，按照自定义规则计算滞销指数并展示。功能完全独立，不改变任何现有业务流程。

三维评估打分：

• 依赖复杂度(S)：2分（项目虽然老，但订单域和库存域的边界相对清晰，只有少量查询入口相互引用）
• 功能独立度(F)：1分（只读旧数据，写入新建的3张看板结果表，不影响任何现有表结构）
• AI稳定度(C)：2分（Claude Code连续3次输出的划分方案一致，且明确给出了看板模块应独立于订单和库存模块的理由）

决策：按照矩阵，进入“AI主导+人工快速审查”模式。

过程：我让Claude Code读取了订单表、库存表的数据结构定义，并让它分析了这两个域中与“滞销判断”相关的业务逻辑。15分钟后AI给出了第一版模块划分：建议在看板模块中只定义计算规则和展示逻辑，数据读取通过已有的DAO层接口完成，不直接访问数据库表。

我的审查只花了20分钟，重点检查了：

1. 它是否会跨模块直接操作其他域的数据表（没有，都走的DAO接口）
2. 它的计算结果写入的新建表有没有和其他域产生隐式耦合（没有，3张新表全部在看板模块内）
3. 它的依赖方向是否清晰（清晰，看板→订单DAO/库存DAO，无反向依赖）

结果：5个工作日完成开发和测试，上线后零返修。事后复盘评分，三个维度的得分都落在安全区间内，用最小的人工投入撬动了最高的AI效率。

6.2 反面案例：抽奖插件被并入订单模块，耦合爆炸

项目背景：一个电商平台的促销系统，需要在订单确认页增加“支付后抽奖”功能。原系统中促销逻辑散落在3个独立的微服务中，分别是“满减计算服务”“优惠券服务”和“积分服务”，但它们之间通过一个共享数据库和Redis集群隐式耦合。

三维评估打分（我当时跳过了这一步，直接拿了AI的建议，问题就出在这儿）：

• 依赖复杂度(S)：9分（事后评估：三个促销子服务存在严重的数据库级别耦合，没有明确的接口契约，大量全局Redis键被直接读写）
• 功能独立度(F)：6分（抽奖功能需要读取订单状态变更事件，且需要在多个促销规则中插入新的优先级判断）
• AI稳定度(C)：3分（但我在当时并没有跑稳定性测试，只看了一次输出就做了决定，这本身也是个错误）

当时发生的事情：Claude Code分析了订单服务的代码后，给出了一个建议，在订单服务内部新建一个lottery子模块，抽奖逻辑直接嵌入订单完成流程中。从代码结构上看，这个建议是合理的：它避免了跨服务调用，减少了网络开销，而且利用了订单服务已有的数据库连接。

但它没“看到”的：

1. 那个Redis集群里有一个全局的“促销活动优先级栈”，由满减服务和优惠券服务共同维护，抽奖功能的优先级必须插入这个栈中，而订单服务原本无权操作它
2. 抽奖的中奖结果需要反向写入积分服务的用户账户，而这个写入操作不能走订单服务的数据库连接，积分服务有自己独立的写入校验逻辑
3. 最致命的是：当时积分服务正准备拆分独立用户账户模块，而订单服务里的抽奖逻辑会在这个拆分过程中成为新的耦合锚点

结果：按照AI建议的方案上线后，第三周就遇到了积分服务拆分导致的抽奖功能崩溃，因为订单服务直接写入了积分账户表，而积分团队在拆分时改了表结构，订单服务这边完全不知道。最后花了整整两天做紧急修复，把抽奖逻辑从订单服务中剥离出来，重构成一个独立的抽奖服务。

事后复盘：如果当时我先跑了依赖分析，就会发现三个促销子服务之间的数据库级别耦合，Claude Code的静态代码分析根本看不出这个层面的问题。如果当时我认真填完了S维度的评分表，就会清楚地看到9分已经跨过了“强制人工主导”的红线。当时的不理性乐观，直接转化成了两周后的紧急返工。

七、不同场景下的取舍：几个你大概率会遇到的纠结时刻

在实际工作中，很少有机会碰到“三维评分全部落在安全区”的理想情况。更多时候，你会面对各种两难选择。下面四个场景，每一个都是我或者我带的人真实纠结过的。

7.1 依赖复杂度高但功能独立度也高，该不该让AI参与？

典型场景：一个10年的CRM系统，内部依赖乱成一锅粥，但你这次要新增的功能是一个完全独立的“客户标签自动生成引擎”，它只从客户表中读取数据，计算结果写入新建的标签表，逻辑完全自闭环。

我的建议：可以适度让AI参与，但参与方式不是“替你做决定”，而是“帮你做验证”。

具体做法：让人工先划定大致的模块边界（因为你对这个混乱的项目最了解），然后让Claude Code在这个边界内生成具体的代码结构和内部划分。AI的职责是从架构层面验证你划定的边界是否真的“无泄漏”，它会比你更快地发现你的新模块是否意外引用了某个不该引用的工具类。在这个场景下，人做顶层设计，AI做细节校核，是投入产出比最高的分工。

7.2 AI稳定度很低但你又急着上线，要不要硬上？

典型场景：连着问了Claude Code三次，三次给出的模块划分方案都不一样，第一次说独立服务，第二次说嵌入订单模块，第三次说用观察者模式解耦。但需求排期就摆在那儿，你没时间反复推敲。

我的建议：如果C维度得分超过7分（非常不稳定），且你的功能独立度F得分不高（意味着出问题影响面大），直接放弃AI辅助划分，回归手工方案。但要做一个补偿动作：让Claude Code对手工方案做“反方辩论”，请它站在对立角度批判你的方案，找出你遗漏的耦合点。这比让它当设计师可靠得多。

我做过对比实验：在同一个项目里，让Claude Code“设计”方案时，它给出的质量波动很大（不同会话差异明显）；但让它“批判”一个既有方案时，它能稳定地发现大约70%的人为遗漏问题。批判比创造稳定，这是目前AI工具的一个特点，利用好它。

7.3 团队里有人特别抗拒AI，怎么推动？

典型场景：你作为技术负责人，想在团队内推广“AI辅助+人工审查”的混合模式，但组里有两位老同事坚持“AI不懂业务，纯手工最靠谱”。

我的做法：不辩论，改做对比实验。

具体操作：找一个中等复杂度的新增功能需求，分成两路并行，一路完全手工划分，一路AI初稿+人工审查（就是你做审查的那个人）。记录两组的时间投入、方案质量（用6.3节的审查清单打分）、以及最终的交付稳定性。然后把数据摆出来。

在我带过的一个团队里，做完这个实验后，结果是：AI辅助组的耗时是纯手工组的47%，但方案质量得分反而高了12%（因为AI发现了几处老员工遗漏的边界耦合）。 数据出来之后，原本最抗拒的那位同事主动来找我聊“AI审查清单怎么用”，理性比说教管用一百倍。

7.4 项目实在太老了，依赖复杂度爆表，还要用Claude Code吗？

典型场景：一个2008年开始维护至今的企业内管系统，PHP 5.3时代一路升级到PHP 7.4，全局变量满天飞，没有任何测试覆盖，原始开发团队全部离职，代码注释里写的联系人已经离职8年了。

我的建议：用，但别让它碰模块划分。

Claude Code在这种项目里的真正价值不是做架构设计，而是：

1. 帮你理解那些没人能解释的代码：把一段没人敢动的老代码喂给它，它能猜出这段代码的业务意图，虽然不是100%准确，但比你自己硬读快得多
2. 生成重构的安全性分析：让你在一个受限范围内尝试拆分，它可以模拟拆分后的引用关系变化，提前预警哪些地方会断掉
3. 充当“活文档”：让它为关键的几个核心模块生成最新的架构说明和依赖文档，虽然这些文档不会完美，但比没有强一万倍

在这个场景下，把Claude Code当成一个会说话的反编译工具和文档生成器来用，别指望它当架构师。

八、争议的未来：当AI真的越来越懂耦合

写了这么多方法论和实操案例，最后我想跳出来聊两句趋势判断，这不是科幻畅想，而是基于我对Claude Code近几个版本迭代轨迹的观察。

8.1 我观察到的三个趋势

趋势一：上下文窗口持续扩大，跨文件理解能力显著提升

Claude Code早期版本在面对超过200个文件的项目时，模块划分建议明显变差，因为它看不到全局。但近几个版本，能塞进上下文窗口的文件量级已经有了数量级的提升。这意味着它在理解遗留项目全局依赖方面的能力会越来越强。

但请注意：看到更多文件，不等于理解更多隐性约束。 它依然看不到部署拓扑、团队边界、非技术性限制。这个盲区短期内不会被技术突破弥补。

趋势二：“项目记忆”能力的雏形已现

Claude Code现在可以在会话中保持对项目上下文的理解，未来大概率会演化为“持久化项目记忆”，它能记住上一次帮你做模块划分时的决策、你否掉的方案、以及你给出的修改理由。这意味着它的建议会越来越“懂你项目”，从而提升C维度（AI稳定度）的得分。

趋势三：从“回答”到“提问”的能力在进化

最近的版本中，我注意到Claude Code开始在某些场景下主动反问，“这个模块似乎和另一个服务共享Redis键，我应该把它们合并吗？还是你希望保持分离？”这种质疑式交互比直接给答案有价值得多。它意味着未来AI会从一个“答录机”进化为“对话型参谋”，而后者恰恰是我们最需要的角色。

8.2 开发者的核心能力将重新定位

如果上述趋势成立，那么作为一个在遗留项目中工作的开发者，你的核心价值将不再是“会写代码”或“懂这个项目”，前者AI做得越来越好，后者会随着AI项目记忆的成熟而逐渐被补上。

未来真正不可替代的，是你的边界决策力：在多个可行方案中，基于对业务、组织、风险的综合判断，做出最合适的取舍。

这个能力，就是我整篇文章试图通过“三维评估法”帮你建立的东西。它不是一个公式，而是一种思考方式。当你用得足够多之后，你可能不需要每次都填表打分，你的大脑会自然地跑完这三个维度的评估，然后在几分钟内做出判断。

结尾：你的评估表版本是多少？

说了这么多，让我把核心观点再浓缩一下：

模块划分的争议不会消失，因为Claude Code和人类工程师天然掌握着不同维度的信息，一个看到代码结构看不到历史包袱，一个带着业务直觉却偶尔遗漏细节。正确的策略不是站队，而是搭建一个能让两者互补的决策框架。

如果你想立刻开始用这篇文章里的方法，我建议你现在做三件事：

1. 找一个你手头正在做的遗留项目，花15分钟跑一下4.1节的依赖复杂度评分，你可能会惊讶地发现，你自认为“还行”的项目得分比你预期的高不少
2. 下一次用Claude Code做模块划分之前，先填完三张评分表再做决定，强制自己走完这个流程，看看结果和你凭直觉做的判断差多少
3. 把6.3节的审查清单贴在你的显示器旁边，它只有6条，但覆盖了80%的返工原因

这篇文章里的方法和数据，来源于我在7个不同规模、不同语言的遗留项目中的实践总结。它们对我有用，但我不能保证它们对你100%适用，你的项目有自己的独特性，你的团队有自己的工作方式，你的Claude Code版本可能和我的表现不同。所以我更希望你把这篇东西当成一个“版本0.9”的草稿框架，而不是一个“最终答案”。

如果你在实践中发现了这套评估法的漏洞、或者总结出了更好的判断规则，请告诉我。我很认真地认为：在AI辅助编程这件事上，我们所有人都还处在快速迭代的学习期，没有专家，只有先跑一步的探索者。

你的评估表版本是多少？

*（全文完）*