PDD：Prompt作为第一等制品

TL;DR

本文核心观点：

1. Prompt即代码 — Prompt需要版本控制、Code Review、CI/CD
2. 制品升级 — Prompt与源代码、测试、文档并列成为核心交付物
3. 工程化标准 — Prompt的编写、评审、部署需要标准化流程
4. 资产沉淀 — 高质量Prompt是可复用的组织知识资产

为什么Prompt是第一等制品

💡 Key Insight

当AI生成代码成为常态，决定代码质量的不是编程技巧，而是Prompt质量。Prompt就是新时代的”源代码”。

软件制品的演进

软件制品的形态随着开发范式的演进而不断升级。早期的软件开发，制品只有源代码本身；后来有了测试，测试成了第二类制品；再后来有了文档，文档成为第三类。每一次制品的扩展，都伴随着工程化手段的跟进：版本控制、Code Review、CI/CD。

如今，当 AI 成为代码生成的主力，Prompt 作为驱动 AI 的意图载体，已经成为第四类核心制品。与源代码一样，Prompt 需要版本控制；与测试一样，Prompt 需要质量评审；与文档一样，Prompt 需要版本化管理。不同的是，Prompt 的质量直接决定了 AI 输出的质量——Prompt 的微小改动，可能导致输出天壤之别。这种”高杠杆”特性，使得 Prompt 的工程化比以往任何一种制品都更迫切。

Prompt的核心地位

Prompt质量直接决定AI产出质量。 这不是夸张，而是工程实践中的普遍规律。当一个 Prompt 被优化到”一次生成可用代码”的程度，它实际上已经承担了传统开发中需求文档 + 架构设计 + 核心算法三重职责。Prompt 是开发者意图的直接表达，是 AI 理解任务的唯一窗口。窗口模糊，再强的 AI 也无济于事；窗口清晰，普通的 AI 也能产出高质量结果。

Prompt作为制品的特征

Prompt完全符合”第一等制品”的定义。

💡 Key Insight

Prompt完全符合”第一等制品”的定义——它是意图的直接表达，是软件开发流程的起点，也是 AI 产出质量的决定性因素。

Prompt版本控制

💡 Key Insight

Prompt的微小改动可能导致输出巨大变化。版本控制不仅是备份，更是可追溯的实验记录。

Prompt版本控制挑战

挑战1：语义版本不适用

传统的语义版本（SemVer）基于 API 的公开接口变化来定版本号，适用于函数签名变更、字段增删等可观测变化。但 Prompt 没有公开接口——它是一个函数，一个从自然语言到输出的映射。同一个 Prompt，在不同模型版本上表现可能截然不同；在相同模型上，温度参数不同输出也不同。语义版本的三段式（主版本.次版本.补丁）在这里找不到对应物：我们没法说这是”主版本升级”还是”补丁修复”。

挑战2：难以diff

代码 diff 的价值来自于语言的语法结构：两行代码增删一行，diff 精确显示变化。Prompt 是纯文本，语义相近的两个 Prompt 可能字面上差异很大，字面上差异很小的两个 Prompt 语义上可能完全相反。”这个 Prompt 改了 5 个字”在代码里是小事，在 Prompt 里可能是灾难。传统的 line-by-line diff 对 Prompt 的语义变化完全不敏感。

挑战3：输出不稳定

同样的 Prompt 两次执行，输出可能不同——即使模型、温度、seed 都固定。LLM 的概率本性使得 Prompt 版本控制不只是”管理 Prompt 文本”，还要同时管理模型版本、温度参数、context window 等运行环境参数。版本化必须包含这些环境变量，否则同一个”v1.0”的 Prompt 在不同运行环境下表现可能完全不同。

Prompt版本控制方案

针对上述三个挑战，实际业界已经形成了几种可行的版本控制方案。

内容寻址存储（Content-Addressable Storage）：不看版本号，而是看内容哈希。SHA-256 哈希相同的 Prompt 被视为同一版本，不同的哈希必然意味着内容变化。这种方式天然解决了”什么是版本”的定义问题：内容即版本。配合 prompt 注册表（Prompt Registry），每次保存都会生成一个不可变的哈希地址，支持精确回溯。

Prompt元数据追踪：每个 Prompt 版本记录的不只是文本，还包括：模型版本（如 gpt-4o-2026-06）、温度参数、top-p 参数、context window 大小、所属业务线、作者、标签。这使得版本控制从”文本管理”升级为”运行环境快照管理”，让复现成为可能。

语义化标签（Semantic Tagging）：放弃 SemVer 的数字版本，改用业务语义标签，如 prompt/user-onboarding/v2/production。标签包含场景、编号、环境三层信息，比数字版本更直观，也更容易在团队内形成统一认知。

