AI Native 能力建设：从系统 MCP 化到研发范式重构

之所以把它单独成篇而不是拆到各个业务 Case 里去，是因为它的核心价值不在任何一个具体功能上，而在于范式——同一套 MCP + Skill 的设计方法被复用到了采集和后训练两个系统上；同一套 AI Native 研发流程改变了软件团队的所有日常。任何一个业务 Case 单独讲，都无法完整承载这件事的分量。所以本页专门收纳这条能力演进主线，其他 Case 里出现的 MCP、AI 编排、Git 一手工作流，都会在这里指回到具体的设计判断和演进逻辑。

需要先说清楚的是：这条线不是自上而下按方法论规划出来的，是从一次次具体的工作习惯变化里长出来的。我和 CTO 就"怎么让研发效率更高"聊过很多次，但没有人在早期就把它定义成 "AI Native 方法论"。我在采集和后训练两个业务场景里独立实践，最终两条路径殊途同归，长成了现在这个样子。以下按三个阶段展开。

阶段一：系统能力 MCP 化 —— 从批量工具到 AI 操作入口

起点：一个偶然发现的用户行为

事情最开始不是从 AI 出发的，是从运营侧的一个实际压力点出发的。数据采集系统的运营每周需要创建 60 到 80 个采集项目，如果每个项目都在系统里逐个填字段、配置采集内容、定义场景 / 物体 / 分类 / 供应商，这个操作本身就成了生产瓶颈。

我最早做的应对是一个非常朴素的功能：Excel 批量导入。运营端提前把所有项目的字段用 Excel 写好，然后一次性导入系统。这个功能上线之后确实解决了当下的效率问题，但真正让我警觉的是我在后续观察运营实际使用方式时看到的东西——运营不是直接手写 Excel，他们的实际工作流是：

先和 Claude / ChatGPT 聊需求 → AI 帮忙整理成结构化的 Excel → 再把 Excel 导入系统。

也就是说，用户在没有任何人提醒或引导的情况下，已经自发形成了"先在自己熟悉的 AI 环境里生成结构化需求，再进入系统执行"的行为模式。他们把 AI 当成了一个介于自己和系统之间的中间层。

这个观察是这条线真正的起点。它让我意识到一件事：所谓 "AI Native"，可能并不是我们要"新加"一个 AI 交互层给用户，而是用户已经在这样用了，只是系统还没跟上。

产品经理要 Chat UI，我拒绝了

顺着这个洞察，产品经理最先给出的方案是很自然的：在系统内做一个 Chat UI，让用户在系统里直接用对话式界面来配置项目。这个方向表面上非常合理——既然用户已经习惯了和 AI 对话，那就在系统里给他们一个 AI 对话入口，一站式完成。

我没有沿着这个方向做，而且当时就明确反对了。理由有两条，是我当时真实的判断，不是复盘后的补充：

第一，用户已经在自己熟悉的 AI 环境里工作了——Claude、ChatGPT、他们自己配好的 Prompt、自己积累的记忆和上下文、自己习惯的输入方式。如果我们再造一个系统内 Chat UI，就等于要求他们从熟悉的环境切换到一个不熟悉的、能力上未必对等的对话入口。用户体验上是负值，不是正值。而且更麻烦的是，系统内自建的 Chat UI 的 Prompt 能力、记忆能力、上下文管理，短期内不可能达到 Claude / ChatGPT 这种成熟产品的水准——我们不可能只为了一个业务功能去重造一个通用 AI。

第二，Chat UI 会把所有复杂性集中到一个地方。业务规则、字段校验、操作顺序、异常兜底，最后全部都要塞进那个 Chat UI 背后的一个大 Prompt 里。这种设计的演进能力非常差——每加一个业务场景，Prompt 就更臃肿一分，最后必然崩塌。更根本的是，它把 AI 能力和某一个具体产品耦合死了，未来切换模型、切换 AI 平台、接入新的 AI 生态，全都要重写一遍。

那正确的方向就变得很清楚：不要重新造一个 AI 入口，而是把系统能力暴露给现有的 AI。

MCP + Skill 的分层设计

具体方案分两层：

