版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。第 1 章为什么模型会替客人猜1.1 模型补的是“像答案”不是业务事实客人说“帮我订周末的房”熟练的前台会立刻发现哪个周末、几个人、住几晚、要什么房型、能否接受退改限制都没有说清。大模型却很容易产出一段流畅完整的话因为它擅长根据上下文继续生成“看起来合理”的内容。流畅只说明句子接得顺不代表日期、人数或政策来自客人本人。对酒店、旅游、OTA 运营来说这种能力既有用又危险。写欢迎语时补一点语气没有关系进入预订、报价、退款或改签时把未知信息补成确定值就会改变交易条件。真正要防的不是模型“说得不好”而是它把“没有证据”包装成“已经确认”。1.2 酒旅对话里的省略常常连着真实动作同一句自然语言在闲聊和交易里风险不同。判断标准不是“模型能不能猜中”而是“猜错后会不会改变库存、价格、合同或客人权益”。客人原话模型可能擅自补齐可能触发的后果“周末住两晚”把周末解释成某两个日期查错库存或订错日期“给一家人安排一下”把一家人解释成固定人数房型容量与报价不匹配“便宜点就行”自动选择限制更严的产品客人后来无法按预期取消“还是上次那个线路”沿用旧订单中的偏好新行程与当前需求不一致“直接帮我下单”把未确认信息当作已确认系统执行不可接受的动作酒店旅游从业者的优势正是知道一句话后面藏着多少未决条件。转到大模型应用岗位时要把这种经验写成系统能检查的规则而不是只在提示词里提醒一句“请仔细询问”。第 2 章第一条硬规矩——先列必填槽位2.1 把脑中的接待清单变成字段slot槽位指一条任务里非有不可的信息字段。对住宿或线路预订最小清单至少要覆盖人数、入住与离店日期、房型或线路、取消与退款政策、联系方式。不同业务可以增加儿童年龄、证件要求、接送地点但不能在对话中临时凭感觉决定哪些字段重要。槽位住宿任务示例线路任务示例缺失时处理人数成人与儿童人数参团人数与儿童年龄追问不代填日期入住日、离店日出发日、返程日追问并二次确认产品房型线路与班期追问或给候选项政策取消和退款条件退团和改期条件展示原文并二次确认联系方式可接收通知的号码可接收通知的号码追问并最小化保存schema 是对数据结构的明确约定可以理解为“字段名、类型、是否必填”的机器版表单。下面的示例把所有业务字段列入required但允许尚未取得的值为null。这样“字段存在”与“客人已经提供有效内容”就不会混成一件事。⚠️代码待验证{type:object,properties:{guest_count:{type:[integer,null],minimum:1},check_in:{type:[string,null]},check_out:{type:[string,null]},product_choice:{type:[string,null]},cancellation_policy:{type:[string,null]},contact:{type:[string,null]}},required:[guest_count,check_in,check_out,product_choice,cancellation_policy,contact],additionalProperties:false}2.2 必填不等于可以编值required约束的是输出结构里要有这个键不会证明值来自客人。工程上还要同时保存字段状态例如missing未提供、provided已提供、confirmed已复核。如果日期字段有一个格式正确的值但它来自系统猜测这个槽位仍应判为未提供。一条可靠记录至少要回答三个问题值是什么、证据来自哪轮对话、当前是否已确认。没有证据片段或消息编号就不能仅凭一个完整 JSON 进入下单。第 3 章第二条硬规矩——缺失就追问3.1 静默补齐只留给低风险展示项“默认 1 人”“默认今晚”“默认不可退”看起来省事实际把系统假设变成了客人意愿。可以静默补齐的只应是不会改变交易实质、且用户随时能看见并修改的展示项一旦影响库存、金额、履约或权益就必须追问。信息类型可以静默补齐必须追问展示偏好日期展示格式、列表排序方式无交易主体无人数、联系方式履约范围无入住离店日期、线路与班期价格条件无币种不明、费用构成不明权益条款无取消、退款、改期条件3.2 追问模板也要配置化追问不是一句“请补充信息”打发客人而是一次只问最阻塞动作的字段说明为什么要问并给出便于回答的格式。模板应与槽位绑定方便产品、运营和测试共同检查。缺失槽位推荐追问停止条件人数“请问几位成人、几位儿童如有儿童请告知年龄。”人数与结构明确日期“请给出具体入住日和离店日例如 10 月 12 日入住、10 月 14 日离店。”两个日期明确且先后有效房型或线路“你想订哪种房型或哪条线路也可以让我先列可选项。”选项唯一可识别政策“这个产品有以下退改条件是否接受”客人明确接受或改选联系方式“请提供用于接收订单通知的联系方式。”格式检查通过且用途已告知⚠️代码待验证required_slots:-guest_count-check_in-check_out-product_choice-cancellation_policy-contactquestion_templates:guest_count:请问几位成人、几位儿童check_in:请给出具体入住日期。check_out:请给出具体离店日期。product_choice:请选择房型、线路或班期。cancellation_policy:请确认是否接受展示的取消与退款条件。contact:请提供用于接收订单通知的联系方式。第 4 章把“不许猜”做成程序门槛4.1 缺失检测必须独立于模型文案不要让同一个模型既填写字段又自行裁定字段是否齐全。更稳妥的做法是模型只抽取候选值应用代码读取配置并检测空值、无效值与证据缺失。检测不通过时系统只能返回追问不得调用落单工具。⚠️代码待验证REQUIRED_SLOTS{guest_count,check_in,check_out,product_choice,cancellation_policy,contact,}deffind_missing(slots,evidence):missing[]fornameinREQUIRED_SLOTS:valueslots.get(name)sourceevidence.get(name)ifvaluein(None,,[])ornotsource:missing.append(name)returnsorted(missing)这段逻辑有两个闸门值为空算缺失没有客人原话或消息编号作为证据也算缺失。即使模型输出了“今晚”只要对话里没有对应依据代码仍会把日期打回追问状态。4.2 用状态机限制下一步状态机就是把流程限定为几个可枚举状态并规定每个状态能做什么。它比“模型自行判断下一步”更容易测试。状态进入条件允许动作禁止动作收集中至少一个必填槽位缺失追问、展示候选项报价锁定、落单待确认必填槽位齐全但关键槽位未复核汇总日期、金额、政策落单、扣款可执行关键槽位均有确认记录调用一次受控动作擅自改字段已执行收到业务系统回执展示结果、接受后续查询重复提交⚠️代码待验证CRITICAL_SLOTS{check_in,check_out,amount,cancellation_policy}defnext_action(missing,confirmations):ifmissing:return{action:ask,slots:missing}unconfirmedsorted(CRITICAL_SLOTS-set(confirmations))ifunconfirmed:return{action:confirm,slots:unconfirmed}return{action:place_order}这里的关键不是 Python 写法而是place_order只能从“可执行”状态触发。提示词写得再周到也不能绕过代码门槛。第 5 章第三条硬规矩——关键槽位二次确认5.1 确认要复述值也要说明动作日期、金额、政策条款属于关键槽位。二次确认不是问一句“没问题吧”而是把即将提交的值逐项复述说明确认后会发生什么并等待明确答复。客人修改任一关键值后之前的确认立即失效流程退回“待确认”。关键项确认时展示什么合格记录修改后的处理日期入住、离店或出发、返程的具体日期字段值、消息编号、时间清除旧确认重新核价金额总额、币种、已包含与未包含费用金额快照、确认原话金额变化后重新确认政策取消、退款、改期的适用条件条款版本或文本快照产品变化后重新展示对于联系方式可以在展示时做脱敏对于政策不能只写“按平台规则”而要给客人能核查的具体文本或链接。确认按钮、明确答复与客服代确认都应留下来源不能只存一个布尔值。5.2 让确认记录可核查可核查记录至少包含任务标识、字段快照、来源消息、确认时间与下一动作。它的用途不是堆日志而是在争议或排障时说明系统执行前看到了什么、客人确认了什么。⚠️代码待验证{task_id:booking_demo,status:confirmed,confirmed_fields:{check_in:2026-10-12,check_out:2026-10-14,amount:{currency:CNY,value:1280},cancellation_policy:policy_text_snapshot},source_message_ids:[msg_in,msg_out,msg_confirm],next_action:place_order}上面的记录结构还需要结合真实业务系统、隐私规则和存储方案验证但原则不变没有关键字段的确认记录就没有动作权限。多轮补全配置清单把必填槽位、追问模板、确认字段和测试用例放进同一份评审材料方便从运营经验过渡到 Agent 工程。放在资料包里扫码即可获取第 6 章官方文档能证明什么不能证明什么6.1 两家模型文档都把输入结构写成契约OpenAI 的 Structured Outputs 官方文档原文是“Structured Outputs is a feature that ensures the model will always generate responses that adhere to your supplied JSON Schema, so you don’t need to worry about the model omitting a required key, or hallucinating an invalid enum value.”同页给出的启用形式包含text: { format: { type: json_schema, strict: true, schema: ... } }OpenAI 的 Function calling 官方文档对strict的逐字说明是“Whether to enforce strict mode for the function call”这些原文说明结构化输出可以约束模型是否遵循给定结构但它不能替业务系统证明某个值确实由客人提供。因此required和strict负责“形状”证据检查与确认门槛负责“事实来源”。Anthropic 的 tool use 官方文档把input_schema定义为“A JSON Schema object defining the expected parameters for the tool.”同页示例对required的逐字解释是“This tool, namedget_weather, expects an input object with a requiredlocationstring and an optionalunitstring that must be either “celsius” or “fahrenheit”.”这说明列入required的参数是必填项未列入的参数可以是可选项。迁移到酒旅任务时应该由业务方先确定哪些槽位必填再交给模型和工具接口执行而不是让模型临场决定。6.2 规章提供经营边界三条硬规矩是工程实现截至 2026-10-06文化和旅游部政策法规目录仍列有《在线旅游经营服务管理暂行规定》官网展示其由文化和旅游部令第 4 号公布自 2020 年 10 月 1 日起施行目录与正文页面没有显示修改或废止说明。与本文直接相关的原文包括第十二条要求在线旅游经营者“应当提供真实、准确的旅游服务信息”并要求预订渠道“公开、透明、可查询”第十四条规定在签订包价旅游合同或者出境旅游产品代订合同时应提示旅游者提供紧急联络人信息第十六条要求提供包价旅游服务时依法签订合同并填报有关信息第十九条要求平台经营者对有关产品、服务和交易信息依法记录、保存并动态管理。这些条文没有直接写出“缺失槽位必须追问”或“关键槽位必须二次确认”。本文的三条硬规矩是面向大模型应用的工程设计用它们减少虚构信息进入交易流程并为真实、准确、可查询、可记录的业务要求提供技术支撑。不要把工程建议冒充成条文原句。第 7 章把酒店旅游经验改写成 Agent 岗位能力7.1 你原来的经验并没有作废前台、客服、民宿主和旅行社计调每天都在做需求澄清识别省略、拆分条件、解释退改、核对日期、处理变更。这些能力转成大模型项目语言就是槽位设计、对话状态、工具调用门槛、确认记录和异常回退。作品集不必先追求一个什么都能聊的机器人。更有说服力的是做一条窄而完整的预订链路准备若干含糊请求证明系统能识别缺失字段客人不确认日期、金额或政策时落单函数始终不会执行客人修改关键项后旧确认会失效每次动作都有可核查记录。7.2 用验收问题判断项目是否真的可交付交付前逐条问必填字段是否在配置中完整列出每个字段是否有对应追问模板系统是否把null与“已经确认”分开模型猜出的值是否会因证据缺失被拦截日期、金额、政策是否全部经过二次确认修改关键值后旧确认是否失效没有确认记录时动作接口是否保持关闭如果答案依赖“模型应该会注意”项目还没有完成如果答案能从配置、状态和测试结果中直接核查酒店旅游经验才真正变成了 Agent 工程能力。核心不是让模型更会猜而是让系统知道什么时候必须停下来问人。Agent 项目验收清单按“字段、追问、确认、动作、记录”五个环节检查作品集避免只展示对话效果。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处文档名 发布方 链接本文位置Structured Outputs 会使响应遵循所提供的 JSON Schema并避免遗漏 required key《Structured model outputs》OpenAIhttps://developers.openai.com/api/docs/guides/structured-outputs第 6 章 6.1Structured Outputs 的启用形式包含strict: true《Structured model outputs》OpenAIhttps://developers.openai.com/api/docs/guides/structured-outputs第 6 章 6.1strict表示是否为函数调用强制严格模式《Function calling》OpenAIhttps://developers.openai.com/api/docs/guides/function-calling第 6 章 6.1input_schema是定义工具预期参数的 JSON Schema 对象《How to implement tool use》Anthropichttps://platform.claude.com/docs/en/agents-and-tools/tool-use/implement-tool-use第 6 章 6.1Anthropic 示例中location为 requiredunit为 optional《How to implement tool use》Anthropichttps://platform.claude.com/docs/en/agents-and-tools/tool-use/implement-tool-use第 6 章 6.1官网目录仍列该规定并展示令号、审议日期与施行日期未显示修改或废止说明《政策法规》中华人民共和国文化和旅游部https://zwgk.mct.gov.cn/zfxxgkml/zcfg/第 6 章 6.2第十二条要求旅游服务信息真实、准确预订渠道公开、透明、可查询《在线旅游经营服务管理暂行规定》中华人民共和国文化和旅游部https://zwgk.mct.gov.cn/zfxxgkml/zcfg/bmgz/202012/t20201204_905349.html第 6 章 6.2第十四条、第十六条、第十九条分别涉及紧急联络人提示、包价旅游合同信息和交易信息记录保存《在线旅游经营服务管理暂行规定》中华人民共和国文化和旅游部https://zwgk.mct.gov.cn/zfxxgkml/zcfg/bmgz/202012/t20201204_905349.html第 6 章 6.2附表 B术语速查表术语一句话解释在本文哪里用到slot / 槽位一条任务中需要收集的独立信息字段第 2 章schema对字段名称、类型和约束的机器可读约定第 2 章required在结构定义中声明必须出现的字段清单第 2、6 章strict用于强制结构化输出或函数调用遵循指定结构的模式第 6 章状态机用有限状态和转移条件限制流程下一步第 4 章关键槽位会直接影响日期、金额或权益条款的字段第 5 章证据片段支撑槽位值的客人原话或消息编号第 2、4 章动作门槛调用落单等外部动作前必须满足的程序条件第 4、7 章写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。