AI Engineering on 鬼哥的空间

持续学习 - 读吴恩达老师的 AI Engineering Skills Map

Sun, 16 Aug 2026 00:00:00 +0000

Andrew Ng 最近发布了 The AI Engineering Skills Map。

我原以为，它大概又会列出一串要学的新名词：模型、Agent、RAG、MCP、评估……毕竟这两年 AI 圈最不缺的，就是下一批必须学会的工具。

但读完后，真正让我停下来的不是某个工具，而是其中一项能力：Shaping the build。

当 AI 越来越擅长“按规格把东西做出来”，工程师更重要的工作，反而变成了决定：究竟什么值得被做出来。

我们太擅长围观模型，太少真正走进现场

这两年，AI 圈最不缺的，是围绕模型的热闹。

又一家机构发布了新模型，参数多大，跑分涨了多少，在哪个 benchmark 超过了谁。我们很容易花半天时间讨论它的能力边界，仿佛坐在路边摊上，也能把国际局势分析得头头是道。

信息当然重要。模型进步也确实会改变工程方案。我自己也在关注、在试用、在学习各种 AI Coding 工具、harness 和 Skill。

但读完 Andrew 的文章，我开始反问：这些信息最后有多少变成了我真正做过的东西？我有没有拿一个真实问题去试过、撞过墙、做过评估、承担过一次“它答错了怎么办”的后果？

鬼哥一直有个很朴素的判断：

上过一天战场的普通士兵，强过训练过一年、却从未见过敌人眼中杀气的特种部队。

放到 AI 开发上，这不是鼓吹粗糙上线，而是说：一次真实实践里遇到的脏数据、用户误解、预算约束、模型幻觉和责任边界，比十篇模型评测更能逼着人长出工程判断。

一句“做个 AI 客服”，其实还没有开始定义问题

假设有人对你说：

“我们做一个 AI 客服，提高客服效率吧。”

这句话看起来已经足够清楚。于是很自然的下一步是：选一个模型，接知识库，做一个聊天窗口，必要时再加个 RAG 和转人工按钮。

这些都没错。但这其实是把一个尚未被理解的问题，过早翻译成了一个技术方案。

更值得先问的是：

“效率”到底是谁的效率？是用户更快得到答案，还是客服少处理一些重复问题？
用户来找客服时，真的只需要一个事实答案吗？还是需要确认、安抚、解释，甚至需要一个愿意负责的人？
如果它答错了一次，错的是退款金额、物流状态，还是医疗、金融、账户安全这类高风险问题？
哪些问题可以自动处理，哪些必须立刻转给人？

这些问题会直接改变知识库怎么建、工具权限开多大、评估集怎么选、何时升级人工、界面如何表达不确定性，以及为了可靠性愿意付出多少成本。

所谓“理解用户”“理解人性”，不是产品课上的漂亮话。它会一行一行地进入你的系统设计。

Andrew 的四项能力，恰好解释了差别从哪里开始

Andrew 的团队基于 10,000 多条招聘信息、专家与招聘方访谈、问卷及其他在线数据，归纳出四项最重要的 AI Engineering 能力。对我来说，它们不是一张“待学名词表”，而是一张让那句 AI 客服需求显影的地图。

1. 构建与部署 AI 应用：把“不确定”当作系统属性

传统软件大多是确定性的：同样的输入，通常得到同样的输出。AI 应用不是。你给 LLM 一段上下文，不会完全知道它下一次会怎么回答；你训练一个模型，也无法保证它面对新样本时的判断。

所以 AI 客服的关键从来不是“它能不能回答”，而是：它会怎样答错，我们如何发现、衡量并纠正它。

这就是为什么 Andrew 特别强调 disciplined evals 和 error analysis loops。没有评估和错误分析，所谓优化常常只是换一个 Prompt、换一个模型，然后凭感觉说“似乎好一些”。

2. 软件工程基础：AI 不会替你做取舍

