最近因为折腾 AI，陆续买了好几台云服务器——有国内的，有海外的，不同供应商、不同系统版本。每台机器到手之后，流程都一样：SSH 进去，装基础工具链（git、zsh、oh-my-zsh、fzf），装 Node.js 和 Claude Code，配环境变量（API Key、代理设置），调 shell 配置，装 Tailscale 组网……第一台的时候还挺有新鲜感，到第三台就开始烦了。

纯粹的重复劳动，没有任何技术含量，但一步都不能少。手动配一台服务器，快的话二十分钟，慢的话半个小时以上——中间还总得查一下"那个环境变量叫什么来着"。

然后某个瞬间，我反应过来——我为什么要自己做这件事？

我直接把新服务器的 IP 和密码告诉 Claude Code，再给它一台已经配好的服务器作为参考，一句话：“SSH 到这台参考机器看看装了什么、环境变量怎么配的，然后照着在新服务器上复现。”

它自己 SSH 过去，cat /etc/os-release 看系统版本，读 .zshrc 和 .bashrc 扒环境变量，查 which 看装了哪些工具，然后切到新服务器上，按顺序装好一切。中间碰到系统版本不同导致包管理器不一样（Ubuntu 用 apt，CentOS 用 yum），它自己做了适配，我压根没提过这个问题。

几分钟之后，环境配好了。我 SSH 上去抽查了一下，该有的都有，环境变量一个不差。

这件事本身不大，但它让我意识到一个问题：我的默认思维模式是错的。

以前觉得"配服务器"就等于"我 SSH 进去敲命令"，这两件事在脑子里是绑定的。但我的目标只是"让这台机器变成可用状态"，至于谁来登录、谁来执行那些命令——无所谓。目标和手段之间有一层解耦，一旦意识到这一点，很多以前觉得"只能亲自做"的事情，突然就变成了可委派的。

什么是 Agent First

过去几年，我用 AI 工具的频率越来越高。从最早拿 ChatGPT 问问题，到后来用 Cursor 写代码，再到现在 Claude Code 几乎成了我的主力 Agent。但回头看，很长一段时间里，我的思维一直停留在一个阶段——“工具辅助”。

什么叫工具辅助？就是我是主角，AI 是配角。我想好做什么，我决定怎么做，AI 负责帮我加速执行。写代码的时候让它补全，遇到 bug 的时候让它分析，写文档的时候让它润色。核心决策和执行路径都在我手里，AI 只是提速的工具。

这没什么问题，但它有一个隐含的假设：执行者是我。

Agent First 是一个反过来的思路：做任何事之前，先问一句——这件事能让 Agent 来做吗？

这个问题的答案会引出三条路：

第一，能做，那就直接委派。你当调度者，它当执行者。

第二，现在不能做，但可以建设这个能力。花点时间把它沉淀成一个可复用的 skill 或 workflow，下次就能做了。

第三，确实只能自己干。这才是你亲自上手的时候。

关键在于顺序。大多数人（包括之前的我）碰到一件事的默认反应是第三条——撸起袖子自己上。Agent First 的意思是把这个顺序倒过来，“自己干"变成最后的选项，而不是第一反应。

用一个表格来对比一下这两种思维模式：

一句话变成一个自主循环

这种思维转变在日常开发中体现得很明显。

写完一段代码之后，我以前的习惯是：自己跑一遍 git diff，逐文件看改了什么，发现问题——比如变量命名不一致、错误处理遗漏、某个边界条件没覆盖——然后手动改，改完再 diff 一遍确认，没问题了提交。这个循环完全是手动的，每一步都需要我盯着屏幕，脑子里同时装着"改了什么"和"还有什么没改好"两件事。

现在我会直接跟 CC 说一句：

“review 一下当前 git 改动，有问题就直接修，修完继续 review，循环到你觉得可以提交为止。”

一句话，它自己就跑起来了。先 git diff 看所有改动，然后逐文件分析：命名是否一致、逻辑是否完整、有没有遗漏的错误处理。发现问题直接改——不是告诉我"这里有问题"然后等指示，而是自己判断怎么改、改完继续检查。整个过程形成了一个自主闭环：

读 diff → 分析问题 → 修复 → 重新 diff → 检查修复是否引入新问题 → 确认没问题 → 报告结果

我干嘛去了？倒了杯咖啡，回来看到它告诉我"改了三处，现在可以提交了"，附带改动摘要。我扫一眼摘要，确认合理，提交。以前要二十分钟的人肉循环，现在两分钟搞定。

这不是什么高深的技巧。技术上零门槛，任何人都能做到。但它需要你脑子里先转过一个弯：这件事我是不是可以不亲自做？

