内容来源：文因互联内部分享

作者：文因互联提示工程实验室张一博

“如果只能写一句话”

【提示工程】在B端落地的目标是：在保持效果可接受的前提下，设计最短的工作流链路，并在其中的每个节点使用最小尺寸的模型，来操作最短长度的提示词。

“为什么要给B端应用单独写一篇经验分享？”

在2024年末至2025年初，OpenAI和Anthropic相继发布了智能体构建指南（How to build LLM Agents）。他们都将智能体分为两类：声明式（Declarative）和指令式（Imperative）。

这就像开车导航：

• • 声明式（Agent）：用户只说“我要去哪”，剩下的路径规划、工具调用、代码撰写全由模型包办。

• • 指令式（Workflow）：用户明确定义第一步走哪条路、第二步在哪里转弯，每一步都有严格的执行逻辑。

市面上的指南大多聚焦于“声明式”，展示如何利用海量参数的LLM配合Web Search、Code Interpreter等工具解决复杂问题，看起来非常“Fancy”。但在我们这家服务于金融行业、泛工业、医疗等垂直行业的人工智能公司，面对数据提取、规则审核、文档撰写等B端业务时，绝大多数任务都是指令式的。

B端场景是截然不同的：

1. 1. 确定性高于一切：审核什么规则、抽取什么字段、代入什么公式，都有严格定义，不能自由发挥。

2. 2. 高频与高准率：我们的任务不是解决一次复杂难题，而是要稳定、准确、快速地解决成千上万次同质化问题。准确率往往要求99%以上，且无法依赖人工多轮对话微调。

3. 3. 算力与合规限制：客户数据不出域，我们无法使用云端巨型模型，只能在本地部署7B、30B、70B级别的模型。

因此，市面上那些针对通用场景的“智能体构建指南”，对于我们在算力受限、容错率低的场景，参考价值有限。

所以，我自己单写一篇。

“忘了所有的提示词模板吧”

有些提示工程师喜欢用各种神奇首字母凑单词来命名模板，这比沪上的面包店和Bistro给菜品命名还要做作。

诚然，在2023年，给大模型设定严格的角色，或者念咒语般地让它“Let’s think step by step”是有效的。但到了2025年，大多数基座模型已不再依赖特定的模板就能表现优秀。

这不是一道把空填满就能得分的题目。具体的结构不重要，但“有结构”很重要。

• • 精简：避免冗长的提示词，但要保持System Prompt（系统提示词）的稳定性。这不仅节省Token，更能最大化利用KV Cache（缓存）。

• • 别让模型猜：如果有背景知识和上下文，直接给模型，不要让它猜。

• • 关闭“思考”：对于有严格、预定义步骤的任务，不要让模型自己规划。该关掉Chain of Thought（思维链）的时候就果断关掉，直接执行。

在B端工作流构建中，“分而治之”是核心共识。

• • 拆解节点：不要试图用一个冗长的提示词解决所有问题。将任务拆解为多个节点，确保每个节点的提示词拥有最小逻辑闭环，且难度在模型能力覆盖范围内。

• • 警惕“SOTA依赖症”：总是依赖SOTA（State Of The Art）超大模型一站式解决问题，本质上是一种思维上的懒惰。

• • 降本增效：要学会在工具箱里通过组合使用更小尺寸的模型来解决问题。如果能意识到某个环节可以用30B甚至7B模型搞定，而不是盲目上70B+，在一个高频任务中节省的成本起步是十万级的。

此外，做好前处理和后处理至关重要。在提示词里“仅输出JSON格式，不要加评论”是坏的，在代码的后处理节点里写一个 .strip 是好的。

“构建标准集，不要打补丁”

构建完整的、覆盖全面的评测数据集（Evaluation Dataset）。这是一条需要“死记硬背”的铁律，因为其他的东西可以边干边学，但数据集如果不在项目初期就开始积累，后期往往无法弥补。

拒绝“打补丁”式的修复：

不要针对每一个具体Bad Case去打补丁。建立“规模化收集——分类定位——批量处理——回测”的闭环。

• • 逻辑问题：回归到工作流链路或代码/提示词层面进行通用性修改。

• • 个例问题：既然是长尾个例，不如通过高召回阈值的RAG链路，外挂一个“错题本”来针对性解决。

最后，任务和评测必须有明确的 Exit（出口条件）：

• • 什么是“通过”，什么是“不通过”，什么情况必须“转人工”？

• • 字段的取值范围是什么？抽取不到是填空、填Null还是报错？

• • 如果涉及循环，Break的条件是什么？

在落地应用层，我们要控制过度的定制化。因为你在细枝末节的长尾问题上所做的、Case-by-Case的、消耗大量精力的“硬编码优化”，很可能半年内就会被新一代模型或工具的能力覆盖掉。

记住：小黄车只负责从地铁站到目的地的最后一公里，别骑着小黄车去下一站地铁。

• • 抓大放小：尽可能不要花巨大精力去解决个例性质的长尾问题。

• • 模块化沉淀：尽可能花巨大精力，保持提示词和工作流的高度模块化。

• 一个具体的实践：从你每次写提示词都会复制粘贴的那段话开始，逐渐“合并同类项”和“取最大公约数”，将其封装成可复用的模块。

2023年我们说“学LangChain的思路，而不是照搬代码”；2025年这个所谓的“Agent元年”，面对满天飞的架构图，原则依然不变。

我们要借鉴的是思路，而非生搬硬套：

• • RAG链路：思路打开，你可以在任何库里检索任何东西，然后用到流程的任何地方，不局限于“问答”。

• • 工具调用：把复杂的路由问题（Routing），转化为简单的分类问题（Classification）。

• • MCP与结构化：把复杂的生成任务，转化为填空题。

• • 复杂决策：把开放的、多层的分类问题，转化为树形的、分层的选择题。