Taste Is All You Need

当 AI 把实现速度拉到过去难以想象的水平，作品之间的差距就不再只取决于“能不能做出来”，还取决于你选择做什么、删掉什么，以及用什么标准宣布完成。

过去一个月，我用 Coding Agent 跨进了不少原本陌生的领域。我用 Swift 做 macOS App，也独立完成 Agent 工作台、产品渲染、动效和技术文档。过去会被我拆成多个专业环节的事情，现在一个人就能先做出可运行、可比较的版本。

变化不只发生在速度上。当我让模型自由发挥时，它经常交回熟悉的答案：深色背景、蓝紫渐变、玻璃卡片，以及一句“输入你的需求，让 AI 帮你完成一切”。这些方案并不一定差，问题是它们太容易互换。换一个 Logo，产品仍然成立，也意味着它没有留下多少自己的判断。

实现成本下降后，另一个瓶颈开始变得清楚：Taste。

我说的 Taste 不只是审美偏好。它是对目标、取舍、边界和完成标准的判断：什么问题值得做，哪个方案更适合用户，哪些细节必须坚持，哪些效果应该删掉，以及一个功能虽然能做，为什么仍然不该继续加。

标题借用了 Attention Is All You Need 的句式，“All” 是有意的夸张。业务理解、工程能力、领域知识和持续交付仍然不可替代。更准确的说法是：当 AI 可以快速提供大量可行实现时，Taste 决定这些实现最终会被组织成什么样的作品。

一句话总结

AI 没有让工程能力失去价值，它改变了瓶颈的位置：生成候选越来越便宜，定义问题、比较方案、拒绝噪声、验证结果和沉淀标准变得更重要；我把这组带责任的判断称为 Taste。

AI 降低了“做一版”的门槛，也提高了“选一版”的要求

传统软件开发里，执行成本本身就是一道筛选器。

一个想法要经过设计、开发、联调和测试，很多不够重要的需求会因为成本太高而自然消失。现在，这道筛选器正在变薄。在我的实际工作里，一个 Prompt 可以很快展开多套界面，Agent 可以连续修改几十个文件，过去需要较长排期才能比较的方向，可以先在一个晚上做成原型。

于是问题发生了变化：

这里不存在一个严格的因果公式：使用 AI 不会自动让所有人拥有相同执行力，生成速度提高也不必然导致产品同质化。我的判断来自一个更具体的变化——当候选数量增加时，选择、验收和承担结果的成本不会一起消失。

AI 可以把货架迅速摆满，但它不会替产品负责人决定什么应该上架。方向准确时，它能让模糊想法迅速长成产品；方向错误时，它也能以很高的完成度把错误做得更远。

Taste 是一套带责任的判断

我现在用五类选择理解 Taste：

这也是为什么 Taste 不能只用“好不好看”衡量。一个漂亮但不稳定的窗口、一个功能很多却让用户失去控制的 Agent、一个氛围很强但读不清正文的页面，都可能有审美，却缺少完整的产品判断。

Taste 也不只体现在加了什么。那些没有进入最终版本的颜色、按钮、动画和功能，往往更能说明一个产品知道自己是谁。

我做 Owlet 和专业 Agent 工作台时，对这一点感受很深。

Owlet：AI 帮我跨进陌生领域，产品仍然需要我拍板

Owlet 是我用 Claude Code 和 Codex 做的一款 macOS menu-bar 应用。它来自一个很私人的问题：我每天大量使用 Coding Agent，到底消耗了多少 token，哪些项目最活跃？

我是前端工程师，并不熟悉 SwiftUI、AppKit、NSPanel、Sparkle 和 macOS 签名发布。按过去的学习路径，我可能会先系统学习 Swift，再从 Hello World 慢慢摸到 menu bar。Coding Agent 把这条路径压缩了：我可以直接从真实需求出发，在实现中补齐陌生领域知识。

AI 解决了大量“怎么做”的问题，下面这些决定仍然需要我回答：

