vibe coding 如何约束才算工程：从赌场式生成到可审计意图
vibe coding 省事但会掏空架构理解。本文基于近期工程讨论，给出可执行的约束层级：外置意图、可检查验收、限制 blast radius，以及哪些“伪规范”不值得堆。
Alex Klos 的文章把焦虑说得很直：代理普及之后，大家担心的不是“还会不会手写代码”，而是 slop 会不会把工程纪律一起冲掉。Karpathy 说自己几乎不再敲代码——方便真实存在；同时你对代码库的心智模型也在变稀。和本站已有的 vibe coding 规格驱动开发 互补，本文聚焦一件事：怎么约束，才配叫工程，而不是多写几段 markdown 自我安慰。
先承认：回退到手写全家桶不现实
Booch 把软件抽象浪潮比作编译器之后的又一次抬升：意图直接生成实现。回退到“禁止 agent”既挡不住团队效率压力，也挡不住生态。目标应改成：
- 尽量让 agent 做你真正要求的事；
- 改动可审计，最好不必通读每一行才敢合并；
- 纪律路径的摩擦力不能明显高于纯 vibe。
三条缺一，流程再花哨也只是提示词仪式。
伪约束：看起来严谨、其实不可强制
Klos 批评得很准，对照自检：
- 巨型 markdown 流水线：specify→clarify→plan→… 六步全靠人催，agent 仍是自己批改作业。
- Skills 当银弹：条件注入说明书有用，但没有机械校验时，和“写长一点的 system prompt”同类。
- 让 agent 写完测试再验收自己：TDD 的确定性被重新打开。
这些东西可以当辅助，不要当成“已经工程化”的证明。若你主要卡在规格写法，先看规格驱动那篇；若你卡在“改完不敢信”，继续下面三层约束。
约束第一层：意图外置，且可扫描
自然语言需求很快让人眼花。更可扫的形式包括：
- EARS 式条件句：
WHEN … THE SYSTEM SHALL …/IF … THEN … - 短声明列表：职责、非目标、验收命令
- 变更范围：允许改的目录与禁止改的目录
意图写在仓库文件里，会话只引用路径。这样换会话、换人不丢上下文，也避免窗口被聊天史挤爆。
约束第二层：验收可执行，不靠“看起来对”
合并前至少固定一种机械信号：
- 指定测试命令必须绿；
- 类型检查 / lint 必须过；
- 关键路径的权限与密钥扫描必须过。
Agent 可以帮忙生成测试，但验收命令由人定，结果由 CI 跑。人审的是失败用例与架构边界，不是 2000 行生成 diff 的文学性。
约束第三层：看见 blast radius
纯 vibe 最可怕的是：计划散文里不告诉你会碰到哪些模块。实践上要求代理在动手前给出：
- 将修改的文件列表；
- 可能影响的接口 / 迁移；
- 明确不做的事项。
做不到就缩小任务，而不是加大模型。并行多代理时尤其容易失控，可参考 自主运行风险防护。
一条可落地的最小流程
- 开任务卡：目标 / 非目标 / 验收命令（10 分钟内写完）。
- Agent 只读任务卡与相关目录，先给文件级计划，你确认范围。
- 实现 → 本地或 CI 跑验收 → 人看 diff 与失败点。
- 合并后更新任务卡状态，开新会话做下一刀。
工具可以是 Spec Kit、Kiro、自研 MCP 模型层，或你们内部模板——流程价值在强制点，不在品牌名。
常见问题
和“规格驱动”那篇重复吗？
角度不同。规格驱动讲怎么写规格；本文讲哪些约束真能降低信任成本，以及哪些流程是仪式。
个人项目也要这么重吗？
按风险缩放。玩具项目可以 vibe；涉及钱、权限、用户数据时，至少保留“外置意图 + 可执行验收”。
会不会牺牲速度？
前几分钟变慢，返工与线上事故通常更少。速度应算“到可合并”的时间，不算“到第一版能跑”的时间。