Claude Code：产品经理的“原型神器“——20分钟将PRD变成可运行Demo

Anthropic推出的AI编程代理Claude Code让产品经理无需编程背景，即可在20分钟内将Markdown格式的PRD转化为可运行原型。通过自然语言描述需求，PM能快速验证想法、探索代码库、分析数据并自动化文档。文章详解了安装配置流程、6大实战用例（如PRD转原型、代码库探索等）及其局限性，展示了AI时代PM的全新工作流。借助Claude Code，PM不仅能定义产品方向，还能直接参与原

携梦问道

1025人浏览 · 2026-02-13 15:48:56

携梦问道 · 2026-02-13 15:48:56 发布

摘要：作为一名产品经理，你是否曾花费数周等待开发排期，只为验证一个简单的产品想法？本文将介绍 Anthropic 推出的 AI 编程代理 Claude Code，它能让你在 20 分钟内将 Markdown 格式的 PRD 转化为可运行的原型。无需深厚的编程背景，只需自然语言描述，你就能快速验证产品想法、探索代码库、分析数据、自动化文档。文章涵盖安装配置、6大实战用例、局限性分析，以及如何通过 Builder.io 实现团队协作。让我们一起探索 AI 时代产品经理的全新工作流！

一、真实场景：20分钟出原型

产品经理 Dennis Yang 的工作方式：

用 Markdown 写好 PRD
打开终端，输入 claude
20 分钟后，PRD 变成了一个正在运行的原型
屏幕录制发到 Slack，团队基于"真实可用的东西"开始讨论改进

信号很明确： 能用朴素自然语言描述需求，并把它变成可工作软件的产品经理，将拥有更强的竞争优势。

二、Claude Code 是什么？为什么 PM 应该关注？

Claude Code 是 Anthropic 推出的 AI 编程代理，直接运行在你的终端中，能够：

能力	说明
📁 文件操作	读取和写入文件
⚡ 命令执行	直接执行终端命令
🔀 Git 集成	直接创建 git commits
📝 多文件变更	在代码库内生成/修改多文件
🤖 自然语言转代码	把需求描述变成工作原型
📊 数据分析	分析 CSV 等数据文件
📄 文档生成	自动生成各类文档
🔌 MCP 集成	连接 Linear、Jira、Slack 等工具

💡 产品经理的优势转变：PM 一直擅长 “做什么（what）” 和 “为什么（why）”，现在有了 AI 编程工具，你也可以部分拥有 “怎么做（how）”。

三、快速安装与配置

3.1 安装命令

Mac / Linux：

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell：

irm https://claude.ai/install.ps1 | iex

3.2 费用说明

Claude Pro：$20/月（适合大多数 PM 场景）
Max 计划：$100/月起（适合重度使用）

3.3 首次使用

cd your-project
claude

3.4 创建 CLAUDE.md（项目简报）

在项目根目录创建 CLAUDE.md 文件，为 AI 提供持久上下文：

Product Context:
- E-commerce platform, B2B SaaS, 50K monthly active users
- Key customer segments: enterprise buyers, small business owners
- Tech stack: Next.js, PostgreSQL, Stripe for payments

3.5 两种关键模式

模式	快捷键	用途
Plan Mode	Shift + Tab	只读分析，不修改代码，适合探索陌生代码库
Default Mode	Shift + Tab	可读可写可执行，准备构建时使用

3.6 上下文管理技巧

/clear    # 清空上下文（切换任务时使用）
/compact  # 压缩长会话摘要

📌 建议：保持上下文窗口占用在 60% 以下，能获得更稳定的输出质量。

四、PM 必学的 6 大实战用例（含详细案例）

🔥 用例 1：PRD → Prototype（PRD 到原型流水线）

实战案例：电商平台的"限时秒杀"功能

假设你是一名电商产品经理，需要快速验证一个新的"限时秒杀"功能：

Step 1：编写 PRD（Markdown 格式）

# 限时秒杀功能 PRD

## 功能概述
在首页增加一个限时秒杀模块，展示当前正在进行的秒杀商品。

## 核心需求
1. 倒计时组件：显示距离秒杀结束的剩余时间（时:分:秒）
2. 商品卡片：展示商品图片、名称、原价、秒杀价、已售进度条
3. 抢购按钮：点击后跳转下单页，库存不足时置灰
4. 响应式：适配移动端和桌面端

