AI时代PRD长什么样?——从文档到Executable Specification

「2025年,产品经理Alice的PRD被AI直接编译成了可运行的代码。不是生成代码框架,是真正的业务逻辑、数据库Schema、API接口、前端页面。她的PRD不再是’给工程师看的文档’,是’产品的源代码’。这就是Executable Specification的时代。」


一、传统PRD的困境

PRD是什么?

Product Requirements Document(产品需求文档),产品经理的核心产出,用来描述:

  • 产品要解决什么问题
  • 目标用户是谁
  • 功能需求是什么
  • 业务流程如何
  • 验收标准怎样

传统PRD的典型结构

PRD-用户下单功能-v1.2.docx

1. 背景与目标
   - 提升移动端下单转化率
   - 目标:从15%提升到25%

2. 用户故事
   - 作为用户,我希望一键下单,以便快速完成购买

3. 功能需求
   3.1 商品选择
       - 用户可以从购物车选择商品
       - 支持批量选择
   
   3.2 地址填写
       - 自动填充默认地址
       - 支持新增地址
   
   3.3 支付方式
       - 支持微信支付、支付宝、信用卡
   
   3.4 订单确认
       - 显示订单摘要
       - 显示预计送达时间

4. 业务流程
   [流程图]

5. 验收标准
   - 下单流程3步完成
   - 页面加载时间<2秒
   - 支付成功率>99%

6. 界面原型
   [Figma链接]

传统PRD的困境

困境1:文档与实现的鸿沟

产品经理写PRD(1周)
    ↓
工程师阅读PRD(2天)
    ↓
工程师理解有误,需要澄清(1天)
    ↓
工程师开始开发(2周)
    ↓
开发完成,产品经理验收(2天)
    ↓
发现与预期不符,修改(1周)

总周期:5-6周

问题:自然语言的歧义性导致理解偏差。

困境2:PRD的维护成本

场景:需求变更

传统流程:
1. 产品经理修改PRD
2. 通知相关工程师
3. 工程师修改代码
4. 测试人员修改测试用例
5. 文档人员更新文档

问题:
- PRD修改了,代码改了,测试改了,文档改了
- 但它们之间没有自动关联
- 经常出现"改了A忘改B"

困境3:PRD的不可执行性

PRD描述:"用户下单后,系统应该发送确认邮件"

问题:
- 邮件什么时候发?(同步?异步?)
- 邮件发送失败怎么办?
- 邮件内容模板在哪里?
- 如何测试这个功能?

PRD无法回答这些问题,需要在开发阶段补充。

困境4:AI时代的加速困境

AI可以10秒生成代码
    ↓
但产品经理需要1周写PRD
    ↓
PRD成为瓶颈

AI加速了代码生成,但需求定义的速度没有跟上。


二、Executable Specification:新范式

什么是Executable Specification?

Executable Specification(可执行规格说明)

一种结构化的、机器可读的、可直接编译为可运行代码的产品需求描述。

不是”给工程师看的文档”,是”产品的源代码”。

Executable PRD vs 传统PRD

维度 传统PRD Executable PRD
格式 自然语言文档 结构化代码/配置
读者 人类工程师 人类 + AI/机器
歧义性 低(结构化)
可执行性
维护成本 高(多份文档) 低(单一真相源)
与代码关系 分离 一体

Executable PRD的核心理念

核心理念1:需求即代码

传统:
PRD → 工程师理解 → 写代码

Executable:
PRD(可执行格式)→ AI编译 → 可运行代码

核心理念2:单一真相源

传统:
PRD.docx + 代码 + 测试 + 文档 = 多个版本,容易不一致

Executable:
PRD.spec = 需求 + 生成代码 + 生成测试 + 生成文档

核心理念3:意图显式化

传统:
"用户下单后发送确认邮件"
(隐含了很多假设)

Executable:
spec:
  trigger: order.completed
  action: send_email
  template: order_confirmation
  async: true
  retry: 3
  fallback: log_error
(所有细节都显式定义)

三、Executable PRD的技术实现

格式:结构化需求语言

示例:用户下单功能

# order_feature.spec

spec_id: ORDER-001
name: 用户下单功能
description: 移动端一键下单,提升转化率

business_goals:
  - metric: conversion_rate
    current: 15%
    target: 25%
    timeline: Q2-2025