MCP 层——系统能力的标准化暴露。我把采集系统里原本散落在各个后台接口里的核心操作抽象成一组 MCP（Model Context Protocol）能力，包括创建采集项目、定义采集任务、创建和管理供应商、配置采集要求、分配供应商，以及围绕这些主流程的一系列辅助操作。MCP 描述的是"系统能做什么"，是一个纯粹的能力目录，不包含任何"应该怎么做"的判断。

这一层的关键设计是：MCP 描述不依赖任何具体的 AI 产品。Claude 可以用、ChatGPT 可以用、任何支持 MCP 协议的 AI 客户端都可以用。系统能力和 AI 产品之间是解耦的。

Skill 层——业务方法论的显式化。光有 MCP 能力还不够，因为 AI 就算能调 API，也不知道"一个采集项目应该怎么合理地配置"——哪些字段必须填、字段之间有什么依赖、操作应该按什么顺序执行、哪些信息 AI 应该主动向用户追问、哪些信息可以由 AI 自己补全。这些原本是运营人员脑子里的隐性知识。Skill 就是把这些隐性知识显式化沉淀下来，作为 MCP 之上的一层业务方法论描述。

两层组合起来，用户面对的就不再是一堆孤立的 API 或表单字段，而是一个"可以被 AI 理解和执行的完整工作流"：

用户自然语言需求
      ↓
AI 理解意图
      ↓
Skill 约束 / 引导 AI 补全细节
      ↓
AI 和用户确认关键信息
      ↓
形成结构化任务
      ↓
AI 调用 MCP
      ↓
创建项目 → 配置采集 → 分配供应商

第一条链路：登录本身也被拉进 Tool 流程

方案设计出来之后，我一个人负责了从方案 → 开发 → 测试 → 运营侧上手的整条链路，大约用了一周时间做出了第一条完整可用的业务链路：

AI 对话 → 自动弹出登录框 → 完成业务登录和认证 → 获取业务权限 → 创建采集项目 → 配置采集任务 → 分配供应商。

这条链路里有一个不太显眼但很关键的设计——登录本身也被封装成了 Tool。也就是说 AI 在对话过程中如果发现当前用户没有认证，它可以直接触发登录流程、把登录框弹出来、等用户完成认证之后再继续后面的业务操作。用户不需要提前登录系统、也不需要在两个界面之间来回切换，整条链路在 AI 对话里一次性走完。

之所以要把登录也做进来，是因为我从一开始就没想让这套东西变成"用户还是要先登录系统然后再来用 AI"的半吊子形态。既然目标是让用户完全通过 AI 完成工作，那就不能在链路中间留一个"你得先去别处登一下"的断点。

真实使用两周，发现的问题

链路交付之后，运营侧实际使用了大约两周，规模大概是每周 40 到 50 个项目。这个数字比之前预期的每周 60~80 略低一些，一部分原因是这是一个磨合期，运营也在学怎么和 AI 配合。

使用过程中运营主动给了反馈，这些反馈让我对 MCP + Skill 的边界有了更清晰的认识：

系统能力本身是能跑通的，但 AI 对业务意图的理解并不总是可靠。举一个具体的例子：运营描述了一个采集需求，AI 在理解过程中对某个业务概念的判断出现了偏差，最后配置出来的项目在业务上是不合逻辑的——字段值本身合规，但组合起来并不符合真实的采集场景。这类问题不是系统 Bug，是 AI 语义理解和业务真实意图之间的 gap。

运营给出的诉求非常明确：需要一个人为验证的阶段——不是要 AI 别参与，而是要在 AI 最终把项目"创建下去"之前，先让人确认一下"这个配置是不是你想要的"。

解法从技术上不复杂，本质就是在 Skill 里再加一条明确的规则：AI 在调用最终"创建项目"这个 MCP 之前，必须先把已经理解和补全好的完整配置反馈给用户、等用户明确确认之后才能继续。这个 checkpoint 不是加在系统里的（如果加在系统里就等于强制所有调用者都走这个流程，太重了），而是加在 Skill 这一层的——因为它本质上是业务层的一条"操作规范"，不是能力层的一条"接口约束"。

这里我想诚实说一句：因为公司的人力和资源投入有限，这条产品线在打通第一条链路、跑了两周、拿到反馈、把人工确认这一步加上之后，就没有继续往更深的方向做。它验证了方向的正确性，但没有变成一个大规模覆盖所有业务场景的成熟产品。这是这条线目前真实的边界。

