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 条编码级规则:

#原则规则
1触发阈值>3MB 压缩,≤3MB 直接上传
2大小上限>10MB 拒绝上传,Toast 提示
3失败降级压缩异常 → 静默上传原文件
4用户感知压缩失败不提示,对用户完全透明
5埋点监控成功/失败状态 + 压缩耗时
6接口兼容props/emit/API 一个不变

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

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