AI 产品经理洞察与博客 | AI PM Insights

前阵子和同事宇刚聊起企业级 AI 落地，他写了一篇文章介绍了一个关于门店备货执行的本体设计案例（点击阅读宇刚的原文），非常具有启发性。

在这个场景中，门店备货绝非简单地“看到货架没奶了就下单”。它背后交织着多重实体的状态和业务逻辑：从系统生成的到货计划——调拨单（Transfer Order），到货物实际运抵门店的到货记录（Delivery），再到对每一个箱子进行条码扫描核验的箱号扫描（Carton Scan）。同时，还要判断**陈列位置（Fixture）是否被旧活动占用，以及当天在班的员工（Staff）**是否具备视觉陈列（VM）的认证技能。

宇刚把这个复杂的物理世界解构为了一个清晰的 “本体模型”（Ontology）。在这个模型里：

Agent（执行者/大脑） 扮演的是“执行者/大脑”，相当于门店里那个负责观察、计划并点击下单的店长。
Ontology（本体论） 则是“语义层/世界观”，相当于门店的“经营字典与规则手册”。它清晰地定义了什么是可用库存，规定了促销活动与物料到位之间的约束，并划定了哪些动作在什么情境下是违规的。

如果没有本体，大模型在面对复杂的“脏数据”时，就会发生逻辑灾难——它可能会在未完成箱号核验、不知道实际损耗的情况下，仅凭调拨单的数据就盲目上架，或者在陈列位置被占用时强行推行新活动。大模型必须有一张严密的“地图”来告诉它：这个业务世界是由什么构成的，规则的红线在哪里。

🛠️ 标准化：我们将“本体设计”固化为一个 Skill

在日常的 AI 产品实践中，如果每次都以“脑暴提示词”开始，Agent 的行为就会变得不可预测。因此，我们在团队的 AI 产品经理（AIBP）工作箱中，将本体设计固化为了一个通用的标准能力——agent-ontology-designer（参见 agent-ontology-designer Skill 规范）。这也是我们沉淀在 AI Accelerator - AI 创新加速器和 AI 2.0 产品实践指南中的核心工具之一。

我们参考了宇刚的建模思路，将 Agent 的本体定义为三个清晰的层次：

建模层级	核心解决问题	建模具体内容
Layer 1 · 对象关系	这是什么？	领域内的实体（Entity，如门店备货中的调拨单、陈列位置）、关键属性（Attribute）与关联关系。
Layer 2 · 行动边界	现在能不能做？	判定决策的情境（Situation）、所需证据（Evidence）、合法动作、禁止动作以及异常触发条件。
Layer 3 · 状态迁移	做完以后去哪里？	核心执行流（Workstream，如收货流程）、状态节点（State）、迁移条件与安全护栏。

在实操中，产品经理不需要直接去写复杂的代码，而是通过一份结构化的 YAML 文件定义这三层模型。然后，利用我们提供的编译工具，一键生成一个带有交互的三 Tab 页面（包含对象关系卡片、行动边界四象限和状态迁移内联 SVG 图）。这使得业务团队与技术团队在开发前，就能在“颗粒度”极细的层面上对齐业务逻辑。

🎯 案例剖析：火车票退改签助手为什么同样需要“本体驱动”？

理解了门店备货的逻辑，我们再来看一个更硬核、对计算精度和合规限制有着 100% 刚性要求的场景——火车票退改签助手。

