从面向对象到面向意图：提示词工程与领域建模的融合
在传统软件工程中，“面向对象编程（OOP）”与“领域驱动设计（DDD）”是指导复杂业务系统建模的核心方法论：我们通过类（Class）、对象（Object）、聚合根（Aggregate Root）和方法（Method）将现实世界中的业务规则精确映射为一行行静态代码。
然而，当大模型（LLM）成为系统的核心计算单元时，传统的静态建模遭遇了全新的挑战：
- 用户的输入不再是严格遵循契约的强类型 DTO（Data Transfer Object），而是充满模糊、口语化、甚至自相矛盾的自然语言意图（Intent）；
- 系统的决策不再完全写死在
if-else或状态模式的代码里，而是部分让渡给大模型在语义空间中的概率推理。
很多后端工程师在写 Prompt 时，容易走向两个极端：要么把 Prompt 当作文科写作文，写得天马行空缺乏约束；要么试图在 Prompt 里死板地写满伪代码，导致大模型丧失语义泛化能力。
将 DDD 的领域建模思想与现代提示词工程（Prompt Engineering）深度融合，从“面向对象”升级为**“面向意图（Intent-Oriented Architecture）”**，是构建健壮大模型应用的关键思维跃迁。
一、面向对象与面向意图的核心概念映射
┌────────────────────────────────────────────────────────┐ │ 经典面向对象 (OOP / DDD) │ 面向意图大模型架构 (Intent-Driven) │ ├────────────────────────────────┼────────────────────────┤ │ 领域实体 (Domain Entity) │ 结构化实体槽位 (Entity Slots / Pydantic)│ │ 接口契约 (Interface / Contract) │ 工具描述与元数据 (Tool Metadata Schema)│ │ 业务规则校验 (Invariant / Guard)│ 护栏提示词与断言 (Guardrail Prompts) │ │ 状态流转机 (State Machine) │ 意图生命周期与图编排 (Intent Graph) │ │ 异常处理 (Exception / Try-Catch)│ 反思与自纠错回路 (Self-Reflection Loop)│ └────────────────────────────────────────────────────────┘二、面向意图建模的三大核心步骤
[ 现实业务问题: 用户希望退货并补发差价优惠券 ] │ ▼ ┌────────────────────────────────────────────────────────┐ │ 步骤 1: 意图实体与槽位定义 (Intent Schema Modeling) │ │ 将模糊诉求抽象为具备必填/选填槽位的领域模型 (Slot Modeling)│ └─────────────────────┬──────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ 步骤 2: 意图执行空间收敛 (Action Space Scoping) │ │ 为该意图绑定专属的确定性 API 工具与最小权限集 (Tools) │ └─────────────────────┬──────────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ 步骤 3: 语义护栏与后置断言 (Semantic Invariants) │ │ 声明必须遵守的硬性业务边界 (例如: 优惠券金额不得超过50元) │ └────────────────────────────────────────────────────────┘生产级 Python 代码示例：用 DDD 思想封装意图 Prompt
from typing import Dict, Any, Optional from pydantic import BaseModel, Field # 1. 意图实体建模：槽位（Slots）就是领域对象的属性 class ReturnOrderIntent(BaseModel): order_id: str = Field(..., description="待退货的真实订单编号") reason_category: str = Field(..., description="退货原因分类：QUALITY_ISSUE, LOGISTICS_DELAY, PERSONAL_PREFERENCE") wants_coupon_compensation: bool = Field(default=False, description="用户是否显式要求补偿优惠券") compensation_amount_max: float = Field(default=0.0, description="申请补偿的最大金额") # 2. 意图提示词构建器：高内聚地组装人设、规则与语义断言 class ReturnIntentPromptBuilder: DOMAIN_NAME = "E-Commerce Return & Refund" @classmethod def build_system_prompt(cls, user_level: str) -> str: return f""" 你是一名负责【{cls.DOMAIN_NAME}】的专业领域智能体。 【当前服务对象画像】: 用户等级 = {user_level} 【核心职责】: 1. 准确识别用户退货诉求，提取订单号与退货原因； 2. 严格核验用户退货诉求是否符合平台 7 天无理由退货政策； 3. 若用户索要优惠券补偿，必须严格遵守以下领域不变量（Invariants）。 【领域不变量（硬性业务规则）】: - 规则 1: 普通用户最高仅可申请 10 元无门槛优惠券；VIP 用户最高可申请 50 元优惠券； - 规则 2: 若商品状态为“已签收超过 15 天”，严禁触发自动退款工具，必须引导用户申请人工仲裁； - 规则 3: 严禁在未确认订单号前直接调用 `issue_refund_ticket` 工具。 【输出规范】: 必须以结构化 JSON 格式输出意图解析结论与拟调用的工具动作。 """三、面向意图架构带来的工程优势
- Prompt 不再是一团混乱的自然语言散文：
每个 Prompt 都对应着清晰的领域边界、输入 Schema、前置断言和不变量约束，具备了像传统代码一样的模块化与高内聚特性。 - 极大地降低了测试与调试成本：
每一个 Intent 都可以独立编写单元评测集（Unit Evals），针对“槽位提取准确率”、“规则遵从率”进行自动化批量回归。 - 团队协作边界清晰：
业务架构师负责定义意图的领域模型与不变量，Prompt 工程师负责打磨语义表达，后端工程师负责实现底层的 Tool RPC，各司其职，彻底摆脱过去的混乱协同模式。
四、写在最后
大模型时代并没有淘汰软件工程的基本原理，而是对工程师的抽象与建模能力提出了更高的要求。
把自然语言当作接口，把大模型当作概率计算器，用经典 DDD 思想牢牢锚定系统的业务边界，你就能构建出兼具大模型灵活性与企业级确定性的新一代智能体系统。
)
