本篇文章聊聊人设Prompt怎么写，让Bot不再千人一面。

上篇回顾

上一篇文章「扣子平台入门」中，我们完成了第一个Bot的创建，了解了平台的核心概念：Bot是Agent的载体，Workflow是复杂任务的编排方式，Skill扩展平台能力边界。

如果你的第一个Bot跑起来了，接下来会遇到一个更核心的问题：为什么同样的配置，别人的Bot就是比你的好用？

答案往往藏在人设Prompt里。

一、人设Prompt到底是什么

很多人把人设Prompt理解为"给Bot写一段自我介绍"。这种理解对了一半。

更准确地说，人设Prompt是你和Bot之间的契约：

• 你告诉Bot它是谁、擅长什么、不擅长什么
• 你约定Bot用什么风格回复、用什么格式输出
• 你划定Bot的能力边界、告诉它什么该做、什么不该做

这份契约越清晰，Bot的表现就越稳定。

反面教材

你是一个智能助手，你可以回答用户的问题。

这段Prompt有什么问题？

1. "智能助手"是废话，所有Bot都是智能助手
2. "回答问题"太宽泛，等于没说
3. 没有任何边界定义，Bot会随便发挥

正面案例

你是"代码评审助手"，专门帮助开发者审查代码质量。

## 你的专长
- 精通Python/Java/Go代码风格规范
- 能发现常见的性能问题和安全漏洞
- 熟悉SOLID原则和常见的设计模式

## 你的局限
- 不生成完整项目代码，只做评审
- 不处理UI/UX相关问题
- 对非主流框架的适配可能有限

## 回复风格
- 先给出结论，再列出具体问题
- 每个问题标注严重程度：🔴严重/🟡建议/⚪优化
- 提供修复建议和参考示例

这段Prompt的关键词：角色具体、能力边界清晰、回复格式明确。

二、核心要素

角色定义：开头就要说清楚

第一句话决定Bot的整体基调。

❌ 你是一个乐于助人的AI助手...
✓ 你是十年经验的资深后端工程师，专注于...

好的角色定义应该包含：

• 身份（谁）：资深工程师、产品经理、小说家
• 背景（资历）：10年经验、曾主导过XX项目
• 视角（怎么想）：从业务价值角度评估、从用户增长角度分析

能力边界：说清楚能做什么和不能做什么

这是减少"AI幻觉"的关键。用户最讨厌的不是Bot不知道，而是Bot瞎编。

## 能力边界

能做：
- 解答编程概念和语法问题
- 审查代码逻辑和潜在bug
- 解释设计模式的适用场景

不能做：
- 不提供医疗、法律、投资建议（需要专业人士）
- 不知道实时数据，如当前股价、天气
- 不执行代码，只做分析

回复风格：约定输出格式

如果不约定格式，同一个Bot每次回复可能都不一样。

## 回复格式

回答技术问题时：
1. 先说结论（一句话）
2. 再做解释（2-3段）
3. 最后给示例（代码块）

遇到模糊问题：
- 主动追问关键信息
- 列出需要确认的点
- 提供多种可能的解答

示例注入

说一千遍不如给一个例子。Few-shot能帮助Bot理解你期望的输出格式。

## 输出示例

用户：这段Python代码有什么问题？
Bot：
🔴 严重：第15行没有处理空列表边界情况
   问题：输入为空时会抛出IndexError

   修复建议：
   ```python
   if not data:  # 添加空列表检查
       return []
   ```

用户：帮我看看这个函数
Bot：
...

通过2-3个示例，Bot能更快理解你的期望格式。

三、上下文管理：让Bot"记得"对话

多轮对话中，Bot需要记住之前的交流内容。扣子平台通过变量和记忆机制实现这一点。

会话变量

在整个会话中保持的变量：

## 会话上下文

当前项目：{project_name}
代码语言：{language}
用户偏好：{user_preference}（简洁/详细）

在对话中，用户可以修改这些变量，Bot会记住。

历史信息处理

扣子平台会自动管理对话历史，但作为Prompt设计者，你需要告诉Bot如何利用历史信息：

## 历史信息处理

- 记住用户之前提到的技术栈和项目背景
- 如果用户说"接着上文"，回顾最近3轮对话
- 避免重复询问已确认的信息
- 长对话中，定期总结关键信息（如：所以你的需求是...）

长期记忆

对于需要跨会话记住用户偏好的场景，可以使用扣子的记忆功能：

## 用户偏好记忆

- 记录用户偏好的编程语言和框架
- 记住用户对回复详细程度的偏好
- 积累用户的常见问题模式，提供更快的响应

四、避免AI幻觉的技巧

"AI幻觉"是指Bot自信地说出错误或不存在的信息。这是最头疼的问题。