这三种方案并不互斥——很多团队实际采用的是”内容哈希 + 语义标签 + 元数据注册表”的组合方案，既能精确追溯，又能语义清晰。

Git管理Prompt的最佳实践

Commit Message规范：

Prompt 的 Git Commit Message 建议采用 Conventional Commits 的变体，格式为 prompt(scope): description，其中 scope 表示 Prompt 所属的业务场景或功能模块。例如：

prompt(code-review): 增加对安全敏感字段的检查规则
prompt(user-onboarding): 优化新用户引导Prompt，减少幻觉输出
prompt/bugfix: 修复PDD文档生成Prompt的格式崩塌问题

这种方式让团队在 Git 历史中一眼就能看到 Prompt 变更的业务背景，而不只是技术细节。

目录结构规范：

建议在仓库中建立 prompts/ 目录，按业务域或功能模块组织，结构示例：

prompts/
├── code-review/
│   ├── security-check.md
│   └── pr-summary.md
├── user-onboarding/
│   ├── welcome.md
│   └── feature-intro.md
└── shared/
    ├── system-prompt-base.md
    └── output-format.md

每个 Prompt 文件保持单一职责，一个文件只对应一个使用场景。共享的基础 Prompt 通过 include 机制引入，而非复制粘贴。

Prompt Code Review

💡 Key Insight

Review Prompt比Review代码更高效：改Prompt一分钟，改代码可能需要一小时。

Prompt Review检查清单

一份高质量的 Prompt Review 检查清单，是 Prompt 工程化的基础。以下是实操中总结的 15 点检查项，覆盖从语义到工程的完整维度：

意图清晰性

1. Prompt 是否明确说明了期望的输出格式？
2. 是否有明确的边界条件说明（什么情况该拒绝回答、什么情况该报错）？
3. 关键术语是否有定义，避免 AI 自行推断？

完整性

1. 是否覆盖了该场景的主要使用路径？
2. 是否包含了常见边缘情况的处理指引？
3. 是否有足够的上下文信息（context），避免跨对话丢失关键信息？

可维护性

1. Prompt 是否过于冗长（超过 2000 token 应考虑拆分）？
2. Prompt 中的指令是否相互矛盾或重叠？
3. 硬编码的示例是否过多（超过 3 个应考虑抽象为 few-shot 模板）？

模型适配性

1. Prompt 是否依赖特定模型的特殊能力（如 CoT、function calling）？
2. 温度参数建议值是否已标注？
3. 是否指定了输出长度限制，避免资源浪费？

质量可控性

1. 是否有可验证的输出标准（可以用自动化测试检验的）？
2. 是否包含”自我检查”指令，让 AI 在输出前验证是否符合要求？
3. 是否有明确的错误处理机制（当输入不符合预期时如何响应）？

Review流程示例

以下是一个真实的 Review 流程示例，展示从提交到反馈的完整闭环：

提交的Prompt：

你是一个代码审查助手。当用户粘贴一段代码，你需要：
1. 检查是否有安全漏洞
2. 检查是否符合最佳实践
3. 给出修改建议

Reviewer反馈：

该 Prompt 存在以下问题：

1. 缺少输出格式规范：”给出修改建议”没有说明格式。审查结果应该结构化输出（漏洞类型 + 严重程度 + 具体位置 + 修改建议），否则下游无法自动化处理。

2. 安全检查范围不明确：”安全漏洞”过于宽泛。应明确覆盖 OWASP Top 10 中的哪些类型（SQL注入、XSS、敏感信息暴露等），并给出对应的检查逻辑说明。

3. 缺少输入验证：没有说明当用户粘贴非代码内容（如纯文本问题）时的处理方式，容易产生幻觉响应。

4. 缺少上下文边界：没有说明代码语言的限制（只支持主流语言，还是支持所有）、代码长度的上限。

修订后的Prompt核心片段：

当用户粘贴代码时，首先判断是否为有效代码（非代码内容返回"请粘贴代码段"）。若是代码，按以下顺序审查：

1. 安全漏洞：重点检查 [SQL注入, XSS, 敏感信息(API密钥/密码/密钥明文), 不安全的依赖引用]
2. 最佳实践：[命名规范, 错误处理, 资源释放]
3. 格式：严格按以下JSON结构输出：
{
  "has_issues": true/false,
  "issues": [
    {
      "type": "security|style|logic",
      "severity": "high|medium|low",
      "location": "文件名:行号 或 行区间",
      "description": "问题描述",
      "suggestion": "修改建议"
    }
  ],
  "summary": "一句话总结"
}

