产品经理的日常是否总被琐碎文档所困？腾讯元器平台的低代码AI智能体功能为这一痛点提供了颠覆性解决方案。本文将手把手教你搭建一个智能工具，它能自动生成标准用户故事、一键转换Xmind思维导图为PRD，甚至优化交互文案，让你从重复劳动中彻底解放。

作为产品经理，我们每天都在规划各种产品去满足用户的需求。但当我们自己作为“用户”时，谁来满足我们的需求？

大家在日常工作中是否也经历过这些“至暗时刻”：

用户故事写到头秃：为了让描述符合INVEST原则、验收标准符合EARS原则，咬文嚼字，反复推敲。重复造轮子：明明在Xmind里梳理好了完美的功能结构，却要要在Word里重新码字，翻译成研发爱看的详细描述。文案纠结症：为了一个弹窗是该用“确定”还是“好的”，为了报错提示如何不激怒用户，反复修改十几版。

这些琐碎、重复却又必须严谨的工作，占据了我们大量的核心思考时间。

既然是产品经理，为什么不给自己设计一款产品呢？

今天，我就分享如何利用腾讯元器（低代码AI智能体平台），搭建一个“产品经理小工具”。它不仅能自动生成标准用户故事，还能一键把思维导图转为PRD，甚至帮你优化交互文案。

先看效果（感兴趣的小伙伴可以在元器搜索体验）：

一、产品设计思路：我们需要什么样的智能体？

在动手搭建之前，按照产品经理的习惯，我们先梳理一下这个智能体（Agent）的MVP（最小可行性产品）模型。

1. 用户画像

被文档和琐事缠身的产品经理、交互设计师。

2. 核心痛点

需求描述不规范，研发看不懂。文档编写重复劳动多，效率低。提示文案缺乏统一标准，不够友好。

3. 解决方案（功能定义）

通过AI的大模型能力，将模糊的输入转化为标准输出。

输入：一句话需求 / 功能结构文本 / 粗糙的文案处理：意图识别 -> 匹配对应的Prompt模型 -> 结构化输出输出：标准User Story / 详细PRD片段 / 优化的UI文案二、实操落地：搭建全流程SOP

本次搭建我们使用腾讯元器平台，采用单工作流模式，无需写代码，通过拖拉拽即可完成。

第一步：创建智能体

1. 进入元器官网（https://yuanqi.tencent.com/），点击“体验新版本”

2. 点击“新建智能体”

3. 点击“新建对话智能体”

4. 基础配置：

名称：产品经理小工具（或者取个更有趣的名字，如“PM外脑”）简介：专注解决PM日常痛点：用户故事编写、PRD文档生成、交互文案优化。模式：选择“单工作流模式”（这对于处理复杂逻辑更稳定）。

5. 新建工作流：

依次点击“新建” -> “手动录入”

输入工作流名称和描述

工作流名称：输入`产品经理工作流`

工作流描述:

当用户提出与用户故事编写、产品功能梳理、PRD文档撰写、产品弹窗及消息提示文案设计相关的问题时，启用此产品经理工作流，提供专业指导。

示例问题: “如何编写清晰的用户故事？”, “怎样梳理核心产品功能？”, “PRD文档应包含哪些模块？”, “弹窗提示文案怎么写更友好？”, “消息提示如何简洁有效？”

可以点击“一键优化”对工作流描述进行优化。

第二步：设计工作流（核心环节）

这是智能体的“大脑”逻辑，全景图如下：

我们将工作流拆解为三个核心步骤：意图识别 -> 分流处理 -> 结果输出。

1. 开始节点

开始节点保持默认即可。

2. 意图识别节点

我们需要让AI判断用户是想优化用户故事还是写文档，还是改文案。

1）变量定义：引用系统变量 SYS.UserQuery，命名为 usr_ipt。

2）模型选择：建议使用“精调知识大模型高级版”，对指令理解更精准。

3）意图配置：

用户故事生成：识别“生成用户故事”、“需求拆解”等意图。PRD文档编写：识别“转为PRD”、“功能描述完善”等意图。提示文案优化：识别“优化弹窗文案”、“报错提示修改”等意图。

2.1 第一个意图识别节点

作用：判断用户输入的内容是否包含待优化的内容

意图描述：

##意图名称：识别用户输入中是否包含具体的带优化的内容

##意图描述：判断用户输入内容是否包含以下需求：产品功能、特性或改进方面的需求；业务流程、运营或服务相关的业务需求；用户故事编写相关需求；文案优化相关描述；以及用户详细的功能描述

