企业官网建设流程全解析

1. 从“AI 辅助研发”说起：为什么大多数团队用了个寂寞

这两年“AI 辅助研发”这个词被喊得震天响，几乎每家公司都在搞，但真正跑通、跑顺、跑出效果的团队其实不多。我见过太多团队，买了几十上百个账号，配了各种插件，结果三个月后统计一下，真正每天在用的不超过三成人，剩下的人要么觉得“还不如自己写”，要么觉得“生成的东西没法用，改起来更费劲”。问题出在哪？不是模型不行，是工作流没搭对。

所谓“AI 辅助研发工作流”，核心不是让 AI 帮你写几行代码，而是把 AI 嵌入到研发的完整链路里——需求拆解、方案设计、编码、测试、Code Review、文档沉淀，每个环节都有 AI 的参与方式，而且这些参与方式要能串起来，形成可复用的“套路”。而“团队提效”则是这套工作流跑通之后的自然结果，不是靠堆工具堆出来的。

这篇文章我想聊的就是这套东西怎么落地。适合谁来读？如果你是团队里那个“负责推 AI 工具的人”，或者你自己想把手上的 AI 工具用出体系感，那这篇就是写给你的。我会从整体设计思路讲到具体环节的实现，包括 Skill、MCP 这些最近很热的概念到底怎么用、用在哪，以及我在实际推进过程中踩过的坑。

先给一个整体判断：AI 辅助研发的提效上限，取决于你把多少“上下文”喂给了 AI，以及你把多少“重复动作”固化成了可复用的能力单元。前者靠 MCP 这类协议解决，后者靠 Skill 这类封装解决。这两条线是整篇文章的主干。

2. 整体设计与思路拆解：先想清楚 AI 在链路里的位置

2.1 为什么不能“哪里都塞 AI”，而要分层设计

很多团队一上来就想“全流程 AI 化”，结果每个环节都浅尝辄止。我的做法是先把研发链路拆成三层，然后判断每层 AI 的介入方式。

第一层是信息层：需求文档、接口定义、历史代码、报错日志、数据库表结构。这一层 AI 的价值是“理解和检索”，它需要能读到这些信息。第二层是执行层：写代码、改 bug、写测试、跑命令。这一层 AI 的价值是“动手”，它需要能操作工具。第三层是沉淀层：把这次的经验变成下次能直接用的东西，比如一个 Skill、一段提示词模板、一个检查清单。

分层的好处是，你不会指望一个模型对话窗口解决所有问题。信息层靠 MCP 打通数据源，执行层靠 Agent 加工具调用，沉淀层靠 Skill 封装。三层各司其职，链路才跑得通。

2.2 MCP 到底解决什么问题：把“上下文”标准化

MCP 全称 Model Context Protocol，你可以把它理解成“AI 和外部世界之间的标准插头”。在没有 MCP 之前，你想让 AI 读到你的数据库、你的接口文档、你的浏览器页面，得为每个数据源单独写对接代码，换个模型就得重写一遍。MCP 把这个过程标准化了：只要数据源那边提供一个 MCP Server，任何支持 MCP 的客户端都能直接连上去用。

举个实际场景。我们团队做前端联调的时候，经常需要 AI 帮忙看接口返回。以前的做法是把 JSON 复制粘贴到对话框里，又长又容易漏字段。后来接了一个数据库查询的 MCP Server，AI 可以直接查表结构、查样本数据，我只需要说“帮我看看这个订单接口的返回字段和表结构对不对得上”，它自己就去查了。这就是 MCP 的价值——把“人肉搬运上下文”变成“AI 自主获取上下文”。

2.3 Skill 的角色：把“重复动作”固化成能力单元

如果说 MCP 解决的是“AI 能拿到什么”，那 Skill 解决的就是“AI 会做什么”。Skill 本质上是一段封装好的能力描述，包含触发条件、执行步骤、注意事项。你可以把它理解成给 AI 写的“操作手册”。

