从提示工程到概念工程的演变：迈向更具未来感的AI交互

📢 转载信息

原文链接：https://www.kdnuggets.com/the-evolution-from-prompt-engineering-to-concept-engineering

原文作者：Nate Rosidi

标题：从提示工程到概念工程的演变：迈向更具未来感的AI交互

副标题：了解从脆弱的提示字符串到可重用、可测试构建块的面向未来的转变。

图片来源：作者
 

引言

 
提示工程之所以能够大放异彩，是有其原因的。

它是无需微调或自定义基础设施即可从语言模型中获得有用行为的最快方式。然而，构建实际产品的团队很快就会发现一种模式——你越依赖一个单一的、庞大的提示，你的系统就越感觉像是在用胶带粘合起来。

概念工程是下一个抽象层。与其将交互视为“一个巧妙的令牌串”，不如将其视为一组显式的概念：输入、输出、约束、工具和成功标准。这样，提示就只成为一个实现细节。

这一转变体现在多个方面：强制执行契约的结构化输出和函数调用、像DSPy这样的框架，它们可以编译和优化提示管道，以及真正地在模型表示内部操作概念而不是重写文本提示的研究。

概念工程的演变 | 图片来源：作者

理解提示工程为何触及瓶颈

 
提示很有效——直到它失效为止。常见的突破点是可以预测的：

• 脆弱性：一个细微的措辞变化就可能破坏格式、语调和准确性。
• 隐藏的需求：只有当用户抱怨时，你才会意识到“简洁”和“包含边缘情况”之间的矛盾。
• 无契约：如果你的下游代码期望字段A、B和C，提示无法真正保证它们。
• 令牌压力：随着示例、策略和上下文的增加，成本会增加，注意力也会变得混乱。

提示工程中有一些好的实践可以提供帮助（清晰的指示、示例、约束），但它们仍然让你停留在“字符串工艺”的领域。

实践中定义概念工程

 
概念工程是一种思维方式和一系列模型，而不是一个简单的、一次性的工具。

起点通常是契约：你定义模型必须产生什么（模式、签名、类型）。这就是你定义“正确”意味着什么，以便你可以一致地验证它。

从那里开始，工作流程被视为一组可组合的模块，将工作分解成更小的、可以替换、测试和重用的步骤。然后，改进循环基于由评估驱动的迭代：通过针对清晰的指标衡量输出来改进行为，而不是凭直觉。

然后，工具边界允许模型决定何时调用工具，但你保持工具本身是确定性的和定义明确的。

最后，出现了一个关于概念级别控制的新兴趋势——研究旨在直接在模型内部表示中定位语义属性。

概念工程的演变 | 图片来源：作者

// 比较相同问题的提示方法和概念方法

考虑这个实际的请求：“读取客户消息并将其路由到正确的团队，附带一个简短的摘要和紧急程度。”

// 应用提示方法

提示方法通常很脆弱：

你是一个支持分诊助手。任务：1）用2句话总结消息。2）选择仅一个路由团队：账单、技术、账户、销售或其它。3）设置紧急程度：低、中、高。规则： - 如果用户提到收费、退款、发票、付款或卡片问题 => 账单 - 如果用户提到错误、bug、登录问题、崩溃、集成 => 技术 - 如果用户提到取消、计划更改、席位、权限 => 账户 - 如果用户询问价格、演示、企业版、升级 => 销售 输出格式（严格）： Summary:  Team:  Urgency:  Message: {{CUSTOMER_MESSAGE}}

这通常能工作得非常好。然而，“严格”并不总是严格的，因为一句额外的话或一个有创意的同义词就可能破坏解析。

// 应用概念方法

你首先定义系统所需的概念：一个模式、一个路由策略和一个验证步骤。

1. 定义输出契约（模式）
结构化输出将模型约束在开发者提供的 JSON 模式内，这使得在生产环境中路由输出更加可靠。

{ "type": "object", "properties": { "summary": { "type": "string" }, "team": { "type": "string", "enum": ["Billing", "Technical", "Account", "Sales", "Other"] }, "urgency": { "type": "string", "enum": ["Low", "Medium", "High"] }, "confidence": { "type": "number", "minimum": 0, "maximum": 1 }, "signals": { "type": "array", "items": { "type": "string" } } }, "required": ["summary", "team", "urgency", "confidence", "signals"], "additionalProperties": false }

2. 提示变得更短，因为契约承载了权重

你将把客户消息分类为支持路由决策。使用路由策略： - 账单：收费、退款、发票、卡/付款 - 技术：错误、bug、登录、崩溃、集成 - 账户：取消、计划、席位、权限 - 销售：定价、演示、企业版、升级 返回与提供的模式匹配的JSON。 Message: {{CUSTOMER_MESSAGE}}

