Matt Pocock 的 AI 工程工作流与其追模型不如造 harness模型只是引擎。prompt提示词、skills工作流规则、codebase 架构代码好不好改、工作环境agent 在哪跑、怎么跑。这些才是你能控制的底盘。Matt Pocock 用 62 分钟拆解他的整套 Agentic Engineering 方法论。从战术 vs 战略编程到 AFK 并行工作流再到「删光一切重新开始」。一、开场定调别只盯模型看看你的 Harness访谈第一分钟Matt 就扔出一个反直觉的判断Everyones obsessed with the model and I think they should be more interested in the harness. 所有人都在追模型但我觉得他们应该更关心 harness。他把 AI 工程比作一辆 F1 赛车。模型是引擎。当然重要但你控制不了它。harness 是底盘、空气动力套件、悬挂系统。prompt 怎么写、skills 怎么组织、codebase 架构好不好、agent 在什么环境里跑。这些你能控制而且它们跟引擎一样重要。什么是 HarnessHarness 本义是「马具/挽具」。套在马身上用来驾驭和传力的皮带系统。马的力量再大没有缰绳你控制不了方向。没有挽具你拉不动车。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 Isnt Enough」。不是 Matt 自己发明的。Ousterhout 在此章定义了两种对立的编程姿态。战术编程以最快速度搞定当前任务为唯一目标不关心未来的修改成本。他为此造了词「战术龙卷风」tactical tornado形容产出极快但留一堆技术债的人。战略编程则采用投资心态。宁可当前慢一点也要花时间改善系统设计。回报期估算 6–18 个月。关键信条首要目标是好的设计代码能跑只是副产品Matt 的判断很直白AI is basically eaten tactical programming. Its 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 承认热情 实验精神 资历。但他引入一对概念DXDeveloper Experience和 AXAgent 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 thats about it. 我是一个 vibe coder我想补上知识缺口让我能交付更好的软件。我只会一些非常基础的 CLI 命令刚好够读代码和使用终端差不多就这样。Agent 读完这个 prompt做了几件事先对齐目标。问三个澄清问题理解学员的目标。创建mission.md。记录「这个人想做什么、为什么重要、成功长什么样」。搜索可信资源判断「对 vibe coder 来说最高杠杆的缺口不是更多语法。而是 Git、读错误信息、debug、测试」。生成 HTML 课程文件。带交互式测验、终端实操练习、参考链接。这门课不是静态的。Matt 特别强调这是stateful skill。agent 在工作区里存学习记录。知道你已经学了什么、下一步该学什么。「好老师记得你学过什么」AI 也可以。Matt 甚至用这个 skill 自学了魔方。「我现在可以凭记忆复原魔方了。靠这个 skill 教的。」安装命令一行npx skillslatest add mattpocock/skills --skillteach五、Procedure vs Ability手握方向盘聊到 skill 架构时Matt 做了一个关键区分Procedure过程Ability能力谁触发用户手动/命令模型自动判断描述词不泄露进 context window常驻 context每轮都占位控制权人模型适用场景规划、审查、教学、面试代码规范、风格检查Matt 偏好⭐ 首选谨慎使用I prefer to be the one in control. I dont want to delegate my thinking to the model. 我偏好人来掌控。我不想把思考也委托给模型。他举了 /grill-me 做例子。这个 skill 只有 4-5 句话。把 agent 变成一个对抗式面试官。你说一个想法它追着你问直到达成共识。Matt 用它替代计划模式。在写任何代码之前先跑一轮。Ive been using this for coding, just as a replacement for plan mode. Its unreasonably effective. 我一直用这个来写代码当计划模式的替代品。效果好得不讲道理。David 提了个有意思的反驳。那 Obra 的 Superpowers目前最流行的 skills 仓库之一走的是 ability-first 路线让模型主动调用。你怎么看Matt 的回应很务实。能力型 skill 的描述词会泄露进 context window。装 100 个 ability skill等于上下文里挂 100 条描述。每轮对话都在为不用的东西付 token。所以他的选择很明确尽量用 procedure。把知识留在人脑里而不是塞进 agent 的 context 里。六、AFK把自己并行化Matt 说他真正感受到 AI 编码威力是在发现 AFKAway 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 Actionsissue 打上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 年验证的软件工程基础而不是针对某个模型做过度优化。那么不管未来哪个模型胜出我的工作流都能继续用。 Im not a pundit. Im trying to do the best with what I have right now. If I try to apply good software fundamentals to what Im doing, it will probably continue to work in the future.他的立场不是「模型不重要」。而是不要从模型出发思考问题。从 codebase 出发、从架构出发、从工作流出发。这些才是你能控制的变量。模型会变好、会变便宜、会有新的王者。但你打下的工程基础不需要推倒重来。人们问我怎么优化 token 消耗。把 codebase 做得更容易改。这样你能用更便宜的模型做同样的事。你的安全边界更好、探索成本更低、agent 不需要反复撞墙。 Have a code base thats 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. Theyre looking at the big shiny new thing, when in fact just focus on the stuff thats been working for 30, 40 years. And it really does work. 人们关注错了方向。他们盯着闪亮的新玩具但真正有效的是那些已经工作了 30、40 年的东西。而且它们真的有效。素材来源视频YouTube Matt Pococks Agentic Engineering Workflow (just copy him)Matt Pocock 的 skills 仓库github.com/mattpocock/skillsMatt Pocock 的网站aihero.devJohn Ousterhout《软件设计的哲学》(A Philosophy of Software Design) Matt Pocock 的 AI 工程工作流：与其追模型，不如造 harness
Matt Pocock 的 AI 工程工作流与其追模型不如造 harness模型只是引擎。prompt提示词、skills工作流规则、codebase 架构代码好不好改、工作环境agent 在哪跑、怎么跑。这些才是你能控制的底盘。Matt Pocock 用 62 分钟拆解他的整套 Agentic Engineering 方法论。从战术 vs 战略编程到 AFK 并行工作流再到「删光一切重新开始」。一、开场定调别只盯模型看看你的 Harness访谈第一分钟Matt 就扔出一个反直觉的判断Everyones obsessed with the model and I think they should be more interested in the harness. 所有人都在追模型但我觉得他们应该更关心 harness。他把 AI 工程比作一辆 F1 赛车。模型是引擎。当然重要但你控制不了它。harness 是底盘、空气动力套件、悬挂系统。prompt 怎么写、skills 怎么组织、codebase 架构好不好、agent 在什么环境里跑。这些你能控制而且它们跟引擎一样重要。什么是 HarnessHarness 本义是「马具/挽具」。套在马身上用来驾驭和传力的皮带系统。马的力量再大没有缰绳你控制不了方向。没有挽具你拉不动车。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 Isnt Enough」。不是 Matt 自己发明的。Ousterhout 在此章定义了两种对立的编程姿态。战术编程以最快速度搞定当前任务为唯一目标不关心未来的修改成本。他为此造了词「战术龙卷风」tactical tornado形容产出极快但留一堆技术债的人。战略编程则采用投资心态。宁可当前慢一点也要花时间改善系统设计。回报期估算 6–18 个月。关键信条首要目标是好的设计代码能跑只是副产品Matt 的判断很直白AI is basically eaten tactical programming. Its 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 承认热情 实验精神 资历。但他引入一对概念DXDeveloper Experience和 AXAgent 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 thats about it. 我是一个 vibe coder我想补上知识缺口让我能交付更好的软件。我只会一些非常基础的 CLI 命令刚好够读代码和使用终端差不多就这样。Agent 读完这个 prompt做了几件事先对齐目标。问三个澄清问题理解学员的目标。创建mission.md。记录「这个人想做什么、为什么重要、成功长什么样」。搜索可信资源判断「对 vibe coder 来说最高杠杆的缺口不是更多语法。而是 Git、读错误信息、debug、测试」。生成 HTML 课程文件。带交互式测验、终端实操练习、参考链接。这门课不是静态的。Matt 特别强调这是stateful skill。agent 在工作区里存学习记录。知道你已经学了什么、下一步该学什么。「好老师记得你学过什么」AI 也可以。Matt 甚至用这个 skill 自学了魔方。「我现在可以凭记忆复原魔方了。靠这个 skill 教的。」安装命令一行npx skillslatest add mattpocock/skills --skillteach五、Procedure vs Ability手握方向盘聊到 skill 架构时Matt 做了一个关键区分Procedure过程Ability能力谁触发用户手动/命令模型自动判断描述词不泄露进 context window常驻 context每轮都占位控制权人模型适用场景规划、审查、教学、面试代码规范、风格检查Matt 偏好⭐ 首选谨慎使用I prefer to be the one in control. I dont want to delegate my thinking to the model. 我偏好人来掌控。我不想把思考也委托给模型。他举了 /grill-me 做例子。这个 skill 只有 4-5 句话。把 agent 变成一个对抗式面试官。你说一个想法它追着你问直到达成共识。Matt 用它替代计划模式。在写任何代码之前先跑一轮。Ive been using this for coding, just as a replacement for plan mode. Its unreasonably effective. 我一直用这个来写代码当计划模式的替代品。效果好得不讲道理。David 提了个有意思的反驳。那 Obra 的 Superpowers目前最流行的 skills 仓库之一走的是 ability-first 路线让模型主动调用。你怎么看Matt 的回应很务实。能力型 skill 的描述词会泄露进 context window。装 100 个 ability skill等于上下文里挂 100 条描述。每轮对话都在为不用的东西付 token。所以他的选择很明确尽量用 procedure。把知识留在人脑里而不是塞进 agent 的 context 里。六、AFK把自己并行化Matt 说他真正感受到 AI 编码威力是在发现 AFKAway 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 Actionsissue 打上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 年验证的软件工程基础而不是针对某个模型做过度优化。那么不管未来哪个模型胜出我的工作流都能继续用。 Im not a pundit. Im trying to do the best with what I have right now. If I try to apply good software fundamentals to what Im doing, it will probably continue to work in the future.他的立场不是「模型不重要」。而是不要从模型出发思考问题。从 codebase 出发、从架构出发、从工作流出发。这些才是你能控制的变量。模型会变好、会变便宜、会有新的王者。但你打下的工程基础不需要推倒重来。人们问我怎么优化 token 消耗。把 codebase 做得更容易改。这样你能用更便宜的模型做同样的事。你的安全边界更好、探索成本更低、agent 不需要反复撞墙。 Have a code base thats 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. Theyre looking at the big shiny new thing, when in fact just focus on the stuff thats been working for 30, 40 years. And it really does work. 人们关注错了方向。他们盯着闪亮的新玩具但真正有效的是那些已经工作了 30、40 年的东西。而且它们真的有效。素材来源视频YouTube Matt Pococks Agentic Engineering Workflow (just copy him)Matt Pocock 的 skills 仓库github.com/mattpocock/skillsMatt Pocock 的网站aihero.devJohn Ousterhout《软件设计的哲学》(A Philosophy of Software Design)