学途智助
首页
分类
标签
关于网站
登录
eeettt
2026-03-26
14
作者编辑
告别手动优化:从新版 Skill-creator 看 Agent Skills的评估和优化
# 告别手动优化:从新版 Skill-creator 看 Agent Skills的评估和优化 > 原文链接:chrome-extension://namdombppngfekpbkmmaoighpkeommih/popup.html ## Intro过去一段时间,如果尝试过用[claude-code](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=claude-code&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJjbGF1ZGUtY29kZSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3MTU2MTc4MCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.1v0Qm_K10H7ohMYXKYxpZoEd5Kc2tccuB9c--7-NNHk&zhida_source=entity) 官方的skills-creator构建agent skills,大概率会发现:agent自己构建的skills往往不好用。于是乎,为了验证一个新写的 Skill 是否真正有效,不得不陷入无止境的“修改 Prompt -> 手动跑测试 -> 检查结果” 的循环中。 直到几天前, 看到了 [Anthropic](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=Anthropic&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJBbnRocm9waWMiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzE1NjE3ODAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.zgfjV-GowD7ZRxUu5CnmzI5Jaaq6IRoFKiF_XRkIlIk&zhida_source=entity) 官方发布的关于 skill-creator 重大更新的文档,给出了一套更加系统、正规和工程化的解法。 简单来说,新版的 skill-creator 已经不再是一个单纯的 SKILL.md 模板生成,而成了一套包含“skill 草稿 → 评测 → 迭代” 的完整工作流。 借着这次更新,尝试拆解一下如何用更系统化的方式来做 Skill 的评估与优化。 TL;DR 新版的核心是用 Agent 来评估和优化 skills,通过多角色分工实现了类似持续集成的自动化测试闭环 ## 新版本 SKill-Creator 总览除去原先版本就具备的Skills模版生成,新版Skill-creator 可以理解成由两个相互协作的核心子系统组成: - 评估系统 - 优化系统 其中评估 包含两个维度: - 触发评估 ([Trigger Evaluation](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=Trigger+Evaluation&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJUcmlnZ2VyIEV2YWx1YXRpb24iLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzE1NjE3ODAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.QOKRpscLp6dmMFVkdVlSOHiXJGbW6CbFvkw3MXErS8g&zhida_source=entity)):测试 Skill 的 description 是否能在正确的查询下被激活,避免“误触发”或“该触发时不触发” - 功能评估 (Functional Evaluation):基于断言(Assertion)测试输出质量,验证 Skill 执行任务的正确性、完整性和专业度 而优化部分,负责根据评估结果进行自动化或半自动化的改进: - description 优化:自动迭代优化Skills的描述,直至触发率达到预期 - 功能优化: 半自动化,引导用户根据评分反馈和 Analyzer Agent 的改进建议,重写 Skill body 中的指令 为了保证评估的客观性,采用多个subagent 隔离上下文实现进行评测 1. [Executor](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=Executor&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJFeGVjdXRvciIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3MTU2MTc4MCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.ZfCSX4bPdgA2TKIChYlhQu7to175dTDa7RRHVxM7jo0&zhida_source=entity): 在隔离环境中并行运行任务,生成执行记录(transcript.md)和输出文件 1. [Grader](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=Grader&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJHcmFkZXIiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzE1NjE3ODAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.2_fRdc-sKWWjk75Nn-hC2nig-_q5OaoEBgI_XREBxnY&zhida_source=entity):依据预设的断言,从执行记录中寻找证据,判定 PASS/FAIL 并输出 grading.json 1. [Comparator](https://zhida.zhihu.com/search?content_id=271561780&content_type=Article&match_order=1&q=Comparator&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzQ3MDkyMDYsInEiOiJDb21wYXJhdG9yIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjcxNTYxNzgwLCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.uuX8ls9IjASzR3jJYEFEtrZh7Q7apvKzYCmE-YRrbWs&zhida_source=entity)/Analyzer:通过 A/B 盲测对比版本优劣,并分析胜出原因,提供可操作的改进建议 ## 评估指标体系### 触发评估指标当评估 skill 描述的触发准确性时,使用以下指标: 指标计算公式含义True Positive (TP)应该触发且确实触发的次数正确的触发False Positive (FP)不应触发但却触发的次数错误的触发True Negative (TN)不应触发且确实没触发的次数正确的不触发False Negative (FN)应该触发但没触发的次数遗漏的触发PrecisionTP / (TP + FP)触发时的准确率RecallTP / (TP + FN)召回率(覆盖率)Accuracy(TP + TN) / (TP + TN + FP + FN)总体准确率Trigger Rate(TP + FP) / Total Runs实际触发的比例计算示例(run_loop.py lines 154-167): ``` def print_eval_stats(label, results, elapsed): pos = [r for r in results if r["should_trigger"]] neg = [r for r in results if not r["should_trigger"]] # 计算 TP, FN tp = sum(r["triggers"] for r in pos) pos_runs = sum(r["runs"] for r in pos) fn = pos_runs - tp # 计算 FP, TN fp = sum(r["triggers"] for r in neg) neg_runs = sum(r["runs"] for r in neg) tn = neg_runs - fp total = tp + tn + fp + fn precision = tp / (tp + fp) if (tp + fp) > 0 else 1.0 recall = tp / (tp + fn) if (tp + fn) > 0 else 1.0 accuracy = (tp + tn) / total if total > 0 else 0.0 print(f"{label}: {tp+tn}/{total} correct, " f"precision={precision:.0%} recall={recall:.0%} " f"accuracy={accuracy:.0%}") ``` ### Assertion 评估指标当评估 skill 的输出质量时,使用以下指标: 指标说明Pass Rate通过的断言数 / 总断言数Passed通过的断言数量Failed失败的断言数量Total总断言数量### 性能指标指标单位说明Time Seconds秒执行时间Tokens个Token 使用量Tool Calls次工具调用次数Errors次遇到的错误数统计聚合 ``` { "pass_rate": { "mean": 0.85, // 平均通过率 "stddev": 0.05, // 标准差 "min": 0.80, // 最小值 "max": 0.90 // 最大值 } } ``` ### Delta 计算比较两个配置(with_skill vs without_skill)的差异: ``` { "delta": { "pass_rate": "+0.50", // 通过率提升 50% "time_seconds": "+13.0", // 时间增加 13 秒 "tokens": "+1700" // Token 增加 1700 } } ``` ## 输入层(测试集)- Draft Skills: Skills草稿 - evals.json 测试用例集(功能测试文件):评估 skill 的功能质量(输出是否正确、完整、有用)而非触发准确性 - trigger_eval.json 触发评估集 (触发测试文件):评估 skill 描述的触发准确性(该触发时触发,不该触发时不触发) 测试集的构建:半自动生成, 结合 AI 生成 + 人工审查 evals.json: 位于/evals/evals.json 格式如下: ``` { "skill_name": "example-skill", "evals": [ { "id": 1, "prompt": "用户任务的提示词,例如:'帮我填写这个 PDF 表单,路径在 ~/Downloads/application.pdf'", "expected_output": "期望输出的描述,例如:'成功填写 PDF 表单,生成新文件'", "files": [ "evals/files/sample1.pdf", "evals/files/input_data.json" ], "expectations": [ "输出包含正确的表单字段值", "使用了 fill_pdf.py 脚本", "生成的 PDF 文件存在且可读", "所有必填字段都已填写" ] }, { "id": 2, "prompt": "另一个测试场景...", "expected_output": "...", "files": [], "expectations": ["..."] } ] } ``` trigger_eval.json CC会首先生成 20 个触发评估查询, 10个should_trigger=true 的查询(应该触发), 和10个should_trigger=false 的查询(不应触发) 而后生成一个交互式 HTML 界面(基于 assets/eval_review.html)供人工审查和编辑 最终结果保存在: <skill-directory>/evals/trigger_evals.json 格式: ``` [ { "query": "hey can you help me fill out this pdf form? its in ~/Downloads/application.pdf and i need to put my name as John Smith", "should_trigger": true }, ... { "query": "merge these 3 word docs into a single pdf please", "should_trigger": false }, ... ] ``` ## Subagent设计整体而言,分为4种角色分工 Subagent职责输入输出Executor执行Skill + Prompt输出文件 + 执行记录Grader打分输出 + 断言清单grading.jsonComparator盲测比较输出A + 输出Bcomparison.json (胜者)Analyzer分析比较结果 + Skills + 记录analysis.json### ExecutorExecutor 是通过 CC 的 Agent tool 直接调用的subagent (即默认的general-purpose) (from SKILL.md line 169) > ## Step 1: Spawn all runs (with-skill AND baseline) in the same turnFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time. 输入参数 ``` expectations: 期望列表(从 evals.json 获取) transcript_path: 执行transcript记录路径 outputs_dir: 输出文件目录 ``` 输出格式 生成 {outputs_dir}/../grading.json: ``` { "expectations": [ { "text": "原始断言文本", "passed": true/false, "evidence": "支持判断的具体引用或描述" } ], "summary": { "passed": 2, "failed": 1, "total": 3, "pass_rate": 0.67 }, "claims": [...], "eval_feedback": { "suggestions": [...], "overall": "对评估设计的整体评价" } } ``` 评分标准 ``` **PASS when**: - The transcript or outputs clearly demonstrate the expectation is true - Specific evidence can be cited - The evidence reflects genuine substance, not just surface compliance (e.g., a file exists AND contains correct content, not just the right filename) **FAIL when**: - No evidence found for the expectation - Evidence contradicts the expectation - The expectation cannot be verified from available information - The evidence is superficial — the assertion is technically satisfied but the underlying task outcome is wrong or incomplete - The output appears to meet the assertion by coincidence rather than by actually doing the work **When uncertain**: The burden of proof to pass is on the expectation. ``` (Step 4: Extract and Verify Claims) > Beyond the predefined expectations, extract implicit claims from the outputs and verify them 即Hallucination 检查。 “隐性声明(implicit claims)”: 除了expectations 之外的检查项,Agent在执行时产生的statements(顺口吐露的陈述?) 由于这些 statements 不在 Rubric 里,传统测试会之间跳过。而Step4 Grader 会逐个检查agent的statements是否存在幻觉或者是撒谎的情况。 implicit claims被大致分成: - Factual claims: 事实层面;如agent claims “该表单包含 12 个字段”, 则Grader需要亲自去数 - Process claims: 流程层面; 如 agent claims “使用了 pypdf 库来填写这个表单“, 则Grader需要检查日志或者代码,避免出现“假装自己调用了” 的情况 - Quality claims: 质量层面; 当Agent 自信地claims“所有必填字段都已正确填写”, Grader必须检查一下是否属实。 (Step 6: Critique the Evals) > Good assertions test meaningful outcomes — assertions that are hard to satisfy without actually doing the work correctly. 好的测试用例(断言)应该考察那些有实质意义的结果。在评判完执行表现后,反过来评判测试用例本身的质量(只有在发现“明显的差距(clear gap)”时才提出建议)。 好的建议应该指向那些能测试meaningful outcomes的断言:确保测试具备“区分度”。 ``` - An assertion that passed but would also pass for a clearly wrong output (e.g., checking filename existence but not file content) - An important outcome you observed — good or bad — that no assertion covers at all - An assertion that can't actually be verified from the available outputs ``` - 防止Anti-Shortcut: 标准太低agent容易只看重表面合规; - 检查盲区:审查输出时,观察到了某个非常重要好的(或坏的)结果,但现有的所有断言都没有对这个结果进行考察 - 无足够信息判断真伪 简单来说,Grader Agent不是简单地打分,而是:Evaluate → Verify Claims → Critique Evals → 数据整合结构化输出(包括性能指标) 的流程。 ### Comparator Agent盲测比较。 核心任务在于:盲比较两个输出,判断哪个更好 —— 不知道 A/B 分别来自哪个 skill,避免偏见 工作流程 ``` 读取输出 (Read Both Outputs):检查 A 和 B 的文件或目录,并注意其类型、结构和内容。 理解任务 (Understand the Task):仔细阅读 eval_prompt,明确任务要求生成的产物,以及区分好坏输出的关键质量指标(如准确性、完整性、格式等)。 生成评估矩阵 (Generate Evaluation Rubric):基于具体任务,动态生成“内容”和“结构”两个维度的评分标准。 依据矩阵评估 (Evaluate Each Output):针对 A 和 B,对矩阵中的每项标准进行 1-5 分的打分,并计算出 1-10 分制的总分。 检查断言 (Check Assertions):如果输入包含了 expectations,则分别针对 A 和 B 检查这些断言,计算通过率作为辅助证据。 确定获胜者 (Determine the Winner):按优先级决定胜者。首要依据是评估矩阵的总分,次要依据是断言通过率,如果两者真实水平完全相等才宣布平局。 写入结果 (Write Comparison Results):将比较结果保存为指定的 JSON 文件。 # comparator.md 输入参数 { "output_a_path": "...", # 匿名输出 A "output_b_path": "...", # 匿名输出 B "eval_prompt": "...", # 原始任务 "expectations": [...] # 期望列表(可选) } ``` 评分 Rubric: 维度1 (Poor)3 (Acceptable)5 (Excellent)ContentCorrectnessMajor errorsMinor errorsFully correctCompletenessMissing key elementsMostly completeAll elements presentAccuracySignificant inaccuraciesMinor inaccuraciesAccurate throughoutStructureOrganizationDisorganizedReasonably organizedClear, logicalFormattingInconsistent/brokenMostly consistentProfessionalUsabilityDifficult to useUsable with effortEasy to use输出格式 生成 comparison.json: ``` { "winner": "A" | "B" | "TIE", "reasoning": "获胜原因说明", "rubric": { "content_criteria": { "correctness": {"a_score": 4, "b_score": 5, "notes": "..."}, "completeness": {"a_score": 3, "b_score": 4, "notes": "..."}, "accuracy": {"a_score": 5, "b_score": 4, "notes": "..."} }, "structure_criteria": { "organization": {"a_score": 4, "b_score": 3, "notes": "..."}, "formatting": {"a_score": 5, "b_score": 4, "notes": "..."}, "usability": {"a_score": 4, "b_score": 5, "notes": "..."} } }, "overall_scores": { "a_score": 8.2, "b_score": 8.5 }, "output_quality": { "a_strengths": ["优势1", "优势2"], "a_weaknesses": ["劣势1", "劣势2"], "b_strengths": ["优势1", "优势2"], "b_weaknesses": ["劣势1", "劣势2"] }, "expectation_results": { "a_pass_rate": 0.8, "b_pass_rate": 0.9, "details": [...] } } ``` 设计哲学: 为了确保评判完全客观且基于输出质量本身,采用Blindness(双盲)的设计,确保Agent在评估时只能基于输出结果本身。 同时依靠评估Rubric,避免完全的主观评分。并将Overall rubric score(综合结果)作为首要的决策依据,而非单独Expectation scores,避免hacking情况发生。 ``` ### Step 6: Determine the Winner Compare A and B based on (in priority order): 1. **Primary**: Overall rubric score (content + structure) 2. **Secondary**: Assertion pass rates (if applicable) 3. **Tiebreaker**: If truly equal, declare a TIE Be decisive - ties should be rare. One output is usually better, even if marginally. ``` ### Analyzer Agent针对skills迭代优化而设计的复盘agent,通过深入执行中的细节,找出成功失败的根本原因,并输出如何修改的建议。 主要分为两大核心任务: - 盲测复盘 (Blind Comparison Analysis):在两个不同版本的Skills(Winner vs. Loser)决出胜负后,对它们进行“揭盲”分析。通过对比两者的指令、工具和执行记录,找出胜者的制胜关键,并为败者提供改进方案。 - 基准测试模式挖掘 (Benchmark Pattern Analysis):在批量基准测试后,挖掘汇总数据背后的规律和异常 对于盲测复盘模式 分析过程: ``` 1. 读取 comparison.json(谁赢了) 2. Unblind:确定 A 和 B 分别是哪个技能 3. 读取两个技能定义文件 4. 读取两个执行成绩单 5. 对比分析: - 指令遵循度 - 执行策略差异 - 工具使用模式 6. 归因分析:赢家为什么赢? 7. 生成改进建议(优先级排序) 8. 输出 analysis.json ``` 输出格式: 生成 analysis.json ``` { "comparison_summary": { "winner": "skill-v2", "loser": "skill-v1", "score_difference": 1.5, "key_differentiator": "更详细的指令" }, "winner_strengths": [ "明确的步骤分解", "更好的错误处理指导", "清晰的输出格式要求" ], "loser_weaknesses": [ "指令过于抽象", "缺少具体例子", "未说明边界情况处理" ], "instruction_following": { "winner_score": 9, "loser_score": 6, "notes": "赢家更准确地遵循了技能定义" }, "improvement_suggestions": [ { "priority": "HIGH", "category": "指令清晰度", "suggestion": "添加步骤分解和具体示例", "expected_impact": "提高输出质量和一致性" }, { "priority": "MEDIUM", "category": "错误处理", "suggestion": "明确说明边界情况处理策略", "expected_impact": "减少失败率" }, { "priority": "LOW", "category": "格式化", "suggestion": "统一输出格式要求", "expected_impact": "改善可读性" } ], "transcript_insights": { "winner_patterns": ["使用了更多工具", "更系统的探索"], "loser_patterns": ["跳过了某些步骤", "过早结束"] } } ``` 对于Benchmark 模式 ``` 1. 读取 benchmark.json(聚合数据) 2. 分析每个期望的通过率和方差 3. 识别模式: - 稳定期望 vs 不稳定期望 - 简单任务 vs 困难任务 4. 分析指标趋势(时间、token、工具) 5. 检测异常和离群值 6. 生成观察列表(基于数据的洞察) 7. 输出观察数组 ``` benchmark.json 来源于aggregate_benchmark.py,通过脚本生成汇总报告。 在 Benchmark 分析中,更关注于方差和异常点。 ## 评估与优化流程Skill 评估分为两个独立的流程: 1. 功能评估:测试 skill 的输出质量(使用 evals.json) 1. 触发评估:测试 skill 描述的触发准确性(使用 trigger_eval.json) ### 功能评估和优化生成测试用例 → Executor →Grade → analyzer → (comparator) → Human-Review → 迭代 → … 对于功能优化而言,需要 CC + 用户协作(因为涉及理解任务、判断输出质量、决策如何改进) ### 触发评估和优化在后台运行 scripts.run_loop 脚本,将测试集划分为 60% 的训练集和 40% 的测试集,多次测试当前的描述(每个查询跑 3 次以获得稳定的触发率),并让 CC 根据失败的案例提出改进描述的建议。 最多会迭代 5 次。完成后,系统会生成一份 HTML 报告,并根据测试集的得分(为了防止过拟合)输出一个 best_description 相比之下,触发优化完全交给脚本自动跑(因为只是改一段描述文字,task单纯)。 几个核心脚本: run_eval.py 触发评估; - 使用 claude -p 执行查询并监控 stream events - 通过 content_block_start 事件早期检测触发 - 支持并行执行以提高效率 run_loop.py 将 eval 和 improve 串联成迭代循环,直到全部通过或达到最大迭代次数。 核心逻辑: - Train/Test 分割:支持 holdout 机制(默认 40%),防止过拟合 - 迭代执行: - 运行 eval(train + test) - 如果 train 全部通过 → 结束 - 否则,调用 improve_description 生成新 description - 继续下一轮 - 防过拟合设计:向 improve 提供 history 时会隐藏 test 分数 - 最佳结果选择:根据 test 分数(或 train 分数)选择历史最佳 description - 实时生成 HTML 报告,自动打开浏览器展示进度 improve_description.py 描述优化: 根据评估失败的案例,调用 Claude 生成改进后的 skill description 核心逻辑: - 分析 eval 结果,分类出: - Failed triggers:应该触发但没触发 - False triggers:不该触发但触发了 - 构建详细的 prompt,包含: - 当前 description - 失败案例分析 - 历史尝试记录(防止重复) - Skill 完整内容(供参考) - 调用 claude -p 生成新的 description - 如果生成超过 1024 字符限制,会自动重写 ## 小结回顾新版 skill-creator 的重构, 其代表了 Agent 开发模式从手动调优(Prompt Engineering)向评估驱动工程(Eval-Driven Engineering)的范式转变 (或者也可以叫做Harness-Engineering)。 几个具借鉴意义的设计理念: 物理隔离确保客观性:通过 Subagent 机制严格隔离上下文,避免了主 Agent 与 Subagent 之间、不同测试用例之间的 Context 污染,保证了评估的绝对公平 不只是LLM-as-a-judge:Grader 不仅只是核对Rubric打分,还会主动提取隐性声明(Implicit Claims)做事实核查。它甚至会反向审视测试用例本身的合理性(Critique Evals),有效防止了 Agent hacking。 双盲去偏见:A/B 双盲比较确保评判基于输出质量本身。 非单一指标: 不仅关注最终的成功率,还将方差、异常值、Token 消耗等性能指标纳入考量。 不可否认,目前的自动化仍有边界。当前系统仅能实现 Skill 描述的自动迭代。由于功能逻辑的复杂性,Skill Body 的指令与代码优化依然高度依赖人机协作(Human-in-the-loop)。完全依靠一次交互实现 100% 的能力进阶仍不现实。 但也至少指明了方向。 ## 参考[claude-blog: improving-skill-creator-test-measure-and-refine-agent-skills](https://link.zhihu.com/?target=https%3A//claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills) [skill-creator](https://link.zhihu.com/?target=https%3A//github.com/anthropics/skills/tree/main/skills/skill-creator)
复制
赞
博客信息
作者
eeettt
发布日期
2026-03-26
其他信息 : 其他三字母的人名首字母都是其他同学发布的哦