3. 添加确定性后备机制
如果 confidence < 0.6，则路由到“其它”并标记为人工审查。该规则是确定性的代码，而不是提示文本。

这就是概念工程：所谓的“分诊”理念变成了一个你整个技术栈都能理解的坚实产物。

探索实现概念工程的技术栈

 
这些是推动行业超越手工制作提示的关键赋能者。

概念工程的演变 | 图片来源：作者

// 利用结构化输出和函数调用

当你的应用程序需要机器可读的结果时，模式就很重要。OpenAI的结构化输出旨在比以前的“仅有效JSON”方法更可靠地遵循开发者定义的模式。

实际上，这减少了解析失败、奇怪的格式和静默的数据漂移，同时鼓励团队采用契约和接口，这正是概念上的转变。

// 使用声明式管道而不是提示字符串

DSPy是编程而非提示的一个很好的例子：你描述模块和指标，系统会在管道内部优化提示和策略。

关键在于抽象：

• 提示成为参数。
• 工作流成为图。
• 改进成为编译和评估，而不是基于直觉的手动编辑。

// 超越文本指令进行概念级别控制

某些研究通过将概念视为可以在模型内部激活中进行建模和管理的实体，从而进一步发展。PaCE（节俭概念工程）是这方面的一个例子，旨在删除或调整不期望的概念，同时保留有用的行为。

今天你不需要这些来构建出色的产品，但这是抽象阶梯去向的信号：从令牌到语义。

在不完全改造的情况下采纳概念工程

 
你可以分小步采纳这种思维方式。

概念工程的演变 | 图片来源：作者

// 第一步：在写提示之前写一份“概念规范”

在一页纸上，保持简单，首先写下你的输入（你已经拥有的）和你的输出（下一步或下游系统需要什么）。

接下来，添加你的约束，即防止模型偏离的必需项和禁止项。

最后，定义模型可以调用的工具，以及解释你将如何评估输出的成功指标。即使是这个最小化的清单也能防止提示膨胀。

// 第二步：将你的格式提升为一个契约

如果你需要返回简单的文本，请确保它是一致的：使用标准模板并进行基本检查（必填字段、格式、允许值）。更好的方法是：切换到带有模式的 JSON，这样就可以强制执行结构，并且解析/评估会变得可靠。

// 第三步：添加一个评估循环

要评估输出，请选择一个可衡量的指标：

• “有效模式率”
• “与标记集的路由准确性”
• “摘要有用性（点赞率）”

然后根据数字进行迭代，而不是猜测。对自动提示优化进行的调查突显了手动迭代为何难以扩展。

// 第四步：模块化一个工作流

将一个大的提示分解成不同的阶段：识别信号、决定路由、创建摘要以及生成最终的、有组织的输出。尽管每个阶段仍然“仅仅是一个提示”，但具有清晰的概念边界可以显著简化系统的维护。

在现实世界中导航概念工程

 
纸上谈兵，概念工程似乎很有道理。在生产环境中无意中复制相同的旧“巨型提示”很容易，只是语言更礼貌一些。这部分的目的是保持实用性。

// 识别常见的陷阱以避免

“模式剧场”问题
你添加了一个 JSON 模式，但模型仍然可以在笔记、原因或巨大的自由文本块等字段中塞入模糊性。然后下游逻辑悄悄地依赖于这些大块数据。

该怎么做：

• 保持自由文本字段简短且目的明确。
• 为关键决策偏好枚举和布尔值。
• 添加置信度阈值和确定性回退路径。

没有测试的概念
如果你无法回答“这次更改是否带来了任何改进？”，你就会回到基于感觉的提示编辑。相反，构建一个小的标记数据集（即使只有50个示例），跟踪几个核心指标（模式有效性、决策准确性、回退率），并在每次更改前后运行相同的评估。

概念工程的演变 | 图片来源：作者

过度模块化
将所有内容分解成许多步骤也可能导致延迟、成本和复合错误。只有在存在真正边界的地方才应采用模块化，并且应合并中间输出未使用或未经验证的步骤。如果输入重复，昂贵的步骤也应缓存。

工具混淆
如果允许模型“使用工具”，但你没有清楚地定义何时需要工具，它可能会猜测而不是调用工具，或者不必要地调用工具。设置一个简单的规则，如“如果输入中没有数据，则调用工具”，保持工具输出的确定性和易于解析，并记录调用以验证它们是否真的提高了结果。

// 建立有帮助的护栏

为了减少意外，请在代码中强制执行硬约束（阈值、允许值、最大长度），而不是依赖于文本。保持模式狭窄，字段少，自由度低。

当风险很高时，请采用两步流程：首先，做出一个组织良好的决定，然后根据该决定创建一个面向用户的文本。

// 重用简单的“概念工程”清单

当您将提示转换为更持久的系统时，请使用此清单：

