一个研发的AI进化之路：从胡乱提问到Agent Skills的三次蜕变
写在前面
我用 AI 写代码、解决问题已经有很长一段时间了。
这段时间里，我换过不少工具和网站，也反复调整过提示词，更踩过不少坑。
从最开始的"也就那样"，到后来突然意识到——问题可能不在 AI，而在我自己不会用，用不好。
于是我决定把这些零散的经历和思考整理下来，写成这篇文章。
记录我一路是怎么走过来的，也记录一些在不断试错中慢慢积累下来的经验。
文章中也会穿插一些我个人觉得比较好用的内容，比如常用的网站、提示词的思路，以及一些在实际研发中反复验证过的使用技巧等。
一、开篇：我的AI编程起点
已经记不清 GPT 刚发布时，我的第一反应到底是什么了。
也记不清，我当时问它的第一个问题是什么。
只记得那段时间，朋友圈、技术群、各种公众号都在疯狂讨论这个东西。有人说它是"第四次工业革命"，有人说"程序员要失业了"，也有人说"不过又是一场炒作，和之前的元宇宙、Web3 没什么区别"。
说实话，我对新技术的态度一直是偏保守谨慎的。见过太多风口来了又走，大多数最后都是一地鸡毛。所以当时的心态就是：先观望，有机会再玩一下看看。
但我还记得一件事——不管别人怎么吹，我自己试了之后发现：我完全不会用它。
那时候的我，把 AI 当成一个"更聪明一点的搜索引擎"。想到什么就直接问什么，问题通常只有一两句话，没有背景，没有约束，也没有上下文。
结果也不出所料：它确实回答了，但回答往往不是我想要的那个答案。
我开始意识到不对劲，于是采取了最原始、也最笨拙的方式来"修正"它的行为：在原问题后面不断打补丁。比如："不要用这种写法"、"别考虑 XX 场景"、"可以使用 XXX"、"再简单一点"……
每一次追问，都是在给最初那个模糊的问题打补丁，效率很低。
在一开始的时间里，我对 AI 的使用范围，也被我自己刻意压缩了。我只敢把它用在那些"绝对不会出错"的简单场景上，比如：
- 给它一个 DDL，让它生成对应的实体类
- 让它帮我写一个工具方法
- 处理一些机械的文字工作
- 写一些一次性、不太重要的小逻辑
这些事情，有几个共同特点：需求清晰、上下文少、对"业务理解"几乎没有要求、就算写错了，我也能一眼看出来。
那时候的 AI，更像是一个代码生成器，而不是"协作对象"。
至于复杂需求行不行？我也试过。结论非常明确：不行。
一旦需求稍微复杂一点，涉及到真实业务、现有代码结构、项目依赖时，它给出的东西就开始严重跑偏：看起来很"合理"，但根本不能直接用、用了不存在的依赖、假设了错误的上下文。
那时候，我心里其实已经给它下了一个结论："这个东西，写点简单的还行，真干活还是不太行。"
现在回头看，这个结论当然是错的。但它并不是一个"无知的错误"，而是一个几乎所有早期使用者都会经历的阶段。
因为当时的我，还没意识到一件更重要的事情：问题不在 AI，而在于我根本不知道该如何与它协作。
我把它当成一个"应该能读懂我心思"的工具，却从来没想过：它凭什么知道我用的是什么技术栈？凭什么知道我们项目的代码规范？凭什么知道这个需求背后的业务上下文？
它不是不够聪明，是我给它的信息太少了。
这就像你给一个刚入职的新人派活，只说"帮我写个接口"，然后期待他直接交付一份完美符合项目规范的代码——这不是对方能力的问题，是你根本没把事情交代清楚。
意识到这一点之后，我开始改变自己使用 AI 的方式。而这个转变，也让我真正感受到了 AI 的威力。
在这一阶段，我最常用的网站是：https://sharedchat.fun/
这个网站提供了一些免费的共享 ChatGPT 账号。
二、第一次蜕变：从胡乱提问到提示词优化
在使用 ChatGPT 的这段时间，各家的大语言模型都如同雨后春笋般的发布了，都跟 ChatGPT 进行了标榜。很多测试下来，还不如 ChatGPT，因此，还是一直用的 ChatGPT。
直到后来，Claude 发布了，号称拥有更好的编码和推理能力，这不是专为程序员打造的么。使用了一段时间，发现在代码这块，确实比 ChatGPT 要强——生成的代码更规范，对复杂逻辑的理解也更准确，不会动不动就给你来一段似是而非的"幻觉代码"。于是，慢慢就换成了 Claude，官网每天免费的次数也勉强够用。
也是在这段时间，开始学习"提示词工程"，并逐步运用到实际的开发场景，成功让它完成一些复杂的场景。
关于提示词工程
首先，"提示词工程"是一门新的"学科"，我不打算过多的讲这块的内容，网上有很多教程。要完整的学习下来，其实还挺复杂的。对于程序员来说，只需要掌握一些其中的概念，学会怎么提问，掌握一些技巧就够了。
我是先从模仿开始的。在这门学科刚火的时候，有很多"提示词网站"，比如：https://www.aishort.top/ 。我会去学习这些网站上的提示词是怎么写的，总结其中的一些共同点，比如：要给 AI 设定角色、要把背景信息交代清楚、要明确输出的格式要求等等。然后慢慢的用到项目中，不断的优化，最终，有了这个我最常用的提示词模板。
我的提示词模板
1. 新项目/新功能开发
"你是一个资深的Java研发，我这里有一个SpringBoot的项目，下面是pom文件....（给它核心的一些依赖），现在，我需要你帮我实现.....（描述你的需求）我已经实现了....（比如你已经设计好了数据库、创建好了service等），我需要你在此基础上，帮我实现....(告诉他具体功能，以某个增删改查为例)，....你可以参考下面的用法（如果对代码风格有要求，给它参考案例）。如果我给你的信息不够，你应该先找我提供更多的信息，而不是给我模棱两可的回答。接下来所有对话，只要你有疑问，都已经在解决我的问题之前，先问我，获取更多信息。"
这个模板的核心就3点：
- 给它赋予一个角色，让它知道自己是谁；
- 把上下文交代清楚；
- 重点！！让AI反问你。我觉得这是最关键的一点，你要跟AI有多轮交互，不要指望着一轮问答就能解决你的问题，也不要指望着你可以一次性把它需要的所有信息全部发给它，不要让它着急给你给你结果。
2. Debug 排错
遇到报错的时候，很多人的习惯是直接把错误日志甩给 AI。这样有时候能解决问题，但更多时候 AI 会给你一堆泛泛而谈的可能性，挨个试下来半天就没了。
我的做法是把案发现场描述完整：
你是一个资深的Java研发。
我遇到了一个问题，需要帮忙排查。
环境信息：
- [技术栈版本]
出问题的代码：
[相关代码片段]
报错信息：
[完整的异常堆栈]
我已经尝试过：
1. [试过的方法1]
2. [试过的方法2]
补充信息：
- [如：这个接口昨天还是正常的]
- [如：只有特定参数会触发这个错误]
接下来所有对话，只要你有疑问，都已经在解决我的问题之前，先问我，获取更多信息。关键在于告诉 AI 你已经试过什么，这样它就不会再推荐那些你已经踩过的坑。
3. 代码重构
重构的时候，最怕 AI 给你"重新设计"一遍。你只是想优化一下，它给你来个架构大改造，完全没法用。所以重构类的提示词，重点是划定边界：
你是一个资深的Java研发。
请帮我优化以下代码，但保持接口签名不变：
[现有代码]
优化目标：
- [如：提高可读性]
- [如：减少重复代码]
约束条件：
- 不要修改方法的输入输出
- 不要引入新的依赖
- 保持与现有代码风格一致
接下来所有对话，只要你有疑问，都已经在解决我的问题之前，先问我，获取更多信息。一些实用的提示词技巧
除了上面的模板，还有一些技巧是我在实践中慢慢摸索出来的，分享给大家。
1. 复杂问题要拆分
刚开始用 AI 的时候，我总想一步到位，把一个完整的功能需求一股脑丢给它。结果往往是：AI 生成了一大堆代码，看起来很完整，等你把代码复制粘贴到idea之后，发现有很多问题，甚至是编译都无法通过，费了老大的劲复制、新建、粘贴，结果根本不可用。
后来我学聪明了：复杂的问题分成多个子任务，从简单的开始，一点点来。
比如要做一个"订单超时自动取消"的功能，我不会直接让 AI 把整个功能写完。而是拆成这样：
- 先让 AI 帮我设计数据库表结构和状态流转
- 再写订单创建的基础逻辑
- 然后加上定时任务扫描超时订单
- 最后处理取消订单的库存回滚、退款等逻辑
每一步都确认没问题了，再进行下一步。这样做看起来慢，实际上比一次性生成一堆有问题的代码要快得多。一定不要让AI一股脑的把所有设计、代码全部发给你。
2. 先搭框架，再填细节
这个技巧和上面那个有点像，但侧重点不同。
做一个新功能的时候，我会先让 AI 帮我搭建好整体框架，把目录结构、类的划分、核心接口定义好，但先不写具体实现，方法体里就放个 // TODO 就行。
等框架 review 完没问题了，开启一个新的对话，把框架代码贴进去，再一个一个方法地让 AI 帮我填充实现。
为什么要开新对话？因为 AI 的上下文是有限的，聊得越久，前面的信息它就记得越模糊。开新对话，把当前的代码作为"已有背景"贴进去，AI 反而能更专注地处理当前的问题。
3. 给 AI 看示例代码
每个团队、每个项目都有自己的代码风格。AI 生成的代码虽然能用，但风格经常和项目里已有的代码格格不入，合到一起看着很别扭。
我的做法是：在提示词里贴一段项目中已有的类似代码，让 AI 参考着写。
你是一个资深的Java研发。
请帮我写一个 ProductService，参考下面这个 UserService 的风格：
[贴上 UserService 的代码]
新的 ProductService 需要实现：
1. 商品列表查询（支持分页和筛选）
2. 商品详情
3. 商品上下架
请保持和 UserService 一致的代码风格、异常处理方式和返回值封装。
接下来所有对话，只要你有疑问，都已经在解决我的问题之前，先问我，获取更多信息。这样生成的代码，基本上和项目里已有的代码是一个味道，不用再花时间调整风格。
4. 让 AI 先解释再动手
遇到要修改一段不熟悉的代码时，我不会直接让 AI 改。而是先让它解释一遍：
你是一个资深的Java研发。
请帮我分析下面这段代码的逻辑，说明：
1. 整体流程是什么
2. 每个关键步骤在做什么
3. 有没有潜在的问题
[贴上代码]
接下来所有对话，只要你有疑问，都已经在解决我的问题之前，先问我，获取更多信息。等我明确知道，它理解清楚了，再告诉 AI 要改什么、怎么改。这样做有两个好处：一是改出来的代码我心里有数；二是万一 AI 的理解有偏差，在解释阶段就能发现，不用等到改完代码才发现方向错了。
一点心得
用了这段时间下来，最大的感受是：AI 是放大器，不是替代品。你对需求理解得越清楚，AI 帮你实现得就越好。你自己都说不明白想要什么，指望 AI 猜出来，难。
还有就是，不要盲目信任 AI 生成的代码。AI 帮你写，但你得自己审。
后来，随着使用频率的增加，以及A社变得越来越小气，Claude的免费次数已经不够我使用了，也有不少时候超过了上下文的最大限制。当时就在想，Claude有没有跟ChatGPT一样的"车队"？于是我找到了"xychatai"，我记得当时是399一年，里面有很多Claude的账号，你可以进行切换。目前它是我的主力。 xychatai。
三、第二次蜕变：引入Claude Code
当提示词运用到一定的熟练程度之后，我发现确实能够大幅提升我的开发效率。但是，实际使用过程中，仍然存在一些不方便的地方：
每次提问时，需要复制一大段的提示词、代码等等；AI回答之后，还需要手动把代码复制粘贴到IDE；特别是涉及多个文件的修改时，光是复制粘贴、新建文件、调整代码，都得花很多时间。有时候AI给的代码还需要微调，来回折腾几次，效率反而下降了。
于是，我开始寻找更高效的解决方案，便有了Claude Code。
什么是Claude Code？
Claude Code是Anthropic（Claude的开发商）推出的命令行编程工具。简单来说，它可以直接在你的项目目录里工作，读取你的代码、理解项目结构，然后根据你的需求直接修改文件。
和网页版最大的区别是：你不用再手动复制粘贴代码了。你告诉它要做什么，它自己去找相关文件、生成代码、写入文件，你只需要审查结果。因为我的主力模型一直是Claude，加上Claude Code的命令行方式更符合我的使用习惯，所以就没有深度体验其他工具了。
对我来说，Claude Code最方便的地方
1. CLAUDE.md：项目级的"提示词配置文件"
这是我觉得最实用的功能。
CLAUDE.md是Claude Code的配置文件，Claude在启动时会自动读取它。你可以把它理解为给AI的"项目说明书"——把项目的技术栈、代码规范、注意事项写在里面，这样每次提问时就不用再重复交代背景了。
我通常会在CLAUDE.md里放这些内容：
# CLAUDE.md
## 项目概述
- 技术栈：SpringBoot 2.7 + MyBatis-Plus + MySQL
- 包管理：Maven
- 代码规范：阿里巴巴Java开发手册
## 常用命令
- `mvn clean package -DskipTests` - 打包
- `mvn test` - 运行测试
## 代码风格
- Service层统一使用@Transactional注解处理事务
- Controller层统一使用@Valid进行参数校验
- 异常统一抛出BusinessException，由全局异常处理器处理
## 注意事项
- 数据库字段使用下划线命名，Java属性使用驼峰命名
- 所有接口返回值统一使用Result<T>包装
- 禁止在循环中进行数据库操作有了这个文件，我在提问时只需要说"帮我写一个用户注册接口"，Claude就会自动按照项目的规范来生成代码，不用每次都强调"用MyBatis-Plus"、"返回值用Result包装"这些细节。
2. 直接修改文件 + Git配合审查
以前用网页版Claude，AI给了代码之后，我需要：
- 复制代码
- 找到对应的文件
- 粘贴进去
- 检查有没有粘贴错位置
- 如果涉及多个文件，重复以上步骤N次
现在用Claude Code，我会给它文件修改的权限，让它直接改。改完之后，配合Git，可以非常清晰地看到AI改了哪些内容。
觉得改得不对？直接git checkout回滚。觉得没问题？git add然后提交。
这种工作流让我可以大胆地让AI去尝试，反正有Git兜底，改坏了随时能恢复。
3. 其他好用的功能
除了上面两点，Claude Code还有一些功能也挺实用：
- MCP（Model Context Protocol）：可以让Claude连接外部工具。
- 自定义命令：可以把常用的操作封装成斜杠命令。比如我封装了一个/review命令，让Claude按照团队的代码规范检查当前改动，省得每次都要描述一遍检查标准。
引入Claude Code之后，我的开发流程变成了：
- 在项目目录下维护好CLAUDE.md，将一些通用的、项目级别的提示词也放到此文件
- 用自然语言描述需求
- 让Claude直接修改文件
- 用Git审查修改内容
- 确认无误后提交
最后，终于不用再复制一大堆的提示词了，也不用再手动复制粘贴代码了。
当然，Claude Code也不是万能的。对于一些简单的问题，比如"这个报错是什么意思"、"帮我解释一下这段代码"，我还是会用DeepSeek，没必要杀鸡用牛刀。
但是，在开发过程中，还是会有一些问题无法解决
比如，用 AI 生成前端页面时，出来的效果总带着一股浓浓的"AI味"——布局中规中矩、配色千篇一律、交互生硬死板，一眼就能看出是机器生成的。想要达到设计稿的还原度，或者实现一些有质感的视觉效果，往往还得花大量时间手动调整，AI 反而成了"半成品生成器"。
再比如后端部署这件事，简直是重复劳动的噩梦。每次哪怕只改了一行代码，都要经历一整套流程：本地打包 → SSH 连接服务器 → 上传 jar 包 → 备份旧版本 → 停止服务 → 替换文件 → 重启服务 → 检查日志确认启动正常 → 验证接口可用性……如果是生产环境，还得考虑灰度发布、流量切换、回滚预案。整套流程走下来，少说十几分钟，手一抖还可能出错。
当然，CI/CD 工具可以解决这个问题，但单独部署一套 Jenkins？光是安装配置就够喝一壶的——配置 JDK 环境、设置权限、编写 Pipeline 脚本、配置 Webhook、管理凭证……而且 Jenkins 本身也需要维护，服务器资源、安全更新、插件兼容性，都是额外的心智负担。对于个人项目或小团队来说，这套方案显得过于笨重。
就在我被这些琐事折腾得心力交瘁时，我发现了 Agent Skills。
四、第三次蜕变：Agent Skills带来的终极解决方案
随着各家大模型的能力逐渐趋同，大家渐渐地不再讨论"哪个模型更强"，而是开始讨论"如何让 AI 更好地干活"。在这种转变之下，Agent Skills 频繁出现在大家的视野中。
什么是 Agent Skills？
2025 年 10 月，Anthropic 在推出 MCP（Model Context Protocol）之后，又发布了一个 Agent 领域的新标准——Skills。如果说 MCP 解决的是"AI 如何连接外部工具"的问题，那么 Skills 解决的就是"AI 如何掌握特定领域能力"的问题。
Skills 的核心思想是：将那些重复性的、专业的工作流程进行打包封装。当你需要使用某种能力时，不再需要像过去那样每次都去查阅手册或重新输入冗长的提示词，而是像调用函数一样直接使用。
更通俗地说，Skills 就是给 AI Agent 装上的「技能插件」。就好比你玩游戏给角色学技能一样——战士学了"重击"就能打出高伤害，法师学了"火球术"就能远程攻击。AI 也可以通过安装 Skills，瞬间掌握某个领域的专业能力。
Skill 的结构
一个完整的 Skill 通常包含以下内容：
my-skill/
├── SKILL.md # 核心指令文档（必需）
├── scripts/ # 可执行脚本
│ ├── process.py
│ └── validate.sh
├── reference/ # 参考文档
│ └── api-docs.md
└── assets/ # 资源文件
├── templates/
└── examples/其中最核心的是 SKILL.md，它定义了这个 Skill 的名称、用途、触发条件和工作流程。一个典型的 SKILL.md 长这样：
---
name: github-actions-debugger
description: 帮助调试失败的 GitHub Actions 工作流
---
# GitHub Actions 调试专家
## 使用时机
当用户遇到 CI/CD 失败、构建错误或部署问题时使用
## 工作流程
1. 使用 `list_workflow_runs` 工具查看最近的运行状态
2. 使用 `summarize_job_log_failures` 获取失败摘要
3. 分析日志，定位问题根源
4. 提供修复建议和代码示例
## 常见问题检查清单
- [ ] 环境变量和密钥配置
- [ ] 依赖版本兼容性
- [ ] 权限设置
- [ ] 超时配置
用 Skills 解决实际痛点
回到上一章结尾提到的两个问题，Skills 恰好可以提供优雅的解决方案。
痛点一：前端页面的"AI 味"
用 AI 生成前端页面，最大的问题就是千篇一律——配色单调、布局死板、缺乏设计感。这是因为 AI 并不知道你想要什么风格，它只能按照"最通用"的方式来生成。
解决思路是：封装一个 UI 设计规范的 Skill，或者，使用已经开发好了的ui-ux-pro-max这个skill
痛点二：后端部署的重复劳动
每次改完代码都要经历：打包 → SSH 连接 → 上传 → 备份 → 停服务 → 替换 → 重启 → 验证……这套流程走下来，少说十几分钟。
虽然 CI/CD 工具可以解决这个问题，但对于个人项目或小团队来说，单独部署一套 Jenkins 实在太重了。
Skills 提供了一个轻量级的替代方案：把部署流程封装成一个 Skill。再配合一些scripts，可以很优雅的实现。
如果对全自动部署不太放心，也可以做成"半自动"模式——Skill 负责打包和上传，最后的重启操作由人工手动确认后执行。这样既省去了大部分重复劳动，又保留了人工审核的环节。
其他实用场景
除了上面两个例子，Skills 还可以应用在很多场景：
- 代码审查 Skill：按照团队的代码规范自动 review，检查命名规范、异常处理、SQL 注入风险等
- API 文档生成 Skill：根据代码自动生成符合团队格式的接口文档
- 自动生成博文配图（本文的所有配图，均由AI生成）
如何编写 Skills？
使用 skill-creator
这是一个"教你写 Skill 的 Skill"。你只需要描述你想要的能力，它会引导你一步步完成 SKILL.md 的编写，包括定义触发条件、工作流程、输出格式等。对于初学者来说，这是最快的上手方式。
逛 Skills 市场
已经有一些社区在收集和分享 Skills，你可以去看看有没有现成的，或者学习别人的写法：
这些市场里有各种各样的 Skills，从代码生成到文档写作，从数据分析到运维自动化，基本上你能想到的场景都有人做过。就算找不到完全匹配的，也可以参考类似 Skill 的写法，改成自己需要的版本。
使用 Skills 的一些心得
用了一段时间 Skills 之后，我有几点体会想分享：
把 Skills 当成辅助，不要完全依赖
Skills 本质上还是一套预设的指令，它能覆盖大部分常规场景，但总有一些边界情况是它处理不了的。比如部署 Skill 可能没考虑到你服务器的特殊配置，代码审查 Skill 可能漏掉了某些业务相关的检查点。
所以，Skill 执行完之后，该检查的还是要检查。它是帮你提效的工具，不是让你当甩手掌柜的借口。
不要贪多，按需安装
刚接触 Skills 的时候，很容易陷入一种"收集癖"——看到什么 Skill 都想装上，觉得"说不定以后用得上"。
但实际上，装太多 Skills 会带来几个问题：
- 上下文膨胀：每个 Skill 都会占用 AI 的上下文窗口，哪怕只是加载每个Skill的元数据
- 干扰决策：当 AI 面对太多可选的 Skills 时，反而可能选错，或者在不该触发的时候触发
- 维护成本：Skills 也需要更新维护，装得越多，管理起来越麻烦
我的建议是：从你最痛的那个点开始，先解决一个问题，用熟了再考虑下一个。与其花大量时间在 Skills 市场里淘宝，不如把精力放在打磨那几个真正高频使用的 Skill 上。
五、写在最后
回头看这一路，从最初把 AI 当成"高级搜索引擎"胡乱提问，到学会用提示词"驯服"它，再到 Claude Code 解放双手，最后用 Skills 把重复劳动打包封装——每一次蜕变，本质上都是在回答同一个问题：如何让 AI 真正成为我的协作者，而不只是一个被动应答的工具？
答案其实很简单，却也是我踩了无数坑之后才真正理解的：AI 的上限，取决于你愿意给它多少上下文；AI 的下限，取决于你有没有能力判断它的输出是否靠谱。它不会读心，你得把话说清楚；它也会犯错，你得有能力兜底。说到底，AI 是放大器，放大的是你本身的能力——你越清楚自己要什么，它就越能帮你做到；你自己都稀里糊涂，它只会让你糊涂得更快。
这篇文章里分享的那些网站、提示词模板、工具用法，都只是"术"的层面。真正重要的，是在不断试错中建立起来的那种感觉：知道什么时候该信任 AI，什么时候该自己动手；知道什么问题值得花时间调教，什么问题直接搜索更快。这种判断力，没有捷径，只能靠用。
最后想说的是，AI 这个领域变化太快了，今天写的这些经验，可能过半年就过时了。但没关系，重要的不是记住某个具体的技巧，而是保持那种愿意折腾、愿意试错的状态，保持一个热爱学习的心态。毕竟，能让我们从"不会用"走到"用得顺手"的，从来都不是某个神奇的工具或秘籍，而是一次又一次的"再试一下"。
空空如也！