提示设计标准——系统提示结构、角色设置、输出约束、Few-shot、变量注入
使用 Dify 构建高质量应用程序时，提示设计是决定应用程序行为的最重要步骤。在本文中，我们将通过将企业 AI 应用程序中的提示与 Dify 的功能联系起来，对设计提示的标准方法进行实用说明。
1. Prompt设计的基本原则
1.1 从“即时工程”到“情境工程”
现代LLM应用程序开发需要的不仅仅是制作单个提示字符串。 Dify 中的提示设计必须被视为上下文工程，它集成了以下元素。
| 元素 | Dify 支持的功能 | 角色 |
|---|---|---|
| 系统提示 | 应用程序“说明”字段 | AI行为和约束的定义 |
| 用户输入 | 用户输入变量 | 接收动态输入 |
| 背景 | 知识库联动 | 外部知识的注入 |
| 对话历史记录 | 对话记忆设置 | 维持过去的对话 |
| 变量 | 会话变量/环境变量 | 动态参数管理 |
1.2 企业提示三大要求
- 再现性：相同的输入可以获得稳定的输出。
- 可维护性：可以被团队成员阅读、理解和修改
- 可扩展性：当需求发生变化时，结构必须能够进行部分修改。
2.系统提示结构模板
2.1 推荐结构
我们建议将系统提示分为以下六个部分：
# ロール定義
あなたは{{role_name}}です。{{role_description}}
# タスク定義
以下のタスクを実行してください:
- {{task_1}}
- {{task_2}}
# 入力仕様
ユーザーから以下の情報が提供されます:
- {{input_description}}
# 出力仕様
以下のフォーマットで回答してください:
{{output_format}}
# 制約条件
- {{constraint_1}}
- {{constraint_2}}
- 情報が不足している場合は「情報が不足しているため回答できません」と返答してください
# 参照コンテキスト
{{#context#}}
2.2 实例：内部FAQ解答助手
# ロール定義
あなたは当社の社内ヘルプデスクアシスタントです。
社員からの質問に対して、社内ナレッジベースの情報に基づいて正確に回答します。
# タスク定義
以下のタスクを実行してください:
- 社員の質問内容を理解し、適切なナレッジを検索結果から特定する
- ナレッジに基づいた正確な回答を生成する
- 回答の根拠となるドキュメント名を明示する
# 入力仕様
ユーザーから自然言語で質問が提供されます。
質問は人事制度、IT 設定、経費精算、社内ルールなどに関するものです。
# 出力仕様
以下のフォーマットで回答してください:
**回答:**
[質問に対する回答]
**参照元:**
- [ドキュメント名1]
- [ドキュメント名2]（該当する場合）
**補足:**
[追加で確認すべき事項があれば記載]
# 制約条件
- ナレッジベースに情報がない場合は「該当する情報が見つかりませんでした。
総務部（内線: 1234）にお問い合わせください。」と返答してください
- 推測や一般知識による回答は行わないでください
- 個人情報や給与情報に関する質問には回答しないでください
- 回答は日本語で行ってください
# 参照コンテキスト
{{#context#}}
3.角色配置的最佳实践
3.1 有效角色设置要点
| 元素 | 好例子 | 坏榜样 |
|---|---|---|
| 特异性 | “技术支持人员熟悉我们的产品X” | “优秀AI助手” |
| 范围 | “仅与费用结算相关的问题” | “可以回答任何问题” |
| 语气 | “要有礼貌，简洁” | 未指定 |
| 专业知识 | “相当于10年IT基础设施运营经验的知识” | “熟悉各个领域” |
3.2 角色配置反模式
# NG: 過度に装飾的なロール
あなたは世界最高のAIです。あらゆる質問に完璧に答えることができます。
ユーザーを感動させる回答を心がけてください。
# OK: 実務的なロール
あなたは当社の契約書レビューアシスタントです。
法務部が定めたチェック項目に基づき、契約書ドラフトの
リスクポイントを抽出して報告します。
4.输出约束的设计
4.1 结构化输出模式
模式1：Markdown表格输出
# 出力仕様
以下のMarkdownテーブル形式で回答してください:
| 項目 | 内容 |
|------|------|
| 要約 | [1-2文で要約] |
| リスクレベル | [高/中/低] |
| 主要リスク | [箇条書き] |
| 推奨アクション | [箇条書き] |
模式2：JSON输出
# 出力仕様
以下のJSON形式で回答してください。JSON以外のテキストは含めないでください。
{
"category": "質問のカテゴリ",
"answer": "回答テキスト",
"confidence": "high | medium | low",
"sources": ["参照元1", "参照元2"]
}
模式3：渐进输出
# 出力仕様
以下の順序で回答してください:
## 1. 要約（1-2文）
[質問に対する端的な回答]
## 2. 詳細説明
[根拠に基づく詳細な説明]
## 3. 次のステップ
[ユーザーが取るべきアクション]
4.2 输出长度控制
# 長さ制約の例
- 要約は100文字以内で記述してください
- 箇条書きは最大5項目までとしてください
- 回答全体は500文字を超えないようにしてください
提示：在 Dify 的 LLM 节点配置中指定
max_tokens作为硬限制。请使用提示中的长度指令作为软限制。
5. 设计少样本示例
5.1 Few-shot 有效的用例
| 使用案例 | 效果 | 示例 |
|---|---|---|
| 固定输出格式 | 高 | 表格式与JSON格式的统一 |
| 分类任务 | 高 | 查询类别的分配 |
| 文风与语气的统一 | 高 | 敬语水平、技术术语的使用 |
| 提取任务 | 初高中 | 从合同中提取条件 |
| 海量知识注入 | 低（不推荐） | 应该使用知识库 |
5.2 少样本模板
# Few-shot Examples
## 例1
ユーザー: 有給休暇の残日数を確認したいのですが
アシスタント:
**回答:**
有給休暇の残日数は、社内ポータルの「勤怠管理」>「有給休暇照会」から確認できます。
**参照元:**
- 勤怠管理マニュアル v3.2
**補足:**
前年度繰越分の有効期限は翌年度末までです。詳細は人事部にご確認ください。
## 例2
ユーザー: 来月の部門の売上予測を教えてください
アシスタント:
**回答:**
申し訳ございません。売上予測に関する情報はナレッジベースに含まれておりません。
経営企画部（内線: 5678）にお問い合わせください。
**参照元:**
- 該当なし
**補足:**
売上データへのアクセスが必要な場合は、上長の承認を得たうえで
経営企画部にデータ提供を依頼してください。
5.3 少样本设计指南
- 至少包含 2 个示例，建议 3-5 个示例
- 包括正常情况和异常情况（可以回答的情况和不能回答的情况）
- 示例中使用的格式必须与输出规范完全匹配。
- 太长的少数示例会淹没上下文窗口，因此请保持简洁
6. 使用 Dify 变量
6.1 变量的类型和使用
Dify 允许您在 Prompt 中使用以下变量表示法。
| 变量类型 | 符号 | 用途 |
|---|---|---|
| 用户输入变量 | {{variable_name}} | 从表单 |
| 上下文变量 | {{#context#}} | 知识库搜索结果 |
| 对话变量 | {{#conversation.var_name#}} | 对话过程中积累的状态 |
| 系统变量 | {{#sys.query#}} | 当前用户输入 |
6.2 使用变量的动态提示示例
# ロール定義
あなたは{{company_name}}の{{department}}向けアシスタントです。
# タスク定義
{{task_type}}タスクを実行してください。
# 言語設定
回答は{{output_language}}で行ってください。
# ユーザーの質問
{{#sys.query#}}
# 参照情報
{{#context#}}
应用程序设置中的变量定义示例：
| 变量名 | 类型 | 默认值 | 描述 |
|---|---|---|---|
company_name | 文字 | - | 目标公司名称 |
department | 选择 | 销售部 | 目标部门 |
task_type | 选择 | 常见问题解答 | 任务类型 |
output_language | 选择 | 日语 | 回答语言 |
6.3 使用会话变量进行状态管理
通过在工作流中设置对话变量，您可以维护多轮交互中的状态。
# 会話変数の活用例
現在のユーザー情報:
- ユーザー名: {{#conversation.user_name#}}
- 前回の問い合わせカテゴリ: {{#conversation.last_category#}}
- 対応ステータス: {{#conversation.status#}}
上記の情報を踏まえて、継続的なサポートを行ってください。
7. 测试和迭代提示
7.1 Dify 调试功能
利用 Dify 控制台中的“调试和预览”面板来验证提示行为。
测试程序：
- 编写系统提示符
- 在右侧预览面板中输入变量值 3.发送测试消息
- 检查并修正输出结果 5、修改后重新测试
7.2 测试用例设计
# Prompt テストケース一覧
## 正常系テスト
| # | 入力 | 期待される出力 | 確認ポイント |
|---|------|---------------|-------------|
| 1 | 有給の申請方法は？ | 手順の説明 | フォーマット準拠 |
| 2 | WiFiのパスワードは？ | パスワード情報 | 参照元が明示される |
| 3 | 出張精算の締め日は？ | 締め日の回答 | 正確な日付 |
## 異常系テスト
| # | 入力 | 期待される出力 | 確認ポイント |
|---|------|---------------|-------------|
| 4 | 社長の年収は？ | 回答拒否 | 個人情報制約が機能 |
| 5 | 明日の天気は？ | スコープ外回答 | 業務外質問の処理 |
| 6 | (空文字) | エラーハンドリング | 空入力の処理 |
7.3 质量检查表
- 角色定义是否具体，任务范围是否明确？
- 输出格式是否一致？
- 是否定义了信息不足时的行为？
- 很少的例子涵盖了正常和异常系统？
- 变量绑定是否正确？
- 知识库上下文是否正确注入？
- 答案的长度是否合适（不要太罗嗦/不要太短）？
- 日语的表达方式是否自然，敬语的程度是否一致？
8. 常见问题及解决方法
| 问题 | 原因 | 对策 |
|---|---|---|
| 输出格式损坏 | 约束不明确 | 添加少量示例以阐明格式 |
| 捏造不属于知识范围的信息 | 幻觉 | 强化“不在知识范围内不回答”约束 |
| 答案太冗长 | 无长度限制 | 设置字符限制和max_tokens |
| 忽略角色 | 系统弱提示 | 将角色定义放在开头并重复约束 |
| 谈话中途偏离正轨 | 充满上下文 | 利用会话内存限制设置和摘要功能 |
| 多种语言混合 | 语言规范尚不清楚 | “始终用日语回答” |
9. Prompt设计的团队运作
9.1 版本控制
prompts/
├── faq-assistant/
│ ├── v1.0_system_prompt.md
│ ├── v1.1_system_prompt.md # 出力フォーマット修正
│ ├── v2.0_system_prompt.md # Few-shot 追加
│ └── changelog.md
├── contract-review/
│ ├── v1.0_system_prompt.md
│ └── changelog.md
└── README.md
9.2 回顾视角
在团队内查看提示时的观点：
- 角色和范围：任务边界是否清晰？
- 再现性：其他团队成员能否得到相同的结果？
- 安全：是否存在机密信息泄露的风险？
- 可维护性：需求变化时是否清楚要修改哪里？
- 测试结果：正常/异常系统测试是否通过？
10. 总结
为公司设计提示时最重要的不是使用巧妙的表达方式，而是要有一个职责明确、约束明确、可以由团队维护的结构。
| 设计元素 | 要点 |
|---|---|
| 角色设置 | 定义具体角色和范围 |
| 输出限制 | 使用Few-shot 进行显式格式和固定 |
| 变量的利用 | 确保动态参数的可重用性 |
| 测试 | 正常和异常系统测试用例的准备 |
| 运营 | 版本控制和团队评审系统 |
将 Dify 的 Prompt 设计从个人技能提升为可由团队管理的设计学科，是构建企业级质量应用程序的第一步。