【附完整文档】OpenSpec管得了文档，管不住AI瞎写？ Spec-Kit怎么补上需求拆解+精确化+代码核对这三道关 #ai新星计划 #抖音前沿科技首发计划 #Agent #openspec #speckit

如果你已经把OpenSpecs摸透了，你会发现它有三个绕不开的卡点： 从0到1，没人带你想清楚要做什么；需求写模糊了没人拦你，代码生成完了也没人帮你核对是否正确。 这三个问题，SpecsKit全都补上了，代价是它比OpenSpec复杂得多。 对了，本期SpecKit的五大子系统拆解图，还有能直接抄的模板我都整理好了，评论区留言找我，我挨个发给你。 那先说清楚一件事：同样是SDD规格驱动开发，OpenSpecs和SpecKit根本不是一个思路。 OpenSpecs做的是轻量文档管理，三条命令走完一个闭环，胜在快、胜在轻。 SpecKit不这么干，它是一个可插拔的平台，有插件市场，有主题市场，背后还配了一整套方法论，专门用来解决一件事：怎么写一份真正管用的项目宪法。 “宪法”这两个字在SpecKit里不是比喻，是一份真实存在的Constitution文件，放在Specify目录下的Memory文件夹里。你在这份文件里写死：项目边界、技术栈版本、代码复用策略。 这份文件不是写给人看的，是写给AI看的，约束AI每执行一条命令之前，都要先回头看它，看自己符不符合宪法。 这一期我们分三层，把SpecKit彻底讲透。 第一层，看它的五大子系统怎么协同工作，CLI主体负责接你的命令。 Agent注册中心管着接哪些模型和工具，扩展系统和预设系统，负责把插件和主题装进来。工作流引擎在背后，把这几块串成一条线。你不需要记住每个模块叫什么，只要知道一件事：这不是一套脚本，是一个平台，装得进插件，也换得了主题。 第二层，看它的双轨命令闭环。同样，走探讨需求、落文档、开发、归档这条主线。SpecKit的命令数量，比OpenSpec多出一倍还不止，九条命令里多出来的几个关键节点，恰好就补在OpenSpec缺位的地方。需求想不清楚的时候，有人带你拆；需求写模糊了，有人拦你重新精确化；代码生成完了，有专门一步回头核对是否正确。这也是为什么，它比OpenSpec更繁重。OpenSpec信任你自己把需求想明白，SpecKit不信这个，它把每一步都卡了一道关。 第三层，也是今天真正的重点：怎么写一份真正管用的宪法。照着我们今天走的流程写，你可以直接抄。很多人上手SpecKit，会跳过写宪法这一步，反正有默认模板，先跑起来再说。但项目一旦做复杂了，没有宪法这道约束，AI会越写越野：同样的界面模式，前后写了三遍；同样的接口封装，悄悄搞出两套。宪法不是形式，是这套流程里唯一真管用的约束。你在里面写清楚项目边界，写清楚技术栈锁定哪个版本，写清楚代码复用的策略，AI才有据可依，不会每次生成都凭感觉。 今天我们会带着写作助手，从写宪法开始，一路跑一遍。 好，那我们现在就开始，先来看SpecKit的第一层。 再说一句，今天这份五大仔系统拆解图和宪法，评论区打文档，我挨个给你。 那话不多说，我们现在开始今天的复盘AI说。 好，大家好，我是沐云。 那我们就开始今晚的内容直播。那今天我们来给大家去继续讲解第二个SDD的驱动开发框架SpecKit。 其实针对于我们上一节讲的OpenSpec，相对来说，它是一个在SDD的轻量的驱动规范框架里面，比较容易入门，而且大家在使用起来会比较容易上手的这样一个开发框架。 那我们今天给大家讲的SpecKit，其实相较于OpenSpec，它的一个应用场景以及它的一个适用度，其实是更加广泛的。那么本质上一个最大的一个原因就是SpecKit，它是一个可插拔的，而且它有广泛的这样一个社区的生态。它并不像OpenSpec那样，只是去做这样的一个轻量的文档管理，而是它会给我们做很多的一种脚手架，给我们去做很多的这些插件，还有它会给我们内置很多的这样一些提示的模板，来去走完SDD驱动的这样一个流程。 所以对于SpecKit来说，无论从它的生态上，还是我们在使用的接受度上，以及我们在使用的便捷度上，毫无疑问，它都会比OpenSpec做得更加的优秀。以及我们在接入 工程化开发的过程中，它的表现肯定也是比OpenSpec要更好的。但是它表现更好的根本原因，也在于它的生态，还有它的架构设计，相对来说更加复杂。所以我们在进行学习的时候，它的上手难度相较于OpenSpec，也会有一定的区别。 那我们今天对于SpecKit，在我们的课程里面，也同样是给大家做了两节课程的设计，带大家从0到1去深度实战OpenSpecKit这个框架。我们是分为上下两节直播课：上半场，我们会给大家讲解SpecKit整体的设计思路，以及它的一些核心设计原则，包括它内置的这些工具集，以及我们在进行使用的过程中，它们之间的一些协作方式，帮助大家理解它内在的原理。 那么我们在下一场课程里面，就会带大家深入讲解SpecKit的全命令，在做一些复杂的项目中，应该如何结合我们的这种工程实践，来去完成项目的开发。当然，无论是今天的这一门课程，还是我们下一节课，都会围绕着具体的项目，来带大家讲解SpecKit这个框架。因为其实对于这个SD的规范框架，或者是我们把它叫做这种规范的工具，它都是在实际的开发过程中，才会有对应的应用价值。 那当然，我们只给大家讲解理论，大家肯定仍然没有办法理解它的应用方法。那我们今天上半场，带着大家，一是快速先去了解一下SpecKit的整体架构，然后我们带着大家去做一个AI写作助手的实战应用。 当然，这个实战应用，我们也会用最简的形式来给大家展开。也就是SpecKit，它其实也有最小的MVP链路。它和OpenSpec一样，OpenSpec可以通过Core最简单的三条命令，去完成一个功能模块的闭环。那对于SpecKit来说，它也有最小的MVP命令，一共五条命令，来去完成最小的MVP的闭环。同时它也有全命令，是九个命令的规范，来去完成这样的功能驱动的开发。 那我们今天，就从最小的这样一个示例，来给大家入手。这是我们今天的直接安排。那么我们可以在开始之前，快速给大家回顾一下OpenSpec的项目，以及它这个框架的使用规范。 其实对于OpenSpec，还有我们今天讲解的SpecKit，包括我们接下来要讲解的SuperPowers，大部分小伙伴可能都会比较纠结，这三个框架都是SD的框架，那我到底应该如何去进行选择，以及我在实际的开发过程中。 到底用哪个比较好？或者是这三个框架，我能不能结合起来去进行一个应用？那了解了这个以后，其实我们就需要明确地去知道，每一个框架，他们真正适用的这样一些场景到底是什么，以及结合你具体的一个实际的开发需求，来去匹配一下，你的这个框架，它的特性到底符不符合我当前的这样一个开发的规范。 那么对于OpenSpec来说，它作为新手入门，最适合我们在不太了解SQV驱动规范的这样一个前提下，借助WebCoding，可以很好地去理解和知道，如何通过文档驱动，来去用WebCoding做一些项目的开发。那么它也是通过最简单的三个命令，就可以完成整个项目的一个闭环。 那么比如我们在使用OpenSpec的时候，它第一步我们大家也可以通过ifloid这样一个形式，去和它去进行一些技术方案，或者是我们功能需求的这样一个探索。但是真正去落成文档驱动的，就是它的Propose的这样一个命令。那么Propose的命令是可以帮助我们，把我们所需要接下来进行开发的这样一个功能，以及我为什么要去做这个事情，直接地去落成本地的Markdown文档。 那么通过Applan，它就可以根据Propose在提案的这个阶段生成的设计文档、生成的文档驱动规范、生成的task.md任务清单，来一个一个完成代码的执行。 同时，最终完成某一个项目模块以后，它是可以通过rk5的这样一个命令，把当前的这个模块所有的文档去进行一个归档，标示着当前的这个任务模块所有这些功能我们已经开发完毕了。 所以基于这样的一个情况，我们是可以借助OpenSpec，快速的去完成一个项目在功能上，无论是小功能点，还是大的一个项目体系下这样的一个完整的闭环，它是完全可以的。 但是随之带来的，我们也反过头来，去反观OpenSpec，去找一找它的毛病，它的毛病到底在哪里，到底是什么原因，导致它虽然轻量，但是有很多的缺陷，是没有办法弥补我们在开发过程中的一些不足的。 那么首先第一个，就是它的greenfield落地是比较困难的。其实我们在之前的课程里给大家做过一些介绍，关于greenfield，它指的是我们从0到1的去搭建这样一个项目。那brownfield指的是我们从1到n，在已有的项目代码上，比如你在GitHub上拉下来一个开源项目，然后你基于这个开源项目，继续进行你功能点的开发，那么这个叫做1到n，你已经有了这样一个基础体系。 那么OpenSpec它的一个核心的设计原则，其实更加倾向于brownfield，适配大家已有的开发规范。那么对于greenfield，它为什么会比较困难呢？大家可以去回顾一下。 我们在使用OpenSpec的各个阶段，尤其是我们的第一个阶段，Exploring这个阶段，那么Exploring它其实本质上是建立我们和大模型在所谓的对话框，比如你使用的Cloud Code，比如你使用的Crosser，它是建立在中间的这样一个轻量层。它可以基于你们在对话过程中体验的一些重点，然后直接去触发Purpose，把它落成纸面上的这样一些文档。 但是你在进行交互的过程中，其实你会发现，它没有特别多的引导式的提问。比如我也不知道我这个项目都做哪些功能，我也不知道对应的这个项目它都有哪些技术点，那么你通过Exploring的这个方式来去进行问答的时候，它其实没有一些提问式的引导，比如说我去给你推荐一些框架，我一步一步地引导你，你先确定什么框架，你再确定什么需求，然后这个文档就出来了。这个其实OpenSpark它是没有的。所以这个就导致，虽然它适合我们一些新手，或者是没有太多编程基础的小伙伴，来去快速应用到文档驱动的Coding的这样一个流程，但是你真正想把它做深，如果你自身没有技术理解的话，是很难落盘出一个比较完整、企业比较完备的这样一个规范文档的。这个是它最大的几个问题：就是它的Greenfield从0到1去搭建项目，没有这种引导式的提问。 或者是它内置的一套流程，来辅助你去建立整个项目的认知。所以它不太适合从0去进行开发，更适合从1到n去进行一个开发。 第二个就是它没有 Clarify 这样一个机制。那这个机制指的是什么呢？就是我们刚才说的，它可以去澄清我们在生成规范文档之前所落盘的这样一些技术决策、功能模块，它是可以通过引导式的发问，来帮助我们一步一步地确定：你当前的这个技术栈选择的到底好不好，你当前的功能需求确定的到底好不好。它是没有这样的一个机制。如果没有这样的一个机制，它就会导致，如果我们作为开发者来说，需求不明确，或者是对技术框架不太理解，完全由大模型进行交付，那么它在生成代码以后，我们返工的概率是很高的。就是因为它的需求写得并不是特别清晰，而你又没有对应的这样一个技术判断力，那就会导致它做出来的这些内容，和你实际想要的是不符的，那你肯定就需要进行返工。 这个也是 Specate 它很难让我们去进行一个更加复杂项目的开发，或者是引导你从一个不懂技术，到完成一个实际落地需求的这样一个框架，它的一个最大的短板。这是它的第二个问题。 那么第三个就是它的 Verify 模块。其实对于 Verify，OpenSpec 它本质上是有这样的一个校验的机制，我们也给大家去介绍了。 当我们通过Verify去进行构建的时候，我们可以通过所谓的这种项目的完整性、项目的正确性、项目的一致性，来去确定一下它实际生成的代码和你文档是不是去进行一个匹配。 那么在这个过程中，可能更多依赖的，还是我们人工的这样一个经验，来明确地告诉他，你要在什么地方去进行检查，和我的Spec是不是有相关的一些出入。 一旦你的各个校验的这个维度，没有很好的一个定义，它依然检查不出对应的一个问题。所以它也会导致，如果我们缺少了对技术的这样一个认知，Spec和实际生成的代码有相关的矛盾，那么你在写完代码以后，就需要花大量的时间去进行校验，去进行返工，去进行调试。这个也是SpecIt、OpenSpec它的一个核心问题。 那么针对于这三个问题，在SpecIt里面都有非常好的这样一个解决方案。它的一个解决方案，首先我们来看第一个，它从0到1的这样一个问题，就是我们很难去构建它的一个架构的体系。那么SpecIt，它其实也有所谓的一个Constitution的这样一个宪法的这样一个规则，大家就可以理解成，那它指的是什么呢？指的就是Cloud Code里面的Cloud MIMB文件，它指的就是Crosser里面的Rose文件，它或者也指的是OpenSpec里面的。 那个Config.yaml文件，它是直接针对于你当前整个的这个项目架构，来去定义的这样一个项目的宪法。大家就可以理解成，那对于我们现在这个人类社会来说，我们是由法律来约束我们的这样一个行为，而这个宪法就在SpecIt里面，是约束你整个开发框架的架构设计、技术全景、它的一些代码规范等等。我们都可以在写项目之前，把它定得死死的，那么它在执行的时候，就会严格地去按照你构建的这样一个宪法来去实际执行，从而让你的这个代码，在生成以及后续维护的过程中，是非常可控的。这个是它的一个核心的设计规范。 那么第二个就是，它没有所谓的这种引导式的提问，也就是在OpenSpace里面，你可以通过Explore和它不断地去进行沟通，不断地去聊，然后确定了框架以后，写了这个Purpose，落下了很多的设计文档、它的需求文档、以及它的Spec文档、以及它的任务的清单。那么在这个过程中，如果你没有技术判断能力的话，你可能就不太知道，它这一部分到底有没有问题，存不存在一些假设性原则，存不存在一些我们未知的这样一个冲突等等。那么对于SpecIt，它的一个解法是通过Clarify，可以去进行一个主动的提问，也就是它会根据你所构建的这样一些文档来解析以后。 主动地去提出一些发问，比如在写代码之前，去填充所有的这样一些歧义的信息，然后去发掘一些可能我们自己在进行开发的时候，都很难去发现、或者是避免的这样一些盲点。 那在这个阶段，只要是我们提问得足够详细，那么它是可以帮我们来去进行一个解决的。 那么第三个叫做Verify。其实对于Verify这个校验，你用任何的这种驱动开发框架，它都会有对应的这样一个解决方案。那么对于Spirit，它也有校验的这样一条命令，它内置了一个比较相对完整的这样一个workflow，可以针对于它所构建的这个流程，来去进行一致性的校验。 所以相当于来说，我们既可以去补充一下我们认为需要给它去进行校验，或者是定义一些规范。那如果你完全没有任何思路，完全没有任何想法的话，也可以直接用它内置的这一套流程，来去进行一个快速的准确性校验。 那么它构建的这个过程，我们在后面给大家去进行讲解的时候，也会带着大家逐步地去剖析，它到底是怎么去进行的一个代码的审查。 所以基于OpenSpirit它本身存在的第三大问题，在Spirit里面都有对应的这样一个解法。所以大家理解了这样一个过程以后，我们已经初步地去回顾了一下OpenSpirit，它其实还是优势点很明显，它的劣势也比较明显。 那如果我们去切换了SpiritKit，如何去进行一个构建呢？那我们今天当然也会围绕着这样一个项目实战，来去给大家逐步地展开讲解。今天当然我们做的这个项目，也不会特别的复杂，主要是以它的SpiritKit驱动开发的这样一个流程为主，来给大家演示快速地进行一个上手和入门。所以我们做的这个AR写作助手，会带着大家去做这样的几个场景，比如说做一些学术的润饰、商务邮件的润饰、社交媒体、技术文档、创新写作和翻译优化。就是我们输入对应的这样一个文本，它可以根据我们选择的这样一个场景，去对生成的文本来去进行一些润饰。而我们当然今天使用的是它最快速入门的一个最简的五条命令，完成一个最小的MVP的闭环。这个是我们今天的这样一个实战的安排。然后我们刚才给大家去说了非常非常多关于这个OpenSpark它存在的一些问题，然后我们也给大家提出了一些关于SparkKit，它针对于OpenSpark的一些解法。那我们再来看一下SparkKit它的一些核心的工作流。其实我在这里面去给大家做了一个非常详细的划分，如果大家已经看过OpenSpark或者是实践过的话，你已经对SVD的这个驱动规范流程比较熟悉，那你再来看SparkKit，其实本质上并不是特别复杂。 本质上并不是特别复杂。 因为现在所有的这些框架，或者是工具，它封装的都是比较好的。 而对于SVDD来说，它本身原有的这个规范就定义在那里。我去生成对应的需求文档，我去生成规格文档，我去把任务做子拆分，然后在执行代码的这个过程中，可以实时地去监控我当前完成的这个子任务，然后把它回填到我任务完成的这个清单里。其实都是这个样子的。 那对于SparkKit来说也是一样，我们可以对标着OpenSpark来去进行理解。那么首先第一个叫做它的项目宪法。所谓的这个项目宪法，大家还记不记得，我们在使用OpenSpark的时候，会用它去确定一个config.yaml文件。这个config.yaml文件，我们当时给大家去解释，这个文件它是可以去帮助我们约束OpenSpark，它在去生成文档规范的这个过程中，生成文档的这样一个标准。 那对于SparkKit它的这个项目宪法，其实它所做的事情也是一样：我就是用来去确定一下，我当前在用SparkKit来构建、使用Labcoding来构建这个项目的一些规则，它的一些宪法，我在这个项目执行的这个过程中必须遵循的一些原则是什么，是在这里面可以去进行定义的。同理，大家就可以把它理解成Cloud Code里面的Cloud.MB文件。 这个Cloud里面的Roost文件都是可以的。 这是第一个，我们还是要去给它建立这样的一个项目的宪法机制。 那么第二个叫做Specify，Specify它其实是对标OpenSpark的Purpose，就是它实际的去进行一个提需求，就是和它去进行需求交互的这样一个流程。 然后对于它的Plan，就可以针对于你前面提出的这样一个需求，把它落盘成具体的实施的法案。 那么这个法案里面可能就会包括：我都要使用什么样的一个技术的架构，我都要去完成什么功能模块，在这个过程中我要做什么功能、不做什么功能，我要遵循什么原则等等，它会落成一个非常详细的这样一个技术法案。 当有了这个技术法案以后，它会通过所谓的Task的这样一个命令，去把你的这个技术法案去拆分成子任务。 也就是说你的这个技术法案可以理解成，这是一个项目的蓝图，里面有很多的功能。 那接下来，在技术法案里面还标识了每个功能，我要用什么技术栈去进行一个编写，然后各个模块之间的耦合程度等等，都会在技术法案里面。 那实际在进行代码生成的时候，就会由Task把它去生成一个一个的Face，按照功能模块，每个功能模块都有哪些功能点，一个一个的让代码Agent来去进行一个运行和分析。 这个是Task，也是一样的。 就对标着Purpose，OpenSpark里面的Purpose完成以后，它会生成一个所谓的Task.MD的文件，它是这样对标的。同时当完成以后，它还会有对应的一致性分析。其实它这个过程就是进行一个一致性检查的校验，它内置了一系列的检查标准和规范，我们是可以直接运用。同时在使用的过程中，也可以提出我们自定义的需求，它整个使用过程是非常非常灵活的。而最后当有了Task，它最后一步叫做ExploringMd，就是我开始根据你的Task里面拆分出来的每一个子任务去完成代码的实现，这个就是它构建的一个流程。本质上也是一样，我确定当前项目的一个先法，然后我去实际写需求，确定好了需求以后，我去生成对应的一个技术方案。有了完整的技术方案，我针对于这个技术方案，去拆分每一个子任务，以及它下面的子功能点，接下来我再去完成这样的一个代码实现的流程。当然这里面其实大家看，有一个Clarify和一致性分析，它们这两个节点是可以直接去绕过的，可以直接去绕过的。所以像Clarify和Analysis，它们这两个并不是完全必须的流程。比如我们刚才说了，所谓的盲点发现，指的就是当你完成你的需求确认以后，它可以通过引导式的提问。 来去帮助你发现你当前构建的需求，它到底有没有一些你考虑不到的地方，你的设计前后有冲突的地方，它是可以帮你去进行发现，然后重新的澄清，不断的去描述，你不断的去完善你的specify。 有了它以后再去生成完整的技术方案。当然你也可以绕过这个过程，直接让它去生成方案，这个是完全没有任何问题的。 而对于Task到代码实现的这个流程，也是一样的。我可以在完成了这个任务拆分以后，直接就让它去看，比如我的技术能力就非常强，或者是我的需求本来就比较简单，我不需要让它去进行一致性的分析，我直接让它去生成，是可以的，所以它是可以去绕过的。 当然严谨起见，我们也可以去调用它的一致性分析，其实就是校验，在生成代码之前先去review一下，这是它这样的一个流程。 所以对于Spacate，它和OpenSpac，它们之间最大的一个区别，你就会发现，它在每一步，它会更多的完成一步以后，会停下来，由人工来去进行一个确认，从而去走完你整个的过程。开发人员，无论你之前懂不懂技术，只要你在这里面使用webcoding去进行项目的开发，那么你就是开发人员。它会针对于每一个环节，多次的停下来，向你去询问：我要不要干这件事情？我如果做这件事情可不可以？所以它内部有很多的这种gate。 所谓的gait就是门控。 你到门控这里，它就会停下来，来和你进行提问，或者是确认。 所以这个就是Spacate，它和OpenSpacate最大的一个区别，就是它其实每一步之间，都会有很多的这种人工的检查点。也就是说它比较推崇，每一步的产出需要经过人工确认以后，再去进行推进。 因为它的项目框架的团队，或者是作者也认为，本来web coding它就是一个黑盒。那么Spacate它在进行生产的时候，我们通过文档来去驱动项目的整个进度。那么中间的Spac，就是需要人类来去进行一个掌控、熟悉，才能够很好的去掌控整个项目的开发迭代进度。这个是它的一个核心的设计规范，其实就和OpenSpac有本质性的这样一个区别。 那接下来我们了解了Spac，OpenSpac它其实是有这样的一个核心的工作流，而有了这个工作流以后，它是通过不同的这样一个组件，以及它的子模块，来共同的去构建出它的运行的流程。比如我们这里给大家去分了这样几个组件： 首先第一个叫Clean主体，第二个叫做Agent注册，第三个叫做扩展系统，第四个叫做预设系统，第五个叫做工作流引擎。 那么这里面，大家应该怎么去进行理解呢？首先我们给大家去进行一个拆解，我们下面给大家做了一个详细的讲解。首先第一个。 这个扩展系统，它指的扩展系统和预设系统，它指的是什么东西呢？ 对于这个扩展系统来说，大家就可以理解成，它是一个在原有的既有架构上，额外新增的一些能力。大家就可以把它理解成，大家在使用谷歌浏览器的时候，可以安装很多的插件。那么对于谷歌浏览器来说，它本身就是由谷歌开发的这样一个浏览器，它有很多内置的功能。那么谷歌的插件，就是很多的开发者觉得，我在使用你当前的谷歌浏览器的时候，你的有些操作不太方便，我开发了一个插件，我放上去，如果有人用的话，就把它下载下来，就可以进行使用。 比如我们这里使用的这个翻译软件，它其实就是一个插件。 所以对于Extension来说，它在Sparket里面，除了就是官方维护的这样一些内置的组件和能力以外，是可以通过Extension来去进行的一个固件。 给大家举个例子，比如说这个Sparket里面，它没有一些项目管理方面的这些组件或者是流程，那么就有对应的Gate分支的管理，或者是归档RK。对于Sparket，它其实是没有RK的这样一个概念，也就是你完成功能修复以后，我进行一个归档的这样一个功能，其实是没有的。那么我们就可以通过扩展的这样一个社区、扩展的这样一个论坛、扩展的这样一个市场。 来去把对应的这些组件给它下载下来。那我当前的这个系统里面，就有了Gate分支管理，有了对应的这个归档能力。所以它就相当于，我在EU的SparketK上面，有一个扩展的插件市场。有了这个插件市场，大家就可以自己去开发这样一些不同的插件，在Sparket里面，大家可以共享去进行使用。而且它内置Sparket也去提供了，关于你去开发一些新插件、如何适配我当前Sparket的这样一个规范，所有人都可以去进行开发。那只要是分享出来，大家都可以去进行使用。所以它的一个核心的机制，其实就是应用到的Hooks这样一个命令。这个Hooks命令其实是非常关键的。比如我就以Cloud Code来进行举例，其实Agent在整个的构建过程中，它里面有很多的中间阶段点，比如说我在执行调用工具之前，我在执行调用工具之后等等，它都是其中的一个Hooks。那我们就可以借助于它Hooks的这种功能，来去完成让它在执行，或者是触发某些行为以后，必须要做什么事情。那我们通过这样的一个方式，就可以去构建出一个一个的Sparket，构建出一个一个的这样一个新的插件功能，这个是完全可以的。那么另外一个Preset，Preset它指的是什么呢？Preset它其实指的是，我们还是拿谷歌为例，那么我们刚才说的。 这个Extension的插件市场，指的是我们可以在谷歌浏览器上完成一些新功能插件的安装。 那么对于Preset，大家就可以理解成谷歌浏览器的主题包。我当前的谷歌浏览器是暗黑主题的，我可以在它的商店里面，把它换成亮色主题的，换成粉色主题的等等。 那么它所做的事情是什么呢？它做的叫替换行为。也就是说，我的Sparket里面有很多内置的工具，大家可以理解成每一个内置的工具，它其实也是有command的，也是有skills来进行构建的。 如果我觉得你构建的这个skills不好，那我就可以重新做一套Preset，来把你构建好的skills进行替换。所以它做的是替换。 那么针对于Preset这样的一个组件，它其实就是做一些极限的工作流压，或者是做一些迁移的流程，或者是你内部有一些专有的工作流程，你都可以把它原有的内置的这些组件进行替换，它是这样的一个作用。 所以Extension做的是一个加法，也就是我在你当前的Sparket项目驱动规范下，去新增一些能力。这背后有一个很庞大的社区，大家可以去进行共享。那么第二个是Preset，Preset做的是替换，也就是我把你现有的这些功能，换一个风格。 我换一个使用的策略，我换一个工作流等等。这个是它的一个插件市场。所以对于Sparket，我们刚才说，它有三五大模块：CleanAgent的注册、扩展系统、预设系统以及工作流引擎。我们现在知道了，扩展系统是什么，以及它的预设系统是什么。那接下来我们看它的一个Agent工作流，指的就是对于Sparket来说，它的这个工作流就是我们刚才说的这个东西，这个就是它的一个核心的工作流，它的一个核心的起步的命令，就是它构建的一个工作流。当你去完成一个单独模块的开发，或者是创建的时候，你就要先给它一个项目，先写需求，然后去写技术方案，接下来针对你的技术方案，去拆分Task，最后实际地去执行代码。这个就是它内置的这样一个工作流。所以它的一个full SSD，它的一个闭环，就是我生成规格，也就是生成需求，生成规格需求以后，通过Gate门的这样一个机制，来去进行人工的审核，到底是同不同意当前的这个需求。如果同意的话，就继续进入到Plan，写技术方案的这样一个环节，接下来继续让人来去进行审核，如果审核通过，再进行任务的拆分，到最后的写代码。这是它的一个核心流程，其实这个就是它内置的一个工作流，而直接的展示形式，就是我们一会在下半场要进行使用的，比如说我第一步去做一个specific。 第二步，去做plan。 第三步，去做task。 第四步，就要去做exploitment，去把它的代码进行一个执行。 这个就是它的一个核心的流程。 而对于这个工作流来说，目前它其实只有内置的这一个。我记得是在0.6.1的这样一个版本，才去发布了工作流的这样一个概念，然后社区现在也还没有成熟，所以我们现在主要使用的还是它的这样一个标准的规范流程。 我们现在其实已经了解到了，它的这个工作流到底做的是什么，其实就是类似于像OpenSpark一样，逐步地去写需求规划，然后拆分以及执行代码的这样一个流程，只不过它是可以做成一个workflow，来去进行一个运行。 OK，那我们现在了解了这个，我们再看一下，所谓的Agent注册，这是什么？ 那么这个Agent的注册，大家就可以理解，当我们去使用Sparkit，去生成文档、写文档规范、和它进行聊天、让它去执行代码，每一步都绕不开什么呢？绕不开的就是我们所使用的这样一个IDE里面内置的模型。每一个过程都需要模型来进行一个参与，和我们进行交互，和我们去进行制定方案，去实际地写代码等等。 那它怎么去做呢？所谓的Agent的注册非常简单，其实它做的就是一个各个IDE的集成。那么举个例子，比如说当我们使用Windsurf，或者是Cursor这些。 那么它呢？ 当在使用整个的Sparkit的流程中，它会做的事情就是，把所需要的这些扩展、所需要的这些文件驱动、所需要的这些需求，去写入到你对应的所使用的IDE里面。 比如像Cursor，我就写在你的Route里面。如果你要使用的Germany，如果你要是使用GitHub，它会有不同的这样一个扩展。 而比如像我们使用的Cloud Code，或者是CodeX，那它其实就会集成对应的这样一个Scale的机制。 它在我们的本地的项目目录下，去创建它的Scales以及它的Command，包括了像你的这种，如果我们使用Cloud Code，它做的这样一个Cloud.MD的自动维护。 其实大家就可以简单的去理解成，我的Agent的注册，就是当我去选择了不一样的工作流、不一样的功能来去进行执行的时候，它会根据它内置集成的这样一些规范，来正确的去配置你所使用的AI编程工具。 包括在以后所有的各种命令和各种交互的这个过程中，结合着你对应使用的编程工具内置的一些规范，来去完成相关内容的一些操作。这个应该是非常容易理解的。 所以我们刚才也是拆开的，去给大家讲了一下Agent的注册是什么。基本上我们现在所有使用的主流的AI编程工具，它全都是包含的，全都是可以进行适配的。 所以大家完全不用担心，我们课程使用的这支Cloud Code，那我使用Cursor，能不能使用Swi-Kit？是可以的。甚至你都不需要关心它怎么执行，我们所有的词、所有使用的这个方法，它在后台都会进行一个默认的适配，这个是没有任何关系的。 那么第二个，扩展系统，大家也都知道了，它其实是通过一些新增的命令和Hooks的能力，来去做所谓的这类新功能的插件。你可以根据你自己的一些需求，在插件市场里面，找到一些额外的这种扩展能力。 那么第三个就是所谓的预设信头Preset，Preset就是可以去覆盖它默认的Scales，它的一些Markdown的规范，去替换成不同的这样一些风格。 那么对于所谓的这个工作流，我记得是0.6.1的这个版本才提出的。那么默认它就是使用的这样一个逻辑：先写需求，这里默认使用的就是写需求、审核构建方案、然后拆任务、执行代码的这样一个默认的工作流，这是它的一个核心的流程。而SDT的核心工作流也在这里面，我们一直在给大家反复地进行提及，一会儿我们在写项目的过程中，也会演示这几个命令，来给大家做一个详细的讲解，这是它的一个核心的流程。 OK，那我们现在了解了它的Agent注册中心，了解了它的扩展系统。 了解了它的预设系统，了解它的Cline，那么它的五大内置子系统全景是什么样的呢？大家可以通过这幅图非常清晰地了解。 首先，用户是通过命令行操作的，因为你的Cline Code也是命令行，或者是你的Cursor，它本质上也是命令行，只不过它给你封装了一个可视化的IDE环境。 所以当用户通过命令行，和SwiCate进行交互的时候，它首先第一步，肯定进入的是Cline的主体。对于Cline这个主体，其实它没有任何独立功能，它相当于一个总调的中心，也就是当你要做什么事情的时候，它去找到对应的功能，快速进行执行。 比如，如果我执行一个固定的Workflow，就正如我们前面说的，一个Workflow它可以直接完成下面所有的这些流程。那当你去执行这样的一个Workflow的时候，它就会直接通过Cline去调用Workflow的相关逻辑，来逐步引导和提示你完成一个子功能：从写需求、写方案、拆分任务，到最后走完代码开发的全流程。这个是其中的一个分支。 而另一种，其实它所代表的就是，我们在日常使用中更常选择的手动模式。因为它的这个Workflow，目前来说也是新提出的一个概念。 并不是特别的完善。 那么这种手动的模式，它就要求我们需要去调用和配置我们当前所使用编程工具的这样一个初始的环境，然后根据我们使用的不同的命令，来去执行对应的一些核心的操作。 而针对于它的核心的操作，我们也说了，不管怎么样，我不管你用什么样的一些预设的系统，也就是我的预设的模板，我也不管你用哪种扩展的命令，你肯定所有的这些，都是需要给到我的Adent注册中心的。 就是因为你不管去写需求、写方案、写代码，都是需要用你编程工具里面内置的大模型来去进行执行的，所以所有的这种预设系统、你的扩展组件、它内置的流程，全都需要向Adent注册中心来去进行一个注册。 而对于Adent注册中心来说，它下面是集成了现在主流的各种的编程工具：Crosser、Cloud Code、Codex等等。它连接好以后，配置好你的扩展系统，是根据Clean的一个主调度，来去完成对应工作的一个编排。 所以大家可以在这里面简单的去理解成，Cli的这个主体，指的是唯一面向用户层的这样一个入口。那么工作流引擎，它指的是独立的这样一个子系统，可以直接来去进行一个调用。 那么大家这里面看，它其实也有虚现，就是它也会去使用你对应的Adent注册中心，只不过会在这里面去进行一个直接的关联。 那么同时，对于预设系统，预设系统它其实就是一个平行包管理工具。无论是扩展系统和预设系统，它其实都是可插拔式的平行包管理工具。而对于Adent的注册中心，它就相当于一个共享的服务层。所有的流程，必须要经过Adent的注册中心。所以我相信通过这样的一个讲解，大家应该对Specate的子系统，以及当我们在使用这个框架的时候，每发出一条命令，它们之间的关系到底是什么，应该是有了一个非常清晰的理解。OK，那我们回到它的具体功能，来去进行一个说明。那么Specate，它的三大核心是什么呢？正如我们刚才所说的，首先第一个就是它的宪法，它的项目宪法。这个项目宪法，Cloud Code的Cloud.md文件，OpenSpec的Configure.yaml文件，它所做的事情，就是所有命令，我内置的所有的这些功能，在运行的时候，都必须遵循的这样一个宪法的约束。相当于这个宪法里面定义的，只要是使用Specate，无论是它内置的这些驱动，还是你接入的额外的插件市场的新增能力，还是你用了不同的Preset模板，它都要遵循对应的项目宪法。那这个里面，我们一般来说去写什么东西呢？当然它也是一个非常精简。 而且具有总览性质的这样一个说明。它里面的核心就是：第一个，我构建当前项目的一些核心的原则；第二个就是，我构建当前项目的一些额外的约束；第三个就是我对当前项目，它的一个开发流程是什么，以及我如何治理我当前的项目。所以大家就可以理解成，我们所写的Constitution，它的一个质量就相当于AI在你当前web coding驱动当前项目的流程中，它的一个实际的输出质量，和所需要必须遵循的规范。这个是它的一个项目宪法，非常非常关键。那么第二个就是它的一个插件市场，我们刚才也说了，我们可以自己写，也可以去使用别人已经开发好、公开出来的，根据你自己的需求，来去进行一个灵活的选择。只需要安装下来以后，就可以像Gunsbacket这类工具，点一点这样的一个命令，来去进行一个使用。而对于Preset系统，我们刚才也说了，它可以简单理解成像我们使用谷歌浏览器，去给它换一下皮肤，给它换一下颜色。也可以简单理解成，大家现在在使用手机，里面你可以自己去设计一些主题，包括设置背景照片，调整各个App的呈现样式等等，它其实就是一个不同的主题。那反过来放在我们的SpireKit里面，你就可以简单理解成，当我们再去构建不同的这样一个流程的时候，比如我们去生成规格，我们去写方案，它都是通过Scales里面。 定义的一些MacDom文件，来进行驱动。那我只要是换了主题，它可能生成规格的Scales.md就变了，它的Plan.md也可能去变。当然，它的可扩展性也就因此出来了。比如说你想去时刻限定它生成规划的这样一些侧重点等等，那你只要改一次，那么后面你每次在生成新方案的时候，只要是应用到你当前的这样一个Preset，它都可以按照既定的规范来进行生成。这个是它非常容易扩展的一个根本用途。