# 结构化提示驱动开发（SPDD）：让 AI 编码从个人提效走向团队规模化

- 来源：ginobefun (@hongming731)
- 发布时间：2026-04-29 09:37
- AIHOT 分数：61
- AIHOT 链接：https://aihot.virxact.com/items/cmojdynh303gzslzpsvkq67dd
- 原文链接：https://x.com/hongming731/status/2049302120378278290

## AI 摘要

Thoughtworks提出结构化提示驱动开发（SPDD），以解决AI编码助手带来的团队协作与系统交付瓶颈。该方法将提示视为一等交付物，通过REASONS画布（需求、实体、方法、结构、操作、规范、保障）在编码前明确意图与约束，并配套工具链支持从分析到生成的全流程。SPDD强调抽象优先、对齐和迭代评审，适用于规模化、高合规场景，能提升交付确定性与可追溯性，但其价值高度依赖团队的抽象建模与系统分析能力。

## 正文

结构化提示驱动开发（SPDD）：让 AI 编码从个人提效走向团队规模化

原文：https://martinfowler.com/articles/structured-prompt-driven/

团队用上 AI 编码助手之后，最先感受到的提速发生在个人层面。但交付速度的瓶颈从来就不在打字。把视野拉到从需求到上线的完整链路上，新的摩擦立刻浮现：模糊的需求被快速翻译成代码，误解也被同步放大；评审要消化的变更更多，质量更容易参差不齐；集成和测试问题增加，因为「生成出来」并不等于「真正对齐」；变更体量一大，生产风险也更难评估。局部快了，系统级吞吐却未必跟上。这就像买了一辆法拉利却开在泥泞乡道上，发动机再强，到达时间还是被路况决定。

Thoughtworks 内部 IT 团队由此走向了一套被称为「结构化提示驱动开发（SPDD）」的方法。它的核心主张是，把提示当作一等交付物来对待，纳入版本管理，可以被评审、被复用、被持续打磨。SPDD 由两个组件组成。

第一个组件是 REASONS 画布，一个由七个部分构成的提示结构，引导一份提示从意图走到设计再走到执行和治理。
- R 是 Requirements，明确要解决的问题和完成标准；
- E 是 Entities，梳理领域实体及其关系；
- A 是 Approach，给出解决思路；
- S 是 Structure，说明变更落在系统中的哪个位置；
- O 是 Operations，把策略拆成可执行的步骤；
- N 是 Norms，沉淀通用工程规范；
- S 是 Safeguards，划出不可妥协的边界。

这套结构强迫团队在写代码之前就把意图和约束讲清楚，把不确定性左移。

第二个组件是 SPDD 工作流，把提示和代码放在同一套工程纪律下。它的关键约束很简单，当现实和提示出现偏差时，先修提示，再改代码。落到工具层面，是一组叫 openspdd 的命令行命令：

- /spdd-story 把大需求拆成符合 INVEST 原则的故事
- /spdd-analysis 提取领域关键词并扫描相关代码生成策略性分析，
- /spdd-reasons-canvas 产出完整的七维度蓝图
- /spdd-generate 严格按画布生成代码
- /spdd-prompt-update 在需求变化时增量更新画布
- /spdd-sync 则把代码侧的重构反向同步回画布，让提示始终是当前代码的准确记录。

文章用一个计费引擎的增强案例完整走了一遍这套流程。开发者依次执行：从需求生成简化版用户故事，澄清核心逻辑和范围边界，跑分析命令拿到上下文，生成 REASONS 画布并审阅意图，再生成代码、跑接口测试。整个过程下来，意图对齐度据作者描述能达到 99% 左右。

SPDD 沉淀出三项核心技能。
- 抽象优先要求在生成代码之前先想清楚有哪些对象、它们如何协作、边界在哪里，否则 AI 会冲进实现细节而结构散掉。
- 对齐强调在写代码前就把要做什么和不做什么显式写出来，把规范和硬约束摆到台面上。
- 迭代评审则把 AI 辅助变成一个受控循环，避免一次性草稿式的产出。

同时作者也强调，SPDD 不是万能药。在规模化、标准化交付，以及高合规、强约束的场景里它最值钱；在救火热修复、探索性原型、一次性脚本，以及业务规则极度模糊的领域里，它的治理成本会显著超过收益。它的回报包括确定性、可追溯性、更快的评审、可解释性和更安全的演进，代价是心态转变、对前置抽象能力的要求，以及自动化工具链的搭建。

文章的结尾点出了它真正的精神所在。SPDD 提供的只是「招式」，真正的优势来自背后的元能力，包括抽象建模、系统化分析和对业务的整体理解。在 AI 时代，软件开发比拼的并非模型 IQ，而是工程师的认知带宽，是能否清晰思考、准确框定问题、坚决做出决策。正如 Hamming 所说，在科学里如果你知道自己在做什么，那你就不该在做这件事；在工程里如果你不知道自己在做什么，那你就不该在做这件事。