协作方法论 · 带护栏的 Vibe Coding

规则的价值:每条解决一个真实问题

全景图回顾 + 使用方法 + 适配自己项目的四个动作

本页解决的问题

先给结论

「规则的价值:每条解决一个真实问题」要解决的关键问题是什么?

全景图回顾 + 使用方法 + 适配自己项目的四个动作

判断标准

把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子,以及判断体验何时低于标准的方法。

下一步

记录一个前后对比,让别人不用听解释也能看懂质量线。

常见误区

表面更精致了,却没有减少用户的不确定感。

交互一 · 14 章规则全景图

14 章规则归入五大板块。点击任意板块,展开对应章节明细、一句话说明,以及它在本专题第几节课里讲过。

共同底层:把模糊期望变成可执行的具体动作。「注意质量」执行不了,「删除代码前必须显式声明」才执行得了。
使用方法 · 三步装进项目

STEP 1放入 rules 目录

.mdc 文件放进项目的 .cursor/rules/ 目录,Cursor 会自动识别。

STEP 2配置生效方式

frontmatter 里的 alwaysApplytrue 全局生效,设 false 则需手动 @ 引用,写作规范适合后者。

STEP 3替换环境事实

把模型配置、技术栈、端口规则换成你自己的选型,secrets 文件填占位符并排除出 git。

交互二 · 适配四步自查向导

这套规则并非拿来即用的模板。回答下面 4 个问题,对应「删、换、调、补」四个动作,走完生成一份你的定制建议清单。

适配自查向导 第 1 步 / 4
交互三 · 11 节课回顾

专题一共 11 节课。点击卡片翻开,看每节课的一句话版本。

结课作业 · 发布你的第一版 Rules

60 分钟 · 提交物:你自己的 rules 仓库。xs_vibe_rules 出发,按删、换、调、补四个动作产出你的第一版规则文件;在一个真实项目里用满一周,记录哪些规则被触发、哪些从没生效;删掉从没生效的,把新踩的坑写成新规则,然后开源你的版本。

拿走这套规则

itshen/xs_vibe_rules · 本专题的开源仓库

结课作业的起点就在这里。Fork 一份(MIT License),按删、换、调、补四个动作改成你自己的版本,用满一周后开源出来。

去 GitHub Fork
Takeaway

AI 负责快,规则负责稳。规则的价值不在于多,每条都解决一个真实问题。照搬 14 章不如精选 5 章,规则和代码一样,没人维护就会腐烂。

素材来源:本专题完整素材见开源仓库 itshen/xs_vibe_rules(MIT License),含 rule-opensource.mdc 全文与逐章设计思考。

从「交互一 · 14 章规则全景图」把感觉变成判断

「14 章规则归入五大板块。点击任意板块,展开对应章节明细、一句话说明,以及它在本专题第几节课里讲过」指出,AI 降低了做出“能用”成品的门槛,读者真正需要练的是看出哪里不对,并把感觉说成可以执行的要求。

观察用户的下一步,而不是只看表面

「把 .mdc 文件放进项目的 .cursor/rules/ 目录,Cursor 会自动识别」可以转成几个可观察的问题:用户是否知道现在发生了什么,是否知道下一步做什么,出错或空白时能否恢复,以及信息层级是否让重要内容先被看见。

漂亮不等于容易用

把「AI 负责快,规则负责稳。」用在第二个页面或流程上,记录一个具体犹豫点和一个改动后的用户动作;能被观察到的变化,才是体验改善。

从「交互一 · 14 章规则全景图」走到「STEP 1 放入 rules 目录」

「交互一 · 14 章规则全景图」先把问题落在「14 章规则归入五大板块。点击任意板块,展开对应章节明细、一句话说明,以及它在本专题第几节课里讲过」上;到了「STEP 1 放入 rules 目录」,讨论继续推进到「把 .mdc 文件放进项目的 .cursor/rules/ 目录,Cursor 会自动识别」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。

把这条判断带到下一个场景

评估体验时,把抽象的“好看”或“顺手”换成用户动作:他是否看懂状态、找到了下一步、能从错误中恢复,并且愿意继续使用。

  • 「交互一 · 14 章规则全景图」:14 章规则归入五大板块。点击任意板块,展开对应章节明细、一句话说明,以及它在本专题第几节课里讲过
  • 「STEP 1 放入 rules 目录」:把 .mdc 文件放进项目的 .cursor/rules/ 目录,Cursor 会自动识别
  • 「最后的要点」:AI 负责快,规则负责稳。 规则的价值不在于多,每条都解决一个真实问题。照搬 14 章不如精选 5 章,规则和代码一样,没人维护就会腐烂

最后的「最后的要点」把讨论落到「AI 负责快,规则负责稳。 规则的价值不在于多,每条都解决一个真实问题。照搬 14 章不如精选 5 章,规则和代码一样,没人维护就会腐烂」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

文章讨论

读到这里,留下一个判断。

把刚想明白的地方、还没想通的问题,留给下一位一起学习的人。

正在讨论 规则的价值:每条解决一个真实问题 带护栏的 Vibe Coding
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。

文章讨论4 有帮助