这一年来看 AI 应用，有一个坑很常见：

先写一个大 Prompt，把用户输入、业务背景、输出格式全塞进去，然后等模型吐答案。

Demo 阶段很快。
上线之后就开始还债。

答案偶尔跑偏，不知道是 Prompt 问题、模型问题，还是业务规则本来就没讲清楚。想加一个限制条件，继续往 Prompt 里补一句。想修一个边界场景，再补一句。最后那个 Prompt 越来越长，像一坨没人敢动的祖传 SQL。

我做易策的时候，也差点走这条路。

这个项目本质上是一个基于周易框架的 AI 决策参考系统。用户输入一个问题，系统根据问题场景匹配卦象，再从六个角度分析，最后生成一份决策参考报告。

最简单的做法当然是：

给 LLM 一个角色：你是周易专家。
用户问什么，你就结合六十四卦给建议。

这样一天就能做出原型。

但这个东西没法长期维护。因为你不知道模型到底是怎么选卦的，也不知道它为什么这样分析。今天说是需卦，明天可能说是乾卦。今天强调风险，明天强调机会。看起来都能自圆其说，但系统本身没有骨架。

后来我把这件事拆成了三层：

规则管流程，数据管知识，模型管表达。

流程先固定下来。

用户问题不会直接丢给模型生成最终答案，而是先进入一个结构化上下文：

raw_question
question_type
background
constraints
expected_outcome
time_horizon
risk_tolerance

这一步的意义不是炫技，而是把“用户随口问的一句话”变成系统能处理的中间状态。

中间状态很重要。没有它，后面每一步都只能靠模型猜。

然后是场景路由。

系统根据问题类型、关键词、场景映射去匹配卦象。能用确定规则解决的，就不要交给模型拍脑袋。只有规则覆盖不到的时候，再让 LLM 做辅助判断。

这跟很多垂直 AI 应用是一样的。

比如智能客服里，用户问“能不能退款”，你不能只让模型自由发挥。它至少要先经过几个确定步骤：

识别意图
确认订单状态
匹配售后规则
判断是否需要人工
生成回复

模型可以负责最后一句话怎么说得自然，但它不应该决定该不该退款。这个决策应该来自业务规则。

易策里的六爻分析也是这样。

我没有让一个模型一次性写完整报告，而是把六个视角拆开：

初爻：环境感知
二爻：资源配置
三爻：风险评估
四爻：策略执行
五爻：长期规划
上爻：结果复盘

每个 Agent 只负责一个角度。
它不需要理解整个宇宙，只要把自己那一层讲清楚。

这样做有几个好处。

第一，输出更稳。
每个模块的职责是固定的，不会今天聊风险，明天聊愿景，后天开始讲人生哲理。

第二，问题好定位。
如果最终报告太空，去看 Reporter。
如果场景匹配错了，去看 SceneRouter。
如果某个视角分析跑偏，去看对应的 YaoAgent。
而不是盯着一个几百行 Prompt 猜半天。

第三，系统可测试。
中间状态、路由结果、六个分析结果、最终报告，都可以单独测。AI 应用不是不能测试，前提是你别把所有逻辑都藏在模型回复里。

第四，后续好扩展。
要加新场景，改数据。
要调路由，改规则。
要换模型，改配置。
要增强表达，再调 Prompt。
这些事情不要混在一起。

我现在越来越觉得，做 AI 应用最关键的不是会不会写 Prompt，而是会不会决定：

哪些东西不该交给模型。

模型适合处理模糊表达、语言理解、摘要、生成、归纳。
但流程边界、业务规则、状态流转、权限判断、风险约束，最好显式建模。

否则项目刚开始看着很快，后面每一步都在补 Prompt。

这也是我做易策时最大的一个经验：
不要把 LLM 当成整个系统的大脑。它更像一个能力很强的组件。

系统该有自己的骨架。
模型只是其中一块肌肉。

骨架清楚了，模型换掉也还能跑。
骨架不清楚，再好的模型也只是把混乱包装得更像答案。