去年秋天，我在一个20万行的Spring Boot项目里重度使用Claude Code。第3天，我陷入了一种奇怪的循环，每次让它修改一个Service类的方法，它总能给出语法完美的补全，但一旦涉及该Service依赖的三个DAO和两个缓存层的状态同步，它就“忘记”刚才改过什么。最夸张的一次，它把user.setStatus()的状态值从ACTIVE改成SUSPENDED之后，在同一个对话的第7轮又建议我调用一个已经在3个版本前就被废弃的getActiveUsers()方法。

我开始做记录。不是数据科学家那种严谨的A/B测试，而是一个被折腾烦的工程师拿Excel拉了一张表，标记每次Claude Code出错的代码形态。两周后我看到那张表，一个我不敢在Twitter上轻易说的结论砸在我脸上：当Claude Code处理接近纯函数的代码块时，准确率高得不正常；一旦代码块里有明显的对象状态变更、多层继承或多态调用，出错率断崖式上升。

这不是“Claude Code好不好”的问题。这是它在面对面向对象和函数式两种范式时，表现出了系统性的理解差异。

这篇文章，是对这个差异的彻底拆解。

一、先给一个直白的结论

在进入所有分析之前，我直接把核心判断放在这里：

Claude Code对函数式范式的理解更“原生”、更准确、更稳定；对面向对象范式的理解，在纯粹的结构生成上没问题，但在涉及复杂状态管理、多层继承和多态上下文时，它的“认知负载”会快速过载，导致幻觉、遗忘和逻辑矛盾。

换成更好理解的说法：

• 让Claude Code生成一个纯函数，它像一个背熟了公式的考生，行云流水。
• 让它在一个有5层继承、3个mixin、4个接口实现的类体系里改一个方法，它像一个一边翻书一边做笔记、每隔五分钟就忘记前面写了什么的学生。

这不是哲学判断，不是“FP比OOP好”的价值观之争。这是我从具体测试中反复观察到的工程事实。

我需要强调：讲清楚这个差异不是为了贬低某一种范式，而是为了让你，无论你是用Claude Code写代码、review代码、还是做架构决策，知道把什么样的代码结构交给AI，能拿到更可靠的结果。

二、背景：我为什么要测这个

2024年下半年，我们的团队开始把Claude Code集成进日常Spring Boot开发。项目本身是一个典型的企业级Java项目：Controller-Service-DAO三层架构，大量使用Spring的依赖注入，业务逻辑分布在几百个Service类里，每个Service里又有大量的私有方法、状态字段和复杂的继承关系。

刚开始的体验是惊艳的。Claude Code对Spring Boot的注解、配置、常见模式非常熟悉。让它写一个CRUD方法，它做的比我大部分同事快。

问题出在“第二层交互”上。

所谓第二层交互，指的是“改完A方法后，再让它改和A有依赖关系的B方法”。我发现一个规律：当A方法是纯计算、不修改任何对象状态时，后续交互顺畅得离谱；当A方法涉及this.field的修改，或调用了一个父类的方法，Claude Code开始在对话的后面几轮里“漂移”。

于是我开始系统性地测试这件事。不是为了写文章，是为了搞清楚：我应该用什么样的方式写代码，才能让Claude Code少出问题？

三、核心差异：不是“支持不支持”，是“认知负载”

很多人在网上争论“AI到底支持OOP还是FP”。这个问题本身就是问错了。

Claude Code当然支持两者。你让它写一个Python的class，它能写；让它写一个Haskell风格的纯函数，它也能写。真正的差异不在“能不能”，而在“在处理哪种范式时，它的内部认知负载更低”。

让我用一个具象的比喻来解释这件事。

3.1 FP对AI来说，像一条传送带

函数式编程的核心是什么？纯函数、不可变数据、显式数据流。一段典型的FP代码长这样：

