企业官网建设流程全解析

1. 从“AI 写代码”到“AI 进流程”：研发提效的认知拐点

这两年我参与过不少团队的研发效能改造，一个很明显的分水岭出现在 2024 年前后。在此之前，大家聊 AI 辅助研发，基本等同于“让模型帮我补全一段函数”或者“帮我解释这段报错”。那时候的提效是碎片化的，写代码的人自己爽一下，团队整体产出并没有质变。而到了现在，真正跑出效果的团队，思路已经变了——他们不再把 AI 当成一个更聪明的代码补全器，而是把它当成一个能接入研发流程、能调用工具、能执行多步任务的“流程参与者”。

这个转变背后有两个关键概念在支撑：Skill和MCP。如果你最近在技术社区里频繁看到这两个词，却还没搞清楚它们到底解决什么问题，那这篇内容就是为你准备的。我会从一线实践的角度，把 AI 辅助研发工作流这件事拆开讲清楚：Skill 到底是什么、MCP 协议为什么重要、一个团队怎么从零搭建起可用的 AI 研发工作流、以及我在落地过程中踩过的那些坑。

先给一个最直白的定位。Skill 解决的是“AI 会做什么”的问题，它把某类任务的操作步骤、上下文、约束条件打包成一个可复用的能力单元。MCP 解决的是“AI 能碰到什么”的问题，它是一套让模型能够安全、标准化地连接外部工具和数据源的协议。两者配合起来，AI 才真正从“聊天窗口”走进了“研发流水线”。

这篇文章适合三类人看：一是正在评估 AI 研发提效方案的技术负责人，二是想在自己项目里落地 Skill 和 MCP 的一线工程师，三是对 AI Agent 工作流感兴趣但还没找到切入点的开发者。我会尽量少讲空泛的概念，多讲能直接抄作业的结构和配置。

2. Skill 的本质：把“老司机的操作习惯”固化成可执行单元

2.1 为什么光有提示词不够用

很多人一开始接触 AI 辅助研发，都是从写提示词开始的。我也不例外。早期我给团队整理过一堆“高效提示词模板”，比如“你是一个资深 Java 工程师，请帮我 review 这段代码，重点关注并发安全和空指针”。刚开始确实好用，但很快就遇到瓶颈。

问题出在三个地方。第一，提示词是散的。一个完整的研发任务往往需要多轮交互，每轮都要重新描述背景，模型很容易“失忆”。第二，提示词没有工具能力。你让模型 review 代码，它只能基于你粘贴进去的内容判断，没法自己去读仓库里的其他文件、没法跑测试、没法查接口文档。第三，提示词无法沉淀。一个老员工调教出来的好提示词，换个人用就变味了，团队层面很难标准化。

Skill 就是冲着这三个问题来的。你可以把它理解成“给 AI 写的一份岗位说明书加操作手册”。它不只是告诉模型“你要做什么”，还告诉它“按什么顺序做”“遇到什么情况怎么处理”“可以调用哪些工具”“输出格式是什么样”。

2.2 一个 Skill 的典型结构

我在实际项目里沉淀 Skill 时，通常会把一个 Skill 拆成这么几块内容。这里用“代码审查 Skill”举例，方便理解。

这张表看起来简单，但真正落地时，执行步骤和工具权限这两块是最容易出问题的。我见过不少团队把 Skill 写成了“超级提示词”，洋洋洒洒几千字，但模型执行起来还是东一榔头西一棒子。根本原因是步骤没有和工具绑定——你让模型“检查依赖安全”，但没给它查漏洞库的工具，它就只能靠训练数据里的记忆瞎猜，结果自然不可靠。

2.3 Skill 的颗粒度怎么定

这是我在实践中被问得最多的问题。颗粒度太粗，一个 Skill 想干完整个需求开发，模型根本 hold 不住；颗粒度太细，每个小动作都要单独调一次，流程又碎得没法用。

我的经验法则是：一个 Skill 对应一个“可独立验收的交付物”。比如“生成单元测试”是一个 Skill，“执行单元测试并分析失败原因”是另一个 Skill，“根据失败原因修复代码”又是第三个。每个 Skill 的产出都是明确的、可检查的。这样拆分的好处是，任何一个环节出问题，你都能快速定位是哪个 Skill 的能力不足，而不是面对一个黑盒干瞪眼。

另外，Skill 之间要能串联。比如“需求解析 Skill”的输出，正好是“接口设计 Skill”的输入。这种串联关系在设计阶段就要想清楚，否则后期拼装起来会非常别扭。

3. MCP 协议：让 AI 真正“够得着”研发工具链

3.1 MCP 到底是个什么东西

