产品经理用 AI 跑通「需求→原型→PRD→自动部署」全流程：20 个原型的实战复盘
AI 工具人 PM 的实战笔记：不教理论，只分享我亲手跑通的完整流水线。从一句口述需求，到线上可点的原型，全程我只做「判断」，AI 做「执行」。
起因：PM 的时间都耗在了「翻译」上
我是一个 SaaS 产品的产品经理，有技术背景。传统 PM 的一天是这样的：
- 想清楚需求 → 2 小时
- 把需求「翻译」成原型 → 画 Axure/墨刀，3 小时
- 把原型「翻译」成 PRD → 补字段、补边界，3 小时
- 把 PRD「翻译」给研发 → 评审、答疑、改稿，N 小时
真正有价值的「想清楚」只占 20%，剩下 80% 都是重复劳动。
更糟的是反馈慢：原型画完要导出发给 stakeholder，对方看完再约会议，一轮下来两三天。
所以我想：能不能把这 80% 交给 AI，我只做判断？
跑了两个多月，20 个原型、47 篇 PRD/spec 文档、按月份自动归档、一条命令部署上线。这篇文章把整条流水线拆开讲，每一步都给真实命令和踩坑。
先看全貌：五步流水线
arduino
口述需求
↓ ① 拆需求（结构先行，不急着写）
页面清单 + 跳转关系 → 等我确认
↓ ② 分析（决策索引 + 双向链接）
问题定义 + 关键改动，沉淀进知识库
↓ ③ 画原型（单文件 HTML，5 分钟可跑）
高保真可点击，按月归档
↓ ④ 写 PRD（五段模板，缺一不可）
背景/方案/交互/指标/开放问题
↓ ⑤ 自动部署（一条命令上线）
npm run deploy → 增量上传 + 生成首页 + 回写索引核心原则：每一步都是「AI 先给结构 → 我做判断 → AI 再执行」。我永远不在没确认结构前让它写细节。
① 拆需求：先给结构，确认后再写细节
这是最容易翻车的一步。AI 最擅长「一上来就写 500 行」，但没确认结构的细节都是浪费。
我的硬规则（写进项目的 CLAUDE.md，让 AI 每次开工前先读）：
任何输出必须先给结构再给细节。禁止一次性输出未经确认的长内容。
实际对话长这样：
markdown
我：客户侧要做一个 AI 工具管理，能浏览技能、装/卸/更新、开关
AI：先给结构。页面清单：
1. 技能市场首页（三 Tab：已安装/发现/更新）
2. 技能详情页
3. 上传技能包弹窗
跳转关系：首页→详情→（安装/卸载/配置）
确认后我生成原型。
我：确认，但「更新」Tab 要显示版本号对比
AI：收到，补进结构，开始生成。为什么有效：结构层级的修改成本是 1，细节层级的修改成本是 100。把返工挡在最便宜的阶段。
踩坑：早期我没立这条规则，AI 一次写完 800 行原型，我要改一个跳转逻辑，等于全篇重写。后来立了「结构先行」，返工率断崖式下降。
② 分析：决策索引 + 双向链接，让经验能查回来
PM 最痛的不是做决策，是三个月后忘了当时为什么这么决策。
我的解法：每个需求建一份「决策索引」，并且在 Obsidian 里做领域判断的双向链接。
决策索引记三件事：
| 字段 | 作用 |
|---|---|
| 问题定义 | 这个需求到底解决谁的什么痛点 |
| 关键改动 | 每次迭代改了什么、为什么 |
| 推翻的假设 | 当时以为对、后来证明错的判断 |
真实命令（脚本化，不靠手记）：
bash
# 给新需求建决策索引
node scripts/create-requirement-decision.js <feature-slug>
# 批量回填历史需求
node scripts/create-requirement-decision.js --backfill
# 重新生成需求总表
node scripts/generate-requirements-index.js价值 ：写这篇文章时，我能直接查回两个月前「某个功能为什么从 v1 演进到 v2」，而不是凭记忆瞎编。经验只有能查回来，才算真的沉淀了。
③ 画原型：单文件 HTML，5 分钟可点
这是整条流水线最爽的一环。我彻底放弃了 Axure/墨刀，改用 AI 生成单文件 HTML 原型。
为什么选 HTML 而不是原型工具：
| 对比 | Axure/墨刀 | 单文件 HTML |
|---|---|---|
| 保真度 | 中 | 高（真实 CSS/JS） |
| 可交互 | 有限 | 按钮能点、表单能填、流程能走完 |
| 分享 | 导出/链接受限 | 部署后一个 URL 即点即看 |
| 修改 | 拖拽重画 | 改代码，AI 秒级重生成 |
我的硬规则：
任何原型必须 5 分钟内可运行------单文件、无构建步骤、无 npm install。
目录约定（按月份归档，便于回溯）：
yaml
prototypes/
2026-06/
some-feature-v2/ # 大型原型：拆成 index.html + style.css + main.js
admin-tool-management-v1.html # 小型原型：单文件
2026-07/
image-management-v1/
customer-tool-management-v1.html增量交付（憋大招是反模式） ：大文件绝不一次写完。先写 <!DOCTYPE html> 骨架（几十行），再分块用 Edit 追加，每加一块浏览器打开自检一次。超过 500 行必须拆模块。
踩坑：原型里禁止占位图（placeholder.com），用 CSS 几何图形或真实素材；颜色必须从设计系统提取，禁止写死十六进制。
④ 写 PRD：五段模板，缺一不可
原型确认后，PRD 是「从截图反推文档」，而不是凭空写。
我的五段模板（硬性要求，少一段打回）：
markdown
## 背景与问题（Problem）
- 目标用户、痛点、至少 3 条数据/访谈证据
## 方案概述（Solution）
- 核心功能一句话 + 流程图（Mermaid）或原型链接
## 交互细节（Interaction）
- 页面清单与跳转、关键字段（默认值/校验/错误文案）
- 边界情况：空状态、加载态、弱网、权限不足
## 成功指标（Metrics）
- 北极星指标或功能使用率、预期提升、追踪周期
## 开放问题（Open Questions）
- 待确认的技术可行性或政策风险关键约束：禁止只写 happy path。每个输入字段注明类型/必填/长度/校验/错误提示；每个按钮注明主次/禁用条件/点击反馈；边界清单至少列 3 条（空数据、超长文本、弱网、未登录、无权限、并发）。
流程 ：Markdown 预览 → 我确认 → 脚本生成 Word 终稿（scripts/build-prd-docx.js）。
⑤ 自动部署：一条命令，原型上线
这是把「分享成本」打到接近零的一步。以前原型画完要手动传服务器、改首页，现在一句话搞定。
实际命令：
bash
npm run deploy # = node deploy/sync.js这条命令背后做了 6 件事：
markdown
1. 扫描本地原型（自动把散落的 HTML 归档到当前月份文件夹）
2. 解析每个原型的 <meta>：标题/分类(mobile/desktop)/描述
3. 自动生成首页 index.html（按月归档 + 分类筛选 + 卡片网格）
4. SSH 连接服务器，SFTP 增量上传（MD5 校验，内容没变就跳过）
5. 上传首页
6. curl 验证：首页 HTTP 200 + 原型卡片数真实输出（脱敏）：
yaml
== 4. 增量上传 ==
⏭ 跳过 2026-06/admin-tool-management-v1.html（远程文件内容相同）
↑ 上传 2026-07/customer-tool-management-v1.html (54.5 KB)
== 6. 验证 ==
首页 HTTP: 200
首页原型数据条数: 21
✅ 同步完成：上传 1 个，跳过 20 个
访问地址：https://你的域名/最妙的是联动：部署成功后，脚本会检测「这个原型有没有建决策索引」，没有就提示我补------把第②步和第⑤步串成了闭环。
踩坑 ：云服务器安全组按客户端出口 IP 放行 22 端口，WiFi 一切换白名单就失效。解法：curl ifconfig.me 拿当前 IP，加进安全组，重跑 deploy。别用端口预检，直接跑脚本以实际 SSH 结果为准。
两个月跑下来的真实数据
不靠感觉，直接看数：
- 20 个 HTML 原型（14 电脑端 + 6 移动端），全部线上可点
- 47 篇 PRD/spec 文档
- 2 个月份自动归档目录
- 1 条部署命令，平均增量上传 < 1 分钟
- 每个需求都有决策索引，可回溯「当时为什么这么定」
时间分配的变化：
| 阶段 | 传统 | 现在 |
|---|---|---|
| 想清楚需求 | 20% | 60% |
| 画原型 | 30% | 15%（AI 生成，我调） |
| 写 PRD | 30% | 15%（原型反推） |
| 部署分享 | 20% | ~0%（一条命令） |
我把省下来的 80% 时间，全部投到了「想清楚需求」这件事上------这才是 PM 真正该干的活。
五条可复用的经验
如果你也想搭这套流水线，这五条是我踩坑换来的：
- 结构先行：永远让 AI 先给结构，确认后再写细节。返工成本随阶段指数级上升。
- 经验要能查回来：决策索引不是形式主义，是三个月后救你的东西。脚本化，别靠手记。
- 原型选 HTML 不选工具：可交互、可分享、AI 改起来快。单文件、5 分钟可跑是底线。
- PRD 拒绝 happy path：五段模板 + 边界清单是硬约束，少一条打回。
- 把分享成本打到零：自动化部署不是锦上添花，是让你愿意持续输出的前提。分享成本高，再好的东西也烂在本地。
写在最后
这套流水线的本质，不是「用 AI 替代 PM」，而是把 PM 从重复劳动里解放出来，去做只有人能做的判断。
AI 负责「执行」------画原型、写文档、传服务器；我负责「判断」------这个需求该不该做、结构对不对、决策有没有推翻旧假设。
工具人 PM 的第二篇实战，讲的是「我怎么用 AI 跑通从需求到上线的完整闭环」。
还是那句：不教理论，只分享我亲手跑通的方法。
欢迎交流：如果你也在用 AI 重构 PM 工作流，或者对 Claude Code、原型自动化、PRD 标准化感兴趣，欢迎评论区交流。这套流水线的每个环节我都在持续迭代，后续会分享更多踩坑实录。