AI 时代,别只学会用工具

生成出来，不等于交付了

现在用 AI 做事，最容易产生一种错觉：东西出来了，事情就差不多了。

一篇稿子有标题、有段落、有观点；一份方案有背景、有目标、有步骤；一段代码能跑一遍，甚至还能解释自己为什么这么写。它们都很像完成品，至少第一眼看上去是这样。

但真正要交出去时，问题才会冒出来。稿子能不能让人愿意读，方案能不能让人照着做，代码能不能过测试，资料有没有出处，流程下次还能不能复用。你很快会发现，生成只是把空白填满，交付要解决的是另一件事：别人能不能接住它。

工具让第一版变便宜了。以前要花半天搭结构，现在几分钟就能得到一个看起来完整的版本。但便宜的第一版也带来新的问题：人会更容易把“看起来像”误认为“已经是”。结构完整不等于可读，逻辑连贯不等于可信，能跑一次不等于能放心用。

很多人现在会用 AI，但卡住的不是怎么打开工具，也不是怎么多写几个提示词，而是怎么把一件事整理到可以交出去，并且交出去以后还能验回来。AI 能参与到什么程度，取决于你有没有把目标、材料、边界、标准和验收方式交代清楚。否则它最多是在帮你把空白填满，真正要交付时，压力还是回到人身上。

只会提问，很快会不够用

早期用 AI，prompt 确实重要。你要告诉它背景是什么，任务是什么，限制是什么，希望它用什么语气，输出什么格式。很多看起来是模型不行的问题，后来发现只是人没有把任务说清楚。

所以那段时间，大家学提示词、学结构化表达、学怎么补上下文，都是合理的。不会说清楚需求，AI 再强也只能猜。

但 prompt 有一个天然问题：它太像一次性沟通。你这次说清楚了，下次还要再说；你今天把背景补齐了，明天换个任务又要重新组织。你靠临场发挥把 AI 带到正确方向，但这套经验没有留下来。

这也是为什么我越来越重视 Skill。Skill 不是把 prompt 写得更长，而是把你反复做过的事情沉淀成一套方法。比如写文章时，怎么判断选题，怎么拆材料，怎么找主线，怎么去掉 AI 味，怎么核查事实；写代码时，怎么读项目，怎么定位 bug，怎么改最小 diff，怎么跑测试，怎么写变更说明。

这些东西如果每次都靠临场解释，就会一直消耗人的注意力。你会觉得自己已经在用 AI，但实际上你还是那个调度员。AI 每动一步，都要你在旁边补一句、盯一下、改一下。

Prompt 解决的是这一次怎么说清楚。Skill 解决的是下次不用从零开始。再往后才是 Agent，它能把多个 Skill 串起来，自己读取上下文、调用工具、执行步骤、检查结果。

这条路线看起来很顺：先把需求说清楚，再把方法沉淀下来，最后让系统组织这些方法去执行。问题是，很多人想从普通 prompt 直接跳到超级 Agent。今天还在问“帮我写一个方案”，明天就希望它自动完成研究、编码、测试、发布、复盘。

中间缺掉的那层东西，就是自己的方法、标准和验收机制。没有这些，Agent 就像一个很聪明的新同事刚入职，但没有员工手册，没有项目背景，没有权限边界。它当然能干活，但干出来的东西会飘。

有时候不是 AI 不够聪明，是你的工作还没有被整理成它可以参与的样子。

Agent 能跑，不代表你能放心

Anthropic 在《Building effective agents》里有一个区分，我觉得很实用：workflow 和 agent 不是一回事。

workflow 更像预设好的流程，任务能被拆成固定步骤，每一步按规则往下走。agent 更开放，它会根据任务动态决定下一步做什么，什么时候调用工具，什么时候继续探索。

听起来 agent 更高级，但开放性越强，越需要边界。它能自己决定下一步，也就可能自己决定错下一步。它能调用工具，也就可能调用不该调用的工具。它能修改文件，也就可能改到不该改的地方。

所以问题不是 Agent 能不能动起来。能动起来已经不稀奇了。麻烦在于，它动起来以后，怎么知道方向对不对，结果能不能验收，失败了能不能恢复。

这就是 harness 要解决的问题。这个词听起来有点技术，翻成人话并不复杂：harness 是一层控制外壳。你不是把 AI 裸放进工作流里，让它随便跑，而是给它目标、上下文、工具、权限、日志、测试、回滚和验收标准。

