AI 工程技能工作流

定义

AI 工程技能工作流 在本文语境中，不是单个 prompt，也不是挂在墙上的抽象流程图，而是一组能在 Agent 中被调用、分工和串联执行的工作流技能。

它的重点不在“让模型更聪明”，而在把软件开发里原本容易被含糊带过的步骤，拆成可重复执行的工程动作：先澄清，再验证，再成文，再拆单，再实现，再测试，再审查。

这类工作流的目标，是把“我有个模糊想法”稳定推进到“代码已经达到可合并状态”，尽量降低几类与 Agent 协作时最常见的问题：

• Agent 自作主张，做出的东西和真实需求不一致。
• Agent 对项目内部术语、上下文和约定理解不稳，每次都重新猜。
• 没有测试反馈，代码写完却跑不起来。
• 代码虽然生成得快，但项目结构迅速腐化，几周后就变成没人敢动的烂摊子。

因此，AI 工程技能工作流 更接近一套“可执行的工程纪律”，而不是一段一次性咒语。

在本文档中的语境

本文语境主要来自 Matt Pocock 开源的 skills 体系。原文明确强调，这套内容“根本不是一堆孤立的 Prompt”，而是“一整套工程方法论”。

其中最核心的主线被概括为 idea → ship，即从一个尚未成形的想法，经过连续的技能节点，最终得到可以进入主干、可接受审查的代码产物。

这一语境下的“技能”有两个重要特征：

• 它们有明确职责边界，而不是一个万能命令包打天下。
• 它们可以按分层规则互相调用，所以用户不需要手工记住所有细节步骤。

换言之，AI 工程技能工作流 在这里不是“教 Agent 写代码”的泛泛说法，而是把需求澄清、原型试错、规格沉淀、任务拆解、测试驱动实现和代码审查，组织成一条可复用流水线。

要解决的具体问题

原文把这套工作流要治的病概括成四类，这四类问题也是它存在的直接理由：

1. Agent 想当然

你以为模型已经懂了，但它实际上按自己的理解补完了大量未确认信息，最后做出的结果“像是相关，但不是你要的”。

对应药方是先把需求审清楚，而不是直接进入编码。

2. Agent 话太多、术语不稳

项目里本来已经有自己的概念和黑话，但模型每次都重新猜，导致表达啰嗦、不精确，也容易误解上下文。

原文举了一个很具体的例子：原本一句较长的话，大意是“某节课在某个章节里被落到文件系统上生成实体文件时会出问题”，在项目内部统一术语后，被压缩成“物化级联出问题了”。这说明工作流不只是生成代码，也要建立人和 Agent 共享的项目共同语言。

这与项目共同语言直接相关。

3. 代码跑不起来

如果没有测试反馈，Agent 写代码就近似于盲写。生成速度快不代表结果可执行。

对应药方是把测试反馈内置进实现流程，也就是让实现过程由 TDD 循环约束，而不是先写一大坨代码再祈祷它能跑。

4. 代码库快速腐化

Agent 会加速产出，也会加速技术债累积。如果没有审查和结构纪律，项目很快会变成“谁都不敢动”的状态。

对应药方是把代码审查和架构体检纳入流程收尾，而不是把“以后再整理”当默认做法。

主线：idea → ship

这套工作流的核心主线可以概括为：

/grill-with-docs → /prototype（按需分岔）→ /to-spec → /to-tickets → /implement（内部驱动 /tdd）→ /code-review

主线的价值不在于名字，而在于每一步都承担不同责任，并且把“祈祷 Agent 自己看着办”的空间压到最低。

/grill-with-docs：先把需求和事实对齐

/grill-with-docs 是起点。它的作用不是直接产出代码，而是像“审问”一样逐条逼近真实需求和决策边界。

原文强调它的工作方式是：

• 能从代码库里查到的事实，它自己先查。
• 查不到、文档中没有、需要业务判断的地方，它再问用户。
• 问答会持续到双方对齐，而不是问一两句就草率进入编码。

因此，这一步承担的是“澄清与校准”责任。它针对的正是 Agent 最常见的想当然问题。

/prototype：专门处理聊天回答不了的问题

/prototype 不是每次都要走，而是主线中的分岔步骤。

当某个问题靠聊天、文字讨论或脑补无法得到可靠答案时，就应该转向 /prototype。原文给出的典型场景是交互和体验问题，例如“某个交互到底顺不顺手”。这种问题只靠口头描述往往讲不清，必须跑起来看。

/prototype 的产物是一次性代码，目的不是沉淀正式实现，而是快速验证判断。验证完成后，这些代码可以直接丢弃。

这一步有两个边界非常关键：

• 它服务于“回答问题”，不是直接交付正式功能。
• 它产出的代码不默认进入主干，也不要求像正式实现那样长期维护。

因此，/prototype 更像受控试错，而不是偷跑开发。

/to-spec：把对话整理成规格

当需求已经被讨论清楚后，/to-spec 负责把前面的对话、结论和约束，整理成一份规格文档。

它的职责不是继续发散，而是把已经确认的信息收束为后续执行可依赖的文本：做什么、不做什么、有哪些边界、有哪些已定决策。

这一步的重要性在于：如果不把对话沉淀为规格，后续工单拆分和实现就仍然容易回到口头理解，导致再次漂移。

/to-tickets：把规格切成带依赖关系的工单

/to-tickets 的职责是把规格进一步拆成可执行工单，而不是停留在“大功能描述”层面。

原文明确指出，这些工单之间会声明“卡点关系”，也就是依赖关系或阻塞关系。换言之，它不是简单列一个 todo 列表，而是把先后顺序和相互约束表达出来。

这些工单既可以落到本地文件，也可以接入外部工单系统，例如 Linear 或 GitHub Issues。

因此：

• /to-spec 解决“把讨论变成规格”的问题。
• /to-tickets 解决“把规格变成可执行计划”的问题。

两者不能混为一谈。

/implement：不是孤立写代码，而是编排实现过程

/implement 看起来像“开始写代码”的步骤，但它不是孤立地生成实现。