企业官网建设流程全解析

1. 从“写代码”到“指挥AI写代码”：AI-Native SDLC到底在说什么

“AI-Native SDLC”这个词最近半年在技术圈里出现的频率越来越高，但很多人第一次听到的反应是：这不就是把Copilot装进IDE里吗？如果你也这么想，那说明你还没真正踩进这个坑里。我最初也是这么理解的，直到我把Claude Code、MCP协议、CLAUDE.md这套组合拳完整跑通一个中型项目之后，才发现事情远没有那么简单。

AI-Native SDLC的核心含义是：软件开发生命周期的每一个环节——需求拆解、架构设计、编码实现、测试验证、部署运维——都以AI为第一执行者来重新组织工作流。注意，不是“AI辅助人”，而是“人指挥AI，AI执行，人验收”。这个主次关系的颠倒，是整个方法论的分水岭。

传统SDLC里，开发者是执行主体，工具是辅助。AI-Native SDLC里，AI Agent是执行主体，人是决策者和验收者。你不再需要逐行写代码，但你需要精确地定义问题、约束边界、设计验证标准。这听起来像是“轻松了”，实际上对工程师的系统思维要求更高了——因为你必须把过去隐含在编码过程中的所有决策显式地表达出来。

这套方法论适合谁？我认为有三类人最应该关注：第一类是独立开发者或小团队技术负责人，人力有限但项目复杂度不低，AI-Native工作流能把你从重复劳动里解放出来；第二类是中大型团队里负责工程效率的架构师，你需要理解这套东西才能设计团队级的AI协作规范；第三类是技术管理者，你需要判断哪些环节可以交给AI、哪些绝对不能放手。

热搜词里频繁出现的Claude、CLAUDE.md、MCP、Claude Code，恰好构成了这套方法论目前最成熟的一条工具链。我接下来会围绕这条主线，把AI-Native SDLC的完整实践拆开讲清楚。不管你是刚听说Claude Code的新手，还是已经在用但总觉得“差点意思”的老手，下面这些内容应该都能帮你把认知和操作拉齐到同一个水平线上。

2. 工具链选型：为什么是Claude Code + MCP + CLAUDE.md

2.1 Claude Code的定位：不是补全，是Agent

很多人第一次接触Claude Code的时候会拿它和传统的代码补全工具做对比，这个对比本身就错了。代码补全工具的工作模式是“你打字，它猜你接下来要写什么”，本质上还是一个被动的响应式工具。Claude Code的工作模式是“你描述任务，它自己规划步骤、读写文件、执行命令、验证结果”，这是一个主动的Agent模式。

我举个实际场景你就明白了。假设你要给一个RuoYi-Vue-Pro项目增加一个MCP功能模块。传统补全工具能帮你做的是：你写到@PostMapping的时候它帮你补全注解参数。Claude Code能做的是：你告诉它“在ruoyi-vue-pro里新增一个MCP协议的服务端实现，需要支持工具注册和资源发现”，它会自己去读项目结构、找到合适的模块位置、生成Service层和Controller层代码、写好配置文件、甚至跑一遍编译看有没有报错。

这个差异决定了整个工作流的组织方式完全不同。用补全工具的时候，你的注意力在“这一行怎么写”；用Claude Code的时候，你的注意力在“这个任务怎么定义清楚”。

2.2 MCP协议：AI的“USB接口”

MCP这个词在热搜里出现得非常频繁，但很多人搞不清楚它到底是什么。有人问“MCP是软件协议还是硬件协议”，有人问“MCP协议和普通的API有什么区别”。我用一个类比来解释：MCP就是AI世界的USB接口。

在MCP出现之前，每个AI工具要连接外部数据源或服务，都需要写一套专门的适配代码。你想让Claude读你的数据库，写一套PostgreSQL适配；你想让Claude操作浏览器，写一套Playwright适配；你想让Claude访问Figma设计稿，再写一套Figma适配。每套适配的接口规范还不一样，换一个AI工具就得重写。

MCP（Model Context Protocol）做的事情就是定义了一套标准化的接口规范。任何数据源或工具，只要实现了一个MCP Server，所有支持MCP协议的AI客户端都能直接调用它。这就像USB接口统一了外设连接标准一样——你不需要为每个电脑单独做一个鼠标接口。

热搜里提到的“browser use mcp跟playwright mcp有什么区别”、“codex接入figma mcp怎么授权”、“codex接入蓝湖mcp”，本质上都是在问同一个问题：怎么让AI通过标准接口访问特定的外部资源。理解了MCP的定位，这些问题就都有了统一的思考框架。

2.3 CLAUDE.md：给AI的“项目入职文档”

CLAUDE.md这个文件名字看起来不起眼，但它是整个AI-Native工作流里最关键的“软基础设施”。你可以把它理解为：你给一个新入职的工程师写的项目说明文档，只不过读者是AI。

