昨天开篇里我们说过，AI 写代码”快”和”烂”并存的根源，往往不在写的过程，而在写的起点——需求没想清楚。今天进入六阶段流水线里的第一个：DEFINE。

DEFINE 阶段在 agent-skills 里由五个技能组成（interview-me、idea-refine、spec-driven-development、source-driven-development、doubt-driven-development）。这五个不是同一件事，它们有先后关系：先问对问题，再打磨想法，再把规约写下来，动手前最后用对抗性视角审视一遍。本文重点讲前三件——也是日常最常用的三件。

一句话定位

如果用一句话讲清三件套的分工：

interview-me 把”你以为的需求”挖成”真实的需求”；
idea-refine 把”一个模糊的想法”打成”几个可选的方案”；
spec-driven-development 把”选中的方案”写成”可以验收的规约”。

三件套覆盖了从”用户嘴里的一句话”到”模型能照着写的文档”的全部转化。

interview-me：一次只问一个问题

很多人让 AI 写代码，第一句话就是”做一个登录功能”。模型顺着这句话开始动手，写出来八成不是你想要的——因为”登录功能”对不同的人意味着完全不同的东西。

interview-me 这个技能的核心动作只有一条：一次只问一个问题，每个问题都附带自己的最佳猜测。

它不停下来等你”再想想”，而是带着猜测往下走，让你确认或纠正。这种做法的妙处在于：它把”挖掘需求”这件成本极高的事，拆成了一个又一个可以秒回的小决策。

来看一段示例对话。假设用户最初说：”做一个通知系统”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
AI: 你说的"通知系统"，我理解是要让系统能在某个事件发生时
    主动把消息推给用户。我先按这个理解往下走。
    
    我的猜测是：这里的"用户"是终端用户（购买你产品的 C 端），
    而不是内部员工。是这样吗？

用户: 是的。

AI: 好。那"事件"我猜测是业务事件——比如订单状态变化、
    评论被回复、好友申请这些。
    范围是不是就是这几个？还是另有清单？

用户: 主要是订单状态变化。评论和好友申请先不做。

AI: 收到。我猜你想要"实时"——事件发生 5 秒内用户能看到，
    而不是"批处理"——比如定时汇总成一份日报。
    这个延迟预算对吗？

用户: 5 秒太久，能不能再快一点？最好 2 秒内。

每一轮都是同一个模式：先给猜测，再求确认。这比”你补充一下需求吧”高效得多——后者把思考负担全压给用户，而前者把草稿先抛出来让用户改，改比写容易。

什么时候不要用这个技能？interview-me 的 SKILL.md 明确写了 NOT for 场景：

  • 需求已经写得很清楚，且用户明确说”按这个做”；
  • 改动只动一行、一个变量；
  • 是用户主动召请它（比如用户直接说”先别动手，先 grill 我一下”）。

否则，只要拿到的需求是”模糊的””常规的””没有量化指标的”，都应该先走 interview-me。

idea-refine：发散→收敛

拿到一个打磨过的需求之后，下一步不是写代码，而是看有没有更好的解法。idea-refine 干的就是这件事——结构化的发散与收敛。

它的流程分三步：

