从“打工人”到“管理者”，如何驾驭AI而非被其奴役？本文为你揭示AI时代的高效协作思维。
核心内容：
1. 沉迷AI的困境：从过度使用到自我反思
2. 思维转变：从调用技能到驾驭智能体
3. 实践路径：理解设计哲学与重构工作流

最近我发现一个问题, 就是不上班之后, 我的“工作”时间明显比上班期间更长了.

原因是 AI 越来越强, 我几乎沉浸在使用 AI 的过程中无法自拔.

我觉得不能再这样下去, 索性分析了一下我使用 AI 的方式, 似乎是我自己的问题.

简单来说就一句话: 我还没有摆脱“打工者”或者说“优秀打工者”的思维, 我写了一堆的 Skill, 然后我在 Claude CLI 中自己调用这些 Skill 干活.

我还是个“打工者”, 甚至由于 AI 的强悍, 它不停下来, 我就不停下来, 我这个“打工者”的休息时间更少了.

我其实是被 AI 击穿了, 就像双11时, 如果没有队列、没有缓存, 那么高的并发下, 数据库被击穿一样.

那怎么办?

我得转变思维, 转变成老板思维或者管理者思维.

你见过哪个老板会亲自干活的? 没有, 都是吩咐下属, 下属如果也是个管理者, 他会继续吩咐下属.

我得从直接调用 Skill , 转变成调用 Agent , 让 Agent 去调用 subagent 或 Skill 干活.

我需要做的事情是: 定义 AI 给我的最终交付物的“可验证规范”、任务过程中间物料产出及“自验证”、以及在前面提到的约束条件成立的情况下对 AI 的“信任”.

Claude 设计哲学

在纠正我的思维模式之后, 我要先理解 Claude 的设计哲学, 这样才能更好的用好这个工具.

先说我的理解, 然后让 Claude 给我纠偏.

skill: 代表各个专业场景的技能

agent: 代表各专业方向的员工

底层优秀员工思维: 写一堆 skill , 自己用 skill 完成目标

优秀管理者思维: 写一堆 agent , 通过编排 , 驾驭它们干活完成目标

不知道我的理解对不对?

纠偏：skill 和 agent 不是"员工能力 vs 管理者能力"的对立，而是两个正交维度

• Skill = "怎么做"（how） ：一份可复用的操作手册/流程知识，本身不占用独立上下文，只在被触发时把内容注入当前会话。
• Agent/Subagent = "谁来做、在哪个上下文里做"（who / where） ：一个拥有独立上下文窗口、可以独立跑一段任务、只把最终结果返回给主会话的执行体。

所以更准确的类比不是"底层员工 vs 管理者"，而是：

Skill 是知识/SOP 文档，Agent 是执行这份 SOP 的"人"（或者说，一个隔离的执行环境）。

一个 agent 完全可以在执行过程中调用多个 skill；一个 skill 也完全可以不经过任何 agent，直接在主会话里被 Claude 自己读取执行。

真正对应"管理者驾驭多个执行者"这个直觉的，其实是:

• subagent 编排：主 Claude 把任务拆解，分发给多个 subagent 并行执行（各自独立上下文），再汇总结果给人类。

"底层员工自己完成目标"对应的是:

• Claude CLI 主会话直接加载一堆 skill，人类自己顺序执行完。

用 agent 还是 skill? 判断标准：

• 需要独立上下文/并行/隔离（比如长代码审查不想污染主上下文、多路探索互不依赖）→ 用 subagent
• 需要可复用的流程知识，会反复被触发 → 用 skill
• 以上两者都要 → 组合：subagent 内部调用 skill（这是目前公认最强的模式，一个 subagent 加载专属 skill 完成方法论，再通过 MCP 拿数据，返回总结给主会话）

实践建议

我最近写了一些 PostgreSQL SKILL : https://github.com/digoal/skills/tree/main/postgresql

find-postgres-bug、pg-deploy-cluster、pg-runtime-risk、pg-sql-audit、pg-host-resource-risk 等, 本质上都是纯 skill 层 —— 统一 read-only、PGPASSWORD、中文输出、多文件拆分 500 行内。这套是"知识层"做得非常扎实。

如果要往"编排"方向进化，可以考虑的方向：

1. 把重量级、长耗时、需要独立诊断上下文的环节（比如 pg-load-spike-forensics 的九步根因分析、pg-bloat-root-cause 的 MVCC 因果链推导）拆成 subagent 执行，只把结论摘要返回主会话 —— 避免几十个 SQL 查询结果把主上下文撑爆。
2. 用一个"调度型" skill/命令做总入口（比如 pg-health-checkup），根据用户描述的症状，决定要唤起哪几个专项 skill（pg-find-bloat + pg-find-unused-index + pg-parameter-tuning-advisor），这是纯 skill 层面的编排，不需要 subagent 也能做。
3. 真正需要多个"视角"并行独立分析、互不干扰、最后汇总的场景（这个在我的 multi-expert-analyzer SKILL 里其实已经在用了），才是 subagent 并行编排最有价值的地方。

