AI CXYKK AI 教程
Agent 与 PRD 生成零基础课件 从产品口述需求到企业级 PRD 的完整链路
Beginner Friendly

Agent:会规划、会查资料、会用工具、会交付结果的 AI 助理

这节课用“产品录入一个需求,Agent 自动查企业知识库和系统现状,最终生成高质量 PRD”做主线,让零基础也能理解 Agent 怎么真正落地。

产品
录入需求
PRD
Agent
高质量 PRD
知识库 系统文档 竞品资料 历史需求
第一节

一句话听懂 Agent

先别讲 SDK。先讲生活类比:普通 AI 像问答助手,Agent 像能自己推进工作的项目助理。

建议 8 分钟
最简单定义 Agent 是一个能围绕目标持续工作的 AI 应用:它会规划步骤、调用工具、读取资料、保持上下文,必要时让不同专家协作,直到完成多步骤任务。

给奶奶听的版本

你说 “普通聊天 AI 像你问一句它答一句。”
再说 “Agent 像一个项目助理,你交代目标,它会自己拆步骤、找资料、办事情、最后交付结果。”
最后说 “比如生成 PRD,它不是直接编一篇,而是先问清楚需求,再查现有系统,再写文档。”
第二节

Agent 不只是聊天,也不只是 Prompt

面试里要能讲清楚:Agent 比单轮问答多了“流程、工具、状态和验收”。

建议 10 分钟
普通问答:用户推着走
  • 用户问一句,模型答一句。
  • 模型通常不主动查企业知识库。
  • 没有明确的工具调用和审批边界。
  • 容易写出“看起来对,但不贴合系统现状”的文档。
Agent 工作流:目标驱动
  • 先理解目标,再拆任务步骤。
  • 根据需要调用搜索、知识库、数据库、MCP 工具。
  • 保留任务状态,能跨多轮继续。
  • 有护栏、人工审核、追踪和评估。
PRD 场景里的关键差别 普通模型可能“凭经验写 PRD”;PRD Agent 应该“基于企业资料、系统现状、业务约束和评审标准写 PRD”。
第三节

Agent 的五个核心零件

一个实用 Agent 通常不是一个提示词,而是一套可运行的工作系统。

建议 12 分钟

模型

负责理解、推理、生成内容。复杂任务需要合适的模型和推理策略。

指令

定义身份、职责、边界、输出格式和质量标准。

工具

用于查资料、查知识库、读系统文档、调用 API、生成结构化结果。

状态

保留任务进度、已查资料、待确认问题、版本记录。

护栏

检查输入、输出和工具调用,敏感操作要人工确认。

评估

用测试集、追踪和评分标准不断改进 Agent 表现。

设计判断 当一个任务需要“查很多资料、跨多步执行、保留上下文、需要审批和质量验收”时,就比普通 Prompt 更适合做成 Agent。
第四节

主案例:从产品一句话到企业级 PRD

例子:产品经理在系统里录入“给订单系统增加批量导入订单功能”,Agent 要生成一版可评审 PRD。

建议 15 分钟
1 录入需求 产品输入目标、背景、期望用户和初步范围。
2 澄清问题 Agent 找出缺口:用户、规则、边界、指标。
3 查知识库 检索历史 PRD、FAQ、业务规则、竞品资料。
4 查系统现状 读取接口、数据字典、权限、流程、已有模块。
5 生成 PRD 输出目标、范围、流程、规则、验收和风险。
6 评审迭代 让产品、研发、测试、运营分别检查。
产品录入示例 Agent 的原始输入
需求名称:订单批量导入
背景:运营每周需要把线下渠道订单录入系统,手工录入很慢。
目标:支持上传 Excel,一次导入多笔订单。
期望上线:下个迭代
已知限制:需要校验手机号、商品 SKU、收货地址;不能影响现有订单创建流程。
第五节

第一步:需求录入和澄清

高质量 PRD 的第一步不是写文档,而是把含糊需求变成可分析输入。

建议 12 分钟

用户和场景

谁在什么场景下使用?运营、商家、财务、客服的诉求可能完全不同。

问题和指标

现在痛点是什么?要减少多少时间、错误、成本或投诉?

范围和边界

这次做什么,不做什么?哪些流程不能改,哪些规则必须沿用?

Agent 应该自动提出的澄清问题

