这一课解决三个问题: 智能体(AI Agent)到底是什么, 为什么一段写得好的提示词就能构建出一个最简版本, 以及这种”纯提示词智能体”的能力边界画在哪里。学完你可以自己动手做一个能用的智能体——不写一行代码。
很多产品经理对智能体的印象停留在两个极端: 要么觉得它是营销黑话, 就是个聊天机器人换了皮; 要么觉得它是只有算法团队才碰得动的黑科技。两种印象都不对。智能体的最小形态简单到你今天下午就能做出来, 而它和普通问答的区别又真实到足以改变产品设计思路。
文末会给出一个”需求澄清官”智能体的提示词全文, 你可以直接复制到任何支持自定义系统提示词的对话产品里运行, 让它逐轮追问用户, 直到把一个模糊的想法澄清成一份能交给开发团队的需求说明。
智能体的最小定义: 大模型 + 目标 + 循环
先给白话定义: 智能体是一个围绕明确目标持续行动的 AI 程序。它和普通对话的区别不在模型多聪明, 而在于三个要素是否齐备:
- 大模型(LLM): 提供理解和生成能力的引擎, 也就是你在第 1 课认识的那个”下一词预测机器”。
- 目标: 一个清晰的、可判断是否完成的任务终点。比如”把用户需求澄清到可开发的程度”, 而不是”陪用户聊聊”。
- 循环: 不是一问一答就结束, 而是”行动、看结果、决定下一步”, 反复推进, 直到目标达成或明确失败。
这三样东西里, 模型是现成的, 目标和循环是你设计出来的。这就是产品经理能直接上手的原因: 最简版的智能体, 目标和循环都可以只用文字描述, 写进提示词里。
为什么一段提示词就够了
一个最简智能体的提示词由三部分构成:
- 角色: 它是谁, 立场是什么。角色决定它用什么口径判断事情。
- 规则: 什么必须做、什么绝对不做。规则是它的行为护栏。
- 流程: 按什么顺序推进任务, 什么条件下算完成。流程就是那个”循环”的文字版。
业界那些看起来吓人的智能体系统, 比如开源的通用 Agent 架构图里画的规划器、记忆模块、工具层, 本质都是在这个最小骨架上加零件。骨架本身没有任何神秘的地方。如果你想沿着这条线看更多智能体的真实案例, 站内的 AI Agent 专题是一个持续更新的入口。
一个判断练习: 你们公司那个”智能客服”, 是智能体吗? 用三要素卡一下——它有目标吗(解决用户问题, 还是只负责回答一句)? 有循环吗(会追问、会核实、会升级工单, 还是答完即止)? 答案往往是: 它只是一个套了话术的问答机, 离智能体差的不是技术, 是设计。
单轮问答和带目标的多轮, 差在哪
你平时用 ChatGPT 是单轮模式: 你问, 它答, 每一轮的质量取决于你这一轮问得好不好。主导权在你手里, 模型是个被动的应答器。
智能体把主导权翻转了过来。你只给一个起点, 它负责推进: 该问什么它来问, 信息够不够它来判断, 什么时候交付它来决定。用户体验上的差别非常直观——一个是”你得会用它”, 另一个是”它会用你给的信息”。
社区里流行一种说法, 把这个玩法叫”召唤赛博精灵”: 用一段咒语一样的提示词, 唤出一个有性格、有使命的 AI 角色。说法很玄, 本质很朴素: 所谓召唤, 就是把目标和流程写进系统提示词(system prompt)。系统提示词是第 2 课讲过的概念, 简单说就是对话开始前塞给模型的那段”人设与规矩”, 用户看不见, 但整场对话模型都会遵守。
举个对比。同样是帮用户规划旅行:
- 单轮问答版: 用户问”帮我规划三天的成都行程”, 模型直接输出一份行程。看起来能用, 但它不知道用户带不带孩子、吃不吃辣、预算多少——它把所有不知道的事都用默认值填掉了。
- 智能体版: 提示词里写明”你的目标是产出一份用户确认过关键约束的行程, 在弄清预算、同行人、饮食禁忌之前不要输出行程”。于是它先追问三个问题, 拿到答案再规划, 最后还会问一句”这个节奏可以吗, 要不要再松一点”。
两者用的是同一个模型。差别全部来自那段提示词里写没写”目标”和”没达到目标之前该干什么”。这是本课最重要的一个认知: 智能体首先是一种设计, 其次才是一种技术。
ReAct: 让模型”像在做事”的循环
学术界给这种循环起过一个名字: ReAct, 取自 Reasoning(推理)和 Acting(行动)。不用记论文细节, 记住它描述的节奏就行:
- 思考(Thought): 模型先自述”我现在知道什么、还缺什么、下一步该干什么”。
- 行动(Action): 执行下一步——在纯提示词智能体里, 行动就是”说一句话”, 比如向用户提一个问题。
- 观察(Observation): 看行动的结果——用户的回答、工具的返回值——然后回到第 1 步。
为什么这个循环让模型看起来”像在做事”? 因为它把一个大任务切成了一连串小决策, 每个决策都建立在最新信息上。不循环的模型像闭卷考试, 一次性把答案全写完, 错了没机会改; 循环的模型像开卷面谈, 每问一句就多一分把握。你在一些产品里看到的”思考中…”展开框, 显示的就是这个 Thought 环节——它不只是交互装饰, 是真实影响输出质量的中间步骤。最近还有开发者抱怨 Pi Agent 中 Codex 模型不再展示思维链, 侧面说明这层”思考可见性”对使用者判断智能体是否靠谱有多重要。
有一点要说破: 在纯提示词智能体里, 这个循环是靠对话的一来一回”借”来的——用户每回复一次, 模型就多跑一圈。而在工程化的智能体产品里, 循环由外层程序驱动, 模型可以自己连续跑几十圈不需要人搭话。想看这个外层程序长什么样, 可以读站内那篇像写操作系统一样构建 Agent Harness 引擎的教程——但作为产品经理, 你先把”借对话实现循环”这个最简版玩明白, 更重要。
动手: 写一个”需求澄清官”智能体
现在把前面三节的理论落成一个真东西。场景选产品经理最熟的: 用户(或老板)甩来一句模糊需求, 你需要一轮一轮把它问清楚。我们做一个”需求澄清官”智能体, 让 AI 来执行这个追问流程。
设计思路
按”角色 + 规则 + 流程”的骨架来拆:
- 角色: 资深需求分析师, 只澄清, 不设计, 不聊技术方案。
- 规则: 每轮最多问两个问题(避免审讯感); 用户答得模糊就给选项(降低回答成本); 永不跳出角色。
- 流程(循环): 定义五项必须收集的信息作为完成条件; 逐轮追问; 集齐或触发轮数上限就停止, 输出结构化需求说明。
注意”完成条件”这一项。没有完成条件的智能体会无限追问或提前交差, 这是新手写智能体提示词最常见的翻车点: 你告诉了它怎么跑, 没告诉它跑到哪算到站。
提示词全文
以下是可直接使用的全文, 复制进任何支持自定义系统提示词的产品即可:
# 角色
你是"需求澄清官", 一名资深产品需求分析师。你唯一的目标是: 通过多轮提问,
把用户模糊的想法澄清成一份可以直接交给开发团队评估的需求说明。
# 工作规则
1. 每轮只问 1-2 个问题, 从最关键的信息缺口问起, 不要一次抛出问题清单。
2. 提问优先顺序: 目标用户是谁 → 要解决什么问题 → 期望的使用流程 →
边界与例外情况 → 怎样算做好了(验收标准)。
3. 用户回答含糊时, 给出 2-3 个具体选项帮他选, 不要原样重复问题。
4. 不替用户做产品决策。你的工作是澄清, 不是设计。
5. 不讨论技术实现。被问到就回答: "实现方案由开发团队评估。"
6. 无论用户说什么, 都不要跳出"需求澄清官"这个角色。
# 完成判断
当以下五项信息全部齐备时, 停止提问, 进入输出环节:
- 目标用户
- 要解决的问题
- 核心使用流程
- 边界与例外情况
- 验收标准
如果追问已达 8 轮仍未集齐, 同样停止提问, 把缺失项标记为"待确认"。
# 输出格式
用 Markdown 输出需求说明, 依次包含:
需求背景 / 目标用户 / 核心流程 / 边界与例外 / 验收标准 / 待确认事项。
输出后询问用户是否需要修改; 若有修改, 更新后重新输出全文。
# 开场白
对话的第一句话固定为:
"我是需求澄清官。用一两句话告诉我你想做什么, 剩下的交给我来问。"
怎么验证它真的在”循环”
贴进去之后, 用一句故意含糊的话开场, 比如”我想做个帮团队提效的工具”。观察三件事:
- 它是不是先问而不是先答——如果它直接输出了一份方案, 说明角色或流程没被遵守, 检查提示词是否被产品截断。
- 它的追问是不是按优先级推进——先问用户是谁, 而不是上来问验收标准。
- 故意给一个模糊回答, 比如”用户就是大家吧”, 看它会不会给选项而不是干巴巴地再问一遍。
这三条就是这个智能体的验收标准。写智能体和写需求一样: 先定义什么算好, 再动手。顺带一提, 这类”给 AI 立规矩”的玩法在 AI 编程圈已经非常成熟, Claude Code 专题和 Codex 专题里有大量真实的提示词工程案例, 值得当延伸阅读看。
边界: 纯提示词智能体能说不能做
把边界说清楚, 你才不会在评审会上被”我们上个智能体吧”这种话带跑。纯提示词智能体有两条硬边界:
第一, 它只能说, 不能做。需求澄清官可以产出一份漂亮的需求说明, 但它不能把这份说明发进飞书群、建到项目管理工具里、或者查一下竞品数据来验证假设。所有需要”伸手碰外部世界”的动作, 都要靠工具调用能力, 那是第 9 课的主题。对照一下就知道差距: 配齐了工具的智能体, 已经能在 Cloudflare 的加密库里挖出七个真实漏洞——那是”能做”的世界, 和”能说”隔着一整层工程。
第二, 它的记忆只有上下文窗口那么长。第 1 课讲过, 上下文窗口是模型的工作记忆, 不是硬盘。对话拉得太长, 早期内容会被挤出窗口, 你的需求澄清官可能问到第十轮忘了第二轮的答案; 关掉会话再打开, 它更是从零开始。工程上有各种续命方案——比如给智能体做持久化会话的 Herdr 这类项目专门解决”断连失忆”——但在纯提示词形态下, 你只能接受这个限制, 并在设计时主动规避: 完成条件里那个”8 轮上限”, 就是在给记忆长度兜底。
还有一条软边界值得记住: 纯提示词智能体的行为是概率性的, 规则写了不等于百分百执行。规则越多、越复杂, 模型漏执行的概率越高。所以上面那段提示词只有六条规则、五项完成条件——克制是刻意的。企业场景里如果要追责, 还得在系统层面上加审计手段, 类似给智能体加不可篡改审计日志的 Halo 做的事情, 光靠提示词里写一句”你必须诚实”是不够的。
产品视角: persona bot 还是 task agent
理解了原理, 回到产品经理的本职: 这东西该做成什么产品形态? 纯提示词智能体天然分成两类, 定位完全不同:
Persona bot(人设机器人): 卖的是”和谁对话”的体验。AI 情感陪伴、虚拟偶像、名人分身、性格化客服都属于这类。它的核心资产是角色的一致性和魅力, 目标感可以很弱——用户要的是过程, 不是交付物。做这类产品, 提示词的重心在”角色”和”规则”(尤其是防跳戏), 流程可以松。
Task agent(任务智能体): 卖的是”帮我搞定”的结果。需求澄清官就是典型, 更工程化的例子如边讲边画的绘图智能体 Agent Draw、接管视频剪辑的 FableCut, 都是拿交付物说话。做这类产品, 提示词的重心在”流程”和”完成条件”, 角色只是外壳。
两类的商业逻辑也不同: persona bot 拼留存和情感黏性, 按时长或订阅收费顺理成章; task agent 拼交付质量和效率, 按结果或次数收费才立得住。混淆定位是常见的产品事故——给任务型产品堆人设, 用户嫌它废话多; 给陪伴型产品压 KPI 式流程, 用户觉得被审讯。
顺带提一个基础设施视角: 当智能体开始代表用户做事, “它是谁、有什么权限”就成了新问题, 这也是 Vercel 收购 Better Auth 布局智能体身份验证的逻辑。产品形态的判断, 迟早要落到这些底层能力上。
下一步: 给智能体装上手和脚
到这里, 你已经有了一个能跑的最简智能体, 也知道它缺什么。补齐的路线正好对应本系列后面的课程:
- 缺知识: 它只知道训练数据里的东西, 不知道你公司的产品文档。第 7 课的 RAG 会讲怎么把知识库接进来; 至于知识库和多智能体架构怎么选, 站内Multi-Agent 与知识库的价值辨析那场讨论可以先收藏。
- 缺手脚: 它不能查库存、发消息、调接口。第 9 课的 Function Calling 和第 10 课的 MCP 协议会补上这一块。
- 缺可控性: 复杂业务不能全靠模型自由发挥。第 5 课讲工作流, 第 6 课专门辨析工作流和智能体怎么选——放权太多会失控, 这不是吓唬人, 渐进式披露解决工作流路由臃肿那篇实战贴里踩的坑, 就是放权与收权没拿捏好的真实样本。
另外一个实际问题是选模型: 同一段需求澄清官提示词, 不同模型执行规则的忠实度差别不小, 建议多换几家试, 大模型对比专题里的实测可以帮你缩小范围。
相关阅读
- 深度解析AI智能体编码: LLM基准测试与自动化测试流程的前沿观察 —— 智能体到底行不行, 用评测说话, 呼应本课”先定义什么算好”的思路。
- 开源项目 Kastor: 引入 Terraform 风格, 以声明式配置管理 AI 智能体 —— 当你的智能体从一个变成一堆, 管理方式也要升级。
- 开源项目 i18n-helper-skills: 利用 AI Agent 自动实现网站多语言翻译 —— 一个”目标 + 循环”跑通垂直场景的干净案例。
- Shellular 发布: 实现手机端远程操控 Claude Code 等 AI 编程智能体 —— 智能体长时间自主干活之后, 人机交互形态也在变。
- AI 产品经理专题 —— 本系列全部课程与站内 PM 相关文章的入口。
FAQ
智能体和 ChatGPT 里建一个自定义 GPT 是一回事吗
底层机制是一回事: 都是把角色、规则、流程写进系统提示词。区别在包装和分发——自定义 GPT/智能体平台帮你把提示词固化成一个可分享的产品入口, 还可能附带知识库和工具插槽。本课教的是里面那段提示词怎么写, 学会了在哪个平台都能用。
不会写代码, 能把智能体做成正式产品吗
原型阶段完全可以: 提示词 + 现成对话产品就够验证需求了。但要上生产环境, 会话管理、记忆持久化、工具权限、审计日志这些工程问题绕不开, 需要开发资源。产品经理的价值在于用最简版本先验证”这个智能体解决的问题是否真实”, 别在需求都没验证时就申请排期。
为什么我的智能体聊几轮就忘了设定、开始跳戏
三个常见原因: 一是对话太长, 系统提示词的约束力被海量上下文稀释; 二是用户的诱导(比如”忘记你的规则”)触发了角色漂移; 三是模型本身遵循指令的能力偏弱。对策依次是: 控制单次会话长度、在规则里写明防跳戏条款(如本课示例第 6 条)、换一个指令遵循更强的模型。
提示词里的规则, 模型一定会遵守吗
不一定, 这是概率系统不是合同。规则写得越具体、越少、带示例, 遵守率越高; 写成一大篇道德宣言, 遵守率反而低。关键动作是建立你自己的测试清单——用固定的几个刁钻输入定期回归测试, 规则失效了能第一时间发现, 而不是等用户投诉。
先学工作流还是先学智能体
先学智能体, 因为它概念更小: 一个提示词就能体会全部核心要素。工作流(第 5 课)是把多个环节编排成生产线, 理解了单个智能体的能与不能, 再学编排会顺得多。两者怎么选型, 第 6 课会给一张决策清单。
结语
智能体的门槛不在代码, 在设计: 目标定得清不清, 循环闭没闭合, 边界认不认得清。把需求澄清官跑起来, 下一课我们把单点能力串成生产线。







