从一次 Chat 到自己的 Skill

从还没安装日报 Skill 开始

准备好能读取文件、运行处理并保存结果的 Qoder。全部输入都是虚构工单，可以放心跟练。你负责确认规则、核对数字；处理代码和 Skill 文件交给 AI 整理。

1. 普通 Chat 完成任务：得到一份核对正确的日报。
2. 提炼 Skill：得到自己创建的完整 Skill ZIP。
3. 安装：在已安装列表中找到它。
4. 新 Chat 验证：只给数据、日期和输出位置，重做日报。

今天先完成这四步。批量检查、换电脑和成熟度等内容在进阶阅读，用到时再看。

第一次还没保存方法，需要把业务规则告诉 AI。提炼、安装之后，日常使用只说本次要处理什么文件、哪一天、结果放哪里。页面上的提示词是示例，可以用自己的话说。

1. 用普通 Chat 完成一次工单日报

现在有什么：只有一份工单数据，还没有你自己的日报 Skill。

你要做什么

1. 在电脑上新建一个专门的练习文件夹，例如“工单日报练习”。下载工单样例 normal.json，放进这个文件夹。JSON 是这次练习的数据文件，无需手工编辑。
2. 打开 Qoder，切到通用，点击新的任务。在输入框下方选择工作目录；还没添加过时，点新建工作区 → 点击添加可读写文件夹，选择刚才的练习文件夹，再点创建。确认任务下方显示的是这个文件夹。
3. 展开下面的提示词，复制到 Chat。此时直接描述任务，不需要选择日报 Skill。

运行中可能出现等待你处理或工具执行确认。看清它要读取的文件、生成的位置或运行的命令；与这次练习一致时点允许一次。确认完成前，任务会暂停等待。这些弹窗在后续步骤也可能出现。若请求读取无关资料或删除文件，点拒绝，再告诉它只处理练习文件、保留验证结果。

先按普通 Chat 完成任务，不调用或安装日报 Skill。读取 normal.json，统计 2026-10-10 创建的工单当前状态。

四个必填字段：ticket_id 是非空 ID，created_date 是有效日期（YYYY-MM-DD），status 只接受 completed（完成）或 open（待处理），minutes 是整数分钟数，完成单大于 0、待处理单为 0。先检查全部记录，缺字段或值不合法就停止并说明原因。
同一 ID 的日期、状态、耗时完全一致时保留一条；有不一致就停止，列出差异等我确认。

告诉我总数、完成数、待处理数、完成单总耗时与平均耗时。平均只除以完成单数，保留两位小数；没有完成单时写不适用。实际运行计算，保存日报和处理代码到新的 ticket-first-run 文件夹，保留已有文件，并说明计算过程和文件位置。

应该看到什么

Qoder 返回日报文件的位置和计算过程。打开日报，逐项核对：

原文件有 7 行：T004 完全重复，保留一条；T006 是 10 月 11 日创建的，本次排除。完成单耗时为 60、45、90 分钟，平均只除以 3 个完成单。这里统计的是 10 月 10 日创建工单的当前状态。

什么叫内容冲突：同一个 ID 出现两次，但日期、状态或耗时不同。例如 T001 一行写 60 分钟、另一行写 90 分钟，AI 无法知道该信哪行，应该列出差异等你确认。不同 ID 是不同工单，不算冲突；同 ID 完全相同只是重复，保留一条即可。

核对一致后再继续。如果平均值出现 39 分钟，让 Qoder 检查是否错误地除以了全部 5 单。如果没读到文件、脚本报错或数字不符，先在这个 Chat 中让它修复并实际重跑，再保存核对后的日报和实际使用的处理代码。

2. 把刚才成功的方法提炼成 Skill

现在有什么：同一个 Chat 中已有输入、规则、处理代码和核对正确的日报。

你要做什么

留在刚才的 Chat，请它把已经做对的方法保存成完整 Skill 包。自己的练习技能统一命名为 my-ticket-daily-report，方便和后面的参考包区分。本步只生成文件，安装在第三步做。