• 为什么常驻菜单栏，而不是再做一个 Web dashboard？
• 为什么叫 Owlet，为什么是一只会眨眼的小猫头鹰？
• 为什么功能围绕使用量、会话状态和学习展开，而不是堆成 Agent 百宝箱？
• 为什么界面要像原生 macOS 工具，却不能失去自己的气质？
• 当系统材质带来崩溃风险时，是继续追求效果，还是换一种安全实现保留视觉语义？

模型可以列出候选，却不知道哪一个更像“我愿意长期放在自己菜单栏里的东西”。

Owlet 早期也出现过许多容易生成的方案：更强的光效、更满的卡片、更通用的科技蓝、更醒目的金色。单独看都说得过去，组合起来却越来越像一个没有身份的 AI dashboard。

让它定下来的，是一句和代码无关的话：

你知道临安青山湖水上森林吗？产品配色和调性从这个景区的主要元素蒸馏。

这句话没有指定 hex，也没有规定某个组件怎么写。它给了产品一个母题，让后续的局部选择拥有共同来源。

湖面变成主操作的湖水青，水杉变成成功和运行状态，远山承担次级信息，雾白负责空间和层次，晨光金只留在极少量高光里。母题也同时定义了禁区：不做赛博霓虹，不让金色主导 surface，不用重阴影堆层级，不为了“可爱”牺牲信息效率。

后来为了让灵动卡接近系统组件的玻璃质感，我们尝试过 macOS material 和窗口采样，特定组合会带来稳定性风险。最后我没有放弃“雾”，也没有为了视觉效果继续赌系统边界，而是改用纯 SwiftUI 绘制柔焦层：保留雾白的视觉职责，换掉高风险实现。

这也是 Taste：知道哪个体验必须保留，哪个实现可以妥协，并让审美服从稳定性、性能和可读性。

青山湖：一套风格要先学会删

青山湖风格是在一次次“不对”里长出来的，色板只是后来沉淀出的结果。

Agent 很容易把“自然感”理解成多放几种自然色，把“现代感”理解成更多渐变和胶囊，把“氛围感”理解成让装饰铺满页面。真实界面跑起来后，我反复给出的反馈却是：

• 颜色太花，只保留一个主导色；
• 胶囊按钮突兀，不要为了风格强行统一形状；
• 云雾只负责环境，不能侵入阅读区；
• 卡片之间优先用间距和层级组织，不要继续套卡片；
• 晨光金只能是稀缺高光，不能变成主题色；
• 动画只解释状态，不负责表演。

这段过程让我确认：设计风格首先是一套删减规则。

如果只告诉 AI“可以用什么”，它会很积极地把所有特征一起用上。输出真正开始稳定，是因为规则同时写清了“最多用多少”“只能用在哪里”“什么情况下不要用”。

青山湖于是从一句审美偏好，变成一套可执行约束：颜色有 semantic roles，圆角有范围，间距有节奏，动效有性能与可访问性边界，组件有 anti-pattern。它被写进 DESIGN.md，又被收录进 Design Language Atlas。

1
2
3
4
5
6
7

“我喜欢这个感觉”
        ↓
“我为什么喜欢它”
        ↓
“它在产品里承担什么职责”
        ↓
“什么情况下算做对，什么情况下算跑偏”

Taste 走到最后一层，才不再依赖某一次聊天的运气，而成为下一次 Agent 仍能执行的工程资产。

专业 Agent 工作台：同一种 Taste，不等于复制同一个界面

青山湖后来从 Owlet 迁移到了另一个专业 Agent 工作台。两个产品的技术栈和使用场景完全不同：Owlet 是个人使用的 macOS 工具，后者则面向复杂任务、页面探索和技能复用。

把两边都染成青绿色没有迁移价值。跨端复用的是同一套判断：低噪声画布、清晰的信息层级、克制的状态色、不过度装饰的 glass surface，以及让内容始终压过背景的优先级。

到了这个工作台，这套判断必须适应专业产品的密度。聊天入口可以有缓慢移动的云雾，进入任务和报告后，装饰必须后退。正文、筛选器、状态、日志和结果证据要更紧凑；loading、empty、error 和 success 继续使用同一套自然语义，但不能因为“青山湖”降低扫描效率。

