一开始用 codex，我真的很认真。
不是那种“随便试试”的认真，而是会盯着每一次提问想：这句话该怎么问更准？我到底要它调用什么能力？这次的目标是生成、修改、解释，还是接管后面的执行？
后来我又给它装了一套 superpowers。
按理说，工具更强了，效率应该更高。可真实体验恰恰相反：技能越多，我越得先记住它们各自会什么；场景一复杂，我还得自己判断这一步该切哪个 skill、下一步该不该继续交给它接管。
那阵子我最明显的感受不是“AI 真厉害”，而是“我怎么越来越像它的调度员了”。
我本来是想让 AI 替我干活，最后却差点把自己练成了 AI 的人肉调度台。
这件事对有些人可能只是麻烦，但对我这种记性没那么好的人，是很现实的负担。你以为自己在使用工具，实际上却开始替工具记路由、记路径、记流程。复杂度没有消失，只是换了个壳，又压回到了人身上。
最近我在整理一套给公司中层管理者讲 AI 的材料，写到这里时，我突然意识到：我前面其实有点走偏了。
我原来以为，问题在“怎么把人训练得更会用 AI”这也是很多人现在默认的方向：
既然 AI 越来越强，那人就应该学会写 prompt、拆任务、调工具、串工作流、选技能。谁懂得多，谁就更有优势。
这条路不能说完全错，但它有一个很大的副作用：它很容易把本该由系统承担的复杂度，再次分配给人。
尤其是在公司里，真正频繁用 AI 的，往往不是来玩工具的人，而是要对结果负责的人。
他们要交付方案，要过 review，要跟上下游对齐，要为最后的结果拍板。对这类人来说，最贵的从来不是“不会几个 prompt”，而是心智被后厨细节占满：今天该用哪个模型，哪个 skill 更稳，先走哪个流程，出了问题又该怎么回滚。
如果一个系统最后要求使用者先学会做“后厨操作员”，它就不是在减负，而是在转移负担。
人与 AI 协作的未来，不是把人训练成更熟练的后厨操作员，而是让 AI 接住后厨复杂度。
后来我换了个类比，很多事一下就顺了
我后来拿厨房来理解这件事，发现特别清楚。
先说食材。
数据、纪要、报表、制度、聊天记录，这些都是交给 AI 的原始材料。它们像厨房里的菜、肉、调料，本身不是结果，但没有这些，后面就无从加工。
再说后厨。
prompt、工作流、工具组合、执行路径，本质上都属于“怎么加工”这件事。该先切还是先炒，先检索还是先生成，直接做还是先写 spec，这些其实都更像后厨里的工序安排。
最后是人。
人该负责什么？点菜、验菜、上桌。
翻译成工作场景，就是定目标、控边界、做最终判断。你得知道这顿饭是做给谁吃的，什么不能放，最后端上来的东西是不是能交付、能负责、能拍板。
这个类比最关键的地方，不是好懂，而是它把复杂度分配讲明白了：
食材可以由人提供，后厨复杂度应该尽量由 AI 接住，人不该长期站在灶台边，既背菜单，又记火候，还要顺手排工序。
人真正该守住的，不是灶台上的每一步，而是目标、边界、验收和最后拍板。
我后来做的，不是继续加技能，而是先做“收口”也是因为这个判断，我后来没有继续沉迷“再多装几个技能”。
我直接把问题抛给了 codex：能不能别让我每次都先当路由器？能不能先帮我判断，我这次到底在说什么，需要走到哪一步，值不值得启动一整套流程？
后来我打磨出了一个我自己很常用的底层收口工具：token-scope-tightener。
它不是上来就干活，而是先做三步默认动作：
• 先显式整理任务交代卡：目标 / 背景 / 输入 / 约束 / 输出标准• 再压缩成执行 brief：scope / task_type / goal / no_touch / strategy / output_contract• 最后只给一个路由结论：direct_execute / write_spec_then_execute / route_to_skill / ask_one_blocking_question
这个工具最打动我的，不是它“聪明”，而是它终于开始替我接住一部分本该由系统承担的复杂度。
它不再默认全仓扫描，也不动不动问一长串问题；它先把任务说清楚，把范围压小，再决定最轻的正确推进方式。只有当信息缺失真的会影响实现方向或验收结果时，才补 1 到 2 个关键问题。
说白了，它是在帮我把一件事先收口，再开工。
AI 真正该替人接走的，不是一点执行力，而是后厨里的复杂度。
真正需要被纠正的，不是人的努力，而是复杂度压错了谁这也是我现在越来越确定的一件事：
很多人讨论人与 AI 的未来，第一反应总是“AI 会不会替代人”“人要不要学更多工具”。但在真实工作里，这两个问题都太大，也太虚。
更有用的问题其实是：这段复杂度，到底该由谁来接？
如果一套系统越来越强，结果却要求使用者记更多技能、背更多路径、承担更多工具切换，那它不是更先进了，只是把后台复杂度伪装成了个人能力要求。
这类错位，在组织里特别常见。
嘴上说“大家都要学 AI”，实际落到一线，却变成“你自己去搞明白流程、自己去辨认路由、自己去承担系统没收干净的复杂度”。最后最累的，往往不是工具本身，而是那个既要出结果、又得替系统补洞的人。
系统该接走的是后厨复杂度，人该留下的是点菜、验菜、上桌。
所以我现在反而不太担心“AI 会不会把人挤没”。
我更关心的是：我们会不会一边喊着提效，一边把越来越多本该系统化的负担，重新压回给具体的人。
如果是那样，问题从来不在“人不够努力”，而在复杂度分配出了错。
而人与 AI 协作更靠谱的未来，也不是人人都去学做厨师，而是把人放回人的位置，把 AI 放回 AI 的位置：
人定目标，人控边界，人做验收和最终判断；AI 去接信息处理、执行加工、路径选择和后厨复杂度。
这样，普通职场人不会被复杂度吞掉；那些在公司里真正对结果负责的人，也终于能把注意力放回最重要的地方：这件事要做成什么样，边界在哪，结果算不算过关，最后能不能拍板。
你在公司里用 AI 时，有没有遇到过这种情况：
本来是想省力，最后却变成你在替系统记流程、记工具、记切换路径；本来是想提效，结果新增了一层只有你自己知道的“隐性劳动”。
如果你有，欢迎留言说一个最具体的场景：
• 你当时在做什么事？• 哪一步开始感觉“复杂度压回来了”？• 最后是 AI 接住了，还是你自己硬背了下来？
我想继续把这些真实场景收集出来。因为比“AI 强不强”更重要的，是我们得先看清：今天到底是谁，在替谁扛复杂度。