用 Claude Code 将函数式代码转换为面向对象实现的案例

去年十一月份，我接手了一个旧项目。那个项目里有一个订单折扣计算模块，大概 600 多行纯函数，用了柯里化、组合、管道这些函数式范式。代码本身没问题，逻辑跑了一年多没出过 bug。问题在于，整个团队除了原作者，没人敢改。而我们恰好要对业务规则做一次大调整，原有的“满减 + 会员折扣”要扩展成“满减、会员折扣、限时抢购、新人专享”四个规则叠加，还要加上优先级排序。

当时我跟团队提了一个想法：与其在函数式基础上硬扩，不如趁这次机会，把核心逻辑转成面向对象实现，用策略模式和责任链模式把规则解耦，这样以后加规则、调优先级都不用动核心代码。但我自己对这个 600 行的函数式模块也心里没底，手动重构的话，保守估计要两到三天，还容易引入逻辑错误。

就是在这种情况下，我决定让 Claude Code 来干这件事。

这篇文章里，我会完整复盘我从失败到成功的整个过程。我不会只给你看一条 prompt 和一段漂亮的输出代码，那种“一键搞定”的文章你看得太多了。我会老实告诉你：我第一次让 Claude Code 转换时，它给出的代码是一坨包装精美的垃圾。我也会告诉你我是怎么通过三次 prompt 迭代，最终让它产出了一套可以在 PR 里直接 review 的 OOP 设计。

我的核心结论先说在前面：Claude Code 不是你的首席架构师，它是一面镜子。你给它多清晰的架构约束，它就还你多高质量的代码。把“转成 OOP”这句话扔给它，得到的一定不是你要的东西。

一、为什么这个问题值得专门写一篇

如果你在搜索引擎里输入“函数式转面向对象 AI”“Claude Code 代码重构”这类关键词，你会发现大部分文章属于两类：

第一类是“概念对比文”，洋洋洒洒讲函数式和 OOP 各自优缺点，最后给一句“可以根据场景选择”的正确废话。

第二类是“一键转换文”，贴一段 15 行的函数式代码，贴一条 prompt，再贴一段 Claude 的输出，标注“转换完成”。你照着做完之后发现，这跟你的真实场景差了十万八千里。

这两类文章都没回答开发者真正关心的问题：

• 当代码超过 500 行、涉及多个业务规则交叉时，AI 还能不能靠谱？
• 当我想要的不只是“可以跑的 OOP 代码”，而是“可维护、可扩展的 OOP 设计”时，我该怎么给 AI 下指令？
• AI 转换出的代码，我需要检查什么？那些看起来像设计模式的代码，是真的用对了还是只是长得像？

我写这篇文章，就是想把自己从“第一次失败”到“第三次成功”的完整踩坑过程交代清楚。这里面有真实的代码片段、有逐轮的 prompt 对比、有我事后总结的检查清单。读完之后你不会觉得 Claude Code 是魔法，但你会知道怎么让它成为你重构工具箱里最锋利的那把刀。

二、真实案例背景：一个让团队头疼的折扣计算引擎

2.1 原始代码长什么样

先把场景交代清楚。

我们做的是一个 B2C 电商平台，订单模块里有一个折扣计算逻辑。它的输入是一个订单对象（包含商品列表、用户信息、下单时间），输出是这个订单可以享受的最终折扣金额。

原始代码由一位已经离职的同事在 2022 年写的。这位同事是函数式编程的铁粉，代码里用了 ramda 这个函数式工具库，核心逻辑大概长这样（我做了脱敏和简化处理）：

// 原始函数式实现（简化版）
const R = require('ramda');

// 计算满减折扣

const calcFullReductionDiscount = (order) => {

const totalAmount = R.sum(R.pluck('price', order.items));

if (totalAmount >= 300) return 30;

if (totalAmount >= 200) return 15;

return 0;

};

// 计算会员折扣

const calcMemberDiscount = (user, order) => {

const totalAmount = R.sum(R.pluck('price', order.items));

if (user.memberLevel === 'gold') return totalAmount * 0.1;

if (user.memberLevel === 'silver') return totalAmount * 0.05;

return 0;

};

// 计算限时折扣（特定商品）

const calcFlashSaleDiscount = (order, currentTime) => {

// 复杂的时间判断逻辑...

return order.items

.filter(item => item.flashSaleEndTime && item.flashSaleEndTime > currentTime)

.reduce((acc, item) => acc + item.price * 0.2, 0);

};

// 折扣组合管道

const composeDiscount = R.curry((user, currentTime, order) => {

const discounts = [

calcFullReductionDiscount(order),

calcMemberDiscount(user, order),

calcFlashSaleDiscount(order, currentTime),

];

// 取最大折扣或叠加逻辑...

return Math.max(...discounts);

});

