Code2Skill 生成结果评估

July 25, 2026 · View on GitHub

评估日期：2026-07-25

结论

本次使用同一份私有、多目标客户端源码，分别通过 GPT-5.6 Sol（Ultra 模式）、Kimi K3（Max 推理档位）和 GPT-5.6 Sol（High 推理档位）生成三个结果。评估保留两套独立口径：

生成模型/运行配置生成日期生成耗时主流程完成度业务语义精确度综合参考分
GPT-5.6 Sol（Ultra 模式）2026-07-2447 分 45 秒9.69.09.4
Kimi K3（Max 推理档位）2026-07-24约 93 分钟9.58.08.9
GPT-5.6 Sol（High 推理档位）2026-07-2420 分 29 秒9.07.58.4

综合参考分按 主流程完成度×60主流程完成度 \times 60% + 业务语义精确度 \times 40% 计算并保留一位小数。60/40 是当前产品取向：优先保证用户能够完成主要工作，同时保留足够权重约束源码语义准确性。它不是第三套独立评估，也不是适用于所有项目的行业标准。

主流程分采用后来按“用户能否完成工作”重新校准的完成度结果；业务语义分采用独立的源码优先精确度复核结果。两者评估问题不同，因此不要求分数接近。三个包的主要流程均已达到代码级基本可用，但尚未经过真实业务接口和部署环境验收。

两次 Codex 生成均使用 GPT-5.6 Sol（模型 ID：gpt-5.6-sol）：Ultra 是协调多个 Agent 的运行模式，High 是推理档位。Kimi Code 使用 Kimi K3（模型 ID：k3），推理档位为 Max。模型名称与运行配置分开记录，避免把 Ultra、High 或 Max 误写成模型名称。

生成耗时口径

生成耗时从生成任务开始计算，到对应 Agent 报告生成完成并通过当轮离线验证为止，包括该任务内的源码阅读、Function/MCP/Skill 编写、测试和修正。它不包括之后在其他任务中进行的独立评分、目录改名、安装、MCP 注册、部署或真实接口验证。

  • GPT-5.6 Sol（High 推理档位）和 GPT-5.6 Sol（Ultra 模式）来自 Codex 任务自身记录的运行时长，分别为 1,229,306 ms 和 2,865,158 ms，展示时换算为 20 分 29 秒和 47 分 45 秒。
  • Kimi K3（Max 推理档位）当时只保留了界面中约 93 分钟的观察记录，因此标记为近似值，不伪造秒级精度。
  • 三次生成均发生在 2026-07-24。耗时受模型配置、并行 Agent、依赖安装、源码范围和当轮修正次数影响，不用于推断模型的一般速度。

隐私边界

本报告可以公开生成工具、模型或运行配置，因为这些信息有助于理解生成条件。业务证据仍保持匿名，不保留或披露：

  • 组织、产品、页面或业务目标名称；
  • API、字段、枚举、业务规则和附件类型；
  • 私有源码仓库、目录、文件名、代码片段或本机路径；
  • 账号、会话、私有提示词或候选包原名；
  • 凭证、运行地址、真实响应或私有评测证据。

公开模型名称不等于对模型供应商作普遍能力排名。本报告只比较同一源码范围下的这三份具体产物，也不能用于还原原始业务。

报告公开字段

后续同类评估应尽量公开以下信息：

  • 生成工具、模型名称和已知的推理/运行配置；
  • Code2Skill 产物 Profile、交付文件数和有效代码行；
  • 两套评估问题、各自评分维度、综合权重和扣分规则；
  • 证据优先级、独立验证方法和实际执行结果；
  • 是否调用真实接口、是否完成 Host 注册和部署；
  • 仍然存在的限制和无法验证的状态。

以下内容继续匿名：业务名称、源码路径、API、字段、枚举、规则、真实响应、凭证和逐目标业务得分。这样既能解释“谁生成、怎样评、为什么得到这个分数”，又不会泄露私有业务。

两套评估体系

体系一：主流程完成度

对应 code2skill-review-flow 关注的问题：

一个具备正常 Tool 调用能力的 Consumer Agent，在获得用户信息和运行环境提供的认证、附件等输入后，能否依靠生成包逐步完成主要用户目标？

它重点判断能不能完成工作。只要 Agent 能根据实际响应补问、修正或继续，非阻断的表达差异只小幅扣分；缺少必要能力、形成错误终端请求或错误阻止流程才显著扣分。

体系二：业务语义精确度

对应 code2skill-review-source 关注的问题：

Function、MCP 和 Skill 是否准确还原客户端源码已经证明的接口、字段来源、确定性转换、跨 Tool 交接和目标分支？

它不因为 Agent “理论上可能修正”就忽略确定性差异。错误字段来源、时间或格式转换留给 Agent 临时推理，即使普通路径仍可能完成，也会降低精确度分。

两套体系都把 Function/MCP 实现纳入评分。区别是：主流程体系关注差异是否阻塞用户；语义体系关注差异是否偏离源码。

