企业官网建设流程全解析

1. 项目概述：当Claude Code Skills遇上MCP，我的开发流不再“裸奔”

我做前端和全栈开发快八年了，过去三年几乎每天都在和AI编程助手打交道。从最早用Copilot写个for循环都得反复调prompt，到后来自己搭本地Ollama+CodeLlama跑小模型，再到去年开始试水Claude Code——说实话，前半年我基本是“裸用”状态：装上插件、开个对话框、粘贴代码、Ctrl+Enter、复制结果、手动改bug。听起来高效？实测下来，平均每天要中断27次：不是模型没理解上下文，就是生成的代码漏了TypeScript类型定义，再或者它把useEffect写成了useEffct这种低级拼写错误，还得我肉眼扫三遍。更别提那些需要跨文件操作的场景，比如“把登录页的表单校验逻辑抽成独立Hook，并同步更新所有引用它的组件”，这时候裸用Claude Code就像让一个只懂单点射击的狙击手去指挥整场战役——火力够猛，但完全没协同。

直到上个月，我在GitHub上偶然看到一个叫mcp-server-python的仓库，Readme里写着“MCP: Model Communication Protocol —— a standardized way for AI agents to call tools”。当时没多想，顺手clone下来跑了个demo，结果发现它能直接把VS Code里的文件系统、终端、Git命令封装成标准接口，Claude Code Skills就能像调用函数一样精准调用。那一刻我才意识到：过去我一直在用一把瑞士军刀的刀刃切牛排，而MCP+Skills组合，才是给这把刀装上了可编程的智能手柄。这不是简单的功能叠加，而是工作流范式的切换——从“人指挥AI写代码”，变成“人定义规则，AI按规则执行任务”。现在我重构一个中等复杂度的React组件库，从需求分析、接口设计、代码生成、单元测试到Git提交，整个流程90%由Skills驱动，我只需要在关键决策点按一次回车。标题里说的“从裸用到工程化”，核心就在这儿：裸用是把AI当高级搜索引擎，工程化是把AI当可编排、可验证、可复用的开发流水线一环。如果你也常遇到“AI生成的代码总差一口气”“每次都要手动补全环境配置”“团队协作时AI输出不一致”这类问题，那这套组合拳大概率就是你缺的那块拼图。

2. 核心技术解构：Skills与MCP到底在解决什么根本问题？

2.1 Skills不是插件，是AI的“可编程能力模块”

很多人第一次听说Claude Code Skills，下意识会把它和VS Code的扩展插件划等号。这是个危险的误解。插件是运行在编辑器进程里的本地程序，Skills则是Claude Code模型内部的能力注册表。举个具体例子：当你在VS Code里安装了“Git Commit Message Generator”这个Skill，它并不会在你的电脑上运行任何新进程；相反，Claude Code模型在收到你的请求（比如“为这次修改生成符合Conventional Commits规范的提交信息”）时，会先检查自己的Skills列表，确认该Skill已启用，然后将当前Git暂存区的diff内容、项目根目录路径等元数据，按预定义的JSON Schema打包，作为输入参数发送给Skill服务端。这个服务端可以是本地Python脚本，也可以是部署在公司内网的Node.js API，甚至是一个Docker容器。关键点在于：Skills的执行权始终在模型侧，但执行环境完全解耦。这意味着什么？意味着你可以让同一个Skill，在Mac上调用git命令，在Windows上自动转成PowerShell等效命令，在CI服务器上则直接读取GitLab CI的环境变量。我上周就用这个特性，把团队的“PR描述生成”Skill从仅支持GitHub迁移到同时兼容GitLab和Bitbucket，只改了3行配置，没动一行业务逻辑。

提示：Skills的JSON Schema定义是它的灵魂。比如一个“API文档生成”Skill，它的Schema必须明确声明输入字段：{ "openapi_spec_path": "string", "output_format": "enum: ['markdown', 'html', 'pdf']" }。如果用户提问“把user-service的OpenAPI文档转成PDF”，Claude Code会自动提取user-service/openapi.yaml路径和pdf格式，跳过所有模糊匹配环节。这比传统Prompt Engineering靠关键词触发稳定得多。