## 交互细节
- 倒计时每秒刷新，归零时自动切换为"已结束"状态
- 进度条根据 sold / total 计算百分比
- 鼠标悬停商品卡片时有轻微放大效果

## 数据格式
{
  "productName": "iPhone 15 Pro",
  "originalPrice": 8999,
  "seckillPrice": 7999,
  "stock": 100,
  "sold": 67,
  "endTime": "2026-02-14T20:00:00Z"
}

Step 2：让 Claude Code 生成原型

claude

Prompt：

基于我写的 PRD（docs/seckill-prd.md），创建一个可运行的 React 原型。使用 mock 数据展示 3 个秒杀商品，样式使用 Tailwind CSS，倒计时需要真实运行。

Step 3：Claude Code 的执行过程

读取 PRD 文件，理解需求
创建 src/components/SeckillModule.jsx 组件
实现倒计时逻辑（使用 useEffect + setInterval）
创建 src/data/mockSeckillData.js 模拟数据
在 src/App.jsx 中引入并展示
运行 npm start 启动开发服务器

Step 4：20 分钟后，你看到的效果

✅ 首页展示了 3 个秒杀商品卡片
✅ 倒计时实时刷新（时:分:秒）
✅ 进度条显示已售比例（如 67%）
✅ 悬停时有放大动画效果
✅ 手机端和电脑端都能正常显示

Step 5：分享与验证

录屏发到 Slack，团队成员可以直接看到交互效果，提出改进建议：

“进度条颜色可以从蓝色改为红色，更有紧迫感”
“倒计时结束后，建议自动刷新展示下一场秒杀”

💡 价值点：原本需要排期 1-2 周的前端开发，现在 20 分钟就能看到可交互的原型，大大提高了决策效率。

🔍 用例 2：代码库探索（Codebase Exploration）

实战案例：新入职 PM 快速理解订单系统

假设你刚入职一家电商公司，需要快速了解订单系统的核心逻辑：

场景 1：理解订单状态流转

claude
# 切换到 Plan Mode（Shift + Tab）

Prompt：

我是新入职的产品经理，请帮我理解订单系统的状态流转。从用户下单开始，到订单完成或取消，每个状态变化涉及哪些关键代码？请列出主要的状态值和对应的业务逻辑文件。

Claude Code 的回答示例：

订单状态流转分析：

1. 状态定义（src/constants/orderStatus.js）
   - PENDING_PAYMENT: 待支付（创建订单后初始状态）
   - PAID: 已支付（支付回调成功后）
   - PROCESSING: 处理中（仓库开始拣货）
   - SHIPPED: 已发货（物流单号回传）
   - DELIVERED: 已送达（物流签收）
   - COMPLETED: 已完成（用户确认收货或7天自动完成）
   - CANCELLED: 已取消（用户取消或超时未支付）

2. 关键状态转换逻辑：
   - PENDING_PAYMENT → PAID
     * 触发：src/services/paymentCallback.js 第 45-78 行
     * 动作：扣减库存、生成支付记录、发送确认短信

   - PAID → PROCESSING
     * 触发：src/workers/orderProcessor.js（定时任务）
     * 动作：分配仓库、生成拣货单

   - PROCESSING → SHIPPED
     * 触发：src/services/logisticsService.js 第 112 行
     * 动作：更新物流信息、通知用户

   - SHIPPED → DELIVERED
     * 触发：物流回调接口 src/api/logistics/webhook.js

   - DELIVERED → COMPLETED
     * 触发：用户主动确认 或 7天自动完成（src/cron/autoComplete.js）

3. 取消订单的入口：
   - 用户主动取消：src/api/order/cancel.js
   - 超时取消：src/cron/cancelExpired.js（30分钟未支付自动取消）

场景 2：定位优惠券计算逻辑

Prompt：

我想了解优惠券的折扣计算逻辑。用户在结算页使用优惠券时，系统是如何计算最终应付金额的？请找出相关代码并解释计算顺序。

Claude Code 的回答示例：

优惠券计算逻辑分析（src/services/checkout/calculation.js）：

计算顺序（第 56-98 行）：
1. 计算商品原价总和（subtotal）
2. 应用商品级优惠（如满减、折扣）
3. 计算运费（根据第 3 步后的金额判断是否包邮）
4. 应用订单级优惠券（coupon）
   - 满减券：判断订单金额是否满足门槛
   - 折扣券：按比例计算折扣金额
   - 注意：优惠券不抵扣运费（第 78 行注释说明）
