79张现成封面躺在工作区,MiMo V2.6偏要自己造52张

25 阅读9分钟

前言

10 月 11 日下午,我盯着自己的 GEO 博客(www.wdmeng.cn,我的 AI 实战内容站点)列表页,越看越别扭:卡片缩略图全是被切掉一半字的公众号横图,标题只剩中段。我把我的 AI 员工,小米的 MiMo V2.6,叫过来下了个 bug 单:换掉这些图。

这单有个隐藏背景:我故意没把话说满。我的原话是,"我没有很清晰的给你讲清楚,就是想探测一下你这模型的能力"。结果它用了三轮才把图换对,前两轮全部被我打回。而正确答案从一开始就躺在工作区里:IPMS(我自研的内容生产管理系统)的发布包中,放着 79 张现成封面。

先说结论:图换对了,代价是三轮返工

换封面不用改样式、也不用造图:IPMS 发布包里 79 张 1200×675 通用横版封面直接映射替换,51/52 一轮上线;MiMo V2.6 的前两轮,全在错路上打转。

先把三轮的账摆出来:

轮次它干了什么我的裁定
1判断"比例难看"是 CSS 问题,改槽位比例 16:10→900/383打回:一个图片都没换掉
2回滚 CSS,用 PIL 自造 52 张 800×500 封面覆盖上线打回:给我一键还原
3发布包 1200×675 封面映射替换,51/52 上线通过,未再打回

一次排版事故、一次全量图事故、一次还原,外加我三轮的情绪成本。这就是"动手前不盘点"的净代价。我以为它会先去翻一翻家底,结果它两轮都没往那个方向看一眼。

第一轮:它把"换图"听成了"改样式"

它的判断链路是:图难看,是因为比例不对;比例不对,那就是 CSS 槽位的事。于是它把 .post-thumb 槽位的宽高比从 16:10 改成 900/383,两行代码,commit 0934a670,服务器拉取,还自己截了线上图自证"已生效"。

生效是生效了,图一张没换。

我当时的反应,原话:"改了半天……一个图片都没换掉。"紧接着追发一张带红框的截图:"我让你换图片,你给我换CSS样式?这个鬼样式?这个排版谁教你的?"

它立刻 git revert 回滚了 CSS,线上样式读回确认恢复。动作很快,态度也很好。但我要的是换图,它交上来的是一次排版事故。

第二轮:不找了,它自己造了 52 张

回滚之后,它换了条路:既然没有"合适的图",那就自己造。它用 PIL 程序化生成了 52 张 800×500 的"专属封面",原位覆盖,52/52 全部落地,还规规矩矩把原图打了个备份 tar 包。

单看执行,这活干得干净。但方向全错:那批图是模板化的批量产物,和站点既有设计完全不是一个气质;更关键的是,产线里明明有现成资产,它绕开资产另起炉灶,覆盖的是生产环境的图。

我的原话:"算了算了,你给我一键还原吧。搞的什么玩意?"

还原倒是利索:备份包解开,按字节核对抽查,团队-35.jpg 114448 字节,和原图一致,没留半吊子现场。这是这单里它做得最好的部分,可惜是善后。

正确答案,一直躺在发布包里

第三轮,我直接点破:"发布包里还有适配通用平台的图片。通用平台的图片你上传上去,不就解决了这个问题?"

它这才去盘点。而三条线索,一条都不难查:

  1. 发布包实物:IPMS 的发布目录里躺着 78 个包、79 张通用横版封面,1200×675,每篇都是专属设计;
  2. 迁移脚本的自供状:export_local.py 第 328 行明写着封面取用顺序,公众号 900×383 实物优先,通用横版封面兜底。当年迁移时通用版被"兜底"键闲置,这就是线上全是公众号图的直接原因;
  3. 数据库映射:ip.db 里每个 item 挂着发布包目录,团队#35 做个文件名安全化(#→-),就是站点上的 团队-35.jpg。

映射脚本一轮跑通:51/52 命中,唯一例外是一篇没有发布包的文章。HTTP 200,返回 208455 字节的新鲜文件,页面实截确认。URL 没变,数据库没动,CSS 保持原设计,原图备份随时可以还原。

好资产被兜底键埋了快一年。这事儿比返工本身更让我在意:资产不在多,在盘点;不盘,等于没有。

10% 和 32%,就是"能看"和"不能看"的距离