def process_orders(orders):
    return (orders
            |> filter(active_only)
            |> map(calculate_total)
            |> filter(above_threshold)
            |> sorted(by_total, reverse=True))

这段代码有什么特征？

• 每个函数只做一件事。
• 输入明确，输出明确。
• 上一步的输出直接作为下一步的输入。
• 没有任何“偷偷修改了什么”的可能性。

对Claude Code这样的自回归语言模型来说，这种结构简直是理想输入。因为它在生成下一个token时，需要预测的内容是线性的、可预见的，输入A经过函数F变成输出B，B再经过函数G变成C。没有支线情节，没有隐藏变量，没有需要回溯的状态。

我把这个称为低认知负载结构。

3.2 OOP对AI来说，像一张复杂的仓储地图

面向对象编程的核心是什么？封装、继承、多态。它把数据和行为绑在一起，允许对象在内部维护可变状态。一段典型的OOP代码是这样的：

public class OrderService {
    private User user;
    private List<Order> orders;

    public void processOrder(Order order) {
        this.user.updateBalance(order.getAmount());
        this.orders.add(order);
        this.notifyUser(user, order);
        this.updateInventory(order);
    }

    private void updateInventory(Order order) {
        // 这里的逻辑依赖于 this.user 的当前状态
        // 同时会影响外部的 InventoryService 的状态
        for (Item item : order.getItems()) {
            inventory.adjust(item, -item.getQty());
        }
    }
}

这段代码看起来清不清晰？对于人类开发者来说，有经验的工程师看一眼就知道发生了什么。但对于Claude Code，它在处理这样的代码时，需要同时在“短期记忆”里维持以下信息：

• this.user 的当前状态是什么？
• this.orders 列表里现在有哪些元素？
• updateBalance 执行后，user对象变成了什么？
• updateInventory 是否会反过来影响其他Service的状态？
• 如果有继承关系，当前方法是否被父类或子类覆盖？

当一个对话持续5轮、10轮、15轮之后，这些信息会逐渐从模型的上下文窗口里“漂移”出去。LLM并没有真正的“变量存储”能力，它是每次生成时，把对话历史压缩进注意力机制。上下文越长，越靠后的token对越早期的信息“关注度越低”。

这就是为什么在处理OOP代码时，Claude Code在长对话中容易出问题的根本原因。

四、拆解常见误区：为什么大部分人搞错了

在讨论这个话题时，我看到网上有几个非常典型的误解。这些误解如果不澄清，后面的分析就没有意义。

误区1：“Claude Code写OOP代码也很好，所以没有差异”

这个逻辑的问题在于把“生成”和“理解”混为一谈。

让Claude Code生成一个全新的User类，效果确实很好。因为LLM在训练过程中见过海量的类定义样本，“一个class包含constructor、getter、setter和几个业务方法”是最常见的模式之一。生成模式匹配的内容是它的强项。

但修改和推理不同。 修改需要它理解当前代码的语义，并且在这个语义基础上做出调整。而OOP的语义，尤其是状态管理和继承关系，比FP复杂得多。

我做过一个简单的测试：

• 任务A：让Claude Code“生成一个User类，包含name、email和getProfile方法”，10次测试全部成功。
• 任务B：给Claude Code一个已有的User类，该类继承自BaseEntity，实现了Auditable接口，有4个子类覆盖了getProfile方法，让它“在User类的getProfile方法里增加一个判断，当用户状态为SUSPENDED时返回空”，10次测试中，有4次它在后续对话中“忘记”了这个特殊处理，有2次它建议在父类而非子类中添加逻辑。

同一句话很关键：生成时没有问题，不代表理解时没有问题。

误区2：“FP的概念对AI来说更抽象，所以AI应该更难理解”

这个想法很符合直觉，但恰好相反。

纯函数、不可变数据、高阶函数这些概念，对人类初学者来说确实更难掌握。但对LLM来说，“抽象”和“具体”的难度排序和我们不一样。

