目录:
想象你团队来了个新同事——聪明、勤快、知识面广，但对你们的业务一无所知。第一天上午你走过去说：“帮我整理一下那个项目的材料。” 没说哪个项目，没说给谁看，没说什么格式，没说什么时候要。
他大概率会交出一份正确但平庸的文档。你看了一眼：“这也太模板了。”
这不是他能力不行，是你没把活派清楚。
现在把"新同事"换成 AI。同样的场景，同样的结果。但大多数人的反应不是"我没说清楚"，而是"AI 不够聪明"。事实上，AI 落地的真正瓶颈不是模型能力，是任务委托能力——一项被严重低估的管理技能。
一、任务委托四要素
给一个靠谱的新同事派活，你需要给够四样东西。给 AI 派活，一模一样。
目标定义：要结果，不是步骤。 “帮我写一份竞品分析"比"先打开 Google，搜索 XX，然后整理成表格"好十倍。好的委托定义产出的形态和验收标准，而不是规定每一步动作。告诉同事你要什么样的输出，让他自己决定怎么做。
充分上下文：背景、历史、约束、偏好。 这份分析是给 CEO 季度汇报用的，还是产品团队内部讨论用的？上次类似的分析是什么水平？有没有不能碰的竞品？你的老板喜欢数据密集型还是叙事型？这些信息不说，对方只能猜——猜对是运气，猜错是常态。
工作工具：环境、工具链、数据源。 你不能只给目标不给资源。CRM 账号在哪？数据看板怎么登录？内部文档库的地址？不让同事接触工作系统，他就只能纸上谈兵。AI 也一样。
反馈机制：checkpoint 和迭代空间。 “做到一半给我看看”、“方向不对随时问我”——这不是微管理，是正常的协作节奏。一次委托、一次交付、没有中间反馈——这种模式对人不行，对 AI 也不行。
四个要素缺任何一个，结果都会打折扣。人如此，AI 也如此。
二、四种常见的委托失败
对照四要素，绝大部分"AI 不好用"的吐槽都能归入四种模式：
只给目标不给上下文 → 模板味。 “帮我写个方案。” AI 只能产出一份正确但泛泛的东西——因为它不知道你的具体处境。所有"一看就是 AI 写的"抱怨，根源大多在这里。你给了一个 generic 的输入，自然得到一个 generic 的输出。
给上下文不给工具 → 纸上谈兵。 你把背景讲得很清楚，但 AI 摸不到真实数据、代码库、内部系统。它只能基于训练知识"想象"一个方案，看起来专业，经不起验证。
给工具不给反馈 → 闷头跑偏。 这在 Agent 场景最常见。Agent 拿到工具就开始执行，一路跑了十几步，最后发现方向一开始就偏了。没有 checkpoint——就像新同事闷头写了三天代码才发现需求理解有误。
过度规定动作 → AI 变 shell script。 “第一步打开这个文件，第二步找到第三行，第三步改成这个值……” 过度 step-by-step 的 prompt 不仅浪费了模型的推理能力，还把出错的责任从 AI 转移到了你的步骤设计上。你雇了一个能独立思考的同事，却只让他抄你的操作手册。
三、框架的解释力
用四要素模型审视当前 AI 生态，很多困惑迎刃而解。
RAG 为什么容易让人失望？ 因为 RAG 本质上只补了一个要素：上下文。它把相关文档检索出来塞给模型，但目标定义依然模糊（用户的 query 往往一句话）、没有工具（模型不能操作源系统）、没有反馈（一次生成，不迭代）。只补一条腿的方案，天花板注定不高。
Coding Agent 为什么是当前最成功的 AI 应用形态？ 因为四个要素它全占了——
- 目标定义：代码要编译通过、测试通过，这是天然可量化的验收标准
- 上下文：整个 codebase 就是上下文，还有 git history、PR discussion、issue description
- 工具：编辑器、终端、编译器、测试框架——agent 能直接操作
- 反馈：编译错误、测试失败、lint warning，每一个都是即时的、无歧义的反馈信号
Coding Agent 不是"特别聪明”，是这个场景天然适合委托。四个要素齐备，连一个中等水平的模型都能发挥得很好。
为什么很多人觉得 AI “不够聪明”？ 因为典型的使用方式是：打开聊天框，输入一句模糊的话，期待一次性得到完美答案。四个要素全缺。这就像对第一天入职的同事说"你应该知道该干什么"——不是同事不行，是你根本没有完成委托。
四、好同事关系的本质：信息对称下的信任
为什么有些人和同事配合特别默契？两样东西：共享语境和双向信任。
共享语境：你不需要每次都从头解释业务逻辑、技术栈、历史决策。这些是磨合期积累出来的。信任：在信息充分的前提下，你相信对方能做出合理判断，不需要规定每一步。
把这个逻辑映射到 AI：大部分人跟 AI 的关系还停在"入职第一天"的状态。 每次对话从零开始，没有积累，没有磨合，没有信任基础。
这正是 OpenClaw 设计 SOUL.md / USER.md / MEMORY.md 的出发点——不是什么 prompt engineering 的花活，而是在模拟好同事之间的共享语境：
- SOUL.md = 团队的 working agreement——AI 应该怎么工作、什么原则、什么风格
- USER.md = 你和 AI 之间的 1-on-1 notes——你的角色、偏好、关注点
- MEMORY.md = 同事的工作笔记——上次做了什么、踩了什么坑、你给过什么反馈
这三份文档构建的不是"更好的 prompt"，而是信息对称。它们让 AI 从"第一天的新同事"进化到"合作三个月的搭档"。共享语境越厚，委托成本越低，输出质量越高。这跟人际协作的规律完全一致。
五、怎么给 AI “配工位”
如果你认同这个模型，实操就很直接——用给新同事配工位的心态来配置你的 AI 工作环境：
写清楚岗位职责。 不是"你是一个 helpful assistant"，而是"你负责帮我们团队审查 PR，重点关注安全漏洞和性能退化，输出格式按团队 convention"。角色定义越具体，AI 越不需要猜。
把工作资料备齐。 Codebase access、文档库、API 权限、数据库只读账号——你不让同事接触生产环境，他就只能靠想象工作。不给 AI 工具，就别怪它 hallucinate。
建立反馈循环。 别用完就关掉。把 AI 输出的好坏反馈回系统——改 prompt、更新 memory、调整 system instruction。好同事也是磨合出来的，不是第一天就默契的。
给空间，别微管理。 定义清楚目标和约束，让 AI 自己决定路径。过度 step-by-step 既浪费推理能力，也让你变成瓶颈。你请了一个能思考的同事，就让他思考。
AI 行业花了大量精力提升模型能力——更大的参数量、更长的 context window、更强的推理链。这些当然重要。但在落地的最后一公里，瓶颈往往不是 AI 不够强，而是人不会派活。
学会委托，比学会 prompt engineering 更重要。 因为 prompt engineering 是技巧，委托是能力。技巧会被工具封装，能力不会。能把一件事清晰地交给另一个智能体去做——无论对方是人还是 AI——这件事本身就值得认真练。
Note: 本文由作者与 AI 助手通过对话构思完成，是"好同事"模型的一次实践。