【附完整文档】SDD规范驱动开发企业级实战！ 还在聊天框里一句句补需求，项目迟早会失控。 这期把 SDD 补成完整三道关：前面用多路调研做技术选型，中间按 Spec 拆后端、前端和联调任务，最后为每类任务挂上自动验收。让 AI 不只会写代码，还能按规范完成、验证、修复。九阶段全链路图和测试策略图，评论区扣“文档”，我挨个回！#抖音精选App知识充电站 #抖音精选App征稿中 #VibeCoding大赏 #ai新星计划 #程序员

如果你现在还在聊天框里，一句句跟AI说需求，说完这个说那个，项目迟早要塌。 真正能长期维护的项目，靠的不是对话，而是把需求落成一份结构化文档，让AI照着这份文档施工。 这套打法有个名字，叫规格驱动开发，SDD。 市面上很多SDD教程，只教你怎么拆文档，怎么分任务，中间两头没人管。前面技术选型到底靠不靠谱，没人帮你判断；后面AI说按文档做完了，你也不知道它有没有真的做对。 这不怪你，市面教程只讲了中间一段。所以今天这条视频把SDD完整补成三道关：选型官、开发官、验收官。 对了，今天这套9阶段全链路图，还有我平时在用的全链路测试策略图，都给大家准备好了，评论区扣“文档”，我挨个T。 第一道是选型官，管的是写进Spec的技术方向，不对产品形态、数据来源、开源项目、实现方案仓促下定，四路并行调研，最后落成你自己能看懂的文档。后续项目再放进技术选型法庭，让项目自行梳理优势，红队专门挑出致命缺陷，中立评估师按改造成本、版本依赖和运维难度打分，最终产出一张能写进Spec的复用矩阵。 第二道是开发官，这才是SDD的核心，需求落成Spec后，每个任务都打上BEFEINT标识，后端、前端和联调分别管理，改了哪个任务、碰了哪些文件都能追踪。 第三道是验收官，三个标识后面分别挂上对应测试模型，说做完了就按任务类型自动验证，没通过就回去修，修完再报结果。最后再把prompt、context、harness和loop这四个词捋清楚，让你知道从写提示词升级到写循环到底升级了什么。课件9阶段全链路图和测试策略图，评论区扣“文道”，我挨个踢，公开课现在开始。关于我个人在使用web coding的这个全链路开发，那么经历的这九个阶段，其实我是把它做成了这样一个非常通用的工作流。比如在第一个阶段，我们初步有一些想法，就是想要做出一些什么样的产品。然后第二个阶段，如何去借助于AI编程工具，快速的去完成一些技术架构选型，或者是功能链路，或者是产品的竞品调研相关的这部分内容，然后把这一些相关的数据，去收敛成一个非常标准的PRD的文档。在PRD的这个文档里面去完成，对应如果要实现这个产品，它的一个具体的技术架构的设计和技术的选型，包括了如何去做前端的UI的这个设计。因为大家也一直都在吐槽使用这个大模型去开发的这个前端AI味集中，要么就是红的，要么就是紫的，反正是一眼就知道是AI做的。那关于这个UI的原型的设计选型。 那其实现在有很多的前端开发工具，我们是可以去进行使用的。比如说像Figma，或者是Pencil，或者是Cloud Design以及Google Stitch等等，都是可以去进行使用的。 所以关于这个前端代码和后端代码，再去进行联调的开发，以及完成整个系统的前后端的联调，包括最后的这个部署上线，那么每一个阶段，其实在开发的这个过程中，都有不一样的侧重点。 所以基于这样的一个情况，我们在下面准备了非常多的内容，大家也看这个白板往下滑，就滑出来非常多。那么这一部分，其实里面有很多的技术细节，我想要在我们今天的结营的最后一天，来给大家去做一个分享。 当然，其实这里面也能够看到，我这里面是给大家去准备了一个比较标准的、企业级项目开发的标准目录。其实大家这里面也能够看到，对于一个相对来说比较复杂的，或者是你想要去进行持久化维护的项目结构，我们一般来说，基于webcoding，如果你要是使用cloud，或者是codex进行开发的话，那么它大致的目录，可能会分成这样几类。 那么首先第一个，就是会有一个back end的目录定义。那么这里面，核心就是我们会把所有的后端的 这个代码逻辑放在这样的一个链路里面，放在这样的一个文件夹里面。那么另外一个呢，就是关于这个friend，就是我们会把所有的这种前端的这样一个项目和代码去放在这个里面。那么另外一个非常非常关键的，就是所谓的这个spice文档。那么这个spice文档呢，现在大家都在吐槽：如果我们把所有的这些功能、所有的这些代码都交给大模型来去进行开发的话，那么我们如何去管控，如何去掌握大模型在开发复杂项目的这个过程中，它的一些功能的迭代？我都不知道它怎么去进行开发的，它开发的什么功能，我又不太懂代码，那这个过程怎么办呢？其实现在有一个比较好的，就是SDD或者是TDD的这样一个开发的流程。也就是说当我们去开发一些项目的时候，那么会更倾向于去拆分出一个一个的所谓的这样一个规划。那么这个规划呢，就是给人来看的，这里面写的就是，我在每一个这个项目的功能模块，那么它里面会实现什么样的一些技术的架构，实现什么样的功能的链路，它又使用什么技术来去进行开发。那么这些呢，就是我们现在这个程序员，或者是Agent开发相关的这些小伙伴呢，在去做一些复杂项目的时候，会维护的这样一套流程。而这一套流程呢，是完全可以由人来去进行把控的。所以基于这样的一个标准化的开发的这个链路呢，其实它并不简单的是 我们通过几句提示词就可以完成的构建，而是每一个构建的链路，都有非常非常多的这样一个细节。所以我这里面，会把整个的开发的链路，去分成这样的四类。那么这四大类呢，依次就包括了。 首先第一个，就是关于你有一个想法，想要去做某一件事情。那么基于这样的某一个事情，它的这个想法，其实我在这里面，大家在真实的这个环境里面，它肯定会分成这么几类。那么这个呢，就是当你去有一个想法，想要去进行开发的，那么最多最多的，就是你自己有一些痛点，或者是你自己想要去做一些独立的那样一个产品。比如说你想去做一些副业，想去赚钱，等等等等。或者是你自己，有一些场景下，这些工具用着不爽。在现在这个阶段呢，大家说几句话，就能非常快速的，把这个事情给做出来。所以这个呢，也能够给我们所有人传递一个众生平等的概念，就是不再是程序员才能去开发产品，而是所有人都可以去开发产品。 那么另外一个呢，就是当你在企业里面，它可能更多的，就是来源于你的老板，或者是管理层，或者是你的这个产品经理，去提出的一些个人的这个需求。要么就是你是乙方，你去服务你的这种甲方或者是外部的客户，或者是你在整个的这个公司团队里面，是由一些业务部门，提出对应的这些需求。其实现在，很多的这个情况下。 我们更倾向于使用编程的这种工具，去把它做成一个可通用的小迭代版本的产品。 那么甚至是，关于一些政府、合规、技术趋势的这类方式，其实对于这些提出的想法，整个的这个过程，它并不是很复杂。 总的来说就是，我们想要基于现在手里的这种编程工具，来去完成一些项目的开发。 那么这些，毫无疑问，它是没有任何问题的。 那关键就是回到了，当你有了这样的一个想法，你首先——我们小伙伴问，是直播嘛？当然是直播了，我们肯定是做直播的。 当你有了这样的一个想法，大家会把它分成很多种不同的类型。 比如说，它是你擅长的这个领域，那你当然知道我应该如何去做，你也有对应的业务支持，也有对应的技术支持。 那么另外一种情况，就是你也不知道现在是什么样的技术形式，该选用什么样的技术架构。 所以这里面，就需要一个非常详细的数据分析的过程。 大家可以回想一下，我们昨天进行项目开发的时候，了解到了卡帕西的这个MVK。 网络有点断断续续的，我这里的网络应该是还OK的。 你有了这样的一些想法，想要快速落地推进的话，那么昨天我们采用的这种策略呢。 就是直接在这个Cloud Code里面，让它去完成一些联网的检索。那么这个联网的检索，首先它这个过程是非常非常不可控的，你也不知道它内置的这个工具，在网页上去搜寻了什么样的信息。那如果你要想基于你的这个想法，去真实地完成一些比较细粒度的落地的话，那么我个人常使用的这样一个策略，其实会分成这样的几个维度。 这就是在现在的AI编程、AI时代，我们去快速挖掘一个陌生的领域所采用的一些策略和方法。那么首先第一个，毫无疑问就是我们使用这种Cloud Code，或者是ChatGPT，让它使用通用的Web检索能力，自己去找一些文章、博客，给你返回对应的数据。 那么还有一种，就是现在有很多的深度研究相关的能力，包括Cloud Code，它其实最近也上新了Deep Research这样一个功能，也就是深度研究模式。它会把你提出的这个问题，通过多智能体自主地分解成不同的子任务，再通过多维度来进行构建。或者是你针对你看到的这个网页，通过Web Search这样一个方式。 去把全部的内容拿下来。 那么其实，我们整个在构建这样一个链路的时候，我会针对于一个想法，去把它改造成这样的一个模式。 比如，大家可以看到，我们就以我们要做的这个事情为例。这里面是我之前在课程里面，给我们的正式学员上的一个量化交易的项目。 基于这个量化交易的项目，首先我们也是提出了一个对应的想法：就是我想要去炒股，我想要去挣钱，然后我能不能借助于大模型，去实时爬取一些股票的API接口，然后让它给我去开发一些大盘，然后由大模型实时地进行盯盘，来去进行一些买入卖出呢？ 这个其实就是最初的这样一个想法。当然，你有了这样的一个想法以后，肯定需要借助于你手里面的这样一些工具来去完成。这个项目我到底怎么去进行构建？我采用什么样的一些技术？然后我能够拿到哪些API？ 所以，这就是我们在进行深度搜索的这样一个阶段所需要做的事情。这个过程，我一般来说，会把我们刚才上面的怎么做流程、怎么做可复用的工作流，以及通过不同的渠道去挖掘相关的信息，来去把它抽取成如下的这样几个维度。 首先，我们给大家去看一下，关于我们去抽取的这个维度，它是这个样子的。 它会分成这么几个维度。 首先，我的个人使用方法，我会在基于这个Cloud Code的这样一个阶段，去把它派发多个不同的Agent，来去进行一个并行的执行。 那么每一个Agent呢，它会去做一些单独的调研主题，我会产出这样的几个方向。 那么首先第一个，就是我们在确定好做某一个项目产品的时候，我会由Agent来去判断它的产品形态，这个产品到底是长什么样子，都有什么样的一些功能，然后都有什么样的一些链路，我们在这个产品上都可以怎么去进行操作。 那么第二个呢，我会去调研，如果我们去落地这样的一个项目产品的话，那么它都有哪些数据来源。比如我们刚才给大家举的那个例子，我们想要去做量化交易相关的内容，那量化交易里面股票的这些信息，是不是有一些公开的、免费的还是付费的这样一些接口，可以让我们直接把这些数据给拿过来呢？所以这个叫做数据的来源调研。 那么第三个叫做开源项目调研。相信大家如果是有关注量化交易项目的小伙伴应该知道，最近有一个非常非常火热，而且一直霸榜的叫做Trading Agent的这样一个项目，它本身就是内置实现了很多关于量化交易相关的一些内部的逻辑。所以对于我们来说，肯定很多项目它都是基于开源项目。 来去进行二次开发，或者是直接复用。 很少有直接从0到1去进行开发的。 所以当大家有一些需求的时候，那毫无疑问，我们会去介绍GitHub这样一个平台，来去判断一下你当前想做的这样一个产品的形态，是不是有一些开源项目是支持的，以及已经有一些功能你可以直接去进行复用的。 那么第四个就是，如果你当前的这个项目，想要去进行落地的话，都有哪些对应的实现方案。 所以基于这样的一个情况，哎，那我们就会把你输入的这样一个主题，不再是像我们昨天那样，让它自己快速地去联网检索一下MVK是什么，然后直接用它来进行开发。这样的话，有点太草率了。 而是我个人的这个使用方法，会把它拆分成这几类。那么通过这样的一个横向的链路，它会在每一个项目主题下面生成对应的文件，就包括了，比如我们就拿之前我给大家介绍过的这样一个量化交易的项目，它其实在完成调研以后，会生成这些文件。 那么首先，第一个就是所谓的这个产品的形态。这里面可以看，比如我们的这个维度，就是如果你要去做量化交易的话，在这样的一个核心的链路流程下面，它就会去盘点一下，哎，在中国的这个市场上，A股的看盘赛道，都有哪些竞品，都有哪些产品的类型，比如什么同花顺呀，东方财富呀，它是什么类别的。 他对应的这个定位的信息是什么？然后接下来，就是对于他对应的这个信息，架构之间的一个对比。比如说同花顺、东方财富，他们之间每一个功能链路上，都有哪些type，都有哪些功能，以及他们这个产品形态是什么样的。这里面包含非常多内容，还有对应的横向小节，来自于不同的维度。所以他交接的是对应的产品形态，也就是告诉你，别人在做同类型的产品的时候，他们是怎么做的，他们的网站是怎么设计的，他们都有什么核心功能，甚至包括了一些交互功能。比如自选股怎么去做，智能选股怎么去做，行内一页内的这种套路，他都给你检索出来。所以有这样的一些形态，你就知道了，哎，现在我想要做的这个产品，在市面上大家都是怎么做的，那你做的时候就有了一个基础的参考。所以有了这样的一个产品形态，那么第二个就是来源于他的一些数据来源。所谓的数据来源，他指的是，有些项目是来源于我们公司内部的一些数据，比如说你公司的数据库，你公司的一些公开的API接口，这些你可以稍微的去泛化一下，做相关的业内调研。那如果你要是做一些公域的这种产品，那像我们，如果你要想去抓取A股的一些信息。 那么，他是不是有一些开源的聚合的API啊？ 量化的平台， 然后券商直联。 那这些东西你要拿数据的时候， 是不是就需要你在调研的这个阶段， 把它全部都覆盖到？ 那这个就是， 你在深度调研和普通的联网检索调研之间的这个过程中， 他们之间的一个核心的差别。 包括了这里面， 也会有对应的每一个平台， 它里面都有什么渠道， 它的这个频率是什么， 然后价格档位是什么， 这里面给你写的都非常清晰。 那么第三个， 就是我们刚才说的， 你要真正的去把你这个项目去完成开发， 那么最快和最便捷的方式， 就是先去这个开源项目上看一看， 有没有已经实现好的， 那你直接拿过来去进行复用， 或者是二次开发， 它的效率是最高的。 基本上我们很少说做一个项目， 我们就去从零开始进行开发， 除非你的这个场景特别的定制化， 特别的私有化， 基本上没有人会这么做， 你需要从零开始进行开发。 所以第三个呢， 就是非常非常核心， 在你去进行系统调研的时候， 你要去看一下你的这条链路上， 现在都有哪些热门的开源的工具， 或者是开源的项目， 已经做了相关的这个功能。 那这里面你就要去判断一下， 每一个开源项目里面， 都做了什么功能， 你是可以进行复用的， 它哪些是做的比较深的， 哪些是做的比较浅的。 那么比如说， 对于这个量化交易的， 那我们去进行匹配的， 就是它的一个。 都有哪些框架啊？ 它的这个星标是什么啊？ 最近活跃的是什么？ 包括了这个，就是我们刚才说的，CNN啊，Trading agent啊，非常非常火。 关于量化交易领域，它现在是27k，当然现在应该不只是27k，量应该是非常非常多。 包括了它用的是什么技术栈，它都提供了什么核心能力，可复用哪些模块。其实这些，就是能够帮助我们快速地去进行一些梳理和选型。这个是我们去做开源项目调研的一个核心的思路。 那么第三个就是，我们要去判断一下，我既然知道了这个产品形态是什么，然后我也知道了，我可以去通过一些外部的渠道，来去进行一个接入。同时呢，我又在第三步知道了，关于我要实现的这个项目、产品，都有哪些开源项目可以去进行复用或者是借鉴。那接下来你就要考虑，我在做的时候，都需要通过什么样的一个技术栈，做什么样的功能，用什么样的一些框架，用什么样的一些模型，怎么去构建这个链路。那么这个，就是我们要去调研的，在某一个项目下，它的一个实现方案，或者是技术栈的调研。 包括了，你再去做量化解译的时候，那么数据接入，你用什么样的一个技术栈呀？比如说你通过这个Python，来去进行一个构建，然后接入它这几个接口。然后存储层呢，你可以使用这个Redis，来去做实时的缓存。 然后通过PostgreSQL去做时序库的存储。那么业务逻辑呢，你直接通过大模型来去进行驱动。然后通过RAG来去做早盘的简报。接下来前端的这个UI呢，你可以通过Next.js，然后通过ShadCN等等。推送的这个渠道呢，你可以通过这个飞书的机器人，以及部署运维，你可以使用腾讯的轻量云。你又会发现，在这样的一个调研的体系下，它是直接就明确地告诉你了，你最佳的这样一个使用的方案是什么。所以这个就是，我个人啊，我自己在去完成一个项目的时候，构建的这样一条链路。它就会依次从四个维度，来去产生相关的这个调研，就包括了如何去做产品形态，如何去做当前的这个数据来源，以及如何去找到一些核心的这个开源项目，以及最后的这样一个实现的方案。所以关于这一步呢，就是我们在使用这个核心链路，它的一个构建。所以这个呢，其实基本上我个人在使用的时候，就是由一个Agent来去进行的一个驱动。比如说我这里面，核心地给大家介绍一下这个思路。那么我的这个思路呢，其实就是会把我输入的这样一个产品的形态，去完成六阶段的一个状态机的划分。也就是模型在接收到我们的这个模糊的需求的时候，它不是直接拆分简单的关键字，给到这个联网检索，而是说会拆分成不同的这个维度。 那么就包括了，它在拆分用户的这个问题的时候，也就是我们提出的这个问题的时候，要判断一下我们核心的问题是什么，以及是什么类型，以及对应的这样一个时效性。然后它会把每一个单独的问题，拆分成多个子任务，来去判断它到底是简单的事实，还是需要去做对比的综述，以及它要去走深度研究的这样一条核心的链路。所以基于这样的一个定义，它才能够去梳理和拆分出不同阶段的形式，来去进行返回。所以这个，就是我在做调研的时候，会采用的这样一个四路并行的结果。当然这个过程，它其实也还会存在对应的问题。那什么问题呢？就是当我们去接触一些新兴的技术，大家也不太了解，这个产品它到底是什么，它的前端的产品形态到底是什么，以及在这个阶段调研出来的这些开源项目，你看起来好像都很合理，都是来源于真实的GitHub项目，也给了你具体的对应的实现方案。但是如果我们没有自主的判断能力，那该怎么去做？所以这个也就是大家特别头疼的问题：模型产出的内容，我判断不了它到底是对的。如果你有这个问题的话，不妨就让模型来去进行判断。那我是怎么去进行判断的呢？首先第一个，我会在技术选型的这个阶段。 去给它做所谓的这种对抗设计。 那么这个对抗设计呢，指的就是，我会去拆分出这样的一个核心的链路。比如，这张图其实看得会比较清晰一些，我会去把它拆分成这样的一个链路。就是我们在调研的阶段，会选择多个不同的开源项目。比如说，这里面有第一个项目，5.8k的，然后它有什么核心能力。第二个项目呢，它是一个确定Agent，它有什么能力。那么第三个项目、第四个项目，这里面会拆分出15个以上的这样一些项目。那么这些项目到底是不是激进的事实，可以去完成你当前的这个项目链路呢？那么核心的一个原因就是，如果我们人没有办法去决策，那不妨就交给Agent。那么这里面有一个非常好的方式，叫做对抗式生成。所谓的这个对抗式呢，就是各抒己见，我们这里面测到一个非常非常好的、用来确定最后技术选型的正确性的这样一个思路，叫做法庭式的五角色对抗。这个法庭式的五角色对抗会分成这几类。那么首先第一个叫做法官。那么这个法官呢，就是我坐在这里面，听你们下面的人轮番去进行辩解，然后由我来判断到底哪一部分是对的。那当然这个法官呢，他是属于掌控全局的，看各方各抒己见。所以这里面呢，就有所谓的这种代言人。那么这个代言人指的是什么呢？这个代言人。 其实非常有意思。就是我们竟然是想要去做技术选型，想要去确定，那我们再去开发这个项目的时候，都采用哪些框架，来去进行一个复现或者是复用。那么这个代言人，每一个代言人，他都代表了一个项目。大家可以理解成投标，这个招投标，就是有这样的一个目的，有这样的一个产品。那么每个人都觉得我能胜任，所以这个代言人就是不断地去夸自己，说我能把这件事情给做成。所以这个代言人，就不断地去说好话，来去印证：为了完成你当前的这个项目需求，我是可以做到什么样的。所以这个代言人，就是只夸自己好的。然后，会出现一个所谓的红队，大家可以理解成这种红蓝对抗。那么红队，专门挑毛病的，这个红队就是专门挑毛病的。那你每一个代言人，代表了自己的这个项目，来去进行竞标，说你就选我，我就可以把你这个产品做完。那么这个红队，就是专门挑刺的，说不行，你肯定是有问题的，你要给我提出三个到五个这样的问题，然后自己去指出你的这个缺陷。所以这个红队，就是反一切，各个代言人说自己都是可以的，但是红队是反一切。那么他们在这个对抗的过程中，会有一个所谓的集成评估师，来综合地去判断。既然红队认为你的某一个项目，不能完成哪些功能，那么这个代言人呢。 就会根据红队的这个反驳去提出，结合自己的这个源码，来去提出我是可以完成的。但是他们反驳的这个结论，到底是对不对呢？会有一个所谓的集成评估师，来去进行构建，来去进行判断。所以整个的这样一个五角色对抗，就是有多个不同的代言人：一个红队的魔鬼代言人，反一切；然后还有一个集成评估师，以及最后的这个法官，来去进行一个对抗论证。当然在这个过程中，大家可以通过这样一个直观的理解，是能够看明白的。那不妨我给大家去看一下，我实际构建的这样一个链路，它其实会通过这样的几个维度，来去进行拆分。首先，所谓的这个对抗，它其实也是通过Claw里面的这样一个Skills，来去进行构建的。比如，这个就是我在真实的这个链路里面，使用的这样一个对抗的Skills。大家首先可以去看到的这个Skills，它其实做的就是，把技术选型的这个架构，去标准化成法庭式的、五角色的这个对抗的调研。所以在这个阶段，它的一个核心的原则，这里面是有一个七维度的指标。那么这个七维度的指标，就是每一个开源项目，它各自的这个代言人，要从你的这个技术的架构总览、你当前具备的核心能力清单、你的数据模型、你的扩展点，以及如果我要是采用你的话，那么改造的成本是多少。 我要改多少行代码啊，如何去适配进来。然后你一定要自己去产测一下，你到底有哪些致命的缺陷，以及与其他候选方案的集成的可行性。所以这些，就是我个人在做技术选型的时候，正在使用的五角色对抗的生成维度。大家，这里面还会有对应的设定，每一个代言人，他都有对应的模板。比如说，你是这个项目分析师，你是强势的论证者，然后我要梳理架构的局限，然后你通过这七个维度，来依次给我进行审核。所以它最后经过我们的流程，大家可以看一下，我们在调研阶段，其实在前四个阶段，是完成了产品形态、数据来源、开源项目以及实现方案的梳理。那么这四个部分，就属于我们在Webster阶段的产出。而经过了我们的对抗式审核，会出现一个所谓的决策架构极限。这个决策的架构极限来源于：首先我们当前到底是选择哪一个项目，你就能够明显看到，第一部分就是决策摘要，我们的架构局限最后就选择推定Agent的这个项目。为什么？然后还有这个项目作为上游，来去做后端的复合层和前端的自主构建。然后复用的这个矩阵，都有哪些模块来源于哪一个项目，处理的方式是什么，对应的工作量是什么，完成的是什么功能。你能够明显看到，经过对抗式生成以后。 他是可以把我们去检索到的、在联网搜索到的最适配同类型的这样一些项目里面的这些子模块全部都拆了出来，然后把各个开源项目的最优势点给集成到一起，来给我们构建出我们自己的这个项目。然后他还明确地告诉你，你的某一个模块，是来源于哪一个项目的哪一部分。什么A股的中文的Prompt，是来源于这个项目的，那你的A股的编排框架，是来源于这个项目的，这里面能明显看到它们是来源于不同的项目。所以这里面我们这个法庭式的对抗，其实做的就是这样一个事情，然后告诉我们，我们要用什么产品形态、做什么事情，然后以及如何去进行开发。所以这个就是我们的技术选型的这样一个阶段。所以我们去看一下这个白板，这个白板我们最开始，我是给大家去进行了一个总结：是我们有对应的这个想法，然后通过这个调研，去完成对应的这个PRD。接下来其实我们刚才已经完整地去给大家介绍好了，我们整个的这个技术的调研，我个人就会通过01到06的这个阶段，来去完成每一个选型的这个流程。那么这个阶段大家能够明显地看到，它都是一些人类可读的、可以去了解的这样一些，Webster都可以了解的这样一些既定的事实，大家直接看，每个人都能看懂，哪怕你不太懂技术，你也是能够看懂的。所以它就能够解决大模型胡寻思、乱定义，然后它后段架构设计。 你不太清晰的这样一个原有阶段。那么当有了这样一个阶段，你首先需要考虑的就是：我既然有了这些所谓的文件，有了这么多的文件，那我到底怎么开始，让这个模型给我按部就班、一步一步地去完成每一个功能量度的开发呢？ 所以我们就回到经典的传统软件开发流程里面，当我们去开始某一个项目的开发的时候，首先要有一个非常明确的PRD需求文档。所谓的PRD需求文档，它指的就是，我们已经有了对应的想法，然后完成了相关的技术基础调研、市场需求调研、用户需求调研，准备开始做这件事情了。 这个PRD文档直接决定了你后端怎么进行设计，要实现什么功能模块，前后端的核心链路是什么。那么在webcoding的阶段，我们应该如何构建这个PRD文档呢？ 其实对于PRD文档来说，在我们完成调研阶段之后再写PRD，其实就是一个收敛的过程，也就是把我们已经调研出来的内容整合起来：我既知道产品形态是什么，又知道我们最终用的技术框架是什么，我们要把它收敛成对应的PRD。所以对于这个PRD来说，它核心的落盘也是一个skills，这个skills里面定义的就是。 我要在这个PRD里写什么样的信息内容？ 这里面大家可以去看。这个PRD，根据标准的定义形式，就是我们需要在这个PRD里面，去写到文档的相关信息：你当前这个项目的背景、目标，以及你所涉及的用户画像和用户故事，然后你的这个项目里面的功能范围是什么，以及对应的每一个功能的详细描述、非功能需求、交互设计、验收标准、优先级、数据指标，以及最后的风险依赖。 那么这12项，是微软提供的非常标准的PRD核心流程。所以这一个环节，落到我们的项目形态里面，其实就是属于第二、第三个阶段。当我们完成了这个reset阶段以后，这里面会生成一份所谓的PRD文档。这里面大家能够看到，当前这个项目的需求文档，其实就是一个A股的自动盯盘助手。 那么这个文档信息，其实就是我们整个构建的流程：什么时间构建的，创建人是谁，上下游的产物是什么。然后对应的目标，就是我现在在A股市场，处于混合操作和复盘阶段，核心的日常痛点是什么？多次切换APP看盘，怕错过关键信号，想要看早盘的信息等等。然后对应的目标就是业务目标，我们要去把它做成什么样的事情。 对应这个产品目标，就是我们当前这个产品要做到什么样的一个程度，以及什么不是我们当前这个产品的目标，这些，其实是一定要把它进行定义的。 包括我们的这个产品，在一经推出以后，它适配的用户目标与画像是什么？比如说基本的这个属性，就是软件的普通用户，自学A股、有小几年操作风格，日常去盯大盘，当前的这个痛点是看盘耗时，怕错过一些异动等等信息。反画像就是不服务的人群。 包括下面的用户故事，就是它在当前这个产品里面，都提供哪些功能：关键异动60秒就开始推送，然后每天发送早盘简报等等，非常多的功能。 然后在PRD里面要求了，我们在这个产品的一期里面，都需要去开发什么样的一些功能，关联什么样的一些逻辑。其实这个里面，我们如果去把它定义成这样的一个情况，大模型其实就知道了你做的这个产品到底是什么，它就会非常清晰。 所以这个就是我们去构建PRD的这样一个核心的链路。当然对于我们刚才给大家去讲解的这样一个思路，大家可以去看到，当我们定义好了这样一个PRD的产品形态以后，那么我们所有的产品调研阶段，都是为了PRD来进行服务的。大家可以去回看一下，我们在当前的这个流程里面。 在调研阶段，其实就产出了01到06，覆盖产品形态、数据来源、开源项目、实现方案，以及决策汇总、架构极限这几个部分。这些内容其实都是为了服务最后的PRD生成。 比如说，首先对于业务的描述部分，什么是文档里的内容？背景目标、用户画像、用户故事、功能范围，这一些东西，是不是你哪怕没有技术背景，只要有这样的一个想法，想去开发这个产品，就可以把它落地？所以它不需要对应的技术目标。 而至于后面所谓的技术方案里面涉及到的内容：你要做哪些功能，你的非功能需求是什么，你的数据指标是什么，这些就需要确定你要采用什么样的一些技术框架。 我们的开源项目以及实现方案部分，做的就是一个业务方案的对比。而产品形态、数据来源，它提供的就是PRD里面的用户画像、依赖与约束，以及和业务背景相关的这类信息。所以它是基于这样的情况来构建前面的核心链路的。 这里我给大家看一下，我们做这个PRD的思路的核心链路，其实是这个样子的。对于这个PRD来说，首先我们就是基于前面梳理的这几个项目，也就是基于我们构建的产品形态到实现方案这几个环节产出的Markdown文档，来进行梳理。然后呢，诶。 哪去了？ PRD。 我给大家通知一下，诶，PRD，稍等啊，我给大家切数去了。 然后呢，基于这个，我们就是如何去对14张的主张进行一个钻取。那么这里面就有对应的这个功能，比如我们在这个skills里面，其实就需要把它去进行一个确定。 那么PRD它的这个标准的模式，就是你需要具备文档的信息、项目的背景、用户的画像、用户的故事、功能范围、详细的功能描述、非功能需求、UI交互，等等等等。 大家看啊，这个skills，它其实就直接指导着我们当前的这个PRD里面所有核心功能链路的整体构成，然后由大模型去完成各个中间模块的这样一个抽取，所以它是这样的一个核心的功能。 所以基于这样的一个情况呢，我们去回到它的一个核心的，呃，在这，啊，在这，这个是我们刚才已经给大家讲过了。 所以基于这样的一个情况呢，哎，我们就可以去看一下，如果我们之前在做的这个MVK的这样一个链路，它到底能不能够得上企业级的这样一个形式呢？其实啊，肯定是不太行的。 所以像我们在前天、昨天给大家做的这个MVK，如果你真想把它做成企业级的这样一个知识库，那么当你去提出对应的这样一个需求的时候，说我现在要去做一个企业的知识库，包括我整个的这个数据，来去进行一个管理。 单纯地通过这种所谓的Web Search，肯定是没有办法实现的。所以基于这样的一个情况，其实刚才给大家分享的内容，我给大家看一下，我刚才给大家分享的就是这种多维度调研的链路。多维度调研这个链路，它其实就可以把整个的RAG体系给你构建出来，它会自主地去进行分析。如果你是PLF的，如果你有不同的业务问答场景，那么适用于传统的RAG，还是Graph RAG，还是使用MVK，来进行多架构的这样一个选型。所以这里面，我们就以我们这期的主题——其实我们这期给大家讲的是企业级的RAG落地，所以借着这样的一个主题，也正好给大家补充一下：现在我们在企业里面进行落地，其实无外乎就是三种这样的形式。首先，第一个就是基于向量式的这种检索的模式，它是比较适用于我们的这种海量的文档，文档里面没有一些特别多的实体之间的关联信息，它可以非常轻松地，或者是通过Chunk的这样一个切分的策略，就能够构建起问答的这样一个事实的依据。那么另外一种，就是图谱式的这种Graph RAG，它们是非常适用于这种，比如说你是医疗。 金融领域有非常多的专有名词，而且这些名词散落在不同的文档之间，它们构建了相互之间的关联关系。这种细粒度，我们是需要融入到对应的GraphRAG。而对于编译式RAG，它其实更是用于轻量的Markdown，适配它们之间的这种链式的文档、链式的形式。 所以大家在实际去进行一些RAG构建的时候，除了大家在做Web项目的时候，可以通过我刚才给大家分享的这种多维度搜索的形式，大家也需要知道，不同的RAG的架构形式，它到底适用于什么数据的落地场景。 非常简单：比如说一些合同报告，或者是PDF、Word的这种表格场景，你就无脑选择传统的这种RAG就可以了。现在大家不要被所谓的“现在RAG已经过时了，已经采用什么什么样的技术了”这类说法误导，RAG肯定会一直存在的，而且它的优化策略现在基本上已经非常稳定了。 而如果你的所有问答链路，是需要做所谓的客户关系梳理，或者是去梳理它们之间的一些潜在的联系，那关系图谱也就是传统的这类技术的解析就适用。而如果你们是在内部做一些笔记。 拽药啊， 或者是线索之间的互联，那么就是mlvk啊。 所以基于这样的一个情况，大家应该相对来说比较清晰地知道，我们在企业里面去构建支付的时候，大家更多的去选择什么样的一些策略。 大多数情况下，我们还是采用混合检索的这样一个策略。就是基本上企业里面现在在进行落地的时候，它都不是单一的这样一个维度。 OK，然后小伙伴说，如果是各种书籍，是选择哪一个？正好，我们给大家去介绍的这个页面，你是可以去看到的。 首先，如果你是以语义文档为主的，而且是涉及到整段的这种文档理解，那我理解你的这个场景，它可能更多的适用于这种vk，然后你可以去采用轻量的这个mnvk，或者是去采用nano gbrind这样一个项目。 那如果你是一些结构化的这种pdf为主，那么你可以去采用传统的这个reg的方式，通过OCR，来去进行多模态数据的识别，然后检索入库，走一个通用的流程。 然后这里面也是，如果你是垂直领域的，那就不要想，垂直领域基本上现在gbrind是必上的，垂直领域是必上的，用来找到你的这个专业实体之间的关联关系，去构建海量的这样一个关系网，然后从而达到这样的一个问答功能的链路。 然后还有一种呢，叫做所谓的数值的精确聚合，那么txtecl呢？ 也被称为REG一种，大家可能会，我们一般来说，会把这个数据库也作为一种本地的数据源。然后Text2SQL其实就是通过自然语言，可以链接到你的这个数据库的表结构，然后由大模型去把它转化成Text2SQL，来去根据自然语言，去查询出对应的这样一个事实的链路，来去返回最后的结果。所以它呢，相当于也是这样的一个检索流程。所以，基于这样的一个情况，我们刚才也是给大家，基于我们这一期的这样一个主题，因为带大家去做REG，也是给大家去分享了Web Coding它在开发的这样一个阶段，以及我们接触的这个大模型知识库的这样一个技术领域。其实在整个的这个构建的体系下面，是可以把我们整个的企业级的知识体系，通过在这里面，通过这个决策会商的这样一套流程，明确地告诉你们，应该选择什么样的一个技术架构。所以这里面，大家在进行Web Search的时候，不要再简单地通过联网检索的这样一个形式了，其实还是要给它去制定一些不同的这样一个方向，去制定一些不同的方向。OK，其实这部分，就是我们已经给大家介绍到了，我们从有对应的这个想法，然后到需求调研。 以及写PRD的这样一个流程，包括了，对应在写PRD的这个过程中，技术的架构设计已经完完全全确定了。 所以基于前四个阶段，大家看我们在上半场给大家介绍的，再去应聘一些大模型开发岗位的时候，你说：“我会用Web Coding开发项目。”那么别人问你：“那你平时是怎么维护代码的呢？”你肯定不是人工来去进行校验的，你维护的其实就是一个一个的spec。 所以大家如果想要去深入地去了解的话，这两个框架是一定要掌握的，一个是specator，一个是superpowers。那么officeback呢，相对来说是比较轻量一点，对于我个人来说，我是不太建议大家首选officeback来去做，因为它其实就是一个非常轻量的这样一个构建层。 所以就这样的一个情况，我们在整个的这个核心链路上，其实当你完成了这个PRD需求文档以后，你就是根据这三个不同的技术框架，来去拆分出一个一个的子任务。OK，那你在人来操控的这个阶段就已经完成了。 所以完成了这个阶段，你正常就是进入到前端和后端的这样一个开发。那么对于前端来说，其实大家如果是使用不同的这样一个开发工具，那么他们整个的这个特性是不一样的。 那新手小伙伴，我更建议你去使用这个Figma Mic的这样一个模式，你就直接去使用Figma Mic的模式。那它呢，是可以直接把对应的这个PRD扔给它，然后它就可以给你去开发出对应的这个前后端，然后呢，开发出前端。然后这个前端，你可以通过多轮对话的方式，让它去给你进行调整，然后它会生成完整的这个前端源码，给后端进行对接的话，会相对来说比较容易一些。 那么像谷歌的这个Slitch呢，它其实不会给你生成对应的完整的前后端的源码，而是它会去生成一个所谓的design.md文件。那么这个design.md文件呢，就表示，我当前的这个前端的这几个页面，它里面用的一些UI的主题、token.css，应该是如何去进行设立的。大家就可以理解成，它的这种前端长什么样子啊，它是什么颜色的啊，每一个按钮它是怎么做的啊，其实它出的是这样一个文档。那我们在进行后端对接的时候，前端的这个项目就需要自己去进行开发。 当然除此以外呢，还有像Claw的Design和Fakeman的Make模式，他们其实都是采用的这样一个核心的链路。当然今天因为时间的原因，我就不带大家详细的去进行一个介绍和解读了。然后最后我们去看它的一个后端的实际的开发。 那么对于这个后端的实际开发呢，其实，就是当我们在整个的这个项目链路里面，去完成了一个所谓的、一个一个的feature的构建的话，那么后端在进行开发的时候，核心看的就是每一个feature里面的这个task.md，他会根据这个task.md，一个一个地去完成项目开发和构建。 一个一个完成项目开发和构建。当然在这个过程中，我们是可以借助于specate，或者是superpowers来去进行开发，因为它们默认会有一些所谓的这种流程的校验机制，还有code review的这样一些策略。 这里面这幅图，大家可以在我们的助教老师那里领取到，我们就不给大家展开进行说明。那下面的这一部分，其实它就属于在各个功能链路上的一个测试的阶段。其实大家在开发的这个过程中，会非常痛苦，要把模型开发出来的这些功能链路，实现对应的健壮性。所以我给大家分享一下我个人的开发经验：我在开发的时候，会给每一个链路的test.md做这样的一个标识，大家能够明确清晰地看到，我在每一个子任务里，大家看这个每一个子任务，什么T001啊、T002啊，都是当我们想要开发这一个一个的子任务。 我会给他做这样的一个标识，叫做BE。这个BE，其实它就是beckon的缩写，用来标识当前的这个任务是一个纯后端的。然后再往下我们去找一下，它有没有F，我找找，对，看，然后我再往下，我们这里面能够看到，找到对应的这个FE，看这里面有对应的这种FE。那么这种FE，我给它打的标识，就是前端的开发任务。然后还有一些像这种NT，NT指的就是这个功能涉及到前端和后端的联调，所以我会给它打成这样的标识。这个是我在写这个spec时常用的一种策略。为什么我要去给每一个任务标前端或者后端的标识？是为了我们在这里面去自定义后端的开发测试的链路，就是我需要知道，他开发出来的这个项目、开发出来的代码，到底能不能真正的运行，避免存在一些不确定性，所以我会把它分成这几类。那么首先第一个叫做单后端测试。单后端测试，我会去构建一个所谓的这种skills，大家看我们这里面有一个skills，叫做back end tester。这个back end tester，它里面就明确表示，这个skills解决的就是开发期间覆盖功能是否如规约工作。后端它是有缺口的，然后这个skills。 就是这些缺口的闭环补测，然后它主要针对的，就是后端的一些核心的功能链路，来去提出一些规定的测试方法。然后这里面包括了每一步如何去进行识别，然后如何去定位缺口，覆盖数据层、越权、并发、静态等等。那么这些其实都是我个人在进行开发的时候，沉淀出来的这样一些方法论。然后我会把它拆分到后端测试的体系里，通过调用对应的skills，适配我们开发这类功能链路的场景。比如我们在开发这条功能链路的时候，大模型反馈说我的这个功能已经开发完了，它标识的后端部分就会完成流转，进入到我的这个skills里面去进行一个校验，出问题的话，它自己来去进行修复，这也是我自己使用的这样一套链路。 那么还有一种叫做单前端测试，单前端测试它也是有专门的skills，比如我们这里面是不是有一个Frontend Test？这个单前端的测试，对应的就是单前端闭环测试执行器，它核心解决的场景是：当我在tapen的这个spec任务里面，涉及到一些带Frontend标识的任务的时候，它就会走这样的一条链路。后面还有对应的局部前后端测试，还有完整的功能链路测试。 那这里面每一个核心的功能模块和测试点还是非常多的。大家如果要是感兴趣的话，可以找我们的助教老师，来去领取一下这张图。这幅图就是我日常使用的一些核心策略，如果每一个单拿出来给大家进行讲解，其实都得一个小时左右，所以内容还是非常多的，也是给大家提供了这样一个策略。 OK，这个就是我们构建全链路的阶段。当然我们在上面已经给大家构建了一个全链路，所以接下来还有最后一部分，给大家去拆分一下关于现在所谓的这个Loop，我个人的一些理解。其实对于这个Loop来说，现阶段非常非常多人都在谈论，尤其是有大佬直接说了一句：“我现在已经不再写这个Prompt了，我的工作是写循环。”那么这句话到底是什么意思？以及大家实际在进行开发的时候，你到底做的是Prompt还是在做Loop？这里面我们有自己的这样一个观点。所以首先你需要明白，这个Loop它到底是什么。其实最简单的理解就是，这个Loop就是你给它下一个指令以后，让你的这个Agent反复地去干活，直到满足所谓的这个停止条件。那么什么是这个停止条件呢？比如你让它去完成某一个功能，练某一个功能测试，让它跑到多少分以上，它如果没有达到这个分数，自己会检测这个流程，来去进行纠错。 直到跑到以后，所以你是需要给它去制定对应的这样一些停止的条件的。 当然对于这个Loop，大家可能会跟很多的这些技术名词去混淆，比如说这个Prompt是什么？这个Context是什么？Harness有什么？Loop有什么？ 那么这里面实际是有一个非常明确的拆分。所谓的这个Prompt指的就是，你在每一轮和大模型去进行交互的时候，比如你就能说，你去给我把这些功能做完，那么这个叫做Prompt，它只管这一轮的这个答案。 那么这个Context，它其实指的是你在这个Session里面的一个上下文。模型变成Agent了，在每次去运行链子的时候，它都能够看到什么样的一些上下文，那这个叫做Context。那么这个Context，我们在技术上面一般把它叫做上下文管理，或者是智能体上下文工程，那这里面还是有非常多的这样一个优化的策略。那么当Context给它提供的足够的精准的话，那么它就能够了解到任务的几个全局的这个信息。 而所谓的这个Harness，是在Loop前面一阶段非常爆火的这样一个热词。那么Harness它其实管理的，就是整个Agent这个运行环境，是否会存在一些越权，是否按照你既定的这样一个约定，来去进行运行，所以它更多管控的是 Agent这个行为，而Loop它其实就是整个凌驾于Prompt、Context和Harness之上最深的一个层。也就是基于你的Prompt，然后运用你的Context，以及在你的Harness约束的这样一个范围内，去让你的这个Agent根据你提出的这个需求，不断地、自动地进行循环，直到完成某些标准为止。这个是我个人的这样一个理解。所以其实对于这个Loop，大家就可以理解成，它是自动、不断地、重复地运行，直到完成你的这样一个标准。而其实对于大模型来说，这个概念已经不是第一次出现了，它有一个非常循序渐进的运行逻辑，和技术栈演进的发展阶段。那么首先第一个阶段肯定是在2022年到2023年，也就是ReAct这样一个阶段。ReAct它其实就是让大模型能够自主地去调用工具，调用工具完成以后，自己去判断有没有完成用户的这个需求，如果没有完成的话，它就继续再去调用工具，直到完成用户的这个需求。那么在2023年的时候，当时有一个非常爆火的所谓的AutoGPT项目，这个AutoGPT大家现在在GitHub上也能够找到。但是现在提及和应用AutoGPT的人也并不是特别多了。所以AutoGPT它当时做的是 基于GBT的这个模型，第一次大规模地自己去跑一些复杂任务。当时你们就觉得，哦，这个过程中，大模型可以自己去做一些开发的任务了，觉得非常非常牛。但是实际上它整个底层应用的，也是React这样一个核心的逻辑。然后接下来会有一个Reaction这样一个概念。Reaction这个概念，就是当模型在自主去进行运行的时候，它能够去发现自己在构建量度过程中犯了哪些错误，它发现自己错误以后，自我地去进行修正，然后继续地去向下执行，所以这个叫做Reaction，是自我批评的这样一个记忆。而到了这个Loop，它其实做了最后的一个概念的时候，你收敛。所以很多人都会把这个Go、这个Loop混为一谈，说这个到底什么是Go，然后就是Loop，然后Cloud Code里面又有Go，又有Loop，那么到底什么是这个循环？其实官方已经出面，给出了对应的一个定义。那么这个定义基本上就印证了，我们刚才所说的Prometa、Context、Hanus以及Loop，它们四个之间的这样一个层级的关系。那么Cloud的官方会把它分成这四轮。那么第一轮叫做对话式的，对话式的就是我们一轮，又等于这样一个Prometa。那么其实现在的Cloud的终端，它已经是可以支持，就是你提出一个需求。 它自主地去判断，有没有完成一个任务，它自己去拆分多个子任务链路，然后指导完成。 所以现在的对话式本质上，也是Cloud底层在驱动的Loop这样一个机制。 那么第二个叫做目标式的。目标式在Codex里面，或者是Cloud Code里面，它直观的一个执行命令叫做go。 那么这个go，就是当你用go来去进行一个执行的时候，比如在这个终端，我们给大家打一个，我们打一个这个终端。对啊，这个go就是当你在这个终端通过这个go，然后后面去提出一些挑战，你看它这里面，其实给你对应了这个提示，你去说明一些问题的时候，那么它是会针对于你当前给定的这个目标，不断地去进行一些循环，然后直到完成你当前的这样一个任务。 那么这个，就是它的go的这样的模式，其实Codex里面和Cloud里面都是一样的。 那么第三个叫做定时式，就是在Cloud Code里面，它其实还有一个Loop。那么这个Loop，你可以理解成定时任务，比如说每五分钟做什么事情，每天做什么事情，每隔多长时间去做什么事情，它可以通过这个Schedule，来去做这种定时的任务的流程。 当然最后一个档位，就是主动式的这样一个Loop，它可以通过多个的这种go Loop，来去进行一个循环，写在同样的这样一个提示词里面。所以这个里面。 它们更多应用的就是不同的skills，来去完成构建。 所以这里面很多小伙伴会觉得，如果我去写所谓的loop，那就是在命令行的终端，当我去开启一个任务的时候，我要么通过go来去进行启动，要么就是通过loop来去进行启动。 其实我个人的理解不是这样的。我们现在在做很多的工作流，给大家举一个例子，这里我给大家看一下我真实的开发场景下，做自动化、复杂项目研发的流程。 我看一下，我给大家看一下我理解的这个loop，以及我自己实际在进行使用的时候，它是什么样的一个情况。 然后我们这里问一下：请你给我简要介绍一下我这套全自动企业项目开发的工作流。来，我们看一下，我们等一下它的这个输出。 其实我理解的这个loop，它就是你创建的一个一个的这种agent teams。当你创建好了以后，你每次有一个新的主题的时候，它能够根据你既定的这样一个流程，一步一步的，按照你约束的这个规范来去完成。 所以它更多的是你自己在不同场景下定义的这样一个流水线。而所谓的loop，或者是go的这个命令，它其实是一个agent skills，在对应的这个命令驱动之下。 来去构建了这样一个运行的链路。 所以我会认为，它是一个整个Agent Teams的集合。 所以这里面我们通过它来给大家看一下，我们刚才给大家做的问答，是我在做自动化项目开发的这样一个工作流。 这里面就是我在刚才提问的那个项目下面，它有一个，我看是不是这个，有一个aipod.builder。然后，是不是这个？在这，看一下，在这。 看，这个就是我的Skills，一个工作流里面，它包括了完整的这样一个链路。 其实这里面就包括了我们刚才给大家分享的内容：如何去写PRD，如何去设计前端。只不过我个人的工作流里面，它做的会更加复杂，还包括了如何去做竞评的拆解、需求的分析，然后如何去做对抗生成等等，这个链路的环节非常多。 然后我们看一下它的整个工作流给我们的回复。看，这个就是我这套自建的aipod.builder自动化开发的体系，它是一个人在环、SPEC驱动的全栈aipod.builder产品开发的工作流。 然后它做的事情，首先你看在第一个阶段，来去探测一下当前这个项目落地的可行性。然后一到四的这个阶段，去判断框架的可行性，然后去做立项的调研。然后我们会借助于Cloud Code的dpresearch的这个功能，来去进行一个深度的拆分。然后接下来在4到5个阶段，会做架构极限的对抗。 那么这个其实大家也能看到，法庭式的对抗辩论，那基本上就是我刚才给大家介绍的这样一个流程。然后在完成这个以后，它会使用这个specator，完成这个spec切片，然后去做用户里程的这个图谱，然后接下来去做视觉的竞标。然后在第九个阶段，去构建每一个产品的用户旅程，然后逐feature全资助的，去实现TDD的这样一个开发流程。在最后去真实化地完成mock的数据的取消，改成真实的项目的联调对接。所以这个就是我认为在loop的这个阶段，其实就是一个一个的agent teams来去构建大家定义化的这样一个需求。那么在这个里面，可能每一个子任务，你像我在完成这个TDD开发的流程，比如说这个逐feature全资助的实现，那其实我在整个的编译和定义的过程中，就会频繁地去使用到gallope的这样一个命令，然后让它去进行一个外派。所以基于这样的一个工作流，它能够做的是什么呢？就是我们不断地去调整和优化，然后当你有一个新的项目主题去进行开发的时候，它就能够依次按照你的每一个阶段，来去进行一个构建。而这个过程，我们去看它的核心功能的源码，就是一个agent skills的这样一个集合。我给大家打开看一下，比如我们去找一下。 这个AI Builder，然后它的这个Skills，其实写的就是这样的。看这里面其实就是写的AI产品的主控的工作流。然后第1个阶段、第0个阶段是做什么的，然后第0.5个阶段是做什么的，第1个阶段是做什么的，全局的这些约束是什么。在这里面它会去调用我们在Agent Skills里面不同的这样一些Skills，来去完成指定功能的驱动的开发。也相当于有一个顶层的Agent，然后去派发和管理不同的Agent Skills的这个集群，来去完成相关的这个项目。比如说我们在当前的这个Session里面，你只要是有了这样的一个功能的链路，那你想去做一个新的这个主题，比如说我现在想要去做一个企业级数据分析的项目，OK，你其实只需要说这一句话，那接下来，它就会主动式的引导着你，然后按照你构建的这样一个流程，去完成你整个项目的这个开发。这里面就是我现在去做企业级数据分析，当然我也可以去做其他的这样一个项目，然后我们可以去看一下它给我们对应的这样一个回复。它这个可能会稍微有点慢，因为我们在晚上的这个时间。看啊，这个就是我这里面有一个企业级数据分析项目，它说另起一个新的数据分析项目，然后全新的。我们告诉它，我们要，我要开发一个。对啊，因为我们正在给大家，对，我们的付费学员。 去开发新的这个企业级项目。 所以我的这个研发电脑上，它本来就有一个数据分析的项目。 所以你这里面能看到，就是接下来它的这个回答，就会按照我们既定的这个流程，来去一步一步地进行构建。 在公网有点慢呀。 它第一句话就是，明白，全新项目，那就是套件全流程重新走一遍。 然后在起跑之前，它要干什么？是不是在阶段零，去减配我们当前的这个环境？ 它就按照了我们的这个顶层的这个skills，进入到了阶段零。 看阶段零，它在开工前先去跑，探测一下我们本地，有没有当前这个环境，是不是具备soberpowers、websets这样的一个功能，然后以及它有没有去做一些技术的这些配置。 那么这些都是我们已经给它定义好的，对吧？ 所以我会认为这种工作流，它更多的就是loop的这样一个体现。就是当我们去把它定义好了以后，那么像loop或者是go的这些工具，那其实它都是每一个skills里面核心的这样一个启动的形式，以及去验收每一个中间节点的这样一个关键的命令。 而不是你通过loop或者是go，让它去跑一个超长的任务，那它跑了几十个小时以后，发现它在中途完全的去跑偏了。那么这种很明显，就不是loop的最终的这样一个实现的形式。 所以这个当然就是我的这样一个设计。 OK，其实那最后这部分。 也是给大家重点介绍了一下我对Loop的这样一个理解，以及我日常在进行一些项目开发的时候，自己搭建工作流、搭建这个ATM Team的这样一些核心的。