做了一个解决我自己痛点的小工具

出行规划工具 · 项目毕业复盘

个人项目复盘从「心算倒推时间」到「小程序自动算」 2026.08.06

我为什么会需要这么个工具？

我女朋友在福建，我在北京，隔三差五就要远距离出行。

周五或周六早班机飞过去，周日最晚一班飞回来——每次都要倒推：几点到机场、几点出门、几点起床。

环节多了就涉及各种交通工具，心算很容易漏。我记性又差，算完就忘，忘了又得重算。

问题不复杂：从终点往回推，算出每个节点的最晚出发时间。

这是一个做出行时间规划的微信小程序，主要功能就是用户输入自己的行程信息，工具就会根据行程信息倒推出每一个节点的最晚出发时间。
做这个项目的起因是来自于我自己的一个小需求。我总会遇到一个问题，当我每次要进行一个比较复杂的行程的时候，我就需要知道，在行程开始前，我应该几点起床，什么时候出门才能赶得上我要乘坐的交通工具。因为我女朋友在福建，而我在北京，所以我经常会需要远距离出行，很多时候可能就是去程要买周五或者周六早一些的飞机，返程要买周日晚上最晚的一班返程航班。所以我就需要知道我出发的时候需要几点前到达机场、几点前从家里出门、几点起床，然后根据最早的这个时间点设定好闹钟。周日的场景就是，如果周日也有安排行程，那就需要提前计算好我必须几点出发才能赶得上返程的飞机，因为会涉及到各种不同的交通工具，所以环节会比较多，不太好计算。
在做出这个小工具之前，我只能通过心算来往前倒推计算时间，算一次两次还好，但关键是我记性不太好，总是会忘，忘了就有要重新去推算，确实很头疼。

年初的想法，拖到五月才动手

过年的时候就在想了，一直拖着没动。5 月 15 号才正式启动，断断续续搞了半个月，5 月 30 号 V1 上线。

年初

每次出行都要心算倒推

想做个工具解决这个问题，但一直拖着没动手。

5.15

终于正式启动

跟 Codex 聊需求、写 PRD、定技术方案。

5.19

发布开发版内测

几位朋友认真体验了，给了很多有价值的反馈。

5.30

V1 正式上线

从想法到能用的工具，第一个闭环跑通了。

半个月不短，但中间推翻重来了好几次，不是一条直线。

写了需求文档，为什么第一版还是不行？

一个具体想法

→

跟 AI 反复讨论
写了 PRD + 技术选型

→

AI 按文档实现了
但实际体验不对

我当时以为

把文档想清楚，剩下交给 AI 就行了。

后来才明白

文档写不清楚所有的概念、页面形态和交互逻辑。很多事只能边做边想清楚。

# 开发历程
## 建立产品模型和最初的产品设计
在正式开始去做这个项目的时候，最开始做的就是跟 codex 去沟通交流这个产品最基本的一些产品设定，并完善出一个比较像样子的产品需求文档，以及技术选型方案。我看了一下会话记录，当时用的还是 gpt 5.5 模型，还在用 superpowers 技能。主要就是使用 superpowers 的 brainstorming 头脑风暴技能，去不断地细化、确认我的具体的需求设计，最终确定出一版我一开始认为还比较完整的产品需求文档。
我当时确实有仔细的去看这个产品需求文档，但是确实，很多需求并不是一篇需求文档就能事无巨细的阐述清楚的。于是我在让 codex 根据这份产品需求文档编写实现第一版代码之后，就发现了很多问题。

第一版的问题：什么信息都往一张卡片里塞

初代版本

每张卡片上都写了出发地、到达地、交通工具。
地点信息和通行信息混在同一个对象里。
页面上大量重复文字，交互逻辑也很模糊。

应该是

地点（节点）：需要停留或经过的位置。
路段（交通）：两个地点之间的通行方式与耗时。
两种不同的东西，各用各的方式在页面上展示。

概念没分清楚，UI 再好看也没用——用户看不懂、用不顺。

## 初代版本的方向问题（标题待定）
需求文档出来之后，我就放手让 codex + superpowers 自己推进实现了，但是 superpowers 真的很重，实现起来很慢，每次都要等很久才能出一版结果。最终是断断续续地开发实现了一个初代的版本，当然由于 gpt 众所周知的前端水平，这个版本距离能用还有十万八千里的距离。但是一些 UI 和 交互设计方面的问题就先不说，我那时候发现了一个非常核心的产品设定的问题，在最开始产品需求定义的时候，对于地点和地点之间的通行段之间的关系，我没有想到，gpt 也没有想到，所以最终生成出来的版本，工具使用逻辑上给我的体验并不好。
codex 把各种概念弄得很乱，例如正常来讲应该是用户在一个一个地点之间通过交通工具进行通行，所以应该明确的分成两个元素类型，一个是地点（节点），另一个是地点之间的路段。但 codex 最初的版本，它设计的页面是很多卡片组成的一个时间线，每个卡片上面都写了出发地、到达地、过程中的交通工具。听起来很合理，但是实际呈现在页面上就是大量的重复信息、难以理解的交互方式。

