别再每天给 AI 重新解释一遍了，YC 大佬的四条规则就够
别再每天给 AI 重新解释一遍了，YC 大佬的四条规则就够
YC 创始人 Garry Tan 最近在 X 上把他在用的 OpenClaw 提示词放出来了，原推这两天在程序员圈里扩散得挺凶。打开看一眼，正文短得让人愣住——只有四条规则。
但这四条，是我看到的关于 AI 协作最狠的一刀。它没在卷模型，没在堆 agent 框架，纯纯讲一件事：你跟 AI 协作累，不是因为 AI 不够聪明，是因为你每天都在重新教它一次同样的东西。
下面把这四条规则拆开讲，附上你今晚就能直接抄到自己 AGENTS.md 里的版本。
一、禁止一次性工作
第一条最反直觉，也最值钱。
什么叫一次性工作？大多数人用 AI 的标准姿势——发一段 prompt，AI 产出一份结果，事儿完了。下一次想做同一件事，重开窗口，再发一段 prompt。
OpenClaw 直接禁掉这个模式。它要求：
- 第一次做这件事时，先产 3-10 个样本给你看
- 你确认效果之后，AI 自己把这套流程写进 SKILL.md，沉淀到技能库
- 下次你再喊「写周报」，AI 直接调技能，不再问你格式
如果是周期性任务（每周一抓数据写日报），不用手动喊，openclaw cron add 直接到点自启。
这条规则的精妙之处在于，它把”提一个函数”这件程序员的本能，移植到了”教 AI”这件事上。我们写代码到第三次相同逻辑就一定要抽函数，可面对 AI 这套自然语言协作，这个本能往往会被关掉——每开新对话窗口都从零讲起，像每天上岗第一天的实习生一样从头解释一遍业务。
四个字总结，写一次，跑无限次。
二、MECE 原则
第二条来自麦肯锡老套路，相互独立、完全穷尽。放在 AI 技能库这个语境下，就一句人话：
一个活只能由一个技能管，不重叠，不空白。
很多人技能库一开始不大，写到第十几个就开始打架。比如同时存在「写文章」和「文章配图」两个技能，配图逻辑可能在两边都各塞一份，时间一长两个版本各自演进，结果用 A 时调出一种风格，用 B 时调出另一种。
OpenClaw 第二条规则就是治这个的——能扩展旧技能就绝不新建。
技能不是越多越好，是越精越好。每个技能都该是一块锋利的、不会滑刀的小工具。
这条规则反过来用还有第二个好处：它强迫你在每次想新建技能前，先扫一遍整个技能库的边界。久而久之你的技能库不会变成杂物间，而会保持一种”轻盈感”——这词儿听着虚，但用过的人都懂。
三、第二次发生 = 失败
第三条原文叫「最狠的失败判定」。规则只有一句：
如果你第二次还要问 AI 同一件事，它就失败了。
不是第十次。第二次。
第一次是发现需求，第二次就该自动完成。
这条特别狠的地方在于，它不是在管 AI，它是在管你自己。
我们用 AI 用得最累的时候，往往不是 AI 哪里没做好，而是我们自己卡在「再讲一遍它就懂了吧」的幻觉里——觉得是模型不够强，再换个模型就行了；觉得是上下文不够长，多塞点 prompt 就行了。但真正的问题是，我们没有把”第二次发生”当成一个需要立即解决的故障。
OpenClaw 把这条做成了亮黄灯：第二次发生 = 失败 = 立即补一个技能 = 以后再也不要发生第二次。
好家伙，这条比模型升级值钱多了——模型升级是别人给你的杠杆，这条规则是你自己装的反馈回路。
落地动作：每天结束时翻一遍当天对话日志，把出现两次以上的相同请求挑出来，立刻沉淀成技能。一周之内你会惊讶地发现，自己每天究竟在做多少完全可以一次性写死的东西。
四、六步流程：概念 → 原型 → 评估 → 编码 → 定时 → 监控
第四条是整套规则的执行模板：
- 概念：先把要解决的问题说清楚。是「我每周要从五个数据源拼一份周报」，不是「写周报」
- 原型：先弄三五个样本，看跑出来对不对
- 评估：给样本打分，定位失真在哪
- 编码：把这套逻辑沉淀成一个 SKILL.md，结构化、可复用
- 定时：如果它该周期性跑，加 cron
- 监控：产出得有最低质量底线，低于底线停机回炉
这就是软件工程过去三十年的工作流。我们以前把它用在写代码上，现在把它用在「教 AI 学一件事」上。逻辑一模一样。
整套流程跑完一圈，最容易被忽略也最关键的是最后那个监控。绝大多数人给 AI 定了任务就放手不管，三周后 AI 产出的东西已经悄悄漂移了——某次格式变了，某次幻觉了一个数据源。如果不主动去看，它会一直跑下去，错下去。
监控这一环不补，前面五步都白搞。
顺手的支线：从 Markdown 转向 HTML
主线讲完了，顺手聊一个跟这套规则配起来用效果翻倍的支线。
主线是教 AI 学会做事，支线是教 AI 用什么格式给你看结果。
那条原推下面有一个引用，是 Claude 团队工程师讨论的话题。他们说，团队内部已经基本不用 markdown 当 AI 的输出格式了，转向 HTML。
逻辑是这样的：markdown 早年好用是因为两个核心优点——AI 写出来人能看，人能再手动改。但 2026 年这两个优点已经垮了：
- AI 一次能输出 800-2000 行 markdown。这个规模下它就是一堵纯文字墙，扫到第 300 行就走神
- 「人能再改」也作废了。现在跟 AI 协作的标准模式是 AI 写、人看——不会去改 markdown 里某个字，会让 AI 重新输出一遍
两个优点都垮了，markdown 就变成了折中产物。它没那么适合 AI，也没那么适合人。
而 HTML 能做 markdown 想都不敢想的事：
- 带颜色的表格
- SVG 流程图
- 可点击的原型
- 滑块调参数
- 拖拽排序的任务清单
最关键的是，链接一发别人点开就看，不用任何工具。
体验差距不是一倍两倍，是十倍。
三个能直接抄的 HTML 用法
代码审查：让 AI 把 PR diff 输出成彩色 HTML，旁边附一段「这个改动会影响哪些模块」的简单依赖图。重点高亮、风险标红、低风险段折叠。这一手有点子牛逼——比 GitHub 网页 review 的注意力曲线高得多。
做计划：让 AI 把项目计划直接出成 HTML——时间线、按优先级排的任务卡片、附带「如果做不完会发生什么」的风险表。读完就能立刻判断哪里需要砍、哪里需要加人。比纯 markdown 大纲省一半脑力。
临时调参器：调 prompt 时最痛苦的事之一是来回粘贴二十遍试不同语气长度风格。让 AI 直接写一个 HTML 调参器，几个滑块控制温度/长度/风格强度，下面实时显示生成结果。改完一键复制。
代价：HTML 比 markdown 多耗 token、生成时间长 2-4 倍、git diff 不如 markdown 干净。但跟体验提升十倍比起来这点代价不值一提。
实际工作流可以划开两层用——给自己看、用完就扔的，全用 HTML；需要长期归档、要 git 跟踪的，仍然 markdown。两者各管一段，不冲突。
写在最后
回到 Garry Tan 那四条规则。
我们这些年用 AI 用得越来越累的真正原因，从来不是 AI 那一边。模型再聪明，你不教它把听到的话沉淀下来，每次都得从头听一遍。上下文再长，你不让它把成功经验存进技能库，每次都得现推理。agent 框架再成熟，你不让它自己 cron 自己，每次都得等你按按钮。
真正的杠杆从来不在工具里，在教法里。
今晚回家你小子就做一件事——把这四条规则复制到自己的 AGENTS.md 最前面，重启 Claude Code。
明天开机的时候，那个一直在等你重新解释一遍的 AI，就会慢慢学会自己游了。