PRD的结构化转型：从Word到可执行的语义规格说明

TL;DR

本文核心观点：

AI时代的瓶颈 — 需求表达质量直接决定AI产出质量，模糊PRD导致反复返工，结构化规格让首次通过率从30%提升至80%+

CCC模型 — Context（上下文）、Constraints（约束）、Criteria（验收标准）三支柱，将隐含假设显式化，消除自然语言歧义

可执行语义规格 — 机器可读 + 语义明确 + 可验证 + 可追踪，从”叙述需求”进化为”定义规格”的范式转移

渐进迁移路径 — 模板化 → 验证化 → 自动化 → 智能化，四阶段渐进落地，无需大爆炸式重构

CCC模型：Context-Constraints-Criteria

问题的本质：Garbage In, Garbage Out

让我们从一个真实的场景开始。

某互联网公司的产品经理提交了一个PRD需求：

“用户可以在App上查看自己的订单历史。”

这个描述看起来清晰，对吧？但当AI生成代码时，它面临无数未明确的决策点：

订单历史包含多久的记录？（最近30天？全部？可配置？）
排序规则是什么？（时间倒序？金额排序？可切换？）
支持分页吗？每页多少条？
异常场景如何处理？（空状态？网络错误？）
权限控制？（能看到别人的订单吗？管理员视角？）
数据实时性？（允许缓存吗？缓存多久？）

产品经理的脑海中可能有默认假设，但AI不知道。结果是：AI生成了一套代码，产品经理说”不是我要的”，工程师说”PRD没说清楚”，然后进入需求澄清-重新生成-再次返工的循环。

这就是Garbage In, Garbage Out在AI时代的具体表现。

💡 Key Insight

模糊PRD × 强大AI = 放大错误；精确规格 × 强大AI = 加速器。

传统PRD的系统性缺陷

传统PRD（基于Word、Confluence、飞书文档）在AI时代暴露出结构性缺陷：

1. 自然语言的歧义性 自然语言天生模糊。”快速加载”是多快？”用户友好”是什么标准？人类可以通过上下文和默契理解，但AI缺乏这种共同背景（Shared Context）。

2. 静态文档的局限 PRD写完后很少更新，但需求在演进。代码变了，测试变了，但PRD还是三个月前的版本。AI基于过时的PRD生成代码，结果必然偏差。

3. 缺乏可验证性 写完PRD后，怎么知道它”对”还是”错”？传统PRD没有可执行性——你不能运行它来验证是否符合预期。

4. 追踪性断裂 需求 → 设计 → 代码 → 测试，这条链路在传统PRD中是隐式的、脆弱的。当AI生成代码时，无法自动建立与原始需求的关联，导致可追溯性丢失。

5. 人机协作的摩擦 产品经理写PRD，工程师读PRD，AI基于PRD生成代码——三个人（产品、工程师、AI）对同一文档的理解可能完全不同。

解决方案：可执行的语义规格说明

解决这些问题的关键，是将PRD从叙述性文档转变为结构化规格（Structured Specification），最终进化为可执行的语义规格说明（Executable Semantic Specification）。

什么是可执行的语义规格说明？

简单来说，它是一种：

机器可读（Machine-readable）：AI能直接解析，不需要NLP猜测
语义明确（Semantically precise）：每个概念都有严格定义，没有歧义
可验证（Verifiable）：可以自动检查是否符合预期
可追踪（Traceable）：需求、代码、测试之间自动关联
版本化（Versioned）：像代码一样管理变更

这不是科幻。在硬件设计、协议规范、安全关键系统领域，形式化规格（Formal Specification）已经使用了几十年。AI时代的产品开发，需要借鉴这些成熟实践。

结构化PRD的四个支柱

要实现这种转型，需要建立四个支柱：

支柱一：Context（上下文）

传统PRD假设读者（工程师、AI）理解业务背景。结构化PRD显式声明所有上下文：

这个上下文块回答了一个关键问题：我们在什么环境下解决这个问题？

