博客好久没更新了。
最近有点累，乏于做笔头工作，不过有个话题这个月一直在脑子里打转，索性找了个周二的午后写下来（而且今天没额度了，你懂的哈哈哈）。
前阵子我调整了一下和AI协作的方式，有一个挺强烈的感受：
不要成为AI的传话筒。
先说我之前的用法：
我会习惯给每个项目都先建立一个Main会话，用来沟通我的想法、拆解问题、做整体规划。想清楚之后，Main会把任务拆成具体的worker，让worker去执行。
这样做的好处是——避免让人类这颗最贵的大脑陷入做廉价的笔头工作，而是把精力放在最重要的问题定义上，况且论逻辑和闭环，Main一定会比人类写指令写得更好。
这听起来挺顺的，对吧？
但最初的几周，我累得够呛。
因为Main和worker之间不直接通信，每一条Main给worker的指令，都要我人肉复制粘贴过去；worker跑完了，我再把结果复制粘贴回Main；然后Main看完说“这里再改一下”，我又复制粘贴给worker；如此反复……
于是，我变成了一个“人肉 API 接口”。
90%的精力花在传话上，而真正用于思考的时间被挤得所剩无几，更重要的是，这真的很累人！
你的精力被挤压后，原本该去定义和解决问题的专注力也会随之下降。
后来我开始琢磨一件事：能不能让worker自己跑一段路，不撞南墙不要来烦我？
这里并不是说让它无限制地跑，而是给它一个足够清晰的边界，让它自己在边界内推进，且一旦真的推到撞墙了，它自己能安全停下来，然后我再去和Main一起看：到底是哪里撞墙了、为什么撞墙、是产品定义问题还是技术问题，怎么解决……这可比我在中间来回传话高效得多！
但要做到这一点，给worker的指令就不能是简单的“帮我做这个”，它需要包含几个东西，我摸索了一段时间，大概是这样的：
第一，明确的目标。
不是“我这里要一个按钮”，而是我们是怎么做规划的、这里要达到什么目标，所以需要一个什么功能承载，面向谁提供服务等等，你和Main讨论的目标越具体，worker越不容易跑偏。
第二，清晰的边界。
哪些事能做、哪些事不能做，要提前说清楚。比如“可以修改文本内容，但不要改动原始文件结构”、“可以生成最后可发布的文件，但禁止在生产环境部署”、“可以调用网络搜索，但不要发送任何邮件”等等。
第三，安全阈值和终止条件。
这是最关键的部分。我们需要告诉worker：什么情况下你应该停下来。比如“如果遇到无法解析的格式，不要自己猜测，停下来报告”、“如果连续三次尝试都失败，停止执行，输出错误日志”等等。
不过，你也要给它空间，因为这样极容易变成——有点问题worker就停下来问你，你还是无法摆脱做API的厄运，更好的方式是让它在一定轮次内先尝试自我解决，尝试自己推过去，而不是发生个屁大点儿的事情就眼巴巴的停下来看着你。
第四，授权范围。
我能给你什么权限，你不能碰什么。这个在Codex里尤其重要，因为它有沙盒机制，你需要明确告诉它哪些操作是被允许的。
把这四样东西说清楚之后，大体上worker就能自己跑一段路了。
它会在边界内自主推进，遇到真的解决不了的问题就停下来，而不是一味的硬着头皮乱试（除了耗时，主要是废token 啊！）。我收到它的“撞墙报告”（也或者是完成报告）后，再去和Main一起分析：这个问题是目标没定义清楚、还是边界设窄了、还是工具本身的能力不够，亦或者这一轮我们的设计就是让它在这个位置停下来（完美！）。
我的角色从“传话筒”变成了“看block的人”。
区别在哪？
传话筒的精力花在搬运上，看block的精力花在判断上。前者是体力活，后者才是真正需要人类介入的地方。
自从这么调整之后，确实爽了很多，我不再需要盯着每一条指令的流转，可以把精力放在更上层的事情上：目标对不对、边界合不合理、结果符不符合预期。
当然，代价也有。
烧token比较狠！
因为worker在自主推进的过程中，会尝试更多的路径、会做更多的推理、完成更远的任务，这些都要消耗token，以前我只让它做一步，现在它可能自己跑十步。
我有一次看统计，9 月初的时候，有一天仅仅一个上午烧掉了我2.5 亿 tokens，心在滴血……
但我觉得这个代价是值得的！这些tokens换的是我90%的精力被释放出来，头脑清明这笔账，怎么算都划算。
回头看这件事，我意识到一个更大的问题：
很多人用AI的方式，本质上是在用“人肉API”的模式。
你给AI一个指令，它返回一个结果，你再给下一个指令，它再返回下一个结果，你全程都在中间做搬运工，AI只是一个更快的执行工具。
如果这样，人就被 AI 挟持了。
你真正需要做的，应该是帮它把这条路画清楚：目标在哪、边界在哪、什么时候该停下来。
然后你就可以去做别的事了。
别做AI的传话筒，做那个画地图的人。
不过，我说的可能都是错的。