AI CLI 企业管理面板
项目可行性分析报告
目录
01项目背景
当前公司已有部分团队成员在使用 AI CLI 工具（Codex 等）辅助工作，但由于工具入口分散、缺乏统一管理，目前仅少数工程师能够熟练使用，50+ 人团队中大部分岗位（运营、客服、设计、人事、行政等）未能有效使用。
参考浪潮中心 Wave Center 的产品思路，拟建设一套企业级 AI CLI 管理面板，将分散的个人工具转化为团队统一管理的生产力资产。
- 公司已具备内部账号体系并接入钉钉，账号与组织架构可直接复用，无需重新搭建
- 部分团队成员已在使用 AI CLI，具备真实使用场景基础，无需从零推广
02建设目标与核心功能
项目目标
将 AI CLI 从「个人工具」升级为「团队可控资产」，使各岗位均能在权限可控的前提下安全使用 AI 能力，而非仅限于工程岗位。
核心功能规划
| 序号 | 功能 | 说明 | 规划阶段 |
|---|---|---|---|
| 1 | 统一入口 | 接入 Codex（后续扩展至 Claude Code 等），通过公司钉钉账号统一登录，免去多套工具分别登录 | 阶段一 |
| 2 | 会话历史留存 | 按项目、按人员留存使用记录，支持跨人员、跨工具的历史追溯 | 阶段一 |
| 3 | Key 集中托管 | API Key 不直接暴露给员工，由系统统一管理、分发、监控异常使用 | 阶段一（基础版） |
| 4 | 团队技能库 | 将高频提示词沉淀为可复用「技能」（如批量改商品标题、整理客诉原因），非工程岗位可直接调用 | 阶段一（固定模板） |
| 5 | 权限分级 | 技能按风险等级分类（查询/生成/修改/执行），按角色开放对应权限 | 阶段二 |
| 6 | 用量统计 | 按人员、项目、模型维度统计使用量与成本，支撑管理决策 | 阶段二 |
拟解决的核心问题
使用门槛高
工具入口分散，非工程岗位难以判断该使用哪个工具、Key 应如何配置、历史产出如何查找。
管控风险高
Key 一旦泄露或被用于越权操作，缺乏有效的追溯和管控手段。
经验无法沉淀
各自独立使用，优质提示词和经验无法在团队内复用，人员变动后需重新摸索。
03开源方案调研
在启动自主研发前，已对市面现有开源项目进行调研，评估是否存在可直接复用的成熟方案。
| 项目 | 支持的CLI | 团队/权限能力 | 技术栈 | 协议 | 评估结论 |
|---|---|---|---|---|---|
| preset-io/agor | Claude Code / Codex / Gemini / Copilot / OpenCode / Cursor | 多人协同、分支级RBAC+ACL、按人分Key隔离、Token/费用记账、完整会话历史持久化 | FeathersJS + React + LibSQL/Postgres | BSL 1.1（非纯开源） | 不能直接部署 |
| Genuifx/claude-code-env-manager（CCEM） | Claude Code / Codex | 6种权限模式、Key加密存储、团队配置共享（加密传输），但无完整多用户RBAC/分账体系 | Tauri 2.0 + React + Rust | MIT | 可作参考，能力不足以独立支撑 |
| mukul975/claude-team-dashboard | 仅Claude Code | 「团队」指AI Agent团队，非人类多用户团队；仅单密码验证，协作功能尚未落地 | React + Node.js + Express + WebSocket | MIT | 不符合需求，排除 |
| siteboon/claudecodeui | Claude Code / OpenCode / Cursor / Codex | 未见多用户RBAC支持，定位偏向个人远程访问工具 | 未详查 | 待确认 | 形态不符，排除 |
agor 项目风险说明
agor 是目前功能覆盖面与本次需求最为吻合的项目，涵盖多CLI适配、团队协同、分支级权限、按人Key隔离、完整会话记账等能力。但其授权条款存在明确限制，需重点说明：
- 许可协议：Business Source License 1.1（标准 MariaDB 模板）
- Additional Use Grant（额外使用授权）：None——未开放任何生产环境使用豁免，限制程度高于同类 BSL 项目
- Change Date：2029-01-15，该日期之前受限，之后自动转为 Apache 2.0 完全开源协议
- 授权范围：允许复制、修改、创建衍生作品、再分发，以及「非生产用途使用」（如本地代码研究、技术选型评估、Demo验证）；超出该范围需购买商业授权，或不得使用，条款原文为
you must purchase a commercial license from the Licensor... or you must refrain from using the Licensed Work
可行的应对方式：
- 架构参考、自主实现——研究其设计思路（分层架构、分支级 RBAC 设计、按人 Key 隔离机制、Token/费用记账数据模型），自主开发实现。参考开源项目的架构思路与直接部署使用二者性质不同，前者不涉及协议合规风险。
- 如需直接使用，需联系项目作者 Maxime Beauchemin 购买商业授权，或等待 2029-01-15 协议自动转为 Apache 2.0（时间上不具备可行性，不作为选项）。
- 备选参考方案：CCEM（MIT 协议，无限制）可直接复用其权限模式设计和 Key 加密传输方案作为部分实现参考，但团队账号体系、RBAC、多CLI适配等核心能力仍需自主搭建。
04产品形态与页面规划
产品形态是网页还是安装包，会直接影响后续开发周期与工作量的评估，因此需要在方案中明确这一点。
面板的目标用户覆盖运营、客服、设计、人事、行政等多个非工程岗位，这些岗位的典型任务（改写文案、整理表格、生成素材、处理文档）围绕文本、表格、图片等日常办公产出展开，不涉及本地代码仓库操作，这个特点决定了终端形态的选择方向。
4.1 Web 端与桌面客户端对比
| 对比维度 | Web 端（网页） | 桌面客户端（安装包） |
|---|---|---|
| 使用门槛 | 打开浏览器输入地址即可用，零安装 | 需下载安装，推广门槛更高 |
| 跨平台适配 | 天然支持 Windows/Mac，无需额外适配 | 需分别打包、签名、维护多平台版本 |
| 版本管理 | 服务端统一更新，员工无感知 | 需要自动更新机制，否则版本参差不齐，排查困难 |
| 本地文件/代码仓库访问 | 无法访问，AI任务需在服务端隔离环境执行 | 可直接访问本机文件与代码仓库 |
| 开发成本 | 相对较低，适合快速验证 | 跨平台打包、签名、自动更新本身是独立工作量 |
| 离线使用 | 不支持 | 部分功能可支持 |
4.2 形态建议
结合目标用户的任务特点（处理文本/表格/图片，不涉及本地代码仓库），阶段一建议采用纯 Web 端形态，员工通过浏览器访问即可使用，不做安装包。理由：
- 目标用户以非工程岗位为主，任务本身不需要访问本机文件系统，服务端执行完全能满足需求
- 零安装、跨平台的特性，能最大程度降低非工程岗位的使用门槛，契合「让不熟悉工具的岗位也能用起来」这一核心目标
- 开发成本更低，适合优先验证核心假设，不必在验证阶段投入跨平台打包这类周期较长的工作
4.3 阶段一页面规划（基于 Web 端形态）
| 页面 | 说明 |
|---|---|
| 登录页 | 对接钉钉扫码/免密跳转登录，不单独开发账号密码体系 |
| 工作台（核心页） | 选择技能模板或直接输入需求，实时查看 Codex 输出流 |
| 历史记录页 | 按项目、按时间查看历史任务与产出结果 |
| 技能库页 | 浏览、选择团队沉淀的 3-5 条固定技能模板 |
阶段二将在此基础上新增：管理后台（用量统计、权限分配、审计日志查看）、技能编辑页（供工程师维护和扩展技能库）。
05实施路径与阶段规划
Demo / 原型验证
- 接入公司钉钉账号，不单独开发登录系统
- 接入 Codex，CLI输出流实时展示于网页端（采用SSE方案）
- 会话按用户与项目维度留存，支持历史记录查询
- Key 不向用户直接暴露，由系统代管代填（基础版本）
- 提供3-5条团队沉淀的固定「技能」模板，支持点选调用
企业级系统建设（面向 50+ 人规模）
- 钉钉组织架构映射至部门/角色权限体系
- 技能库按4级风险分类，按角色可见范围隔离
- Key全生命周期管理：发放、轮换、离职自动回收、异常限流
- 会话按项目、人员、模型多维度统计，支撑用量与成本核算
- 审计日志导出
- 多CLI适配层，后续每新增一个CLI仅需开发对应适配器
周期压缩依据：阶段一账号体系直接对接钉钉SSO，无需另行开发登录注册，技术架构可参考agor现有设计，减少技术摸索成本；阶段二账号体系搭建与核心架构摸索两项最耗时工作已省去，参考agor成熟设计可减少弯路。
阶段一验证目标：验证非工程岗位能否通过该面板有效使用AI CLI（核心假设），同时验证技术路径（进程管理、流式输出转发、Key加密存储）的可行性。
阶段二关键风险提示
Key 集中托管是最大的安全风险点
若设计不严谨，将由「分散的小风险」转变为「一次性泄露全员Key的单点风险」。该模块需单独进行安全设计评审（加密存储方案、访问审计、最小权限原则），不宜直接套用现成方案上线。
多CLI适配难度存在差异
Codex、Claude Code相对标准化，Cursor CLI、OpenCode的开放程度目前尚未验证，需在技术选型阶段实测确认，列为待确认风险项，避免影响后续排期。
技能库需具备明确边界设计
技能定义应包含适用场景、输入输出格式、禁止事项、失败兜底机制，不能仅存储提示词文本——否则规模化推广速度越快，风险越高。
06资源需求与排期影响
以下两项为项目启动前需明确的前置条件，直接影响项目能否按预期周期推进，需提前决策。
6.1 中转站 Key 访问问题（研发与业务两类场景需分别处理）
- 现状说明：公司产品开发内部研发团队目前日常开发工作使用的是中转站（第三方API聚合服务）Key访问GPT等模型，存在响应延迟较高的问题，该问题在本项目启动前已经存在，并已对研发团队日常工作效率造成影响，与本项目本身没有直接关系。
- 建议区分处理：
- 研发团队（工程侧）：建议为内部研发团队申请原生 OpenAI API 直连访问权限，用于日常产品开发工作（含本项目的开发过程），解决当前已经存在的效率问题。
- 业务侧 CLI 面板（面向运营、客服等使用者）：出于成本控制考虑，面板底层模型调用仍走中转站方案，不更换为原生API。
6.2 现有项目排期影响
- 现状说明：团队当前项目任务已处于满负荷排期状态
- 启动影响：若启动本项目，将必然占用现有项目的人力与时间资源，需通过实际调整排期腾出对应人力，而非依靠额外加班完成
6.3 周期估算说明
07决策事项
以下事项需明确决策后，项目方可正式启动：
- 前置资源确认：面向研发团队的原生API访问权限申请时间安排；本项目在当前排期体系中的优先级定位。以上两项未明确前，后续周期估算不具备执行基础。
- 阶段一启动：前置资源到位后，投入约1周时间完成阶段一Demo，验证「非工程岗位可用性」这一核心假设，同时完成技术路径验证。
- 阶段二决策依据：阶段一验证完成后，依据试点部门实际使用率、以及Key托管模块安全设计评审的完成情况，决定是否投入阶段二建设。
- 明确排除方案：不采用直接fork agor部署上线的方案，原因为BSL许可协议对Production Use的限制，以规避潜在的许可协议合规风险。
附实施前后对比
| 场景 | 实施前：个人各自使用CLI | 实施后：企业管理面板 |
|---|---|---|
| 安装配置 | 各自安装、自行排查问题 | 统一入口，按角色开通 |
| 会话记录 | 分散留存于本机与不同工具 | 按项目集中沉淀 |
| 技能复用 | 依赖群内转发提示词 | 技能库一键调用 |
| Key管理 | 个人保存，离职后难以回收 | 统一托管，按权限分发 |
| 成本统计 | 月末统一核对账单 | 按人员、项目、模型分项统计 |
| 风险控制 | 事后追查 | 事前限权、事中记录 |