这一阶段沉淀下来的判断

不是"MCP 比 Chat UI 技术上更好"，而是几个更根本的判断：

第一，AI 产品的入口设计应该跟着用户已有的行为走，而不是要求用户跟着产品走。用户在哪里用 AI，系统能力就应该暴露到那里去。

第二，能力层和方法论层必须分开。MCP 描述系统能做什么，Skill 描述业务应该怎么做，两者混在一起的方案（比如 Chat UI 里一个大 Prompt 包打天下）在能力扩展和业务演进上都会很快到瓶颈。

第三，AI 可以执行，但不能默认拥有最终业务决策权。这一点在后面的研发模式里会被继续沿用和强化。

阶段二：AI Native 研发模式 —— 从 Git 文档化到全流程自动化

第二条线和第一条线是并行发生的，但起点完全不同。它不是从一个宏大的"AI Native 研发方法论"开始的，是从一个非常琐碎的问题开始的：AI 生成的 Markdown 文档，放哪里合适？

起点：把文档扔进 Git

我们发现一个很朴素的现象——AI 写出来的东西大部分是 Markdown 格式，而 Markdown 在飞书文档里的解析和展示体验都很一般（表格、代码块、层级结构经常错版），但在 Git（GitHub / Gitea 的 Web 界面）里读起来非常自然。所以当时最初的选择只是一个技术选型：AI 生成的文档，都往 Git 里放。

这一步没有任何"方法论"色彩，只是"哪里读得顺就放哪里"。

第二步：Git 从文档存储变成协作载体

用了一段时间之后开始注意到一些新变化：AI 调外部接口和读写文件的能力越来越强了。原本我们的工作流是：

人写文档 → 放 Git → 同步给团队 → 大家读 → 讨论 → 再写方案 → 再讨论。

中间涉及大量在飞书文档和 Git 之间搬运信息的工作。慢慢地，我们开始"偷懒"——直接让 AI 把产出物写进 Git 的 Issue 或 PR 里。AI 可以自己创建 Issue、写描述、评论、提 PR、写 PR 描述。人这一侧要做的只是"发现问题 → 把问题清楚地丢进一个 Issue"，剩下的都不用手工搬运。

这种用法持续一段时间之后，很多原本需要在多个系统之间流转的工作，其实一个 Git 就能完全承载了。文档、讨论、决策、代码变更、Review 意见，全都可以留在 Git 里。

于是研发协作流程就自然地演化到了新的形态：

发现问题
   ↓
Git 一手（Issue）——包含完整的问题描述和上下文
   ↓
其他同事 / AI 直接读一手就能开始干活

我们把这种"某个业务需求或问题在 Git 里的第一份完整描述"叫做一手。一手不是一个术语上的创新，是我们内部的约定叫法——它强调的是"这份 Issue 是所有后续工作的第一手来源，所有讨论、设计、决策都从它出发、并回写到它上面"。

到这一步为止，其实还没有涉及任何"AI 自动化研发"的东西。变化只是协作媒介从多个系统集中到了 Git 一个地方。但这一步做完之后，Git 已经不再是一个"代码仓库"，而是变成了：

整个研发过程的工作台。

这是所有后续演进的地基。

第三步：把研发流程自动化

一旦所有信息都集中在 Git 里，一个新的问题就自然浮出来了：既然 AI 可以读写 Git，那 Issue → 需求分析 → PR → Review → 修改 这一整串工作，为什么还要靠人一步步串起来？

我开始亲自搭建这条自动化链路。这不是一个"方案先行、然后实施"的过程，是一步步在实际使用中把痛点自动化掉的：

Issue 自动分析。新的一手创建之后，AI 自动读取内容，判断需求是否完整、是否需要更多上下文、有没有明显的技术疑问、需要哪些前置信息。如果需求描述有明显缺口，AI 会主动在 Issue 里提问，把 gap 暴露给需求提出者。

PR 自动关联和生成。对于 AI 可以处理的一手，AI 会直接开始设计和实现，产出 PR，并在 PR 里把设计思路、变更说明、和 Issue 的对应关系写清楚。

