为什么再多 AI 新工具也救不了你？因为缺的是元能力

背景

前几天刷到 Addy Osmani（Google Chrome 那个 Addy）一个演讲，标题叫 The AI-Native Software Engineer，核心一句话：以后的工程师不该再问 “AI 会不会替代我”，而是该问 “这个任务 AI 能不能帮我做得更快、更好、或者用一种我没想到的方式”。

我看完挺有感触的。从 2022 年底最早接触 ChatGPT 开始，这几年我自己折腾 AI 编程，角色换了好几轮：从一开始抠 prompt 当 AI 低声细语者，到后面琢磨上下文工程，再到现在天天盯着 Claude Code、各种 Subagent、Skill、Harness。工具一茬接一茬地换，概念一个接一个地造，刚搞明白 prompt engineering，下一秒 context engineering 就出来了，再下一秒又是 agent，又是 harness，又是 spec-driven development……

刚开始我也焦虑，生怕错过哪个新词就被时代抛下。后面用得多了，慢慢发现一个事实：工具会换，叫法会换，但底下那几条真正起作用的能力，反而很稳定。

这篇就把我自己摸出来的几条”元能力”扒一扒。不聊具体工具用法，聊底子。希望对你有用~

1、先认清 AI 的底牌：它就是个概率预测器

这是第 0 条，也是最容易被忽略的一条。

AI 的底层是 Transformer 架构，核心机制就一个词：概率预测。给定前面的 token，预测下一个 token 最可能是什么。仅此而已。

具体的注意力公式、矩阵运算这些，你不需要懂。但有一个推论你必须刻在脑子里：

哪怕你输入一模一样的提示词，每次得到的输出也不一定是相同的。

这事看起来简单，但很多人在用 AI 的时候根本没把它当回事。

实际意味着什么？

• • 不能假设它”记得”上次说过什么 —— 它根本就没有”记忆”，所谓的记忆都是把历史塞进上下文里再喂一遍
• • 不能假设它每次都对 —— 哪怕昨天跑通了的 prompt，今天可能给你写出 bug
• • 不能假设它的回答是”经过深思熟虑”的 —— 它就是在按概率往下吐字

所以，任何时候用 AI 写出来的东西，都必须有一道人来 review 的关。哪怕这道关是你自己再让一个 AI 来 review。

Addy 在演讲里提到一个数字我印象很深：调研里 66% 的开发者反馈 AI 生成的建议”看着合理但常常不对”，45% 的人说”调试 AI 写的代码比自己写还累”。这不是 AI 的问题，这就是概率预测器的本质 —— 它输出的是”看起来最像答案的东西”，而不是”被验证过的答案”。

知道这一点，你才能心平气和地接受它的不靠谱，并且建立起验证的习惯。

2、摸清它的脾气：长处用满，短处避开

知道它是概率预测器之后，下一步就是搞清楚它有哪些”脾气”。我总结了四条最关键的：

注意力机制

简单说就是：模型读你给它的内容时，注意力是有”权重”的。上下文越乱、越长、越多无关信息，关键信息越容易被稀释、被淹没。

实战推论：上下文不是越多越好。把无关代码、过期日志、半成品文档一股脑塞进去，模型反而抓不到重点。要学会做”上下文减法”，把最相关的东西、关键的几个文件、当前任务的目标，结构化地放进去。

模式泛化

模型对”见过的模式”做得特别好，对”没见过的模式”就开始抽风。

实战推论：写常规 CRUD、写测试、写文档、写脚手架，AI 完全可以飞起来；但是一旦遇到你们公司特殊的业务规则、奇葩的内部框架、十年老代码的隐性约定，它就会按它训练数据里的”通用做法”硬套，然后翻车。

这种时候要么多喂例子（让它”看到”你的模式），要么干脆自己写。

链式推理（CoT）

让模型”一步一步想”，效果比让它直接给答案好得多。

实战推论：复杂任务别让它直接出代码，先让它出”实施计划 / 步骤 / 假设”，你 review 完再让它执行。这就是为啥 spec-driven development 这套打法越来越火 —— 本质就是把”链式推理”显性化、文档化。

