1. 先说结论：我把项目里的Prompt全部重写了一遍

如果你每天都在和代码生成模型打交道，大概率遇到过这种尴尬：一段原生Prompt丢过去，模型回了一大篇"看起来很有道理、仔细一读全是毛病"的内容。字段名猜错、分类逻辑漏分支、输出格式时而是JSON时而是带注释的代码块，结果就是下游解析脚本要写一堆兼容逻辑，人工还要一条条核对。我手里这个日志解析任务就是这么翻车的——50条模拟异常日志，直接用原生Prompt让Codex生成解析规则，一条条核对下来错了12条，而且错得都很隐蔽。不是模型不够强，是我给它的"说明书"存在太多空白，它只能用最常规的信息去填空。

后来我把工作方式改成"Codex + 陌讯Skill"的组合：Codex负责推理执行，陌讯Skill负责把任务拆成带校验节点的结构化流程，相当于给模型发了一本非常具体的操作手册。同样的50条任务，准确率从78%左右直接跳到96%以上，而且单任务耗时几乎没有增加。这篇就把这段改造过程完整拆开：原生Prompt到底哪里拖后腿、陌讯Skill做了什么、实测数据差多少、以及我自己换赛道时踩过的坑。

如果你也在用Codex做代码生成、数据抽取、规则配置这类偏"确定性问题"的任务，大概率能从这篇里面找到可以直接抄走的思路。

2. 原生Prompt的四个"自由发挥"陷阱

先别急着骂模型。很多准确率问题，本质上不是模型能力不够，而是原生Prompt给模型的发挥空间太大。复杂任务里，模型一旦开始"自由发挥"，准确率就变成了一场概率游戏。下面四个坑是我在改造前测出来的主要失败来源。

2.1 任务描述太宽泛，模型只能靠猜

原生Prompt最常见的问题就是"你以为说清楚了，其实没有"。比如"把日志里的异常提取出来"，这句话里至少有四个未定义项：什么是异常、异常分几类、输出什么格式、级别怎么判断。模型会被迫用训练语料里最常见的"异常"概念去补全，但这个概念几乎不可能和你的业务规则完全一致。

举一个实际例子：我们系统里的"订单超时"算不算异常？业务上要归到"性能类"，而模型大概率会按照通用运维习惯归到"业务类"。这就是典型的"猜错默认值"。原生Prompt不是做不到，而是你写Prompt的时候没有把这些业务假设显式写出来，它就只能替你脑补。

2.2 一次问答没有中间检查点

原生Prompt是"输入到输出"的一次性过程，中间没有任何校验。模型从读题到出结果，历经理解需求、补全假设、推理步骤、生成格式四个环节，任何一个环节出错，后面全跟着错。问题在于，这个错往往不是"整个结果错了"，而是"中间某一步偏了，但最终输出看起来还像回事"。

我给你举个真实场景：有次让模型生成一段日志清洗脚本，它在第一步把时间戳格式理解成了标准ISO格式，但我们的日志用的是自定义的紧凑格式。后续所有逻辑都建立在错误前提上，生成的代码看起来结构完整、注释规范，跑起来全是坑。这种错误靠人工Review是可以查出来的，但如果场景复杂、输出很长，Review成本会高到让你怀疑人生。

2.3 输出格式不稳定，解析成本永远居高不下

同一句Prompt，你今天让它输出JSON，它明天可能就在JSON外面包一层Markdown代码块；你让它返回字段id，它可能在部分场景里返回Id或者ID。这种格式漂移在短任务里问题不大，但在批量任务里就是灾难——下游解析程序必须兼容各种变体，稍不注意就解析失败。

我给这个现象起了个名字叫"格式概率化"：模型每次输出的格式不是确定性的，而是服从某种概率分布。对于追求稳定交付的生产环境，这种不确定性就是最大的隐藏成本。你写的不是一次Prompt，而是要给模型的每次输出的"格式分布"兜底。

2.4 长任务的上下文稀释效应

任务步骤越多，原生Prompt的准确率下滑越明显。前面提到的约束，到后面经常被"遗忘"，越靠后的输出内容越随性。我猜测原因是模型的注意力分配：早期约束离生成位置太远，贡献的信号弱化，模型就会偏向于"更自然的续写"而不是"严格遵循开头的要求"。

