既然不想买高价显卡，我就在代码里优化每一个 Token。这话说出来，自己都觉得有点悲壮，像是个守着老手艺不肯放下的匠人，眼睁睁看着隔壁用上了全自动流水线。
今天跟团队里一个 97 年的后端聊，他问我怎么用 LangChain 搭个客服机器人，最快多久能上线。我下意识就开始拆解：你得先处理意图识别，NER 实体抽取的准确率怎么保证，对话状态管理用有限状态机还是基于 embedding 的向量匹配，上下文窗口长了怎么压缩，短了怎么补充……我这边还没说完，他那边已经用 GPT-4 的 API 写了个 demo 出来，虽然粗糙，但功能点全了。他挠挠头说：“哥，你说的那些太底层了，现在不都封装好了吗？调个参数的事儿。” 我愣在那儿，嘴里那句“底层不稳，上层都是空中楼阁”硬是没说出来。那一刻我清晰地感觉到，我过去十年赖以生存的“深度拆解能力”，正在被一种“原生应用直觉”降维打击。他们这代人，生来就在云上，API 就是积木，拼起来就能跑。而我们这代人，总忍不住想掀开盖子，看看里面的齿轮是怎么咬合的。
这种执念，直接反映在成本上。他们可以毫不在意地调用 GPT-4 的 128K 上下文，一次对话烧掉我几毛钱。而我，还在为如何把 prompt 精简到 500 token 以内、如何用更便宜的 text-davinci-003 模型通过思维链提示达到近似效果而绞尽脑汁。我像个抠门的账房先生，在代码的每一个角落算计。用 `tiktoken` 库精确计算输入 token 数，非核心描述一律删掉；把系统指令从一段充满人情味的“你是一个乐于助人的 AI 助手”压缩成冰冷的“角色：客服。任务：解答产品问题。规则：不涉及价格与售后政策。”；把多轮对话历史，用提取摘要或者只保留最近 N 轮 + 关键实体信息的方式压缩再压缩。我甚至研究起了不同模型输出 token 的定价差异，琢磨着什么时候该用 ChatGPT 3.5 Turbo，什么时候必须上 4.0，这感觉就像十年前研究不同云服务商的流量计费策略一样。
但你说这是迂腐吗？我不完全认。当他们的“积木应用”遇到真正的生产环境问题——API 频率限制突然触发、响应时间从 2 秒变成 20 秒、或者因为 prompt 不严谨导致输出完全跑偏时，他们往往会懵掉。这时候，我那套“老手艺”就派上用场了。我知道怎么设计重试机制，用指数退避应对限流；知道怎么把大任务拆成小任务链，用更便宜、更快的模型做预处理，只在关键节点调用重型模型；知道怎么用 `n8n` 或者自建中间层做请求队列和缓存，平抑波峰。这些不是“调个参数”就能解决的，这是实打实的工程问题，是钱和稳定性的问题。
所以 38 岁，学画图、学写诗？那太表层了。我们要学的，是理解这套新积木的内在力学结构。知道哪块积木承重强但贵，哪块便宜但易碎。然后，用我们最擅长的“组装机器”的能力，把这些 AI 积木，和自动化流程（`n8n`、`Zapier`）、和现有的业务系统（CRM、ERP）、甚至和物理设备（通过 API 控制的硬件）连接起来，搭建出一台能自动运转、能产生现金流的机器。这才是我们的战场。用老兵的工程思维，去驾驭新兵的原子能力。显卡买不起，就逼自己成为最懂 Token 流向的架构师。这口气，不能松。