我现在写稍微复杂点的功能，基本都是 plan mode → 让它先吐 3-5 个步骤，我看一眼方向对不对，对了再让它写。一上来就让它撸代码，翻车率高得吓人。

幻觉

这是最坑的一条。模型会一本正经地胡说八道，而且还包装得有理有据。

最容易出幻觉的几个地方：

• • 文件路径、目录结构（它经常脑补一个不存在的路径）
• • API 名字、函数签名（你用的库的某个方法它根本不存在）
• • 版本号、配置项（它可能给你一个三年前的写法）
• • 引用的论文、URL（假的可能性极高）

实战推论：包装得越像样的输出越要警惕。涉及到具体路径、API、版本号的，必须自己跑一遍验证。

把这四条吃透之后，你跟 AI 协作的整体姿势就会变 —— 你不会再期待它”啥都能干”，而是会主动给它派合适的活、避开它的雷区。这就是 Addy 说的：AI 不是来替代专家的，AI 是个放大器。你越懂行，AI 在你手里效果越炸；你越是甩手掌柜，它给你写的代码越是垃圾。

3、把最好的子弹打出最高的产出

很多人以为 AI 编程就是”开个 ChatGPT 写写代码”。实际上模型选型本身就是一门很重要的功课。

我自己常用的就三家：Claude、GPT、Gemini。每家都有自己的强项：

关键不是”追最新”，是”配组合”。

我现在的工作流大概是：

• • 重要任务、生产代码 → 用最贵最强的（Claude Opus / GPT 顶配）
• • 大批量、自动化跑的活 → 用 Flash / Haiku 这种便宜小模型，跑 100 次成本也不疼
• • 评估和 review → 用另一个独立模型来 cross-check，避免同一个模型既当运动员又当裁判

成本和产出的平衡，永远是落地的核心。不是越贵越好，是任务匹配模型才好。一个简单的格式整理你上 Opus，那真的是在烧钱~~

顺带说一句，别过度迷信 benchmark。模型在 benchmark 上的得分和你实际用起来的体感经常差很远。最靠谱的方法还是用自己的真实任务亲自试一遍。

4、跟着角色进化，但别陷在工具里

回头看这几年，我自己的角色其实换了好几次：

prompt engineer  ↓context engineer  ↓agent 编排者  ↓harness 使用者  ↓（下一个？）

早期玩 prompt engineer，天天琢磨”用啥句式效果好””加不加 think step by step””要不要给角色设定”。这个阶段产出确实有提升，但天花板很低，因为再花哨的 prompt，也救不回来上下文里缺的关键信息。

然后是 context engineer。这个词其实是后面才有的，但本质就是：”与其纠结一句话怎么写，不如把模型需要知道的所有东西（相关文件、历史决策、约束、例子、工具）系统地准备好”。Addy 演讲里也提到了，他直接说 “Context is king”。我自己感受最深的是：输出质量基本和上下文质量成正比。你给得多、给得对、给得结构化，它就能产出像样的东西。

再后来是 agent 时代。这时候不再是”我跟 AI 对话一个回合得到一个结果”，而是”我描述一个目标，agent 自己规划、自己调工具、自己迭代、自己验证”。Cursor 的 background agent、Claude Code、Jules、各种 IDE 里的 agent 模式都是这个路子。Addy 说工程师正在从 implementer 变成 orchestrator —— 我们在指挥一支 agent 队伍，而不是亲自写每一行代码。

现在又到了 harness 时代。Harness 简单理解就是”给 agent 套一层壳”：定义它的 working loop、工具集、记忆策略、审批节点、回滚机制。Claude Code 本身就是个 harness，Cursor 也是，OpenAI 的 Agent SDK 也是。开发者从写代码的，变成了搭这套壳的。

但你看出来没有 —— 这五个阶段里，工具一直在变，但底层那个东西没变：

想清楚要解决什么 → 把所需信息和约束准备好 → 选合适的执行方式 → 验证并迭代。

这个循环，prompt engineer 在做，context engineer 在做，agent 编排者在做，harness 使用者也在做。只是抽象层级在不断往上抬。

