Fenno + CC Switch：一个 API Key 搞定 Claude Codex 等全套 AI 编程工具
2026-06-18 3359768
2026-06-18 0
很多人刚开始用 AI 编程时，都会经历一个很顺的阶段。
随手开个对话，丢一句需求，AI 很快就能给出方案、代码、测试或者文档。前几次体验通常都不错，所以很容易形成一个判断：
“以后遇到问题，继续在聊天里说清楚就行了。”
我一开始也是这么做的。
但项目一多、任务一杂、上下文一长，这种方式就开始不稳了。不是 AI 突然变差了，而是同一类信息被反复重新解释，工作流越来越依赖“这次对话里有没有碰巧说全”。
因为聊天记录的门槛最低。
你不需要先设计流程，不需要提前整理规范，也不需要准备模板。想到什么就说什么，马上就能得到反馈。
在这些场景里，它确实很好用：
所以我并不觉得聊天记录是错的。
它的问题不在“不能用”，而在“只适合前期探索，不适合长期复用”。
当项目进入持续开发阶段，聊天记录会暴露几个问题。
第一个问题是：上下文越来越长，但真正关键的信息没有沉淀下来。
比如你可能已经在前面说过：
但只要换一个新对话，这些内容又得重说一遍。
第二个问题是：同类任务的处理方式会不稳定。
你这次说“先列测试矩阵再写测试”，AI 可能照做。下次你少写一句，它就直接开始生成测试代码。不是因为它故意乱来，而是因为这条规则没有真正固化。
第三个问题是：团队很难复用。
聊天记录天然更像个人临场沟通，别人接过来时，往往只能看到结果，看不到你当时是怎么一步步把 AI 约束住的。
不是一开始。
通常是到了下面几个信号同时出现的时候：
比如：
这时候我就越来越确定，这些东西不该继续散在聊天里了。
它们已经不是一次任务的补充说明，而是一类任务的固定规则。
我现在更愿意这样理解：
前者关注的是：
“这次请帮我做什么。”
后者关注的是：
“以后只要遇到这种任务，就按什么原则做。”
这就是两者最本质的区别。
所以 Skill 的重点并不是“写得更长”，而是把那些会重复出现、又直接影响质量的约束固定下来。
不是所有东西都要写。
我更建议优先写这四类：
第一类是技术栈和环境约束。
比如：
第二类是工作流程。
比如：
第三类是风险边界。
比如：
第四类是输出格式。
比如：
这四类东西，几乎是最容易反复说、也最值得最早沉淀的。
我现在也不会把 Skill 神化。
它能解决的是：
但它解决不了：
也就是说，Skill 不能替你思考，但它可以帮你把“已经想清楚的部分”稳定地交给 AI 执行。
所以我为什么开始把 AI 提示词收成 Skill，而不是继续堆聊天记录？
因为我慢慢发现，真正拖慢协作的不是 AI 生成速度不够，而是那些本来已经讲清楚过的规则，一直没有被沉淀下来。
聊天记录适合探索。
Skill 适合复用。
当你开始反复做同类任务、反复踩同类坑、反复解释同类边界时，就说明这件事已经值得从“临时沟通”升级成“固定工作流”了。 收成 Skill，而不是继续堆聊天记录？
因为我慢慢发现，真正拖慢协作的不是 AI 生成速度不够，而是那些本来已经讲清楚过的规则，一直没有被沉淀下来。
聊天记录适合探索。
Skill 适合复用。
当你开始反复做同类任务、反复踩同类坑、反复解释同类边界时，就说明这件事已经值得从“临时沟通”升级成“固定工作流”了。