一、这个插件到底是干什么的？
to-spec是Matt Pocock开源的AI技能包（Skills）中的核心工具之一，累计安装量超过1680万次。它的任务很简单：把你和AI已经讨论完的内容，直接变成一份结构化的产品规格文档（PRD），然后发布到项目的Issue跟踪器上。
关键词是“已经讨论完”。to-spec不做访谈、不追问、不让你再填一遍表格。它只综合对话和代码库里已有的内容。你在对话里说清楚了什么，它就写什么——不会多问一句。
这听起来简单，但解决了AI辅助开发中一个非常实际的痛点：你和AI花了一个小时聊清楚需求，聊完之后呢？ 那些讨论散落在对话记录里，没人整理成文档。下次打开项目，你自己都忘了当时怎么定的。to-spec就是把“聊清楚”到“写下来”之间那一步自动化掉。
此外，还有一个功能更全面的tospec CLI工具（@seanmars/tospec），它提供了一套完整的规格驱动开发工作流——从需求探析、规格编写、设计、任务拆解到实现和归档，配套10个Workflow Skill。这篇文章主要聚焦Matt Pocock的to-spec技能，因为它更轻量、更通用，也是目前安装量最大的版本。
二、核心功能拆解
对话综合与PRD生成
to-spec最核心的能力：读取当前对话的完整上下文，结合对代码库的探索理解，直接生成一份PRD。不需要额外提问，不需要用户再解释一遍。
代码库自动探索
生成规格之前，to-spec会先探索代码库——理解项目的领域词汇（domain glossary）、架构决策记录（ADRs）、当前代码状态。生成的规格文档会使用项目已有的术语体系，而不是凭空造词。这意味着文档和代码库说的是同一种语言。
测试接缝识别
to-spec会在动笔之前先勾画测试接缝（testing seams）——也就是在哪些边界上测试这个功能。优先使用已有的接缝，尽量用最高层的接缝，理想情况下整个功能只有一个测试接缝。这个设计思路来自测试金字塔理论：接缝越少、越靠近用户行为层，测试越稳定、重构成本越低。
结构化模板填充
Problem Statement（问题陈述） ：用户面临的问题是什么
Solution（解决方案） ：怎么解决这个问题
User Stories（用户故事） ：一长串编号的用户故事，格式为“作为<角色>，我想要<功能>，以便<收益>”
Implementation Decisions（实施决策） ：模块划分、接口设计、架构决策、Schema变更、API合约等
Testing Decisions（测试决策） ：测试策略、测试范围、测试先例
Out of Scope（范围外） ：明确不做什么
Issue跟踪器一键发布
规格文档生成后，自动发布到项目的Issue跟踪器（如GitHub Issues），并打上ready-for-agent标签。AI代理看到这个标签就知道“这是一份已经定稿的规格，可以开始实现了”。
三、怎么安装？
to-spec的安装非常轻量，一条命令搞定。
方式一：npx安装（推荐）
在项目目录下执行：
npx skills add mattpocock/skills --skill to-spec --agent claude-code这条命令会把to-spec安装到当前项目的.claude/skills/目录下。
方式二：全局安装
如果想在所有项目中都能用：
npx skills add mattpocock/skills --skill to-spec -g -y方式三：通过Claude Code插件市场
在Claude Code中执行：
/plugin marketplace add mattpocock/skills /plugin install to-spec
方式四：手动安装
从GitHub克隆仓库：
git clone https://github.com/mattpocock/skills.git然后把skills/engineering/to-spec/SKILL.md复制到你的.claude/skills/目录下。
首次使用前的准备
安装完成后，第一次使用之前需要先运行：
/setup-matt-pocock-skills这个命令会配置Issue跟踪器的信息（比如GitHub仓库地址）和分诊标签词表。不跑这一步，to-spec不知道把文档发到哪里。
前置条件
Node.js环境（用于npx命令）
一个项目Issue跟踪器（GitHub Issues、Jira等）
四、谁适合用这个插件？
产品经理与需求分析师
to-spec是产品经理的“会议记录员”。和团队讨论完需求、和客户对齐完想法，直接让to-spec把讨论内容变成一份规范的PRD。不用会后熬夜整理文档。
独立开发者与创业者
一个人做产品，最容易出现的情况是“脑子里想得很清楚，写下来就变了”。to-spec帮你在AI对话中边聊边生成规格，想法和文档同步落地。
AI辅助开发团队
如果团队在用Claude Code、Cursor等工具做开发，to-spec是规格驱动开发工作流的关键一环。完整的推荐流程是：/grill-with-docs（先拷问需求）→ /to-spec（写成规格）→ /to-tickets（拆成任务）→ /implement（先写测试再写代码）。
技术写作者与文档工程师
需要维护项目规格文档但不想手动同步代码变更？to-spec可以基于当前代码库状态生成规格，减少文档和代码之间的偏差。
开源项目维护者
接收外部贡献时，最头疼的是贡献者不理解项目架构和设计决策。用to-spec生成一份规格文档，贡献者一目了然。
五、真实使用案例
案例一：新功能从讨论到规格
场景：一个SaaS产品的团队在Claude Code里讨论了一个“用户自定义仪表盘”的新功能，聊了大约40分钟，确定了用户需求、技术方案和数据模型。
操作：讨论结束后，产品经理在同一个对话窗口中输入
/to-spec。结果：to-spec探索了代码库，理解了现有的仪表盘相关代码和领域术语，把40分钟的讨论综合成了一份完整的PRD，包含问题陈述、8个用户故事、4个实施决策和测试策略，自动发布到了GitHub Issues并打上了
ready-for-agent标签。整个过程不到2分钟。
案例二：遗留项目的文档补全
场景：一个开发团队接手了一个没有文档的遗留项目，需要快速理解系统功能并补充规格文档。
操作：在Claude Code中打开项目，输入
/to-spec——不经过任何讨论，直接让to-spec基于代码库探索生成规格。结果：to-spec扫描了代码库结构、模块划分和接口设计，生成了一份当前系统功能的规格文档。虽然不如从需求出发写的文档完整，但作为理解项目的起点足够了。团队在此基础上补充完善，节省了数周的手工文档工作。
案例三：规格驱动开发的标准流程
场景：一个AI辅助开发团队采用Matt Pocock推荐的四步工作流进行新功能开发。
操作：
/grill-with-docs——AI对需求进行四象限压力测试，拷问“这个功能解决什么问题”“为什么不是别的方案”“边界条件是什么”
/to-spec——把拷问达成共识的内容写成规格
/to-tickets——把规格拆成可独立验证的小任务
/implement——按TDD方式先写测试再写代码结果：每一步都在同一个对话窗口中完成，决策链路完整可追溯。团队发现“发现走错”这件事被提前到了第一步——在写任何代码之前，需求就已经被拷问过一轮了。
案例四：跨团队的需求对齐
场景：一个平台团队需要向三个业务团队同步一次架构变更的规格。
操作：平台团队在Claude Code中完成架构设计讨论后，运行
/to-spec生成规格文档并发布到Issue跟踪器。结果：三个业务团队的负责人直接查看Issue中的规格文档，所有决策和理由一目了然。不需要再约会议同步、不需要再发邮件确认。规格文档成了唯一的真相来源。
案例五：从PR到规格的反向生成
场景：一个团队收到了一个外部贡献的PR，但PR没有附带任何设计文档，评审人难以理解改动意图。
操作：评审人在Claude Code中加载PR的diff，输入
/to-spec。结果：to-spec基于diff内容和代码库上下文，生成了这份PR所对应的规格文档——解释了改动了什么、为什么这样改、影响了哪些模块。评审效率大幅提升。
六、写在最后
to-spec这个插件最打动我的，是它的克制。
很多AI工具喜欢“多做一步”——你给它一个需求，它帮你把需求、设计、代码、测试全做了。看起来很厉害，但出来的东西往往不是你要的。to-spec恰恰相反，它只做一件事：把已经确定的东西写下来。
不做访谈、不追问、不替你决策。它默认你和AI的对话已经达成了共识，它只负责把共识变成文档。这种克制让它成为规格驱动开发工作流中不可或缺的一环，而不是一个试图取代你的“全能AI”。
Matt Pocock把这套技能包定位为“反Vibe Coding” ——不是让AI随便写写代码碰运气，而是让每一步都有规格可依、有测试可验、有文档可查。
当然，to-spec也有局限。它依赖对话质量——如果讨论本身就不清晰，生成的规格也不会自动变清晰。它也不适合从零开始的探索性项目，因为“已经讨论清楚”这个前提不成立。
但对于那些需要把想法变成文档、把讨论变成规格的场景来说，to-spec是目前最轻量、最直接的解决方案。一行命令安装、一个斜杠触发、两分钟出文档——这才是AI辅助开发该有的效率。
◯ 评论 0