日报已核对正确。请把刚才的方法整理成 my-ticket-daily-report.zip，供新 Chat 复用。
保存已确认的业务规则和实际用过的处理脚本。入口 SKILL.md 含 name、description 元数据，写清使用条件、输入、调用包内脚本及停止条件。新 Chat 只给输入文件、日期和新输出目录就能运行，不依赖旧聊天或本机固定路径。
沿用异常停止和保留已有文件的规则，在当前练习目录生成完整 Skill 文件夹与 ZIP，告诉我位置。本步只生成，暂不安装。

应该看到什么

Qoder 给出 my-ticket-daily-report.zip 的文件位置，列出里面保存的内容：

• SKILL.md：何时使用、需要什么输入、怎样处理、何时停止。
• 已确认的业务规则：日期筛选、去重和平均耗时的口径。简短规则可写在 SKILL.md，较长时放 references/。
• 处理脚本：保存已经核对过的计算方法，供下次调用。

另行保留第一步的输入和确认结果，供第四步核对。如果它只在 Chat 中输出了一段说明，让它继续生成完整文件夹并压缩。打开 Skill 说明，检查规则是否与第一步一致；确认脚本只处理指定的本地文件。

以后每次都要遵守的规则、调用脚本的方法、失败时怎样停止，应保存在 Skill 中。下次用户只提供本次参数。若还需要靠长提示词补齐这些内容，先把遗漏补进 Skill。

有了完整 ZIP 才进入安装。业务同事无需自己编写代码，但要确认保存的方法就是刚才做对的方法。

3. 安装自己刚创建的 Skill

现在有什么：第二步生成的 my-ticket-daily-report.zip，尚未安装。

你要做什么

1. 在 Qoder 左侧打开扩展 → 技能。
2. 选择添加技能 → 上传 Skill，选中第二步的 my-ticket-daily-report.zip 并打开。这里上传自己创建的完整包。
3. 安装成功后，会进入扩展管理 → 技能，在本地 Skill列表中确认 my-ticket-daily-report 和“已安装”标记。同名技能已经存在时，先核对版本，避免覆盖别人的内容。

操作依据：Qoder 官方安装指南。不同版本的按钮名称可能略有差异，找到上传本地技能的入口即可。

应该看到什么

已安装列表里出现你的技能名称。点返回应用，再新建一个任务，在输入框键入 /，建议列表中也能找到它。选中后，输入框会出现 @my-ticket-daily-report 标签。

如果找不到，先检查 ZIP 中是否包含 SKILL.md 和所需脚本。可以把报错给刚才创建文件的 Chat，请它检查包结构。安装成功后进入第四步。

4. 在新 Chat 中验证能否复用

现在有什么：已安装的日报 Skill，以及第一步保存的输入和正确结果。

你要做什么

1. 在电脑上新建一个“工单日报验证”文件夹，只把第一步的 normal.json 复制进去。保留原练习文件夹和正确日报，供核对。
2. 新建一个全新的任务，不沿用前两步的 Chat。按第一步添加工作区的方法，选择刚建的验证文件夹；确认输入框下方显示这个目录。
3. 输入 /，选择 my-ticket-daily-report。看到 @my-ticket-daily-report 标签后，在它后面粘贴下面的提示词。输出使用一个新的文件夹。

用 normal.json 生成 2026-10-10 的工单日报，保存到新的 ticket-second-run 文件夹。

应该看到什么

Qoder 读取已安装的 Skill，调用其中保存的处理脚本，交付新的日报和核对记录。日报仍为 5 单、完成 3 单、待处理 2 单，完成单平均耗时 65 分钟。

展开回复中的执行工具，查看加载的技能和实际运行的脚本，打开交付文件核对数字。脚本应该来自已安装的 my-ticket-daily-report，而非临时重写或原练习目录的副本。不同产品的安装路径和脚本名可以不同。新的验证文件夹只放输入数据，方便分辨来源。如果它要求你重新讲业务规则，返回第二步补齐 Skill，再更新安装并重试。

再试一次变化和一次异常