真实代码里，composeDiscount 这个函数内部还有一层管道组合逻辑，用 R.pipe 把几个计算步骤串起来。600 行代码涉及 5 种折扣规则交叉计算，还有一堆边界条件判断。

2.2 它为什么必须改

这套函数式代码有四个问题，一个比一个致命：

第一，扩展性很差。 每次加一个新规则，都要在 composeDiscount 里加一行，然后去测试会不会跟现有规则冲突。这次要加“新人专享”规则，下次可能还要加“节假日特惠”。按照这个写法，每加一次规则，核心函数就要多一行，600 行变成 800 行、1000 行，迟早失控。

第二，规则之间的关系是隐式的。 满减和会员折扣可以叠加吗？还是取最大值？这个逻辑埋在一堆 R.ifElse 和 R.max 调用里，没写注释的话根本看不出来。新人接手至少要花半天才能理清。

第三，测试困难。 因为所有规则耦合在一起，单元测试只能测整体输入输出，没法单独测“满减规则是否正确”、“会员规则是否正确”。如果一个测试用例失败了，你要花很长时间定位是哪个规则出了问题。

第四，团队没人能维护。 这是最核心的问题。团队其他 5 个后端都习惯写 OOP，对 ramda 和柯里化不熟。原作者离职后，这个模块就成了一个所有人绕道走的“黑盒”。

2.3 为什么选择转到 OOP 而不是继续函数式

有人可能会问：你们为什么不继续用函数式扩展？找个懂函数式的人接手不就行了？

现实是：招人成本远高于重构成本。 在我们这个二线城市，找一个既熟练用 ramda 又能写好函数式组合管道的后端，比找一个会策略模式的 OOP 开发者难三倍不止。而团队已有的 5 个人都熟悉 OOP，只要重构完，每个人都能维护。

另一个原因是业务特性决定的。折扣规则天然适合用策略模式（Strategy Pattern）表达，规则之间的组合关系天然适合用责任链（Chain of Responsibility）或组合模式（Composite）。这不是硬套设计模式，而是 OOP 在这个场景下确实比函数式更贴合业务语义。

三、第一次尝试：我被 Claude Code 的“机械式转换”上了一课

3.1 我写了什么 prompt

第一次尝试时，我对 Claude Code 的能力还有些过于乐观。我当时想的是：Claude 3.5 Sonnet 在代码理解能力上这么强，我把这 600 行代码直接贴进去，告诉它转成 OOP，应该能拿到一个像样的结果吧？

于是我写了一条现在看起来非常天真的 prompt：

"请将以下函数式代码重构为面向对象实现，使用 ES6 class 语法。"

就这么一句话。然后是 600 行代码粘贴在后面。

这条 prompt 的问题我当时完全没有意识到。 我只给了 Claude 一个“做什么”的指令，完全没有告诉它“怎么做”和“为什么这么做”。就像一个客户跟你说“帮我把房子重新装修一下”，但不告诉你预算、风格、家庭成员结构，你能给他装成什么样？

3.2 Claude 给了我一坨包装精美的垃圾

对话大概跑了 30 秒，Claude 给出了结果。我第一眼看过去，心里还喜了一下：代码格式很漂亮，有 class 关键字，有 constructor，有 method，看起来“很 OOP”。

但等我实际读了代码逻辑，心就凉了半截。它是这样写的（简化版）：

class DiscountCalculator {
constructor(order, user, currentTime) {

this.order = order;

this.user = user;

this.currentTime = currentTime;

}

calculate() {

const fullReduction = this.calcFullReductionDiscount();

const member = this.calcMemberDiscount();

const flashSale = this.calcFlashSaleDiscount();

return Math.max(fullReduction, member, flashSale);

}

calcFullReductionDiscount() {

const totalAmount = this.order.items.reduce((sum, item) => sum + item.price, 0);

if (totalAmount >= 300) return 30;

if (totalAmount >= 200) return 15;

return 0;

}

calcMemberDiscount() {

const totalAmount = this.order.items.reduce((sum, item) => sum + item.price, 0);

if (this.user.memberLevel === 'gold') return totalAmount * 0.1;

if (this.user.memberLevel === 'silver') return totalAmount * 0.05;

return 0;

}

calcFlashSaleDiscount() {

return this.order.items

.filter(item => item.flashSaleEndTime && item.flashSaleEndTime > this.currentTime)

.reduce((acc, item) => acc + item.price * 0.2, 0);

}

}

表面上看，它确实把函数变成了类方法。但这根本不是面向对象设计，这只是一个把函数式语法改成 class 语法的“换皮手术”。

3.3 问题出在哪

我把这版代码的问题拆开了揉碎了看，总共五个致命缺陷：

