这个 App 只活了 38 天,但它完成了使命

最近读到花叔的一篇文章，讲他给一趟 38 天的南太平洋邮轮，专门做了个航海日志 App。航程结束，App 的使命也就完成了。

我头一个反应是：这不浪费吗？做都做了，怎么也得加点功能让它活下去吧？

细想之后，我发现这恰恰戳中了很多人做工具时一个没被说破的死结。今天把它拆开讲给你，四步，一步补一个缺口。

你肯定也动过这个念头：要是有个小工具能……就好了。

但念头刚起，包袱就压上来了：做出来谁来维护？以后功能不够怎么办？要不要规划个路线图？想着想着，事情从「做个小工具」变成了「启动一个长期项目」，成本感瞬间拉满。

于是大量明明值得做的小工具，死在了想法阶段。不是做不了，是我们默认软件都得长寿。

头一阶要补的，就是这个默认设定。

花叔那个航海日志 App，就是给自己 38 天的航程用的：海图航线、每日一句一图、导出日志卡发朋友圈。关键在于他的做法——每做完一个需求，就能直接用上，每一步都是完整产品。

航程一结束，这个 App 就从「工具」变成「可翻看的记录」，归档完事。不加酒店预订，不加攻略社区，不为续命强行加功能。

这给我的启发很深：工具可以设定生命周期终点，到点光荣退休。我们平时做东西，默认都在想「怎么让它活得久」，很少有人想「它什么时候该退」。有了出口，做工具的门槛才真的降下来。

第二阶解决另一个常见失败：做出来了，但用不起来。

文章里那句话很准：「做的时候聊，用的时候点。」创造的时候，你用对话把需求说清楚；日常使用的时候，你点的是固定界面——打开、选照片、写一句、保存。

为什么这个区分重要？因为对话适合探索，界面适合重复。天天要干的事，靠翻聊天记录找上次那句指令，谁都会累。用 AI 做工具，成不成往往就看这一步：你有没有把「聊出来的东西」固化成「点两下就能用的东西」。

顺带一句，文里提到这种能持续服务一个人的 AI，需要三件事：身份（知道在服务谁）、行动（能调什么能力）、记忆（下次回来还记得）。这三个词，值得记在本子上。

第三阶解决启动难。很多人卡在开头：对着一个空输入框，不知道该怎么描述需求。

文章里的做法是先生成六版视觉设计，你挑一版顺眼的再继续往下做。体感差别很大：看见以后再去想怎么改，比对着空输入框凭空想，容易太多了。

这个思路不只做 App 用得上。给团队做任何东西——方案、页面、模板——都先把「能看见的版本」摆出来让人挑，别让人对着一段文字描述干想象。

照例泼点冷水：文中的产品我自己没实测过，只登记不背书；「38 天」「六版设计」这些数字都是文章转述口径，取用前请自己核对。

但那句判断值得留下：先做出来看看，用户就是自己也挺好的。你手里是不是也压着一个「想想就算了」的小工具？评论区聊聊。觉得有用点个「在看」，转给那个总说「等有空就做」的朋友。