最近一个名为Agent Skills的开源项目在 GitHub 上持续走热。这个仓库由 Addy Osmani 发起。熟悉前端工程、性能优化和软件工程实践的人大概率听过这个名字。他是 Google Chrome 团队工程负责人之一也长期关注开发效率、工程质量和前端架构。Agent Skills 项目地址https://github.com/addyosmani/agent-skills这个项目官方定位很明确Production-grade engineering skills for AI coding agents.也就是面向 AI 编程智能体的生产级工程能力库。截至目前该仓库已经获得大量开发者关注。更值得注意的是它并不是一个传统意义上的代码框架也不是又一个 AI 编程 IDE而是把软件工程里的需求澄清、任务拆解、增量开发、测试验证、代码评审、安全检查、性能优化、发布上线等流程封装成一套 AI Agent 可以遵循的 Skills。这件事很有意思。因为过去大家谈 AI 编程更多关注的是AI 能不能写代码 AI 能不能修 Bug AI 能不能生成测试 AI 能不能改前端页面 AI 能不能一口气完成一个功能但 Agent Skills 想讨论的是另一个问题当 AI 已经能写代码以后怎么让它按工程方式写代码这才是这个项目真正值得拆开的地方。目录Agent Skills 到底解决了什么问题仓库结构它不是一个 Prompt 合集核心模块一Skills真正的工程流程载体核心模块二Slash Commands把流程变成入口核心模块三Agents给 AI 分配工程角色核心模块四Hooks 和 References让流程可扩展为什么 AI 编程开始需要工程流程测试开发真正要补的不是 Prompt而是工程资产测试团队怎么仿照它做自己的 Skills 能力库Agent 时代质量能力会被重新定义一、Agent Skills 到底解决了什么问题现在很多团队已经开始用 AI 编程工具。Claude Code、Cursor、Gemini CLI、OpenCode、Copilot Agent各类 IDE Agent 都在快速发展。这些工具越来越强不只是能补全代码还可以读取项目文件 理解上下文 修改多个文件 执行终端命令 生成测试代码 分析报错日志 辅助代码评审 完成局部重构 推动一次完整开发任务但问题也随之出现。AI 写代码的速度很快但它不一定总是按工程流程做事。常见问题包括需求还没澄清AI 就开始写代码 方案还没拆分AI 一次性改了很多文件 上下文只读了一部分AI 就开始自信下结论 测试没跑通AI 却输出“应该可以” 为了让测试通过反向修改测试逻辑 报错出现后不定位根因只是不断打补丁 功能能跑但可维护性、安全性、性能都没检查 发布前没有检查清单也没有回滚方案。这些问题的本质不是 AI 不会写代码。而是 AI 缺少工程流程约束。软件开发不是简单的“写代码”。一个功能从需求到上线至少会经历需求理解 边界澄清 技术方案 任务拆分 编码实现 测试验证 代码评审 安全检查 性能检查 CI/CD 发布上线 监控回滚Agent Skills 的价值就是试图把这些工程步骤变成 AI Agent 可以遵循的结构化流程。它不是让 AI 更像一个“代码生成器”。而是让 AI 更像一个被放进工程体系里的执行者。二、仓库结构它不是一个 Prompt 合集很多人看到 Skills第一反应可能是这不就是 Prompt 模板吗但 Agent Skills 的仓库结构明显不是这样设计的。根据项目中的CLAUDE.md这个仓库主要包含以下几个核心目录agent-skills/ ├── skills/ # 核心 Skills每个目录一个 SKILL.md ├── agents/ # 可复用的 Agent 角色 ├── hooks/ # 会话生命周期 Hooks ├── .claude/commands/ # Slash Commands 命令入口 ├── references/ # 测试、安全、性能、可访问性等参考清单 ├── docs/ # 不同工具的安装与使用文档 ├── CLAUDE.md # Claude Code 项目级说明 ├── AGENTS.md # Agent / Skills / Commands 的协作规范 └── README.md # 项目说明这套结构已经很接近一个“AI 工程能力库”的组织方式。它不是把所有东西写进一个大 Prompt 里而是分成了几层层级目录作用工程流程层skills/描述具体怎么做角色分工层agents/描述由谁来做命令入口层.claude/commands/描述什么时候触发生命周期层hooks/描述会话中的自动化动作参考资产层references/提供检查清单和补充规则工具适配层docs/适配 Claude Code、Cursor、OpenCode 等环境这就说明Agent Skills 并不是简单堆提示词。它更像一个面向 AI Agent 的工程工作流仓库。如果用测试开发的视角来看它的设计思想很像把测试规范、开发规范、评审规范、发布规范拆成可复用的流程模块。这才是这个项目最值得借鉴的地方。三、核心模块一Skills真正的工程流程载体Agent Skills 最核心的目录是skills/每个 Skill 都是一个独立目录里面包含一个SKILL.md文件。项目文档里明确提到每个 skill 是一个 Markdown 文件用来描述一个具体工程工作流。当它被加载到 Agent 上下文中时Agent 就会按照其中定义的步骤、验证要求、反模式和退出条件执行。一个典型 Skill 的结构可以理解成这样skills/ └── test-driven-development/ └── SKILL.md而SKILL.md通常不是一句简单提示词而应该包含--- name:test-driven-development description:Guidestheagentthroughtest-firstdevelopment.Usewhenimplementingbehaviorthatshouldbeprotectedbyautomatedtests. ---然后正文部分一般会包含# Overview 这个 Skill 要解决什么问题。 # When to Use 什么时候应该使用这个 Skill。 # Process 具体执行步骤。 # Common Rationalizations AI 或人类常见的偷懒理由。 # Red Flags 过程中出现哪些信号说明要停下来。 # Verification 完成任务前必须验证什么。这套结构非常关键。因为它把一个 Skill 从“提示词”变成了“工程流程”。普通 Prompt 是你是一个资深工程师请写出高质量代码。这种写法的问题是它没有约束。什么是高质量 需要先读哪些文件 需要跑哪些测试 遇到失败怎么办 什么时候可以认为完成 哪些情况不能直接下结论都没有说。而一个工程化 Skill 应该更具体1. 先阅读相关需求和现有实现 2. 提取当前行为和目标行为的差异 3. 先写失败测试 4. 再做最小实现 5. 运行测试 6. 如果失败定位根因不允许直接删除测试 7. 通过后再做重构 8. 输出修改范围、验证命令和剩余风险这就是 Agent Skills 和普通 Prompt 最大的区别。Prompt 更像一句指令。Skill 更像一套流程。四、核心模块二Slash Commands把流程变成入口Agent Skills 另一个关键目录是.claude/commands/这里放的是 Claude Code 可识别的 slash commands。项目 README 里列出了 7 个核心命令它们分别对应软件交付生命周期中的不同阶段阶段命令核心原则Define/specSpec before codePlan/planSmall, atomic tasksBuild/buildOne slice at a timeVerify/testTests are proofReview/reviewImprove code healthSimplify/code-simplifyClarity over clevernessShip/shipFaster is safer这套命令不是为了好看而是给 AI Agent 提供了明确入口。用户不需要每次都写一大段提示词比如“请先帮我分析需求再拆分任务再实现再写测试再做代码评审……”而是可以直接使用/spec让 Agent 进入需求规格阶段。或者使用/plan让 Agent 开始拆解任务。再比如/test让 Agent 进入测试验证流程。这背后其实是一种很重要的工程设计把复杂流程封装成稳定入口。对开发团队来说这类似于把复杂命令封装成 Makefile、npm script、CI pipeline。对 AI Agent 来说slash command 就是工作流入口。它解决的问题是不用每次重复解释流程 不同成员使用同一套流程 AI 不容易跳过关键步骤 团队可以统一交付标准 工程经验可以复用和迭代。这一点对测试开发团队非常有启发。未来我们也可以设计自己的测试命令/testcase-review /api-test-design /ui-auto-generate /performance-analysis /bug-root-cause /release-quality-check /llm-eval /rag-test这些命令背后不是一句 Prompt而是一套完整测试流程。五、核心模块三Agents给 AI 分配工程角色Agent Skills 还有一个重要目录agents/这里放的是可复用的 Agent Personas也就是角色。项目文档里提到这个仓库有三层组合关系Skills → workflows with steps and exit criteria Agents → roles with a perspective and output format Commands → user-facing entry points and orchestration layer也就是模块作用类比Skills怎么做流程规范Agents谁来做工程角色Commands什么时候做命令入口在agents/里典型角色包括code-reviewer test-engineer security-auditor这些角色不是随便起个名字而是让 AI 从不同专业视角检查同一个任务。比如code-reviewer关注代码健康度、可维护性、复杂度。test-engineer关注测试覆盖、验证证据、失败路径。security-auditor关注权限、输入、依赖、敏感信息和安全风险。这里有一个很关键的设计原则角色不应该彼此乱调用。项目文档明确指出用户或 slash command 是编排者personas 不调用其他 personasSkills 是 persona 工作流里的必要步骤。多角色编排只推荐在独立任务可以并行时使用比如/ship同时让 code-reviewer、security-auditor、test-engineer 产出报告再由主 Agent 合并成 go/no-go 决策。这点非常工程化。因为很多团队做多 Agent 时容易设计成一个总控 Agent 调另一个 Agent另一个 Agent 再调第三个 Agent。最后上下文混乱责任不清结果不可追踪。Agent Skills 的思路更克制能顺序执行就顺序执行 能单角色完成就单角色完成 只有任务彼此独立时才并行 fan-out 最后必须有合并阶段和决策输出。这对测试开发做多 Agent 测试平台也很有参考价值。比如一次发布前质量检查可以设计成/release-quality-check ├── test-engineer → 测试覆盖报告 ├── security-auditor → 安全风险报告 ├── performance-reviewer → 性能风险报告 └── main-agent → 合并报告输出发布建议这比让一个 AI “全都看一遍”更可靠。六、核心模块四Hooks 和 References让流程可扩展除了skills/、agents/、.claude/commands/Agent Skills 里还有两个容易被忽略的模块hooks/ references/1. hooks会话生命周期扩展hooks/用来处理会话生命周期里的自动化动作。它可以理解成 AI 编程环境中的“钩子”。在传统工程里我们很熟悉 hooksGit hooks CI hooks pre-commit hooks post-build hooks test hooks deploy hooksAI Agent 进入工程环境后也需要类似机制。比如会话开始时加载项目规范 任务开始前检查当前分支状态 代码修改后提醒运行测试 提交前检查是否有敏感信息 发布前触发质量检查 会话结束时生成总结。这些都可以通过 hooks 这类机制实现。它让 Skills 不只是“被动等待调用”而是可以和开发生命周期结合起来。2. references参考清单和工程规则references/则更像工程知识库。这里可以放测试检查清单 安全检查清单 性能优化清单 可访问性规则 代码评审规则 发布检查规则 文档规范 ADR 模板一个重要设计是Skill 不应该无限膨胀。如果某些内容只是参考资料不应该都塞进SKILL.md。否则 Skill 会越来越长Agent 每次加载都会带来大量上下文成本。更好的方式是核心流程写在 Skill 里 详细规则放在 references 里 需要时再引用。这就对应了 Agent Skills 很重要的思想渐进式披露。也就是先给 AI 必须执行的流程 再在需要时加载更多细节。这对大型团队尤其重要。因为测试规范、安全规范、性能规范、发布规范都很长。如果每次都全部塞给 AI不仅浪费上下文还容易让模型抓不住重点。七、为什么 AI 编程开始需要工程流程AI 编程刚开始流行时大家最关心的是“能不能生成代码”。但真正进入项目以后大家会发现代码生成只是软件工程的一小部分。一个功能从需求到上线中间有大量非编码工作需求是不是清楚 边界是不是明确 影响范围有没有评估 设计是否可维护 测试是否覆盖核心路径 异常场景有没有考虑 权限和安全有没有问题 性能是否会退化 发布是否可回滚 线上是否可观察如果这些都没有只是代码写得快项目风险反而会更高。AI Agent 越强这个问题越明显。因为过去人类工程师改代码慢出错速度有限。现在 AI 可以几分钟改几十个文件生成大量代码甚至自动执行命令。如果没有流程约束AI 的能力会变成风险放大器。所以 Agent Skills 的出现本质上说明 AI 编程进入了一个新阶段从“让 AI 会写代码”进入“让 AI 按工程流程交付代码”。这也是为什么这个项目值得测试开发关注。因为测试开发做的事情本来就是把质量保障体系工程化。而 Agent Skills 给了一个很好的参考把流程拆出来。 把角色分清楚。 把入口标准化。 把验证写明确。 把红线定义清楚。 把经验沉淀成可复用资产。八、测试开发真正要补的不是 Prompt而是工程资产Agent Skills 对测试开发最大的价值不是它提供了几个现成命令。而是它给了一个非常清晰的信号测试能力也可以被封装成 AI 可执行的工程资产。过去很多测试经验都停留在人的脑子里。一个资深测试开发工程师能快速判断这个需求有没有歧义 这个接口有没有边界条件 这个页面状态有没有遗漏 这个异步任务有没有失败补偿 这个数据流有没有一致性风险 这个权限模型有没有绕过路径 这个发布有没有回滚方案 这个性能指标有没有可观测性。这些能力非常重要但也非常隐性。新人很难快速学会。 团队很难稳定复制。 AI 也很难靠一句 Prompt 完全理解。所以现在很多团队做 AI 测试时会停留在比较浅的一层让 AI 生成测试用例。 让 AI 写自动化脚本。 让 AI 总结缺陷。 让 AI 生成测试报告。这些当然有价值。但如果只做到这里AI 测试很容易变成“内容生成”。真正有价值的方向应该是把测试方法、测试流程、质量门禁和工程经验封装成 AI 可以执行的 Skills。比如测试团队完全可以沉淀这些能力需求评审 Skill 测试点分析 Skill 测试用例生成 Skill 测试用例评审 Skill 接口测试设计 Skill UI 自动化生成 Skill App 自动化生成 Skill 接口自动化生成 Skill 缺陷定位 Skill 日志分析 Skill 性能压测分析 Skill 发布前质量检查 Skill 线上问题复盘 Skill RAG 测试 Skill 大模型评测 Skill Agent 行为测试 Skill这些 Skill 不应该只是几句提示词。它们应该像 Agent Skills 一样有清晰结构name这个 Skill 的名字 description什么时候使用 overview它解决什么问题 when to use触发场景 process执行步骤 red flags风险信号 verification验证标准 output输出格式这才是测试开发进入 Agent 时代真正要补的能力。不是会不会写 Prompt。而是能不能把测试经验沉淀成可复用的工程资产。九、测试团队怎么仿照它做自己的 Skills 能力库如果测试团队想借鉴 Agent Skills可以不用一上来做得很复杂。可以先从一个最常见的场景开始测试用例评审 Skill。目录可以这样设计test-agent-skills/ ├── skills/ │ ├── testcase-review/ │ │ └── SKILL.md │ ├── api-test-design/ │ │ └── SKILL.md │ ├── ui-automation-generation/ │ │ └── SKILL.md │ ├── bug-root-cause-analysis/ │ │ └── SKILL.md │ └── release-quality-check/ │ └── SKILL.md ├── agents/ │ ├── test-engineer.md │ ├── automation-engineer.md │ ├── performance-engineer.md │ └── quality-reviewer.md ├── commands/ │ ├── testcase-review.md │ ├── api-test.md │ ├── ui-auto.md │ ├── bug-analysis.md │ └── release-check.md ├── references/ │ ├── testcase-checklist.md │ ├── api-test-checklist.md │ ├── ui-auto-checklist.md │ ├── performance-checklist.md │ └── release-checklist.md └── README.md这就已经很像一个测试团队自己的 Agent Skills 工程能力库了。示例测试用例评审 Skill--- name: testcase-review description: Reviews test cases for requirement coverage, executability, boundary conditions, expected results, and risk scenarios. Use when reviewing manually written or AI-generated test cases before execution. --- # Overview This skill reviews test cases against requirements and quality criteria. It identifies missing coverage, vague steps, weak assertions, missing data, and untested risk scenarios. # When to Use Use this skill when: - Reviewing test cases generated from requirements - Reviewing AI-generated test cases - Preparing for test case review meetings - Checking whether test cases are executable - Looking for missing boundary or exception scenarios # Process 1. Read the requirement or user story. 2. Extract business rules and acceptance criteria. 3. Map existing test cases to each business rule. 4. Check whether normal flows are covered. 5. Check whether exception flows are covered. 6. Check boundary values and invalid inputs. 7. Check preconditions, test data, steps, and expected results. 8. Identify duplicate, vague, or non-executable cases. 9. Output missing cases and improvement suggestions. # Red Flags - Test case has steps but no expected result - Expected result is vague, such as works normally - Only happy path is covered - Boundary values are missing - Permission and role scenarios are missing - Data initialization is unclear - Case cannot be executed by another tester # Verification Before finishing, confirm: - Every requirement has at least one mapped test case - Critical business rules have positive and negative coverage - Each case has clear preconditions, steps, data, and expected result - Missing scenarios are listed separately - Risks are explicitly called out这个示例的价值不在于文字多而在于它把“测试用例评审”这件事变成了可执行流程。以后 AI 不再只是回答“这批用例整体不错建议补充边界值。”而是必须逐项检查需求覆盖 业务规则 正常路径 异常路径 边界值 权限 状态流转 测试数据 执行步骤 预期结果 风险遗漏这就是工程化。示例发布前质量检查命令还可以进一步设计一个命令入口/release-check它背后可以编排多个 Agent/release-check ├── test-engineer → 测试覆盖与失败用例检查 ├── automation-engineer → 自动化结果与稳定性检查 ├── performance-engineer → 性能指标与容量风险检查 ├── security-reviewer → 权限、安全和敏感信息检查 └── quality-reviewer → 合并结论输出发布建议最终输出可以统一成1. 发布结论Go / No-Go / Conditional Go 2. 核心风险 3. 测试覆盖情况 4. 自动化执行情况 5. 性能与稳定性 6. 安全风险 7. 必须修复项 8. 可延期项 9. 回滚建议 10. 上线观察指标这就是 Agent Skills 思想在测试开发里的落地方式。不是让 AI 随便“帮我看看”。而是让 AI 进入一套可复用、可验证、可追踪的质量流程。十、Agent 时代质量能力会被重新定义Agent Skills 的走红不只是一个开源项目的热度变化。它背后代表的是一个趋势AI 编程正在从 Prompt 阶段进入工程流程阶段。过去大家比的是谁的 Prompt 写得好 谁能让 AI 生成更多代码 谁能更快做出 Demo 谁能用 AI 提升个人效率。但接下来真正拉开差距的会是谁能把工程经验沉淀成流程 谁能把质量标准变成门禁 谁能让 AI 输出可验证证据 谁能把开发、测试、评审、发布串成闭环 谁能让 Agent 在复杂项目里稳定工作。对测试开发来说这个变化尤其重要。因为测试的核心从来不是“写几条用例”。测试真正要解决的是需求是否清楚 风险是否暴露 路径是否覆盖 结果是否可验证 缺陷是否可定位 发布是否可控 质量是否可持续。这些能力过去依赖人的经验。未来它们会越来越多地被沉淀成 Skills、工作流、质量门禁和智能体能力。AI 可以帮我们生成内容。但质量体系仍然需要人来设计。Agent Skills 给测试开发带来的最大启发是不要只问 AI 能不能帮你写测试。更应该问你的测试经验能不能被工程化成 AI 可以执行的 Skill这才是 AI 测试开发真正拉开差距的地方。未来的测试开发不只是会用 AI 工具的人。而是能把测试方法、质量标准、自动化能力、工程流程和 Agent 体系结合起来的人。会写自动化是基础能力。会设计 AI 可执行的测试工程体系才是新的竞争力。