AI 时代,软件也可以只解决自己的问题

源自一个很小的念头

最近做了一个 macOS 菜单栏音乐播放器，叫 JustWho。

它只回答一个问题：

今天想听谁？

点开菜单栏，选一个歌手，再按播放。它会随机播放这个歌手的歌。没有首页推荐，没有歌单广场，也没有一层层的分类。

这么干净的产品，大概率是没有的，因为大概率只能是满足自己，或跟自己一样的小部分人。以前可能就是没有就算了，即使需求功能简单，也不会想到要去做，只能使用现成的工具，因为自己做意味着要了解一个新的技术栈、查很多文档、处理打包和系统兼容，最后为了一个很小的需求投入一段并不小的时间。

现在不一样了，有了Agent，恰好在额度重置前，还有一部分额度未用又不想浪费，可以先试试，也没有亏，一切交给AI。

先从需求开始，再补上陌生的部分

因为平时用的mac系统 ，所以第一选择是做macOS的原生应用，之前没有做过，对 Swift、SwiftUI、菜单栏应用的生命周期都不熟悉。播放器本身还会碰到另外一组问题：音频播放、本地音乐元数据、远程地址、系统媒体键、控制中心的“正在播放”，以及最后怎样把一个 Swift Package 变成可以双击的 .app。

如果按过去的学习路径，可能要先找一套 Swift 教程，再学 SwiftUI，做几个示例窗口，然后去了解 AVFoundation 和 MediaPlayer。不等了解完，当初那个简单的想法可能已经没有继续做的兴趣了。

这次的顺序是反过来的：先把需求和边界说清楚，再沿着具体问题进入陌生领域。

起初通过chat的方式和AI进行需求的澄清以及收敛，最后我只定了几件事：

• 它只住在菜单栏，不要 Dock 图标，也不要主窗口
• 入口是歌手，不是歌曲或歌单
• 选择歌手只负责加载，由我按下播放才真正出声
• 本地音乐可以直接扫描，远程音乐源只是可选能力
• 不需要账号、统计和推荐，不配置远程源就不访问网络

当然还有份 PROJECT 文档，里面有更细致的边界，拿到文档 AI Coding Agent 先理解项目，找到对应的系统框架，我不必先把整个 macOS 开发生态学完，便能很快看到菜单栏里出现第一个可以点击的界面，然后再根据编译和实际运行的结果继续修改。

这类即时反馈本身对人会产生很强的继续下去的动力。以前面对一个陌生领域，最大的阻力往往不是某个知识点太难，而是要走很久才能知道方向对不对。现在这个距离缩短了：一个想法可以更快变成可运行的东西，而运行中的别扭又会反过来帮助我把需求想清楚。

真正费时间的是“它应该怎样”

第一版能播放并不难，后面大部分精力反而用在一些看上去很小的行为上。

比如随机播放，不只是对歌曲数组调用一次 shuffle。每个歌手都要有自己的播放进度，切到另一个歌手时暂停，切回来还能接着听；“上一首”应该回到真正听过的历史，而不是再随机一次；一轮播完后才能重新洗牌；远程歌曲如果地址失效，也不能一直卡在同一首。

再比如“只听这个歌手”，搜索结果里可能包含合唱、翻唱、现场版和各种相似名字。于是需要把歌手匹配、独唱过滤、录音室版本优先和 Live 版本排序都明确下来。这里没有一个框架接口能直接告诉我正确答案，因为正确答案来自我自己到底想怎样听歌。

界面也一样。SwiftUI 的 MenuBarExtra 可以很快做出菜单栏应用，但原生菜单样式会把一些自定义布局拆散，播放按钮无法按想要的方式并排，最后改成了 window 风格的面板。歌手少时应该直接展开，本地曲库多了才折叠；过滤按钮也不需要一直出现，只有列表真的变长时才值得占一个位置。

还有一些完全属于 macOS 的细节：菜单栏图标要做成 template image，才能跟着浅色、深色和点击状态自动反色；控制中心封面又需要另一种不透明图片；swift run 得到的是可执行文件，要补齐应用目录结构、图标、Info.plist 和签名，才像一个正常的 .app。

AI 缩短的是执行路径，不是判断

从仓库提交记录看，9 月 16 日完成第一个版本，到 9 月 18 日又补上应用图标、资源生成和 .app 打包，当然前期还有段需求确认的时间，以及额度限制等待的时间。总的来说这个速度放在一个我原本没有接触过的技术领域里，过去很难想象。

但这次的过程并没有让我觉得开发变成了“一句话生成产品”。AI 只是把很多中间路径给压短了。

过去遇到一个陌生 API，可能要在搜索结果、旧文章和官方文档之间来回跳。现在可以让 Agent 先进入代码上下文，找到相关系统框架，写出实现，再通过编译和运行结果继续修正。

在开发实现的过程中，作为人的判断并没有消失：选择歌手后要不要自动播放，远程源应不应该成为必选项，本地歌手多到多少才折叠，搜索是用来发现新歌还是只过滤已有列表，这些都不是“技术上能不能实现”的问题。AI 可以提供几种方案，却不知道哪一种才是我想长期使用的状态。

甚至很多修改不是因为代码错了，而是因为用起来不舒服不够顺手。

所以现在更愿意把这种开发方式理解为：人负责愿望、边界和品味，Agent 帮助跨过陌生知识与实现细节，再一起通过反馈把东西磨到可用。

最后

如果只是为自己做小工具，现在可能是最好的时代。

现在要把一个需求明确的小工具实现出来，已经是一件相对简单的事。更稀缺的反而是前面那一步：能不能发现日常里反复出现的那一点不顺手，能不能把它说清楚，知不知道自己究竟想要什么，并且愿意开始做第一版。原来那个会因为投入产出比太低而放弃的想法，现在可以顺手验证一下了。

不过，我总是要说或者对于一些人来说需要踩个刹车，能快速做出一个个人工具，并不等于能很快做出一个面向外部用户的产品。

真正对外的产品考虑的是另一组问题：目标用户是谁，他们遇到的是不是同一个问题；第一次使用时能不能理解；不同设备和环境下是否稳定；数据、安全、版权和隐私怎样处理；不同用户的权限如何区分；单点，并发问题；自建，上云，成本问题；上线以后如何支持、运营和持续维护。而个人工具来说很多的前提不必解释，使用环境也相对固定。AI 会让其中一些执行工作变快，也会改变角色之间的协作方式，但专业判断和完整的产品过程不会因此很快消失。

如果你也有一个一直找不到完全合适方案的小需求，也许可以试着先做一个只服务自己的版本。

喜欢就“点个赞”↓