用了 AI Coding，我反而不知道该怎么分任务了
AI Coding 把单人执行效率拉上去了，但分工方式没跟着变，提速很快到天花板。按老方法分任务，对齐成本吃掉了并行的收益。
十几年 Git 历史全是 add，一个 Skill 改掉了
commit message 十几年全写 add，知道不对但一直放着。写了一个 Skill 让 Claude 读 diff 生成 message，几分钟搞定，顺带解决了颗粒度和 AI 代码 review 的问题。
SKILL.md 怎么写：不是越写越长，是越蒸越准
写 SKILL.md 多半被当文档，越写越长越写越虚。Skill 其实是反复加规则、再反复删规则蒸出来的。加是熵增 AI 能帮，删是熵减 AI 替不了。
业务全 Skill 化，不叫 AI 落地
身边不少人把传统业务流程包成 Skill 交给 Agent 跑，用 Skill 数量衡量 AI 落地。但按旧流程步骤切 Skill，堆得越多，Agent 能自主判断的地方越少。
SKILL.md 不是 SOP，是你的判断小抄
翻了不少别人写的 SKILL.md，几乎都长成 SOP。SOP 是写给会照做的人看的，Skill 是写给会推理的 AI 看的。把 SKILL.md 写成 SOP，AI 就只是个更慢的查询系统。
Skill 的原理：不是工具，是给 AI 的 4 张便签
很多人把 Skill 当 API，看见 scripts/ 就以为是工具。其实 Skill 是给 AI 的 4 张便签：description 永远在，SKILL.md 触发才在，references 找才在，scripts 是 AI 调的。
AI 做 Code Review 总说没问题，因为它在偷懒
写了个 Skill 让 Codex 帮我做 code review，审 Claude 的代码。以为两个模型分工互不偏袒就稳了。做了几个月才发现：换谁审都一样，问题在评判机制本身。
让 AI 写方案，越用 Skill 反而越差
同事不用 Skill 直接让 AI 生成的 HTML 清晰得很。我自己加 SKILL.md 改三轮反而越改越差。AI 写方案这件事，第一稿别给 Skill。
AI 卡住了，我问了它一句：需要我帮忙吗？
Claude Code 写 Skill 时卡在飞书懒加载的死循环里。我问了一句"需要我帮忙吗？"，配合它刷新浏览器，问题就解了。
AI Coding 之后，任务能不能拆，上下文说了算
上一篇说了分工标准得变，这篇讲具体怎么判断。核心就两个问题：上下文是否完整，决策权落不落在这个域内。