最新

我构建 Lific 的原因是我负责大型项目中的 AI 编码代理，并且需要一个地方来存放项目状态，而不是将它们保存在仓库的 markdown 文件中。 当我开始着手长期项目时，我最初使用的是 Linear，但我的代理创建问题的速度比人类快得多，几乎立刻就触及了它的限制和定价门槛。然后我尝试自托管了一个流行的开源跟踪器，这意味着要运行它的 13 个容器，而且它的 MCP 集成高达 30k 个 token，我对此感到非常厌烦，最终将其移除，并回到了 .md 文件，持续了几周。 Lific 的形态与大多数自托管服务器问题跟踪器截然不同：它是一个单一的 Rust 二进制文件，使用 SQLite，并且内置了一个优化的 MCP 服务器。Web UI 也直接集成在二进制文件中。 这种简洁性仅体现在其规模和易于安装方面。Web UI 功能齐全，具备您对 Linear 等问题跟踪器所期望的所有用户体验。 自从我开始使用 Lific 以来，我的代理工作流程是：我打开 Web UI，找到一些我想处理的问题，然后告诉代理“处理 LIF-298、299 和 301，如果你发现 bug，就将它们创建为新问题。” 一天结束时，项目就已经自我跟踪了。问题有状态、阻塞项和评论线程，因此“当前可处理的内容”是一个查询，而不是让代理去猜测。计划是持久化的步骤树，因此明天的会话将以与制定计划的会话相同的目标和路径理解来恢复。我最大的项目有 300 多个问题和 100 多份文档，代理可以快速搜索。所有内容都可以一键导出为 markdown，数据库只是您机器上的一个文件。 设置过程是： ``` cargo install ``` ``` lific init ``` ``` lific connect ``` 然后选择您的框架（OpenCode、Cursor、Claude Code 等）。一个诚实的提醒：在 Windows 上，目前还没有服务安装，因此二进制文件必须处于运行状态，MCP 或 Web UI 才能在 Windows 上工作。 我认为 Lific 与许多其他选项最大的不同之处在于其轻量级的特性，同时仍然拥有功能齐全的 Web UI。它旨在让自托管用户能够使用代理处理大型项目，而不会牺牲问题跟踪器的其他优势，例如良好的管理 UI 或团队使用的身份验证。 非常欢迎您在此处或 Discord 上提供反馈和 bug 报告！

嘿，HN 的朋友们，这是一个世界杯风格的比赛，参赛歌曲是我多年来在 Spotify 的“喜欢”列表中收藏的 500 多首饶舌歌曲。制作过程非常有趣！ 里面有很多来自 NWA、Jadakiss、Lil Wayne、Jay-Z、Big Pun、Eminem、Nas 等艺人的优秀作品。 比赛是筛选音乐这种高维度空间中精华的好方法，而且在比赛结束前，你完全不知道哪首歌曲最终会脱颖而出，这本身就很有趣。 作为过去十年里主要从事后端/数据开发的开发者，这是我第一次真正涉足像素级精确的前端开发，并且是在 AI 统治这个领域之前于去年完成的。Flexbox 相当直观，前端开发也很有成就感！ 赛制是先进行 4 首歌的小组赛（每组前 2 名晋级），然后是 128 首歌的淘汰赛。 淘汰赛：564 -> 512 首歌曲 小组赛第一轮：512 -> 256 首歌曲 小组赛第二轮：256 -> 128 首歌曲 淘汰赛：128 首歌曲 -> 1 位获胜者 点击任何一首歌曲，都可以在嵌入的 Spotify mini-player 中试听。