从宏观层面来说技能的培养过程大致如下确定你希望这项技能实现什么功能以及它大致应该如何实现。撰写一份技能草案创建一些测试提示并运行 claude-with-access-to-the-skill 命令来测试它们。帮助用户对结果进行定性和定量评估在后台运行期间如果没有定量评估请拟定一些评估结果如果有您可以直接使用也可以根据需要进行修改。然后向用户解释这些评估结果或者如果已有评估结果请解释已有的结果。使用该eval-viewer/generate_review.py脚本向用户展示结果并允许他们查看量化指标。根据用户对结果的评价反馈以及量化基准测试中发现的任何明显缺陷重写该技能。重复操作直至满意为止。扩大测试集并在更大规模上再次尝试。使用这项技能时你的任务是弄清楚用户在这个过程中处于哪个阶段然后介入并帮助他们逐步完成各个阶段。例如他们可能说“我想为 X 创建一个技能”。你可以帮助他们缩小范围撰写草稿编写测试用例确定他们希望如何评估运行所有提示然后重复上述步骤。另一方面他们可能已经有了技能的草稿。在这种情况下你可以直接进入循环的评估/迭代部分。当然你应该始终保持灵活如果用户说“我不需要进行大量的评估只要和我感觉合拍就行了”你也可以这样做。然后在技能完成后但同样顺序是灵活的您还可以运行技能描述改进器我们为此编写了一个单独的脚本以优化技能的触发。酷吗酷。与用户沟通技能创建工具的用户群体可能涵盖各种编程术语水平。如果你还没听说过这怎么可能呢毕竟它出现不久现在有一种趋势Claude 的强大功能正促使水管工打开终端甚至让父母和祖父母上网搜索“如何安装 npm”。另一方面大多数用户可能都具备相当的计算机知识。所以请注意语境线索以便更好地措辞举个例子简单来说“评估”和“基准”这两个词用在这里有点勉强但还可以接受。对于“JSON”和“断言”你需要看到用户明确表示他们了解这些概念然后再使用它们而无需解释。如果对术语有疑问可以简要解释一下如果不确定用户是否能理解也可以用简短的定义来澄清术语。培养技能捕捉意图首先要了解用户的意图。当前的对话可能已经包含用户想要记录的工作流程例如他们说“把这个变成一项技能”。如果是这样首先要从对话历史记录中提取答案——使用的工具、步骤顺序、用户所做的更正、观察到的输入/输出格式。用户可能需要补充信息并且在进行下一步之前应该得到确认。这项技能应该能让克劳德做什么此技能应在什么情况下触发用户使用哪些短语/情境预期输出格式是什么我们是否应该设置测试用例来验证技能是否有效对于输出结果客观可验证的技能例如文件转换、数据提取、代码生成、固定工作流程步骤测试用例非常有益。而对于输出结果主观的技能例如写作风格、艺术创作通常不需要测试用例。建议根据技能类型提供合适的默认值但最终由用户决定。访谈与研究主动询问有关边界情况、输入/输出格式、示例文件、成功标准和依赖项的问题。在彻底解决这些部分之前不要编写测试题。检查可用的 MCP多级协作平台——如果对研究有用例如搜索文档、查找类似技能、查找最佳实践则尽可能通过子代理进行并行研究否则直接在线进行。准备好相关背景信息以减轻用户的负担。编写 SKILL.md 文件根据用户访谈内容填写以下部分名称技能标识符描述何时触发以及触发效果。这是主要的触发机制——请同时包含技能的功能以及具体的使用场景。所有“何时使用”的信息都应在此处说明而非正文。注意目前 Claude 倾向于“触发不足”技能——即在技能有用的时候却不使用。为了解决这个问题请让技能描述更具“说服力”。例如与其写“如何构建一个简单的快速仪表盘来显示 Anthropic 的内部数据”不如写成“如何构建一个简单的快速仪表盘来显示 Anthropic 的内部数据。只要用户提及仪表盘、数据可视化、内部指标或者想要显示任何类型的公司数据即使他们没有明确要求使用‘仪表盘’也请务必使用此技能。”兼容性所需工具、依赖项可选很少需要剩下的技能 写作技巧指南技能剖析skill-name/ ├── SKILL.md(required)│ ├── YAML frontmatter(name, description required)│ └── Markdown instructions └── Bundled Resources(optional)├── scripts/ - Executable codefordeterministic/repetitive tasks ├── references/ - Docs loaded into context as needed └── assets/ - Files usedinoutput(templates, icons, fonts)渐进式披露技能采用三级加载系统元数据名称 描述 - 始终与上下文相关约 100 字SKILL.md 正文- 技能触发时显示的上下文理想情况下少于 500 行捆绑资源- 按需提供无限制脚本无需加载即可执行这些字数只是大概的如果需要的话你可以随意增加字数。关键模式SKILL.md 文件应控制在 500 行以内如果接近此限制请添加额外的层级结构并提供清晰的指示说明使用该技能的模型接下来应该去哪里进行跟进。参考文件明确来自 SKILL.md并附有何时阅读它们的指导。对于篇幅较长的参考文献文件超过 300 行请添加目录。领域组织当一项技能支持多个领域/框架时按变体进行组织cloud-deploy/ ├── SKILL.md(workflow selection)└── references/ ├── aws.md ├── gcp.md └── azure.mdClaude 只读取相关的参考文件。缺乏意外原则这一点无需赘言技能绝不能包含恶意软件、漏洞利用代码或任何可能危害系统安全的内容。如果技能内容已明确描述其意图不应令用户感到意外。切勿接受创建误导性技能或旨在促进未经授权访问、数据窃取或其他恶意活动的技能的要求。不过像“扮演XYZ”这样的技能是可以接受的。写作模式指令中最好使用祈使句。定义输出格式——您可以这样做## Report structureALWAYS use this exact template:# [Title]## Executive summary## Key findings## Recommendations示例格式- 添加示例很有用。您可以按如下格式编写示例但如果示例中包含“输入”和“输出”则可能需要稍作调整## Commit message format**Example1:** Input: Added user authentication with JWT tokens Output: feat(auth): implement JWT-based authentication写作风格尝试向模型解释事物为何重要而不是生硬地灌输“必须”之类的生硬观念。运用心智理论并尽量使技能具有普遍性而不是局限于具体的例子。先写个草稿然后用全新的视角审视并改进它。测试用例写完技能草案后想出 2-3 个真实的测试提示语——就像真实用户可能会说的话。把这些提示语分享给用户[不必完全照搬这句话]“这里有一些我想尝试的测试用例。这些看起来合适吗或者您想添加更多”然后运行这些测试用例。将测试用例保存到指定位置evals/evals.json。暂时不要编写断言只需编写测试提示即可。您将在下一步测试运行过程中编写断言。{skill_name:example-skill,evals:[{id:1,prompt:Users task prompt,expected_output:Description of expected result,files:[]}]}请references/schemas.md参阅完整架构包括assertions稍后将要添加的字段。运行和评估测试用例本部分内容为连续序列请勿中途停止。请勿使用/skill-test任何其他测试技巧。将结果放在skill-name-workspace/技能目录的同级目录下。在工作区中按迭代例如iteration-1/ test1、test2、iteration-2/test3 等组织结果并在每个迭代中为每个测试用例创建一个目录例如eval-0/eval-1/test1、test2、test3 等。不必预先创建所有这些目录只需在编写代码时创建即可。步骤 1在同一回合生成所有跑图包括技能跑图和基础跑图。对于每个测试用例在同一回合内生成两个子智能体——一个拥有该技能一个没有。这一点很重要不要先生成拥有该技能的子智能体然后再返回生成基准测试。所有测试用例都要同时启动以便它们几乎同时完成。熟练跑动Execute this task: - Skill path:path-to-skill- Task:eval prompt- Input files:eval filesifany, ornone- Save outputs to:workspace/iteration-N/eval-ID/with_skill/outputs/ - Outputs to save:what the user cares about — e.g.,the .docx file,the final CSV基准运行提示相同但​​基准取决于上下文创建新技能根本没有技能。提示信息相同没有技能路径保存到without_skill/outputs/.改进现有技能旧版本。编辑前先对技能进行快照cp -r skill-path workspace/skill-snapshot/然后将基线子代理指向该快照。保存到old_skill/outputs/。为每个测试用例编写一个eval_metadata.json评估语句目前断言可以为空。根据每个评估语句测试的内容为其指定一个描述性的名称而不仅仅是“eval-0”。同时也将其用于评估语句所在的目录。如果本次迭代使用了新的或修改后的评估语句提示请为每个新的评估语句目录创建相应的文件不要假设它们会从之前的迭代中继承过来。{eval_id:0,eval_name:descriptive-name-here,prompt:The users task prompt,assertions:[]}步骤二在运行过程中草拟断言不要只是等待测试运行结束——你可以利用这段时间做些更有意义的事情。为每个测试用例编写量化断言并向用户解释这些断言。如果测试用例中已经存在断言evals/evals.json请审查它们并解释它们检查的内容。好的断言应具有客观可验证性并配有描述性名称——它们在基准测试查看器中应清晰易懂以便查看结果的人能够立即理解每项断言所考察的内容。主观技能例如写作风格、设计质量更适合进行定性评估——不要将断言强加于需要人为判断的事物上。草案完成后更新eval_metadata.json文件并evals/evals.json添加相关断言。同时向用户解释他们将在查看器中看到的内容——包括定性输出和定量基准测试。步骤 3运行完成后捕获计时数据total_tokens每个子代理任务完成后您会收到包含以下信息的通知duration_ms。请立即将此数据保存到timing.json运行目录中的相应位置{total_tokens:84852,duration_ms:23332,total_duration_seconds:23.3}这是获取此数据的唯一机会——数据通过任务通知传递不会存储在其他地方。请在收到通知时立即处理而不是尝试批量处理。步骤 4评分、汇总并启动查看器所有运行完成后对每次运行进行评分——生成一个评分子代理或进行内联评分该子代理读取agents/grader.md并评估每个断言与输出结果的对应关系。将结果保存到grading.json每次运行的目录中。grading.json 文件中的 expected 数组必须使用 text、 passed 和 字段evidence不能使用name/met/details或其他变体——查看器依赖于这些确切的字段名称。对于可以通过编程方式检查的断言请编写并运行脚本而不是手动检查——脚本速度更快、更可靠并且可以在多次迭代中重复使用。将数据汇总到基准测试中——从技能创建器目录运行汇总脚本python-mscripts.aggregate_benchmarkworkspace/iteration-N --skill-namename这将针对每种配置生成pass_rate、time 和 tokens 数据benchmark.json以及benchmark.md平均值 ± 标准差和差值。如果手动生成 benchmark.json 文件请参阅references/schemas.md文档以获取查看器所需的确切架构。将每个 with_skill 版本放在其对应的基准版本之前。进行一次分析师审核——阅读基准数据找出汇总统计数据可能隐藏的模式。请参阅agents/analyzer.md“分析基准结果”部分了解需要关注的内容——例如无论技能如何都始终通过的断言缺乏区分度、高方差评估可能不稳定以及时间/代币权衡。启动查看器时将同时显示定性输出和定量数据nohuppythonskill-creator-path/eval-viewer/generate_review.py\workspace/iteration-N\--skill-namemy-skill\--benchmarkworkspace/iteration-N/benchmark.json\/dev/null21VIEWER_PID$!对于第 2 次及以后的迭代也传递--previous-workspace workspace/iteration-N-1。**共享办公/无头环境**如果webbrowser.open()服务器不可用或环境没有显示器请使用此方法--static output_path编写独立的 HTML 文件而不是启动服务器。feedback.json用户点击“提交所有评论”后反馈将以文件形式下载。下载后将其复制feedback.json到工作区目录以便下次迭代时读取。注意请使用 generate_review.py 创建查看器无需编写自定义 HTML。可以这样告诉用户“我已经在您的浏览器中打开了结果。有两个标签页——‘输出’标签页允许您点击查看每个测试用例并留下反馈‘基准测试’标签页显示定量比较结果。完成后请回到这里告诉我。”用户在查看器中看到的内容“输出”选项卡一次只显示一个测试用例提示所布置的任务输出该技能生成的文件尽可能以内联方式呈现。先前输出迭代 2 及以上折叠部分显示上次迭代的输出正式成绩如果进行了评分折叠部分显示成绩为通过/未通过。反馈一个会在用户输入时自动保存的文本框先前反馈第 2 次及以后他们上次的评论显示在文本框下方。“基准测试”选项卡显示统计摘要每种配置的通过率、计时和令牌使用情况以及每次评估的细分和分析师观察结果。导航方式为上一页/下一页按钮或方向键。完成后他们点击“提交所有评论”即可将所有反馈保存到系统中feedback.json。第五步阅读反馈当用户告知他们已完成操作时请阅读以下内容feedback.json{reviews:[{run_id:eval-0-with_skill,feedback:the chart is missing axis labels,timestamp:...},{run_id:eval-1-with_skill,feedback:,timestamp:...},{run_id:eval-2-with_skill,feedback:perfect, love this,timestamp:...}],status:complete}如果用户没有反馈说明他们认为产品没问题。你应该重点改进用户提出具体问题的测试用例。使用完毕后请关闭查看器服务器kill$VIEWER_PID2/dev/null提高技能这是循环的核心。你已经运行了测试用例用户也查看了结果现在你需要根据他们的反馈改进这项技能。如何思考改进**从反馈中总结经验。**关键在于我们试图开发出可以在各种不同情境下使用无数次或许真的能用上百万次甚至更多谁知道呢的技能。目前你和用户反复迭代的只是几个例子因为这样可以加快开发速度。用户对这些例子了如指掌能够快速评估新的输出结果。但是如果你和用户共同开发的技能只适用于这些例子那就毫无意义。与其进行繁琐的过度拟合修改或者设置过于苛刻的“必须”条件不如尝试拓展思路使用不同的比喻或者推荐不同的工作模式。尝试的成本相对较低而且或许能带来意想不到的惊喜。**保持提示简洁。**删除那些无用的部分。务必阅读测试记录而不仅仅是最终输出结果——如果发现某个技能让模型浪费大量时间去做一些低效的事情你可以尝试移除导致这种情况发生的部分看看会发生什么。解释原因。务必努力解释你要求模型执行的每一个操作背后的原因。如今的学习型学习模型LLM都很智能。它们拥有良好的心智理论如果给予合适的工具它们就能超越机械的指令真正地完成任务。即使用户的反馈简短或沮丧也要努力理解任务内容以及用户实际输入的内容背后的原因并将这种理解融入到指令中。如果你发现自己总是用大写字母写“ALWAYS”或“NEVER”或者使用过于僵化的语句结构那就需要警惕了——如果可能请重新组织语言并解释原因让模型理解你所要求的事情为何重要。这是一种更人性化、更强大、更有效的方法。**寻找测试用例中的重复操作。**阅读测试运行的日志注意子代理是否都独立编写了类似的辅助脚本或者是否对某些操作采用了相同的多步骤方法。如果所有 3 个测试用例都导致子代理编写了 acreate_docx.py或 bbuild_chart.py则强烈表明该技能应该打包该脚本。只需编写一次将其放入 b 中scripts/并告知技能使用它。这样可以避免每次调用时重复造轮子。这项任务非常重要我们试图创造每年数十亿美元的经济价值你的思考时间不是问题慢慢来仔细斟酌。我建议你先写一个草稿然后再重新审视并进行改进。务必尽力设身处地地站在用户的角度思考了解他们的需求。迭代循环技能提升后将你的改进应用到这项技能中将所有测试用例iteration-N1/包括基线运行重新运行到新目录中。如果您正在创建新技能则基线始终为without_skill无技能——这在所有迭代中保持不变。如果您正在改进现有技能请根据实际情况判断基线用户最初使用的版本还是之前的迭代版本。启动审阅者--previous-workspace指向上一个迭代版本等待用户审核并告知他们已完成。阅读新的反馈意见再次改进重复以上步骤。继续进行直到用户表示他们很开心反馈全部为空一切看起来都很好你没有取得实质性进展。高级盲测如果您需要对同一技能的两个版本进行更严格的比较例如用户询问“新版本真的更好吗”可以使用盲测系统。详情请参阅[此处插入链接]agents/comparator.md。agents/analyzer.md其基本思路是将两个输出结果交给一个独立的智能体但不告诉它哪个是哪个让它自行判断质量。然后分析获胜者的原因。这是可选的需要子代理而且大多数用户都不需要它。人工审核通常就足够了。描述优化SKILL.md 前置元数据中的描述字段是决定 Claude 是否调用技能的主要机制。创建或改进技能后建议优化描述以提高触发准确率。步骤 1生成触发评估查询创建 20 个评估查询——包括应该触发和不应该触发的查询。保存为 JSON 格式[{query:the user prompt,should_trigger:true},{query:another prompt,should_trigger:false}]查询语句必须贴近实际是 Claude Code 或 Claude.ai 用户实际会输入的内容。不要写抽象的请求而是要写得具体明确并包含足够的细节。例如文件路径、用户工作或情况的个人信息、列名和值、公司名称、URL 等。最好能提供一些背景信息。有些语句可能使用小写字母、缩写、拼写错误或口语化的表达。使用不同长度的语句并着重考虑一些特殊情况而不是过于死板用户最终会确认这些语句。坏的Format this dataExtract text from PDFCreate a chart好的ok so my boss just sent me this xlsx file (its in my downloads, called something like Q4 sales final FINAL v2.xlsx) and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think对于应该触发的查询8-10请考虑覆盖范围。你需要用不同的措辞来表达相同的意图——一些正式的一些非正式的。包括用户没有明确指出技能或文件类型但显然需要它的情况。加入一些不常见的用例以及该技能与其他技能竞争但应该优先使用的情况。对于不应触发的查询8-10最有价值的是那些“擦边球”的查询—​​—这些查询与技能共享关键词或概念但实际上需要不同的匹配方式。例如相邻领域、措辞含糊不清简单的关键词匹配会触发但实际上不应该触发以及查询涉及技能的功能但上下文更适合使用其他工具的情况。关键在于避免不要让那些明显无关紧要的“不应触发”查询显得毫无意义。“编写斐波那契函数”作为PDF技能的否定测试就太简单了——它根本没测试任何东西。否定测试用例应该真正具有挑战性。步骤 2与用户一起审核使用HTML模板将评估集呈现给用户以供查看请阅读模板assets/eval_review.html请替换占位符__EVAL_DATA_PLACEHOLDER__→ 包含 eval 项的 JSON 数组无需引号——这是一个 JS 变量赋值__SKILL_NAME_PLACEHOLDER__→ 技能名称__SKILL_DESCRIPTION_PLACEHOLDER__→ 该技能的当前描述写入临时文件例如/tmp/eval_review_skill-name.html然后打开它open /tmp/eval_review_skill-name.html用户可以编辑查询、切换应触发条件、添加/删除条目然后点击“导出评估集”。文件下载到~/Downloads/eval_set.json——请检查“下载”文件夹以获取最新版本以防有多个版本例如eval_set (1).json。这一步很重要——糟糕的评估查询会导致糟糕的描述。步骤 3运行优化循环告诉用户“这需要一些时间——我会在后台运行优化循环并定期检查结果。”将评估集保存到工作区然后在后台运行python-mscripts.run_loop\--eval-setpath-to-trigger-eval.json\--skill-pathpath-to-skill\--modelmodel-id-powering-this-session\--max-iterations5\--verbose使用系统提示符当前会话的提示符中的型号 ID以便触发测试与用户实际体验到的情况相匹配。在程序运行期间定期跟踪输出以便向用户提供当前迭代次数和分数等信息。这段代码会自动处理完整的优化循环。它将评估集拆分为 60% 的训练集和 40% 的预留测试集评估当前描述每个查询运行 3 次以获得可靠的触发率然后调用 Claude 根据失败的描述提出改进建议。它会在训练集和测试集上重新评估每个新的描述最多迭代 5 次。完成后它会在浏览器中打开一个 HTML 报告显示每次迭代的结果并返回 JSON 数据best_description——为了避免过拟合数据是根据测试集得分而不是训练集得分选择的。技能触发机制理解触发机制有助于设计更优的评估查询。技能会available_skills以名称和描述的形式出现在 Claude 的列表中Claude 会根据描述决定是否查询该技能。需要注意的是Claude 只会在自身难以轻松处理的任务上查询技能——例如像“阅读此 PDF”这样简单的单步查询即使描述完全匹配也可能不会触发技能因为 Claude 可以使用基本工具直接处理这类任务。而对于复杂、多步骤或专门的查询只要描述匹配就会可靠地触发技能。这意味着你的评估查询应该足够实质性以便克劳德能够真正从技能查询中受益。像“读取文件 X”这样的简单查询是糟糕的测试用例——无论描述质量如何它们都不会触发技能。步骤四应用结果从 JSON 输出中提取数据best_description并更新技能的 SKILL.md 文件前端信息。向用户展示更新前后的效果并报告得分。打包并赠送仅当present_files工具可用时检查您是否拥有该present_files工具的访问权限。如果没有请跳过此步骤。如果有请打包该技能并将 .skill 文件提供给用户python-mscripts.package_skillpath/to/skill-folder打包完成后引导用户找到生成的.skill文件路径以便他们可以进行安装。Claude.ai 特定说明在 Claude.ai 中核心工作流程相同草稿 → 测试 → 审查 → 改进 → 重复但由于 Claude.ai 没有子智能体一些机制有所不同。以下是需要调整的内容运行测试用例不使用子智能体意味着无法并行执行。对于每个测试用例请阅读技能的 SKILL.md 文件然后按照其说明自行完成测试提示。一次执行一个测试用例。这不如使用独立子智能体那样严谨因为技能是您编写的而且您也在运行它所以您掌握完整的上下文信息但它仍然是一个有用的健全性检查——而且人工审核步骤可以弥补这一点。跳过基线运行——只需使用技能按要求完成任务即可。结果查看如果您无法打开浏览器例如Claude.ai 的虚拟机没有显示器或者您使用的是远程服务器请完全跳过浏览器查看器。而是直接在对话中展示结果。对于每个测试用例显示提示信息和输出结果。如果输出结果是用户需要查看的文件例如 .docx 或 .xlsx请将其保存到文件系统并告知用户文件位置以便他们下载和查看。同时在线询问用户反馈“这个看起来怎么样有什么需要修改的地方吗”基准测试跳过定量基准测试——它依赖于基线比较而如果没有子代理这种比较毫无意义。重点关注来自用户的定性反馈。迭代循环与之前相同——提升技能重新运行测试用例征求反馈——只是中间不再有浏览器审核员。如果您有文件系统仍然可以将结果整理到迭代目录中。描述优化本部分需要使用claudeCLI 工具具体来说是 Claude_codeclaude -p该工具仅在 Claude Code 中可用。如果您使用的是 Claude.ai请跳过此部分。盲测需要子代理。跳过此项。打包该package_skill.py脚本可在任何支持 Python 和文件系统的环境中运行。在 Claude.ai 上您可以运行它用户可以下载生成的.skill文件。更新现有技能用户可能要求您更新现有技能而不是创建新技能。在这种情况下**保留原始名称。**注意技能的目录名称和namefrontmatter 字段——直接使用它们不要更改。例如如果已安装的技能是 skill_nameresearch-helper则输出skill_nameresearch-helper.skill而不是 skill_nameresearch-helper-v2。**编辑前请先复制到可写位置。**已安装的技能路径可能为只读。复制到/tmp/skill-name/该位置在那里进行编辑然后从副本打包。**如果手动打包请先暂存/tmp/**然后复制到输出目录——由于权限问题直接写入可能会失败。共享办公空间特定说明如果你在联合办公空间办公需要了解的主要事项有您有子代理因此主要工作流程并行生成测试用例、运行基线测试、评分等都能正常工作。但是如果您遇到严重的超时问题可以串行运行测试提示而不是并行运行。由于您没有浏览器或显示器因此在生成评估查看器时请--static output_path使用独立的 HTML 文件而不是启动服务器。然后提供一个链接用户可以点击该链接在其浏览器中打开 HTML 文件。不知何故Cowork 的设置似乎会让 Claude 在运行测试后无法生成评估查看器所以再次强调一下无论你使用的是 Cowork 还是 Claude Code运行测试后都应该先生成评估查看器让用户查看示例然后再自行修改技能并尝试进行修正generate_review.py不要自己编写 HTML 代码。抱歉我得强调一下在你自己评估输入*之前*务必先生成评估查看器。你需要尽快让用户看到这些示例反馈机制有所不同由于没有运行中的服务器查看者的“提交所有评论”按钮会将评论下载feedback.json为文件。然后您可以从该文件中阅读您可能需要先申请访问权限。打包功能正常——package_skill.py只需要 Python 和文件系统。描述优化run_loop.py/run_eval.py在 Cowork 中应该可以正常工作因为它使用claude -p子进程而不是浏览器但请保存直到您完全完成技能的制作并且用户同意它状态良好为止。更新现有技能用户可能要求您更新现有技能而不是创建新技能。请按照上方 claude.ai 部分的更新指南进行操作。参考文件agents/ 目录包含特定子代理的指令。需要启动相关子代理时请阅读这些指令。agents/grader.md— 如何根据输出结果评估断言agents/comparator.md— 如何对两个输出进行盲测 A/B 对比agents/analyzer.md如何分析为什么一个版本胜过另一个版本references/ 目录下包含更多文档references/schemas.md— evals.json、grading.json 等的 JSON 结构。为了强调这里再次重复核心循环弄清楚这项技能是关于什么的。撰写或编辑技能运行 claude-with-access-to-the-skill on test prompts与用户一起评估输出结果创建 benchmark.json 文件并运行eval-viewer/generate_review.py以帮助用户进行审查进行定量评估重复此步骤直到您和用户都满意为止。将最终技能打包并返回给用户。如果您有待办事项清单请将步骤添加到清单中以防遗忘。如果您在 Cowork 办公请务必在待办事项eval-viewer/generate_review.py清单中特别添加“创建评估 JSON 并运行以便人工审核测试用例”确保该步骤能够执行。祝你好运