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,划出不可妥协的边界。