评分模型

先从授权源码独立识别实际可进入的主要用户目标。本次识别出五个主要目标，等权评估。每个目标在两套体系下分别满分 10 分；每套总分都是五个目标得分的算术平均值，最后保留一位小数。公开报告只保留包级总分，不公开逐目标业务得分。

主流程完成度

分项分值判断内容
目标理解与信息引导2.0Skill 是否识别正确目标，使用动态信息，并能逐步收集当前缺少的输入
Function/MCP 能力覆盖3.0查询、计算、上传、预校验和最终写入等必要能力是否存在且可由 MCP 调用
数据交接与请求正确性3.0字段是否来自正确上游，确定性转换是否进入 Function，最终请求是否使用正确接口和结构
条件、确认与完成处理2.0必要条件分支、附件、用户确认、停止和响应交付是否足以让 Agent 完成或诚实停止

Function/MCP 能力覆盖与请求正确性合计 6 分。因此一个只有 Skill 文档、但 Function 缺能力或必然构造错误请求的候选，不可能获得高分。

业务语义精确度

分项分值判断内容
接口与能力对应2.0Tool 是否使用正确接口、方法、认证边界和业务操作语义
字段来源与请求映射3.0查询值、用户选择、页面状态和最终请求字段是否来自正确来源
确定性转换与数据交接2.5时间、格式、组合、清理和跨 Tool handoff 是否由 Function 稳定实现
分支与前置条件1.5条件必填、附件、预校验、确认和停止点是否绑定到正确目标或分支
产物一致性1.0Skill、MCP Schema、Function 和测试是否表达同一套可证明语义

扣分规则

为避免只凭印象打分，主流程完成度使用：

  • 代表性标准路径必然无法到达最终请求：该目标通常不高于 5 分。
  • 源码可能进入的必要条件路径缺少能力：按影响范围扣 1.0–2.0 分。
  • 源码明确的转换仍交给 Agent 临时推理，但 Agent 通常可恢复：扣 0.2–0.6 分。
  • 必经入口判断、用户确认或停止点表达不清，但 Agent 仍可恢复：扣 0.2–0.6 分。
  • 仅有文案详略、文件命名或非执行性说明差异：不扣分。

业务语义精确度使用：

  • 错误接口、方法或关键字段来源：按影响扣 0.5–2.0 分。
  • 源码明确的时间、格式或组合转换没有确定性实现：扣 0.3–0.8 分。
  • 查询语义和写入语义混淆，或跨 Tool 数据交接依赖猜测：扣 0.5–1.5 分。
  • 条件、附件、确认或前置步骤绑定到错误目标：扣 0.3–1.0 分。
  • Skill、MCP、Function 或测试之间存在非阻断矛盾：扣 0.2–0.5 分。

两套体系共同遵守：包内测试通过不直接增加业务分；未调用真实接口不从代码级评分中机械扣分，但必须单独标记为“真实业务未验证”。后端内部且客户端不可见的规则不因无法还原而扣分。

证据优先级

本次评估不使用三个生成结果各自生成的 Review 报告，也不沿用历史聊天中的评分。证据按以下顺序独立取得：

  1. 授权客户端源码：重新识别可见入口、主要目标、直接接口调用链、用户输入和客户端确定性转换。
  2. Function Core：逐项检查端点、方法、认证头、查询与请求体、字段来源、时间和格式转换。
  3. MCP Tool：确认必要 Function 已被公开、输入 Schema 足够宽松、结果不会在到达 Agent 前被严格输出 Schema 拦截。
  4. Skill：检查是否能渐进收集信息、使用正确 Tool、处理当前目标自己的条件和停止点。
  5. 独立行为探针：不复用生成包自己的测试断言，使用 dry-run 或 mock 单独检查跨 Tool 数据交接和最终请求。
  6. 包内离线测试与结构校验：确认依赖安装后能够加载、完成 MCP discovery 并执行包内测试。

后端 Service 内部实现不作为默认能力面。只有客户端调用的公开接口、请求/响应契约和客户端明确执行的转换进入评分；无法从授权源码证明的后端内部规则不会被猜测成硬要求。

实际执行方法

1. 重建源码基线

  • 从实际可见入口识别主要目标，排除隐藏或不可进入的功能。
  • 对每个目标记录“取得上下文 → 动态查询 → 用户选择 → 条件分支 → 最终写请求”的标准路径。
  • 继续追踪授权范围内被页面直接引用的组件和公共模块，直到请求构造或附件上传结果能够闭环。
  • 同名字段不按名称认定语义，而是跟踪“接口返回 → 页面状态 → 下一个请求”的真实来源和用途。

2. 核对生成包

  • 从 Skill 入口开始，确认 Agent 能否逐步取得每个必要输入。
  • 检查每一步对应的 MCP Tool 是否存在，并最终调用正确 Function。
  • 逐字段比较 Function 生成的 query/body 与客户端最终请求。
  • 检查时间拼接、ISO 格式化、动态选项选择、附件 URL 绑定等确定性行为是否由 Function 执行。
  • 检查公共 Tool 是否只出现在当前目标真实需要的调用链中。