缺陷一：单一大类承担了所有职责。 所有折扣计算逻辑塞在一个 DiscountCalculator 类里，单个类 600 行变成了单个类 600 行，完全没有模块化。和原来用函数拆分的版本相比，不仅没有更好，反而更差了，原来的函数定义至少是分散在不同模块文件里的。

缺陷二：没有任何设计模式。 这是最让我失望的一点。折扣规则天然适合用策略模式，Claude 完全没做。calcFullReductionDiscount、calcMemberDiscount、calcFlashSaleDiscount 三个方法之间没有任何抽象，加一个新规则还是得在这个类里新增方法。

缺陷三：状态管理混乱。 order、user、currentTime 都挂在 this 上，但有些方法只用到其中一两个。比如 calcMemberDiscount 只用到 user 和 order，却被迫持有了 currentTime。这个类变成了一个状态大杂烩，谁用谁拿。

缺陷四：totalAmount 计算重复了两次。 calcFullReductionDiscount 和 calcMemberDiscount 里各算了一次 totalAmount。同一个计算结果没有缓存、没有提取到公共位置，纯属浪费。原来的函数式代码也有这个问题，但 Claude 在“转换”时完全没有主动优化。

缺陷五：规则之间的组合逻辑仍然是硬编码。 calculate() 方法里 Math.max(fullReduction, member, flashSale) 这一行，把“取最大折扣”这个规则组合策略写死了。如果产品经理下个月说“会员折扣和限时折扣可以叠加，但满减只取其中之一”，整个 calculate 方法就得重写。

我把这版代码称为“函数式的 OOP 马甲”。 它看起来像 OOP，跑起来也像 OOP，但骨子里还是函数式的耦合结构。如果我真的把这个 PR 合并到主分支，团队其他人打开一看，只会得出一个结论：“Claude Code 写出来的 OOP 代码也就这样嘛。”

四、问题的根源：Claude Code 没有“架构判断力”

如果你也遇到过类似的情况，AI 给出的代码看着像那么回事，但一细读就发现哪里不对，那么你肯定问过自己一个问题：到底是 AI 不行，还是我没用好？

我的答案是：两个都有。但更多是我没用好。

4.1 AI 的“理解”和你的“理解”不是一回事

Claude Code 的工作原理决定了一件事：它不是在“设计代码架构”，它是在“预测最符合你指令的 token 序列”。

当你说“把这个函数转成 class”的时候，Claude 理解的不是“将业务规则抽象为可扩展的类层级结构”，而是“将 function 关键字替换为 class 关键字，并在语法上做相应调整”。它完成了你字面上要求的事，但没完成你心里想的事。

这不是 Claude 的能力天花板问题。Claude 3.5 Sonnet 和 Claude 4 Opus 在代码理解能力上的强大是毋庸置疑的。但再强大的模型，也需要你在 prompt 里给它一个“思维框架”。你不给框架，它就用最省事的方式完成任务，这种情况下的输出，就是“换皮式重构”。

这就解释了为什么你在 X 上看到有人说“Claude Code 帮我重构了整个项目，太强了”，而另一个人说“Claude 写的代码跟实习生差不多”。差距不在模型，在 prompt 质量。

4.2 为什么“函数式转 OOP”比普通重构更难

函数式转 OOP 不是一个简单的语法迁移，它是一个编程范式的转换。这两者在设计哲学上有根本性差异：

这种跨范式的转换，Claude Code 不可能自主完成。因为它需要做的不只是“翻译”，而是重新设计代码的组织方式。就像把一本英文小说翻译成中文容易，但把一首英文诗翻译成中文古诗，需要的是完全不同的能力。

4.3 做这件事，你必须给 AI 一个“可以执行的架构约束”

我在第一次失败后重新复盘，得出了一个最重要的认识：

“转成 OOP”这句话本身不是约束，它只是一个目标描述。真正有效的约束是：“转成使用策略模式+工厂方法的 OOP”、“每个折扣规则独立为一个策略类”、“规则组合逻辑使用责任链”。

举一个类比。你让一个建筑工人“盖一栋房子”，和你给他一张建筑设计图纸“按照这张图纸盖一栋房子”，结果天差地别。第一次我相当于只说了“盖一栋房子”，然后抱怨他盖出来的楼既没有承重墙也没有水电管道。但问题是，我没告诉他要有这些东西。

Claude Code 在这件事上的角色定位应该是：它是一个执行效率极高的“高级码农”，但做不了“技术总监”的决策。架构设计必须由你来决定，然后让 Claude 去落地。

五、第二次尝试：用“命题作文”的思维引导 Claude Code

5.1 我重新设计 prompt 的方法论

在第一次失败之后，我没有直接开始第二次尝试。我花了大约四十分钟，在脑子里把这套折扣计算逻辑重新梳理了一遍，想清楚了三件事：

