改存量代码别翻车，把AI编排成开发流水线

文章目录

• • 前言
  • 1. 改存量代码，最怕的不是不会改
  • • 1.1 需求看着挺人畜无害
    • 1.2 拆开一看，全是暗坑
    • 1.3 所以核心矛盾是啥
  • 2. 别再用"散装AI"了
  • • 2.1 什么叫散装AI
    • 2.2 换条思路：搞条流水线
  • 3. 这条流水线长什么样
  • • 3.1 一个编排器，两条流程
    • 3.2 每个 Skill 只干一件事
    • 3.3 三个机制，让流水线不僵化
    • 3.4 Skill 之间怎么传数据
  • 4. 实战：给图片上传做个"瘦身"
  • • 4.1 需求一句话，改起来要命
    • 4.2 先摸清这刀下去切到谁
    • 4.3 规则先谈清楚，边界值问明白
    • 4.4 最小侵入：就改一个变量名
    • 4.5 永远 resolve 的 Promise
    • 4.6 埋点和国际化：两个小跟班
    • 4.7 回归用例 + CR 自查：提交前的双保险
  • 5. 数据说话：202 行搞定
  • 6. 六条原则，帮你少踩坑

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548

前言

先问个扎心的问题：你怕不怕改老代码？

不是那种"新建一个文件，从头写到尾"的岁月静好。是那种需求单上写着"优化一下上传体验"，你打开代码一看，好家伙，这个组件有两个爹、三个儿子，还牵着一个祖传接口。那一刻你脑子里只有一个画面：自己站在一屋子多米诺骨牌中间，手里捏着第一块，身后是产品经理期待的眼神。

今天不聊什么高大上的架构，就聊聊怎么给存量代码"动刀"，还能不翻车。全程无理论背诵，纯实战唠嗑。

1. 改存量代码，最怕的不是不会改

1.1 需求看着挺人畜无害

某天，业务同学过来：销量上报那边，图片上传之前，前端先压缩一下再传呗，服务器快扛不住了。

听上去是不是很小的事？压缩图片，网上一搜一大把方案，十分钟搞定。

但你冷静一下。这是存量代码，不是新项目。新项目是白纸上画画，画错了橡皮一擦完事；存量代码是在写满字的纸上改错别字，涂改液用多了，纸就破了，破的还不是你的纸。

1.2 拆开一看，全是暗坑

真正动手之前，先给自己泼盆冷水，数数这单活儿里藏了几个坑：

• **影响范围不确定。**上传组件不是只有这一个页面在用，同一个组件好几个页面共用。你在这边加个压缩，隔壁页面的上传行为可能全变了。改完你都不知道该先给谁道歉。
• **分支复杂。**单文件上传一条路，批量上传一条路。压缩逻辑插哪个分支？插到哪一层？会不会有副作用？插错了，批量上传变批量翻车。
• **降级策略没定义。**压缩失败了怎么办？是报错让用户重传，还是静默传原文件？还有那个经典的边界问题：恰好 3MB 算哪边？恰好 10MB 算哪边？
• **效果没法量化。**压缩到底有没有用？省了多少流量？没有埋点，你拿什么证明？全靠产品经理的直觉吗？

1.3 所以核心矛盾是啥

改存量代码，最吓人的从来不是"改不动"，而是改完之后，你根本不知道哪个角落会先炸。

这感觉就像你在自己家墙上钉钉子挂画，一锤子下去，隔壁邻居家停电了。你拿着锤子站在原地，连道歉都不知道该朝哪个方向鞠。

传统的"打开文件直接改"模式，容易漏掉一堆看不见的活儿：影响面没分析、规则没定、埋点没加、回归没覆盖。漏了任何一个，线上事故就离你不远了。

2. 别再用"散装AI"了

2.1 什么叫散装AI

以前我们怎么用AI？问一句答一句：帮我写个函数、帮我查个API、帮我改个bug。用完即走，经验一点不剩，下次遇到类似问题，从头再问一遍。

这就叫散装AI。像你买了一抽屉螺丝刀，但从来没有一把电钻；像买了一大包散装奶茶料，但从来没想过把它们按步骤做成一杯成品。

散装AI最大的问题不是"不能干"，而是每次都得从零开始，那些隐性工作——影响面、处理规则、埋点、回归——全靠当天的心情和运气。

2.2 换条思路：搞条流水线

我们的做法是：把开发过程中那些"每次都要做、但每次都容易忘"的环节，沉淀成一个个独立的、单职责的 Skill；再搞一个编排器，按需把它们串起来。

打个比方，这就像饭店后厨。不是客人点什么，厨师现想怎么做；而是有一本 SOP：配菜、切菜、下锅、装盘，每一步都有专人负责，最后端出来的那盘菜，色香味基本稳定。