这个工作台的产品路径也体现了另一种 Taste：不把 Agent 的全部能力堆到用户面前，而是把复杂执行收束成可理解、可确认、可验收的过程。

1
2
3
4
5

用户提出目标
  → Agent 理解意图并匹配项目与技能
  → 用户确认范围和边界
  → 多个执行单元并行工作并保留证据
  → 报告交付结果、优先级与行动建议

范围确认没有“一句话直接开跑”那么酷，却让用户在消耗执行资源前看清边界；报告也不只展示 Agent 跑了多少步骤，而是把结果整理成业务能够使用的行动建议。

这让我对 Taste 有了更完整的理解：它还决定产品把复杂度放在哪里。好的产品不会假装复杂度不存在，而是把它安排在用户能够理解、控制和验收的位置。

从直觉到 Skill：让下一次 Agent 继续做对

只在一个产品、一个页面或一次会话里成立的偏好，还不是可复用能力。

我后来把 Owlet、专业 Agent 工作台、Design Language Atlas 和相关 Landing Page 里的实践重新扫描了一遍，抽取出公开的 Qingshan Lake Design Skill。它覆盖 macOS、iPhone/iPad、Android、React Native、Web dashboard 和 Landing Page。

这次抽取没有把同一套界面复制到六个平台。共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式：

Qingshan Lake Design Skill 里除了 token，还有布局顺序、材质策略、状态合同、Reduced Motion、对比度检查和禁区。它不证明 Taste 可以被 AI 自动拥有；它证明的是另一件更务实的事：人的判断可以被外化成 Agent 能读取、实现和验收的约束。

这不是三个项目，而是一条设计生产链

如果只讲 Qingshan Lake Design Skill，这套方法仍然少了两端：判断从哪里来，以及视觉资产怎样稳定生产出来。

Design Language Atlas 不是换皮网站。除了设计语言索引和可运行 Demo，它还在继续补 UI Reference、Design Systems、组件、模板和社区 UI Skills。它的价值不是替我选风格，而是把零散收藏变成可以搜索、对照和拆解的 Reference 系统。

better-imagegen 也不只是给图片 API 包一层调用。封面、插图、Logo、壁纸、sprite loop 和 Codex pet 对尺寸、透明度、文字准确性、压缩与验收的要求完全不同，因此需要不同的生产路径。比如本文封面先由图片模型生成无文字的青山湖氛围底图，再用 HTML/CSS 确定性排版标题，最后转成 WebP 并记录生成 metadata。模型负责打开视觉可能性，工程流程负责保证文字、尺寸和交付结果没有靠运气。

这三层刚好对应 Taste 的三个动作：先扩大看过的世界，再把选择写成约束，最后把约束变成稳定产物。 对我来说，这同样是设计，而不是设计完成之后的辅助工作。

这也是整篇文章最关键的闭环。Taste 如果只能由作者本人“看一眼就知道”，它仍然难以规模化；当它能解释为什么、约束在哪里、怎样验证，才会从个人直觉变成团队和 Agent 可以复用的生产资料。

AI 能不能帮助人提升 Taste？

可以，但不要把最终选择也外包给模型。

AI 对 Taste 最有价值的地方，是降低探索和对照成本。过去做视觉研究，需要自己收集案例、拆组件、试实现；现在可以让 Agent 快速生成不同方向、分析差异、把参考转换成 token，再放回真实界面比较。

我现在使用这样一条循环：

Reference：先扩大看过的世界

Taste 不会从空白 Prompt 里凭空出现。产品、建筑、电影、自然景观和真实生活，共同构成判断的坐标系。

我做 Design Language Atlas，目的不是让 Agent 随机套一套皮肤，而是建立比较能力：同一个 dashboard 为什么适合青山湖、不适合 Cyberpunk；同样是 glass，原生系统 material 和业务后台的半透明 surface 分别承担什么职责；哪些产品需要情绪，哪些产品更需要秩序。

