Code2Skill：不用重写业务接口，把现有代码生成 MCP 和 Agent Skill

最近我一直在研究一个看起来有点反常的问题很多公司其实并不缺少可以交给 Agent 使用的业务能力为什么建设 Agent 时却常常要从头再做一遍客户查询、订单处理、售后记录、内部申请、数据统计……接口、字段和流程都已经存在只是这些能力主要被封装在网页里打开系统 → 找到页面 → 填写条件 → 点击按钮 → 查看或提交结果当我们开始建设 Agent 时常见做法却是重新整理接口文档、重新定义 Tool再手工编写 MCP Server 和 Skill。已有系统明明每天都在正常运行接入 Agent 时却像要把业务能力重新开发一遍。我不太甘心把这些已经被验证过的代码丢在一边于是产生了一个很直接的想法已经运行多年的业务代码能不能直接成为 Agent 能力的来源于是我把这个想法做成了 Code2Skill。Code2Skill 是一组可以安装给编程 Agent 的 Skills。用户指定一个前端页面、功能目录或全栈代码范围后它会从允许读取的源码中理解业务功能并生成可执行的 Function可通过 MCP 标准发现和调用的 Tools引导 Agent 收集信息和组合能力的业务 Skill对应的离线测试与 MCP 注册说明。当前正式版本是 v1.1.3。先别讲概念来看一次完整任务把一个真实形态的业务场景抽象后可以得到这样的页面功能查询记录列表查询某条记录的备注为选中的记录新增备注。过去这些操作需要用户进入后台页面完成。使用 Code2Skill 后生成结果可以提供三个原子能力并附带一份告诉 Agent 如何理解目标、补充信息和选择能力的 Skill。用户可以直接提出找到名称和编号都匹配的记录先把现有备注告诉我再新增一条备注。Agent 可以根据当前结果逐步完成查询列表 ↓ 根据名称与编号核对目标 ↓ 查询目标记录的备注 ↓ 向用户展示写入内容并确认 ↓ 调用新增备注 Tool ↓ 把后端实际响应交还给用户这里请停一下——这可能是整条链路里最容易被忽略也最容易真正造成错误的一步。查询接口返回的“当前选中记录”不能被写成生成时的固定样本。它必须作为动态数据传给后续 Tool。否则第一次测试可能非常顺利换一条记录却会把请求发给错误的对象。Code2Skill 的生成规范要求保留这种跨 Tool 数据来源并要求用两条匿名记录进行切换测试检查后续请求中没有残留上一条记录的数据。最终是否正确仍以实际生成结果和测试为准。这也是我认为“从代码生成”真正有价值的地方我们需要的不只是三个接口地址而是接口、页面状态和下一次请求之间的真实关系。只有保留这些关系生成结果才能从“看起来像一个 Tool”变成真正能够连续完成用户目标的能力。四类产物别让它们互相抢工作产物职责Function封装接口调用、参数映射、数据交接和确定性格式转换MCP Tool通过 MCP Server 暴露 Function使 Agent 能够按标准协议发现和调用Skill告诉 Agent 当前目标、所需信息、可用 Tool、常见顺序和停止条件Tests离线验证请求组装、Tool discovery、dry-run 和关键交接行为我特别想强调Skill 不是一条必须机械执行到底的工作流。如果用户已经提供了全部信息Agent 可以直接调用需要的 Tool信息不足时Agent 可以逐步询问后端返回业务错误时Agent也可以读取实际响应再决定修正参数、向用户解释或停止。因此 Code2Skill 的分工是Function 封装确定性执行逻辑MCP Tool 让能力能够被标准发现和调用Skill 提供业务使用知识Agent 结合当前目标自主选择下一步。真正让我兴奋的是重新组合已有能力过去一个业务功能想真正交到业务人员手里通常需要产品经理先设计完整流程再由前端开发页面、后端提供接口最后经过联调、测试和上线。哪怕底层已经存在几个可以复用的查询或操作能力只要没有被整合进同一个页面业务人员往往就很难直接使用。这使很多需求并不是没有价值而是因为使用频率不够高、涉及多个系统或者单独开发一个页面的成本太高最终一直没有被实现。当已有能力逐步转换成 MCP Tool并配上说明业务目标和使用方法的 Skill 后情况会发生变化Agent 可以根据用户当前的目标从允许使用的能力中选择并组合需要的部分。例如原本分散在不同页面里的查询、计算、记录读取和写入能力可以在一次任务中被临时组合起来。企业不必为每一种组合都预先开发一套固定页面低频但有价值的需求也有机会被更快验证常用组合再逐步沉淀成稳定的 Skill 或正式产品功能。我很喜欢这种变化不是一上来就替代产品设计和正式开发而是先把“验证一种新组合是否有价值”的成本降下来。权限控制、写入确认和业务验收仍然存在只是不必为每一个想法先造一整套页面。为什么我不满足于再写一份接口文档接口文档当然很重要我也不会和它过不去。但在真实项目里它往往不足以还原一个用户究竟怎样完成工作。前端代码中经常还存在这些信息页面真正调用的是哪个接口某个字段来自用户输入、页面状态还是上一个接口的返回同名字段在查询和提交时是否具有不同含义日期、数组、URL 和枚举在提交前如何转换哪些接口只属于某个目标哪些能力可以复用用户最终是如何完成这项工作的。所以 Code2Skill 以前端实际调用的后端接口为主要能力来源再按需读取后端公开的请求和响应结构。它不是看到一个函数就兴奋地包装成 Tool而是先还原用户目标再决定哪些原子能力真正值得暴露。它不会因为在后端搜索到一个内部方法就自动把它暴露成 MCP Tool也不会只根据文件名里有没有DTO来判断数据契约。Request、Response、Schema、Payload、函数参数或运行时对象都可能是有效证据。Code2Skill 是怎样拆解源码的整体过程可以概括为用户指定的页面、功能目录或源码范围 ↓ 识别可以独立完成的主要用户目标 ↓ 追踪前端接口、字段来源和确定性转换 ↓ 按需读取后端公开请求/响应结构 ↓ 生成 Function MCP Tools Skills Tests ↓ 完成离线验证并报告尚未验证的边界这里也有一个容易误解的地方用户指定的目录只是搜索范围不一定等于一个 Skill。如果一个目录中包含多个独立目标Code2Skill 可以分别生成多个业务 Skill并复用共同的 Function 和 MCP Tool。每个 Skill 只描述自己的业务目标不会因为某个公共接口在其他流程出现过就把它提升成所有写操作的全局前置步骤。一份典型的生成结果大致包括generated/code2skill/feature-id/ ├── SKILL.md 或 skills/*/SKILL.md ├── function-core/index.mjs ├── mcp-tool/index.mjs ├── tests/ ├── package.json ├── MCP-SETUP.md └── references/feature-context.md # 复杂业务才生成其中MCP-SETUP.md会说明依赖安装、环境变量、启动方式和 MCP 注册步骤。Skill 已生成、MCP 已连接、真实业务已验证是三个不同的状态。我怎样判断生成质量为了避免“看起来挺完整”成为唯一判断我使用同一个包含多个业务目标的前端功能目录分别通过 Codex 和 Kimi Code CLI 生成了三份结果并从两个角度进行评估。评分由独立复核任务按照公开扣分规则完成但仍然是项目自建评估不是第三方认证。主流程完成度用户是否能依靠生成的 Skill、Function 和 MCP 完成主要工作业务语义精确度接口、字段来源、确定性转换和调用关系是否准确还原源码已经证明的事实。生成模型/运行配置生成耗时主流程完成度业务语义精确度综合参考分Codex GPT-5.6 SolUltra 模式47 分 45 秒9.69.09.4Kimi Code CLI Kimi K3Max 推理档位约 93 分钟9.58.08.9Codex GPT-5.6 SolHigh 推理档位20 分 29 秒9.07.58.4这张表不是模型排行榜。综合分采用“主流程 60% 语义精确度 40%”表达的只是 Code2Skill 当前更重视“先把主要工作做完同时尽量准确还原源码语义”的产品取向不是行业标准。比数字更重要的是边界三份结果都完成了离线测试、本地 MCP discovery 和独立请求探针但没有调用真实业务接口或写入生产数据。因此这里的 9 分以上表示“代码级主要流程基本可用”不等于“已经生产可用”。完整评分方法、扣分规则和匿名结果记录在评估报告中。如果你想现在试一次Code2Skill 使用通用的 Agent Skills CLI 安装。以 Codex 为例npx skillsaddleechen298/Code2Skill\--skillcode2skill-generate\--agentcodex\--global\--yes然后在一个已有代码仓库中告诉编程 Agent使用 $code2skill-generate把这个页面转换成 Agent 能力页面文件或路由。安装和发起任务通常很快但源码分析与产物生成仍需要时间。实际耗时会受到源码范围、模型配置、依赖安装和修正次数影响。如果是第一次尝试我会建议你先选一个范围明确的页面或功能目录一个只读查询或者低风险、容易回查的写入功能前端实际能够正常调用的接口你自己熟悉、能够判断生成结果是否合理的业务。需要注意安装 Code2Skill、安装生成的业务 Skill、安装 MCP 依赖、注册 MCP以及验证真实业务是不同的步骤。npx skills add不会替你注入认证信息也不会自动证明生产接口可用。Code2Skill 本身也不提供独立的源码上传服务。源码如何被读取、保存和传输取决于用户选择的编程 Agent、运行环境和部署方式企业项目应按照自己的代码安全要求选择运行方案。先说清楚它不适合什么情况Code2Skill 目前并不承诺把任意代码一次生成成无需检查的生产系统100% 还原源码没有表达的业务规则自动取得真实账号、权限、附件和部署配置用离线测试代替业务方验收让所有模型生成完全相同的结果。我宁愿把这些边界提前讲清楚真实项目仍然需要熟悉业务的人抽检主要路径配置运行环境并在明确授权后测试真实接口。项目还提供两个可选 Review Skillcode2skill-review-flow像用户一样走一遍生成结果检查主要功能能不能真正完成code2skill-review-source回到原始代码逐项核对检查接口、字段和请求转换有没有生成错。它们用于发现高价值问题不是为了重新建立一套沉重的审计体系。最后是我真正想验证的一件事今天很多企业 Agent 项目首先想到的是重新建设知识库、接口和工作流。但面对已经运行多年的企业系统我更想先做另一件事盘点那些已经存在、却还没有被 Agent 使用起来的能力。公司已经为这些页面、接口和流程投入了很多开发成本它们不应该在新的交互方式出现后突然失去价值。这正是我想通过 Code2Skill 持续验证的方向不是从零重建一套 Agent 业务系统而是让现有系统里的能力以新的方式继续产生价值。如果你手里也有一个已经运行了一段时间的前端或全栈项目可以先选一个只读页面让我陪你试一次。GitHubleechen298/Code2SkillReleaseCode2Skill v1.1.3评估方法Code2Skill 生成结果评估如果生成失败可以把脱敏后的目录结构、错误信息和预期目标提交到 Issue。我不会把失败藏在漂亮的演示后面——对这个项目来说“哪里生成得不够好”与“哪里已经可以真正使用”同样重要。你