5. 计算积分抵扣（如有）
6. 最终应付金额 = 商品金额 + 运费 - 优惠券 - 积分

关键边界情况处理：
- 优惠券过期校验：src/middleware/couponValidation.js 第 23 行
- 不可叠加使用：同类型优惠券只能选一张（第 45 行）
- 最低支付金额限制：使用优惠券后订单金额不能为 0（第 82 行）

💡 价值点：新 PM 无需打扰开发同学，就能在 10 分钟内理解核心业务逻辑，更快进入工作状态。

📊 用例 3：数据分析（Data Analysis）

实战案例：分析用户行为漏斗

场景：产品迭代效果评估

假设你刚上线了一个新的注册流程，需要分析转化漏斗，找出流失环节：

Step 1：准备数据（user_funnel_data.csv）

user_id,event,step,timestamp,device
U001,page_view,1,2026-02-01T09:00:00,ios
U001,click_start,2,2026-02-01T09:00:15,ios
U001,input_phone,3,2026-02-01T09:00:45,ios
U001,input_verify,4,2026-02-01T09:01:10,ios
U001,complete,5,2026-02-01T09:01:30,ios
U002,page_view,1,2026-02-01T09:05:00,android
U002,click_start,2,2026-02-01T09:05:10,android
U002,input_phone,3,2026-02-01T09:05:40,android
...

Step 2：让 Claude Code 分析

claude

Prompt：

分析这个 user_funnel_data.csv，帮我：

计算每个步骤的转化率和流失率

识别流失最严重的环节

按设备类型（ios/android/web）对比转化漏斗

给出优化建议

Step 3：Claude Code 的分析结果

## 注册漏斗分析报告

### 1. 整体转化漏斗

| 步骤 | 事件 | 用户数 | 步骤转化率 | 累计转化率 |
|------|------|--------|-----------|-----------|
| 1 | 页面访问 | 10,000 | 100% | 100% |
| 2 | 点击开始注册 | 6,500 | 65% | 65% |
| 3 | 输入手机号 | 4,200 | 64.6% | 42% |
| 4 | 输入验证码 | 2,800 | 66.7% | 28% |
| 5 | 完成注册 | 1,680 | 60% | 16.8% |

### 2. 关键发现

🔴 **最大流失点：Step 2 → Step 3（点击开始注册到输入手机号）**
- 流失率：35.4%（2,300 用户）
- 原因推测：可能是手机号输入界面设计问题，或用户犹豫提供手机号

### 3. 设备类型对比

| 步骤 | iOS 转化 | Android 转化 | Web 转化 |
|------|---------|-------------|---------|
| 1→2 | 72% | 58% | 65% |
| 2→3 | 68% | 61% | 65% |
| 3→4 | 71% | 63% | 65% |
| 4→5 | 65% | 55% | 60% |

**Android 端整体转化率明显低于 iOS，需重点优化。**

### 4. 优化建议

1. **优化 Step 2→3 流失**
   - 在"点击开始注册"按钮前增加价值说明（如"仅需30秒"）
   - 提供第三方登录选项（微信/QQ），减少手机号输入门槛

2. **提升 Android 端体验**
   - 检查 Android 端的验证码自动填充功能是否正常
   - 针对 Android 各机型做兼容性测试

3. **缩短整体流程**
   - 考虑将 Step 3 和 Step 4 合并为一屏（手机号+验证码一起输入）

场景 2：Bug 严重度分析

Prompt：

分析这个 bug_report.csv，为 Top 20 bug 构建严重度/频次矩阵，并给出修复优先级建议。

数据示例（bug_report.csv）：

bug_id,title,severity,report_count,affected_users,component
B001,支付超时未提示,high,156,3400,payment
B002,购物车数量不更新,medium,89,1200,cart
B003,首页白屏,high,234,5600,home
...

Claude Code 输出：

Bug 严重度/频次矩阵分析：

高严重度 + 高频次（立即修复）：
- B003 首页白屏：影响 5,600 用户，报告 234 次
- B007 订单无法提交：影响 4,200 用户，报告 198 次

高严重度 + 中频次（本周修复）：
- B001 支付超时未提示：影响 3,400 用户，报告 156 次
- B012 优惠券无法使用：影响 2,100 用户，报告 87 次

