Claude Code参与前端样式框架迁移时的设计系统适配成本

去年秋天，我们团队接手了一个中型SaaS产品的技术债清理项目。这个产品四年前用Ant Design 3.x搭建，后来陆续混入了部分自定义组件，设计团队又在两年前出了一套完整的设计规范。CIO给的deadline是三个月，目标是把前端样式框架彻底迁移到基于Tailwind CSS的自建组件库，而且要保证业务不中断。

项目启动第一周，我让一个资深前端估算工作量。他在白板上画了两天，给出的数字是：纯人工迁移需要11人月。我说试试Claude Code。然后我们花了三天搭建迁移流水线，两周跑完了第一版。看起来一切顺利。

但验收那天出事了。

产品经理拉我们看新版本，指着Dashboard页面问：“为什么所有的警告提示都变成了灰色？为什么表格的行高比原来大了4px？为什么这个按钮hover的时候文字会闪烁？”

所有这些问题都指向同一个源头：设计系统的适配成本没有因为我们用了AI就消失，它只是换了一种方式被支付了。

核心结论：你不只是在为代码付费

在正式展开之前，我想先把核心结论摆出来。这篇文章要讨论的不是“Claude Code能不能做样式迁移”，它可以，这没有悬念。真正的问题是：当你让Claude Code参与前端样式框架迁移时，有一笔“设计系统适配税”是你无论如何都要付的，区别只在于你选择在哪个环节支付。

这笔“税”大致由四个部分构成：

1. Token系统的语义税：约占总适配成本的35%-45%
2. 组件状态的上下文税：约占20%-30%
3. 全局样式的幽灵税：约占15%-25%
4. 回归测试的验证税：约占10%-20%

这组数据来自我参与的三个实际项目（一个SaaS产品、一个内部工具、一个客户交付项目的迁移模块），样本量有限但方向明确。其中Token语义税几乎占了一半，但绝大多数团队在估算迁移成本时根本不会单独把它列出来。

这就是我要说的核心观点：Claude Code可以大幅降低“执行成本”，也就是敲代码的时间和精力，但它几乎无法降低“认知成本”，即理解、映射、验证设计系统之间语义差异所需的心智投入。 而且，如果你错误地将认知成本也寄望于AI来承担，你后期花在修复和返工上的钱，可能比你省下的更多。

为什么这么多人低估了这笔成本

在做这个项目之前，我也看过不少讲“用AI辅助前端迁移”的技术文章。这些文章有一个共同的特点：它们展示的迁移场景太干净了。

一张典型的截图是这样的，左边是Ant Design的Button源码，右边是“改用Tailwind后”的等价实现，中间是Claude Code生成的一次性转换脚本。底下配文：“10分钟完成Button组件迁移。”

这种展示方式本身没什么问题，问题在于它只展示了迁移中最简单的10%。一个真实的样式框架迁移项目，Button组件只是冰山露出水面的那个尖。水面以下的部分包括：

全局颜色Token不是@primary-color: #1890ff这一个变量，而是一个由几十个衍生色（@primary-1到@primary-10，hover态、active态、disabled态）构成的完整色板

间距系统不是几个margin和padding值，而是一套基于4px或8px基线的空间关系逻辑

组件之间的样式不是独立存在的，一个Card组件可能依赖了全局的box-shadow变量、Typography的行高基准、甚至Layout的min-height设定

当我让Claude Code处理这些场景时，问题就开始暴露了。

第一项税：Token系统的“语义税”

什么是Token语义税

先解释一个概念。Token语义税指的是：在样式框架迁移中，将源框架的设计Token（变量、常量、命名值）正确映射到目标框架时，由于两套系统的命名逻辑、层级结构、取值粒度不一致，而产生的理解成本和修正成本。

举个例子。在Ant Design里，有一个Token叫@font-size-base: 14px。在另一个设计系统里，对应的Token可能叫$text-size-body-md: 0.875rem。从表面上看，都是“基础正文字号”，直接映射似乎没问题。

但问题在于，Ant Design的@font-size-base不仅控制正文，还间接影响了一堆派生值：