AI 像发动机，harness 像车架、刹车、仪表盘和安全带。发动机强当然重要，但你不会把一个发动机直接放到路上跑。你需要知道它往哪开，什么时候该停，哪里出了问题，撞到边界时怎么处理。

写文章也是一样。AI 可以先写，但读者愿不愿意读，是验收；观点有没有出处，是验收；段落有没有节奏，是验收；标题和正文是否一致，也是验收。没有这些检查，文章只是生成出来了，并没有真正完成。

代码更明显。能生成一堆文件，不等于能合并；能跑通一次，不等于能维护；能解释得很漂亮，不等于行为符合预期。测试、日志、对账、回滚、人工抽查，这些听起来不如“一个人顶一个团队”刺激，但它们才是 AI 进入真实工作的条件。

没有验证，AI 只是生成；有了验证，AI 才接近交付。

人的位置不是消失，而是上移

Karpathy 在讲 Software 3.0 时，有个说法我很喜欢。他说未来更像是 Iron Man suit，而不是 Iron Man robot。

我理解这句话，不是说我们要幻想一个完全自主的机器人替人做完所有事，而是要做一套半自主的增强系统。人还在里面，但人的位置变了。

以前人负责每一步，查资料、写代码、改 bug、跑测试、整理文档、发结果，很多工作都靠人自己一手推进。现在更高杠杆的方式，是人设计任务环境，定义目标，给出边界，配置工具，建立验证，然后让 AI 在里面跑。

这不是人消失了，是人从低层执行里往上移了一层。你不再只是那个亲自敲每一行代码、亲自看每一份资料的人。你开始变成任务的设计者、系统的管理者、结果的验收者。

以前执行贵，所以会做事的人很值钱。现在执行越来越便宜，会定义事、会放行事、会验收事的人，会变得更值钱。

如果 AI 只帮你写一句文案，你可以逐字看。如果 AI 帮你改一个函数，你可以逐行审。可如果 AI 帮你跑一个两小时任务，改二十个文件，整理五十页材料，生成一组测试和报告，你还想靠逐字逐行盯住它，就会重新变成瓶颈。

这时候需要的不是更勤奋地盯屏幕，而是更好的验收机制：任务要拆到什么粒度，哪些地方可以让它自主，哪些地方必须人工确认，每一步要不要留下记录，怎么做测试、对照、抽查和回滚，跑偏时怎么尽快发现。这些能力过去也重要，只是 AI 把它们放大了。

先分清主干和叶子

这里最容易走偏。一边是工具厂商的叙事：放心交给 AI，一切都会自动完成。另一边是很多有经验的人本能反感：这东西不可靠，重要的事情不能碰。

这两种说法都太粗。更准确的问题不是要不要交给 AI，而是哪一层可以交给 AI。

Anthropic 关于 vibe coding in prod 的分享里，有个很好用的边界：leaf nodes 和 trunk。

leaf nodes 是叶子节点，影响范围相对可控。比如一个小工具、一个独立页面、一个测试补充、一个日志处理器、一个不会被很多地方依赖的边缘功能。这里即使有一点技术债，风险也比较容易关住。

trunk 是主干。比如核心架构、权限系统、数据一致性、调度器、训练 loop、会影响很多模块的基础抽象。这里不能让 AI 自己决定方向，人必须控制。

这个原则放到非代码工作里也成立。文章的资料初筛，可以让 AI 先跑；最终观点不能交给它拍板。用户反馈的分组，可以让 AI 先整理；到底改哪个产品方向，不能让它替你决定。会议纪要可以让 AI 生成；哪些承诺真的要对外说，必须人来确认。

成熟的 AI 使用方式，不是“我全管”，也不是“我不管”，更像是人控制主干，AI 扩展叶子。

这句话看起来简单，但它要求你先知道自己的工作哪里是主干，哪里是叶子。很多人的问题，恰恰是不知道。有人什么都不敢交出去，AI 永远停在问答层。也有人什么都敢让 AI 改，最后系统越来越乱。

会划边界，会变成一项很硬的能力。哪些可以先让它跑，哪些只能让它提建议；哪些结果可以抽查，哪些必须全量核对；哪些错误可恢复，哪些错误一旦发生成本很高；哪些任务看起来复杂，但其实有明确验收，适合 AI；哪些任务看起来简单，但隐性规则太多，反而不适合放手。这个判断，工具不会替你做。

AI 会照出工作流的混乱

