keqistarry

你的设计思路其实可以概括成一句话： 不是让 AI 直接“替你完成测试”，而是把测试流程拆成“可编排的 Agent + 可复用的 Skills + 可落地执行的 MCP/Tools”，让 AI 负责理解

如果你现在的目标不是做研究，也不是一上来就啃透 Transformer、微调训练、强化学习，而是想尽快进入大模型应用开发这个方向，最好还能在较短时间内做出项目、投递实习、拿到 offer，那么这篇文章

两个真实软件 Bug 分析：从现象到排查思路 这篇文章记录两个我在实际使用和测试过程中遇到的真实 Bug。 我想把它们整理出来，不只是为了“记住一个问题”，而是训练自己从下面几个角度看 Bug： 现象

设计测试用例 这份笔记主要整理面试中常见的“请你设计测试用例”题型，按统一的答题框架和典型案例来归纳，方便复习和现场表达。 一、通用答题框架 我一般回答这类题，会从以下几个维度来分析： 功能测试 界面

在测试开发岗位中，接口测试几乎是绕不过去的一项核心能力。 很多人刚开始学测试时，容易把重心放在页面功能点上，但真正到了企业项目里就会发现，接口测试往往比 UI 测试更稳定、更高效，也更容易融入持续集成

AI 提效测试的技术方案 一、为什么测试岗位值得重点用 AI 测试工作里有很多高频、重复、规则明确的任务，这些任务天然适合被 AI 辅助提效，比如： 阅读需求文档并提炼测试点 根据接口文档生成测试用例

这两年很多同学在准备测试开发、后端开发、AI 应用工程、LLM 工程相关岗位时，都会遇到一个很现实的问题： 我知道“大模型很火”，也知道 RAG、Agent、Prompt、评测这些词经常出现在 JD

Playwright 详细用法 如果说 Selenium 是很多人学习 UI 自动化的第一站，那么 Playwright 往往是很多团队在新项目里更愿意尝试的新选择。 它对现代前端支持更友好，自动等待

Selenium 和 Playwright 对照代码版 学习 UI 自动化时，很多同学都会遇到一个问题： 我知道 Selenium，也知道 Playwright，但总感觉两个工具是分开记的。一旦真正写