走廊测试 是做什么的？
名字来源于在走廊里抓一个人，看着他们使用产品。这里的“人”是一个子代理，它没有看过实现、规格说明或生成代码的对话，因此无法“忘记”作者知道的信息。它阅读需求文档和面向用户的文档，决定应该发生什么，亲自尝试，然后报告现实与预期的差异。在 modama 爬虫项目中，一个下午就发现了价值二十个实验的行为，包括测试套件已经“固化”的缺陷。
两种模式，通常组合使用：
- 行为模式：测试者构建测试输入，在运行前为每个输入写下期望，然后运行工具，比较结果，分类。
- 肉眼模式：针对面向人眼的输出，测试者在真实终端中驱动工具并判断截图，从而捕获文本解析永远看不到的问题：滚动出屏幕的输出、被噪声淹没的信号、换行、分页器隐藏的调试信息。随附的驱动脚本
${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py在虚拟 X 服务器下启动 xterm，发送按键并截图；它需要安装xvfb、xterm、xdotool和imagemagick（ImageMagick 的import），这些可以通过 devcontainer 托管。
一个借用来的检查清单，感谢：MIT 许可的 cli-ux-tester 技能（作者 ali5ter）中的十一条 CLI 可用性标准，位于 ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md，作为命令行工具的额外检查环节。
启动前
与用户确定以下事项，它们将成为测试者的任务简报：
- 测试者可以阅读的内容。 仅限于首位用户能接触到的：需求文档、用户文档、命令的帮助信息。明确指出文件或目录；明确禁止其余内容（源代码、测试、规格说明、设计笔记、git 历史）。测试的重点是新鲜视角；每增加一份文档都会削弱这一效果。
- 工具及其运行方式。 命令行或入口点，测试输入应创建的位置（临时目录，绝不能是仓库），可以安装什么，绝对不能碰什么（例如只读数据挂载）。
- 必须覆盖的内容。 取自需求文档和上次玩法测试缺口的一系列测试场景，加上“自行添加实验”。对于肉眼测试：场景、终端尺寸、按键序列。
- 谁回答问题。 当需求未说明应该发生什么时，测试者向主会话提问；主会话根据设计回答，并将自己无法自信回答的内容记录为待办事项，交给项目所有者。
- 报告存放位置 和摘要长度。
任务简报
在后台生成一个通用子代理，任务简报基于模板 ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md 构建：角色（“一位首次尝试此工具的关键早期用户，作为研究软件工程师”）、严格的阅读规则、用户视角的命令参考、方法（创建→先写期望→运行→比较→分类为“匹配/缺陷/意外但合理/缺口/疑问”）、强制覆盖范围、提问指令和报告结构。对于肉眼测试，使用 ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md 中的简报，该模板描述了驱动脚本，并强调测试者只能基于截图进行判断。
模型选择：肉眼测试者可以使用更便宜的模型，它负责观察和报告；行为测试者受益于主会话的模型，因为它需要推理应该发生什么。
运行期间
根据设计回答测试者的问题，附上推理过程，并在问题暴露一个缺陷时通知测试者（然后按照正常方式修复缺陷，附带测试，并告知测试者工具已更改）。保留一份你无法自信回答的问题清单；这些问题应作为“决策”而非“猜测”交给项目所有者。
之后
- 阅读报告。在接受每个缺陷声明前，对照代码进行验证；没有源代码访问权限的测试者仅描述症状，原因可能不同。
- 将持久记录写入项目设计笔记（例如
design/playtest.md）：哪些被阻止了，哪些已修复并附带了测试和规格场景，给出的答案，以及一份为项目所有者准备的待办事项清单，每项附带你的倾向性意见。 - 对于每个缺陷，回答“本应如何捕捉到它”并添加对应措施：一个测试、一条规则、一项检查。没有这个答案的缺陷只修复了一半。
- 保持测试者的目录和截图可重现：编写一个能重新运行任何实验的小脚本，保存在报告旁边或临时目录中，路径在记录中注明。
规则
- 测试者绝不修改仓库，绝不读取被禁止的内容，并在报告中说明自己获得了哪些信息，包括测试框架附加的、它未主动请求的内容。
- 期望值必须在运行前写下，否则比较毫无意义。
- 每条发现都是一个时刻：具体的命令、期望的结果、观察到的结果、相关的 stderr 行或截图文件名。
- 不要在任何测试者作为问题报告的内容上立即修复；先判断它是缺陷还是设计选择，然后附带测试进行修复。