这个对比清楚地展示了：好 Prompt 和差 Prompt 的核心差异在于输出格式确定性和覆盖范围明确性。

AI辅助Prompt Review

除了人工 Review，LLM 也可以参与 Prompt 的自动化质量评审。具体做法是训练一个专门负责”Review 其他 Prompt”的 Agent，给它一个 Prompt 质量评分 rubric，让它对提交的 Prompt 批量打分并生成报告。

自动化 Review 的优势在于：速度极快，适合 CI 流程中的批量检查；一致性高，不会因审稿人疲劳而出现标准漂移；可量化，支持历史趋势跟踪。

但自动化 Review 也有局限：它可以检查格式规范性、语义完整性、指令清晰度；但对 Prompt 在真实场景下的输出质量判断，仍然需要人工抽检。换句话说，AI Review 负责”格式对不对”，人负责”质量够不够”。

一个实用的做法是双层 Review：CI 流程中先跑 AI Review 生成结构化报告，报告中标注”需要人工确认”的问题项，再由人工 Reviewer 重点关注这些高风险点。

Prompt CI/CD

💡 Key Insight

Prompt变更必须经过自动化验证，确保输出质量稳定。Prompt的CI/CD是整个AI-Native开发流程的基石。

Prompt测试金字塔

Prompt CI Pipeline

Prompt 的 CI Pipeline 与代码 CI 类似，但检查对象从语法变成了语义质量。一个完整的 Prompt CI Pipeline 包含以下四个阶段：

阶段1：Lint（语法与格式检查）

这一阶段做的是最基础的检查：Prompt 文件是否存在语法错误（如未闭合的引号、markdown 格式混乱）、是否缺少必要的元数据字段（model、temperature、description）、是否超过了推荐长度上限（通常 4096 token 为软上限）。Lint 通过后才进入测试阶段。

阶段2：Test（执行验证）

这是 CI Pipeline 的核心。用变更后的 Prompt 执行一组预设的测试用例，对比输出是否与预期一致。测试用例需要提前覆盖该 Prompt 的主要使用场景和边界条件——这与测试金字塔的结构完全对应：底部单元测试覆盖基础指令，中间集成测试覆盖多步骤推理，顶部端到端测试覆盖完整工作流。

阶段3：Validate（质量评分）

即使所有测试通过，也不能保证 Prompt 质量足够好。Validate 阶段用独立的评估 Prompt 对变更后的 Prompt 输出进行打分，维度包括：输出格式正确率、指令遵循率、幻觉率、安全风险检出率。分数低于阈值则 Pipeline 失败，需要人工确认后才能继续。

阶段4：Deploy（发布到注册表）

通过前三个阶段的 Prompt 版本，会被分配一个不可变哈希地址并注册到 Prompt 注册表。如果该 Prompt 有对应的生产环境别名（如 user-onboarding/v3/production），Deploy 阶段还需要更新别名的指向，触发下游配置变更通知。

Prompt测试示例

以下是三种典型 Prompt 测试的实现示例：

单元测试（单步 Prompt）：适用于独立的单一指令 Prompt，例如”将自然语言 SQL 查询转换为标准 SQL”。测试用例覆盖正常查询、边界输入（空字符串、特殊字符）和对抗性输入（SQL注入尝试）。

集成测试（多步 Prompt 链）：适用于需要多个 Prompt 串联的工作流，例如”代码审查”场景：第一个 Prompt 提取关键代码段，第二个 Prompt 检查安全漏洞，第三个 Prompt 生成修复建议。集成测试验证的是环节之间的数据传递是否正确，以及整体输出的质量是否满足要求。

回归测试（Prompt 编辑防护）：当一个 Prompt 被修改后，回归测试验证修改没有破坏它原本能够正确处理的历史用例。回归测试集是持续积累的，每次发现 Prompt 的边界失效案例，都应该将其加入回归测试集，防止同类问题再次出现。

Prompt部署策略

Prompt 变更的部署比代码部署更需要谨慎，因为 Prompt 变更对输出的影响不如代码变更那样可预测。以下是三种实用的部署策略：

影子模式（Shadow Mode）：新版本 Prompt 与当前生产版本并行运行，所有请求同时发送给两个版本，但只有生产版本的结果返回给用户。新版本的结果被记录但不生效，用于 A/B 质量对比。这种模式适合高风险变更，在不影响用户体验的前提下验证新版本质量。

金丝雀发布（Canary Release）：先让一小部分流量（如 5%）使用新版本 Prompt，观察错误率、用户满意度、平均响应长度等指标。如果指标正常，逐步扩大流量比例直至全量。Canary 的优势在于有明确的回滚触发条件：指标恶化即自动回滚，不需要人工判断。