user_stories:
  - id: US-001
    role: 注册用户
    action: 一键下单
    benefit: 快速完成购买
    acceptance_criteria:
      - steps_count: 3
      - max_time: 60s
      - success_rate: >99%

entities:
  Order:
    fields:
      - name: id
        type: uuid
        required: true
      - name: user_id
        type: reference
        ref: User
        required: true
      - name: items
        type: array
        item_type: OrderItem
        required: true
      - name: total_amount
        type: decimal
        precision: 10
        scale: 2
        required: true
      - name: status
        type: enum
        values: [pending, paid, shipped, delivered, cancelled]
        default: pending
      - name: created_at
        type: timestamp
        auto: true
    
    business_rules:
      - rule_id: BR-001
        name: 库存检查
        condition: order.status == 'pending'
        action: check_inventory
        error_message: "商品库存不足"
      
      - rule_id: BR-002
        name: 价格计算
        condition: order.items.changed
        action: recalculate_total
      
      - rule_id: BR-003
        name: VIP折扣
        condition: user.tier == 'VIP' AND order.total >= 1000
        action: apply_discount(0.2)
        max_discount: 500

workflows:
  - id: WF-001
    name: 标准下单流程
    steps:
      - step: 1
        name: 选择商品
        ui: ProductSelectionScreen
        validations:
          - inventory > 0
          - price > 0
      
      - step: 2
        name: 确认地址
        ui: AddressConfirmationScreen
        data: user.default_address
        fallback: AddressInputScreen
      
      - step: 3
        name: 选择支付
        ui: PaymentMethodScreen
        options: [wechat, alipay, credit_card]
      
      - step: 4
        name: 订单确认
        ui: OrderSummaryScreen
        actions:
          - confirm: submit_order
          - cancel: abort
    
    post_actions:
      - action: send_confirmation_email
        async: true
        template: order_confirmation
        delay: 0
      
      - action: notify_inventory_system
        async: true
        event: order.created

apis:
  - path: /api/v1/orders
    method: POST
    description: 创建订单
    request:
      body: OrderCreateRequest
    response:
      success: Order
      error: OrderError
    rate_limit: 100/minute

ui:
  screens:
    - id: ProductSelectionScreen
      components:
        - type: ProductList
          data: cart.items
          actions:
            - select: add_to_order
        - type: Button
          text: "下一步"
          action: next_step
    
    - id: OrderSummaryScreen
      components:
        - type: OrderDetail
          data: order
        - type: PriceBreakdown
          items:
            - subtotal
            - discount
            - shipping
            - total
        - type: ButtonGroup
          buttons:
            - text: "确认下单"
              type: primary
              action: submit_order
            - text: "取消"
              type: secondary
              action: cancel

tests:
  - id: TEST-001
    name: 正常下单流程
    steps:
      - action: select_product
        params: { product_id: "P001", quantity: 2 }
      - action: confirm_address
      - action: select_payment
        params: { method: "wechat" }
      - action: submit_order
    expected:
      - order.status == 'pending'
      - email.sent == true
      - inventory.updated == true
  
  - id: TEST-002
    name: 库存不足场景
    steps:
      - action: select_product
        params: { product_id: "P002", quantity: 100 }
    expected:
      - error.code == 'INSUFFICIENT_INVENTORY'
      - error.message == '商品库存不足'

constraints:
  performance:
    - metric: page_load_time
      threshold: 2s
      priority: high
    - metric: api_response_time
      threshold: 500ms
      percentile: 95
  
  security:
    - requirement: input_validation
      scope: all_user_inputs
    - requirement: rate_limiting
      scope: order_creation

编译:从PRD到可运行系统

编译流程

order_feature.spec
    ↓
Spec Compiler
    ↓
├─ Database Schema (SQL)
├─ API Definition (OpenAPI)
├─ Business Logic (Python/Java)
├─ UI Components (React/Vue)
├─ Test Cases (Jest/PyTest)
└─ Documentation (Markdown)

编译示例

# 输入:Entity定义
entities:
  Order:
    fields:
      - name: id
        type: uuid
      - name: total_amount
        type: decimal
        precision: 10
        scale: 2
-- 输出:数据库Schema
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    total_amount DECIMAL(10, 2) NOT NULL,
    -- ...
);
# 输出:业务模型
class Order(BaseModel):
    id: UUID
    total_amount: Decimal = Field(max_digits=10, decimal_places=2)
    # ...
// 输出:TypeScript类型
interface Order {
    id: string;
    total_amount: number;
}

可执行性:PRD即测试