一个客服系统不仅有模型，还有并发、延迟、缓存、数据权限、审计、成本、可用性和隐私。

如果客户上传的订单截图被送进第三方模型，数据如何处理？如果一个工具调用错了退款接口，如何避免不可逆操作？如果高峰期响应慢了 3 秒，用户会等待还是转人工？

这些没有标准答案，只有取舍。工程基础的价值，不是让人比 Agent 多写几行代码，而是让人看见 Agent 看不见、也不会主动替你承担的代价。

3. 使用 Coding Agent：不是让它替你思考，而是让它进入闭环

Coding Agent 能很快搭出客服界面、接好 API、补齐测试的表面结构。它也可能在没有足够上下文时，做出一个看起来合理、实则危险的默认选择。

会用 Agent，远不止会写一段 Prompt。它意味着你知道该给什么上下文，什么时候先规划，什么时候直接执行；更意味着你能给它清晰的 verifier：哪些回答算正确，哪些调用绝不能发生，哪些失败必须自动暴露。

Agent 是执行的杠杆。没有规格、边界和验证，它放大的往往只是含糊。

4. Shaping the build：最难的工作在代码之前

前三项能力让系统能被可靠地做出来；第四项追问的是：它该不该这样被做出来？

当 Agent 越来越擅长交付一份明确的 spec，工程师的价值正从“把 spec 写成代码”，逐渐前移到“参与决定 spec 应该写什么”。

回到 AI 客服：也许真正的问题不是客服打字太慢，而是退款规则本身让用户反复追问；也许用户要的不是一个更会说话的机器人，而是一个能告诉他“这件事已经由谁、在什么时候处理”的确定性。

如果没有走到用户面前，没有理解业务目标和人的感受，再强的模型也只会把错误的问题实现得更快。

持续学习，不是追完每一条模型新闻

Andrew 在最后还提到了一项贯穿所有能力的底层心态：Continuous Learning。

这句话看起来最不“技术”，却可能是最难的一项。

因为 AI 变化太快了。模型在变，Coding Agent 的能力边界在变，工具的最佳实践也在变。两个月前还需要手工拆解的步骤，今天可能已经可以交给 Agent；今天看起来可靠的工作流，下一次模型升级后又可能需要重新设计。

所以，持续学习当然包括关注新模型、试用新工具、阅读好文章。但如果它只停在这些地方，我们又会回到开头那种“围观模型”的热闹里。

我更愿意把它理解成一种把真实反馈不断写回自己脑中的能力：

用一个真实问题做出最小可用的尝试；
看它在真实用户、真实数据和真实约束下怎样失败；
分析失败到底来自模型、上下文、流程、工程设计，还是自己一开始就理解错了需求；
把得到的判断更新进下一次的规格、提示、评估和系统边界；
再去尝试新的模型和工具，而不是把“新”本身当成收获。

这才是一种会越用越强的学习循环。

比如 AI 客服上线后，发现用户不断追问“我的退款到底什么时候到账”。这未必说明模型不够聪明。它也许暴露的是：系统没有接到订单状态、退款流程对用户不透明、客服话术没有说清责任人，或者我们一开始就把“效率”误解成了“少回复几句”。

一次这样的失败，往往比知道某个新模型多了几个 benchmark 分数更有价值。前者会改变你下一次怎么理解问题；后者未必会。

持续学习因此不是把知识库存得越来越满，而是让自己的判断在一次次真实交付中变得更准。它让工具进步不只发生在屏幕上，也发生在使用工具的人身上。

AI 提高了效率，但没有取消人的认知边界

这也是我从这张技能地图里读到的、更私人一点的理解。

AI 确实让我们以前所未有的速度做出页面、功能、原型，甚至一个像模像样的产品。它降低了表达想法的成本，也放大了动手实践的机会。

但它没有自动给我们产品判断，没有自动补齐软件工程的基本功，也不会替我们理解需求背后那个焦虑、愤怒、着急或无助的人。

