一家面向代理机构的 AI 技术栈，是一家机构运行其 AI 工作所依赖的五层：客户记忆、编排、生产、审阅和衡量。它不是一文件夹的订阅。技术栈的存在是让机构更快、而不更不负责，而唯一值得建而非买的层，是那个承载机构对其客户所知的东西的层。
我见过机构买出一条 AI 故事，最后落得一张在提案里令人印象深刻、在交付里令人困惑的工具清单。技术栈问题其实是一个穿着技术外衣的运营模式问题，所以在花钱之前值得把两者分开。
为什么数工具数是错误的框架
默认的直觉是数工具。十二个平台、五个模型、一个设计工具、一个抓取工具、一个报告工具。工具数容易展示，也大体无意义，因为两家有相同订阅的机构能有完全不同的结果。一家把它们接进一条工作流、配单一客户真相来源；另一家有十二个标签页和零记忆。
重要的技术栈由层与层之间流动的东西定义，而不是由每层里坐着什么定义。如果一份简报进来一次、产出一个方案、一次投放、一份报告、以及一个喂给下一份简报的学习，你就有一个技术栈。如果每个工具都从零开始，你有一堆。那个区分就是全部游戏，而它在采购表格里是看不见的。
五层
我见过的每一条管用的机构技术栈，都归结到同样的五层。它们不是产品；是要做的工作，你可以按规模用不同的建/买/流程组合填充每一层。
| 层 | 工作 | 买还是建 |
|---|---|---|
| 客户记忆 | 保存简报、过往工作、品牌规则、结果 | 建——这是护城河 |
| 编排 | 路由工作、持有上下文、跑循环 | 买，再配置 |
| 生产 | 起草文案、创意、方案、代码 | 买——变化最快的一层 |
| 审阅 | 抓错误、执行品牌、核对事实 | 建评分表，买工具 |
| 衡量 | 把产出诚实地绑到结果 | 数据买，框架建 |
顺序很重要。记忆坐在一切之下，因为其他每一层在能读机构已知的东西时都更有用。审阅坐在生产之上，因为没有审阅的生产，是机构高速交付自信错误的方式。
第一层：客户记忆
这是我会先建、也最用力守的一层。它是机构存储对每个客户累积的理解的地方：简报历史、品牌规则、胜出与失利的创意、衡量读数、决定以及为什么做它们。没有一样是稀奇的。所有都难以复制，因为它特定于你做过的工作。
一个通用模型知道品类。你的技术栈应该知道你的客户。那个差别，是一天之内做出一家机构能做、而客户的内部工具根本做不到的事的原因，而且每保留它一个月就复利一次。如果你想要这一层为什么是持久的那一层的长版本，我单独写过客户记忆数据护城河。
第二层：编排
编排是把一个工作搬过技术栈、同时携带上下文的管道。它回答这样的问题：当一份简报落地，什么运行、以什么顺序、带哪份记忆、以及在一个东西被发出之前哪里有人看。在小机构里，这常常是一个人加一张清单，那是一个合法的答案。在更大的里，它是一个工作流工具或一个薄的内部应用。
陷阱是在你知道自己的工作流之前就买一个编排平台。软件会愉快地编码一个你没设计过的流程，那是机构最终自动化自己现有混乱的方式。先在纸上设计循环，手工跑一个月，然后才找东西来承载它。
第三层：生产
生产是会商品化的层，也是买几乎总胜过建的一层。起草文案、生成创意、组装方案、写代码的模型和工具，改进得比任何机构能内部跟上的都快。你在这里的工作不是建引擎；是选少量引擎并深入学习它们。
抵制每周加一个新生成器的冲动。在生产里深度胜过广度，因为一个随意使用的工具与一个用调好的 prompt、知道其失败模式的工具之间的质量差别，大于工具本身之间的差别。挑两三个，写下它们擅长和不擅长的，每季度修订那张清单。
要警惕的陷阱是那种感觉快、却悄悄削弱团队判断的工具——一个我在「快但削弱判断」的工具陷阱里写过的失败。那种工具比它的订阅更贵，因为在起草时间上省下的，会以没人抓住的错误回来。
第四层：审阅与 QA
审阅是机构区分自己的地方，因为它是客户为之付钱、而大多数技术栈忽视的那一层。AI 让生产便宜、让审阅昂贵，意味着你规模化的那一刻瓶颈就移到审阅步骤。一个没有审阅层的技术栈不会规模化；它会累积审阅债，直到某样尴尬的东西上线。
即便工具你买了，也把评分表建起来。什么算合乎品牌、什么算需要来源的事实宣称、什么算在任何东西靠近客户之前的硬停止。评分表是机构的判断被说清楚，也是让一个初级操盘手能在没有资深的人盯着的情况下跑一次资深质量检查的东西。
第五层：衡量
衡量闭住循环，它的工作是诚实、而非量。技术栈应该能说出：一份工作本该改变什么、实际动了什么、以及你对这份工作导致了它有多自信。那比数产出更难，也是把一家能辩护自己费用 的机构、与一家只能展示活动的机构分开的东西。
买数据管道，因为归因数据住在你不控制的平台里。建框架，因为框架是判断所在。一个薄而自律的框架——一个业务结果、几个领先信号、一条关于你能归因什么与不能归因什么的诚实笔记——胜过一个人人都不读的二十指标 dashboard。
如何给搭建排序
从记忆和一条手工跑的循环开始。把客户知识放进一个地方，写下工作经过的步骤，手工跑它直到步骤不再变。然后给最痛的那些步骤加生产工具。在生产快到足以制造审阅压力时加审阅。当你有值得衡量的东西时加衡量。
那个顺序在第一个月感觉慢，却省一年的返工，因为每一层都在下一层稳定时才被加上。挣扎的机构，通常是那些先买了生产、然后试图把记忆和审阅从旁边拧上去的。技术栈必须从机构已知的东西往上长。
一次演练过的技术栈复盘
每年一次，通过让一个真实工作端到端走过技术栈来审计它。从一份简报进入的地方开始，跟着它过编排和生产，点名人在哪里审阅，结束在衡量读数。在每一次交接，问两个问题：上下文穿过来了吗，一个新人能不能不提问就跟着走？如果上下文在两层之间丢失，那是要先修的那一层，因为记忆在阶段之间泄漏，是把五个工具变成五件不相干任务的东西。如果没人能把一个结果追溯回产出它的简报，衡量层就是装饰性的。这次复盘花一个下午，比一次订阅审计告诉你更多，因为它测试的是连接，不是清单。
FAQ
我们需要自己的模型吗？
几乎从不需要。一家机构技术栈的价值在记忆、编排和判断里，不在训练里。fine-tuning 只在你有一个大、稳定、专有的数据集、以及一个通用模型处理得很差的 任务时才值得。大多数机构两者都没有，应该把力气花在记忆层上。
我们该建多少、买多少？
买那些改进快、且别的公司也用的层，因为你无法在那些上比市场投入更多。建那些承载你特定知识、编码你特定判断的层，因为只有那些竞争者买不到。记忆和审阅是建的层；生产和数据是买的层。
最大的技术栈错误是什么？
在设计与连接它们的流程之前就加工具。它看起来像进步，产出一张续费清单，并让机构带着同样的瓶颈、加上更多订阅。技术栈应该跟随运营模式，永远不是反过来。
我们如何让客户数据在这一切里安全？
把记忆层当作边界。客户数据住在你控制的存储里，工具只读一项任务需要的东西，你保留一份什么进去、什么出来的记录。那是一场既关乎治理、也关乎技术的对话，应该在技术栈规模化之前解决。
简短版
一家机构 AI 技术栈是五层——客户记忆、编排、生产、审阅和衡量——围绕运营模式装配。买会商品化的层，建那个承载你所知的层，并让技术栈从记忆往上长。执行指南覆盖这个技术栈所服务的工作流，面向代理机构的车道把它贯穿机构运营模式来做。
如果你的机构反着搭了技术栈——工具先行——我想听听是什么逼出了重设计。
祝好， Chandler
本文提供简体中文版本。课程材料（视频、模板和配套指南）以英语、日语、简体中文和韩语提供。本网站提供 13 种语言版本。