业务问题 每次大概导入多少订单?哪些渠道?失败订单如何处理?
规则问题 SKU 不存在、库存不足、地址不完整、手机号重复时怎么处理?
权限问题 谁能导入?是否需要审批?导入记录谁能查看和撤销?
验收问题 导入成功率、处理时长、错误提示、日志追踪有什么要求?
不要让 Agent 乱补 澄清阶段要明确:缺失信息必须标记为“待确认”,不能为了文档完整而编造业务规则。
第六节

第二步:查资料和查知识库

企业 PRD 最大的问题不是文笔,而是能不能基于企业真实资料写。

建议 15 分钟

历史 PRD

找类似功能:导入、订单创建、异常处理、日志、审批。

业务规则

订单状态流、权限规则、库存规则、财务规则、风控规则。

系统资料

接口文档、数据库表、字段字典、事件流、已有服务边界。

外部参考

竞品、行业规范、Excel 模板习惯、合规要求。

Agent 检索计划示例 先列问题,再查资料
检索目标:
1. 找订单创建现有流程和状态流。
2. 找历史“批量导入”或“Excel 导入”类需求。
3. 找商品 SKU、库存、地址、手机号校验规则。
4. 找订单权限、操作日志、异常回滚规则。
5. 找测试用例或线上事故,识别历史风险。

检索输出:
- 每条资料的来源链接
- 与本需求相关的结论
- 可信度:已确认 / 推测 / 待产品确认
知识库不是越多越好 Agent 要做“检索 + 摘要 + 证据引用”。PRD 里的关键规则最好能追溯到资料来源,否则评审时很难服众。
第七节

第三步:贴合企业系统现状

好 PRD 不是“理想功能说明”,而是“能落在当前系统里的方案”。

建议 15 分钟

流程现状

现有订单创建、支付、库存扣减、发货、取消流程是什么?新功能插在哪里?

数据现状

订单表、商品表、用户表、地址表有哪些必填字段?Excel 模板如何映射?

权限现状

哪些角色能导入、查看、下载失败明细、重新导入、撤销导入?

风险现状

是否会绕过风控、库存、价格、优惠、财务对账或售后流程?

Agent 输出的“现状对齐表”

已有能力 系统已有单笔订单创建接口,可复用手机号、SKU、地址校验。
缺口 缺批量任务表、导入结果明细、失败原因下载、异步处理进度。
影响面 订单服务、商品服务、库存服务、权限中心、操作日志、消息通知。
待确认 导入失败是否允许部分成功?库存不足时是否阻断整批?
第八节

第四步:生成一版高质量 PRD

PRD 不只是“写得像文档”,而是能让产品、研发、测试、运营都拿来评审。

建议 18 分钟

1背景和目标

说明为什么做、解决什么问题、成功指标是什么。

2用户和场景

谁使用、什么时候使用、前置条件和触发条件是什么。

3范围和非范围

本期做什么、不做什么,避免评审时无限扩张。

4业务流程

主流程、异常流程、状态流、审批流和通知流。

5功能规则

字段、校验、权限、错误提示、日志、导入结果。

6验收标准

测试可执行的 Given / When / Then,覆盖正常和异常场景。

7数据和埋点

导入成功率、失败原因分布、处理耗时、操作人和任务记录。

8风险和待确认

明确依赖、风险、未决策问题和需要人工确认的假设。

PRD Agent 输出片段示例 展示“有证据、有边界、有待确认”
## 功能范围
本期支持运营角色上传 Excel 批量创建订单,系统异步校验并生成导入任务结果。
本期不支持自动扣款、不支持跨店铺合并订单、不支持导入后批量修改。

## 校验规则
1. 手机号:必须符合现有订单创建接口的手机号校验规则。
2. SKU:必须存在且处于可售状态;库存不足时标记该行失败。
3. 地址:省市区和详细地址必填,缺失时标记该行失败。

## 待确认问题
- 部分成功是否允许提交?建议允许部分成功,并提供失败明细下载。
- 同一批次中重复手机号和 SKU 是否合并?建议不合并,逐行生成订单。
第九节

护栏和人工审核:别让 Agent 自己拍板

PRD 会影响研发排期和业务规则,Agent 可以辅助,但不能越权决策。

建议 12 分钟

输入护栏

需求过于模糊、缺少业务目标、涉及敏感合规时,先阻断或要求澄清。

工具护栏

查知识库、读内部文档、调用系统接口时要做权限控制和审计。

输出护栏

生成 PRD 后检查是否编造事实、缺少来源、遗漏异常流程。

必须人工确认的内容 业务规则取舍、上线范围、影响排期、合规风险、跨系统改造、可能产生真实数据变更的工具调用,都应该进入人工评审。
第十节