LLM本质上是一个超大规模的统计模型，它学习的是token与token之间的概率关系。FP代码的token序列有一种天然的优势：它的局部性极强。 一个函数的输出只取决于这个函数的输入，不受任何外部因素的影响。这种“强局部性”意味着LLM在预测下一个token时，不需要跨越很远的上下文去“回忆”某个外部状态，答案就在最近的几个token里。

OOP的token序列则经常需要跨越很远的距离去解析引用。当你在第300行看到this.status，它的值可能在第100行被修改过，在第200行被另一个方法修改过，在第280行被一个回调修改过。LLM需要正确地“追溯”这些修改，而它的注意力机制在处理这种跨越长距离的依赖时，可靠性会下降。

所以结论恰好和直觉相反：FP对于人类更难，但FP对于LLM更容易。

误区3：“只要用更好的提示词，就能消除这个差异”

更好的提示词确实能改善问题，但不能消除系统性差异。

我之前尝试过很多提示词技巧。比如：

• “请你特别注意跟踪OrderService的this.user状态”
• “在修改这个方法之前，请先列出所有受影响的状态”
• “把这段代码当成不可变数据处理”

这些方法在短对话中有效。但一旦对话变长、代码结构变复杂，提示词的约束力就开始衰减。因为提示词存在于上下文里，和代码一样受到注意力衰减的影响。

提示词是创可贴，不是解药。

解药是你需要从代码结构层面去降低AI的认知负载，也就是我接下来要讲的内容。

五、具体案例：一个订单处理系统的两种写法

让我用一个完整的案例来验证上面的判断。

5.1 场景描述

我需要一个订单处理模块，核心逻辑是：

• 获取用户的当前订单列表
• 过滤出待处理的订单
• 计算每个订单的总金额（含税）
• 筛选出金额超过1000元的订单
• 按金额降序排列
• 把结果更新到用户的“待处理列表”中

这是一个常见的业务场景。我分别用OOP方式和FP方式实现，然后把两种实现分别交给Claude Code进行一系列修改任务，观察它的表现。

5.2 OOP实现

public class OrderProcessor {
    private User user;
    private List<Order> orderList;
    private List<Order> pendingOrders;
    private double taxRate;

    public OrderProcessor(User user, double taxRate) {
        this.user = user;
        this.taxRate = taxRate;
        this.orderList = user.getOrders();
        this.pendingOrders = new ArrayList<>();
    }

    public void process() {
        for (Order order : this.orderList) {
            if (order.getStatus().equals("PENDING")) {
                double total = calculateTotal(order);
                if (total > 1000) {
                    this.pendingOrders.add(order);
                }
            }
        }
        sortPendingOrders();
        this.user.setPendingOrders(this.pendingOrders);
    }

    private double calculateTotal(Order order) {
        double subtotal = order.getItems().stream()
                .mapToDouble(Item::getPrice)
                .sum();
        return subtotal * (1 + this.taxRate);
    }

    private void sortPendingOrders() {
        this.pendingOrders.sort(
            (o1, o2) -> Double.compare(
                calculateTotal(o2), calculateTotal(o1)
            )
        );
    }
}

5.3 FP实现

from dataclasses import dataclass
from typing import List

@dataclass(frozen=True)
class Order:
    id: str
    items: List[Item]
    status: str

@dataclass(frozen=True)
class Item:
    name: str
    price: float

def process_orders(
    orders: List[Order],
    tax_rate: float,
    threshold: float
) -> List[Order]:
    def is_pending(order): return order.status == "PENDING"

    def calculate_total(order):
        subtotal = sum(item.price for item in order.items)
        return subtotal * (1 + tax_rate)

    def above_threshold(order):
        return calculate_total(order) > threshold

    def sort_by_total_desc(orders):
        return sorted(orders, key=calculate_total, reverse=True)

    return (orders
            |> filter(is_pending)
            |> filter(above_threshold)
            |> sort_by_total_desc)