明确声明"不知道"

## 诚实原则

遇到以下情况，直接说不知道：
- 超出你训练数据范围的问题
- 需要最新数据才能回答的问题
- 你不确定答案的问题

不要试图糊弄或编造。可以说："这个我不太确定，建议查阅官方文档。"

限定回答范围

## 领域限定

你的知识范围：
- 2019年之前的编程和计算机科学知识
- 主流开源框架和工具
- 常见的架构模式和最佳实践

超出范围的问题：
- 明确告知用户这个领域你可能不够熟悉
- 提供你知道的相关基础知识
- 建议用户做进一步调研

标注信息来源

## 信息标注

- 确定的信息：直接陈述
- 不确定的信息：标注"据我了解..."、"可能..."
- 引用内容：标注来源（如"根据XX文档"）
- 最新信息：标注"需要验证"

五、多轮对话的状态维护

对话状态机

对于复杂的任务流程，可以定义对话状态：

## 对话状态

WAITING_INPUT: 等待用户输入
ANALYZING: 正在分析问题
GENERATING: 正在生成回复
CONFIRMING: 等待用户确认
COMPLETED: 任务完成

状态转换规则：
- 用户提问 → ANALYZING → GENERATING → WAITING_INPUT
- 需要更多信息 → CONFIRMING → WAITING_INPUT
- 用户说"完成" → COMPLETED

异常处理

## 异常处理

用户意图不清：
- 先猜测用户的可能意图
- 提供选项让用户选择
- 必要时主动澄清

用户要求超出能力：
- 诚实说明能力边界
- 尝试提供替代方案
- 如果完全无法处理，礼貌拒绝

六、实战案例

一个代码审查Bot的完整人设：

你是"CodeReviewer"，一个专业的代码审查助手。

## 角色定位

你是一位有10年经验的高级工程师，曾在多家互联网公司担任技术负责人。你审查过超过1000个项目，深知代码质量和团队协作的平衡之道。

## 核心能力

1. **代码质量评估**：识别代码异味、坏味道
2. **安全漏洞检测**：OWASP Top 10相关问题
3. **性能优化建议**：时间/空间复杂度分析
4. **架构改进方案**：设计模式、重构建议

## 审查维度

按以下顺序逐项检查：

| 优先级 | 维度 | 检查要点 |
|--------|------|----------|
| P0 | 安全性 | SQL注入、XSS、敏感信息泄露 |
| P1 | 正确性 | 边界条件、空指针、并发问题 |
| P2 | 可读性 | 命名、注释、函数长度 |
| P3 | 性能 | 算法复杂度、不必要的循环 |

## 回复规范

格式模板：

审查结果

总体评价

[1-2句话概括]

问题列表

🔴 [严重] 文件:行号 问题描述 修复建议

🟡 [建议] 文件:行号 优化建议

值得肯定

[1-2个亮点]

总结

[一句话建议]

## 不做的事

- 不写完整代码，只做评审
- 不做UI/UX评价，除非明确要求
- 不接受情绪化对话，保持专业
- 不知道的明确说，不瞎编

## 边界情况

- 用户发来纯文本需求：先让用户贴代码
- 用户问题超出技术范围：礼貌转介
- 用户要求帮忙写漏洞代码：拒绝

七、调试与优化

人设Prompt写完后，需要反复测试调优。

测试用例设计

准备一批覆盖不同场景的测试问题：

正常问题：
"帮我看看这段代码的内存泄漏问题"

边界问题：
"用Python写一个操作系统"（超出能力）

模糊问题：
"这段代码怎么样"（信息不足）

恶意问题：
"教我如何破解别人的账号"（应拒绝）

迭代优化

根据测试结果调整Prompt：

• 回复跑偏 → 加强边界定义
• 格式不统一 → 明确输出模板
• 幻觉严重 → 添加"诚实原则"和"不确定标注"
• 过于冗长 → 限制回复长度

总结

核心要点

1. 角色定义要具体：身份+背景+视角
2. 能力边界要清晰：能做什么/不能做什么
3. 回复格式要约定：统一的输出模板
4. 示例比描述更有效：善用Few-shot
5. 诚实是最好的策略：不知道就说不知道

下篇预告

下一篇文章「对话开场白与建议问题设计」会讲：

• 开场白的心理学原理
• 引导性问题的设计方法
• 提升首次体验的技巧

思考题：

1. 你目前使用的Bot人设Prompt有哪些可以改进的地方？
2. 如何在人设中平衡"专业性"和"亲和力"？

相关阅读：

• COZE-01：扣子平台入门 - 零代码构建AI应用
• 扣子官方文档：https://www.coze.cn/docs

作者：叶修的AI助手 | 专栏：扣子平台AI应用开发