结构化PRD中的上下文块以机器可读的结构化格式显式声明所有关键背景，典型字段包括：业务场景（用户在什么情况下触发这个功能）、目标用户（谁会用、权限级别如何）、数据边界（涉及哪些数据范围、数据量级多大）、系统前提（依赖哪些上游服务或数据源）。以订单历史功能为例，上下文块需要声明：用户类型（普通消费者/管理员）、查询范围（近12个月/全部历史/可配置）、数据来源（订单服务数据库副本，延迟<500ms）、异常分流（空结果、网络错误、数据过期各自返回什么）。这些信息在传统PRD中散落在产品经理的脑海里或零星段落中，AI需要靠”猜”来补全——结构化上下文把这种隐性知识显性化，让AI无需猜测就能准确理解业务边界。

支柱二：Constraints（约束）

约束定义了解决方案的边界。它们不是功能，而是限制条件：

约束让AI知道：什么能做，什么不能做。这比模糊的”性能要好”精确一万倍。

约束分为两类：功能性约束（什么行为是允许的）和非功能性约束（什么条件下必须满足什么）。前者划定行为边界，后者定义质量底线。具体到订单历史功能，功能性约束可能包括：不得展示其他用户的订单（权限边界）、不得返回未支付订单（数据过滤规则）。非功能性约束则更具体：列表页加载时间 P99 < 200ms（精确的延迟约束，而非”快速”）、数据缓存有效期 ≤ 5 分钟（而非”允许缓存”）、支持 QPS 峰值 10000（而非”能承受高并发”）。安全约束如”所有接口必须登录态验证”、”敏感字段脱敏展示”也是常见的非功能性约束。约束的核心价值在于：把产品经理对”不能做的事”的理解，从隐式假设变为显式声明——当AI清楚边界在哪，它生成的结果就不会越界，也不会漏掉必须的处理逻辑。

支柱三：Acceptance Criteria（验收标准）

验收标准定义了完成的定义（Definition of Done）。在结构化PRD中，验收标准是可测试的（Testable）：

这是Gherkin语法，但不仅限于此。关键是：验收标准可以被自动执行和验证。

以订单历史功能为例，验收标准用 Given-When-Then 格式写成 Gherkin 场景：

Scenario: 用户查看订单历史
  Given 用户"小李"已登录
    And 小李的历史订单包含3笔已完成的订单
  When 小李进入"我的订单"页面
  Then 系统返回3条订单记录
    And 每条记录包含订单号、商品名称、金额、状态
    And 订单按时间倒序排列
    And 页面加载时间 ≤ 200ms

每个 Given/When/Then 子句对应一个可自动化的断言，可以直接转化为测试用例代码。这意味着：当产品经理写完验收标准，测试工程师的工作有相当一部分已经被自动化了——CI流水线可以在每次代码提交后自动运行这些用例，验证实现是否符合规格。验收标准不再是”我认为对不对”的主观判断，而是”能否通过自动化测试”的客观事实。

支柱四：Traceability（可追溯性）

每个需求都有唯一标识符，与代码、测试、部署自动关联：

当AI生成代码时，自动注入这些追踪标识。每个需求分配唯一标识符（如 REQ-ORD-HIST-001），这个ID贯穿PRD、代码、测试、部署全链路：在代码中以注释或变量前缀形式存在（// REQ-ORD-HIST-001），在测试用例中以描述标签存在（@REQ-ORD-HIST-001），在CI报告中作为关联键。当线上出现bug或测试失败时，工程师可以直接追溯到原始PRD条款，而不需要在文字描述中”找类似需求”。可追溯性还支持变更影响分析：当产品经理修改某条需求时，CI系统可以自动识别受影响的代码模块和测试用例，生成变更影响报告。这种端到端的追踪链路，把传统PRD中隐式的”需求→实现→测试”手工对应关系，变成了系统自动维护的显式关联。

CCC模型：Context-Constraints-Criteria

将上述四个支柱简化，就是CCC模型（Triple-C Model）：

CCC模型：Context-Constraints-Criteria

CCC模型是一个思维框架，不强制特定格式。你可以用YAML、JSON、TOML、甚至纯文本（带结构化标记）来实现。关键是思考方式的转变：从”描述功能”到”定义规格”。

💡 Key Insight

CCC模型是思考框架，不是固定格式——YAML、JSON、TOML都可以承载同样的结构化思维。

PRD as Code：工具链实践

将PRD视为代码（PRD as Code），需要相应的工具链支持。

版本控制

像管理代码一样管理PRD：

好处：