flowchart LR
    A["理解与扩展
发散"] --> B["评估与收敛"]
    B --> C["锐化与产出
一页纸"]

第一步是发散。把需求重述一遍，主动问”还有没有别的可能”，生成多个变体。比如需求是”通知系统”，可能的解至少有：

  • 中心化消息队列（Kafka / RocketMQ）
  • 轻量级嵌入式方案（数据库轮询 + WebSocket）
  • 第三方 SaaS（SendGrid / 极光 / 个推）
  • Serverless 事件总线（AWS EventBridge + SES）

每一种都有完全不同的成本结构和维护负担。在没列出来之前，你不知道你选的是不是最差的。

第二步是收敛。把这些变体聚类、做权衡比较、暴露隐藏假设。”如果用第三方 SaaS，那用户数据会出境吗？””如果自建队列，团队现在有人能 oncall 吗？” 这些问题在评审时才暴露就晚了，要在收敛阶段就挑明。

第三步是产出。一页 Markdown，把选中的方案、备选方案、关键假设、风险点都写清楚。SPEC 的草稿从这里开始。

spec-driven-development：PRD 先行

走到这一步，需求已经从”一句话”变成”一页纸”。下一步是把它写成模型能照着写的规约。spec-driven-development 这个技能定义了规约的四个阶段门控：

flowchart TB
    S1["1. 目标与非目标
Goals & Non-goals"] --> S2["2. 结构与边界
Structure"]
    S2 --> S3["3. 测试与边界
Tests & Edge cases"]
    S3 --> S4["4. 完成定义
Definition of Done"]
    S4 -->|未通过| S1

每一步都必须通过门控才能进入下一步。门控不是一个动作，而是一个判断：

  • 目标与非目标门控：能一句话讲清楚”为谁、解决什么问题”吗？非目标是否同样明确？
  • 结构门控：模块划分是否稳定？接口边界是否清晰到可以独立 review？
  • 测试与边界门控：有没有把验收测试列出来？边界场景（空、并发、超长输入、异常）是否覆盖？
  • 完成定义门控：所有测试是否跑通？文档是否同步？监控/告警是否就位？

很多团队跳过了前两步直接写代码，结果是：

  • 目标模糊 → 写完才发现做错了目标；
  • 结构未定 → 写完发现要在三个模块之间大动；
  • 测试/边界未列 → 评审时被问”这个 case 怎么处理的”答不上来；
  • 完成定义缺失 → 写完不知道什么时候算”做完了”。

spec-driven-development 把这四个门控变成显式动作，每个动作都有”必须产出物”。比如目标门控必须产出一段不超过三句话的目标描述；测试门控必须列出一份场景清单。

反合理化表堵住了什么

DEFINE 阶段最容易出现的偷懒借口，agent-skills 已经替我们列了一张清单：

借口 为什么是错的
“这个需求太小，写个 SPEC 太重” 越小的改动越容易漏边界；SPEC 不重，三句话就够
“用户已经说清楚了” 用户嘴里的话和他脑子里的需求通常差三层
“我可以先写代码，等遇到问题再改 SPEC” SPEC 是设计，不是文档；写完代码再补 SPEC，等于先盖楼再画图纸
“发散浪费时间，我直接选最优解” 你以为的最优解 70% 不是最优解；发散的成本远小于做错返工的成本
“完成定义不重要，写完代码就是完成” 没有 DoD，团队永远在争论”做完了没有”

这张表的存在很关键。SKILL.md 里它被叫做”Common Rationalizations”，每一行右边那一栏叫”Reality”。它的作用不是给用户看，而是给 AI 看——当 AI 想跳步时，右栏就是强制反驳。

三件套之外的补充

DEFINE 阶段还有两个技能今天没展开：

  • source-driven-development：要求每一条框架特定的代码都必须有官方文档支撑。这是另一种”反幻觉”机制。
  • doubt-driven-development：在新上下文中对决策做对抗性审视，专治”长会话里的越聊越自信”。

这两个技能更适合长链路项目和敏感改动，平时的小改动用上前三件就够。

写在最后

DEFINE 阶段听起来很慢。三件套走下来可能要花 30 分钟到 2 小时。但它解决的问题是”做错返工”——这个成本通常以天为单位。

工程上有句话：前期 1 小时的设计，能省后期 8 小时的实现。AI 编码时代这条经验没变，反而更重要——因为模型的产出太快了，错得也快。

明天我们进入一个有意思的话题：agent-skills 是怎么用 Anti-Rationalization 表和 Red Flags，把”AI 找借口跳过流程”这条路堵死的。

参考资料

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。