我们刚刚开源了全套的AI开发技能和方法论： IDD（Intent Driven Development）
我们开源了一套叫 IDD（Intent Driven Development）的方法论和工具链。核心理念一句话：告诉 AI “要什么”，而不是 “做什么”。
在 AI 辅助编程成为日常之后，传统的需求文档、user story、技术 spec 这些东西越来越显得不合时宜。它们是为人类协作设计的，搬到人机协作的场景下，写了一堆文档 AI 还是经常理解偏，然后就是一轮轮的修正。IDD 的思路是换一个方向：与其告诉 AI 怎么做，不如把"要什么"说清楚，让 AI 自己规划实现。这篇文章想聊聊我们为什么这么做，以及这套东西具体是怎么运作的。
SDD vs IDD
软件工程领域有过很多尝试来解决"先想清楚再动手"的问题。SDD（Spec Driven Development）就是其中之一，核心思路是先写详细的规格说明，再按规格实现代码。听起来很合理，但在 AI 时代暴露出问题。
| 方法 | 流程 | 问题 |
|---|---|---|
| Traditional | Code → Test → Docs | 文档经常过时或缺失 |
| SDD | Spec → Code → Test | Spec 容易过时，分散在多个文件里 |
| TDD | Test → Code → Docs | 测试不能表达设计意图 |
| IDD | Intent → Test → Code → Sync | Intent 表达"要什么"和"为什么"，AI 负责"怎么做" |
我对 SDD 这套形式主义有些切身体会。多年前在西雅图某大软件公司工作时，团队有位 PM 小哥，任何东西到他手里都会变成巨长的八股文，几句话能说清的事情非要拆成十几个 user story，格式工整，滴水不漏，看完之后你依然不知道这东西到底要干嘛。去年试用 Amazon 的 Kiro 时，那种熟悉的感觉又回来了。Kiro 是典型的 SDD 工具，它会帮你生成一堆 spec 文件，结构很规范，但"为了写而写"的气息扑面而来。这不是工具的问题，而是思路的问题，把传统软件工程那套直接搬到 AI 时代，工具变了但思维方式没变。
SDD 的问题在于它还是按传统方式组织信息：按需求类型分（功能需求、UX 需求、技术需求），拆成 user story，维护单独的任务文件。这种分类对人类协作有意义，产品经理看功能需求，设计师看 UX 需求，架构师看技术需求。但对 AI 来说，这种分类把完整的上下文打散了。AI 需要理解一个模块的全貌，而不是从五个文件里拼凑信息。你按传统方式拆得越细，AI 越要花力气重新拼装，拼错了就是反复修正。
IDD 的思路不同：按模块组织而不是按需求类型组织，保持完整的上下文；不写任务文件，让 AI 自己分解任务；Intent 的抽象层级更高，描述"要什么效果"而不是"怎么实现"。和 TDD 比，IDD 在 Test 之前加了一层 Intent；和 SDD 比，IDD 不规定实现细节，让 AI 有空间规划更好的方案。
为什么 IDD 可行
你可能会问：不写详细 spec，AI 怎么知道具体要做什么？这里有一个反直觉的事实：在很多领域，AI 比人类更懂"怎么做"。
前段时间我想实现一个 6502 CPU Emulator，这种任务传统上属于"硬核"级别，需要理解 CPU 架构、寄存器设计、指令编码解码，光设计阶段就要翻阅大量技术手册。如果用 SDD 的方式，我得先写几十页文档把每条指令、每种寻址模式都列清楚，spec 还没写完项目可能就凉了。但我只告诉 AI：我需要一个 6502 Emulator，能正确执行标准指令集，要有基本的调试能力。就这些。
结果让我意识到一件事：6502 是 1975 年的芯片，驱动过 Apple II、NES 游戏机，围绕它的技术文档和开源实现多到难以计数，LLM 见过的 emulator 代码比任何人类专家都多。AI 给出的模块划分比我自己设计的还清晰，结合 TDD 的要求整个实现一气呵成。过去被认为需要最资深工程师的任务，对 AI 来说反而轻松，因为这类经典问题在训练数据里覆盖最充分。
这就是 IDD 可行的基础：在 AI 训练数据覆盖充分的领域，你不需要告诉它怎么做，你只需要把"要什么"说清楚。AI 见过的模式比我们多，它规划的方案可能比我们自己想的更合理。人类的价值在于判断"要什么是对的"，这才是真正需要人类智慧的部分。
Intent 是新的源代码
这句话的意思是：Code review 可以交给 AI，Intent review 必须由人类完成。
AI 擅长检查代码是否符合规范、是否有安全漏洞、是否遵循项目风格。但 AI 无法判断"这个功能是不是我们真正想要的"，这个判断只能由人类做出。所以人类的精力应该集中在 Intent 的审核上，而不是逐行 review AI 生成的代码。
Intent 和传统需求文档的区别：
| 传统需求 | IDD Intent |
|---|---|
| 按类型分（功能/技术/UX） | 按模块分 |
| 描述"做什么" | 描述"要什么" |
| 写给人看 | 写给 AI + 人看 |
| 写完容易过时 | 持续与代码同步 |
Intent 的抽象层级更高。你不用告诉 AI 用什么技术、怎么分层，这些让 AI 自己规划。你要做的是描述清楚：最终效果是什么、有什么约束、边界情况怎么处理。
Intent 文件结构
IDD 的 Intent 文件用三层结构：
1. 结构图 - ASCII 图展示模块关系、数据流向。图比文字精确，LLM 能直接"看懂"。
2. 约束规则 - 必须遵守的限制，如依赖方向、边界规则。可直接转化为 lint 规则或测试断言。
3. 行为示例 - 具体的输入输出，包括边界情况。可直接转化为测试用例。
设计原则：每一层都必须是可验证的。 不是模糊描述，而是可以用代码检查的约束。
工具链
我们做了一套 Claude Code 插件：
| 命令 | 功能 |
|---|---|
/intent-assess | 评估项目是否适合 IDD |
/intent-init | 初始化 IDD 目录结构 |
/intent-interview | 通过采访把想法转化为 INTENT.md |
/intent-review | 审批 Intent 的关键 section |
/intent-check | 验证代码与 Intent 是否一致 |
/intent-report | 从 Intent 生成文档 |
完整流程：
/intent-assess # 评估是否适合
↓
/intent-init # 初始化结构
↓
/intent-interview # 创建 Intent
↓
/intent-review # 审批关键部分
↓
[AI 实现代码]
↓
/intent-check # 验证一致性
安装：
npx add-skill arcblock/idd
适用场景
适合 IDD：
- AI 辅助开发是主要工作方式
- 系统软件、框架、基础设施
- 需要严格架构边界的项目
可能不适合：
- 高度监管行业，必须用传统文档格式
- 团队没有 AI 工具
- 需要给非技术人员看 user story
写在最后
回到开头的问题：人类应该告诉 AI 什么？我觉得答案是告诉它"要什么"，而不是"怎么做"。Spec-driven 在 AI 时代容易变成形式主义，写了一堆文档 AI 还是不理解你要什么。IDD 换了个方向，与其详细规定怎么做，不如把"要什么"说清楚，让 AI 自己规划实现。
这套东西我们自己用了一段时间，感觉方向是对的。开源出来，希望对其他团队也有帮助。
GitHub: github.com/ArcBlock/idd