人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载ALWAYS use this exact template:[Title]Executive summaryKey findingsRecommendations**示例模式**如果示例里同时有 Input 和 Output 可能需要稍微变通 markdown ## Commit message format **Example 1:** Input: Added user authentication with JWT tokens Output: feat(auth): implement JWT-based authentication写作风格Writing Style与其堆砌生硬的 MUST不如向模型解释为什么这些很重要。善用心理理论theory of mind让技能通用化而非过分窄化到具体示例。先写出草稿再以全新的眼光审视改进它。测试用例Test Cases草稿完成后设计 2-3 个贴近真实用户语气的测试提示词与用户确认可以参考这样的说法Here are a few test cases Id like to try. Do these look right, or do you want to add more?然后运行它们。测试用例保存到evals/evals.json。此阶段先不写断言只写提示词断言在下一步运行进行中再起草{ skill_name: example-skill, evals: [ { id: 1, prompt: Users task prompt, expected_output: Description of expected result, files: [] } ] }完整的 schema含稍后要添加的assertions字段见 references/schemas.md。该文件定义了技能目录下evals/evals.json的完整结构除skill_name、evals[].id/prompt/expected_output/files外还支持evals[].expectations字段——一组可验证的陈述列表如 The output includes X、The skill used script Y它是后续评分grading的输入来源。运行与评估测试用例五个连续步骤这一节是一条连续的流程不要中途停下。不要使用/skill-test或其他任何测试技能。结果放在技能目录的兄弟目录skill-name-workspace/下。工作区内按迭代组织iteration-1/、iteration-2/……每次迭代内每个测试用例一个目录eval-0/、eval-1/……。不要一次性建好全部目录而是边做边建。第 1 步在同一轮中并行启动所有运行with-skill 与 baseline对每个测试用例同一轮启动两个子代理——一个带技能、一个不带。这很重要不要先启动带技能的运行再回来补基线。一次性全部启动让它们大致同时完成。带技能运行with-skillExecute this task: - Skill path: path-to-skill - Task: eval prompt - Input files: eval files if any, or none - 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基线运行baseline同一提示词但基线取决于上下文创建新技能完全不带技能。同一提示词、无技能路径输出保存到without_skill/outputs/改进已有技能用旧版本。编辑前先快照技能cp -r skill-path workspace/skill-snapshot/然后把基线子代理指向快照。输出保存到old_skill/outputs/。为每个测试用例写一个eval_metadata.json断言暂时可为空。给每个 eval 起一个基于测试内容的描述性名称而不仅是 eval-0目录名也用这个名字。如果本次迭代使用新的或修改过的 eval 提示词要为每个新 eval 目录创建这些文件——不要假定它们会从上一迭代自动延续{ eval_id: 0, eval_name: descriptive-name-here, prompt: The users task prompt, assertions: [] }第 2 步运行进行中起草断言不要干等运行结束这段时间可以高效利用。为每个测试用例起草定量断言并向用户解释。如果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 }这是捕获该数据的唯一机会——它来自任务通知不会被持久化到别处。逐个处理通知而不是攒一批再处理。schemas.md 中给出的完整timing.json还包含 executor 与 grader 各自的起止时间戳与耗时executor_start/end、executor_duration_seconds、grader_duration_seconds等说明该文件同时承载执行与评分两个阶段的计时信息。第 4 步评分、聚合、启动查看器全部运行结束后为每次运行评分——启动一个评分子代理或内联评分读取 agents/grader.md将每条断言与输出比对结果保存到各运行目录的grading.json。grading.json 的 expectations 数组必须使用text、passed、evidence这三个字段名不要用name/met/details等变体——查看器依赖这些精确字段名。可编程检查的断言请编写并运行脚本而不是肉眼判断——脚本更快、更可靠、可跨迭代复用。从 agents/grader.md 可以看到完整的评分标准PASS 需要转录或输出明确证明断言为真、可引用具体证据、证据反映真实实质而非表面合规例如文件存在且内容正确而非仅有正确文件名FAIL 涵盖无证据、证据矛盾、断言不可验证、证据肤浅、输出仅靠巧合满足断言等情形不确定时举证责任在断言方the burden of proof to pass is on the expectation。grader 还要从输出中提取并验证隐式声明事实类/过程类/质量类阅读user_notes.md并在发现弱断言或遗漏的关键结果时对评测本身提出改进建议写入可选的eval_feedback字段。schemas.md 展示了完整的grading.json结构除expectations与summarypassed/failed/total/pass_rate外还包括execution_metrics各工具调用次数、总步数、输出字符数、转录字符数、timing、claims、user_notes_summary与eval_feedback。聚合成基准——从 skill-creator 目录运行聚合脚本python -m scripts.aggregate_benchmark workspace/iteration-N --skill-name name这会生成benchmark.json与benchmark.md包含每种配置configuration的 pass_rate、时间与 token 消耗带均值 ± 标准差以及两者之差delta。如果手工生成 benchmark.json请严格参照 schemas.md 中查看器所期望的精确 schema。把每个 with_skill 版本放在其基线版本之前。从 scripts/aggregate_benchmark.py 的实现看它从各eval-*/config/run-*/grading.json读取数据兼容工作区布局与带runs/子目录的旧布局动态发现配置目录名不硬编码with_skill/without_skill因此也支持new_skill/old_skill之类命名计算各指标均值/标准差/最小/最大并输出delta其生成的benchmark.md是一张Pass Rate / Time / Tokens Delta的三行表格非常适合快速查看。做一次分析员遍历analyst pass——阅读基准数据发现聚合统计可能掩盖的模式。参见 agents/analyzer.md 的 Analyzing Benchmark Results 一节重点找这些现象无论是否有技能都总是通过的断言无区分度、高方差的 eval可能不稳定、时间/token 的取舍。该文件给出的分析方法论包括逐断言模式分析始终通过/始终失败/带技能通过不带失败/带技能失败不带通过/高波动、跨 eval 模式分析、指标模式分析以及输出为自由文本 notes 数组的格式要求。启动查看器同时呈现定性输出与定量数据nohup python skill-creator-path/eval-viewer/generate_review.py \ workspace/iteration-N \ --skill-name my-skill \ --benchmark workspace/iteration-N/benchmark.json \ /dev/null 21 VIEWER_PID$!从第 2 次迭代起还要传--previous-workspace workspace/iteration-N-1。Cowork / 无头环境如果webbrowser.open()不可用或环境无显示器改用--static output_path写出独立 HTML 文件而不是启动服务器。用户点击 Submit All Reviews 后反馈会以feedback.json文件形式下载下载后把feedback.json复制进工作区目录供下一迭代读取。注意请用generate_review.py生成查看器无需手写自定义 HTML。从 eval-viewer/generate_review.py 的实现看它零第三方依赖仅用 Python 标准库递归发现含outputs/目录的运行、把文本/图片/PDF/xlsx/二进制按类型内嵌进自包含 HTML模板为同目录viewer.html、用HTTPServer提供页面每次刷新重新扫描工作区并通过POST /api/feedback将反馈写回feedback.json若端口被占用会自动寻找空闲端口默认端口为 3117。告诉用户例如Ive opened the results in your browser. There are two tabs — Outputs lets you click through each test case and leave feedback, Benchmark shows the quantitative comparison. When youre done, come back here and let me know.用户在查看器中看到什么Outputs 标签页一次展示一个测试用例Prompt给出的任务Output技能产生的文件尽可能内联渲染Previous Output第 2 次迭代起折叠显示上一迭代的输出Formal Grades若运行了评分折叠显示断言的通过与失败Feedback文本框输入时自动保存Previous Feedback第 2 次迭代起上次的评论显示在文本框下方。Benchmark 标签页展示统计摘要各配置的通过率、计时与 token 消耗含逐 eval 细分与分析员观察。导航用 prev/next 按钮或方向键。完成后点击 Submit All Reviews所有反馈保存到feedback.json。第 5 步读取反馈用户告知完成后读取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_PID 2/dev/null改进技能循环的心脏这是整个闭环的核心。测试已跑完、用户已审阅结果现在要根据反馈把技能改得更好。如何思考改进从反馈中泛化。大局在于我们要创建的是能被使用一百万次甚至更多的技能横跨无数不同提示词。你和用户现在只在少数几个例子上反复迭代是因为这样推进更快——用户对这些例子了如指掌能快速评估新输出。但如果你们共同开发的技能只对这些例子有效那就毫无用处。与其做琐碎过拟合的改动或令人窒息的 MUST不如在遇到顽固问题时换用不同的隐喻或推荐不同的工作模式——尝试成本很低说不定能碰到好方案。保持提示词精简。删掉那些不配位的内容。务必阅读转录transcripts而不只是最终输出——如果技能让模型在无产出的事情上浪费大量时间可以试着删掉导致这一点的技能部分再看看效果。解释为什么。尽力解释你要求模型做的每件事背后的原因。当今的 LLM 很聪明具备良好的心理理论在好的驾驭harness下能超越死板指令真正做成事。即使用户反馈简短或充满挫败感也要真正理解任务、理解用户为什么写那些话、到底写了什么然后把这份理解传导进指令。如果你发现自己写出全大写的 ALWAYS 或 NEVER或用超刚性结构那就是一个黄旗——尽可能换个框架、解释推理过程让模型理解你要求的事情为什么重要。这是更人道、更有力、也更有效的方法。寻找跨测试用例的重复工作。阅读测试运行的转录留意子代理们是否都独立写了类似的辅助脚本或采用了相同的多步骤方案。如果 3 个测试用例全都导致子代理各写了一份create_docx.py或build_chart.py这是强烈信号技能应该内置该脚本。写一次放进scripts/让技能指示使用它。这能为未来每次调用省去重复造轮子。这个任务相当重要你的思考时间不是瓶颈——慢慢来真正想透。建议先写一版修订草稿再以全新视角审视改进。尽最大努力进入用户的头脑理解他们想要什么、需要什么。迭代循环改进技能后将改进应用到技能上把所有测试用例重新跑进新的iteration-N1/目录包括基线运行。创建新技能时基线永远是without_skill不带技能各迭代保持一致改进已有技能时用你的判断决定基线用哪个版本用户最初带来的原版还是上一迭代用--previous-workspace指向上一迭代来启动查看器等待用户审阅并告知完成读取新反馈再次改进重复。持续迭代直到满足任一条件用户表示满意反馈全部为空一切正常你不再有有意义的进展。进阶盲比较Blind Comparison当需要更严格地比较技能的两个版本时例如用户问新版本真的更好吗可以使用盲比较系统。详细说明见 agents/comparator.md 与 agents/analyzer.md。基本思想是把两份输出交给一个独立代理不告诉它哪份由哪个技能产生让它评判质量然后分析获胜方为什么赢。从 agents/comparator.md 看比较器根据 eval 任务生成双维评分表——内容维度正确性/完整性/准确性1-5 分与结构维度组织/格式/可用性1-5 分以评分总分为首要判据、断言通过率为次要判据输出包含winnerA/B/TIE、reasoning、rubric、output_quality与可选expectation_results的 JSON随后 agents/analyzer.md 中的Post-hoc Analyzer揭开盲区对比两份技能的 SKILL.md 与转录产出winner_strengths、loser_weaknesses、instruction_following评分与按优先级/类别instructions、tools、examples、error_handling、structure、references组织的improvement_suggestions其对应数据结构见 schemas.md 中的comparison.json与analysis.json。这是可选的需要子代理多数用户用不上——人工评审循环通常已足够。Description 优化提高触发准确率SKILL.md frontmatter 中的 description 字段是决定模型是否调用技能的主要机制。创建或改进技能后主动提出为 description 做优化。第 1 步生成触发评测查询创建 20 条评测查询——混合应触发与不应触发。保存为 JSON[ {query: the user prompt, should_trigger: true}, {query: another prompt, should_trigger: false} ]查询必须真实是 Claude Code 或 Claude.ai 用户会实际键入的内容——不是抽象请求而是具体、详细、信息量充足的请求。例如文件路径、关于用户工作或处境的个人背景、列名与取值、公司名、URL一点点背景故事。有些可以全小写、含缩写或拼写错误、口语化。混合不同长度聚焦边界情况而非边界清晰的案例用户之后有机会签署确认。坏示例Format this data、Extract text from PDF、Create 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 条最有价值的是擦边球near-misses——与本技能共享关键词或概念、但实际上需要别的能力的查询。考虑相邻领域、模糊措辞朴素关键词匹配会误触发但不应触发、以及查询涉及技能所做的事但上下文里别的工具更合适的案例。关键要避免不要让不应触发的查询明显不相关。对 PDF 技能而言Write a fibonacci function 作为负例太容易了——它什么都测不出来。负例应真正棘手。第 2 步与用户一起审查使用 HTML 模板向用户呈现评测集从assets/eval_review.html读取模板替换占位符__EVAL_DATA_PLACEHOLDER__→ 评测项的 JSON 数组两侧不加引号——它是一次 JS 变量赋值__SKILL_NAME_PLACEHOLDER__→ 技能名__SKILL_DESCRIPTION_PLACEHOLDER__→ 技能当前的 description写入临时文件如/tmp/eval_review_skill-name.html并打开open /tmp/eval_review_skill-name.html用户可编辑查询、切换 should-trigger、增删条目然后点击 Export Eval Set文件下载到~/Downloads/eval_set.json——检查 Downloads 文件夹里最新的版本可能有多份如eval_set (1).json。这一步很重要——糟糕的评测查询会导致糟糕的 description。第 3 步运行优化循环告诉用户This will take some time — Ill run the optimization loop in the background and check on it periodically.把评测集保存到工作区然后后台运行python -m scripts.run_loop \ --eval-set path-to-trigger-eval.json \ --skill-path path-to-skill \ --model model-id-powering-this-session \ --max-iterations 5 \ --verbose使用系统提示中的模型 ID即驱动当前会话的模型这样触发测试才匹配用户实际体验。运行时周期性 tail 输出向用户汇报当前进行到第几次迭代、分数如何。这处理完整的优化循环把评测集按 60% 训练 / 40% 保留测试切分评估当前 description每条查询跑 3 次以获得可靠触发率然后让 Claude 根据失败情况提出改进对每个新 description 在训练集与测试集上重新评估最多迭代 5 次。完成后在浏览器中打开一份 HTML 报告展示每次迭代的结果并返回含best_description的 JSON——按测试集分数而非训练集分数选择以避免过拟合。从 scripts/run_loop.py 的实现看其split_eval_set函数按should_trigger分层切分训练/测试集循环内组合run_eval评测当前描述与improve_description调用模型提出改进并跟踪历史记录对应 schemas.md 中的history.json含各版本 pass_rate、grading_resultbaseline/won/lost/tie与current_best标记。技能触发机制的工作原理理解触发机制有助于设计更好的评测查询。技能出现在模型的available_skills列表中附带 name description模型根据该 description 决定是否查阅技能。关键认知是模型只为它无法轻易独立完成的任务查阅技能——像 read this PDF 这样的单步简单查询即使 description 完美匹配也可能不触发技能因为模型用基础工具可直接处理。复杂、多步或专业化的查询在 description 匹配时能可靠触发技能。因此评测查询必须足够有分量让模型确实能从查阅技能中获益。像 read file X 这样的简单查询是糟糕的测试用例——无论 description 质量如何它们都不会触发技能。第 4 步应用结果从 JSON 输出中取出best_description更新技能的 SKILL.md frontmatter。向用户展示前后对比并报告分数。打包与呈现仅当present_files工具可用时检查你是否拥有present_files工具。没有则跳过此步。有则打包技能并向用户呈现.skill文件python -m scripts.package_skill path/to/skill-folder赞分享人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载相关推荐Report structureReport structure ALWAYS use this exact template: Title Executive summary Key finAI 应用大模型桌面应用本地部署RAGReport structureReport structure ALWAYS use this exact template structure: Analysis Title Execut前端UI组件Report structureReport structure ALWAYS use this exact template structure: Analysis Title Execut人工智能大模型AI AgentAgent 框架多智能体工具调用MCP ClientsRAG模型评测数据生成上一篇BotBrowser安全测试最佳实践授权隐私研究环境配置指南下一篇Pueue系统服务集成如何将pueued配置为系统守护进程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Report structure
人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载ALWAYS use this exact template:[Title]Executive summaryKey findingsRecommendations**示例模式**如果示例里同时有 Input 和 Output 可能需要稍微变通 markdown ## Commit message format **Example 1:** Input: Added user authentication with JWT tokens Output: feat(auth): implement JWT-based authentication写作风格Writing Style与其堆砌生硬的 MUST不如向模型解释为什么这些很重要。善用心理理论theory of mind让技能通用化而非过分窄化到具体示例。先写出草稿再以全新的眼光审视改进它。测试用例Test Cases草稿完成后设计 2-3 个贴近真实用户语气的测试提示词与用户确认可以参考这样的说法Here are a few test cases Id like to try. Do these look right, or do you want to add more?然后运行它们。测试用例保存到evals/evals.json。此阶段先不写断言只写提示词断言在下一步运行进行中再起草{ skill_name: example-skill, evals: [ { id: 1, prompt: Users task prompt, expected_output: Description of expected result, files: [] } ] }完整的 schema含稍后要添加的assertions字段见 references/schemas.md。该文件定义了技能目录下evals/evals.json的完整结构除skill_name、evals[].id/prompt/expected_output/files外还支持evals[].expectations字段——一组可验证的陈述列表如 The output includes X、The skill used script Y它是后续评分grading的输入来源。运行与评估测试用例五个连续步骤这一节是一条连续的流程不要中途停下。不要使用/skill-test或其他任何测试技能。结果放在技能目录的兄弟目录skill-name-workspace/下。工作区内按迭代组织iteration-1/、iteration-2/……每次迭代内每个测试用例一个目录eval-0/、eval-1/……。不要一次性建好全部目录而是边做边建。第 1 步在同一轮中并行启动所有运行with-skill 与 baseline对每个测试用例同一轮启动两个子代理——一个带技能、一个不带。这很重要不要先启动带技能的运行再回来补基线。一次性全部启动让它们大致同时完成。带技能运行with-skillExecute this task: - Skill path: path-to-skill - Task: eval prompt - Input files: eval files if any, or none - 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基线运行baseline同一提示词但基线取决于上下文创建新技能完全不带技能。同一提示词、无技能路径输出保存到without_skill/outputs/改进已有技能用旧版本。编辑前先快照技能cp -r skill-path workspace/skill-snapshot/然后把基线子代理指向快照。输出保存到old_skill/outputs/。为每个测试用例写一个eval_metadata.json断言暂时可为空。给每个 eval 起一个基于测试内容的描述性名称而不仅是 eval-0目录名也用这个名字。如果本次迭代使用新的或修改过的 eval 提示词要为每个新 eval 目录创建这些文件——不要假定它们会从上一迭代自动延续{ eval_id: 0, eval_name: descriptive-name-here, prompt: The users task prompt, assertions: [] }第 2 步运行进行中起草断言不要干等运行结束这段时间可以高效利用。为每个测试用例起草定量断言并向用户解释。如果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 }这是捕获该数据的唯一机会——它来自任务通知不会被持久化到别处。逐个处理通知而不是攒一批再处理。schemas.md 中给出的完整timing.json还包含 executor 与 grader 各自的起止时间戳与耗时executor_start/end、executor_duration_seconds、grader_duration_seconds等说明该文件同时承载执行与评分两个阶段的计时信息。第 4 步评分、聚合、启动查看器全部运行结束后为每次运行评分——启动一个评分子代理或内联评分读取 agents/grader.md将每条断言与输出比对结果保存到各运行目录的grading.json。grading.json 的 expectations 数组必须使用text、passed、evidence这三个字段名不要用name/met/details等变体——查看器依赖这些精确字段名。可编程检查的断言请编写并运行脚本而不是肉眼判断——脚本更快、更可靠、可跨迭代复用。从 agents/grader.md 可以看到完整的评分标准PASS 需要转录或输出明确证明断言为真、可引用具体证据、证据反映真实实质而非表面合规例如文件存在且内容正确而非仅有正确文件名FAIL 涵盖无证据、证据矛盾、断言不可验证、证据肤浅、输出仅靠巧合满足断言等情形不确定时举证责任在断言方the burden of proof to pass is on the expectation。grader 还要从输出中提取并验证隐式声明事实类/过程类/质量类阅读user_notes.md并在发现弱断言或遗漏的关键结果时对评测本身提出改进建议写入可选的eval_feedback字段。schemas.md 展示了完整的grading.json结构除expectations与summarypassed/failed/total/pass_rate外还包括execution_metrics各工具调用次数、总步数、输出字符数、转录字符数、timing、claims、user_notes_summary与eval_feedback。聚合成基准——从 skill-creator 目录运行聚合脚本python -m scripts.aggregate_benchmark workspace/iteration-N --skill-name name这会生成benchmark.json与benchmark.md包含每种配置configuration的 pass_rate、时间与 token 消耗带均值 ± 标准差以及两者之差delta。如果手工生成 benchmark.json请严格参照 schemas.md 中查看器所期望的精确 schema。把每个 with_skill 版本放在其基线版本之前。从 scripts/aggregate_benchmark.py 的实现看它从各eval-*/config/run-*/grading.json读取数据兼容工作区布局与带runs/子目录的旧布局动态发现配置目录名不硬编码with_skill/without_skill因此也支持new_skill/old_skill之类命名计算各指标均值/标准差/最小/最大并输出delta其生成的benchmark.md是一张Pass Rate / Time / Tokens Delta的三行表格非常适合快速查看。做一次分析员遍历analyst pass——阅读基准数据发现聚合统计可能掩盖的模式。参见 agents/analyzer.md 的 Analyzing Benchmark Results 一节重点找这些现象无论是否有技能都总是通过的断言无区分度、高方差的 eval可能不稳定、时间/token 的取舍。该文件给出的分析方法论包括逐断言模式分析始终通过/始终失败/带技能通过不带失败/带技能失败不带通过/高波动、跨 eval 模式分析、指标模式分析以及输出为自由文本 notes 数组的格式要求。启动查看器同时呈现定性输出与定量数据nohup python skill-creator-path/eval-viewer/generate_review.py \ workspace/iteration-N \ --skill-name my-skill \ --benchmark workspace/iteration-N/benchmark.json \ /dev/null 21 VIEWER_PID$!从第 2 次迭代起还要传--previous-workspace workspace/iteration-N-1。Cowork / 无头环境如果webbrowser.open()不可用或环境无显示器改用--static output_path写出独立 HTML 文件而不是启动服务器。用户点击 Submit All Reviews 后反馈会以feedback.json文件形式下载下载后把feedback.json复制进工作区目录供下一迭代读取。注意请用generate_review.py生成查看器无需手写自定义 HTML。从 eval-viewer/generate_review.py 的实现看它零第三方依赖仅用 Python 标准库递归发现含outputs/目录的运行、把文本/图片/PDF/xlsx/二进制按类型内嵌进自包含 HTML模板为同目录viewer.html、用HTTPServer提供页面每次刷新重新扫描工作区并通过POST /api/feedback将反馈写回feedback.json若端口被占用会自动寻找空闲端口默认端口为 3117。告诉用户例如Ive opened the results in your browser. There are two tabs — Outputs lets you click through each test case and leave feedback, Benchmark shows the quantitative comparison. When youre done, come back here and let me know.用户在查看器中看到什么Outputs 标签页一次展示一个测试用例Prompt给出的任务Output技能产生的文件尽可能内联渲染Previous Output第 2 次迭代起折叠显示上一迭代的输出Formal Grades若运行了评分折叠显示断言的通过与失败Feedback文本框输入时自动保存Previous Feedback第 2 次迭代起上次的评论显示在文本框下方。Benchmark 标签页展示统计摘要各配置的通过率、计时与 token 消耗含逐 eval 细分与分析员观察。导航用 prev/next 按钮或方向键。完成后点击 Submit All Reviews所有反馈保存到feedback.json。第 5 步读取反馈用户告知完成后读取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_PID 2/dev/null改进技能循环的心脏这是整个闭环的核心。测试已跑完、用户已审阅结果现在要根据反馈把技能改得更好。如何思考改进从反馈中泛化。大局在于我们要创建的是能被使用一百万次甚至更多的技能横跨无数不同提示词。你和用户现在只在少数几个例子上反复迭代是因为这样推进更快——用户对这些例子了如指掌能快速评估新输出。但如果你们共同开发的技能只对这些例子有效那就毫无用处。与其做琐碎过拟合的改动或令人窒息的 MUST不如在遇到顽固问题时换用不同的隐喻或推荐不同的工作模式——尝试成本很低说不定能碰到好方案。保持提示词精简。删掉那些不配位的内容。务必阅读转录transcripts而不只是最终输出——如果技能让模型在无产出的事情上浪费大量时间可以试着删掉导致这一点的技能部分再看看效果。解释为什么。尽力解释你要求模型做的每件事背后的原因。当今的 LLM 很聪明具备良好的心理理论在好的驾驭harness下能超越死板指令真正做成事。即使用户反馈简短或充满挫败感也要真正理解任务、理解用户为什么写那些话、到底写了什么然后把这份理解传导进指令。如果你发现自己写出全大写的 ALWAYS 或 NEVER或用超刚性结构那就是一个黄旗——尽可能换个框架、解释推理过程让模型理解你要求的事情为什么重要。这是更人道、更有力、也更有效的方法。寻找跨测试用例的重复工作。阅读测试运行的转录留意子代理们是否都独立写了类似的辅助脚本或采用了相同的多步骤方案。如果 3 个测试用例全都导致子代理各写了一份create_docx.py或build_chart.py这是强烈信号技能应该内置该脚本。写一次放进scripts/让技能指示使用它。这能为未来每次调用省去重复造轮子。这个任务相当重要你的思考时间不是瓶颈——慢慢来真正想透。建议先写一版修订草稿再以全新视角审视改进。尽最大努力进入用户的头脑理解他们想要什么、需要什么。迭代循环改进技能后将改进应用到技能上把所有测试用例重新跑进新的iteration-N1/目录包括基线运行。创建新技能时基线永远是without_skill不带技能各迭代保持一致改进已有技能时用你的判断决定基线用哪个版本用户最初带来的原版还是上一迭代用--previous-workspace指向上一迭代来启动查看器等待用户审阅并告知完成读取新反馈再次改进重复。持续迭代直到满足任一条件用户表示满意反馈全部为空一切正常你不再有有意义的进展。进阶盲比较Blind Comparison当需要更严格地比较技能的两个版本时例如用户问新版本真的更好吗可以使用盲比较系统。详细说明见 agents/comparator.md 与 agents/analyzer.md。基本思想是把两份输出交给一个独立代理不告诉它哪份由哪个技能产生让它评判质量然后分析获胜方为什么赢。从 agents/comparator.md 看比较器根据 eval 任务生成双维评分表——内容维度正确性/完整性/准确性1-5 分与结构维度组织/格式/可用性1-5 分以评分总分为首要判据、断言通过率为次要判据输出包含winnerA/B/TIE、reasoning、rubric、output_quality与可选expectation_results的 JSON随后 agents/analyzer.md 中的Post-hoc Analyzer揭开盲区对比两份技能的 SKILL.md 与转录产出winner_strengths、loser_weaknesses、instruction_following评分与按优先级/类别instructions、tools、examples、error_handling、structure、references组织的improvement_suggestions其对应数据结构见 schemas.md 中的comparison.json与analysis.json。这是可选的需要子代理多数用户用不上——人工评审循环通常已足够。Description 优化提高触发准确率SKILL.md frontmatter 中的 description 字段是决定模型是否调用技能的主要机制。创建或改进技能后主动提出为 description 做优化。第 1 步生成触发评测查询创建 20 条评测查询——混合应触发与不应触发。保存为 JSON[ {query: the user prompt, should_trigger: true}, {query: another prompt, should_trigger: false} ]查询必须真实是 Claude Code 或 Claude.ai 用户会实际键入的内容——不是抽象请求而是具体、详细、信息量充足的请求。例如文件路径、关于用户工作或处境的个人背景、列名与取值、公司名、URL一点点背景故事。有些可以全小写、含缩写或拼写错误、口语化。混合不同长度聚焦边界情况而非边界清晰的案例用户之后有机会签署确认。坏示例Format this data、Extract text from PDF、Create 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 条最有价值的是擦边球near-misses——与本技能共享关键词或概念、但实际上需要别的能力的查询。考虑相邻领域、模糊措辞朴素关键词匹配会误触发但不应触发、以及查询涉及技能所做的事但上下文里别的工具更合适的案例。关键要避免不要让不应触发的查询明显不相关。对 PDF 技能而言Write a fibonacci function 作为负例太容易了——它什么都测不出来。负例应真正棘手。第 2 步与用户一起审查使用 HTML 模板向用户呈现评测集从assets/eval_review.html读取模板替换占位符__EVAL_DATA_PLACEHOLDER__→ 评测项的 JSON 数组两侧不加引号——它是一次 JS 变量赋值__SKILL_NAME_PLACEHOLDER__→ 技能名__SKILL_DESCRIPTION_PLACEHOLDER__→ 技能当前的 description写入临时文件如/tmp/eval_review_skill-name.html并打开open /tmp/eval_review_skill-name.html用户可编辑查询、切换 should-trigger、增删条目然后点击 Export Eval Set文件下载到~/Downloads/eval_set.json——检查 Downloads 文件夹里最新的版本可能有多份如eval_set (1).json。这一步很重要——糟糕的评测查询会导致糟糕的 description。第 3 步运行优化循环告诉用户This will take some time — Ill run the optimization loop in the background and check on it periodically.把评测集保存到工作区然后后台运行python -m scripts.run_loop \ --eval-set path-to-trigger-eval.json \ --skill-path path-to-skill \ --model model-id-powering-this-session \ --max-iterations 5 \ --verbose使用系统提示中的模型 ID即驱动当前会话的模型这样触发测试才匹配用户实际体验。运行时周期性 tail 输出向用户汇报当前进行到第几次迭代、分数如何。这处理完整的优化循环把评测集按 60% 训练 / 40% 保留测试切分评估当前 description每条查询跑 3 次以获得可靠触发率然后让 Claude 根据失败情况提出改进对每个新 description 在训练集与测试集上重新评估最多迭代 5 次。完成后在浏览器中打开一份 HTML 报告展示每次迭代的结果并返回含best_description的 JSON——按测试集分数而非训练集分数选择以避免过拟合。从 scripts/run_loop.py 的实现看其split_eval_set函数按should_trigger分层切分训练/测试集循环内组合run_eval评测当前描述与improve_description调用模型提出改进并跟踪历史记录对应 schemas.md 中的history.json含各版本 pass_rate、grading_resultbaseline/won/lost/tie与current_best标记。技能触发机制的工作原理理解触发机制有助于设计更好的评测查询。技能出现在模型的available_skills列表中附带 name description模型根据该 description 决定是否查阅技能。关键认知是模型只为它无法轻易独立完成的任务查阅技能——像 read this PDF 这样的单步简单查询即使 description 完美匹配也可能不触发技能因为模型用基础工具可直接处理。复杂、多步或专业化的查询在 description 匹配时能可靠触发技能。因此评测查询必须足够有分量让模型确实能从查阅技能中获益。像 read file X 这样的简单查询是糟糕的测试用例——无论 description 质量如何它们都不会触发技能。第 4 步应用结果从 JSON 输出中取出best_description更新技能的 SKILL.md frontmatter。向用户展示前后对比并报告分数。打包与呈现仅当present_files工具可用时检查你是否拥有present_files工具。没有则跳过此步。有则打包技能并向用户呈现.skill文件python -m scripts.package_skill path/to/skill-folder赞分享人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载相关推荐Report structureReport structure ALWAYS use this exact template: Title Executive summary Key finAI 应用大模型桌面应用本地部署RAGReport structureReport structure ALWAYS use this exact template structure: Analysis Title Execut前端UI组件Report structureReport structure ALWAYS use this exact template structure: Analysis Title Execut人工智能大模型AI AgentAgent 框架多智能体工具调用MCP ClientsRAG模型评测数据生成上一篇BotBrowser安全测试最佳实践授权隐私研究环境配置指南下一篇Pueue系统服务集成如何将pueued配置为系统守护进程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考