AI Review。PR 提出之后，接一套自动的 PR Review 流程——AI 读代码、对照一手要求、给出 Review 意见。

Review 后的自动修改和多轮 Review。AI 拿到 Review 意见之后可以直接在 PR 上做修改，改完之后触发下一轮 Review，直到 Review 通过或者进入需要人工介入的状态。

整套流程串起来是：

Git 一手（Issue）
   ↓
AI 自动分析 / 拆解
   ↓
（分流）
   ↓
AI 施工 → PR
   ↓
AI Review
   ↓
自动修改
   ↓
下一轮 Review
   ↓
Merge / Release
   ↓
Milestone / 项目管理更新

过程中所有的设计、判断、修改依据都会持续回写到 Issue / PR 的评论和讨论里。

这套自动化基础设施是我自己搭出来的，用的还是我自己维护的一套开源工具的思路——那套开源工具最初就是围绕"AI + Git 工作流"设计的，我在公司里的这套实践基本上是把开源工具的思路在具体业务场景里落成产品化的工作方式。

关键设计：不让 AI 判断业务复杂度

在设计自动化分流的时候，一个很自然的想法是"让 AI 自己判断这个 Issue 是简单的还是复杂的，简单的自己做，复杂的转给人"。

我明确没有采用这种设计。原因是在实际使用中反复观察到的一个事实：AI 对"复杂度"的判断经常是错的，而且错的方向没有规律。

• AI 认为很复杂的东西，很多时候其实只是"业务上的一个约定"——比如某个字段的命名规则、某个流程的固定顺序，人一眼就知道，AI 会觉得涉及大量代码变更。
• AI 认为很简单的东西，很多时候真实业务场景里并不好用——比如一个看起来只要加个开关的功能，实际涉及权限、数据一致性、下游消费方等一连串隐藏语义。

复杂度不是一个可以自动判断的指标，业务语义和业务约定才是。所以我在流程里保留了两个明确的人工 Checkpoint：

Checkpoint 1——需求授权 / 澄清。一手进入之后，是否授权 AI 自动处理，由人来判断。人也可以选择先给 AI 补充更详细的业务上下文、澄清关键约定，然后再让 AI 继续。这一步的本质是"人来给 AI 定义任务边界"。

Checkpoint 2——最终验收。一个 Case 执行完毕、准备 Merge 之前，人会看一眼最终结果，做最后确认。

这两个 Checkpoint 之外的所有环节——分析、设计（简单场景）、Coding、Review、修改——都可以由 AI 自主推进。这形成了整套模式的核心结构：

Human Checkpoint + AI Execution

人负责授权 / 澄清 → AI 执行 → 人最终验收

对于特别复杂、需要额外系统设计的问题，工作方式和常规业务不一样——这类问题会退化到人主导设计、AI 辅助施工的模式，但一手和最终验收这两个 Checkpoint 依然存在。

Git 从代码仓库变成工程决策记录

这套流程跑起来之后，Git 的角色又发生了一次变化。它不再只是"代码仓库"，也不再只是"协作工作台"，而是变成了：

研发过程的工作台 + 工程决策记录。

以后回头看某个功能，可以在 Git 里看到完整链路：当时为什么提这个需求（一手描述）、怎么理解问题（AI 分析 + 讨论记录）、做过哪些设计（PR 描述 + 评论）、为什么选这个方案而不是另一个（决策讨论）、AI 做了什么、人做了什么判断、最终代码怎么落地（PR diff + Merge 记录）。

这种"决策历史沉淀"是这套模式带来的一个非常关键的副产品——它不是设计出来的，是"所有工作都在 Git 里发生"这件事的自然结果。以前很多研发决策存在人脑里、飞书聊天记录里，人一走就没了；现在所有决策都自然沉淀在仓库里，可追溯、可审计、可被后续 AI 继续读取和使用。

落地程度：软件团队默认工作方式 + 公司级 Git 一手入口

这套模式现在已经不是"我个人的实验"，也不是"少数几个 Case 在这么做"，而是：

在软件团队内部，已经是默认的工作方式——所有新的业务需求都自然地按"Git 一手 → AI 分析 / 施工 → PR → AI Review / 修改 → 人 Checkpoint → Merge"这条路走。这不是被 CTO 或者我强制推行的，是团队在使用过程中自发形成的共识——用起来更省事，大家自己就切过来了。