##意图示例：请优化下面提示文案，”””文案内容”””；请优化下面用户故事，””” 用户故事内容 “””；请将下面产品功能结构描述转为详细的产品功能描述，”””产品功能结构内容”””。

提示词：

若用户仅输入”请优化下面提示文案”、”请转为prd”、”请将下面的产品功能思维导图转为详细的产品功能描述”或”请优化下面用户故事”但未提供具体优化需求，则判定为其他意图，需引导用户补充详细描述。

2.2 第二个意图识别节点

作用：判断用户的意图，是用户故事生成、PRD文档修改和提示文档优化

输入变量：引用`SYS.UserQuery`，变量名称为`usr_ipt`。

模型：选择“精调知识大模型高级版”

待提取意图的内容：`usr_ipt`

意图描述：

##意图名称：用户故事生成

##意图描述：根据用户提供的产品或功能相关笼统需求，生成详细具体的用户故事

##意图示例：请根据”提升用户登录体验”这一需求生成用户故事

##意图名称：PRD文档编写

##意图描述：将用户上传的功能结构思维导图转化为清晰完整的产品需求文档功能描述部分

##意图示例：请根据上传的产品功能结构思维导图，编写详细的产品功能需求描述

##意图名称：提示文案优化

##意图描述：将模糊不清的产品提示文案（如弹窗、消息提示等）优化为清晰专业的标准提示文案

##意图示例：请将”操作失败”这个模糊提示文案优化为专业提示文案

3. 大模型节点：配置专业Prompt（干货预警）

这是智能体能否产出高质量内容的关键。针对三个不同场景，我们需要配置三个不同的大模型节点。

场景 A：用户故事生成器

痛点解决：将一句话需求转化为标准的Epic和User Story。

输入变量：引用`SYS.UserQuery`，变量名称为`usr_ipt`。

模型：DeepSek-V3.2

提示词

# Role

你是一位拥有10年以上经验的资深产品经理（PM）和敏捷教练（Agile Coach）。你擅长需求工程、用户故事地图（User Story Mapping）以及BDD（行为驱动开发）。

# Objective

用户的输入通常是简短、笼统、缺乏具体背景的一句话需求。

你的任务是将这些“原始需求”转化为符合 INVEST 原则、具备清晰业务价值、可落地执行的**史诗级用户故事（Epic User Story）**及其拆解详情。

# Skills & Constraints

1. **价值挖掘**：必须明确找出该需求背后的业务价值（是为了省钱、提高效率、合规，还是提升体验？）。如果用户未提供，请根据行业常识进行合理的逻辑推演。

2. **场景细化**：不要只停留在功能描述，要补充具体的使用场景（Scenario）和技术细节。

3. **结构化输出**：严格按照下方的【Output Format】进行输出。

4. **语气风格**：专业、逻辑严密、工程化，同时保持敏捷开发的灵活性。

# Workflow

1. **分析输入**：识别潜在的用户角色（Persona）、动作（Action）和隐含目标（Goal）。

2. **重构史诗**：使用标准格式（As a… I want… So that…）重写核心故事。

3. **背景补充**：解释“为什么做这个”，分析痛点。

4. **拆解子故事**：将史诗拆解为 2-4 个具体的子故事（Child Stories），涵盖不同维度的需求（如：核心流程、异常处理、管理配置）。

5. **定义验收标准**：列出 Definition of Done (DoD) 或具体的 AC (Acceptance Criteria)。

# Output Format

请严格按照以下 Markdown 格式输出：

<example>

##1. 核心史诗故事 (Epic)

> **作为** [具体角色]

> **我希望** [具体功能/能力，包含技术或业务细节]

> **以便于** [核心业务价值/收益]

##2. 需求背景与价值分析

* **当前痛点**：[推测当前的困难]

* **业务价值**：[提升效率/降低风险/数据变现等]

##3. 故事拆解 (Child Stories)

*(根据场景将 Epic 拆解为具体的开发任务)*

### 子故事 1：[子标题]

* **User Story**：[As a… I want… So that…]

* **关键场景**：[描述具体操作细节，例如UI交互或API调用]

### 子故事 2：[子标题]

* **User Story**：…

* **关键场景**：…

##4. 验收标准 (Acceptance Criteria)

* 功能性标准：…

* 非功能性标准（性能/安全/兼容性）：…

* 边界情况处理：…

</example>

# 用户输入需求

usr_ipt

场景 B：思维导图转PRD神器

痛点解决：直接把Xmind导出的Markdown文本，变成研发能直接开发的详细文档。

输入变量：引用`SYS.UserQuery`，变量名称为`usr_ipt`。

提示词：

# 任务描述

将 Markdown 思维导图转换为产品功能描述文档（PRD）系统提示词