为什么需要这个文件？因为AI Agent每次开始一个新会话的时候，对项目的了解是零。它不知道你的项目用了什么技术栈、代码规范是什么、哪些目录不能动、部署流程是怎样的。如果你每次都要在对话里重复这些信息，效率极低而且容易遗漏。CLAUDE.md就是把这些上下文固化下来，让AI每次启动时自动加载。

我见过很多人抱怨“Claude Code不好用，生成的代码不符合项目规范”，一问才知道他们根本没有写CLAUDE.md。这就像你招了一个新人，不给他看任何文档就让他直接上手改代码，然后抱怨他改得不对。问题不在AI，在于你没有提供足够的上下文。

2.4 三者如何协同：一条完整的工作流

把这三个东西串起来，AI-Native SDLC的基本工作流是这样的：

1. CLAUDE.md定义上下文：项目结构、技术栈、编码规范、禁止事项、常用命令
2. MCP连接外部资源：数据库、浏览器、设计工具、项目管理平台
3. Claude Code执行任务：读取CLAUDE.md获取上下文，通过MCP调用外部资源，完成编码、测试、部署任务

这三者缺一不可。没有CLAUDE.md，AI不了解项目；没有MCP，AI无法与外部世界交互；没有Claude Code这样的Agent工具，前两者就没有执行载体。

3. 环境搭建：从零把Claude Code跑起来

3.1 安装与配置的完整流程

Claude Code的安装本身不复杂，但热搜里出现了大量安装相关的问题，比如“claude code安装”、“ubuntu配置claude code”、“vscode配置claude code”、“claude : 无法将‘claude’项识别为cmdlet、函数、脚本文件或可运行程序的名称”。这些问题大多集中在环境变量和终端配置上，我把自己在Windows、Ubuntu、macOS三个平台上的安装经验整理一下。

Windows平台需要注意几个点。首先，Claude Code在Windows上运行时需要虚拟机平台支持，如果你看到“claude's workspace requires the virtual machine platform on windows”这个提示，需要去“启用或关闭Windows功能”里勾选“虚拟机平台”和“适用于Linux的Windows子系统”。其次，安装完成后如果终端提示“无法将‘claude’项识别为cmdlet”，说明npm的全局bin目录没有加到PATH里。你可以用npm config get prefix找到npm全局目录，然后手动把这个目录加到系统环境变量里。

Ubuntu平台的安装相对顺畅，但要注意Node.js版本。Claude Code要求Node.js 18以上，如果你系统自带的Node版本太老，建议用nvm管理多版本。安装命令很简单：

npm install -g @anthropic-ai/claude-code

安装完成后直接运行claude命令就能启动。如果提示权限问题，检查一下npm全局目录的权限设置。

VS Code集成是很多人关心的。Claude Code有官方的VS Code扩展，安装后在侧边栏会多一个Claude图标，点击就能在编辑器内直接对话。这个扩展的好处是你不需要切换窗口，AI修改的代码会直接在编辑器里以diff形式展示，你可以逐行review后再决定是否接受。

3.2 CLAUDE.md的编写模板与要点

CLAUDE.md的编写质量直接决定了AI的工作质量。我经过多个项目的迭代，总结出一个比较通用的模板结构：

# 项目概述 一句话说明项目是做什么的，技术栈是什么。 # 目录结构 - src/：源代码目录 - tests/：测试目录 - config/：配置文件目录 - docs/：文档目录 # 编码规范 - 使用TypeScript strict模式 - 所有函数必须有JSDoc注释 - 错误处理统一使用自定义Error类 - 禁止使用any类型 # 常用命令 - 开发：npm run dev - 测试：npm run test - 构建：npm run build - 部署：npm run deploy # 禁止事项 - 不要修改config/production.json - 不要删除任何migration文件 - 不要直接操作数据库，通过ORM层 # 架构决策记录 - 选择PostgreSQL而非MySQL的原因：... - 选择Prisma而非TypeORM的原因：...

这个模板的关键在于：信息要具体，不要写废话。“使用TypeScript”这种话没有意义，AI本来就能从文件扩展名看出来。“使用TypeScript strict模式，禁止使用any类型”才有意义，因为这是AI从代码里不一定能推断出来的约束。

还有一个容易被忽略的点：CLAUDE.md应该随着项目演进持续更新。每当你发现AI犯了一个“本不该犯”的错误，就应该思考是不是CLAUDE.md里缺少了相应的约束，然后补上去。我用下来的经验是，一个维护良好的CLAUDE.md能让AI的代码采纳率从50%左右提升到85%以上。

3.3 MCP Server的接入与调试

MCP Server的接入方式取决于你用的具体Server。以最常见的几个为例：

文件系统MCP：让AI能够读写项目目录之外的文件。配置方式是在Claude Code的配置文件里添加：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"] } } }