2.2 MCP协议：给AI装上标准化的“USB-C接口”

如果说Skills定义了“能做什么”，那MCP（Model Communication Protocol）就是规定“怎么连接”。它的设计哲学非常务实：不碰模型推理层，只管工具调用层。你可以把它想象成USB-C接口标准——Type-C物理形态千变万化，但只要遵循USB-IF协议，手机、笔记本、显示器就能即插即用。MCP同理：它用一套极简的JSON-RPC 2.0规范，定义了四个核心方法：list_tools（获取可用工具列表）、call_tool（执行工具）、stream_tool_output（流式返回结果）、tool_error（错误处理）。没有复杂的认证体系，没有强制的传输协议（HTTP/WS/gRPC全支持），甚至连工具元数据都只要求三个字段：name、description、input_schema。为什么这么轻量？因为Claude Code团队发现，开发者最痛的不是协议复杂，而是每个AI工具都要求你重写一遍环境适配代码。比如以前接一个本地代码搜索工具，你要写Python脚本解析VS Code的workspacePath，再用subprocess调用ripgrep，最后把结果格式化成Markdown；而用MCP，你只需在工具服务端实现一个search_code方法，接收{ "query": "useState", "scope": "current_file" }，返回{ "results": [ { "file": "src/hooks/useAuth.ts", "line": 12, "content": "const [user, setUser] = useState<User | null>(null);" } ] }。Claude Code会自动处理路径解析、编码转换、超时重试。我实测过，把一个原来需要200行胶水代码的Figma设计稿解析工具，用MCP重写后只剩47行核心逻辑，维护成本直降76%。

2.3 二者结合的化学反应：从“随机应变”到“精准制导”

单独看Skills或MCP，价值有限；但当它们组合，就产生了质变。我们用一个真实场景拆解：自动化修复TypeScript类型错误。裸用时，你得把报错信息截图、粘贴进Claude Code、描述“请帮我修复这个TS2339错误”，模型可能生成一堆无关代码。用Skills+MCP后，流程是这样的：

1. 你在VS Code里选中报错行，右键选择“Fix with Claude Code”；
2. VS Code插件捕获当前文件路径、光标位置、TS编译器报错详情，通过MCPcall_tool发送给ts-fixerSkill；
3. ts-fixerSkill启动tsc --noEmit --watch模式，实时获取完整错误树，定位到确切的属性访问链；
4. 它调用tsc的getSuggestionDiagnosticsAPI，获取官方推荐的修复方案（比如添加!非空断言，或重构为可选链）；
5. 将修复建议按MCPstream_tool_output格式分块返回，VS Code插件实时渲染成可点击的修复按钮；
6. 你点“应用”，插件直接调用VS Code的TextEditor.edit()API注入代码。

整个过程没有一次自由文本生成，全是结构化数据流转。我统计过，同类错误的修复准确率从裸用的68%提升到94%，且平均耗时从3分12秒压缩到18秒。这背后是Skills提供的领域知识封装（TS编译器API调用逻辑）和MCP保障的通信可靠性（错误不丢失、流式不卡顿）共同作用的结果。它让AI从“猜你想做什么”，变成了“严格执行你定义的修复协议”。

3. 工程化落地：我的VS Code工作流改造全记录

3.1 环境准备：避开那些坑了我三天的依赖陷阱

在Ubuntu 22.04和macOS Sonoma上，我踩过最多的坑不是配置本身，而是环境依赖的隐式冲突。这里必须强调一个血泪教训：绝对不要用系统自带的Python 3.10或3.11。Claude Code官方文档说支持Python 3.8+，但实际测试发现，当你的系统Python链接到/usr/bin/python3，而VS Code的Python扩展又默认用这个解释器时，MCP服务端的asyncio事件循环会和VS Code主进程产生竞态条件，表现为Skill调用偶尔卡死，重启VS Code才能恢复。解决方案很直接：用pyenv管理独立Python环境。

