当大模型写代码的速度比人类快上百倍时，软件工程面临的挑战不再只是写不出代码，而是可能快速制造出难以维护的「代码大泥球」。面对这种情况，关键是不要让 AI 直接替你做主，而是让模型像架构师一样促使你把设计和方案想清楚。模型需要人把目标与判断标准传达给它，做决定的始终是工程师自己。

TypeScript 教育者 Matt Pocock 曾凭借 Total TypeScript 课程创下超过 250 万美元的销售额。但在大模型能力提升后，单纯讲解语法与实现细节的战术知识吸引力明显下滑。然而，当开发者尝试把真实业务交给自动化 Agent 时，往往容易遇到问题：模型容易曲解意图、臆造权限逻辑、堆砌同义反复的无效测试，甚至在上下文膨胀后破坏既有架构。

Matt 自己的转型历程正是这种变化的缩影。在投身软件行业前，他做了六年声乐老师；为了能在乡下远程工作，他自学编程入行，写的第一个作品是给学生分析嗓音频谱与共振峰的网页工具。他入行的优势在于多年教学练出的沟通能力：能把技术原理讲明白，晋升很快。这也是他后来做教学以及注重「如何向 Agent 表达意图」的基础。后来他全职做开发，并凭借 Total TypeScript 课程被广泛认知。随着大模型能力提升，单纯教授语法细节的课程收入明显下滑。他曾尝试转向制作「如何把 AI 接进应用」的课程，但收益未达预期。直到去年底假期试用前沿模型后，他根据自己的体验判断，模型的能力已经足够接手大部分局部的具体编码，开发者可以把更多精力放在系统设计与全局架构上。

完整节目可以在 YouTube 观看：The Pragmatic Engineer《AI Skills with Matt Pocock》，1 小时 36 分，可开自动字幕。下文各节附有配好中英字幕的精华片段。

为了解决这些失效模式，Matt Pocock 梳理出了一套开源技能库 mattpocock/skills，在 GitHub 上已超过 26 万星。这套方案并没有发明某种全新的「AI 原生理论」，而是将《程序员修炼之道》《软件设计哲学》《领域驱动设计》等经典软件工程著作中的核心原则，转化为能够约束和激发模型的具体工作流。

这套技能库主要解决什么

• 动手前把需求问清楚：grill-me 让 Agent 先追问业务取舍和架构决定，避免它自行填补关键假设。
• 把讨论沉淀成可执行任务：to-spec 将决定整理为规约，to-tickets 再拆成能在单个上下文窗口内完成的垂直工单。
• 管理跨会话的大型项目：wayfinder 用地图、依赖关系和战争迷雾记录已经确定与尚未确定的工作，让新会话能够接着推进。
• 用真实反馈约束实现：实现技能要求先建立会失败的测试，再写代码并检查回归，减少同义反复的无效测试。
• 持续改善代码库结构：架构检查技能寻找浅模块、重复概念和不断增加的理解成本，把可执行的重构建议转成日常工单。

战术交给 Agent，战略留给人：为什么「智慧」反而没有变得更好学？

在 Matt 看来，AI 正在重塑软件工程中不同技能的相对价值。在日常教学中，编程可以拆分为两层：一层是语法细节与具体实现的「知识」（the what），另一层是探究设计原因与权衡的「智慧」（the why）。如今查阅具体语法的门槛大幅降低，但系统层面的工程思考并没有变得更容易——缺乏架构判断依然会遇到设计瓶颈。Matt 借用斯坦福大学教授 John Ousterhout 在《软件设计哲学》中的分野指出：专注于局部实现的「战术编程」（Tactical Programming）越来越适合交由模型辅助，而开发者需要把重心放在关注全局与系统演进的「战略编程」（Strategic Programming）上。

战略编程往往更难掌握，原因在于它的反馈周期很长。如果在一家公司只工作几个月就离开，早期的架构缺陷可能很久之后才会暴露。Matt 把战略编程比作调音台上的推子——例如一个推子代表「可部署单元数量」，推高是拆成微服务，推低是合并为单体。做架构决策类似调音，往往要等很长时间系统遇到瓶颈，才能验证当初的选择是否合理。在 Matt 看来，AI 提升了编码和验证的速度，客观上也加快了暴露设计缺陷的节奏，让战略层面的反馈周期缩短。

