Backlog.md

如果你的团队已经把代码、分支和文档放在 Git 里，并且希望 AI 不只是“改一段代码”，而是按任务持续推进项目，Backlog.md 值得采用；如果你要的是完整 Jira 替代品、可视化项目管理 SaaS，或强规范 spec 生成器，它就不是这类工具，更像“给代码仓库内的人类与代理共享的一层 Markdown backlog 操作系统”。

它的实际作用，是把任务放进仓库内的 backlog，让人和代理围绕任务 ID、分解、执行与交接协作。GitHub 仓库与官方 X 更新能证明项目持续迭代，例如支持自定义任务目录、默认 Agent Mode 从 MCP 转向 CLI；这属于能力边界与演进方向的较强证据。知乎文章和回答则提供了更接近实操的工作流样本：有人用它做本地计划拆解、配合 worktree 或其他代理工具并行推进。关于“更省 token、成本低一个数量级”的说法，目前主要来自社区文章阐释，不是官方稳定承诺。

门槛主要在工作流而不是许可证费用。证据能支持它是开源项目，也能支持可通过 npm 全局安装 CLI；但没有可靠官方定价信息，因此不能把它当付费托管平台估算成本。真实成本更可能来自你搭配的 AI 代理、模型 API 和团队改造习惯，这部分在现有样本里多是社区演示或经验说法，适合保守看待。它更适合已经接受 Markdown、Git、分支协作、CLI 操作的工程团队；不适合想零配置上手、强依赖图形化看板、或希望工具自动替你完成产品定义的团队。

社媒共识是“轻量、务实、适合 Git 原生协作”，而不是“万能 AI 项目管理平台”。热度证明很强：GitHub Star 数高，X 上有明显转发和浏览；但这些更多说明它受关注。好用证明目前中等偏强：有少量中文长文、工作流对比文、个人实操分享，也有用户为相关集成提 PR、讨论任务链接与界面接入，说明已有真实使用。但整体讨论仍偏早期，转发和功能播报多，系统化评测与大样本复盘还有限，因此结论应保持谨慎乐观。