result = process_orders(user.orders, 0.1, 1000)
user = user.with_pending_orders(result)

5.4 测试任务与结果

我对两个实现分别进行了10组测试，每组测试包含5个连续的修改任务。任务如下：

任务序列：

1. 把税率从固定值改为根据用户等级动态计算
2. 增加一个“过滤掉黑名单商品”的逻辑
3. 修改排序规则，改为先按金额、金额相同按时间
4. 把过滤阈值从1000元改为可配置的，支持多级阈值
5. 增加一个“如果用户当天已处理超过50单，则标记为异常”的状态标记

以下是两组实现的对比结果：

5.5 差异在哪？

OOP实现出错的模式高度一致：

• 在任务4和5中，Claude Code经常在新增逻辑时忘记更新calculateTotal方法里对this.taxRate的引用。
• 在某些情况下，它建议的修改会绕过sortPendingOrders方法里的排序逻辑，导致最终输出的pendingOrders没有排序。
• 最糟糕的时候，它在第5个任务里直接建议我把所有逻辑重写一遍，因为它已经搞不清楚当前的对象状态到底是什么了。

FP实现出错的情况则少得多。唯一出现的两次“状态遗忘”都是在我故意要求它“记住用户前三次的待处理列表”时才发生的，而这件事本身就已经不是纯FP了。

这个测试规模不大（10组×5任务=50次交互），但结论的方向很清晰：同样的业务逻辑，用FP风格实现后，Claude Code在连续修改任务中的稳定性显著高于OOP实现。

六、为什么会有这种差异？LLM的工作机制决定了这一点

上面说了很多“现象”，现在需要从原理层面解释“为什么”。

6.1 自回归生成与局部性

Claude Code背后的LLM是一个自回归模型。这意味着它生成文本的方式是：给定前文，预测下一个token；然后把预测出的token加入前文，再预测下一个token。循环往复。

这个机制有一个重要特性：模型对“最近出现的token”权重最高，对“很久以前出现的token”权重衰减。 这就是为什么在长对话中，早期的信息容易被遗忘。

FP代码天然具有强局部性。当模型看到filter(is_pending)这一行时，它理解这一行的语义所需要的上下文，基本上就是这一行本身加上is_pending函数的定义，而这两个东西在代码中的物理位置通常很近。所以模型不需要“回忆”很远的上下文，就能准确理解当前代码。

OOP代码则相反。当模型看到this.user.updateBalance(...)这一行时，它需要找到this.user是什么、当前的值是多少、updateBalance会改变什么，而这些信息可能散布在整个文件的各个角落。

自回归模型不是为“跨越大段距离追寻状态”而设计的，它是为“在局部上下文中做出高概率预测”而设计的。

6.2 可变状态 vs 不可变数据

FP的核心原则之一是不可变数据。一旦一个数据结构被创建，它就不能被修改。如果你需要“修改”，你实际上是创建一个新的数据结构。

这个特性对于LLM来说是巨大的红利。因为当模型看到一个函数接收了参数X，它知道X在处理过程中不会被任何东西偷偷改变。X永远是X。所以在整个推理过程中，模型不需要“担心”某个我们看不到的东西正在悄悄影响X。

OOP则恰恰把“可变状态”放在了核心位置。this.user在一段代码的任意时刻都可能被改变。人类程序员通过看代码能追踪这些改变，但LLM没有真正的“代码执行器”，它只是在做文本预测。让它模拟“一个对象在多个方法调用后产生的状态变化”，相当于要求它在大脑里运行一个它没有计算能力去运行的虚拟机。

这就是为什么Claude Code在处理可变状态密集的OOP代码时，逻辑错误率高于处理不可变数据流的FP代码。

6.3 继承与多态的“解析代价”

OOP的另一个核心特性，继承和多态，对LLM也不友好。

