3
0EP105 | 带你云游WAIC大会：OAK架构——选项与知识，一个拿走就能用的方法
本期简介
辉子读完Sutton演讲前三期已经上头，终于等到了第四期——OAK架构。这次他不是来听大道理的，是来拿工具的。更巧的是，他手头正好在做供应商画像的8个维度，读着读着发现，Sutton说的"特征到子问题到选项到转移模型"，跟他的实际工作对上了。但他也有个真实的困惑：8个维度都要建技能吗？忙得过来吗？小超带着他的工作日志来帮忙拆解，两人一起把Sutton的理论框架和辉子的工程实践（FC-STOMP）给串了起来。本期你将听到：什么样"活的"特征才值得建技能？转移模型不需要一开始就设计好？FC-STOMP其实是OAK架构的工程实现版本？
本期内容
特征不值钱，子问题才值钱——筛选"活的"特征
辉子一开始特别兴奋：我有8个维度，那是不是要建8个子问题、8套选项、8个转移模型？但小超给他看了Sutton在Q&A环节亲口说的一句话——"我们绝对不能为每个特征都创建子问题，特征是便宜的，子问题是大对象。" 这句话直接让辉子懵了：你说特征到子问题是一对一，又说不能全建，到底听哪个？
关键转折来了：小超让辉子重新审视自己的8个维度——名称和品类是死的，不管你怎么努力它们都不会变，不值得建技能。但报价响应率、活跃度、动态状态是活的，每一天都在变化，而且你能主动去影响它们。**只有"活的"特征才值得建技能**——因为你有影响空间，你的动作可以改变它的值。按照这个标准，辉子的8个维度筛掉了2个，剩下6个值得建技能。
转移模型不是设计出来的，是跑出来的
辉子最头疼的问题是：为每个特征建一个"如果执行了这个选项会发生什么"的预测模型，这个从哪来？他以为需要一开始就把规则定义好。
小超翻出辉子的工作日志里写过的"反馈循环"——每一次询单完成，真实成交还是没成交，客户满意还是投诉——这个反馈回到系统里，系统就知道了"原来推荐这个供应商，在这样的场景下，结果是这样的"。这不就是转移模型吗？**转移模型不在初始设计里，在每一次真实反馈里长出来。** 你不需要一开始把模型写好，你只需要设计好"收集反馈、更新模型"的机制。跑上个几十次，数据链出来，转移模型自然就形成了。
FC-STOMP = OAK架构的工程实现
辉子之前写过一套方法论叫FC-STOMP——特征发现、子任务、技能、模型、规划。他一直以为这是一条流水线，按顺序走一遍就完了。但听完Sutton说的"智能体可以随时生成新特征"，他突然意识到：不是的。
小超帮他一对一映射：**FC（特征发现）对应Sutton说的特征和子问题，S（子任务）就是子问题的产品经理版本，T（技能）就是选项，M（模型）就是转移模型，P（规划）是做完以上所有之后才能做的**。而且FC-STOMP不是一个线性流程，是一个循环。每执行一轮"推荐到反馈"之后，F阶段要重新扫描——有没有新特征冒出来？S阶段重新建——旧子任务的技能描述还够不够细？M阶段重新学——模型预测准不准？这才是"用起来"的方法。
本期小建议
如果你也有一个表格、一个画像、一堆维度想要优化，问自己四个问题：
1. 这个特征是"活的"吗？ — 它的值会随时间和你的动作变化吗？如果不会，不建技能。
2. 这个特征的子问题到底是什么？ — 把你的目标写清楚，而不是模糊地说"我想优化它"。
3. 你的选项怎么定？ — 具体怎么做，以及什么时候停。把策略和终止条件都想清楚。
4. 执行后的反馈怎么收集？ — 每次动作的结果怎么被记录、怎么回收到系统里？把这个机制设计好了，转移模型会自己长出来。
而且这四个问题不是问一次就完事的。每跑一轮真实反馈，重新问一遍——尤其是第一个问题：有没有新特征值得建技能了？
---
关于《辉子下班啦》
更新频率：每日更新（工作日）
单集时长：5-10分钟
互动方式：如果你也在用AI的过程中有困惑或者心得，欢迎来找我们聊聊！
感谢收听！咱们下期见！