在公司层面，Git 一手成了给软件团队提需求的统一入口——不管是硬件团队、产品团队、运营团队、还是其他任何团队，如果要给软件团队提需求，必须先在 Git 上创建一手，否则我们不接、不进入研发闭环。这一条也不是被强制的，是软件团队采用新模式之后自然产生的边界——所有下游流程都从 Git 一手开始，没有一手就无法进入这个流程。硬件和其他业务团队自己内部还没有采用完整的 AI Native 工作方式，但他们和软件团队之间的接口已经完全统一到 Git 上了。

效果：不是 Coding 更快，是脑带宽被释放

这里必须诚实说一句：我没有做过效率统计——没有"提升 X%"、"单需求耗时降 Y%"、"人力节省 Z 人"这种数字，因为我们从来没有专门为了统计而统计。

但我能观察到的一个非常具体的变化是：

在传统 AI Coding 模式下（一个人手动 prompt AI 写代码），团队的研发速度其实完全取决于研发人员当前的心力和脑带宽——你今天状态好、能记住 3 个业务上下文，你就能推 3 件事；你今天累了、只能 focus 一件事，你就只能推 1 件事。个体的脑带宽是硬瓶颈。

新模式产生之后，最大的变化是——平时那些低成本、重复性的工作（需求初分析、PR 描述、Review 意见跟踪、修改闭环）几乎不再占用额外的脑带宽。研发人员可以把有限的注意力集中投放在真正需要人判断的地方：业务语义澄清、系统设计、最终验收。

这个观察比任何一个效率百分比都更接近真实。它说明这套模式的价值不是"让人更快地做重复劳动"，而是"把重复劳动从人身上拿走，让人只做人应该做的事"。

阶段三：从 Operator 到 Analyst —— MCP 向后训练系统的扩展

前两个阶段完成之后，MCP + Skill 这套方法本身也在被扩展。

采集系统里的 MCP 验证成功之后，我把这套思路带到了后训练系统。后训练系统里同样存在"用户需要理解和操作复杂业务流程"的场景——只不过场景变了，从"创建采集项目"变成了"分析训练过程、理解训练质量"。

我把训练相关的一系列能力抽象成了新的 MCP：训练任务的状态查询、训练过程数据的读取、训练指标的解析、训练质量的评估维度。同时配上对应的 Skill，描述"分析一个训练任务的质量应该看哪些维度、按什么顺序看、异常应该怎么解读"。

用户接入这套 MCP 之后，可以在自己熟悉的 AI 里直接问："帮我分析一下最近这次训练的质量"——AI 会调用 MCP 拉训练数据、按 Skill 定义的方法论展开分析、给出结构化的判断。

这一步的关键区别是——AI 的角色变了：

第一阶段：AI 是 Operator（操作员）——帮用户操作系统，创建项目、配置采集。

第二阶段：AI 是 Analyst（分析者）——帮用户理解系统产生的数据和结果。

MCP + Skill 的底层设计没有变：能力层和方法论层依然清晰分离，AI 依然不依赖任何特定产品，Human Checkpoint 依然存在（分析结论的采纳还是要人来判断）。变的是认知模式：从"执行"扩展到了"解释"。

这种扩展也验证了 MCP + Skill 这套方法本身的可迁移性——它不是一个只能用于"创建采集项目"的具体方案，是一个可以复用到任何"用户需要通过 AI 完成复杂系统交互"场景的通用范式。

技术架构：MCP + Skill 分层与研发自动化链路

产品侧：MCP + Skill 分层
┌──────────────────────────────────────┐
│  用户（运营）                          │
│  "我想创建一份做饭的视频采集项目"        │
└──────────────┬───────────────────────┘
               ▼
┌──────────────────────────────────────┐
│  AI（Claude / ChatGPT / 任意 MCP 兼容）│
│  理解意图 → Skill 约束 → 信息补全      │
│  → 人工确认 checkpoint                │
└──────────────┬───────────────────────┘
               ▼