# Ubuntu上（macOS同理，只是brew替换为pyenv） curl https://pyenv.run | bash export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init -)" pyenv install 3.12.3 pyenv global 3.12.3

接着安装MCP服务端核心依赖。注意，mcp-server-python的0.5.0版本有个已知Bug：当uvloop未安装时，高并发下会出现RuntimeError: Event loop is closed。所以初始化命令必须带--no-cache-dir强制刷新：

pip install --no-cache-dir mcp-server-python==0.5.0 uvloop

VS Code插件方面，别用市场里那个叫“Claude Code”的旧版（最后更新是2023年10月）。正确做法是去GitHub Releases下载最新claude-code-vscode-*.vsix文件，然后在VS Code里用Extensions: Install from VSIX手动安装。我试过，旧版插件对MCP 0.5.0的stream_tool_output响应格式解析有偏差，会导致流式输出乱码。

注意：如果你用的是企业版VS Code（如Code - OSS构建版），务必检查settings.json里是否禁用了"extensions.autoUpdate": false。很多公司策略会锁死插件更新，导致新版MCP协议无法被识别。临时解决方案是在用户设置里加一行："claudeCode.mcpEnabled": true，强制启用MCP通道。

3.2 Skills开发实战：从零写一个“Git分支健康度扫描”Skill

与其堆砌一堆现成Skills，不如亲手写一个最能体现工程价值的。我选了“Git分支健康度扫描”，因为它直击团队痛点：开发人员常忘记清理已合并的feature分支，导致远程仓库臃肿，CI构建时间拉长。这个Skill要能自动检测：1）本地分支是否已推送到远程；2）远程分支是否在main上存在对应merge commit；3）分支最后一次提交距今是否超过30天。以下是核心代码（已脱敏）：

# git_health_skill.py import subprocess import json from datetime import datetime, timedelta from typing import List, Dict, Any def list_tools() -> List[Dict[str, Any]]: return [{ "name": "scan_git_branch_health", "description": "Analyze local and remote Git branches for health metrics: push status, merge completeness, and age.", "input_schema": { "type": "object", "properties": { "max_age_days": {"type": "integer", "default": 30}, "remote_name": {"type": "string", "default": "origin"} } } }] def scan_git_branch_health(input_data: Dict[str, Any]) -> Dict[str, Any]: max_age_days = input_data.get("max_age_days", 30) remote_name = input_data.get("remote_name", "origin") # Step 1: Get all local branches with their latest commit date local_branches = _get_local_branches() # Step 2: Fetch remote refs to avoid stale data subprocess.run(["git", "fetch", "--prune", remote_name], capture_output=True, text=True, check=True) # Step 3: Get remote branches remote_branches = _get_remote_branches(remote_name) # Step 4: Cross-check each local branch results = [] cutoff_date = datetime.now() - timedelta(days=max_age_days) for branch in local_branches: status = "healthy" issues = [] # Check if pushed to remote if branch["name"] not in remote_branches: status = "unpushed" issues.append(f"Branch '{branch['name']}' not pushed to {remote_name}") # Check if merged into main if branch["name"] != "main" and branch["name"] != "master": merge_status = _is_merged_into_main(branch["name"], remote_name) if not merge_status["merged"]: status = "unmerged" issues.append(f"Branch '{branch['name']}' not merged into {merge_status['target']}") # Check age commit_date = datetime.fromtimestamp(branch["commit_timestamp"]) if commit_date < cutoff_date: status = "stale" issues.append(f"Branch '{branch['name']}' last updated {int((datetime.now() - commit_date).days)} days ago") results.append({ "branch": branch["name"], "status": status, "issues": issues, "last_commit": commit_date.isoformat(), "age_days": (datetime.now() - commit_date).days }) return {"results": results} def _get_local_branches() -> List[Dict[str, Any]]: result = subprocess.run( ["git", "for-each-ref", "--format=%(refname:short)%00%(committerdate:unix)", "refs/heads/"], capture_output=True, text=True, check=True ) branches = [] for line in result.stdout.strip().split("\n"): if not line: continue name, timestamp = line.split("\x00") branches.append({"name": name.strip(), "commit_timestamp": int(timestamp)}) return branches def _get_remote_branches(remote_name: str) -> List[str]: result = subprocess.run( ["git", "ls-remote", "--heads", remote_name], capture_output=True, text=True, check=True ) return [line.split("\t")[1].replace(f"refs/heads/", "") for line in result.stdout.strip().split("\n") if line] def _is_merged_into_main(branch_name: str, remote_name: str) -> Dict[str, Any]: # Simplified logic: check if branch's tip is reachable from main try: subprocess.run( ["git", "merge-base", "--is-ancestor", f"{remote_name}/{branch_name}", f"{remote_name}/main"], capture_output=True, text=True, check=True ) return {"merged": True, "target": "main"} except subprocess.CalledProcessError: try: subprocess.run( ["git", "merge-base", "--is-ancestor", f"{remote_name}/{branch_name}", f"{remote_name}/master"], capture_output=True, text=True, check=True ) return {"merged": True, "target": "master"} except subprocess.CalledProcessError: return {"merged": False, "target": "main/master"}

