最近看了不少用 Claude Code 处理复杂工程任务的案例，其中最让我有感触的一类，不是“几分钟写了多少代码”，而是那种真正把大模型放进大型工程流程里去用的实践。
尤其是那种迁移量级比较大的项目，比如把一套成熟的 Go 系统逐步搬到 Rust。这样的任务有一个特点：它真正难的部分，不是“把一段语法翻译过去”，而是如何在很长的周期里，让实现持续沿着正确方向推进。
这也是我现在看这类 AI 工程案例时最关心的点。
大项目迁移里，最怕的不是慢，而是失控
很多人第一次用 AI 做工程任务，最容易上头的地方是速度。
模型今天帮你写一段，明天帮你改一段，看起来进展非常快。但只要项目一复杂，很快就会发现，真正的问题不是“写不写得出来”，而是：
- 改动是否还在同一套架构意图里
- 新代码有没有延续原系统的边界
- 后面的实现是不是会推翻前面的判断
- 团队里的人还能不能理解这套过程
对大型迁移来说，最危险的状态不是产出慢，而是每一步都像对的，但合起来逐渐失控。
所以我现在越来越觉得，AI 在复杂项目里的价值，不是代替工程，而是放大工程纪律。
我越来越认同“Agent Team”而不是“万能 Agent”
如果只让一个 Agent 从头包到尾，理论上也能做事，但一旦任务拉长，它就会自然滑向一个问题：角色混杂。
既要想架构，又要做实现，还要补测试、修边角、看优先级，最后结果通常是每一部分都做了，但没有任何一部分真正做深。
相比之下，我更认同把工作拆成不同角色：
- 有的角色负责路线和优先级
- 有的角色负责架构判断
- 有的角色专注实现和测试
- 有的角色负责验证和回归
这不只是为了“更像团队”，而是因为复杂任务天然就需要不同粒度的思考。
大模型最容易犯的一个错误，是在局部实现里偷偷改变全局约束。把角色拆开，本质上是在降低这种风险。
文档不是给人看的装饰，而是给 Agent 用的护栏
这类案例里还有一个我特别认同的点：文档密度。
以前很多项目文档写得很大而空，给人的感觉更像档案，而不是工作工具。放到 AI 场景里，这种文档几乎没什么帮助，因为它不能形成有效约束。
我现在更相信一种更实用的写法：只写那些代码里推不出来、但又真的会影响实现的东西。
比如：
- 哪些模块边界不能碰
- 哪些兼容约束必须保留
- 哪些实现路径虽然可行但不允许采用
- 哪些测试标准是“必须过”，不是“最好有”
这种文档不一定长，但信息密度要高。
对 Agent 来说，文档不是背景材料，而是运行边界。边界清楚了，模型输出才更稳定；边界模糊，后面就一定会返工。
真正的杠杆不在“提示词多华丽”，而在“过程是否可复用”
现在很多关于 AI Coding 的讨论还停留在 prompt 技巧层面，比如怎么写更细、怎么喂更多上下文、怎么一句话让模型更聪明。
这些当然有用，但在复杂迁移里，我觉得真正的杠杆不在这里。
更关键的是：
- 这套流程能不能重复执行
- 新加入的人能不能接上
- 某个阶段出问题时，能不能快速定位责任和上下文
- 当前这一步的决策，三周后还能不能解释清楚
也就是说，最重要的不是“这次写出来了”，而是“这次的做法能不能沉淀成系统”。
这也是为什么我会越来越重视 ADR、迁移计划、任务拆解、测试标准这些看起来没有那么“AI”的东西。因为最后决定项目成败的，常常还是这些最传统的工程要素。
我现在对 AI 工程化的一个基本看法
如果任务很小，AI 的优势就是快。
但如果任务足够大，AI 的优势其实是另外一件事：它可以在严格约束下，持续承担那些原本会消耗大量心力的执行工作。
前提是，你得先把约束搭好。
所以对我来说，用 Claude Code 做大项目迁移，真正该关注的不是“模型到底有多强”，而是：
- 有没有明确分工
- 有没有高信息密度的文档
- 有没有可追溯的决策记录
- 有没有能兜底的测试和验收标准
模型会越来越强，但复杂工程这件事，最后依然不会变成“谁 prompt 写得好谁就赢”。
真正拉开差距的，还是谁更会把 AI 放进一套稳定、清楚、可复用的工程系统里。