所以我的建议是：别被新词新工具搞焦虑。每出一个新概念你都焦虑一遍，会被各种 PPT 和公众号文章生生折磨死。把底层那个循环吃透，新工具来了你两三天就能上手。

5、Always exploring，但要扎根业务

这一条是给自己提醒的，也是给所有”沉迷玩 AI 玩具”的同行提的。

AI 这一年发展确实快，每周都有新东西出来。保持好奇、保持探索是必须的 —— 不学就掉队，这点没啥可争辩的。

但是！只玩 demo 项目、只在 GitHub 上看新仓库、只在推特上看大佬秀图，这种探索是有水分的。真正的能力提升来自把它落到你的实际工作里。

Addy 演讲里有一段我特别赞同，他叫**”70% 问题”**：

AI 能帮你做到 70%，但是最后 30% —— 也就是真正进生产、能让你不在 Hacker News 头条挂着的那 30% —— 是最难的。

新手会觉得 70% 已经很神奇了，但有经验的工程师会知道：那最后 30%，往往比从零开始写还慢。Edge case、性能、异常处理、和老系统的集成、安全性、可观测性、回滚预案……这些东西 AI 给你的版本里大概率是欠缺的。

落到实际工作上有几个原则我会一直坚持：

第一，提效要看真实业务结果

不是看你今天用 AI 写了多少行代码、提了多少个 PR。这些都是过程指标。真正要看的是：业务有没有更快上线？事故有没有更少？用户体验有没有变好？团队产能有没有真的提升？

我见过一些团队 AI 用得很猛，PR 数量暴涨 100%，但 review 时间也暴涨 90%（Addy 演讲里也提到了这个数据），生产事故还多了几起，结果一算总账，提效是负的。这种”假提效”要警惕。

第二，最后那 30% 必须自己上

prototype、脚手架、CRUD、单元测试、文档、commit message —— 这些 AI 写得很好，放心交给它。

但是架构决策、关键路径的代码 review、生产配置、安全相关的逻辑、和业务核心绑死的地方 —— 这些必须自己上手，自己思考，自己验证。你才是那个为生产环境负责的人，AI 不会被叫起来上线，被叫起来上线的是你。

第三，定期做”无 AI 训练”

Addy 提了一个我特别认同的做法：no-AI challenges。固定一段时间或某种类型的任务，强制不用 AI，自己写。

为啥要这么干？因为长期依赖 AI，你的”基本功”会悄悄退化 —— 看代码的速度、徒手 debug 的能力、设计算法的肌肉记忆。这些东西在 AI 失灵的时候（模型升级出 bug、API 挂了、敏感场景不能用）会救命。

我自己现在大概一周会留半天到一天，做一些刻意不开 AI 的练习。不是反 AI，是保持手感。就像写字一直用电脑，突然让你手写一个字，你会发现连”凉”字怎么写都得想一下。

总结

写到这里其实就两段话能讲完：

工具会一直变，元能力不会变：

1. 1. 知道 AI 是概率预测器 —— 不迷信，必须验证
2. 2. 摸清它的脾气 —— 长处用满，短处避开（注意力、模式、CoT、幻觉）
3. 3. 模型组合用 —— 任务匹配模型，不追新只追性价比
4. 4. 角色跟着进化 —— prompt → context → agent → harness，底层循环不变
5. 5. Always exploring，但落地业务 —— 别被 70% 的”看起来不错”骗了

心态上记住一句话：AI 不是来取代你的，AI 是个放大器。

你越是真懂业务、真会工程、真能思考，AI 在你手里就越是个核武器。你越是甩手掌柜、不思考、不验证，AI 在你手里就越是个翻车机器。

所以最重要的元能力，可能根本不是”会用 AI”，而是 —— 你自己得是一个好工程师。AI 只能放大你已有的能力，放大不出你没有的能力。

这几年我能感受最深的就是这一点。共勉~~

加入AI技术交流群，可以先关注本公众号，然后在后台回复「交流」，获取入群方式。

感谢你看到这里，如果觉得有帮助，转发,点个赞或在看，就是对我最大的鼓励。也欢迎留言交流你的想法~