• 契约：我们有模式或类型化输出吗？
• 概念边界：提取、决策和生成是否在重要的地方分开？
• 回退：当置信度低或缺少必要信息时会发生什么？
• 指标：什么数字告诉我们系统得到了改进？
• 工具策略：模型何时必须调用工具 vs 推断？
• 版本控制：我们能安全地回滚行为更改吗？

分析实际示例

// 为分诊概念添加护栏

如果您使用前面的分诊示例，一个强大的升级是明确地将决策与措辞分开。

第一轮：仅决策（严格JSON）

使用路由策略对消息进行分类。返回与模式匹配的JSON。不要包含道歉或额外的文本。 Message: {{CUSTOMER_MESSAGE}}

第二轮：面向客户的摘要（使用决策作为输入）

编写一个简短、友好的内部摘要供代理使用。使用以下字段作为事实来源： Team: {{team}} Urgency: {{urgency}} Signals: {{signals}} Rules: - 最多2句话 - 除信号外无猜测 返回： Summary: 

虽然听起来微不足道，但这在概念上是一个巨大的胜利：系统的“真相”变成了结构化的决策，而人类可读的文本则成为表示层。

// 查找3个月滚动平均值

查看这个面试题，目标是找到购买收入的3个月滚动平均值。

我们有一个包含 user_id、created_at（日期）和 purchase_amt 的 purchases 表。退款用负的购买值表示，所以我们必须排除负值。

我们需要输出：

• 月份格式为 YYYY-MM
• 月度总收入的3个月滚动平均值，滚动窗口为：当前月+前两个月，按从最早到最晚的月份排序。

// 提示工程方法（单次SQL）

一种典型的提示工程方法是：“编写SQL来按月计算3个月滚动平均收入。”

你通常会得到看起来正确的东西，但你是在信任模型：

• 正确解释“滚动平均”（月度总额的平均值，而不是购买的平均值）。
• 正确排除退款（负值）。
• 按月正确分组。
• 使用正确的窗口帧（正好3个月，而不是“过去90天”）。
• 严格按照要求格式化输出。

这是脆弱的，因为提示一次性暗示了太多内容，并且输出的准确性取决于模型是否默默地做出了你想要的假设。

// 概念工程方法（明确的契约+步骤+检查）

相反，我们将解决方案定义为一个具有清晰契约、明确约束和轻量级验证的小系统。SQL 成为最终的实现细节。

1. 输出契约

• month（字符串，YYYY-MM）
• avg_revenue（数字）= 月度总收入在3个月窗口内的滚动平均值

2. 约束（显式）

• 排除 purchase_amt < 0 的行。
• 月度收入 = 按月分组的 SUM(purchase_amt)。
• 滚动窗口 = 当前月 + 前2个月（即，月度聚合后的 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW）。
• 按月升序排序。

3. 最小计划

• 步骤 A：将购买汇总为月度总额（过滤负数后）。
• 步骤 B：对月份应用窗口函数以计算滚动平均值。
• 步骤 C：将月份格式化为 YYYY-MM。

4. 实现

WITH monthly AS ( SELECT TO_CHAR(created_at, 'YYYY-MM') AS month, SUM(purchase_amt) AS monthly_revenue FROM amazon_purchases WHERE purchase_amt > 0 GROUP BY 1 ) SELECT month, AVG(monthly_revenue) OVER ( ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW ) AS avg_revenue FROM monthly ORDER BY month;

5. 验证检查（“反幻觉”层）
在信任输出之前，我们进行快速的健全性检查：

• 模式检查：只返回 month 和 avg_revenue。
• 退款处理：确认没有负值贡献。
• 窗口正确性：选择一个月份，手动验证它是否平均了正好3个月的总收入（或前1-2个月少于3个月）。

“提示工程”的心态是：问得更好，让模型做得对。

“概念工程”的心态是：设计一个可靠的解决方案形状，然后让模型来填充代码。

总结概念工程

 
提示工程不会消失。你将继续创建提示、调整措辞和处理上下文。然而，具有前瞻性的方法不是将提示视为最终产品。

概念工程的演变 | 图片来源：作者

概念工程提高了抽象级别：定义契约、命名概念、模块化工作流并衡量成功。提示成为一个更容易测试、更安全更改、更易于跨模型和平台移植的系统的一部分。

一个简单的指导原则是：如果你的应用程序依赖于输出，请避免依赖希望和格式指令。相反，依赖于概念，然后让提示做它们擅长的事情，即把意图转化为语言。
 
 

Nate Rosidi是一位数据科学家，从事产品战略工作。他还是分析学兼职教授，并且是StrataScratch的创始人，该平台帮助数据科学家准备来自顶级公司的真实面试问题。Nate撰写有关职业市场的最新趋势，提供面试建议，分享数据科学项目，并涵盖SQL的所有内容。

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。