你可以亲自在这里体验我们搭建的真实案例应用：火车票退改签助手演示系统 (https://ticket.vibeproduct.space/)。

在火车票退改签的场景中，规则的复杂度和门店备货如出一辙，多重条件的嵌套极其考验 Agent 的逻辑收敛能力：

取整与算费红线：不同类型的车票费率和计算截断规则完全不同。境内普通票退票遵循“5角取整”算法；广深港跨境车票则是直接向下截断取整到元（没有5角规则）；中老铁路跨境票则是按20%比例四舍五入。
状态与次数叠加：每张车票仅能改签一次。如果一张车票已经改签过，且列车已经发车，那么它将绝对禁止退票。广深港跨境票改签后产生的新票，更是无论何时都不可退票。
例外政策拦截：如果在购票成功后 30 分钟内且距发车 4 小时以上，注册用户可以享受免费的“误购退票”（日限1次），但改签后的车票或中老铁路跨境票不适用此通道。

在这种高度合规的业务中，如果只给大模型丢一段零散的 Prompt 提示词，它在计算退票费或者判断“已改签、开车后”这种叠加状态时，不仅算不对账，还会被用户通过话术绕过限制规则。我们必须用本体设计为它穿上一件“防弹衣”。

📝 实操展示：用 Skill 绘制火车票退改签的本体图景

我们按照 Skill 的三层设计，为火车票退改签助手编写了本体定义文件（参见本体设计定义）。

在这份业务地图中：

1. 对象关系层（Layer 1 · Object Relations）

定义了 ticket、refund_fee_rule、passenger 和 policy_exception 等实体。不仅标注了实体属性，还厘清了诸如“积分票不可退票，仅可改签且改签差额不退”的概念边界。对象关系层建模示意图

2. 行动边界层（Layer 2 · Action Boundaries）

明确了针对普通退票、改签费测算、误购退票、跨境票等场景的准入边界。例如，处理“误购退票”时，必须收集齐“购票时间”、“发车时间”和“当日额度”等证据，严防规则被突破。行动边界限制示意图

3. 状态迁移层（Layer 3 · State Transitions）

规划了意图分类流、退票费测算流和改签引导流，利用严密的逻辑状态机防止流程发生漂移。状态迁移执行流示意图

通过编译，这套本体在团队内部形成了绝对的可视化共识，省去了反复沟通和需求对齐的损耗。

🧪 验证与迭代：用 Ticket-QA-Agent Skill 跑通自动化沙盒测试

有了本体，在动手写交易执行的核心代码之前，我们先以本体 YAML 自动生成的 System Prompt 作为输入，装配了一个专门负责解答政策咨询的 ticket-qa-agent Skill。

它的核心工作是检验大模型能否在纯自然语言的对话中，准确识别旅客的意图、判定边界并提取关键参数（例如在计算境内车票退票费时，追问旅客是否已经领取了报销凭证）。

为了验证这套“语义大脑”是否靠谱，我们构建了一个包含 120 多个复杂边界测试用例的测试集，并利用自动化回归脚本批量运行：

python3 scripts/run_tests.py tests/Agent测试用例集.md tests/reports

测试引擎会自动对比大模型返回的动作判断与预期是否相符，并输出直观的 HTML 回归测试报告。在没有编写任何交易功能代码前，我们通过这套沙盒验证，就已经确保了 Agent 的政策理解正确率。

🏗️ 工程落地：从问答客服走向真正的 Agentic AI 交易应用

当政策咨询的业务语义被本体完全约束并验证通过后，我们就可以有底气地将其重构为具备真实交易能力的 Agent 交易应用了。

根据火车票退改签助手的整体架构（详见系统架构设计），我们确立了企业级 Agent 落地的黄金法则：

💡 “让大模型做语义理解，让本地代码做确定性裁决，让服务端承担唯一执行边界。”

系统的核心骨架和时序调用链路图如下：

火车票退改签助手架构与调用链路

我们在正文中探讨过，在落地企业级AI应用，产品经理要会的20件事中，我们提到过系统规则的刚性边界。为了防范大模型的逻辑幻觉，我们设计了五层分层模型：

展示层：前端 React 界面（包含聊天对话、车票看板、退改签测算计算器）。
接口层：Next.js 后端 API 控制器（如 /api/chat 和 /api/ticket/execute）。
编排层：利用 LangGraph 状态机（agentGraph.ts）编排节点的流转、提取参数和做分类防护。
规则与领域层：这是决定成败的关键。我们编写了纯 TypeScript 实现的 rulesEngine.ts（规则引擎）和 ticketPolicyService.ts（策略服务）。所有费用计算、业务能不能办的最终裁决，全收口在这层代码中，这里是财务和业务的“单一真理源”（Single Source of Truth）。
数据层：内存数据库 mockDb.ts 确保数据存取的事务一致。