1. “散装 AI”正在成为团队里最贵的隐性负债如果你和我一样在过去一年里反复安慰自己“AI 至少能帮我们写点单测、解释几段历史代码”那你大概率也注意到了另一件事团队里的 AI 能力正在以极其混乱的方式野蛮生长。有人把几十条提示词藏在个人收藏夹里有人自己掏钱接模型接口有人用 IDE 插件补全还有人至今还在用最原始的“复制粘贴到网页对话框”。前阵子我接手一个维护了六年的订单系统翻着同事们各自维护的“AI 用法心得”忽然意识到一个很扎心的事实我们缺的从来不是更强的模型而是一套能把 AI 能力组织起来的方法论。这篇内容想聊的是我最近在一个存量项目里真实落地的一件事用 SKILL 编排对老代码做最小侵入的改造。它不要求推倒重来不要求全面换框架更像是一台微创手术——先划定切口再做局部处理最后缝合、观察、回归。如果你正在带团队、维护老系统、想把 AI 从“个人玩具”变成“团队资产”这篇应该能给你一些可以直接抄作业的参考。1.1 我看过的最典型的五种“散装”状态先说第一种提示词孤岛。团队里总有那么一两个 AI 用得特别溜的同事他们的提示词写得详细、分层、带示例效果确实好。但问题在于这些提示词只存在于他们自己的终端历史、收藏夹、甚至微信笔记里。哪天这个人请假或者离职他那些“最佳实践”就彻底消失了后来的人还得重新踩一遍坑。第二种是各自接 API。同一个团队里有人用这个模型有人用那个模型系统提示词自己写温度参数凭感觉调输出风格千奇百怪。同一份代码换个成员来 AI 辅助生成的东西完全不是一套风格。代码评审的时候光适应队友的 AI 风格就够累的了。第三种是工具链混乱。有人用编辑器插件做自动补全有人在终端里敲命令行有人写一次性脚本批量处理文件。这些工具之间互不相通各自为战。看起来都在用 AI实际上每个工具都只知道上下文的一个碎片完全谈不上协同。第四种是上下文靠人工搬运。这是最普遍也最消耗精力的一种。数据库表结构靠手抄、接口定义靠复制、报错日志靠粘贴每个人都有一套自己拼凑的“项目背景材料包”。同一个项目十个人就有十种不同的上下文喂法AI 的回答质量自然也参差不齐。第五种是经验只存在于聊天记录里。今天解决了一个诡异的线上问题把排查过程贴到群里明天同事遇到类似问题又开始新一轮的翻聊天记录。那些踩过的坑、验证过有效的方案从来没有被结构化成可复用的资产。1.2 散装式 AI 真正让人头疼的三件事散装最直接的问题是不可复用。一个提示词写得再好它也是“一次性”的——换个项目、换个代码目录、换个模型版本效果立刻漂移。很难把某一次成功的 AI 辅助沉淀成下一次也能稳定复现的操作流程。第二是不可审计。AI 在散装状态下干过什么几乎没有任何记录。它改过哪些文件、为什么这样改、有没有引入副作用全凭团队成员自觉。放在存量代码这种“改错一个逗号都可能炸”的场景里这种不可见性非常危险。微创手术最怕的就是医生凭感觉下刀还不写手术记录。第三是不可评估。因为各用各的你很难回答一个最基本的项目管理问题AI 到底提高了多少效率用在哪些环节上收益最大继续投入值不值没有统一的输入、输出和评价标准所谓的“AI 提效”就只是一句人人都说、但没人能拿出证据的口号。1.3 从“散装零件”到“微创器械包”我后来想明白一件事你不可能要求外科医生每次做手术时临时想一句咒语让帮手递工具。你需要的是一个针对特定手术场景预先准备好的器械包——里面有什么工具、第一步做什么、第二步做什么、怎么判断这次操作是安全的全都写得清清楚楚。SKILL 就是把散装的 AI 用法打包成这种器械包。它不只是一个提示词而是一个包含指令、参考材料、辅助脚本和执行流程的完整单元。更重要的是多个 SKILL 可以像流水线一样编排起来这个 skill 的输出正好是下一个 skill 的输入环节之间有明确的数据契约。这正是“散装 AI”到“编排式 AI”的关键转变从依赖个人灵感和临场发挥转变成依赖一套可复制、可监督、可验证的操作规程。用它对存量代码动刀才有可能真正做到“微创”。2. SKILL 到底是个什么东西可打包、可运行、可编排的工作方法2.1 一个 skill 的实际组成在不涉及具体厂商的前提下现在主流的 AI 编程工具基本都支持了 skill 的概念。它通常是一个目录里面有前端说明文件、参考文档、辅助脚本和模板。我拿一个实际用过的目录结构举例skills/ legacy-trace-ld/ SKILL.md # 前端定义 主流程 references/ # 项目背景、框架约束等参考材料 scripts/ # 依赖扫描、日志提取等辅助脚本 templates/ # 报告模板、补丁模板其中核心的 SKILL.md 分两部分头部是一段结构化的元信息声明这个 skill 的名字和适用场景正文则是具体的操作流程告诉模型“你要先做什么、再做什么、每一步必须产出什么”。类似于给模型塞了一本“岗位手册”。头部示例大概长这样--- name: legacy-trace-ld description: 在存量 Java 服务中分析调用链并为指定的业务接口补充链路追踪上下文要求不改变原有行为。 ---正文则写成步骤式指令。注意这里不是给模型念咒语而是给出一套带有输入、输出、约束条件的操作规程。这一点非常关键后面我会专门展开。2.2 SKILL 与普通提示词、Agent、Workflow 的边界很多人容易把 skill、agent、workflow 混为一谈其实它们解决的是不同层面的问题。普通提示词是一段一次性的话说完就完workflow 是一张固定的流程图适合确定性很高的流程但改起来很僵硬agent 是一个能自主决策的助手适合开放探索但稳定性天然不足。skill 更像是夹在中间的“标准操作手册”它把“针对某类任务怎么做”固化下来既能被 workflow 串起来跑也能被 agent 在适当时机自动调用还允许人手工触发。换句话说skill 本身不是一个完整的应用而是一个可以被灵活复用的能力单元。我用一个表格来说清楚边界形态擅长的事典型问题在存量代码场景的表现普通提示词一次性的问答、解释、草稿换场景就失效每次都要重新组织上下文结果不稳定Agent开放式的探索、多步推理不可控可能跑偏让它自由改代码容易顺手改坏别的东西Workflow固定流程、强顺序僵化改动成本高适合打包回归测试但没法处理临场变化SKILL高频、可重复、可验证的任务需要设计成本稳定、可审计适合作为微创手术的工具包再说到“编排”。很多人以为编排就是把几个 skill 堆在一起让模型依次跑一遍。实际上编排的核心在于数据契约上一个环节输出的结构化结果必须是下一个环节可以直接消费的输入。比如“依赖扫描”输出一份问题清单“补丁生成”读取这份清单而不是重新扫描一遍“验证回归”又只针对补丁涉及的变更范围展开。这样才叫编排而不是简单的顺序执行。2.3 设计一个靠谱 skill 的三个原则第一个原则是单一职责。一个 skill 只解决一个类型的问题。我见过有人试图做一个“全栈改造大师”结果它既想扫描依赖又想生成补丁还想跑测试最后每一步都浅尝辄止输出质量惨不忍睹。正确做法是拆成“诊断”“手术”“验证”三个独立 skill各管一段。第二个原则是上下文聚焦。存量代码项目动辄几十万行全部塞给模型效果和效率都会急剧下降。好的 skill 会主动裁剪上下文先跑脚本把入口文件、接口定义、相关依赖筛出来只把和本次改动相关的部分交给模型。这就好比医生不会把病人全身的检查报告都看一遍而是只看和病灶相关的片子。第三个原则是可观测性。每一步都要有明确输出都要有检查点都要有终止条件。尤其是改造类的 skill最后必须强制带一个“验证行为一致性”的出口。做不到这点的 skill用起来和散装提示词没有本质区别。3. 存量代码“微创手术”到底从哪几个切口下刀3.1 切口一先摸清家底依赖与配置梳理存量项目和绿地项目的最大区别是你根本不知道自己脚下踩着什么。很多老系统经过多年维护依赖关系混乱、配置文件成谜、某些模块甚至没人知道还跑不跑。这时候最忌讳的就是直接让 AI 上手改代码——它连依赖图都没搞清楚改出来的东西你敢信吗我习惯的做法是先做一个“环境摸底”类的 skill。它做的事情其实很朴素扫描项目里的依赖清单、配置文件、模块之间的 import 关系然后输出一份结构化的风险矩阵。矩阵的每一行是一个关键组件包含版本、被谁引用、使用位置、可能的兼容性风险。这一步完全不动业务代码纯粹是体检。举个例子一个老的 Java 项目里某个内部库同时被三个模块以不同版本引用。单靠人眼 grep可能要半天才能理清楚用 skill 加脚本自动化扫描几分钟就能产出一张依赖冲突清单。后续改造的时候这张清单就是手术的“术前影像图”所有方案都基于它来制定。3.2 切口二局部病灶处理最小 diff 重构存量代码最怕“顺手重构”。很多人用 AI 改老代码时最大的冲动就是让 AI 把看不顺眼的老写法全部改掉。这种冲动在微创手术里是大忌。老代码虽然丑但它能跑线上行为是稳定的你一旦让 AI 大面积重写就等于把一次小手术扩大成了开胸手术。正确的做法是“行为保持”优先。改之前先为现有的方法生成行为测试把“给定这些输入原来输出是什么”固化下来。然后基于这个基线只对目标方法做最小 diff 的改动。skill 里要写死一条约束禁止修改与本次任务无关的代码。我在实际项目中跑下来只要把这条约束写清楚模型越界的概率会大幅下降。但注意是不能完全消除的所以还需要配合人工的 diff 评审这个后文会细讲。3.3 切口三测试补全与回归看护存量改造最让人夜不能寐的就是回归。老系统大多测试覆盖不足你改了 A 方法根本不知道 B 模块会不会因此崩溃。这时候 skill 可以扮演“心脏监控”的角色针对改动的范围生成边界值测试、兼容性测试并把它们接到现有的 CI 流程里。这里有个特别容易踩的坑模型生成的测试很多时候是按它想象中“应该的样子”写的而不是按代码“现在的样子”写的。它会不由自主地把老代码里一些诡异但正确的行为当 bug 修掉。所以测试类的 skill必须在流程里强制模型先读真实实现再写断言还要允许人工抽检测试的质量。否则你等于用一个会撒谎的测试去验证一个不靠谱的补丁双重灾难。3.4 切口四文档与变更记录同步老系统往往没人愿意写文档因为文档早就和代码脱节了。但微创手术做完之后如果连“到底改了什么、为什么改”都没有记录下一次维护的人又会回到靠猜的状态。这种文档的缺失本质上也是一种技术债。所以我设计了“变更说明生成”类的 skill喂给它一次 git diff它输出一份结构化的变更说明包括改动范围、影响面、潜在风险、回滚建议。不追求天衣无缝但至少把 AI 做过的事情变成可审计的记录。慢慢地这份记录就成了团队理解老系统的最新鲜的入口。这也能带来一个额外收益存量代码的维护不再依赖某个老员工的记忆而是形成了一条可以持续沉淀的“知识管线”。4. 一次真实的“微创手术”给老订单系统补链路追踪4.1 项目背景与手术边界前面讲了不少方法论我们来看一个真实的案例。项目是一个六年前上线的订单系统Spring Boot 2.x服务之间靠日志 grep 排查问题。这次的需求是要给关键业务接口加上链路追踪的上下文为后面接入中间件做准备。硬性约束有三个线上行为不能变、改动范围尽量小、必须能快速回滚。团队当时犹豫要不要用 AI 做因为大家平时都有被 AI 胡乱改代码坑过的经历。我拍板说可以做但前提是必须把整个流程编排成一串有监督的 skill不能像平时一样丢一个长提示词让它自由发挥。4.2 方案三个 skill 组成一条编排链路最终我们设计了一条由三个 skill 组成的改造流水线先是 scope-analysis负责圈定本次改动的影响面然后是 patch-gen在影响面内生成最小补丁最后是 verify负责验证改造前后行为等价。三个 skill 的输入输出是严格衔接的。scope-analysis 的输入是一个业务接口名输出是一份“影响面清单”包括涉及的文件、类、方法以及每个位置的风险等级。这份清单是结构化数据直接作为 patch-gen 的输入。patch-gen 只允许在清单范围内生成补丁并且在 SKILL.md 里写死了三条硬约束不修改与链路追踪无关的类、不顺手重构老代码风格、发现疑似 bug 时只在报告里指出但不擅自修改。verify 则是接管补丁之后的工作它会把改动前的旧逻辑做成一组“黄金信号”测试再对比改动后的运行结果是否一致。4.3 执行过程哪些地方顺利哪些地方差点翻车第一次跑 patch-gen 的时候效果比预期好但也干净利落地踩了一次坑。模型确实只改了目标接口可它在改日志工具类的时候顺手把类名重命名了。从代码风格角度看新名字更合理但这是典型的越界操作——如果当时没有做 diff 评审这个改动会在上线时引发一堆找不到类的错误。后来我在 patch-gen 的 SKILL.md 里加了一条更严格的规定只允许新增方法和修改方法体禁止修改任何公开的类名、方法名、参数列表。加了这条之后越界行为基本绝迹。还有一次模型在阅读旧代码时发现了一个“看起来明显是 bug”的地方于是不动声色地在补丁里把它修掉了。从逻辑上讲它修得没错但这个修复超出了本次手术的范围而且没有经过任何评审。如果上线后出问题这就是一次无记录的行为变更。后来 verify 环节加了“报告与改动一致性”检查专门拦截这类“顺手修 bug”的情况。4.4 事后复盘微创手术的风险控制清单整个项目做完之后我复盘了几条经验。第一模型对老代码的“风格洁癖”很难根治它看到丑陋的代码总想改唯一的办法就是在 skill 里做显式约束并且留一道人工评审关卡。第二上下文窗口永远是瓶颈老项目几个 G 的代码不可能全塞给模型用脚本预筛相关文件是必须的不是可选的。第三人工评审不能省但可以轻量化。有了 skill 生成的结构化变更说明评审只需要看 diff 和说明是否一致不需要重新理解整个项目背景效率比想象中高很多。第四黄金信号测试非常值得做。在改造前先记录旧逻辑的输出特征改造后对比这种“行为等价”验证比单纯跑一遍单测更能抓住问题。模型天生会写“看起来对的测试”但它不会主动为你验证“线上行为没变”所以这一步只能由 skill 流程强制兜底。5. 从“我会用”到“团队会用”SKILL 落地的最后几件事5.1 把 skill 当成代码来管理个人用 skill 很自由但到了团队层面就得把它当代码一样管理。我建议用独立的 git 仓库来存放所有 skill每次新增或者修改都要走评审流程。评审的时候重点看三件事description 是否清晰边界是否明确是否自带验证环节。缺少任何一项都不允许合入。命名规范也很重要。建议按“动词 对象”的方式命名比如 scan-dependencies、patch-trace-context、verify-behavior-equivalence。名词描述的是静态概念动词描述的才是可执行的动作后面接的对象正好限定了适用场景。这种命名方式让整个 skill 库像一份“能力菜单”团队里的人一眼就能知道什么东西可以复用。5.2 区分场景什么值得做成 skill什么不值得也不是所有事情都值得做成 skill的。我现在的判断标准很简单连续三次用同样的方式解决同一个问题就值得沉淀成 skill。一次性问答、思路探讨、开放式头脑风暴直接用对话更高效没必要增加设计成本。反过来高频、可重复、可验证的任务哪怕现在只有自己一个人用也值得做成 skill。比如“扫描依赖冲突”“生成变更说明”“对某个方法做行为等价测试”这些任务每次做的方式都很相似而且产出可以核对做成 skill 的性价比极高。还有一种情况特别适合 skill团队里新人的成长路径。新人不理解老系统可以先让他跑一遍“摸底”类的 skill很快就能得到一张结构化的项目认知地图比翻几个月代码老黄历快得多。这也算是 skill 编排带来的一个隐性收益。5.3 编排的下一个阶段和 CI、评审、新人培养打通最后聊聊我看到的下一步。skill 编排目前已经可以做到诊断出影响面、生成最小补丁、自动验证行为等价、输出变更说明。再往前走就是把这套东西和团队的 CI 流程、代码评审工具、技术债管理彻底打通。比如每次 MR 提交之后CI 里自动跑一个“diff 分析”类的 skill生成变更摘要和风险提示评审人打开页面就能看到摘要不用人肉读完整 diff。比如新人入职第一次领任务先跑一遍全链路摸底 skill把输出当成第一个“通关任务”。这些都是低成本、高感知度的改进。如果你也要对存量代码动刀我个人建议别急着追求“AI 全自动”。真正稳妥的节奏是先挑一条最不敏感的业务链路做试点用 skill 编排把流程跑通把风险控制清单固化下来再逐步扩大范围。老系统经不起大手术但它完全承受得住一次次规划周密的微创手术。先把每一件小事按规矩做好你会发现那些看起来很大的问题早就在无数个可以验证的小改动里被悄悄拆解掉了。