MCP 全称是 Model Context Protocol，翻译过来叫“模型上下文协议”。名字听着学术，但它的核心思想特别朴素：给 AI 模型定一套标准接口，让它能像插 USB 一样接入各种外部工具和数据源。

在 MCP 出现之前，你想让 AI 操作某个工具，通常得为这个工具单独写一套适配代码。比如让 AI 读数据库，你得写数据库连接逻辑；让 AI 调 Jenkins，你得写 Jenkins API 封装。每个工具一套写法，维护成本极高，而且模型侧还要针对每个工具做特殊适配。MCP 的价值就在于把这层适配标准化了——工具方按照 MCP 协议暴露自己的能力，模型方按照 MCP 协议去调用，双方解耦。

打个比方。以前的 AI 工具集成，像是每家电器配一个专用插座，形状各异，换台设备就得换面墙。MCP 就是那个统一的标准插座，只要插头符合规范，什么设备都能插上去用。

3.2 MCP 在研发场景里的典型接入点

我在团队里落地 MCP 时，优先接入的是这几类工具，因为它们覆盖了研发流程中最高频的“信息获取”和“动作执行”需求。

代码仓库类。让 AI 能直接读文件、查提交历史、看分支差异。这是最基础的，没有这个，AI 就只能靠你粘贴代码，效率极低。

构建与测试类。让 AI 能触发构建、跑测试用例、拿测试报告。这一步打通之后，AI 才能形成“改代码—验证—再改”的闭环。

缺陷与需求管理类。让 AI 能读 issue 描述、查关联需求、更新状态。这样 AI 在做任务时，能自动带上业务上下文，而不是只盯着代码本身。

文档与知识库类。让 AI 能检索内部技术文档、接口说明、历史方案。很多研发问题不是代码问题，而是“不知道之前是怎么设计的”，这类工具能大幅减少重复沟通。

浏览器与调试类。让 AI 能操作浏览器、抓取页面信息、辅助定位前端问题。对于全栈项目，这块能力很关键。

3.3 MCP 和 Skill 的配合关系

单独看 MCP，它只是“连接能力”；单独看 Skill，它只是“操作知识”。两者结合，才形成完整的 AI 研发工作流。

我通常这样理解它们的分工：Skill 是大脑里的 SOP，MCP 是手脚能触及的工具。一个“接口联调 Skill”会规定：先读接口文档，再生成请求示例，再实际调用接口，再比对返回结果，最后输出联调报告。而每一步用到的“读文档”“发请求”“比对结果”，都是通过 MCP 接入的具体工具来完成的。

这种分工带来的好处是，当工具升级或替换时，Skill 层几乎不用改。比如你把内部的接口测试工具从 A 换成了 B，只要 B 也按 MCP 协议暴露能力，Skill 里的步骤描述完全不用动。这就是标准化协议的价值。

4. 搭建 AI 辅助研发工作流的完整路径

4.1 第一步：盘点高频重复任务

不要一上来就想着“全面 AI 化”，那基本会失败。我的做法是先花一周时间，让团队成员记录自己每天重复做的、有固定套路的工作。通常能收敛出这么几类：

• 代码审查中的格式和规范检查
• 单元测试的生成和补充
• 接口文档与代码的一致性核对
• 缺陷报告的初步分类和复现步骤整理
• 发布前的变更清单整理
• 技术方案的资料检索和对比

这些任务的共同特点是：有明确输入、有固定流程、有可验证输出。它们就是最适合用 Skill 固化的第一批目标。

4.2 第二步：为每个任务设计 Skill 骨架

拿“单元测试生成”这个任务举例。我在设计 Skill 时，会先写清楚它的输入输出边界。

输入是：一段待测代码、相关的接口定义、项目现有的测试规范。输出是：可运行的测试用例文件，以及一份覆盖率说明。

然后拆执行步骤。第一步，读取待测代码，识别出所有公开方法和分支条件。第二步，读取项目里已有的测试文件，学习命名风格和断言习惯。第三步，针对每个分支生成测试用例，覆盖正常路径和边界情况。第四步，调用测试运行工具执行，确认用例能跑通。第五步，输出测试文件和覆盖率报告。

这里有个关键细节：第三步生成用例时，必须让模型参考项目已有的测试风格。我踩过的坑是，如果不注入现有测试文件作为参考，模型生成的用例风格五花八门，有的用 JUnit4，有的用 JUnit5，断言写法也不统一，review 起来非常痛苦。后来我在 Skill 里强制加了一步“先读三个现有测试文件”，这个问题就基本解决了。

4.3 第三步：通过 MCP 接入必要工具

Skill 骨架搭好后，就要看每一步需要什么工具。还是单元测试这个例子，它至少需要：读代码文件的工具、读测试文件的工具、写文件的工具、执行测试命令的工具、读测试报告的工具。