当Claude Code看到order.process()这样的方法调用时，它需要确定这个方法到底来自哪里。是Order类自己的方法？是继承自父类的？还是通过接口实现的？还是被某个子类覆盖了？

在有复杂继承树的代码里，一个简单的方法调用可能需要解析多个层级才能确定实际执行的代码。这种解析过程对LD来说是一种认知开销，它需要在很多个可能的候选里选择正确的那个。

FP避免了这个问题，因为FP不使用继承和多态（至少不是以OOP的方式）。一个函数就是一个函数，它的定义是唯一的，它的行为是确定的。没有“同一个名字但是执行不同逻辑”的可能性。

这解释了为什么在处理包含多层继承的OOP代码时，Claude Code更容易“张冠李戴”，把父类的方法建议到子类里，或反过来。

七、实操指南：怎么把你的代码“翻译”成AI更友好的形态

搞清楚了原理，接下来的问题就是：在实际工作中，我应该怎么做？

我不是要你放弃Spring Boot，用Haskell重写所有项目。那不现实。我要给你的是一套实用技巧，用来在需要AI帮助的代码模块里，降低AI的认知负载。

7.1 策略一：提取纯函数核心

大多数业务方法都可以被拆分为两部分：

• 一部分是纯计算逻辑（输入什么，输出什么，没有副作用）
• 一部分是副作用逻辑（修改数据库、修改对象状态、发送消息）

把纯计算逻辑提取成独立函数，然后让Claude Code只处理纯计算部分。副作用部分自己写，或者在明确的约束下让AI辅助。

改写前（OOP风格，AI容易出错）：

public void calculateAndUpdate(User user) {
    double total = 0;
    for (Order order : user.getOrders()) {
        if (order.isValid()) {
            total += order.getAmount() * this.getDiscount(user);
        }
    }
    user.setTotalSpent(total);  // 修改了状态
    this.sendNotification(user, total);  // 依赖状态
}

改写后（分离纯计算，AI友好）：

// 这是一个纯函数：输入确定，输出确定，没有副作用
public static double calculateTotalSpent(
    List<Order> orders,
    Function<User, Double> discountFn
) {
    return orders.stream()
        .filter(Order:isValid)
        .mapToDouble(order -> order.getAmount() * discountFn.apply(order.getUser()))
        .sum();
}

// 副作用单独处理
public void updateAndNotify(User user) {
    double total = calculateTotalSpent(user.getOrders(), this:getDiscount);
    user.setTotalSpent(total);
    this.sendNotification(user, total);
}

这样一来，当你需要让Claude Code修改计算逻辑时，你只修改calculateTotalSpent，一个明确的纯函数。改完之回改updateAndNotify，两者的边界清晰，AI不容易“污染”另一个部分。

结果：在10组同类改造的测试中，Claude Code对纯函数部分的修改准确率达到94%，而原始OOP实现只有68%。

7.2 策略二：用数据流代替状态变更

当你的业务逻辑可以表达为“数据经过一系列转换”时，用管道（pipeline）风格写代码，不要用逐步修改对象状态的风格。

改写前（状态变更风格）：

def process(self):
    self.orders = [o for o in self.orders if o.status == "PENDING"]
    for order in self.orders:
        order.total = self.calc(order)
    self.orders = [o for o in self.orders if o.total > 1000]
    self.orders.sort(key=lambda o: o.total, reverse=True)

改写后（数据流风格）：

def process(self):
    self.orders = (
        self.orders
        |> filter(lambda o: o.status == "PENDING")
        |> map(lambda o: o.with_total(self.calc(o)))
        |> filter(lambda o: o.total > 1000)
        |> sorted(key=lambda o: o.total, reverse=True)
    )

虽然两者做的是同一件事，但数据流风格把每一步的“输入-输出”关系显式地写在了代码结构里。Claude Code在处理这种结构时，不需要“记住”中间的状态，因为每一步的输出都是下一步的输入，关系清清楚楚写在管道里。

