Reqmango 是一个可以自己部署的开源项目管理工具，面向的是那些已经习惯 Jira 式工作项、工作流和自动化，却又被云端订阅费用和数据存放位置卡住的团队。它的定位很直接：把核心数据留在你自己的机器上，用 Docker 一条命令跑起来。
它到底补的是哪块短板
多数团队对工作项类型、状态流转、触发器这套模型并不陌生。真正耗人的是入口环节——新需求进来，谁来判断它是缺陷还是特性、该给什么优先级、是不是和已有条目重复。这一步长期靠人肉分诊，重复且容易漏。
Reqmango 把这块做成了 Intake 分诊：新需求提交后先由模型给出类型、优先级和疑似重复的建议，拿不准的再转人工进 backlog。模型走的是自备 API Key 的路径，AI 能力嵌在 Issue、Intake、Cycle 三个工作路径里，而不是单独挂一个聊天窗口。
除此之外，工作项类型的字段与结构可以按项目自定义，状态流转、权限和审批同样按项目配置，自动化则沿用触发器、条件、动作三段式。这套组合对熟悉 Jira 流程的人来说几乎没有学习成本。
部署：先拉镜像再起容器
官方已经发布了镜像，不需要本地编译。整个流程是克隆仓库、准备环境文件、拉取镜像、启动容器：
git clone https://gitcode.com/yongfeng9m-/reqmanpy.git reqmango
cd reqmango
cp .env.example .env
docker compose pull
docker compose up -d
启动完成后浏览器访问 http://localhost，演示账号是 demo@example.com / demo1234。想体验 AI 分诊，需要在 .env 里填入 AI_API_KEY，然后重启后端容器，否则 Intake 页面不会出现分诊建议。
这里有两个容易踩的坑。第一，docker compose pull 失败多半是镜像仓库网络问题，先确认本机能否解析并连通镜像源，再检查 compose 文件里引用的镜像标签是否与已发布版本一致；盲目重试没有意义。第二，容器起来了但页面打不开，先用 docker compose ps 看服务状态，再用 docker compose logs -f 跟后端日志，重点确认端口映射是否被宿主机上已占用的 80 端口挡住，以及 .env 是否在 up 之前就已就位——环境变量在容器创建时注入，改完 .env 必须重新创建容器而不是只重启进程。
演示数据与生产环境的边界
演示账号能直接登录，是因为种子数据默认开启。任何可能被外网访问的实例，都必须关掉 SEED_DEMO，并按文档站的「生产部署」章节配置密钥。这一步不是可选项：带着演示账号和默认凭据上线，等于把入口敞开。
文档地址在 https://vinthuy.github.io/reqmango/，生产部署的密钥设置、反向代理和访问控制都以那里为准。
哪些场景适合，哪些要谨慎
单机 Docker 部署的形态决定了它适合中小团队内部使用、对数据驻留有硬性要求、且愿意自己承担运维的场景。它不适合需要多节点高可用、跨地域容灾或大规模并发的组织——这类需求下，单机容器的备份策略和故障恢复能力会成为瓶颈，数据库卷的定期快照要提前规划。
另一个需要想清楚的点是 AI 密钥。分诊建议依赖外部模型 API，需求文本会离开你的机器发往模型服务商。数据驻留的优势在核心业务数据上成立，但在 Intake 环节会被这条外发链路部分抵消。对内容敏感度高的团队，要么在提交前做脱敏，要么干脆不启用 AI 分诊，只用手工流程。
参与共建的方式
熟悉 Jira 流程的开发者可以直接提缺口 Issue，工作流、字段、自动化、迁移这几块都是明确的贡献方向，仓库地址是 https://gitcode.com/yongfeng9m-/reqmanpy。截图素材在仓库的 docs/assets/demo-0*.png 和 demo.gif，覆盖了从 Intake 表单到分诊队列的完整链路。
ID:7099
