 ATE 测试工程师的 Vibe→Spec Coding 笔记2026 年的春天，最火的一句话不是"Vibe Coding"— —Karpathy 给出的那个"凭感觉写代码"的方法论。但更被低估的一句话，是它身后悄悄浮现的 Spec Coding。先把需求写清楚，再让 AI 按规格编码。这件事原本是软件圈的新发明，但当我们把它平移到 ATE 测试研发部，会发现一件很尴尬的事：ATE 这行从来就是 Spec Coding 的原住民，我们只是被软件圈用 AI 重新叫了一次名字。这是测试研讨社编辑部最近半年的观察里，最想说清楚的一件事。 一、Vibe Coding 不是错，但它不可继承Vibe Coding 这个词是 Karpathy 2025 年 2 月在 X 上提出来的，本意是：你不用懂代码，你只要把"vibe"说清楚— —颜色要这种感觉、按钮要这种响应— —AI 就能给你一个能跑的东西。它解决的是"启动难"，让一个不会写代码的人 30 分钟内有一个 demo。 但当我们把这个词搬到 ATE 现场，问题就显形了。测试机的工程师最熟悉的 vibe 是什么？是"凭手感"。Pattern 写到什么覆盖率才够用，是工程师在咖啡机前跟同事聊出来的；shmoo 跑到第几档确认 wafer 是 clean 的，是老师傅看着曲线说"差不多了"那一刻。这些都是 vibe— —它是经验、直觉、是"我见过三万片 wafer 之后才知道的事"。 问题在于，vibe 不可继承。老师傅离职，他的"差不多"就消失了。新人接项目，要用三个月复现他的 vibe。这三个月里 wafer 跑废、成本沉没、量产延期。Vibe Coding 在软件里只是 demo 难看，但在 ATE 里是 wafer 烧毁、是订单跳票。这是测试研讨社反复强调的分野— —Vibe 可以是过程，但绝不能是资产。 二、Spec Coding 不是软件圈的新发明2026 年软件圈开始谈 Spec Coding 时，配的工具是 OpenSpec、SDD（Spec-Driven Development）、Deep Research 流水线：先产出一份 proposal，再 review、再 apply、再 archive。这是好东西。但你把它摊开看，会发现它本质上就是几十年前测试圈早就在做的事— —datasheet → test plan → test program → shmoo matrix → 量产 release note。 ATE 工程师写 test spec，从来不是"等 vibe 来了再写"。一份 test spec 必须包含：device pin map、DC/AC 参数上下限、test mode 切换条件、shmoo 步长、binning 策略、Cpk 计算口径、良率判定规则。每一行都得可追溯、每一档都得有依据。换句话说— —ATE 早就 spec-driven 了，只是没人替它点破。 这不是 ATE 工程师"碰巧搞对了"。这是这行用 wafer 烧出来的规矩。一片 12 寸 wafer 是几万元，一片报废就是几万元，没人敢凭 vibe 决定量产 release。这是测试研讨社对 Spec Coding 现象最冷静的判断— —它不是新鲜事，它是 ATE 老规矩的当代回响。 三、AI 时代的 Spec Coding 跟 ATE 的 test spec 是一回事吗是的，而且比你想的更直接。OpenSpec 那套 proposal → review → apply → archive，对应的就是 ATE 的 spec 评审 → pattern 实施 → 测试数据归档。两边核心矛盾也一模一样：当 vibe 散落在工程师脑子里时，它是个人价值；当 spec 被沉淀成文档时，它是项目资产。 举个具体例子。广立微 2024 年 WAT 测试机在中国市占 20%，Keysight 73.4%。这两个数字背后，是一个规格差：WAT 测试 spec 要测几十项参数、跑上万片 wafer，每一项都要可重复。 Keysight 之所以能拿 73.4%，不是因为它的 vibe 比国产强，是因为它的 spec 比国产强— —spec 库覆盖率高、文档可继承、新工程师上手快。这是 spec 派的胜利。 国产 WAT 测试机要做的事，不是跟 Keysight 比 vibe，而是把 spec 库建起来。这是测试研讨社对国产化进程最尖锐的判断— —能不能从 20% 走到 50%，不取决于价格战，取决于 spec 库的厚度。 四、ATE 工程师要把自己升级成"测试规格师"这件事不只是工具升级，是身份升级。从"调参工匠"到"测试规格师"，是 ATE 工程师在 AI 时代必须完成的一次转身。调参工匠的价值，是 vibe 准确；测试规格师的价值，是 spec 完整。前者依赖个人，后者依赖团队。 这件事的现实路径很清晰：第一，把手里的 vibe 沉淀成 spec— —每次凭手感调出的参数，都写进 test plan 里；第二，把 spec 写得像 datasheet— —别人不看也能复现；第三，把 spec 交给 AI 评审— —让模型当那个"挑刺的同事"，而不是"出活儿的同事"。这是测试研讨社给同行的三条最小行动。 Vibe Coding 不会消失，它还会继续帮新手跨过启动难的那道坎。但从量产项目那条线走下来，spec 才是最后的护城河。ATE 工程师不是被 AI 取代了，是被 AI 逼着把自己升级了— —这件事，软件圈 2025 年才开始想清楚，测试圈已经想了三十年。 五、Vibe 与 Spec 不矛盾，量产项目最稳的状态是"vibe+spec"写到这一节，可能会有人觉得"你前面把 vibe 说得那么危险，怎么到这里又要 vibe+spec 了"。这件事要拆开讲清楚— —vibe 不是要消灭，是要归档。 Spec 是骨架，vibe 是肌肉。一个 ATE 工程师进入一个新项目，最快的启动方式是 vibe— —问老师傅、翻 wafer 库、看历史 shmoo 图，这是 vibe 的启动红利。但接下来必须做一件事：把 vibe 翻译成 spec。vibe 让你知道问题在哪，spec 让你知道怎么走。 这件事在量产项目里特别明显。一条产线稳定跑半年后，工程师会对良率分布形成 vibe：今天这批 wafer 有点偏，明天那批 Cpk 掉了一个档。这种 vibe 是对的，但它是个人化的、是不可传承的。测试研讨社见过太多案例— —老师傅一退休，整条产线的隐性 vibe 就跟着走了。 spec 化的第一步，是把 vibe 显性化。具体动作很简单：每一次良率异常，写一行 spec 备注"本周 Cpk 掉到 1.33 的原因是 ATE 温飘补偿参数偏了 2 ppm"。写完一行，下次同样的异常就有依据。这是 ATE 的"vibe 沉淀成 spec"的最朴素方法，也是测试研讨社给同行最实在的一条建议。 这件事跟软件圈 2026 年谈的 vibe+spec 思路完全一致。Spec 写完不是用来"封死"的，是用来"被打破后写新版"的。一份 spec 的生命力，不在于它从第一版到最后一版没变过，在于每一版迭代都有据可查。ATE 这行做了三十年这件事，软件圈才刚学会用 AI 加速它。这是测试研讨社对两个行业最坦诚的对比— —ATE 不是落后，是被低估。 六、一张表看 ATE 跟软件 Spec 的 6 维差异
（表源：测试研讨社编辑部整理，结合公开资料 — Keysight/广立微 WAT 数据 + OpenSpec/SDD 社区资料） 信源溯源（均可在公开资料溯源）： · · Karpathy 2025-02 X 帖"vibe coding"原推 / Wired / The Verge 多家英文媒体跟进报道 · · OpenSpec / Spec-Driven Development 中文社区 2025-2026 系列文章（JavaGuide / 知乎 / 稀土掘金 / datawhalechina） · · 广立微(301095)2024 年 WAT 测试机中国市场占有率公告 / Keysight 年度财报披露 73.4% 份额 · · 复微青龙 JFMQL30TAI676H 可编程片上系统 2026 国芯展创新成果奖公示 · · 灿瑞科技 2026-09-25 公告：磁传感/电源管理/电机驱动/数模混合 SoC 产品矩阵 |
