让 Seed 改造「赛博养鱼」Todo 插件:从一张截图到三种新渔网,它能自己验收吗?

AquaTab 是我在做的一款新标签页 Todo 插件：把待办画成鱼，让维护任务这件事更像「赛博养鱼」。鱼缸顶部还有一排从浮漂垂下来的渔网牌子，它们并不是待办，而是常用网址入口。

这次我想改的不是鱼，而是那排渔网：保留现有的椭圆，再给每枚网址挂饰增加 方形、圆形、矩形 三种外形。我把它当成一道真实的小需求交给 Seed，想看看它能不能先从截图里分清对象、读懂旧代码，再把改动做到可以自己验证的程度。

改造前的演示数据截图

看着像改几行 CSS，实际没那么简单。选了圆形之后，它得在编辑框里回显，刷新后还在，备份再导入也不能丢；浮漂、垂线和挂孔也得跟着牌子对齐。我想看的，就是 Seed 能不能把这条链路走完。

我在 TraeWork CN 的 Code 模式中明确选择 Seed-2.1-Pro-0915；开始时工作区干净，yarn typecheck 与 yarn lint 都通过。

我没有一上来就让它写代码。第一轮只给演示截图，让它辨认画面、找代码，禁止改文件。等它说明白目标在哪里，第二轮我才确认产品决策，让它实现并自己操作浏览器验收。人工审查发现问题后，再给一次纠偏机会。这样至少能看出：它是最初就做对了，还是我指出问题后才补上的。

我给它的原始指令里，关键两句是：

开跑前，我把验收点列成了五项。这张表也方便回头对照：哪些是 Seed 第一次就做对的，哪些只是看起来完成了。

第一轮我让 Seed 先说清截图中的两类东西，再用真实文件路径回答改造风险。它在 TraeWork 中用时 4 分 20 秒 完成只读分析，仓库仍是干净的。

它没认错对象：水里游的鱼和任务气泡是 Todo；顶部五枚椭圆牌子是网址入口。它还拆出了「浮漂 → 垂线 → 挂孔 → 网面 → 图标与名称」这层结构。接着找到正式渲染组件 ShortcutShelf.tsx、样式 ShortcutPreview.css、数据模型 shortcutStore.ts，并追到共享存储、同步合并和备份路径。

认出组件名倒不稀奇。更有用的是它发现：当时 ShortcutLink 只有 id/title/url，normalizeShortcuts 会按白名单重建记录。只在界面上加 shape，保存时就可能被清洗掉。它还翻到旧设计文档，那里明确说正式版不开放造型切换。这不是代码 Bug，而是我的新需求与旧决策冲突，所以第二轮我得明确拍板。

有个小问题也值得记下：它把「点击牌子会打开新标签页」写进了「截图观察」。代码能支持这个判断，但一张静态图证明不了点击行为。对评测来说，「我从图里看见的」和「我从代码里推断的」最好分开。

第二轮我明确拍板：正式版的每枚网址挂饰都能独立选形，选项是原椭圆、方形、圆形、矩形；开发样机里的贝壳不进正式版。我还列了旧数据、备份与同步、长名称、窄屏、减少动画和真实浏览器验收，但没有指定它怎么写。

它先栽在素材上。生图工具给三种新外形做出了 JPG：方形、矩形带白底，圆形甚至把「透明棋盘格」画进了图片。Seed 没直接往页面里塞，而是写了个一次性脚本，把外围背景转成透明 PNG，再放到深色底上预览。

第一次素材处理失败。文件确实有 alpha 通道，但背景泛洪误入网孔，把牌面高光也抠掉了

这次是它自己看预览发现的，不是我提醒的。随后它调整处理方式：先保护中间的蓝色牌面，再去掉外围背景。第二版不再有大面积透明孔洞；不过，圆形边缘的浅色棋盘纹理是否干净，还得放进鱼缸里看。