第一，我想用哪些设计模式？ 答案是：策略模式（Strategy）封装单个折扣规则，组合模式（Composite）处理规则之间的叠加/互斥关系，工厂方法（Factory Method）负责根据业务条件创建策略对象。

第二，每个类的职责边界是什么？

• DiscountStrategy 接口：定义一个 calculate(order, context) 方法
• FullReductionStrategy：实现满减逻辑
• MemberDiscountStrategy：实现会员逻辑
• FlashSaleStrategy：实现限时逻辑
• CompositeDiscountCalculator：负责组合多个策略、处理叠加/互斥逻辑
• DiscountStrategyFactory：根据规则配置创建策略对象列表

第三，规则之间的组合逻辑我希望怎么表达？ 我决定用一个简单的配置对象来声明规则之间的关系，而不是硬编码。比如 {type: 'max'} 表示取最大值，{type: 'sum'} 表示累加。

想清楚这三件事之后，我写了一条完全不同的 prompt。这条 prompt 的核心思想是：我不让 Claude“自由发挥”，我给它一张“建筑设计图”。

5.2 第二次的 prompt 长什么样

## 任务
请将以下使用 ramda 和函数式范式编写的订单折扣计算逻辑，重构为使用策略模式、组合模式和工厂方法的面向对象实现。

架构约束（必须严格遵守）

策略接口：定义一个 DiscountStrategy 抽象类或接口，包含 calculate(order, context) 方法和 name 属性。所有具体折扣规则必须实现这个接口。
具体策略类：

FullReductionStrategy：满减规则，阈值和减免金额通过构造函数注入（不要硬编码）

MemberDiscountStrategy：会员折扣，折扣率通过构造函数注入

FlashSaleStrategy：限时抢购折扣

要求：每个策略类只做一件事，必须可以独立进行单元测试

规则组合器：创建一个 CompositeDiscountCalculator 类，接收一个策略对象数组和一个组合策略（取最大值/累加/按优先级取第一个有效值）。组合策略也通过构造函数注入。
工厂方法：创建一个 DiscountStrategyFactory，根据配置数据（而不是 if-else）生成策略对象列表。
业务逻辑保留：所有折扣计算的具体数值、阈值、比例必须和原始代码完全一致。不允许修改任何业务逻辑。
代码质量要求：

每个类不超过 50 行

不允许任何重复的 totalAmount 计算

使用 TypeScript

所有公共方法必须有类型注解

原始代码如下

[600行函数式代码粘贴在这里]

这条 prompt 的核心变化就一个字：“细”。我把我对架构的所有设想都写进了 prompt，包括我想用哪些模式、类怎么命名、组合逻辑怎么表达、甚至每类不超过多少行。Claude 不再需要“猜”我想要什么，我直接告诉它了。

5.3 第二次转换结果的显著提升

这一次，Claude Code 给出的代码让我真正点了头。

// DiscountStrategy 接口
interface DiscountContext {

user: User;

currentTime: Date;

}

abstract class DiscountStrategy {

abstract readonly name: string;

abstract calculate(order: Order, context: DiscountContext): number;

}

// 满减策略 - 阈值和金额注入

class FullReductionStrategy extends DiscountStrategy {

readonly name = 'fullReduction';

constructor(private tiers: Array<{threshold: number; reduction: number}>) {

super();

}

calculate(order: Order, _context: DiscountContext): number {

const totalAmount = this.getTotalAmount(order);

const applicableTier = this.tiers

.filter(tier => totalAmount >= tier.threshold)

.sort((a, b) => b.threshold - a.threshold)[0];

return applicableTier ? applicableTier.reduction : 0;

}

private getTotalAmount(order: Order): number {

return order.items.reduce((sum, item) => sum + item.price, 0);

}

}

// 会员折扣策略

class MemberDiscountStrategy extends DiscountStrategy {

readonly name = 'memberDiscount';

constructor(private discountRates: Record<string, number>) {

super();

}

calculate(order: Order, context: DiscountContext): number {

const totalAmount = order.items.reduce((sum, item) => sum + item.price, 0);

const rate = this.discountRates[context.user.memberLevel] || 0;

return totalAmount * rate;

}

}

// 限时折扣策略

class FlashSaleStrategy extends DiscountStrategy {

readonly name = 'flashSale';

readonly discountRate = 0.2;

calculate(order: Order, context: DiscountContext): number {

return order.items

.filter(item => item.flashSaleEndTime && item.flashSaleEndTime > context.currentTime)

.reduce((acc, item) => acc + item.price * this.discountRate, 0);

}

}

// 组合策略类型

type CombinationRule = 'max' | 'sum' | 'firstValid';

// 组合计算器

