Matt Pocock 的 AI 工程工作流：与其追模型，不如造 harness-尧图网络科技

Matt Pocock 的 AI 工程工作流：与其追模型，不如造 harness

模型只是引擎。prompt（提示词）、skills（工作流规则）、codebase 架构（代码好不好改）、工作环境（agent 在哪跑、怎么跑）。这些才是你能控制的底盘。Matt Pocock 用 62 分钟，拆解他的整套 Agentic Engineering 方法论。从战术 vs 战略编程，到 AFK 并行工作流，再到「删光一切重新开始」。

一、开场定调：别只盯模型，看看你的 Harness

访谈第一分钟，Matt 就扔出一个反直觉的判断：

Everyone's obsessed with the model and I think they should be more interested in the harness. 所有人都在追模型，但我觉得他们应该更关心 harness。

他把 AI 工程比作一辆 F1 赛车。模型是引擎。当然重要，但你控制不了它。harness 是底盘、空气动力套件、悬挂系统。prompt 怎么写、skills 怎么组织、codebase 架构好不好、agent 在什么环境里跑。这些你能控制，而且它们跟引擎一样重要。

什么是 Harness？

Harness 本义是「马具/挽具」。套在马身上，用来驾驭和传力的皮带系统。马的力量再大，没有缰绳，你控制不了方向。没有挽具，你拉不动车。

Matt 把这个词搬到 AI 工程里。指围绕模型的整套可控基础设施，包括：

提示词
（prompt）：你怎么给 agent 下达指令
Skills
：可复用的工作流程和规则集
Codebase 架构
：代码的模块化程度、接口清晰度、改动成本
自动化流水线
：CI/CD、GitHub Actions、沙箱环境
Context Window 管理
：CLAUDE.md / AGENTS.md 里放什么、不放什么
工作流设计
：human-in-the-loop 还是 AFK、队列还是循环

一句话：模型是「你拉什么车」，harness 是「你怎么赶车」。马（模型）会越来越壮。但驾车技术（harness）是你自己的。换匹马照样跑。

Matt 甚至说，这是他的「hot take」（个人锐评、大胆主张。快速抛出、刻意引发讨论的观点）。模型和 harness 五五开。人们花 90% 精力追最新模型。忘了剩下 50% 的可控区域。

有人问我怎么优化 token 消耗？把 codebase 做得更容易改就行。codebase 架构好，便宜模型也能干同样的活。

二、战术编程已死，战略编程永生

Matt 引用了 John Ousterhout 的《软件设计的哲学》(A Philosophy of Software Design)里的经典二分法：

战术编程（Tactical Programming）
：写代码、修 bug、处理语法细节、创建 commit。日复一日的「地面作战」。
战略编程（Strategic Programming）
：赢得战争，而非战役。codebase 应该长什么样？怎样提高团队开发速度？模块间接口怎么定义？

这确实出自原书第 3 章「Working Code Isn't Enough」。不是 Matt 自己发明的。Ousterhout 在此章定义了两种对立的编程姿态。战术编程以最快速度搞定当前任务为唯一目标，不关心未来的修改成本。他为此造了词「战术龙卷风」（tactical tornado），形容产出极快但留一堆技术债的人。战略编程则采用投资心态。宁可当前慢一点，也要花时间改善系统设计。回报期估算 6–18 个月。关键信条：首要目标是好的设计，代码能跑只是副产品

Matt 的判断很直白：

AI is basically eaten tactical programming. It's gone. All gone. AI 基本吃掉了战术编程。全吃掉了。没了。

AI 写代码比你快、比你便宜、还不用睡觉。你现在拥有一支「无限的战术程序员舰队」。但指挥这支舰队的能力。把任务界定清楚、把难点预先设计好、把模块接口定义准确、把测试策略想清楚。这些才是你作为人的主战场。

这些东西，没有因为 AI 出现而改变。Matt 说得直接。战略编程 30 年前怎么做，现在就怎么做。只是你把活从初级程序员手里，转交给了 AI。

三、你的技能 = AI 的天花板

Your skills are the ceiling on what AI can do. 你的技能就是 AI 能发挥的上限。

Matt 到处看到同一个现象。AI 让资深开发者强 10 倍。但给初级开发者的提升非常有限。为什么？因为 AI 是倍增器。基数小，乘出来还是小。基数大，乘出来吓人。

这不是说初级开发者没前途。Matt 自己也经历过那个阶段。他最初是声乐老师，转行写代码，现在教几万开发者。但他的观点很清楚：

Getting good with AI is really about getting good at your domain. 用好 AI 的关键，是精通你自己的领域。