• 下载变化样例 changed.json，放进同一验证文件夹。另开新 Chat，仍选择验证目录和同一个 Skill，把提示词中的输入改为 changed.json、日期改为 2026-10-11，输出改为新的 ticket-changed-run。应该得到 1 单完成、0 单待处理、总耗时 30 分钟、平均 30 分钟。
• 下载缺字段样例 missing-field.json，放进同一验证文件夹。另开新 Chat，仍选择验证目录和同一个 Skill，把输入改为 missing-field.json，日期仍用 2026-10-10，输出改为新的 ticket-missing-run。应该指出缺失字段并停止，不生成成功日报。

这轮练习完成的标志：普通 Chat 中做对一次，保存成 Skill 并安装；新 Chat 能复用，同口径处理变化，遇到缺字段能停下来。记下输入、日期、实际结果、输出位置和遇到的问题。

这一步完成结果与安装复用的基础验证。Evals 的版本比较和生产观察另见进阶理论：评估 Skill 的表现。

进阶阅读：四步完成后再看

四步解决“保存的方法能否在新 Chat 复用”。下面分别说明方法怎样组织、验证怎样准备与执行，以及怎样比较版本和分享。

• 看懂方法：步骤、AI 推理与固定代码；参考包目录。
• 准备和执行验证：下载参考包；先计划，再生成检查文件；重跑程序检查；让 LLM 核对实测结果。
• 比较和分享：Golden Tasks 与版本比较；换人复用；教学成熟度。

处理方法：步骤、AI 推理与固定代码

对应课件第 5、6 页。Workflow 安排任务怎样推进，Data Processing 负责数据处理；两个层次都可以使用 AI 和代码。

例如同一 ID 的耗时出现 60 和 90，固定检查应报告冲突；AI 解释差异，等业务确认后再处理。字段名或口径改变也要先确认，参考脚本会拒绝不符合契约的输入。用了固定代码仍要核对可信答案，后面的程序回归检查用于发现代码本身的错误。

Tests 与 Evals：可以共用同一套判定标准

Tests（测试）检查行为是否符合预期，例如数字是否正确、权限是否拒绝、异常时是否停止。Evals（评估）用代表性任务观察 AI 的表现，并支持版本比较与持续改进。Task eval 经常直接使用 tests 中相同的断言来判定任务成功，两者高度重叠。

直接运行脚本得到 65，证明这次计算符合预期；把任务交给 Qoder，再核对文件和实际调用，验证的是安装后能否复用。工单案例适合完成这些基础检查。要比较 Skill 的改进效果，需要一批有代表性的任务和可比较的运行记录。

评估可以由程序执行。评估程序发起 Agent 任务、收集结果，再运行 Tests 或其他评分规则。人也可以启动任务、查看记录、核对同样的标准。执行者是谁不决定它属于测试还是评估。数字、文件和状态优先用程序核对，主观质量可用明确标准请人或模型评审。

独立预期是判定依据。本例依据业务规则和明细，提前确认平均耗时为 65 分钟。这个答案可以同时供脚本测试和任务评估使用，独立性取决于依据，放在包内、包外均可。详细例子见独立预期与错误分母。

已有 Skill 后，可以用只读自评提示词定位缺口。自评阅读文件并给出建议，实际表现仍以运行记录为准。

统一目录：tests 放程序测试，evals 放 AI 任务场景

对应课件第 7 页，下面展示实际参考包。SKILL.md 留使用说明；references/ 放详细规则；scripts/pipeline.py 合并检查、处理和校验。简单任务可以只有入口文件，模板等资源按需放 assets/。

参考包与课件使用同一套目录。tests/ 放程序检查、输入样例和已确认答案；evals/ 放让 AI 完成的任务与判定标准，直接复用 tests 中的样例和答案。

ticket-daily-report/
├── SKILL.md
├── references/
├── scripts/pipeline.py
├── tests/
│   ├── check-regression.py
│   ├── fixtures/
│   ├── expected/
│   └── example-results/
└── evals/
    ├── evals.json
    └── README.txt