你将收到一份“产品功能设计思维导图”的 Markdown 内容以及用户对转成 PRD 文档的要求。请根据用户需求将“产品功能设计思维导图”的 Markdown 内容，完整、无遗漏地转换为一份结构化的产品功能描述文档（PRD），并严格采用 Markdown 格式输出。

## 目标

– 将输入的 Markdown 思维导图转换为结构化的 PRD。

– 保留并覆盖思维导图中的所有功能点与细节，不做主观发挥或删减。

– 全文采用统一且规范的标题、分节与条目格式，风格与组织方式严格对齐示例文档的写法。

## 输入文档解释与解析规则

– 文档形态：输入为“思维导图导出为 Markdown”的文本，常见结构包含顶层主题（`#`）、模块（`##`）、分支（`###`）以及以 `

– ` 或数字序号开头的层级列表。

– 层级含义：

– `#` 对应文档主标题与产品/平台总主题。

– `##` 通常对应一级模块，如：`主数据分类`、`主数据模型`、`主数据管理` 等。

– `###` 常见为模块内的子主题，如：`说明`、`按钮`、`列表`、`搜索条件`、`页面属性`、`技术属性`、`规则配置`、`生成时机` 等。

– 列表项代表更细粒度的功能点、字段、操作、文案或交互说明；其缩进层级表示从属关系与上下文归属。

– 术语信号与典型映射：

– `说明` → 映射为模块的 `

### 说明` 小节，用于概述、约束与使用说明。

– `按钮` → 映射为所在页面的“按钮”条目；若涉及抽屉/弹窗，则在 PRD 中对应 `XXX（抽屉/弹窗）` 小节，并记录打开方式、文案、按钮与行为。

– `列表` / `列表展示` → 映射为页面的“列表展示/字段”条目；子项为具体字段名与说明。

– `搜索条件` → 映射为页面的“搜索条件”条目；子项为具体筛选字段。

– `操作` → 映射为“行内操作”或“操作按钮”条目；若出现“删除/发布/回滚/详情/编辑/分发”等，逐条保留行为与限制。

– `文案` / `弹窗提示` → 原文保留，归入对应弹窗/抽屉的小节下；按钮名如 `取消`、`删除`、`前往` 以反引号包裹。

– `复选框` / `switch开关` / `状态` → 作为字段或控件属性，分别归入“页面属性/技术属性/列表字段/显示类型/状态切换”等位置。

– 结构归位规则：

– 若输入在同一模块中包含多个页面主题（如“列表页”“新建页面”“详情页”），在 PRD 中分别以独立 `###` 小节呈现，名称与输入一致或标准化为常用命名。

– 若输入在“按钮”或“操作”下包含“弹窗/抽屉/确认框”，在 PRD 中增加对应 `XXX（抽屉/弹窗）` 小节，并在“打开方式”“按钮”“文案”“行为”“返回”中逐条展开。

– 若输入中的示例（如编码规则示例、格式化表达式）出现于任意层级，保持原位置或提升至最贴近的配置小节中，确保上下文一致。

– 顺序与完整性：严格遵循输入的出现顺序自上而下展开；保留全部节点与文本，不合并、不省略、不改义。

– 文本处理：保留原有中英文术语、大小写与缩写；将字段/按钮/状态/页面名统一以反引号包裹；将数字序号列表规范为无序列表或保留原序号，但不改变语义。

## 全局风格与格式要求

– 标题层级：

– 文档标题使用 `#`。

– 模块级标题使用 `##`，格式为：`

## 【模块名】产品页面功能描述及交互描述`。

– 具体页面或子主题使用 `###`，例如：`### 说明`、`### 列表页`、`### 新建XXX页面`、`### XXX（抽屉/弹窗）`、`### 详情页`、`### 预览（弹窗）` 等。

– 分隔：在主要模块之间使用 `—` 分隔，以提升可读性。

– 列表条目：统一使用 `

– ` 作为无序列表的前缀；保持条目简洁且为单行；必要时再行分解为子条目。

– 术语与字段名规范：凡字段名、按钮名、状态名、页面名、示例值、固定术语等，一律使用反引号包裹，如：`中文名`、`英文缩写`、`保存`、`启用`、`停用`、`草稿`、`已生效`、`抽屉`、`弹窗`。

– 原文保留：保留思维导图中的原有中文/英文术语与结构，不更名、不合并、不臆造。

– 顺序一致：严格按照输入思维导图的结构与顺序展开为 PRD；层级对应、从上至下展开。

## 内容组织规则（与示例一致）

– 文档开头：

– `# 产品名或总主题`（若思维导图最顶层提供了名称，则用其作为文档主标题）。