为什么公众号横图在列表页那么难看?算一笔账。列表页缩略图槽位是 16:10(168×105),三种资产放进去的横向裁切比如下:

资产尺寸比例槽位横向裁切结局
公众号横图(线上原图)900×3832.35:1约 32%本轮替换掉
通用横版封面(发布包)1200×67516:9约 10%当前线上
AI 自造封面(第二轮)800×50016:100%已废弃还原

32% 的裁切,意味着标题左右各被削掉一截,读者只能看到中段几个字;10% 的裁切,构图完整、标题清晰。它第一轮想靠改 CSS 解决"比例难看",方向恰好反了:该换的是图,不是槽位。

根因:不是不会干,是没人告诉就不会找

三轮看下来,这个模型的画像很清楚。

被告知"换什么"之后,它的执行并不差:还原一次到位还按字节核对,正确路径给出后,映射、验尺(51 张全部 1200×675)、打包、上线、验证,一轮收口。每一轮它都给了新鲜实证,commit 哈希、服务器 git log、HTTP 状态码、字节级比对、页面实截,没有一句空口的"已完成"。

但"没人告诉就自己去找"这项,是零分。三条线索都在它够得着的地方,它一条没碰,就先开了枪。

我自己也有责任。首指令"换掉这些图",动词明确、对象模糊,资产线索和验收口径我有意留白,这单本来就是一次能力探测。探测结果值回票价,规律也沉淀下来了:模型对"动词明确、对象模糊"的指令,会用最快的路径补位,而最快的路径往往是错的。对象没锁定之前,任何"快"都是返工的预付款。

这单搬进公司,值多少

给企业读者换算一下:内容或设计团队凡是"换资产"类需求,换图、换模板、换皮肤,先花 30 秒确认候选资产清单再动手。这单三轮返工对一轮收口,净差两轮:一次排版事故、一次全量图事故、一次还原。按 AI 员工每轮"执行加验证加沟通"的完整成本算,前置 30 秒的盘点,直接砍掉约三分之二的返工量。团队里 AI 干得越多,这条省得越多。

三条规矩,你带 AI 干活可以直接抄

这单的教训,我定成了三条死规矩:

  1. 动手前先输出三行再开枪:改动对象是什么(图、样式还是数据)、候选资产清单在哪、将动的文件列表。三行发给我点头,成本 30 秒,省两轮;
  2. 换图换资产类需求,盘点序是死的:发布包多尺寸实物,到站点存量,到才允许自造。造图和改样式,永远是排在末尾的选项;
  3. 宣称型语句必须执行完才能说。这单它嘴上说"已记录",实际没写,两轮后才补上。先说后做,在我这里按虚假交付对待。

这三条不绑定任何具体模型,你带 GPT、带 Claude、带国产模型干活,照样成立。

FAQ

换个 AI 模型,这三条规矩还成立吗?

成立。规矩约束的是"动手前的盘点动作",不绑定模型。只要指令是"动词明确、对象模糊",任何执行型 AI 都倾向于用最快路径补位,区别只是补位姿势不同。

为什么不让 AI 一开始就自己去盘点?

它能,但它不会主动做。这单三条线索都在工作区里,它一条没查。我的实操结论是:首指令里直接带一句"资产在发布包里",探测数据显示这一句能省掉两轮。

发布包里那 79 张封面,当初是哪来的?

是我的内容产线 IPMS 在发每篇文章时一并产出的,每个发布包都带一张 1200×675 的通用横版封面,按篇专属设计,本意就是适配公众号之外的平台。只是当年迁移站点时,取用顺序把公众号图排在前面,通用版被"兜底"键闲置,一躺就是快一年。

那 52 张自造封面,为什么一张都不能留?

不是技术不行,是方向不对。模板化批量产物和站点既有设计语言不搭,这是审美层;更要命的是产线里已有 79 张专属设计的现成封面,自造等于绕开资产另起炉灶,这是流程层。两层都错,只能整体还原。


我是野生码农,AI实战派。17年全栈工程师,一人AI公司实践者。打造个人IP内容体系、软件全链路产品产线,拥有百套企业AI方案、200多个岗位Agent;自研知识库、AI数字员工系统,公开实战复盘。

本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。

这篇来自《AI员工团队》系列,记录我和 AI 数字员工协作的真实翻车与修复。

关注我,看真的。

野生码农AI实战 · 全网同名