最近在用 Claude Code 折腾 Unity 项目移植------把一个 Unity 2017 的 Lua 老 MMORPG 功能，迁到 Unity 2022 的纯 C# 新工程里。 本来以为就是个"代码翻译"的活，真上手才发现坑太多：两个项目架构天差地别，直接扔给 AI 瞎写，要么漏了整条调用链，要么把 Lua 那套架构硬套进 C#，改 bug 的时间比自己写还长。
更关键的是，全堆在一个对话里猛塞代码，上下文很快就脏了，后面的回答质量肉眼可见地下降。索性我就搭了一套完整的自动化移植工作流，从最开始的一堆零散 Skill，迭代成了「主控 Skill + 专业 Subagent」的团队协作模式。今天把整个演进过程和底层思路分享出来，做 AI 辅助开发的朋友大概率能用上。
第一版：堆了7个独立Skill，看着清楚用着累
最开始思路很直白：把移植全流程拆成7步，每一步做一个独立 Skill 命令。 分析 Lua 用 /lua-feature-analysis，分析 C# 用 /csharp-project-analysis，找差异、写方案、写代码、验证、写教程各对应一个工具。skill如下：
/lua-feature-analysis：分析 Lua 原始功能，默认只读。
/csharp-project-analysis：分析 CSharp 目标工程，默认只读。
/migration-gap-analysis：比较两边的功能差异，默认只读。
/migration-planner：制定可审核、可迭代的详细移植计划，不写代码。
/csharp-feature-migration：仅在当前计划获批后实施代码修改。
/migration-validation：核对实际实现与批准计划，默认只读。
/migration-tutorial-writer：根据真实分析、批准方案、代码变更和验证结果生成教程，不修改项目代码。
每个 Skill 职责确实清清楚楚，但用起来就别扭了：
- 得自己记死调用顺序，一步错步步乱
- 各个工具之间完全不通气，进度全靠人工盯
- Lua 和 C# 的分析本来能并行干，顺序跑纯纯浪费时间
- 所有分析结果全堆在主对话里，上下文越跑越脏，后面答非所问的概率飙升
说白了就是一堆零散的螺丝刀扳手，没有个总负责人统筹，而且还在持续污染你的主对话上下文。
升级：加个主控Skill当"项目经理"
既然缺统筹的人，那我就加了一个统一入口：/migrate-feature 你只需要跟它说一句"把某某功能从 Lua 迁到 C#"，剩下的全流程它来安排。
它不用自己写代码、自己扒源码，就干项目经理的活： 理解需求 → 查项目资料 → 派分析任务 → 收结果 → 做差异对比 → 出移植方案 → 找人审查 → 等你批准 → 安排编码 → 验收 → 出教程
一下子就省心了，不用自己天天盯着"下一步该调用啥"。更重要的是，大量中间分析过程被封装在流程内部，主对话只保留关键决策节点，信噪比直接拉满。
再细化：4个专业Subagent，各司其职
有了项目经理，干活的人也得专业分工。我把核心专业任务拆成了4个专属 Subagent，各管一摊，只对主控负责。
这里说句掏心窝子的：很多人用 Subagent 只看到了"分工"，没看到最核心的价值------上下文隔离。
每个 Subagent 跑在独立的上下文里，Lua 分析员的窗口里只有 Lua 代码和相关知识，C# 分析员的窗口里只有 C# 工程，彼此互不干扰。好处是实打实的：
- 上下文不串味。Lua 分析过程里产生的大量中间变量、调用链细节，不会跑到 C# 分析的上下文里去，避免 AI 把两边的架构混在一起瞎发挥。每个 Agent 的注意力都高度聚焦，输出质量更稳。
- 主对话极度干净。所有脏活累活的细节都在子 Agent 里消化掉了，主控只把结论和关键证据汇总回来。你的主对话里不会塞满几百行源码片段，Token 省下来的同时，后续对话的理解精度也不会被历史垃圾信息稀释。
- Token 消耗更可控。独立上下文用完即弃，不用带着一整个工程的分析记录跑完整条流水线。尤其是大工程分析，单任务 Token 峰值降下来，整体消耗反而更划算。
四个专业角色分工如下：
- Lua项目分析员：专门扒老 Lua 源码，定位功能入口、梳理完整调用链、核对消息协议，全程只读不改，输出带证据的分析报告
- C#项目分析员：专门研究新 C# 工程架构，找现成的类、消息 Handler、实体逻辑，判断哪些功能可以复用，分析阶段只读
- 移植方案审查员：方案写完先过它的手------有没有漏逻辑？有没有乱改现有架构？修改范围清不清楚？潜在风险有没有说明白？
- 移植验证员：代码写完它来验收，检查是否按方案执行、调用链是否完整、有没有编译错误，输出验证报告
最终结构如下：
.claude/
├── agents/
│ ├── lua-feature-analyst.md
│ ├── csharp-feature-analyst.md
│ └── migration-plan-reviewer.md
├── knowledge/
│ ├── module-index.md
│ ├── lua-project-analysis.md
│ └── csharp-project-analysis.md
└── skills/
└── migrate-feature/
└── SKILL.md
完整流程长啥样？审批门禁是核心
整个工作流跑下来是这样的：
你提移植需求 → 主控接活 → 同时派 Lua 和 C# 分析员并行干活 → 收齐两份报告做差异分析 → 制定移植方案 → 审查员内审 → 提交给你终审
最关键的一条：你不批准，绝对不许动代码。 这是我专门设的门禁，防止 AI 写嗨了越改范围越大。方案里必须写清移植目标、修改文件清单、每个文件的改动目的、潜在风险和验收标准，还带版本号，你批准哪个版本就按哪个版本来，中途要改范围必须重新走审批。
两个实用细节：提效+避坑
1. 搭个知识库，省Token省时间
每次移植都从头扫整个工程，又费 Token 又慢。我在项目里建了个知识库，提前存好：
- Lua 项目的架构、核心模块、常用调用关系
- C# 项目的核心类、消息体系、已有功能清单
- Lua 和 C# 的模块对应映射表
Agent 干活先查知识库定位，再去源码里核实，不用每次从零开始扫全工程，效率提升很明显。
2. 踩过的坑：后台Agent不是发了就完事
最开始跑的时候，主控说"两个 Agent 后台并行执行中"，我就等着出结果。后来才发现： Agent 启动了 ≠ 跑完了 ≠ 主控收到结果了 所以一定要加状态检查机制：跑没跑完？有没有报错？结果有没有正常回收？失败了怎么兜底？ 不能只设计正常流程，异常处理也得跟上。功能是独立了，但舱壁隔离没有跟上。
最后总结
从一堆零散 Skill 到「主控 Skill + Subagent」，本质上不是文件夹结构变了，是工作组织方式和上下文管理思路变了：
- 入口从7个变1个，不用记一堆命令
- 执行从单打独斗变专业分工，并行干活更高效
- 上下文从一锅粥变分层隔离，每个 Agent 聚焦单一任务，主对话只留决策信息，信噪比高、Token 省
- 流程从"分析完就瞎写"变全链路可控，内审+人审双保险
说白了，用好 Claude Code 不是看你会写多少 Prompt，而是看你会不会管理上下文。把不同专业领域的内容拆到独立上下文里去，让主对话只负责流程控制和决策，这才是长时间跑复杂工程的正确姿势。 这套思路其实不止适用于 Unity 移植，很多复杂的开发任务都能这么搭工作流，感兴趣的朋友可以试试。
需要我再补一段适合发技术社群的精简版文案，或者给文章加个结尾互动引导吗？