@font-size-lg: @font-size-base + 2px; // 16px

@font-size-sm: @font-size-base – 2px; // 12px

@heading-1-size: @font-size-base * 2.5; // 35px

而目标系统的$text-size-body-md可能只是一个孤立的声明，不参与任何派生计算。不同的组件通过直接引用不同的独立Token来获取字号：

$text-size-body-md: 0.875rem; // 正文

$text-size-body-lg: 1rem; // 大号正文

$text-size-heading-xl: 2.188rem; // 大标题

这时如果你简单地让Claude Code做“Token的一对一替换”，你会得到什么？

你会得到一堆看起来能跑、实际上比率全错的页面。

我在实际项目中遇到的Token语义问题

在我们的SaaS迁移项目中，源框架使用了超过200个设计Token，目标框架约有180个。表面上看是一个“多对少”的映射，但实际上，有47个源Token找不到直接的语义对应，因为它们控制的是源框架特有的行为逻辑。

比如Ant Design有一个@btn-padding-horizontal-lg: @padding-md – 1px，这个“减1px”的逻辑在目标系统中根本不存在，因为目标系统的Button padding是基于px-4 py-2这样的原子类累加，而不是CSS变量计算。

Claude Code在第一次迁移中是怎么处理这个的呢？它生成了一个新的CSS变量，把“减1px”的逻辑原封不动搬了过来，完全没意识到这在新框架中是多余的，且会导致和其他原子类产生非预期的层叠效果。

这件事的教训是：Token迁移不是字符串替换，而是语义重新编码。 Claude Code默认做的是前者，而你如果想要它做到后者，必须额外投入大量的Prompt工程成本来构建上下文。

如何量化Token语义税

在我们项目中，Token语义税的直接体现大约是每个Token平均需要15-30分钟的人工审查时间。对于200个Token的规模，这意味着至少50-100小时的纯审查时间（不是AI生成时间，而是人看AI生成结果并判断对错的时间）。

这是Claude Code帮你省不了的成本，因为AI不会主动告诉你“这个Token映射在语义上是错的”，它只会告诉你“这个Token映射在语法上是通的”。

第二项税：组件状态的“上下文税”

状态的组合爆炸

如果说Token迁移的主要挑战是“语义不对齐”，那组件迁移的真正难点在于状态管理的复杂性。

一个看似简单的Button组件，在实际产品中承载的状态远远超出你的直觉判断。以我们项目中的主操作按钮为例，它在系统中实际承载了以下状态：

状态维度

取值举例

数量

交互态

default / hover / active / focus / disabled

5

语义态

default / primary / danger / success / warning

5

大小态

sm / md / lg

3

加载态

idle / loading

2

轮廓态

solid / outline / text

3

图标态

icon-only / icon-left / icon-right / no-icon

4

仅仅一个Button，就涉及 5 × 5 × 3 × 2 × 3 × 4 = 1800种 可能的样式组合。

实际业务中不是每一种组合都会出现，但一个中型SaaS产品中，一个Button组件至少覆盖60-100种实际被使用的状态组合。Claude Code在面对这种组合爆炸时，典型的失败模式是：漏掉低频组合，或者在不同的状态之间混淆逻辑。

我们踩过的具体坑

迁移项目中最耗费修复时间的一个Bug出现在Dropdown组件的disabled状态上。

源框架（Ant Design）的Dropdown在disabled状态下，不仅改变了视觉样式（灰色文本、降低不透明度），还禁用了所有子元素的pointer事件。目标框架的自定义Dropdown组件只做了视觉处理，没有禁用pointer事件。

Claude Code在迁移时，正确地生成了视觉样式代码，但完全忽略了pointer-events的处理，因为它在分析源代码时，这部分逻辑是散布在JS事件处理层而非CSS层的，而Claude Code当时处理的是“纯样式迁移”的Prompt。

结果上线后，用户在某个流程页面点击“看起来是禁用状态的下拉菜单”，竟然弹出了下拉选项列表。这是个P1级别的Bug，修复只花了5分钟，但定位这个Bug花了将近2小时，因为从视觉上看一切正常，没有开发人员第一时间怀疑是pointer-events的问题。

