我踩过的两个坑

在我真正建立自己的工作框架之前，踩过两个典型的错误。

坑 01
所有代码堆在一个文件里
我用自然语言描述完成了一版视觉 demo，觉得效果不错，就把它放进 Claude Code 里希望做工程化。结果 AI 读取的内容和结构跟我做好的完全不一致，细节根本识别不了。更麻烦的是，测试用的假数据被直接写进了界面代码里，整个文件变成了一块牵一发动全身的混合体。后来花了很长时间才把它拆开修复。
教训：视觉 demo 和可交付的前端工程之间，有一道巨大的鸿沟。结构不提前定义，AI 就会自己发明。
坑 02
页面五颜六色
在没有颜色规则的情况下，AI 会自动抓取我上传文件里出现过的色值来用，没有任何约束。一个页面里可以同时出现五六种蓝，深深浅浅，毫无体系。
教训：这不是 AI 的问题，是我没有给它边界。AI 不会自动理解你的设计体系，范围没定义，它就自己定义。

什么是真正的 Skill

Harness
驾驭，而不是放任。
AI 有巨大的执行力，但没有你的设计判断力。Skill 的作用不是替你思考，而是把 AI 的能力约束在你定义的轨道里，让它的输出尽可能接近你的预期。

我现在的 skill 不是一段 prompt，而是一份持续迭代的 我的设计 skill 文件，目前已经是第四版。它包含四个核心层次：

01
设计系统的硬约束
颜色的映射关系、组件的使用规范、颜色使用边界。告诉 AI "不能做什么"——不能自己发明颜色、不能绕过规范直接用色值、不能跳过设计系统随意搭配。有了这一层，输出才有可能是品牌一致的。
02
工程架构的前置定义
在动手之前，必须先完成页面结构定义 → 信息流向 → 布局方案 → 模块拆分 → 数据结构 → 假数据方案 → 数据请求层，然后才是界面实现。这个顺序锁死，不能跳步。
03
工作模式系统
搭建 / 校验 / 修复三种模式，对应不同的工作意图。每个模式的行为边界是明确的，AI 不会在你只想调一个间距的时候把整个页面重新设计一遍。
04
产品原则
信息优先于视觉、密度优先于装饰、决策速度优先于视觉新颖——这些底层判断沉淀成规则后，AI 在模糊地带的选择会更接近我的预期。

"表层建设"和真正的方法论有什么区别

表层建设
把一个开源的 skill 发出来，别人去复用，能跑通，但只有最基础的配色、字体规则，只能做简单的官网建设，无法搭建复杂产品。
真正的方法论
能复用、能迭代、能在新场景下生长。每次遇到新问题，就往里面加一条新规则。

我的设计 skill 不是一次写成的。第一版很薄，只有颜色限制和基本的组件规范。踩了"代码全堆在一起"的坑，加了工程架构的执行顺序。发现 AI 在需求模糊时会乱改布局，加了三种工作模式的边界定义。发现操作按钮的颜色经常用错，加了按钮语义规则。

每一次更新都有一个真实的触发点，不是为了让文件看起来更完整，而是因为某个地方出了问题。

你的 skill 有没有在真实工作流里被验证过，有没有在真实的失败里被锻炼过——这是迭代和"开源表演"的本质区别。

它现在还不完备

我需要诚实地说：这份文件现在仍然不完备。它在执行层很严密，但还缺少几个重要的东西：

产品性格没有定义 — AI 不知道这个产品要"克制"还是"有温度"，遇到模糊情况还是会猜。
交互模式没有沉淀 — AI 分析面板的展开方式、追问建议的呈现规则、操作栏的行为逻辑，实际产品里已经有了固定模式，但还没写进文件。下次 AI 遇到类似场景还是会重新发明一套。
异常状态的视觉规范缺失 — 没有数据时显示什么、接口报错时显示什么、加载中显示什么，文件里还没有定义。

Skill 的建设不是一次性完成的，它应该跟你的实际工作同步生长——每次遇到新问题，就往里面加一条新规则。