对存量代码来说，这条流水线就是一份"怎么改才不出事"的流程保证。AI 不是来替你拍脑袋的，是来替你按流程走的。

3. 这条流水线长什么样

3.1 一个编排器，两条流程

整个系统很简单：1 个中央编排器（dev-workflow）+ 一堆单职责 Skill。

编排器先干一件事：判断需求是增量还是存量。

dev-workflow 编排器
├─ 判断需求类型
│ ├─ 增量需求（新建模块/页面/功能）
│ │ └─ 流程A：搭骨架 → 写业务 → 验证提交
│ └─ 存量修改（改已有代码）
│ └─ 流程B：分析评估 → 写代码 → 验证提交

为什么非要分两条路？因为增量是盖新楼，错了可以推倒重来；存量是给已经住满人的楼换承重墙，每一锤都得算清楚。

3.2 每个 Skill 只干一件事

流水线上的每台"机器"只有一个职责，谁也别想当瑞士军刀：

• **impact-analysis（影响面分析）：**动刀之前先做全身体检。向上追"谁在用我"，向下追"我依赖了谁"，横向扫"谁跟我共用同一个API"。
• **processing-principles（处理原则提取）：**把产品经理嘴里的"你看着办"，翻译成能写进代码的规则。
• **minimal-invasion（最小侵入分析）：**找风险最低的手术切口，信条就一句：改得越少，风险越低。
• **monitor-integration（埋点集成）：**给功能装个记步手环，好不好用，数据说话。
• **i18n-integration（国际化）：**用户看得见的文案，一个都不许硬编码。
• **regression-cases（回归用例）：**给老功能买保险，该测什么，一条条列清楚。
• **cr-self-check（CR自查）：**提交前的最后一班岗，逐项检查，别带着雷上线。

3.3 三个机制，让流水线不僵化

光有流水线还不够，最怕它变成走过场。所以加了三个机制：

• **智能跳过：**不是每个 Skill 都要跑。本次实战 9 个 Skill 只跑了 7 个，跳过了 2 个。就像开会，这个议题跟你没关系，你可以先撤，没人拦你。
• **Phase 关门：**每个阶段干完，暂停，给你看摘要，问一句"确认继续吗？"这就像打游戏的存档点——方向错了，读档重来，不用删号重练。
• **可拆可组：**每个 Skill 都能单独用。紧急 hotfix 可以跳过分析直接改，谁也别想绑架你走完整套流程。

3.4 Skill 之间怎么传数据

这里没有 API，没有数据库，全靠自然语言。上游 Skill 输出的结论，就是下游 Skill 的输入。

像接力赛，上一棒递过来的不只是接力棒，还有一句口信：“前面有弯道，慢点。”

举例：impact-analysis 判定"影响面很小"→ processing-principles 就跳过"跨组件兼容"检查；processing-principles 说"要埋点"→ 编排器自动激活 monitor-integration；没提"新建模块"→ scaffold-generator 直接跳过。

就这么朴素，但有效。

4. 实战：给图片上传做个"瘦身"

4.1 需求一句话，改起来要命

需求原文：“销量上报，图片上传到服务器之前，前端先压缩再传。”

编排器一看：要改现有组件，典型的存量修改，走流程 B。三个 Phase：分析评估 → 编写代码 → 验证提交。

4.2 先摸清这刀下去切到谁

第一个 Skill 上场：impact-analysis。自动做了三件事：向上追溯谁在调用我、向下追溯我依赖了谁、横向扫描谁跟我共用 API。

结论：修改完全封闭在 uploadComponent.vue 内部。三个关联文件，全部无影响。这一刻，悬着的心放下了一半。

就冲这个结论，我决定今天不骂产品经理了（也就今天）。

4.3 规则先谈清楚，边界值问明白

第二个 Skill：processing-principles。它抛出了两个直击灵魂的问题：

• “恰好 3MB 算哪边？” → 不压缩。
• “压缩失败要不要提示用户？” → 不提示，静默降级。

别小看这两个问题。恰好 3MB、恰好 10MB 这种边界，平时没人问，上线了一定会出现。就像考试 59 分和 60 分，就一分之差，命运完全不一样——一个补考，一个庆功。

最终沉淀出 6 条编码级规则：

4.4 最小侵入：就改一个变量名

第三个 Skill：minimal-invasion。它读完目标函数，画了个分支图：

uploadFileToServer(file)
├─ if (Array) ── 批量上传
│ └─ forEach → FormData.append → 调接口
└─ else ── 单文件上传
└─ FormData.append → 调接口

然后从 5 种集成策略里挑了两种组合：入口守卫（10MB 快速失败）+ 前置处理（FormData 构建前压缩）。

实际改动就一处：

// 改之前
formData.append("file", item.file);
// 改之后
const processedFile = await this.processFileWithCompress(item.file);
formData.append("file", processedFile);