把这个文件放在项目根目录的skills/文件夹下，然后在VS Code设置里添加：

{ "claudeCode.skills": [ { "name": "git_health_scan", "path": "./skills/git_health_skill.py", "enabled": true } ] }

重启VS Code，你就能在命令面板（Cmd+Shift+P）里搜到“Claude Code: Scan Git Branch Health”，执行后会生成一份带颜色标记的健康报告。关键技巧：_is_merged_into_main函数里用了两次try/except，是因为有些老项目主干分支叫master，新项目叫main，硬编码会失败。这个细节是我在三个不同客户项目里踩坑后补上的。

3.3 MCP服务端配置：让Skills真正“活”起来

Skills代码写完只是第一步，要让它被Claude Code识别，必须启动MCP服务端。我用的是mcp-server-python的内置HTTP服务器，配置文件mcp_config.json如下：

{ "server": { "host": "127.0.0.1", "port": 8080, "cors_origins": ["*"] }, "tools": [ { "name": "git_health_scan", "module": "git_health_skill", "function": "scan_git_branch_health" }, { "name": "ts_fixer", "module": "ts_fixer_skill", "function": "fix_typescript_error" } ], "logging": { "level": "INFO", "file": "./mcp_server.log" } }

启动命令很简单：

mcp-server-python --config ./mcp_config.json

但这里有两点必须强调：第一，cors_origins设为["*"]是为了让VS Code插件能跨域调用，生产环境务必改成具体域名；第二，日志文件路径./mcp_server.log必须确保VS Code工作区有写入权限，否则服务会静默失败。我最初就因为权限问题折腾了两小时，最后发现journalctl -u mcp-server里根本没有错误，纯粹是日志写不进去导致的假死。

VS Code插件侧的配置更关键。在settings.json里，必须显式指定MCP服务地址：

{ "claudeCode.mcpServerUrl": "http://127.0.0.1:8080", "claudeCode.mcpEnabled": true, "claudeCode.enableSkills": true }

特别注意mcpServerUrl的协议必须是http，即使你启用了HTTPS反向代理，VS Code插件目前不支持https前缀（这是个已知限制，官方Issue #217正在跟踪）。如果填成https://localhost:8080，插件会静默降级到传统HTTP调用，Skills完全不生效。

3.4 工作流串联：用Skills组合完成一次完整的组件重构