Diverge：让 AI 打开有意义的可能性

AI 很适合快速生成候选。这个阶段先比较方向：产品更安静还是更活跃，信息更集中还是更舒展，品牌母题来自自然、建筑还是角色。

发散的价值是暴露选择，不是留下更多图片。

Select：把“不对”说清楚

“不好看”“不高级”无法形成长期能力。更有效的反馈是：主操作不突出、背景侵入阅读区、圆角让专业工具显得玩具化、动效节奏抢走注意力。

当我能说清“不对在哪里”，直觉才开始变成可以讨论和复现的判断。

Constrain：把偏好写成规则

颜色要有语义，间距要有范围，组件要有职责，动效要有性能和可访问性边界，还要明确 anti-pattern。与其写“保持高级感”，不如写“湖水青是唯一主操作色；浮萍绿控制在极小面积；不要卡片嵌套卡片”。

清晰约束不会限制 Agent，反而能让它把算力用于更有价值的探索。

Verify：回到真实产品

设计稿里成立的东西，放到菜单栏的真实尺寸、数据密集工作台、不同尺寸屏幕和长时间动画里，可能完全是另一回事。

Owlet 的图标要在菜单栏真实尺寸验收，专业 Agent 工作台的云雾要连续观看仍不打扰阅读，玻璃组件要检查文字对比度，动效要尊重 Reduced Motion。截图只能证明一个瞬间，Taste 要经得起持续使用。

Remember：记住拒绝过什么

只保存“最终用了什么”还不够。很多一致性来自对失败经验的记忆：为什么不再用大面积金色，为什么不恢复高风险系统材质，为什么数据页面不铺云雾，为什么不做纯黑科技风。

把这些决定写进 DESIGN.md、Skill 和验收清单，下一次 Agent 才不会重新走一遍老路。

人和 AI 的新分工

回看 Owlet、专业 Agent 工作台和青山湖风格的形成过程，我更愿意这样划分责任：

这不是“人负责想、AI 负责做”的简单二分。AI 也能分析、提出方案和发现问题，人也必须理解工程。真正不能模糊的是最终责任：模型给出十个版本之后，必须有人决定哪一个值得留下；Agent 把功能跑通之后，必须有人判断它是否解决了问题。

AI 时代的超级个体，不需要亲手包办所有专业角色。他需要一套足够清晰的判断框架，再让 Agent 把执行力放大。

我的判断框架：Taste 什么时候真正有价值

• 值得投入： 当 AI 已经能快速产出候选，而产品仍然缺少方向、辨识度或稳定完成标准时，优先补 Reference、选择规则、anti-pattern 和验收方式。
• 不能替代： 涉及安全、合规、数据正确性和复杂系统边界时，Taste 不能替代专业知识、工程验证和责任机制。好判断必须建立在真实约束上。
• 重点关注： 不要只记录最终选择。把删掉什么、为什么删、什么证据会推翻当前决定一起沉淀，下一次协作才不会从零开始。

“Taste Is All You Need” 不是说有品味就不需要技术。只有理解技术边界，Taste 才不会停在漂亮图片；只有理解业务，Taste 才能从视觉偏好进入产品取舍。

发生变化的是稀缺性的顺序。

代码会更容易生成，界面会更容易完成，内容会更容易填满。更难复制的，是一个人长期形成的参考系、对细节的敏感、拒绝平庸方案的勇气，以及把一次直觉变成可复用标准的能力。

AI 会让更多人拥有更强的执行力，却不会自动替任何人承担选择的责任。

当“做出来”不再是唯一瓶颈，选择做什么、删掉什么、坚持什么，就是作品本身。

本文由 writting-skill 辅助生成，文章观点、项目事实与最终判断由作者确认。

延伸阅读与项目

• Qingshan Lake Design Skill
• better-imagegen：通用多模型 AI 生图 Skill
• 我用 Claude Code + Codex vibe 了一个 macOS App：Owlet
• 青山湖设计风格的诞生记
• 让云雾动起来：聊天界面的分层氛围动画
• Design Language Atlas