先说个有意思的现象。前阵子我在帮某团队调一个 Codex 落地的批量任务项目本身不复杂就是把历史遗留的几百段代码块按规范重构再顺便生成一版接口文档。最开始我们走的是“原生 Prompt”路线把需求写在文本里丢给 Codex让它自由发挥。单次任务偶尔看着还行可一旦任务串起来接二连三地出现格式漂移、字段漏写、上下文越翻越乱最终统计下来准确率只有八成出头大量时间都花在人工纠错上。后来我们把 Codex 和一套叫“陌讯 Skill”的技能模块接起来之后准确率做到了九成五以上跑完一批任务几乎不用返工。这篇文章就把整个调优过程和关键经验拆开讲适合正在用 Codex、Agent 类工具做批量处理又被“这玩意怎么就不听话”折磨的人。1. 原生 Prompt 的痛点快是快但准确率一直悬着先厘清什么是“原生 Prompt”。我这里的定义很简单你直接把任务描述、约束条件、期望输出写进对话或指令里想让大模型理解什么就写什么不加任何外部结构化层、不拆阶段、不挂工具。这种模式优势很明显上手快、零依赖、改个词就能跑。Codex 本身理解能力又强写写小脚本、改个函数、回答一个具体技术问题原生 Prompt 完全够用。可一旦跨入批量、稳定、高约束的工作流原生 Prompt 的短板就会集中爆发。1.1 原生 Prompt 的三类常见翻车现场第一类是“上下文污染”。多轮任务时前一个任务的输出、中间思考、失败重试日志全都堆在窗口里。Codex 在生成下一次回答时很容易把上一次的输出格式当成范例于是一种错误格式被反复复制。比如有次我们要求所有代码块加统一头注释第一轮确实加了但第二轮因为前面某次输出没加它连带着后面十几条全漏了。第二类是“约束无力”。你在 Prompt 里写了十条规则模型记住三条忽略三条又“创造”出四条新规则。尤其当约束之间互相冲突时原生 Prompt 没有任何校验机制模型只能按概率猜。我曾经在一次文档生成任务里明确要求“输出 Markdown 表格”Codex 却自己在数据中间插了一堆引用块问就是说“感觉这样更适合阅读”。第三类是“不可复现”。同一套 Prompt 今天跑准确率 90%明天可能是 80%调个措辞又变成 70%。原生 Prompt 下模型决策是黑盒的出错后你没法快速定位是哪条规则被破坏了只能整段 Prompt 推翻重写。这在大规模使用场景里是致命伤稳定性不足后面所有基于结果的自动化都不好展开。1.2 Codex 本身解决不了流程问题Codex 是个很强的单点能力模型能理解自然语言、能写代码、能调用工具但它不知道自己“该在什么时候做什么事”这是流程层的问题。就像你把一个技术很强的同事扔进一条没有标准作业程序的流水线他照样会漏步骤、抄错单据、忽略交接规范。Codex 也是如此它缺的不是能力而是一套“就算脑子开小差也不会跑偏”的外部约束。这也是“陌讯 Skill”出现在整个方案里的真正原因。它提供的不是更聪明的模型而是把任务拆成标准动作、为每个动作配上严格的输入输出契约、再给 Codex 套上一套自动纠偏机制。说白了Skill 是给 Codex 装了个“生产管理制度”。2. 陌讯 Skill 的核心设计把 Prompt 从“一段话”变成“一套流程”如果你单看“Skill”这个名字可能会觉得它只是一个更长的 Prompt 模板而已。实际不是。我接的这套陌讯 Skill更像是一个携带了技能定义、步骤编排、格式约束、校验规则和故障回退逻辑的完整工具包。2.1 Skill 的五个核心组成部分一个完整的陌讯 Skill 一般包含五部分技能元信息这个 Skill 叫什么、作用于哪些任务、依赖哪些外部能力。Codex 拿到元信息后能识别“当前应该触发哪个技能”跟路由器分发请求一个逻辑。步骤编排把任务拆成有序步骤比如“先分析→再重构→后生成文档→最后自检”。每一步只给 Codex 一个明确且窄化的子目标避免它在一长串目标里挑着做。输入输出契约定义每一步接收什么结构、输出什么结构。用 JSON Schema 或更简单的字段定义表写清楚Codex 必须按契约交作业。校验与自纠错规则在关键步骤后插入“停一下对照契约检查当前输出”的动作。发现问题就按预设指令修正不让错误往下游流。示例库每个字段、每个格式要求配一条“极简正例”而不是放一大段复杂案例。极简正例帮助模型锚定模式又不至于让它照抄细节。2.2 为什么 Skill 能提升准确率而不是单纯增加 token一开始我也怀疑这不就是把 Prompt 变长了吗变长只会增加理解负担怎么会更准做了一轮实验后我发现真正起作用的是“步骤粒度变细”和“每步有验证”。原生命中率低很多时候是模型一次性承担了太多决策。比如“重构代码并生成文档”这件事如果一口气完成模型要同时处理代码语义、风格映射、文档结构、术语一致性任何一个环节模糊整体结果就跑偏。拆成“先提取函数级变更点→再逐段重构→再映射到文档模板→最后做术语校验”之后每一步的决策空间都小得多。Codex 在“小决策”上的准确率本来就高累加起来反而逼近稳定区。陌讯 Skill 做的就是把这个大决策人为切碎并且强制按顺序执行。2.3 技能化之后的执行效果差异同一个任务我来做个粗略对照。原生 Prompt 下Codex 可能一次输出五段重构代码加一段文档然后直接结束。Skill 工作流下它会先输出变更清单确认无误后再输出重构代码接着单独生成文档草稿最后运行一个“校验清单”动作把字段缺失、格式不符、命名不一致的问题一次性列出来并修复。这个差异最直接的体现是结果可用性。原生 Prompt 的结果经常“一眼看着没什么大问题”但细节经不起推敲。Skill 跑出来的结果从一开始就是按机器校验标准生成的很多低级错误根本走不到人眼里就已被拦下。我测过一组真实项目数据接入 Skill 后格式类错误比例从 12% 降到了 1.5% 以内。3. 实操拆解Codex 陌讯 Skill 工作流怎么落地落地这套方案不一定要写很重的代码。核心是把流程“显式化”。下面我拿三个比较有代表性的真实场景把关键步骤和配置方法铺开讲。3.1 场景一批量代码规范化重构某次接了个任务要对一个老项目里 200 多个 Python 文件做统一重构重命名私有方法、补齐类型注解、把日志打印收敛到统一接口。用原生 Prompt 做了两轮单文件通过率大约 85%剩下 15% 需要人工逐条修。改造后的流程分四步注入 Skill 定义。我建了一个名为“代码规范化重构”的 Skill里面定义了输出 JSON 结构文件路径、变更列表、依赖关系、变更前后代码片段。启动分析步骤。让 Codex 读取指定文件先只回答“需要变更的所有点”完全不写代码。这一步输出的变更清单本身就是结构化的方便后续做人工抽查。执行变更步骤。上一步清单确认后Codex 逐项实施变更每项变更输出一个小 JSON 块包含“原代码”—“新代码”—“变更原因”。自动校验步骤。Skill 里内置了规则函数命名必须符合小写加下划线类型注解必须覆盖所有参数日志调用只能命中白名单接口。Codex 拿这些规则对照新代码输出一份校验报告。这套流程跑下来前 50 个文件花的时间是原生 Prompt 的两倍因为多了分析和校验。但到第 100 个文件时返工率急剧下降总耗时反而追平。做完 200 个文件之后一次通过率 96% 以上而且每个文件都留了结构化的变更说明后续 review 效率也上来了。3.2 场景二非结构化文本抽取与表格化第二个任务是从上百篇技术文档里抽取关键参数整理成统一表格。原生 Prompt 在这里死得很惨。文档格式五花八门有的字段叫“延迟”有的叫“时延”有的写“p99 100ms”有的写“平均响应时间约 50-80ms”。直接要求抽取字段错位和单位错乱非常频繁。用陌讯 Skill 之后我先定义一个“归一化字段映射表”让 Codex 在抽取前先把原始文本里的同义字段名映射到标准字段名再定义“单位转换规则表”让它把所有时间类字段统一转换成毫秒并标注转换依据。抽取过程本身拆成“定位候选段落→字段映射→数值归一化→结构组装”四段每一段都输出中间结构。结果很有意思。原生 Prompt 的单篇字段准确率只有 85%电气拼写错误和单位错误是重灾区。Skill 流程把字段准确率拉到了 98%。比如“p99 100ms”和“平均响应时间 50-80ms”这两种表述最终都能正确落到“p99_ms”和“avg_ms”列不会再出现把平均时间塞进 p99 的情况。代价是每篇文档多花几秒但对批量场景来说完全值。3.3 场景三长文档自动摘要与风险点标注还有一类任务是给几十页的项目文档生成摘要同时标出风险点。原生 Prompt 在这类任务上最大的问题是“遗漏”。文档一长Codex 容易看到后半段忘了前半段的约束摘要里丢了关键风险。Skill 里我把文档切成了带编号的片段先让 Codex 对每个片段单独生成“单片段要点”再进入“跨片段合并”环节最后才是生成整体摘要。并且加了一条强制规则摘要中涉及风险点的句子必须引用来源片段编号。这样既解决遗漏也方便人工溯源。实际跑完一批 30 篇文档Skill 方案的“风险点召回率”从原生的 72% 提高到 91%。人审时不用再从头读整篇文档确认直接看标注的片段编号就能校验对错省下来的时间非常可观。3.4 配套一个简单指标看板方案跑起来之后我建议给每次批量任务配一个最简单的指标看板不需要啥重型平台一个表格就够。每个任务批次记录五个字段任务总数、格式通过数、语义正确数、人工返工数、平均耗时。只要坚持记录Skill 和原生 Prompt 的差距很快就能从感觉变成数字。我自己的历史记录里Skill 工作流的综合返工率大概只有原生 Prompt 的三分之一。4. 准确率怎么算才靠谱不只看“看起来对不对”很多人听到“准确率提升”第一反应是问升了多少但准确率本身怎么定义其实更重要。如果定义得模糊对比出来的数字没有参考价值。4.1 三层准确率拆解我习惯把准确率拆成三层看完成率任务是否执行到规定终点有没有中途断掉或缺失区块。格式符合率输出的结构、字段名、类型、必填项是否符合契约。这里能做成完全机器校验最客观。语义准确率内容本身是否正确这一步通常靠抽样人工标注评估或者用一组设计好的断言规则近似验证。举个例子。一次批量接口文档生成任务总任务数 100。完成率完成 100 条不等于质量好因为可能每条都生成了但字段错了一半。格式符合率98 意味着 98 条在字段、类型、命名上都过机器校验。语义准确率则通过抽样 20 条人工核验如果 18 条正确那语义准确率就是 90%。三个数字一起看画像比“准确率 98%”可靠得多。4.2 一套可复用的加权综合公式如果老板只要一个数字我会用加权综合准确率。权重按任务重点设比如表格抽取类任务格式权重高摘要类任务语义权重高。公式很简单综合准确率 完成率 × 0.2 格式符合率 × 0.4 语义准确率 × 0.4用上面那个例子算就是 100% × 0.2 98% × 0.4 90% × 0.4 95.2%。这个数字不再是一个模糊感觉而是每个批次都能对比的硬指标。调 Prompt、改 Skill、换模型版本时只要这个数字往上走方案就是有效的。4.3 我的实测对比数据把原生 Prompt 和 Codex 陌讯 Skill 放在同一批任务上跑一周取平均值差别非常明显。这里放一张我在项目里实际记录的对比表任务类型和准确率都做了简化处理但趋势是真实的。任务类型原生完成率Skill 完成率原生格式符合率Skill 格式符合率原生语义准确率Skill 语义准确率代码规范化重构96%99%78%96%85%96%文本字段抽取94%100%82%98%90%98%长文档风险标注92%100%70%95%72%91%原生 Prompt 的完成率并不低代码模型大多数时候能把活干完。但格式符合率被原生输出自由度高拖累得很惨。Skill 方案通过契约和校验把格式做成硬约束准确率自然被顶上去了。5. 我踩过的坑和排查技巧聊点实操中真正让人头疼的部分。方案听着简单真跑起来会遇到不少反直觉的问题这里整理几个高频坑。5.1 校验规则写得太模糊Codex 选择性忽略最早做 Skill 时我在校验步骤里写“请检查所有字段是否正确”结果 Codex 每轮都回复“所有字段正确”。后来改成结构化描述明确列出“逐字段核实类型、范围、必填项输出通过/不通过列表”它才真正开始干活。经验和提示文案一定要区分。模糊的经验只是参考结构化指令才是约束。Skill 里所有校验步骤都要写成可检查的动作而不是一句口号。5.2 步骤拆太碎上下文被中间产物堆爆有次我把一个简单抽取任务拆成 8 个步骤每个步骤都要输出大段中间 JSON跑几轮之后上下文窗口被撑满Codex 开始丢前面的字段定义准确性反而断崖式下跌。后来我压缩中间产物只在关键节点输出完整的结构化结果其余步骤只给极短的结论标记问题立刻缓解。拆步骤的原则是拆到“决策变小”就好不要拆到“决策太多”为止。够用、可控、不爆上下文才是正解。5.3 模型“惯性延续”导致格式漂移多轮运行同一个 Skill 时前一次的输出会影响后一次。若前一条输出里某个字段是空的后一条容易照抄空值。我的对策是在 Skill 的校验规则里加“禁止空值传播”并要求 Codex 对任何空字段输出原因标记为“待补充”或“不适用”。虽然只是一个小改动但能明显减少连续丢失。5.4 不同任务类型混用同一个 SkillSkill 也不是越通用越好。代码重构和文本抽取混用一套技能经常出现规则打架。比如文本抽取的 JSON 契约里有个字段叫 result_body代码重构任务也想沿用结果输出了一堆跟代码不匹配的字段。最后我每个大任务类型都单独建 Skill结构与校验规则各走各的互不干扰准确率又回升了几个点。5.5 排查流程先查契约再查数据别动不动就调 Prompt遇到结果不对顺序很重要。先确认结果是否违反输入输出契约再查输入数据是否有脏值、缺失字段最后才是回到 Prompt 措辞层面找问题。我见过很多工程师一看到准确率掉了就重写 Prompt这是成本最高、回报最不稳的路径。结构化方案的价值正在于把大部分问题定位到某一步骤、某一个规则上而不是让整个 Prompt 为乱局兜底。6. 个人经验结构比措辞更能解放大模型做完这一轮接入和实测我最大的感触是原生 Prompt 不是不能用但它的适用范围被严重高估了。适合原生 Prompt 的任务往往是单步、低约束、靠常识就能完成的。一旦任务涉及多步骤、强格式、批量复用把宝押在措辞上不如把宝押在结构上。陌讯 Skill 这套方案给了我一个更稳的度用流程约束给模型创造力留出合理空间让它能把精力集中在真正需要推理的部分而不是反复猜测“我到底该交什么格式的作业”。这也解释了为什么准确率能提升不是模型变聪明了而是错误被一个个显式的关卡拦截住了。最后分享一个我还在用的习惯。每次跑批任务结束我都会让 Codex 生成一份“本次任务偏差清单”把校验未通过、语义存疑、字段异常的项目单独列出来。这份清单既是复盘依据也是下次优化 Skill 的一手素材。坚持两周你会发现自己对“哪里容易错”“哪里需要加规则”的判断会越来越准整套体系就能稳定迭代下去。
先说个有意思的现象。前阵子我在帮某团队调一个 Codex 落地的批量任务项目本身不复杂就是把历史遗留的几百段代码块按规范重构再顺便生成一版接口文档。最开始我们走的是“原生 Prompt”路线把需求写在文本里丢给 Codex让它自由发挥。单次任务偶尔看着还行可一旦任务串起来接二连三地出现格式漂移、字段漏写、上下文越翻越乱最终统计下来准确率只有八成出头大量时间都花在人工纠错上。后来我们把 Codex 和一套叫“陌讯 Skill”的技能模块接起来之后准确率做到了九成五以上跑完一批任务几乎不用返工。这篇文章就把整个调优过程和关键经验拆开讲适合正在用 Codex、Agent 类工具做批量处理又被“这玩意怎么就不听话”折磨的人。1. 原生 Prompt 的痛点快是快但准确率一直悬着先厘清什么是“原生 Prompt”。我这里的定义很简单你直接把任务描述、约束条件、期望输出写进对话或指令里想让大模型理解什么就写什么不加任何外部结构化层、不拆阶段、不挂工具。这种模式优势很明显上手快、零依赖、改个词就能跑。Codex 本身理解能力又强写写小脚本、改个函数、回答一个具体技术问题原生 Prompt 完全够用。可一旦跨入批量、稳定、高约束的工作流原生 Prompt 的短板就会集中爆发。1.1 原生 Prompt 的三类常见翻车现场第一类是“上下文污染”。多轮任务时前一个任务的输出、中间思考、失败重试日志全都堆在窗口里。Codex 在生成下一次回答时很容易把上一次的输出格式当成范例于是一种错误格式被反复复制。比如有次我们要求所有代码块加统一头注释第一轮确实加了但第二轮因为前面某次输出没加它连带着后面十几条全漏了。第二类是“约束无力”。你在 Prompt 里写了十条规则模型记住三条忽略三条又“创造”出四条新规则。尤其当约束之间互相冲突时原生 Prompt 没有任何校验机制模型只能按概率猜。我曾经在一次文档生成任务里明确要求“输出 Markdown 表格”Codex 却自己在数据中间插了一堆引用块问就是说“感觉这样更适合阅读”。第三类是“不可复现”。同一套 Prompt 今天跑准确率 90%明天可能是 80%调个措辞又变成 70%。原生 Prompt 下模型决策是黑盒的出错后你没法快速定位是哪条规则被破坏了只能整段 Prompt 推翻重写。这在大规模使用场景里是致命伤稳定性不足后面所有基于结果的自动化都不好展开。1.2 Codex 本身解决不了流程问题Codex 是个很强的单点能力模型能理解自然语言、能写代码、能调用工具但它不知道自己“该在什么时候做什么事”这是流程层的问题。就像你把一个技术很强的同事扔进一条没有标准作业程序的流水线他照样会漏步骤、抄错单据、忽略交接规范。Codex 也是如此它缺的不是能力而是一套“就算脑子开小差也不会跑偏”的外部约束。这也是“陌讯 Skill”出现在整个方案里的真正原因。它提供的不是更聪明的模型而是把任务拆成标准动作、为每个动作配上严格的输入输出契约、再给 Codex 套上一套自动纠偏机制。说白了Skill 是给 Codex 装了个“生产管理制度”。2. 陌讯 Skill 的核心设计把 Prompt 从“一段话”变成“一套流程”如果你单看“Skill”这个名字可能会觉得它只是一个更长的 Prompt 模板而已。实际不是。我接的这套陌讯 Skill更像是一个携带了技能定义、步骤编排、格式约束、校验规则和故障回退逻辑的完整工具包。2.1 Skill 的五个核心组成部分一个完整的陌讯 Skill 一般包含五部分技能元信息这个 Skill 叫什么、作用于哪些任务、依赖哪些外部能力。Codex 拿到元信息后能识别“当前应该触发哪个技能”跟路由器分发请求一个逻辑。步骤编排把任务拆成有序步骤比如“先分析→再重构→后生成文档→最后自检”。每一步只给 Codex 一个明确且窄化的子目标避免它在一长串目标里挑着做。输入输出契约定义每一步接收什么结构、输出什么结构。用 JSON Schema 或更简单的字段定义表写清楚Codex 必须按契约交作业。校验与自纠错规则在关键步骤后插入“停一下对照契约检查当前输出”的动作。发现问题就按预设指令修正不让错误往下游流。示例库每个字段、每个格式要求配一条“极简正例”而不是放一大段复杂案例。极简正例帮助模型锚定模式又不至于让它照抄细节。2.2 为什么 Skill 能提升准确率而不是单纯增加 token一开始我也怀疑这不就是把 Prompt 变长了吗变长只会增加理解负担怎么会更准做了一轮实验后我发现真正起作用的是“步骤粒度变细”和“每步有验证”。原生命中率低很多时候是模型一次性承担了太多决策。比如“重构代码并生成文档”这件事如果一口气完成模型要同时处理代码语义、风格映射、文档结构、术语一致性任何一个环节模糊整体结果就跑偏。拆成“先提取函数级变更点→再逐段重构→再映射到文档模板→最后做术语校验”之后每一步的决策空间都小得多。Codex 在“小决策”上的准确率本来就高累加起来反而逼近稳定区。陌讯 Skill 做的就是把这个大决策人为切碎并且强制按顺序执行。2.3 技能化之后的执行效果差异同一个任务我来做个粗略对照。原生 Prompt 下Codex 可能一次输出五段重构代码加一段文档然后直接结束。Skill 工作流下它会先输出变更清单确认无误后再输出重构代码接着单独生成文档草稿最后运行一个“校验清单”动作把字段缺失、格式不符、命名不一致的问题一次性列出来并修复。这个差异最直接的体现是结果可用性。原生 Prompt 的结果经常“一眼看着没什么大问题”但细节经不起推敲。Skill 跑出来的结果从一开始就是按机器校验标准生成的很多低级错误根本走不到人眼里就已被拦下。我测过一组真实项目数据接入 Skill 后格式类错误比例从 12% 降到了 1.5% 以内。3. 实操拆解Codex 陌讯 Skill 工作流怎么落地落地这套方案不一定要写很重的代码。核心是把流程“显式化”。下面我拿三个比较有代表性的真实场景把关键步骤和配置方法铺开讲。3.1 场景一批量代码规范化重构某次接了个任务要对一个老项目里 200 多个 Python 文件做统一重构重命名私有方法、补齐类型注解、把日志打印收敛到统一接口。用原生 Prompt 做了两轮单文件通过率大约 85%剩下 15% 需要人工逐条修。改造后的流程分四步注入 Skill 定义。我建了一个名为“代码规范化重构”的 Skill里面定义了输出 JSON 结构文件路径、变更列表、依赖关系、变更前后代码片段。启动分析步骤。让 Codex 读取指定文件先只回答“需要变更的所有点”完全不写代码。这一步输出的变更清单本身就是结构化的方便后续做人工抽查。执行变更步骤。上一步清单确认后Codex 逐项实施变更每项变更输出一个小 JSON 块包含“原代码”—“新代码”—“变更原因”。自动校验步骤。Skill 里内置了规则函数命名必须符合小写加下划线类型注解必须覆盖所有参数日志调用只能命中白名单接口。Codex 拿这些规则对照新代码输出一份校验报告。这套流程跑下来前 50 个文件花的时间是原生 Prompt 的两倍因为多了分析和校验。但到第 100 个文件时返工率急剧下降总耗时反而追平。做完 200 个文件之后一次通过率 96% 以上而且每个文件都留了结构化的变更说明后续 review 效率也上来了。3.2 场景二非结构化文本抽取与表格化第二个任务是从上百篇技术文档里抽取关键参数整理成统一表格。原生 Prompt 在这里死得很惨。文档格式五花八门有的字段叫“延迟”有的叫“时延”有的写“p99 100ms”有的写“平均响应时间约 50-80ms”。直接要求抽取字段错位和单位错乱非常频繁。用陌讯 Skill 之后我先定义一个“归一化字段映射表”让 Codex 在抽取前先把原始文本里的同义字段名映射到标准字段名再定义“单位转换规则表”让它把所有时间类字段统一转换成毫秒并标注转换依据。抽取过程本身拆成“定位候选段落→字段映射→数值归一化→结构组装”四段每一段都输出中间结构。结果很有意思。原生 Prompt 的单篇字段准确率只有 85%电气拼写错误和单位错误是重灾区。Skill 流程把字段准确率拉到了 98%。比如“p99 100ms”和“平均响应时间 50-80ms”这两种表述最终都能正确落到“p99_ms”和“avg_ms”列不会再出现把平均时间塞进 p99 的情况。代价是每篇文档多花几秒但对批量场景来说完全值。3.3 场景三长文档自动摘要与风险点标注还有一类任务是给几十页的项目文档生成摘要同时标出风险点。原生 Prompt 在这类任务上最大的问题是“遗漏”。文档一长Codex 容易看到后半段忘了前半段的约束摘要里丢了关键风险。Skill 里我把文档切成了带编号的片段先让 Codex 对每个片段单独生成“单片段要点”再进入“跨片段合并”环节最后才是生成整体摘要。并且加了一条强制规则摘要中涉及风险点的句子必须引用来源片段编号。这样既解决遗漏也方便人工溯源。实际跑完一批 30 篇文档Skill 方案的“风险点召回率”从原生的 72% 提高到 91%。人审时不用再从头读整篇文档确认直接看标注的片段编号就能校验对错省下来的时间非常可观。3.4 配套一个简单指标看板方案跑起来之后我建议给每次批量任务配一个最简单的指标看板不需要啥重型平台一个表格就够。每个任务批次记录五个字段任务总数、格式通过数、语义正确数、人工返工数、平均耗时。只要坚持记录Skill 和原生 Prompt 的差距很快就能从感觉变成数字。我自己的历史记录里Skill 工作流的综合返工率大概只有原生 Prompt 的三分之一。4. 准确率怎么算才靠谱不只看“看起来对不对”很多人听到“准确率提升”第一反应是问升了多少但准确率本身怎么定义其实更重要。如果定义得模糊对比出来的数字没有参考价值。4.1 三层准确率拆解我习惯把准确率拆成三层看完成率任务是否执行到规定终点有没有中途断掉或缺失区块。格式符合率输出的结构、字段名、类型、必填项是否符合契约。这里能做成完全机器校验最客观。语义准确率内容本身是否正确这一步通常靠抽样人工标注评估或者用一组设计好的断言规则近似验证。举个例子。一次批量接口文档生成任务总任务数 100。完成率完成 100 条不等于质量好因为可能每条都生成了但字段错了一半。格式符合率98 意味着 98 条在字段、类型、命名上都过机器校验。语义准确率则通过抽样 20 条人工核验如果 18 条正确那语义准确率就是 90%。三个数字一起看画像比“准确率 98%”可靠得多。4.2 一套可复用的加权综合公式如果老板只要一个数字我会用加权综合准确率。权重按任务重点设比如表格抽取类任务格式权重高摘要类任务语义权重高。公式很简单综合准确率 完成率 × 0.2 格式符合率 × 0.4 语义准确率 × 0.4用上面那个例子算就是 100% × 0.2 98% × 0.4 90% × 0.4 95.2%。这个数字不再是一个模糊感觉而是每个批次都能对比的硬指标。调 Prompt、改 Skill、换模型版本时只要这个数字往上走方案就是有效的。4.3 我的实测对比数据把原生 Prompt 和 Codex 陌讯 Skill 放在同一批任务上跑一周取平均值差别非常明显。这里放一张我在项目里实际记录的对比表任务类型和准确率都做了简化处理但趋势是真实的。任务类型原生完成率Skill 完成率原生格式符合率Skill 格式符合率原生语义准确率Skill 语义准确率代码规范化重构96%99%78%96%85%96%文本字段抽取94%100%82%98%90%98%长文档风险标注92%100%70%95%72%91%原生 Prompt 的完成率并不低代码模型大多数时候能把活干完。但格式符合率被原生输出自由度高拖累得很惨。Skill 方案通过契约和校验把格式做成硬约束准确率自然被顶上去了。5. 我踩过的坑和排查技巧聊点实操中真正让人头疼的部分。方案听着简单真跑起来会遇到不少反直觉的问题这里整理几个高频坑。5.1 校验规则写得太模糊Codex 选择性忽略最早做 Skill 时我在校验步骤里写“请检查所有字段是否正确”结果 Codex 每轮都回复“所有字段正确”。后来改成结构化描述明确列出“逐字段核实类型、范围、必填项输出通过/不通过列表”它才真正开始干活。经验和提示文案一定要区分。模糊的经验只是参考结构化指令才是约束。Skill 里所有校验步骤都要写成可检查的动作而不是一句口号。5.2 步骤拆太碎上下文被中间产物堆爆有次我把一个简单抽取任务拆成 8 个步骤每个步骤都要输出大段中间 JSON跑几轮之后上下文窗口被撑满Codex 开始丢前面的字段定义准确性反而断崖式下跌。后来我压缩中间产物只在关键节点输出完整的结构化结果其余步骤只给极短的结论标记问题立刻缓解。拆步骤的原则是拆到“决策变小”就好不要拆到“决策太多”为止。够用、可控、不爆上下文才是正解。5.3 模型“惯性延续”导致格式漂移多轮运行同一个 Skill 时前一次的输出会影响后一次。若前一条输出里某个字段是空的后一条容易照抄空值。我的对策是在 Skill 的校验规则里加“禁止空值传播”并要求 Codex 对任何空字段输出原因标记为“待补充”或“不适用”。虽然只是一个小改动但能明显减少连续丢失。5.4 不同任务类型混用同一个 SkillSkill 也不是越通用越好。代码重构和文本抽取混用一套技能经常出现规则打架。比如文本抽取的 JSON 契约里有个字段叫 result_body代码重构任务也想沿用结果输出了一堆跟代码不匹配的字段。最后我每个大任务类型都单独建 Skill结构与校验规则各走各的互不干扰准确率又回升了几个点。5.5 排查流程先查契约再查数据别动不动就调 Prompt遇到结果不对顺序很重要。先确认结果是否违反输入输出契约再查输入数据是否有脏值、缺失字段最后才是回到 Prompt 措辞层面找问题。我见过很多工程师一看到准确率掉了就重写 Prompt这是成本最高、回报最不稳的路径。结构化方案的价值正在于把大部分问题定位到某一步骤、某一个规则上而不是让整个 Prompt 为乱局兜底。6. 个人经验结构比措辞更能解放大模型做完这一轮接入和实测我最大的感触是原生 Prompt 不是不能用但它的适用范围被严重高估了。适合原生 Prompt 的任务往往是单步、低约束、靠常识就能完成的。一旦任务涉及多步骤、强格式、批量复用把宝押在措辞上不如把宝押在结构上。陌讯 Skill 这套方案给了我一个更稳的度用流程约束给模型创造力留出合理空间让它能把精力集中在真正需要推理的部分而不是反复猜测“我到底该交什么格式的作业”。这也解释了为什么准确率能提升不是模型变聪明了而是错误被一个个显式的关卡拦截住了。最后分享一个我还在用的习惯。每次跑批任务结束我都会让 Codex 生成一份“本次任务偏差清单”把校验未通过、语义存疑、字段异常的项目单独列出来。这份清单既是复盘依据也是下次优化 Skill 的一手素材。坚持两周你会发现自己对“哪里容易错”“哪里需要加规则”的判断会越来越准整套体系就能稳定迭代下去。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