把地点和交通拆开，页面一下就清楚了

地点卡片：只展示这个地点本身的信息，不再塞交通内容。

交通气泡：在两个地点卡片之间，单独展示通行方式和耗时。

数据和页面终于对上了——用户一看就知道自己在编辑什么。

先把「对象是什么」搞清楚，再谈交互怎么做。

第一轮返工教会了我什么

一个模糊的想法撑不起一个产品：对象、关系、边界都得想清楚。

产品形态要自己判断：大致的布局和核心交互，不能全都交给 AI。

AI 写代码很快，但它不能替人做产品决策。

没想清楚就让 AI 开干，最后大概率要返工，代码越改越难维护。

核心就一句：不能放弃思考，全盘交给 AI 替你做决定。

给我的教训：开发一个产品并没有想象中的那么简单，也并不是单靠 AI 就能实现。仅凭一个基础的想法和概念并不足以支撑开发，作为产品的设计者，必须要完整清晰地了解到自己到底想要一个什么东西，它大体上应该是一个什么形态，UI 的布局大概应该是什么样子，一些基本的交互逻辑应该是怎么样的，这些关乎着产品的实际体验，关乎着能不能真正的让用户能看懂、会用和好用。如果这些不自己提前想清楚，直接让 AI 开工干，最后极大概率就要返工。虽然 AI 写代码很快，但是在一个代码工程上进行大范围、大规模的修改，非常容易导致代码越来越难以维护，引入越来越多的技术债。核心就是，不能放弃思考，全盘交给 AI 替人来做决定，尤其是这些关乎产品核心体验的事项。

第二次走偏：为什么「单时间轴」是根本错误？

我的理由：人是一个物理实体，同一时间只能在一条时间线上——所以只需要一条时间轴。

实际用了才发现：这个工具不是日常用的，它只解决复杂出行的场景。

下一次打开，大概率是一段全新的行程。而且用户会提前安排未来多次出行。

"人不能在两个地方"是事实，但这不是这个产品该用的模型。

正确的结构：不是一条线，是多个独立的行程

每次复杂出行是一个独立的行程，行程内部才是地点和交通段。

行程 A

北京 · 家

首都机场

福州

行程 B

福州 · 酒店

景点

返程机场

行程 C

未来出行

待规划

多行程才符合真实使用：用户不是每次都在上一段行程的尾端继续。

但是我实际体验之后，发现这是一个巨大的错误。因为这个工具在设计层面，并不是一个常驻的工具，并不是用户每一次出行都需要使用的工具，它只解决复杂行程下的时间推算问题。用户每天日常的出行根本就用不到这个工具，那设计成一条时间轴就是大错特错的了。用户在下一次使用这个工具的时候，是一段全新的行程，它极大概率不是继续上一次行程的最后一个节点继续的。如果按照目前的单时间轴的设定，根本无法承载这种情况，是一个巨大的矛盾。而且用户虽然无法在同一个时间内有多个行程，但是用户非常有可能在同一个时间内就预定了后面很多次的行程。所以单条时间轴模型完全错误。

知道错了以后：为什么还是选择整体重构？

单时间线前端、后端、数据库全都围绕这个错误假设建的。

→

纠结了很久影响面太大了，基本等于重写。但继续打补丁只会越描越黑。

→

多行程结构把底层设定推翻，换来能承载真实使用场景的基础。

重构代价很高，但核心模型错了就是错了，不是局部修修补补能解决的问题。

面对根本性错误，早点重构比继续维护错误结构更划算。

更难受的一课：不要因为「自己很确定」就不去验证

我当时干了什么

AI 最开始提了多行程方案，我用「人不可能同时在两个地方」这个理由否掉了它。AI 就顺着我改了设计。

现在我会怎么做

对每个重大设计，都用真实使用场景去反复追问。正确性比谁提的更重要。

产品设计既要有主见，也要给「我可能是错的」留验证空间。

重构完了，最磨人的工作才刚开始

人工体验
找到问题

→

给 AI 下
修改任务

→

AI 改完
人工复核

这个阶段没有了第一版实现时的那种惊艳感，面对的全是 bug、逼死强迫症的小样式、奇怪的交互细节。

整个过程枯燥乏味，但也很有成就感——看着产品一点点被打磨成型，越来越好。

5 月 19 号发了内测版，真心感谢帮我体验的朋友们

作为开发者，自己太熟悉产品了，反而看不出用户第一次打开时的问题。

他们真的有在认真用兜老师、蛋妞老师、派trick老师、山河老师、牛牛老师，认真体验了我的小程序，给了我很多反馈。

