本文探讨了构建Agent系统安全攻击Case库的必要性与方法。针对Agent系统模型行为随版本变化的特点（如Prompt调整、工具新增等），提出需要建立可重复、可回归、可自动化的安全测试机制。文章详细介绍了安全Case库的结构化设计（包含用例编号、攻击类型、攻击输入和期望行为等字段），列举了Prompt注入、工具注入、数据泄露和权限绕过等常见攻击类型，并建议以JSON/YAML/CSV格式维护案例

AI 辅助测试，不是让 AI 直接替我生成需求分析、测试点和脚本。更核心的是，先把测试判断体系沉淀下来，再通过规则、流程和反馈机制，让 AI 逐步按我的思路执行，并持续优化。工具会变，模型会变，平台也会变。但只要判断框架和反馈闭环还在，这套能力就能继续迁移。

在自动化测试里，脚本写出来并不难，真正麻烦的是后续维护。很多失败并不是真正的功能缺陷，而是 locator 变化、placeholder 调整、断言文本不一致这类高频、低难、重复性的维护问题。这次实践没有继续围绕“AI 会不会生成 Playwright 脚本”去做，而是换了一个更贴近测试日常的问题：AI 能不能参与自动化测试维护流程，完成失败归因、最小修复和回归验证这条闭环。本文记录这次最小实践的

你没办法说哪个”对”、哪个”错”，你只能去定义——什么范围内的回答是可接受的，然后想办法把系统行为控制在这个范围里。造数接口、清数接口、日志查询、状态校验、回归执行入口，这些能力如果没有被标准化，AI就只能给建议，没办法真正帮你做事。状态写入不稳定，后续的行为和输出都不可信。∙不再是”发现问题报Bug”，而是”定义规则，让问题可复现、可回归”输出层：结果是否可信，有没有幻觉，该拒答的时候有没有拒答

在 AI Agent 系统中，大模型并不会直接执行系统操作，而是通过 Tool 来完成业务逻辑。因此理解，是理解 AI 系统行为的关键。本文重点拆解。核心问题包括：Agent是怎么触发Tool的？Function Calling是怎么工作的？如何控制模型调用Tool？如果模型乱调用怎么办？

在完成打卡 / 日报 Agent v1.0 的基础功能后，通过真实交互日志 + 用例执行，对当前版本进行了一轮系统性的 Bug 梳理。将零散的异常现象合并为可复现、可归因、可修改的 Bug 清单，并明确区分了代码缺陷与业务策略问题。通过这次整理，我重点暴露了输入解析、对话状态维护、一致性/幂等性等基础问题，为后续 v1.1 的修复与规则收敛提供了明确方向。这套从“用例执行 → Bug 合并 → 清

AI系统评测与传统测试存在本质差异：由于AI输出具有生成性、决策性和不确定性，需构建系统化评测体系。文章提出三层评测模型：1）行为层验证Tool调用决策；2）状态层检查数据一致性；3）输出层评估结果质量。采用回归集和BadCase数据集驱动测试，覆盖正常流程与边界场景，并发现情绪输入误触发等典型问题。当前以人工评估为主，未来将向自动化评测演进。核心转变在于：从验证"功能正确"升

在实现一个用于打卡提醒与日报辅助的个人 Agent 过程中，我没有一开始就写代码，而是先花时间梳理：真实工作场景下的输入，哪些应该触发 Function Calling，哪些必须被系统拦住。通过把日常工作中的自然语言输入进行分类，我逐步明确了“事实输入、查询输入、情绪/评价输入、越界输入”等边界，并据此约束 Agent 的行为。这篇笔记记录了我在项目实践中，如何从真实输入出发，为 AI Agent

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

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