David 追问了一个尖锐的问题。那怎么看待「真正的 AI 信徒」？那些技术基础一般，但把 AI 工具玩得飞起的年轻人。他们会不会比不碰 AI 的资深开发者更有竞争力？

Matt 承认，热情 + 实验精神 > 资历。但他引入一对概念：DX（Developer Experience）和 AX（Agent Experience）。好的 codebase，让人类开发者和 AI agent 都舒服。模块边界清晰、改动影响范围小、测试覆盖充分。这些东西，资深开发者做了 10 年，自然知道怎么做。初级开发者要补的，不是「怎么用 AI」。而是这些软件工程基础。

四、/teach：把教学法编码进 Agent

访谈中最精彩的实操演示，是 Matt 的 /teach。原理简单，但执行深度惊人。把教育学的关键概念（最近发展区、知识/技能/智慧三层模型）编码进一个 skill。让 agent 变成你的私人教师。针对任何主题，生成个性化课程。

现场 Demo 环节，Matt 模拟了一个「vibe coder 想补基础」的场景。他的 prompt 没提任何具体技术。只描述了自己的处境：

I am a vibe coder and I want to fill in my knowledge gaps so that I can ship better software. I know some very, very basic CLI commands and I know just about enough to read some code and use the terminal, but that's about it. 我是一个 vibe coder，我想补上知识缺口，让我能交付更好的软件。我只会一些非常基础的 CLI 命令，刚好够读代码和使用终端，差不多就这样。

Agent 读完这个 prompt，做了几件事：

先对齐目标。问三个澄清问题，理解学员的目标。
创建mission.md。记录「这个人想做什么、为什么重要、成功长什么样」。
搜索可信资源，判断「对 vibe coder 来说，最高杠杆的缺口不是更多语法。而是 Git、读错误信息、debug、测试」。
生成 HTML 课程文件。带交互式测验、终端实操练习、参考链接。

这门课不是静态的。Matt 特别强调，这是stateful skill。agent 在工作区里存学习记录。知道你已经学了什么、下一步该学什么。「好老师记得你学过什么」，AI 也可以。

Matt 甚至用这个 skill 自学了魔方。「我现在可以凭记忆复原魔方了。靠这个 skill 教的。」

安装命令一行：

npx skills@latest add mattpocock/skills --skill=teach

五、Procedure vs Ability：手握方向盘

聊到 skill 架构时，Matt 做了一个关键区分：

	Procedure（过程）	Ability（能力）
谁触发	用户手动`/命令`	模型自动判断
描述词	不泄露进 context window	常驻 context，每轮都占位
控制权	人	模型
适用场景	规划、审查、教学、面试	代码规范、风格检查
Matt 偏好	⭐ 首选	谨慎使用

I prefer to be the one in control. I don't want to delegate my thinking to the model. 我偏好人来掌控。我不想把思考也委托给模型。

他举了 /grill-me 做例子。这个 skill 只有 4-5 句话。把 agent 变成一个对抗式面试官。你说一个想法，它追着你问，直到达成共识。Matt 用它替代计划模式。在写任何代码之前，先跑一轮。

I've been using this for coding, just as a replacement for plan mode. It's unreasonably effective. 我一直用这个来写代码，当计划模式的替代品。效果好得不讲道理。

David 提了个有意思的反驳。那 Obra 的 Superpowers（目前最流行的 skills 仓库之一），走的是 ability-first 路线，让模型主动调用。你怎么看？

Matt 的回应很务实。能力型 skill 的描述词会泄露进 context window。装 100 个 ability skill，等于上下文里挂 100 条描述。每轮对话，都在为不用的东西付 token。所以他的选择很明确：尽量用 procedure。把知识留在人脑里，而不是塞进 agent 的 context 里。

六、AFK：把自己并行化

Matt 说，他真正感受到 AI 编码威力，是在发现 AFK（Away From Keyboard）之后：

The moment I discovered AFK was the moment I really got into AI coding. I was able to massively increase my output. 发现 AFK 的那一刻，我才真正进入 AI 编码。我突然能并行产出：两个我、三个我、四个我，同时做事。

他管这叫「把自己并行化」（parallelize yourself）。关键工具是他自己造的Sandcastle。一个在 Docker/Podman 沙箱里运行 agent 的系统。配合 GitHub Actions：

issue 打上explore标签 → AFK agent 自动分析可行性
issue 打上agent implement标签 → AFK agent 在沙箱里实现
PR 提交 → AFK agent 自动 code review
人只需要做最终 approve

这套流水线的关键：每个 AFK agent 做一件范围明确的事。Matt 说，这不是什么新概念。开发者团队一直都是这样工作的。一个待办列表、多个人（现在是多个 agent）取任务、做完提交、人审核。