在 Matt 的工作流中，代码本身是 Agent 工作的环境，工程师的核心工作是维护和优化这个环境。下文的三道防线，是他针对战略编程总结出的具体做法——第一步就是在需求阶段通过提问把模糊决策理清。

从 Ralph 循环到有限状态机：技能到底是什么，又是如何诞生的？

确立分工后，Matt 把「让 AI 促使开发者做决定」整理成了一套可安装的技能。这套方法的雏形来自 Geoffrey Huntley 提出的「Ralph 循环」。传统做法常让模型先制定宏观计划再逐步落地，但 Agent 在编码遇到新情况时计划容易变形。Ralph 循环的做法是：给 Agent 设定明确目标，每次只执行离目标最近的一小步，随后清空上下文重置；系统状态保存在代码和本地文件（如 Markdown 清单）中，不依赖模型单次会话中的记忆。此前做应用集成的经验，让 Matt 更加关注上下文的数据结构、优先级以及清空时机。在他看来，这些执行循环本质上是由状态与事件驱动的流程，与他在 XState 中使用的有限状态机（Finite State Machine）原理相通。

在把自制状态循环应用到视频剪辑器等项目后，Matt 发现切回默认环境时效果会有落差。为了复用这些流程，他借用了工具生态中的载体——技能（Skills）。技能的形式很直观：本质上是一个包含若干 Markdown 文件的本地目录，安装后可通过斜杠命令在终端或对话中调用。这类技能在机制上分为两类：一类由模型根据上下文自主触发（Model-invoked），另一类由用户手动触发（User-invoked），grill-me 便属于后者。

看到社区中出现 Superpowers、Claude Code 插件以及 Garry Tan 的 GStack 等技能集后，Matt 将自己的工作流整理开源，该仓库随后成为他获星最多的开源项目，他也受邀在 AI Engineer 大会上以此为题发表演讲。在编写技能时，Matt 的原则是保持简明，便于人工阅读和检查。面对差异较大的实际业务，现成工作流很难直接适用所有场景；逻辑清晰直接，开发者才更容易按需修改和引入项目。

第一道防线：把 AI 当严厉的架构师，用设计树一轮轮拷问你

使用代码 Agent 时，常见的问题是预设模型能理解开发者的意图和权衡。如果只输入「帮我实现某个功能」，模型为了尽快输出结果，往往会自行推测未说明的细节，可能做出不合适的鉴权方式或数据结构选择。

应对方法是不让 Agent 立即写代码，而是让它向开发者反向提问确认需求（Grilling）。主持人 Gergely 尝试过：做一个简单的「邮件订阅校验接口」，被连续追问了 35 个工程细节：鉴权 Token 放在 Header 还是请求体？每天 1000 次的频率限制，是否严格卡在第 1000 次？

grill-me 的设计灵感来自 Claude Code 团队成员 Thariq 的建议：「让 Agent 在动手前先全面采访你」。固化为技能后，模型不仅能排查逻辑漏洞，有时还能提出不同的设计视角。Matt 提到，这种连续提问让他联想到早年工作中有经验的架构师追问方案的场景。虽然最终决策由开发者做出，但提问过程能暴露出未曾深思的技术盲区，促使人查阅资料并理顺逻辑。主持人 Gergely 认为，人机协作的关键在于保持开发者的主动思考；如果连对系统的理解也完全外包给模型，后续就容易积累维护隐患。

这套机制在底层将所有待确定的决策抽象为一棵设计树（Design Tree）。每一个父级决定的落定，都会解锁一批悬挂在下方的子问题。前置条件都已落定、眼下就能问的那批问题，叫作「前沿」。

在每一轮交互中，Agent 会将查证客观事实与提出决策问题区分开。如果一个问题依赖代码库中现有的文件结构、数据库字段或工具配置，Agent 会派子 Agent 自行查找，而不是把可通过工具获知的事实抛给开发者。只有涉及业务取舍或架构权衡的问题，才会列入本轮问题清单。

提问也有明确规范：把所有前置条件已满足的问题合并在同一轮提出，每个问题附带推荐答案，随后等待开发者回复。每次回答后重新计算设计树前沿，直到没有未明确的假设，提问流程才算结束。在前期把需求与判断标准对齐，有助于降低后续返工的成本。

第二道防线：把任务压进 15 万 token 的聪明区，实行「白班规划、夜班施工」

