让AI输出从"碰运气"变成"可设计、可复制、可进化"
本章适用读者:
- L2/L3层级的AI骨干员工,想系统掌握驱动AI的底层技术
- 企业主想理解:为什么同样用AI,别人效果好、自己效果差
- 想从"会用AI"进化到"会设计AI工作方式"的人
本章核心主张: Gartner 2025年宣布——"Context Engineering(上下文工程)已经取代Prompt Engineering,成为AI应用成败的关键。"这三种能力构成一个递进体系:先学会写好Prompt,再理解如何给Agent配置工具,最终学会设计整个上下文架构。
一、Prompt Engineering:从"试出来"到"设计出来"
1.1 为什么大多数人的Prompt效率极低?
随机试Prompt的典型路径:
第1次试:写一句话 → 结果不满意
第2次试:加了几个字 → 还是差不多
第3次试:换了个说法 → 偶尔好一次
第N次试:某个写法凑巧不错 → 记住这个
这不是学习,是碰运气。问题在于:大多数人用的是"输入法直觉"写Prompt,而不是"信息设计"的方式。
AI模型本质上是一个概率预测引擎——它根据你给的信息,预测最可能是"正确输出"的内容。你给的信息越完整、越结构化,它的输出就越稳定、越符合预期。
1.2 五要素框架:每个好Prompt都有这五层
| 要素 | 作用 | 常见缺失 |
|---|---|---|
| ① 角色(Role) | 告诉AI"你是谁",激活对应的知识领域和表达风格 | 缺少角色定义,AI用通用语气回答 |
| ② 任务(Task) | 明确"做什么",用动词开头,越具体越好 | 任务模糊("写一篇关于XX的文章") |
| ③ 上下文(Context) | 提供背景信息:受众是谁、场景是什么、已知信息 | 缺少背景,AI只能猜测你的实际需求 |
| ④ 约束(Constraint) | 定义边界:字数/格式/禁止项/语气/视角 | 无约束,输出长度和方向随机 |
| ⑤ 格式(Format) | 要求输出的结构:列表/表格/代码块/分段 | 无格式要求,AI输出一大段文字 |
对比示例:
❌ 低效Prompt:
"帮我写一份客户提案"
✅ 高效Prompt(含五要素):
【角色】你是一名有10年经验的企业咨询顾问,擅长为制造业中小企业提供数字化解决方案。
【任务】帮我为一家50人的汽车零部件企业写一份AI引入初步方案提案。
【上下文】该企业痛点:质检靠人工,漏检率约8%;月产报告需要2天人工整理。
对方决策者是总经理,技术背景不强,关注ROI和落地风险。
【约束】不超过500字;不要用技术术语;重点突出成本节省和实施时间;
不要承诺具体数字,用区间描述。
【格式】分三部分:核心问题 → 我们的方案 → 下一步行动。每部分3-5句话。
同样的AI,不同的Prompt,输出差距可以是10倍。
1.3 系统Prompt vs 用户Prompt:两层设计
在搭建Agent或自动化工作流时,Prompt有两个层次:
系统Prompt(System Prompt)= 给Agent的"岗位说明书"
→ 长期有效,定义AI的角色、能力边界、行为准则
→ 通常由L3构建层员工设计,不随每次对话改变
用户Prompt(User Prompt)= 每次具体的"工作任务指令"
→ 用户实际输入的内容
→ L1/L2员工日常使用的部分
系统Prompt的设计要点:
[优秀系统Prompt的六个组成部分]
1. 身份定义:"你是XX公司的[角色],专门负责[职责范围]"
2. 知识边界:"你只使用以下知识库中的信息回答问题;如果不知道,明确说不知道"
3. 行为准则:"永远不要编造数据;不确定时主动问用户"
4. 输出风格:"使用简洁的中文,避免过度礼貌用语;不要以'好的'开头"
5. 禁止项:"不讨论竞争对手;不提供超出你权限的承诺"
6. 边界情况处理:"如果用户问到[敏感话题],回答:'这个问题请联系[部门]'"
1.4 三种进阶技巧(L2层员工应掌握)
技巧一:链式思维(Chain of Thought, CoT)
适用:复杂分析、多步推理、容易出错的任务
在Prompt末尾加上:
"请一步步思考,在给出最终答案前,先列出你的推理过程。"
效果:AI的准确率在逻辑推理类任务上提升20-40%
适用场景:合同风险分析、财务异常诊断、复杂问题排查
技巧二:Few-shot 示例(给AI看例子)
适用:有特定输出格式要求、风格要求高的任务
在Prompt中加入:
"请按照以下格式输出:
示例输入:[客户投诉:收到的产品颜色和图片不符]
示例输出:
- 问题类型:商品描述不符
- 紧急程度:中
- 建议回复:[具体话术]
- 处理步骤:[1. 核实订单 → 2. 联系仓库 → 3. 提供补偿方案]
现在处理这条投诉:[实际输入内容]"
效果:输出格式稳定性提升70%以上,几乎消除格式不一致问题
技巧三:角色扮演+对立视角
适用:需要批判性分析、风险识别的场景
"以下是我们计划推出的新产品方案。
请扮演一个持怀疑态度的资深客户,指出你最担心的3个问题。
然后再扮演一个竞争对手的产品经理,说出你认为这个方案的最大弱点。"
效果:比直接问"这个方案有什么问题",能发现更多真实的风险点
1.5 如何诊断和修复差Prompt(系统化方法)
当AI输出质量差时,不要随机修改——用这个诊断流程:
步骤1:判断问题类型
→ 输出方向错了(没理解任务):缺少"任务"或"上下文"
→ 输出质量低(内容空洞):缺少"约束"和"示例"
→ 输出格式乱:缺少"格式"要求
→ 输出不稳定(每次不同):系统Prompt不够固定
步骤2:针对性修改
→ 方向错:在Prompt开头加"你的目标是...",明确任务
→ 质量低:加"请具体说明...",或加Few-shot示例
→ 格式乱:直接给出格式模板让AI填写
→ 不稳定:将有效元素写入系统Prompt,固化下来
步骤3:A/B对比验证
→ 修改后用相同的5个输入测试
→ 如果3/5以上达到预期:固化这个Prompt
→ 如果仍然不稳定:继续定位问题
二、Agent工具/技能体系:给AI装上"手"
2.1 工具调用(Tool Use)是什么?
纯语言AI的局限:
用户:今天XX股票的价格是多少?
AI:我的知识截止到2024年,无法获取实时股价。
用户:帮我发一封邮件给客户
AI:我无法直接发送邮件,但我可以帮你起草内容...
这是纯语言模型的天花板——只能"说",不能"做"。
配置了工具的Agent:
用户:今天XX股票的价格是多少?
Agent:[调用金融数据API工具] → 返回:今天收盘价¥XX,涨幅X%
用户:帮我发一封邮件给客户
Agent:[调用邮件发送工具] → 起草内容 → 确认 → 发送
工具调用(Tool Use / Function Calling)让AI从"顾问"变成"执行者"。
2.2 企业Agent工具的四大类别
| 类别 | 功能 | 典型工具 | 风险等级 | 适用场景 |
|---|---|---|---|---|
| 数据读取类 | 查询数据库、读取文件、搜索网页、调用API获取信息 | 网页搜索、数据库查询、CRM只读接口 | 低 | 信息获取、报告生成 |
| 内容生成类 | 生成文本、图片、代码、文档 | DALL-E、代码执行、PDF生成 | 低-中 | 内容创作、文档生成 |
| 系统操作类 | 发邮件、更新CRM、填写ERP、触发业务流程 | 邮件API、Salesforce写入、ERP接口 | 高 | 流程自动化 |
| 外部服务类 | 调用第三方平台:支付/物流/短信/日历 | 微信消息、支付宝、物流查询 | 中-高 | 业务系统打通 |
安全原则: 数据读取类工具可以先开放给Agent自动使用;系统操作类工具必须有"人工确认节点",不要让Agent直接写入生产系统。
2.3 MCP工具生态:你的Agent能连接什么?
MCP(模型上下文协议)已建立了一个快速扩张的工具生态:
| 工具类型 | 代表性MCP Server | 能做什么 |
|---|---|---|
| 搜索与信息 | Google Search MCP、Bing MCP | 实时网页搜索、新闻获取 |
| 文件与文档 | Notion MCP、Google Drive MCP、飞书文档 | 读写文档、管理笔记 |
| 代码与开发 | GitHub MCP、代码执行沙箱 | 读取代码库、运行Python脚本 |
| 通讯与协作 | Slack MCP、邮件MCP | 发送消息、处理邮件 |
| 业务系统 | Salesforce MCP、HubSpot MCP | CRM数据读写 |
| 数据库 | PostgreSQL MCP、MySQL MCP | 直接查询企业数据库 |
| 超级入口 | Zapier MCP(7,000+应用、30,000+动作) | 一个MCP连通几乎所有SaaS工具 |
Dify v1.6.0已内置双向MCP支持: 既可以把外部MCP工具引入Dify Agent使用,也可以把Dify工作流暴露为MCP服务供其他系统调用。这是2025年最重要的平台更新之一。
2.4 中小企业的5个高价值工具组合
组合A:内容创作增强包
Agent + 工具配置:
1. 网页搜索(获取最新行业信息)
2. 图片生成(配图自动生成)
3. 文档输出(直接生成Word/PDF)
适合:市场/内容团队,自动化内容生产流水线
组合B:客服智能升级包
Agent + 工具配置:
1. 知识库检索(RAG,查产品/政策文档)
2. 订单查询API(连ERP/电商系统)
3. 工单系统写入(自动创建客服工单)
适合:有大量客户咨询的企业,7×24小时自动处理
组合C:销售支持包
Agent + 工具配置:
1. 企业信息搜索(客户背景研究)
2. CRM只读查询(客户历史记录)
3. 文档生成(提案/报价单)
4. 邮件草稿(跟进邮件生成)
适合:B2B销售团队,大幅减少备客时间
组合D:财务数据助手包
Agent + 工具配置:
1. 数据库查询(读取业务数据)
2. Python代码执行(复杂计算/图表生成)
3. 报告文档生成(Word/Excel输出)
适合:需要定期生成数据报告的财务/运营团队
组合E:HR招聘加速包
Agent + 工具配置:
1. 简历解析(OCR + 结构化提取)
2. 岗位JD生成
3. 面试题库检索
4. 候选人评分(基于自定义标准)
适合:招聘量较大的HR团队
2.5 在Dify中配置工具的实操步骤
步骤1:创建Agent应用
→ 登录Dify → 新建应用 → 选择"Agent"类型
步骤2:配置基础大模型
→ 选择模型:推荐DeepSeek-V4(中文+性价比最优)
步骤3:写入系统Prompt
→ 定义角色、边界和行为准则(参考本章1.3节)
步骤4:添加工具
→ 点击"工具"选项卡 → 从内置工具库选择(50+工具)
→ 或点击"添加MCP服务器"→ 输入MCP Server URL
→ 测试工具是否正常连通
步骤5:连接知识库
→ 如已有知识库,在"知识库"选项卡中关联
→ 配置检索策略(相似度阈值、返回片段数)
步骤6:测试与调整
→ 用10个真实场景问题测试
→ 调整系统Prompt和工具配置直到稳定
总耗时:技术背景一般的员工,约半天可完成基础配置
三、Context Engineering:2025年AI效果的真正决定因素
3.1 什么是上下文工程?
Gartner 2025年宣言:
"Context Engineering is in. Prompt Engineering is out." ——Gartner,2025
核心区别:
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | 如何问(措辞、结构、技巧) | 给什么(信息内容、数据架构) |
| 操作对象 | 单次提问 | 整个信息环境 |
| 解决的问题 | "怎么表达更好" | "什么信息应该在AI的视野里" |
| 类比 | 优化考试作文的语言 | 设计考试卷本身的内容和范围 |
| 2025年重要性 | 仍然重要,但是基础 | 决定Agent成败的关键变量 |
为什么Context Engineering更重要?
对于单次对话,Prompt质量确实是主要变量。但对于企业Agent(需要持续工作、连接多个系统、处理复杂任务),真正的瓶颈是:AI在做决策时,能获取到哪些信息?
举例:客服Agent收到用户问题"我的订单什么时候到?"
差的Context设计:
AI只有FAQ文档 → 只能说"通常3-5个工作日" → 用户不满意
好的Context设计:
AI能访问:用户订单记录 + 物流状态API + 历史类似订单数据
→ "您的订单[编号]已于昨天发货,预计明天下午3点前送达,
当前位置在[城市]转运中心" → 问题真正解决
3.2 企业上下文的四层架构
一个设计良好的企业Agent,其"上下文空间"应该有四个层次:
┌─────────────────────────────────────────┐
│ 层级4:实时输入层(用户当次的具体问题) │
│ → 用户的消息、上传的文件、当前会话记录 │
├─────────────────────────────────────────┤
│ 层级3:工具层(按需检索的动态信息) │
│ → 工具调用结果:数据库查询/API返回/搜索结果│
│ → RAG知识库检索:相关文档片段 │
├─────────────────────────────────────────┤
│ 层级2:记忆层(历史信息与用户画像) │
│ → 此用户的历史对话摘要 │
│ → 已知的用户偏好和背景信息 │
├─────────────────────────────────────────┤
│ 层级1:系统层(固定的角色和规则定义) │
│ → 系统Prompt:角色定义/行为准则/边界 │
│ → 固定知识:公司介绍/核心政策摘要 │
└─────────────────────────────────────────┘
关键原则:越靠近底层,越要稳定;越靠近顶层,越要动态。
3.3 最常见的上下文设计错误
错误1:把所有信息塞进系统Prompt(信息过载)
❌ 错误做法:
系统Prompt = 产品手册全文(50,000字)+ 所有政策文件 + FAQ全集
→ 结果:AI在海量信息中找不到重点,回答质量反而下降
→ 原因:AI的注意力是有限的,信息越多,重点越模糊
✅ 正确做法:
系统Prompt = 简洁的角色定义(300字以内)
知识库 = 按需检索(RAG):只有当用户问到相关问题时,才检索对应片段
错误2:没有记忆机制(每次对话从零开始)
❌ 错误做法:
每次对话都让AI重新了解用户背景
→ 用户每次都要重新解释情况,体验极差
✅ 正确做法:
为每个用户维护一份"记忆摘要":
- 身份信息(公司/岗位/偏好)
- 历史对话的关键结论
- 已解决和未解决的问题
→ 每次对话开始时,将相关记忆注入上下文
错误3:工具调用结果不加筛选直接塞进上下文
❌ 错误做法:
数据库查询返回1000行数据,全部放进上下文
→ AI处理效率极低,可能超出上下文窗口限制
✅ 正确做法:
在工具层做预处理:
- 只返回最相关的前N条记录
- 将结构化数据提前聚合(如:求和/分组)
- 大文件先做摘要,再放入上下文
3.4 RAG是上下文工程的核心实现
RAG(检索增强生成)本质上就是上下文工程的实践——它解决的正是"如何在正确的时刻,把正确的信息放入AI的上下文"。
企业RAG的上下文工程要点:
| 设计维度 | 建议 |
|---|---|
| 文档切片大小 | 128-512个Token为宜;太大=引入无关信息,太小=缺乏完整上下文 |
| 检索数量 | 每次检索返回3-5个片段;太少=可能遗漏关键信息,太多=噪音增加 |
| 相似度阈值 | 建议0.7以上;低于阈值的片段宁可不返回,也不要引入低质量信息 |
| 元数据过滤 | 先按类别/时间/作者过滤,再做语义检索,提升精准度 |
| 混合检索 | 关键词检索(精确)+ 语义检索(模糊)双管齐下,互补优势 |
3.5 实操案例:设计一个客服Agent的上下文架构
场景: 某教育机构部署课程咨询客服Agent
上下文架构设计:
【层级1:系统层(写入系统Prompt,固定不变)】
"你是[机构名]的课程顾问AI,专门帮助潜在学员了解课程信息。
你的知识来自知识库,不确定时必须说'我需要帮您确认'。
不要承诺任何未经确认的价格或名额信息。
保持专业友好的语气,每次回复不超过200字。"
【层级2:记忆层(按用户动态注入)】
如果是老用户:
"该用户背景:[从上次对话摘要中提取]
- 感兴趣的方向:产品运营
- 上次咨询时间:3月15日
- 未解决的问题:价格和开课时间"
如果是新用户:
(暂无记忆,等第一次对话结束后生成摘要存储)
【层级3:工具层(按需检索)】
工具1:知识库RAG检索
→ 触发条件:用户问课程内容/师资/上课方式
→ 返回:最相关的3个课程介绍片段
工具2:课程排期查询API
→ 触发条件:用户问"什么时候开课"
→ 返回:最近3期开课日期和名额状态
工具3:优惠政策查询
→ 触发条件:用户问价格/优惠
→ 返回:当前有效的优惠方案
【层级4:实时输入层(用户消息,自动进入)】
用户每条消息 + 当次对话历史(最近5轮)
效果预期:
- 能准确回答课程问题(知识库检索)
- 能查实时开课时间(工具调用)
- 记住老用户的历史需求(记忆注入)
- 不会编造不存在的优惠(系统Prompt约束)
本章小结:三层能力的递进关系
基础层:Prompt Engineering(会写有效的指令)
↓ 建立在此基础上
中间层:Agent工具配置(给AI配备执行能力)
↓ 建立在此基础上
高阶层:Context Engineering(设计AI的整个信息环境)
类比:
Prompt Engineering = 学会如何向一个员工布置任务
Agent工具配置 = 给这个员工配备所需的工具和权限
Context Engineering = 设计这个员工的工作环境、信息获取渠道和工作方式
企业AI能力建设的真相: 很多企业AI效果差,不是因为模型不够好,也不是因为Prompt写得不好,而是因为AI工作的"信息环境"设计得很差——它得不到完成任务所需的信息,当然无法给出有价值的输出。