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

沉淀你自己的协作规范

四步流程对比演示;三档任务:写第一条 Rule、真需求走一遍流程、导出建造日志整理成规范 v1

本页解决的问题

先给结论

「沉淀你自己的协作规范」要解决的关键问题是什么?

四步流程对比演示;三档任务:写第一条 Rule、真需求走一遍流程、导出建造日志整理成规范 v1

判断标准

跟着交接处走,不要只看 Demo。 系统是否可靠,往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。

下一步

为一个自动化步骤写清输入、负责人、审批和恢复动作。

常见误区

一次运行成功了,却说不清发生了什么,也无法安全重放。

实战主线最后一格:东西做出来了,现在把过程变成可复用的资产
M0
想清楚它替你干什么
M1
能稳定说人话
M2
能动手干活
M3
改好改坏能量化
M4
长跑不失忆
M5
过程可复现
先看清楚 · 断点设在动手之前,返工才会消失

这一章的四步流程(复述、PRD、确认、编码)解决的是同一个问题的两副面孔:AI 理解错了需求还闷头猛干,你发现时它已经改了二十个文件。断点必须设在它动手之前,动手之后的纠正都叫返工。

同一个需求,两种交法

01
AI 复述需求

用它自己的话讲一遍要做什么,歪了当场就能看见

02
写 PRD

方案、边界、不做什么,白纸黑字落下来

03
等你确认

人工闸门:不点头就不动手

04
开始编码

此时才动手,写出来的就是确认过的那个东西

理解就歪了,后面写得越快,错得越多
一句话丢过去直接开写,第一步理解就歪了,但你要到验收时才发现。它写得越快、越勤奋,你要拆的违章建筑越大。这就是「AI 写得快反而容易搞砸」的机制。

规矩不用从零写

这一章拆的 xs_vibe_rules 是能直接 Fork 的。只是别整套照搬。规则的价值在于每条背后都有一次真实翻车,你没翻过的车,规则贴上去也守不住。正确姿势是:从你自己前五格踩过的坑里挑三五条写成规矩,再从仓库里借用你看得懂「为什么」的那些。

动手清单 · 挑一个开始,勾掉它

这一章的动手清单

0 / 3 已完成

写下你的第一条 Rule

15 分钟 所有人

从前五格的记录里挑一个你踩得最疼的坑,写成一条规矩。格式照这一章教的:先写为什么(那次翻车),再写怎么做(具体指令)。比如你在 M1 被格式飘坑过,规矩就是「所有输出必须符合 XX 模板,资料里没有的写未提及」。

什么算做完了
这条规矩放进新对话的开头后,那个坑真的不再出现。规矩写了不生效,说明写的是愿望不是指令。

拿一个真需求走一遍四步流程

1 小时 和 AI 协作干活的人

下一个真实需求,别直接丢给 AI。先要求它复述,复述歪了就纠正;再让它写一页迷你 PRD;你确认之后才放行。全程感受一下:断点前移之后,成品和你预期的差距变了多少。

什么算做完了
复述环节至少抓到一处理解偏差(抓不到说明这个需求太简单,换个大点的),且最终成品没有大返工。

导出建造日志,整理成规范 v1

半天 要走完整条主线的人

回建造日志把六个里程碑补全,导出 Markdown。然后做最后一步:把它整理成一份你自己的 AI 协作规范:需求怎么定(M0)、提示词怎么写(M1)、工具怎么接(M2)、怎么评测(M3)、怎么长跑(M4)、流程怎么走(M5)。发给一个同事,看他能不能照着做出一个类似的东西。

什么算做完了
同事拿着你的规范能提出具体的问题,说明他真读懂了。回一句「写得挺好」的,多半没读。到这一步整条主线就走完了,你手上有一个能干活的 Agent,和一份能传给别人的方法。

回建造日志,把六格填满

M5 是最后一格。六个里程碑全部填完后,导出按钮会给你一份完整的 Agent 建造档案,那就是这门课在你手上留下的实物。

去填 M5 并导出

「先看清楚 · 断点设在动手之前,返工才会消失」怎样变成可执行的指令

「这一章的四步流程(复述、PRD、确认、编码)解决的是同一个问题的两副面孔:AI 理解错了需求还闷头猛干,你发现时它已经改了二十个文件。」强调的不是某句神奇咒语,而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。

背景决定方向,限制决定边界

从「这一章拆的 xs_vibe_rules 是能直接 Fork 的。只是 别整套照搬 。规则的价值在于每条背后都有一次真实翻车,你没翻过的车,规则贴上去也守不住。正确姿势是:从你自己前五格踩过的坑里挑三五条写成规矩,再从仓库里借用你看得懂「为什么」的那些」可以看出,一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景,模型只能猜;少了验收标准,即使文字流畅也无法判断是否完成任务。

继续加字不一定继续变好

把「M5 是最后一格。六个里程碑全部填完后,导出按钮会给你一份完整的 Agent 建造档案,那就是这门课在你手上留下的实物」变成一个小练习:只改背景、要求、限制中的一项,保留其他内容不动,观察哪一层真正改变了结果。

从「先看清楚 · 断点设在动手之前,返工才会消失」走到「动手清单 · 挑一个开始,勾掉它」

「先看清楚 · 断点设在动手之前,返工才会消失」先把问题落在「这一章的四步流程(复述、PRD、确认、编码)解决的是同一个问题的两副面孔:AI 理解错了需求还闷头猛干,你发现时它已经改了二十个文件。 断点必须设在它动手之前 ,动手之后的纠正都叫返工」上;到了「动手清单 · 挑一个开始,勾掉它」,讨论继续推进到「从前五格的记录里挑一个你踩得最疼的坑,写成一条规矩。格式照这一章教的: 先写为什么(那次翻车),再写怎么做(具体指令) 。比如你在 M1 被格式飘坑过,规矩就是「所有输出必须符合 XX 模板,资料里没有的写未提及」」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。

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

写请求时也应逐层补齐:先说任务和受众,再给材料和输出要求,最后加上限制与验收方式;一次只改变一层,才能知道哪项信息起了作用。

  • 「先看清楚 · 断点设在动手之前,返工才会消失」:这一章的四步流程(复述、PRD、确认、编码)解决的是同一个问题的两副面孔:AI 理解错了需求还闷头猛干,你发现时它已经改了二十个文件。 断点必须设在它动手之前 ,动手之后的纠正都叫返工
  • 「动手清单 · 挑一个开始,勾掉它」:从前五格的记录里挑一个你踩得最疼的坑,写成一条规矩。格式照这一章教的: 先写为什么(那次翻车),再写怎么做(具体指令) 。比如你在 M1 被格式飘坑过,规矩就是「所有输出必须符合 XX 模板,资料里没有的写未提及」
  • 「最后的要点」:M5 是最后一格。六个里程碑全部填完后,导出按钮会给你一份完整的 Agent 建造档案,那就是这门课在你手上留下的实物

最后的「最后的要点」把讨论落到「M5 是最后一格。六个里程碑全部填完后,导出按钮会给你一份完整的 Agent 建造档案,那就是这门课在你手上留下的实物」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。

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

继续阅读

同一条线上的下一篇。

文章讨论

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

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

正在讨论 沉淀你自己的协作规范 带护栏的 Vibe Coding
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

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

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

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

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

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

文章讨论4 有帮助