
第一次读 Alan Walker 的《认知机器》,我把它当成"AI 时代设计系统的生存指南"来读。P2 "规则可编码即在射程内"让我确信:设计规范可以写成 YAML,进入 AI 的射程。P4 "模型是发动机,Harness 是变速箱"让我确信:把设计规范写成代码格式(Schema-As-Code)就是界面层的 Harness,在模型和界面之间做转换。四步判断循环(找场景→识别位置→推命运→给框架)对应我的四个环节(看组件→找原因→写规矩→做测试)。
当时我觉得读懂了。但现在回头看,我只读到了第一层。
第一件事,是我对 LLM 漂移的理解变了。
以前我觉得,AI 把"Critical"写成"严重"、把删除按钮做成蓝色,是 prompt 没写好,是工程问题,可以优化。后来我花了两个月扫了八类 AI 界面生成工具,诊断了 ChatGPT、Perplexity、Claude 和国内产品的具体症状,才发现:这不是某个工具的 bug,是 LLM 的内禀属性。
概率采样机制决定了 AI 天生就会"变着花样说"——同一个 prompt,今天给红色,明天可能给蓝色,后天觉得"严重"和"Critical"差不多。这不是工程缺陷,是生成机制的底色。就像重力,你不能消除它,只能设计能容忍它的系统。
第二件事,是阶段二的思考。
阶段一的模式库(Semantic Pattern Library)解决的是"认知问题"——让人知道"这是什么问题"。但知道了 ERR-001 是"错误状态后果差异未分级",前端可能还是不知道"删除按钮必须是红色空心"。从"知识"到"行动",需要一个"约束"机制。
约束的本质是:不需要理解为什么,只需要遵守规则。约束是知识转化为行动的最小闭环。没有约束,模式库只是"好看的文档"。有了约束,模式库变成了"可执行的系统"。
这两件事合起来,让我经历了第二次认知跃迁:从"把设计规范写成代码格式(Schema-As-Code) 是一个工具"到"Constraint as Code 是一种约束哲学"。
原来我读到的第一层: "规则可编码即在射程内"意味着设计规范可以写成 YAML,被 AI 消费。设计意图进入了 AI 的射程,可以被生成、被转换、被实现。
现在理解更深的一层: "可编码"只是可能性,"约束即代码"是强制性。一旦规则被写成代码格式的契约,AI 不是"可以参考",而是"必须遵守,不遵守就阻断"。
区别在哪?
第一层是"知识传递",第二层是"行动控制"。
原来我读到的第一层: "模型是发动机,Harness 是变速箱"。把设计规范写成代码格式(Schema-As-Code) 是界面层的 Harness,在模型(发动机)和界面(轮子)之间做转换——把设计意图翻译成代码、把语义令牌映射成视觉样式。
现在理解更深的一层:约束即代码(Constraint as Code) 不是做转换,是做控制。不是"让模型生成的界面更好看",而是"让模型生成的界面不能越过语义边界"。
Harness 是变速箱,控制的是"速度"和"方向"。约束基建是刹车+油门限制,控制的是"不能越过红线"。
第一层是"怎么生成",第二层是"什么不能生成"。
原来我读到的第一层: "生产权和评价权必须分开"讲的是组织层面的分工——设计师生产界面,走查人员评价界面,不能既是运动员又是裁判员。
现在理解更深的一层: 四层推演引擎(语法/语义/安全/美感)就是"机器评价权"。
人不再既是生产者又是评价者。人专注于定义约束规则(写 YAML),机器负责执行评价(跑推演)。
不满足就阻断,不需要人眼走查。一个产品 500 个页面,人工走查 100 个就累了,机器走查 500 个,覆盖率 100%。
第一层是"人分工",第二层是"机器接管评价"。
Alan Walker 讲的是"怎么判断 AI 时代的命运"(四步判断循环)。
我讲的是"怎么在 AI 时代守住边界"(Constraint as Code)。
两者合起来:判断命运 + 守住边界 = 完整的 AI 治理。
原来我读《认知机器》,是为了找理论背书。现在重读,是为了给 Constraint as Code 找认知锚点。
约束不是可选项,是必选项——因为 LLM 的漂移是它的内禀属性,不是 bug。