为什么要做这个实验

2026 年 5 月，明显感觉 AI Coding 的能力又上了一个台阶。之前我试过 Cursor、Claude、Gemini 等工具，这一次 OpenAI Codex 的表现给我的感受很不一样，所以决定用一个真实的小产品来试试它到底能走多远。

我一直觉得 AI 辅助开发不是一个静态能力，它每隔一段时间就会突然变强一截。这次 Codex 的 Agent 模式让我有了很强的冲动：不再只是让 AI 写几个函数，而是把一个完整产品从想法、规划、前端、后端、部署，一路交给它推进。

这次我给自己的限制是：尽量不碰代码，只描述需求、判断结果、提出修改。

尝试 SDD

这次我特意在开发前使用了最近一直在了解的 Specification Driven Development。

一开始不是直接让 Codex 写代码，而是先让它建立产品需求、前端 Spec、后端 Spec、数据模型、地图路线能力、工程规范和 AI 开发协议。后续每次有新需求，都先判断是否需要更新 Spec，再进入实现。

这一步很关键。它让整个项目不是靠聊天上下文硬撑，而是有了一套能持续迭代的工程记忆。

从 Journey 到 Atlas

最早的想法很简单：做一个记录和规划旅程的 Web 应用。左边是旅程列表，右边是一张有艺术感的地图。每段旅程有事件节点、时间、地点、照片和交通方式。

后来在不断打磨和与 Codex 的人文主义探讨中，它逐渐变成了 Atlas：一个更像“私人地图集”的产品。

Git 历史也大致记录了这个过程：

• 5 月 22 日：初始化项目、地图动画、侧边栏、地图交互、颜色系统
• 5 月 23 日：继续打磨地图、时间线、交通方式
• 5 月 24 日：接入 Supabase、公开空间、社交分享、移动端体验
• 最后几轮主要集中在移动端、微信分享、事件照片和地图面板体验 这不是一次“生成一个 Demo”式的尝试，而更接近一个小产品的真实开发过程。

Codex 给我的惊讶

最让我意外的是，它不是简单执行命令，而是会给出非常专业的产品和工程建议。

比如它会建议：

• 先确定产品理念和信息架构
• 前端先用 Mock 数据把体验打磨清楚
• 后端先定义接口边界，再接 Supabase
• 地图能力单独拆 Spec，区分 Mapbox、AMap、路线规划和公共交通边界
• 提前考虑 SEO、分享页、Open Graph、移动端、Vercel、域名
• 数据模型预留未来多人使用和 AI 生成旅程的扩展空间

这已经不像过去“让 AI 帮我写代码”，更像是身边坐了一个很专业的全栈产品工程师。

优化体验时的能力

后面大量时间都花在体验打磨上，比如地图缩放、fly-over、事件节点图标、交通方式图标、移动端抽屉、照片展示、微信分享卡片等等。

很多时候我并不能非常准确地描述问题，只能说“这里不够好看”、“感觉太乱”、“这个交互不自然”。但 Codex 通常能理解我真正想表达的东西，然后拆成具体的 UI、交互和工程修改。

更重要的是，它不太像那种只会迎合你的 AI。它会按专业判断工作，必要时也会指出更合理的路径。

Agent 模式真的变可靠了

这次还有一个明显变化：每一轮开发结束后，它会自己跑检查，自己打开浏览器验证页面，自己看控制台错误和视觉效果。

过去使用 AI Coding，常常会有一种“它写完了，但你不知道能不能跑”的不确定感。这次 Codex 调用浏览器 Skills 做视觉验证的体验很好，很多问题它会自己发现、自己修掉。

这让 Agent 模式真正开始像一个可靠的开发流程，而不是一个高级代码补全。

成本也变成了真实问题

另一个真实感受是：20 美元/月的额度，在这种高强度 Agent 开发里很快就用完了。我大概 1 小时内就把5小时的额度打满，最后忍不住升级到了 100 美元/月。

如果只是问答，这个价格可能显得贵。但如果把它当成一个能陪你做个人产品的开发搭档，100 美元/月的额度对个人小产品开发来说已经差不多够用。

Codex 不只是编码工具

开发到后面我会自然地让它做很多编码以外的事情：整理 Spec、维护 roadmap、总结 GitHub 版本管理规范、帮我分析博客结构、操作本地服务、处理依赖问题。

考虑到它还能控制电脑、浏览器、终端和各种工具，它的边界其实已经远远超过“写代码”。听说有人直接用它优化家里的网络，这种可能性确实很大。

成果

这次一个周末的密集开发，最终得到了一个可运行、可分享、可部署、也初步接入后端的小产品。（顺便把6月底的日本之行真实旅程安排给录入进去了)

项目地址： atlas.xumeng.me

总结

这次尝试让我很确定地感觉到，AI Coding 又进入了一个新阶段。

它不只是更会写代码了，而是开始能参与产品规划、工程决策、体验打磨、验证和发布。对于个人开发者来说，这意味着很多以前因为成本太高而放弃的小想法，现在真的可以用一个周末做出来。

当然，它还不是万能的，仍然需要人来判断方向、控制审美、提出需求、做最终选择。但如果把它放在一个清晰的工作流里，尤其是配合 SDD 这样的方式，它已经足够成为一个非常强的开发伙伴。

