尧图网页设计 
如何为AI插件写评估测试portal-ai-plugins的51个测试套件与Token节省基准方法论完整解析【免费下载链接】portal-ai-plugins项目地址: https://gitcode.com/gh_mirrors/po/portal-ai-pluginsportal-ai-plugins是 Spotify 官方开源的 AI 插件市场其中shunt插件能把大块文件读取和样板代码生成委托给更便宜的 worker 模型宣称节省 82%–94% 的 Token。但省钱这个卖点如何被证明答案是 plugins/shunt/evals/ 目录下的一套完整评估测试体系51 个自动化测试套件 4 个 Token 节省基准场景。本文带你拆解这套方法论无论你写的是 Claude Code 插件还是其他 AI 工具链都能直接借鉴。为什么AI插件需要评估测试传统软件测试验证功能是否正确而 AI 插件还多了一个独特挑战成本行为。一个读取大文件的插件可能功能正常但悄悄烧掉几十万 Token。shunt 的评估体系同时回答两个问题路由是否正确Hook 该拦的大文件读没拦住该放行的定向读取放没放行账算没算对委托出去后上下文里到底少了多少 Token这也是整套体系的核心思路功能正确性与成本正确性必须分开度量。51个测试套件总览三层递进结构51 个测试不是堆在一起的而是按风险从低到高分成三层全部由 plugins/shunt/evals/run.sh 一个入口统一调度层级测试对象文件用例数是否需要 Portal 连接① Hook 路由两个 PreToolUse Hookhook-evals.json bash-hook-evals.json17 17❌ 不需要② 传输层scripts/lib/aika.sh 的调用封装transport-evals.sh17❌ 用桩代替 CLI③ 端到端Claude 是否真的会调用脚本evals.json3✅ 需要真实环境④ 基准Token 节省率benchmarks.json4 个场景✅ 需要认证前两层是离线可跑的纯单元测试CI 里随时能跑后两层是真实回归发布前手动执行。这种离线兜底 在线回归的划分是 AI 插件评估测试最值得抄的一点。第一层Hook决策测试的黄金样本设计shunt 的两个 Hook 是硬闸门check-file-size 拦截对 350 行以上文件的整体读取check-bash-read 拦截cat/head/tail等批量读命令。17 个 Read Hook 用例hook-evals.json展示了边界值测试的教科书式写法boundary-exact-350恰好 350 行 →放行阈值是大于而非大于等于just-over-threshold351 行 →拦截targeted-read-offset/targeted-read-limit大文件但带了 offset/limit →放行env-override-higherSHUNT_MIN_LINES500时 351 行文件 →放行env-non-numeric-fallbackSHUNT_MIN_LINESabc→回退到默认值特别注意两个offset:0、limit:0的用例——它们把已知的绕过行为显式写成用例并标注documenting behavior。AI 插件的评估测试不只是防回归也是行为文档每个放行/拦截的边界都用一条用例钉死。Bash Hook 的 17 个用例bash-hook-evals.json同样精彩cat file | grep放行、cat file out放行、带引号路径cat file必须拦截甚至把解析器的已知 bughead -n 5 file中5被误认为文件路径也固化成了用例。每个用例都带reason字段——测试失败时你能直接读出为什么它应该是这个决策而不必反查源码。第二层用桩Stub隔离外部依赖传输层测试transport-evals.sh验证aika.sh如何组装 payload、解析响应。它的关键技巧是桩替 CLIshunt_portal() { # 记录收到的参数返回预制的 JSON 响应 echo {text:- first line,mode:{id:id-bulk,name:bulk-reader}} }桩函数捕获每次调用的 payload然后逐字段断言mode_name与mode_id互斥、不发送 history每次委托都是独立的、超尺寸 payload 必须在发送前报错而非撞上E2BIG、stderr 噪音不能污染 stdout 的 JSON 信封。17 个断言全部零网络、零 Token、零 Portal 实例即可完成。这就是为什么 run.sh 注释里强调传输层需要桩不需要认证——把最易碎的通信契约用最便宜的方式锁住。第三层端到端测试验证AI真的会这么干吗前两层测的是插件代码对不对端到端测试evals.json测的才是 AI 插件最脆弱的环节模型会不会按预期行为。只有 3 条但每条都对应一个关键决策问 602 行的 websocket-handler.ts 导出了什么 → 期望 Claude 被 Hook 拦截后调用bulk-read脚本而不是硬读全文照 OrderService 的测试模式给 UserService 写单测 → 期望 Claude 用--spec--reference--target调code-write修掉第 42 行的 bug → 期望 Claude不要委托用 offset/limit 定向读取后自己推理第 3 条尤其重要它测的是**不该做什么**。AI 插件最常见的失败不是不会干活而是过度委托——把需要推理的调试任务甩给只会总结的 worker。评估测试里必须有拒绝路径的用例。Token节省基准一个可复算的成本公式真正的省钱证明在 benchmarks.json4 个场景单大文件读取、跨服务多文件读取、源码测试对读取、代码生成全部基于仓库里可复现的 fixture 文件。基准方法run.sh 的 run_benchmarks用一条极简但可辩护的估算公式Token ≈ 字符数 / 4对代码偏保守的近似且输出 Token 按 5 倍权重计费对齐 Opus 的输入/输出价差对比口径是同一次任务上下文里进了多少内容bulk-read 场景无 shunt 文件全文进 Claude 上下文有 shunt 只有 AiKA 的摘要进上下文code-write 场景无 shunt 读上下文文件输入 生成代码输出 ×5有 shunt Claude 只发一条短 spec代码直接落盘输入侧记 0实测结果对着一个 16.2 万行的 Java 单体仓库场景无 shunt有 shunt节省单个大文件4,014 行33,684 tokens5,737 tokens82%源码测试对7,408 行75,990 tokens4,148 tokens94%多文件跨服务1,281 行16,221 tokens821 tokens94%基准输出带颜色分级80% 绿、50% 红并且公式和口径直接打印在结果表下方——任何读者都能用自己的数据复算。这正是基准方法论的灵魂省钱数字必须可复算否则只是营销话术。一键运行评估测试的三种模式整套体系只有一个入口 run.sh三种用法对应三种信任级别bash evals/run.sh # Hook 路由 传输层51 个测试无需任何 Portal 权限 bash evals/run.sh --benchmark # 追加 Token 节省基准需 portal-cli 认证 bash evals/run.sh --all # 全量套件细节上还有几个值得学习的设计fixture 按需生成setup_fixtures读 JSON 里声明的fixture.lines现场seq生成对应行数的临时文件测完即删——测试数据零维护{{FIXTURES}}占位符JSON 用例与临时路径解耦同一份用例可复用于任意目录传输层在子进程里跑防止桩函数泄漏进后续需要真实 CLI 的基准环节失败即非零退出码直接可挂 CI方法论总结AI插件评估测试的5条经验分层隔离成本路由决策、传输契约、端到端行为、成本基准四层分开测越便宜的层跑越勤边界值钉死行为阈值±1、空值、畸形配置各一条用例reason字段写清为什么桩掉外部世界用捕获 payload 的桩函数验证通信契约让 90% 的测试零依赖测不做什么AI 插件最贵的一类 bug 是过度委托必须有反例用例基准必须可复算公开估算公式、权重假设和数据口径让节省 90%变成可验证的数学而非口号这套 51 个测试 4 个基准的体系与其说是一套测试不如说是一份 AI 插件质量与成本的验收标准。如果你想为自己的 Claude Code 插件补上评估能力从 plugins/shunt/evals/ 的目录结构抄起就对了。【免费下载链接】portal-ai-plugins项目地址: https://gitcode.com/gh_mirrors/po/portal-ai-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何为AI插件写评估测试？portal-ai-plugins的51个测试套件与Token节省基准方法论完整解析
如何为AI插件写评估测试portal-ai-plugins的51个测试套件与Token节省基准方法论完整解析【免费下载链接】portal-ai-plugins项目地址: https://gitcode.com/gh_mirrors/po/portal-ai-pluginsportal-ai-plugins是 Spotify 官方开源的 AI 插件市场其中shunt插件能把大块文件读取和样板代码生成委托给更便宜的 worker 模型宣称节省 82%–94% 的 Token。但省钱这个卖点如何被证明答案是 plugins/shunt/evals/ 目录下的一套完整评估测试体系51 个自动化测试套件 4 个 Token 节省基准场景。本文带你拆解这套方法论无论你写的是 Claude Code 插件还是其他 AI 工具链都能直接借鉴。为什么AI插件需要评估测试传统软件测试验证功能是否正确而 AI 插件还多了一个独特挑战成本行为。一个读取大文件的插件可能功能正常但悄悄烧掉几十万 Token。shunt 的评估体系同时回答两个问题路由是否正确Hook 该拦的大文件读没拦住该放行的定向读取放没放行账算没算对委托出去后上下文里到底少了多少 Token这也是整套体系的核心思路功能正确性与成本正确性必须分开度量。51个测试套件总览三层递进结构51 个测试不是堆在一起的而是按风险从低到高分成三层全部由 plugins/shunt/evals/run.sh 一个入口统一调度层级测试对象文件用例数是否需要 Portal 连接① Hook 路由两个 PreToolUse Hookhook-evals.json bash-hook-evals.json17 17❌ 不需要② 传输层scripts/lib/aika.sh 的调用封装transport-evals.sh17❌ 用桩代替 CLI③ 端到端Claude 是否真的会调用脚本evals.json3✅ 需要真实环境④ 基准Token 节省率benchmarks.json4 个场景✅ 需要认证前两层是离线可跑的纯单元测试CI 里随时能跑后两层是真实回归发布前手动执行。这种离线兜底 在线回归的划分是 AI 插件评估测试最值得抄的一点。第一层Hook决策测试的黄金样本设计shunt 的两个 Hook 是硬闸门check-file-size 拦截对 350 行以上文件的整体读取check-bash-read 拦截cat/head/tail等批量读命令。17 个 Read Hook 用例hook-evals.json展示了边界值测试的教科书式写法boundary-exact-350恰好 350 行 →放行阈值是大于而非大于等于just-over-threshold351 行 →拦截targeted-read-offset/targeted-read-limit大文件但带了 offset/limit →放行env-override-higherSHUNT_MIN_LINES500时 351 行文件 →放行env-non-numeric-fallbackSHUNT_MIN_LINESabc→回退到默认值特别注意两个offset:0、limit:0的用例——它们把已知的绕过行为显式写成用例并标注documenting behavior。AI 插件的评估测试不只是防回归也是行为文档每个放行/拦截的边界都用一条用例钉死。Bash Hook 的 17 个用例bash-hook-evals.json同样精彩cat file | grep放行、cat file out放行、带引号路径cat file必须拦截甚至把解析器的已知 bughead -n 5 file中5被误认为文件路径也固化成了用例。每个用例都带reason字段——测试失败时你能直接读出为什么它应该是这个决策而不必反查源码。第二层用桩Stub隔离外部依赖传输层测试transport-evals.sh验证aika.sh如何组装 payload、解析响应。它的关键技巧是桩替 CLIshunt_portal() { # 记录收到的参数返回预制的 JSON 响应 echo {text:- first line,mode:{id:id-bulk,name:bulk-reader}} }桩函数捕获每次调用的 payload然后逐字段断言mode_name与mode_id互斥、不发送 history每次委托都是独立的、超尺寸 payload 必须在发送前报错而非撞上E2BIG、stderr 噪音不能污染 stdout 的 JSON 信封。17 个断言全部零网络、零 Token、零 Portal 实例即可完成。这就是为什么 run.sh 注释里强调传输层需要桩不需要认证——把最易碎的通信契约用最便宜的方式锁住。第三层端到端测试验证AI真的会这么干吗前两层测的是插件代码对不对端到端测试evals.json测的才是 AI 插件最脆弱的环节模型会不会按预期行为。只有 3 条但每条都对应一个关键决策问 602 行的 websocket-handler.ts 导出了什么 → 期望 Claude 被 Hook 拦截后调用bulk-read脚本而不是硬读全文照 OrderService 的测试模式给 UserService 写单测 → 期望 Claude 用--spec--reference--target调code-write修掉第 42 行的 bug → 期望 Claude不要委托用 offset/limit 定向读取后自己推理第 3 条尤其重要它测的是**不该做什么**。AI 插件最常见的失败不是不会干活而是过度委托——把需要推理的调试任务甩给只会总结的 worker。评估测试里必须有拒绝路径的用例。Token节省基准一个可复算的成本公式真正的省钱证明在 benchmarks.json4 个场景单大文件读取、跨服务多文件读取、源码测试对读取、代码生成全部基于仓库里可复现的 fixture 文件。基准方法run.sh 的 run_benchmarks用一条极简但可辩护的估算公式Token ≈ 字符数 / 4对代码偏保守的近似且输出 Token 按 5 倍权重计费对齐 Opus 的输入/输出价差对比口径是同一次任务上下文里进了多少内容bulk-read 场景无 shunt 文件全文进 Claude 上下文有 shunt 只有 AiKA 的摘要进上下文code-write 场景无 shunt 读上下文文件输入 生成代码输出 ×5有 shunt Claude 只发一条短 spec代码直接落盘输入侧记 0实测结果对着一个 16.2 万行的 Java 单体仓库场景无 shunt有 shunt节省单个大文件4,014 行33,684 tokens5,737 tokens82%源码测试对7,408 行75,990 tokens4,148 tokens94%多文件跨服务1,281 行16,221 tokens821 tokens94%基准输出带颜色分级80% 绿、50% 红并且公式和口径直接打印在结果表下方——任何读者都能用自己的数据复算。这正是基准方法论的灵魂省钱数字必须可复算否则只是营销话术。一键运行评估测试的三种模式整套体系只有一个入口 run.sh三种用法对应三种信任级别bash evals/run.sh # Hook 路由 传输层51 个测试无需任何 Portal 权限 bash evals/run.sh --benchmark # 追加 Token 节省基准需 portal-cli 认证 bash evals/run.sh --all # 全量套件细节上还有几个值得学习的设计fixture 按需生成setup_fixtures读 JSON 里声明的fixture.lines现场seq生成对应行数的临时文件测完即删——测试数据零维护{{FIXTURES}}占位符JSON 用例与临时路径解耦同一份用例可复用于任意目录传输层在子进程里跑防止桩函数泄漏进后续需要真实 CLI 的基准环节失败即非零退出码直接可挂 CI方法论总结AI插件评估测试的5条经验分层隔离成本路由决策、传输契约、端到端行为、成本基准四层分开测越便宜的层跑越勤边界值钉死行为阈值±1、空值、畸形配置各一条用例reason字段写清为什么桩掉外部世界用捕获 payload 的桩函数验证通信契约让 90% 的测试零依赖测不做什么AI 插件最贵的一类 bug 是过度委托必须有反例用例基准必须可复算公开估算公式、权重假设和数据口径让节省 90%变成可验证的数学而非口号这套 51 个测试 4 个基准的体系与其说是一套测试不如说是一份 AI 插件质量与成本的验收标准。如果你想为自己的 Claude Code 插件补上评估能力从 plugins/shunt/evals/ 的目录结构抄起就对了。【免费下载链接】portal-ai-plugins项目地址: https://gitcode.com/gh_mirrors/po/portal-ai-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考