这篇实践笔记记录了我一次具体尝试：将平时写测试用例时会反复检查的规则（结构、边界、异常覆盖等），整理成一个可复用的 Skill，并通过扣子进行调用。Skill 本身不替代人工设计用例，只负责先跑出一版结构清晰、边界明确的用例初稿，便于后续人工 review 和补充。本文不讨论方法论，重点放在实操过程与使用感受，供类似场景参考。

本文记录一次 AI 辅助自动化测试维护流程实践。项目聚焦 UI 自动化中高频出现的 locator 变化、placeholder 变化、文本变化、断言不一致等维护问题，基于 Playwright + Codex 打通了“执行测试 → 读取日志 → 失败归因 → 最小修复 → 回归验证”这条核心链路，并进一步完成了统一 workflow 和连续两轮稳定性验证。

本文探讨了AI在UI自动化测试脚本维护中的应用。通过Playwright测试框架，模拟了按钮定位、输入框placeholder和断言文本三种常见错误场景。实验表明，AI能够分析失败日志、定位问题并自动修复简单测试脚本错误。研究指出，虽然当前验证仅限于基础场景，但AI辅助测试维护具有降低人工成本、提高效率的潜力。文章同时分析了现有局限性，包括未覆盖复杂页面结构和失败原因，并提出了后续探索更复杂场景的

本文探讨如何通过搭建AI测试工程师工作台，将AI从零散使用的聊天工具转变为系统化的工作协作伙伴。作者指出当前AI使用存在上下文丢失、经验难沉淀等问题，提出建立包含项目工作区、风险模型库、测试方法库等模块的结构化工作台。该工作台能实现项目知识沉淀、风险模型复用、测试方法积累等功能，使AI成为贯穿需求分析、系统建模、测试设计等全流程的思考辅助工具。通过这种系统化的工作流，AI不仅能提高测试效率，更能帮

AI在测试领域的核心价值不在于简单的用例生成或效率提升，而是帮助测试工程师快速理解系统。测试工作的真正痛点在于系统理解缓慢，而非用例编写速度。通过AI辅助需求分析、系统建模和风险识别，测试人员能更高效地把握关键业务流程、服务调用关系和历史Bug模式，从而构建完整的"系统地图"。这种从"写用例"到"理解系统"的转变，让测试设计更有针对性，比

本文针对Agent系统的安全性进行了基础测试，设计了6个测试案例，覆盖Web安全、API安全和模型安全等层面。测试发现两个主要风险：未授权删除接口和调试信息泄露，而XSS、Prompt注入等攻击未成功。文章指出Agent安全与传统Web安全不同，更关注模型行为控制而非单纯输入验证，强调系统设计在防范风险中的重要性。建议Agent项目应同时关注API权限、Prompt注入防护和工具调用安全，才能确保

在 Agent 项目中，安全问题不仅来自大模型本身，还可能来自 API、系统设计以及 Tool 调用逻辑。本文从整体架构出发，梳理了一套 Agent 系统安全测试的基本框架，将安全问题划分为 系统层、Agent 层和模型层 三个层级，并分析每一层可能存在的风险。通过这种结构化视角，可以更系统地理解 Agent 项目的安全测试思路。

本篇记录了为 RAG Copilot 构建最小回归集的过程。通过设计 20 条黄金用例（10 条应答、10 条应拒），并引入 decision 日志机制，对系统行为进行量化验证。在 v0.2-regression-baseline 版本中：Overall：85%ANSWER：100%REFUSE：70%这一步的目标不是优化模型能力，而是为 RAG 系统建立“可回归、可解释、可追溯”的质量基线。后续

主观题看起来“没标准”，其实最怕的是改一次就悄悄变味，回归跑不起来。这篇文章梳理一套最小可用的评测方法：先定 Fail-fast 底线（编造事实、违背规则红线、瞎改工具结果直接判 Fail），再用 0/1/2 三档 Rubric 从事实一致性、完成度、可执行性、清晰度四个维度打分。最后挑了 5 条黄金主观题（日报总结、忘打卡风险提醒、明日计划、复盘建议、规则边界说明）拆出 must-have /

最近在梳理 AI 辅助测试时发现，行业讨论大多停留在“生成测试用例”，但从工程实践看，真正有价值的方向已经在转向：让 AI 参与测试工程本身，比如日志分析、回归差异对比、评测问题生成与质量总结等。同时，在传统测试流程中，AI 也可以作为辅助工具，帮助做需求风险梳理、测试点检查、数据生成和报告整理。整体来看，AI 更适合嵌入到测试流程中提升效率，而不是替代测试工作本身。