这个开发者把TODO注释的死亡率从90%降到了0：2秒自动建单

你代码库里躺着多少具TODO尸体？我数过自己的：去年写的127条，最后变成GitHub issue的只有11条。剩下的116条像幽灵一样飘在注释里，"稍后修复"成了"永不修复"。

Bar Ticket的作者算过一笔账：开发者每天写几十条TODO注释，真正提交成issue的不到10%。不是不想管，是管的成本太高。切到浏览器、登录GitHub、填标题描述、复制粘贴、再切回来——这套动作足够让你在心里默念"下次一定"。

Bar Ticket的解法是把"下次一定"变成"已经好了"。

菜单栏里的自动流水线

这是一款macOS菜单栏应用，安装后常驻屏幕右上角。它的工作逻辑像一条隐形传送带：你在任何编辑器里写TODO注释，保存文件的瞬间，它就完成了检测、解析、建单、回写四步操作。

具体路径是这样的。文件系统事件触发检测→从git config读取远程仓库地址→调用GitHub API创建issue→把返回的issue编号自动追加到原注释末尾。整个过程约两秒，你的光标没离开过当前行。

动画反馈做在macOS刘海区域：detecting→creating→confirmed三阶段状态流转。作者解释这个设计的用意："开发者需要确认事情发生了，但不能被打断。"

支持的编辑器列表几乎是全量的：VS Code、Xcode、Vim、Cursor、Zed，以及任何能往磁盘写文件的编辑器。它不依赖插件生态，因为根本没必要——直接监听文件系统比适配每个编辑器的API更干净。

为什么偏偏是注释

这个产品的切入点值得细品。TODO注释是开发者的肌肉记忆，比任何快捷键都更深地嵌在工作流里。作者的原话是："我要用的不是新工具，是已经在做的事。"

市面上不是没有替代方案。CLI工具需要记住命令，IDE插件绑定特定编辑器，GitHub的代码扫描功能有延迟且配置繁琐。Bar Ticket的差异化在于"零认知负荷"：你不用学任何东西，继续写你的//TODO，保存，完事。

自动回写issue链接是个关键细节。原注释从// Fix login timeout on slow networks变成// Fix login timeout on slow networks (#42 github.com/...)，代码和项目管理工具之间建立了双向索引。半年后你翻到这段代码，能直接点进issue看讨论历史和解决状态。

这个设计解决了TODO注释的一个结构性问题：它们原本是单向的、孤立的、容易过期的。现在每条注释都锚定到一个活的、可追踪的工单。

限制与边界

Bar Ticket的约束条件写得很诚实。macOS 14.0+起步，Windows和Linux用户被排除在外。免费下载，但作者没提后续商业模式——可能是个人项目，也可能在验证需求。

GitHub是目前唯一支持的代码托管平台。GitLab、Bitbucket、自建Gitea的用户暂时用不了。作者在社区回复里提到"更多平台在考虑中"，但没有时间表。

另一个潜在限制是权限。应用需要访问你的文件系统和GitHub账户，对安全敏感的企业环境可能需要额外评估。作者的开源背景（@night_district_创始人）能在一定程度上建立信任，但大规模部署时IT部门的审查不可避免。

从个人痛点到通用工具

这个产品的诞生路径很典型：开发者发现自己的工作流有断点，用周末时间写了个脚本，打磨成可发布的工具。作者在DEV社区的自我介绍是"Always building something new"，Bar Ticket是这条线索上的最新节点。

他之前还做过一个案例：尝试让DevFest Ireland活动更无障碍，最后意外做成了一款SaaS产品。这种"解决问题时顺便造工具"的模式，在独立开发者圈子里越来越常见。

Bar Ticket的底层技术并不复杂。文件系统事件监听用FSEvents API，GitHub集成走REST API，动画用SwiftUI。技术栈的选择服务于一个核心目标：把延迟压到人类感知阈值以下。两秒是作者反复测试后的平衡点——再快就牺牲可靠性，再慢就产生等待焦虑。

社区反馈呈现两极分化。一部分用户立刻安装，称其为"TODO注释的救生舱"；另一部分质疑为什么不用IDE内置的任务管理，或者为什么不让CI流程扫描TODO。作者的回应是："那些方案我都试过，摩擦系数不一样。"

这个分歧本质上是对"工作流优化"的不同理解。有人愿意为了统一性接受额外步骤，有人宁愿为流畅性牺牲功能完整性。Bar Ticket显然是为后者设计的。

产品名Bar Ticket是个双关：既是"菜单栏（Menu Bar）的工单（Ticket）"，也暗指酒吧里那种随手记在小票上的待办事项。这种命名风格符合作者的产品经理背景——好的名字自己就会讲故事。

目前Bar Ticket在Product Hunt和DEV社区同步发布，下载量未公开。作者在最后留了一个开放接口："想知道它适配（或不适配）你的工作流。评论区见。"

你的TODO注释现在是什么状态？还在代码库里自然死亡，还是已经找到了通往issue的自动通道？