tests:
  - id: TEST-001
    name: 正常下单流程
    steps:
      - action: select_product
        params: { product_id: "P001", quantity: 2 }
      - action: confirm_address
      - action: select_payment
        params: { method: "wechat" }
      - action: submit_order
    expected:
      - order.status == 'pending'
      - email.sent == true
# 生成的测试代码
class TestOrderWorkflow(unittest.TestCase):
    def test_normal_order_flow(self):
        # Step 1: 选择商品
        self.select_product(product_id="P001", quantity=2)
        
        # Step 2: 确认地址
        self.confirm_address()
        
        # Step 3: 选择支付
        self.select_payment(method="wechat")
        
        # Step 4: 提交订单
        order = self.submit_order()
        
        # 验证
        self.assertEqual(order.status, 'pending')
        self.assertTrue(email_service.sent)

四、Executable PRD的工作流程

新范式的工作流程

产品经理编写Executable PRD(结构化规格)
    ↓
AI编译器生成代码、测试、文档(分钟级)
    ↓
产品经理验证生成的系统(交互式)
    ↓
反馈循环,调整PRD(快速迭代)
    ↓
工程师审查和优化(关注架构和质量)
    ↓
部署上线

周期:1-2天(vs 传统5-6周)

各角色的转变

产品经理

  • :写文档给工程师看
  • :写可执行的规格说明
  • 技能:结构化思维、业务规则建模

工程师

  • :根据PRD写代码
  • :审查AI生成的代码,关注架构和边界情况
  • 技能:架构设计、代码审查、性能优化

AI的角色

  • 编译器:将Executable PRD编译为代码
  • 验证器:自动测试和验证
  • 助手:解释规格、建议改进

五、实战:传统PRD vs Executable PRD

场景:优惠券功能

传统PRD

优惠券功能PRD

背景:提升用户复购率

需求:
1. 用户可以领取优惠券
2. 用户可以在下单时使用优惠券
3. 优惠券有使用条件(满减、品类限制等)
4. 优惠券有过期时间

业务流程:
[流程图]

验收标准:
- 优惠券正确计算折扣
- 过期优惠券不能使用
- 一个订单只能使用一张优惠券

问题

  • “使用条件”具体是什么?
  • 满减规则如何计算?
  • 品类限制如何实现?
  • 并发使用如何处理?

需要多次沟通才能明确。

Executable PRD

spec_id: COUPON-001
name: 优惠券系统

entities:
  Coupon:
    fields:
      - name: code
        type: string
        unique: true
      - name: type
        type: enum
        values: [percentage, fixed_amount]
      - name: value
        type: decimal
        validation: "> 0"
      - name: conditions
        type: json
        schema:
          min_order_amount: decimal?
          applicable_categories: array?
          applicable_products: array?
          user_tiers: array?
      - name: valid_from
        type: timestamp
      - name: valid_until
        type: timestamp
      - name: usage_limit
        type: integer
        default: 1
    
    business_rules:
      - rule_id: COUPON-R001
        name: 有效期检查
        condition: now() < coupon.valid_until
        error_message: "优惠券已过期"
      
      - rule_id: COUPON-R002
        name: 使用次数检查
        condition: coupon.usage_count < coupon.usage_limit
        error_message: "优惠券使用次数已达上限"
      
      - rule_id: COUPON-R003
        name: 订单金额门槛
        condition: |
          coupon.conditions.min_order_amount IS NULL 
          OR order.total >= coupon.conditions.min_order_amount
        error_message: "订单金额未达到优惠券使用门槛"
      
      - rule_id: COUPON-R004
        name: 品类限制
        condition: |
          coupon.conditions.applicable_categories IS NULL 
          OR order.items.all(item.category IN coupon.conditions.applicable_categories)
        error_message: "订单商品不符合优惠券适用范围"
      
      - rule_id: COUPON-R005
        name: 折扣计算
        action: |
          if coupon.type == 'percentage':
            discount = order.total * coupon.value
          else:
            discount = coupon.value
          return min(discount, order.total)  # 折扣不超过订单金额
      
      - rule_id: COUPON-R006
        name: 单订单限制
        condition: order.coupons.count == 0
        error_message: "一个订单只能使用一张优惠券"