在我做的日志解析任务里，原生Prompt设置了一套三级分类规则：大类、子类、异常级别。结果显示，前两层分类准确率尚可，到第三层就经常出现"推理不在规则表内"的情况，比如规则表里只有高、中、低三档，模型偶尔生成一个"紧急"。这不是难问题，是典型的上下文稀释造成的"尾部失守"。

这四类问题叠在一起，让我做了一个决定：不再优化那一条越来越长的原生Prompt，而是换一种组织方式。

3. 陌讯Skill：把"一次性提问"改成"多关卡生产线"

陌讯Skill不是某个官方功能，它本质上是一套开源的Skill组织方案，社区里已经有不少人用它来管理Codex的复杂任务。我最初接触这个工具是因为一个同行分享了一句话："别让模型做问答题，让它做填空题。"Skill就是把这句话落地的载体。

3.1 Skill模块到底装了什么

一个Skill包的核心，是用结构化的方式把任务拆成多个有依赖关系的步骤，并给每个步骤定义输入、执行指令、校验规则和输出模板。它的常见骨架是这样：

name: log_anomaly_parser version: 1.2.0 steps: - id: precheck description: 判断输入日志是否包含必要字段 prompt: | 检查输入日志，确认是否包含timestamp、level、message字段。 如果缺失，直接返回 missing_field 标记。 validation: must_contain: [timestamp, level, message] output_enum: [pass, missing_field] - id: classify description: 按规则表对异常进行分类 prompt: | 根据异常分类规则表，判断当前日志的异常大类和小类。 只允许输出规则表中已有的分类ID。 validation: field: category_id must_be_in_enum: true - id: format description: 输出结构化结果 prompt: | 按模板输出最终JSON结果。 不得添加额外注释，不得修改字段名。 validation: output_fields: [anomaly_id, category_id, confidence, summary]

注意每个步骤都有一个validation节点。这是整个Skill设计里最关键的改动——它不再信任模型"一步到位"，而是在每个关卡都设置了一次检查。

3.2 它和Agent工作流的区别

很多老朋友第一次看到这个结构，第一反应是"这不就是Agent工作流吗？"思路确实相近，但有本质区别：Agent调度强调的是"模型自主规划下一步"，Skill强调的则是"任务链路预先固定，模型只负责执行单个关卡"。

Agent适合探索性任务，你也不知道怎么拆最好，让模型自己尝试；而Skill适合那些你已经很清楚步骤、只是不想每次重复写提示词的高频任务。用我自己的话说，Agent是让模型当项目负责人，Skill是让模型当流水线工人。流水线工人看似自由度低，但在固定场景下，产出稳定性和准确率反而更高。

3.3 为什么"较原生Prompt"这个说法是成立的

有些人觉得，Skill不也是写在Prompt里的吗？区别在于组织粒度。原生Prompt是一大段混合了目标、规则、例子的文本，模型需要自己从中抽取出"先做什么、再做什么、边界在哪"；而Skill把决策信息切碎，放在最靠近对应执行步骤的位置，让模型在每个步骤都只需要处理极小范围的推理。

我做过一个对比：把同一个Skill的配置全部展开写进一段原生Prompt，让Codex按整段执行。结果准确率有提升，但远远不如按Skill分步调用稳定。这说明问题的关键不只是"信息是否齐全"，还包括"信息的结构化程度"。模型在短步骤里的推理能力，远比你把它淹没在长文本里时可靠。

4. 实测数据：准确率从78.6%提升到96.3%

接下来放一组我们内部A/B测试的数据。说明一下：这不是严谨的学术评测，样本量和评测方式都偏工程实用，但对日常工作参考意义已经足够。

4.1 测试样本与评测方法

我们造了800条模拟业务日志，覆盖8种异常类型，包含嵌套结构、编码问题、模糊文本、时间戳缺失等难例。任务目标是：给定一段原始日志，生成对应的标准化异常解析结果。控制变量只有执行方式——A组用原生Prompt直接调用Codex，B组用Codex挂载陌讯Skill执行，底层模型保持一致。

评测分为三个维度：语义正确（分类逻辑和描述都符合业务规则）、字段级一致（输出字段名和类型完全符合模板）、人工修正率（生成的解析规则是否让下游直接跑通）。每组50条任务，每条结果由三个人独立打标，出现分歧时讨论确认。

4.2 数据结果