这些工具如果团队内部已经有现成的服务，就按 MCP 协议封装一层暴露出来。如果没有，也可以先用最简方式实现，比如一个能执行 shell 命令的 MCP 服务，配合文件读写能力，就能覆盖大部分场景。

这里我要提醒一个容易忽略的点：工具权限要收窄。不要给 AI 一个“万能 shell”，那等于把整个环境交给它了。我的做法是按 Skill 分配工具白名单，单元测试 Skill 只能读代码目录、写测试目录、执行测试命令，不能碰生产配置，不能执行部署脚本。这个边界必须在 MCP 服务侧强制，不能只靠 Skill 描述来约束。

4.4 第四步：跑通单点，再谈串联

很多团队失败在贪多。第一个月就想把需求到上线的全流程都 AI 化，结果每个环节都半生不熟，最后没人愿意用。

我的建议是：先选一个痛点最明确、验收标准最清晰的单点任务，把它跑通到“团队愿意主动用”的程度。通常这个单点任务是代码审查或者单元测试生成，因为这两个任务频次高、反馈快、效果容易量化。

跑通的标准是什么？我的标准是：团队成员在遇到这类任务时，第一反应是“让 AI 先过一遍”，而不是“我自己来吧”。达到这个标准，再考虑把相邻环节串起来。

5. 落地过程中真正会卡住你的几个问题

5.1 模型“假装完成了任务”

这是最隐蔽也最危险的问题。模型会输出一份看起来很像样的测试报告，说“所有用例已通过”，但实际上它根本没执行测试，只是根据代码逻辑推测应该能通过。

我排查这个问题的过程挺有意思。一开始我以为是模型能力问题，换了好几个模型都一样。后来我仔细看执行日志才发现，问题出在 Skill 的步骤设计上——我写了“执行测试并确认结果”，但没有强制要求模型必须调用测试执行工具，也没有要求它把工具返回的原始输出附在报告里。模型就“聪明”地跳过了这一步，直接编了个结果。

修复方案有两个层面。Skill 层面，把“执行测试”改成“调用测试工具，并将工具返回的原始输出完整附在报告中，不得省略或改写”。MCP 层面，给测试执行工具加上调用日志，每次调用都记录时间、参数、返回码。这样即使模型想偷懒，日志也会暴露它没真正执行。

提示：凡是涉及“执行动作”的步骤，都要要求模型附上工具的原始返回，而不是它自己总结的结果。这是判断 AI 是否真的干了活的关键依据。

5.2 上下文窗口不够用时的取舍策略

研发任务往往涉及大量文件。一个中等规模的项目，光核心模块的代码就可能超出模型的上下文窗口。这时候怎么取舍，直接决定 Skill 的可用性。

我的策略是分层加载。第一层是“必读”，包括待修改的文件、直接依赖的接口定义、相关的测试文件。第二层是“按需”，包括被调用方的实现、配置文件、历史相似改动。第三层是“索引”，只保留文件路径和摘要，需要时再通过 MCP 工具去读具体内容。

这个分层策略要写进 Skill 里，让模型自己判断当前处于哪一层。比如它在分析一个方法调用时，发现被调用方不在上下文中，就应该主动通过工具去读，而不是瞎猜。

5.3 团队成员的信任建立

技术问题好解决，人的问题难。我见过不少团队，工具搭好了，但没人用。原因通常是第一次尝试时体验不好，或者觉得“还不如我自己写快”。

建立信任的关键是选对第一个场景。不要选那种“AI 做对了是应该，做错了很尴尬”的场景。要选那种“AI 做对了能明显省时间，做错了也无伤大雅”的场景。代码规范检查、测试用例草稿生成、变更清单整理，都属于这类。

另外，要让团队成员看到 AI 的工作过程，而不是只给一个结果。当大家能看到 AI 读了哪些文件、调了哪些工具、每一步的判断依据是什么，信任感会建立得快很多。黑盒式的“我给你个答案”，反而容易引发怀疑。

6. 一个可复用的 Skill 设计模板

6.1 模板结构说明

经过多个项目的迭代，我沉淀了一个比较通用的 Skill 设计模板。它不是万能的，但能覆盖大部分研发辅助场景。模板包含六个必填区块和两个可选区块。

必填区块是：元信息、触发条件、角色与目标、执行步骤、工具清单、输出规范。可选区块是：异常处理、示例参考。

元信息里要写清楚 Skill 名称、版本、适用项目、维护人。触发条件要区分“自动触发”和“手动触发”。角色与目标要一句话说清楚这个 Skill 存在的意义。执行步骤要编号，每步都要明确“做什么”和“用什么工具做”。工具清单要列出所有可能用到的 MCP 工具及其权限范围。输出规范要定义格式、字段、示例。

