manual-testing

用途：在代码改动完成后建立紧凑的验证闭环，先用工具证明一切可自动验证的部分，再请用户只检查需要人眼、手、设备或判断力的内容。资料强调不要让用户自己想测试计划，而应由助手带用户逐步完成。\n\n主要能力与流程：\n1. 建立验证矩阵：对每个改动行为记录主要成功路径、最可能的失败或边界情况、一个邻近回归检查，以及该检查由工具还是用户负责。\n2. 优先运行工具可验证的检查：如构建、编译、类型检查、lint、测试、API 响应与状态码、文件输出、数据库状态、日志与副作用、CLI 行为与退出码、生成产物；浏览器自动化、截图、DOM 文本、网络行为也应在工具能证明时自行验证。自动化检查失败时，先停止并解决，再请用户手动验证。\n3. 准备用户路径：给出确切路由、URL、屏幕或命令、所需初始状态、单个操作、预期结果以及需要回复的内容。\n4. 引导原子步骤：一次一个步骤，小范围冒烟测试最多合并两到三个紧密相关检查。格式包含“Testing”“Progress: Step N of M”“Action”“Expected”，并给出一组具体回复选项（含 Other）。如有结构化提问工具则转成结构化提示，否则用纯文本内联选项。\n5. 覆盖合适范围：UI 改动检查初始渲染、加载/空/错误/禁用/成功状态、键盘与焦点路径、移动端或窄宽布局、文案与间距；缺陷修复复现原路径、确认缺陷消失、确认邻近路径仍正常；API 或后端改动检查正常响应、非法输入或失败路径、持久化副作用或下游状态、日志与错误无新增破坏；CLI 或本地工具改动检查成功路径、常见失败路径与退出码、输出文件、stdout/stderr 与帮助文本。\n6. 失败按调试处理：记录失败步骤、预期与实际、可见错误文本或日志截图，决定停止排查还是继续剩余检查；改代码前先提出 2-3 个可能假设。\n7. 以置信度与缺口总结收尾：列出已运行的自动检查及结果、已完成的手动步骤及结果、发现的缺陷或回归、仍未验证的区域与建议下一步。\n\n原则：最小化用户投入、最大化助手投入；让用户一次只处在一个语境；优先具体回复选项而非开放式问题；实用时检查一条成功路径、一条失败路径和一个邻近回归；在请求人工验证前积极使用工具。\n\n限制：资料未说明具体支持的平台、安装方式、命令、收费或效果数据，这些暂未提供。