这就是上下文税的典型特征：AI生成了“看起来对”的代码，但在你真正使用时，才会发现行为逻辑的断层。

什么时候上下文税最高

根据我的经验，上下文税最高的场景有三个特征：

1. 组件之间存在隐式依赖：比如Table组件依赖Pagination组件的间距变量，而这个依赖在源码中是通过@table-padding-vertical这样一个间接变量传递的
2. 业务逻辑和样式逻辑混合：比如一个“根据用户权限动态改变按钮颜色”的功能，颜色逻辑写在JSX的style属性里而不是CSS文件里
3. 第三方库的样式覆盖：比如你的项目中用::ng-deep（Angular）或:global()（CSS Modules）覆盖了某个第三方组件库的内部样式，这段覆盖逻辑在Claude Code的理解范围之外

第三项税：全局样式的“幽灵税”

最难追踪的成本

如果用一句话总结“幽灵税”，那就是：Claude Code生成的迁移代码，在新框架的全局样式层中产生的、非预期的、难以追踪的副作用。

我把这项成本叫“幽灵税”，因为它有一个非常烦人的特征：你不知道它在哪里，直到它突然出现。

在我们的迁移项目中，最典型的幽灵税事件是这样的：

迁移完成后的第三天，测试团队提了一个Bug：“用户设置页的modal弹窗，z-index异常，被全局header遮挡。”

开发人员第一反应是去检查那个Modal组件的z-index值。一切正常，设置的是z-50。又去检查Header组件，Header设置的是z-40。理论上50 > 40，不应该被遮挡。

排查了将近一小时后才发现问题所在：Claude Code在迁移一个完全无关的全局样式文件时，为了“保持兼容性”，加了一行position: relative; z-index: auto;到一个全局容器类上。这行代码在新的层叠上下文中创建了一个新的 stacking context，导致整个弹窗的z-index在渲染时被重新计算，最终显示在Header下方。

这行代码在语法上没有任何错误，在逻辑上也没有任何错误，它只是在错误的全局位置上被添加了。

幽灵税的三种典型形态

第一种：隐式层叠上下文变更。就像上面的例子，Claude Code在迁移过程中可能引入新的position或transform声明，改变了元素的层叠上下文结构，导致整个页面的z-index行为异常。这类问题极难在代码审查中被发现，因为审查者通常关注“代码写对没”，而不是“这个position是不是不应该在这里”。

第二种：全局样式污染。源框架可能有一个全局的“normalize.css”或“reset.css”，目标框架也有自己的版本。Claude Code在迁移时，有时会生成一个“混合版本”，既保留了源框架的部分reset规则，又引入了目标框架的规则。结果是，某些元素的默认样式既不是源框架的样子，也不是目标框架的样子，而是一个奇怪的中间态。

第三种：CSS特异度（Specificity）冲突。不同框架的CSS选择器策略不同。Ant Design大量使用类选择器+低特异度，而Tailwind是原子类+中特异度。Claude Code在转换时，可能会生成一些特异度计算异常的选择器组合，导致某些样式规则被意外覆盖或无法生效。

如何减少幽灵税

说实话，幽灵税是很难完全避免的，因为它的本质是“你无法预测一个复杂系统中的所有副作用”。但我总结了几条在实践中有效的降低策略：

1. 增量迁移，每次只迁移一个样式域：不要一次性迁移所有CSS文件，而是按“基础变量 → 布局 → 组件 → 页面”的顺序分步迁移，每一步都做完整的视觉回归
2. 给Claude Code设定明确的“禁止生成”规则：在Prompt中明确列出“不要修改全局layout容器”、“不要新增position声明”、“保持原有z-index体系不变”等约束
3. 在迁移阶段锁定非目标文件：如果你在迁移Button组件，应该确保Claude Code只能看到Button相关的文件，避免它“顺手”修改了无关的全局样式

第四项税：回归测试的“验证税”

自动化迁移带来的验证悖论

有一件事很多人不愿意明说：AI辅助迁移越快，验证成本反而可能越高。