大多数人写完代码之后的第一反应是"我来看一遍"，而不是"让 Agent 来看一遍"。差别就在这个默认反应上。

飞轮

Agent First 真正的价值在于长期的复利效应，远超单次提效。

最初用 Claude Code 的时候，能委派给它的事情比较有限——写代码、改 bug、做 code review，基本就这些。但随着使用的深入，我开始把一些"非代码"的工作也往它身上放。

第一个转折点是飞书文档。我写技术分享经常需要在飞书上发文档，以前的流程是：本地写好 Markdown → 复制粘贴到飞书 → 手动调格式（因为飞书对 Markdown 的支持有各种限制）→ 表格重新排版 → Mermaid 图表手动截图再贴进去。一篇长文档折腾下来，排版花的时间比写作还长。

后来我花了大概两天时间，把飞书的 Open API 调通，写了一套导入脚本，处理了 Mermaid 图表自动渲染、大表格自动拆分、Callout 格式适配这些边角情况，然后封装成了一个 CC 的 skill。从那以后，“把这篇 Markdown 导入飞书"变成了一句话的事——格式完美，图表自动渲染，表格不会乱。

然后是图床上传。写博客需要插图，以前要手动打开图床网站、选文件、上传、复制链接、粘贴回 Markdown。一张图还好，一篇文章十几张图就很烦。现在这也是一个 skill，一句话上传，直接返回 Markdown 格式的链接。

再然后是封面图生成。以前找封面图要去各种素材网站翻半天，费时间还不一定找得到合适的。现在接了 AI 生图的 API，描述一下想要什么风格，几秒钟出图。

从单点到链路

这些 skill 单独看，每个都只是节省了一点点时间。但组合在一起的时候，事情就不一样了。我现在写完一篇文章，后续流程是这样的：

一句话生成封面图 → 一句话上传图床 → 一句话保存文章 → 一句话导入飞书 → 一句话发消息通知

整条链路全自动。以前从写完正文到发布完成需要半小时到一小时的手动操作，现在五分钟搞定，中间不需要我做任何决策——每一步该怎么做，skill 里都定义好了。

不用往远了说，这篇文章本身就是一个例子。你现在看到的封面图，是我跟 CC 说"生成一张哆啦 A 梦风格的封面”，它调用图片生成 skill 出图，再调用图床上传 skill 拿到链接，直接填进文章的 frontmatter 里。从描述需求到封面就位，一分钟不到。如果没有这些 skill 的积累，光找图、P 图、上传这一套流程就得折腾二十分钟。

而且这些能力组合在一起之后，会产生一些原本不存在的新可能。

举个例子，以前我从来不写"转载翻译"类的文章——看到一篇好的英文文章，想翻译成中英双语对照发到自己博客上，工作量太大了。要逐段翻译、排版、处理图片、上传……一篇五千字的文章搞下来半天就没了。但现在，“翻译 + 排版 + 图片处理 + 图床上传 + 生成封面 + 发布"这整条链路都是自动的。结果就是，我的博客上多了好几篇以前根本不会去做的翻译文章。不是我突然变勤快了，是执行成本降到了低于我的行动阈值。

这就是飞轮效应。每建设一个 skill，你的能力池就大一点；能力池越大，能组合出来的 workflow 就越多；workflow 越多，你能以低成本做到的事情就越多。

搭第一次确实要花时间。飞书导入那个 skill 我折腾了两天，中间调 API 调到想摔键盘。但这两天的投入换来了之后每周好几次的零成本使用，累计回报率高得吓人。

而且一旦这种思维方式形成习惯，你会发现自己在日常工作中不断发现可以沉淀的点。每次手动做一件重复的事情，脑子里自动冒出一个声音：“这个能不能做成 skill？“能就建，不能就先标记着，等以后工具能力够了再说。长期来看，你手里能调度的能力是滚雪球式增长的。

很多以前"不值得做"的事——比如每篇博客都配一张精心生成的封面图、每次技术分享都同步生成飞书文档——现在变成了一句话的事。这些事本身没变简单，但执行成本降到了接近零。

Anthropic 内部有个策略叫 Dogfooding——全员用自己的 Claude 干活，遇到 Agent 搞不定的问题，直接把它定义成下个版本的 Benchmark。每一个真实场景里的翻车，都变成了模型进化的训练目标。这大概是他们的模型能做得那么深的一个原因——全靠自己天天踩坑踩出来的。

国内的 MiniMax 也在推类似的东西，他们叫 Agent Native，全员包括法务、HR 都要求优先用 Agent 工作，用 Agent 做 GPU 算子优化，甚至合同审核和招聘流程也在往 Agent 上迁。逻辑都一样：内部真实使用产生的反馈，能覆盖到任何 Benchmark 测不到的边缘场景。