最佳实践清单

Skill 设计实践：

• description 字段是唯一被 Claude 常驻扫描的部分，写清楚"做什么 + 何时用"，这是触发准确率的关键。
• SKILL.md 正文保持精炼 —— 一旦加载，内容会常驻上下文并在后续每轮都计入 token 成本，把"为什么这样设计"这类解释性内容挪到 skill 的附属文件，正文只留"做什么"。
• 复杂技能拆成多文件（主 SKILL.md + examples.md + scripts/），保持主文件聚焦，这也是你现在遵循的模式。
• 明确 disable-model-invocation 还是允许模型自主调用 —— 如果你也因为 SKILL 太多而踩过 skillOverrides 的坑，在 SKILL.md frontmatter 里显式声明比全局配置更可靠。  参考 《Claude , Codex 使用经验总结》
• 一次性、不会复用的任务（比如某次特定的数据库迁移）不要写成 skill，直接内联给指令；只有会反复出现的模式才值得沉淀成 skill。

Subagent/编排设计实践：

• 只在"需要上下文隔离"或"需要并行"时才引入 subagent，否则就是纯粹的调度开销 —— deterministic 的重复工作留在 skill 层用循环处理即可，不要为每次调用都 spawn 一个新 subagent。
• Subagent 之间的研究路径如果彼此不依赖（比如同时排查代码、日志、系统资源三条线索），并行 subagent 收益最大；如果有依赖关系（比如必须先拿到诊断结果才能出优化建议），还是老实串行执行 skill。
• 给 subagent 一个清晰的"只返回结论摘要"的约束，避免污染主上下文。

判断优先级（如果 skill 数量已经远多于 MCP/subagent 数量，说明方向是对的） ：把知识沉淀为 skill 的性价比通常高于为同一件事反复 spawn subagent —— 只有当你确实需要独立上下文或并行时，subagent 才值得付出那份开销。

思维变了, 下面就是设计流程和交付标准

从"优秀员工"切到"管理者"，不会自动让你轻松下来。管理者的累是另一种累 —— 从"亲自执行"变成"设计流程 + 审核结果"。如果编排层设计得不好，你反而会更累：既要盯着每个 subagent 有没有跑偏，又要花心思整合结果，相当于自己又当了一遍总编辑。

真正能让你轻松下来的，不是"用了 agent"这个动作本身，而是下面这几件事有没有做到位：

1. 现在累的根源，大概率是"每次都要自己决定用哪个技能、怎么组合"

比如遇到一个数据库性能问题，你脑子里要过一遍：先跑 pg-runtime-risk，再看要不要 pg-bloat-root-cause，要不要顺手 pg-parameter-tuning-advisor……这个"路由决策"本身就是脑力消耗，而且是每次重新做一遍，没有被沉淀下来。

这部分工作恰恰是可以让 Claude 自己干的 —— 写一个调度层（可以是一个 skill，也可以是一个 subagent），输入是"用户症状描述"，输出是"该调用哪几个专项技能、以什么顺序"。这一步做完，你从"决策者"变成了"提需求的人"，这才是真正的减负，而且它不一定需要 subagent，一个好的调度 skill 就够。

2. 真正该交给 subagent 的，是"你现在需要盯着看 但 其实不需要你盯着"的部分

比如 pg-load-spike-forensics SKILL 那种九步根因分析，你现在如果是自己在主会话里一步步跟着看每条 SQL 结果，那这部分注意力消耗是可以转移的 —— 让它在独立 subagent 里跑完九步，只把"根因是什么、证据链是什么"这个结论抛给你。你不需要看它怎么一步步排查的，只需要看结论对不对。 省的是"过程陪跑"的精力，不是决策的精力 —— 决策该不该采纳这个结论，还得是你。

3. 管理者真正轻松的前提是"信任 + 可验证的输出契约"

如果你对 subagent 返回的结果每次都要从头核实一遍（因为不放心），那你比自己干还累。所以这里的关键投入是：给每个 subagent/skill 定义清楚的执行逻辑、输出格式和自检项（比如你的报告要求"结论 + 证据链 + 置信度"），这样你审核的时候扫一眼结构化的东西就能判断靠不靠谱，而不是重新推导一遍逻辑。这个"契约设计"是一次性投入，换来的是长期的省心。

比如我最喜欢的框架是这样的: 结论/观点、逻辑推演过程、支撑结论/观点的证据链、证据权威性、结论适合的边界、结论成立的前提条件(使用第一性原理拆解)、前提发生变化时的新结论、结论的置信度等.

所以: 我该把'决策路由' 和 '过程陪跑'这两件事外包出去，自己只保留'设计流程', '设计可验证的规范的契约', '定义问题'和'审核结论'这几个动作。

这个转变，subagent 是工具，但真正省力的是你有没有花时间把"调度逻辑"和"输出契约"写清楚、写死。如果只是把原来自己顺序跑的技能改成并行丢给几个 subagent，而你还是每个都要仔细看一遍 —— 那顶多算是把体力活换成了监工活，未必真的轻松。

登录查看剩余 70% 内容