跳转至

初卓 ERP · AI 协作蓝图

给团队所有人看的一份 "我们为什么这么做、要做成什么样" 的高层文档。 详细操作步骤在 docs/01_onboarding/ 与各角色指南里。

1. 我们的目标

用 AI 把 20 人团队的产研产能放大 2× 以上，且让每个角色的"无脑环节"被自动化吞掉。

具体即：

角色 希望 AI 接管的部分
技术/项目经理 Sprint 规划 / 故事就绪度门禁 / 风险依赖扫描 / 状态周报 / 评审治理
PM 原料收敛 / 文档撰写 / 故事拆解 / 原型生成
后端 CRUD 脚手架 / 接口调用样板 / 单测 / 文档 / 自查
前端 列表/表单/弹窗样板 / 字典枚举 / 路由 / 自查
QA 用例 / 自动回归 / 缺陷归集
运维 故障定位 cookbook 检索 / 部署文档 / 监控

剩下的部分（业务理解、架构判断、风险评估、用户体验把关）仍然是人类的核心价值。

2. 五条铁律

  1. AI 输出的是"草稿"，不是"成品"：所有 AI 生成的代码 / 文档 / 用例都必须有人类 review，特别是涉及生产、安全、合规的部分。
  2. 优先复用现有能力：先查 IFinmate 框架 → 再查公司前端封装 → 再查 PingCode 知识库 → 仍然没有再考虑造轮子。
  3. 事实先行：拉到 PingCode 故事 / 文档之前不写代码；不靠脑补开工。
  4. OpenSpec 是新功能的"通行证"：跨服务 / 新表 / 新接口必走 change proposal。
  5. 本地自检 + 人评把关：开发本地用 Claude Code / Codex 自检通过；Gitee PR 走 Gitee Go 流水线（当前仅 Maven 编译、跳测试）+ 开发组长人工复核后合并。AI 自动评审（Qodo PR-Agent）目前是自建 GitLab 上对 czerp-demo 的试点、推广中，尚未覆盖 Gitee 主仓。

3. 整体协作架构

┌────────────────────────────────────────────────────────────────────┐
│              产品经理（Notion + 钉钉 + 微信 + Figma + Axure）              │
└──────────┬─────────────────────────────────────────────────────────┘
           │ 整理 → AI 收敛 → 写故事 → 出原型
           ▼
┌────────────────────────────────────────────────────────────────────┐
│        PingCode (CZPRD 需求 / CZPRJ 项目 / CZTST 测试 / CZKB 知识库)        │
└──────────┬─────────────────────────────────────────────────────────┘
           │ 故事分发到 Sprint
           ▼
┌────────────────────────────┐  ┌─────────────────────────────────┐
│  后端 / 前端 / Codex / Claude   │  │  测试 (生成用例 + AI 驱动回归)              │
│  - 拉故事 + OpenSpec change   │  │  - 拉故事 + 计划                         │
│  - Superpowers TDD / 实现     │  │  - 用例上 CZTST                        │
│  - 本地 Pre-PR Review         │  │  - 回归 → 失败自动提缺陷                 │
└──────────┬─────────────────┘  └──────────┬──────────────────────┘
           │ git push                       │
           ▼                                ▼
┌────────────────────────────────────────────────────────────────────┐
│        Gitee PR (Gitee Go 编译跳测试 + 组长人评) → 合并 → CI 构建镜像        │
└──────────┬─────────────────────────────────────────────────────────┘
           │
           ▼
┌────────────────────────────────────────────────────────────────────┐
│   Jenkins 直推 czerp-gitops(main) + ArgoCD AutoSync → k8s rolling → 监控告警 │
└────────────────────────────────────────────────────────────────────┘

详细流程图见 02_workflow-diagram.md。

4. 关键基础设施

名字 当前状态
PingCode MCP 已部署（内部 MCP，经 MCPJungle 网关 czerp-team-mcp 接入）
Gitee MCP 已部署（官方）
Notion MCP 已部署（官方）
Axure LLM Wiki MCP 已部署，公司内网
钉钉接入 当前路径：会议智能纪要导出 → Notion → AI 提炼（见 czerp-pm/dingtalk-meeting-distill）
OpenSpec 全员强制（新功能）
Superpowers plugin 全员安装（claude-plugins-official）
本仓库 marketplace Claude Code / Codex 均接入（见 docs/01_onboarding/04_multi-agent.md）

5. 与存量代码的关系

存量代码未走 OpenSpec、无配套 skill。策略：

  1. 不强行回填：存量代码不补 spec。
  2. AGENTS.md 描述现状：legacy-onboarding/ 备有各仓库 AGENTS.md 模板，由维护者一次性部署到各代码仓库根（sync-legacy-agents.mjs --apply 后提交）让 AI 读懂约定；尚未部署的仓库 AI 暂读不到仓库级约定。
  3. 新需求走新流程：新功能一律 OpenSpec change + skills-aware 开发。
  4. 高频模块按需补：某存量模块被频繁改动时，由 Tech Lead 决定是否补 spec。

6. 落地原则

  • 先打通最小闭环再铺开：每个角色先用一个真实任务跑通端到端，再推广。
  • 遇阻碍即补：不顺畅点 → 补 skill / 补 docs / 调流程，走 PR。
  • 以产能与质量为准绳：用 AI 介入前后的实际效果决定下一步投入，而非一次性铺满。

7. 风险与边界

  • 过度依赖 AI → 仍然要求人类 review 关键决策。
  • AI 输出的代码不知所云 → 强调 Superpowers requesting-code-review + 本仓库 pre-pr-review 双重检查。
  • 数据安全 → 客户敏感数据、密钥、prod token 绝不进 AI 上下文。
  • AI 上下文窗口 → 大故事 + 大代码库会撞到 token 限制 → 使用 Explore / general-purpose Agent 子任务分担。
  • 团队学习曲线 → 提供 docs/04_training/ 课件 + 自学路径。

进一步阅读：