模型支持的上下文窗口越来越大，但在工程实践中，上下文长度并不等于有效的推理能力。工程师 Dex Horthy 提过一个说法：上下文里存在「聪明区（smart zone）」和「笨区（dumb zone）」。

上下文里每个 token 都在争抢注意力，塞得越多，重要的信息越难被「听见」。Matt 的估计是，目前的前沿模型大约前 15 万 token 属于聪明区，跟窗口总共多大无关；超过之后质量会一点点往下掉。此时模型更容易忽略关键约束，开始丢失代码间的逻辑一致性。

要让 Agent 稳定工作，就必须把庞大的工程拆解成可以在 15 万 token 的聪明区内独立结项的微型会话。这套工作流通过两道工序完成转化：

规约沉淀（to-spec）：将上一阶段拷问完成的对话上下文综合成一份需求规约。这份文档只记录用户视角的问题陈述、端到端的用户故事清单、对外暴露的测试接缝（Seams）以及明确排除在外的边界（Out of Scope）。规约中避免写入具体的文件路径或实现代码，以防这些实现细节在后续开发中过时。

切片建单（to-tickets）：将规约进一步分解为一组相互声明阻塞关系的工单。每个工单都是一个垂直切片（Vertical Slice），同时贯穿数据模型、接口逻辑、用户交互与自动化测试，避开「先把所有数据表建完、再堆所有接口」的水平切分。每个切片的工作量限制在单一上下文窗口内，以便在全新会话中独立完成并验证。

当面对涉及全库共享符号的大范围重构时，切片规则会采用扩展-收缩（Expand-Contract）模式：第一张工单先在旧结构旁增加新形式，保持双轨并存；随后按模块分批迁移调用方，确保每个批次提交时持续集成都能通过；最后一张工单再移除旧形式。

这种流程形成了一种协作节奏：开发者在白天集中进行架构设计、需求对齐与工单拆分；随后把工单交由自动化执行循环在独立上下文中逐一完成。工程师减少了在多个终端窗口间频繁切换的负担，将精力更多放在前期的结构输入上。

第三道防线：用战争迷雾与活地图治理超大工程（Wayfinder 机制）

当面对类似「克隆一个完整支付平台」这种规模庞大的系统时，单次会话很难容纳完整的架构规划。如果一开始就试图把整个系统的所有细节规划清楚，很容易超出模型的有效上下文范围。

Wayfinder 技能通过引入即时战略游戏中的战争迷雾（Fog of War）隐喻，在工单追踪系统（如 GitHub Issues 或 Linear）中构建起一张动态演进的「活地图」。

## Destination（终点目标）
清晰定义该地图走向何方（一份可交接落地的规约、一项数据架构迁移决策）。

## Decisions so far（已落定决策索引）
- [工单标题](链接)：一句话提炼该决策的核心结论，正文保留在子工单内，主地图不作冗余展开。

## Not yet specified（尚未具象的战争迷雾）
记录前方已经察觉到、但前置依赖尚未解决的模糊方向；随着前沿推进，它们会逐步具象化并毕业成独立工单。

## Out of scope（明确排除的范围）
任何超出当前终点目标的设计诉求，直接关闭对应工单并归档于此，不进入主路线图演进。

在地图之下，所有具体探索被拆分为四种类型化的子工单，每次会话只处理一个工单：

调研工单（Research）：纯后台自主执行（AFK）。由派生的子 Agent 查阅外部文档、第三方接口定义或本地知识库，得出的关键事实以 Markdown 文件形式沉淀在分支中。

原型工单（Prototype）：必须有人类参与（HITL）。针对「界面该长成什么样」或「复杂状态流如何运转」等无法仅靠抽象文字说清的问题，快速做出可交互的原型，或者几种不同方向的方案，供人类直观感受并敲定方向。

拷问工单（Grilling）：必须有人类参与。针对具体的设计分歧，通过设计树逻辑与人类展开一轮深入对齐。

前置任务工单（Task）：为了扫清后续决策障碍而必须先进行的实际操作（例如申请某个受限平台的接口权限、导入一批测试数据）。

这套机制的做法是：当前能够明确提问的环节，立即建单并标注依赖关系；看不清全貌的部分先保留在迷雾区域，不强行提前拆解。当一个工单完成后，结论以一句话索引形式追加到主地图中，原本模糊的设想再逐步细化为新的工单。

什么时候该先拷问，什么时候直接做？三档对齐策略与激进原型的解法

