AI 这个"员工"我也是下定决心给他好好培训一下了。
败家子 AI
起因是我发现之前的一些项目都是 AI 写的，但是都是通过单点提效的方式生成的，导致各个文件之间没有规范，且重复的逻辑也相当多，一个维护了3-4个月项目，他的项目体量也是相当大，最关键的是连原始需求都丢了，导致让 AI 去改动都出了不少问题。
麻烦的事来了，这些烂摊子都交到了我的手上，而当我想让 AI 增加功能的时候，我发现一个 258K 的上下文，一轮对话就能消耗 18% 左右，这不是花钱如流水嘛~
而最大的问题是出在多轮对话上。按照这个消耗的速度，平均 5-6 轮对话就需要压缩一次上下文，一旦压缩上下文后，就会出现 AI 容易把之前的一些需求细节给忘了，导致多次返工，项目还越改越失控~
所以我决定要最大程度的改变一下这个现状，否则养着这么个"败家子"，那地主家也没有余粮啊！
skills 的诞生
如果要让 AI 能理解好我每一个项目，势必需要一个 Skills 来帮助它生成文档，当它需要了解项目的时候就从文档中去读取，并且给他划好边界，做好方案文档，免得到时候多轮对话后忘记了我们的原始需求。
好了，现在这个 Skills 的核心功能已经有了，下面就需要考虑生成什么样的文档才能帮助 AI 更好的理解项目，理解需求。
首先第一个就是入口文件 AGENTS.md，这是项目级 AI 的协作规则，让 AI 进入这个项目后，第一眼就知道应该读什么，哪些事能做，哪些事不能乱做。
第二个 docs/architecture.md 解决的是：这个项目的技术栈、目录边界、核心模块、数据流和高风险链路是什么。
第三个 docs/runbook.md 解决的是：这个项目怎么启动、怎么测试、怎么构建、怎么排错。
第四个 docs/specs/ 解决的是：中高风险需求不要直接开改，先把目标、非目标、影响范围和验收标准写清楚。
第五个 docs/decisions/ 解决的是：重要技术决策要留下原因，不要让后来的 AI 只看到结果，看不到当时为什么这么选。
这样设计的重点不是为了生成的文档好看，而是为了减少 AI 的猜测空间。
AI 要解决的是后续开发里最关键的几个问题：
这个项目怎么跑？
哪些地方是核心链路？
哪些文件修改前必须先读？
哪些逻辑不能凭感觉动？
改完之后用什么命令验证？
需求边界不清时，应该先写方案还是直接改代码？
这些问题如果不提前靠文档解决掉，后面每一次开发都会重新付费，付 token，付时间，也付返工成本。
文档能有用吗
有些人可能觉得 Skills 貌似是个很高级的东西，应该有很多脚本、命令，只靠生成一些文档能有作用吗？
其实完全不是这样，文档只是输出形式，重要的是解决如何让 AI 在行动前知道边界的问题。
当然很多人会对文档这个形式产生质疑我也是能够理解的，因为很多人都很讨厌写文档，尤其是程序员，毕竟程序员最讨厌的四件事就是：写文档，写注释，别人不写文档，别人不写注释。
但是吧，我想说给 AI 用的文档，和给人看的汇报文档不是一回事。
一个没有边界的 AI，很容易把积极理解成扩大范围。
一个没有上下文的 AI，很容易把重构当成顺手优化。
一个没有项目记忆的 AI，很容易在多轮对话后忘掉最初的需求。
所以我写的 project-onboarding 这个 Skills 的核心，就是为了让 AI 把项目中最影响后续协作的部分固定下来。
它不需要记住每一行代码。
它只需要知道哪里危险，哪里稳定，哪里可以扩展，哪里需要先确认。
这才是项目级 AI 协作的基础设施。
用上 Skills 后有什么变化
我也对比了一下没有 project-onboarding 生成文档之前的项目和生成文档之后的项目，结果的差异性还是比较明显的。
当我让 AI 增加一个支付的 Provider 的时候，AI 会先识别这是高风险改动，然后追问 Provider 的接入方式、回调处理、环境变量、验收标准。方案确认后，它会先写进 docs/specs/，再按方案实施，最后根据 docs/runbook.md 做验证。
这个时候 AI 就不再是凭感觉工作，而是在项目约束里工作。
当然它仍然会犯错，但错误会更容易被限制在一个范围内。
让然它仍然需要读取上下文，但不会每次都从零开始。
当然它仍然需要人来判断方向，但人不用一直重复解释基础背景，并且告诉他上一轮对话的结果是什么。
我们暂时也没办法把 AI 变成一个万能工程师，但是通过这个 Skills 至少能让它从一个临时外包，变成一个知道项目规矩的协作者。
AI 还有更多的潜力
所以当项目越来越复杂的时候，AI 能不能帮上忙，不只取决于它有多聪明，也取决于你有没有给它建立一套工作秩序。
它不一定马上变成王牌工程师。
但至少，稍微给它做个入职培训，别再让它每次都像第一天上班一样。