3. 独立可执行验证

三个原始生成包保持不变，复制到临时目录后安装其声明依赖并执行：

  • JavaScript 语法检查；
  • MCP initialize 与 tools/list；
  • 包内离线测试；
  • Code2Skill 默认目录结构校验；
  • 评估者编写的独立 dry-run 请求探针。

验证结果：

生成模型/运行配置包内测试结构与 MCP 校验独立请求探针
GPT-5.6 Sol（Ultra 模式）21 / 21通过通过，发现少量确认策略差异
Kimi K3（Max 推理档位）24 / 24通过通过，发现一个依赖 Agent 的确定性时间转换
GPT-5.6 Sol（High 推理档位）15 / 15通过通过，确认普通路径可执行并发现条件附件能力缺口

所有验证均为离线或本地协议验证，没有调用真实业务接口、对象存储、真实身份或写入能力。

分数如何形成

GPT-5.6 Sol（Ultra 模式）：主流程 9.6 / 语义 9.0 / 综合 9.4

  • 主要目标、必要 Tool 和最终写请求全部闭环。
  • 条件附件能力和下游绑定完整。
  • 查询用途与最终写入用途能够分离，确定性时间和字段转换由 Function 执行。
  • 主流程仅因少量确认策略依赖 Consumer Agent/Host 而扣分；语义分还对边缘分支与源码表达差异进行更严格扣分。

Kimi K3（Max 推理档位）：主流程 9.5 / 语义 8.0 / 综合 8.9

  • 主要目标和附件闭环完整，用户确认说明清楚。
  • Function/MCP 的请求构造整体正确，动态值能够交接到最终请求。
  • 少数确定性转换和入口判断仍依赖 Agent；它们通常不阻塞主流程，但在源码语义体系中会被明确扣分。

GPT-5.6 Sol（High 推理档位）：主流程 9.0 / 语义 7.5 / 综合 8.4

  • 无附件的普通标准路径完整，查询、计算、预校验和写请求能够执行。
  • 最终请求中的同名字段语义、动态选择和常见时间转换已正确处理。
  • 当源码动态要求附件时，包内没有业务上传 Function/MCP，只能接受外部已经上传的 URL；这使部分条件路径无法单靠生成包完成。
  • 条件输入、确认和部分精确语义依赖 Host 或 Agent，因此语义精确度明显低于主流程完成度。

产物规模

下表是生成包自身规模，不是 Producer 实际读取源码的数量。代码行排除了 package-lock.json 和 node_modules：

生成模型/运行配置交付文件有效文本/代码行目录大小
GPT-5.6 Sol（Ultra 模式）162,880176 KB
Kimi K3（Max 推理档位）151,859164 KB
GPT-5.6 Sol（High 推理档位）131,168120 KB

最终产物无法可靠证明 Producer 实际读取了哪些源码文件或多少代码行。共享源码也不能简单分摊到各个 Skill。若未来需要该指标，应在生成时记录匿名的包级访问汇总，不能从生成结果倒推。

状态边界

本报告证明的是：

  • 生成包结构可加载；
  • MCP Tool 可发现；
  • 离线请求构造能够执行；
  • 从源码重建的主要用户目标在代码级基本闭环。

本报告不证明：

  • 真实认证和权限有效；
  • 动态生产数据符合离线样本；
  • 真实业务接口接受请求；
  • 写操作已经提交、审批或生效；
  • Consumer Host 已正确注册 MCP 或提供附件。

因此，主流程 9 分以上表示代码级基本可用，不等于已经生产可用；语义分表示与可见源码的一致程度，也不能替代真实接口验证。使用方仍应在部署前配置环境，并根据自身业务知识抽检高价值路径；真实接口验证必须显式授权，写接口不得自动调用。

产品结论

这次评估支持当前产品方向：

  • 默认生成精简、可运行的 Function、MCP 和独立 Skill。
  • 优先保证用户能够完成代表性主流程，不恢复大型 Contract、矩阵和审计目录。
  • 源码明确的请求构造和确定性转换应进入 Function，交互、补问和响应判断交给 Agent。
  • 生成包自身绿测只做技术保障；需要时再使用独立 Review 或真实环境抽检。
  • 当前核心生成流程可以进入稳定期，后续根据新的真实案例修复高收益缺口，而不是继续推测性扩张架构。

限制

  • 只评估了一个匿名、多目标源码范围，不能代表所有语言、架构和业务类型。
  • 总分包含评估者判断，适合同批生成结果比较，不应作为跨项目硬门槛。
  • 综合参考分的 60/40 权重是 Code2Skill 当前产品取向；其他项目可以保留两项原始分数并采用不同权重。
  • 没有真实接口和部署证据，不能声称生成结果已经端到端可用。
  • 为保护私有信息，仓库不提供原始源码、生成包、逐字段证据、私有提示词或业务身份映射。