最让我意外的是字段级完全匹配率，从61.2%一跃到92.8%。这说明原生Prompt丢掉的准确率，有很大一部分根本不是"模型推理错"，而是"格式和字段不稳定"。前面提到的"格式概率化"问题，通过输出模板这一项就解决了一大半。

4.3 失败模式的差异

原生Prompt的错误分布很散，主要集中在这几类：

• 分类遗漏：规则表有8个异常大类，模型只识别出6个，剩下两个冷门分类被"忽略"
• 字段命名漂移：同一批结果里，message和msg混用、timestamp有时变成ts
• 长任务尾部错误：层级分类越到后面越不遵守规则表

Skill组的残留错误集中在另一个方向：输入日志本身严重损坏，比如时间戳完全乱码、关键字段缺失。这种场景下Skill的校验节点会直接标记"无法处理"，而不是硬造一个结果。从准确率角度看这反而是一种理想失败——模型知道它不知道什么。

4.4 速度为什么没有劣化

按直觉来说，分步执行比一次性输出应该慢不少。但实测只慢了0.5秒，原因有两个：第一，Skill每个步骤的Prompt很短，短Prompt的生成速度快；第二，结构化模板让输出基本不用重试，而原生Prompt经常因为格式不符合预期要再次调用或者人工修复，这部分隐性耗时补回来了。

如果算上"下游解析失败后的重跑成本"，Skill方式的实际端到端耗时反而更短。这也是我后来在团队里推动改造时最有力的数据支撑。

5. 原理拆解：为什么"更准"不是因为模型变强了

数据摆完了，该讲讲背后的道理。Codex+陌讯Skill能提升准确率，不是模型忽然变强了，而是这套组合改变了模型处理任务的方式。

5.1 从"问答题"改成"选择题"，推理空间被强行缩小

原生Prompt面对的是开放式的"问答题"：模型要在巨大的可能输出空间里找出一个答案，路径自由，犯错概率自然高。而Skill把每个步骤都变成了有限选项的"选择题"——分类结果必须在枚举值里选，输出字段必须对齐模板，连异常输入的响应都被限制为missing_field标记。

选择题永远比问答题简单，一个靠猜，一个靠判断。模型只要理解了当前这个小步骤的上下文，就很难答错。准确率就是这么被拉起来的。

5.2 校验节点模拟的是"工程师复查"意识

校验节点是整个方案的灵魂。它做的事情，在人工流程里叫"自查"：输出前检查结果是否符合规则、是否漏字段、是否偏离模板。模型在执行每个步骤后，会被要求先做一次自检，发现不合规就触发修正，再进入下一步。

这个设计的精妙之处在于它把错误拦截在"萌芽期"。原生Prompt是一次性生成一个大结果，错一步就全盘皆输；Skill则是每走一步都检查一次，把整体错误率从"每一步错误率的乘积"降到了"每一步错误率的最大值"，量级完全不一样。

5.3 模板化输出把解析损耗隔离在流程之外

原生Prompt部署到生产环境时，你永远要处理"模型的自由格式"与"代码的刚性解析"之间的矛盾。Skill里的输出模板把模型侧的输出空间严格限定，让下游解析代码可以写得非常简单，不再需要兼容各种偶然变体。

这个改动看似无关痛痒，实际却解决了准确率统计里一个非常微妙的问题：以前原生Prompt产生的"看起来正确"的结果，一旦格式漂移，下游根本用不了，还要算进去。模板化之后，这类隐性损耗几乎归零，语义准确率才真正等价于可用率。

6. 实操：把Skill包迁到自己的Codex环境

原理再漂亮，不落地就是纸上谈兵。下面分享我从零搭Skill包的过程，以及迁移时需要注意的关键细节。

6.1 最小可用Skill包的目录骨架

我建议从最小骨架开始，不要一上来就搞全功能大框架。一个能跑起来的最小包大概长这样：

skills/log_parser/ ├── skill.yaml # 主配置，定义步骤和校验规则 ├── prompts/ │ ├── precheck.md # 步骤1的指令模板 │ ├── classify.md # 步骤2的指令模板 │ └── format.md # 步骤3的命令模板 ├── validators/ │ └── check.py # 可选的脚本校验 └── templates/ └── output.json # 输出模板

skill.yaml是核心，其余都是辅助资源。最初阶段甚至可以只写skill.yaml，把prompt内容直接内联进去，跑通后再拆文件。

