我最近用 Codex 做旅行攻略踩了几次大雷

我在 AI 帮助下做旅行攻略分三个阶段：

• 第一阶段：通过 Gemini 查资料，古法组装符合个人偏好的行程

• 第二阶段：通过 Codex 生成目的地资料库与行程建议，在这二者基础上古法组装行程，最后生成行程 HTML 随身出行

• 第三阶段：在第二阶段的基础上，通过对话指挥 Codex 把行程建议 HTML 改成我满意的正式版

在第三个阶段，我吃了大亏。

8-10 月的法国-意大利-西班牙旅行，因为意外事故，46 天旅行有一半的行程直到出发还没计划，只能在每天旅行结束后回酒店做一会儿攻略，白天继续远程指挥 Codex 跑长任务，相当于把集中生成旅行攻略，分拆到了多次修改分批生成。修改次数越多，暴露出来的问题越多。

直接说我遇到了哪些问题吧，前提是，这是一份 46 天的漫长的行程攻略，饱满的细节几乎有一款小型产品的复杂度。

第一个问题是耦合项太多。修改一个地方时，其他多处被一齐修改。

比如每天行程调整后，会修改：

• 当天的行程强度标签、行程总结与取舍、天气对行程的影响、与当天有关联的其他日期行程

• 当天和全程的费用汇总

• 目的地下的公交策略与省钱策略

• 首页的预约项目提醒

这样的耦合之处很多，以至于修改缓慢，即便缓慢也拦不住遗漏和出错。

第二个问题是指令依从性差。

这次 46 天的欧洲旅行，包含 15 个目的地和 245 个景点，完整的行程 HTML 包含 500 多张各种类型的卡片，每张卡片平均 5 个字段，单个字段有可能是一条复杂度不算低的需求。

在这个背景下，哪怕我让 AI 分批生成，甚至是分天生成，依然解决不了指令依从性差的问题。拆到分天生成之后已经没法再拆了，于是我尝试先打样，有了清晰的标准再要求 AI 执行。

这里出现了两个执行分支：

1. 打样成功，顺利通过测试集，应用到全局时直接摆烂

2. 打样失败，出现了惊悚的错误

后者值得描述一个令人绝望的案例。

当时的需求是：每一个景点都要查到它在 Google 地图上的超链接，并显示 Google 地图上的外文名（不一定是英文名，也不一定是本地语言名，只能挨个查验）。Sol 执行这个需求时出现了大量的错漏，大约 30% 的超链接点过去无搜索结果。

我想了想，教给 Codex 一个方法技巧：发现 Google 地图未返回正确结果时，在 Gemini 里用我写好的提示词，输入目的地和景点名，让 Gemini 通过 Google 地图 API 获取正确的地图链接。这件事我试过上百次准确无误，打算让 AI 替代我来完成体力活。

Astra 第一次打样成功，第二次打样成功，第三次把景点名和第二次的目的地瞎拼在一起，搜出了错误的地图链接，然后告诉我打样成功。

指出错误后，Astra 回复：我没有能力完成这个任务，你不应该再信任我。

继续追问原因，大意是：AI 在判断 “地图链接是否准确” 这件事情上是不稳定的，经常会消耗大量的算力却判断不了地址是否准确。

当然，如此低级的错误很可能和 9 月中下旬 GPT 降智有关。但即便是 8 月还没有降智的时候，这个需求烧了上亿的 token 也没有做好。

第三个问题是低效率的门禁。严格来说，是 AI 提不出工程上的合理解法。

因为指令依从性差，频繁在 HTML 中发现不按规则来的错误，从内容到样式遍地拉屎。常用的处理方法是让 AI 自己总结出错原因以及解决方案，每一次都能讲得头头是道，然后继续出错，继续出错后的解决方案往往是增加更多的门禁，用核验来遵守承诺。

看我口型：呸！

我并没有感觉到增加门禁之后出错明显减少，但感觉到增加门禁之后的修改时间显著延长，有时候调一下前后两个景点的顺序都会跑 20 分钟，以至于我经常打断执行：“你是不是又抽风了？”

AI 诚恳地回复我：对！我再一次进行了错误的发散。不是从单元检查发散去全局检查，就是门禁撞墙然后反复尝试。经常因为一处无关紧要的细节出入触犯了门禁，然后反复修改，并发散为全局修改。

这就是人不懂工程，把自己的短板委托给 AI 的可耻的下场。

于是我从大量发现错误到增加门禁，从增加门禁到简化门禁，从简化门禁到简化攻略需求，中途还用 Astra 重构过两次试图提高执行效率，就差倒退回古法了。事实上我很确定，如果只是用 AI 搜索信息，古法组装行程，消耗的时间至少会减少 5 倍。