追踪和评估:让 Agent 越用越靠谱

企业 Agent 不能只看一次输出,要能追踪每次怎么查、怎么判断、哪里失败。

建议 12 分钟
1 记录 Trace 保留模型调用、工具调用、资料来源和人工审核节点。
2 收集样例 把真实需求、好 PRD、失败 PRD 变成测试集。
3 设评分表 完整性、准确性、现状贴合度、可测试性、风险标注。
4 对比版本 比较不同 Prompt、不同检索策略、不同 Agent 拆分。
5 持续改进 把失败原因写回指令、工具、知识库或护栏。
PRD Agent 的验收标准 不只看“文档写得像不像”,更要看:有没有引用资料、有没有贴合当前系统、有没有暴露待确认问题、研发和测试能不能据此行动。
第十一节

练习:设计一个 PRD Agent

这三题用来训练她把 Agent 讲成业务系统,而不是只讲概念。

建议 18 分钟

练习题

  • 1产品只说“做一个会员积分功能”,Agent 应该先问哪 5 个澄清问题?
  • 2为 PRD Agent 设计 6 个必须查询的知识库来源。
  • 3写一个 PRD 质量评分表,至少包含 5 个维度。
参考答案 1

积分用户是谁?积分怎么获得和消耗?是否过期?是否影响财务或营销成本?当前会员系统有哪些等级和权益?本期做哪些场景、不做哪些场景?

参考答案 2

历史 PRD、产品手册、业务规则文档、接口文档、数据库字典、线上问题单、客服 FAQ、运营 SOP、权限矩阵、测试用例库。

参考答案 3

业务目标清晰度、范围边界清晰度、系统现状贴合度、规则完整性、异常流程覆盖、验收标准可测试性、资料来源可追溯、风险和待确认问题完整性。

第十二节

面试怎么说:短答案和长答案

面试时先讲 Agent 的定义,再用 PRD 案例证明你理解真实业务落地。

建议 15 分钟
30 秒回答

Agent 是能围绕目标自主推进多步骤任务的 AI 应用。

它不只是回答问题,而是会规划、调用工具、读取知识库、保持状态,并通过护栏和人工审核控制风险。比如 PRD Agent 会先澄清需求,再查企业知识库和系统现状,最后生成可评审的 PRD。

3 分钟展开

我会从三个层面理解 Agent。

第一是能力层:Agent 封装模型、指令、工具、状态和结构化输出,能持续完成多步骤任务。

第二是流程层:以 PRD 生成举例,它要完成需求录入、澄清、检索知识库、分析系统现状、生成文档、评审迭代。

第三是治理层:企业落地必须有权限、护栏、人工审核、追踪和评估,避免 Agent 编造业务规则或越权操作。

常见追问

Agent 和 Prompt 有什么区别?
Prompt 是给模型的一段指令;Agent 是一个运行系统,除了指令,还包含工具、状态、流程、护栏和评估。
PRD Agent 为什么不能直接生成文档?
因为企业 PRD 必须贴合现有系统和业务规则。直接生成容易编造规则,所以要先查知识库、查系统现状、标记待确认问题。
什么时候要拆成多个 Agent?
当不同环节需要不同工具、权限、模型、输出风格或审批策略时,可以拆成需求澄清 Agent、资料检索 Agent、系统分析 Agent、PRD 撰写 Agent、评审 Agent。
第十三节

一页复习:面试前 5 分钟看这个

把这一页说顺,就能把 Agent 和 PRD 生成案例讲完整。

建议 5 分钟
定义:Agent 是能规划、调用工具、保持状态、协作并完成多步骤任务的 AI 应用。
区别:Prompt 是指令;Agent 是工作系统;MCP 是连接外部工具和数据的协议;Skill 是可复用工作说明书。
PRD 流程:录入需求 -> 澄清问题 -> 查知识库 -> 查系统现状 -> 生成 PRD -> 评审迭代。
资料来源:历史 PRD、业务规则、接口文档、数据字典、权限矩阵、测试用例、线上问题、运营 SOP。
PRD 质量:目标清楚、范围明确、贴合现状、规则完整、异常覆盖、验收可测试、风险可追溯。
企业治理:权限控制、护栏、人工审核、Trace、评估集和持续优化。
面试金句:“PRD Agent 的价值不是替产品写作文,而是把需求澄清、知识检索、系统分析和文档生成串成可追踪、可评审的工作流。”