进阶跟练：检查、评审与分享

基础练习完成后，再按需继续

先完成基础四步与完成检查。本页用你创建的 my-ticket-daily-report 继续，目标是准备可重复的检查材料；不需要一次做完全部进阶内容。

1. 可选自评：只读定位问题。
2. 确认检查计划，再生成 tests/evals 文件。
3. 实际运行程序检查，保留失败与修复记录。
4. 新 Chat 执行任务，再让人工或 LLM 核对输出与执行记录。

tests 是程序测试与样例，evals 是 AI 任务及核对标准。这里继续使用基础练习已确认的 65 分钟等答案；详细原理放在深入阅读。若要借用样例，可下载参考包，保留自己的技能名称、脚本接口和输出格式。

开始准备检查 →

可选：先用只读自评定位缺口；自评后返回本页继续。

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

对应课件第 11 页。已有 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 任务。

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 理论。

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

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

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

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

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

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

参考包：对照已有实现

下载完整参考练习包 · 下载现成 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 和版本：
期望得到什么：
实际发生什么：
使用的产品和版本：
附件：脱敏输入样例、出错截图、校验记录
请先移除客户信息、账号和密钥。