你跟 AI 说"这次再口语化一点"，说过多少次了？

跟它说"上次那种风格再来一遍"，但它每次都给你不一样的"那种风格"——又特么说过多少次了？

如果你的回答是"很多次"，这篇文章是写给你的。

因为最近一个月，发生了一件事——"教 AI 别再这样"这件事，正在裂成 4 个维度。每个维度都有专业人在解决。但唯独有一个维度，只有你自己能写。

之前的文章都在告诉你「你该写一份 CLAUDE.md」。但看到这些同时冒出来——一份 md，还够吗？

01 代码维度：「写规矩」这件事自己又裂了三层

先说代码维度——这是最早成熟的一档。从 CLAUDE.md 开始，到最近，它自己又开始分级了。

第一层是 Skill。一段你重复要用的提示词，写成文件。轻量，单机，治"我懒得每次敲一遍"这种事。

第二层是 AGENTS.md / CLAUDE.md。项目级的约束。规定 AI 在这个项目里该走哪个目录、用什么命名、什么时候停下来问你。

第三层是工程级硬约束。阿里最近开源的 OpenCodeReview 是个代表——干脆把"哪些判断不能交给 LLM"用代码写死，AI 只负责剩下的场景推理。

说白了：Skill 能容忍输出抖动，因为代价是你重写一遍；一旦进入有业务后果的场景（自动评论、自动 PR），抖动就是事故。Skill 不够了，得工程化。

💡代码维度的约束已经分级了：Skill 管套路、AGENTS.md 管协作、硬代码管不可错的事。

02 视觉维度：同一个问题，冒出两条完全相反的路

视觉维度最近冒出两个项目，治同一个病——但解法南辕北辙。

一个像家训，一个像法条。

家训的写法：你跟 AI 说"我家的调性是克制 + 温暖赤陶 + 编辑式版面"，几句人话讲清楚品牌气质，剩下让它自己悟。

法条的写法：写 67 条 UI 风格、161 条行业规则、99 条 UX 准则——"银行类禁用紫渐变和 Dark Mode""医疗类禁用高饱和荧光色"，直接写死，AI 照着挑。

这两条路在治的是同一个病——AI Purple。

你大概率见过这种界面：AI 生成的 SaaS 官网，紫色渐变背景，Hero 区大字标题，下面三列卡片，每张顶部一个 emoji。不管你让它做金融后台、医疗应用、还是电商——都是这个味，大家管它叫 AI Purple。

一开始大家都以为是模型问题。最近冒出来的两个项目说明：治 AI Purple 不靠换模型，靠把审美写下来。

家训那条路是 Google Stitch 推的 Design.md。一个纯 Markdown 文件，写品牌定位、配色、字体、动效原则，用人话写。VoltAgent 扒了几十个主流网站的 DESIGN.md 做成 awesome 集合，Stripe、Vercel、Notion、Linear、Apple 全在里面。

法条那条路是 ui-ux-pro-max-skill。Claude Code 的 Skill，冲到几万 star。67 种 UI 风格、161 条行业推理规则、99 条 UX 准则全部写成结构化数据库，写代码前先跑一遍设计系统推理。

💡同一个痛点，两条相反路线都有人买单——这才是有意思的地方。

视觉维度从无人管，到几乎同时冒出两条路。这不是巧合，是"AI Purple"这个痛点真到了忍不下去的临界点。

03 先别急着写 md——为什么所有人选的不是 JSON

退一步看 01 和 02 这两节——你会发现一件没人讨论但很显然的事。

代码维度的约束文件叫CLAUDE.md / AGENTS.md。 

Skill 维度的叫SKILL.md。视觉维度的叫DESIGN.md。写作维度叫STYLE.md。

全是 .md。

不是 JSON、不是 YAML、不是 SQL、不是某种新发明的 DSL。是 Markdown——一个 2004 年发明、原本是给人写博客用的轻量标记语言。

这件事有点反直觉。如果你是一个十年前的工程师，让你设计"AI Agent 的配置接口"，你大概率会出一份 schema、配 validator、写 spec。但 AI 时代所有人不约而同选了 md——一种不能 validate、不能 type-check、连"必填字段"都没法强约束的格式。

为什么？

因为这套文件的真正读者，是 LLM。

LLM 读 JSON 和读 md 没本质区别，但 md 同时是人能直接读的。你写一份 DESIGN.md，团队设计师能看、产品经理能改、AI 能执行——三方共读同一份文件，这是 JSON 给不了的体验。

md 文件正在成为 AI 工作流里 Agent 与 Agent 之间、Agent 与人之间的通用接口。人写规范，Agent 执行，规范本身才是产品。

这才是这件事真正狠的地方——不是 AI 变聪明，是"人怎么把判断写下来"这件事，第一次有了跨人和工具的通用载体。

但如果你不是工程师也不是设计师，这套东西跟你有什么关系？ 

关系大了——

04 你也该有自己的 STYLE.md

回到开头那个问题——你跟 AI 反复说"再口语化一点""按上次那种风格"，到底为什么没用？

因为你没把"那种风格"写下来。

写下来的事，AI 能稳定执行；只在你脑子里的事，AI 每次只能猜。这件事工程师早就在做，最容易被圈走、普通人不知道自己也能玩。

我自己写作用的 STYLE.md，就放在项目根目录，里面写了什么？给你看几条：

禁忌清单（明确禁止 AI 用的词）： 

• "值得关注"、"令人印象深刻"、"与此同时"——媒体腔
• "总结来说"、"综上所述"、"笔者认为"——AI 腔
• "感谢关注"、"点个赞"式结尾——公众号俗套

加粗约定：一段一处加粗。加粗的必须是"哪怕只读这一行也不亏"的判断句，不是装饰名词或子标题。

emoji 约定：只允许 💡 和 ⚠️，其他场景一律不用。

我甚至专门列了一条"允许用的口头禅"——连我想让 AI 学的语气，都写成了文件。

跑一段时间下来，AI 改稿的风格漂移明显降下来了——以前每篇要拉锯几轮才像我，现在第一稿就接近。

工程约束（AGENTS.md）、视觉约束（DESIGN.md）、文字约束（STYLE.md）——是同一根藤上的瓜。你只要有一件"反复想让 AI 学但每次都教不会"的事，你就需要一份 md。

门槛低到不可思议——一个文本编辑器、先写个几十行起步，就能把"我喜欢这样"从反复解释变成 AI 永久能读的一份文件。用着用着自然会长，我那份现在 300 多行，是攒了好几个月慢慢加出来的。

如果你今天还在跟 AI 反复教同一件事——那不是 AI 不行，是你欠了自己一份 md。

05 4 个维度只是开始

今天是 4 个维度。明天可能是 14 个。

每个有专业判断的领域，都会沉淀出自己的约束文件——这是 md 这个载体已经定下来的趋势。

但对你来说，维度有几个不重要，重要的是有没有一份是你写的。

💡别人能帮你写代码维度，能帮你写视觉维度——但你最懂的那个领域，别人写不了，等也等不来。

代码、视觉、文字、编排——哪一个让你跟 AI 较劲最多次了？

那一份 md，就是你该补的功课。

今晚就开一份。空白文档，文件名想好——叫STYLE.md也行、叫MY.md也行。然后写第一条：

"AI 别再做的一件事是 ___"

写完这一条，约束文件里就已经有你写的一份了。