你给 AI 的不只是 Prompt。你给它的还有：你对用户的理解、你识别风险的能力、你知道哪些地方该慢下来、以及你愿意对什么结果负责。

当然，反过来也成立：你没有看见的约束、没有问出的需求、没有验证的假设，也都会被它更快地编码进产品。

你是什么，你的 AI 就是什么。

每次让 AI 开工前，先问自己五个问题

如果这篇文章只留下一件可以立刻执行的事，我希望是下面这五问：

用户说出的需求，背后真正想解决的是什么？
AI 答错或做错一次，谁承担什么后果？
我用什么真实样本和标准，判断它真的有用？
哪些决策可以交给 AI，哪些必须由人负责？
我现在给 AI 的上下文，是否已经暴露了自己的认知盲区？

AI Coding 最好的时代，或许不是每个人都能更快地生成代码的时代。

而是每个愿意走进真实问题、持续校准自己判断的人，都能把自己的能力更大规模地交付给世界的时代。

参考资料

Andrew Ng, The AI Engineering Skills Map

别让 Fable/Opus 干杂活：Agent 系统的省钱架构

Thu, 09 Jul 2026 00:00:00 +0000

你开发 Agent 的时候，是不是也干过这种事：

不管任务大还是小，先把 Fable/Opus 请出来，一路从查网页、搬数据、整理表格，撸到最后写报告。

鬼哥以前也经常这么干。刚开始是图省事，也确实希望结果尽量好。至于更深层的原因，大概是经验不足，手艺还菜，这句不要外传。

直到后来看到 API 账单，整个人就清醒了。

开法拉利去跑货拉拉，当然快。但快归快，油钱是真的遭不住。

用 Fable/Opus 去读网页、搬资料、整理表格，也有点像拿炮弹打苍蝇。不是打不中，而是太贵、太吵，还容易把桌子一起掀了。

所以我最近翻了几篇 Anthropic 关于 Advisor Tool、Managed Agents 和 multi-agent workflow 的技术文章，发现它们表面上是在讲 Claude 的新能力，底层其实在讲一件更工程化的事：

Agent 系统的成本，不只取决于你用了哪个模型，更取决于你有没有把任务拆对。

这篇文章不做文档复读。我们直接把它抽象成一套可复用的 Agent 省钱架构。

先看一个调研任务：拿 Opus 打苍蝇是怎么发生的

假设你要做一个知识调研：

对比 10 个 AI 编程工具的 Agent 架构、定价、上下文管理、工具调用能力，并给出选型建议。

很多人的第一反应是：直接丢给 Fable/Opus。

1
2


Fable/Opus 单体 Agent：
搜索网页 -> 阅读文档 -> 抽取事实 -> 整理表格 -> 对比分析 -> 写最终报告

这当然能做。

但你仔细看一下任务链条，会发现里面大量步骤其实不需要顶级推理能力：

步骤	需要什么能力	是否值得用 Fable/Opus
搜索官网和文档	覆盖率、耐心、工具调用	不太值
读取定价页	信息抽取	不太值
整理上下文长度、工具能力	结构化归纳	不太值
交叉验证来源	仔细、可重复	通常不需要
判断适合什么团队	产品判断、架构取舍	值
识别长期风险	深度推理、经验迁移	值

也就是说，80% 的 token 可能烧在“搬信息”上，但真正需要 Fable/Opus 的，是最后 20% 的判断。

更合理的拆法应该是这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Sonnet coordinator：
 设计调研维度，拆分任务，规定输出格式，验收结果

Haiku / cheaper workers：
 并行搜索、读取网页、抽取事实、保留来源

Sonnet executor：
 合并结构化结果，发现冲突，要求补查

Fable/Opus advisor：
 在最终选型、风险分析、架构判断时介入

这不是为了“少用好模型”，而是为了把好模型用在刀刃上。

