导读
用 AI 做产品，最大的坑可能不是"做不出来"，而是"什么都想做"。本文记录了百度前端研发工程师与 AI 组队开发 Design.md Token Exporter 的全过程------ChatGPT 陪他脑暴、Codex 当主力写代码、Gemini 做体验顾问，但 AI 的热情差点让产品变得臃肿不堪。当技术门槛被击碎后，什么该做、什么不该做，成了每个产品人必须自己回答的问题。这篇文章，讲的就是这个"取舍"的故事。
从一个 DESIGN.md 插件说起：普通人做产品之后，真正难的是什么
01 那个关于"AI 蓝紫风"的提问
事情的起因，来自朋友一次很实在的提问。
前阵子，我为了给自己写的一个小工具做个介绍页。为了让界面看起来克制、体面一些，我从网上找了一份带有手稿风的 Claude 风格 DESIGN.md------这是一种描述设计系统（色彩、字形、圆角、间距等）的 Markdown 规范。我把这份文件直接粘贴给大模型，说："照着这个规范，给我生成一个网页。"
大模型在几秒钟内，就产出了一个质感不错的静态页面。
我把网页截图分享出去后，一位做设计的朋友发微信问我："这种审美是怎么来的？为什么我自己用大模型写网页，出来的永远是高饱和度、带霓虹渐变和浮夸阴影的'AI 蓝紫风'？"
这个提问让我意识到一个细节：很多人并不是不会让 AI 写页面，而是不知道怎么把自己"喜欢的风格"，稳定地转化为能交给大模型的输入。
我们日常浏览网页时，经常会觉得某个网站的设计极其优雅。如果能有一个工具，把这个网站的设计系统一键提取成结构化的 DESIGN.md，然后作为大模型能听懂的"上下文"带走，很多 vibe 网页的审美门槛就消失了。
跟大模型讨论后，做一个浏览器插件的想法自然落地了。产品名字叫 Design.md Token Exporter 。（目前已经发布到chrome应用商店，在chrome商店搜索"design.md token exporter" ，或者直接用chrome打开这个链接 chromewebstore.google.com/detail/desi...
02 技术平权之后，门槛转移了
这确实是技术门槛被击碎的时代。
在以前，普通人有了一个产品想法，第一反应往往是："我不会写代码，我做不出来。" 试错的代价和搭建环境的物理障碍，足以在初期劝退大部分灵光闪现。
但现在，有了大模型的辅助，很多想法至少可以先低成本地试出一版。
在开发插件的过程中，我拥有了一个分工明确的"临时产品小队"：
-
ChatGPT 帮我讨论产品方向，将模糊的审美概念梳理成具体的功能逻辑；
-
Codex 扮演主力程序员，帮我高效率地实现代码、补齐类型定义，跑通测试和打包；
-
Gemini 则是体验顾问，站在用户的角度挑战我的交互细节。
这种高效率确实带来了极强的爽感。但很快我也发现，技术平权降低了普通人做产品的门槛，却并没有自动赠送产品判断。
AI 抹平了一部分实现能力的差距，但没有抹平产品判断的差距。
当写代码变成一件几乎不需要体力成本的事情时，你试得越快，另一个问题就暴露得越早：在面对大模型源源不断吐出的方案时，你到底要做什么，不做什么？
03 欲望膨胀，与克制的收缩
只要你经历过一次用 AI 从零做产品的全过程，就一定能体会到"被执行力诱惑"的感觉。
因为 AI 写代码太快了，你不需要付出多少精力和心智成本，就会本能地想要往产品里塞功能。在最开始的脑暴中，我想象中的插件极其庞大：它应该支持自动分析所有网页、在侧边栏显示实时预览、支持跨页面合并设计、支持云端同步，甚至要内置一个完整的 Mock 交互组件工作台。
在这个过程中，AI 不仅是一个执行者，更像一个"推波助澜"的编码器。只要你下达指令，它就会源源不断地吐出成百上千行的代码来实现你的各种想象。
但很快，我开始在这个无节制扩张的路线图前面退缩：
-
自动分析所有页面：看似很酷，但会在后台无节制地消耗浏览器算力，更会让用户产生严重的隐私疑虑。没有用户会喜欢一个悄悄扫描自己所有浏览记录和页面数据的扩展。
-
预览面板：看起来有用，但真实网页的 CSS 极度不可预测，如果不准，反而会损害用户对核心提取结果的信任。
-
更复杂的功能 ：意味着要在
manifest.json中申请<all_urls>等高危权限，这不仅会增加用户安装时的信任门槛，还会大幅延长 Chrome 商店的审核时间。
版本做得越大，越容易忘记最初那个最真实的场景。AI 很擅长帮我把功能加上去，但我必须学会把产品收回来。
04 预览被砍掉：一次关于"信任债务"的取舍
在所有收缩的决定中，彻底砍掉"预览面板（Preview Tab）"是最典型的一个案例。
为了让用户直观地看到提取出来的设计系统，我们曾在侧边栏开发了一个预览面板。它的逻辑是：根据当前网页提取到的颜色、圆角、间距，实时渲染出几个模拟组件（按钮、卡片、输入框）供用户观察。
然而，当我们尝试去分析 Claude 这种设计极度内敛的页面时，预览跑偏了。
Claude 的页面有着暖白背景、橙色小品牌符号和偏安静的控件。但因为大模型提取到的主色调权重问题，预览界面直接渲染成了一个粗暴的、高饱和度的蓝色 SaaS 营销卡片。
大模型并没有觉得这是个问题，它站在技术的角度，极其兴奋地向我建议了一套复杂的"修补方案"：
"我们可以把颜色拆成 brandAccent 和 actionColor，无可信 primary 时按钮自动走中性色，通过判断页面语义把模板从 Landing 营销页面切换为 App 聊天界面......"
从技术实现上看，这个补救方案条理清晰，完全行得通。但从产品的角度看，这个功能开始变得异常复杂，甚至偏离了它原本的初衷。
大模型给了我很多可行路径，但我意识到，这条路径不值得继续往下走了。我决定直接删掉 Preview 这一整套逻辑。
大模型在短暂的"明白"后，迅速转入执行，花了几分钟帮我彻底从 Side Panel 中删除了 Preview 所有的入口、import 语句、关联组件以及测试断言。侧边栏的最终打包体积从之前的 80KB 降到了 50KB。
这个决策背后，是我对"信任债务（Trust Debt）"的权衡。
在做设计系统工具时，如果生成的预览是不准确的，用户就会直觉地认为你底层的 tokens 提取也是不准确的。这会让一个本来应该帮助用户建立信任的功能，反过来制造怀疑。
删除 Preview 不是偷懒，而是为了让 MVP（最小可行产品）更诚实，让产品重新回到 Tokens 提取和交付的核心价值上。
05 权限与报错：在规则的边界内解释清楚
另一个体现产品判断的地方，是对 Chrome 严苛的 activeTab 权限机制的妥协。
在 activeTab 机制下，出于安全保护，侧边栏内部按钮的点击不被视为合法的显式授权手势。这意味着，如果用户在新打开的页面上直接点击侧边栏的"Analyze"，插件会因为拿不到临时授权而频繁报错。
对于工程师和大模型来说，这只是 Chrome MV3 的正常安全逻辑；但对于用户来说，这就是"按钮坏了，程序有 Bug"。
为了让体验更顺畅，大模型在搜集资料后向我提过很多方案：比如在 Manifest 中加入右键菜单权限 contextMenus，或者引入全局快捷键 commands。这些方案在技术上确实能避开限制，但在产品上，这会增加我的权限申请成本和 Chrome 商店的审核难度，同时也会增加用户安装时的安全疑虑。
最终，我决定不新增任何 Manifest 权限，而是去优化错误提示和状态保持。
产品体验不总是靠增加能力解决的，有时候是靠在既定边界内把事情解释清楚。
我们与大模型一起完成了这套纯前端的容错和状态流转逻辑：
-
保持稳定状态 ：顶部状态栏永远只显示
Last analyzed: example.com等稳定状态。如果分析出错，状态栏会自动回滚到上一次的稳定文案，绝不用晦涩的 Chrome 技术堆栈报错去打扰用户。 -
多态错误卡片 ：如果用户直接点击且缺少授权，我们在内容区展示简洁的
Authorization required英文警告卡片；如果是在系统保护页面（如chrome://），则展示专用的Page cannot be analyzed卡片。 -
保护历史结果：如果已经有了分析结果，刷新时即使报错，我们也决不用报错卡片覆盖已有的数据，而是只在按钮下方展示一小行紧凑的 inline notice 动作反馈。
-
去除 Emoji，规范视觉 ：将原本跳脱的 🔒 和 🚫 符号，全部换成
lucide-react中标准的Lock和AlertCircle矢量图标，保持高质感与界面一致性。 -
固定按钮宽度 ：将 Analyze 按钮用 Tailwind 固定为
w-40 min-w-[160px]宽度，避免在"Analyze current page"、"Analyzing..."和"Refresh analysis"文案流转时产生尴尬的 UI 跳动。
我们没有去挑战浏览器的规则，但我们在规则的边界内，给了用户最诚实、最透明的解释。
06 临时小队不会自动给出正确产品
回顾整个过程，多模型协作的真实价值，是让普通人第一次拥有了一个随叫随到、不知疲倦的"临时产品小队"。
-
ChatGPT 提供方向碰撞；
-
Codex 跑通实现、测试、打包与发布前审计；
-
Gemini 捕捉交互和体验上的细节。
但这个小队并不会自动给你一个正确的产品。AI 就像一个拥有无限精力的匠人，它会源源不断地向你提供可能性。如果你不加控制，它会很乐意用代码帮你盖出一座由伪需求堆积而成的庞大废墟。
在这个过程中，最核心的依然是人类的判断力。你要决定哪些可能性可以进入产品，哪些方案虽然技术上优雅但产品上多余，以及何时在既定的规则边界前体面地妥协。
大模型抹平了普通人与工程师之间关于代码实现的鸿沟，却也因此把另一个问题推到了台前：技术平权让普通人拿到了做产品的入场券，但它没有自动赠送产品判断。
07 降噪后的体会
这次经历让我意识到，技术平权并不是让每个人都自动做出好产品，它只是把我们从枯燥的底层语法和语法纠错中解放出来，让我们得以用极低的成本去验证自己的观察。
以前，我的想法可能止步于"我不会写代码"；现在，真正的问题变成了：我能不能定义一个足够小、足够真实的场景，并在 AI 极其热情的建议里，冷静地守住产品的边界。
正如在这款插件中，我最终决定砍掉预览，坚守最简权限，用极其克制的 tokens 提取和干净的交付，去解决最纯粹的问题。
当代码越来越便宜，取舍就越来越贵。
Vibe Coding 的终点不是"让 AI 写代码"，而是把人类的审美、经验沉淀和产品边界，变成可以交给大模型的可执行上下文。
而在这个过程中，那个决定"不做些什么"的判断本身，才是人类留给产品最独特的锚点。