比如我们团队有一个“生成单元测试”的 Skill，里面写清楚了：先读被测函数的入参和出参类型，再读项目里已有的测试文件作为风格参考，然后按 AAA 模式（Arrange-Act-Assert）生成，最后跑一遍确认能过。这套流程固化下来之后，任何人只要触发这个 Skill，出来的测试质量都稳定在一个水平线上，不会因为“今天提示词写得随意”就翻车。

Skill 和 MCP 的关系是互补的：MCP 负责“取数据”，Skill 负责“用数据做事”。一个完整的研发动作，往往是 Skill 触发后，内部调用若干 MCP Server 去拿信息，再执行生成或修改。

2.4 方案选型的几个关键取舍

在推进过程中，有几个选择是必须提前想清楚的。

第一个取舍：用通用 Agent 还是自建工作流？通用 Agent 灵活，但不可控；自建工作流可控，但维护成本高。我的建议是核心链路（比如提交前的检查）用自建工作流保证稳定性，探索性任务（比如调研一个新技术方案）用通用 Agent 放开手脚。

第二个取舍：Skill 粒度多细合适？太细了调用麻烦，太粗了复用性差。我的经验是按“一个完整的研发动作”来切，比如“根据需求生成接口定义”是一个 Skill，“根据接口定义生成 Mock 数据”是另一个，而不是把“生成接口定义”再拆成“分析需求”“提取实体”“定义字段”三个 Skill。

第三个取舍：MCP Server 自己写还是用现成的？通用数据源（数据库、文件系统、浏览器）优先用社区现成的，业务特有的（比如我们内部的工单系统）自己写。自己写的时候注意把权限收窄，只暴露必要的读接口，别一上来就给写权限。

3. 核心细节解析与实操要点：MCP 和 Skill 怎么落地

3.1 MCP Server 的接入方式与权限设计

接入一个 MCP Server，通常是在客户端配置里加一段配置，声明 Server 的启动命令或连接地址。以文件系统为例，配置里会写明允许访问的目录范围。这里有个关键点：权限范围一定要收窄。我见过有人图省事，直接把项目根目录甚至整个用户目录暴露出去，结果 AI 在排查问题时误删了不该动的文件。正确的做法是只暴露当前任务需要的目录，任务结束就关掉。

对于数据库类的 MCP Server，我的做法是准备两个连接：一个只读连接给日常查询用，一个受限的写连接只在明确需要改数据时临时开启。只读连接里再通过视图限制可见的表，避免 AI 看到敏感字段。这些限制看起来麻烦，但比起出事之后的排查成本，前期多花十分钟配置完全值得。

3.2 一个真实可用的 Skill 结构长什么样

Skill 的写法没有唯一标准，但一个能稳定复用的 Skill，通常包含这几块内容：触发描述、前置检查、执行步骤、输出格式、异常处理。

触发描述要写清楚“什么情况下用这个 Skill”，比如“当用户要求为某个函数补充单元测试时”。前置检查是执行前要确认的条件，比如“确认被测文件存在且能编译通过”。执行步骤是核心，要写到“AI 照着做就能出结果”的粒度。输出格式规定结果长什么样，比如“输出一个完整的测试文件，文件名遵循 xxx 规范”。异常处理是兜底，比如“如果编译不通过，先输出错误信息再停止，不要盲目修改”。

我特别想强调前置检查这一块。很多 Skill 翻车不是因为步骤写得不好，而是因为没检查前置条件就开干。比如让 AI 改代码，结果当前分支有未提交的改动，改完一提交把别人的东西也带进去了。加一句“检查工作区是否干净”就能避免这类问题。

3.3 把 MCP 和 Skill 串起来：一个完整的研发动作拆解

拿“修复一个线上 bug”这个动作举例，看看 MCP 和 Skill 怎么配合。

