AI Native 能力建设：从系统 MCP 化到研发范式重构
补天石 · 2025–2026 · 已上线
这是个什么项目
这不是独立项目，而是横穿最近一年后半段、贯穿多个系统的能力演进。它从两个观察起步：运营人员自发地先在 Claude / ChatGPT 里生成结构化采集项目配置，再导入系统；AI 生成的 Markdown 放在 Git 里比飞书自然。早期没有人把它定义成方法论，它从具体工作习惯里长出来。
两条线并行推进。产品侧，将采集与后训练系统的核心能力 MCP 化：MCP 是能力层，描述系统能做什么；Skill 是方法论层，描述业务应该怎么做。用户在熟悉的 AI 里完成操作与分析，登录也封装成工具，整条链路在 AI 对话里走完。研发侧，Git 从代码仓库演化成工作台：一手（Issue）→ AI 分析 → PR → AI Review → 自动修改 → 人工 Checkpoint → Merge，设计与决策回写 Git。
关键判断：不重造 AI 入口，把系统能力暴露给用户已有的 AI；能力层与方法论层分开；AI 可以执行，但不能默认拥有业务决策权。流程保留“需求授权 / 澄清”与“最终验收”两个 Checkpoint，复杂度判断不交给 AI。此模式后来成为软件团队默认工作方式，公司各团队向软件团队提需求统一走 Git 一手。
系统长什么样
产品侧：MCP + Skill
用户自然语言 → AI（任意 MCP 客户端）
→ Skill 层（业务方法论）
必填字段 / 操作序列 / 信息补全 / 人工确认
→ MCP 层（系统能力）
创建项目 / 配置任务 / 分配供应商 / 认证登录 / 训练分析
研发侧：Git 一手 + AI Execution
Git Issue（一手，人工授权）→ AI 分析 / 施工 → PR
→ AI Review → 自动修改（多轮）→ 人工验收 → Merge
设计与决策全程回写 Git
项目规模
- 时间：最近一年后半段，贯穿多个业务系统
- 覆盖：采集系统（Operator）与后训练系统（Analyst）两条 MCP 线；软件团队默认研发方式；公司级 Git 一手入口
- 验证：MCP 首条业务链路真实使用约两周，每周 40–50 个项目
- 边界：MCP 线未大规模铺开；研发模式无可量化效率数据
核心问题清单
① 系统应该给用户造一个 AI 入口，还是把系统能力暴露给用户已有的 AI？
→ 不重造入口：MCP 能力层 + Skill 方法论层，与具体 AI 产品解耦；用户在熟悉的 AI 环境里完成系统操作。
② 研发流程里哪些环节可以交给 AI，哪些判断必须由人保留？
→ Human Checkpoint + AI Execution：人负责需求授权 / 澄清与最终验收，其余环节由 AI 自主推进；复杂度判断不交给 AI。
③ 这套模式怎么从个人实践变成团队默认？
→ Git 成为研发工作台：一手 → 分析 → PR → Review → 修改 → Merge 全流程留在 Git，决策历史自然沉淀；需求入口自然收敛到 Git 一手。
我的职责
两条线均由我主导：完成 MCP + Skill 方案设计、开发、测试和运营侧交付，约一周打通首条业务链路；亲自搭建研发自动化基础设施（Issue 分析、PR 生成、AI Review、修改闭环），并抽象进自己维护的开源工具。与 CTO 共同探索，具体实现由我完成。
工作模式变化
- 运营侧：从表单填写 / 批量导入变为“在熟悉的 AI 里描述需求 → AI 调用 MCP”；首条链路使用约两周、每周 40–50 个项目，AI 执行前加入人工确认。
- 研发侧：默认流程变为 Git 一手 → AI 分析 / 施工 → PR → AI Review → 自动修改 → 人工 Checkpoint → Merge；研发关注点从重复执行逐渐转向业务语义、方案判断与最终验收。
- 组织侧：硬件、产品、运营等团队向软件团队提需求统一走 Git 一手，作为研发闭环入口。
- 角色扩展与沉淀：AI 从 Operator 扩展到 Analyst（解释训练质量）；工程决策历史沉淀在 Git，可追溯、可复用。边界：无量化效率数据；MCP 线因人力限制未继续铺开。