在油管上看到最喜欢的 Skill 博主 Matt 发布了跟元老级的人物 Uncle Bob 的播客访谈，个人觉得非常高质量，遂记录。
（前面是一些寒暄，然后 Matt 引入了大模型 Agent 的一些东西，同时问 Bob 对这些的看法...）
Bob：
我就想，这东西快是快，但恼火的是它把我拖慢了。嗯。
只要它们快------它们确实快。
只要能把它们约束好，我就不拿我的慢去拖累它们。
我的慢，就是某种粒度上审代码、查代码。
Matt：
所以你的目标是把自己从代码里抽出来，不靠人工审查，在代码周围搭一层脚手架，自己尽量少碰，还要把 agent 拘在最紧的束缚衣里，让它没法犯错。
那烂代码为什么烂？我们为什么在意？它们这么快、跑这么猛，我们在意什么？何苦搭这一整套 Harness？
直接让 Agent 大力出奇迹直接修，让 bug 自己消失不行吗？
Bob：
代码烂到一定程度，agent 也扛不住。
进入一种模式：改好一处，顺手弄坏另一处。
然后开始空转，越弄越糟，束手无策。
在 context window 中，随着上下文不断变长，"lost in the middle" 现象就会慢慢浮现，即模型对于比较久的和最新的对话的记忆比较清楚，但是在中间的内容却很难记得住。开头和结尾的内容权重高，中间的会被弱化...
提示词中的对于代码的约束，由于上下文变长，这些约束可能就处于内容的"中间"，指令就会被忽视。这些约束最终会被上下文淹没
Bob：
用 agent 的关键------这非常难做到------是把初始 prompt 削到最短。
所以他的建议是：
尽量让内容都留在它的优先区。
而且比如像确定性工具这种外部的东西，就不会失踪。需要做的时候模型直接调用就好了
然后靠确定性工具事后把关
Matt 对此的回应是：
完全同意。所以你放弃了引导，回头捡起了自动化检查的老手艺。
那为什么说确定性工具就不会被忽视呢？
Matt：
因为这些检查不像引导指令那样进上下文窗口，
所以可以一层层往上叠、随便叠。
但一直往上叠也不是一件好事，对于自检性比较强的模型来说：这会不会算是一种负担，会不会测试过头了？这也是在探讨的地方
Matt：
那如果语言本身有强类型、又有测试，这幅图景对你来说什么样？
Bob：
如果叠的过多显然是有的，甚至比人还慢。但是只要确保生产的效率还是在人之上，那还是能接受的
这些确定性工具实际上就是一层层的 loop，用这些确定性工具，实质是把它们放进循环。在循环里下命令：改，改到这个测试确认通过为止。
经过一层又一层的检查，agent 也会做复杂性校验，解耦，补测试，拆函数等等...得折腾一阵子才能完成一个 loop
等于拿生产率换质量。
得折腾一阵才能全部达标。
于是 Uncle Bob 尝试使用多 Agent 来完成这些事情：干活 -> 审查 -> 测试 -> 加固 -> ... 一直循环往下，这就引入了多 agent 话题
Bob 列出了多 agent 的好处：
一是能并行跑。
二是 agent 聚焦单一任务时，上下文窗口可控。
lost in the middle 的毛病就轻多了。
ps：这里的 "lost in middle" 在上面的 context window 有提到过。
头部多放几条规则------别太多------它们就更愿意遵守。
还可以让 agent 生、干活、死，下一个带着干净上下文进场。
Matt 对 Uncle Bob 的多 Agent 的工作流的评价是：
我最近在想：所以你操盘的不只是上下文窗口。
好比说上下文窗口、或者说会话，是有"轨迹"的：就像是你让它做过一件事、之后同一会话里的所有动作都会顺着这条轨迹走。
比如你让它测过一次 UI，之后不管改多少轮，它每次都要测 UI。
那么清掉轨迹的唯一办法就是清空上下文窗口。
拿实现 agent 举例：只求跑通的轨迹，用不上盯着 100% 覆盖率，搞那么执拗。
Bob 对此持同意看法：
你这个"轨迹"的说法很到位。
只要方向不乱、上下文里前后一致，就不容易出现大家常碰到的疯狂幻觉。
只要代码前提设计模块得好，效率的杠杆就会大的惊人。
那为什么好的模块结构非常重要？这个道理跟垃圾代码的角度来说是一样的：
分区清晰、接口规矩的东西，人才能把握，因为大脑本来就靠分块思考。
但是 agent 对 spec 的东西写的过于详细了，plan 的非常细致，但是执行的时候往往达不到预期的效果
Bob：
我最近改成了这样：不再写规约去定义我想要什么、甚至我有什么。
我看着最终产物说：它本身就是规约。
这句话这值得深思...
Matt：最后一个问题
再借一次 John Ousterhout：他对编程类型的定义特别精彩。
随机他引出了"战术式编程"，即：
战术对战略。
战术是地面上的军士、真刀真枪打仗的人；战略就是将军、决定战争走向的人。
那么现在的 agent 战术超强，但战略超烂。现在战术活全被 AI 做了，那刚入行的人怎么办？
战略编程怎么学?
Bob's answer:
首先，程序员该受的训练，不管在大学还是别处，核心就是写代码。起码写上一年。多久不好说，总之要写到知道 agent 面对的是什么。
下一步：你进了重度使用 agent 的公司，你这个刚出训的年轻人，就该被当成一个 agent 对待。
主管工程师也好、谁也好，那个手里跑着一串 agent，自己当将军的人，应该把你当一个 agent 看：派同样的活，上同样的确定性工具。
你该这么干上几个月，产出难看死了，但能学到海量的东西。
这套关卡闯完，也许就配让你自己带 agent 了。说不准。（?
就像是：
没写过汇编的，该花一个周末写写汇编，才知道幕后到底发生了什么。
Bob 对此的解释具体为：
agent 是代码之上的一层抽象。
代码在下面，而抽象层------你刚才说的模块查看器就是这意思------
在代码上架这种抽象，是很棒的学习方式。
再往下钻时，理解就深一层。
Matt 有感： agent 相当于加速了你的学习进程，比如：
干六个月就跳槽的人，可能永远学不到战略编程。 因为他们的错误要九个月后才显形。
自己的错，自己永远看不见。
但有了 agent，就看得见了。
一切加速，犯错后的反馈来得更快更密。
去年 12 月你看着 agent 的产出说"这是坨狗屎"------ 那你是怎么识别出来的？
Bob 对此疑问的回答是：重点不在于怎么认出来，是要看 agent 挣扎，看到 agent 对这些产出不能很好的执行时，那就说明大概率是狗屎了
原话：
一开始就是肉眼看代码，看见狗屎。
那不是重点。重点是下一步：看它们挣扎。
难就难在这：新手进来，认不出那种挣扎。
那怎么学呢？看书👀，软件的基本功还是很重要的！
Bob：
软件是人类尝试过最复杂的东西，比我们试过的任何事都复杂，软件就是最复杂的。
所以基本功是把这种复杂度组织成可把握形态的方法 ------不光人把握得了，model 也把握得了，毕竟 model 本就是照着人造的。
基本功依然成立，因为我们就是靠它把复杂度驯化成可理解的形态。
现在有人说基本功不重要了。他们会懂的，会碰壁懂的那种，而且用不了多久。但说不定比我预想的久，毕竟 agent 确实强。
但我亲眼见过它们撞墙。眼下这个局面，处处是历史的重演。
怎么个重演呢？Bob 原话：
刚才 Matt 提到的抽象层，现在我们站在了编译器之上，从前的抽象层是编译器，往前就是汇编、二进制，现在抽象层已经上升到了 model 这一层。
抽象层每升一级，底下一层的人都会抱怨："我们饭碗都没了，sth like that..."，每一次都是这样。现在又到新的阶段，下面的人又喊："完了全完了！"，这显然是不会的。
后面是 Bob 的最后的几句，我觉得应该贴上原字幕印象会更加深刻～
我把最精简的部分都总结出来了，如果对此播客感兴趣的，地址在�LIVE: Uncle Bob on Software Fundamentals in the Age of AIk]
看完只能说：小编要 n 刷这次播客了，感受颇深，受益匪浅呀。希望大家也能从中受到启发，祝大家变得更强！