中严重度 + 高频次（排期优化）：
- B002 购物车数量不更新：影响 1,200 用户，报告 89 次
- B015 搜索无结果提示不明确：影响 980 用户，报告 76 次

修复优先级建议：
1. P0：B003、B007（直接影响核心交易链路）
2. P1：B001、B012（影响收入转化）
3. P2：B002、B015（体验优化类）

💡 价值点：原本需要写 SQL 或 Excel 透视表的分析工作，现在几分钟就能得到专业的数据洞察和可视化建议。

📄 用例 4：文档自动化（Documentation Automation）

实战案例：从 PRD 自动生成 Jira Tickets

场景：需求评审后的任务拆分

Step 1：PRD 内容

# 会员积分系统 PRD

## 功能 1：积分获取
- 用户每消费 1 元获得 1 积分
- 每日签到获得 10 积分
- 分享商品到朋友圈获得 20 积分（每日限 1 次）

## 功能 2：积分使用
- 积分可在结算时抵扣现金（100 积分 = 1 元）
- 积分可在积分商城兑换商品
- 积分有效期为获得之日起 365 天

## 功能 3：积分查询
- 个人中心新增"我的积分"入口
- 展示当前积分余额、即将过期积分
- 积分明细列表（收入/支出/过期）

Step 2：生成 Jira Tickets

Prompt：

基于这份 PRD，生成标准的 Jira Tickets。每个功能点拆分为独立 ticket，包含：标题、描述、验收标准、故事点估算、关联的 Epic（积分系统迭代1）。输出格式为 Markdown 表格，方便直接复制到 Jira。

Step 3：Claude Code 生成的 Tickets

## Jira Tickets 生成结果

### Epic: 会员积分系统迭代1

| Ticket ID | 标题 | 类型 | 故事点 | 描述 | 验收标准 |
|-----------|------|------|--------|------|----------|
| POINTS-001 | 【后端】实现消费积分计算逻辑 | Task | 3 | 开发用户消费后自动计算并发放积分的后端逻辑 | 1. 用户完成订单支付后，按 1元=1积分 规则发放积分<br>2. 积分发放记录在积分明细表<br>3. 订单退款时扣回相应积分 |
| POINTS-002 | 【后端】实现每日签到积分发放 | Task | 2 | 开发用户每日签到获得10积分的接口 | 1. 用户每天首次签到获得10积分<br>2. 同一天多次签到只发一次<br>3. 连续签到7天额外奖励20积分 |
| POINTS-003 | 【后端】实现分享积分发放接口 | Task | 2 | 开发用户分享商品获得积分的接口 | 1. 用户分享成功后获得20积分<br>2. 同一用户每日限领1次<br>3. 分享记录需关联具体商品 |
| POINTS-004 | 【后端】积分抵扣现金逻辑 | Task | 5 | 开发结算页使用积分抵扣现金的计算逻辑 | 1. 100积分=1元，向下取整<br>2. 积分不可抵扣运费<br>3. 积分抵扣后订单金额不能为0<br>4. 退款时按比例返还积分 |
| POINTS-005 | 【后端】积分过期任务 | Task | 3 | 开发定时任务处理过期积分 | 1. 每天凌晨检查即将过期的积分<br>2. 过期积分自动清零并记录<br>3. 过期前7天发送提醒通知 |
| POINTS-006 | 【前端】个人中心积分入口 | Task | 2 | 在个人中心新增"我的积分"入口 | 1. 入口显示当前积分余额<br>2. 点击跳转积分详情页<br>3. 有即将过期积分时显示红点提醒 |
| POINTS-007 | 【前端】积分详情页 | Task | 3 | 开发积分详情页展示积分余额和明细 | 1. 顶部展示当前积分总额<br>2. 列表展示积分收入/支出/过期记录<br>3. 支持按类型筛选<br>4. 支持下拉加载更多 |
| POINTS-008 | 【前端】结算页积分抵扣 | Task | 3 | 在结算页增加积分抵扣功能 | 1. 显示可用积分和可抵扣金额<br>2. 提供开关选择是否使用积分<br>3. 实时计算抵扣后应付金额 |
| POINTS-009 | 【测试】积分系统功能测试 | Task | 5 | 编写并执行积分系统全流程测试用例 | 1. 覆盖所有积分获取场景<br>2. 覆盖积分使用边界情况<br>3. 验证积分过期逻辑 |
| POINTS-010 | 【产品】积分系统埋点文档 | Task | 1 | 补充积分相关的数据埋点需求 | 1. 积分获取事件埋点<br>2. 积分使用事件埋点<br>3. 积分页访问埋点 |