很多问题我根本意识不到UI 和交互上的细节，从用户视角看就是另一回事。他们的反馈给了我全新的视角和启发。

反馈之后做了这些记录反馈 → 全面优化 → 再次验证，不是零散地修修补补。

让别人帮你体验，是在借用别人的眼睛发现自己看不见的东西。

## 发布第一代内测版本
经过一番打磨之后，我在 5 月 19 号，发布了第一代开发版作为内测版本分享了出来。
在这里也真的很感谢 兜老师、蛋妞老师、派trick老师、山河老师、牛牛老师，真的有在仔细的体验我的小程序，然后给了我很多很多很有价值的反馈，有很多 UI 和交互上的细节问题，都是我根本没有意识到的，给了我很多全新的视角和启发。

启示：有时候作为开发者，可能本身对于自己开发的产品就很熟悉了。很多用户体验层面上的问题，作为开发者本身来说，可能就会因为一些视角受限、或者知识存在欠缺，导致很多问题都无法发现。那其他人的反馈就非常的重要了，从用户视角，甚至是用户和开发的双重视角，能提供更多有价值的反馈和启发，能够让产品的开发者跳出自己固有的思考环路里面，换一个角度去重新思考。

初代体验版长这样

← 初代体验版首页飞书上收到的反馈 →

第二轮大改：从动森风格组件库「偷」设计思想

那段时间在 HelloGitHub 上看到一个动森风格的 Web 组件库，一眼就喜欢上了。

但它只有 Web 端没有小程序端，我就让 AI 全面分析它的文档，把设计规范和设计思想整理出来。

然后按照这个设计要求，对小程序的样式做全方位改造。

这次用的是 Claude Opus 4.6，改完打开一看，确实惊艳到了。

基础样式固定之后，后面 Codex 接着迭代也没出什么大问题。

## UI 和 交互设计全面重构
我收集记录了一下大家对于我体验版本的各种反馈，然后就开始了第二轮的全面打磨优化。第一个核心事项就是全面的重调 UI 设计，恰逢当时那段时间我看到 hellogithub 上有介绍一个动森风格的 web 组件库，我看到就觉得很喜欢，但它只有 web 端，没有小程序端的组件，我就让 AI 全面分析了一下它的文档，把他的设计规范、设计思想整理了一份出来，然后根据这个设计要求去重新对小程序的样式进行全方位的调整。这次重构是 claude opus 4.6 完成的，因为当时正好有朋友跟我说 kiro 有便宜的渠道，而且可以用 claude 模型，我当时就尝试了一下，这也是我用 claude 跑的第一个任务。claude 改完之后，我打开查看效果的一瞬间就被惊艳到了，确实是全面的大换血，效果非常好。但是后面就因为 kiro 被封杀，我在前端样式大改版之后，又转头回到了 codex 进行后续的开发，不过基础的样式已经固定了，codex 后面的迭代在前端层也没有出现什么纰漏。

前端全面改版之后，效果确实不一样了

← 改版后首页改版后行程页 →

做新手引导，我来回搞了两天

为什么要做 onboarding

帮我测试的朋友都说打开之后看不懂。「倒推计算时间」这个概念确实不是常见的心智模型，第一次用很难 get 到。

为什么这么难做

要带用户完整走一遍核心操作：局部高亮、箭头指向、步骤提示、按钮动画、滚动定位……每一处细节都得对齐。

理解工具是干什么的

→

跟着走完一遍核心操作

→

形成自己的使用方式

Onboarding 不是写一段说明文字，是把关键交互流程演示给用户看。

新手引导的最终效果

步骤 ①步骤 ②步骤 ③步骤 ④

一次缓存事故，逼我重新划了数据边界

测试时发现：删了的行程数据，本地残留缓存居然把远端已删除的数据又覆盖回来了。

数据层	应该承担的角色	边界规则
服务器数据	权威数据源	数据存不存在，服务器说了算
本地缓存	离线兜底用	不能反向覆盖服务器已确认的删除
同步逻辑	恢复一致性	明确优先级、删除语义和失效时机

缓存不是第二个真相来源，没有明确权威边界就会搞出「幽灵数据」。

做完这个项目，我到底学到了什么？

从自己的真实痛点出发，做出了一个能上线用的小程序。

两次推翻核心产品假设，最终确认了地点—路段—多行程的模型。

通过内测反馈、UI 重构、onboarding、缓存边界，把产品从「能跑」推到了「能用」。

弯路没白走，每一次推翻都让理解更准确了。

最想记住的一句话

AI 能放大实现速度，但产品的定义、验证和责任，始终要由人自己来承担。

想清楚 + 验证假设 + 持续打磨 = 真正能用的产品

谢谢观看

出行规划工具 · 项目毕业复盘

从一个真实痛点开始，把每次推翻都变成更准确的理解。