目录 一、你注意到没有，编程的门槛正在被重新定义 二、本质不是“AI写代码”，是“经验被封装” 三、Skill 到底是什么——技术层面拆给你看 四、一个对比让你看懂：为什么 Skill 比对话更可靠 五、这件事对你意味着什么 六、最后一个问题
一、你注意到没有，编程的门槛正在被重新定义
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:true
include_project_root:true
prompt_template: |
你是一位资深软件工程师，专注于安全、高性能、可维护的代码。
审查以下{{language}}代码（文件：{{file_path}}）：
重点关注：
- 安全漏洞（SQL注入、XSS等）
- 资源泄漏
- 风格违规
- 性能反模式
输出格式：[严重程度] 类别：问题描述 → 修复建议
这个文件一共不到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能不能帮你把这件事做出来？
