vibe-killer

Vibe Killer

有人输入了一条提示词，得到一个网页。页面有紫色渐变的 主视觉区、三个带表情符号的小圆角方块卡片，还有 400 行世界上独一无二的 CSS。 页面看起来不错。但它也走进了死胡同： 组织里的任何人都无法维护它、为它换主题、审计它，或复用其中哪怕一个像素。

这个技能会将页面改用你的设计系统重建，让它不再孤立无援，而是成为基础设施的一部分。内容不变，作用不变，运行在团队已经维护的组件上。

重点不在于整洁。基于你的系统构建的页面，可以继承其背后的所有投入：主题、无障碍工作、设计令牌、 浏览器支持，以及修复 bug 的唯一渠道。凭感觉编写的页面什么也继承不了，却要你永远维护它。

这不是什么

• 不是 ds-adoption-plan。 它会为整个产品的迁移制定预算和时间表。这个技能会立即转换单个页面，并交付可运行的代码。
• 不是 product-inspection。 它会在十个环节评估已发布的产品。这个技能则是一套单一流程，只有一个交付成果。
• 不是代码检查工具。 它不会只报告原始页面的问题，然后就此打住。每次运行都会以转换后的页面结束，或者诚实说明为何无法生成页面。

基本原则

1. 绝不凭空捏造组件、属性、插槽或令牌。 输出中的每个名称都来自系统自己的目录。如果你想用的是凭记忆想起来的内容，就停下来查阅目录。大多数组件库会静默丢弃投射到不存在的插槽名称中的内容，这意味着页面会渲染为空，且不会报错，你也不会发现问题，直到别人指出来。
2. 证据标签要始终随附。 [verified] 表示你从系统目录、MCP、清单、代码库或文档中读到了相关信息，并能指出具体行。[reported] 表示信息由人提供。主要依据 [reported] 名称完成的转换仍然值得做，只需在回执顶部注明这一点。
3. 目标是不使用任何自定义 CSS，差距本身就是发现。 不要添加自定义类、硬编码颜色或间距、字体声明，也不要添加指向 Google Fonts 的 <link>。如果系统确实无法满足某项需求，那就是一个系统缺口：在回执中写明，向上游提出改进建议，并在代码中清楚标记占位内容。悄悄手写组件是唯一会让整个工作失去意义的失败方式。
4. 转换页面的功能，而不是外观。 一个视觉线索能揭示意图。页面顶部的渐变色带意味着“这是入口”，入口对应的是主视觉区或页面标题。渐变本身不是要求，只是模型默认审美留下的产物。解读指南见 reference/THE-TELLS.md。系统侧也是如此：映射到能完成任务的组件，而不是碰巧看起来相似的组件。标题上方的一小行文字看起来像徽章，实际上是文本。
5. 内容至关重要，装饰则不然。 绝不要为了让转换更简单而改写页面文案，也不要因为某个版块难以映射就删掉它。如果某些文案本身带有 AI 生成的痕迹，在回执中指出，让人来决定。这是他们的事，不是你的事。
6. 在转换过程中修复无障碍问题。 氛围编程生成的页面在这方面通常很糟糕：用 div 充当按钮、跳过标题级别、使用 outline: none、图片没有替代文本、从未检查对比度。既然你要重建标记，就要把它正确地重建。每项修复都要写入回执，因为这是最能证明此次转换物有所值的证据之一。
7. 从未渲染过的页面只是一个说法，不是结果。 执行第 4 阶段的检查。如果你无法渲染或验证，就在回执中如实说明，而不要暗示页面能够正常运行。你从未看过的区域也只是一个说法。即使验证器结果正常，DOM 检查也显示所有插槽都已填充，人们仍可能在几秒内否定这个页面。
8. 绝不羞辱任何人。 有人做出了一个东西，而创造东西是好事。原页面并不愚蠢，提示它的人也不愚蠢。回执只报告数量和事实，绝不挖苦。

设计系统：证据链

此技能不依赖特定设计系统。沿着这条链找到系统的组件目录，使用任何现有资源。绝不要求使用特定厂商的产品。

1. 系统自带的 MCP 服务或 CLI。 如果它提供组件查找、搜索、组合或验证工具，每次运行都使用它们。这是唯一能让映射标记为 [verified] 的来源，也是唯一能自行保持最新的来源。
2. 机器可读的导出文件。 custom-elements.json、组件清单、token JSON、Storybook index.json。请用户指出文件位置。
3. 代码仓库。 如果系统的源代码在磁盘上或可以访问，就读取组件文件。速度较慢，但完全权威。
4. 文档站点。 组件页面包含 API 和使用指南。留意内容是否过时；已发布的文档通常落后于已发布的版本。
5. 设计库。 它对于了解系统包含哪些内容以及设计侧的命名具有权威性，但不适用于代码 API。在 Figma 中标为 Primary 的变体，并不能说明属性名是 variant 还是 appearance。reference/FIGMA-ACCESS.md 介绍了如何访问设计库。
6. 访谈。 直接询问。将所有收到的信息标记为 [reported]。

不仅要检查名称，还要查看禁用事项。 名称看似最合适的组件往往并不适用；好的目录会在自己的指南中说明这一点。在确定映射之前，先阅读目标组件的禁用说明和无障碍说明。

