霍格沃兹测试开发学社
四、上岗培训：别急着让他干活，先考他一轮手册写完了，你以为就完事了？新员工入职还得有个试用期呢。Skill 的测试，我分三步走，缺一步都可能埋雷。第一步：历史案例回放。 拿出你项目中过去三个真实需求（包括那个搞出过事故的），让 Skill 重新生成方案或代码。拿他的产出跟当年人工写的、以及最终出问题的点一一比对。我那个支付 Skill 刚写出来时，在一个退款场景里漏了幂等性校验，我直接把那条规则补进 pitfalls.md 里：“退款接口必须在入口处做幂等判断，以业务流水号 + 退款批次号作为唯一键。”第二步：边界试探。 故意给一些刁钻输入：字段为空、文件超长、一个需求里混了两个模块的改动。看 Skill 是硬着头皮瞎编，还是按交互规则主动提问。这能测出你规则里的漏洞。第三步：同行评议。 把你认为调好的 Skill，让另一个同事加载，跑同样的任务，看他觉得输出质量如何。这会暴露很多“你自己习惯了但别人受不了”的隐性知识。有一回我写的 Skill 里习惯用 var 声明局部变量，同事测试时说团队规范里明令禁止，我羞愧地加了条规则。只有跑完这三轮，这个 Skill 才算“转正”。五、版本管理：把 SKILL.md 当生产代码看待很多朋友把 Skill 写完就扔那儿了，结果三个月后项目技术栈升级，Skill 还在给你生成旧版本的代码，那就是定时炸弹。我现在强制要求自己：每个 Skill 文件夹用 Git 管理，SKILL.md 头部版本号手动 +1任何一次项目规范、架构、依赖的变更，必须同步更新关联 Skill 的参考资料每个月挑一个低峰期，用最新的业务需求跑一遍 Skill，检查产出是否仍然合格，不合格就拉分支迭代你想想，你给新人的纸质手册如果一直不更新，这新人迟早变成技术债务。AI 员工没长腿，不会自己主动去了解项目变化，锅全在你这儿。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
发布于 辽宁
分享
评论
赞
未登录
友善发言
评论
加载中
