从面向对象到面向意图：提示词工程与领域建模的融合

从面向对象到面向意图提示词工程与领域建模的融合在传统软件工程中“面向对象编程OOP”与“领域驱动设计DDD”是指导复杂业务系统建模的核心方法论我们通过类Class、对象Object、聚合根Aggregate Root和方法Method将现实世界中的业务规则精确映射为一行行静态代码。然而当大模型LLM成为系统的核心计算单元时传统的静态建模遭遇了全新的挑战用户的输入不再是严格遵循契约的强类型 DTOData 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 思想封装意图 Promptfrom 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(defaultFalse, description用户是否显式要求补偿优惠券) compensation_amount_max: float Field(default0.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 思想牢牢锚定系统的业务边界你就能构建出兼具大模型灵活性与企业级确定性的新一代智能体系统。