理论讲完，来个硬核实战。上周我要把团队的<DataTable>组件从纯CSS-in-JS迁移到Tailwind CSS，并自动生成配套的Storybook案例。裸用需要至少6步手动操作，而用Skills工程化后，我只做了三件事：

1. 在VS Code里打开src/components/DataTable.tsx，右键选择“Claude Code: Generate Tailwind Migration Plan”（这是个自定义Skill，输入是组件路径，输出是迁移步骤JSON）；
2. 等待15秒，它生成了一个包含7个子任务的计划，比如“提取所有CSS类名到tailwind.config.js的safelist”“将className={styles.table}替换为className="w-full border"”；
3. 我在命令面板里选“Claude Code: Execute Migration Plan”，它自动调用tailwind-migratorSkill，逐条执行，每步完成后在VS Code底部状态栏显示绿色✓。

整个过程的关键在于计划生成Skill和执行Skill的解耦。前者专注分析（调用AST解析器），后者专注操作（调用VS Code API）。这样做的好处是：计划可以人工审核修改，比如我把第4步“删除所有styled-components导入语句”改成“注释掉导入语句，保留原始代码”，执行Skill会严格按我的修改执行。这比裸用时“让AI一次性重写整个文件”安全得多——毕竟没人敢把生产组件的全部样式逻辑交给AI一锅端。

我截取了执行日志里最关键的几行：

[INFO] Executing step 3/7: Replace className bindings [DEBUG] Found 12 instances of className={...} in DataTable.tsx [INFO] Applied 12 replacements using regex pattern /className=\{([^}]+)\}/g [INFO] Step 3 completed successfully ✓

看到[INFO] Step 3 completed successfully ✓，我就知道这步稳了。这种可验证、可中断、可回滚的执行模式，才是工程化的本质。

4. 避坑指南：那些官方文档绝不会告诉你的实战经验

4.1 技术债清单：Skills开发中最容易被忽视的5个隐形成本

很多开发者以为写个Skills就是写个Python函数，其实远不止。我整理了一份真实的“技术债清单”，每一条都来自血泪教训：

这些坑，没有一个出现在任何官方教程里。它们只存在于深夜三点的journalctl日志里，和你对着空白控制台发呆的十分钟里。

4.2 性能调优：让Skills响应速度从“能用”到“丝滑”的3个关键参数

Skills的响应速度，直接决定你愿不愿意把它纳入日常流程。我对比了12个常用Skills在不同配置下的P95延迟，总结出三个最有效的调优参数：

第一，mcp-server-python的--workers参数。默认是1，意味着所有Skill调用排队执行。在4核CPU的开发机上，设为--workers 3（N-1原则）后，ts_fixer的P95延迟从1.2秒降到0.38秒。但注意不能设为4，因为VS Code插件本身会占用一个核心，设满会导致资源争抢。

第二，VS Code插件的claudeCode.skillTimeout设置。默认是30秒，对简单Skill太长，对复杂分析又太短。我根据Skill类型做了分级：

• 代码生成类（如generate-react-hook）：设为8秒（人类等待阈值）
• 静态分析类（如scan-security-vulns）：设为45秒（允许深度扫描）
• 文件操作类（如rename-component-files）：设为3秒（必须瞬时响应）

第三，也是最容易被忽略的：uvloop的loop.set_exception_handler配置。默认异常处理器会打印冗长traceback，拖慢响应。我在mcp_config.json里加了自定义handler：

{ "logging": { "level": "WARNING", "file": "./mcp_server.log" }, "uvloop": { "exception_handler": "custom_exception_handler" } }

对应的custom_exception_handler.py只有5行：

def custom_exception_handler(loop, context): # 只记录ERROR级别以上，忽略CancelledError等噪音 if context.get('exception') and not isinstance(context['exception'], asyncio.CancelledError): logger.error("Uncaught exception", exc_info=context['exception']) else: logger.debug("Ignored exception: %s", context.get('message', 'unknown'))