第一步，触发“bug 定位”Skill。这个 Skill 内部会调用日志查询的 MCP Server，拉取相关时间段的错误日志，再调用代码检索的 MCP Server，找到报错位置对应的代码。第二步，AI 分析日志和代码，给出可能的根因。第三步，触发“修复方案生成”Skill，这个 Skill 会参考项目里类似问题的历史修复记录（通过代码仓库 MCP 获取），生成修复方案。第四步，人工确认方案后，触发“代码修改”Skill，AI 执行修改并跑本地测试。第五步，触发“提交信息生成”Skill，按团队规范生成 commit message。

整个链路里，人只在“确认方案”这一步介入，其余都是 AI 按 Skill 定义执行。这就是工作流跑通之后的样子——人做判断，AI 做执行。

3.4 实操中的几个硬性注意事项

注意：MCP Server 的连接信息里如果包含凭证，不要直接写在明文配置里，用环境变量注入。

注意：Skill 的执行步骤里，凡是涉及“删除”“覆盖”“提交”这类不可逆操作，必须加人工确认环节，不能让 AI 自动执行。

注意：多个 MCP Server 同时连接时，注意它们的工具命名是否冲突，冲突时客户端可能随机选一个，导致行为不可预期。

还有一个容易被忽略的点：Skill 要版本化。我们团队把 Skill 文件放在独立的仓库里，每次修改都走 PR 流程。这样当某个 Skill 改出问题时，能快速回滚到上一个稳定版本。没有版本管理的 Skill，改着改着就没人敢用了。

4. 实操过程与核心环节实现：从零搭一套可用的工作流

4.1 环境准备与基础配置

先把基础环境搭起来。你需要一个支持 MCP 的客户端（现在主流的一些代码编辑器都支持），然后准备几个基础 MCP Server。我的起步配置是三个：文件系统、代码仓库、数据库只读。文件系统 Server 限定在当前项目目录，代码仓库 Server 用来查历史提交和 blame，数据库 Server 用只读账号。

配置写完之后，先做连通性测试。让 AI 执行一个简单任务，比如“列出当前项目根目录下的所有文件”，确认它能正确调用文件系统 Server。这一步别跳过，我见过配置写错了但一直没发现，后面排查半天以为是模型问题。

4.2 第一个 Skill 的编写与调试

从最简单的 Skill 开始，比如“生成 commit message”。步骤可以这样写：先调用代码仓库 MCP 获取本次改动的 diff，然后按团队规范（比如 type(scope): description）生成消息，最后输出。调试的时候，故意制造几种情况：只改了一个文件、改了多个文件、改了配置文件、改了测试文件，看生成的 message 是否都符合规范。不符合就调整 Skill 里的描述，直到稳定。

这个过程中你会发现，Skill 的描述越具体，输出越稳定。比如“按团队规范生成”就不如“格式为 type(scope): description，type 从 feat/fix/docs/refactor/test 中选，scope 为改动涉及的模块名”来得可靠。

4.3 把 Skill 接入日常研发流程

Skill 写好之后，关键是让它“出现在该出现的地方”。我们的做法是在几个关键节点设置触发点：提交代码前自动提示“是否生成 commit message”，创建 PR 时自动提示“是否生成 PR 描述”，收到 bug 工单时自动提示“是否启动 bug 定位流程”。这些提示不是强制的，但因为有提示，使用率比“让用户自己想起来用”高很多。

这里有个经验：触发点要少而准。一开始我们设了十几个触发点，结果用户被频繁打扰，反而关掉了提示。后来精简到五个核心节点，使用率反而上去了。

4.4 效果度量：怎么知道工作流真的提效了

不能只看“用了多少次”，要看“省了多少时间”。我们的做法是记录几个关键指标：从收到需求到提交第一个 PR 的平均时长、Code Review 的平均轮次、单元测试覆盖率的变化、线上 bug 的修复时长。这些指标在引入工作流前后各统计一个月，对比看变化。

实测下来，最明显的改善在 Code Review 轮次上，因为 AI 在提交前已经按 Skill 做了一轮自检，低级问题少了很多。单元测试覆盖率也有提升，因为生成测试的成本降低了。但需求到 PR 的时长改善没那么明显，因为需求理解这部分 AI 还替代不了人。