补充：为 Atlas 增加 AI 辅助旅程规划（6.7）

这次给 Atlas 增加的 AI 功能，初衷不是做一个开放聊天机器人，而是把 AI 变成“新建旅程”流程中的受控起草助手。用户不需要从空白表单开始，也不会把一大段旅行想法直接丢给 AI 后等待不可控结果；系统通过结构化问题收集信息，再生成一个可编辑的旅程草稿。

实现思路

产品上先区分两种使用场景：

• 还原一次旅程：用户已经旅行结束，希望把游记、总结、记忆片段整理成事件结构。
• 构想一段行程：用户还在规划，希望把零散想法组织成一个未来旅行草稿。

AI 只负责生成草稿，不直接写入正式数据。草稿包含：

• Journey 标题、日期、描述
• EventNode 时间线事件
• TransportLeg 相邻事件之间的交通建议
• 字段来源状态，例如 user_provided、ai_suggested、needs_confirmation

用户确认、修改、补全后，才提交为正式 Journey，默认私有。

实现路径

技术上采用一个封闭的 AI 工作流：

1. 用户从“新建旅程”进入 AI 起草。
2. 选择“还原一次旅程”或“构想一段行程”。
3. 填写结构化字段：主题、时间、地点、节奏、补充说明。
4. AI 最多提出少量结构化补问。
5. 使用 OpenRouter 调用 qwen/qwen3.7-plus 生成严格 JSON 草稿。
6. 前端执行地点解析，不让 AI 生成坐标。
7. 系统基于地点、距离和语义补齐相邻交通方式。
8. 用户确认后，按现有 Journey / EventNode / TransportLeg 写入数据库。

一个关键点是：AI 不应该直接产出经纬度。地点坐标由 Atlas 自己的 Location Resolution Pipeline 处理：先根据用户输入和草稿建立地理上下文，再调用地图 provider 或使用内置锚点兜底，避免出现“日本旅程被定位到美国”的问题。

另一个关键点是交通方式。最初 AI 草稿里交通段经常是“交通待定”，体验很弱。后来补了一层确定性兜底：如果 AI 没给出相邻事件的交通方式，系统会根据坐标距离、机场 / 车站 / 码头等语义，生成可编辑的交通建议。它不承诺真实线路或班次，只提供结构化起点。

需要注意的点

• 不做开放聊天，避免成本、输入和结果不可控。
• AI 草稿必须可编辑，不能直接写入正式 Journey。
• AI 不生成坐标，坐标由地图服务或系统锚点解析。
• 低置信地点必须标记“待确认”。
• 交通建议只表达语义，不承诺真实公共交通路线。
• 管理员测试可以不受内部 credit 限制，但仍记录真实 AI usage。
• 等待体验要稳定可见，不能让用户只看到按钮转圈。
• 成本控制要前置：限制输入长度、限制补问次数、限制事件数量。

一次真实测试的成本

我用一个简单的东京 1 日游测试：

成田空港 → 浅草寺 → 羽田空港

最终生成：

• 3 个事件点
• 2 段列车交通建议
• 成功创建为私有 Journey

本次 OpenRouter 用量：

使用模型：qwen/qwen3.7-plus

当前价格：

• Input：$0.40 / 1M tokens
• Output：$1.60 / 1M tokens

计算方式：

text
Input 成本 = 954 / 1,000,000 × 0.40 = $0.0003816
Output 成本 = 5050 / 1,000,000 × 1.60 = $0.00808
合计 = $0.0084616

也就是说，这次 AI 旅程规划的模型成本约为：

不到 1 美分。

Mapbox 本次 AI 创建路径没有额外成本：

• Geocoding / Search：0 次
• Directions：0 次

因为本次地点命中了系统内置锚点，列车交通也只是语义路线，使用 future_provider，没有调用真实 Directions。

如果未来普通用户输入更模糊，可能会触发若干次 Geocoding。Mapbox Temporary Geocoding 当前每月前 100k 次免费，超出后约 $0.75 / 1000 次。假设一次旅程触发 6 次地点查询：

6 × 0.75 / 1000 = $0.0045

因此，一个普通 AI 旅程草稿的直接服务成本，粗略可能落在：

$0.01 - $0.03

复杂长行程、更多地点解析、失败重试会更高。

商业化 Credit 设计设想

Credit 不应该直接按 token 暴露给用户，而应该按“可理解的产品动作”计费。

一个合理的第一版设计：

• 结构化补问：免费或极低 credit
• 生成一次 AI 旅程草稿：固定扣费
• 本地编辑草稿：免费
• 重新生成草稿：再次扣费
• 提交正式 Journey：免费
• 地点重新定位：免费额度内包含，异常高频再限制

例如可以设计为：

1 次 AI 起草 = 5 credits
1 credit ≈ $0.01 用户侧价值

如果实际成本约 $0.01 - $0.03，那么 5 credits 对应 $0.05 的用户侧价值，可以覆盖：

• AI token 成本
• 地图查询成本
• 失败重试
• 支付通道损耗
• 免费额度和滥用风险
• 后续模型升级空间

更重要的是，用户感知上不是“我花了多少 token”，而是：

我花了一点额度，把一个模糊想法变成了可编辑的旅程草稿。

这更符合 Atlas 的产品气质：AI 不喧宾夺主，只在用户需要时，轻轻把旅程结构铺开。