一个检查数据文件的 Agent 遇到缺少日期列的输入，仍然算出了异常率。你给 Skill 加上“缺少字段时不要猜测”，下次它又被另一段“必须完成分析”的要求推着往下走。此时继续强调“务必遵守”很难解决问题，需要查清哪些规则同时生效，以及程序在输入不完整时应该返回什么。
先保存失败现场，不急着改正文
上面的数据检查只是一个说明方法的假设场景。原文引用过 Skill 从四百行增长到一千五百行的案例，但没有提供足够的原始实验材料，因此这里不把它作为效果证据。文件变长值得检查，却不能据此断定准确率一定下降；删短以后是否更好，也要通过任务对照确认。
第一次整理时，保存用户输入、加载过的规则版本、工具返回和最终输出。尤其要区分“模型没有读到要求”与“读到了相互矛盾的要求”。前者可能是触发描述或引用路径的问题，后者才需要改写规则关系。只保留最后一句错误回答，往往看不出故障发生在哪一步。
在数据例子里，先确认工具有没有报告缺少日期列。如果工具已经返回明确错误，Agent 却继续编造结果，应检查错误处理说明；如果工具把缺失值默认为今天，则要先修工具。不要让自然语言规则替一个有错误默认值的程序长期兜底。
把一句要求写到可以判断是否通过
“认真检查数据质量”无法告诉执行者，缺字段时究竟该继续还是停止。可以把这段要求改成下面的形式。它是面向假设任务的规则示例，需要按实际字段调整，并非某个模型的通用保证。
输入检查：
读取列名，确认包含 date、metric、value。
缺少任意必需列时，返回 missing_columns 和缺失列名。
本次结果标记为 input_invalid，不生成异常率。
列名完整时，再执行数值类型和日期格式检查。
这里补全了触发条件、执行顺序和可观察结果。“不生成异常率”仍是一项必要限制，但与它配套的下一步已经明确。检查者可以读取结构化结果，也可以断言异常率字段没有出现，不必靠语言是否严厉来判断。
同时处理原先的“必须完成分析”。把完成定义改为两条合法终点：有效输入产出分析，无效输入产出可修复的错误说明。这样缺字段不会再被当作没完成任务，也无需额外添加“除了特殊情况”的长段落。
给重复规则找一个归属位置
把当前文件复制到一个候选分支，按行为逐项整理：何时触发、依据是什么、调用哪个工具、怎样处理失败、什么算完成。不同段落若只是重复“不要猜”，可以合并；若一个说缺字段就停止，另一个说自动补全，就必须由维护者决定适用范围。
合并前要检查差异是否有意义。例如“公开示例允许生成假数据”和“生产分析不得补造记录”可以同时成立，前提是场景明确。若只是删掉其中一句，可能让演示任务变得难用，或让正式任务误用样例。去重时保留条件，删除同义的修辞。
可以给稳定规则加简短标识，比如 INPUT-01，但不必把整个文件变成复杂制度。标识的用途是让失败样本、变更记录和测试结果指向同一条要求。读者看到“缺列样本验证 INPUT-01”时，应该能立刻找到对应行为，而不是再查另一套编号手册。
主文档负责路线，参考文件负责细节
Agent Skills 规范定义了主文件、元数据以及可选资源目录，并采用按需要逐步加载信息的组织方式。这给整理提供了一个实际办法：主文档说明任务入口和关键步骤，某种文件格式的细节放进单独参考，在走到该分支时再读取。
例如，主文件只说明“确认文件类型，按相应格式检查字段”；CSV 编码约定可以放在格式参考里，历史事故留在测试目录。引用时写出触发条件和具体文件，不要只说“更多内容见文档”。如果模型必须猜该打开哪份资料，挪动文件并没有减少工作。
Anthropic 的编写建议强调简洁、清楚的描述和实际使用测试，并建议主文件保持在五百行以内。这个数字属于该文档的组织建议，不是所有宿主共同强制的格式上限，也不是超过一行就会失效的性能阈值。更值得检查的是一次任务到底需要读取多少无关内容。
拆分后重新检查链接。主文件说日期采用某种格式，示例却保留另一种格式，会让同一问题换个位置继续出现。共享定义尽量保留一个权威位置；其他地方引用它，避免每次修复都同步修改多份近似文本。
回归样本要包含正常任务
只加入缺日期列的样本，会让维护者看不出新规则是否误伤其他情况。可以先准备六个小文件：正常输入、缺日期列、缺数值列、列名完整但日期错误、允许额外列的输入，以及只有表头没有数据行的输入。每个样本都写清预期状态和允许出现的字段。
这六种情况还揭示一个设计问题：空数据与缺字段是否相同？通常不是。列结构完整但没有记录时，可以返回空数据状态；缺少列则需要用户修正输入格式。把它们合并成“分析失败”，虽然省事，却会让使用者不知道下一步该补数据还是改文件。
测试里尽量检查行为，不要绑定一段固定措辞。有效输入应能分析，缺列输入应指出缺哪一列；在这些条件满足以后，错误说明采用哪一种自然语言不必完全一致。若输出必须供程序读取，再用 schema 检查必填字段和类型。
还要保留一个相似但不该触发的任务。例如用户只是询问日期字段的含义，Agent 不应强行要求上传 CSV。这样可以检查 Skill 的选择范围，而不仅是加载后的执行质量。
对照运行时，一次只改一类东西
把旧版本和候选版本放在同样的任务集下比较，保持模型、工具、输入与采样设置尽可能一致。先记录二者的错误类型，再决定是否扩展测试。若同时升级模型、替换工具并精简规则，结果即使改善，也很难归因到哪一项变化。
有些任务存在输出波动，重复运行比只挑最好的一次更有信息。保存全部结果，观察候选版本是否减少了缺字段后继续计算的情况，以及正常输入是否仍能完成。小样本只能帮助发现具体问题，不能据此宣称整体提升了某个百分比。
自动检查能覆盖输出结构和明确动作，语义是否符合业务仍需适当人工复核。比如日期列确实存在，但用户明确要求比较两个不重叠时期，这可能需要任务层面的判断。不要为了方便自动评分，把业务问题缩减为“某几个词出现了就算通过”。
自动修复可以提建议，先让它解释改动
如果让 Agent 根据失败记录维护 Skill，可以要求它先给出候选差异：这次修改对应哪个失败，已有哪条规则接近，为什么不能只改工具或增加样本。每一项新增要求都应能找到触发它的证据。
新增规则进入候选版本后，跑相关样本和正常任务，再决定是否发布。涉及外部写入或权限扩大时，按团队实际的变更规则审核。审核重量可以与影响相称，修正一个失效链接不必采用与生产数据库操作同样的流程。
长度预算适合用来提醒维护者复查，而不是机械删字。可以规定主文档增长到某个规模时检查重复内容、引用层级和加载范围；没有必要为了满足行数，把必要条件压缩成难以理解的一句话。目标是让下一位维护者知道为什么这样做，以及怎样验证修改没有破坏原有行为。
回退时把相关文件一起恢复
发布前保存主文件、引用资料和相关脚本的版本，以及这次使用的测试集。只回退 SKILL.md，却留下新版工具参数，可能制造新的不兼容。对于成套维护的资源，记录一个可以复现的版本组合，比只保存文件修改日期更有用。
回退后重跑导致此次变更的样本和正常输入。如果必须暂时恢复旧行为，也应保留已知问题说明，避免下一位维护者又把同一事故写成新补丁。失败样本可以继续留在候选改进清单里，不需要为了让现有版本全部显示绿色而删除。
整理结束后，回到最初那个缺字段文件：程序有没有识别缺失，Agent 有没有给出可执行的修复提示，是否停止了不具备依据的计算。能回答这几项，再看文件是否更短。这样每次删改都有具体目标，也能保留那些虽不简短、却确实承担必要职责的规则。