在 AI Native 时代，产品经理的角色正在发生变化。真正的 AI Native，并不是把所有工作一股脑交给模型，而是在遇到问题时——从需求拆解、方案探索，到版本迭代——优先尝试与 AI 共创，利用“智能需求引擎”持续生成、校准和优化产物。其核心是三件事：给到 AI 足够的上下文，明确可交付物的预期形态，并围绕每一次结果建立反馈循环，不断调整 prompt、工具链与输入结构。
自 9 月正式推出 GLM Coding Plan 以来，我们在与大量开发者的真实交互中不断迭代订阅体系、计费结构与整体体验，也积累下了一整套可复用的 AI Native 需求方法论。这篇文章也算是一份阶段性的经验总结，分享给所有正在探索 AI Native 工作方式的 PM 与开发者。
这也是接下来内容的起点——通过 GLM Coding Plan 的真实落地经验，拆解我们在 AI Native 工作方式下的完整产品方法论。如果你正在探索如何在团队中把 AI 用好，这部分的内容会非常值得一读。
一、定位：AI Native 时代的「需求阶段」优先解决什么问题？
传统需求阶段常见问题：
- 信息来源割裂： 调研、访谈、竞品、数据分散，靠人脑整合慢且容易偏。
- 想法主观： PRD 写的是「我觉得」，而不是「被验证过的假设」。
- 交付物脱节： PRD、交互稿、视觉稿由不同角色重复理解需求，信息多次丢失。
- 调整成本高： 到开发、测试阶段才发现需求不清，返工巨大。
AI Native 重塑目标：
让产品经理借助 AI，把“需求发现 → 假设生成 → 快速验证 → 方案收敛 → PRD + 设计稿”变成一条高速闭环流水线，而不是线性手工车间。
核心变化：
- AI 变成「调研与推理引擎」：自动搜集信息、生成假设方案。
- PM 变成「问题定义者 & 审核者」：专注于判断、取舍和对齐。
- 产出物一次成链路：需求阶段即同时产出「结构化 PRD 草稿 + 交互原型说明」，减少后续翻译损耗。
二、AI Native 需求阶段总流程（PM 视角）
那我们如何把“与 AI 共创”的理念，转化为可执行、可复现、可扩展的一条完整链路，让需求从提出、分析到验证和产出，都能形成闭环呢？
我们在项目中沉淀出了一套适用于 0→1 / 1→N 场景 的 AI Native 需求阶段全流程。这套流程既保持了 PM 对业务、用户、场景的深度判断，也极大限度利用 AI 完成高强度的信息整合、结构化生成和功能探索。
流程总览
- 问题对齐：业务目标 & 北极星拆解
- AI 辅助信息收集：用户、数据、竞品、多源汇总
- AI 生成机会空间：痛点 → 场景 → Hypothesis
- 方案共创：和 AI 联合产出多版本解决方案框架
- 最小验证设计：用 AI 快速生成「可验证的原型 &用例」
- 验证结果回灌：AI 协助归因与结论化
- PRD 自动化生成与精修
- 设计稿联动生成：从场景 → 用户旅程 → Wireframe Brief
三、分步骤落地指南
理解了整体流程并不代表能立刻落地。接下来我们会把每一个步骤进行拆解，你可以直接照做，每一步都给出「PM 角色」「AI 能力」「产出物」。
Step 1：问题对齐——AI 辅助定义“对的问题”
| 关键部分 | 详细说明 |
|---|---|
| PM 做什么 | - 输入业务目标（收入、留存、成本、产品战略）、已知约束。 - 描述当前认知：已有功能、主要用户群体、现状问题。 |
| AI 做什么 | - 帮你： - 将业务目标拆成可度量指标与用户行为指标。 - 识别信息缺口：还缺哪些数据 / 访谈 / 日志才能判断。 - 输出结构化《问题定义草稿》。 |
| 关键产出物 | - 《问题定义 One-pager》： - 业务背景 - 目标 & 指标 - 用户范围 - 已知事实 - 待确认问题列表 |
建议：这一页直接作为后续 PRD 的「背景 & 目标」章节，由 AI 维护为单一事实源（Single Source of Truth）。
Step 2：信息收集——AI 做你的「Research Ops」
数据源包括：埋点数据、工单、反馈社区、访谈记录、竞品文档、网络公开信息等。
| 关键部分 | 详细说明 |
|---|---|
| PM 做什么 | - 明确数据源入口：给 AI 权限/文档链接。 - 提出聚焦问题，如： - 「过去 90 天用户在哪些节点流失？」 - 「工单中关于 xxx 的 Top 10 问题？」 |
| AI 做什么 | - 汇总 + 归类 + 抽象： - 聚类用户痛点 - 识别高频场景 - 提炼「影响指标」的关键路径 - 输出结构化的： - 用户分群 - 核心场景清单 - 痛点证据表（问题 + 数据/示例） |
| 关键产出物 | - 《用户痛点与场景列表》 - 《证据对照表》（每个痛点背后的数据/案例链接） |
这些内容将直接喂给后面「机会分析」「方案生成」「设计稿生成」。
Step 3：机会空间——用 AI 整理「哪里值得做？」
| 关键部分 | 详细说明 |
|---|---|
| PM 做什么 | - 确定约束：资源规模 / 时间窗口 / 战略方向。 - 选择评估维度：影响力、紧迫性、可行性、与 AI 能力的匹配度等。 |
| AI 做什么 | - 基于痛点和约束，自动生成「机会地图」： - 每个机会项包含：目标用户、场景、痛点、潜在方案方向、预期指标提升。 - 对机会进行打分 & 排序，给出推荐优先级。 |
| 关键产出物 | - 《机会评估矩阵》 - 《本周期聚焦机会 Top N》 |
到这里，PM 已经从“想到什么写什么”，升级为“在 AI 整理的机会空间中作决策”。
Step 4：方案共创——AI 帮你出多条路线
选定 1–3 个重点机会后：
| 关键部分 | 详细说明 |
|---|---|
| PM 做什么 | - 为每个机会给一个「设计约束」： - 不改现有架构 / 允许灰度 / 需要 2 周内上线 / 尊重合规要求等。 |
| AI 做什么 | - 为每个机会生成 3 类方案草图： a. 极简版（MVP，最小实现） b. 体验优先版 c. AI 增强版（充分利用模型/智能体的差异化能力） - 每条方案包括： - 核心价值叙述（Value Proposition） - 关键用户旅程 / 用例 - 必要功能点 vs 可选功能点 - 依赖与风险 |
| 关键产出物 | - 《方案对比表》（给评审会直接用） - 用于下一步「最小验证」的候选方案集合 |
Step 5：最小验证——用 AI 把验证成本打到最低
目标：在「需求评审会之前」完成一轮验证，让 PRD 带着证据走进会议，而不是带着猜想。
推荐 4 类 AI Native 验证方式（可组合）：
| 验证方式 | 详细说明 |
|---|---|
| AI 模拟用户访谈 | - AI 扮演不同用户画像，对方案逐条提问 & 质疑。 - 快速暴露体验缺陷、边界场景。 |
| AI 生成交互草图 + 可点击原型 | - 使用 AI 生成 Wireframe / 流程图（文本 → 线框）。 - 内部快速走查可用性。 |
| AI 驱动日志回放 & 假设检验 | - 将匿名化行为日志喂给 AI，让它回答： - 「现有用户行为中，有多少人已表现出对该功能的需求迹象？」 |
| Prompt 级 MVP | - 先不改代码，在 AI/Agent 里通过指令或简单脚本模拟目标方案，让种子用户试用，从反馈中验证价值。 |
PM 的职责
- 定义「验证标准」：例如 NPS、完成率、关键任务成功率、用户反馈标签。
- 让 AI 输出《验证设计方案》，然后你负责选型与执行。
关键产出物
- 《最小验证方案》与执行记录
- 《验证结论摘要》（支持 / 反对 / 待补充）
这些内容直接进入 PRD 的「假设与验证」章节，极大提升说服力。
Step 6：PRD 自动化生成与精修——AI 当写手，你当总编
在前面所有产出基础上，让 AI 帮你生成结构化 PRD。
| 关键部分 | 详细说明 |
|---|---|
| PRD 结构示例 | 1. 背景 & 问题定义（来自 Step 1） 2. 目标 & 指标（业务 + 用户 + AI 能力利用指标） 3. 用户画像 & 使用场景 4. 需求范围 - Must / Should / Could / Won’t 5. 方案说明 - 核心流程 - AI 参与点（模型、Agent、工具调用、数据依赖） 6. 验证过程与结论 7. 边界条件 & 风险 8. 技术与数据要求（留给研发/架构评估） 9. 埋点与评估方案 |
| AI 做什么 | - 从「问题定义 + 痛点 + 机会 + 方案 + 验证结论」自动拼装完整 PRD 初稿。 - 自动抽取待确认问题，生成「评审清单」。 - 帮你把多轮讨论同步回 PRD（作为动态文档）。 |
| PM 做什么 | - 全文审核：删除堆砌、澄清模糊描述。 - 用人类判断修正优先级、市场策略、合规红线。 |
| 关键产出物 | - 《AI 协作生成的 PRD v1.0》（评审用） |
Step 7：设计稿联动生成——需求阶段直接带出 Wireframe
目标：需求阶段结束时，不只交付 PRD，还有「可落地的设计稿雏形」，减少后端环节反复抄写与误解。
| 关键部分 | 详细说明 |
|---|---|
| 做法 | 1. 让 AI 基于 PRD： - 生成 信息架构（IA） - 生成 关键页面/模块列表 - 为每个页面写出： - 核心元素（字段、控件） - 状态（空态、加载态、异常态） - 主流程与分支流程 2. 用「AI + 设计工具」生成 Wireframe： - 文本描述 → 自动生成低保真原型 - 或输出给设计师的「结构化设计 Brief」 |
| 关键产出物 | - 《交互稿 Brief / Wireframe 列表》 - 可以直接导入 Figma/墨刀/蓝湖等 - 和 PRD 强绑定：每个需求点→对应界面→对应组件→对应事件/埋点。 |
至此，「需求阶段」正式交付两个关键物：PRD v1.0 + Wireframe/设计 Brief，且两者源自同一套 AI 协作链路，信息一致，可追溯。
四、实操案例
场景设定
目标：在大模型 MaaS 平台上设计/优化一套「套餐订阅产品」（如按月 / 年、不同配额、模型组合等），让开发者 / 企业方便购买、续费和管理，兼顾营收与体验。
Step 1：问题对齐——明确我们为什么要上「套餐订阅」
目标：从“我们想搞个套餐”升级成“我们需要通过套餐解决哪些业务 & 用户问题”。
| 关键部分 | 详细说明 |
|---|---|
| PM 做什么 | - 把当前现状丢给 AI：现有计费方式、痛点、业务目标。 - 让 AI 帮你整理成结构化「问题定义 One-pager」。 |
| Prompt 模版 | 业务背景梳理 你现在扮演资深 B2D SaaS 产品顾问。 背景信息： - 产品：简述MaaS平台，包含模型列表、现有计费模式，如按量计费、后付费等简述 MaaS 平台，包含模型列表、现有计费模式，如按量计费、后付费等简述MaaS平台，包含模型列表、现有计费模式，如按量计费、后付费等 - 当前情况：例如：开发者对价格不敏感但怕不可控账单；企业希望预算可预测；现有按量模式购买门槛高例如：开发者对价格不敏感但怕不可控账单；企业希望预算可预测；现有按量模式购买门槛高例如：开发者对价格不敏感但怕不可控账单；企业希望预算可预测；现有按量模式购买门槛高 - 业务目标：提高付费转化率、提高ARPU、降低计费投诉率、提升留存提高付费转化率、提高 ARPU、降低计费投诉率、提升留存提高付费转化率、提高ARPU、降低计费投诉率、提升留存 请输出一份《问题定义草稿》，结构包括： 1. 业务目标 2. 现状与挑战 3. 关键用户群体（开发者个人 / 小团队 / 中大型企业等） 4. 已知事实（用数据或案例支持，如有空缺帮我标出「需要补充的数据」） 5. 待验证的关键问题列表 |
| 期望产出 | 关键是结构，不用太长 - 清晰写出：为什么考虑套餐、服务谁、要影响哪些指标、目前信息缺口有哪些。 |
Step 2：信息收集——用 AI 做系统调研
目标：把「感觉开发者需要套餐」变成「基于数据/反馈的结论」。
| 关键部分 | 详细说明 |
|---|---|
| 数据来源 | > AI 通过 RAG 或接口访问，或直接上传线下整理好的数据 - 平台账单使用数据：长尾高波动、超限频率等 - 工单 / 客服记录：关于费用、限流、复杂度的吐槽 - 市场竞品：OpenAI/Anthropic/阿里/腾讯等套餐方案 - 内部销售 & BD 反馈 |
| Prompt 模板 | 1. 内部数据/工单归纳 你是数据分析 + 客服文本挖掘助手。 输入是一批最近 6 个月的用户反馈和工单内容（已在上下文 / 附件中）。 请按以下要求输出： a. 与「价格/计费/限流」相关的高频问题分类（每类给 2–3 个示例原文片段）。 b. 每类问题背后隐含的需求或情绪（如：可预测性、上手门槛、风控、多人协作）。 c. 标记哪些问题可以通过「套餐订阅」解决，哪些需要别的手段。 2. 竞品套餐扫描 你是资深云服务定价分析师。 请对以下竞品的订阅/套餐模式进行对比分析：列出若干竞品名称或附上资料列出若干竞品名称或附上资料列出若干竞品名称或附上资料。 输出表格: - 套餐档位名称 - 计费维度（token、QPS、项目数、团队成员数等） - 目标客群 - 卖点 & 限制 - 对我们 MaaS 平台的启发（用一句话说明） |
| 期望产出 | - 《用户痛点清单》 - 《竞品套餐模式对比表》 > 带证据的：为什么我们需要做 “订阅套餐 + 明确配额 + 并发保障” |
Step 3：机会空间——用 AI 帮你列出可做哪些「套餐机会」
目标：从“做套餐”拆成多个可选机会：如个人开发者包、团队包、企业包、模型组合包等。
| 关键部分 | 详细说明 |
|---|---|
| Prompt 模板 | 机会地图生成 基于前面的问题定义、用户痛点和竞品分析（已在上下文中）， 你是 MaaS 商业产品负责人，请： 1. 列出 6–10 个潜在「套餐机会点」，每个包括： - 目标用户画像 - 典型使用场景 - 套餐设计思路（按什么维度打包，如 token、QPS、团队成员、模型组合） - 预期解决的痛点 2. 用「影响力 / 可行性 / 与现有架构兼容度」打 1–5 分，并给出推荐优先级。输出为表格。 |
| 期望产出 | - 如： - 「个人开发者成长包」：固定额度 + 小 QPS 保证，解决账单焦虑。 - 「小团队协作包」：多子账号 + 合并账单 + 适度 QPS。 - 「企业稳定生产包」：高 QPS + SLA + 专属支持。 - 给出优先排序结果 → 例如先做「个人+小团队套餐」。 |
Step 4：方案共创——和 AI 一起拉出多套套餐方案对比
选中几个机会后，用 AI 展开具体「产品版本」。
假设我们优先做 3 个档位：Plus / Pro / Max。
| 关键部分 | 详细说明 |
|---|---|
| Prompt 模板 | 1. 多版本方案设计 你是订阅计费产品设计专家。 目标：为我们的 MaaS 平台设计「套餐订阅产品」。 约束： - 计费基础单位：token 消耗为主，可附加 QPS/并发限制。 - 需兼容现有按量后付费模式。 - 避免让用户难以理解，方案数控制在 3–4 个档位。 请输出： a. 3–4 套档位方案（示例：Basic / Pro / Team / Enterprise），每个说明： - 目标用户 - 月/年价格（可用区间，用 X 表示） - 包含额度（token、QPS、用户数/子账号、模型权限等） - 超限策略（限流 / 按量补扣 / 升级引导） - 核心卖点（对用户） - 我方收益与风险点 b. 一个「方案对比表」，方便在内部评审会上展示。 2. 风险与依赖检查 请对上述套餐方案做审视，列出： - 可能的滥用场景 - 成本不可控风险 - 技术依赖（账单系统、限流系统、风控系统） - 法务/合规注意点 并按严重程度排序。 |
| 期望产出 | - 《套餐方案候选对比表》 - 《风险与依赖清单》 > 这些内容会直接进入 PRD 的「方案说明」和「风险评估」。 |
Step 5：最小验证——在真正开发前，把方向用 AI+MVP压一轮
目标：在需求评审前，用最低成本确认：这些套餐逻辑 有需求 & 可理解 & 可接受。
可执行的 AI Native 验证手段：
| 验证方式 | 详细说明 |
|---|---|
| 1. Landing Page + AI 文案 > 用 AI 生成一个「套餐介绍页草稿」+ FAQ，用少量用户测试点击/咨询意愿。 | 文案 & 页面结构 请根据当前选定的套餐方案（见上下文），生成一个「套餐订阅介绍页」结构： - 栏目结构（Hero、套餐对比表、常见问题、使用案例） - 每个套餐 3 行以内的卖点文案 输出 JSON 结构，方便我直接交给前端/设计。 |
| 2. AI 模拟用户评审 | 模拟用户质疑 你分别扮演： - 个人开发者 - 小团队技术负责人 - 企业架构师 根据当前套餐方案和介绍页，提出你可能的疑问、顾虑和反对意见，每个画像不少于 8 条。然后总结我们需要优化的 5 个关键点。 |
| 3. 使用历史数据做「虚拟回放」 | 历史数据检验 基于历史账单与调用数据（假设已导入），请回答： - 如果按现在的套餐梯度划分，有多少比例用户会自然落入每一档？ - 有哪些现有大户可能因为套餐而「降级支出」？ - 有哪些长尾用户可能因此更愿意付费？ 请给出定性结论和需要进一步精算的点。 |
期望产出：
-
《最小验证方案 & 结果摘要》：
- 用户是否看得懂？
- 是否有明显价格/规则雷区？
- 是否存在明显「流失风险」或「滥用窗口」？
这些写进 PRD 的「假设与验证」章节，更便于评审
Step 6：PRD 自动生成与精修——AI 写骨架，你补关键决策
| 关键部分 | 详细说明 |
|---|---|
| Prompt 模板 | 1. 生成 PRD v1.0 你是资深 SaaS 产品经理，请基于当前上下文（问题定义、机会评估、套餐方案、验证结果），生成《MaaS 平台套餐订阅产品 PRD v1.0》。 要求目录为： 1. 背景与目标 2. 用户画像与使用场景 3. 需求范围 - 功能点列表（购买、升级/降级、续费、超限处理、发票、团队成员管理等） 4. 产品方案说明 - 套餐档位定义 - 配额和并发策略 - 计费与对账逻辑（高层描述） - 风控与限制（如防止共享滥用） 5. 最小验证过程与结论（引用 Step 5） 6. 埋点与核心指标（转化率、续费率、超限率、工单投诉率等） 7. 边界与非目标 8. 研发 & 运维依赖（账单系统、身份系统、风控、监控） 用清晰小标题 + 列表形式输出，不要写成散文。 2. 生成评审问题清单 基于该 PRD v1.0，列出在需求评审会上必须确认的 10–15 个关键问题，按「产品 / 技术 / 商务 / 法务」分类。 |
| PM 做什么 | - 手动修：价格区间、正式条款、合规红线。 - 做最终取舍：删掉 AI 写的多余复杂度，确保“首期可落地”。 |
| 期望产出 | - PRD - 评审问题及回应 |
Step 7：设计稿联动生成——需求阶段同时产出 Wireframe Brief
此步就是把 PRD 中的逻辑结构化，给设计/前端一个统一蓝本，可由 AI 直接生成线框或组件说明。
| 关键部分 | 详细说明 |
|---|---|
| Prompt 模板 | 1. 信息架构 & 流程 你是资深 UX 设计师，请基于该 PRD，输出「套餐订阅相关的 IA（信息架构）」和「关键用户流程」。 a. 列出涉及的页面/模块： - 套餐列表页 - 套餐详情页 - 购买/支付流程页 - 套餐管理页（查看额度、用量、并发、账单） - 升级/降级/续费流程 b. 为每个页面说明：必须展示的元素字段、关键按钮、错误/空状态。 c. 输出 2–3 个核心流程的步骤图（文字版 Flow）。 2. Wireframe 文本稿 请将上一步的页面结构转化为低保真 Wireframe 描述： 对每个页面，用「区域划分 + 元素列表」方式描述，例如： - 顶部：导航（Logo、文档、控制台） - 主区域左：套餐卡片列表 - 主区域右：当前选择的套餐详情 - 底部：购买按钮 + 风险提示文案 要求：可以直接交给设计师或生成式设计工具，生成初版界面。 |
| 期望产出 | - 《信息架构 & 流程》 - 《Wireframe Brief》：直接交付给 Figma / 设计同学。 |
五、结语
AI Native 不会取代产品经理，但会重新定义产品经理的工作方式。它让需求不再是一次性的输出，而是一条持续迭代的智能链路。
在这次大模型订阅产品的设计中，我们用一套可复用的“智能需求引擎”验证了 AI 与 PM 共创的价值：
- PM 负责方向、判断与约束；
- AI 负责结构化、探索与生成。
两者互相帮助，才能在有限时间内跑出一个让 10 万开发者认可的方案。
未来的产品设计将越来越像这次实践：
不是让 AI 做完所有事，而是让 AI 与你一起，把每一步做得更快、更完整、更可验证。
而这，也将是下一代产品经理的核心竞争力。
