Skills

清明时节，雨落纷纷。 那些离开的同事，他们积累了几年的经验、踩过的坑、沉淀的判断力，也随着一纸离职证明，永远地留在了身后。 GitHub 上有个项目 colleague-skill，短短几天star

既然已经有这么多现成的 Skills，我为什么还要自己写？直接「拿来主义」不香吗？当然可以，但前提是你会选、会评估、会用。

很多读者可能会问：写一个高质量的 Skill 是不是很重？每次都要手敲几百行的 SKILL.md 和脚本吗？ 答案是：不需要。

如何设计一个高质量、生产可用的 Skill？ 一个好的 Skill 不是随便写几个指令就完事了，它需要有清晰的结构、明确的边界、可复用的流程，甚至还要考虑 Token 消耗、版本管理等工程问题。

面对 Skills、MCP、多智能体这些概念，很多人的第一反应是：它们到底有什么区别？什么时候该用哪个？

大模型很聪明，但落地时常常卡在三点：缺稳定流程（输出难复现）、缺领域常识（行规与红线难约束）、缺上下文管理（规则塞进 Prompt 又贵又难维护，每次重说又易漏）。 Skills 要解决的问题。