Agent First 已经超越了个人效率偏好，它是一种正在成型的工作范式。你不需要等到 Agent 什么都能干才开始用——现在就用，用的过程中遇到的每一个坎，可能下个月就被模型更新解决了。

翻车是进化的燃料

说了这么多好处，但事情肯定不是一帆风顺的。

Agent 再强，它也不知道你的项目有哪些暗规则、哪些约定俗成的潜规则。它不知道那行被注释掉的代码是故意留着的，不知道某个看起来多余的配置是给另一个环境用的，不知道团队内部约定的某些命名习惯。这些上下文从来没有写在任何文档里，全靠你脑子里装着。

所以 Agent 会产生幻觉，会自作主张，会在你没预料到的地方搞出问题。这很正常——它看到的信息和你看到的信息不对称，它只能基于它拿到的上下文做判断，而你脑子里那些没说出口的东西，它无从得知。

但冷静下来想想，手动操作就不犯错吗？我自己手动改代码的时候也翻过不少车。差别在于：Agent 翻车之后，你可以把教训固化成规则；你自己翻车之后，只能靠"下次注意”——但下次大概率还是会忘。

每次出了问题，我做的第一件事是想：它为什么会犯这个错？是上下文给少了，还是约束没写清楚？然后把缺失的信息补到规则文件或 skill 里。这些规则会被 Agent 每次执行任务时读取，写一次，永久生效。

你要当掌舵人，持续优化和思考。 每次翻车都是一个信号，告诉你现有的流程哪里有缺口。你把这个缺口补上，下次同类任务自动规避。时间一长，你手里就不只是一堆零散的工具，而是一套经过实战打磨的方法论——哪些任务该怎么委派、边界在哪、什么情况需要人工介入，全都编码在你的 Agent 配置里了。

翻车次数越多，这套方法论就越成熟，犯错率反而越来越低。翻车不是不委派的理由——每一次翻车都在喂养你的系统，让它变得更强。

为什么这个弯不好转

说起来容易做起来难。Agent First 最大的阻力来自心理层面，跟技术无关。

惯性是第一面墙。写了这么多年代码，“打开编辑器自己改"已经是肌肉记忆了。碰到一个 bug，手指比脑子反应快——还没想清楚要不要委派，手已经开始改了。我经常是改到一半才意识到，“这个事情其实可以让 CC 来做的”，但已经改了一半了，算了，干完吧。下次再说。

然后是控制欲。说白了，很多程序员（包括我自己）享受亲手解决问题的成就感。定位到一个隐蔽的 bug，那种"找到你了"的快感是真实的。让 Agent 干完了，结果虽然一样，但你没经历那个寻找和发现的过程，总觉得少了点什么。这种感觉很微妙，它会让你在潜意识里抵触委派。

还有一层是信任。你不确定 Agent 能不能做对。以前自己亲手改的代码，出了问题我知道去哪找原因。交给 Agent 之后，万一改出了新 bug 怎么办？代码读着不顺眼怎么办？风格不统一怎么办？这些担心都是合理的。但解决方案是建立验证机制——让 Agent 做完之后你检查结果，跑测试，看 diff。调度者该做的事只有一件：审查结果。

我自己花了大概两三个月才真正转过这个弯。没有什么一夜之间的顿悟，就是一次次小事情的积累。每次手动做了某件事之后，事后反应过来"这个完全可以交给 CC 做的”，下次就记住了。慢慢地，默认反应从"我来"变成了"它来”。

而且这个转变是有正反馈的。一旦你开始习惯性地委派，你会发现自己多出来的时间和精力，可以花在更需要人类判断力的事情上——架构决策、需求分析、优先级排序、跟人沟通。这些事没法委派，也不应该委派。但以前你的时间被大量执行层面的琐事占满了，根本没空认真想这些。

话说回来，这套思路是不是适用于所有类型的工作，我没完全想清楚。写代码、配环境、处理文档，这些偏流程化的任务委派效果确实好。但对于那些需要从零开始构思、需要大量模糊决策的工作——比如想清楚一个产品该往哪个方向走——Agent 能帮多少忙，我还在摸索。

几个容易被忽略的前提

聊了这么多 Agent First 的好处，但有几个前提不说清楚，整套逻辑就是空中楼阁。

第一，永远用最新最好的模型和工具。

这一点听起来像废话，但实际操作中大量的人卡在这里。最近跟同事聊，他说 AI 生成的代码不靠谱、理解不了复杂需求，一问用的还是几个月前的模型，工具也停留在网页聊天框。

很多人没意识到，AI 已经从 Chat 阶段过渡到了 Agent 阶段。Chat 阶段是什么样？你在网页对话框里输入问题，AI 回你一段文字，你复制粘贴到编辑器里，手动改改再用。本质上它是一个高级搜索引擎，你问它答，执行还是靠你自己。