class CompositeDiscountCalculator {

constructor(

private strategies: DiscountStrategy[],

private combinationRule: CombinationRule = 'max'

) {}

calculate(order: Order, context: DiscountContext): number {

const discounts = this.strategies.map(s => s.calculate(order, context));

switch (this.combinationRule) {

case 'max':

return Math.max(...discounts);

case 'sum':

return discounts.reduce((a, b) => a + b, 0);

case 'firstValid':

return discounts.find(d => d > 0) || 0;

default:

return 0;

}

}

}

// 工厂

class DiscountStrategyFactory {

static createFromConfig(config: DiscountConfig): DiscountStrategy[] {

const strategies: DiscountStrategy[] = [];

if (config.fullReduction?.enabled) {

strategies.push(new FullReductionStrategy(config.fullReduction.tiers));

}

if (config.memberDiscount?.enabled) {

strategies.push(new MemberDiscountStrategy(config.memberDiscount.rates));

}

if (config.flashSale?.enabled) {

strategies.push(new FlashSaleStrategy());

}

return strategies;

}

}

这一次的代码和第一次有了本质区别：

1. 真正的策略模式：每个折扣规则是独立的类，各自实现 DiscountStrategy 接口。加一个新规则不需要改任何现有代码，只需新增一个类。
2. 依赖注入：满减的阈值、会员的折扣率不再硬编码，而是通过构造函数注入。这意味着同一套策略类可以用于不同区域的规则配置。
3. 规则组合可切换：CombinationRule 类型定义了三种组合方式，切换组合策略只需要改一个参数，不用动核心逻辑。
4. 单一职责：每个类做的事情非常明确，类大小控制在 30-50 行。
5. 可独立测试：你可以单独 new 一个 FullReductionStrategy 来测试满减逻辑，不需要模拟其他规则。

当然，这一版也不是完美的。我注意到 totalAmount 的计算仍然在 FullReductionStrategy 和 MemberDiscountStrategy 中各出现了一次。这个重复在第一次失败中就存在，第二次 Claude 还是没有主动消除它。但这已经是一个可以通过手动微调快速解决的问题了。

六、第三次迭代：给 Claude Code 装上“质量监控系统”

6.1 我发现的三个残留问题

第二次的结果虽然很好，但我做代码 review 的时候，还是挑出了三个问题：

问题一：totalAmount 重复计算。 如前所述，两个策略类各自用 reduce 算了一次总金额。当订单有 200 个商品时，totalAmount 被重复计算了多次。

问题二：DiscountContext 的设计可以更好。 当前 DiscountContext 只包含 user 和 currentTime，但如果以后某个策略需要用到订单来源渠道、用户历史订单数等信息，这个接口就得改。

问题三：缺少输入验证。 策略类的构造函数接收了外部配置，但没有验证。如果有人传了 threshold: -100 这种非法值，程序不会报错，但会产生错误结果。

这三个问题不算致命，但如果不解决，代码的健壮性和性能会打折扣。我决定针对这三个点再做一次迭代。

6.2 我如何通过追加 prompt 修复这些问题

我没有重新写一条 prompt，而是在 Claude Code 的对话窗口中追加了一条指令：

## 请在上面的代码基础上做以下改进：

消除 totalAmount 重复计算：将 totalAmount 的计算提取到 CompositeDiscountCalculator 中，然后通过 DiscountContext 传递给各个策略。或者直接在 Order 类上增加一个 getTotalAmount() 方法。请选择你认为更合理的方案。
增强 DiscountContext：将 DiscountContext 设计为可以灵活扩展的结构，而非固定的 user + currentTime。可以考虑使用一个通用的 metadata 字段来承载扩展数据。
添加构造函数参数验证：为 FullReductionStrategy 和 MemberDiscountStrategy 的构造函数添加参数验证逻辑。阈值不能为负、tiers 数组不能为空、折扣率应在 0-1 之间。验证失败应抛出明确的错误信息。
保持其他所有逻辑不变。

Claude 在三秒内给出了第三版代码。这一版解决了我提出的所有问题：

• totalAmount 通过 Order.getTotalAmount() 方法集中计算，缓存在实例上
• DiscountContext 增加了一个 metadata: Record<string, unknown> 字段，允许任意策略存取自己需要的数据
• 构造函数验证逻辑以清晰的 if 语句和 throw new Error() 实现

最让我惊喜的是，Claude 在做这些修改时，没有引入任何新的 bug。 它准确地理解了我说的“保持其他所有逻辑不变”，只改了需要改的地方。

6.3 这个“增量迭代”模式比“一次到位”高效得多

复盘整个三阶段过程，我发现一个规律：不要期望第一条 prompt 出来的东西就是最终版。把转换过程看作多轮对话，每一轮解决一个层次的问题。

