Mattpocock skill大升级 这份来源介绍开发者 Matt Pocock 发布的代码仓库 Skills v1.1 版本重大更新。作者通过视频详细说明了核心技能指令的重命名，例如将原有的 PRD 生成工具更名为更具通用性的 to-spec，并将任务细分工具改为 to-tickets 以匹配实际工作流。更新引入了名为 Wayfinder 的全新复杂任务规划系统，旨在通过 GitHub Issues 将庞大需求拆解为可管理的子任务。此外，该版本还新增了 implement、research 与 prototype 等技能，并对 TDD 流程及代码审查标准进行了优化，以提升 AI 辅助开发的协作效率与代码质量。作者强调，这套工具不仅适用于专业工程师，也能帮助新手构建完整的软件开发生命周期。 #大模型 #aiagent #codex #claudecode

大家好，朋友们，好久没有发视频了。 这是因为我一直在忙着更新我的技能仓库到1.1版本，里面新增了大量令人惊叹的内容。 还有一种全新的烧烤方法，可能值得单独做一期视频，但我会尽量在这里简单介绍一下。 现有技能也有很多新变化，包括对两个主要流程技能的重命名，内容实在太多了，我没法在开头全部总结，所以你只能看完整个视频才能知道。 你可以看到，这个合并请求现在已经可以直接合并了。 那为什么不合并呢？ 那我们就真的把它合并掉，就这样，我们的1.1版本已经准备好了。 我们先从两个可能会让你们觉得最烦、最想问为什么要这么做的改动说起。 我之所以这么做，是有一个非常具体的原因，就是有两个技能被重命名了。 比如Two Proud现在已经被重命名为Two Spec。 如果我们再往上一层看，Issues也已经被重命名为Two Tickets。 我之所以这样做，是因为这件事困扰我很久了。 我们在Two Proud里创建的东西其实并不是一个PRD，它其实是一个规范文档。 产品需求文档通常会描述更多关于实际产品本身的内容，而我们之前允许一些并不属于PRD的内容混进了PRD。 所以很长一段时间以来， 我都想把它重命名为 Two Spec，因为这才是我们真正创建的东西。 我们其实只是在创建一个规范文档。 规范文档是一个更广泛的术语，它实际上涵盖了我们要做的事情，为我们想要构建的东西制定规范。 它可以是技术性的，也可以是非技术性的，甚至可以两者结合，其实并不重要。 说到 Two Issues，Two Issues 总是让人觉得它偏向于使用 Issues 的 GitHub 和 Linear，但实际上我们希望它是 Tickets。 你有一个规范文档，然后在规范文档下面有一系列 Tickets，这些 Tickets 就是你实际执行规范、将其实现的过程。这件事困扰我很久了，现在终于不再让我烦恼了，这让我感到很开心。 不过，这次重命名有个让人头疼的地方，就是你可能需要删除那些技能，然后重新添加。 这意味着你需要运行 npx skills add matpork skills，我很确定这个技能安装器不会检测到重命名，所以它不会尝试把 Two Specimen 更新成 Two Spec，你明白我的意思吧？ 所以运行这个命令是获取所有这些新技能最安全的方式，因为你可以挑选你想要的技能，完成之后。 你最好再检查一遍你的Skills文件，确保没有不需要的技能还留在那里，所以你要确保自己有意识地获取了所有正确的技能。下一个变化是，我修复了大家在使用Grillme和Grill with Docs时遇到的一些bug，这两个功能都依赖于一个核心的参考Grilling技能，这个技能会向LLM展示如何盘问一个人。我把这里的这句话改得更明确了：一次问多个问题会让人感到困惑。即使有了这个明确的指示，让他一次只问一个问题，他有时还是会一次问好几个问题，所以我已经告诉他，为什么我们不希望一次问多个问题。我们还在最后加了一个确认环节：在我确认我们已经达成共识之前，不要执行计划。很多人在不同的模型上反馈说，盘问环节会突然结束，然后直接进入实施阶段，所以这里就多加了一个小小的关卡。最后，在某些情况下，他甚至会自问自答，这真的非常奇怪。这不是我个人遇到或注意到的情况，但我只能了解这些技能实际使用方式的一小部分，所以我基本上尝试用几个引导性的词语，来区分事实和决策。有时候他会用之前的表达方式，只是探索代码库并自我盘问，实际上这种情况在fable上尤其常见，因此我决定在事实和决策之间做出区分。 也就是说，事实是你通过探索代码库自己发现的内容，而决策则是另外一类，决策需要由用户来做出。所以只是在句子里加了几句话，调整了一些内容，让整体变得更加一致了，关于那些奇怪问题的投诉确实少了很多。接下来要说的是，我新增了几个技能，这些技能实际上是把原本主要是规划流程、并没有真正引导你进入实现阶段的过程，转变成了一个完整的软件开发生命周期。很多人问我流程是什么，你应该如何配合这些技能使用主要的流程。首先我的意思是，这就是答案：首先你应该做的是，不再使用计划模式，而是让一个智能体来详细询问你，并利用这两个文档来添加术语表，以便在过程中更好地理解你的需求，同时还会添加架构决策记录，这样你就能捕捉到那些不那么明显的信息。在GrilleFordox阶段收集到的内容，随后会被整理进规范文档，就像我们之前看到的那样，这个规范文档基本上定义了你的目标，也就是你要去的方向。然后你会把这个规范文档拆分成单独的任务单，这样你就可以把开发工作分散到多个智能体会话中进行，这就是two tickets的作用。接下来，你会用implement技能来实现每一个任务单，而implement技能其实非常非常简单。 它看起来就是这样，实现用户在规范文档或任务单中描述的工作内容。 在预先约定的接口处，尽可能使用TDD测试驱动开发，这个做法很不错。 定期进行类型检查，运行单测及完整测试套件，完成后通过代码审查并提交至当前分支。 这很简单，我差点没把它列为一项技能。它主要靠代理自身的先验知识，以及框架引导它。 我原以为这里不需要技能，但大家总问我流程是什么？流程呢？所以我就想干脆做一个实现技能，让它变得简单明了，对吧？ 在流程的每一个阶段都调用这个技能，因此，实现技能在此非常关键。 有了两个工单后，只需分别编码实现即可，该技能会自动调用代码审查。而代码审查，我是在第一个版本的进行中阶段把它剥离出来的，所以它已经存在有一段时间了，但在这个第二版里，我对它做了一些更新。 代码审查技能的理论是，它会从两个维度来审查代码，所以它会为每一个维度都创建一个子代理。第一个维度是标准轴，代码是否符合这个仓库中记录的编码标准。所以如果你的仓库里有一个Coding Standards.md文件，它就会读取那个文件，并根据里面的内容进行检查。 我通常认为编码标准应该放在Agents.md文件之外，它们应该单独存放。而代码审查环节 正是他们最有用的地方。 然后在完成标准检查之后，你会继续检查规范，代码是否忠实地实现了最初的问题、PRD或规范，它们都会作为并行的自代理运行，并且在这里会有一个流程，逐步检查每个部分。 现在，这个技能有趣且新颖的地方在于，我最近又在读Martin Fowler的《重构》，我决定让代理能够识别Martin Fowler所列举的各种代码异味。《重构》这本书问世已久，也被广泛引用，这些所谓的代码异味已经深深植入了代理的先验知识中。 所以，你只需要引入这些概念，比如说，神秘命名、重复的代码、特性嫉妒、数据团块、原始类型偏执、重复的分支、发散式变更、投机性泛化、消息链等等。你明白我的意思了吗？ 这些内容都深深地存在于代理的知识库中，我们所需要做的只是用一句话把它们描述出来。我发现这样做会让代理重复你说的词，比如说，是的，我发现了一些消息链，我需要把它们移除，我发现了中间人问题，我需要解决它。 所以，我测试了几个星期，结果非常有用，效果惊人，它真的非常有助于提升我的代码质量，而且操作起来也很简单，大概只需要输入代码。 但接下来，我们来聊聊我真正感到兴奋的部分，那就是我们启动和制定规范方式的全新变革。 也就是前置规范的部分。 换句话说，它会出现在这里，在某些情况下可能会取代Grill with Docs。这个工具叫做WavFinder，我会专门做一篇帖子、一整段视频来介绍WavFinder。但现在简单来说，我希望当你考虑使用Grill with Docs的时候，可以优先选择WavFinder。 WavFinder的作用是，它专为那些你有大量内容需要规划，但内容太多，以至于单轮代理会话无法处理的情况而设计。换句话说，你可能会超出代理的智能边界，甚至可能超出代理的上下文窗口，你需要把它拆分成多个部分，才能理清方向。 一个模糊的想法出现了，它太大，无法在一次代理会话中解决，还被迷雾包裹，从起点到目的地的路径还不可见。这个技能会在代码库的问题追踪器上，绘制一张共享地图，然后逐个处理这些工单，直到路线变得清晰，这些地图会保存在GitHub的Issue问题中。 比如，这是Sandcastle仓库中的一个例子，我们正在做一个Spike，考虑是否要把AISDK作为依赖项引入进来，这是一个非常重大的变更。所以，你可以看到，目前还没有做出任何决定，所有需要做出的决定都被保存在子问题中。 这些子问题之间存在组合关系， 因此我们可以看到， 在做出最初这个关键决定之前， 其他任何决定都无法进行， 每一个这样的决策， 其范围都被限定在一次代理规划的大小。 我们还可以看到， 这些决策在这里被标记为不同的类型， 比如说， 这个被标记为研究任务， 所以这实际上是一个让代理离开去做一些研究， 然后再回来汇报的离线任务。 我认为这个也是一个研究任务， 这个是研究任务， 而这个是质询任务， 所以这里需要进行一次质询规划。 我认为这些都是质询任务， 我们可以在下面的工单类型中看到这些定义， 所以我们有研究任务， 有质询任务， 也有原型任务。 最近我一直在大力倡导的一件事， 就是在制定规范之前多做一些原型， 其理念是， 通过制作一个便宜、粗糙、具体的产物， 比如大纲、初步方案、框架、UI、逻辑代码等， 让讨论的细致程度提升， 大家可以据此进行反馈， 这就是原型技能的作用， 我们马上会讲到这一点。 这里有一个链接， 把原型作为一个资产， 并且说明， 当它应该长什么样，或者它应该如何表现是关键问题时使用。 这对于几乎所有涉及前端代码的事情来说， 都是至关重要的。 所以我绝对会推荐， 凡是涉及前端的内容， 都要使用Wayfinder。 这里最后一个就是任务。 比如需要配置的内容、开通权限、把数据整理成需要的格式，所有这些不需要深度决策，也无法被AI自动化处理的琐碎事情。最终，当所有这些工单都关闭后，所有信息都会被保存到地图上。而原始工单则作为记录内容的主要来源，然后你可以把这张地图按照常规方式，转化为规范文档。我发现，用Wayfinder之后，不再像用GrowWithDocs那样，需要焦虑地管理我的绘图，担心交接或者智能区域的问题，一切都为我自动管理好了。我只需要关闭一个绘图，然后开启下一个Wayfinder工单，所有内容都保存在Gatehub上，所以可以协作，你可以和你的团队共享它。一旦地图完成了，只需要进入规范文档，你就可以开始了。为了支持Wayfinder技能，我们还推出了一个新的调研技能，非常小巧，特别适合你，只需要进行一次调研绘图的时候，或者它也能以我喜欢的方式引导模型进行正确的调研。它启动后台代理调研，让你能继续工作，它则阅读并调查一手资料，将结果写入Markdown文件，并按规范存入仓库笔记区。如果你需要做任何调研，只需调用调研技能，就可以开始了。接下来当然是原型功能，我之前其实已经稍微展示过一点。 我觉得我还没有专门做过一整期视频来介绍它。 现在这个功能已经可以通过模型调用了，所以Wayfinder可以自己调用它。本质上，它会让你在逻辑和状态之间做出选择，所以它要么是逻辑原型，要么是UI原型，而且它们的反应方式非常不同。 最后一个变化是大家一直以来都在要求的功能，我终于决定实现它了。之前在我的TDD技能中，它会为你推荐一系列需要遵循的步骤，但有时候这样做会有点尴尬。这些步骤大致是：它会和你确认想要编写哪些测试，然后你需要一步步地引导它，但这种方式并不符合大多数人对TDD的理解。大家认为TDD应该是，你可以把TDD技能交给一个AFK代理，它就能自动运行。 所以现在这个TDD技能只是作为参考资料存在，它不会指定任何特定的步骤，除了你应该按照什么顺序编写测试之外，比如要遵循红绿重构的流程。所以它只是说要先红后绿，一次只做一个小步骤，而且还把重构单独分离出来，不再作为循环的一部分。所以现在不再是红绿重构循环，更像只是红绿。我倾向于认为，把重构放在代码评审环节会更高效，因为这样你就不会让实现过程变得过于复杂。 这些就是所有关于技能的变更。这些变更非常多，如果你担心会错过任何更新， 我建议你清空所有技能，然后运行NPX Skills Update，把所有新技能都获取下来。如果你这期间对你的技能做了更新，你可以直接让你的Clanker指向我的仓库，然后把所有新的好东西都拉下来，特别是参考发布说明。我认为这次发布最让人记住的地方，就是2 Spec和2 Tickets的变更，因为这会带来一点点摩擦，但我觉得这是好的摩擦，因为它让命名更加准确。我也希望这能成为你开始迷上Wayfinder的起点，我现在几乎所有事情都在用Wayfinder，甚至包括非编程的内容，实际上我已经在用Wayfinder规划我的下一个课程了，真的非常非常好用。实在非常感谢你们的观看，和大家分享这些技能更新，总是一件很开心的事。看到使用量不断增长，真的很酷。大家都跟我说不应该展示星标数量，但现在已经有大约16万颗星了，Skills SS上的下载量已经达到700万次，这简直太疯狂了。所以非常感谢大家喜欢这些技能，我希望这些技能能帮助你们更高效地发布产品，我们很快再见！