### 依赖关系
- POINTS-004 依赖 POINTS-001（抵扣需先有积分）
- POINTS-008 依赖 POINTS-004（前端抵扣依赖后端逻辑）
- POINTS-006、007 依赖 POINTS-001、002、003（展示需先有数据）

### 迭代计划
- Sprint 1（2周）：POINTS-001 至 POINTS-005（后端核心）
- Sprint 2（2周）：POINTS-006 至 POINTS-010（前端+测试）

场景 2：自动生成发布说明（Release Notes）

Prompt：

基于本周合并的 PR 列表（git log --oneline --since="1 week ago"），生成一份用户友好的发布说明，突出对用户的价值，而不是技术细节。

Claude Code 输出：

## 🚀 V2.5.0 版本发布说明（2026-02-13）

### ✨ 新功能

**【积分系统上线】**
- 购物可累积积分，100积分=1元，下次购物直接抵扣现金
- 每日签到领积分，连续7天还有额外奖励
- 积分详情一目了然，随时查看收支明细

**【购物车优化】**
- 新增"移入收藏"功能，暂时不买的商品可以先收藏
- 失效商品支持一键清理，购物车更清爽

### 🐛 问题修复

- 修复部分用户支付时页面卡死的问题
- 修复优惠券使用后订单金额计算错误的问题
- 修复 Android 端分享图片模糊的问题

### 📱 体验优化

- 首页加载速度提升 30%
- 商品详情页新增"猜你喜欢"推荐
- 订单列表支持按状态筛选

---
感谢大家的反馈和支持！如有问题请通过【我的】→【意见反馈】联系我们。

💡 价值点：从 PRD 到开发任务拆分，从代码提交到发布说明，Claude Code 能大幅减轻 PM 的文档工作负担。

🎤 用例 5：用户研究综合（User Research Synthesis）

实战案例：用户访谈后的洞察提炼

场景：新产品方向调研

你进行了 8 场用户访谈，了解用户对"社区团购"功能的需求，需要快速提炼关键洞察：

Step 1：准备访谈记录（interviews.txt）

用户A（30岁，上班族）：
- "平时工作很忙，没时间买菜，希望周末能集中采购"
- "担心团购的商品不新鲜，还是喜欢自己去超市挑"
- "如果邻居都买，我会更愿意尝试"
- "价格优惠很重要，但品质不能差"

用户B（45岁，家庭主妇）：
- "经常参加社区团购，主要是便宜"
- "最烦的是提货点太远，希望能送到小区门口"
- "团长服务态度很重要，遇到过态度差的就再也不去了"
- "希望有退换货保障，买到坏菜能退"

用户C（25岁，自由职业）：
- "团购的商品种类太少了，经常买不到想要的"
- "喜欢尝鲜，希望有更多进口水果、网红零食"
- "配送时间太固定了，希望能自选时段"
- "界面太复杂了，找个东西要翻很久"

用户D（35岁，公司职员）：
- "只在买大件时考虑团购，比如整箱水果"
- "担心个人信息泄露，不想加太多群"
- "希望能看到其他买家的真实评价"
- "支付要方便，最好支持花呗分期"
...

Step 2：让 Claude Code 综合提炼

Prompt：

我进行了 8 场关于"社区团购"需求的用户访谈，以下是访谈记录。请帮我：

提取共性主题和核心痛点

识别不同用户群体的差异化需求

提炼产品机会点

输出一份结构化的用户洞察报告

Step 3：Claude Code 的分析结果

# 社区团购用户洞察报告

## 一、用户画像分类

### 类型1：价格敏感型（占比约 50%）
- 代表：用户B、用户F
- 特征：家庭主妇、退休人员
- 核心诉求：便宜、实惠、基本品质保障
- 关键痛点：提货点远、售后无保障

### 类型2：便利优先型（占比约 30%）
- 代表：用户A、用户H
- 特征：上班族、双职工家庭
- 核心诉求：省时间、集中采购、送货上门
- 关键痛点：商品不新鲜、没时间挑选

