旅行社如何用 Claude Code 安全制作行程单与报价

设想一个周五傍晚的忙碌场景：几条定制咨询同时进来，其中一条是假设需求，“下周末两人去京都住两晚，预算两万元左右，想看红叶、吃怀石料理”。定制师还要核对空房、路程、价格、退改条款和错别字，才能交出方案。

这是 ClaudeCodeLab 为测试流程编写的纯虚构场景，没有使用真实客人资料、订单号、供应商报价或旅行社内部数据。本文只验证两件事：Claude Code 能否按规则生成行程草稿，以及本地脚本能否拦住报价合计错误。

本文不承诺固定的提速幅度。应先记录人工基线，再用同类样本做试点，把“交给 AI 的部分”和“必须由人确认的部分”划清楚后再计算收益。

本文要点

• 行程单、报价、提案方案里的“拼装和誊写”是 AI 的强项。定制师可以把精力集中在选目的地和接待客人上
• 文中给了可直接套用的提示词模板，以及一段用机器揪出费用算错的对账检验脚本
• 价格、库存、退改规定这类“一旦出错就是事故的数字”必须人来确认。划清这条线，是安全使用的前提
• 个人信息先把姓名和订单号打码再交给 AI。先定好“不贴原始数据”的操作规矩
• 不预设节省时间，先用基线和试点时间戳测量；下文给出可复算的 ROI 公式

旅行社的活儿到底重在哪

读这篇的，多半是在门店或做企业客户、给人定制旅行的定制师。比起卖打包好的跟团产品，那些更多是听需求从零拼的人，这篇文章会更对口。

定制提案大致是这么走的：

1. 沟通需求：问目的地、人数、预算、喜好、不能少的条件
2. 收集素材：查酒店、交通、当地体验的候选项和价格
3. 拼装行程：边看路上时间和空房情况，边落到每天的日程里
4. 出报价：把住宿、交通、操作费、税费加起来算总价
5. 誊写成稿：整理成行程单和提案方案，附上注意事项
6. 提交并修改：给客人看，再把“第二天多安排点观光”之类的修改改进去

其中第 1 步和第 6 步应保留人的判断，因为它们需要理解客人的优先级和没有说出口的预算。而第 3 到第 5 步，是把已经确认的素材放进固定框架。耗时会随行程复杂度变化，因此不要引用统一时长，而要记录各阶段的开始、结束和返工次数。

客人一句“第二天能不能再松一点”，路上时间和费用就得全部重排。Excel 里挪了一行，合计就对不上了，没察觉就交出去，事后脸红。这种小事故，现场其实悄悄地多。

交给 AI 的部分，和人必须判断的部分

这里要是含糊就会出事。先把线划好。

工序	交给 AI	人必须判断
沟通需求	检查问题有没有遗漏	预算的真实底线、合不合得来、氛围的读取
收集素材	候选项的初步查询、做对比表	库存空房的最终确认、推荐项的取舍
拼装行程	考虑路上时间的日程草稿	动线累不累、体力扛不扛得住
出报价	搭计算公式、合计的草稿	进货单价、汇率、退改规定的数字
誊写成稿	整理成行程单和提案方案、查错别字	最终审批、客人名义的确定

要记住的分界只有一条：“一旦出错会引发退款或投诉的数字”，必须人来确认。 价格、空房、退改费、按年龄区分的票价、汇率。这些别照搬 AI 的草稿，要拿进货方的正式报价来核对。AI 是手快的誊写员，但它不替你担保价格。

用例一：从需求备忘录生成行程单草稿

沟通时记的备忘往往是一堆零散要点。把它整理成日程表的重复劳动可以交给 AI，但路线是否合理、是否符合客人体力，仍由定制师判断。

下面是可以直接套用的提示词模板：

你是旅行社的资深定制师。
请根据下面的需求备忘，做一份路上时间不会太赶的行程单草稿。