┌──────────────────────────────────────┐
│  Skill 层（业务方法论）                │
│  · 必填字段定义                       │
│  · 操作步骤序列                       │
│  · 信息补全逻辑                       │
│  · 人工确认节点                       │
└──────────────┬───────────────────────┘
               ▼
┌──────────────────────────────────────┐
│  MCP 层（系统能力）                    │
│  · 创建项目    · 配置采集任务          │
│  · 管理供应商  · 分配人员              │
│  · 认证登录    · 状态查询              │
└──────────────────────────────────────┘

研发侧：AI Native 自动化链路
  业务需求
     ▼
  Git Issue（"一手"，人工关卡）
     ▼
  AI 自动分析 + 拆解
     ▼
  ┌────────────────────────┐
  │ 简单任务 → AI 直接施工   │
  │ 复杂任务 → 人工设计判断  │  ← 人决定复杂度，不交给 AI
  └────────────┬───────────┘
               ▼
  代码 / PR
     ▼
  AI Review → 自动修改 → 再 Review（多轮）
     ▼
  人工最终验收（第二个 checkpoint）
     ▼
  Merge → Release → Milestone
     ▼
  全过程决策回写 Git Issue/PR
  → 工程决策历史可追溯

各 Case 中的体现

这条能力主线不是抽象存在的，它在其他每个具体业务 Case 里都有落地。这里给出交叉引用：

Case 3——数据生产平台。这是 MCP + Skill 第一次真正落地的地方。运营侧真实使用两周、40~50 项目/周的验证、"AI 不能默认拥有最终业务决策权"这条判断的来源，都在那个 Case 里。那个 Case 讲的是"数据生产平台本身"，本页讲的是"MCP 化这件事的思考和判断"，两者互为补充。

Case 5——后训练平台。这是 MCP 扩展到"Analyst"角色的地方。后训练系统里的训练分析、训练质量评估 MCP，用的是这里沉淀出来的同一套 MCP + Skill 分层设计方法。

所有 Case 的研发过程。本页描述的 AI Native 研发模式（Git 一手 → AI 分析 → PR → AI Review → Human Checkpoint → Merge）是所有其他 Case 在最近一年后半段的默认执行方式。每个 Case 里的具体功能都是通过这条流程做出来的，Git 里都留着完整的一手 → 决策 → PR → Review → Merge 的记录。

回看这条主线

这条线本身没有一个"从零到一的宏大立项"，它是从两个非常小的观察起步的——一个是"运营在偷偷用 Claude 生成 Excel"，一个是"AI 写的 Markdown 放 Git 里更好读"。但它最终演化成的东西改变了两件事：产品和用户的关系、以及研发和工作的关系。

产品侧——我推翻了产品经理最开始要的 Chat UI 方案，因为我看到了用户已经在自己熟悉的 AI 里干活的事实。MCP + Skill 的分层设计让 AI 接入不再绑定任何具体产品，让业务方法论有了显式化的载体。这套方法在采集系统跑通之后被平移到后训练系统，验证了它的通用性。

研发侧——我把 Git 从代码仓库演化成了整条研发生产链路的工作台，亲自搭了 Issue → AI 分析 → PR → AI Review → 自动修改 → Merge 的自动化基础设施，形成了 Human Checkpoint + AI Execution 的默认研发范式。这套模式在软件团队变成了共识，公司内部所有给软件团队提需求的通道也统一收敛到了 Git 一手。

两条线共同证明的是同一个判断：AI Native 不是"给系统加一个 AI 功能"，而是重新划分"系统的复杂性"和"人的判断"之间的边界——让机器承担复杂性，让人专注在只有人能做的判断和验收上。

最后必须诚实说明的证据边界：MCP 那条线只跑通了第一条业务链路，实际使用两周、40~50 项目/周，因为人力资源限制没有继续深入拓展；研发模式那条线没有任何量化效率数据，最能说明问题的定性证据是"低成本工作不再占用额外脑带宽"这个观察；这套模式在软件团队是共识，但硬件和其他业务团队自身还没有采用；我和 CTO 是共同探索者，但两条线的具体设计和实现都是我自己主导完成的，MCP + Skill 的方案设计 / 开发 / 测试 / 运营侧交付大约用了一周，研发流程的自动化基础设施也是我亲自搭的，并且抽象进了我自己维护的开源工具里。