workflows:
  - id: CLAIM-COUPON
    name: 领取优惠券
    steps:
      - validate_user_eligibility
      - check_coupon_availability
      - create_user_coupon_record
    
  - id: APPLY-COUPON
    name: 使用优惠券
    steps:
      - validate_coupon_validity
      - check_all_conditions
      - calculate_discount
      - apply_to_order
      - increment_usage_count

tests:
  - name: 满减优惠券正常使用
    given:
      coupon: { type: fixed_amount, value: 50, conditions: { min_order_amount: 200 } }
      order: { total: 250 }
    when: apply_coupon
    then:
      discount: 50
      final_amount: 200
  
  - name: 过期优惠券使用失败
    given:
      coupon: { valid_until: "2025-01-01" }
      current_date: "2025-02-01"
    when: apply_coupon
    then:
      error: "优惠券已过期"
  
  - name: 品类限制检查
    given:
      coupon: { conditions: { applicable_categories: ["electronics"] } }
      order: { items: [{ category: "clothing" }] }
    when: apply_coupon
    then:
      error: "订单商品不符合优惠券适用范围"

优势

  • 所有业务规则显式定义
  • 条件、计算逻辑精确
  • 自动生成测试
  • 可直接编译运行

六、Executable PRD的挑战与应对

挑战1:学习曲线

问题:产品经理需要学习结构化规格语言

应对

  • 可视化编辑器(类似Figma但更结构化)
  • AI辅助编写(自然语言→结构化规格)
  • 培训渐进式迁移

挑战2:复杂度管理

问题:复杂系统的规格可能很长

应对

  • 模块化(像代码一样import/reuse)
  • 分层(高层概览→低层细节)
  • 版本控制(Git管理规格变更)

挑战3:与遗留系统集成

问题:已有系统不是Executable PRD生成的

应对

  • 逆向工程(从代码生成规格)
  • 渐进式迁移
  • 混合模式(部分用Executable,部分传统)

挑战4:AI编译器的成熟度

问题:AI生成的代码质量不稳定

应对

  • 人类审查环节(必须)
  • 自动化测试(必须)
  • 逐步提升AI能力

七、写在最后:从文档到源代码的范式转移

软件工程的历史脉络

1970s: 瀑布模型
       需求文档 → 设计文档 → 代码 → 测试
       
2000s: 敏捷开发
       用户故事 → 迭代开发 → 持续交付
       
2020s: Executable Specification
       可执行规格 ←→ 编译 ←→ 可运行系统

每一代范式都缩短了”想法”到”实现”的距离。

Executable PRD的意义

不是:让产品经理取代工程师 而是:让产品经理和工程师在同一语言上协作

不是:完全自动化开发 而是:自动化重复性工作,人类专注于创造性工作

不是:消灭文档 而是:让文档变得可执行、可验证、可维护

未来展望

短期(1-2年)

  • Executable PRD工具成熟
  • 早期采用者(创业公司、创新团队)
  • 与现有开发流程混合使用

中期(3-5年)

  • 行业标准形成
  • 主流企业采用
  • 产品经理技能转型

长期(5-10年)

  • “写PRD”成为编程的一种形式
  • 产品经理 = 产品架构师
  • 开发效率10倍提升

给产品经理的建议

1. 开始学习结构化思维

  • 不是”描述功能”,是”定义规格”
  • 学习业务规则建模
  • 学习状态机、工作流

2. 拥抱Executable工具

  • 尝试现有的低代码/无代码平台
  • 学习结构化规格语言
  • 与工程师协作定义规格

3. 成为产品架构师

  • 不仅关注用户体验,关注系统架构
  • 不仅关注功能,关注业务规则
  • 不仅关注现在,关注可扩展性

📚 延伸阅读

相关概念

  • BDD (Behavior-Driven Development): 行为驱动开发,Executable Spec的思想前身
  • DSL (Domain-Specific Language): 领域特定语言
  • Model-Driven Development: 模型驱动开发
  • Low-Code/No-Code: 低代码/无代码平台

技术基础

  • YAML/JSON Schema: 结构化数据定义
  • OpenAPI Specification: API规格标准
  • GraphQL Schema: 数据模型定义
  • Protocol Buffers: 结构化数据序列化

工具实践

  • Figma Dev Mode: 设计到开发的桥梁
  • Storybook: 组件驱动的UI开发
  • Swagger/OpenAPI: API规格和文档
  • JSON Schema: 数据验证和文档

Published on 2026-03-09
深度阅读时间:约 18 分钟

AI-Native软件工程系列 #04 —— 从PRD到Executable Specification的需求工程革命