# 需求备忘
- 目的地：京都
- 日程：3 天 2 晚
- 人数：夫妻 2 人
- 预算：总价 2 万元上下
- 希望：红叶景点、晚上吃怀石料理、行程别排太满

# 输出规则
- 每天按“上午/下午/晚上”分段
- 每一项写上大致耗时和交通方式
- 单程超过 1 小时的地方，标注“★路途较长”
- 需要价格的地方写成 [待确认:价格]，不要擅自填数字
- 最后用要点列出“需要确认的项目”

最后两行是关键。别让 AI 擅自填价格，把它留成 [待确认:价格] 这样的占位符。 这样能避免 AI 编一个看着像样的假价格出来的事故。拿到草稿后，再把你从进货方拿到的正式价格灌进去。按这个分工，用起来才放心。

还不熟悉 Claude Code 基本操作的人，先读一下Claude Code 入门指南，就能马上把这个模板试起来。

用例二：用机器揪出报价合计的算错

提案方案里最怕的就是价格加错。一晚两餐乘以人数、税费和服务费、操作费。用 Excel 拼的时候，加了一行，合计的范围就错位了，没察觉就用偏低的金额交出去。这是要道歉加自掏腰包补差价的路线。

所以下面提供一段检查报价明细的脚本。装了 Node.js 就能跑。它把明细金额重新相加，再核对是否与方案中展示的总价一致。

// verify-quote.mjs  检验报价明细与总价是否一致
// 运行：node verify-quote.mjs

const quote = {
  customer: "（打码）先生",
  items: [
    { label: "住宿 第1晚 旅馆A 2人", amount: 4800 },
    { label: "住宿 第2晚 旅馆B 2人", amount: 5200 },
    { label: "高铁 往返 2人", amount: 5600 },
    { label: "当地向导 半天", amount: 1800 },
    { label: "操作费", amount: 800 },
  ],
  tax: 1440, // 税费等
  presentedTotal: 19640, // 写进提案方案的总价
};

const subtotal = quote.items.reduce((sum, item) => sum + item.amount, 0);
const calcTotal = subtotal + quote.tax;

console.log(`小计：${subtotal.toLocaleString()}元`);
console.log(`税费：${quote.tax.toLocaleString()}元`);
console.log(`算出的总价：${calcTotal.toLocaleString()}元`);
console.log(`方案上的总价：${quote.presentedTotal.toLocaleString()}元`);

if (calcTotal === quote.presentedTotal) {
  console.log("OK：明细与总价一致");
} else {
  const diff = quote.presentedTotal - calcTotal;
  console.log(`NG：差了 ${Math.abs(diff).toLocaleString()} 元，交出去之前请先改正`);
  process.exit(1);
}

把 presentedTotal 设成方案上的数字，一旦对不上就会以 NG 停下来。这是交给客人之前的最后一道门卫。items 里的单价本身，前提是填人在进货方确认过的值，这里只做对账。把“对账”和“确认价格”分开看待，这一点很重要。

想把提示词的精度再提一截的人，顺便看看提升提示词精度的技巧。

用例三：一句“第二天松一点”的修改，一次改到位

提交之后的修改也是适合 AI 的环节。不要每次重写整份行程，而是限定改动范围并使用下面的指令：

请在刚才那份行程单上，套用下面的修改。
- 第2天：上午减掉一个安排，下午加 1 小时在酒店休息
- 因此变动的路程部分，把耗时重写
- 价格会变的项目，改回 [待确认:价格]
- 改动过的地方在开头加“▼变更”，用一行说明改了什么

诀窍是要求它“在改动处做标记”。审阅者可以集中检查改动位置及受影响的总价。价格会变的项目应恢复成 [待确认:价格]，重算仍由人负责，避免行程已更新而总价仍是旧值。

把行程和提案方案的模板让项目记住，就不用每次从零开始下指令。做法可以参考CLAUDE.md 写法。

可直接复制的交付前核对清单

