<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>spdd on </title>
    <link>/tags/spdd/</link>
    <description>Recent content in spdd on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Thu, 21 May 2026 22:00:00 +0800</lastBuildDate><atom:link href="/tags/spdd/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>读《Structured Prompt-Driven Development》：把 prompt 当一级交付物的几点笔记</title>
      <link>/reading/martinfowler/structured-prompt-driven-spdd/</link>
      <pubDate>Thu, 21 May 2026 22:00:00 +0800</pubDate>
      
      <guid>/reading/martinfowler/structured-prompt-driven-spdd/</guid>
      <description>Wei Zhang 和 Jessie Jie Xia（两位都来自 Thoughtworks）2026-04-28 在 Martin Fowler 网站发表了 Structured Prompt-Driven Development。核心主张比较干脆：把 prompt 当成与代码同级的工程工件管理——版本化、评审、复用、迭代。这条主张不新，但作者把它具体化成了一组流程、一份七维度模板（REASONS Canvas）和一套配套 CLI（gszhangwei/open-spdd），外加一个完整示例项目（gszhangwei/token-billing）。
SPDD 与 PDD、Spec Kit、PromptOps 这些相邻概念的差别，另起了一篇速写：prompt-driven vs spec-driven：把 PDD、SPDD、Spec Kit 几支理清楚。本文只聚焦 SPDD 这一篇文章本身。
文章主张：prompt 是一级交付物 文章开头给的一句话很直接：
Instead of relying on ad hoc chats, SPDD turns prompts into assets that can be: version controlled, reviewed, reused, and improved over time.
这句话把 SPDD 和临时 chat 式交互区分开来：prompt 不只是一次性输入，而是可以被版本化、评审、复用和持续改进的资产。SPDD 想解决的问题文章写得很具体：
模糊的需求被快速翻译成代码，误解随之扩散 评审里要处理的改动越来越多 集成 / 测试问题增加 难以推理生产风险 它给出的答案是：把&amp;quot;意图&amp;quot;从 chat 历史里拎出来，写成可追溯的工件。</description>
    </item>
    
  </channel>
</rss>