七、Queues, not Loops：开发不是死循环

访谈后半段，David 把话题引向当时 Twitter 上最火的讨论。agentic loop。很多人认为，AI 编码的未来，是让 agent 在一个 while 循环里不停地跑，直到任务完成。

Matt 对此态度鲜明：

This idea that loops are the only way to do it is crazy. 认为循环是唯一方式，这想法太疯狂了。

他的替代方案：Queues（队列），不是 Loops（循环）。

开发本质是一个队列。产品经理往待办列表加任务。开发者（人 or agent）取任务、完成、提交。一个死循环 agent 不停地跑。既对不上团队工作方式，又在无意义地烧 token。

有个 bug report → 打标签 → AFK agent 取走 → explore → implement → review → 人 approve → merge。这不是循环。这是队列。

David 用了个精妙的比喻。像中世纪国王管理王国。你不会把大臣派到边疆，然后不管了。他会在那边自主决策，可能对可能错。你要的是「大臣回来汇报，你来做优先级决策」。AI agent 也一样。human-in-the-loop checkpoints 应该被「推得更远」，但不该被消灭。因为你看的不只是代码。更是产出代码的系统，是否健康。

八、Bitter Lesson 与务实主义

David 抛出一个尖锐的挑战。你说的 harness 优化，会不会掉进机器学习的「Bitter Lesson（苦涩的教训）」？历史上，每次有人尝试手动优化系统，最终都被 raw compute 的增长碾压。原始算力。纯粹堆更多 GPU、更大模型、更多数据让机器自己学，而非人工注入领域知识。

Matt 的回应坦率而务实：

我不是预言家。我只是用现在手头的东西做到最好。如果我用的是经过 30、40 年验证的软件工程基础，而不是针对某个模型做过度优化。那么不管未来哪个模型胜出，我的工作流都能继续用。 I'm not a pundit. I'm trying to do the best with what I have right now. If I try to apply good software fundamentals to what I'm doing, it will probably continue to work in the future.

他的立场不是「模型不重要」。而是不要从模型出发思考问题。从 codebase 出发、从架构出发、从工作流出发。这些才是你能控制的变量。模型会变好、会变便宜、会有新的王者。但你打下的工程基础，不需要推倒重来。

人们问我怎么优化 token 消耗。把 codebase 做得更容易改。这样你能用更便宜的模型做同样的事。你的安全边界更好、探索成本更低、agent 不需要反复撞墙。 Have a code base that's easier to make changes in, because then you can employ a stupider model.

九、删光一切，从零开始

访谈尾声，David 问 Matt：给普通 AI 用户一两个立刻能做的事，你的建议是什么？

Matt 的答案出乎意料：

Delete every single skill, every single plugin, every single MCP server. Delete your CLAUDE.md, delete your AGENTS.md. Go back to absolutely nothing. Observe what the agent does. 删掉每一个 skill、每一个插件、每一个 MCP server。删掉你的 CLAUDE.md、AGENTS.md。回到什么都没有的状态。观察 agent 做了什么。

理由是：大多数人把 context window 塞爆了。100 条指令躺在上下文里。每轮对话都占 tokens。但 80% 从来用不到。归零之后，再加回来的每一样东西，都必须是你自己决定需要的 procedure skill。而不是「别人推荐」的 ability skill。

如果你发现少了什么。比如没了 Superpowers 的 brainstorming 让你不舒服。再加回来。但要确保你装的每一样东西，都是你能修改、能实验、能掌控的。 If you really miss brainstorming from Superpowers, then bring that back. Make sure you install them in a way you can customize them.

小结

Matt 的方法论，可以浓缩为一句话：模型给你上限，harness 决定你离上限有多近。

他反复回到这对概念。engine 和 chassis、tactical 和 strategic、ability 和 procedure、loops 和 queues。每对概念，都是同一个主张的不同切面：把控制权拿回自己手里。

Fable 出来那天，所有人都在惊叹模型又变强了。Matt 的反应是：模型强很好。但你的 codebase 是不是该更好一点？你的 skills 是不是该更精简一点？你的 AFK 流水线是不是该更自动化一点？

这不是保守主义。这是工程师的本能。在你能控制的变量上做功，别在控制不了的变量上焦虑。

People are focused on the wrong thing. They're looking at the big shiny new thing, when in fact just focus on the stuff that's been working for 30, 40 years. And it really does work. 人们关注错了方向。他们盯着闪亮的新玩具，但真正有效的，是那些已经工作了 30、40 年的东西。而且它们真的有效。