- 用户问一句,模型答一句。
- 模型通常不主动查企业知识库。
- 没有明确的工具调用和审批边界。
- 容易写出“看起来对,但不贴合系统现状”的文档。
Agent:会规划、会查资料、会用工具、会交付结果的 AI 助理
这节课用“产品录入一个需求,Agent 自动查企业知识库和系统现状,最终生成高质量 PRD”做主线,让零基础也能理解 Agent 怎么真正落地。
录入需求
Agent
一句话听懂 Agent
先别讲 SDK。先讲生活类比:普通 AI 像问答助手,Agent 像能自己推进工作的项目助理。
给奶奶听的版本
Agent 不只是聊天,也不只是 Prompt
面试里要能讲清楚:Agent 比单轮问答多了“流程、工具、状态和验收”。
- 先理解目标,再拆任务步骤。
- 根据需要调用搜索、知识库、数据库、MCP 工具。
- 保留任务状态,能跨多轮继续。
- 有护栏、人工审核、追踪和评估。
Agent 的五个核心零件
一个实用 Agent 通常不是一个提示词,而是一套可运行的工作系统。
脑模型
负责理解、推理、生成内容。复杂任务需要合适的模型和推理策略。
规指令
定义身份、职责、边界、输出格式和质量标准。
手工具
用于查资料、查知识库、读系统文档、调用 API、生成结构化结果。
记状态
保留任务进度、已查资料、待确认问题、版本记录。
栏护栏
检查输入、输出和工具调用,敏感操作要人工确认。
评评估
用测试集、追踪和评分标准不断改进 Agent 表现。
主案例:从产品一句话到企业级 PRD
例子:产品经理在系统里录入“给订单系统增加批量导入订单功能”,Agent 要生成一版可评审 PRD。
需求名称:订单批量导入
背景:运营每周需要把线下渠道订单录入系统,手工录入很慢。
目标:支持上传 Excel,一次导入多笔订单。
期望上线:下个迭代
已知限制:需要校验手机号、商品 SKU、收货地址;不能影响现有订单创建流程。
第一步:需求录入和澄清
高质量 PRD 的第一步不是写文档,而是把含糊需求变成可分析输入。
谁用户和场景
谁在什么场景下使用?运营、商家、财务、客服的诉求可能完全不同。
痛问题和指标
现在痛点是什么?要减少多少时间、错误、成本或投诉?
边范围和边界
这次做什么,不做什么?哪些流程不能改,哪些规则必须沿用?
Agent 应该自动提出的澄清问题
第二步:查资料和查知识库
企业 PRD 最大的问题不是文笔,而是能不能基于企业真实资料写。
史历史 PRD
找类似功能:导入、订单创建、异常处理、日志、审批。
规业务规则
订单状态流、权限规则、库存规则、财务规则、风控规则。
技系统资料
接口文档、数据库表、字段字典、事件流、已有服务边界。
外外部参考
竞品、行业规范、Excel 模板习惯、合规要求。
检索目标:
1. 找订单创建现有流程和状态流。
2. 找历史“批量导入”或“Excel 导入”类需求。
3. 找商品 SKU、库存、地址、手机号校验规则。
4. 找订单权限、操作日志、异常回滚规则。
5. 找测试用例或线上事故,识别历史风险。
检索输出:
- 每条资料的来源链接
- 与本需求相关的结论
- 可信度:已确认 / 推测 / 待产品确认
第三步:贴合企业系统现状
好 PRD 不是“理想功能说明”,而是“能落在当前系统里的方案”。
流流程现状
现有订单创建、支付、库存扣减、发货、取消流程是什么?新功能插在哪里?
数数据现状
订单表、商品表、用户表、地址表有哪些必填字段?Excel 模板如何映射?
权权限现状
哪些角色能导入、查看、下载失败明细、重新导入、撤销导入?
风风险现状
是否会绕过风控、库存、价格、优惠、财务对账或售后流程?
Agent 输出的“现状对齐表”
第四步:生成一版高质量 PRD
PRD 不只是“写得像文档”,而是能让产品、研发、测试、运营都拿来评审。
1背景和目标
说明为什么做、解决什么问题、成功指标是什么。
2用户和场景
谁使用、什么时候使用、前置条件和触发条件是什么。
3范围和非范围
本期做什么、不做什么,避免评审时无限扩张。
4业务流程
主流程、异常流程、状态流、审批流和通知流。
5功能规则
字段、校验、权限、错误提示、日志、导入结果。
6验收标准
测试可执行的 Given / When / Then,覆盖正常和异常场景。
7数据和埋点
导入成功率、失败原因分布、处理耗时、操作人和任务记录。
8风险和待确认
明确依赖、风险、未决策问题和需要人工确认的假设。
## 功能范围
本期支持运营角色上传 Excel 批量创建订单,系统异步校验并生成导入任务结果。
本期不支持自动扣款、不支持跨店铺合并订单、不支持导入后批量修改。
## 校验规则
1. 手机号:必须符合现有订单创建接口的手机号校验规则。
2. SKU:必须存在且处于可售状态;库存不足时标记该行失败。
3. 地址:省市区和详细地址必填,缺失时标记该行失败。
## 待确认问题
- 部分成功是否允许提交?建议允许部分成功,并提供失败明细下载。
- 同一批次中重复手机号和 SKU 是否合并?建议不合并,逐行生成订单。
护栏和人工审核:别让 Agent 自己拍板
PRD 会影响研发排期和业务规则,Agent 可以辅助,但不能越权决策。
输输入护栏
需求过于模糊、缺少业务目标、涉及敏感合规时,先阻断或要求澄清。
工工具护栏
查知识库、读内部文档、调用系统接口时要做权限控制和审计。
出输出护栏
生成 PRD 后检查是否编造事实、缺少来源、遗漏异常流程。
追踪和评估:让 Agent 越用越靠谱
企业 Agent 不能只看一次输出,要能追踪每次怎么查、怎么判断、哪里失败。
练习:设计一个 PRD Agent
这三题用来训练她把 Agent 讲成业务系统,而不是只讲概念。
练习题
- 1产品只说“做一个会员积分功能”,Agent 应该先问哪 5 个澄清问题?
- 2为 PRD Agent 设计 6 个必须查询的知识库来源。
- 3写一个 PRD 质量评分表,至少包含 5 个维度。
参考答案 1
积分用户是谁?积分怎么获得和消耗?是否过期?是否影响财务或营销成本?当前会员系统有哪些等级和权益?本期做哪些场景、不做哪些场景?
参考答案 2
历史 PRD、产品手册、业务规则文档、接口文档、数据库字典、线上问题单、客服 FAQ、运营 SOP、权限矩阵、测试用例库。
参考答案 3
业务目标清晰度、范围边界清晰度、系统现状贴合度、规则完整性、异常流程覆盖、验收标准可测试性、资料来源可追溯、风险和待确认问题完整性。
面试怎么说:短答案和长答案
面试时先讲 Agent 的定义,再用 PRD 案例证明你理解真实业务落地。
Agent 是能围绕目标自主推进多步骤任务的 AI 应用。
它不只是回答问题,而是会规划、调用工具、读取知识库、保持状态,并通过护栏和人工审核控制风险。比如 PRD Agent 会先澄清需求,再查企业知识库和系统现状,最后生成可评审的 PRD。
我会从三个层面理解 Agent。
第一是能力层:Agent 封装模型、指令、工具、状态和结构化输出,能持续完成多步骤任务。
第二是流程层:以 PRD 生成举例,它要完成需求录入、澄清、检索知识库、分析系统现状、生成文档、评审迭代。
第三是治理层:企业落地必须有权限、护栏、人工审核、追踪和评估,避免 Agent 编造业务规则或越权操作。
常见追问
一页复习:面试前 5 分钟看这个
把这一页说顺,就能把 Agent 和 PRD 生成案例讲完整。