• 第一轮：解决“架构有没有”的问题（从无到有）
• 第二轮：解决“架构对不对”的问题（从粗糙到精准）
• 第三轮：解决“代码好不好”的问题（从能跑到优雅）

这种分层迭代的好处是：每一轮的 prompt 都很聚焦，Claude 不会因为信息过载而顾此失彼。而且你在每一轮 review 代码的过程中，也能更清楚地看到哪些地方是 Claude 的强项、哪些地方是它的短板。

七、完整的方法论：函数式转 OOP 的 Prompt 设计框架

7.1 转换前必须回答的五个问题

在写 prompt 之前，你需要先在脑子里（或纸上）回答这五个问题。如果你一个都回答不上来，就别急着打开 Claude Code。

问题 1：这段函数式代码的核心业务逻辑是什么？

答案不能是“计算折扣”这种笼统的。你得能说清楚：输入是什么、输出是什么、中间有几个独立的计算步骤、步骤之间是什么关系。

问题 2：如果拆成 OOP，哪些逻辑应该成为独立的类？

一个实用判断标准：如果某个计算逻辑在未来三个月内可能被独立修改、替换或关闭，它就应该是一个独立的类。 比如“满减规则”可能因为促销策略调整而改阈值，“会员折扣”可能因为会员体系升级而改比例。它们各自独立变化，所以应该各自成类。

问题 3：这些类之间是什么关系？继承、组合还是依赖？

这是架构决策的核心。以我的折扣引擎为例：

• FullReductionStrategy 和 MemberDiscountStrategy 之间是兄弟关系（都继承自 DiscountStrategy，但彼此独立）
• CompositeDiscountCalculator 和各个策略之间是组合关系（calculator 持有多个 strategy 对象）
• DiscountStrategyFactory 和各个策略之间是依赖关系（factory 负责创建 strategy 对象）

把关系图画出来，你的 prompt 就有了一半的内容。

问题 4：哪些值需要注入，哪些可以硬编码？

一个简单的判断：如果这个值会随环境变化（开发/测试/生产）、会随区域变化（中国区/海外区）、或会随 A/B 测试变化，它就应该是注入的。 满减的阈值和会员折扣率显然属于这一类。限时折扣的固定 20% 如果不是频繁变化，可以暂时硬编码在 FlashSaleStrategy 里。

问题 5：规则/策略之间的组合逻辑是什么样的？

是取最大值？是累加？是有一个排他性优先级（高优先级的命中了就不看低优先级的）？这个问题一定要问产品经理，或者在代码里找到明确的证据。不要自己猜。

7.2 Prompt 的四层结构模板

基于我的经验，我总结了一个 prompt 的四层结构模板。你可以直接套用：

## 第一层：任务定义（一句话说清要做什么）
请将以下使用[具体函数式库/范式]编写的[功能模块名称]重构为面向对象实现。

第二层：架构约束（这是最重要的部分）

目标设计模式

使用[模式A]解决[问题A]

使用[模式B]解决[问题B]

类与接口定义

抽象接口：[名称]，包含[方法签名]

具体类：[类名1]负责[职责]，[类名2]负责[职责]

组合/协调类：[类名]负责[职责]

数据流设计

输入如何进入系统？

中间数据如何传递（构造函数注入 / 方法参数 / Context对象）？

输出如何返回？

边界约束

每个类不超过[X]行

不修改任何业务数值

[X]逻辑必须保留原实现

第三层：代码质量要求

语言/框架要求：[TypeScript / ES6+ / 等]

类型注解：[全部公共方法 / 仅接口]

测试友好度要求：[每个策略类可独立单测]

第四层：原始代码

[粘贴原始代码]

这个模板最有价值的层是第二层“架构约束”。它直接解决了“AI 不知道你想要什么架构”的核心问题。你给的约束越具体，Claude 的输出就越接近你的预期。

7.3 不同复杂度的项目应该用不同颗粒度的 prompt

模板虽然是通用的，但不同体量的项目，prompt 的颗粒度应该有所不同：

小型模块（100 行以内，3-5 个函数）

• 迭代策略：1 轮即可
• Prompt 理念：直接告诉它“用策略模式拆解”
• 架构约束层可以简单写，因为类少、关系简单
• 示例：一个输入验证逻辑、一个简单的数据转换管道

中型模块（100-500 行，5-15 个函数）

• 迭代策略：2 轮（架构 + 打磨）
• Prompt 理念：明确指定设计模式和类职责边界
• 架构约束层需要写清楚每个类的职责
• 示例：我这次的折扣计算引擎就属于这个级别

大型模块（500-2000 行，多文件）

• 迭代策略：分模块逐个击破，不要一次性扔进去
• Prompt 理念：先转换核心领域模型，再转换外围服务
• 先把最大的逻辑块拆出来转，转了之后验证正确性，再处理下一块
• 示例：一个包含订单创建、支付、履约、售后全流程的订单系统

