Appearance
AI应用思路：成本篇
随着 AI 的普及，公司和个人都会慢慢回过味来：资源总是有限的，不可能什么事情都靠“大力出奇迹”。
在 IT 行业里，我一直比较认同一个公式：
利润 = 需求 - 设计
优秀的设计，能显著降低成本。
所以在 AI 应用里，真正值得研究的，不只是模型能力，而是：哪些设计能把成本真正降下来。 下面分享一些个人落地经验。
一、上下文：关键是按需加载
这个思路并不是 AI 时代才有。
在微服务里叫关注点分离，在单体架构里叫模块化，在工作流里也一样，通常都会拆成需求、设计、编码几个阶段。说到底，都是一个思路：当前阶段只处理当前需要的信息。
完成一个场景，很多时候并不需要全部背景信息。
如果流程分成 A、B、C，做 B 的时候还把 A 和 C 的大量信息都带进来，损耗往往不是 A + B + C，而是 A * B * C。
上下文不是越多越好，对人如此，对 AI 更是如此。
不要过早暴露不需要的信息。这样做有两个直接好处：
- 降低问题复杂度
- 节约调用成本
二、知识库：先把结构做好
之前常说的 RAG，本质上就是给问题匹配相关上下文。常见做法是向量库，但它有个核心难点：文档切分。
切得不好，效果就会很不稳定。更麻烦的是，这件事在不同领域里差异很大，很难有通用方案。
我比较倾向的一种做法是：不要只想“怎么找到答案”，也要想“怎么把答案组织得更容易被找到”。
具体点说，先让懂业务的人按业务模块自上而下拆知识，再建立一套结构化索引。
这样即使知识库很大，也无非是树多几层。只要节点切得足够小、足够准，召回质量就更容易稳定。
建立索引之后，还可以继续压缩知识本身。
因为自然语言里往往有很多背景话、重复话、解释话。真正必要的信息，可以压缩成更结构化的形式，比如：
- JSON
- YAML
- 建模语言
- 结构化字段
这样做的好处很直接：上下文更短，召回更准，成本更低。
三、工作流：能固化的就别让 AI 现场发挥
以前做传统系统，这个问题没这么明显。因为每一步做什么，代码里都很清楚，基本不会有太多没用的东西。
但到了 AI 时代，经常有人拿着一大段描述直接去调用模型。比如“参考某本书，做某件事”。这种方式通常很难达到目的，还会浪费成本。
所以在设计 AI 工作流时，我更建议自上而下去做：
- 先把复杂流程的关键节点理出来
- 把稳定、重复、可规则化的部分做成固定脚本或固定 skill
- 再由人工或调度层去编排和完善
- 只把真正非结构化的部分交给 LLM
如果条件合适，甚至可以直接用 workflow 平台把结构化节点固化下来，让 LLM 只参与非结构化业务。
一句话：能固化的就固化，能结构化的就结构化，不要什么都丢给模型临场发挥。
四、工具使用：好钢要用在刀刃上
从我的使用体验来看，一个规律很明显：
- 越便宜的 AI 或 agent，越需要提前给它设计规则和流程
- 越高级的 agent，越能靠自然语言直接完成复杂任务
但这两种方式都有成本。
所以关键不是单纯追求“更强”，而是要做价值排序，把贵的能力用在真正重要的地方。
拿常见工作流程来说，一般可以分成大众认可的：
- 需求
- 设计
- 编码
如果做价值排序，我个人更倾向于：
需求 > 设计 > 编码
越靠前的环节，越决定方向；越靠后的环节，越偏执行。
价值越高的环节，往往人参与得越多，AI 能直接替代的部分反而越少。看起来有点矛盾，但也正常，因为高价值问题本来就更复杂，具体复杂的问题再怎么拆分更适配人+AI的模式这里不展开讨论。
所以我的理解是：高难度、高价值的问题，用更强的 agent 去解决；规则明确、重复度高的问题，就别用太贵的能力。
五、低价值流程固化：不要反复用 AI 做重复劳动
对于流程固定、规则固定的工作，不要每次都重新让 AI 驱动完成。
更合适的做法通常是把它固化下来，比如：
- 简单脚本
- 模板化流程
- workflow
- 半自动工具
后面只做动态调整就够了。
这样做的价值很直接：
把本来反复消耗模型成本的事情，变成一次设计、长期复用。
六、结语
AI 应用的成本优化，本质上不是少用，而是用对地方。