面对具体的业务需求，Matt 主要依据试错成本来决定对齐时机：如果任务逻辑复杂，一旦实现方向出现偏差，后续修正成本较高，就要在动手前进行对齐，将鉴权方式或接口数据结构等关键细节事先确定；如果是几行代码的小改动，则可以先让 Agent 编写，再通过审查工具或直接查看结果完成事后校验，这种方式处理简单任务更为直接。

基于这种成本权衡，他在工程实践中沉淀出了清晰的「三档对齐法则」：

• 第一档（微型任务）：事后易于验证与调整的改动，不启用 grill-me，直接快速实现；
• 第二档（单会话任务）：工作量在单一会话内可完成、但逻辑关键的任务，调用 grill-me 展开设计树对齐；
• 第三档（多会话巨型任务）：跨越多个会话、牵涉系统全局的复杂工程，启动 Wayfinder 建立动态推进的活地图。

针对「这是否倒退回瀑布模型」的疑问，Matt 的做法是在正式制定规约前进行快速原型开发（Prototyping）。由于代码生成成本大幅降低，开发者可以让 Agent 快速产出几个不同版本的原型，直观对比交互和结构，选定合适方案后再细化规约。主持人也引用 Grady Booch 的观点指出，传统瀑布模型的问题在于规划与交付周期过于漫长，容易脱节；若在短周期内结合低成本原型辅助规划，能及时检验方案，与耗时数年的瀑布流程存在本质区别。

波动的新材料与文本接缝：Agent 擅长什么，又不擅长什么？

为什么几十年前的经典工程方法能够用于约束当下的 Agent？这与 Agent 擅长的处理机制有关。主持人 Gergely 援引形式化方法专家 Hillel Wayne 的观点指出，软件工程过去与传统工程学科的区别在于材料属性：传统物理材料存在公差与波动，而确定性代码在相同环境下运行结果一致；大语言模型则给软件开发引入了非确定性。Matt 认为，代码 Agent 之所以在编程中表现突出，核心在于软件开发的输入与输出主要是文本——代码、文档、提示词是文本，测试结果、类型检查与静态分析报告同样是文本，模型可以在这种文本反馈回路中快速处理和流转。

相对而言，Agent 较难直接评估无法充分文本化的感官与交互体验。例如界面的动态微调、动效曲线和实际手感，模型难以单凭代码推断真实的体验效果。因此在工程实践中，一种有效的做法是尽量把任务和规则转化为 Agent 易于处理的文本形式：包括格式化数据、清晰的断言与配置文件。Matt 也在尝试将自己常用的工具链路开放给 Agent，让模型通过标准文本协议来调用和协同。

激活先验：用经典工程概念充当模型的「引导词」

在形成这套工作流之前，Matt 曾尝试过规约驱动开发（Spec-driven Development），试图只维护一份需求规约文档，通过修改需求让 Agent 同步修改代码。但在实践中，多轮生成后代码质量逐渐下降。他意识到问题的关键在于反馈回路：如果缺乏严密的测试和明确的环境反馈，Agent 接收到的信号失真，生成的结果就容易偏离预期。

这促使他重新翻阅《程序员修炼之道》（The Pragmatic Programmer）。书中关于「软件熵」（Software Entropy）的论述提到系统容易随修改滑向混乱，而在缺乏约束时，Agent 也会加速软件熵的累积。书中提到的原则——如「别跑得比车灯还快」（Don't outrun your headlights）、「在反馈循环内工作」（Always work within your feedback loops）、警惕「巧合式编程」（Programming by coincidence）以及倡导「曳光弹」（Tracer bullets）——恰好对应了当前与 Agent 协作时所需的控制手段。

大语言模型在预训练数据中吸收了大量软件工程相关的经典文献。如果直接用口语下指令，模型容易输出笼统宽泛的回答；而如果在提示词中使用定义明确的经典工程术语，就能起到引导词（Leitwort）的作用：通过特定术语触发模型已掌握的工程实践模式。

Matt 判断引导词起作用的信号，是 Agent 在推理过程里把这些词原样用回来，比如说「好，我把这个做成一颗曳光弹」，后面的做法也随之改变。

在领域驱动设计的实践中，这套方法建议建立一份专门的 CONTEXT.md 术语表，仅记录核心业务概念的定义，不掺杂具体实现细节、文件路径或临时草稿。当模型和开发者使用统一的术语时，可以减少上下文沟通成本，代码命名与接口设计也更容易保持一致。