然后也要把这些指南视为一种说法。 目录由人编写，内容可能与底层代码脱节。使用说明可能会推荐某个组件用于一种它自身样式从未设计来支持的用途。如果目录纠正了你的第一直觉，就把这个修正记下来，但在渲染出该区域并检查之前，不要把它当成成功。复盘中最有用的一句话，往往是目录与渲染结果不一致的地方。

模式

模式 1 — 转换页面（最常见的情况）

按顺序执行四个阶段。每个阶段之间提供一行状态说明。

1. 获取配置文件。 如果 vibe-killer/SYSTEM.md 存在，就阅读并确认其内容仍然有效。如果没有，就先运行 intake/SYSTEM-INTAKE.md。这只需几分钟，之后的所有工作都会更快、更准确。
2. 提出下方的立场问题。 不要跳过，也不要猜。
3. 阶段 1 — 取证（phases/phase-1-forensics.md）。阅读源文件，整理特征，并写下每个区域的用途。
4. 阶段 2 — 映射（phases/phase-2-mapping.md）。为每个区域指定一个真实组件、真实组合，或如实说明存在缺口。
5. 阶段 3 — 转换（phases/phase-3-conversion.md）。编写页面。
6. 阶段 4 — 验证（phases/phase-4-proof.md）。进行验证、统计变更内容，并编写记录。

模式 2 — 构建或刷新系统配置文件

单独运行 intake/SYSTEM-INTAKE.md。当系统发布主要版本、转换过程中出现无人能找到的组件名称，或运行时 URL 不再有效时，也应使用此模式。

模式 3 — 针对不同系统进行转换

同一个页面，第二份配置文件。这是一场正面对比：每个系统分别让哪些工作变得容易，又有哪些地方需要你自己编写标记？保留两份记录，并比较缺口清单。

立场问题（每次运行都要问）

转换可以采用两种方式，最终呈现的页面确实会有所不同。 在第 2 阶段开始前，按大致如下的措辞提问：

你希望采用哪种方式？

A. 以你的系统规则为准（这是我的建议）。我会理解页面的用途、内容、层级，以及各个区域的作用，然后按照你的系统原本会采用的方式重新构建。如果原页面的某项设计选择与你的系统不一致，就以你的系统为准。最终效果会像你的产品，而不是原页面的截图。

**B. 跟随原页面的设计。**我会尽可能按照原页面的布局和视觉设计来实现，并使用你的组件替换底层内容。当需要让前后页面形状一致、有人确实喜欢原设计，或页面是对真实产品的忠实仿制时，这种方式很有用。

**默认采用 A。**大多数通过 vibe 编码生成的页面，都包含一些实际上无人做过的设计决策。忠实移植这些设计，就等于把别人的失误带进你的代码库，然后还得一直维护。

如果用户选择 B，开始前要直截了当地说明 B 的代价：坦诚地说，“保留原页面的外观”往往会让差距清单变得更长，因为系统中找不到对应项的定制视觉选择，最终只能成为差距或覆盖项，而覆盖项正是这项技能旨在消除的东西。在剖析文档开头记录所选方式，让后续读者知道页面为何呈现出这样的效果。

转换后的页面放在哪里

**默认：一个独立、可运行的页面。**一个能加载你系统的真实运行时，并且无需构建步骤就能在浏览器中渲染的单文件。这就是演示页面，也是你可以交给任何人的成品。

**询问他们想把页面放在哪里。**有些人希望直接写入代码仓库，使用框架的语法编写真实模板，并与其他页面放在一起。问一次，然后按他们的选择执行。写入代码仓库时，应优先遵循项目现有约定，不要凭空创建项目中尚不存在的目录或模式。

无论采用哪种方式，vibe-killer/ 都要保留整个过程的记录。

此工具包中的文件

• intake/SYSTEM-INTAKE.md — 用于访谈并构建 SYSTEM.md
• reference/THE-TELLS.md — vibe 编码页面的实地指南，以及各种迹象所反映的设计意图
• reference/CAPABILITIES.md — 这项技能能做和不能做的事
• reference/FIGMA-ACCESS.md — 如何访问设计库，以及各个桥接实际能看到的内容
• phases/phase-1-forensics.md — 阅读页面，整理各种迹象
• phases/phase-2-mapping.md — 将区域映射到组件，并提供依据
• phases/phase-3-conversion.md — 编写页面
• phases/phase-4-proof.md — 验证、统计并撰写验收记录
• templates/system.md、templates/autopsy.md、templates/receipt.md — 输出模板

状态（位于用户的项目中）

vibe-killer/
├── SYSTEM.md                        ← the design system profile, built once
└── kills/
    └── YYYY-MM-DD-<slug>/
        ├── autopsy.md               ← tells found, regions mapped
        ├── receipt.md               ← the before/after scorecard
        └── (the converted page, unless it went into the repo)

与任何 ds-inspection/、product-inspection/ 或 ds-adoption-plan/ 文件夹同级。它们可以在同一项目中并存。如果可以写入文件，就保留此文件夹。如果不行（纯聊天），则将每份产物单独作为一条消息发出，供用户保存，不要合并。

语气

简洁、有活力、具体。发现结果要用数字和文件引用来表述，不要谈感觉：“31 个定制类名、47 个硬编码十六进制颜色值、0 个焦点样式”胜过“有很多自定义 CSS”。读完验收记录的人应该能准确知道哪些内容已迁移到系统中、哪些没有，以及如何处理未迁移的部分。