先统一项目事实，
再决定用什么系统

事实快照

真正要统一的六件事

1. 项目：一个稳定 project_id，不能用群名、仓库名或微盘目录代替。
2. 责任：一个决策负责人，明确执行、协作、审批和知会关系。
3. 阶段：开发、测试、发布、运行验证、客户验收分层表达。
4. 节点：每个项目只突出当前下一门禁、目标日期和前置条件。
5. 证据：状态必须带来源、最后核验时间、证据等级和失效规则。
6. 组合：优先级同时考虑硬门禁、价值、风险、依赖、容量和 WIP。

聊天适合捕获问题、互助和责任变化，但不能成为最终事实源。客户承诺、优先级、排期、生产和验收必须保留人工确认。

你是一名“企业项目组合管理（PPM）架构师 + 开源软件研究员 + 中国企业协作系统集成顾问”。请基于当前日期开展联网深度调研，帮助我设计一套适合多项目并行的整体管理体系，并判断应该组合现有系统、引入开源系统，还是建设一个轻量项目组合控制面。

【组织与现状】
我管理智慧食堂、智慧营养健康餐厅、食品安全、AI 产品、设备接口、客户本地部署、政务云、安全整改、售前方案等并行工作。现有系统包括企业微信、微信、企业微信微盘、云效、Codeup/Git、Codex/Agent 和部分运行数据系统。

当前“项目、任务、仓库、运行环境、微盘主题、聊天事件”没有统一对象和口径。近期可识别 14 个当前推进项，另补充 1 个受限运维项目；运行数据源登记 17 个环境；资料中出现过“7 月 22 个项目同时推进”，但没有唯一的 22 项原始名单。最近真实项目群还出现职责交接，并有人明确要求提供“软件开发进度表”向业主解释。

【核心问题】
1. 没有唯一项目主表、project_id、决策负责人、当前阶段、下一门禁、目标日期和证据路径。
2. 同一项目包含开发、测试、部署、设备、数据、外部联调、安全和材料等多泳道，单一状态失真。
3. 群聊中的需求、风险、决策、承诺、责任变化和互助没有稳定进入项目视图。
4. “有代码、开发完成、已测试、已发布、生产运行、客户验收”缺少统一证据分层。
5. 没有跨项目优先级、依赖、外部等待、资源容量和 WIP 视图。
6. 不希望一次性迁移，也不希望新增一套靠人工重复录入的看板。

【需要比较的三条路线】
A. 保留云效为研发任务事实源，新增轻量项目组合控制面；
B. 引入自托管开源 PPM 作为新的核心系统；
C. 混合架构：云效/Codeup 管研发，开源 PPM 管组合，企业微信管入口和通知，微盘管文档，Agent 管抽取和证据，BI 管管理视图。

请先建立 10–15 个候选长名单，再筛选 3–5 个短名单。可研究 OpenProject、Plane、Leantime、Taiga、Tuleap、Redmine/Easy Redmine、GitLab、ERPNext/Frappe Projects、Odoo Community、Vikunja、Nextcloud Deck 及其他活跃候选；也必须研究“不引入新 PPM”的方案。

【评估维度】
产品定位；自托管与升级备份；许可证和开放核心边界；近 12 个月活跃度；项目组合；里程碑/甘特/关键路径/跨项目依赖；人员容量和 WIP；风险/问题/决策/变更/验收/审计；组织/项目/客户权限；API/Webhook/SSO/OIDC/LDAP；企业微信、个人微信、云效、Codeup、微盘集成；Git/MR/CI/CD/发布证据；移动端和客户视图；Agent 工具调用与审核回写；三年 TCO；锁定、维护、迁移和重复录入风险。

每项结论必须标明“已证实 / 部分证实 / 未找到证据”，并给官方文档、官方仓库、release、许可证或 API 文档的直接链接和检索日期。不要用二手排行榜、软文、Star 数或过时印象替代证据。

【必须给出的统一对象模型】
Project、Workstream、WorkItem、Milestone/Gate、Risk、Issue、Dependency、Change、Decision、Person/Team/Role/Capacity、Artifact/Evidence、ConversationEvent、SourceMapping、StatusAssertion。

状态必须区分：
计划中 → 开发中 → 已开发待测试 → 测试通过待发布 → 已发布待运行验证 → 运行验证通过待客户验收 → 客户已验收。
菜单、截图、代码存在、HTTP 200 或 Agent 报告都不能直接证明生产上线或客户验收。

【优先级治理】
请设计“硬门禁 + 组合评分 + 容量约束”，覆盖合同/承诺和时间临界性、收入回款、战略复用、上线安全合规、依赖解锁、客户影响、工作量与稀缺资源、外部等待、技术债与运营成本。给出 P0/P1 条件、权重和复核责任、项目与个人 WIP 上限、插单挤出规则、外部等待处理、RACI 和只处理偏差/冲突/决策的周例会机制。

【聊天集成边界】
群聊先形成候选需求/问题/风险/决策/承诺/责任变更；关联置信度不足时人工分拣；客户承诺、优先级、截止日期、负责人变更、生产操作和外发必须人工确认；确认后才写回项目；回群时带项目 ID、负责人、下一节点、证据链接和最后核验时间。聊天是入口，不是事实源。个人微信必须说明合规、稳定性和账号风险，不得建议未经授权的抓取、逆向或绕过平台控制。

【四类同源视图】
1. 管理层：健康度、优先级、关键节点、资源冲突、逾期、外部等待、需决策；
2. 项目负责人：多泳道、依赖、风险、里程碑、证据、客户承诺；
3. 执行人：本周可执行任务、阻塞、WIP、需要协助、即将到期；
4. 客户/业主：少术语，只显示已确认范围、阶段、完成项、下一节点、双方待办和风险。

【交付结构】
一页执行结论；当前问题模型；Must/Should/Could 需求矩阵；10–15 个候选长名单；3–5 个短名单深度比较；三条组合架构和数据流；统一对象模型与最小 JSON；优先级、容量、WIP、里程碑和例会治理；四类视图；30/60/90 天试点；迁移、权限、安全、隐私、运维、TCO 和回滚；验收清单和 Go/No-Go；淘汰方案及原因；一句话总结“推荐技术栈 + 推荐治理方式 + 第一个试点项目选择原则”。

不可妥协原则：先建立唯一项目主表再选工具；一个项目一个稳定 ID、一个决策负责人、一个当前阶段、一个下一门禁、一个证据路径；所有状态带来源、证据等级、最后核验时间和失效规则；人工保留客户承诺、优先级、排期、安全、资金、生产和验收决策权；先跑 30 天试点再决定扩大迁移。

请现在开始调研，并在开头先明确回答：我们是否真的需要换系统？

研究结果的验收门槛

• 不是只列工具名称，而是比较三种组合路线。
• 不是用营销描述，而是用官方一手来源核验开源边界和能力。
• 不是直接建议大迁移，而是给出 30 天可退出试点。
• 不是只画管理层看板，而是定义项目对象、事实源、证据和人工门禁。
• 不是把个人微信自动化当默认能力，而是明确授权、隐私和平台风险。