刚开始用 AI 时，我觉得把需求说清楚就够了。
后来才发现，每开一个新对话，很多话又得重新说一遍。
今天让它帮我改一段文字，我会提醒它：“自然一点，别太像 AI。”明天让它改个小功能，又得补一句：“只改这里，别顺手把别的东西重构了。”
它很多时候不是不会做，而是做得太多。
让它改一个按钮，它可能顺手改整页样式；让它润色一段话，它又加了一段总结；只是想补个小功能，它已经开始规划下一阶段架构。
我后来把这些常说的话写成了 Skill。
Skill 有什么用
可以把 Skill 理解成一份提前写好的说明。
把平时常用的习惯、边界和要求放进去。下次遇到对应的事情，就不用从头解释一遍。
比如我经常让 AI 帮忙改代码，就会希望它知道：
改之前先看现有代码，别上来就重写。
一处能解决的问题，不要改五处。
不确定需求时先问，别自己猜。
不要为了看起来“更规范”，加一堆用不上的东西。
改完要检查，但别顺手动无关模块。
这些话每次都说一遍挺累。写进 Skill 后，至少能少重复几次。
有些规则可以通用，有些得单独写
有些规则放哪儿都能用。
比如“不确定先问”“别乱加功能”“保持原来的风格”，写文章、改代码、整理内容时都适用。
但写博客文章和改项目代码，还是得分开。
写文章时，我在意的是语气自然、少说空话、别把原来的表达改没了。
改代码时，我更在意别乱动结构、别引入新东西、别把一个小问题搞成大工程。
所有要求都塞进同一个 Skill，最后容易变成一份又长又乱的说明，自己都不想看。常用规则放一份，特殊功能单独写一份，会更好用。
功能越复杂，边界越要先说清楚
简单的事情，AI 偶尔多做一点，影响不大。
但功能复杂了，或者改动范围变大，就得提前把边界说清楚。
比如你说：“帮我加个评论导入功能。”
AI 可能理解成要新建导入页面、改数据库、补后台管理、再加导出功能，最后还要写一份配置说明。
但你真正要的，可能只是把一份现成的 CSV 导进去。
这种时候，Skill 里最好直接写明：
只处理这次导入，不新增不需要的页面。
不改现有评论功能。
不确定字段含义时先问。
导入前先检查数据。
导入后确认数量和显示位置。
不要顺手做“以后可能会用到”的功能。
Skill 的作用就是把这类边界提前讲清楚。AI 知道什么能做，什么不能碰，做事就不会越跑越远。
Skill 不是写完就完了
第一版通常不会很完整。
用几次以后，新的问题总会冒出来。
比如它总喜欢在文章最后加一句“希望对你有所帮助”，就补一条：除非用户要求，不要新增总结和客套话。
比如它总喜欢改太多代码，就补一条：除非明确要求，否则不要重构，不要改目录结构。
比如它遇到不清楚的地方还爱猜，就补一条：有疑点必须先确认，不能自行假设。
每次遇到一个重复问题，就加一条简单规则。慢慢调整下来，这份 Skill 才会越来越贴近自己的习惯。
最后
AI 不会自动知道你的边界在哪儿。
目前AI是你提供越多的数据参考文献以及详细提示词越不容易出现幻觉，能提高命中率。更接近你的想法。
想让它写得自然一点、改得少一点、别太自作主张，就把这些要求提前写下来。
不用一开始写得特别完整。先从最常遇到、最烦的事开始：新开一个对话后，又得重新教一遍。
把这件事解决了，Skill 就已经有用了。