### 类型3：品质追求型（占比约 20%）
- 代表：用户C、用户G
- 特征：年轻人、高收入群体
- 核心诉求：商品丰富、品质高、新鲜奇特
- 关键痛点：商品种类少、配送时间不灵活

## 二、核心痛点排序

| 排名 | 痛点 | 提及次数 | 影响用户类型 |
|------|------|---------|-------------|
| 1 | 商品品质/新鲜度担忧 | 7/8 | 全部 |
| 2 | 提货点距离/配送不便 | 6/8 | 价格型、便利型 |
| 3 | 售后服务不完善 | 5/8 | 价格型 |
| 4 | 商品种类少 | 4/8 | 品质型 |
| 5 | 使用门槛高（界面复杂/加群麻烦） | 4/8 | 品质型、部分便利型 |

## 三、关键发现

🔍 **信任问题是最大障碍**
- 7/8 的用户表达了对商品品质的担忧
- "邻居都买我才买"体现社交信任的重要性
- 现有团购平台在品质保障方面缺乏有效机制

🔍 **履约体验决定留存**
- 提货点距离、团长服务态度被多次提及
- 售后退换货机制是用户持续使用的关键保障

🔍 **需求分层明显**
- 低端用户：只要便宜，其他都可以妥协
- 中端用户：性价比+便利性平衡
- 高端用户：愿意为品质支付溢价

## 四、产品机会点

### 机会1：品质保障体系（高优先级）
- 建立"不满意就退"的无理由退货机制
- 引入第三方质检报告展示
- 设立"团长担保"制度，强化信任传递

### 机会2：差异化商品策略（中优先级）
- 基础款：满足价格敏感型用户（蔬菜、米面）
- 品质款：满足品质追求型用户（进口水果、有机蔬菜）
- 独家款：打造差异化竞争力（产地直采、网红商品）

### 机会3：灵活履约方案（中优先级）
- 自提点优化：基于用户位置智能推荐最近提货点
- 配送升级：提供"送货到门"增值服务
- 时间灵活：支持预约配送时段

### 机会4：简化使用流程（高优先级）
- 无需加群，小程序直接下单
- 一键复购常买商品
- 智能推荐"邻居都在买"的热门商品

## 五、设计建议

1. **首页设计**：突出"品质保障"和"邻居推荐"，降低信任门槛
2. **商品详情页**：增加质检报告、用户评价（特别是邻居评价）
3. **下单流程**：提供"一键加购常买清单"功能
4. **售后入口**：明显展示"不满意包退"承诺

## 六、下一步行动

1. 设计团队：基于机会点1和4，输出首页和详情页原型
2. 运营团队：调研供应链，评估"不满意包退"的可行性
3. 技术团队：规划用户位置服务和智能推荐算法
4. 用研团队：针对"品质保障"机制进行第二轮概念测试

💡 价值点：原本需要一整天整理访谈记录、画 affinity diagram 的工作，现在几分钟就能得到结构化的洞察报告，且不会遗漏关键信息。

🔌 用例 6：面向 PM 的 MCP 集成

实战案例：Jira + Slack 自动化工作流

场景：需求变更的自动同步

通过 MCP 集成，Claude Code 可以成为你连接各个工具的"智能中枢"：

案例 1：PRD 变更自动更新 Jira

claude

Prompt：

读取 docs/payment-prd-v2.md，对比其中"支付流程"章节与 Jira 中 Epic “PAY-202” 下的所有 tickets，找出需要更新的 tickets，并生成更新建议清单。

Claude Code 执行流程：

通过 MCP 读取本地 PRD 文件
通过 MCP 查询 Jira API，获取 Epic PAY-202 下的所有 tickets
对比 PRD 中的需求点与现有 tickets 的覆盖情况
输出差异分析：

## PRD 与 Jira Tickets 对比分析

### 新增需求（PRD 中有，Jira 中无）
1. **支持花呗分期付款**
   - 建议新建 Ticket：PAY-215【支付】花呗分期接入
   - 故事点：5
   - 依赖：PAY-208（支付渠道配置重构）

2. **支付失败 3 次后锁定账户 1 小时**
   - 建议新建 Ticket：PAY-216【风控】支付失败次数限制
   - 故事点：3
   - 关联：安全团队