Agent 阶段完全不一样了。Claude Code、Codex CLI 这类工具让 AI 直接操作你的开发环境——自己读代码、改代码、跑测试、操作文件系统、调用 API。你不需要复制粘贴任何东西，你只需要说清楚要做什么，它自己去干。从"你问它答"变成了"你说它干”，这是交互范式的根本转变。

模型能力也在同步跃迁。Claude Opus 4.6、GPT-5.3 这些新一代跟半年前完全不是一个量级。上一代搞不定的任务，新一代可能轻松解决；上一代需要你精心构造 prompt 才能勉强完成的事，新一代一句大白话就行。如果你还停在 Chat 阶段的认知里，拿着旧模型、旧工具得出"AI 不行"的结论，然后因此拒绝 Agent First——这个推理链条从第一步就错了。

所以，要舍得为 AI 付费，模型订阅和工具订阅都是。从投资回报率的角度看，这可能是当下性价比最高的个人投资——用最少的钱，撬动最大的生产力杠杆。一个月几百美元的订阅费，换来的是一个能力不断增长的执行者。你在别的地方省出来的时间和精力，价值远超这个成本。

第二，Agent 的上限是你。

AI 是认知的杠杆。杠杆能放大力量，但它放大的是你已有的力量。

你懂架构设计，Agent 能帮你把设计落地得更快更完整。你懂性能优化，Agent 能帮你跑 benchmark、分析瓶颈、实施优化方案。你懂业务逻辑，Agent 能帮你把逻辑翻译成代码。它放大的是你的认知，让你快速获得"完成事情"的能力。

但反过来，对于你完全不懂的领域，Agent 对你而言约等于零。不是说它不会做——它可能做得出来——而是你没有能力判断它做得对不对。你不知道该问什么问题，不知道怎么验证结果，不知道哪些地方可能埋坑。调度者最核心的能力在于判断。而判断力来自你自己的认知积累。

所以 Agent First 不是"什么都交给 AI"。它是一种分工策略：你负责方向、判断和决策，Agent 负责执行和加速。 你的认知越深，能委派的范围越大，杠杆效应越强。反过来，如果你自己没有足够的判断力，委派得越多，翻车的概率越高，而且你还发现不了翻车了。

第三，输出质量取决于你给的输入。

这一点很多人没意识到。大部分人用 AI 的方式是这样的：打开对话框，输入"帮我生成一个 PPT"，然后等结果。

你站在 AI 的角度想想——什么 PPT？给谁看的？什么主题？多少页？什么风格？要不要配图？图从哪来？模板用公司的还是通用的？在哪个软件里做？这些问题你一个都没说，AI 只能猜。猜对了算运气好，猜错了你就觉得"AI 不行"。

不是 AI 不行，是你给的上下文太少了。Agent 的输出是你输入的函数——输入越丰富、越精确，输出就越靠谱。一句"帮我生成 PPT"和一段"用公司模板，给技术总监看的架构评审材料，重点讲微服务拆分方案，15 页以内，每页配架构图"，出来的东西完全是两个水平。

回头看开头配服务器那个例子，我看起来只说了一句话，但"参考机器"本身就是最完整的上下文——所有该装的工具、该配的环境变量，都在那台机器上摆着，不需要我一条条列出来。上下文不一定是你打出来的文字，也可以是你指向的一个已有系统。

这也是为什么前面花了那么大篇幅讲 skill 和飞轮。当你把一个流程沉淀成 skill 的时候，你本质上是在做一件事：把上下文固化下来。你不需要每次都告诉 AI “用哪个图床、格式是什么、上传完链接怎么拼”——这些信息在 skill 里已经写死了。你只需要说一句"上传这张图"，剩下的上下文 skill 自动补齐。

打磨 Agent 工作流的核心就一句话：不断把可复用的上下文沉淀成 skill，让每次委派都自带充足的背景信息。一开始可能要手动补很多上下文，但随着 skill 越建越多，你需要手动说的越来越少，Agent 自己能拿到的信息越来越多。飞轮一旦转起来，回报是指数级的——因为你喂给它的输入质量在持续提升，哪怕 AI 能力没变化，效果也在变好。

这几个前提合在一起，指向同一个结论：在 Agent First 的框架里，对自己的投资和对工具的投资同样重要。 持续学习让你的判断力更强，持续升级让你的执行层更强，持续沉淀让你的输入质量更高。飞轮才转得起来。

核心不是工具有多强。是你愿不愿意把"执行者"的位置让出来——同时持续让自己配得上"调度者"这个角色。

最后修改于 2026-02-27