5. 常见问题与排查技巧实录

5.1 MCP 连接类问题速查

5.2 Skill 执行不稳定的排查思路

Skill 输出不稳定，八成是描述有歧义。排查方法是把 Skill 里的每一步单独拿出来测，看哪一步的输出波动最大。比如“分析代码风格”这一步，如果 AI 每次分析的维度不一样，就说明描述太模糊，要改成“分析命名规范、缩进风格、注释密度三个维度”。

另一个常见问题是 Skill 之间的依赖没处理好。比如 Skill A 的输出是 Skill B 的输入，但 A 的输出格式偶尔变化，B 就挂了。解决办法是在 A 的输出格式里加校验，格式不对就报错而不是往下传。

5.3 团队推进中的非技术障碍

技术问题好解决，人的问题难。最常见的抵触是“AI 生成的东西我还要检查，不如自己写”。应对方法是先挑那些“人本来就不想写”的任务切入，比如写测试、写文档、写 commit message。这些任务人写起来痛苦，AI 写出来哪怕要改，心理接受度也高。等大家习惯了，再往核心编码环节推。

还有一个坑是“一刀切强制使用”。我们一开始要求所有人必须用 AI 生成 commit message，结果有人为了应付，生成完看都不看就提交，反而引入了错误信息。后来改成“推荐使用，但提交前自己确认”，质量反而好了。

5.4 几个我踩过的坑

坑一：过早追求“全自动”。一开始想让 AI 自动改 bug 并自动提交，结果有一次改错了逻辑还直接推上去了。后来加了人工确认环节，虽然多一步，但安全得多。

坑二：Skill 写得太“聪明”。有个 Skill 我写了很多分支判断，想让它适应各种情况，结果维护起来极其痛苦。后来拆成三个简单 Skill，每个只管一种情况，反而好用。

坑三：忽略上下文长度限制。有一次让 AI 读一个超大文件，结果它只读了前面一部分就开始分析，结论完全不对。后来在 Skill 里加了“文件超过一定行数就先分段”的处理。

6. 工作流的持续演进：从个人用到团队用

6.1 个人工作流怎么沉淀成团队资产

个人用 AI 用出感觉之后，下一步是把它变成团队能用的东西。关键动作是把个人提示词变成 Skill，把个人配置变成团队配置。你个人调好的提示词，如果不封装成 Skill，别人用的时候还是得重新调。你个人配的 MCP Server，如果不写成团队共享的配置模板，每个人都要重新配一遍。

我们的做法是建了一个“AI 工作流”仓库，里面放 Skill 文件、MCP 配置模板、使用说明。新人入职第一天就把这个仓库克隆下来，按说明配好环境，当天就能用上团队积累的能力。

6.2 怎么让 Skill 库持续生长

Skill 库不能只靠一两个人维护，要让用的人也能贡献。我们设了一个简单的机制：任何人用 AI 完成一个重复性任务超过三次，就建议把它写成 Skill。写好的 Skill 走 PR 流程，由熟悉的人 review 后合并。这样 Skill 库是跟着实际需求长出来的，不是拍脑袋规划出来的。

6.3 后续可以扩展的方向

现在我们的工作流主要覆盖编码和测试环节，后续想往两个方向扩。一个是往上游走，接入需求管理工具，让 AI 辅助需求拆解和排期。另一个是往下游走，接入监控系统，让 AI 在告警触发时自动做初步排查。这两个方向都需要对应的 MCP Server 支持，目前还在摸索阶段。

我个人在实际操作中的体会是，AI 辅助研发这件事，技术选型只占三成，剩下七成是工作流设计和团队习惯培养。工具再好，如果没嵌进日常动作里，用两周就荒废了。反过来，哪怕工具朴素一点，只要工作流顺，大家用着不别扭，效果就能持续出来。最后分享一个小技巧：每次团队周会留五分钟，让一个人分享他这周用 AI 解决的一个具体问题，比任何培训都管用。