逻辑是这样的：当一个人手工迁移一个组件时，他会自然地理解这个组件在业务中的使用场景，从而在迁移完成时已经完成了70%的验证工作（因为他在写代码的过程中就在脑内模拟各种状态）。

但当Claude Code在几分钟内生成了几十个组件的迁移代码时，你面对的是大量的“一次性产出物”，你对这些代码的理解深度远远低于手写时的水平。这意味着你需要投入更多的独立验证时间来弥补理解上的缺失。

在我们项目中，实际的人时分布是这样的：

编码生成：Claude Code API调用 + Prompt调试 ≈ 18小时

视觉回归测试：截图对比 + 人工逐页走查 ≈ 42小时

交互行为测试：逐组件状态验证 ≈ 28小时

集成问题修复：处理幽灵税 + 上下文税bug ≈ 24小时

总人时：约112小时。作为对比，纯人工迁移的估算人时是880小时（11人月 × 80小时/人月）。Claude Code确实省了大量时间，但省下的主要是编码时间，验证时间几乎没有减少，甚至因为代码生成速度过快而出现了“验证债务堆积”的效应。

验证税的核心来源

验证税之所以高，有三个具体原因：

第一个原因是AI生成代码的“正确性错觉”。当一个人类开发者手写一段样式代码时，如果他写错了，通常会有明显的语法报错或页面崩溃。但Claude Code生成的代码几乎没有语法错误，它的问题都藏在语义层，比如“hover态颜色是#1890ff而不是#1a8cff”。这种级别的偏差在视觉回归中需要非常仔细的对比才能发现。

第二个原因是“验证范围膨胀”。当你知道代码是AI生成的，你会自然地不信任它，这导致你检查的范围比审查人类代码时更大。审查人类代码时你可能会跳过“显然没问题”的部分，但审查AI代码时你会检查一切，因为你知道AI可能在“显然没问题”的地方犯一个“人类不会犯的低级错误”。

第三个原因是组件间的级联依赖。当你修改了Button组件的样式，你需要验证所有使用了Button的页面。当Claude Code同时修改了Button、Input、Card、Modal的样式，你的验证范围就变成了所有这四个组件的笛卡尔积组合。这是一个无法线性叠加的验证成本增长。

Claude Code到底省了什么？又付出了什么？

看到这里，你可能会产生一个误解，觉得我在否定AI辅助迁移的价值。完全不是。 我只是在纠正一种过于乐观的预期。

让我们用一个清晰的对比表格来说明Claude Code改变了什么、没有改变什么：

成本类型

纯人工迁移

Claude Code辅助迁移

变化方向

编码时间

高（约占65%）

低（约占20%）

✅ 大幅降低

Token语义理解

人工完成，伴随编码过程

AI完成基础映射，人工修正

⚠️ 成本转移（从编码阶段转移到审查阶段）

组件状态覆盖

人工逐状态实现

AI生成大部分，人工补漏

⚠️ 部分降低

全局样式副作用

存在但可控（人知道自己改了什么）

存在但不可控（人不知道AI改了哪里）

❌ 风险上升

验证成本

占35%，伴随编码过程分散

占80%，集中在编码完成后

❌ 成本转移且集中化

知识沉淀

开发者深度理解新框架

开发者可能只理解了迁移过程，未理解新框架

❌ 隐性损失

这张表告诉我们一个关键洞察：Claude Code大幅降低了迁移的“执行门槛”，但并没有降低迁移的“质量门槛”。 而且它创造了一种新的成本类型，我称之为“AI产出审查成本”，这是在传统工作流中不存在的一笔开销。

迁移策略：如何优化你的“适配税”结构

基于上述分析，我摸索出一套适合Claude Code参与样式迁移的策略框架。这不是“最佳实践”（因为样本还不够大），但确实是我在三个项目中反复调整后的经验总结。

策略一：不要迁移代码，要迁移“设计决策”

这是我踩过最大的坑之后得出的最重要的一条原则。

第一次尝试时，我的Prompt是：“请将@/components/Button/styles.less从Ant Design样式迁移为Tailwind CSS样式。”

