我过去用的方式其实很裸打开 Claude Code甩一段需求描述它理解为啥就干啥我像个给 AI 传话的实习生一遍一遍提醒它注意项目结构别动那个配置文件用项目里已有的工具函数。短期内好像也能跑但换一个项目、换一台机器、换一个人一切归零。后来我把 Skills 和 MCP 引入工作流把 AI 从对话里的临时工变成了带着工具箱和项目规范进场的正式员工整个开发节奏和交付质量都上了一个台阶。这篇文章就把我这段时间的工程化实践从思路到配置再到踩坑一次性讲清楚。1. 为什么我会从裸用转向工程化1.1 裸用阶段我遇到的真问题先说清楚什么叫裸用。我的理解是你没有给 AI 任何持久化的上下文没有固定的工具集也没有跨会话保留的约定每次开工都是新开一个会话从零解释需求。这套方式的典型表现有几种。第一种是重复解释。项目里明明有一个统一的请求封装AI 第一次会乖乖用但换一个会话它可能自己fetch一把你不得不重新把项目里的目录结构、依赖关系、代码风格粘贴一遍。稍微复杂一点的项目光进入状态就要花掉十分钟。第二种是工具不可达。让 AI 去查数据库、读线上日志、看某个服务的返回结果它做不了因为它没有相应的接口。你只能自己手动查完再把结果贴给它。一次两次还行次数多了你会发现我到底是来写代码的还是来给 AI 跑腿的第三种是上下文丢失。聊到一半会话超时重新进来AI 对刚才讨论的决策一无所知。你可能还记得当时为什么放弃了方案 A 选择方案 B但 AI 不记得于是它可能再次给你推荐方案 A你又要花时间解释。这些问题本质上是同一个AI 的工作环境太单薄了。它只有对话窗口没有项目上下文没有工具调用能力没有长期记忆。让一个只有对话能力的助手去参与工程级开发当然会觉得它不聪明不听话。后来我才意识到问题不全在模型身上在我没有给它搭好环境。1.2 MCP 和 Skills 分别解决什么问题MCPModel Context Protocol模型上下文协议和 Claude Code Skills 是两条不同的补强路线理解它们的边界很重要不然容易混在一起不知道什么时候该用哪个。MCP 解决的是**AI 能触达什么**的问题。它定义了一套标准化的接口让 AI 可以调用外部工具、读取外部数据。比如通过 PostgreSQL MCPAI 能直接查询数据库通过 GitHub MCPAI 能查看仓库、创建 Issue、发起 Pull Request通过文件系统 MCPAI 能管理本地文件。相当于给 AI 接上了手和眼睛。Skills 解决的是**AI 知道怎么做、按什么规范做**的问题。它是一份结构化的提示词和示例集合告诉 AI 在特定任务里应该遵循什么流程、用什么代码风格、有什么必须遵守的项目约定。相当于给 AI 发了员工手册。我用一个类比来理解MCP 是工具柜里面摆着螺丝刀、电钻、水平仪Skills 是操作规范写着打孔前要先划线电线必须走线槽完工后要清理现场。只有工具柜AI 有力气但不知道怎么干只有操作规范AI 知道怎么干但没工具。两者结合AI 才是一个带工具、懂规矩的施工队。想清楚这一点之后我开始动手给工作流做工程化改造核心就两件事建好工具柜写好员工手册。2. MCP 基础选型与配置实操2.1 用大白话理解 MCP 的运作方式在写配置之前先把 MCP 的运作方式说透。MCP 分三个角色宿主比如 Claude Code、MCP 服务器提供能力的服务、MCP 客户端连接两者的桥梁。当 AI 在对话中决定我需要查询数据库时它会通过 MCP 协议向服务器发出请求服务器执行操作并返回结果AI 再把结果纳进自己的思考继续生成代码。这个设计的精髓在于标准化。过去的做法是每个工具都有自己的调用方式AI 要接十个工具就得适配十种接口。MCP 把这一切统一成一套协议等价于给 AI 的工具调用做了一个USB-C 接口。不同服务器只要遵循同一协议就能无缝接入。从配置角度看MCP 服务器的接入通常就是一段 JSON 配置。以claude_desktop_config.json或者在 Claude Code 里的settings.json为例核心字段包括name服务器名、transport传输方式通常是stdio或sse、args启动命令和参数、env环境变量。配置方式不算复杂关键在于掌握 .mcp 文件与依赖管理。我实际在项目里优先使用的 MCP 服务器如下MCP 服务器用途类型filesystem本地读写、文件搜索、目录树官方示例PostgreSQL执行查询、查看表结构、数据行采样stdioGitHub仓库读取、Issue/PR 操作、代码检索HTTP/SSEMemory跨会话记忆用户偏好与项目决策stdioContext7实时获取第三方库最新文档stdioPuppeteer浏览器自动化、页面内容提取stdio这个清单是我在实际项目里的基础款足够覆盖大部分日常开发场景。重点不是装得多而是装得准每个工具都要对应真实需要。装一堆用不上的工具既增加系统请求开销也让 AI 在决策时更容易选错。2.2 几个高性价比 MCP 服务器的配置示范PostgreSQL MCP是我所有项目里最常用的一个。AI 能直接连上本地开发库天然知道有哪些表也能执行带条件的查询。配置示例如下{ mcpServers: { postgres: { command: npx, args: [-y, modelcontextprotocol/server-postgres], env: { DATABASE_URI: postgresql://user:passwordlocalhost:5432/mydb } } } }配置完成后你可以在对话里直接说看一下 orders 表最近一周的订单量趋势AI 会自己生成 SQL、执行查询、把结果整理成可读的总结。这里要注意不要给 AI 配上生产环境的写权限我一开始图省事直接指向了生产库的只读账号结果 AI 在分析时把只读当成常规遇到写入需求时报错才发现配置里少了权限层级。给 MCP 的最小权限原则和给人类开发者的最小权限原则完全一致。Memory MCP的价值在于把跨会话记忆变成一种基础能力。之前裸用时的老大难——AI 不记得上一次的决策——由它来兜底。它内部维护了一份知识图谱式的记忆库当 AI 发现对话里出现我们决定后端用 FastAPI用户反馈里 E 开头的订单号是异常数据这类信息时可以主动写入记忆。下次会话里这些问题就不再需要重复解释。Memory MCP 不用特意配置复杂参数它默认会在本地维护一个记忆文件。我要强调的其实是另一个点记忆是有噪音的。AI 写入记忆的门槛很低什么用户喜欢蓝色主题这类临时偏好也会被记下来积累多了反而干扰判断。我每周会清理一次记忆文件只保留真正对项目有长期影响的决策。这就像给 AI 做大扫除把脑子里没用的东西清出去免得它做事的时候想太多。GitHub MCP比较适合团队协作场景。它让 AI 能直接读取仓库里的文件结构、查看分支状态、创建 Issue甚至发起 PR。配置上通过环境变量传入 Personal Access Token 即可。我用它来替代把代码粘贴到对话框里的笨办法直接在对话里说看看 feature/user-auth 分支上改了哪些文件AI 自己去拉取信息比人肉复制粘贴准确得多。2.3 Claude Code Skills 的编写规范Skills 的核心是一组带说明的 Markdown 文件放在项目的.claude/skills目录下。每个 Skill 有一个名字、一段说明、一段脚本和若干示例。Claude Code 在启动时会加载这些文件并在对话中把相关内容作为上下文的一部分提供。我自己写 Skill 的模板如下--- name: 后端接口开发规范 description: 新增或修改后端 API 接口时使用。强制统一响应格式、错误码规范、日志埋点要求。 --- ## 使用场景 当需要新增一个 HTTP 接口或者修改已有接口的签名/返回值时请遵循本规范。 ## 响应结构 所有接口返回统一结构 { code: 0, message: success, data: {} } ## 错误码 - 1000: 参数错误 - 1001: 未登录 - 1002: 无权限 - 2000: 业务异常 ## 注意事项 - 必须在入口处记录请求日志包含 request_id - 参数校验使用 pydantic不允许手写 if 判断 - 所有时间字段统一为 ISO8601 格式编写 Skill 的要点在于具体化。写得越具体AI 的执行越稳定。你说要遵守好的代码风格AI 不知道该听谁的你说函数命名用 snake_case禁止用缩写AI 就能给出符合预期的结果。我还会给团队公共的 Skill 加上版本号方便知道当前用的是哪一版。如果发现某个 Skill 让 AI 频繁做错事那不是 AI 的问题是 Skill 写得不够清楚我会先修订它再重新跑一次典型场景验证。3. 把工作流改造成工程化链路3.1 项目启动上下文注入与目录约定工程化和裸用的第一个明显分水岭在项目启动阶段。裸用是你人肉把项目背景灌给 AI工程化是你把项目背景沉淀成文件让 AI 自己读取。我在每个新项目里固定做三件事写一个CLAUDE.md项目说明内容包括项目简介、技术栈、目录结构、常用命令、关键业务约定。Claude Code 会自动把它作为项目级上下文进行加载。写.claude/skills/目录下的业务型 Skill把那些只可意会只可经验的编码规范沉淀下来。把 MCP 配置写进项目级配置文件让团队里每个开发者 clone 后只需一条命令就能把工具链拉起来。CLAUDE.md的内容不用追求面面俱到但要有优先级。我的习惯是开头先写三句话以内的项目定位然后是如果你要改这个项目必须先知道的五件事——这五件事往往才是 AI 最容易踩雷的地方。例如某个模块用了全局单例改之前必须先了解它的生命周期某个表的删除用的是软删除某条链路绕过了统一异常处理。这些都放进CLAUDE.mdAI 从一开始就带着避雷清单进场。3.2 开发过程技能绑定与工具协同项目运行起来之后工程化工作流给我的体验是AI 从被动答题变成主动干活。过去我描述一个需求AI 给我一段代码现在我会说按后端接口开发规范实现用户资料更新接口它能自动按规范里的响应结构、错误码、日志要求去写不再需要我把规范一步步贴给它。演示一个实际开发场景假设有个需求给用户模块加一个修改昵称的接口。我的实际使用方式是这样一句话给用户模块新增修改昵称的接口。请先阅读 CLAUDE.md 了解项目结构再按用户接口开发规范实现完成后运行该接口的单测。AI 的执行链路是读取CLAUDE.md→ 了解项目模块位置 → 加载用户接口开发规范Skill → 通过 PostgreSQL MCP 查看用户表字段 → 生成接口代码 → 用文件系统 MCP 确认目标文件 → 写入代码 → 运行测试命令验证。这条链路里AI 不是在写一段代码而是在完成一个工程任务。我节省了来回确认的时间AI 的输出也更接近团队规范。自动化意识一旦建立我就能把更多精力放在设计决策上而不是类型标注和命名。3.3 交付检查自动化验证与文档生成工程化带来的另一个好处是交付质量可控。原来 AI 写完代码我人肉审查现在一部分审查可以交给工具。我的做法是在 Skill 里内置一个交付检查清单让 AI 每次完成任务后按清单逐项确认是否有遗漏文件变量名是否符合规范是否有调试日志残留是否补充了测试是否更新了相关文档AI 按清单检查输出一个完成情况报告我再重点看它标注未完成或不确定的项。CLAUDE.md和 Skills 的引入也让生产文档从负担变成了副产品。项目里有一个接口文档生成的 SkillAI 在写完接口后可以自动更新 OpenAPI 格式的文档文件有变更日志SkillAI 在每次完成需求后把变更内容追加到 CHANGELOG。文档和代码是同一次行为产生的就不容易出现代码改了文档没改的常见病。4. 踩坑记录与排查技巧4.1 权限与配置同步问题MCP 接入后的第一坑永远是权限。我给 PostgreSQL MCP 单独建了一个最小权限账号只给SELECT和必要的INSERT权限不给DROP、TRUNCATE。一开始觉得开发库而已无所谓直到有一次 AI 在会话里把一张临时表DROP了我才意识到开发库也是库也要按生产标准对待。最小权限不是针对 AI 的不信任而是对任何自动化流程的基本防护。第二个坑是配置不同步。团队里如果有人改了 MCP 配置或者新增了 Skill其他人拉代码后不会自动生效就会出现你那边 AI 能查数据库我这边报找不到工具的混乱。后来我把 MCP 配置和 Skills 全部纳入版本控制并在CLAUDE.md里写上更新配置后请重启 Claude Code。这不是什么高明技巧但能减少大部分困扰。通过 .mcp 文件管理项目级工具时同样建议把依赖的 package 版本写清注释写清每个工具的用途。目录权限上若团队成员共享同一台机器要注意个人仓库与全局仓库的隔离——不共享 HOME 目录配置不覆盖他人的全局工具列表是避免改了个人的配置影响别人环境的基本觉悟。4.2 工具输出超时与请求量过大MCP 工具不是没有成本。AI 每次调用工具都有一次网络开销调用链一旦密密麻麻排起来整个会话会变得很慢严重时工具直接超时。我遇到过一次 AI 写一段前端代码为了查一个组件库的 API连续调用 Context7 查了七八次每次都在等待网络返回体验极差。应对方式有两个。一是在提示词里明确约束例如在 Skill 中写Context7 仅在不确定 API 时使用同一会话内最多使用两次。二是给工具调用做缓冲像 GitHub 类工具AI 可以先把仓库信息汇总一次性读完需要的文件而不是逐个单独请求。4.3 常见问题速查表现象可能原因处理方式AI 调用工具后报connection refusedMCP 服务器未启动或端口冲突检查配置文件端口重启服务AI 无法写入文件文件系统 MCP 未授予对应目录权限在配置中补上该目录AI 频繁使用不必要的工具Skills 缺少工具使用约束在 Skill 中写明工具使用边界跨会话不记得项目决策未配置 Memory MCP或记忆文件过期接入 Memory更新记忆内容更新配置后不生效宿主进程未重启重启 Claude CodeAI 生成了不符合项目规范的代码缺少业务型 Skill编写对应场景 Skill团队成员工具版本不一致配置未纳入版本控制工具与配置入仓库同步排查方法与人类新员工上岗类似先看它有没有权限再看它有没有工具最后看它懂不懂规矩。这三个维度对照排查大部分问题都能定位。我还有一个习惯是让 AI 在工具调用前先说明我要用哪个工具、用来做什么。这样我能看到它的意图在它走偏之前拦下来而不是等它执行完才发现结果不对。实测下来会话的可控性提升尤其明显。5. 工程化实践的几个进阶心得5.1 用自定义 Skill 沉淀团队规范比起一堆写在 wiki 里没人看的规范文档我把团队规范逐步改写成 Skills。新成员加入后与其让他读三天文档不如让他直接和配好 Skills 的 Claude Code 一起工作AI 会在实际任务里隐形地执行规范。这个转变不是技术上的而是知识管理上的把知道怎么写变成了运行时会自动遵守。但 Skill 也不是越多越好。每个 Skill 都会增加上下文长度装得太多AI 反而抓不住重点。我现在的原则是只保留那些出错成本高或反复犯过错误的规范。比如统一响应格式、错误码规范、日志埋点这类必守红线值得写像函数要写注释这种软性追求写了用处也不大AI 会为写注释而写注释。5.2 定期审查 AI 的工具使用日志Claude Code 会记录会话中所有工具调用情况。我每隔一段时间会把日志翻出来看一眼重点做两个分析一是哪些工具被高频调用说明是核心依赖二是哪些工具调用了但结果没被使用说明这个工具可能是个干扰项削弱了 AI 的执行效率。这就像是看程序的 profiler 报告——不加分析时一切正常分析完总能找到几个可以优化的热点。我之前发现自己装了某个翻译工具AI 偶尔会去翻它但翻完并不能帮助写代码反而拖慢节奏。移除之后会话速度提升明显AI 的执行路径也干净了。5.3 把这些方法迁移到其他工具和场景一旦理解了 MCP 和 Skills 的思路你会发现这套方法论并不局限于某个特定工具。只要支持 MCP 协议的客户端或者任何支持工具集上下文注入的 AI 工具都能套用同样的框架。业务系统的接入也越来越多像禅道这类项目管理工具都已提供 MCP 接口AI 可以直接读取需求、更新任务状态地图、行情、办公协作等领域也在逐步开放。MCP 的意义在于它把 AI 和真实系统之间的连接方式做成了开放式标准。今天我接数据库、接代码仓库、接浏览器明天接内部系统、接业务平台不用重写所有集成代码。工程化不是一次性的改造而是一种可以不断复用的思维框架给 AI 建工具柜给 AI 发员工手册让 AI 在一个有结构、有规范的环境里工作。对于正准备开始改造工作流的朋友我的建议是从小处入手先给一个你最有痛感的工具链配好 MCP再挑一个最容易违反的规范写成 Skill。跑顺了再逐步加码。我自己也还在迭代这套流程毕竟 AI 开发工具更新得太快唯一稳妥的做法就是把持续调整本身也工程化。