我有时觉得，Agent 最残酷的地方，不是它抢谁的工作，而是它会照出很多工作本来就没整理好。

你让它写文章，它总写成模板稿，可能不完全是它不会写，而是你没给它真实经历、判断偏好和读者关系。你让它改代码，它总乱动文件，可能是项目里本来就没有清晰边界。你让它整理资料，它总生成漂亮废话，可能是你没定义什么叫有用。你让它做自动化，它总在最后一步需要你手动补，可能是这个流程本来就没被设计成可以交付，只是靠你脑子里的习惯勉强跑着。

所以很多时候 AI 出问题不只是模型问题。它也在提醒你：这件事还没有被系统化。

文件散着，规则藏着，标准靠感觉，验收靠经验，失败靠人兜底。这样的工作交给人也会出问题，只是人会靠默契和现场感补掉一部分。AI 没有那些默契，就把问题暴露出来了。

过去，一个人厉害，可能体现为他自己很能干，很多隐性知识都在脑子里，别人问他就能处理。以后，一个人厉害，会越来越体现为他能把自己的判断、流程、标准和边界外化出来，让 AI 也能参与其中。

不是把自己变成工具人，而是把自己的工作方式变成系统。

比如你写文章，就不只是“让 AI 帮我写”。你要沉淀选题判断、资料筛选、事实核验、叙事风格、发布前检查。AI 是执行器，但你的风格和标准要在系统里。

比如你写代码，就不只是“让 AI 帮我改”。你要沉淀项目规则、测试门槛、review 标准、危险操作边界、回滚方式。AI 可以跑实现，但系统要能发现它跑偏。

比如你做运营，就不只是“让 AI 帮我总结”。你要沉淀用户分类、反馈权重、业务指标、不能碰的表达红线、哪些结论必须回原文验证。

参考稿里把这个叫个人工程操作系统。听起来像个大词，落到个人身上，就是把那些“我知道但没写下来”的东西，一点点变成 AI 能理解、能调用、能执行、能被检查的工作流。

先改造一个真实任务

所以我现在不太建议一上来就追“万能 Agent”。

万能 Agent 很迷人，但也很容易变成一种逃避。只要你相信未来有个超级系统会替你做完一切，你就不用面对今天自己的任务为什么交不出去。

更实际的做法，是先找一个真实任务，改造它。不要太大，也不要太假。太大，你很难控制风险。太假，它给不了你真实反馈。

你可以从一个旧项目开始，让 AI 先读目录、解释模块、找风险、改一个很小的功能，然后跑测试。你会马上知道它哪里能帮忙，哪里必须停下来。

你也可以从一批资料开始，让 AI 先分类、提炼观点、列出反例、标出出处。不要让它直接成稿，先让它做可验证的前置工作。

你还可以从一个重复流程开始，比如每周都要整理的一份报告、一次客服反馈归类、一个内部数据检查脚本。让 AI 先跑一半，看看最后卡在哪里。

关键不是证明 AI 无所不能，而是观察这件事：如果我要把这项工作交出去，它缺什么？

缺材料，就整理材料。缺规则，就写规则。缺验收，就设计验收。缺边界，就划边界。缺回滚，就补回滚。这样跑几次以后，你得到的不是一个漂亮 demo，而是一套更清楚的工作流。

这套工作流才是资产。模型会换，工具会换，今天流行 prompt，明天流行 agent，后天又会有新的名词。但你对任务的拆解方式、质量标准、验收机制、风险边界，会越积越厚。

AI 最迷人的地方，是它看起来像智能。它会聊天，会写作，会编码，会解释，会总结。很多时候，它一开口就让人觉得这事稳了。但进入真实工作以后，决定结果的不是它看起来多聪明，而是它有没有被放进正确的系统里。

裸模型是能力，prompt 是表达，Skill 是沉淀，Agent 是组织，harness 是控制，个人工作流是你自己的长期资产。

所以今天最值得问的，可能不是“我会不会用某个 AI 工具”，而是这些更具体的问题：我的任务有没有被说清楚，我的经验有没有沉淀下来，我的边界有没有写出来，我的质量标准能不能被检查，我的验证机制能不能让 AI 自己暴露错误，我的工作流能不能在我不逐步盯着的时候，继续往前走一点。

如果这些问题没有答案，会用再多工具，也很容易停在热闹里。如果这些问题开始有答案，一个普通人也会慢慢拥有自己的 AI 生产系统。

别只学会使用工具。学会把事情交出去，验回来，再沉淀下来。