Fable/Opus 应该像会议室里最后拍板的专家，而不是从早到晚跑腿打印材料的人。

Advisor Tool：Sonnet 干活，Fable/Opus 把关

第一种实现手段，是 Advisor Tool。

它的模式很简单：

1
2
3
4


Sonnet executor
 -> 遇到复杂判断
 -> 调用 Fable/Opus advisor
 -> Sonnet 继续执行

这像什么？

像一个靠谱的项目经理在推进日常工作，遇到架构选型、安全边界、产品取舍这种“错了会很贵”的节点，再把资深专家叫进来。

Advisor 不是另一个执行员，也不是全程陪跑的老板。它更像关键决策时被请进会议室的人。

适合它的任务有几类：

Sonnet 能稳定推进，但中间有少数非显然设计决策
任务链很长，全程用 Fable/Opus 成本过高
需要在关键节点做风险审查、策略纠偏、方案选择
coding agent、computer use、多步研究这类“执行量大、判断点少”的任务

反过来，不适合的场景也很明确：

单轮问答
每一步都需要强推理
任务太小，advisor 调用成本超过收益
executor 还没收集上下文，就急着问 advisor

这里最重要的实践不是“能不能调用更强模型”，而是什么时候调用。

我的判断标准是：

如果这个决策错了，后面会产生大量返工，就值得问 Fable/Opus；如果只是搬资料、改格式、补字段，交给 Sonnet 或更便宜的模型就够了。

Advisor Tool 的价值，正在于它把模型能力做了纵向分层：

角色	适合模型	主要职责
Executor	Sonnet	推进任务、调用工具、落地修改
Advisor	Fable/Opus	复杂判断、风险提示、策略纠偏
User	人	目标定义、偏好确认、最终接受

一句话总结：

Sonnet 负责把车开起来，Fable/Opus 负责在岔路口提醒你别开进沟里。

Managed Agents：把一个大任务拆成一支小队

第二种实现手段，是 Managed Agents。

Advisor 是纵向升级，Managed Agents 是横向分工。

它的基本结构是：

1
2
3
4
5
6


Sonnet coordinator
 -> research worker A
 -> research worker B
 -> validation worker C
 -> review worker D
 -> coordinator 综合结果

每个 worker 有自己的上下文、工具和任务边界。它不需要知道全局目标的所有细节，只要把自己那一小块做好。

这件事非常关键。

很多单体 Agent 的失败，不是因为模型笨，而是因为上下文被污染了：

读了太多网页，噪音进入上下文
工具输出太长，关键信息被淹没
前面一个错误判断影响后面所有步骤
权限全开，风险边界变大
最后模型已经分不清哪些是事实，哪些是推测

Managed Agents 的价值，不是“模型数量变多所以更聪明”，而是三件事：

价值	解释
上下文隔离	每个 worker 只看自己需要看的材料
并行吞吐	多个资料源、多份文件、多条事实可以同时处理
权限隔离	调研 worker 不一定需要写文件，代码 worker 不一定需要外网

回到前面的 AI 编程工具调研案例。

你可以让每个 worker 只负责两个工具：

1
2
3
4
5


Worker A：调研 Cursor、Windsurf
Worker B：调研 Claude Code、Codex
Worker C：调研 Devin、OpenHands
Worker D：调研 Replit Agent、Gemini CLI
Worker E：交叉检查定价和上下文窗口

每个 worker 的输出必须结构化，比如：

1
2
3
4
5
6
7
8
9


工具名称：
官方链接：
Agent 架构：
上下文管理：
工具调用能力：
定价：
适合人群：
不确定点：
引用来源：

这样 coordinator 拿到的不是一堆网页碎片，而是一组可比较的事实卡片。

这就是多 Agent 的正确姿势：worker 负责吞吐，coordinator 负责验收，不要让最终答案变成 worker 摘要的简单拼接。

Plan Big, Execute Small：真正值得偷走的范式

第三篇 cookbook 里最值得记住的，不是那个具体案例，而是它背后的范式：