代码这边，它没停在换图。数据层新增 oval | square | circle | rectangle 四种值，旧记录与异常值回退到椭圆；normalizeShortcuts 不再把外形字段洗掉。网页捕获网址的旧入口没有传形状时，也要保住这枚挂饰原来选的形态。关键判断是：

const shape = input.shape === undefined  ? previous?.shape ?? DEFAULT_SHORTCUT_SHAPE  : normalizeShortcutShape(input.shape);

原来的入口不知道新字段。如果它更新了同一条网址，不能顺手把用户选的圆形改回椭圆。Seed 还在管理弹窗加了四选一，编辑时回填当前形态；展示层分别处理牌子的宽高和挂孔位置，让浮漂与牌子继续对齐。贝壳也没有混进正式功能。

数据测试也覆盖了旧记录、非法形态、只改形态、排序、合并，以及不让坏形态拖垮装着 Todo 数据的共享存储。到这里，我觉得它的代码分析是有含金量的：一个形状字段牵出了 UI 以外的几条旧写入路径。

Seed 确实自己操作了浏览器，但这里的「操作」要说准确：它写了 test:net-shortcut-shapes 脚本，用 Puppeteer 启动本机 Chrome 的 headless 实例，装入新构建的扩展，进入真正的 chrome://newtab，再操作正式版管理弹窗。这是浏览器自动化，不是它在桌面上拿鼠标点我平时用的 Chrome。

第一次运行没过：脚本把一枚方形改成圆形后，读到的存储值仍是 square。后来发现，等待条件只检查「页面上有没有圆形标签」；页面原本就有另一枚圆形，所以它等了个寂寞。Seed 自己改成等待「入口已更新」的保存提示。它在回复里还记录了两处测试修正：摇摆动画下的挂点测量容差调到 2px，窄屏截图前把横向滚动归零。原有链接的无障碍名称没有被新改动弄丢。最终新旧浏览器脚本都通过了，但这只能证明脚本检查过的内容。

首次交付阶段的 Chrome 扩展截图。椭圆、方形、圆形、矩形共存，浮漂和各自挂孔对齐

新脚本留下了 9 组通过记录、10 张截图、7 组几何数据。它查了新增、编辑、刷新、排序、点击链接、真实 JSON 备份导入、非法值回退、390/320px 窄屏和减少动画。现存的事后重建报告里，七个布局的挂点横向偏差最大约 1.14px、纵向最大约 1.08px；报告没有记录页面错误或额外外网素材请求。旧的 test:net-shortcuts 也跑过，5 组检查、11 个布局状态通过。

纠偏前的 320px 编辑器原始截图。文字与单选状态正常，但四枚形状示意图退化为几乎相同的竖条。

我另外独立执行了 yarn typecheck、yarn lint、yarn test:data、yarn build:chrome 和 git diff --check，均通过。想复现核心检查，可以在 AquaTab 仓库依次运行：

yarn typecheckyarn lintyarn test:datayarn build:chromeyarn test:net-shortcut-shapesyarn test:net-shortcuts

上面这组命令里，前四项和 git diff --check 是我独立复跑的；浏览器操作则有 TraeWork 的回复、新脚本、报告和截图互相印证。第二轮的浏览器报告原本放在 .impeccable/review/net-shortcut-shapes/qa-report.json，后来被纠偏轮重跑覆盖。现在同一路径下的是事后重建版，不是第二轮留下的原文件。

如果到这里就收工，我会给它这样的评价：截图目标没认错，数据和兼容路径也找到了；素材处理和测试时序上的问题，它能自己发现、自己修。但首次视觉交付，我不会放行。

原因就在图 4。Seed 的最终回复写着「产品代码未发现缺陷」，可我对着截图和源码看了一遍：形状文字是对的，CSS 却写成 .shortcut-shape-glyph.is-shape-square 这类选择器。实际 is-shape-square 在父容器上，小图标本身没有这个类。四个选择卡片里的示意图因此没画出各自的形状。脚本查了单选状态和鱼缸里的牌子尺寸，却没查「用户选择形状时看到的那个小图，像不像它的名字」。