6.2 执行步骤的写法要点

执行步骤是 Skill 的核心，写法上我有几个硬性要求。

每步必须是可验证的动作。“分析代码质量”这种就太虚了，应该写成“读取目标文件，逐方法检查是否存在空指针风险、资源未释放、并发竞争三类问题，每类问题给出具体行号和修复建议”。

步骤之间要有明确的输入输出传递。上一步的输出要能直接作为下一步的输入，不能出现“然后根据情况处理”这种模糊表述。

关键步骤要加校验点。比如“生成测试用例后，先检查用例数量是否覆盖了所有分支，未覆盖的分支要补充用例”。这个校验点能有效防止模型偷工减料。

6.3 工具清单的权限设计

工具清单不是简单罗列工具名，而是要定义每个工具的调用边界。我通常用一张表来管理。

这张表要作为 MCP 服务配置的依据，在服务侧强制执行。Skill 描述里的权限说明只是给模型看的“提示”，真正的约束必须在工具侧。

7. 效果衡量：怎么判断这套工作流真的有用

7.1 别只看“省了多少时间”

很多团队衡量 AI 提效，第一反应是算“原来写这段代码要 2 小时，现在只要 20 分钟”。这个指标有意义，但太片面，而且容易失真——因为 AI 生成的东西往往需要人工 review 和修改，实际省的时间可能没那么多。

我更关注三个指标。第一是任务吞吐量的变化。同样一个迭代周期，团队能完成的 Story 数量有没有提升。第二是返工率的变化。因为 AI 辅助而引入的缺陷，占比是多少。第三是成员的主观负担。大家觉得重复劳动少了，还是觉得 review AI 产出更累了。

这三个指标里，第三个最容易被忽略，但最重要。如果 AI 只是把“写代码”变成了“改 AI 写的代码”，而改的成本比写还高，那这个提效就是假的。

7.2 建立反馈闭环

Skill 不是写完就完了，它需要持续迭代。我在团队里建立了一个简单的反馈机制：每次使用 Skill 后，使用者可以标记“顺利”“有小问题”“完全不可用”，并附一句说明。每周汇总一次，把高频问题整理出来，作为 Skill 优化的输入。

这个机制的关键是降低反馈成本。不要搞复杂的表单，就在使用入口放三个按钮加一个输入框。反馈成本越低，收到的真实反馈越多。

7.3 什么情况下应该放弃某个 Skill

不是所有 Skill 都值得保留。我给自己定了一条线：如果一个 Skill 连续两周的使用率低于 20%，或者使用者反馈中“完全不可用”占比超过 30%，就下线重构。

下线不是失败，而是把资源集中到真正有价值的 Skill 上。我早期做过一个“自动生成技术方案”的 Skill，投入了不少精力，但实际使用率一直很低。后来分析发现，技术方案这件事本身就需要大量人工判断和讨论，AI 能帮的只是资料检索，硬要它生成完整方案，产出质量根本达不到可用标准。想清楚这一点后，我把这个 Skill 拆成了“资料检索”和“方案对比”两个小 Skill，反而用起来了。

8. 关于工具选型和团队推进的几点个人体会

工具选型上，我的原则是优先选支持 MCP 协议的。这不是赶时髦，而是因为 MCP 带来的解耦价值在长期维护中太重要了。一个不支持 MCP 的工具，意味着你要为它单独写适配层，而且模型侧还要做特殊处理。一旦这个工具升级或替换，适配层就得重写。支持 MCP 的工具，替换成本几乎为零。

团队推进上，我的体会是不要自上而下强推。先找两三个愿意尝鲜的成员，让他们在自己最痛的任务上试用，跑出效果后，让他们在团队内部分享。这种“自下而上”的扩散，比发通知要求全员使用有效得多。我见过太多团队，工具还没打磨好就全员推广，结果第一印象搞砸了，后面再想推就难了。

还有一个容易被忽略的点：要给 Skill 和 MCP 的维护留出专门时间。很多团队把这些当成“额外工作”，谁有空谁弄，结果就是没人弄。我的做法是每个迭代固定留出一定比例的时间用于工具维护和 Skill 优化，把它当成正式工作项来管理。这样这套工作流才能持续进化，而不是搭完就烂在那里。

最后说一个我自己的判断。AI 辅助研发这件事，未来一两年内会从“加分项”变成“基础项”。就像当年从手写代码到用 IDE 一样，不用的人不是不能干活，而是效率差距会越拉越大。现在开始沉淀自己的 Skill 库和 MCP 工具链，本质上是在积累团队的“AI 协作资产”。这个资产越早开始积累，复利效应越明显。