PostgreSQL MCP：让AI能够直接查询数据库。热搜里有人问“postgresql好用的skill或者mcp”，这个需求很常见。配置时需要提供数据库连接字符串，建议只给只读权限，避免AI误操作数据。

Playwright MCP：让AI能够操作浏览器进行端到端测试。这个和Browser Use MCP的区别在于，Playwright MCP更偏向于测试自动化场景，Browser Use MCP更偏向于通用网页操作。

调试MCP连接问题的通用思路是：先用npx手动跑一下MCP Server的命令，看能不能正常启动；然后检查Claude Code的日志输出，看有没有连接错误；最后确认MCP Server的权限配置是否正确。热搜里“codex无法找到mcp”这类问题，90%以上是配置文件路径或格式的问题。

4. 核心工作流：AI-Native SDLC的日常操作

4.1 需求拆解：从一句话到可执行任务

AI-Native SDLC的第一步不是写代码，而是把需求拆解成AI能理解的原子任务。这件事听起来简单，做起来非常考验功力。我举个例子说明。

假设需求是“给系统增加用户头像上传功能”。如果你直接把这句话丢给Claude Code，它可能会给你一个能跑但不符合你预期的实现。正确的做法是把它拆解成：

1. 数据库层：users表增加avatar_url字段，写migration
2. 存储层：配置文件上传的存储后端（本地/S3/OSS）
3. API层：POST /api/user/avatar接口，接收multipart文件，返回URL
4. 校验层：文件类型限制（jpg/png/webp）、大小限制（2MB）、图片尺寸压缩
5. 前端层：上传组件、预览、裁剪
6. 测试：单元测试覆盖校验逻辑，集成测试覆盖上传流程

每个子任务都可以独立交给AI执行，而且每个子任务都有明确的验收标准。这种拆解方式的好处是：AI每次只专注一个明确的子问题，出错概率大幅降低；你可以在每个子任务完成后立即验证，而不是等整个功能做完才发现方向错了。

我自己的习惯是在CLAUDE.md里维护一个“任务模板”区域，把常见的需求类型（新增API、新增页面、修改数据模型等）的标准拆解方式写进去。这样每次新需求来的时候，AI可以参照模板自动拆解，我只需要review和调整。

4.2 编码实现：如何让AI写出“像你写的”代码

让AI写出符合项目风格的代码，核心手段就是CLAUDE.md + 示例代码。CLAUDE.md定义规范，示例代码展示风格。我通常会在项目里选几个“标杆文件”，在CLAUDE.md里标注“新增代码请参照src/services/user.service.ts的风格”。

具体来说，AI需要从示例代码里学到的东西包括：命名习惯（驼峰还是下划线）、错误处理模式（try-catch还是Result类型）、日志格式、注释风格、测试组织方式。这些东西很难用文字描述清楚，但给AI看几个例子它就能模仿得很好。

还有一个技巧是使用“渐进式细化”。第一轮让AI生成整体框架，你review后指出问题；第二轮让AI根据反馈修改；第三轮做细节打磨。不要指望一次生成就完美，把AI当成一个需要code review的初级工程师来对待，迭代两三轮之后质量就上来了。

4.3 测试验证：AI自测与人工验收的边界

AI-Native工作流里，测试环节的边界划分很重要。我的原则是：AI负责生成测试用例和跑通测试，人负责定义验收标准和判断边界情况。

具体操作上，我会要求AI在完成编码后自动执行以下步骤：运行现有测试套件确保没有回归、为新功能生成单元测试、运行lint和类型检查、生成变更摘要。这些步骤可以写进CLAUDE.md的“完成定义”里，让AI每次完成任务后自动执行。

但有些东西必须人工把关：业务逻辑的正确性（AI不知道你的业务规则）、边界条件的合理性（AI倾向于覆盖常见情况）、性能影响评估（AI对性能的直觉不如有经验的工程师）。我一般会在AI完成自测后，重点review这几个方面。

4.4 部署运维：AI能碰和不能碰的红线

部署环节是AI-Native SDLC里最需要谨慎的地方。我的建议是：AI可以生成部署脚本、可以执行部署命令、可以做部署后的健康检查，但绝对不能自主决定部署时机和回滚策略。

具体来说，我会在CLAUDE.md里明确写清楚：部署命令是什么、部署前需要检查什么、部署后需要验证什么。但“什么时候部署”这个决策必须由人来做。同样，如果部署后健康检查失败，AI可以执行预设的回滚命令，但不能自主判断“要不要回滚”。

这个边界的设计逻辑是：AI擅长执行确定性任务，不擅长做风险决策。部署时机的选择涉及业务节奏、团队协调、风险评估，这些是人的职责。把边界划清楚，既能享受AI的执行效率，又不会引入不可控的风险。

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

