李维伊上次给团队落地第一套项目级Skills时，我本来觉得这事不难——把每个人平时手写的那些Claude Code、Codex里的小技能收集一下，按统一目录放好，再约定几个命名规则，基本就完事了。结果第二天就被现实教育了：个人Skills写得再好，拼到项目里也未必能跑。真正的坑不在“技能怎么写”，而在“技能之间怎么配合、状态怎么流转、人对AI产出怎么校验”。这篇就当作系列的第6篇，聊聊项目级Skills开发与团队协作、项目管理结合时，我趟过一遍之后留下的实操经验。
先说清楚一件事：这里讨论的Skills，不是系统集成项目管理工程师软考里的“技能”，也不是Ros2、OpenClaw周边那些资源包，而是面向AI编程代理的“AI技能”，是喂给Claude Code、Codex这类工具的结构化指令与脚本集合。说它是“项目级”，是指一整个团队在同一个仓库、同一套项目流程里共用，而不是某个人自己爽。
1. 为什么项目级Skills不是把个人Skill放大
1.1 先分清“个人Skills”和“项目级Skills”的差别
个人级Skills解决的是个人的高频小动作。比如我经常用 “git-commit-message” 这个技能，自动把暂存区的diff整理成符合 Conventional Commits 的提交信息；“meeting-notes” 把随手记的杂乱文字转换成结构化纪要。这种技能的特点是：输入输出自己定义，数据只需要自己理解，坏了也不影响别人。
项目级Skills完全不是这个玩法。它服务的对象从“我自己”变成了“项目交付节奏、团队信息同步、风险控制”这些团队共同目标。它的运行深度也会变：个人Skills通常是“一条指令对应一次动作”，项目级Skills则往往是由多个动作串联成的“小流程”。
拿“周报”来举例。个人态的技能可以是：丢给我一段本周做的事，AI帮我润色成一封给老板的周报。项目态的周报技能则是：自动去Linear/Jira里拉截止到现在的Issues列表，统计哪些完成、哪些没动、哪些被阻塞，再扫一遍Git提交记录里的分支和PR，对照代码仓库实际进展和任务系统里的记录，找出“说做完但没提交”“提交了但没更新任务”的不一致点，最后按照团队统一模板生成一份周报草案。
这两件事看起来都叫“周报技能”，做起来差得远。后者如果只是把前者复制几份，失败几乎是必然的。
1.2 项目级Skills“有状态”后才谈得上协作
个人Skills本质上可以是无状态的，每次调用都是一次全新的问答。但项目级Skills必须建立“项目状态”这个概念。因为一个团队协作场景下，AI不是只服务一次，而是要在整个迭代周期里反复介入：这周它帮你生成了站会摘要，下周还得继续；这次它帮你整理了上线Checklist，下次迭代还得复用同一套节奏。如果技能没有记忆，每次都要从零理解“我们项目现在处于什么阶段”“当前Sprint是哪几条”“哪些人负责哪块”，那它的质量和效率都上不去，还会因为上下文不一致产生前后矛盾的建议。
所以做项目级Skills时，我强烈建议先建立一个「状态文件」。通常放在项目目录下的 .ai/ 或 docs/ai/ 里，结构类似：
markdown复制# 项目状态快照
迭代: 23.2
周期: 2025-04-14 ~ 2025-04-25
目标: 客户工作台改版上线 / 支付链路超时指标恢复
## 当前成员分工
- 张一: 前端工作台
- 李二: 支付BFF层
- 王三: 数据迁移脚本
## 活跃需求与状态
- WLT-293 客户工作台List页重构: In Progress
- WLT-297 退款超时告警: Blocked(等待运维开通权限)
- WLT-301 账单导出性能优化: Done(待QA回归)
这个文件可以由Skills定时更新，也可以由团队成员在迭代计划会上手动过一遍。每次任何项目级Skill运行时，第一步先去读这个Snapshot后再动手。这样才能保证多个技能之间看到的是同一个“现状”。否则AI就像个只看了项目Wiki片段的顾问，给出的结论永远和实际脱节。
1.3 项目级Skills的三要素雏形
趟过几次坑之后，我现在认定一套可用的项目级Skills必须包含三类东西，缺一个都容易变废案：
- 通用型套路技能：例如“分支合并到主干前自动跑检查”“按angular规范生成PR描述”，这种属于可复用动作，收在公开技能库里即可。
- 项目定制化技能：例如团队内部有特殊状态流、特殊上线前检查项、特殊文档模板，这些需要把团队约定写进去。
- 项目状态同步技能：负责维护和更新前面说的状态文件，以及定期从API拉数据，把最新进展同步成统一格式。
第三类是大家最容易漏掉的。很多团队做了十几个技能，都是“做得漂亮但不知道当前项目处于什么状态”，结果每个