知擎写这篇东西的起因，是我最近在一线项目复盘时看到的一组数据：前后端加测试，差不多有一半的需求，在第一版交付后都要经历至少两轮“重新对需求”的返工。返工的原因翻来覆去就那么几个——业务方说“这不是我要的”，开发说“当时需求文档里没写”，测试说“按文档测的，文档没覆盖”。那一刻我意识到，问题从来不在于大家的编码速度，而在于整个协作链条里，人的“意图”在层层转述中磨损了。
这也是IDD（意图驱动开发）这几年越来越受关注的根本原因。它不发明新框架，不绑定具体的编程语言，它只是在回答一个问题：怎样让从业务想法到代码落地的过程中，每一步都有一条可追踪、可验证的线索。而在IDD的实践里，最容易被低估、但也最值得花时间的产物，就是构块规格说明书。这篇文章，我会用完整的思路拆解它到底是什么、应该包含哪些内容、怎么写出一份真正能落地的规格，以及在真实项目中你会踩到哪些坑。
1. 代码交付反复返工，根源从来不在“手速”而在“意图传递”
1.1 三层信息失真：需求是怎么在传递中变形的
软件开发过程中的“返工成本”，绝大多数不是技术难点造成的，而是需求理解不一致造成的。我见过太多这样的协作链条：业务人员用自然语言描述一个诉求，产品经理把它翻译成业务流程图，开发负责人再把它拆解成技术方案，最终由执行开发或AI工具生成代码。每一次转译，都是一次信息的再加工，而再加工必然伴随损耗。
举个例子。业务方说“给订单列表加一个导出功能”，这句话听起来很明确，但落到不同人脑子里完全不是一回事。业务方的真实意图可能是“我要把本月所有完成订单的关键字段导成Excel，给我的财务同事做对账”。产品经理可能只理解到“订单列表页提供一个导出按钮”，开发人员考虑的是“后端接口是同步返回还是异步任务拉取”，而AI辅助编程工具如果没有更多上下文，会默认按最普通的CSV导出实现，把带格式、带汇总行、带币种换算的复杂需求全部漏掉。
这不是谁不专业的问题，而是自然语言天然带有“信息省略”的倾向。说话人默认很多背景对方知道，听话人又习惯用自己的经验脑补缺失的部分。三层转译下来，最终代码和原始意图之间可能已经隔了十万八千里。
1.2 “意图信息差”才是软件开发最大的隐性成本
我一直觉得，团队里最贵的不是服务器费用，也不是IDE授权费，而是“意图信息差”带来的隐性成本。信息差会出现在每个阶段：需求评审会上没问清楚的关键细节，会在联调阶段变成阻塞；测试用例里没覆盖到的边界，会在线上出事故；技术文档里省略掉的设计取舍，会在人员变动后变成无人区。
IDD这个思路之所以成立，是因为它把“消除信息差”这个模糊的目标，拆成了几个非常具体的动作：捕获意图、分解意图、为每个可独立交付的部分建立规格、然后才进入编码。它不是让你多写文档，而是让你在写代码之前，强制性地把脑子里的假设全部摆到台面上。
1.3 在意图和实现之间，需要一份“契约层”
如果你做过集成电路设计，一定熟悉“规格先行”的流程。芯片设计里，规格书是连接架构师和前端实现工程师的契约，一份规格含糊了，后端的布局布线再优秀也白搭。软件工程在很长时间里缺少这种“契约感”，PRD更像是记录需求的备忘录，技术设计文档更像是写给未来维护者的说明，两者都不是真正意义上的执行契约。
构块规格说明书要做的，就是填上这个空档。它不是需求文档的详细版，而是面向实现的、以可验证性为中心的规格描述。它的读者既是人，也是AI工具——只要描述足够精确，人看了知道边界在哪里，AI辅助工具看了也知道生成代码时不能被模糊描述带偏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 把构块规格放进IDD流程：它到底是哪个环节的产物
2.1 我习惯把IDD流程拆成六个阶段
IDD目前没有统一共识标准，更多是实践中形成的方法论沉淀。我在多个项目里调整过流程，现在习惯把它拆成六个阶段：
- 意图捕获：收集业务目标，分辨哪些是用户真实诉求，哪些是伪需求。
- 意图分解：把大目标拆成可以独立开发、独立验证的功能单元。
- 构块建模：为每个功能单元定义边界、输入输出、依赖关系和状态变化。
- 规格编写：把构块模型写成结构化的、可验证的规格说明，这就是构块规格说明书。
- 智能实现：基于规格，由人或AI工具生成实现代码。
- 验证反馈：用规格中的验收标准反推测试用例，形成闭环。
对这个流程，我有两个心得。第一，阶段之间不要真的搞成瀑布流，规格写完进入实现后，发现边界遗漏要允许回到前序阶段补充；第二，规格编写这个阶段花的力气决定了后面两个阶段的总效率，它是杠杆率最高、也最容易被忽视的一环。
2.2 什么是一个“构块”
“构块”这个概念，可以理解为IDD对系统进行切分后产生的基本功能单元。一个构块应该满足三个特征：有明确的边界、可以被独立验证、可以被组合进更大的业务场景。它可能是单个微服务接口，可能是前端页面里的完整交互模块，也可能是一个后台定时任务。
我自己的经验是，构块的粒度在项目初期不需要追求绝对一致。判断标准很简单：如果一个功能单元的规格，你能用不超过两页纸写清楚，它的边界就是合理的；如果你发现规格越写越长，或者一个构块里塞了三四种互不相关的业务规则，那通常不是规格写得