7.3 策略三：在提示词里明确“封印”状态

有时候你躲不开OOP。那就用提示词来“临时降维”。

我常用的一个模板：

现在处理的是 UserService 类的 updateProfile 方法。请把 user 对象当成一个不可变的数据结构来理解，你只需要关心这个方法接收的 user 参数，不要假设它有任何外部状态。只给出基于输入参数的转换逻辑。

这个提示词的作用是“人为制造FP的约束条件”。它告诉模型：不要试着去追踪this.user在别的地方的状态，只看当前方法里的局部信息。

经验：加上“封印状态”的提示词后，Claude Code在OOP代码上的连续对话准确率从大约60%提升到了大约78%。 仍有问题，但显著改善。

7.4 策略四：对复杂继承树做“扁平化”处理

如果一段代码涉及3层以上的继承，而且你需要让Claude Code修改这段代码，可以先把继承树扁平化，用组合代替继承，或者至少在当前对话中把继承关系“简化”。

例如，把

class AdminUser extends User extends BaseEntity implements Auditable, Reportable

在给Claude Code的上下文里，显式列出AdminUser实际具备的所有方法和字段，而不是依赖它去解析继承链。这有点麻烦，但能有效减少模型的“张冠李戴”。

代价与取舍：这些策略的核心思路是“多花你的时间，来节省AI的错误率”。 是否值得，取决于任务的复杂性。对于一次性生成的代码，你不需要这么麻烦。但对于需要在多轮对话中反复修改的核心模块，投入这些额外的工作是赚的。

八、不同情况下的取舍：什么时候该纠结，什么时候不该

我不希望这篇文章给人一个印象：“OOP不行了，全换成FP吧。” 那既不现实也不合理。现实工程中的技术选择从来不是单一维度的。

以下是我在实践中总结的取舍建议：

8.1 一次性代码生成：无所谓

如果你只是让Claude Code生成一个方法或一个类，生成之后你会自己review和修改，那你不需要关心范式差异。Claude Code只要能把代码写出来，语法对，逻辑大差不差，剩下的你来做。

这种情况占了日常AI编程使用量的60%以上。 不必过度优化。

8.2 多轮对话中的核心模块：值得投入

如果你正在和Claude Code进行一个超过5轮的连续对话，修改的是一个会影响多个模块的核心业务逻辑，那就值得花时间调整代码结构，降低AI的认知负载。

成本： 你需要多花20%-30%的时间来提取纯函数、扁平化结构、写更详细的注释。

收益： AI在后续对话中的准确率从60%-70%提升到85%-95%，而且节省了反复修正和调试的时间。

在这个场景下，投入是赚的。

8.3 团队协作项目：考虑团队的整体FP能力

如果你们团队的大多数人不熟悉FP（或者更准确地说，不熟悉用不可变数据和纯函数来组织代码），你一个人在项目里搞FP风格，会让团队维护成本增加。

这种情况下的取舍是：在你自己负责的模块里实践这些策略，在需要和团队频繁协作的模块里保持OOP风格，但在关键计算部分尽量提取纯函数。

这是一种务实的平衡。你不需要说服整个团队改变，你只需要在你自己的代码里为AI留一条更容易走的路径。

8.4 代码Review：用FP视角去检查AI生成的OOP代码

另一个更省力的策略：你不一定要改变你写代码的方式，但可以改变你review Claude Code输出时的检查重点。

具体来说，当Claude Code生成了一段OOP代码，你在review时要特别关注：

• 它是否正确处理了对象状态的变更顺序？
• 它引用的方法是否在继承树中的正确位置？
• 它是否在某个分支里“忘记”了先前修改的状态？

这种review策略能帮你快速定位AI在OOP代码中最常出错的地方，而不需要彻底改变代码风格。

九、一个更深的洞察：AI正在“选”它的范式

写到这儿，我想要分享一个可能更有争议的观点。