5.1 安装与连接类问题速查

5.2 AI生成代码质量不稳定的排查思路

AI生成代码质量波动大，通常不是AI本身的问题，而是上下文提供的问题。我总结了一个排查清单：

• CLAUDE.md是否完整：缺少关键约束是质量不稳定的首要原因
• 任务描述是否具体：模糊的需求导致模糊的实现
• 示例代码是否充分：AI需要参照物来对齐风格
• 上下文是否过长：过长的对话历史会稀释关键信息，建议定期开新会话
• 是否给了AI验证手段：AI能跑测试和不能跑测试，生成质量差异巨大

5.3 MCP工具调用的典型故障

MCP工具调用失败最常见的原因是权限配置和参数格式。我遇到过的几个典型案例：

一个是PostgreSQL MCP查询返回空结果，排查后发现是数据库连接字符串里的schema配置不对，AI默认查的是public schema，但实际数据在自定义schema里。解决方法是在MCP配置里显式指定search_path。

另一个是Playwright MCP在CI环境里超时，原因是CI环境没有安装浏览器依赖。解决方法是在CI配置里加上npx playwright install --with-deps。

还有一个是文件系统MCP无法访问项目目录，原因是allowed directory配置的是相对路径，而MCP Server的工作目录和预期不一致。解决方法是一律使用绝对路径。

5.4 我的独家避坑经验

第一个经验：永远不要让AI直接操作生产环境。我见过有人让Claude Code直接连生产数据库做数据修复，结果AI理解错了条件，更新了全表。正确的做法是让AI生成SQL，人工review后在受控环境执行。

第二个经验：CLAUDE.md要版本控制。CLAUDE.md是项目资产的一部分，应该和代码一起提交到git。这样团队成员共享同一份AI上下文，AI的行为才能保持一致。

第三个经验：定期清理对话历史。Claude Code的对话历史太长时，早期的重要信息会被稀释。我的习惯是每完成一个独立任务就开新会话，把需要保留的上下文写进CLAUDE.md而不是留在对话里。

第四个经验：给AI的每个任务都定义“完成标准”。不要说“帮我优化这个函数”，要说“帮我优化这个函数，要求：时间复杂度降到O(n)，通过现有测试，不改变函数签名”。有了明确的完成标准，AI的输出质量会稳定很多。

6. 从工具到方法论：AI-Native SDLC的进阶思考

6.1 团队协作中的AI工作流设计

个人使用AI工具和团队使用AI工具，最大的区别在于“一致性”。个人可以凭感觉调整用法，团队必须有一套标准化的流程。我在团队里推行AI-Native工作流时，重点做了三件事：

第一，统一CLAUDE.md模板。所有项目使用同一套模板结构，确保AI在不同项目间的行为一致。第二，建立“AI代码review清单”。AI生成的代码在合并前必须经过人工review，review清单里明确列出重点检查项。第三，定期分享“AI使用技巧”。每周团队例会上留10分钟，大家分享本周发现的AI使用技巧和踩过的坑。

这套机制运行三个月后，团队的代码产出效率提升了大约40%，但更重要的是代码质量没有下降。关键就在于标准化——把个人的使用经验转化为团队的共同资产。

6.2 AI-Native SDLC的边界与局限

说了这么多AI-Native SDLC的好处，也必须说清楚它的边界。目前阶段，以下几类工作不适合完全交给AI：

架构设计：AI可以生成架构方案，但架构决策需要考虑团队能力、业务演进、技术债务等多维因素，这些是AI不擅长的。性能调优：AI能做一些常规优化，但深层次的性能问题需要profiling和领域知识。安全审计：AI可以辅助发现常见漏洞，但不能替代专业的安全审计。跨团队协调：涉及多个团队的技术方案对齐，需要人的沟通和谈判。

认清这些边界，才能合理分配AI和人的工作，避免在AI不擅长的领域浪费时间。

6.3 后续可以扩展的方向

这套工作流目前主要覆盖了编码和测试环节，后续可以往两个方向扩展。一个是往上游走，接入需求管理工具（通过MCP连接Jira、Linear等），让AI直接从需求单生成任务拆解。另一个是往下游走，接入监控和告警系统，让AI在收到告警后自动分析日志、定位问题、生成修复建议。

我个人最期待的是“AI Pair Programming”模式的成熟——不是AI单方面执行任务，而是人和AI实时协作，人负责方向和决策，AI负责执行和验证，两者在同一个工作空间里无缝切换。目前Claude Code已经具备了这个雏形，但交互体验还有很大的优化空间。

我在实际使用中体会最深的一点是：AI-Native SDLC不是让工程师变得不重要，而是让工程师的价值从“写代码”转移到“定义问题”和“验证结果”上。这个转变对很多人来说不舒服，但适应之后你会发现，工作的创造性和掌控感反而更强了。