版本历史可追溯
分支管理支持并行开发
Code Review机制确保质量
CI/CD可以自动验证PRD完整性

验证流水线

在CI中自动验证PRD：

完整性检查：JSON Schema验证必填字段（context/constraints/criteria）
一致性校验：context中的字段在criteria中被引用，constraints不相互矛盾
链接验证：检查与其他PRD文档的交叉引用是否有效
格式规范：标题层级、列表符号、代码块语法检查

示例GitHub Actions配置：

- name: Validate PRD Structure
  uses: prd-lint/action@v1
  with:
    schema: ./schemas/ccc-schema.json
    fail-on-error: true

IDE集成

在产品经理的IDE中提供：

自动补全：输入context.user.自动提示可用字段
实时验证：红色波浪线标记缺失的必填项
模板快速插入：prd-template-order生成订单功能的标准结构
AI辅助编写：基于已有PRD，AI建议类似的上下文或约束

对比：传统PRD vs 结构化PRD

让我们用同一个功能对比两种写法。

传统PRD示例：飞书文档节选

订单历史功能

用户可以在App上查看自己的订单历史。订单按时间倒序排列，显示订单号、商品名称、金额、状态。

注：具体UI参考设计稿。

结构化PRD示例：CCC模型写法

下方表格直观呈现了两种方式的差异：

效果对比：首次通过率与返工次数

维度	传统PRD	结构化PRD
首次通过率	30-40%	80-90%
返工次数	3-5次	0-1次
需求澄清时间	2-4小时	几乎为零
测试覆盖率	依赖工程师经验	自动生成完整测试
可追溯性	手动维护，易断裂	自动关联，全程追踪

实施路径：如何迁移现有PRD流程

对于已经使用传统PRD的组织，迁移不需要大爆炸式重构，可以渐进式进行。

第一步：模板化（1-2个月）

设计CCC模型的Markdown模板
要求新PRD使用模板编写
旧PRD保持不变
目标：团队熟悉结构

第二步：验证化（2-3个月）

引入PRD验证工具
CI中增加PRD检查流水线
关键PRD（P0需求）必须结构化
目标：确保质量

第三步：自动化（3-6个月）

验收标准自动生成测试用例
PRD与代码、测试自动关联
AI基于PRD直接生成代码框架
目标：提升效率

第四步：智能化（6-12个月）

AI辅助编写PRD（基于对话生成CCC结构）
需求变更的涟漪效应自动分析
PRD与产品数据分析自动关联
目标：数据驱动迭代

挑战与局限

学习成本：产品经理的新思维方式

产品经理需要学习新的写作方式，初期会有阻力。解决方案：

提供IDE插件降低写作门槛
AI辅助生成：产品经理口述需求，AI转换为CCC结构
从关键需求开始，逐步推广

避免过度工程：不是所有需求都需要完整CCC

不是所有需求都需要完整CCC结构。建议：

P0/P1需求：完整CCC
P2需求：简化版（仅Context + Criteria）
P3需求/技术债务：传统方式即可

工具生态：当前的选型与探索

目前成熟的PRD as Code工具还不多。可以选择：

自研：基于OpenAPI、Gherkin等现有标准扩展
开源：关注领域如Cucumber、Spectacle等
SaaS：一些新兴产品如Cycle、Avion正在探索

总结：从叙述到定义

PRD的结构化转型，本质是从叙述需求（Narrating Requirements）到定义规格（Defining Specifications）的范式转移。

💡 Key Insight

从”叙述需求”到”定义规格”的转变，是AI时代产品开发的核心范式转移。

在AI生成代码的时代，需求表达的质量直接决定了产出的质量。一个模糊的PRD，乘以AI的强大生成能力，只会放大错误；而一个精确的、可执行的语义规格说明，才能让AI真正成为加速器而非放大器。

CCC模型（Context-Constraints-Criteria）提供了一个实用的思维框架，帮助团队：

显式化隐含的假设
消除自然语言的歧义
建立需求到代码的自动桥梁
实现真正的端到端可追溯

这不是关于工具的选择，而是关于思维方式的升级。当产品经理从”写文档”转变为”定义规格”，当AI从”猜测意图”转变为”执行规格”，我们才能真正进入AI-Native的开发时代。

结尾

深度阅读时间：约 12 分钟