交出提案方案之前的最终核对，写在纸上、记在便签上都行，每次都过一遍这几条：

• 价格是否和进货方的正式报价核对过了
• 空房、库存是否做了最终确认（有没有轻信 AI 的草稿）
• 退改规定和按年龄区分的票价是否写进了正文
• 是否跑过对账脚本、确认合计一致
• 客人的姓名、订单号是否改回了正确写法
• 路上时间会不会太赶（带老人、带小孩的尤其要注意）

个人信息与安全注意事项

旅行手配涉及姓名、出生日期、护照号、订单号，是敏感信息的集合。这些别原封不动地贴给 AI。

操作规矩简单两条。第一，个人信息先打码再交。 姓名换成“A 先生”，订单号换成“（打码）”。拼装和誊写用不到真名。第二，原始数据放在本地管理，最后只有把名义填进去这一步由人在自己手边做。 让 AI 搭模板，能定位到个人的信息在自己手边填。守住这个顺序，会让外人为难的信息就不会流出去。

如果是公司层面引入，最好把“什么能交、什么不能交”写成明文，会更安全。团队里怎么划这条线，可以在培训与咨询里一起理清。判断标准含糊地发给所有人，总会有人把原始数据贴进去。

如何测量时间与 ROI

下表不是已经实现的成果，而是试点时应填写的测量计划。请对相似需求分别记录人工基线和 Claude Code 辅助流程。

测量阶段	人工基线记录	试点记录
需求备忘到首版草稿	开始、结束时间	同样的时间戳及所用提示词
价格确认与合计核对	人工核对时间、错误数	人工确认时间、脚本结果
修改处理	收到修改到批准的时间	变更行、审阅时间、重算结果
最终批准	审阅人、修正次数	审阅人、占位符与 PII 检查

**仅作估算的 ROI 示例：**如果测得人工基线为 90 分钟、试点为 70 分钟，每月处理 60 份同类方案，则估算节省时间为 60 × (90 - 70) ÷ 60 = 20 小时/月。这不是保证值；是否采用应依据自己的时间戳、审阅成本和工具成本判断。

担心不是工程师能不能用的人，读读不是工程师也能用的 Claude Code，迈出第一步的门槛会低不少。

常见问题

问：我担心 AI 会擅自定价。 答：在提示词里用 [待确认:价格]，让它不填数字。价格只填人在进货方确认过的值。把 AI 的角色固定成“管计算公式和誊写”，它就不会乱来。

问：填客人的真名和订单号没问题吗？ 答：请不要填。先打码再交，最后填名义这一步在自己手边做。拼装和誊写用不到个人姓名。

问：我们有自己的行程模板，能复刻吗？ 答：能。把自家的模板和格式规则让项目记住，它每次都会照着那个形式输出。具体设置方法请查官方文档。

问：能完全自动化、省掉人工确认吗？ 答：不建议。价格、库存、退改规定的确认，前提是人来握住。省掉这步，错误就会原样送到客人手里。提速只限于“拼装和誊写”才安全。

使用虚构数据实际测试的结果

ClaudeCodeLab 只使用文中的虚构金额运行了 verify-quote.mjs。presentedTotal 正确时，脚本输出 OK。随后把展示总价故意改动 1 元，脚本输出 NG，并以进程状态 1 退出。测试没有使用供应商正式报价或真实订单。

同一条虚构京都需求也用于检查提示词输出。输出经过人工审阅，确认需要价格的位置保留了 [待确认:价格] 占位符，并且不含姓名、订单号、护照号等个人身份信息（PII）。这项测试不证明生产环境的准确率或固定节省时间。

本次能确认的范围只有：样例总价正确时通过、被改动时失败，以及占位符和 PII 规则可以人工核验。上线前请先用脱敏的历史案例做自己的试点。第一次操作 Claude Code 时，可以从Claude Code 入门指南开始。

想提升整体效率，也可以参考Claude Code 效率技巧。官方用法请参考Claude Code 官方文档。