说起AI编程工作流我踩过的坑可能比大多数人都多。最初用Claude Code的时候我的姿势非常原始打开终端把需求往对话框里一贴让它改代码、写测试、查报错。一开始确实爽但用久了问题就浮出来了——每次新会话都要重新解释项目背景同样的规则换了项目就失效AI查完代码还要我手动去跑数据库、翻日志、开浏览器调试。直到我把Claude Code Skills和MCP这两个东西真正用起来工作流才从“裸用”变成了“工程化”。这篇东西没有教科书味儿全是我自己从项目里磨出来的实操经验、配置方法和避坑记录。如果你也折腾Claude Code或者正被“AI只会聊天、不会干活”困扰建议耐心看完。1. 先看痛点裸用阶段的那三座大山1.1 每次都要重新“教育”AI裸用阶段最让我抓狂的是模型没有长期记忆。项目里明明有既定的代码规范、目录结构、数据库表命名规则但每次开一个新会话Claude Code又变回一个什么都不知道的新人。我不得不反复把同样的约束粘贴进Prompt比如“所有数据库操作必须走Repository层”“错误码请遵循项目内部的ErrorCode枚举”“测试文件放test/目录下且以_test.go结尾”。这种重复劳动不只是浪费时间更大的问题是一致性失控。今天心情好多写两句AI就守规矩明天忘了贴它就开始放飞自我。直到我意识到问题的本质不是“Prompt写得不够好”而是“方法论没有被固化下来”。团队里不会有人把编码规范写在每一次交流的邮件里而是沉淀成文档、lint规则、评审清单AI也应该有同样机制。1.2 工具链割裂AI只能“隔空抓药”第二座大山是工具链完全割裂。Claude Code有代码读写能力但生产环境里的东西它一概碰不到要查线上PostgreSQL的数据我得自己开psql跑一条SQL再把结果贴给它要看某个接口的真实响应我得用curl调完复制回对话里要做前端调试还得手动打开Chrome DevTools把Console报错截图给它解释。这不仅仅是效率低而是上下文信息链断裂。AI看到的永远是二手数据而且经常是不完整的数据。它猜一个方向我验证一遍错了再回头猜整个流程磕磕绊绊。当时我的感觉就像让一个盲人帮忙指路我负责把看到的景象翻译给它听效率全浪费在翻译层。1.3 过程不可复现换台机器回到解放前裸用还有一个很隐蔽的问题能力全在会话里换个环境就清零。我在笔记本上精心调出来的Prompt、让AI遵循的规则、自定义的工具调用方式到了同事的电脑上、CI环境里、新的项目目录中统统不存在。整个工作流完全依赖个人对话历史根本谈不上可复制、可审计、可交接。这也引发了我对“工程化”这件事的重新思考。工程化的核心从来不是“用了一个热门工具”而是把经验和流程沉淀为团队可共享的资产。Claude Code Skills解决的正是“方法论固化”MCP解决的正是“工具链打通”两者合起来才算把AI从临时聊天对象变成了正式开发流程的一部分。2. Skills把方法论直接灌进模型脑袋2.1 机制拆解SKILL.md是如何被调用的先说Claude Code Skills到底是什么。简单讲它是一组可以被Claude Code主动调用的“技能包”。每个技能以目录为单位目录里通常有一个SKILL.md文件里面用结构化方式描述这个技能是什么、在什么场景触发、具体怎么执行。你可以把SKILL.md理解成技能的“说明书”——模型会读取说明书判断当前任务是否匹配这个技能匹配就按说明书里的步骤去执行。这里最关键的设计是由模型自己决定是否调用技能而不是你每次都显式指定。这意味着只要把技能描述写得清晰、触发条件写得准确Claude Code就会在合适的时机自动套用。我第一次用的时候在项目里加了一个“代码评审”的Skill第二天让它帮我检查一个PR diff它自动加载了评审规范按规范里列的检查项逐条过了一遍输出直接就是结构化的评审意见。那一刻确实有“它终于懂规矩了”的感觉。在Claude Code中注册Skills的方式一般是通过命令行参数或配置文件指定技能目录。比如我常用的做法是把技能统一放进~/.claude/skills目录然后在启动时用--add-dir带上它。具体命令类似claude --add-dir ~/.claude/skills也可以把Skills放入项目的.claude/skills目录随项目走团队其他人clone代码后自然就带上了这套技能这比让每个人手动配置要省心得多。我个人推荐团队场景优先放项目内个人通用习惯放用户目录。2.2 实操写一个能真正落地的代码审查Skill光讲概念没用我直接分享一个我实际在用的Skill模板。这个Skill解决的是“代码评审标准不统一”的问题——以前团队里每个人Review风格差异很大有人只抠命名有人只关心性能永远凑不到一起去。我的SKILL.md长这样大家可以直接替换内容--- name: code-review description: 对代码变更进行系统化审查覆盖正确性、性能、安全、可维护性四个维度。适用于code review、PR检查、变更分析等场景。 --- # Code Review 规范 当用户要求评审代码、分析Pull Request或检查变更时触发本技能。 ## 审查流程 1. 获取变更的完整diff列表确认涉及的文件列表 2. 按下列维度逐项分析忽略无关文件 3. 输出“问题列表”每条问题必须标注文件、行号、严重级别P0/P1/P2、问题描述、修复建议 4. 有阻塞性问题P0/P1时先汇总核心问题再顺序列出其余细节 ## 审查维度 - 正确性空指针风险、边界条件、并发问题、异常路径 - 性能不必要的循环、缺失索引查询、大对象复制、N1问题 - 安全注入风险、敏感信息明文、权限校验缺失、越权访问 - 可维护性命名一致性、重复代码、过度复杂函数、注释与文档缺失 ## 团队特殊约定 - 代码中所有TODO必须关联Issue编号否则视为未完成 - 新增数据库查询必须检查是否走索引必要时给出索引建议 - 接口返回结构变更需要同步更新API文档Review时标注是否已更新写完之后你在目录里加一个可执行脚本比如review.sh让模型在需要的时候可以调用它来生成diff统计或者跑静态检查工具。这样整个Skill就不仅仅是“给模型看一堆文字”而是真正可以驱动外部动作的组合体。这个模板推荐给所有做技术管理的朋友。实测下来团队Review质量会明显往同一个方向收敛至少在检查项上不会漏掉那些最容易出问题的地方。2.3 避坑不要把Skills变成杂物间Skills好用归好用但也容易被滥用。我一开始犯过一个错误几乎把每天所有重复工作都封装成Skill什么“写migration”“部署测试环境”“整理changelog”结果就是每次对话开始时模型要把一二十个SKILL.md全读一遍光理解“该用哪个技能”就耗费不少上下文。而且技能描述一旦写得含糊模型经常选错。所以我的经验是只封装三样东西第一团队硬性约束比如代码规范、提交流程第二高频且需要稳定输出格式的动作比如生成变更记录、执行发布检查第三需要联动外部工具的复杂流程比如查数据库、调用测试环境接口。那些“让AI写个React组件”这类开放任务根本不需要封装成Skill直接对话反而更灵活。还有一个细节SKILL.md里的description字段一定要认真写因为这是模型判断是否触发技能的唯一依据。写得过于宽泛它什么都触发写得太过具体该触发时又漏掉。我习惯在description里明确列出“适用场景”和“不适用场景”比如代码评审Skill里加上“不用于处理运行时问题排查”能明显减少误触发。3. MCP给AI接上能干活的手3.1 MCP是什么一句话版本的理解MCPModel Context Protocol是一个开放协议解决的是AI与外部工具之间的标准化连接问题。在没有MCP之前每个AI应用要对接一个工具都得单独写适配层数据库一个适配、浏览器一个适配、调试器一个适配接口五花八门。有了MCP之后工具方只需实现一个MCP ServerAI客户端通过统一的MCP Client接入就能以标准化方式调用这些工具的能力。我习惯把MCP理解为AI世界的“USB-C接口”。各家外设数据库、浏览器、调试器、项目管理平台只要支持了USB-C主机就能即插即用不需要为每台设备专门设计接口。MCP Server就是那个外设的驱动程序让Claude Code这种AI客户端能发现工具、调用工具、拿到返回结果。MCP Server在协议层面主要暴露三类原语Tools可调用的函数比如“查询订单表”“打开URL”、Resources可读取的数据资源比如“读取项目配置文件”“获取schema”、Prompts预定义的可复用Prompt模板。其中Tools用得最多Resources非常适合把只读知识库暴露给模型。3.2 配置实操从零接入一个PostgreSQL MCP Server我觉得最典型的MCP接入场景是数据库操作。以前让Claude Code查数据全靠手动导结果现在直接让它自己连数据库你要做的就是先装好一个PostgreSQL MCP Server。在Claude Code中最省事的方式是用内置命令注册claude mcp add postgres -t stdio -- npx -y modelcontextprotocol/server-postgres postgresql://user:passwordlocalhost:5432/mydb这条命令的意思是注册一个名为postgres的MCP Server通过stdio协议启动实际启动命令是npx -y modelcontextprotocol/server-postgres后面跟的是数据库连接串。注册成功后Claude Code会在当前会话里发现这个Server暴露的Tools比如query和list_tables。配置文件的方式也一样Claude Code会生成一个.mcp.json内容大致是{ mcpServers: { postgres: { command: npx, args: [-y, modelcontextprotocol/server-postgres, postgresql://user:passwordlocalhost:5432/mydb] } } }接完之后我就可以直接在会话里说“帮我看看orders表里最近7天订单量的趋势”它自己会调用list_tables找到表再调用query跑SQL然后基于结果做分析。整个链路不需要我复制粘贴任何数据误差一下子小了非常多。这里要说一个关键经验生产数据库一定只给只读权限。MCP Server连接生产库时建议单独创建一个只读账号从用户根源上避免AI误执行UPDATE或DELETE。这不是信不信任模型的问题而是工程上应该把最坏情况概率降到最低。3.3 值得装的MCP Server清单实测推荐数据库类只是冰山一角。我目前在生产环境里稳定使用和测试过的MCP Server按照实用性排序大概是这批MCP Server解决什么问题我的使用频率PostgreSQL / MySQL直接查库、分析数据、生成报表每天必用Playwright / Chrome DevTools自动化浏览器操作采集页面数据、复现前端问题每周多次GitHub / GitLab拉取PR、创建Issue、查看CI结果每天必用Fetch / HTTP 请求调接口、验证响应、对比环境差异每天必用文件系统跨目录读写文件比默认工具更强的文件操作能力偶尔内存/向量存储保存对话关键结论跨会话复用探索中调试器如x64dbg/gdb相关MCP对特定二进制/运行中程序做动态分析时把反汇编、断点信息直接喂给AI低频但不可替代就拿调试器场景举例遇到崩溃转储或者程序异常行为时模型能精确记忆指令集和调用约定但自己去翻汇编还是太慢。把调试器接入MCP后AI可以直接操作断点、读取寄存器、查看调用栈相当于它亲自上手在调试器里做实验而不是只看人转述的截图。近期社区里已经有针对x64dbg、IDA这类工具的MCP插件下载做逆向分析或者底层调试的朋友可以关注一下这会大幅减少“人翻译给AI听”的时间损耗。另外我要特别提一下浏览器MCP比如Playwright的那套。前端问题排查一直是AI的弱项因为模型看不见页面。接了浏览器MCP后Claude Code能自己打开页面、点击按钮、读取控制台报错再结合代码分析定位问题。我曾经让它复现一个只在特定用户权限下出现的菜单异常它自己登录测试账号、逐个菜单点击、最终定位到是某个按钮缺少权限判断导致的整个过程我只给了它起始URL和测试账号剩下全是它自己操作。4. Skills MCP 合体这才是工程化工作流的真正骨架4.1 谁该用Skill谁该用MCP职责边界想清楚把两个工具装好只是开始真正让效能翻倍的是搞清楚它们各自的定位。我总结下来Skills管“方法论”流程、规范、检查清单、输出格式。MCP管“连接能力”能访问什么系统、能操作什么工具、能拿到什么数据。用代码审查举例子Skill定义评审的维度和规则方法论MCP负责把PR diff、静态检查结果、CI日志拉回来能力。没有SkillAI什么都查了但输出零散没有MCPAI有审查规范但拿不到真实的变更内容。两者缺一个效果都会大打折扣。再比如发布上线检查流程。方法论层面需要一条一条过检查项配置是否修改、迁移脚本是否执行、缓存是否需要清理、回滚计划是否就绪。能力层面需要真实数据当前版本号、服务器列表、数据库迁移状态、最近构建产物。我通常会用Skill固化检查流程再用MCP读取部署平台的信息两个一配合发布检查从45分钟缩短到10分钟而且不容易漏项。4.2 典型案例一次真实业务数据问题的完整排查说一个最近发生在我自己项目里的实战案例很能体现两者合体的价值。当时线上反馈某用户订单状态异常用户看到“已支付”但业务后台显示“待发货”两边状态不同步。这种问题放以前我的流程是登服务器查日志 - 翻数据库订单表 - 对照支付回调记录 - 手工捋逻辑至少半小时起步。现在我的工作流是这样的第一步直接在Claude Code里描述症状“查一下订单号ORD-20250218-039的状态和支付回调记录对比异常点”第二步它通过PostgreSQL MCP Server拉取订单主表、支付流水表、状态变更记录表的数据第三步它根据项目里固化的“订单状态机”Skill我提前把该业务线的状态流转规则写进了Skill描述对比数据推理出支付回调比订单创建先到达、状态机拒绝了迟到事件导致状态不一致第四步它调用接口MCP验证修复方案手动补偿该订单状态并检查幂等性。整个过程从开始到给出结论只花了大约6分钟而如果我手动做光是登录生产环境、拼接SQL和翻日志就要花掉小半天。这就是“方法论连接能力”同时在场的效果AI不是空有推理能力而是有清晰规则可以遵循有条件有工具可以操作。4.3 组合进阶把内部系统也接入MCP除了数据库和浏览器其实企业内部系统同样可以接MCP。我看热搜词里有人提到禅道MCP、百度地图MCP AI、同花顺MCP这说明趋势已经很明确了——项目管理平台、地图服务、数据终端都在通过MCP把自己暴露给AI生态。我团队里目前接了一个内部项目管理系统的MCP ServerClaude Code可以直接查询任务状态、认领人、截止时间还可以按需把任务信息带入开发上下文。想象一下这个终极流程AI在开发时发现某个需要UI设计的依赖任务还没完成它自己通过MCP查了项目管理系统然后在对话里提醒我“这个功能依赖的任务还在进行中建议先做后端接口”。它已经开始具备项目级的全局视角了而不只是盯着当前文件的代码细节。虽然内部系统接入MCP需要一点开发工作量但收益非常可观。所有开发者共享一套“AI可访问的数据接口层”而不是每次都模拟人去登录系统、复制粘贴信息。5. 工程化落地的硬仗踩坑记录与排查技巧5.1 现象一MCP Server启动了但工具找不到这是我遇到最多的问题。MCP Server配置没问题进程也起来了但在Claude Code里却看不到它暴露的Tools。排查步骤我建议按这个顺序来第一确认Server确实成功启动很多情况下是npx拉包失败导致进程秒退。先在终端直接运行配置里的command看是否能正常输出。第二确认Server的协议实现完整有些Server只实现了list_tools没实现call_tool会导致工具能看到但调不了。第三确认Claude Code确实加载了对应配置用claude mcp list命令查看当前会话已连接的Server。我有一回折腾了很久最后发现是Node版本太低某个新版本的MCP Server需要Node 18而我这台机器还停留在16。所以遇到MCP相关怪问题第一反应应该是升Node、升级包、重启Claude Code三件套。5.2 现象二Skills触发了但执行得驴唇不对马嘴有时候Skill被加载了但模型执行出来的结果明显“跑偏”——比如我让它按Review规范审查它却只关注命名问题对更严重的权限漏洞视而不见。这种问题的根因绝大部分出在SKILL.md的结构上。模型的注意力是有限的说明书里如果堆了太多内容它只会有选择性地读取。我的解决办法是把最核心的检查项用强指令词写在最前面比如“必须按以下顺序检查”“以下列表为最高优先级”而不是用“建议”“可以”这种模糊词。另外每次只让Skill做一件事不要试图在一个Skill里塞进“审查代码生成报告自动修Bug”三个任务拆成三个独立Skill反而准确率更高。还有一点很值得注意Skill的description字段要写场景化的触发条件而不是功能描述。比如“当用户要求检查代码质量、执行code review、审查PR时使用”这种写法比“代码审查工具”准确得多。5.3 现象三上下文爆炸长会话后AI开始胡言乱语接了数据库MCP和浏览器MCP之后你很快会发现上下文窗口不够用。一次查询返回几千行记录AI就得把整批数据塞进上下文浏览器执行多次操作DOM内容也会积压。我的对策是分层级的一是SQL查询务必带限定不要放任AI全表扫描。我的习惯是在MCP Server外面再包一层代理强制限制返回行数上限超出就报错提示用户加WHERE条件或LIMIT。二是MCP返回结果做截断很多MCP Server支持配置最大返回长度把没那么多价值的日志、耗时长的响应体截掉只保留摘要。三是长会话及时换Session当一个会话明显变“钝”不要让AI勉强继续直接开新会话并把旧会话的关键结论写在一个CONTEXT.md文件里让新会话读取。这个方法在团队协作时特别好用任何一次约定、一个架构决策、一段踩坑记录都沉淀到CONTEXT.md里AI每次启动自动加载。这也是从“裸用”走向“工程化”的重要标志不再依赖会话记忆而是把知识显性化落盘。5.4 现象四团队协作时技能不同步、权限混乱如果是个人项目Skills和MCP怎么配都行但到了团队层面就要管理了。我一个朋友的公司团队在推行Claude Code时遇到的第一个问题就是每个成员本地配的MCP Server五花八门有的人连的是测试库有的人连的是生产库还有人连的是本地容器里的数据库同名但数据完全不一样。解决方案是在项目根目录统一维护.mcp.json里面写清楚每个Server的名称、用途、安全等级并通过脚本做启动前检查。另外Skills目录一定要放项目里而不是各放各的保证团队所有人使用同一套方法论。安全边界也要肉眼可见地划清楚只读类MCP Server给全员写操作类MCP Server只给指定高级开发者生产环境连接统一走网关注入的临时凭证不在配置文件里写死明文密码。用工程化思维来看MCP和Skills不只是个人效率工具它们同样需要版本管理、权限管理、审计日志。早期就建立好这套规则比后期给AI擦屁股要省心太多。6. 我最终沉淀下来的工作流上面说了这么多最后总结一下我当前实际落地的Claude Code工程化工作流长什么样。我电脑上有一套全局Skills大概10个左右覆盖代码规范、提交信息、变更日志、代码评审、数据库操作规范这些通用场景。每个项目目录里的.claude/skills再放项目专属技能比如业务状态机说明、结算规则、内部接口文档索引。项目专属技能处理“这个项目特有的事”全局技能处理“所有项目共同的事”。MCP这边全局标配PostgreSQL、GitHub、Fetch、文件系统四个Server。进新项目时根据技术栈再追加浏览器DevTools、Redis、消息队列等。权限上所有写库操作一律走跳板机加白名单AI对话里的执行请求默认只读需要真写的时候我手动审批。整个工作流跑下来最直观的感受是Claude Code不再像“一个很聪明的实习生”而是变成了“一个熟悉项目套路、能自己查数据、能操作工具的资深同事”。我每天节省出来的重复劳动时间至少有2到3个小时这些时间被我用在方案设计、代码走查和真正的难点攻克上。最后分享一个实用小技巧给MCP Server接入效果做一套自检测试。我写了一个mcp-check的Skill专门用于验证所有MCP连接是否正常每次配置新Server或者升级环境后跑一遍几秒钟内就能判断出哪些工具连接失败、哪些工具返回格式异常。这就避免了“自以为接好了实际用的时候才发现断了”的尴尬。工程化不是一次性改造而是持续打磨的流程自检测试是让这套流程长期可靠的保险丝。