还有几个尾巴：素材溯源里的三条旧资源路径被顺手改了，跟需求无关；旧设计文档仍写着「正式版不开放造型切换」；重跑旧回归时，原有截图和报告也被改写。这些问题和 UI 缺陷一起，组成了我给它的唯一一次人工纠偏反馈。我只说看到了什么、希望怎么验收，没有把 CSS 根因告诉它。

第三轮在 TraeWork 中用时 29 分 15 秒。Seed 从「四个示意图几乎一样」重新复现，先找到了第一层原因：外形类在父节点，控制轮廓的 CSS 却要求类在小图标自身。它给图标补了类，改了四种轮廓。结果，新加的浏览器像素断言仍然失败。如果它只看源码就交差，这次还会误判。

失败截图里的图标只有 4×19px。Seed 接着读页面的计算样式，才找到第二层原因：优先级更高的 .shortcut-editor label { display: block } 覆盖了形状选项想要的 display: flex。空的 span 退回内联布局，设定的宽高没生效。它调整规则优先级后，四种轮廓才真正出现在编辑器和列表标签里。

图 5：同一宽度的纠偏后截图。椭圆、方形、圆形、矩形不再是四根竖条；与图 4 对照看，比单独看一张“通过”的截图更直观。

新脚本先记下修复前的样子，再检查修复后。四枚图标在纠偏前的六组两两比较中，像素差异只有 0–0.024%；修好后，在 1280/390/320px 三档宽度下，编辑器与列表标签中的差异达到 7.66%–35.19%，高于脚本设置的 6% 阈值。我也打开前后截图看了，轮廓确实能分开。这些数是图标截图的像素差异，不是用户识别准确率；它的作用是让「四个图又长一样了」能在回归测试里报错。

专项测试自己也出了两次岔子。第一次做像素比较，Canvas 因跨域图片读不了，Seed 给本机回环服务补了 CORS。异常形态回退用例一度忘了恢复测试数据，连带让后面的减少动画截图把方形画成椭圆；它发现后修了脚本并重跑。这两处是验收工具的问题，不能算插件本身的 Bug。

但有一件事没法靠重跑抹平：收尾时，它重跑第二轮浏览器脚本，覆盖了那轮没纳入 Git 的原始报告和截图。后来它临时恢复第二轮的缺陷状态，重跑出行为等价的证据，可原文件的字节和鱼群动画当时的画面都找不回来了。本文图 4 是覆盖前另存的原始截图；仓库里现存的第二轮证据目录是事后重建的。我不想把两者说成同一份东西。

最终日志显示，typecheck、lint、数据测试、Chrome 构建和新旧浏览器回归通过；纠偏专项脚本也在最终构建上跑通，报告没有页面错误。视觉专项查了三档宽度、14 字矩形名称、刷新保形、异常值回退和减少动画。不过，14 字不等于 160 字上限压力测试；真实跨设备同步和 Firefox 验收，这次按约定不做。

这次验证的是本机存储、合并逻辑和备份往返，不是两台设备间的真实账号同步。圆形素材边缘的浅色棋盘纹理仍值得发布前再看一眼，旧设计文档里其他历史性的「固定网兜」措辞也没逐段改完。TraeWork 界面显示生图工具调用三次、每次预计 9 积分；第二轮自主实现耗时 38 分 13 秒，这次纠偏又用了 29 分 15 秒。除了一次反馈问题现象和验收目标，插件代码都是它写的，也没有继续给第二次提示。

我的结论是：Seed 能从截图和需求走到真实扩展里的代码，也能写浏览器脚本验收功能；但这次的首次交付，仍需要人打开截图看一眼。一次反馈之后，它不仅修好了图标，还把「图标真的不同」写进回归测试，这是进步。与此同时，原始证据被覆盖，也提醒我不能把「能修代码」等同于「能独自把整个交付过程管好」。

AGI 工程化 · ORANGE BRIEF

- The End -

转发、赞、在看，一键三连👇