# 官方唯一测试件，短得可疑 ## 本期概述 ## 先对账：开发者效率四个格子，各摆了什么 | 格子 | 在位玩家 | 证据口径 | |------|---------|---------| | 写码后把关（审查/简化/验证） | 官方审改简验四件、`gh-address-comments` | 本栏 09-24 前后三期存档 | | 修错善后 | `gh-fix-ci`、`notebook-fix`、`encoding-check`、`apk-reverse` | 本栏 09-24 期深拆，`gh-fix-ci` 综合分 4.2 | | 调试方法论 | superpowers 二分法调试件、x64dbg-mcp-server、blitzstrike | 本栏 09-20 期；调试件装机 177.6K（07-08 口径） | | 测试验证 | `webapp-testing`（官方）、`pptx-test`（本机产线件） | 本期实读 | ## 主拆 webapp-testing：短，是因为复杂度全外包了 先交代出身：`webapp-testing` 收录在 Anthropic 官方 skills 仓库。本栏 08-29 期存档记过一个数字——官方仓库彼时仅 19 个件，重心全在文档与设计（docx/pptx/pdf），开发者效率方向「只有 webapp-testing 勉强沾边」。今天把它请上手术台，发现这个「勉强沾边」的件，是整条效率货架上设计密度最高的文本之一。 ### 正文第一句就亮了底牌 SKILL.md 开门见山：**「To test local web applications, write native Python Playwright scripts.」**——测试本地 Web 应用，就写原生 Playwright 脚本。 这句话的信息量在「原生」二字。它不引入测试框架、不生成 fixture、不造 pytest 目录结构，甚至不承诺输出可回归的测试套件。它默认你枪里有子弹（Playwright 生态成熟），自己只干一件事：**让模型在正确的时机、用正确的方式开枪**。整篇正文，实质上只有三样东西：一棵决策树、一个黑盒脚本、一条戒条。 ### 决策树：四叉把场景切干净 正文第二节是一棵 ASCII 决策树，第一刀切「静态还是动态」：静态 HTML 直接读文件找 selector，读不出来就降级按动态处理；第二刀切「服务器起没起」：没起就调 `with_server.py` 托管，起了就走「侦察-再行动」。两个问题、四个出口，把 Web 测试的全部开场场景覆盖完。没有第五个分支——这个克制是官方件和社区件最直观的差别，社区件爱把「可能有用」的分支都写上，官方件只留「必然遇到」的。 ### 黑盒纪律：全篇最狠的一段 紧跟着 --help 提示，正文写了一段在官方件里罕见的强硬条款： > Always run scripts with `--help` first. DO NOT read the source until you try running the script first and find that a customized solution is absolutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window. 翻译过来：先跑 --help，**不许读源码**，除非跑完发现非改不可。理由写得毫不遮掩——脚本很大，读进来会污染你的上下文窗口；「它们的存在方式是被调用，而不是被读进上下文」。 这段话值得单独起一节，因为它处理的是 SKILL.md 设计里最隐蔽的坑：**件本身就是往上下文里注入的文本，而件引用的资源文件是二次注入**。一个大脚本全文进上下文，轻则挤掉正事，重则让模型把脚本细节当任务。官方的处理方式不是「建议」，是禁令，且禁令附带了物理理由。这一条对写社区件的读者的启发价值，超过本件其余部分的总和。 ### with_server.py：双服务器托管是隐藏加分项 从 --help 示例看，这个脚本支持多服务器并行托管： ```bash python scripts/with_server.py \ --server "cd backend && python server.py" --port 3000 \ --server "cd frontend && npm run dev" --port 5173 \ -- python your_automation.py ``` 前后端双进程、端口就绪检测、跑完回收——自动化测试最脏的活全在脚本里，SKILL.md 里一个字不提。这是「门牌与正本」关系的正面典型：正文薄，是因为厚活都在不许读的脚本里。 ### 唯一戒条：networkidle 的三连击 整篇「Common Pitfall」一节只有一对正误对照： > ❌ Don't inspect the DOM before waiting for `networkidle` on dynamic apps > ✅ Do wait for `page.wait_for_load_state('networkidle')` before inspection 而示例代码里，`wait_for_load_state('networkidle')` 上方注释写着 **CRITICAL**。同一件事在一件之内出现三次：示例标一次、坑位节立戒条、侦察流程第一步再写一遍。Playwright 实战里最高频的翻车就是 JS 没跑完就去查 DOM，官方把这一个坑拎出来反复钉，其余坑一个不提——**戒条的价值在少，不在全**。 ### 侦察-再行动：不预判 selector 对「服务器已在跑」的场景，件给出的流程是：先导航等 networkidle，再截图或查 DOM，从渲染结果里认 selector，最后才动手执行。这个「Reconnaissance-then-Action」模式针对的正是大模型的顽疾——凭训练记忆瞎猜 selector（`#submit-btn` 这种想当然的 ID）。先看再打，四个范例脚本（`element_discovery.py` 元素发现、`static_html_automation.py` 静态页、`console_logging.py` 控制台采集）里第一个就是元素发现，排序都是故意的。 ### 短板也诚实 它不教你 Playwright。不会写 `page.locator` 的人拿到这件，得到的只是「去写 Playwright」的许可和一个好脚手架；它也不产出可回归的测试资产——每次都是现场写、跑完即弃，想留回归套件得自己另起炉灶。功能完整度四星，扣的一星扣在这。 ## 副拆 pptx-test：流水线上的试产台 第二件 `pptx-test` 是本机部署的中文件（路径 `~/.claude/skills/pptx-test`），定位写在副标题里：「PPTX 幻灯片单页测试验证——在批量生成前验证样式和编码」。 它的设计逻辑是制造业的**试产**：批量生产前，先做一张测试片，把最容易翻车的五类问题一次验完——HTML/CSS 渲染、长文本换行、中文 UTF-8 显示、emoji 与特殊符号、python-pptx 的 `.rgb` 颜色属性兼容性。SKILL.md 自带测试模板（中英混排、checkmark、箭头符号、代码块全塞进一张片子里），通过后打印「All tests passed! Ready for batch processing.」，再移交 `/pptx-batch` 批量生成。 两个设计细节值得记： **失败处理做成配对表**。每条失败都跟一个箭头对策：「✗ Chinese characters garbled → Add encoding='utf-8'」「✗ Text overflow → Implement manual text wrapping logic」。这不是文档，是把该产线历史上踩过的坑连同解法成对印刷——和 webapp-testing 的单戒条是两种哲学：产线件求全（每条失败都有预案），台子件求精（只钉最高频的坑）。 **触发方式是显式斜杠命令**。`/pptx-test test-slide.md`，人叫才动。这与 webapp-testing 形成调用模型的两个极端：一个靠描述让模型自己判断何时进场，一个靠命令精确点名。单页试产这种「时机比能力重要」的活，显式触发显然更对——自动触发反而会在不该试产的时候浪费一轮。 短板是它单件不成立：离开 `/pptx-batch` 那条产线，试产台没有存在意义；全中文正文也决定了它就是为中文 PPT 产线定制的，不会有人把它装进通用工具箱。 ## 横评对比表 综合分按本栏标准权重：功能 25%、设计 25%、实战 20%、上手 15%、社区 15%；上手难度星越多越容易。三个参照件引自存档判词，口径分列注明。 | 件 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | 综合 | |----|-----------|---------|---------|---------|-----------|------| | webapp-testing（官方） | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | **4.1** | | pptx-test（本机产线件） | ★★★ | ★★★★ | ★★★ | ★★★★★ | ★★ | **3.4** | | gh-fix-ci（09-24 存档原分） | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★ | **4.2** | | superpowers 调试方法论件* | ★★★ | ★★★★ | ★★★ | ★★★★★ | ★★★★★ | 3.8 | | mattpocock triage* | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | **4.4** | > \* 按 09-20 期「E0 层判词」（零配置赢纪律、复现不出就无解）折算；triage 按本栏 08-29 期拆解（状态机+门控+AI 披露行，624.4K 安装）折算。两者非测试件，列出仅为定位参照。 ## 一张图看懂 webapp-testing 的全部流程 ```mermaid flowchart TD T["用户任务"] --> Q1{"静态 HTML？"} Q1 -->|是| R1["直接读文件找selector"] Q1 -->|否| Q2{"服务器已在跑？"} Q2 -->|否| R2["with_server.py 托管启停"] Q2 -->|是| R3["侦察再行动"] R1 --> W["现场写Playwright脚本"] R2 --> W R3 --> W W --> N["networkidle后再查DOM"] ``` ## 测试格的货架全景 ```mermaid flowchart TD subgraph S1["写码把关格：重兵把守"] A1["官方审改简验四件"] A2["mattpocock 流程套件"] end subgraph S2["修错善后格：四件族"] B1["gh-fix-ci"] B2["notebook-fix"] B3["encoding-check"] B4["apk-reverse"] end subgraph S3["测试验证格：仅两件"] C1["webapp-testing"] C2["pptx-test"] end subgraph S4["测试生成与重构格"] D1["空位"] end ``` ## 赛道判词：为什么测试格最薄 三个二十万星级仓库都不做测试，官方也只放一件，这不是巧合。审查、修错、调试三格的共同点是**有明确的失败信号**：红灯、报错栈、issue——件只需要接住信号。测试格没有信号，它要回答的是「你怎么知道它是对的」——这需要先造信号（断言、预期、试产样张），再验证信号。造信号是设计工作，是整条开发链里最难压缩成提示词的一环。webapp-testing 的解法是直接跳过造信号：不产出测试资产，每次现场写现场跑，把测试降级成「带脚手架的手工验证」。这是务实的短路，也解释了它为什么短——**它解决的不是测试问题，是「让模型敢动手」的问题**。 真正的空位在两处：给存量代码补单测的**测试生成**件，和社区侧的**重构**件。前者每一轮 Agent 写码潮都会被重新需要一次；后者官方 simplify 占着位子，社区至今没人叫板。按本栏「高频者生存」的定律，这两个格子是下一波上架潮最该盯的方向。 ## 安装与使用 ```bash # webapp-testing：官方 skills 仓库收录，随官方插件分发 # 本栏环境经 example-skills 插件加载，调用即生效 npx skills@latest add anthropics/skills # pptx-test：本机件，位于用户技能目录，放入即装 # 路径：~/.claude/skills/pptx-test ls ~/.claude/skills/pptx-test # webapp-testing 典型调用形态（双服务器托管） python scripts/with_server.py \ --server "cd backend && python server.py" --port 3000 \ --server "cd frontend && npm run dev" --port 5173 \ -- python your_automation.py # pptx-test 典型调用形态（斜杠命令，显式触发） /pptx-test test-slide.md ``` ## 本期排行榜 - **设计质量榜**：webapp-testing（决策树+黑盒禁令+单戒条，官方范本级）＞ mattpocock triage（状态机门控）＞ pptx-test（清单配对） - **上手友好榜**：pptx-test（斜杠命令一键试产）＞ superpowers 调试件（零配置即用）＞ webapp-testing（需会 Playwright） - **综合榜**：mattpocock triage 4.4 ＞ gh-fix-ci 4.2 ＞ webapp-testing 4.1 ＞ superpowers 调试件 3.8 ＞ pptx-test 3.4 - **空位预警榜**：测试生成 ＞ 社区重构 ＞ 移动端回归（apk-reverse 只管分析不管回归） ## 参考来源 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。