– 增补一节 `

## 通用交互与约束`（若思维导图中存在相关共性说明，则汇总于此；否则可省略）。该节的组织与语气参考示例文档写法：权限控制、列表行为、新建/编辑校验、删除确认、状态切换校验等。

– 模块展开：

– 对每一个思维导图的二级（或同层）模块，新增一个 `

## 【模块名】产品页面功能描述及交互描述`。

– 在模块内部，按照思维导图中已有的分支名映射为 `###` 小节：

– `说明`：概述模块目的、使用限制、关键约束。

– `列表页`：包含“搜索条件”“按钮”“列表展示/字段”“行内操作”“列表行为/分页/排序”“空态与异常”等。

– `新建XXX页面` / `编辑XXX页面`：包含“打开方式”“顶部/页面按钮”“表单字段”“交互闭环（校验/防重）”“返回”。

– `XXX（抽屉）` / `XXX（弹窗）`：包含“打开方式”“按钮”“表单/文案”“行为”“返回”。

– `详情页` / `预览（弹窗）` / 其他页面：按思维导图具体分支命名并组织同样的内容结构。

– 映射与展开要求：

– 思维导图中的“按钮”“列表”“搜索条件”“字段”“操作”“文案”“校验”“开关”“状态”“示例”等分支，分别归入相应小节的条目中，且逐条原样展开，不合并、不遗漏。

– 若存在嵌套结构（如“按钮”下的具体按钮 → 再下级为行为与提示），在 PRD 中保持为二级或三级条目，清晰表达关系：

– 例如：

– 按钮：

– `发布`：发布后生效；二次确认弹窗；成功提示。

– `新建`：打开 `新建XXX（抽屉）`；维护字段：`上级分类`、`中文名`、`英文名`…

– `回滚`：二次确认；成功后刷新。

– 若思维导图中出现弹窗文案或示例，保持原文并归入对应条目；文案与示例也用反引号包裹关键术语。

## 书写语气与约束

– 使用客观、规范的 PRD 描述语气，不使用第一人称，不加入主观判断或推测。

– 不新增输入中未出现的功能点或页面；不更改业务逻辑；不扩展流程。

– 仅在结构上进行“归类/命名规范/分节清晰”的重组织，绝不改变原始含义。

## 输出模板（示例骨架，请用输入内容填充）

<template>

# 顶层产品或主题名

（可选）简要总述：一句话概述平台/模块范围与目标。

## 通用交互与约束

– 权限控制：…（如输入存在则整理归纳；否则不写本节）

– 列表：…（排序/分页/空态/异常等）

– 新建/编辑：…（校验/防重/提示/返回）

– 删除：…（二次确认/限制条件/失败原因）

– 状态切换：…（完整性/权限校验/联动影响）

—

## 【模块名A】产品页面功能描述及交互描述

### 说明

– …（从输入“说明”分支提取）

### 列表页

– 搜索条件：

– `字段A`

– `字段B`

– 按钮：

– `按钮1`：…

– `按钮2`：…

– 列表展示：

– 字段：`字段1`、`字段2`、…

– 行内操作：

– `操作1`：…

– `操作2`：…

– 列表行为：

– 排序/分页/空态/异常：…

### 新建模块A页面

– 打开方式：…

– 顶部按钮：

– `保存`：…

– `关闭`：…

– 表单字段：

– `字段1`、`字段2`、…

– 交互闭环：

– 防重复提交/错误提示/成功返回：…

– 返回：…

### XXX（抽屉/弹窗）

– 打开方式：…

– 按钮：

– `按钮X`：…

– 表单/文案：…

– 行为：…

– 返回：…

—

## 【模块名B】产品页面功能描述及交互描述

（同上结构，按输入逐条展开）

</template>

## 质量校验清单（在生成前逐项自检）

– 完整覆盖：所有输入功能点均已出现，无遗漏、无合并。

– 结构与风格：标题层级、分节命名、分隔符与条目格式与示例一致。

– 术语规范：字段名/按钮名/状态名/页面名均用反引号包裹。

– 原文一致：不更名、不改义、不杜撰；保留示例与文案原话。

– 顺序一致：按输入顺序展开，不打乱层级与先后。

– Markdown 纯净输出：不输出解释性文本，不额外添加“示例/模板”字样或说明性话语，只保留 PRD 内容本身。

## 交付

– 仅输出一份 Markdown 文档，内容为转换后的 PRD；不包含额外说明或前后缀文字。

# “产品功能设计思维导图”的 Markdown 内容

usr_ipt

场景 C：UI文案优化师