Claude Code很忠诚地执行了，生成了一个用Tailwind类名重写的等价组件，但它在底层做的是“找到最接近的Tailwind类名来匹配Ant Design的视觉输出”。

结果是什么呢？比如Ant Design的Button有一个微妙的box-shadow: 0 2px 0 rgba(0, 0, 0, 0.015)效果，Claude Code找到了Tailwind的shadow-sm来替代。语义上能跑，但shadow-sm的实际渲染值是0 1px 2px 0 rgb(0 0 0 / 0.05)，阴影方向、扩散半径、透明度全都不一样。

正确的做法是：先让AI理解设计意图，再让它生成代码。

改进后的Prompt分层策略是：

第一层：Token映射层

“分析源框架tokens.less中的所有设计变量，理解每个变量的语义角色（基础色、派生色、间距基准、字号层级等），然后为目标框架tokens.css生成语义等价的变量映射表。对于找不到直接对应关系的变量，标注出来并给出三种可能的替代方案。”

第二层：组件约束层

“在迁移Button组件之前，请先列出这个组件在源框架中的所有样式依赖（依赖了哪些Token、哪些mixin、哪些全局类）。然后在目标框架中确认这些依赖是否已全部就绪。未就绪的依赖先不要迁移组件，先补全依赖。”

第三层：生成层

“现在基于前两层的分析结果，生成目标框架下的Button组件代码。要求：不引入新的CSS变量、不覆盖全局层叠上下文、确保所有交互状态有明确的样式定义。”

按照这个策略执行后，我们的Token语义正确率从第一次的约60%提升到了约85%。虽然Prompt设计时间增加了约40%，但后期的修复时间减少了约60%。

策略二：建立“AI可读的迁移规则文件”

这个做法是我在第二个项目中摸索出来的，效果远超预期。

核心思路是：给Claude Code写一份它自己能理解的迁移规范文档，而不是指望它从你的Prompt片语中推断出完整的迁移逻辑。

这份规范文档（我们内部叫migration-rules.md）包含以下内容：

迁移规则 v2.1

禁止行为

• 禁止在任何全局容器上新增 position 声明
• 禁止修改现有的 z-index 体系
• 禁止引入源框架的 normalize.css 规则
• 禁止使用 !important（除非是覆盖第三方库）

Token映射表

组件状态检查清单

每个交互组件迁移后必须确认：

• [ ] 所有交互态有样式定义（hover/focus/active/disabled）
• [ ] loading态有视觉降级处理
• [ ] 图标定位逻辑在迁移后保持一致
• [ ] 无新增的pointer-events阻断

有了这份文件后，Claude Code的迁移质量有了质的飞跃。因为它在生成代码时有了一个明确的“边界”和“参照系”，而不是纯粹靠模式匹配来猜测。

更重要的是，这份文件本身是可迭代的。每发现一个新的迁移问题，我们就更新migration-rules.md，然后重新跑迁移，形成一个正向的反馈循环。

策略三：分阶段迁移，每阶段独立验证

这一点可能听起来老生常谈，但我想强调的是分阶段的粒度。

很多人理解的“分阶段”是：第一周迁基础组件，第二周迁业务组件，第三周迁页面。这个粒度太粗了。

我们的做法是把迁移拆成了七个阶段，每个阶段的产出物独立可验证，验证通过后才进入下一阶段：

这个分阶段策略的好处是：把验证成本分散到了整个迁移周期，而不是堆在最后。 如果我们在最后阶段才发现Token映射有问题，那前面的所有组件迁移都要推倒重来，这种返工成本是灾难性的。

策略四：接受“适配税”，但把它变成知识资产

最后一条策略可能有点反直觉：不要试图把适配税降到零，而是想办法让这笔税变成可以复用的资产。

什么意思呢？

在我们的迁移项目中，最终积累下来的migration-rules.md、Token映射表、状态检查清单、以及迁移过程中的所有Claude Code对话记录，本身就是一笔巨大的知识资产。下一次再做类似迁移时，这些资料可以让我们把适配税降低30%-50%。