特性开关（Feature Flag）：在应用代码层控制使用哪个 Prompt 版本，通过配置中心动态切换。特性开关的优势是可以快速回滚——只需改配置，不需要重新部署代码。对于有多个 Prompt 版本的团队，这是最实用的发布管理机制。

Prompt资产管理

💡 Key Insight

高质量Prompt是可复用的知识资产。组织级Prompt库是AI-Native企业的核心竞争力。

Prompt库架构

组织级 Prompt 库是 PDD 实践中最重要的基础设施之一。一个设计良好的 Prompt 库，不只是存储 Prompt 文本的仓库，而是能够支撑团队协作、版本追溯、质量度量的完整平台。

目录结构：建议按业务域（Domain）→ 功能（Function）→ 版本（Version）三层结构组织。业务域如”代码审查”、”用户引导”、”数据提取”；功能如”安全漏洞检测”、”欢迎语生成”、”结构化抽取”；版本即每个功能下的历史版本记录。这种结构让使用者可以通过目录导航快速定位所需 Prompt，而不只是依赖搜索。

元数据 schema：每个 Prompt 版本至少应包含以下元数据：唯一标识符（哈希地址）、业务域标签、功能标签、作者、创建时间、最后修改时间、当前状态（草稿/审核中/生产/废弃）、模型要求（模型名称、版本限制）、参数配置（温度、top-p、max tokens）、使用次数统计、成功率统计。这些元数据是后续度量和发现的基础。

访问控制：不同状态的 Prompt 有不同的可见性要求。生产环境使用的 Prompt 应该只有授权人员可以修改；草稿状态的 Prompt 应该在团队内可见以获取反馈；废弃的 Prompt 应该保留但标记为不可用于新项目。访问控制与版本状态机结合，确保变更流程的可控性。

Prompt发现与复用

Prompt 库的价值不只是存储，更是复用。一个被束之高阁的 Prompt 库毫无价值。以下机制可以提升 Prompt 的复用率：

标签搜索：每个 Prompt 应该有多维标签（业务域、功能、输入类型、输出类型、语言、适用模型等）。使用者通过标签组合搜索，比纯文本搜索更精准。例如搜索”代码审查 + 安全 + 中文 + gpt-4o”，可以快速定位符合条件的 Prompt。

继承模式（Base Prompt + Specialized Variant）：对于相似但有差异的场景，不要复制 Prompt，而是建立继承关系。一个”通用代码审查 Base Prompt”加上针对不同语言的 specialized variant（JavaScript 版、Python 版），Base 的改进自动惠及所有 variant，而 variant 的特殊调整不会污染 Base。这种模式与面向对象编程的类继承思想一致。

成功率和复用率度量：在元数据中记录每个 Prompt 的使用次数和成功率，定期生成”高价值 Prompt”排行榜。成功率低于阈值的 Prompt 应该被标记为待优化；复用率高的 Prompt 说明具有通用性，值得投入优化精力。

结尾

PDD（Prompt-Driven Development）重新定义了软件开发的起点：当 Prompt 成为第一等制品，整个开发流程的重心从”实现”前移到”意图表达”。这不只是工具的变化，而是权力结构的变化——写代码的人从执行者变成了设计者，AI 从工具变成了执行者。

🎯 Takeaway

PDD（Prompt-Driven Development）不是取代软件开发，而是重塑软件开发的起点。

💡 Key Insight

PDD（Prompt-Driven Development）不是取代软件开发，而是重塑软件开发的起点——从”实现意图”前移到”表达意图”，这是整个开发流程权力结构的根本转变。

当Prompt成为第一等制品，我们获得了：

• 可追溯的决策历史（Prompt版本）
• 可复用的知识资产（Prompt库）
• 可自动化的质量保证（Prompt CI/CD）
• 可规模化的AI协作（标准化流程）

这是AI-Native软件工程的基础设施。

“代码是意图的实现，Prompt是意图的表达。管理好Prompt，就管理好了软件开发的源头。”

PDD成熟度模型

你的组织在哪个级别？

📚 延伸阅读

经典案例

• LangChain的Prompt管理实践：如何管理数千个生产级Prompt
• OpenAI的Prompt工程指南：企业级Prompt设计原则

本系列相关

• TDD的死亡与重生 (第1篇)
• SDD 2.0：用户故事的Prompt工程化 (第2篇)
• CDD：上下文工程即核心竞争力 (第6篇)

学术理论

• 《Prompt Engineering Guide》(DAIR.AI): Prompt工程系统方法
• 《Software Engineering at Google》: 大规模软件工程实践
• 《The Mythical Man-Month》(Fred Brooks): 软件工程经典，理解工程化的本质

深度阅读时间：约 12 分钟