6.2 Codex端的接入方式

接入方式通常就三种：本地加载、目录挂载、云端Skill仓库。我目前用的是本地加载，操作层面就像这样：

# 将skill包注册到Codex环境 codex skill add ./skills/log_parser # 调用时指定skill名称 codex run --skill log_parser "分析下面这条日志：... "

实际命令不一定叫这个名字，但思路都一样：让Codex知道有个叫log_parser的skill包，并且调用时自动按包里的步骤执行，而不是傻乎乎地让模型自由发挥。

6.3 迁移过程中最值得投入的三件事

第一，从"每周重复三次以上"的任务开始。这类任务你已经有成熟的业务规则，拆Skill的边际成本低，收益又最明显。冷门任务先别碰，维护Skill本身的成本可能比任务还高。

第二，先写校验规则，再调Prompt语料。我见过很多人反过来，把步骤Prompt浇得花团锦簇，校验规则写得很松甚至不写，结果和原生Prompt没本质区别。校验规则才是准确率的主要来源，它定义了"什么算对"。

第三，用失败样本反哺校验规则。每跑完一批任务，把错误样本收集起来，看看是哪一类校验没拦住，然后把对应的约束补进validation节点。这样Skill包会越用越准，因为它本质上是把业务经验不断固化到配置文件里。

7. 边界与反例：别把Skill当成万能胶

听到提升数据之后，最危险的想法是"那我所有任务都套上Skill"。我踩过这个坑，这里说清楚什么情况不适合，以及怎么判断要不要上。

7.1 三类不适合的场景

第一类是开放性创意任务，比如"帮我设计一个活动方案""头脑风暴几个功能方向"。这类任务的价值恰恰在于跳出框架，固定步骤反而会压抑模型的发散能力。

第二类是需求本身还在快速变化的任务。Skill一旦拆好，改起来牵一发动全身——换个字段名，可能校验、模板、下游代码全都要动。任务没定型前，用原生Prompt反而灵活。

第三类是极短任务，一次Prompt就能稳定输出。硬套Skill只是增加复杂度，带来不了任何准确率收益。我当时给字符串格式化这种简单任务都配了Skill包，结果纯粹是自己给自己加戏。

7.2 实际踩坑记录

第一个坑是校验规则写得过严。比如要求confidence字段必须是两位小数，模型偶尔输出整数就触发重试，一个简单任务反复跑三四次，速度直接没法看。后来把校验分成"硬校验"和"软校验"两类：字段缺失是硬校验，格式细节是软校验，软校验只警告不重试。

第二个坑是步骤拆得太碎。步骤多了，每步都由模型推理一次，误差会在链路里累积。早期我拆过七步的Skill包，准确率反而比五步版本低。经验和教训是：让每个步骤保持"一句话能说清"的粒度，不要为了结构化而结构化。

第三个坑是模板字段和下游代码不一致。有次我把输出模板的字段名改成了金额单位带符号的写法，但下游解析代码还是旧逻辑，结果Skill内部自检全过，端到端却全是错。后来我坚持在每次修改后跑完整链路验证，而不是只看Skill内部校验。

7.3 一个简单的判断公式

我的参考标准是：同一类任务每周出现3次以上、手工修正率超过20%、业务规则已经稳定两个月以上。三条同时满足，就值得上Skill；否则老老实实用原生Prompt。

再补一条选型心得：如果任务遇到模型"不知道"的情况，Skill的价值会被放大，因为校验节点能把问题暴露出来；如果遇到模型"知道但表达不对"的情况，模板和校验同样能救；真正救不了的是"模型压根不会推理"的任务——那种情况换任何封装都没有意义，先在底层模型层面找解决方案更实际。

最后分享一下我在整个改造过程中的个人体会：改造准确率这件事，80%的收益来自头20%的改动。别急着把全部任务都挪到Skill体系里，先从最痛的那条线入手，做一个十几行的小包，跑通、加校验、看数据。我最初就是一口气把所有高频任务全套上Skill，结果维护成本直线上升，准确率表面涨了，投入产出比却很糟糕。后来砍到只剩两个真正高频的场景，人工修正率从接近两成才降到个位数，准确率和效率才真正同时站在了可接受的位置。真正好用的工程方案，往往不是功能最全的，而是刚好解决痛点的那个。