这就引出了一个长期视角：

• 第一次迁移：适配税大约是纯人工迁移成本的25%-35%（我们项目约28%）
• 第二次迁移：如果有可复用的迁移规则库，适配税可能降到15%-20%
• 第三次及以后：适配税可能稳定在10%-15%

适配税不会消失，但它可以被“摊销”。

九、什么情况下不适合让Claude Code参与迁移

在给出正面建议的同时，我还想明确地指出几种不适合让Claude Code深度参与样式迁移的场景。这些判断来自我自己的教训和同行的交流，不是说AI不能用，而是说投入产出比可能不高。

场景一：设计Token数量少于30个的小型项目

如果项目本身的设计Token数量很少（比如一个简单的官网或者工具型页面），那迁移的复杂度主要集中在“组件重写”而不是“Token映射”上。这种情况下，手工迁移可能比调试Claude Code的Prompt更快。

我在一个只有18个Token的小项目中试过Claude Code，最后发现Prompt调试花了2小时，人工审查花了3小时，而纯手工迁移这个项目大概只需要5小时。AI辅助反而增加了流程复杂度。

场景二：源框架和目标框架的设计范式差异过大

如果是从Bootstrap 4迁移到Tailwind CSS，Claude Code的表现还不错，因为两者都是“类名驱动”的框架，映射逻辑相对直观。

但如果是从一个高度封装的组件库（比如Ant Design Pro的整套布局方案）迁移到一个完全自定义的设计系统，迁移的难度主要不在于“代码怎么写”，而在于“设计决策怎么定”。这种情况下Claude Code能做的其实很有限，因为它无法替你做设计决策，比如“旧系统的侧边栏宽度是256px，新设计规范里没有侧边栏这个概念，这个256px应该怎么处理”。

场景三：业务处于快速迭代期

这是最容易被忽视的一种情况。如果产品正在快速迭代，每周都有新页面和新组件上线，那么迁移项目天然处在“追赶状态”，你迁移的速度赶不上新增的速度。

在这种场景下使用Claude Code迁移，你会发现一个尴尬的局面：你刚刚验证完上周的迁移结果，这周又新上了5个组件需要纳入迁移范围。 验证成本被无限拉长，因为“完成态”永远达不到。

我的建议是：先冻结业务迭代，或者至少把迁移范围锁定在一个稳定的功能模块上，然后再引入Claude Code。 不要一边跑一边换轮子。

场景四：团队AI协作经验不足

如果你的团队之前没有使用过Claude Code或类似AI编码工具，那我不建议直接把“样式框架迁移”作为第一个AI协作项目。

迁移项目天然具有高耦合、强依赖、难回滚的特征。如果团队对AI工具的边界和失效模式没有体感，很容易出现“过于信任AI产出”或“完全不信任AI产出”两种极端，前者导致隐性Bug大量上线，后者导致AI辅助失去意义。

先用低风险的小模块练手，建立团队和AI的协作默契，再投入迁移项目。 这是血的教训。

十、更长期的视角：设计系统迁移的未来形态

写到这里，我想跳出“当前如何用Claude Code做迁移”的框架，聊聊我对这件事未来走向的判断。

趋势一：从“迁移工具”到“设计系统编译器”

目前Claude Code在迁移中的角色还是一个“高级代码翻译器”，它把框架A的代码翻译成框架B的代码。这是一种“语法层”的迁移。

但我认为，未来2-3年内会出现“语义层”的迁移工具。这类工具不只是翻译代码，而是理解设计系统的抽象语义，然后根据目标框架的设计范式重新生成代码。

举个例子，当前Claude Code看到这段代码：

.btn { padding: 8px 16px; border-radius: 4px; }

它会把它翻译成：

<button class="px-4 py-2 rounded">

这是语法层翻译。未来的工具可能会理解：“这个按钮的圆角是4px，但在目标设计系统中，圆角只有0, 2, 4, 8, 16五档，而4px恰好是‘小圆角’的语义。因此应该映射为rounded-sm而不是rounded。”

