一个Linux用户的反击：把macOS独占工具"fork"成KDE插件

朋友给我展示了一个macOS独占的菜单栏小工具，能列出本地开发端口。我是那几十个把Linux（具体是Fedora KDE）当主力系统的人之一。我用OpenCode把它fork成了一个能用的KDE Plasma插件，叫Portmanteau。

我一直遇到同一个问题：看到某个很酷的AI或开发者工具想试试，结果它们全是macOS独占。几年前这种情况通常意味着算了，换下一个。现在我倾向于想："我应该能fork那个。"

这次这个工具是Port Menu，一个简单的macOS菜单栏应用，用来查看本地开发服务器。如果你白天要跑一堆Vite、Rails、Django、Flask、Next.js之类的服务器，核心需求很明显：给我看端口，告诉我是哪个项目的，让我能打开或杀掉它们，不用在终端标签页里翻来找去。

但又是macOS独占，所以我做了任何一个有进取心的vibe coder都会做的事。我开了个OpenCode会话，问了个风险很低的问题：

"这看起来是macOS独占的。移植到Linux有多可行？"

第一个回答很乐观，就像AI和agent常有的那种乐观。端口扫描的想法很可移植。Linux有ss、lsof、/proc//cwd、git、kill，所有原材料都有了。

但应用本身不会是个正常的移植。原版是SwiftUI/AppKit菜单栏应用。KDE版本得是个Plasma插件。这意味着QML、Plasma打包、面板展示、弹出窗口，还有一套不同的桌面集成边界。

折腾了一番、追加提问之后，回答变得没那么光鲜但更有用了。这其实不是移植，而是同一个想法的KDE重新实现：

这就成了项目的形态：一个Linux扫描器加一个Plasma 6插件。

接下来我要了个计划。然后用ticket tk记录下来。我真的很喜欢ticket，推荐你跟agent一起工作时用。

"你能规划一下创建这个需要的步骤/工单吗？我们用tk（ticket）来创建epics/tasks之类的。"

我的agent提了五个epics：

agent在这五个epics下创建了38个工单，加了依赖关系，tk直接给了我们一个实现顺序。这时候项目就从"探索性聊天"变成了"工作队列"。

然后我提了个不负责任的请求：

"你能开始实现这个吗？理想情况下别停，直到所有工单都完成 :)"

agent把Linux版本建成了一个单独的linux/目录，这样原版macOS应用完全没动。这感觉是对的形态：保留想法，别假装SwiftUI应用会跟我们一起走。

核心部件是一个Python扫描器、一个JSON契约、一个Plasma插件。扫描器搞清楚本地在监听什么，插件把它变成我真正能用的面板弹出窗口。

它还加了第一组操作：打开、复制URL、复制端口、杀掉。有些留下来了。复制端口没有。

agent自己也关掉了所有工单。我不觉得"所有工单关闭"是