守住工程质量：《记忆碎片》驱动开发、红绿测试与技术债

当代码生成速度加快后，若缺乏有效约束，代码质量容易快速滑坡，形成难以维护的代码库。在实践中，Matt 强调了两项保障代码健康的机制：

Matt 将 Agent 的工作特点比作电影《记忆碎片》：每次新会话都从零开始面对项目。人类开发者在熟悉的代码库中，往往依靠以往经验绕开隐藏的问题；而 Agent 没有跨会话的记忆，每次启动只能依赖当前的上下文与代码环境。因此，代码库本身的清晰度与一致性直接决定了 Agent 的推理质量。这与经典软件工程对整洁代码的要求一致。

针对 Agent 特点的测试驱动开发（TDD）：Agent 虽然能处理较长的上下文，但无法脱离运行环境感知真实状态，有时会写出同义反复的无效测试（例如断言常量等于自身，或用与业务代码相同的逻辑计算预期值）。

为了防止模型作弊，必须要求 Agent 严格执行「红-绿-重构」循环，且测试必须建立在预先商定的公共接缝（Seams）上。在写入任何业务代码之前，Agent 必须先提供一份能够真实复现失败的测试用例，用失败证据证明改动的必要性；只有在绿灯通过后，才允许进行后续工作。

Matt 认为，TDD 最初是为人类有限的工作记忆设计的，让人被打断后能通过失败测试找回上下文；而 Agent 真正需要的是明确、客观的环境反馈。因此他在实践中依然使用 TDD，并要求 Agent 证明「在未做修改前该测试确实会失败」，以确保测试的有效性。这也关系到技术债：正如 YC 的 Jared Friedman 指出的，过去技术债多在大型项目中积累，Matt 则提到在 Agent 辅助下，小型项目若不加约束也会较快堆积质量问题。他的应对方式是明确分工：一个 Agent 负责编写实现，另一个自动审查 Agent 检查编码规范并排查无效测试，最终由开发者完成确认。

代码库架构的日常巡检与深化：对抗代码熵增不能依赖偶发的推倒重来。improve-codebase-architecture 技能专门找「浅模块」：接口复杂、实现单薄。它对可疑模块做「删除测试」：如果把它删掉，复杂度是被集中到一处，还是只是换了个地方？答案是「集中」，就说明这个模块值得动。

体检结果会自动渲染为一份独立的 HTML 可视化报告，利用 Mermaid 架构图清晰展示重构前后的模块深度对比，并标注出潜在改进点的推荐指数。开发者只需在晨间挑选值得深化的候选点，就能一键触发拷问循环，把架构优化平滑融入日常迭代。

人和团队怎么变：做 Agent 的园丁，给它装监控、搬上云端

在频繁使用 Agent 编写代码的团队中，工程师的工作重心有所转移：重点不再是逐行编写语法细节，而是转型为维护工程环境的「代码园丁」与平台建设者。通过设定质量规范、治理不良实践、完善自动化测试反馈，保障系统在持续变更中保持稳定。

当需要说服管理者在工程规范上投入资源时，Matt 认为有效的方式是为 Agent 建立可观测性（Observability）：记录 Agent 执行的任务、成功率与失败率。由于调用模型产生实际成本，量化其产出比有助于评估工具价值。通过对比不同代码库中 Agent 的成功率，团队可以把表现较好仓库的工程规范与提示词复用到其他项目。Matt 自己每天会运行一次 improve-codebase-architecture 技能，挑选可行的重构建议转为工单；他建议开发者留出一部分时间（如 20%）维护工程环境与工作流本身。

在运行环境上，Matt 选择将开发工作流部署在远程云端。在他看来，云端环境便于团队协作与多终端接入，遇到分歧时可以共享会话，也可以与 Linear 等任务系统对接。在实际使用中，他可以通过移动端与远程 Agent 交互推进任务，或编排定时运行的后台任务。主持人 Gergely 补充道，像 Ramp、Stripe、Uber 等公司中，已有不少工程师将开发环境迁移至云端；主要例外是前端开发，仍依赖本地直观查看渲染与交互效果。

给新人和想跟上的人：战略判断力溢价、内省特质与「信息编排」