八、转换后的代码审查清单

Claude Code 生成的代码再漂亮，也不能跳过人工审查。但审查 AI 生成的代码和审查人类同事写的代码，关注点不太一样。我总结了一份专门针对“AI 转换代码”的审查清单。

8.1 审查的核心维度

维度一：业务逻辑正确性（最重要）

这是底线。AI 转换过程中最可能出的问题就是“看起来逻辑通了，但实际上是错的”。你需要重点关注：

• 边界条件是否保留了？比如订单金额刚好等于 300 时，满减规则应该触发吗？
• 原有的异常处理逻辑是否被“优化”掉了？函数式代码里可能有针对空数组、null 值的防御性判断，AI 可能会认为是冗余代码而删掉。
• 业务数值有没有被“智能”修改？阈值 300 有没有被莫名其妙地变成 299 或 301？

审查方法很简单：用同一组测试用例分别跑原始代码和转换后代码，对比输出。 至少需要 20 个测试用例，覆盖正常场景、边界场景和异常场景。

维度二：设计模式的正确使用

AI 喜欢用设计模式，但它有时候会“假装”用了一个模式。你需要检查：

• 策略模式的 calculate 方法签名在所有策略类中是否一致？
• 工厂方法是否真的在根据配置创建对象，还是内部写了一堆 if-else（那就不是工厂模式，只是一个 if-else 生成器）？
• 组合模式中的叶子节点和组合节点是否实现了相同的接口？

一个简单检验：你能不能用一句话说清楚每个设计模式在这个代码里的作用？ 如果说不清楚，可能 AI 只是在堆代码。

维度三：状态管理与数据流

OOP 代码的状态管理比函数式代码复杂很多。需要检查：

• 对象的状态在哪些方法中被修改了？这些修改是否是预期的？
• 有没有一个方法写了 this.xxx 但从来没有其他地方读这个值？
• 依赖注入进来的对象是否被意外修改了？（特别是引用类型的参数）

维度四：可测试性

如果你发现写单元测试很困难，需要 mock 太多东西、需要构造复杂的对象图，那说明类之间的耦合可能过重了。好的 OOP 设计应该是容易测试的。每个策略类应该可以独立 new、独立传参、独立调 calculate() 并验证返回值。

8.2 Claude Code 常见的“聪明反被聪明误”

在使用过程中，我发现 Claude Code 有几个高频的“自以为聪明”的行为，值得特别警惕：

陷阱一：擅自“优化”业务规则。 比如原始代码里有一个注释说“VIP 用户在生日月额外打 9 折”，Claude 可能会把这个逻辑“优化”掉，因为它觉得这和会员折扣规则“不统一”。永远在 prompt 里明确写一句：“保留所有业务逻辑，不得删除、修改任何条件判断”。

陷阱二：引入不必要的抽象。 Claude 有时候会过度设计。本来两个策略类就够用了，它给你抽象出四层继承关系。解决方案是在 prompt 里限定：“只使用以下设计模式：……”，不给它自由发挥的余地。

陷阱三：忽略语言惯用写法。 如果你用 TypeScript，Claude 有时会写出 Java 风格的代码，大量的 getter/setter、过度使用 private。可以在 prompt 里补充：“使用 TypeScript 惯用写法，如参数属性简写、readonly 修饰符”。

陷阱四：注释和代码不一致。 AI 生成的注释有时候和它实际写的代码对不上。比如注释说“该策略返回折扣率”，但实际返回的是折扣金额。审查时务必以代码逻辑为准，不要被注释误导。

九、性能影响：转换前后的运行时对比

9.1 我测了什么

很多人担心 OOP 版本比函数式版本慢。我在本地对这个折扣引擎做了简单的性能基准测试。

测试环境：Node.js 20 LTS，MacBook Pro M1 Pro，32GB 内存。测试用例是一个包含 50 件商品的订单，覆盖了所有折扣规则。每个版本预热 100 次后执行 10 万次取平均值。

9.2 数据怎么说

几个发现：

1. OOP 版本并没有变慢。 第三次迭代的 OOP 版本甚至比原始函数式版本快了一点点（0.38ms vs 0.42ms）。原因很简单：原始函数式版本用 ramda 的 R.pipe 和 R.curry 带来了额外的函数调用开销，而 OOP 版本的方法调用更直接。
2. 第一次转换的版本最慢。 这印证了前面的分析，把函数式逻辑硬塞进 class 里只会增加开销而没有带来任何好处。
3. 内存差异可以忽略。 2.1KB vs 2.3KB 的差异在实际应用中完全感知不到。