程序测试运行 tests/check-regression.py；AI 任务按 evals/evals.json 在 Qoder 新 Chat 中逐案执行。执行后怎样核对，见evals.json 的使用例子与 evals/README.txt。实际结果另存包外的新目录。当前参考包没有自动评估程序。

参考包：对照已有实现

下载完整参考练习包 · 下载现成 Skill ZIP

参考 Skill 名为 ticket-daily-report，包含固定脚本和已确认的预期。它与四步中自己创建的 my-ticket-daily-report 是两个包。需要对照实现时再看；导入参考包属于练习使用现成 Skill。

安装方式见完整参考包的 GUIDE.txt，文件按上面的统一目录组织。参考包供对照和检查使用；执行任务时，只给 AI 本案的提示词与输入。

python3 scripts/pipeline.py \
  --input tests/fixtures/normal.json --date 2026-10-10 \
  --out ../ticket-first-run

为自己的 Skill 准备验证：先计划，再生成文件

对应课件第 10 页。已有 Skill 时，可先用只读自评定位缺口。自评给出问题与建议；下面的检查计划确定怎样验证。两者都不会直接生成 tests、evals 或运行任务。

1. 先确认检查什么

先准备自己的完整 Skill、输入样例和已经确认的答案或评审标准，让同一个 Chat 能读到这些材料。工单练习可借用参考包的 tests/fixtures 和 tests/expected，但自己的脚本名称、参数与输出格式以实际实现为准。使用下面的请求，应该得到一张场景表：正常、可处理变化、应停止异常，每案有输入、标准及依据、运行方式和通过条件。例如日报正常案确认平均 65，缺字段案确认停止。逐案核对计划，纠正后再确认；没有可靠依据的标准标为待确认。

若 AI 找不到文件，补充 Skill 和材料文件夹的完整路径，确认它能读取后再继续。

只读这个 Skill，准备正常、变化和应停止场景的检查计划。每案列输入、可信答案或评审标准及依据、运行方式和通过条件，分清脚本测试与 Agent 任务评估。缺少标准标待确认。只写计划，暂不运行、修改或安装。

2. 计划确认后，再生成检查文件

留在同一个 Chat，明确回复计划已确认，再发下面的请求。它要求生成与参考包职责类似的 tests 和 evals：可机械判定的内容有程序检查，AI 任务有提示、输入和核对标准，两者共用样例与答案。写作质量等内容可保留人工或 LLM 的评审标准，不强行写成程序断言。

按确认的计划，为这个 Skill 补齐 tests/ 和 evals/evals.json，适配现有接口与输出。样例和已确认答案随包保存，两类检查共用，不能用当前输出反推答案。能程序判定的写成可运行检查，其余保留评审标准；evals 写任务、路径和核对项。更新使用说明，注明有无自动评估程序；缺标准标待确认。不覆盖无关文件。只生成，暂不运行、安装或发布。

应该看到：实际生成的文件路径、内容清单和使用说明，待确认项单列。样例放 tests/fixtures，答案放 tests/expected，程序检查和 evals 引用同一份文件，复制完整 Skill 到新目录后仍能找到。检查 Skill 名称、脚本路径、参数、输出格式和业务标准是否适用于自己的实现；my-ticket-daily-report 不能直接套用参考包中的技能名和脚本路径。生成文件后仍要实际运行，不能把“已生成”当作“已通过”。

若样例或答案还留在包外，或检查程序没有读取它声称共用的答案文件，先让 AI 修正，再运行。生成请求并不保证一次写对。

3. 运行检查，保留结果，再核对 Agent 任务

先让 AI 按新生成的使用说明运行程序检查。应该看到每案的预期与实际、命令、退出码和汇总，记录保存在包外的新目录。失败时先定位：可能是业务代码，也可能是检查程序或路径问题。不能为了显示 PASS 改掉已确认的答案。

每轮选择未使用过的输出位置，保留旧结果。若检查程序要求目录尚不存在，让程序创建，不要先手动建好。

