正在打开每日关注
正在打开每日关注
以 SPEC、Tickets、TDD 与 Code Review 构建可审计的 Agent 开发闭环。
还是强烈推荐一下，大家看看mattpocock @mattpocockuk 的skill（昨天又更新了1.2版本）https://t.co/LjJsjWWn58 我自己使用下来最大的心得体会是，它将原型设计（无论是代码逻辑原型还是 UI 原型）与实际开发区分得非常明确。 在开始编写功能或代码时，你需要像它一样——无论是使用最新的 WayFinder 还是之前的 Grilling——都必须先明确所有的分支和内容。明确后再将其转化为具体的实施方案，即 SPEC。有了具体的 SPEC，接下来才能让模型进行拆解： * **最新版本**：将其拆解为 Ticket（票据）。 * **旧版本**：则是转化为 Issues。 无论是哪种方式，核心都是将大问题具象化为每一个可执行的步骤，再交由模型执行。 在此基础上，我结合了 Loop 的概念。它原本的执行逻辑是一个简单的 implement（实现）技能，这个技能套了两环：TDD（测试驱动开发）和 Code Review。 1. **TDD**：用测试的方式写代码。模型先写出错误的代码，再通过反复校验将其改对。同时，它会让 TDD 去读取方案中每个接口之间的衔接逻辑，并根据这些逻辑反向编写测试用例。 2. **Code Review**：这是一个非常出色的设计。它将代码审查分为两块： * **代码规范**：检查代码是否符合项目的规范。 * **功能一致性**：检查实现的逻辑是否与最初 SPEC 文档中的详细要求一致。 只有这两项都满足，Code Review 才算成功。此外，它还包含一个“坏代码文档”，将常见的不良代码情况列入其中进行约束。通过这种方式，即使是能力较弱的基础模型，也能写出相对健壮的代码。 为了防止 Agent 之间发生错误，我在流程的开头和结尾加入了 Start Work 和 End Work 动作，目前我主要通过委派 subagent 的方式来写代码： * **Start Work**：让 Agent 自动在现有测试分支上开设新分支，随后进入 TDD 和 Code Review 流程。 * **End Work**：整套流程走完后，它会自动提交 PR 并给我发送通知。 我要求它把 PR 写得非常详细。如果项目不急，我会亲自审计；如果比较着急，我会让它自动 Merge PR。通过这种预先拆解好的架构，不断向后推演，最终实现彻底的无人自主化功能编写。 总的来说，这套思想非常契合现有的 Agent 架构和经典的软件开发原则。它的每一个小技能都写得非常“小而美”。如果你有自己的代码规范，不一定要全盘照搬，但其设计思路非常值得思考和参考。比如我最开始，就只单独使用了它那个叫 Grilling 的“拷问”技能。
是什么
这条收藏推荐的是 Matt Pocock 的 GitHub 仓库 mattpocock/skills。README 将其定位为面向真实工程的 Agent Skills 集合，强调“小而美”、可适配、可组合，并支持不同模型。仓库元数据显示其使用 Shell，拥有 240608 个 Stars，创建于 2026-02-03，最近提交于 2026-08-24。
核心设计 其结构按触发方式区分 user-invoked 与 model-invoked skills；工程流程则围绕 Grilling 对齐需求、CONTEXT.md 统一领域语言、to-spec 形成规格、to-tickets 拆分任务，再由 implement 配合 TDD 与 Code Review 执行。Review 同时检查项目规范和实现是否符合 SPEC。推文作者又在外层加入 Start Work、End Work 与 subagent 委派，将分支、PR 和通知纳入闭环。
关键洞察 价值不在于某个神奇提示词，而在于把隐性判断外置为文档、任务、测试和审查门禁，让 Agent 在更小的执行单元中持续获得反馈。尤其是将“规范正确”和“功能正确”分开验证，能减少只通过 lint 却偏离需求的实现。
边界与风险 流程严谨不等于结果必然正确：错误或遗漏的 SPEC 可能被稳定地实现，测试也可能固化错误假设。自动合并还需要可靠的 CI、权限控制与回滚机制。Start Work、End Work 和无人化 PR 流程是推文作者的使用扩展，不能据此断言它们全部属于仓库原生能力。UI 原型在这里只是开发阶段划分，并未提供具体设计方案。