夜雨聆风最近我儿子迷上了N比例火车模型，每次铺轨之前，他都会先规划哪里放车站、哪里做弯道、哪里接侧线，再根据规划布局购买对应的配件。他找了几个轨道设计的软件，但是一些高阶的功能都要付费，比如某个比较好用的软件License价格是59.9美元。于是我想，不如把这件事当成一次 AI 实战：我们自己做一个火车轨道规划软件。
实践过程和结果演示
这个项目里，我儿子是产品经理，负责提出需求和体验反馈，包括了提示词原型：
1. 要能选择 TOMIX 的轨道件； 2. 要能在画布上拖动、旋转和拼接； 3. 两段轨道靠近时，最好能自动接上； 4. 如果能看到 3D 效果就更好； 5. 最后还想让 AI 帮他规划轨道。
我先把需求拆成 AI 能执行的小任务：先参考成熟工具，再确定最小版本，再根据孩子的体验反馈逐步迭代。
主要的工具有两个：
1. Codex 做规划和最小版本。 我先把 SCARM 当作参考案例，和 Codex 多轮沟通，讨论这个工具应该做成什么样，哪些功能先做，哪些功能暂时不做。 2. Claude 接 GLM-5.2 做中间迭代。 后续一些改进需求，我用 Claude 接 GLM-5.2 来推进开发，过程中调用了搜索工具和浏览器收集素材。 3. Codex 做最后收尾。 到最后的 bug 修复、结构整理、README 和测试收尾，我还是更信任 Codex。
这么做的原因一方面是因为我的账号token额度有限，不能支撑单一工具完成全过程开发和验证；而且不同的模型的优势不同，设计阶段和最后收尾，我更看重对代码结构、任务边界和错误修复的稳定判断，所以更愿意交给 Codex。
整个过程下来，我们分两个周末各投入了半天时间完成了一个纯浏览器运行的火车轨道规划的Web 应用，我上传到了github上开源：https://github.com/maplefirecn-prog/toyrail_planner。也可以直接访问网页体验：https://maplefirecn-prog.github.io/toyrail_planner/
它目前的核心能力包括：
• 内置 TOMIX Fine Track 素材库； • 支持 2D 毫米画布规划； • 支持 3D 立体预览； • 支持轨道拖近吸附和角度校正； • 支持固定起点后连续拼接； • 支持导入、导出项目 JSON； • 支持接入模型做对话式 AI 规划。
页面演示录屏如下：
开发过程拆解
这次开发不是直接写代码，而是先做规划，再一步步迭代。
第一阶段：先找一个软件做参考，和 Codex 讨论方案。
网上大家推荐了一个比较热门的轨道规划软件，我把它当作范例，和 Codex 进行了多轮沟通。讨论的问题包括：
1. 关键需求和核心的功能分解？ 2. 轨道件应该如何表达成数据结构？ 3. 画布上的部件应该显示和记录哪些字段？ 4. 技术栈和代码架构？ 5. 软件开发分几个阶段实现，第一版实现的功能，逐步迭代增强哪些能力？
多轮沟通形成了方案规划，并且约定了两个关键schema：
1. 描述“厂商素材库”，例如 Tomix 某条产品线有哪些轨道、道岔、立柱、配件。 2. 描述“用户设计项目”，只引用厂商素材库里的轨道素材，记录摆放位置、旋转、高度、连接关系、图纸设置。
第二阶段：优先实现最小版本。
最小版本只解决一个问题：这个工具能不能先跑起来？
我先让 Codex 做一个基础版本：左边是素材库，中间是 2D 画布，右边是项目信息。用户可以从素材库选择轨道，放到画布上，保存项目，再导出 JSON。通过这个过程快速验证了方案可行性和数据结构：每一段轨道有自己的 pieceId，放到画布上后变成一个 placement。每个 placement 记录位置、角度、高度和图层。轨道之间的连接关系则记录成 connections。
第三阶段：让孩子体验，再根据对比结果迭代。
最小版本跑起来后，我没有马上继续堆功能，而是让孩子自己试玩。他从轨道规划角度提出了一些建议，比如：“能否双击拖动轨道，轨道间对齐角度并且连接”“SCARM有一个设置起始点，再选择部件不断延展轨道的功能很好用”
这些反馈比我自己坐在电脑前想需求更直接，我优化提示词给Claude和Codex进行优化，实现自动连接、设置起始点、镜像翻转、3D预览等功能改进。
第四阶段：补齐轨道素材库。
轨道规划工具要有价值，必须有足够完整和准确的轨道件，因为用户根据规划的结构去选择要购买的轨道部件。
我一开始尝试了用搜索工具去查 TOMIX 的轨道规格，但效果比较一般：信息很分散，有些名称和尺寸也不完整。但既然已经有了复刻目标，我就换了一个办法：把目标软件的TOMIX 部件列表截图给 AI，让它先根据截图读取部件名称，再根据名称去定向搜索准确的规格和尺寸。
项目当前内置的 TOMIX Fine Track catalog 大约包含 64 个部件，包括直轨、曲轨、交叉、道岔、桥脚、坡道支撑等。虽然还不能说很完整，但已经能支撑一个基本可用的轨道规划。
第五阶段：加入 AI 对话式规划。
等手动铺轨功能相对稳定后，我开始加 AI 规划。
这部分我设计成一个简单对话入口，支持配置模型参数，输入需求让 AI 返回一个轨道规划的项目描述JSON格式内容，本地程序校验后导入到页面生成规划。
小彩蛋：一次关于缓存和用量统计的排查
我在接入模型 API 做开发的时候，看了一下阿里云百炼控制台的用量统计，发现总 Token 和输入、输出、缓存 Token 的总和对不上。一开始我以为是统计错误，咨询了阿里云客服，同时也把相关的截图和账单数据发给了AI。
客服分析了半个小时，申请了授权，给出了控制台缺少显示缓存统计的定性判断，但是没有定量分析。
而AI的排查方式更像一个技术同事。它先导出账单明细，再按字段反推：普通输入、输出、隐式缓存、显式缓存读取、显式缓存创建分别对应多少 Token 和费用。最后它通过定量分析，准确的给出了显式缓存读取和创建的token数量和账单占比，整个过程耗时不到5分钟。
今日复盘
这个项目给我最直接的体会有两点。
第一，AI 对应用软件的冲击，变得非常具体了。
以前说“AI 会改变软件”，听起来还是一个宏观判断，但这个项目让这个判断更具象了：我不需要等一个商业软件刚好满足我的需求，也不需要为了几个高级功能购买 license。只要需求足够清楚，AI 已经可以帮我把一个“够自己用”的工具做出来。
当然，这个工具和成熟商业产品相比，在可靠性、完整度、素材库覆盖范围上还有很大差距。但对我儿子来说，它明显更好用：界面可以按他的习惯改，功能可以围绕 TOMIX 轨道调整，想要 3D 预览、自动连接、AI 规划，都可以用上。
这让我意识到，未来很多应用软件的竞争，不一定只发生在“通用功能谁更强”上，也会发生在“谁能更快满足一个具体人的具体需求”上。对普通用户来说，只要 AI 定制工具的成本足够低，很多原本需要购买软件的场景，就会被个性化的小工具替代。
第二，有些事情找人不如找AI
阿里云用量统计问题的排查给我的感受很明显：客服花费了半个小时，只给出了一个定性分析和通用概念介绍。
真正把问题讲清楚的，是我的AI Agent。它根据账单字段一步步反推，拆出普通输入、输出、缓存读取、缓存创建这些部分，再解释为什么控制台概览和账单明细看起来对不上。而阿里云客服在这件事里的价值，更多是从官方渠道确认了 AI 的分析方向没有错。但在速度、完整逻辑和结合上下文排查这几个方面，AI 明显更适合处理这种问题。
未来更重要的能力，是学会和 AI 协作：用好 AI 在检索、整理和推理上的优势，同时保留人的判断、取舍和最终负责。人要把问题定义清楚、把材料组织好，再判断 AI 的分析是否可靠，并把结果真正落地。