按使用说明运行这些程序检查，结果保存在包外的新目录，保留命令、退出码和失败记录。有问题先定位原因，再修复并重跑；不要为通过检查改动已确认答案。

程序检查通过后，按自己 evals.json 的一案，在新 Chat 中给 Agent 任务与输入，再保留输出和工具执行记录，交给核对者评审，操作见下一节的 LLM 核对例子。使用自己的场景 ID 和实际输出文件；自己的 Skill 若输出 Markdown，就核对 Markdown，不要求它生成参考包的三个文件。程序测试通过不会替你完成这些 Agent 任务。

修改后，批量重跑已知案例

这就是回归检查：修过一个问题后，确认以前能处理的任务仍然正常。既要重跑程序测试，也要重跑受影响的 AI 任务评估。业务同事可以重复第四步；技术同事可以把这些检查自动化。

python3 tests/check-regression.py --out ../ticket-regression-first

为自己的 Skill 执行验证前，先按准备验证确认场景和文件。数据任务核对数字，写作分析核对来源与内容质量，流程任务核对执行分支和停止。程序结果与 Agent 执行记录分别留存，未运行部分保持待验证。

为什么还要用独立预期核对

独立预期就是运行前确认的正确答案或评审标准。本例先依据明细和业务规则算出 195 ÷ 3 = 65，再拿这个答案核对实际输出。它可以同时用于程序测试和 AI 任务评估。

参考包中的受控教学副本曾把平均耗时除以全部 5 单，得到 39 分钟；内部数量检查仍通过。独立预期为 195 ÷ 3 = 65 分钟，批量检查因此报告 FAIL。修正分母后，四案重跑通过。

原记录在 tests/example-results/ 的 before-fix.json 与 after-fix.json。正式参考 Skill 没有注入错误，预期文件也没有为迎合输出而修改。

遇到错误，修复规则或实现，再用新目录重跑。保留失败记录；业务规则改变时，先确认新口径，再更新预期。

参考包的已确认答案统一放在 tests/expected/，供程序测试和 AI 任务评估共用。“独立”指答案来自已确认的业务规则。评估时只把任务和输入交给受测 AI，正确答案由核对者保留。

evals.json 怎么用：交给 LLM 核对实测结果

evals.json 保存任务与判定标准，本身不会运行或评分。Skill 作者或核对者读取它，先让受测 Agent 完成任务，再由人工或负责评审的 LLM 核对实际结果。业务同事可在安装、修改或分享前重复这组检查。

例子：参考 Skill 的正常案 id=1

1. 先按参考包 GUIDE.txt 安装现成 Skill ticket-daily-report，再把 tests/fixtures/normal.json 复制到新的验证文件夹。在 Qoder 新 Chat 中选择这个文件夹和 Skill，发送场景 1 的 prompt：
   用 normal.json 生成 2026-10-10 的工单日报，保存到新的 ticket-normal-run 文件夹。
2. 任务结束后，保留实际生成的 report.json、report.txt 与 evidence.json。展开执行工具，把技能加载、实际脚本路径、参数、退出状态和有关回复复制为 execution-record.txt。无法取得的部分注明缺失，不凭印象补写。
3. 新建独立的评审文件夹。复制参考包的 evals/evals.json 和 tests/expected/2026-10-10.json，保留这两个相对路径；把本次三个输出文件放到 actual/，执行记录放在文件夹根目录。另开能读取这些材料的评审 Chat，选择该评审文件夹，发送下面的短请求。受测任务只收到任务和输入，答案留给评审方。

只核对 evals/evals.json 中 id=1 这一案，对照它引用的预期答案、actual/ 的本次输出和 execution-record.txt。逐项给出核对项、PASS/FAIL/UNKNOWN、文件或日志证据和理由。证据不足记 UNKNOWN，明确不符记 FAIL；不能用自报 PASS 代替调用日志；最后汇总本案结论。只做核对，不重跑任务或修改文件。

应该看到：逐项结论、引用的文件或日志证据、理由和本案汇总。数字应逐字段与已确认答案比对；脚本调用必须有执行记录，不能仅凭日报正确或 evidence 自报 PASS 推断。数字和文件存在性适合程序核对；过程记录也可由人工或 LLM 审阅。