随着代码生成成本下降，编写具体实现的战术工作价值被压缩。面对「初级开发者如何成长」的问题，Matt 坦言目前行业还没有标准答案。过去初级工程师通常通过大量具体编码积累经验，逐步建立对系统设计的直觉；如果基础编码全部交给模型，传统的成长路径便会发生变化。在他看来，全局视野与架构层面的判断力，正在变得相对更有价值。

对希望提升能力的开发者，Matt 的建议是在实际开发中多尝试使用 Agent。例如调用 grill-me 辅助方案推演；如果他在自学编程写音频工具时有这类工具，模型就能帮他指出深层嵌套循环等性能问题。他认为重点不仅是看最终生成的代码，更要审视开发流程本身。Matt 认为重要的一项特质是内省（Introspection）：能够审视自己的工作方式，并将工程流程转化为清晰的规则与结构。被问及推荐书目时，他提到了三本书：《程序员修炼之道》、John Ousterhout《软件设计哲学》，以及 Eric Evans《领域驱动设计》的前三章（重点在通用语言与领域建模）。

关于 AI 时代的编程教学，Matt 认为教学的核心价值在于挑选与编排（Curation）。单纯获取知识点并不困难，但面对复杂的知识网络，初学者容易理不清学习次序。导师的作用在于根据认知节奏，规划出负荷更低的学习路径，而这种针对学习路径的编排，正是目前单纯向模型提问较难替代的。

他的技能：怎么装、怎么挑、最值得先用的几个

Matt Pocock 开源的技能库 mattpocock/skills 遵循 MIT 开源协议，支持两种安装方式。两种方式二选一，切勿同时安装，否则会在环境中引入重复技能定义；其原生 Codex 插件仍在作者规划中，目前尚未发布：

方式一：Claude Code 官方插件。整套技能只读，随作者更新自动升级，适合开箱即用、不想自己维护的人。插件已上架 Claude Code 官方插件市场，不用先添加市场，在终端运行：

claude plugins install mattpocock-skills

也可以在 Claude Code 对话里直接输入 /plugin install mattpocock-skills。

方式二：通过 skills.sh 装进当前项目。技能文件会复制到项目里，能随意改，适用于任何支持技能的编码 Agent，适合要按自己项目调整规则的团队。在项目根目录运行：

npx skills@latest add mattpocock/skills

安装时会让你挑技能，务必勾上 setup-matt-pocock-skills；以后拉取作者的更新用 npx skills update。

这套技能在 Claude Code、Cursor、Codex、Copilot 等编码 Agent 里都能用；作者网站 aihero.dev/skills 按「什么时候用」给主力技能分了组，并有配套的七节邮件课。

官网列出 25 个主力技能，分成入门、主流程、打磨方案、日常维护、效率和参考六组，其中参考类多由其他技能在后台调用；GitHub 仓库连同杂项和还在做的一共 38 个。

最值得先用的几个

/grill-me：整个技能库里最出名的一个，机制在第一道防线讲过。它不需要代码仓库，不在本地写文件，聊的甚至不必是代码。脑子里冒出一个值得认真对待的想法，就开个新会话敲命令，让 Agent 连番追问，逼你在动手前把模糊设想磨成清晰的决定。

主流程按顺序用，规格和工单在第二道防线讲过：

1. /grill-with-docs：对齐方案，同时把领域术语和架构决策写进仓库的 CONTEXT.md 和 ADR。
2. /to-spec：在同一会话里接着用，不再提问，把谈妥的共识写成需求规约，写明测试接缝和排除范围，发布成工单。
3. /to-tickets：把规约拆成带阻塞依赖的曳光弹纵向切片工单，每张刚好装进一个全新的上下文窗口。
4. /implement：每张工单开一个独立会话，测试先行地写代码、做类型检查、提交。
5. /code-review：对照仓库的编码规范和原始规约，做双重审查。

/wayfinder：一个会话装不下的大工程用它，机制在第三道防线讲过。它只做规划、不写业务代码，把未知拆成调研、原型、拷问、前置任务四种决策工单，一次会话推进一张。适合全新项目或路线模糊的大重构，地图清空后再交给 /to-spec。

/prototype：解决「光靠说说不清」的设计问题。遇到状态流转或界面分歧，它会做出免编译、双击就能打开的 HTML 演示，或在真实路由里给出几种差异明显的界面方案。结论写进代码或 ADR，原型本身留在独立分支，不合进主分支。

