一、你注意到没有，编程的门槛正在被重新定义

2026年有个数据挺扎眼：78%的开发团队已部署AI辅助工具。Cursor每周人均编码量翻了一倍以上，单次PR新增代码量同比暴涨2.5倍。

但另一组数据更值得琢磨：60%的人已在用AI写代码，却只有不到20%敢完全放手。

我接触过的团队里，大部分人的状态其实是这样的——AI补全用得挺溜，但真要让它独立完成一个完整任务，心里没底。代码能跑，但不敢合。

与此同时，行业里另一件事正在发生。Anthropic的工程师用Claude Code，人均代码量翻了8倍，但团队内部人与人之间的交流反而变少了。硅谷那边甚至有人用“近乎忧郁”来形容工程师的职涯困境。

一边是效率暴涨，一边是信任崩塌。工具越强，人越焦虑。

这不是危言耸听。你只要还在写代码，迟早会面对一个问题：AI生成的东西，你敢不敢直接信？

二、本质不是“AI写代码”，是“经验被封装”

过去两年大家对AI编程的认知，大多停留在“对话式补全”或“单次指令执行”。你问一句，它答一句。你给一个需求，它吐一段代码。

这种模式的问题在于——每次都要从头开始。没有积累，没有复用，没有版本控制。你今天调教好的效果，明天换个项目就没了。

Cursor团队看到了这件事。他们在v0.50版本做了一件很有意思的事：推出原生Skills系统。

本质不是什么新技术突破。核心在于把“如何做一件事的经验”固化成一个可复用的单元。

你可以这样理解：

• Rules是永远生效的声明式约束——比如“代码缩进用4空格”
• Skills是动态触发的程序化操作指南——比如“当我输入/review时，按以下流程审查代码”

一个是“规矩”，一个是“手艺”。

Skill解决的根本问题是：让AI像一个有经验的同事一样，在特定场景下稳定输出专业行为，而不是每次都碰运气。

这对测试从业者意味着什么？意味着你不需要会写代码，也能把测试经验“教”给AI。

三、Skill 到底是什么——技术层面拆给你看

说具体点。一个Cursor Skill本质上就是一个YAML配置文件。

name: "CodeReviewer Pro"description:"跨语言代码审查，覆盖安全、风格、性能"trigger:command:"/review"languages:["python","java","go","javascript"]context:include_file_path:trueinclude_project_root:trueprompt_template: |你是一位资深软件工程师，专注于安全、高性能、可维护的代码。审查以下{{language}}代码（文件：{{file_path}}）：重点关注：1. 安全漏洞（SQL注入、XSS等）2. 资源泄漏3. 风格违规4. 性能反模式输出格式：[严重程度] 类别：问题描述 → 修复建议

这个文件一共不到30行。你不需要写任何代码，只需要用自然语言描述“你希望AI怎么工作”。

背后的技术机制，行业内叫“渐进式披露”。

什么意思？

传统对话系统是一次性把所有上下文塞给模型——system prompt + user prompt + 工具列表 + 对话历史。Token消耗大，上下文容易跑偏。

Skills的做法不同。Agent启动时只加载每个Skill的元数据（名称和描述），大约100个token。当模型判断需要某个Skill时，才加载它的完整指令（不到5k token）。如果还需要更多信息，Agent会继续向模型披露。

核心在于：只在需要的时候加载需要的内容。不像以前那样把所有东西塞进一个对话窗口。

这就是为什么你不需要写代码——你把经验写成描述性的指令，Agent负责在合适的时机把它拿出来用。

四、一个对比让你看懂：为什么 Skill 比对话更可靠

我拿两个场景对比一下。

场景A：纯对话模式

你跟AI说：“帮我审查一下这段代码。”

AI开始工作。但它不知道你团队的代码规范，不知道你们关注哪些安全漏洞类型，不知道你们用什么格式输出审查结果。它只能凭“通用知识”干活。

结果每次输出都不一样。这次关注了性能，下次可能只看了风格。你每次都得重新调教。

场景B：Skill模式

你定义好一个CodeReviewer Skill，把团队的审查标准、关注点、输出格式全部写进去。

然后你在任何项目里输入 /review，AI自动按照你预设的标准执行审查。每次输出的格式一致、关注点一致、质量标准一致。

区别在哪？对话模式依赖AI的“通用能力”，Skill模式把“你的经验”固化成了AI的“专业能力”。

Windsurf走的是另一条路——他们管这叫“AI Flow”，强调让AI自主规划并执行跨文件编辑任务。Cascade Agent会按照依赖关系逐步推进，每改完一个文件就运行测试确认。

两种思路各有优劣。但共同指向一个趋势：AI编程工具正在从“问你答你”变成“帮你做事”。

而这个转变的关键，恰恰不是代码，是如何把你的经验清晰地表达出来。

五、这件事对你意味着什么

对测试从业者来说，Skill提供了一个非常具体的机会。

你不用会写Java、Python、Go。你只需要把你做过的测试工作——什么场景要测、什么数据要造、什么断言要写、什么结果算通过——用自然语言描述清楚。

把这些描述放进一个Skill里，以后的测试工作就可以交给AI按标准流程执行。

Cursor官方已经提供了Docs Canvas Skill，可以让AI为代码仓库生成交互式架构图。还有开发者把团队的测试设计方法论、领域知识和断言规范封装成Skill，实现了测试用例的智能生成与审查。

这个链条里，最难的不是最后一步“让AI执行”，而是中间两步“把经验描述清楚”。

而这恰恰是测试从业者的优势——你们每天都在做这件事：把模糊的需求变成明确的测试用例。

Skill只是把这个过程从“给人看”变成了“给AI看”。

六、最后一个问题

回到开篇那个数据：60%的人在用AI写代码，只有不到20%敢完全放手。

差距在哪？不在工具本身，在你有没有一套可靠的、可复用的“AI工作方式”。

Skill提供了一种思路：把经验封装成指令，让AI按标准执行。

但有一个问题我想留给你：

如果没有，你觉得Skill能不能帮你把这件事做出来？

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。