1
2
3
4
5
6
7
8


Plan Big：
 Sonnet / Fable / Opus 制定计划、定义维度、设计验收标准

Execute Small：
 Haiku / cheaper workers 并行搜索、读取、抽取、验证

Review Hard：
 Sonnet 汇总冲突，Fable/Opus 做最终判断或策略建议

翻译成人话就是：

大模型负责问题定义，小模型负责信息吞吐，强模型负责判断和验收。

这套模式特别适合几类任务：

多网页知识调研
多文件代码库扫描
多产品竞品分析
多事实交叉验证
长文档消化和结构化摘要
“先查很多东西，再做少数关键判断”的工作流

它为什么有效？

因为很多复杂任务的成本结构并不均匀。

你以为最难的是“写最终报告”，其实最费 token 的往往是：

把 20 个网页读完
从文档里抠出字段
对齐不同来源的说法
反复检查链接和引用
整理成统一格式

这些事情需要耐心、覆盖率和结构化输出，但不一定需要 Fable/Opus 级别的判断力。

不过，多 Agent 也不是银弹。

最容易踩的坑有四个：

坑	结果
拆得太碎	调度成本超过收益
worker 输出太自由	coordinator 难以比较和验收
coordinator 只拼接	错误会被包装成“综合结论”
关键证据不保留	最终判断无法追溯

所以，Plan Big, Execute Small 不是“把任务随便丢给一堆小模型”，而是要先设计好三件事：

拆分边界：每个 worker 负责什么，不负责什么。
输出格式：worker 必须交付什么字段、证据和不确定性。
验收标准：coordinator 如何发现冲突、追问缺口、决定是否升级给 Fable/Opus。

怎么选架构：别先问模型，先问任务

很多人在设计 Agent 系统时，第一句就是：

我该用 Sonnet，还是直接上 Opus？

这个问题问早了。

更好的顺序是：

这个任务里，哪些步骤只是读取、搜索、抽取？
哪些节点需要真正的判断？
哪些子任务可以并行？
worker 的输出如何验收？
如果判断错了，返工成本高不高？
Fable/Opus 应该在哪些位置介入，才最值？

你可以用这张表快速判断：

任务类型	推荐方案
单轮问答	直接 Sonnet 或 Fable/Opus
普通工具执行 + 少数复杂判断	Sonnet executor + Fable/Opus advisor
大量网页、文件、事实调研	Sonnet coordinator + cheaper workers
高价值研究报告	Sonnet coordinator + workers + Fable/Opus final review
代码库大规模扫描	Coordinator + specialized workers
每一步都需要深推理	直接 Fable/Opus，少拆
小任务	不要多 Agent，调度成本不值

这里的关键不是“多 Agent 一定比单 Agent 好”，而是：

当任务可以拆、证据可以结构化、验收标准可以定义时，多 Agent 才有意义。

如果任务本身是连续推理，比如数学证明、复杂算法设计、哲学论证，你硬拆成一堆 worker，反而可能把思路打碎。

真正的省钱架构：让每个模型做它最值钱的事

回到开头那个比喻。

Fable/Opus 当然可以读网页、搬资料、整理表格。就像炮弹当然可以打苍蝇。

问题是：你为什么要这么打？

好的 Agent 系统，不是把所有事情都交给最强模型，而是把任务拆成三层：

层级	职责	典型模型
吞吐层	搜索、读取、抽取、初步整理	Haiku / cheaper workers
执行层	调度、工具调用、合并、落地	Sonnet
判断层	架构取舍、风险分析、最终审查	Fable/Opus

最后留下一个很实用的判断：

如果一个步骤没有明显的判断成本，就不要默认交给最贵的模型。
如果一个决策会影响后面大量工作，就不要吝啬请 Fable/Opus 把关。

这才是 Agent 系统真正的省钱架构。

不是不用强模型，而是让强模型出现在它最值钱的位置。