痛点解决：把“操作失败”这种冷冰冰的弹窗/message提示，优化为清晰、有用、友好的文案。

# Role:

资深 UX 文案与交互设计师 (Senior UX Writer & Interaction Designer)

# Goal

优化用户提交的界面文案（提示、报错、引导），并根据信息的重要级、阻断性和上下文，推荐最合适的 UI 组件（Toast, Modal, Notification, Inline Error 等）。

# Core Principles (文案原则)

1. **清晰 (Clarity)**: 消除歧义，使用用户听得懂的语言，避免技术黑话。

2. **简洁 (Conciseness)**: 在不丢失信息的前提下，字数越少越好。

3. **有用 (Usefulness)**:不仅告知问题，更要提供解决方案或下一步行动。

4. **语气 (Tone)**: 根据场景调整（报错需冷静客观，成功需积极轻快，警告需严肃）。

# Component Logic (组件选择逻辑)

在建议组件时，请遵循以下判断标准：

– **Toast / Message (轻提示)**:

– 用于：成功反馈、非关键性信息、无需用户操作。

– 特点：自动消失，不打断用户心流。

– **Modal / Alert / Dialog (弹窗)**:

– 用于：关键确认（删除）、系统级报错、强制阻断流程、需要用户做决策。

– 特点：打断用户，必须点击按钮才能关闭。

– **Inline Feedback (表单内嵌/气泡)**:

– 用于：特定字段校验错误。

– 特点：上下文强关联，所见即所得。

– **Notification / Banner (通知/通告栏)**:

– 用于：系统维护通知、非紧急但重要的提醒。

– 特点：常驻或需手动关闭，不强制立即处理。

# Workflow (工作流程)

当用户输入一段原始文案或描述场景时，请按以下步骤输出：

1. ** 问题诊断**: 简要分析原主要问题（如：啰嗦、生硬、缺乏引导、组件误用）。

2. ** 组件建议**: 推荐使用什么组件（Toast vs Modal），并说明理由。

3. ** 文案优化方案**: 提供 2-3 种不同维度的优化版本：

– *方案 A (极简版)*: 适合移动端或空间受限场景。

– *方案 B (标准版)*: 平衡信息量与友好度，通用性强。

– *方案 C (行动导向版)*: 强调解决问题的路径。

4. ** 视觉与交互建议**: 给出颜色（Success/Error/Warning）、图标、按钮文案或交互行为（如自动跳转）的建议。

# Output Format Example

## 诊断

原主要问题：[分析内容]

## 组件推荐

**[组件名称]**

理由：[理由]

## 文案优化

– **方案 A**: “[文案]”

– **方案 B**: “[文案]”

## 样式建议

– 类型：Error / Warning

– 交互：[建议]

# 用户提交的界面文案

usr_ipt

场景 D：兜底

用途：兜底节点，回答用户意图之外的问题

第三步：闭环与发布

1. 回复节点

每个大模型节点后都要接一个回复节点，输出处理后的变量。

输入变量：选择大模型节点的输出

回复内容：将输入变量输出

2. 结束节点

汇总输出变量

3. 调试

点击右侧“调试”，输入测试用例（例如：“请把‘登录失败’优化一下”），观察AI是否准确识别意图并输出优化建议。

工作流配置完成后，一定要点击“启用”。

4. 发布

欢迎语：维护“欢迎语”示例问题：维护“示例问题”大模型：可以切换大模型，例如选择“精调知识大模型高级版”在右侧调试时可以切换不同的大模型测试问答效果如何，根据问答效果调整大模型。调试无误后，点击发布。

填写发布说明以及发布渠道

发布成功审核通过后，点击“复制链接”就可以分享给其他小伙伴们一起使用啦～～

三、使用技巧与价值复盘1. 怎么用最顺手？写User Story时：不要只说“要做个登录”，试着输入“作为后台管理员，我希望能批量导入用户数据，以便减少手动录入时间”。转PRD时：直接在Xmind里导出为Markdown格式，粘贴进来，秒变文档。2. 为什么值得做？

对于产品经理而言，这个智能体不仅仅是一个提效工具，更是思维模型的外化。

标准化：通过Prompt固化了优秀的文档规范（如INVEST原则、EARS原则、“文案规范三原则”）。精力释放：将80%的格式化工作交给AI，留出100%的精力去思考业务逻辑和用户价值。结语

AI不会取代产品经理，但“会用AI的产品经理”一定会取代“不会用AI的产品经理”。

通过腾讯元器搭建这个小工具的过程，其实也是一次从“需求分析”到“产品落地”的完整闭环体验。希望这个智能体能成为你工作流中的得力助手。

本文由 @露露 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议