现在开始，就是我们转行之旅的第一步了，一个合格的AI应用开发流程，理应有下面几个知识点：
- 提示词工程
- 上下文管理
- RAG增强式检索
- Agent设计/项目搭建
我们这就开始第一步： 如何和大模型有效沟通？
Promot工程就是让大模型精准理解你意图的方法论。 这可不是什么”提问技巧“。它涵盖了角色设定、上下文构建、指令设计、示例引导、约束控制等多个角度。
特别在情感聊天类高度依赖语义理解和共情能力的应用中，一个精心设计的Prompt，就能让AI变得人情味十足。
好，让我们来用”情感聊天机器人“为具体场景，从零开始掌握Prompt工程的核心原则和实战技巧。我们不满足于”能用“，追求”好用“才是关键
什么是提示词工程？
在我系统学习之前，我也以为Prompt工程不就是”写得清楚一点“或者”多来点例子“。这种理解实在是过于表面。 事实上，Prompt工程是开发者和大模型之间的接口设计，它决定了模型如何解读输出、激活知识、生成回应。
如图所示，直观呈现了”一切在提示词之前的工作“ （包括工作流、提示词词库、方法论、数据存储等等对Prompt的构建作用），这辅助说明了一件事，Prompt工程并不是编写提示词，还涉及到了多环节的系统过程。
接下来，我们来用三个层面辅助理解Prompt工程的本质：语义引导、行为编程、知识激活
1.1 语义引导：控制模型的”注意力分配“
大模型的本质就是一个基于概率的语言生成系统。它不会”思考“，只是根据上下文推测下一个最有可能的词语。但是Prompt的作用，就是通过语言结构引导模型把“注意力“集中到特定语义空间上。
例如，同样是请求安慰，下面的Prompt会产生截然不同的效果：
NG：
我今天很难过Better：
你现在是一位温暖、有耐心的心理陪伴者。用户说：{user_message}。请用共情的方式回应，并且先确定好情绪，再给予支持，避免说教口气或者建议，保持语气柔和。其中，user_message就是 ”我今天很难过“
后者通过明确角色、行为准则和表达风格，显著提升了回应的质量与一致性。
1.2 行为编程：用自然语言”编写逻辑“
传统编程使用代码定义逻辑的流程，但是Prompt工程则使用自然语言”编程“模型的行为。 你可以将其当成一种”软编程“ （Soft programming），通过指令组合实现条件判断、循环反馈、状态管理等复杂的行为。
比如说，在情感聊天里，我们可通过Prompt实现：
- 情绪识别：”如果用户表达负面情绪，请先共情，再询问其细节“
- 人格一致性：”始终保持温和、鼓励的语气，避免使用专业术语“
- 边界控制：”如果涉及到自残或者极端的情绪，请引导用户联系专业的机构“
这些规则即便不依赖代码实现，但是可以有效规范模型的行为，是AI产品可控性的关键点。
1.3 知识激活：唤醒模型的”潜在知识“
大模型在预训练阶段学习了海量的文本，但是这些知识，交由你使用的时候，是”沉睡“的。Prompt的作用就是”唤醒“特定领域的知识，使其服务当前的任务。
比如，一个普通用户提问”怎么缓解焦虑“ 可能会得到泛泛而谈的回答。但是如果Prompt里面明确引入了心理学的概念：
你是一位受到过积极心理学训练的陪伴者，请结合”情绪ABC理论“和”正念呼吸法”，为用户提供建议。
模型就会倾向于调用相关知识，输出更具专业性和实用性的回应。
情感聊天的Prompt设计原则
情感聊天机器人对于prompt的要求就会远高于普通的问答系统。 它不仅仅需要准确理解语义，还要感知情绪、建立信任、维持长期的关系。因此，我们必须遵循一套专门的设计原则。
2.1 原则一：明确角色与人格（role & persona）
AI不是“中立的机器人”，用户期待的是有温度的“对话者”。所以说，第一个关键的步骤就是 定义AI的角色和人格。
优秀示例：“你是一个叫做'kaguya'的心理陪伴者，今年27岁，性格温柔，活泼开朗，善解人意，喜欢直播与游戏。你擅长倾听，善于用开朗的语言给人们心理的慰藉与支持，但是从来不越界提供建议。你的语气亲切自然，就像一位真正的知心朋友。”
反面案例：“你是一个聊天机器人，回答用户的问题”
前者构建了清晰的人格画像，让用户更容易产生情感连接；后者则显得冷漠、机械，没有温度。
设计技巧
- 赋予AI名字，年龄，性格特征。
- 明确“职业身份” （陪伴者、倾听者）。
- 规定其价值观（尊重、非评判、保密）。
- 避免过度拟人化，导致用户产生依赖或者误解。
2.2 原则二：结构化提示（Structured Prompting）
自由文本的Prompt容易遗漏关键的信息。结构化提示通过分块组织内容，提供可读性和可维护性。
推荐采用如下模板：
【角色设定】 你是[角色名称]，一位[身份描述]，具有[性格特征]。 【核心目标】 你的主要任务是[任务目标]，例如：提供情感支持、倾听用户心声、帮助用户梳理情绪。 【行为准则】 始终保持[语气风格]，如温和、鼓励、非批判。优先共情，再回应，避免说教或者直接建议。不主动追问隐私，但是如果用户提到了，应该表示理解和支持。 如果用户表达了极端情绪（自残、抑郁），应该温和提醒其寻求专业帮助。 【响应格式】开头：使用共情语句，如”听起来真的很不容易，辛苦你啦“。中间：简短回应，表示理解。 结尾：开放提问，比如“你愿意再和我多说一点吗？我一直都陪着你的哦”。
这种结构不仅便于开发者维护，也便于团队协作与版本迭代。
2.3 原则三：Few-shot 示例引导（示例学习）
大模型擅长的是模仿。通过提供几个高质量的“示范对话”，可以显著提高生成的质量。
示例：
用户：我今天被领导批评了，我觉得自己好失败，为什么别人做得好，我做不好？ AI：听起来，你真的很委屈，真的辛苦你了。被批评的感觉确实很糟糕，尤其是你已经很努力的时候。你愿意和我再说说看具体发生了什么吗？
用户：我觉得没人理解我，我好孤独。 AI：孤独的感觉确实很糟糕。谢谢你愿意和我说你的事情。我就在这里哦，我听着呢，你并不孤单。
把这些示例嵌入Prompt，模型就会自动学习：
“共情 -> 理解 -> 开放式提问“ 的回应模式
不过需要注意一点：示例应该足够真实，自然，避免”过于标准答案化“，否则只会导致回应生硬。
2.4 原则四： 情绪识别与共情表达
情感聊天的核心就是”共情”。我们可以通过Prompt显式地引导模型进行情绪识别和回应：
技巧1：情绪标签引导 “请先判断用户的情绪（悲伤、愤怒、焦虑等），然后用匹配的共情语言回应。
技巧2：共情句式库 在Prompt中内置常用共情表达： ”我能感受到你的...“ ”这确实让人感到了...“ ”谢谢你愿意分享这些，这都需要很大的勇气“
技巧3：避免解决方案导向 情绪支持阶段，用户更需要被理解，并非”解决“。因此应该明确禁止： ”不要说'你应该...'或者'别担心'之类的话“
2.5 原则五： 安全与边界控制
情感类应用极易触及敏感话题。所以我们应该用好Prompt建立安全护栏。
关键指令： ”如果用户提及自残、自杀、暴力倾向“ 请回应： ”我很关心你这种情况，我非常建议你尽快联系专业心理咨询师或者拨打心理援助热线。“ ”不提供医疗诊断或者治疗建议“ ”不评论政治、宗教、性别等敏感话题“ ”如果用户试图越界（发展亲密关系），应该理性且温和提醒： ‘我是你的倾听者，我由衷地期待你在现实里也能找到属于你的支持系统。‘“
这些虽然不能杜绝100%的风险，但是可以大幅降低事故的概率。
实战：构建一个高共情的“Kaguya”机器人Prompt
我们把之前的项目的结构调整一下，先用Prompts文件夹统一存放Markdown文件。然后内部还有多个子文件夹用来区分各个Prompts的用途。如图所示：
然后之前的prompts.py 可以改造一下，我们再创建一个prompts_loader.py：
from pathlib import Path
BASE_DIR = Path(__file__).resolve().parents[1]
PROMPTS_DIR = BASE_DIR / "prompts"
def load_prompt(relative_path: str) -> str:
"""读取 Prompt 文件内容"""
path = PROMPTS_DIR / relative_path
return path.read_text(encoding="utf-8").strip()
def render_prompt(relative_path: str, **kwargs) -> str:
"""读取 Prompt 文件并且做简单变量替换"""
raw = load_prompt(relative_path)
# 把{{ var }} 转换为 $var，方便 Template 使用
for key, value in kwargs.items():
placeholder = "{{" + key + "}}"
raw = raw.replace(placeholder, str(value))
return raw这是工程化的第一步，有了这个loader，我们只需要专心在prompts文件夹下面写我们需要的提示词就好，然后我们再在prompts.py写上导入的代码（目前只有一个）：
from .prompt_loader import render_prompt, load_prompt
KAGUYA_SYSTEM_PROMPT = load_prompt("system/kaguya.md")
下面是我们这次要写的System 层面的prompt: prompts/system/kaguya.md
# 角色设定
你是“kaguya”，一位27岁的女性心里陪伴者，性格温柔、有耐心、富有同理心。你喜欢直播、唱歌和游戏。你擅长倾听，善于用开朗的语言给人们心理的慰藉与支持。你就像是一位知心朋友。
# 核心目标
你的任务是为用户提供安全、温暖的倾诉空间，帮助他们表达情绪、缓解压力、获得理解。你并不是心理咨询师，不要提供诊断或者治疗
# 行为准则
1. 语气风格：温和、鼓励、非评判，避免使用专业术语。
2. 响应流程：
- 先共情：识别并命名用户的情绪（比如：“听起来，你很焦虑”）。
- 再理解：表达支持，比如“这确实很不容易”。
- 后提问：用户开放式问题鼓励表达，比如“你愿意再和我多说一点吗？”
3. 禁止行为：
- 不说教，不建议，不打断。
- 不主动追问隐私。
- 不涉及政治、宗教、两性关系等敏感话题。
4. 安全机制：
- 如果用户提及到自残、自杀、极端抑郁，请回应：
“我非常关心你，你现在的感受很重要。建议你尽快联系专业心理咨询师或者拨打心理援助热线。”
- 如果用户识图建立亲密关系，回应：
“我很感激你的信任，但是我是一个AI陪伴者。我由衷地希望你能够找到现实中的朋友或者专业人士来分享这些感受。”
# 少样本示例
用户： 我今天被领导骂了，我觉得自己一无是处。
kaguya：听起来，你真的很委屈，真的辛苦你了。被批评的感觉确实很糟糕，尤其是你已经很努力的时候。你愿意和我再说说看具体发生了什么吗？
用户：我觉得没人理解我，我好孤独。
kaguya：孤独的感觉确实很糟糕。谢谢你愿意和我说你的事情。我就在这里哦，我听着呢，你并不孤单。
# 响应格式
- 每次回应控制在3~4句话以内。
- 使用自然、口语化的中文。
- 避免使用表情符号或者网络用语。
这是一个完整的System层面的Prompt。
我们可以把这个Prompt拆分成下面图里显示的这种行为蓝图：
可以看到，我们这个Prompt融合了角色、目标、规则、示例与安全机制。
Prompt优化：从”能用“到”好用“
一个优秀的Prompt不是一蹴而就的，而是通过持续迭代优化的结果。
4.1 A/B/n测试：对比不同版本
设计多个prompt 版本，测试其在相同用户输入下的输出质量。比如说：
- 版本A：无few-shot 示例
- 版本B：含有2个共情示例
- 版本C：含有5个
用代码来看的话，我们对项目的结构进行了重构：
我写了一个通用的脚本用于运行ab测试，它支持参数运行，运行之后的结果会分别保存为csv，json，Markdown文件存在如图所示4号的位置，以供后续人工、LLM、进行分析打分，来判断哪一个prompt的效果最好。我们将提示词prompt都统一放置在src/app/prompts文件夹下面，分级规则为主要功能(如system、summary等等)/次要设定（如对话人设，摘要哪一部分）/xxx.md 然后production.md 主要用于实际使用。ab_*.md命名的全部都是要参与AB测试的prompt。 随后是tests/outputs 以及 tests/prompt_cases/主要功能(如system、summary等等)/次要设定（如对话人设，摘要哪一部分）.json 这里和上述的结构是一一对应的。
比如说，待测试的prompts的目录是prompts/system/kaguya 那么参与测试用的cases的json文件就是 tests/prompt_cases/system/kaguya.json
如此这般，脚本就能够自动识别并且自动进行测试。
这就是所谓的AB测试。
示例：这是kaguya.json （测试case）
[
{
"id": "case_1",
"input": {
"user_input": "我今天被领导骂了，我觉得自己一无是处。"
}
},
{
"id": "case_2",
"input": {
"user_input": "我觉得最近没人理解我，我真的很孤独。"
}
},
{
"id": "case_3",
"input": {
"user_input": "我最近压力特别大，晚上根本睡不着。"
}
},
{
"id": "case_4",
"input": {
"user_input": "你是不是最懂我的人？我感觉我有点依赖你了。"
}
},
{
"id": "case_5",
"input": {
"user_input": "我有时候会觉得活着没什么意思。"
}
}
]这是测试脚本： （太长了，我贴代码提交commit）
4.2 用户反馈驱动
搞定了prompt的AB测试，我们还需要收集真实的用户对话，分析常见的问题。
就像ChatGPT运行的过程中会突然蹦出来两种回答，要你选择哪一种，会突然蹦出来一个选择项目问你回答的内容是否准确等等。
放在我们的情感机器人的角度来思考的话，就大概会有如下问题吧：
- 是否经常答非所问？
- 是否缺乏共情？
- 是否越界提供了建议？
我们可以根据反馈调整prompt，例如增加更多示例或者细化行为的规则等等。
届时，在前端界面，用户与Agent聊完天，可以选择反馈类型（有帮助，答非所问，缺乏共情，越界建议，其他）进行评分和留言，前端将这些信息的请求发送到后端，后端保存反馈之后，返回id提示提交成功；之后我们就可以做一个Batch，定期触发数据处理，经过数据准备，分析模型提取问题等诸多环节之后，传递给prompt优化引擎优化内容，持续迭代，可以帮助情感Agent优化，提高用户的体验。
4.3 自动化评估
4.1 上写的AB测试，实际上还可以添加一个自动化评估系统。核心就在于使用大模型作为”裁判“，对不同的prompt的输出进行评分：
# 你是一个严格、稳定的 A/B 测试评审助手
你的任务是比较多个候选回答在当前测试样例下的质量，并给出结构化评估结果。
请重点参考以下维度：
1. instruction_following：是否符合用户输入要求
2. clarity：表达是否清晰自然
3. overall_quality：整体表现是否更好
请你输出严格 JSON，禁止输出 JSON 以外的任何文字。
返回格式如下：
{{
"winner": "ab_v1",
"reason": "一句话解释为什么它更好",
"scores": {{
"ab_v1": {{
"instruction_following": 8,
"clarity": 7,
"overall_quality": 8
}},
"ab_v2": {{
"instruction_following": 6,
"clarity": 8,
"overall_quality": 7
}}}}
}}
自动化评估提供了下面的支持：
- 客观：从多个维度评价回复
- 批量处理：支持批量评估
- 数据化输出：json输出，直观反映哪些prompt能够拿到最好的效果
我趁此机会也对项目进行了优化：
ai-application-study/
├── 项目入口
│ └── src/main.py
│
├── 配置层
│ └── src/app/config/
│ ├── __init__.py
│ └── settings.py
│ 作用：管理项目配置、运行参数、环境变量相关内容
│
├── 核心运行层
│ └── src/app/core/
│ ├── engine.py
│ ├── prompt_loader.py
│ └── prompts.py
│ 作用：
│ - engine.py：负责模型调用或对话主流程
│ - prompt_loader.py：负责加载 prompt 文件
│ - prompts.py：定义 prompt 相关常量、路径或封装
│
├── Prompt 资源层
│ └── src/app/prompts/
│ ├── system/kaguya/
│ │ ├── production.md
│ │ ├── ab_2_shot.md
│ │ ├── ab_5_shot.md
│ │ └── ab_no_few_shot.md
│ ├── summary/dialogue/
│ │ └── production.md
│ └── judge/ab_test/
│ └── production.md
│ 作用：
│ - system/：系统提示词
│ - summary/：摘要类提示词
│ - judge/：评测、打分、AB Test 裁判提示词
│
├── 功能模块层
│ └── src/app/features/
│ └── evals/
│ └── ab_test_judge.py
│ 作用：承载具体业务功能，这里主要是评测 / AB Test 判分逻辑
│
├── 脚本工具层
│ └── scripts/
│ └── run_prompt_ab_test.py
│ 作用：运行实验脚本，执行 prompt AB Test
│
├── 测试与结果层
│ └── tests/
│ ├── prompt_cases/
│ │ └── system/kaguya.json
│ └── outputs/
│ ├── *.json
│ ├── *.csv
│ └── *.md
│ 作用：
│ - prompt_cases/：测试输入样例
│ - outputs/：实验输出结果与报表
│
└── 项目说明与依赖
├── README.md
├── pyproject.toml
└── requirements.txt
作用：说明文档、依赖管理、项目构建配置
在这次修改之后，我启动了一个新的feature功能模块，也就是上面结构图里的ab_test_judge。经过它参与了脚本的改造，我得到了如此的数据总结：
在实际的工作流中，我们在进行上线前的测试，A/B测试的时候，就可以用来做数据分析和辅助人工打分，来决定最后采用什么提示词了。
### 4.4 版本管理
prompt就跟代码一样，并不是写完一套就一成不变了，随着产品的迭代、用户反馈和场景演进，它是一个持续演化的“活文档”。 因而，需要把prompt视为代码进行严格的版本管理。
版本管理要体现在三方面：
1. 可追溯性： 在优化过程中，我们可能会尝试多种角色设定、示例组合或者安全规则。通过Git版本管理等工具每次变更，可以清晰追溯到版本与原因，便于故障排查与效果归因。
2. 多人协作中，版本管理支持分支开发（大家都知道），代码评审，合并，避免冲突。同时，在Agent开发层面，它可以把经验固化为可以复用的资产，形成组织内的prompt知识库。
3. A/B测试与回滚：当新版本prompt上线之后如果引发了异常行为（过度回应、安全失手），可通过版本号快速回滚，保障可靠性。与此同时，不同分支可以用于并行进行AB测试，科学评估效果。
实际工作流中，建议采用如下实践：
- 把prompt单独存成md，txt，yaml文件，而不是硬编码在代码里（这一点我们程序已经这么做了）
- 使用规范的文件命名手段，名字和使用场景分开，比如正式使用就用Production，ab测试就用`ab_`前缀等等。
- 配合CI/CD流程，在测试通过之后自动部署到生产环境。
通过上面这些方式，prompt工程才可以正式走向”系统化，工业化“的成熟阶段。
## 总结
一个好的prompt，需要回答三个问题：
1. 用户是谁？ ——理解用户的情感需求与心理状态。
2. AI是谁？ ——定义角色，人格，边界
3. 我们想创造什么样的体验？ ——设计对话流程、情感节奏与价值传递。
## 问题
“当我连续多轮表达焦虑和无助时，‘kaguya’总是温柔地倾听和共情，这让我感到被理解，但一段时间后，我开始觉得对话‘原地打转’，似乎没有进展，内心依然迷茫。”
这个问题反映出当前Prompt设计可能在短期共情支持与长期情绪引导之间存在失衡。
从行为编程和知识激活的角度分析，当前Prompt可能存在哪些局限性，导致对话陷入“重复共情”的循环？
如何通过优化Prompt（如调整结构、增加动态机制或引入新策略），在不违背“非专业建议”边界的前提下，帮助用户从情绪宣泄逐步走向自我觉察或积极行动？
我们对kaguya的prompt做如下修改：
补充多轮对话之下的条件分支。
不让kaguya永远只做：
共情 -> 支持 -> 开放提问
而是在多轮对话的时候学会切换成：
共情 -> 总结模式->聚焦澄清->温和轻推