目录
- 开场与AWS经历 [00:00:00 - 00:10:00]
- Lambda Power Tools与工程成长 [00:10:00 - 00:20:00]
- 用全局视角理解复杂决策 [00:20:00 - 00:30:00]
- Agent驱动的开发循环 [00:30:00 - 00:40:00]
- 纸笔会议与团队协作 [00:40:00 - 00:50:00]
- 验证工程最后百分之十 [00:50:00 - 01:00:00]
- 在大型代码库落地Spec [01:00:00 - 01:10:00]
- Spec驱动开发的核心循环 [01:10:00 - 01:20:00]
- 从开发产物到实现 [01:20:00 - 01:30:00]
- 事件钩子与可信执行 [01:30:00 - 01:40:00]
- Retro反馈与风险治理 [01:40:00 - 01:48:35]
开场与AWS经历
Patrick Akil：欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目，通过先进的AI声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的AI财经，健康与科技领域精品内容，我是主播一凯，一位热衷于AI领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁，接下来让我为您简单介绍，本期我们克隆的这档节目，本期我们克隆的是知名播客，Bayoncoding的一期深度对谈，主持人Patrick与嘉宾Heitor Lessa，展开了一场关于AI时代软件工程变革的硬核讨论，Heitor是AWS老兵，在亚马逊工作了11年，曾培训过8000多名架构师，并亲手将Lambda Power Tools打造成，每周处理2300亿次API调用的开源项目，这期节目里，Heitor首次在屏幕上完整展示了，他为1400名工程师设计的，agent的驱动开发工作流，从产品发现，规范驱动开发，到合并检查，还分享了他重构时，烧掉2亿token的惨痛教训，那我们就一起来听听，这期完整的对话，这次重构花了我，差不多2亿个token，我当时就想，天哪，我得停用OPUS了，这根本不行。 [00:01:24]
Heitor Lessa：这位是Heitor Lessa，一位真正的AWS老兵，培训过8000多名架构师，今天他要分享他用Agent做软件工程的蓝图，当领导层开始质疑。
Patrick Akil：我是不是真的需要一个月花5000美元，请一个工程师来干活，这笔账根本算不过来，就算他们伪造证据，伪造自己跑了测试，甚至从网上复制粘贴结果，他们真干得出来。
Heitor Lessa：我怎么确保这种事不会发生，Agent以及工程团队怎么跟他们协作，这期节目我们要做一件以前从没做过的事，听完这期，你会想重建自己的软件工程工作流，好好享受吧，杜伯林的规模，尤其是科技圈，已经发展的非常大了，哦对，对，啊对，但肯定也很有意思吧，你积累的那些人脉和关系，哦对。 [00:02:16]
Patrick Akil：我觉得通常你会遇到一家公司，你的成长关键期就在那里，但亚马逊尤其特别，那种超高速增长的概念，或者说那种，你只要上个大学，读本哈佛的书，就能搞定一切的想法，对亚马逊完全不管用，因为它的增长实在太惊人了，对，我记得公司从几百人，每年涨到2000人，4000人，我当时就想，这什么情况，我们到底要涨到哪去，然后就是，对每年最低25%的增长，然后总法律顾问说，好我们翻倍，翻三倍，翻四倍，我心想，所以那些常规做法根本行不通，太不可思议了，最后你在那待了11年，你最大的收获是什么，你当时担任什么角色，太多了，我觉得亚马逊有意思的一点是，尽管规模很大，AWS尤其大，人流程各种东西都庞大，但他给我的感觉始终像一家创业公司，你可以在不同角色和团队之间流动，我想这也是我能待这么久的部分原因，加入AWS之前，我去参加过一次AWS的meetup，但我说过，我永远不会加入亚马逊这样的公司，永远不会这种大企业，我对他们过敏，我只想把事情做成，对，结果你来了，我记得我当时还在抱怨那个演讲者，但台下的人我一个都不认识，然后正好有两个AWS员工过来跟我说，嘿你为什么不投个简历，我说算了吧，我永远不会去，他们说不，其实有点不一样，然后我就投了，加入了之后，我大概换了八个不同的岗位，如果我没记错的话，从技术支持到一线客户审查，技术客户经理，解决方案架构师，专家解决方案架构师，然后帮忙搭建我们所说的无服务器业务，我是美国以外的第一个专家，然后还要招开发者步道师之类的，我得先学会怎么干这个活，直到我们招到人，所以所有这些事情，从外面看不像亚马逊，但里面就是走，去见这些东西，说到收获，有两个三个角色对我影响很深，塑造了我的思维方式，一个是技术客户经理，这个角色通常是在出问题的时候，才会被叫去，比如我现在当机了，我们出了大事故，或者你刚开始用AWS做了迁移，现在账单暴涨，你想知道怎么优化成本，这些都是人们不太愿意面对的事，他们不会客客气气的说，嗨我有个问题，而是我现在就需要帮助，我现在就要解决，那个角色让我接触到，一些大家最终都不太想合作的公司，比如早期的游戏公司，或者增长惊人的创业公司，你会看到2015年就有公司在做，微服务大规模DevOps API优先的团队，那是2015年，这让我开始想，好吧，现在一切都应该是微服务DevOps之类的，然后常态是，NOSCO的币表上，有70TB的数据要处理，那也是2015年，对，之后我开始看到，其他公司几百人的规模，我心想，他们才刚看到，第一个10GB，所以我有很多经验可以分享，太好了，没错，所以我从那种，人人都不太喜欢AWS，或者抱怨AWS的战壕里走出来，去帮忙，去修复，去试着挽回一些信任，一路走到客户，第一次看到AWS，第一次听说Elastic Computer的时候，对他们来说，那感觉就是，哇天哪，这是什么，然后专家角色转向了Serverless，从咱们来构建API团队，这个想法开始，也就是围绕API组建团队，把DevOps和DevOps放在一起，诸如此类，到后来，你的团队可以小得多，因为你不用再操心服务器运维，或者大部分运维的活，那是我看到的第二次最大的认知转变，因为一开始我以为这全是技术问题，你只需要换个思路，你的依赖，你怎么启动代码，你得把性能考虑进去，但现在性能背后有了一个投资回报的数字，而开发者通常在晋升周期里很难解释清楚，如果我做这个重构，如果我提升这块的性能，这对业务会有改善，开发者很难做到这一点，serverless就简单多了，我可以说如果我这么做，能砍掉我们90%的账单，好，然后大家就说，真的吗，现在我终于有了一条CFO能听懂的说明方式，对，但我原本以为这主要是技术问题，比如，对你不用什么都用Java，当年Java在Serverless上表现不太好，你得用GoPython或者Node.js这类语言，有意思的是，对小团队来说，这全是技术，但当你去琢磨，这对一万个开发者怎么运作，对五千一千几百个开发者怎么运作的时候，大部分其实变成了组织转型，所以我突然要面对组织里那些不太好玩的部分，如果有一百个人，他们的工作就是盯着web服务器，重启东西，serverless，把这些都接管了，你什么都不用做了，对，这些全没了，那你怎么从这过渡到重新定位，重新培训怎么做，然后结果就是，我这个角色最长的一段时期，差不多四年做的事情是，怎么帮一个组织去审视自己的人才，自己的团队，开始思考社区建设，打造核心工程，用不同的方式组建团队，组建更小的团队，而那时候roadmap或者PRD这套东西，已经在慢慢过时了，因为这个模式太快了，我可以去客户那儿，做首席工程师及服务，如果你愿意这么叫的话，六个月之内你就能说，好了，IMVP有了，上线了，上线后也跑起来了，我们拿到了一些经验，现在可以推广到整个组织了，这在企业环境里是不可想象的，因为通常要花好几年，大部分工作不是写代码，主要是协调，然后说服别人，事情可以变成什么样，怎么变，但哪怕只是，事情可以变成什么样，这个说法，本身就很昂贵，你得有利益相关者，愿意相信你说的话，但当你说，其实给我三个人就行，我演示给你看，这很有意思，因为它跟AI这个话题有相关性，我们待会会聊到，最后一点，我先停一下，免得我一直在说，就是看这些公司，有一段时间，大概每年看70家左右，但我前前后后看过，大概三四百家公司，或多或少是从内部去看，试着帮他们，这变成了管理咨询，变成了写作，变成了代码，变成了中间所有的事情，关于Serverless，我学到的是，即使AWS会帮他们处理所有基础设施，什么都不用想，仍然有一个巨大的鸿沟，我习惯说开发者把某些东西当信仰，我的编程语言是Java，我的编程语言是Python，别的都不重要，身份认同，没错，这变成了一个身份认同的问题，对他们来说最难的一点是，但我习惯了Spring，我习惯了Django，我习惯了这些框架，现在我用Serverless，感觉像被扒光了，如果用这个冷启动要好几秒，这对客户不好，所以我当时做的东西叫Power Tools，也就是Lambda Power Tools，想法是怎么让他们用上类似的开发体验，同时把分布式系统的最佳实践也嵌进去，我有这个能力，队列里的读消息怎么处理，自适应重视怎么搞。 [00:10:00]
Lambda Power Tools与工程成长
Patrick Akil：自适应重视怎么搞，而不是静态重视，熔断器你能想到的都有，然后这个东西就爆了，我一开始想，我就给某些客户做这个，因为反正我知道他们的模式，DLC和他们的组织方式，但后来从我就做个原型，放到开源里看看会怎样开始，我在开源方面没什么经验，我偶尔贡献过一点，但从来没有Power Tools这个规模，后来不到五年，其实不到四年，Power Tools从几百次下载，变成了每周2300亿次API调用，美国政府，英国政府，还有一堆其他地方在用，我就想，我不能像以前那样，随便发版本了，没错，所以那就是我学到，其他方面的地方，这些年我在serverless，和一线积累的东西，一直活在压力下，经历组织变革，现在我得做一件好玩的事，就是在公开环境里工作，这就像硬币的两面，每个人都想贡献，新技术让人兴奋，你懂的，就像Rust一出来，每个人都觉得，应该像其他人一样，把整个库重写一遍，对吧，Power Tools也没多大区别，每个人都想贡献，想从零开始建一个社区，但这时候我得学，怎么在公开场合写作，怎么把文档做成你的秘密武器，因为你根本没有营销预算，怎么在众目睽睽之下，做产品管理，所有人都盯着你写的东西，你的思考方式，去批评和审视，怎么去带那些你从没见过，有时还隔着时区的人，又怎么处理这种情况，有人说，我贡献了这些，但你没按我预期的时间，合并我的pool request，因为我花了时间在这上面，我就说，行，那咱们聊聊，有时候网上还有抽稿事，我也遇到过跟踪骚扰，还有一堆乱七八糟的事，这就是做开源的另一面，所以对我来说，这三个角色是我学习的地方，怎么处理生产事故，生产成本和FINOPs，那是2015年FINOPs这个概念，当时我们其实就在做，但话说回来，我不是什么都懂，只是看着它变成一个正式的名字，挺酷的，给东西命名这件事本身很有意思，然后是客户现场和serverless，怎么和我能想到的最优秀的人，一起从零开始做业务，我愿意再跟他们共事，一直到怎么做首席工程师及服务，怎么帮企业转型，让他们换个角度看SDLC，最难的是，怎么去处理开发者那种身份认同，他们跟自己的语言框架长在一起了，但还得给他们指一条往前走的路，最后怎么在公开场合工作，把产品营销工程客户，以及中间所有环节的。 [00:12:47]
Heitor Lessa：这些线索和角色全用上，对，所以那差不多就是11年，不我很喜欢这段，对先说一句，我职业生涯是从运营开始的，听你说这些，我特别有共鸣，见过那种出大事的时候，火烧眉毛的时候是什么样，而且是在很大的规模上，我希望很多人都有更多这种经历，因为它真的能给你一个视角，让你知道对事情搞砸了是什么样，然后它会驱动你，或者让你脑子里永远锚定着这个东西，一直带着走，绝对，那整个公开构建，你的开源项目突然爆火，这最开始是怎么发生的，你重新把这个做起来吧，它至少能解决我在企业里看到的问题，变成做一个巨大，别人都依赖的东西，而且公开构建是很吓人的。 [00:13:37]
Patrick Akil：对我觉得幸运这个词合适，我有幸在一个团队短暂待过，那个东西你可能听过，叫AWS Well-Architected，所以我帮忙建了他们叫，AWS Well-Architected Lens的东西，就是让你能为公司带来自己的，最佳实践之类的，我写了第一个叫Serverless Lens，那个也很快就爆了，我们大概有，我记得差不多一万个独立评审，还有各种我们叫Workload的东西，比Application更宽泛，六个月之内，这让我看到了一个窗口，我不仅能看SDLC，还能当然出于安全和法律原因，我看不到客户本人，但能看到人们在哪里挣扎，哪里出问题，可观测性是第一个，每个人都有Trace，但Trace里基本没有任何，跟业务相关的东西，我就想，那这其实帮不到你，所以Power Tools发布的时候，我的想法是，我得让这个过程更简单，因为这是那种，我一直在说，但没有展示的情况，我确实有例子，如果你没有这样做的可观测性，那这是你应该怎么做，这是怎么做结构化日志，这是怎么做所有事，顺便说一句，那是2016年，但没有任何东西，能展示一个哇的时刻，几秒钟内我就能有可观测性，能有一堆东西，而且不用觉得我是在放弃测试，放弃我设计应用的方式等等，所以我发布Power Tools的时候，是在reinvent上，本来那应该是一个，关于AWS控制台里，Serverless Lens的演讲，发布稍微推迟了一点，但我分享了一些东西，然后我说，所有这些关于Serverless的架构，最佳实践，安全可靠性等等，这是我正在做的东西，所以我是故意用那个舞台，当时台下大概有3000人来展示，这是能帮上忙的东西，但反响一半是批评，一半是超级正面批评的声音是，只有Python，谁用Python，我当时就下定决心说，那就让Python成为Serverless，最好的编程语言，后来Power Tools就火了，我发布了我们叫，Tracer， Metrics和Logger的东西，就是结构化日志，大家做demo变得特别容易，一旦人们开始在各种newsletter里分享，传到我们叫AWS Heroes，AWS Community Builders的人那里，大家就开始写文章，说这比以前容易多少，然后这东西就有了自己的生命，下一波大浪是合作伙伴，不只是Exavia，还有AWS那边其他几个，开始把它用到咨询业务里，甚至有人在咨询公司里，做了定制项目来落地Power Tools，那时候我就想，行 现在我失去控制了，没错，现在就是雪球滚起来了，对。 [00:16:24]
Heitor Lessa：就是这样，这太疯狂了，在聊软件开发周期，怎么演变之前，我想先说说，基于你的职业经历，我真的很佩服，对吧，我自己在这个领域，都还没待满11年，而你在AWS干了11年，换了8个不同的岗位，接触过几百家公司，AWS是我至今，仍然仰望的一家公司，我不知道现在，正在听的听众怎么想，但至少我自己是，无论是他们的工程文化，还是我跟一些在那里待过的人，聊过之后的感觉，你会给正在听这期节目，心里想着，我也想要类似的经历，我也想做类似的影响，我希望十年后，我的职业生涯也能这样的听众，什么建议。 [00:17:03]
Patrick Akil：我觉得我见过最好的建议，来自我最喜欢的newsletter，跟技术完全没关系，但它是每个人都需要的，尤其是staff以上的工程师，作者叫West Cow，我回头把链接发你，你可以之后分享出去，大意是说，当你到了senior以上，你迟早会撞上一堵墙，就是我还能学什么，我们往往被训练成，只学硬技能，只学技术那一套，然后做到最好，成为房间里最聪明的人，这某种程度上挺扯的，但很多时候，当你试图从senior升staff，或者从staff升principal，硬技能不是不重要，你必须得有，否则你根本走不到那一步，但它们的重要性在下降，因为大部分时间，你花在影响别人，跟人协作，跟人沟通上，那条newsletter里的建议就是，这恰恰是我一直在做的事，只是没人给它起个名字，你迟早会撞上那堵墙，而让职业生涯成长的最好方式，不是学更多东西，让自己在现有岗位上更高效，而是去学相邻岗位的东西，所以我学开发者营销，学公开演讲，学怎么写商务文档，怎么写，怎么成为技术写作者，你不一定真的去做那个岗位，或者转过去，我很幸运，那是亚马逊当时，现在也仍然拥有的一个很棒的时刻，但你可以加入开源项目，开始帮忙改进文档，你能学到很多关于认知复合，人们怎么感知事物的东西，你怎么把非常复杂的主题，拆成简单的东西，我认识的每一个工程师，尤其是senior往staff走的，都在同一个问题上挣扎，他们只会从复杂到简单，从来不会从简单到复杂，这类东西你都可以学，你可以用这种方式，掌控自己的命运，而不必依赖雇主，可能给你的机会，有时候你可以在开源，或者其他地方练手，但这件事，你可以自己握在手里，我特别喜欢这个，所以就是说，你身边永远有那么多东西，从来不是一个工程师，在经营一家公司，你可以学一点销售，学怎么影响别人，说到底，我们无时无刻，不再像某人推销某样东西，一个想法，一个念头，或者试图说服他们，接受一个反共识的观点，如果你愿意这么说的话，所以这些东西对生活有用，对职业也有用，对，任何职业都是，对吧，没错。 [00:19:28]
Heitor Lessa：对，我就是这么做的，纯粹是出于兴趣本能和好奇心，我当时想，我很想看看这个人正在经历什么，那边到底在发生什么，比如我完全没概念，那里有个盲区，让我试着搞清楚，或者让我多学学这个东西，而且不是那种，我有时候觉得有些人挺蠢的，我只是真的想理解，某些决定到底是怎么来的，Gregor其实给过我这条建议，Gregor Hope他说，当一些决定，让你觉得没道理的时候，要知道那都是非常聪明的人，领导团队里几乎不会有蠢人。 [00:20:01]
用全局视角理解复杂决策
Heitor Lessa：领导团队里几乎不会有蠢人，对吧，超级聪明的人，他们能走到那个位置，是有原因的，所以当决定看起来没道理时，大概率是你缺了某块信息，而不是他们缺，绝对，我特别喜欢这一点，因为它重塑了我的思维方式，当某件事说不通的时候，是我缺了什么，对吧，我需要看到更大的图景，才能在我试图达成的任何事情上更有效，不只是我的工作，也包括在这个团队，这家公司里，对，我在进亚马逊之前，就跟Gregor，Gregor，共事过，我很幸运能跟这么多人合作。
Patrick Akil：我以前在AWS负责培训别人成为principal，等等，我觉得我应该给他们的建议，尤其是那些对领导层极度，极度不满的人，有时候领导层给人的感觉像个灵性存在，好像什么都知道，但什么都不做，这其实是谎言，就是当你理解不了某件事，觉得某件事很不理性的时候，比如他们为什么要做这个决定，为什么全是弯弯绕绕，因为你找不到答案，答案是某个地方一定存在一个激励，跟着激励走，有时候就是跟着钱走，一旦你这么做，事情就开始变得说得通了，对对明白了。 [00:21:12]
Heitor Lessa：现在我觉得我们在大语言模型，agent，agent工程，循环工程这些方面进展真的很快，现在行业里有三个人，他们说的话大家会有共鸣，然后大家就开始琢磨，这到底用在哪，还是说这就是扯淡，现在真是挺有意思的时期，而且我看到这对独立工程师特别有效，对吧，我没有其他职责，我就负责构建，我可以埋头干活，我和我那一群agent，我们在一起就是高效，但到了企业层面，这怎么影响软件开发生命周期，对我来说，看事情怎么演变很有意思，因为我觉得每个人都在做不同的实验，有不同的体验，而且我知道你肯定有你的看法，尤其是有你这样的背景，我想深入聊聊这个，今天我们还要做一个，以前从没做过的事，就是会在屏幕上展示，Heitor要讲的内容的可视化，所以如果你是在听音频的话，可能得去看看我们屏幕上，现在放的东西，我觉得一切都准备好了，你能带我过一遍吗。 [00:22:06]
Patrick Akil：我想从产品开始讲起，现在有agent参与进来，产品是怎么演变的，当然，没问题，我要展示的是我个人的看法，是我知道行得通的做法，对，但这不代表它就是唯一真理，就像我说的，现在我们正进入工程的一个新阶段，不只是工程，还有经营企业，我们现在终于能做到，对任何东西进行超个性化，但这也是危险的一部分，因为这样大家可能会错误的以为，工程就是一个独立开发者就够了，或者以为你不再需要PRD之类的东西了，有agent帮你搞定一切就行了，而且这里有个叫，信任与下降恢复的东西，等我们过幻灯片的时候，我可以多讲一点，但先让我给你看产品，这是我们在agent公司里，我所在团队做的一个循环，叫抵抗任务组，这里的目标是尝试，把产品需求文档这个概念，也就是那个有名，或者说有失臭名招注的PRD，嵌入进去，让它不再是一个文档产物，你有了它，然后只给别人看，而是怎么把PRD的精髓，融入整个产品思考阶段，融入工程环节，让它不再是一个文档产物，而是变成人们的思维模型，因为agent会做执行，但如果你把它们带偏了，那就是一团乱，对，所以这个产品循环的全部意义在于，如果你从discovery开始，一路走到slash new work，这个我待会儿解释，这个是不变的，discovery的理念是，如果你做过开源相关的工作，或者做过我史上最喜欢的角色之一，产品工程，那你就必须跟人聊，必须跟客户聊，有时候我们工程师总是抱怨需求不对，我又要重做这些东西，但其实你也可以去跟客户聊，你也可以跳出自己的框框，这个discovery就是我们的方式，先跟人聊，搞清楚到底需要什么，就像agent公司一贯做的，客户中心是关键，但你也不能只听一个客户的意见，你需要一些数据，然后开始排序，找出哪一个解决方案，能同时解决多个问题，这就是discovery的部分，我们试图搞清楚事情，跟人聊，然后下一步就是白板，有点像工程师的设计讨论，你要搞清楚，这是客户告诉你的，这些是客户的分群，什么功能匹配，这些分群或这类客户，哪个功能能覆盖，其中80%的人，就是那个巴尔法则，新手用户，对重度用户，边缘客户等等，所以白板环节是让我们开始想清楚，路线图大概长什么样，因为现在有了agent，那种我们做季度计划，或年度计划的想法，基本上已经崩塌了，但再说一次，不是所有地方都这样，所以你怎么先在白板上做这件事，让它能装进你的脑子里，然后最终，我们得把它固化成真正的路线图，对，但我们也不想把它变成瀑布式流程，因为这在现在也很常见，尤其是规范驱动开发，问题不在哪，问题是我们怎么对待规范驱动，所以我们把白板上所有的东西拿过来，调用一个助手，它叫slash roadmap。 [00:25:15]
Heitor Lessa：在我们去那里之前，discovery和白板还是同一批人在做吗，因为在我看来，那应该是产品人员，或者专门负责某个产品的人在做，这就是产品工程的妙处。
Patrick Akil：如果你身边有一个产品经理和团队在一起，那太棒了，那是个超能力，但并不是总有这种情况，尤其如果你在创业公司，或者某些地方，所以在我们这个团队，就是抵抗任务组，我有时候会简称RTF方便一点，我们没有产品经理，不过我们现在确实要招一个了，这挺酷的，但工程师都是staff级以上的，所以他们得具备一些，这方面的能力，对，所以我大多数时候，需要的时候，就会扮演这个角色，我会去引导一些，和客户的讨论，再带上一位同事，也是一位资深工程师，他能搞清楚客户到底在说什么，还会用一些常规方法，比如梳理用户体验路径之类的，对，你刚才提到，如果你是软件工程师，可以看看自己职责周边的事情，这就是一个很好的例子，对吧，绝对的，甚至像技术负责人的概念，我觉得以前行业里，有些人会把它固化下来，说技术负责人应该懂这些，但产品工程师同样也能做到，这就是为什么我最喜欢这个角色，因为你可以把工程里面，像客户的那一面结合起来，跟客户打交道，思考产品路线图，想清楚我要的结果是什么，而不是实现细节等等，大多数时候，写代码这件事你反而不想去做，因为写完还得维护，所以如果你能不用写代码就解决问题，那太棒了，那就更好了，没错，更好了，但与此同时，你也得成为，我不会说是真相的声音，但有时候是理性的声音，这个结果在业务上很棒，但要实现，它成本会非常高，所以你必须得有技术背景，产品工程师最后就是两边都要做，所以如果你把这些技能都掌握了，这种agent能力就会变成，我能做得更快，明白了，对，然后我们说到斜杠roadmap，这是第一次，在这里你看到的是agent加人类，对差不多，这么做的原因是，我觉得我一直在找一个更贴切的词，来形容我在网上，偶尔读到的东西，就是当我们用模型，用了很久，用情这样的词，用你能想想这个吗，这样的说法，其实是在浪费token，但久而久之，你的大脑会觉得，这就是你现在的沟通方式，但事实并非如此，所以强制自己，先完全不用agent，先想清楚客户的问题是什么，这会比你更多的，用分析性的大脑，用一套你平时，不会用的不同思维方式，所以我想保留这一点，让你的人性面，那种推动，你做出更好解决方案的同理心，不会在某种程度上萎缩，对，所以这个slash roadmap，现在仍然是我刚才讲的，内容里很重要的一部分，但它是agent优先，我一开始是先这么做的，后来发现我的沟通，变得非常简短，非常直接，我就想，我为什么要这样，我不是粗鲁的人。 [00:28:30]
Heitor Lessa：我不是那种人，而且这种事会发生在所有人身上，不管你是什么背景，什么经验，对，所以批判性思维，尤其是在早期阶段，理解客户问题，还有你说话的方式，这些是留在人这边的，对，差不多。
Patrick Akil：如果你看资深工程师，或者首席工程师，首席和工程师最大的身份危机，尤其是资深工程师，就是他们从，让我把这个代码写了，变成，英语现在是我的新编程语言了，这个转变很难让人接受，它带来的影响各不相同，挺复杂的，明白了，不过这个话题改天可以再聊，现在说这个slash roadmap，它简单的有点傻，slash roadmap这个命令的想法是，它会把你在白板上笔记里，或者别处的任何输入，拿去更新或创建一份路线图，比如一份markdown格式的路线图，这没什么复杂的，然后它会有一些阶段，或者想法，或者叫里程碑也行，一旦你有了这个，你就可以说，来把它同步到我们用的任何系统里，GitLab，Jira，随你，我们这边用的是GitLab，它会创建Epic，创建Issue，但slash roadmap一个很大的好处是，有时候，尤其是工程师，我们会忘记，我们总得有一定程度的验收标准，或者说清楚我们想要的结果是什么，对，所以roadmap会强制这一点。 [00:30:00]
Agent驱动的开发循环
Patrick Akil：所以roadmap会强制这一点，因为这样，我就可以把它用进开发循环里，我还有另一个循环专门用来验证，我们到底有没有达成想要的结果，否则代码和任务本身都不重要。
Heitor Lessa：明白了，那这个斜杠是不是意味着，它是一个skill，或者说是一个预先配置好的东西，专门帮你做这件事的，这是一个命令，我们用的是一家叫factory的公司。
Patrick Akil：是factory出的类似cloud code，这类公司有很多，比如很棒的OpenCode之类的，但关键在于，命令的定义是用户主动调用的，而Skill更多是模型自己调用的，我对Skill的使用体验一直不太稳定，因为在Agente，我们坚信要多做选择，多尝试不同的东西，我们不只用Cloud，比如OPUS之类的，我们用的，我记得我账号里，大概有32个不同的模型，不错，那是很多不同的模型，所以他们的体验和质量差异很大，这对token效率和预算来说很好，这个我们后面会聊，但说到到处都用skill，我注意到的是，最终会有很多东西模型直接跳过，或者他们说自己在做，但做的完全是另一回事，所以命令能强制他真的去用，对。 [00:31:15]
Heitor Lessa：而且我觉得这种方式更多是增强式的，对吧，人还是坐在驾驶位上，他们说了，好，现在我们用命令而不是skill，是因为我们要这么做，然后当你往自主AI那边走的时候，才是模型来做决定。
Patrick Akil：好根据这个上下文，我们现在把XYZ这些skill用上，对差不多，我特别推崇这个，因为我在跟各种组织讲的时候，一直强调，人天生就是非确定性的，但现在我们又加了更多agent，那就更非确定了，所以我需要一定程度的确定性，这就是slash命令的意义，确保我知道这些指令，会在一定程度上被执行，明白了，对，接下来是什么，下一个我之前简单提过，就是现在你有了roadmap，它通常会生成一个roadmap.md，放在docs，或者某个文件夹结构里，然后你有一个roadmap的同步，它一般会问你，但如果不问，你就有slash roadmap sync，这个命令会创建所有的epic，所有的issue，并更新roadmap，这样如果你再跑一次，你知道我们是没有确定性的，我不想让他继续创建更多epic之类的，这些产品管理命令的问题，我注意到的是，第一次跑，好去创建epic issue，然后你下次再跑，他又会创建非常相似的，因为我觉得上下文就在那，然后他就一直在自己办自己，所以单独搞一个命令或者子命令，就是为了让这些更确定，明白了，那这些epics像，是不是我们要解决的问题的拆解。 [00:32:47]
Heitor Lessa：最后会落成一个功能，或者一组功能，是产品经理，或者哪怕是产品工程师，来定义那个长什么样，还是agent帮忙拆解这个大问题，两者都有。
Patrick Akil：所以我才把人和agent放在一起，对，你刚才提到增强，我觉得这几乎成了我心的最爱词，就算是我们人类，能想的事情也太多了，我们在agent经常做的一件事，尤其是这个项目，就是做对抗性评审，每当我有一个roadmap，一个计划，一个spec或者什么，你总是会跑多角度的反向评审，看看有没有漏掉什么，有没有过度涉及的地方，或者是不是想把整个海洋都煮开，所以我们有那个环节，但它不是被强制成硬性要求，它有一条指令说，roadmap完成后，做一轮小循环式的检查，看看有没有哪些是相似的，可以合并的，或者哪些没有明确结果，没有明确验收标准，然后用苏格拉底式提问法去追问，直到我们真正挖到底，这是主线，这是你的思路，这是你的理由，这些事不变量，现在我们知道产品需要什么了，但就算做了所有这些，你永远不可能做到百分之百，对。 [00:34:03]
Heitor Lessa：这是我们为了让事情更简单做的一些事，也让人们，我觉得我特别想要这个，我现在负责产品，如果能有一个这样的东西，我确实会跟我的同事这么做，但它没有真正结构化，对吧，现在是比较随意的，感觉你这边有更成体系的流程，确保结果还有决定结果的人都做得更好，对 我觉得还是那句话，这是一种特权，我觉得这某种程度上来自亚马逊的文化。
Patrick Akil：因为亚马逊非常重视写作，你脑子里没写出来，想法就出不来，你得用文档说服人，不是用演示文稿，很多方面这都很棒，因为不是谁嗓门大谁赢，而是谁思路最清晰谁赢，但它也难，因为不是每个人都有那个读写能力，我花了大概四到六年时间专门练写作，那是很多时间，不是每个人都有那个时间，所以我在想，我怎么把这个带到agent的世界里，我怎么把它带过去，又不变成亚马逊那种，写作里有时会出现的毒性，所以最快的招，哪怕你没什么流程，就是一直告诉agent，用苏格拉底式提问法，去挖到底，或者找出我思路里的漏洞，不清晰的地方，光这一条就能逼着它更结构化，你说的苏格拉底式提问法是什么意思，你能给听众解释一下吗，好，苏格拉底式提问法来自哲学，就是你纯粹靠提问来真正理解一个话题，一个问题引出下一个问题，再下一个问题，你在提问的过程中，试图找出对方思路里的矛盾，到最后不是你没问题了，而是你找不到新的矛盾线索了，那些他们说的跟之前说法相矛盾的地方，所以苏格拉底式提问法是一种方式，让你几乎像在调查模式里，但用的是好奇心的视角，你想把一件事理解到最透，但又不会让人觉得你是在审讯，好像对方犯了罪，必须交代什么事的，对。 [00:36:00]
Heitor Lessa：所以当你做那种同行评审的时候，他们用的就是这个方法，只提问，不是那种说我有个问题，然后顺便给个观点的人，而且我猜你也可以跟agent这么干，对，差不多，在亚马逊我有个角色。
Patrick Akil：特别酷，几乎就像铸厂工程师及服务，我有个东西叫discovery，这也是名字的一部分来源，我得在一周之内搞清楚，公司会告诉我，他们没法快速交付，这说法很模糊，可能性太多了，从来不是技术原因，或者他们的工程师，实际做的跟他们以为的不一样，质量不行，也许他们该考虑外部招聘，所以他们想要第二意见，那一周里我得去访谈人，跟人聊，有点像顾问，我的技巧之一就是先说，我们要聊90分钟前70分钟左右，我会问你一些问题，但游戏规则是这样的，你告诉我我有没有不诚实，我不会表露我的观点，我不会带任何偏见，虽然这几乎不可能，人总有判断，但我的角色是试着理解你的视角，搞清楚你是怎么想的，你的心智模型是什么，你对世界的看法是什么，然后我用苏格拉底式提问法，就是不断问问题，然后复述回去，在会议最后20分钟展示给他们，这是我理解到的，我理解错了吗，还是有别的意思，然后我会重复，直到我得到一个图景，好这些就是模式，也是agent很擅长做的事，有些事情从权力位置，或管理位置说出来，听着像真的，但当你往下挖，会发现很多误解，错误信息。 [00:37:33]
Heitor Lessa：或缺乏透明度，而开源某种程度上，解决了这个问题，明白了，这看起来是个很有意思的技能，我也可以直接拿来实践和试验，对吧，我不必说，我现在要用苏格拉底式提问法，我只要不断问问题，希望别问的太烦人，让大家把想法往下钻，我们就能搞清楚，他们到底想做什么，对，这基本上就是我在agent里做的事，我实际上在强迫agent。
Patrick Akil：用这种方式跟我对话，对，有时候会变得很烦人，因为他们会说，你对我来这套，我知道你在干嘛，但我觉得这最妙的地方在于，我们经验越多，就越容易直接跳到结论，越快说出，我以前见过这个，然后你觉得世界都围着这个转，用苏格拉底式提问法的思路，或者说，咱们做70分钟调查，只问问题，如果我太严厉或太有攻击性，你告诉我，我就降低点强度，但提前把预期设好，手里只有纸笔笔记，只问问题帮助很大，对你也用纸笔记，有意思，对我有个角色，抱歉，信息太多了，没事，你说，当我从天哪，你来了，咱们解决一切，生产挂了，那种角色转出来的时候，救火队员，对，有时候也像，北国侠，没错，就是你，就是你，没错，当我转到另一个完全相反的角色，叫解决方案架构师，我们现在有点像叫前部署工程师，我得去见那些客户，那是他们第一次见到我，他们说，天哪，太棒了，诸如此类，但他们有太多东西想分享，或者更糟的是，因为这是商业世界，所以我需要，我身边总跟着一个客户经理，我从他身上学到，很多关于影响销售的东西，我看到了，销售不是你想卖东西那么简单，你是在建立关系，哦，原来如此，而秘诀就是纸，我从这个角色里学到的是，我总是在一个重要会议之前，开个预备会，比如高stakes的会议，我会用我的纸，提前准备两三个问题，准备一段我总会说的话，这些是主要结论，或我们要做的主要行动，然后围绕它展开，我做了几年之后，注意到我只用纸，顺便说，现在我也只用纸笔记，现在还这样，还这样，对。 [00:40:00]
纸笔会议与团队协作
Patrick Akil：对，好，我开始用不一样的眼光，看事情了，我去开会的时候，看到有人抱着笔记本电脑，我就知道，他们不会把全部注意力放在这，因为你和面前这件事之间，永远隔着一堵墙，哪怕大家不是有意要这样，但事情自然而然就变成这样了，而用纸的话，你基本上就是全身心在场，你是敞开的，所以这更像是一种，我不会说更有同理心的方式，但它确实给你一个优势，因为你能看到肢体语言，你能看到通常70%以上的沟通，都是非语言的，就是肢体语言本身，所以用纸给我带来两个笔记本电脑，永远给不了我的优势，用笔记本电脑，我打字总是比我的思维处理，消化信息的速度快，这是个劣势，用纸则相反，我写的总是更慢，因为我在处理，我已经在消化那些信息了，用笔记本电脑，我通常先记笔记，然后还得再花时间想，我到底打了什么字，我理解了什么，记下了什么，用纸的话，我是同时完成的，有个东西叫双通道理论，这个可以以后再聊，但他给了我笔记本电脑，永远给不了我的东西，那就是，我可以问你一个问题，比如一个引导性的问题，或者模仿你对我做的某个动作，而当你回答的时候，我可能已经准备好了，两三个后续问题，或者我可以先写下一个问题，不去打断你，这样你的思路就能自然流淌，也许你刚好已经回答了，我本来想问的问题，那我就直接滑掉，这样一来对话就变得更自然了，而且对方会觉得自己被听见了，你们之间建立了连接，用纸的话这些可以做得非常快，所以我可以引导对话，去任何我们想去的地方，而且不会让人觉得，我是在强迫你，或者做了什么不好的事，我确实意识到了，笔记本电脑会形成的那堵墙。 [00:41:57]
Heitor Lessa：有时候嘉宾分享一些东西，我会想我想试试这个，我内心有那种冲动，我想试试，但我也不是真的喜欢，整夜整夜的写笔记，我试着做的，这真的是我的方法，而且这真的很看场合，因为有时候我确实需要随手记，我尽量能记多少记多少，可能做播客这个场景，坐在主持人这个位置上，要提问，要推动对话，这本身就帮助我去记，去内化，还有在话题被放下之后，重新捡起来，但这是我的方法，然后会议一结束，如果那是个重要的会，我就会去记笔记，因为我也想之后能回看，而且现在我打字越来越少了，所以我一结束，就点开语音转文字，来吧，把零散的念头都倒出来，而在我说的过程中，我觉得这可能跟你说的写字有科比性，我也会获得清晰度，因为我打字可以很快，笔记可以很潦草，东一句西一句，但当我开口说的时候，我会努力把话说清楚，所以突然之间，我就需要把自己的思路理顺，这意味着我得放慢说话的速度，而且思考本身也要有清晰的条理。 [00:43:04]
Patrick Akil：这正是我们用纸质笔记的原因，因为它是一种强制机制，逼着你慢下来，在agent出现之前，我们一直有这个问题，现在有了agent，问题更严重了，我们拥有的信息多到不知道该怎么用，对，能够对某件事进行推理，然后领先一步，这就是只能给你的东西，从页面底部往上数五行，画一条横线，那条线以下你只用来写问题，但别写完整的问题，因为那不可能，你速度不够快，不然的话，我们正在说话，你还在写，那就更糟了，所以你要做的，是写一个关键词，或者能提醒你，我想问这个问题的东西，然后你问出去，然后它过去了，然后对方还在说的时候，你已经有了第二个问题，这样对话就更自然了，明白了，不是的，原始纸质笔记，不是让你把每句话都记下来的，对，它只是让你有个念头，这是我想问的问题，大概的框架，这是会议结束后，我们应该滑掉的下一项，诸如此类，这就足够了，你不需要记一大堆，他们说了什么，因为整个目标，就是让你人在那里，心在那里，给人留下一个好的，积极的印象，然后我基本上，就能达成某件事，或者同意某件事，我们开会唯一的原因，有些开发者很讨厌开会，是因为我们想法，总是不一样，我们总有不同的观点，所以一个会议，一个好的成功的会议，一定要有我喜欢的东西，那就是，我们一开始为什么要开会，成功的标准是什么，这样你去开会的时候，每个人都知道，我们为什么坐在这里，如果我们没达成这个，那这个会议，尤其是如果它是定期会议，对，就应该取消，那就是失败了，对，它没起到作用，但如果它起作用了，那就太好了，现在你有了笔记，下一步该做什么，虽然不完美，所以记笔记这个想法的好处在于，你现在能读懂排桌了，销售里还有其他很酷的技巧，但你可以靠读排桌，逼自己慢下来，这样你就能理解，人们是怎么说某些话的，如果你打字记录，那个人说了某些话，但他们当时是什么感受，他们是不是很恼火，他们其实更积极吗，他们是不是那种，对我们就是这么干的，这比你在警察局里找个书记员，光打字记录下来的内容，信息量大得多，我们不是书记员，对吧，我们该做的是理解，知道下一步往哪走，对，这对我启发很大，因为我本来在想，把完整问题写在纸上，然后觉得，天哪。 [00:45:40]
Heitor Lessa：我写字太慢了，我想试这个的话，得先把写字速度练上去，但我在笔记本电脑上，记的时候，用的也是关键词，所以这么试就说得通了，我打算试试，我觉得会挺有意思的，一定要试，播客录完之后。
Patrick Akil：我给你看看，我的一些纸质笔记，我甚至在想，我是不是也该在播客场景里这么干，就像那样给你看看，我确实这么干过，我以前做直播之类的时候，也会这么做，对非常快，就像记者一样，就像你那些东西会让你觉得，天哪，我从来没这么想过，你见过记者采访的时候，带笔记本电脑吗，他们绝不会这么干，他们总是带点快速的。 [00:46:21]
Heitor Lessa：纸质笔记之类的东西，对，这就是原因，明白了，对，我们聊了从发现阶段开始猜解，把你遇到的问题猜成epic或者issue，猜成某种更容易消化的形式。
Patrick Akil：那之后是什么，现在我们有了路线图，一个主要的事情就是这种判断，我是不是真的把所有东西都捕捉到了，因为人类想要，我不会说不是每个人都有完美主义倾向，我有这是个问题，我建了一些机制来防止自己太完美主义，不然我什么都做不成，你有了路线图，但通常的感觉，尤其是对工程师来说会是，如果我开始实现这个会怎样，做到一半我发现，我漏了什么东西，或者我没有，我以为自己有的那种清晰的思路，因为有时候你真拿到代码了，会发现更多东西，哪怕你已经跟客户聊了几百个小时，这很正常，然后我们有个叫slash new work的东西，这也是另一个命令，它的作用是弥合你在实现某件事实的那种差距，尤其是现在agent最大的问题，就是那种，就再多做这一件小事，我顺手就做了，太便宜了，你想让我做吗，他甚至会主动问你，对就像在说，不别别别，别在这种意义上，喂养我的独行人格，就再多做一件事，对不别这么干，这不是那种，史蒂夫乔布斯式的东西，有时候你想捕捉那个想法，留到以后再做，有时候它真的是，计划里的一个洞，但这个洞，不是你一开始就能预防的，只有你在实现或做事的过程中才会意识到，所以slash new work会接管你的上下文，然后你可以说，你知道吗，我刚发现了这个，但听起来我们需要为他建一个issue，然后他就会创建一个新的GitHub issue，或者Jira之类的，并把它关联到一个epic上，这样工作就始终是可追溯的，明白了，所以你可以在整个实现过程中这么做，或者你知道这是一个新绘画，让我就这么做，因为你还没有它，所以两种方式都可以用，有意思，我是那种对某些事，我有点完美主义。 [00:48:30]
Heitor Lessa：但对某些事，尤其是我们软件工程的方式，我觉得我们需要一定程度的务实，因为随着你往前走，随着你开始，你会学到新东西，有时候90%的路，其实已经很完美了，你就保持那个100%，因为最后那10%，永远不会被优先处理，这是我目前的做法，甚至有时候我在这方面的想法有点过头，太非黑即白了，所以我也需要有人来平衡我。
Patrick Akil：跟我说这个其实因为某某原因还是很重要的，所以对于我觉得这会挺有意思的，但这正是它的美妙之处，这也是我不喜欢听人说，我在用agent，我现在生产力提高了20倍，100倍的原因，不管是在个人场景还是团队场景，因为我们不是独自工作的，就算你说你独自工作，你在做一个开源项目，所有事都自己来，最终还是会有人来用，来问你问题，所以你还是会有一定程度的协作，所以对我来说，以前带团队的时候，我一直在做的，就是把人往他们的墙上拉，看看什么能互补，而不是说，这些人只能做这个，什么才是真正对团队有增量的，因为如果让我建一个团队，我肯定想要一个像你这样的人，他会说等等，我们这是在试图，主废整个海洋，务实一点，然后接下任务，把活干完，但我也想要一个会说，你真的把每一个边界情况，都想到了吗。 [00:50:00]
验证工程最后百分之十
Patrick Akil：都想到了吗，我们有没有做更多的验证，的人，这是工程里最难的事情之一，把最后那10%，或者说最后5%检查一遍，因为有时候，有些关键任务，关键应用里，这些东西不是锦上添花，而是入场门槛，对，对。
Heitor Lessa：我很喜欢这个说法，真的要看具体，用力来决定，你需要哪种思维模式，而团队里同时具备这两种人，就能让你在解决各种问题时，非常灵活，对。
Patrick Akil：而且我这周刚好聊过这个话题，我们有一位非常资深的工程师，想理解这次重组是怎么回事，但又不用去深究内部细节，因为没必要分享那些，但工程师们通常会把重组看成，又来一次重组，天哪，我们又要改了，我们没有重点了，但有时候组织也是一个活的生命体，就像软件一样，你改变某样东西的时候，你可能看不到全貌，就像我们讨论的这些碎片，他们不理解，领导层也不理解他们在做什么，诸如此类，但这只是在为组织下一次做出重大改变做准备，就像我们做软件，你不会简单的说，agent去把整个代码库重构到rust，因为我喜欢RUST，它可能能跑通，可能把额度用完，可能会一团糟，但你要做的是让这件事更可控，你要做的是准备好代码库，让agent知道这些是有效的模式，这些是不该做的事，这些应该被Lint工具拦住，而不是靠一个对抗性的评审者，否则你就在非确定性上花太多时间了，而一旦你有了这些，然后你做一个改动，它能跑吗，然后再做下一个，明白了，对。 [00:51:43]
Heitor Lessa：那当工程师真的拿起一个任务，一件需要完成的事实，那是什么样子的，跟传统方式很像，你拿起一个issue。
Patrick Akil：然后说agent去做这个任务，agent就会去做，因为issue已经有模板了，你已经知道它是结构化的，如果你已经有了模板，你就已经写清楚了，这些是预期结果，这些基本上就是验收标准，问题是什么，可能的解决方案如果有的话，然后他们就用agent来驱动一切，agent会有一轮对话，比如我怎么在实现里让它跑起来，这个用力站得住吗，它有没有什么权衡取舍，也许这是个好时机，翻到下一张幻灯片，给你看看开发周期长什么样，那就来吧，它比看起来要复杂，我尽量让它简单，但我们用了一个叫open spec的项目，这是我在规范驱动开发里，最喜欢的项目之一，OpenSpec的想法，跟所有规范驱动开发相关的东西一样，是你先有一个讨论，头脑风暴的阶段，试图搞清楚解决方案可能长什么样，我们需要数据库吗，需要持久层吗，需要测试吗，我们怎么测这个东西，我们用端口和适配器，我们用六边形架构，我们怎么让它可演进，有太多问题要问了，而这个OpenSpec Explorer，用苏格拉底式的方法，一直问你问题，直到把你的设计问到底，它永远不会是100%，但它能让你达到够好的程度，我怎么测这个，我怎么组织代码库，或者这个功能，这样当我读文件的时候，我知道每个文件扮演什么角色，我能看到一定程度的架构，所以Explorer就是那个任务的头脑风暴阶段，但有时候务实主义就要介入了，你不需要所有这些重型机制，就为了改个颜色，或者加个下拉菜单，为一个下拉菜单，搞一整套OpenSpec流程毫无意义，那你就直接写个prompt搞定，然后我们后面还有验证层，来确认我们是否真的达到了，issue里路线图里描述的预期结果，这样就把工程师个人和agent，都要做到完美的压力卸掉了，明白了，OpenSpec我试过，如果你在听的话。 [00:54:03]
Heitor Lessa：屏幕上现在有一张新图，展示的是开发循环，我想说，对，它从探索开始，对，那是agent和人类一起，上面还写着SOTA，就是state of the art模型，没错。
Patrick Akil：所以你会用能力更强的模型，去探索需要构建什么问题，对 完全正确，agente的一个不同之处，顺便说一句，我很喜欢这一点，就是我们不是那种，为了赶时髦而用某样东西的公司，我们主要在想的是，什么才能真正解决商家的问题，我们怎么让商家用上这些技术，去获得更好的利润率，忠诚度等等，就是所有我们想解决的问题，而说到AI，技术上我们确实可以只用SOTA模型，只用OPUS，只用GPT 5.5之类的，但那样最终是要付出代价的，而且就像开发者常说的行话，要选最适合工作的工具，你不会想一直用同一个，所以在我们流程里，我们通常用三个不同档次的模型，我们用一个叫最佳模型SOTA的，用来帮我理解，帮我探索，不要做任何事，不要创建任何文件，就是禁止你创建任何东西，你必须在创建任何东西之前，先请求许可，有钩子，有办法可以阻止它，而这也是我发现那些超大模型，极其高效的地方，尤其是如果你用像Fable这样的工具，它在规划方面非常出色，所以一旦你有了计划，进入比如说实施阶段，那你就可以用更多中档模型，取决于你规划的内容，然后你可以用更小的模型，尤其是开放权重的，做一轮又一轮的审查，非常高效，这样你的财务部门会很高兴，而且你还能更有效的利用预算，这也是我们现在在agent和AI方面，还在摸索的事情，现在我们在进入那种，对什么都用的阶段，token拉满，这不是我喜欢的做法，但最终那个成本会来的，然后当领导层开始质疑，等一下我需要为一个工程师，每月多付5000块3000块，就为了让他们干活，这笔账算不过来，对一个工程师，几个工程师来说，当然没问题，我的意思是，对大公司来说，那只是零花钱，尤其是在企业级，但当你看到Agenti的规模，比如我们有1400个工程师，这笔账很快就显现出来了，对，而且会引发质疑，但不是说我们就会说，我们永远不会这么做，而是我们必须更明智一些，这是我们还在摸索的事情，没有人对这一切有最终答案，不然我们早就把它卖掉了，对，我们早就已经在用了，对，对完全正确。 [00:56:51]
Heitor Lessa：那么在这个想法里，具体来说，你设想这会是一个指导，一个准则，一种教育，关于我们作为软件工程师，在软件开发生命周期里，如何工作，特别是在你的环境里，在你的组织里，还是说你会一定程度上强制执行，因为1400个人要承担这个责任，这就是我们的工作方式，然后他们又有能力不这么做，只用最先进的模型，我有点想知道你的想法是怎样的，对。 [00:57:17]
Patrick Akil：我来自云计算的背景，首先，懂云的人会理解这个，在云计算里，大多数组织遇到的第一个冲击是，我以前很清楚我为服务器付多少钱，哪怕花了几千块，对，然后它会随着多少年折旧，对吧，多少年，简单的数学计算，你懂的，对完全正确，听起来很简单，就像对资本支出和运营支出的区别，然后云来了，就像你什么意思，我不知道我下个月到底要付多少，这听起来不对，就是这样，走吧，没错，所以当你看到云带来的生产力和好处，弹性自助服务这些，你会觉得，我懂了，但我也不是想让所有人都用这套，因为不一定适合每个人，到某个点上，你必须信任人的判断，不然当初干嘛招这个人进来，但与此同时，你也得在建议模式，软件之上加一些护栏，来帮你把关，说到AI，尤其是在agenti，我们有一个平台工程组织，有一个很棒的团队，专门在搞这个，他们现在的一个核心问题是，在agent时代，SDLC，也就是软件开发生命周期，应该长什么样，我们要铺出什么样的康庄大道，那些我们确定可行的路，但永远不会只有一条康庄大道，它会根据不同的画像，不同的应用场景铺出不同的路，这是个webhook吗，这是个关键业务流吗，你在处理欺诈场景，你不会为了一个欺诈检测的东西去省token，那是大事，但另外我们用哪些工具，现在AI的一个大问题是，我可以用open code，有时候我用Cloud Calls，有时候我用别的Amazon的Kilo，Kira，到处都是散的，其实云时代也一样，没什么区别，但在Agente，我们具体在做的是找到那些定居者，在组织里，哪些人是在探索新东西的，我们要密切关注他们，看看什么有效，什么是炒作，什么不行，这也是我团队的一部分工作，然后有了这些经验之后，我们怎么再拉两三个团队来做实验，我们用OpenSpec吗，还是用别的，OpenSpec在Agenti的一部分场景是能用的，但大部分场景根本跑不起来，因为我们有一个巨大的monorepo，这本身不是坏事，所有上下文都在里面，但Agent有时候不太喜欢，因为信息量太大了，对，而且OpenSpec本身没有在monorepo里工作的概念，它默认所有东西都在顶层文件夹里，但当你有成百上千的开发者。 [01:00:00]
在大型代码库落地Spec
Patrick Akil：但当你有成百上千的开发者，都在动这些代码，冲突就来了，各种问题都来了，那我们现在怎么让他，对一部分开发者先跑起来，然后再怎么过渡，怎么一步步挪到，这个更大的mono repo上，这样他就能覆盖，agente的核心业务，所以我们这个团队，就在想这些事，从限制的角度去想，云做的特别好，也塑造了整个行业的一件事，是如果你让AWS Lambda，这样的服务，直接跟你说，你可以随时跑10万个容器，发个请求就行，基础设施我们来搞定，但当你成立几百万个客户的时候，你就得做大量的容量规划，而且这可能是错的方向，你第一个应用，凭什么就需要10万个容器，没道理，所以限制能帮你加一道软护栏，让你发现，你到上线了，我们可以给你提，这没问题，反正都是虚拟的钱，但让我先了解一下，你实际是怎么用的，你只用Sota模型吗，这样它就变成一种教育性的，带着好奇心的对话，而不是我的方式，就是大家的方式，这是我们的门槛，IT就该这么干。 [01:01:09]
Heitor Lessa：所以这更像是一种IT服务，而不是平台工程，明白了，所以你其实是给了工程师，很大的自主权和所有权，但内置了一个对话出发点，因为不管用什么，总有预算限制，对吧，你想用Intellij，那有授权费用，所以内部是有预算的，而模型这块，SOTA模型现在是按量付费的，所以大概在某处有个上限，当你出到上限，那就是你开启对话的契机，聊聊你是不是只用SOTA模型，还是说我们可以用更聪明的方式，这就是教育发生的地方，差不多我们还会作为公司，但都是平台工程在做。
Patrick Akil：跟其他什么积分没关系，他们会有一个内部网站，上面有各种模式，这是大家实际在用AI做什么，这是如果你用open spec，什么做法能成功，这是公司里你应该去聊聊的这些人，这是你用超大模型时的指南，这是你用终端模型，小模型，开源权重模型时的指南，这些都写在上面，但如今这个时代，没几个人会去读文档，所以它就变成了一个自我实现的循环，你出道上线了，我来找你聊聊，一起想办法，也许你根本不知道有那份指南存在，就像解决方案工程师，我们现在叫forward deployed engineer，又或者指南本身不够用，它大多是隐性的，那怎么让它更显性，也许我们需要更多工具，也许可以做点我现在正在实验的东西，叫autosizer，在agent动手实现之前，别一上来就说，我来搞定，我是英雄，先让他想一想，这个任务需要一份spec吗，还是直接加个prompt就够了，当然，永远不可能，百分百确定，但至少你能加这么一层，别搞得像不行，我只能这么干，这些就是你的选项了呀，对，这从来没能阻止任何人，搞出影子IT。 [01:03:07]
Heitor Lessa：他们还是会去搞，对，绝对的，对，对我们工程师就是倔，特别倔，不我也喜欢这一点，我在我自己的处境里，也在想同样的事，这些做法到底怎么才能规模化，我跟你想法一样，有人撞上预算上线，这就是个话头，能不能学，能不能教，你知道有XYZ这些东西吗，对我来说理论上行得通，但当我们面对的是1400个人的时候，这种对话怎么规模化。
Patrick Akil：这个你也想过吗，想过我是说还是那句话，这是种特权，在AWS的时候我管过，我记得当年我培训过，怎么说呢，8000多个架构师，因为我运气好，是最早的那批人之一，那时候有个模式，先读文档，或者你不想读的话，用AI帮你总结，有些工具能让你的日子好过很多，因为你要尽可能把这些东西固化下来，就像我做Power Tools那样，如果你把它固化到一定程度，让它成为工作流的一部分，那人们撞上上线之类的时候，根本不会觉得意外，然后你还有常规的那些东西，比如内部聚会，内部社区建设，还有到处培养冠军的想法，不只是agente，我们也在做这件事，但亚马逊在这方面特别出名，我在亚马逊特别喜欢的一点是，比如我去面试的时候，会有抬杠者bar raiser这个概念，就是有个人面试经验极其丰富，面过几百号人，他们通常不在你的团队，甚至大多数时候都不在你的组织里，完全是外部的人，但你知道可以信任他们，如果他们拿到了那个认证，你就知道他们的标准一定很高，所以冠军这个想法，就像培训认证和分级一样，这套东西很成熟，这是同一个模式，我们现在面对的东西，不是什么新鲜事，变得只是你上路和撞墙的速度，但你处理问题的方式。 [01:05:03]
Heitor Lessa：你看事情的角度是一样的，明白了，我喜欢这个，这不只是我们只做这个，而是我们做这个，这个还有这个，确保我们把方方面面都覆盖到，这样我们才有信心去教育人，确保他们觉得自己有能力，有装备，去搞定自己负责的那个结果，因为那才是真正的赋能，差不多，如果你去看软件本身，我特别爱干这事，当年我跟团队。
Patrick Akil：跟社区一起做power tools的时候，每天就我一个人，我最大的挑战是，这个东西有多强的倾向性，有多少只是因为我们觉得自己对，所以就成了一个意见，因为这种事会发生的，自我膨胀哪都有，又有多少是我们干脆放手，让他们自己做决定，只给他们最基本的东西，这一直是最难的事，所以你看软件的时候想想，如果Java给了你全套标准库和一堆东西，Python Go也差不多，那为什么人们还是不停用框架，大多数时候是因为你不想做决定，你想尽可能少做决定，一旦你在自己的处境，自己的问题空间里想明白了，哪些是你不想做决定的，哪些事让人产生决策疲劳，比如这个跟结果没什么关系，不会大幅改变最终产出，那你就把它固化下来，自动化，把决定拿掉，agent基本上也是一回事，我们刚聊的roadmap这个想法，还有搞一个像思考伙伴一样的东西，用很激进的方式，苏格拉底式的方式，一路推到一道闸门，就是我们后面要聊的merch check，那个东西一开始连我自己都讨厌，但现在我在改进它，它存在的意义就是，把你从那些事里救出来，同时也是不逼你去做那个决定，因为我们一天能做的决定就那么多，在那之前我们就已经累了，在读完agent吐出来的那一大堆文字之前就累了，所以这些东西会找上你，明白了，对这个工作流里下一步是什么，接下来是真正的计划，一旦你想清楚了，知道自己要做什么，Open spec plan就会生成实际的产物，这就是标准，里面有spec设计文档还有任务，我们不用原版的open spec，我学到的是，OpenSpec最大的威力在于，你可以把你想要的工作流固化下来，这太棒了，因为你总是会有一个必须存在的Spec，其他一切你都可以自定义，你可以加很多关卡，很多产物，想要的话甚至可以加PRD，这个阶段我们引入了形式化验证之类的东西，这是一种让你指定系统应该如何行为的方式，不变量是什么，有哪些状态从一开始就不该出现，想想Outbox模式，你往数据库里加一条数据，一个事物，然后你再加一个条目，可以用作对列，比如放一个事件什么的，那个outbox通常总是处于这样的状态，要么已经持久化了，要么正在持久化中，要么失败了就该重视，所以如果出了这个范围，那就是错的，这些东西你不能用普通方式固化，我们用一种叫fistbee的东西，我特别喜欢，但还有很多其他的，比如cla加quint，当你这么做的时候，agent在实现层面就能更精确的知道需要做什么，因为英文对我们人类来说从来都不精确，所以这个计划会一次性生成所有这些，它生成spec，列出所有验收标准，因为这是从roadmap来的，它列出我们想达成的结果是什么，整个设计，go和no go，测试策略是什么，我们测试是为了什么，需要模糊测试吗，需要基于属性的测试吗，测试是必须的，但还需要什么，我们是为了测试而测试，还是真的需要，一直到这涉及UI变更吗，如果涉及我们要用哪些组件，我们要跑对比测试来检查，无障碍性之类的东西吗，所以涉及非常全面，而且是我们自定义的agent，看一眼就懂了，然后任务基本上是这个的原子化版本，先做这个，然后我们做后端，也就是API，它会覆盖这些，如果这是破坏性变更，我们的迁移策略是什么，先做什么，什么可以并行，什么必须串行，你的建议是。 [01:09:23]
Heitor Lessa：从OpenSpec开始，然后看看在你的软件开发生命周期里什么，对你重要，尽可能把它固化下来吗，还是说已经有一些框架或者开源资源，人们可以从中获得灵感，抢占先机，我总会建议。
Patrick Akil：从简单的开始，然后加入你自己的东西，错误在于选择OpenSpec TLC，它确实很好，是目前最先进的，或者用Amazon Key之类，已经内置好的东西，然后把它当成唯一的方式，因为每样东西的运作方式都不一样，尤其是在AI领域超个性化，所以美妙之处在于，你先开始从而理解，Spec驱动开发的循环。 [01:10:01]
Spec驱动开发的核心循环
Patrick Akil：Spec驱动开发的循环，你必须有一个Spec，必须有一个设计，必须有任务，这就是核心，但你的设计长什么样，你能做的传统任务质量如何，这些必须来自你自己，所以你可以从任何东西开始，OpenSpec我觉得是最简单的，你只要安装OpenSpec，然后运行OpenSpec Explorer，它会引导你完成一切，别的什么都不用做，但别停在那里，如果停在那里，那就是个错误，因为那意味着你可能没有流程，也可能没学到多少，关于软件正确性的东西，所以默认效果，基本上就跟你用的模型一样好，那可不怎么样，对，你从原版OpenSpec，到现在的版本速度有多快，中间花了多少时间，去固化人们的想法，组织和推动者的观点，这个嘛，从OpenSpec的初始版本，到自定义工作流，我大概花了一个月，好，但你要达到，这在一个团队里能跑通的程度，那花了整整三到四个月，明白了，主要是因为我和其他人一样，Opus是我的神，我走到哪都跟着它，就用它，然后我开始每次迭代的时候，都是这又花了5000万token，对，然后我想我做了一次重购，是关于我怎么做前端的，我现在在做一件我特别喜欢的事，叫local first架构，就是那种天哪，我要是早知道就好了的感觉，这次重购花了我将近两亿token，然后我就想，我得停止用opus了，这不行，太费了，没错，然后我试着用开源权重模型，比如Kimi，GLM之类的，那是四个月前的事了，实现质量差太多了，质量上它开始对我撒谎，其实Opus也会撒谎，所以那花了我更多时间，我可以固化这些东西，但当我试图省token，换不同模型的时候，就像换不同的框架，换不同的编程语言一样，所以我得非常小心地学习，怎么构建一个验证循环，现在这叫loop engineering，这样我才能把它变成更接近商品的东西，理想情况下，这也是我们应该前进的方向，对，所以这部分花的时间长得多，我大部分时间都花在这上面，怎么把SOTA模型，最先进的模型放到这里，然后放一个流星，再放一个很便宜的模型来做审查，但能力依然很强，那来回折腾了很久，我现在正在做的这部分，也在幻灯片里，我再搭一个，它不会完美，永远不会完美，但我在尽量追求完美，说实话，我在试着搭一个，对几乎所有模型都适用的东西，让我能信任他们，哪怕他们伪造证据，伪造说他们跑完了任务，试图从网上复制粘贴结果，他们确实会这么干，我怎么确保这种事不发生，所以我没时间审查的代码，我不会放进来，明白了，我怎么确保，哦，还有一件事，我们总是这样，我怎么确保，我遇到的最大挑战是，当你走这个循环，用open spec，走spec driven，那在软件正确性上，应该能到1995%的质量，但总会有你想改的东西，这时候循环就来了，因为你现在开始，临时起意的写提示词，然后我得记得去跑审查，跑某些东西，这时候就开始崩了，掉进一个我在亚马逊学到的坑，叫良好意图，你指望大家记得，哦我们得跑这些，你可以做CI门禁，但也就到那一步了，所以这就是我现在花最多时间的地方，我觉得这会花掉我，不是花掉是还要再投入一个月，才能做出一个，在我团队之外也能用的东西，对就像人们偏离了你铺好的路，而你想设一些原则，确保他们能回到正轨，正是我们聊过的，对你不想说只有这一条路，因为没人知道，永远不可能只有一条路，真相总是碎片化的，对吧，真相有多个版本，你得接受某些事实，对吧，我们不想不小心，把这事搞成政治话题，但有了agent，每次anthropic出故障，每次有新模型，每次发生点什么，我注意到有很深的不平等，但这很难衡量，做基准测试也很难，我现在也不太信，这些基准测试了，我得有东西保护我，免受这些偏差，这些质量差异之类的影响。 [01:14:30]
Heitor Lessa：因为我们面对的是，非确定性的东西，对吧，对你刚才提到LFA本地优先架构，还特别说我真希望早知道，这个能给听众解释一下吗，哎呀这又能录一期播客了。
Patrick Akil：本地优先就是想象，我换个方式说，通常我们搭架构，是有一个服务器，在某处云端本地部署，随你说，然后有个客户端，它基本上得跟那个事物打交道，API请求之类的，通常API服务器在某个地方，不在客户端上，而在客户端，你通常会有一定程度的缓存，看你在处理什么，但现在有更新的技术，浏览器能做的事强太多了，我给你举个我正在做的例子，以及为什么我不得不这么做，这是个工程挑战，我们在Agente，在全球很多地方都有办公室，我现在在搭的应用邦尼，它有点像Well Architect工具的克隆版，但更好，在我看来像一个工程师会做出来的东西，这是在阿姆斯特丹达的，我们是本地部署，就算放云上问题也一样，现在你想让新加坡，芝加哥，旧金山的人也能做审查，试着做实时协作审查，光延迟就让某些事不好玩，而且会很费劲，有时候你还会遇到这个问题，如果我要上传一个，不知道100兆的附件，那也会有，因为物理定律起作用了，你怎么解决，通常你会想，解决这个问题很容易，我加一个CDN，它给你提供静态资源和某些内容，帮你做TLS握手，TCP握手，但那并没有真正解决问题，那基本就是创可贴，最后会有更多问题，所以天才可能会想，我直接用分布式数据库不就行了，用Cockroach，或者到处都用Postgres，然后到处加节点，但这样一来，你面对的就是同步问题，你搞出了一个分布式系统，祝你好运，这没看上去那么简单，所以local first这部分要解决的是，怎么让世界各地的人，获得同样流畅的体验，就像Git一样，我大部分操作先在本地完成，你可以想象成，对本地数据库做事务操作，然后我在同步那些，真正需要同步，需要让它工作的部分，这样一来，你就把问题倒过来了，你构建的是一种分布式数据架构，客户端现在成了事实来源，这通常是闻所未闻的，然后你再同步到服务器，因为你总得有个聚合的地方，所以Local First架构的原则就是，你做的所有事情都先在本地发生，但它并不妨碍你说，页面的这一部分应该从服务器来，比如分析数据在本地做毫无意义，因为你会把用户的存储撑爆，对吧，所以现在有个新技术叫OPFs，如果我没记错的话是Origin Private File System，如果服务器也就是HTTP服务器，Web服务器返回两个HTTP头，叫CAP，我可以解释起来很长，但Local First会告诉你，这能让浏览器解锁一个叫VFS的功能，也就是虚拟文件系统，我现在可以把文件持久化到你的机器上，哦，这很厉害，对，但它是个沙箱，有一堆限制，肯定得有，这是好事，对吧，这是好事，但它让你能做到的，就是local first，这个理念，现在当我加载我的应用代码时，不管它是什么第一页，也就是那个壳，给你展示点东西，它是个引导程序，用来下载一个CircleLight WebAssembly，装到你机器上，创建一个新数据库，跑完所有表，迁移等等，几分钟的事，100毫秒，然后所有事物，都在本地发生，好，现在你的服务器，更像一个同步引擎，对，而不是那种很大的API之类的，这让整个体验变得，这太棒了，感觉非常流畅，几乎感觉不到延迟，因为所有事情都在本地发生，它也带来了不同的挑战，那当然，发布现在有点像开源那样，你不能搞坏客户端，对吧，你得从一开始就考虑自愈，你得更仔细的考虑迁移，但你也有很多其他好处，你的服务器，你的API，变得精简的多，你剩下什么，你有一个引导程序，一个拉取，一个推送，还有一个工作区投影，只根据认证和授权，来同步特定用户的数据，我得好好研究一下，这个听起来太迷人了，确实，我真的很喜欢，喜欢到什么程度呢，我让一个agent，去看了我正在做的那个项目，我说你看，我想要另一个local first架构，而且优先考虑隐私，所以没有任何数据库，没有任何服务器，所有事情都在本地发生，作为帮我准备年终绩效评估，和年度绩效评估的工具，所以我有一个自己的成就记录，一个Local First应用，所有事情都在我本地发生，数据库就在那里，如果我想导出，我创建一个dump文件就行了，明白了，这就是为什么我说，这是另一个博客，内容太多了，不我知道。 [01:19:45]
Heitor Lessa：对对我只是在消化这些，如果你在听，想要一个LFA，也就是Local First架构的后续内容，专门跟Heitor聊，请在评论区告诉我，好我们回到开发生命周期，回到我们这里的开发循环。
Patrick Akil：好所以我们聊了。 [01:20:00]
从开发产物到实现
Patrick Akil：创建那些产物的计划，比如设计文档，规格说明和任务清单，以及为什么你不该满足于，用OpenSpec，或者任何框架的默认做法，但秘诀在于把你的工作流，你的团队，最终是你的公司，都固化下来，对吧，然后你到了apply这一步，这实际上就是实现，这里对任何规格驱动开发来说，一个诀窍是，你的上下文，现在塞满了大量信息，但因为你已经把这些上下文，外化到你的产物里了，比如设计文档等等，你就不再需要那些包袱了，否则你每一轮，每一次交互都要花更多token，所以apply就是，一个时刻，你说让我清空上下文，对，把模型切到中档，或者更低一档的模型，然后让它去执行，整个过程可能从十分钟到两小时不等，取决于任务有多复杂，尤其是你有多少个循环，所以这里没什么神秘的，现在更像是自动驾驶，完全自主，你不在循环里，agent在驱动一切，对，它可以驱动多个子agent，可以做编排，你想做什么都行，但OpenSpec本身没什么秘密，它基本上就是说，agent这些是缺陷，去吧。 [01:21:16]
Heitor Lessa：对，基本上就是这样，这是最简单的部分，我觉得很有意思的是，循环工程这个概念，当人们说我不再写代码了，这话说起来容易，对吧，但看到目前为止，从发现拆解任务，再到准备定制化护栏，这些都是在循环开始之前，就预先做好的，其实有大量的准备工作，绝对，我觉得最大的谎言就是说，哪怕当初营销和炒作出来的时候。
Patrick Akil：说我们不再需要工程师了，这个问题全解决了，我在做服务的时候也是这样，我当时在供应商那一侧，他们说你不再需要那么多系统管理员了，不再需要那么多开发人员了，因为你不需要他们盯着服务器运维了，但这不意味着他们的时间不再有价值，只是价值上移到了链条更高的位置，编程在大多数时候从来不是真正的瓶颈，但确实有一些非常难的编程是瓶颈，我们不能撒谎，尤其是C++和一堆别的东西，天哪，我可不想再碰这些，但真正有价值的是思考问题是什么，怎么拆解客户是谁，要达成什么结果，怎么把它变成业务的一部分，否则我们就是在玩，对吧，每个开发者在成为开发者之前，都梦想着我就整天写代码，等他们进了企业，进了公司，结果天天在开会，对，因为编程只是问题的一部分，是整个供应链的一部分，但不是最大的部分，agent也是一样，今天刚出来的那篇博客文章，最受期待的文章之一，讲的是BON，一个JS运行时，怎么从ZIG重写成RUST，以及他们怎么准备整个代码库，模式移植模式，这基本上就是我们在做的事，当人们说我不再写代码了，我几乎什么都不做，建个循环就行，其实有这么多准备工作，因为agent每次都是从头开始的，对，哪怕你建一个memory.md，或者现在人们叫的什么别的名字。 [01:23:21]
Heitor Lessa：他也得知道好是什么样子的，我真的很期待这篇播客文章，所以我很高兴他出来了，对今天早上出来的，我当时就想太好了，我也得去读一下，一直有人评论说规范驱动开发，跟agent的协作，前期工作量太大了，我宁愿自己做，或者我手动做更快，但我觉得你前期做的这些工作，对我来说就像一笔投资，对吧，你早期投入，几个月后收获回报，而且有时候回报来得很快，如果你说我不投资，我就把钱存着放银行里，那好吧，到某个时候，别人会有更大的回报，更高的分红，从早期投资里收获更多，对我来说，这很类似，所以看到有人不投资，不只是投资自己的工作流，还包括怎么在团队里，在组织里扩展，怎么思考和实验，我觉得挺可惜的，因为现在每个人都在实验。 [01:24:13]
Patrick Akil：所以现在就是实验的时候，要我说，这就是我们在讨论的，投资于相邻角色，或者相邻领域的技能，这样你就能用上，我给你举个例子，我们做apply的时候，有一个任务，为数不多的几个任务之一，在任务最后，我们会做一件事，叫更新决策日志，我们记录项目里，做的每一个决策，包括原因，为什么，有点像ADR，但非常清亮，昨天我创建了一个，我很自豪的东西，我还有两个要建，现在还在想，agent的开源策略，之类的问题，它叫斜杠onboarding，是一个命令，也是一个技能，它会扫描你的项目，找code owners，git log，git分支，文档，open spec，如果有的话，或者任何规范文件，然后我们会给你一个高层次的概览，项目的架构是什么，主要决策有哪些，项目的稳定区域和不稳定区域在哪里，哪些人可能更了解某个区域，你应该去找谁聊，然后引导你完成个性化的入职流程，你完全不了解这个项目，还是了解某些区域，想深入某个区域，要不要我创建一个交互式HTML，你从那里开始，这些投资通常在考虑团队层面的时候，会得到回报，如果你有开源背景，你总是在想，怎么让贡献者更容易参与，但同时，怎么让恶意的人，更难去贡献那些，本来就不该贡献的东西，对，所以agent跟这个没什么不同，明白了，我还想明确一点，这是第一次，纯粹由agent的自己跑一个循环，对吧。 [01:25:46]
Heitor Lessa：你提到可能跑十分钟，也可能跑两个小时，你有没有想过agent跑在哪里，是在某人的笔记本，电脑本地跑，还是在远程跑，这样他们可以把电脑合上，我看到网上有梗图，人走着路。
Patrick Akil：笔记本盖子半开着，agent还能继续跑循环，你怎么看这件事，目前我们全都在本地跑，我们也在做实验，尝试跑到远程机器上之类的，但要说的话，这方面我们还非常早期，这和远程开发机没有太大区别，我以前在伦敦跟媒体公司，广播公司合作过，有些公司把远程开发机，当作一种安全措施来用，比如把所有东西都锁死之类的，但这对开发者体验，也会造成摩擦，有些事就没法做了，所以我觉得我们还没到那一步，目前这一切都在本地运行，对，除了最后那部分，我们会做额外的审查关卡，那是用一个工具来完成的，我现在真的很喜欢它，顺便说一句，这不是什么正式背书，我可没被赞助，它叫Rabbit，如果你想赞助我，跟我说一声，对，所以这些东西，现在变得越来越有用了，尤其是在CI那边，明白了，你说本地跑的时候，那他还是在某种沙箱环境里吗，还说人们要承担这个循环跑飞了的风险，我们靠前面做的那些工作来防止这种情况，不是，两者都不是，他还是本地的，但我们要处理的是agent，对吧，我们处理的是钱，资金流动，还有一堆别的东西，所以我们必须非常小心，现在有像factory droids这样的工具，可以提供企业级治理，比如你可以禁止某些级别的命令，某些级别的东西不允许使用，就算agent想那么做，你也可以说禁止，或者有时候他会说，这个其实违反了组织政策，我需要你明确授权，才能运行这个，比如说，所以是有这些不同层级的，即使是agent工作流也一样，对，尤其是对，我给你举个例子，一旦你开始用agent，并且用Kubernetes，agent可能会说，好，让我把这个bot删了，让我把这个东西删了，我们得阻止，对，所以你就有点没法阻止，好吧，让我试着把整个home乌鲁删掉，所以你就是不能让他干，好，所以这就是现在用AI，加上企业治理能做到的一些事，对，Factory Droid跟开源的Droid Agent Harness，是两回事，对吧，对，Droid本身是那个Harness，算是开源的，但现在所有这些公司，都在往企业治理这块投钱，可以这么说，Dex的open code也是同样的思路，所以harness，是你做那些厉害事情的地方，对，但就像任何云上的远程开发环境一样，你总得在某个地方有策略，明白了，有意思。 [01:28:37]
Heitor Lessa：这个我也要去研究一下，我们一直在调研本地沙箱环境，希望让大家更舒服，更有信心的，让agent跑更长时间，对吧，如果只跑五分钟，那没问题，你还能盯着屏幕想，他在干嘛，但要是说跑两个小时，没人会坐两个小时盯着屏幕，确保他不会把后目录删了，而且就算他真删了，你可能也来不及了，因为你当时在睡觉，对，所以你得有个东西兜底，对。 [01:29:03]
Patrick Akil：我们听过这类故事，但确实你现在几乎可以在每个harness里，用hooks来防止一些这类事情，但如果你只是面对几个开发者，那没问题，可你要是面对几千个开发者。
Heitor Lessa：那对话就完全不一样了，对，我想深入聊一下hooks，既然你提到了，对我来说，咱们先从最基础的开始，什么是hook，好让听众能理解，好所谓hook，就像你机器上发生的任何事情一样。
Patrick Akil：它通常会生成某种事件，有时候是一条日志，有时候是给计算机的一条指令，然后基于那个事件，会有事情发生，所以如果你通过open code，cloud code codex，或者factory droid这类工具，在机器上跑一个agent，会有一些决策点或检查点，可以这么说，在这些点上会发出事件，比如在我运行一个工具之前，运行之后，或者正在运行的时候，类似这样的时机。 [01:30:00]
事件钩子与可信执行
Patrick Akil：类似这样的时机，你可以拦截那个事件，然后说，在你本来要执行的指令之上，再帮我做另一件事，举个例子，你可以说，在你把控制权交还给用户，告诉用户，我做完了，之前先跑一下pre-commit hooks，这样你就能确保，我们每次都会跑它，但这不是最聪明的做法，更聪明的做法是在pre-commit hook里做，也就是说如果git要提交这次变更，它会触发一个hook，那是一个事件，你可以在那里运行某些命令，然后直接说终止这次操作，所以hook本质上就是事件驱动的，但从流程或工具的角度来看是这样，那hook是在整个循环跑完的时候运行，还是在循环的每一次迭代时运行，它会运行，这取决于具体位置，就我们刚才讨论的那个例子来说，通常是在循环的某一次迭代时出发，对，但你通常还是希望，在某些方面内置自己的hooks，循环本身不完全是hook，但在某种意义上也算是一种hook，明白了，对我来说hook这个概念非常强大，我希望我的代码容易改。 [01:31:09]
Heitor Lessa：简单，这话我说过很多次了，是受一位嘉宾的启发才这么说的，当你的agent替你执行代码的时候，你依然希望如此，对吧，不是你自己亲手写，而是你的agent在敲代码，或者说生成代码的时候，所以那些代码质量标准的约定，特别是我们仓库里的，或者针对某个特定技术的铺好的路，我觉得我们应该尽可能多的，把它放到确定性里去，而hooks就是实现这个的一种方式，对吧，比如lint规则，samgrave规则，我见过有人用这些来做事情，或者确保某些安全标准在那里，或者尽可能多的约定，这样代码在质量结构架构决策上，就更可预测，因为说到底，我也觉得这笔投入会带来回报，因为总得有人去review那些代码，如果你每次都要review结构，你会很快疲劳，因为我们现在生成代码的速度，可以非常快，但当你必须像review，一个完全不懂行，不遵守任何约定的人，从零写出来的东西，那样去review一切，或者说更像抛硬币，时好时坏，那你很快就会失去优势，认知负担也会很快爆掉，我在笑，是因为我过去几个月花的时间。 [01:32:14]
Patrick Akil：就是我之前说的最难的部分，让它变成团队化的，就是因为我刚才说的，正是你现在讲的这个，我们会在最后，把这个东西叫做slash retro，对，当我们做这件事的时候，继续往下说，当我们真正去实施的时候，你通常会用这种，临时性的提示词，去修某些东西，你不喜欢任务，被组织成那个样子，不管你有多少个SKU，这种事都会发生，它一定会发生，而质量缺口，就是在这个时候出现的，也是从这个时候开始，你会开始有点不信任它，不确定它是不是在做你让它做的事，那些质量关卡什么的，这事能不能更确定一点，你怎么把这些东西带进来，我现在解决这个问题的办法有两个，两个检查点，不是钩子，我们作为OpenSpec计划的一部分来跑，对于正在做的改动，我们大概跑15个对抗性审查员，所以想想，是不是碰了Python代码，那你就要跑一个，Python对抗性审查源，也一样，TypeScript也一样，Postgres也一样，等等，看看正在创建的查询，或者看看正在创建的DDL，看他们鉴表的方式，他们做改动的方式，这会不会导致数据丢失，审查源能抓到这个，所以你在本地跑所有这些，但我们也可以在CI里跑，这会生成一份证明，就像我们在高风险的发布里，做的那样，就像我以前在开源里做的那样，每次发布，你都会生成一份证明和一份溯源，来证明为了生成那个发布所经历的所有步骤，CI-CD任务，环境变量，命令等等，全都记录下来，而我把同样的思路用在了合并检查上，用来防止agent伪造证据，伪造他们跑了任务，做了他们该做的事，所以每一个改动，每一次提交都必须伴随一轮，基于这些改动的审查，所以想想，你有一个永远在跑的安全审查底线，那是必须一直发生的，一直，但你也会有条件性的审查员，比如，如果没碰Python，为什么要跑它，如果没碰文档，为什么要跑它，所以我有这种安全审查和结果验证的底线，还有一个条件性的，在这些东西跑的时候按需运行，而且我有确定性的脚本，用来验证他们是不是真的跑了，是不是真的读了同样的文件，钩子以及其他一些东西，如果都满足了，那我们就能生成一份，带所有证据的证明，测试，发现，需要修的东西，这会在CI里被验证，CI会预先计算所有东西，这比这复杂一点，但这是我能讲的最简单的形式，这就是我为什么叫它合并检查，一旦这件事发生，在我们结束整个开发周期之后，过去六个月，我最大的收获是，你往往会忘记，因为agent在帮你做所有事，其中有些事，本来可以是确定性的，但当你跑了一个绘画，三四七个小时之后，你已经精疲力竭了，你最不想做的事，就是去想，这能不能是个linter，这能不能是个自定义规则，或者格式化规则，你就是会忘，所以我建了一个命令，用了冰岛一家公司的探索成果，在我一个朋友面前，叫slash retro，你用同样的苏格拉底式方法，但看的是你刚跑完的，上一个绘画，或者当前绘画，搞清楚是什么，让你不得不去纠正agent，因为你失控了，你跑偏了，或者他没做，你真正想让他做的事，或者你不得不去修的东西，主要是因为，你知道agent，有时候就是没那么能干，这种事会发生，或者就是单纯，你不知道怎么让这事更确定，所以这个slash retro命令做的是，他采访你，他看你整个上下文和绘画等等，然后搞清楚，有没有我能注意到的线索，我们可以就此展开讨论，我们可以深入进去，最后这会铲出一张表，列出所有现在可以变成确定性的东西，以及其他那些实际上可以保持非确定性，但更轻量，更少指令，更少点什么的东西，这就是我用来改进，这整个开发循环的方式，引入合并检查，一次引入一个审查员，引入自定义Lint规则，引入架构守卫，防止某个文件导入，它不该导入的另一个文件，因为他们用了端口，和适配器之类的模式，所以它某种程度上，变成了一个持续改进的过程，我其实在想，既然我们聊了这么多。 [01:37:01]
Heitor Lessa：里面有些小技巧，我自己首先想用起来，但我也觉得，从听众的角度来看，他们可能也想试试这个，你打算开源这个吗，这个能用吗，人们在哪里能找到它，这个目前还没开源。
Patrick Akil：但我可以在YouTube视频发布后，在评论区放一个示例，不过我们正在讨论，在Agin怎么开源，不只是这个工作，还有Retro Onboarding，我现在还在做Offloading，比如你要去度假了，或者刚休假回来，有一些小技巧可以用，还有我们自己的OpenSpec，自定义工作流，带所有这些合并验证循环的框架，如果这么说的话，我正在搭，这些我们都在研究，但如果你现在就想试，其实可以很简单，就一条指令，你是一个专门帮我反思，帮我找开发工作流优化点的agent，你的工作很简单，看我的上下文，看我之前的绘画，或者当前绘画，问我有没有什么笔记，哪里出了问题，哪里不太顺，采访我用苏格拉底式提问，把线索挖到底，直到没有遗漏，等你有了更完整的画面，确定没有其他待讨论的话题了，或者用户说可以了，那就生成一张表，列出哪些东西可以做成确定性的，这样我或者我们就能少花力气，少对抗少挫败，因为工作之外我们也有生活，还有哪些东西可以加进我们非确定性的做法里，可能是一个reviewer，也可能是别的，把它做得好看一点，就是一张简单的表，用户有需要的话，可以追问，这基本上就是，Wetter的全部了，说实话，大概30行，但就是这种想法，在绘画结束时，或者可能，两三次绘画之后，你能调用一下这个东西，我也不知道，在纸上，或者哪里寄点笔记，或者我就在，后幕录下，放一个retro.md，我会记下我的挫败，比如，天哪，Opus，刚才还好好的，这怎么回事，这种事常有，之后我在retro的时候，把这些喂进去，然后他就能不断发现很棒的东西，但我得提醒你，如果你是像我这样的完美主义者，你会想一直跑这些retro，跑很久，然后有时候你得把务实精神，多拿出来一点，因为总有可以改进的地方，总有别的做法，但对我来说，我最喜欢的转变是，从哇，我爱这些agent，我信任这些agent，到现在这些agent，其实没在做他们该做的事，然后就进入这种信任，信任丧失，再恢复的循环，而你想回到当初那个信任基线，是永远回不去的，它会随着agent一次次作对，而慢慢回升，但retro这个想法开始运转之后，也许我可以写一条自定义lint规则，防止用这种方式写任务，用这种方式写代码，我最近学了go，发现golanci这个lint工具链里，有一个依赖守卫功能，是Retro告诉我的。 [01:40:00]
Retro反馈与风险治理
Patrick Akil：是Retro告诉我的，我当时就说，太好了，还能这么干，这样一来，那个import就永远不会发生，你的二进制文件，保持在三兆字节以下，完美，就这么干，对，所以这东西会高度个性化，这就回到那个前提，如果你以前做过开源，你就有优势，因为你总在想，怎么让别人更容易来贡献，可能是第一次，也可能是长期贡献，怎么防止恶意行为者，甚至防止你自己在状态不好，很累的那天，这种事一定会发生，把风险带进你的项目，但我们在开源里忽略的是这个想法，我快下班了，精力快耗尽了，这些事我记不住，但你现在有了一份完整的事件日志，所以我现在可以让agent去做他们最擅长的事，看海量数据，看很多东西，然后从里面找出意义，对，这种自我访谈。
Heitor Lessa：看我的绘画日志，然后从中改进，我觉得我能做，而且如果我回到过去，如果我在职业生涯早期就做这个，我觉得这个agent和这种反馈方式，会让我做出很多决定，很多我根本不知道怎么做的决定，对吧，你知道XYZ吗，这个Linter里可以这么配，我就想，我连我们现在在干嘛都不知道，那我得用多少自己的批判性思维，又有多少可以让agent来给我建议，给我信息，当我的向导。 [01:41:22]
Patrick Akil：你的建议是什么，会的，永远都是两者兼有，对吧，我举个昨天刚发生的例子，昨天我在重构，我在给GitLab搭一整套CI自动化，因为GitHub在某些方面，我真的很想念，然后我想让agent公司里，任何人都能说，加上merge check，加上这个attestation，确保agent不会骗你，不会编造东西，但按理说，这应该只是一行的事，但我也想在作者，代码作者层面，加上保护，防止这部分代码有副作用，不应该有调用，网络调用，他只应该说，这是我收到的hook，我收到的事件，然后加个标签，那应该是个动作，或者移除一个标签之类的，然后别的东西来控制副作用，这样测试更容易，让东西可测试，agent理解的是，好没问题，一行行，然后他搞出了一个完整的重构计划，说什么我们只需要两个docker镜像，还有所有这些不同的部署，三个不同的仓库，我说，我喜欢你在想Docker镜像，就做个自包含的，但这里有三个不同的关注点，第一个是客户优先，我怎么让它简单到，他们直接包含就行，决策疲劳直接消失，第二，我怎么防止自己不小心，加了不该加的东西，所以我的架构一开始好好的，现在变成了意大利面，但还有，我怎么防止agent，基本上对我撒谎，开始改这些东西，因为他们在某种程度上，是有自由意志的，对吧，然后最后一个是，我怎么让部署更简单，这样维护这整个东西，不会变成我的负担，因为复杂性永远不会消失，你只是把它推到别处去了，我不想承担那个复杂性，即使我在尽量让用户那边，越简单越好，如果这是个不对等的计算，那我得把天平往这边挪一挪，然后那个批判性思维，就必须上场了，这就是有时候新工程师很难的地方，那些入行不够久，犯的错不够多的工程师，我犯的错多到数不清，才能有这种前瞻性的眼光，然后说，其实agent你目前干得不错，但别这么做，如果你经验不够，没有足够的批判性思维，没读过足够的代码，没有足够的伤疤，希望你不会有那么多，那你可以用对抗性评审的循环来平衡，比如你总可以说，把fable拉进来说，用你的判断来决定，什么时候启动，比你更低阶，能力更弱的模型，来评审你正在做的工作，然后从安全的角度，从客户的角度来评审，这是我甚至偶然发现的，你从产品的角度也能这么做，你可以写一个PRD，你可以写其他所有东西，然后你说，这是我想要争取的客户类型，这个市场或这个细分，为各创建一个虚拟客户，然后评审这些东西，这样你会得到不同的发现，然后找出共同点，然后我们就干，对，它不会解决，你没有批判性思维的问题，但它会降低风险，就像架构师，你的主要角色，不只是让周围的人都更聪明，还要降低那个决策的风险，明白了。 [01:44:36]
Heitor Lessa：所以用agent也能做到，对我喜欢这个，就像你在解释的时候，你也在传达，这是你最近才想明白的东西，对吧，或者是你探索过，然后学到了，然后付诸实践的东西，这真的很突出一点，我们现在学到了很多东西，甚至我们沟通的东西，都太新鲜了，不去尝试，不去实验，不去学习，那太可惜了，因为我觉得早年的软件工程，没有这么多创新，对我来说，现在正式开始创新，开始学习，看看能改进什么的好时候，而且说实话，我玩得很开心，对，我也这么觉得，对，我特别享受这个过程，因为我觉得经验越多。 [01:45:17]
Patrick Akil：积累的教条也越多，而到了这个时代，你会发现，其实我们可以换一种做法，我前两天又跟一个朋友聊到，Prince Benjamin Adjian，特别聪明的人，在Rust这方面，我挺仰视他的，他简直就是Rust的天才，他正在做的一件事，Nicholas，请原谅我提前分享，你的一些精彩工作，他在研究怎么把工程设计的讨论，变得结构化，用一种可以为给Adjian，或者做其他事情的方式，比如说有点像决策记录，但技术含量更高，昨天我跟他一起看那份文档的时候，有一件事让我印象很深，这非常亚马逊风格，把所有事情都想得特别周全，你必须去回答，必须去写，但我也从开源社区知道，当人们看到这种东西的时候，他们会害怕，会退缩，只会做最少的功夫，或者他们可能就直接用，Chachy PT Gemini之类的，随便写点东西交差，然后那种冷静的批判性思考，就完全被抛到脑后了，我们能做什么呢，我就给他看了，我们刚才讨论的这个循环，如果我们有一个队列，用那个东西或者一个命令，我觉得命令比队列更好，把那些东西当做模板，当做起点，但用苏格拉底式的方法，把它变成工作流的一部分，这样当你在做最初的头脑风暴，或者探索，打开规范或者别的什么的时候，你就再往里面嵌入任性方面的考量，你就再把即时管理变成这些事情的一部分，这样它就变得很自然了，然后整份文档就产生了，而他们自己都不知道，这本来就是目标，对，就像开源工具一样，重点就是让人们觉得，这东西用起来太方便了，加个日志器，马上就有结构化日志了，一旦你有了关联的概念，加个标志就行，到最后他们审查的时候，会说，哦原来我一直在做这些，我自己都不知道，对。 [01:47:15]
Heitor Lessa：这就是我希望我们能更多走向的那种，啊哈，时刻，这里面肯定有一些行为心理学的东西，因为我也注意到，如果你把最终结果直接给人们，如果结果很完美，但他们不信任他，那他永远行不通，对吧，但如果你给人们工具，让他们自己创造出那个最终结果，他们就会建立起信念，因为他们参与其中，他们的批判性思维被用上了，他们通过动手做来建立自己的信念，然后他们真的会相信那个结果，突然间你就有了自动的认同，这本来就是目标，就像你可以出发了，差不多。
Patrick Akil：这就是我们一开始聊这个话题的全部意义，为什么工程师有时候那么专注于硬技能，那确实是必要的，你必须要，尤其是跟agent打交道的时候，你得知道他们在撒谎，他们会给出次优的结果，但当你开始研究相邻的角色时，这才是你开始放大自己的地方，agent应该是来增强你的，但首先你需要用那些技能之一，来增强自己，这样你才能达到更高的高度，对，非常感谢你来做客分享，没问题，这太棒了，谢谢你的邀请，这是我们第一次做这种形式。 [01:48:29]
Heitor Lessa：在屏幕上展示视觉内容，所以请在评论区告诉我你的想法，我们下期见。