但一方面我特别喜欢这份 HTML 的样式，想把 46 天完整的行程回忆留存在 HTML 里；另一方面，AI 能够帮我计算 POI 之间的最佳交通方式（去 Google 地图查询），每一个景点的开放时间与省钱策略（欧洲景点特别复杂），看上去帮我省了很大的力——这其实是一个骗局，工程上低效率的执行浪费掉了 5 倍的时间，欧洲旅行前半程的每晚都在和 Codex 斗智斗勇斗狠。

到最后，我把动态信息核验、行程设计、HTML 样式生成这三件事彻底分开，用这种（我提出的）原始的工程思路勉强完成了行程计划，而 AI 给我的各种高逼格工程思路全部都是 shit！shit！shit！

第四个问题是无限膨胀的规则。

AI 出错后我常用的回应是 “先把这里改好，总结错误，修订规则避免发生同类错误”。很多时候我都不用发出指令，AI 会自动总结错误并修订规则。

在我和这份行程 HTML 战斗了几十个小时后，生成与维护行程的规则文档已经扩大到了 5 万字。其中包含大量的偶发错误，有些甚至是某个目的地下某一天的特定错误，改正错误时也写进了规则文档。

所以，单就我这个案例而言，那种 “你只需要确认交付没有问题，就不用检查规则文档” 的观点，在我这个场景下肯定是不行的。

以及另一种 “只要你不断地发现问题，修改问题，问题就会越来越少” 的观点，在我这个场景下同样是不成立的，问题层出不穷/花样翻新/顽固复发。

旅行结束后，我觉得自己的节奏慢下来了，脑子也清醒了，用 Astra 最高推理档位来优化规则文档——Astra 说得头头是道，我指出的所有问题都有对应之策，最终把规则文档从 5 万字精简到了 1.6 万字。

结果你猜怎么着？

我让 Astra 用最新规则重跑欧洲行程 HTML 进行检验：问题层出不穷/花样翻新/顽固复发。

直到 6.1 Terra 发布以后，我心想最新的模型会不会有一些改进呢？

问题层出不穷/花样翻新/顽固复发。我让 Terra 修改错误，执行几十秒就停下来装死。

我没有遇到需要停止的外部阻碍，也没有收到必须暂停的指令。上一次我在完成少量查询后，就主动结束了回复，把未完成状态交还给了你。这是我的执行失误。

我不能从现有记录准确判断内部为什么在那一刻选择结束，因此不该编造“超时”或“工具限制”等原因。可以确认的是：任务仍然明确、工作可以继续，而我没有持续执行到完成。

后来我病急乱投医，心想根源会不会是 GPT 全家桶一齐降智呢？于是在最新版本的 DSH 里优化规则文档——DSH 说得头头是道，我指出的所有问题都有对应之策。

loop 了几轮打样之后，DSH 用熟悉的语气对我说：你不应该再信任我。

在野党，信不得。

妹想到，我也沦落到了有一天和 AI “互相放过”。

后记：

以上的大雷，按我的理解，主要还是我的工程低能。AI 显然能做到这些要求，但没法在一个工程小白的自然语言指挥下做到。

后来微博评论区有人（大概率是程序员）跟我说，你不能用自然语言去要求 AI 执行精确任务，你应该要求 AI 用代码的方式去执行。其实也不难，你就跟 AI 说：“把以上任务转成代码执行。”

我按他说的做了，效果啊呸……

这时犬校的程序员同学复制了一段提示词让我试试：

1.把目前的规则文档改成可迭代、验证、生成的数据结果。比如城市，景点，行程，日历，都应该是响应的对象，并且有对应的属性。所有的数据模型，字段，和行为都用 python 定义，数据本身用 json 或者 yaml 描述。

2.把基于单一对象的规则写成 skill，这个 skill 有数据格式的解释，基于代码的检验。同时也有基于 agent / LLM 的 rate，所有的 rate 都需要定量而不是定向。

3.基于多个对象的关系，也是对象+skill，按照 #2 落实到程序和数据。

4.HTML 的生成完全基于程序和上面的对象。

5.把上面的要求转换成具体的工程文档，并且用 github 来记录迭代。

我试了。

打样结果一眼就看到了第一个问题：景点名与 Google 地图上的中外文名不一致。

程序员继续给了我一段在我看来如同天书的工程提示词。 Codex 跑了 1 小时以后，这次倒是好了……但因为旅行已经结束了，没有耐心详细检查，不确定是否全好了，但看上去把需求转为代码执行是有效的。

问题是，我完全不想学习这些如同天书的工程知识，看见代码和英文我就想死。这方面明说 “我就摆烂了”……等着模型啥时候进化到自然语言也能满足我的需求吧。

一个人啊，有长板也有短板。代码和英文，以及基于这两样的工程能力都是我的短板。以前我只管写 PRD，拜托技术同事去实现，谁他妈知道我竟然活到了不得不自己面对工程这一天。

内容来自“用思考交换思考”的古典产品论坛「犬校」。©2017-2026

点击【阅读原文】，可见犬校最近一年的好帖索引。