### 需求变更（PRD 与 Jira 描述不一致）
- **Ticket PAY-203**：原描述"支持微信支付"，PRD 更新为"支持微信支付+微信分"
  - 建议更新描述，故事点从 3 调整为 5

### 已删除需求（Jira 中有，PRD 中无）
- **Ticket PAY-207**：Apple Pay 支持
  - PRD V2 已删除此功能
  - 建议与产品确认后关闭或移至 Backlog

### 建议的 Sprint 调整
当前 Sprint 容量已超载，建议将 PAY-215、PAY-216 放入下一个 Sprint。

案例 2：自动生成周报并推送到 Slack

Prompt：

从 Jira 拉取本周我负责的所有 tickets 状态更新，生成周报摘要，并发送到 Slack #product-channel 频道。

Claude Code 执行流程：

通过 MCP 查询 Jira：
- 本周完成的 tickets
- 进行中的 tickets 及进度
- 阻塞中的 tickets 及原因
生成周报内容：

## 📊 产品团队周报（2026.02.10 - 2026.02.16）

### ✅ 本周完成
- **PAY-203** 微信支付接入 - 已上线（负责人：张三）
- **CART-156** 购物车编辑优化 - 测试中（负责人：李四）
- **USER-089** 注册流程埋点 - 已完成（负责人：王五）

### 🚧 进行中
- **PAY-208** 支付渠道配置重构 - 70%（预计下周三提测）
  - 已完成：数据库 schema 设计、基础接口开发
  - 待完成：渠道切换逻辑、灰度发布配置
  
- **HOME-112** 首页个性化推荐 - 50%（预计下周五提测）
  - 已完成：推荐算法接入、AB 测试配置
  - 待完成：前端卡片样式、曝光埋点

### 🚫 阻塞/风险
- **ORDER-245** 订单导出功能 - **Blocked**
  - 阻塞原因：数据安全评审未通过，需补充脱敏逻辑
  - 解决方案：已与安全团队对齐，预计明天解阻塞
  - 风险等级：🔴 中（可能影响下周发布）

### 📈 数据亮点
- 上周上线的"限时秒杀"功能，转化率提升 **23%**
- 新注册流程的完成率从 16.8% 提升至 **22.5%**

### 📅 下周计划
1. PAY-208 提测并灰度发布
2. HOME-112 完成开发并提测
3. 启动积分系统需求评审（POINTS-001 ~ POINTS-010）

---
如有疑问请联系 @产品经理小明

通过 MCP 推送到 Slack #product-channel

案例 3：Notion 文档自动归档

Prompt：

把本周所有标记为"已结束"的 PRD 文档从 Notion “进行中” 数据库移动到 “已归档” 数据库，并为每个文档添加归档日期和归档原因。

💡 价值点：MCP 集成让 Claude Code 成为 PM 的"智能助理"，自动完成跨工具的重复性工作，让 PM 专注于真正有价值的产品思考。

五、产品经理需要知道的局限性

⚠️ 1. 复杂度天花板

简单工作流能立刻产出价值，但复杂的多文件改动需要：

熟练使用 /clear 和 /compact 管理上下文
缩小 Prompt 作用域
理解代码库结构

典型曲线：一开始进展爆发式，随后进入学习曲线。

⚠️ 2. MCP 稳定性

MCP servers 经常断开并需要重新认证，需要预期一定的配置摩擦。

⚠️ 3. 编辑阶段需要代码库意识

AI 输出能让你很快到 80%，最后 20% 需要：

对照团队约定审查变更
识别与代码库其他部分冲突的逻辑
捕捉边界情况

建议工作方式：用 Claude Code 生成 + 与工程师一起 review

⚠️ 4. 单人工具限制

Claude Code 运行在你的机器上、终端里：

每次会话"从头开始"
缺少与设计师共享进度的内建能力
无法给干系人展示预览
工作交接不够无缝

六、从单人 PM 扩展到团队：Builder.io

Builder.io 是 agentic development platform，将 Claude Code 的单人能力扩展成团队级工作流：

功能	说明
💬 Slack 原生工作流	在 Slack 里 @Builder.io 提需求并审批
🎫 Jira/Linear 集成	Ticket 直接分配给 Builder bot，自动实现并开 PR
👥 基于角色的协作	PM 视觉验证 → 开发 review & merge
⚡ 并行代理	批量分配多个 ticket，同时处理
🔗 可分享预览	每个分支都有 live preview URL