这一招让日志体积减少62%，磁盘IO压力骤降，间接提升了整体吞吐量。

4.3 安全红线：Skills开发中必须遵守的3条铁律

AI工具越强大，安全责任越重。我在公司内部推行Skills时，法务和安全部门划出了三条不可逾越的红线，现在已成为团队开发规范：

铁律一：禁止Skills执行任意shell命令。
你可能会想：“写个run_shell_commandSkill多方便！”——这是自杀行为。正确的做法是，为每个需执行的命令创建专用Skill，比如run_tests（只允许npm test）、build_docs（只允许mkdocs build）。我在run_tests.py里硬编码了白名单：

ALLOWED_COMMANDS = { "jest": ["npm", "test", "--", "--ci", "--coverage"], "vitest": ["npm", "run", "test", "--", "--run", "--coverage"] } if command not in ALLOWED_COMMANDS: raise PermissionError(f"Command '{command}' not allowed in production")

铁律二：所有外部API调用必须带超时和熔断。
比如调用公司内部的代码质量平台API，我用tenacity库实现了指数退避：

from tenacity import retry, stop_after_attempt, wait_exponential @retry( stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10) ) def call_quality_api(code_hash: str) -> dict: response = requests.get( f"https://quality-api.internal/check/{code_hash}", timeout=(3.05, 27) # connect:3.05s, read:27s ) response.raise_for_status() return response.json()

铁律三：敏感数据必须零落地。
Skills处理的代码片段、API密钥、数据库连接字符串，绝不能写入磁盘日志。我在所有Skill的入口处加了数据清洗：

def sanitize_input(data: dict) -> dict: # 移除所有含'key'、'token'、'password'的字段 clean = {} for k, v in data.items(): if not any(sensitive in k.lower() for sensitive in ['key', 'token', 'pass', 'secret']): clean[k] = v else: clean[k] = "[REDACTED]" return clean

这三条铁律，让我负责的Skills系统上线14个月，零安全事件，零数据泄露。它们不是束缚，而是让AI真正融入工程体系的基石。

5. 进阶实践：从单机Skills到团队级AI工作流协同

5.1 多环境Skills分发：如何让前端组和后端组用同一套Skill？

团队协作最大的障碍不是技术，而是环境差异。前端组用macOS + Node 18，后端组用Ubuntu + Java 17，大家写的Skills互相调用时，经常出现ModuleNotFoundError: No module named 'pandas'。我的解决方案是：用Docker容器封装Skills，VS Code只负责发起MCP调用。

具体做法：为每个Skills组（如frontend-tools、backend-utils）创建独立Docker镜像。以frontend-tools为例，Dockerfile精简到23行：

FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8080 CMD ["mcp-server-python", "--config", "mcp_config.json"]

requirements.txt里只放真正必需的包，比如requests、beautifulsoup4，坚决不用pandas这种重型依赖。然后在VS Code设置里，把Skill路径指向容器服务：

{ "claudeCode.skills": [ { "name": "react-component-analyzer", "url": "http://localhost:8081", // frontend-tools容器端口 "enabled": true } ] }

这样，无论开发者用什么系统，只要docker-compose up -d启动容器，Skills就自动就绪。我统计过，团队新成员环境搭建时间从平均4.2小时降到18分钟，因为再也不用纠结“你的Python版本是不是3.12.3”。

5.2 Skills版本管理：用Git Tag实现技能的可追溯发布

Skills不是写完就扔的脚本，它是团队的知识资产。我强制要求所有Skills提交必须打Git Tag，格式为skills/v1.2.0。然后在mcp_config.json里用git describe --tags动态加载：

{ "tools": [ { "name": "git_health_scan", "module": "git_health_skill@v1.2.0", // @后跟Tag名 "function": "scan_git_branch_health" } ] }

mcp-server-python启动时会自动git checkout v1.2.0，确保每次运行的都是经过测试的稳定版本。上周我们发现v1.1.0的_is_merged_into_main函数在某些Git版本下有竞态bug，立刻回滚到v1.0.0，整个过程不到30秒。这种版本控制能力，是裸用时代完全无法想象的。

5.3 监控与可观测性：给Skills装上“仪表盘”

没有监控的AI工作流，就像没有刹车的赛车。我在mcp-server-python基础上加了一层Prometheus监控，暴露了4个关键指标：

• mcp_skill_call_total{skill_name, status_code}：各Skill调用总数，按成功/失败分类
• mcp_skill_duration_seconds_bucket{skill_name, le}：各Skill响应时间分布（直方图）
• mcp_server_up{instance}：服务存活状态
• mcp_skill_error_count{skill_name, error_type}：各Skill错误类型计数（如TIMEOUT、VALIDATION_ERROR）

配置极其简单，在mcp_config.json里加：

{ "monitoring": { "prometheus": { "enabled": true, "port": 9090, "endpoint": "/metrics" } } }

然后用Grafana建了个Dashboard，核心看板就两个：

1. 健康度看板：显示所有Skills的success_rate（成功率），低于95%标红告警；
2. 性能看板：显示p95_duration（95分位响应时间），超过1秒标黄，超过3秒标红。

上周五下午，ts_fixer的p95_duration突然从0.38秒飙升到2.1秒，我立刻查mcp_server.log，发现是某个开发者提交了一个12MB的node_modules/typescript/lib/lib.dom.d.ts文件，触发了ts_fixer的全量类型分析。于是我在Skill里加了文件大小限制：

if os.path.getsize(file_path) > 5 * 1024 * 1024: # 5MB raise ValueError(f"File {file_path} too large for analysis (>{5}MB)")

整个排查+修复过程，从告警到上线，11分钟。这种可观测性，让AI工作流真正具备了工程系统的成熟度。

6. 未来演进：Skills与MCP生态的下一阶段思考

6.1 从Skills到Skill Graph：让AI能力自动组合

当前Skills是扁平的、孤立的函数。但真实开发任务是网状的。比如“重构API客户端”这个需求，可能需要：1）用openapi-parserSkill解析Swagger文档；2）用code-generatorSkill生成TypeScript接口；3）用git-health-scanSkill检查是否有未提交的本地修改；4）用test-runnerSkill验证新接口。现在我得手动按4次快捷键，未来应该让Claude Code自动规划这个Skill Graph。

我正在实验一个轻量级编排层：在mcp_config.json里定义workflows：

{ "workflows": { "api-client-refactor": { "steps": [ {"skill": "openapi-parser", "input": {"spec_path": "$INPUT.spec_path"}}, {"skill": "code-generator", "input": {"ast": "$PREV.output.ast"}}, {"skill": "git-health-scan", "input": {"check_uncommitted": true}}, {"skill": "test-runner", "input": {"pattern": "api-client.test.*"}} ] } } }

$INPUT和$PREV是占位符，Claude Code会自动注入上游Skill的输出。这个想法还在POC阶段，但已经能看到曙光：当AI不仅能执行原子操作，还能理解操作间的依赖关系，工作流的自动化程度将跃升一个数量级。

6.2 MCP协议的“边缘计算”：Skills在浏览器端的轻量化运行

VS Code插件依赖本地服务，但很多场景需要离线或低延迟。我正尝试把部分Skills编译成WebAssembly，直接在浏览器里运行。比如regex-testerSkill，用Rust写，wasm-pack build后，体积仅127KB，加载后毫秒级响应。关键突破是mcp-browser-sdk——一个轻量JS库，让浏览器端Skills也能响应MCP的call_tool请求。这意味着，即使你的VS Code断网，regex-tester依然能工作。这对出差中的开发者、或网络受限的企业环境，是实实在在的生产力提升。

6.3 最后一点个人体会：工程化不是消灭“人”，而是让人回归创造

写这篇长文时，我翻出了三年前的开发日志，里面