ENTRY FDE PRODUCT · 75 MIN
不会提需求的人，用 AI 也做不出产品
先不急着把页面做漂亮，也不急着 Vibe Coding。先训练一件事：把一个模糊愿望，表达成 AI 能执行、研发能评估、业务能验收的 AI 产品需求。
“我想要一个差不多的 AI 效果”
这一句只能表达感受，AI 只能猜：入口在哪里、字段是什么、状态怎么变、数据存不存、失败怎么处理。
对象、动作、状态、数据、规则、验收
把想法拆成可执行表达。AI 才不是替你猜，而是替你推进。
AI 降低的是执行门槛，不是定义门槛。
过去你讲不清需求，产品经理、设计师、研发会替你翻译。现在 AI 把执行力直接放在你面前，真正难的反而变成：你能不能把想法讲到 AI 能执行。
会聊天，不等于会提需求
“高级一点”“顺一点”“智能一点”是感受，不是需求。
AI 能执行，但不能替你定义合格
你不给边界，它就会猜；它猜得越快，项目越容易偏。
产品基础，是为了学会表达
不要求每个人做开发，但要讲清页面、字段、状态、信息来源、保存和验收。
FDE 产品的第一项能力：定义问题
人负责定义，AI 负责执行，人再负责验收和修正。
OPENING STORY
先看一个真实反例
一个项目推进到按钮呼吸感、侧拉抽屉、字段保存时，问题暴露出来了：真正卡住的不是 AI 工具，而是产品表达结构。
“按钮动一点，页面高级一点”
AI 会按常见模式猜一个效果。它可能做出永远闪动的按钮，也可能完全不知道点击后要禁用、等待、失败恢复和记录日志。
“什么条件下出现什么反馈”
页面加载后弱提示一次；用户 10 秒未操作再提示一次；点击后停止动效，进入处理中；失败时恢复可点并展示失败原因。
图 1：从愿望到需求，中间缺的是可执行表达
练习：把“好看一点、智能一点、保存一下”逐句翻译成对象、动作、状态、数据、规则和结果。
SELF CHECK
用一把尺子，看你现在卡在哪一层
不要先问会不会用 AI。先问：能不能把需求讲到可执行、可评估、可验收。多数初学者卡在 L0 到 L2 之间。
愿望表达
只会说“我要一个工具”“页面好看点”“更智能一点”。AI 自由发挥，控制权最低。
界面表达
能说按钮、列表、弹窗、表单，但说不清出现条件和变化规则。
交互表达
能说触发、反馈、状态、异常、确认、撤销，产物开始接近可用。
数据表达
能说字段来源、保存位置、读取规则、权限范围、历史记录和同步关系。
闭环表达
能把目标、流程、数据、边界、验收和复盘连起来，让 AI 在可控范围内迭代。
CORE METHOD
AI 需求 8 段式：把想法写成产品实现
AI 需求本质上还是需求：解决一个具体业务问题的产品实现。不同的是，它要额外写清选择哪类 AI 能力、AI 按什么说明工作、依据从哪里来、错了如何发现、哪些地方必须人工确认。
为什么要做
谁提出，哪个业务问题，当前痛在哪里，为什么现在必须解决。
做完有什么收益
效率、质量、成本、风险、体验，最好对应可观察指标。
在哪里做成什么样
系统入口、页面位置、对话框、侧边栏、弹窗、表单或审批节点。
需要实现什么
页面、输入、输出、历史记录、设置项、语音图片、逐步显示答案、保存。
跟谁连接
上下游系统、信息来源、字段、权限、触发来源、保存位置。
用户怎么走
从哪进来，点哪里，输入什么，拿到什么，如何继续使用。
每个功能怎么验
字段、颜色、状态、动作、异常、使用统计和结果统计都要能说清。
AI 选择与风险边界
AI 能力选择、提示词、知识库、长期记忆、检查样本、人工断点和团队角色。
SIX CARDS
补产品表达结构，先练这六张卡片
不要从学一门语言开始。先从把一个小需求讲清楚开始。每次提需求前，把六张卡写出来。
场景卡
谁在什么业务节点遇到什么问题？现在怎么做？哪里慢、错、重复或不可控？
对象卡
页面、按钮、表单、抽屉、对话框、智能体、知识库分别是什么？在哪里出现？
动作状态卡
谁点击？什么时候触发？加载、成功、失败、撤销、禁用、重试怎么变化？
数据卡
输入字段从哪里来？保存到哪里？谁能看？保存多久？失败后怎么恢复？
AI 能力卡
AI 读什么、判断什么、生成什么、引用什么依据、什么时候必须停下来让人确认？
验收风险卡
怎么测？几次算通过？多久响应？错了谁兜底？哪些行为不能自动执行？
CASE STUDY
贯穿案例：Skill Platform 的 AI 需求怎么讲
用 Skill Platform 案例看一份需求如何写完整。它不是一句“做一个 Skill 平台”，而是从业务痛点、产品价值、功能清单、连接关系、操作流程、详细字段、风险验收一路展开。
“我们要一个平台，把 AI 能力管起来。”
这句话是方向，不是需求。它没有说明为什么管、管什么、谁来用、入口在哪、流程怎么走、AI 具体做什么、做完怎么验收。
“流程资产平台：从流程节点挖掘 Skill，并完成创建、审批、发布、复用。”
这就开始接近产品需求：它有业务对象、有流程、有生命周期、有角色、有上架机制，也能继续拆页面和信息来源。
图 2：Skill Platform 产品链路
先看见一件事：平台不是功能堆叠，而是一条从流程文件到 Skill 上架再到复用的产品链路。
| 需求模块 | 为什么要写 | 需要说清楚 |
|---|---|---|
| 需求背景AI 能力无序建设、流程与 AI 脱节、资产无法沉淀 | 背景不是口号，要写出当前问题的业务后果。 | “现在谁痛、为什么痛、痛在流程哪个节点。” |
| 产品价值减少重复建设、提升匹配度、资产可视可管 | 价值要能被管理层判断，不只写“提升效率”。 | “做完后哪个指标会变、怎么观察。” |
| 功能清单租户、架构树、流程文件、AI 挖掘、Skill 管理、审批、广场、使用说明 | 功能清单不是堆模块，要能串成产品链路。 | “用户先做什么，再做什么，哪个模块承接哪个模块。” |
| 连接关系使用企业选定 AI 能力，第一期不接外部协同工具 | 写清接什么，也写清不接什么。 | “输入输出、外部系统、版本边界、暂不实现。” |
| 验收标准架构树、流程文件、AI 规划、审批、权限、性能 | AI 需求必须可测，不能只说效果好。 | “给测试样本、成功标准、异常处理和人工确认点。” |
DETAIL WRITING
功能清单不能只写“做一个智能体”
新产品经理最容易漏掉的不是大功能，而是隐性功能：设置项、历史记录、保存、权限、使用统计、异常、结果统计和人工确认。
| 如果你写 | 建议改成 | 为什么 |
|---|---|---|
| 做一个对话框 | 在某系统某页面右侧构建对话面板，包含输入框、消息列表、会话标题、加载状态、错误提示。 | 页面形态清楚，研发才知道做在哪里。 |
| 接入 AI 能力 | 说明选择哪类 AI、AI 按什么提示词工作、是否需要知识库、能调用哪些能力、结果是否逐步显示、失败时怎么办。 | AI 能力不是一个按钮，是一组工作说明。 |
| 支持上传资料 | 支持 PDF / DOCX / XLSX，限制 10MB，解析后存储文本，解析失败提示重试或手工粘贴。 | 文件、限制、异常和存储都要写。 |
| 结果保存一下 | 保存到项目配置 / 用户会话 / 历史记录？谁能看？是否可删除？是否保留修改痕迹？ | 保存是产品判断，不是技术小事。 |
| 输出图表 | AI 先按固定栏目给出结果，页面再展示成图表；图表展示失败时显示表格；保留原始数据下载。 | AI 生成内容和页面展示方式要分清。 |
AI-SPECIFIC
AI 需求比传统需求多写什么
传统产品说明也写背景、功能、流程、验收。AI 需求额外要写清“AI 如何判断、依据从哪来、错了如何发现、哪些地方不能自动做”。
AI 能力选择
不只写名字。要写选择标准：复杂问题处理能力、速度、成本、能读多少材料、是否支持图片或语音、是否符合公司要求。
AI 工作说明
角色、任务、需要读取的信息、处理步骤、输出样式、拒绝规则、人工确认点。
知识库与记忆
知识来源、更新频率、冲突处理、引用依据、长期记忆是否启用。
可调用能力
AI 能使用哪些内部能力，需要带入哪些信息，失败时怎么处理。
输出与展示
一次性展示还是逐步展示？文本、表格、图表、文件分别怎么呈现。
运行记录
输入摘要、命中的知识、AI 输出、人工修改是否记录。
测试集
正常、模糊、资料不足、高风险、攻击提示词都要准备样本。
风险护栏
审批、付款、处罚、签署、对外承诺等动作必须保留人工断点。
ACCEPTANCE
验收标准：不要写“效果好”，要写“怎么测”
AI 产品跟传统产品不一样，它需要持续测试。写需求时就要想清楚：用什么样本测、测多少次、错了怎么办、谁来复核。
| 类型 | 错误写法 | 可验收写法 |
|---|---|---|
| 准确性 | AI 回答要准确 | 准备 30 条业务样本，核心字段识别正确率不低于 90%，错误样本进入复盘池。 |
| 响应速度 | 响应要快 | 文本场景第一个字 1 秒内出现，完整答案 8 秒内返回；超时显示重试入口。 |
| 资料不足 | 缺资料时提醒 | 缺少关键字段时不生成结论，只列出缺失项并追问；不得编造金额、客户名、责任人。 |
| 高风险动作 | 风险场景转人工 | 涉及审批、付款、处罚、签署、对外承诺时，只输出分析草稿，必须人工确认。 |
| 连续迭代 | 上线后优化 | 每周抽样 20 条失败会话，归类为提示词、知识库、工具、流程或用户输入问题。 |
COPY TEMPLATES
可直接复制的 5 个提示词
这些提示词不是让 AI 替你拍脑袋，而是逼你补上下文。把里面的占位内容换成自己的业务场景即可。
需求澄清：把愿望拆成问题
我现在有一个模糊 AI 产品想法：【粘贴想法】。 请你不要直接给方案，先用产品经理视角帮我澄清需求。 按以下维度追问我： 1. 业务背景：谁提出，为什么现在要做？ 2. 使用者：谁用，在什么流程节点用？ 3. 产品形态：入口在哪里，页面长什么样？ 4. 输入输出：用户输入什么，AI 输出什么？ 5. 数据与系统：需要读取哪些数据，是否写回系统？ 6. AI 能力：需要知识库、提示词、AI 能力选择、可调用能力或长期记忆吗？ 7. 验收标准：怎么判断做完且做对？ 每个维度最多问 3 个关键问题。
AI 需求卡：从回答生成初稿
请根据下面的业务回答，生成一份《AI 需求卡》。 要求： 1. 不要写空话，所有内容都要能被产品、研发、业务评审。 2. 按“背景、目标、使用者、入口形态、功能清单、信息来源和保存、AI 能力、验收标准、风险边界、参与角色”输出。 3. 对不确定内容标注【待确认】，不要替我编造。 4. 最后列出 10 个下一步评审问题。 业务回答： 【粘贴澄清结果】
功能清单补齐：找隐性需求
请审查下面这份 AI 产品功能清单，帮我补齐容易遗漏的隐性需求。 重点检查： - 页面入口、对话面板、输入框、历史记录、配置项 - 知识库、长期记忆、AI 能力设置、提示词版本 - 文件/图片/语音输入，逐步显示答案，图表展示 - 信息读取、结果保存、权限、运行记录、使用统计 - 异常、超时、失败重试、人工确认点 输出格式：遗漏项 / 为什么重要 / 建议写进产品说明书的句子。 功能清单： 【粘贴功能清单】
连接关系图：生成可画图说明
请根据下面的 AI 产品需求，帮我生成“产品连接关系图”的文字版。 要求： 1. 列出用户入口、页面、AI 能力、知识库、保存位置、外部业务系统。 2. 写清每条连接带入什么信息、返回什么结果、什么时候触发、是否保存。 3. 标注第一期接入范围和明确不做的范围。 4. 用普通文字画出从左到右的连接顺序。 需求内容： 【粘贴需求】
验收样本：让 AI 产品可测
请为下面的 AI 需求设计验收测试集。 至少包含： 1. 正常输入 10 条 2. 模糊输入 5 条 3. 资料不足 5 条 4. 高风险场景 5 条 5. 提示词攻击或越权请求 5 条 每条写：测试输入、期望表现、通过标准、失败后的处理建议。 AI 需求： 【粘贴需求】
LIVE PRACTICE
现场练习：每组写出一份 AI 需求初稿
不要只停留在听懂。结束前，每组完成一页 AI 需求卡，能拿去找 FDE 开发或研发继续沟通。
第 1 步｜选场景（5 分钟）
每组选择一个真实业务问题，要求高频、低敏、结果可判断。
第 2 步｜写六张卡（12 分钟）
场景卡、对象卡、动作状态卡、数据卡、AI 能力卡、验收风险卡。
第 3 步｜生成 AI 需求卡（8 分钟）
用提示词把六张卡整理成需求初稿，标注待确认项。
第 4 步｜同伴评审（7 分钟）
互相检查：有没有入口、数据、状态、AI 能力、验收和人工断点。
第 5 步｜现场修订（8 分钟）
选择 2 组案例现场修改，把“愿望表达”改成“产品表达”。
结束时必须带走的东西
一页 AI 需求卡：背景、目标、使用者、产品形态、功能清单、信息来源和保存、AI 能力、验收标准、风险边界、团队角色。
下一步动作：把需求卡交给 AI 生成原型，再拿“需求 + 原型”去找 FDE 开发或技术评审。