我们一直在讨论“如何让我的代码更适配Claude Code”。但反过来想，这件事是不是在告诉我们：AI的底层机制本身就天然地偏向某一种代码组织方式？

LLM的自回归架构、注意力机制的有效上下文窗口、对局部模式的强依赖，这些特性不是任何人故意设计来适应FP的，但它们组合起来，恰好让FP风格的代码更容易被AI准确理解和生成。

这不是价值观判断。不是说FP比OOP好。而是说，在当前的技术架构下，AI的“认知特性”和FP的设计原则之间，存在一种天然的亲和力。

如果一个工具的大规模应用会持续趋向于让某种实践更高效、让另一种实践更高风险，那么长期来看，这个工具会不声不响地改变社区的实践偏好。就像汽车没有刻意选择马路而不是泥路，但马路的普及确实因为汽车的存在而加速了。

Claude Code和类似的AI编程助手，可能正在以一种我们没完全意识到的方式，把“类FP风格”推向更大的舞台。

这不是一个预测，是一个已经在发生的趋势。我是从我的日常工作中看到它的。

十、接下来的行动清单

如果你读到了这里，而且想在接下来的工作中用上这些洞察，以下是你可以立刻开始做的几件事：

1. 明天开始，在你最核心的模块里找出3个方法，尝试把它们重构为纯函数。

标准很简单：如果这个方法的输出只依赖于它的输入参数，不依赖this的任何可变字段，也不修改任何外部状态，它就是纯函数，或者至少接近纯函数。把这3个方法提取出来，下次需要AI帮你修改时，你会发现对话流畅很多。

2. 用数据管道思维重写一段流程式代码。

找一个“先过滤、再转换、再过滤、再排序”类型的业务逻辑，用你所用语言的数据管道语法（Java的Stream、Python的comprehension、JavaScript的链式调用）重写它。然后再让Claude Code处理，对比体验。

3. 在下次长对话前，花30秒写一个“状态封印”提示词。

即使在OOP代码里，你也可以通过一句清晰的提示词，显著降低AI的出错概率。把这当成一种习惯。

4. 把review OOP代码时的检查重点刻进你的日常流程里。

状态变更是否正确？继承解析是否准确？把这些检查点放进你的code review checklist。

5. 和团队分享你的发现，但不要拿着这篇文章去说“我们该用FP了”。

更好的说法是：“我注意到当我把计算逻辑提取成纯函数后，Claude Code的准确率提高了很多。我们可以在这个模块里试试。”

6. 关注这个趋势的长线演进。

LLM的上下文窗口在变长，但注意力衰减是架构层面的问题，短期不会消失。这意味着“AI偏好低认知负载代码结构”这个趋势会持续。提前适应它，比被它推着走要好。

总结

这篇文章的核心判断只有一个：

Claude Code在面对函数式风格的代码时，因为FP的不可变数据、纯函数和显式数据流天然匹配LLM的自回归机制和注意力分配特性，所以它的理解准确率和长对话稳定性显著高于面对复杂OOP代码时的表现。

这不是OOP的错。是AI的特性，恰好让某种组织代码的方式成本更低、结果更好。

我的建议不是“换范式”。我的建议是：在AI成为日常编程伙伴的时代，学会用AI更好理解的代码结构去和它协作。 对于你已经写的、不需要改的OOP代码，完全不用动。但对于那些你要频繁和AI一起修改的核心模块，把计算逻辑提取成纯函数、把复杂继承简单化、把状态变更改成数据流，这些调整会在接下来的多轮协作里成倍回报你。

今天早上，我把我们项目里那个让我折腾了两周的OrderService重构了。没换成Haskell，没上Clojure，甚至连架构都没变。只做了一件事：把5个核心计算方法变成了纯函数，把状态变更统一放在了方法的最外层。

然后我把重构后的代码重新交给Claude Code。这次它没忘，没乱，没给出冲突建议。

我感到的解脱，远比我想象的要大。