夜雨聆风因为这次行程比较赶，6 天时间里要去三四个地方，所以酒店、交通、租车和游玩信息都比较多
在旅途中，当我们想看今晚的酒店，或者待会去哪玩，或者去哪个餐厅时，总是要反复在几个不同的 App 里面去寻找
也是在这次旅行中，我开始思考是不是可以做一个适用于自己的旅行 App
但我有一个很现实的问题：我完全不会开发，甚至看不懂代码
这个 App 从产品方案、UI、代码、测试到后面的 Bug 修复，都是我通过和 Codex 一步步沟通完成的。我没有办法直接判断某一段代码应该怎么改，能做的是告诉 Codex 我想解决什么问题，再去使用它做出来的版本，判断这个结果到底对不对
一开始，我很自然地把 AI 问答放进了首页。毕竟这是一个 AI 时代的旅行产品，用户可以直接问：「我今晚住哪里？」「下一程几点出发？」听起来既直接，也足够智能
但真正开始梳理使用场景以后，我发现这件事有点不对
人在旅行途中，很多时候并不想先和 AI 对话。他只是刚下飞机、正在赶路，或者拖着行李站在路边，想马上确认今晚的酒店和下一项安排
如果这个信息已经存在产品里，为什么还要让用户先点开对话框，再组织一句问题，等 AI 返回答案？
所以我把首页重新改成了一个「今日执行页」
当用户正在旅行时，首页优先展示今晚住哪里、当前正在进行什么、下一项安排是什么，以及还有哪些事情没有处理。首页不再只是保存旅行资料的档案入口，而是要直接帮助用户完成眼前的行程
我当时没有告诉 Codex 应该改哪段代码，而是直接用口语跟它说：「如果用户正处于旅行日期，首页进去就应该直接是当天正在进行的事项。现在还要再点一下当前旅行，才能看到今天的信息，这个体验不太好。」
围绕这个判断，我又一口气提了很多调整：最近旅行应该放进旅行 Tab；「问问你的旅行记录」不应该占据首页，而应该变成旅行页右上角的搜索入口；上传资料也只保留右上角的加号；和大标题重复的「今天」标签、用户本来就清楚的旅行地址、卡片里重复表达状态的标签，都可以删除
甚至连日期的写法也需要重新判断。原来的「Day 3（7/11）」容易让我误以为是旅途第 7 天，所以后来改成了更明确的「Day 3 · 7 月 11 日」
这些修改并不是为了少放几个元素，而是让首页只回答一件事：我今天要做什么
这次调整也让我意识到，产品看起来更智能，不等于用户用起来更轻松
有些信息根本不需要 AI 猜，也不需要 AI 总结。产品只要在正确的时间，把已经确定的信息放到正确的位置，就已经解决了大部分问题
真正进入开发阶段以后，我又发现：Codex 可以很快帮我把功能做出来，但它不会自动替我判断产品流程是否合理
比如，在创建旅行的流程里，它最初默认让用户手动填写行程。但真实场景里，我更可能直接把酒店、活动、门票和交通截图全部上传，让 OCR 先识别时间和地点，再根据酒店入住日期和交通日期，自动整理出整个行程
如果这个流程没有提前想清楚，Codex 完全可以把「手动创建行程」开发得很完整。但功能做完以后，我还是会发现它不是自己真正想用的方式，然后重新调整产品方案和页面流程
UI 也是一样
旅行详情页的早期版本里，「今日重要信息」只有半屏宽，内部层级和间距都很奇怪；下面的时间线也只是把黑点、时间和卡片摆在一起，没有形成真正的时间线关系。功能都有了，但整个页面不像一个可以直接使用的产品
我只能继续用视觉感受和使用体验跟 Codex 沟通：卡片为什么只有一半宽？黑点能不能移到卡片左侧，并和卡片中心对齐？时间是否也能与时间线保持对齐？
Codex 做出来的第一版通常能够运行，但不一定美观。有一次，我发现卡片里某个功能上下的间距特别宽，于是让它把间距缩小。它告诉我间距已经改成了 12pt，但页面看起来几乎没有变化
继续追问后我才知道，它参考了 Apple 建议的点击区域，给按钮保留了 44pt 的可点击范围。当每张卡片里都有这个按钮时，这个范围也参与了页面布局，所以整个页面看起来很松散
这时，问题已经不是简单地告诉 Codex「把间距改小一点」，而是要继续问清楚：我现在看到的距离，究竟来自卡片间距、内容间距，还是按钮的可点击范围？只有把问题说到这一层，它才知道真正需要修改什么
另外，卡片左侧已经通过「正在进行」「接下来」表达了状态，右上角再放一个状态标签就有些重复；「查看详情」和「标记完成」的位置也需要根据卡片留白继续调整。这些都是代码正常运行以后，才会暴露出来的产品细节
还有一些更直接的视觉问题。比如时间线页面里的日期、时间和行程卡片没有形成清楚的左对齐关系。代码可以正常运行，数据也都展示出来了，但页面看起来就是不舒服
这些问题让我意识到，不会写代码，不等于只要把需求交给 Codex，产品就会自动长成正确的样子
Codex 能够负责实现，但我仍然需要不断使用、观察和追问：这个流程符合真实场景吗？这个页面为什么不好看？我要求修改的东西为什么没有变化？
同样，产品里的 AI 最终能输出什么，也取决于产品本身有没有清晰的规则和可靠的数据
比如，「今晚住哪里」看起来只是一个简单问题，但产品首先要知道哪一段行程正在发生、酒店订单属于哪一天、跨天住宿应该怎么计算、用户修改行程后哪些信息需要同步
这些都不是接入一个 AI 接口以后自然会消失的问题。相反，如果产品流程还没有确定，AI 只会把尚未解决的问题继续放大
产品规则改一次，提示词、数据结构和输出逻辑可能都要跟着改一次。流程没有定好时，越早接入真实 AI，后面的返工就可能越多
所以到了第二阶段，我没有急着接入真实 AI，而是先把本地数据持久化、文件保存和数据一致性做好
因为对于这个产品来说，最先要解决的不是用户能不能问 AI「我今天要去哪里」，而是用户打开首页以后，能不能直接看到今天住哪家酒店、待会去哪里玩、接下来有什么安排
这些明确的信息，本来就不应该再让用户搜索一次。今日执行页应该根据当天的行程，直接把它们展示出来
先做好数据和今日执行页，看起来没有 AI 问答那么吸引人，但它决定了这个旅行 App 在没有 AI 的情况下，能不能先解决最基本的问题
做到这里，我对 AI 产品的开发顺序有了一个更明确的判断：先确定场景，再建立数据，最后接入 AI
第一步，确认用户在真实场景里到底急着完成什么，而不是先决定要放什么 AI 功能
第二步，让产品规则、操作流程和数据关系先稳定下来，确保那些信息真实存在，而且能够被可靠地找到
第三步，再让 AI 去理解更模糊的表达、连接分散的信息，或者减少用户原本需要完成的操作
我并不是认为 AI 不重要。恰恰相反，正因为希望它最后真的有用，我才把真实 AI 放到了后面
AI 更适合增强一个已经成立的产品，而不是代替产品本身成立
这次经历也让我对「用 AI 做产品」有了两层理解
第一层是用 Codex 帮我开发。它让我这样一个看不懂代码的人，也可以把自己的产品想法真正做出来
第二层是把 AI 放进产品。到了这一层，AI 应该解决什么问题、依赖哪些数据、在什么场景下出现，仍然需要由人来判断
如果连用户此刻最需要什么、数据从哪里来、产品应该如何回应都没有想清楚，那么最先需要解决的，可能不是 AI 能不能做，而是这个产品究竟想帮用户完成什么
对我来说，这也是做这个旅行 App 过程中最重要的一次优先级调整：不是因为有 Codex，就省略产品判断；也不是为了让它看起来像一个 AI 产品，就急着把 AI 放到每个地方
先把真实场景想清楚，把产品流程和数据建立起来，让它在没有 AI 的情况下也能解决问题。然后，再让 AI 去增强它。
