当业务老大突然丢来一个5天必须交付的紧急需求时，这位产品经理没有选择熬夜加班，而是用AI重构了整个工作流程。从PRD撰写到可交互原型开发，再到反向提炼可复用的skill体系，最终将原本需要1周的工作压缩至2小时完成。本文揭秘了这套从实战中淬炼出的AI协作方法论，以及如何将个人经验转化为AI可执行的标准化流程。
系列说明：这是「AI 协作」系列二的第一篇——分享下我把”写一份需求”从 1 周压到 2 小时的故事。
从这期开始，公众号会双线并进：系列一「电商产品能力拆解」继续按计划更新，系列二「AI 协作」不定期穿插——一条讲业务系统怎么落地，一条讲我自己怎么用 AI 提效。
这篇不卖”AI 提效 100 倍”的话术，只给一套可以直接抄走的协作骨架。
时间：上个季度某个周三下午 4 点。
那天我刚开完一个跨部门评审会，会上业务老大临时加了一个需求：
“下周一上午我要看到一版完整方案，含 PRD、流程图、还要能演示给老板看的原型。”
我心里默默算了一下时间：
5 天，刚刚好周一交付。 5 天，刚刚好周一交付。但这是最理想的情况——前提是中间没有反复推翻、没有跨部门 battle、没有老板说”我感觉不对再改改”。
那天晚上我盯着白板发了 10 分钟呆，做了一个决定：这次我不靠肝，靠 AI。
我先讲清楚一件事——“用 AI 写 PRD”不是把需求丢给它，让它给你输出。这种用法 95% 的人都试过，最后都骂“AI 真的好废”。
真正能用的方式是：你做导演，AI 做剧组。
不是”看看 AI 能不能写”，是要真的交付一份能上评审的完整方案。所以我同时要做三件事：
最后一项是关键——我不要静态原型，我要老板能在浏览器里点击、能操作、能看到状态切换的“可交互模拟器”。这才能撑得起向上汇报的场面。
第一版我是这么开口的：
“帮我写一份关于会员积分体系优化的 PRD。”
AI 噼里啪啦给我吐了一堆”积分获取/积分消耗/积分有效期……”。全是正确的废话。
废话的原因是——我没给上下文，它就只能讲常识。
第二版我学乖了，喂给它的内容是这样的：
结论：你愿意花 30 分钟整理上下文，AI 才能帮你省 3 天。 这就是 AI 协作的第一性原理。
我一开始也以为 AI 只能做静态的 wireframe。直到我换了思路：
“原型不一定要在 Axure 里画，可以直接是一个能跑的 HTML 网页。”
于是我把所有页面、交互、状态切换、Mock 数据，整理成一份”原型需求清单”丢给 AI，让它直接吐 HTML + Tailwind + 一点点 JS 出来。
结果是——老板真的可以在浏览器里点击操作了。 切换 tab、选品、下单、看到积分余额变化、看到不同等级的兑换价差异，完整体验流程。
而且比 Axure 有几个碾压级优势：
关键认知：原型的目的不是“画得像”，是“让人理解需求”。能交互的 HTML 比静态图强 10 倍。
但这只是第一步。真正让我“封神”的是第二阶段。
第一阶段干完，我交付完那个需求，已经够下班了。但我心里有个隐隐的不安：
“这次能 1 天搞定，是因为我刚好状态好、刚好运气好、刚好这个需求适合 AI——下一次还能复现吗？”
如果不能复现，那这就是一个偶然，不是方法论。
大部分人用 AI 的姿势是：有需求 → 想 prompt → 试结果 → 不行再调。 这是”靠灵感”。
我做的事情是反过来：已经有了一份高质量的产出 → 倒推这份产出的“生产链路” → 把每一个关键节点抽象成可复用的 skill。
Step 1：拆解已交付物——把“长什么样”显性化
我拿着那份交付完的 PRD，用 AI 帮我做了一件事：反向归纳出这份文档的结构模板。
我喂给它的指令大致是这样：
“这是一份我亲手写的 PRD（附文档全文）。请你帮我归纳：① 它的章节顺序；② 每个章节固定使用的内容类型（表格/SVG/JSON 示例 等）；③ 表格的列设计规律；④ 写作语气和句式特征；⑤ 出现频率最高的术语和短语。”
AI 一下子吐出一份结构骨架文档。这就是后来”PRD 生成器”的雏形。
Step 2：还原生产流程——把“怎么做”显性化
光有骨架不够，因为不知道“先做什么、后做什么、卡在哪、怎么校验”。
所以我做了第二件事——把我做这份 PRD 的过程，用一份”复盘日记”写下来：
Step 3：封装成 skill——把“我的方法”显性化
到这一步，最关键的一步是：把骨架（Step 1）+ 流程（Step 2）合体，写成一份“AI 可以直接读取并执行”的指令包。
这个指令包就是 skill。它本质上是一段”元 prompt”，告诉 AI：
“下次再有人让你写 PRD，你必须严格按这个章节顺序、用这种表格格式、保持这种文风、走完这套 workflow，最后输出符合这些 checklist 的产物。”
我陆陆续续封装了 5 个 skill：
关键认知：skill 不是 prompt 工程，是把你的“经验”做成了 AI 的“骨头”。
骨架搭完了，是骡子是马得拉出来溜溜。
正好上周又来了一个新需求：给会员资产体系加一块“代金券” 模块。需求复杂度跟第一阶段那个项目差不多——4 个角色、6 个系统、十几个核心场景。
我开了个计时器，开始干。
第二天评审会，业务、研发、测试都在场。先是业务直接在浏览器里点了 5 分钟原型，然后扔过来一句：
“这次方案做得很细，跟以前不是一个水平。是不是换了个人来做？”
研发的 Tech Lead 翻了一下接口表和时序图，问的第一句话是：
“这接口字段你们怎么这么快就梳理完整了？是不是早就开始做了？”
我嘴上回答着”前期调研做得比较充分”，心里偷偷打开计时器看了看：120 分钟，节省 95%。
如果你只想看结论，这一章节背下来就够了。
1. 上下文密度决定 AI 的下限。 你花 30 分钟整理上下文包，AI 才能省你 3 天。
2. 原型必须能交互。 让业务方点 5 分钟，胜过你讲半小时。HTML 模拟器是 Axure 的天敌。
3. AI 不是替代你，是替代你的“重复劳动”。 写章节骨架、画时序图、补字段表——这些是它擅长的；做业务判断、定优先级、做权衡——还得你。
4. 不要追着 prompt 跑，要追着产出跑。 谁的产出更稳定，谁的 AI 用得更好。
5. 把“长什么样”和“怎么做”分开归纳。 前者是骨架，后者是流程。两个都齐全才能复用。
6. 第一次靠灵感，第二次靠 workflow，第三次靠 skill。 三次以上才算沉淀。
7. workflow 是步骤，skill 是元 prompt。 一个 skill 内嵌完整 workflow，AI 拿到就能跑。
8. skill 越具体越好。 通用 skill 就是空话，”电商品牌端会员 PRD 生成器”这种限定到具体场景的才好用。
9. skill 是会进化的。 每次用完都该回头改 skill——把这次踩的坑写进去，下次就不会踩。
10. 真正的护城河，是你能让 AI 干 80% 的活，再用剩下 20% 把它甩开。 80% 是效率，20% 是判断力，缺一不可。
能勾对 8 题以上的，你已经超过 95% 的 AI 用户了。
1. 每次让 AI 干活前，会先整理一份“上下文包”吗？ 业务背景 + 角色场景 + 系统约束 + 模板样本，缺一不可
2. 给 AI 看你的历史交付物了吗？ 让它学你的文风，比让它”按通用规范”强 10 倍
3. 把约束讲清楚了吗？ 排期、人力、不能动的接口——AI 不知道这些就只能画”理想态”
4. AI 出的内容，你逐条 review 了吗？ 不是看排版，是看业务规则有没有错
5. 有没有一份自查 checklist？ 每次交付前过一遍，不靠记忆
6. 异常场景覆盖了吗？ AI 默认只写主流程，异常分支必须你来提
7. 做完一次有没有反向提炼模板？ 还是下次又从头开始
8. workflow 写下来了吗？ 不是脑子里想想，是文档化、可分享
9. 高频任务封装成 skill 了吗？ PRD / 时序图 / 对接方案，哪个不是高频
10. skill 在持续迭代吗？ 每次用完就改一遍，越用越锋利
一句话总结： AI 协作不是”会用 prompt”，是把你做了 8 年的经验，蒸馏成 AI 能调用的能力。
作者：Zoe产品手记 公众号：Zoe产品手记
本文由 @Zoe产品手记 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。