/improve-codebase-architecture：代码库的架构巡检。它用「删除测试」找出接口复杂、实现单薄的浅模块，生成带推荐徽章的 HTML 报告，自己不改代码；你挑中某一处，它再发起拷问。适合每隔几天跑一次，或者在大改动前问一句「怎样让这次改动更容易」。

/diagnosing-bugs：对付顽固 bug 和性能回退。先找到一条能稳定复现失败的命令，再缩小复现范围、提出可证伪的假设、加带标记的调试日志，最后写一个防回退测试修掉问题，并清理现场。

/teach：把一个目录变成长期的教学工作区。它先把权威一手资料整理进 RESOURCES.md，再生成一节节带小测验的 HTML 课程，用学习记录决定下一课教什么。学一门新语言、熟悉新接手的代码库，都可以单独建一个仓库让它教。

grilling 技能提示词原文与意译

grill-me 真正驱动模型执行严苛面试的核心提示词，完整封装在底层 grilling 技能的指令文件中。下面是这个文件的英文原文（出处：mattpocock/skills 仓库，MIT 协议），可以直接复制：

---
name: grilling
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
---

Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.

Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.

Format a round like so:

```
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

---

❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>
```

Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.

Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.

The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

提示词核心规则逐句意译与解析：

• 目标与建模：对用户发起不留情面的连续采访，直到双方达成完全一致的认知。将整个架构对齐过程映射为一棵设计树（Design Tree），每一个已落定的抉择都会分叉出挂在其下方的后续子决策。
• 分轮次推进与前沿计算：按「轮次（Rounds）」推进设计树。「前沿（Frontier）」指所有前置先决条件都已敲定的决策——即那些你当下无须凭空瞎猜就能直接抛给人类的问题。每一轮必须把整个前沿上的问题一次性全部提出：为每个问题编号并给出你的推荐选项，随后停下来静默等待用户作答，再开启下一轮。
• 标准提问排版：严格按照格式抛出问题，包含问题编号与标题（❓ Q1 - <标题>）、详细背景描述及备选方案，并显式给出推荐答案（➡️ <推荐答案>），各问题间用分割线隔开。
• 动态重塑树形边缘：用户每一轮的回答都会重塑设计树：已确定的选择会将前沿向外推进一步，解锁原本因依赖未定而阻塞的下层问题。重新计算前沿并进入下一轮；如果某个问题的答案取决于本轮尚未敲定的其他问题，严禁抢跑，必须延后到未来的轮次再问。
• 严控职责边界（查事实 vs 做决断）：查证客观事实是 Agent 自己的本职工作，不应由用户承担。当某个前沿问题需要运行环境（文件系统、本地工具等）中的事实支撑时，自行派生子 Agent 去查找，不向用户索取可通过工具查到的信息。调研过程不得阻塞整体节奏：正在进行的探索只作为未决的前置条件阻塞其下游分支，前沿上的其他无关问题正常抛给用户。主观价值抉择则交由用户决定：把选项摆在用户面前，等待决断。
• 终结退出条件：整场会话只有当前沿完全清空时才算结束——即设计树的各个分支都已覆盖，没有任何隐性假设被默认。在用户确认双方达成共识之前，不要据此动手。

相关仓库与资源清单

• aihero.dev/skills：作者官网的技能页，按阶段分组，每个技能有单独的介绍页。
• Superpowers：Jesse Vincent（GitHub 用户 obra）的 Agent 技能框架和软件开发方法论。GitHub 星数约 28.9 万，比 mattpocock/skills 还多，Matt 说自己是「第二多星的技能仓库」，排在它后面。
• GStack：Garry Tan 公开的自己那套 Claude Code 配置，23 个各有分工的工具，分别扮演 CEO、设计师、工程经理、发布经理、文档工程师和 QA。
• Ralph 循环（how-to-ralph-wiggum）：Geoffrey Huntley 提出的 Ralph Wiggum 技巧，倡导单目标离散短循环、快速清空上下文重置状态并将事实留在本地文件中。
• Matt Pocock 的 AI Engineer 演讲：Matt Pocock 在 AI Engineer 大会上的演讲《Software Fundamentals Matter More Than Ever》，就是节目里提到的那一场。
• 经典工程推荐书目：《程序员修炼之道》（The Pragmatic Programmer）、John Ousterhout《软件设计哲学》（A Philosophy of Software Design），以及 Eric Evans《领域驱动设计》（Domain-Driven Design，重点精读前三章关于通用语言与领域建模的论述）。