结论：在类似打折引擎这种偏计算密集型的场景下，OOP 和函数式之间的性能差异主要取决于具体实现，而非范式本身。设计得好的 OOP 代码不会比函数式代码慢，设计得烂的函数式代码也不会比 OOP 快。

十、什么时候不应该用 AI 做这种转换

写到这一节，我担心前面的内容会给人一种印象：AI 是万能的，什么函数式代码都该转成 OOP。不是这样的。有些场景下，强行用 AI 做范式转换是给自己找麻烦。

10.1 不适合转换的四种场景

场景一：代码逻辑极其简单（50 行以内）。

如果一个函数式模块总共就三四个纯函数、几十行代码，手动花 15 分钟就能重构成 OOP，就没必要打开 Claude Code。在这种规模下，写一条高质量的 prompt 所花的时间可能比手动重构还长。AI 的 ROI 是随规模递增的，小模块用 AI 是杀鸡用牛刀。

场景二：原始代码严重依赖函数式的特定特性。

如果你的代码重度使用了高阶类型（Functor、Monad、Applicative）或懒求值（Lazy Evaluation），强行转成 OOP 往往会丢失函数式范式本身的优势。比如一个用 Maybe Monad 优雅处理的 null 安全链，转成 OOP 之后变成一堆 if-null 判断，代码反而退化了。

这不是 AI 的问题，而是两种范式的边界决定的。Monad 天然属于函数式世界，OOP 没有等价物。如果原始代码的“好”恰恰来自于函数式的这些特性，就不要转。

场景三：团队里有人能维护现有的函数式代码。

如果你们团队有函数式编程的能力储备，原始代码结构也合理（只是你看不惯函数式语法），那我劝你不要转。重构本身有风险，没有收益的风险不值得冒。只有当维护成本已经明显高于重构成本时（如我前面说的团队完全没人懂 ramda），才值得动手。

场景四：转换后的 OOP 代码将与现有系统的 OOP 风格严重冲突。

如果你们现有的 OOP 代码使用的是贫血模型（Anemic Domain Model）+ Service 层模式，而 AI 给你生成了一个充血模型（Rich Domain Model），这个转换产物就会成为系统中的“异物”。团队其他人在维护时会困惑“为什么这个模块的写法和别处不一样”。

10.2 判断是否该转的决策框架

给你一个简单的四象限决策框架：

你的情况只有落在右下角那个象限，“团队不能维护函数式 + 业务逻辑频繁变化”，才真正有充分的理由做这个转换。

我那个折扣引擎之所以该转，恰恰因为它就落在这个象限： 团队 5 个人没人会 ramda，而且产品经理明确说了接下来每个季度都要加新的折扣规则。如果这两个条件缺一个，我可能就不会动它。

十一、总结：三个核心认知和一条行动建议

核心认知一：架构设计是你的工作，不是 AI 的工作

这是我从头到尾想传达的最重要的信息。Claude Code 不能替你决定用什么设计模式、怎么拆分职责、规则之间如何组合。 这些决策需要你的业务理解和工程判断。AI 做的是在你把骨架搭好之后，快速填上血肉。

如果你习惯了“把活全扔给 AI”，那么在这类跨范式重构成的任务上，你会反复遇到我第一轮遇到的那种情况，看起来漂亮的代码，一读就发现问题。

核心认知二：高质量的 prompt = 架构约束 + 质量约束 + 代码示例

“函数式转 OOP”这个目标本身不构成 prompt。真正的 prompt 需要包括四个层次：任务定义（做什么）、架构约束（怎么做）、质量要求（做到什么标准）、原始代码（处理什么）。第二层“架构约束”是绝大多数人忽略的部分，也是输出质量的真正分水岭。

核心认知三：不要一次到位，用分层迭代

把转换过程分成三轮：架构有没有 → 架构对不对 → 代码好不好。每一轮聚焦解决一个问题，prompt 短而精准，Claude 的输出也更可控。三轮下来，代码质量从“能跑”到“能用”再到“能维护”。

一条行动建议

如果你现在手上恰好有一个让你头疼的函数式模块，我的建议是：

1. 先别打开 Claude Code。 花半小时回答第七节提出的五个问题：核心逻辑是什么？哪些应该独立成类？类之间是什么关系？哪些值需要注入？组合逻辑是什么？
2. 把你的答案写成 prompt 的第二层“架构约束”。 哪怕第一次写得粗糙一点也没关系。
3. 贴在 Claude Code 里，看第一轮输出，然后针对性微调 prompt。

你不试一次，永远不知道“给 AI 写命题作文”和“让 AI 自由发挥”之间，差距有多大。

写这篇文章花了我三个晚上，因为我不只想给你一段代码，更想把整个思考和试错的过程讲清楚。如果你看完之后，下次让 Claude Code 做代码转换时，多花了十分钟想清楚架构再写 prompt，那这篇文章就没有白写。