最近两个月在开发一个动效编辑器的过程中，我在不知不觉中形成了一套以 Skill 为核心的开发范式：先让 AI Agent 针对需求生成一个独立的 Skill（技能模块），开发者人工审核通过后投入实际开发，并在后续工作中将遇到的坑与解决方案不断沉淀回该 Skill，直至任务完成。我将这一方法论称为 Skill First。
为什么这么做：范式迁移的驱动力
之所以说“不知不觉”，是因为这套范式并非凭空设计，而是被开发过程中的真实痛点一步步倒逼出来的。
在日常的 AI 辅助编程中，我们经常陷入以下几个困境：
-
上下文窗口的掣肘。一个稍复杂的任务很难在单次对话中完整落地。开启新对话意味着丢失历史讨论，大量信息需要反复重申；留在原对话则上下文臃肿，Token 消耗激增，边际成本迅速失控。
-
决策上下文不透明。AI 在生成代码时，背后隐含了它对需求的理解、对技术选型的权衡，但这些“为什么”并未显式记录。后续维护者（甚至一周后的自己）面对一段代码时，常常困惑于“当时为什么这么写”。
-
经验无法沉淀，踩坑反复发生。传统开发中，人对 bug 的印象往往比较深刻；而在 AI 辅助模式下，Bug 由 AI 修复、验证通过后便草草收场，开发者并未真正“长记性”。这些宝贵的排坑经验散落在聊天记录里，除非 AI 模型升级，否则同类问题极有可能卷土重来。
-
模块成为孤岛，代码认知碎片化。在多人 0-1 快速构建 MVP 的场景中，每个开发者借助 AI 高速产出各自负责的模块。结果是：没人能完全吃透自己写的代码，更遑论理解他人的模块。代码虽能跑通，知识却无法流动。
-
团队知识同步成本高。当多个开发者同时使用 AI 产出代码时，彼此对模块的理解都依赖“问 AI”或“读代码”，缺乏统一的知识载体。代码评审时， reviewer 需要花费大量时间理解上下文，沟通成本陡增。
这些痛点共同指向一个结论：AI 辅助开发的瓶颈已经不在于代码生成的速度了，而在于知识的管理与复用。Skill First 正是试图通过将代码、文档、踩坑记录封装为可演进的“技能单元”，来打通这一堵点。
具体怎么做：简单演示我的实战记录
整个流程分为以下 5 个步骤：
需求对齐
与 Agent 进行多轮需求沟通，上传 PRD、可借鉴的开源项目地址、要用到的外部依赖（组件库、函数库）文档地址等材料，直至 Agent 对任务目标、约束条件和实现路径达成足够理解。这一步旨在建立共识，避免后续偏差。
Skill 生成
基于前期讨论，要求 Agent 针对本次任务生成一份 Skill。Skill 需明确标注涉及模块、拆分为可执行的阶段进度，每个阶段附带自测验证用例，并预留“踩坑记录”区域，供后续经验沉淀。
Skill Review（关键环节❗️）
将代码评审前置至 Skill 层面。由于 Skill 采用自然语言描述，开发者可快速判断 Agent 对需求的理解是否准确，避免因理解偏差导致的代码返工与 Token 浪费。
同时可引入另一模型（如用 GPT 评审 Claude 生成的 Skill）交叉验证，打破单一模型的认知局限。
分阶段落地
按 Skill 拆分的阶段依次让 Agent 开发，每个阶段开启新会话，有效规避上下文窗口限制。每完成一个阶段，执行验证用例并评审代码：
- 若发现问题，由 Agent 修复后命其将解决方案记入 Skill 的踩坑记录；
- 若无问题，在 Skill 中标记该阶段已完成。
整体验收
所有阶段完成后，对本次任务涉及的完整代码进行系统性审查，确认所有功能符合预期，并确保踩坑记录已完整归档。
这么做的好处：从业务沉淀到知识交接
当一个需求按照前述五个步骤走完，我们得到的不仅是一个可运行的功能模块，更是一份完整的可交付资产——这份 Skill 包含了需求背景、设计方案、分阶段执行记录、自测用例以及踩坑经验。它被收录进 Git 仓库，成为团队所有成员可查阅、可复用的知识基座。
这套范式的价值，在以下几个维度尤为显著：
开发者视角：经验可追溯
过去，AI 修复完 Bug、验证通过后，这段“排坑经验”便随着对话窗口关闭而烟消云散。下次遇到同类问题，要么凭模糊记忆重头调试，要么再次求助 AI 碰运气。而在 Skill First 模式下，每一次踩坑都被显式记录在 Skill 的“踩坑日志”中。无论是三天后还是三个月后，当你或同事再次面对这个模块时，打开 Skill 就能看到“前人”走过的弯路——经验不再依赖于人的记忆力，而是沉淀为可检索的文本。
团队视角：知识孤岛被连通
在多人协作的项目中，模块之间的认知壁垒往往是效率杀手。A 负责的模块，B 不敢动；C 写的代码，D 看不懂。Skill First 强制将每个模块的设计思路、实现决策、踩坑记录以结构化方式留存。当新人接手遗留模块时，不再需要逐行逆向推导代码逻辑，也不再需要追着前任问“当时为什么这么写”。Skill 本身就成了最好的文档，交接成本从“数天”压缩至“数小时”。
架构师视角：将设计意图无损传递
对于技术负责人或架构师而言，Skill First 提供了一种设计输出标准化的手段。架构师无需亲自下场逐行敲代码，而是可以针对某个需求精心打磨一份 Skill——在其中描述清楚技术选型、模块边界、关键算法的设计思路、可能遇到的坑以及规避方案。然后将这份 Skill 交给外包团队、实习生或初级开发人员去落地实现。由于 Skill 已经将大部分决策风险和踩坑经验前置暴露，执行者只需按图索骥、分阶段推进，质量的下限被显著抬升。
组织视角：代码库进化为知识库
随着项目推进，Git 仓库里积累的不再是一堆冰冷的代码文件，而是一套不断生长的 Skill 集合。每个 Skill 都附带着它的“成长日记”——为什么采用这个方案？改过哪些 Bug？踩过哪些坑？这些原本散落在部门文档、oa聊天软件里的信息，如今被系统性地编织进代码资产中。组织对业务的认知，真正沉淀在了组织内部，而不是随人员流动而流失。
写在最后
这套 Skill First 范式，我已经在实际开发中践行了一个多月。之所以今天提笔写下这篇文章，是因为偶然刷到一些讨论——Meta 等大厂正在将工程师的工作“技能化”（skills），甚至有人担忧：skills 写得越多，程序员被淘汰得越快。
坦白说，看到这类消息时，我不仅不焦虑，反而有些庆幸——自己无意中摸索出的这套工作方式，竟与硅谷大厂的实践不谋而合。
技术的发展从来不是零和博弈。回望历史，从机器语言到汇编、再到高级语言，每一次抽象层次的提升，都没有让程序员失业，反而将我们从繁琐的底层细节中解放出来，去解决更复杂、更具创造性的问题。同样，Skill First 并非要把人“蒸馏”成技能的集合，而是将可复用的经验固化下来，让 AI 更好地辅助我们处理模式化的部分，从而将精力投向那些真正需要人类判断力的领域。
