从 Star-CCM+ 到 VS Code，我花了十年。
2016 年我刚开始做 CFD 的时候，每天盯的是残差曲线——那条蓝色的线在屏幕上一跳一跳，你盯着它看它是否收敛，是否振荡，是否在某个时间步突然发散。一个外流场算例跑 3000 核·时是常态。不收敛就调松弛因子、加密网格、改边界条件。然后重新跑。
2026 年 4 月，我开始学 AI。不是因为我突然对 Transformer 的 self-attention 产生了兴趣，是因为我意识到——我十年积累的对”复杂系统如何收敛”的直觉，可能正好用得上。
到今天刚好两个月。结论是：确实用得上。
不是类比，是同一件事
很多人把 CFD 和 AI Agent 做类比，说”它们很像”。我觉得这低估了这件事。
它们不是像。它们在根上是同一套底层逻辑。
你拆开来看：
CFD 求解器做的事： 给定一个物理场景（边界条件），在一个离散化的空间里（网格），反复计算（迭代），直到结果不再显著变化（收敛）。如果不收敛——调整参数，重新来过。
AI Agent 做的事： 给定一个任务目标（System Prompt），在一个拆解好的任务序列里（ReAct Loop），反复调用工具和 LLM（迭代），直到任务完成（闭环）。如果完不成——调整策略，重试。
这不是类比。这是同一个抽象模式在两个领域的具体化。
我用这个东西做了 Sulix Novel——一个 AI 辅助写作工具——的编排层核心。XState 状态机 + Rust 的 reduce(event) -> Vec<Effect> 模式，本质上就是我在 CFD 里天天写的求解循环。只不过迭代变量从流场变量变成了”用户意图”。
具体一点：三条可平移的直觉
1. 边界条件敏感——我练了十年的 Prompt Engineering
做 CFD 的人都懂一句话：边界条件决定解的存在性。
入口速度设错了，算到天荒地老也收敛不了。壁面粗糙度给错了，分离点位置就是不对。这不是”调参数”的问题——这是你在定义问题的数学空间。
做 Agent 之后我发现，System Prompt 就是 AI 的边界条件。
刚开始写 Prompt 的时候我犯了一个典型的新手错误：什么都往里塞。“你是一个写作助手。你的任务是帮助用户写小说。你要注意语气。你要注意风格。你要注意……”
CFD 直觉告诉我：约束太多，但是方向不明确，空间会过约束到无解。
于是我开始像设边界条件一样写 Prompt：
你是一个小说编辑助手。
- 只回答故事结构和角色弧线相关问题
- 语法检查仅在用户明确要求时做
- 不要替用户写段落，只提修改建议
- 每次输出不超过三个要点每一条都是一个明确的边界。就像在 CFD 里给每个边界指定 type（velocity inlet / pressure outlet / wall）一样明确。
结果？Agent 的行为从”发散”变成了”收敛”。
2. 迭代收敛直觉——我从调试 Agent 第一天就有的肌肉记忆
CFD 工程师的日常工作：跑一步，看残差，判断是否收敛，不收敛就调参数，再跑一步。
我做 Agent 的第一天，发现调试 Agent 的流程一模一样：调一次 LLM，看输出质量，判断是否完成任务，不满意就改 Prompt 或加 Tool，再试一次。
在 Sulix Novel 里，我写了个 Agent loop 的简陋原型。第一次跑，它把我的小说角色名改错了。第二次，它在对话上下文里迷路了。
CFD 直觉告诉我：不是算法的问题，是收敛判据的问题。我没有给它明确的”什么时候停”的标准。
于是我加了三样本能的收敛判据——和 CFD 残差监控一模一样：
# 这就是 CFD 残差监控换了个皮
class AgentMonitor:
def __init__(self, max_steps=15):
self.max_steps = max_steps
self.history = []
def log_step(self, step, progress, tool_ok):
self.history.append((step, progress, tool_ok))
if step > self.max_steps: # 最大迭代步数
raise Timeout("未收敛，强制终止")
if progress > 0.95: # 收敛判据
return True
return FalseCFD 的收敛判据是 residual < 1e-5，Agent 的收敛判据是 task_progress > 0.95。抽象模式一样，只是量纲换了。
3. 调试思路的平行迁移
做 CFD 调试的时候，你不会从头开始检查。你有一个诊断流程：先看残差曲线形状 → 判断是发散还是振荡 → 如果是振荡，看是哪个区域的问题 → 加密那个区域的网格。
做 Agent 调试，我用的是同一套诊断流程：
| CFD 诊断 | Agent 诊断 |
|---|---|
| 残差曲线不降 → 网格不够密 | Agent 循环不结束 → 任务拆解不够细 |
| 某个区域持续高残差 → 边界条件有问题 | 某一步 Tool Call 反复失败 → Prompt 约束不够 |
| 算例莫名其妙发散 → 检查数值稳定性 | Agent 突然胡言乱语 → 检查上下文窗口 |
| 用了高阶格式但网格密度跟不上 → 方法不匹配 | 给了太多能力但模型不够好 → 能力范围太大 |
这一条不是理论推出来的——是实际踩坑踩出来的。Sulix Novel 的 Agent 在第一次 Bake-off 测试里花了 420 美元的 Token，正确率只有 70%。CFD 的老同事说”这也太亏了”，我说”我跑了 3000 核·时的仿真算一个案例的时候，也没人说便宜”。
所以我到底在说什么
我不是说 CFD 工程师做 AI 比别人”厉害”。我是说：
十年做同一件事形成的工程直觉，换了领域也不会消失。它只是换了个容器。
那些你以为是”只会用 Star-CCM+“的技能——盯着残差曲线判断收敛、直觉上知道哪个边界条件设错了、能一眼看出结果是数值振荡还是物理不稳定——它们不是 CFD 技能。它们是”理解和调试复杂系统”的通用能力。
AI Agent 也是一个复杂系统。输入→循环→判断→反馈→调整→收敛。这个循环我跑了十年。你告诉我它换了层皮我就不认识了？
所以我给其他工程背景想转 AI 的人的建议是：
不要从 Transformer 论文开始看。从你已经会的东西开始。
找一个你熟悉的物理过程（燃烧、流动、传热）和一个 AI Agent 流程做对比。找到那个”同一件事”的抽象层。然后你会发现不是从零开始，是把旧工具包里的直觉倒进新的容器里。
CFD 求解器和 AI Agent 都是同一个故事的不同版本：如何在有限资源内，让一个系统逼近可接受的解。
只不过以前我盯的是残差曲线，现在我盯的是 Token 消耗。以前我判断”这个算例收敛了吗”，现在我判断”这个 Agent 闭环了吗”。
曲线变了。问题没变。
顺便：学会用了之后，需要自己总结出自己的范式，这样会走得更顺一些。这就是我在做的。