面向Skills编程：领域知识工程驱动Code Agent高效生成代码

最近跟好几个做企业级开发的朋友聊天，大家都有一个共同的感受——AI编程工具写个小脚本、做个小项目确实很爽，但一旦扔进几十万行代码的大型项目里，基本就抓瞎了。改了这里那里就崩，上下文根本塞不下，最后AI变成了一个高级打字员。阿里妈妈技术团队最近提出了一个挺有意思的方法论，叫「面向Skills编程」，据说能把代码生成准确率拉到90%以上。今天咱们就来好好聊聊这个事儿。 对，你说的这个痛点其实特别典型。很多人觉得AI写代码不行是因为模型不够聪明，但其实核心问题不在算力，而在知识断层。你想啊，一个二十多万行的代码库，真正活跃的可能就两万行，剩下的全是历史遗留、废弃逻辑。不同业务线之间的耦合关系又错综复杂。更要命的是什么呢？核心开发人员可能早就离职了，文档跟实际代码严重脱节。AI每次要改个需求，都得人类重新补一大堆背景知识，这效率能高才怪。 嗯，所以本质上不是AI笨，而是它拿不到足够准确的上下文信息。那有人可能会说，现在大模型的上下文窗口不是已经到128K甚至更长了吗？把文档全塞进去不就行了？ 哈，这恰恰是很多团队最开始踩的坑。把一堆业务文档——甚至是过时的文档——一股脑塞给AI，结果token直接爆掉不说，AI根本抓不住重点。这里面有个很经典的研究结论叫「Lost in the Middle」，就是说当输入内容太长的时候，模型对中间部分的信息关注度会显著下降。你给它塞了十万字，它可能就记住了开头和结尾，中间那些关键的业务规则反而被忽略了。再加上企业级场景调用频率很高，token消耗直接关联成本，这种信息轰炸式的方案在工程上几乎不可用。 那阿里妈妈提出的Skill三层结构具体是怎么解决这个问题的？我理解核心思路是按需加载？ 对，精准路由加按需加载，这个比喻特别好——不是给AI一本字典让它自己翻，而是给它一个智能导航系统。每个Skill分三层：第一层是概要层，大概就一百来字，包含名称和简短描述，始终可见，让AI快速判断这个Skill跟当前任务有没有关系；第二层是主体层，大概三千字左右，只有AI觉得需要深入了解的时候才加载，里面是业务规则、核心流程这些；第三层是细节层，只有在写代码遇到具体的接口定义、数据模型的时候才去拉取。 这其实就像我们自己查资料的过程——先看目录，觉得相关再看摘要，真要用到细节了才翻附录。 你看，这就是渐进式披露的精髓。而且它不光是Skill这一层，整个知识系统是三个层次配合的。最上面是全局项目地图，包括一个叫AGENTS.md的配置文件，相当于给AI一份项目入职手册，告诉它技术栈是什么、目录结构怎么组织、编码规范有哪些。中间是Skill主文件，处理具体任务时加载。最底下是References细节目录。从宏观到微观，非常符合大语言模型的思维习惯。 这里面还有一个关键点我觉得值得展开说——知识与代码的显式映射。传统方式是告诉AI有什么规则，但规则对应到代码的哪个位置，AI得自己猜。 这个太重要了。以前就是这样，AI知道有个规则说「订单状态变更必须走审批流程」，但它不知道这个规则具体对应哪个文件、哪个函数、哪个节点，只能自己去猜，猜错了就写出bug。面向Skills编程的做法是，每一条规则都明确标注它所在的流程、节点和代码入口位置，相当于直接给AI画了一张导航图。这个改进效果非常显著，代码生成准确率直接拉到90%以上。 好，知识建好了，但还有一个很现实的问题——知识会过时。代码天天在变，文档更新跟不上，这在传统开发里就是老大难问题了。在AI编程时代，这个问题是不是更严重？ 严重太多了。Stack Overflow有个调查说超过60%的开发者认为内部文档经常过时。以前文档过时顶多是新人上手慢一点、沟通成本高一点。但AI不一样，它会把过时的规则当真理严格执行，然后以代码生成的速度在整个工程里快速复制这个错误。你想想，一个人手写代码犯错影响范围有限，但AI一口气生成几十个文件都用了错误规则，这破坏力是指数级的。 所以过时的知识比没有知识更危险。那他们怎么解决的？ 搭了一个四层防护体系，贯穿整个开发周期。第一层是反向校验，AI在读取知识和代码的时候如果发现两边不一致，自动生成修正建议；第二层是沟通补充，AI遇到不理解的地方会主动跟开发者讨论，讨论结果直接更新到知识库；第三层是Commit校验，这个最关键——每次代码提交都强制检查，有代码变动就必须同步更新知识，把腐化挡在门外；第四层是全量巡检，每次发布后对整个代码库和知识库做全局比对。这样一来，文档更新就变成了开发过程中自然而然的事情，不需要专门派人维护。 嗯，这让我想到另一个话题。现在社区里比较火的SDD——规范驱动开发，就是先写Spec再让AI生成代码。阿里妈妈提出的Domain Scale跟SDD有什么本质区别？ 其实SDD在全新项目或者大模块初始开发的时候效果是不错的，因为Spec能给AI提供清晰的需求边界。但问题是日常迭代中，一个小需求可能就改几行代码，你却要花好几倍的时间去写Spec，而且这些Spec用完就扔了，没法积累。Domain Scale的思路完全不同，它强调维护一套不断成长的核心领域知识库。每次写的新代码都是知识的一种物理实现，知识库随着项目推进越来越丰富，是真正的团队资产，能产生复利效应。打个比方，SDD像是每次做饭都写一份新菜谱然后扔掉，Domain Scale则是在不断完善一本家传菜谱。 这个比喻好。那最后聊聊落地，如果有团队想尝试这套方法论，你觉得应该怎么开始？ 三个建议。第一，先评估业务适配性，确认你的业务是不是闭环的，领域知识能不能被完整列举出来，不是所有场景都适合。第二，小范围试点，找变更最频繁或者痛点最明显的模块先做起来，快速看到效果，风险也可控。第三，也是我觉得最重要的——防护机制先行，一定要先把Commit校验这道关设好，流程保障优先于文档完善。否则知识库建了但没人维护，越做越乱，反而比没有还糟糕。 说到底，随着大模型能力越来越强，通用的AI编程工具大家都能用，工具本身很难形成差异化。真正的护城河是什么？是你团队积累的领域知识体系，是专门为Code Agent打造的工具链，是一个干净且结构良好的代码仓库。面向Skills编程这套方法论，本质上就是在AI和复杂业务代码之间搭了一座结构化的桥梁。与其纠结该用哪个AI工具，不如先把自己的领域知识管好——这才是长期主义的打法。 没错，工具会迭代，知识才是真正能沉淀下来的东西。