这种语义理解能力，目前需要大量人工Prompt来补足，但模型能力的提升最终可能让它变得自动化。

趋势二：适配税从“一次性支出”变为“持续性订阅”

随着设计系统的Token化程度越来越高，未来的前端项目可能会同时维护多套“样式方言”，同一套组件，根据不同的主题或品牌需要，切换不同的Token值集。

在这种场景下，“迁移”不再是偶发事件，而是持续性的维护动作。适配税就会从“一次性项目成本”变成“常态化的技术债务利息”。

这意味着我们需要把“AI辅助样式映射”的能力嵌入到日常开发流程中，而不是只在迁移时才拿出来用。

趋势三：验证自动化是适配税降低的真正突破点

回顾前面分析的四大适配税，最难解决的是“验证税”，因为目前验证主要依赖人工视觉审查。

如果未来出现了更成熟的可视化回归测试工具（比如基于像素级差异对比的AI视觉测试，能够自动识别“有意义的视觉变化”和“无意义的反锯齿差异”），那么验证税有望大幅下降。

我目前在一些项目中尝试使用Percy和Chromatic这类视觉回归工具配合Claude Code的产出，效果比纯人工审查好，但这些工具目前无法区分“有意的视觉变化”和“意外的视觉Bug”，仍然需要大量人工介入。

我对自己团队的建议

如果今天我的团队面临一个新的样式框架迁移需求，我会给出以下决策路径：

第一步：评估项目适配税基数

• Token数量 > 100？ → 适配税基数高，AI辅助的潜在收益大
• Token数量 < 30？ → 考虑纯手工迁移，AI辅助的ROI可能为负

第二步：评估团队AI协作能力

• 团队有AI协作经验（使用Claude Code或Copilot超过3个月）？ → 可以考虑深度AI辅助
• 团队AI使用经验不足？ → 先用低风险模块练手

第三步：评估业务环境稳定性

• 未来3个月内业务迭代速度可控？ → 适合进行迁移
• 业务在快速迭代中？ → 先冻结需求，或迁移项目延后

第四步：制定分阶段迁移计划

• 总是从Token层开始，不要跳跃
• 每个阶段独立验证，不积累验证债务
• 控制单次迁移规模，每次不超过5个组件

第五步：建立迁移知识库

• 编写AI可读的迁移规则文件
• 记录所有发现的映射问题和修复方案
• 为下一次迁移积累可复用资产

结尾：适配税是投资，不是浪费

回到这篇文章的标题，Claude Code参与前端样式框架迁移时的设计系统适配成本。

我想用一个类比来收尾。

如果你要搬家，你可以雇一辆卡车和几个搬家工人。搬家工人可以帮你把所有东西搬上车、运到新家、搬下车。这就是Claude Code做的事，它帮你搬运代码。

但是，到了新家之后，谁来把东西摆到正确的位置？谁来告诉你旧家的衣橱在新家的哪个房间？谁来决定哪些旧家具不适用新家的格局需要扔掉？

这些问题的答案都不是搬家工人能给你的。这就是设计系统适配成本的本质：它不是搬运成本，而是重新安置和重新理解的成本。

Claude Code帮我们省了搬运的时间和体力，但重新安置这件事，目前仍然需要你自己来。而且如果你试图让Claude Code替你做“重新安置”的决定，它可能会把你的书摆进厨房，把你的锅碗瓢盆塞进卧室，因为从它的视角来看，“有架子就能放”。

所以，我的最终建议是：

接受适配税的存在，但不要把它当作成本浪费。把它当作一笔投资，投资于你团队对目标设计系统的理解深度，投资于可复用的迁移知识库，投资于更成熟的AI协作工作流。

下一笔适配税，你会付得更少。但第一笔，确实要付。

如果你正在计划一个样式框架迁移项目，我建议你现在就做一件事：打开你的Token文件，数一数有多少个变量。然后把这个数字乘以15分钟。这个数字就是你至少要准备支付的“Token语义税”。 如果这个数字让你觉得不安，那说明你之前对迁移的预期可能过于乐观了。

现在调整预期，还来得及。