就一个变量名的事。原有的上传、回调、loading、save，一行没动。

什么叫最小侵入？就是你在客厅换了个灯泡，卧室的人压根不知道你来过。

4.5 永远 resolve 的 Promise

核心工具函数来了。它的设计哲学只有一个：永远 resolve，永不 reject。

export function compressImage(file, callbacks = {}) {
return new Promise((resolve) => {
new Compressor(file, {
quality: 0.8,
success(result) {
callbacks.onSuccess?.({ duration, originalSize, compressedSize, savedRatio });
resolve(compressedFile); // Promise 通道：返回压缩结果
},
error(err) {
callbacks.onFail?.({ duration, error: err.message });
resolve(file); // 关键：失败也 resolve，不 reject！
}
});
});
}

压缩失败？resolve 原文件。调用方完全不需要 try/catch，零分支，零心智负担。

这叫什么？这叫"渣男式承诺"——但这次是好的那种：不管成不成，我一定给你回个话。绝不让你干等着，也绝不让你接不住。

• 压缩成功 → 上传压缩后的文件
• 压缩失败 → 上传原文件
• 调用方代码完全一致，一个 if 都不用加

4.6 埋点和国际化：两个小跟班

因为规则第 5 条写了"要埋点"，编排器自动唤醒了 monitor-integration。它扫描了现有的 20 多个埋点函数，照着命名规范，在文件末尾追加了新的埋点函数，风格跟老函数一模一样——混进去根本看不出来是后加的。

重点是解耦。压缩工具函数不依赖任何埋点库，通过回调暴露钩子，埋点逻辑留在业务层：

compressImage(file, {
onSuccess: (data) => report_imageCompress({ status: 'success', …data }),
onFail: (data) => report_imageCompress({ status: 'fail', …data })
});

工具函数干干净净，谁都能复用；要不要监控、怎么监控，调用方说了算。

i18n 那边同理：检测到硬编码的 Toast 文案，自动去词条库注册，用户看得见的字，绝不写死在代码里。毕竟，谁也不想某天因为一句中文文案，被海外用户截图挂墙。

4.7 回归用例 + CR 自查：提交前的双保险

regression-cases 自动生成了 13 条回归用例，按 P0/P1/P2 分级：核心路径、交叉场景、边界值全覆盖。

cr-self-check 逐项扫完所有改动文件：16 项通过，2 项需关注（监控 ruleId 是占位符待替换、forEach 改成 for…of 后批量上传从并发变串行，上传可能变慢，需要确认）。

回归用例这东西，就像给老功能立遗嘱——不是盼它出事，而是真出了事，你知道该查哪里，不用在代码里大海捞针。

5. 数据说话：202 行搞定

最后上账本：

• 3 个 Phase、7 个 Skill 执行（智能跳过 2 个）
• 6 条处理原则、13 条回归用例、CR 自查通过
• 5 个文件：1 个新增（压缩工具函数）+ 4 个修改，合计 +202 行
• 影响面封闭在 1 个组件内，API/Store 层零变更
• 压缩失败不阻断原流程，埋点与逻辑解耦

202 行，听着不少？但你想想，这 202 行换来了：完整的风险分析、明确的规则、可量化的监控、全套的回归保障。这笔买卖，血赚。

6. 六条原则，帮你少踩坑

最后把这次实战里沉淀的原则交代清楚，每条都附一个"没有它会怎样"：

• **1. 单一职责：**做螺丝刀，不做瑞士军刀。Skill 拆得够细，才能按需组合、单独跳过。一个万能工具，改一次调试一次，谁受得了。
• **2. 接力模式：**上游的输出就是下游的输入。别让每个 Skill 都重新分析一遍代码，浪费 token 不说，还可能得出互相打架的结论。
• **3. 有依赖串行，无依赖并行：**Phase 1 三个分析 Skill 有严格依赖，必须串行；Phase 3 两个验证 Skill 没依赖，直接并行。该排队的排队，该超车的超车。
• **4. 智能跳过：**不是每个 Skill 都要跑。增量需求也去走"影响分析→处理原则→最小侵入"，那不是走流程，那是走形式。
• **5. 关门机制：**每个阶段结束都有一道确认门。AI 一口气写完 200 行你才发现方向错了，那返工成本，够你加一个月的班。
• **6. 可拆可组：**流水线是"建议"，不是"强制"。只想加个埋点？单独调 monitor-integration 就行，不必惊动整个编排器。

最后说句掏心窝子的：AI 能写代码这件事，已经不稀奇了。真正值钱的，是把 AI 的能力编排成一条可复用的流水线，让"做得对"从一种运气，变成一种习惯。

改存量代码，就像拆一个还插着电的插座——手要稳，眼要准，动作要小。手里有流程，心里就不慌。

散装AI的时代，该过去了。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548