ginobefun@hongming731 · XThoughtworks提出结构化提示驱动开发（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，划出不可妥协的边界。