当前没有自动评估程序。本例由人启动任务、整理材料、发起 LLM 核对；tests/check-regression.py 只运行固定脚本。程序也能把 evals.json 当配置，用于批量发起 Agent 任务、收集记录、调用程序或 LLM 评分并汇总，但本包没有实现这条链路。一次核对不构成前面的版本比较或生产评估，比较方法见Golden Tasks 理论。

进阶理论：评估 Skill 的表现

下面用三个视角理解 Evals。这是本课的教学分类，各平台的名称和范围可能不同。它们都要先明确任务和判定标准，再保留实际运行证据。

Golden Tasks：固定一批真实端到端需求

以一个协助开发网站的 Agent 为理论示例：从实际工作中选 10 个有代表性的完整需求，覆盖登录、支付、权限、超时、异常处理等。每个需求都包含真实输入、成功条件和判定依据。这批固定任务作为 Golden Tasks；别只挑容易通过的情况，也别只凭任务数量判断覆盖是否充分。

例如一个权限场景，最终条件是无权限用户确实无法访问目标数据。先用 Tests 固定这个条件，再让不同 Skill 版本的 Agent 完成同一需求；两个版本用相同断言判定。

下面全部是假设结果，用于理解比较方法：

V1 是本次比较的 Baseline（基线）。固定任务和统一判定方法提供 Benchmark（比较基准），运行后汇总各版本的表现。也可以根据目标选择不安装 Skill 或上一版作为基线。

这里成功率提升 20 个百分点。还要同时比较质量、耗时、Token 和失败原因：更常成功是否增加了成本？失败是规则遗漏、工具报错，还是业务口径不清？数字相同也可能有不同的交付质量，需要合适的评分标准。

什么时候才能说改进有效

两个版本使用相同任务、输入和 Tests，保持模型、工具、权限、运行预算及环境一致，每次用独立上下文。重要场景多次重复，观察成功率和耗时波动。换 Skill 的同时又换模型，就难以把变化归因给 Skill。

60% 与 80% 是教学示例。单轮 10 个任务不能证明提升稳定；需要多次重复、控制其他变量，并检查是否只对这批样例有效。保留失败任务，改后重跑；再用未参与调优的新任务检查能否推广。

上线后再看 Production

上线以后，真实请求会出现新表达、新数据和新异常。持续抽样核对结果，记录失败、人工接管、质量、耗时与成本，把代表性问题脱敏后补入任务集。离线 Golden Tasks 的分数提供参考，真实使用效果还要靠这些生产记录判断。

本课没有测量生产指标，也没有用工单练习宣称版本收益。想做自动评估时，需要执行工具启动 Agent、收集记录、调用判定规则并汇总；只有 evals 文件夹或一份计划不会自动产生评估结果。

准备分享时，换一位同事再试

带上完整 Skill、输入样例和独立预期，让同事安装同一版本，在全新 Chat 中重复正常、变化和异常案例。记录产品版本、是否找到 Skill、实际脚本、输出位置及差异。另一台机器没跑过，就保持待验证。

教学成熟度 L0–L4

用于团队讨论的参考模型，属于工程建议。

跟练遇到问题

填写下面的模板后，自行反馈给张坚、李琦；复制模板不会自动通知。说明卡在第几步，附脱敏输入、预期与实际、出错截图和结果记录。真实客户数据继续遵守原项目权限和处理约定。

问题反馈给张坚、李琦
使用的 Skill 和版本：
期望得到什么：
实际发生什么：
使用的产品和版本：
附件：脱敏输入样例、出错截图、校验记录
请先移除客户信息、账号和密钥。

依据与内容范围

Agent Skills 格式规范 · Qoder 安装与使用指南 · Skill 任务评估方法 · Skill 触发评估方法 · Agent 评估与生产观察

本页修订于 2026-10-14。输入和预期沿用虚构工单案例；下载的十页课件（含海报封面）与讲解材料沿用课程 v2.7。