AI Slop 治理实战

Key Takeaways

• 通用 AI 生成 UI 已出现明显同质化， 业内以 slop 一词概括
• 用 [观察] 描述传统 prompt 直出的 slop 链路
• Skill 已成 Agent 工程化的事实标准
• 单条 prompt 无法承载完整产品意图
• 长 Agent 会话最大的失败模式是上下文蒸发
• 真实应用含未经打磨的边角， 模板则过度干净
• 直接克隆站点会丢失原组件的依赖关系
• 把克隆代码与自定义 spec 直接合并必然冲突

引言： 重新认识 AI Slop 与 Vibe Coding 治理

一、AI Slop：同质化浪潮下的视觉税

过去十二个月，通用大模型驱动的 UI 生成已经形成一种可识别的"视觉税"(slop)：同样的圆角、同样的玻璃拟态卡片、同样的渐变 hero 区、同样的 AI 配色——所有页面看起来都像是从同一台机器里印出来的。工程师社区开始用 slop 这个词来概括这种"低信噪比、缺上下文"的生成内容，它和传统意义上的代码冗余不同：slop 不是 bug，而是一种审美同质化 + 上下文缺位的复合现象。

这张表的关键不在表头，而在最后一行：AI 生成的内容越像成品，review 时越容易被 skip。这是 slop 在工程流水线里最具破坏力的副作用——它把"必须看"的 review 环节悄悄降级成"可以扫"的快速浏览，导致上线后的页面常常出现文案失真、信息密度错位、品牌一致性塌陷三类问题。

二、Vibe Coding 与传统 Prompt 工程的边界

在进入治理框架之前，有必要先把 Vibe Coding 这个概念和工程师熟悉的"传统 prompt 工程"做一个明确的边界划分。Vibe Coding 强调"以自然语言描述意图，由 Claude Code 这类 Coding Agent 自主完成 Plan → Build → Review 闭环"，而传统 prompt 工程更多停留在"人写代码、模型补全片段"的协作模式里。两者最关键的差异在于上下文载体从代码迁移到了 spec/blueprint。

[观察] 这张取舍矩阵的关键在于 review 粒度的迁移：Vibe Coding 把 review 的重心从"行级 diff"上移到"spec 级契约"，这意味着工程师必须先学会写 spec，才能真正用好 Agent。Spec 不再是产品经理的专利，而是工程师每天都要交的第一份产出。Spec 的质量直接决定了 Agent 第一轮产出的可信度，以及第二轮 review 的成本。

三、Slop 不是工具问题，是上下文缺失问题

社区里很容易把 slop 归罪于"模型不够强"或"工具不够好"，但这是一种偷懒的解释。[观察] 如果同样一套 Claude Code 配上不同的 spec 契约，产出的 UI 风格、信息密度、可维护性可以相差一个数量级以上——这说明 slop 的根因不在模型本身，而在输入到模型里的上下文质量。模型只是把工程师的上下文缺口"翻译"成视觉语言，缺口越大，翻译出来的 slop 越刺眼。

具体来说，缺失的上下文至少包含四层：

1. 业务上下文：这个页面服务于什么用户、解决什么痛点、转化漏斗在哪一环、目标 CTA 是什么。
2. 设计上下文：品牌色 token、字体家族、组件库、动效节奏、栅格系统、响应式断点。
3. 工程上下文:Next.js App Router 还是 Pages Router、Tailwind 还是 CSS Modules、shadcn/ui 还是 Radix 裸用、TypeScript 严格度。
4. 约束上下文：性能预算(LCP / INP / CLS 阈值，详见 https://web.dev/vitals/)、无障碍等级、SEO 元信息、可访问性文案长度。

四层上下文缺任何两层，Agent 都会用它的"先验"来补，而先验恰恰就是 slop 的来源。先验越强、上下文越弱，产出的页面越像"标准答案"——而"标准答案"从来都不是产品，只是模板。

四、五步治理框架：全篇索引

基于上述分析，本指南后续章节会围绕一个五步治理框架展开，这是阅读全篇的索引：

1. Spec 契约：把意图写成可被 Agent 解析的 blueprint，固化业务/设计/工程/约束四层上下文。
2. Plan mode 锁定：在 Claude Code 进入动手阶段前，先冻结方案，避免 Agent 在中途漂移。
3. Review mode 校验：用 diff + 测试(Vitest/Playwright)双轨验证 Agent 输出，详见 https://vitest.dev/guide/ 与 https://playwright.dev/docs/intro。
4. Context hygiene：管理 .env、token、context window，避免上下文污染与 token 泄漏。
5. 工程师角色翻转：从"写代码"转向"拆需求 + 编排工具"，让 Agent 流水线真正跑起来。

五步之间不是串行流水线，而是双环：外环是 Spec → Plan → Build → Deploy，内环是 Review → Test → Context hygiene。后续章节会按这个双环展开，本文先建立宏观心智。Claude Code 官方文档(https://docs.anthropic.com/en/docs/claude-code/overview)对 Plan mode 与 Review mode 也有原生支持，这是工具层与治理层的天然对齐。

五、一个最小可运行的 spec 示例

为了让"spec 契约"这个抽象概念落地，这里给出一段伪代码片段，展示工程师在动手前应该先交付的最小 spec:

# spec.hero.yaml — 单一事实来源
section: hero
intent: 让访客在 3 秒内理解"这是一个零基础 Vibe Coding 课程"
audience: 中文母语、非前端工程师、想用 Claude Code 上线第一个 Web App
constraints:
  framework: Next.js (App Router)
  styling: Tailwind CSS + shadcn/ui
  motion: Framer Motion,入场动画不超过 600ms
  budget:
    LCP: < 2.0s
    INP: < 200ms
copy:
  headline_max_chars: 18
  subheadline_max_chars: 48
  cta: "开始 23 分钟实战"
assets:
  hero_image: /public/hero.png (must be < 200KB)
i18n:
  default_locale: zh-CN
  fallback: en-US
review:
  owner: frontend-lead
  required_approvals: 1

这段 spec 是后续 Agent 调用的单一事实来源(single source of truth)，任何对 hero 区的修改都必须先回到这份 yaml。它不是 IDE 插件，不是 prompt 模板，而是工程纪律。Next.js 官方文档(https://nextjs.org/docs)也强调配置文件应该成为项目的"可读契约",spec 与此精神完全一致。

六、中国大陆工程师为什么要建立 spec 契约习惯

[数据] 对于中国大陆的工程师团队而言，spec 契约习惯的紧迫性比海外团队更高。原因有三：

1. 模型语境差异:Anthropic Claude、OpenAI GPT 系列在中文场景下的"先验审美"更倾向于国际化极简风，直接套用到中文产品上，容易出现"信息密度过低、转化文案过长、字号过小"的不匹配。一段 18 字符以内的英文 headline，翻译成中文往往要 24 字以上，如果 spec 里不显式声明 headline_max_chars,Agent 会按英文节奏裁剪，最终落到页面上就出现断行错乱。
2. 合规与备案：境内上线产品需要 ICP 备案、内容审核、可识别的开发者信息、必要的实名跳转链接，这些约束必须在 spec 阶段就被显式写入，否则 Agent 生成的页面会在 review 阶段被整段打回，造成返工成本指数级放大。
3. 团队协作粒度：国内多数团队仍以"前端 + 后端 + 产品"三段式分工为主，引入 Agent 后如果不先固化 spec 契约，最容易出现"前端用 Agent 写、后端看不懂、改不动、测试无法覆盖"的协作裂缝，反而把 Vibe Coding 的敏捷优势抵消殆尽。

因此，spec 契约不是可选项，而是引入 Vibe Coding 流水线前的硬性基础设施。本指南会在后续章节反复回到这个论点，把它当作不可妥协的工程基线。

七、锚定 2026：前端工程与 Agent 工程的融合方向

最后，把视野放到 2026 年的工程演进图景上。前端工程和 Agent 工程正在经历一次底层融合:

• 前端侧:Next.js App Router、Tailwind CSS、shadcn/ui 这套"工程化组件栈"已经稳定成为 Claude Code 的首选脚手架，React Server Components 与 streaming 渲染也逐步进入主流实践。
• Agent 侧:Model Context Protocol(MCP，详见 https://modelcontextprotocol.io/)正在成为 Agent 与外部工具对接的事实标准。GitHub MCP Server 仓库(https://github.com/modelcontextprotocol/servers)已经把仓库读写、PR 流转、issue 同步封装成标准 connector，让 Agent 可以直接操作真实仓库。
• 融合点：工程师不再区分"前端工程师"和"AI 工程师"，而是统一为 AI-Native Web Engineer——既懂 Web Vitals，又懂 token budget；既会写 Next.js 页面，又会编排 MCP connector；既会读 diff，又会写 spec。

[观察] 这场融合的胜负手，不在工具，而在工程师能否守住 spec 这条护城河。工具每个月都在换，但 spec 契约能力是十年级别的资产。建议读者把后续章节当作 spec 能力的训练营，而不仅仅是 Vibe Coding 工具教程。当你能稳定地写出可被 Agent 解析、可被人类 review、可被下游消费的三向契约，你就已经赢过了 80% 的 Vibe Coding 实践者。

Vibe Coding 五步法全景图

[观察] 把"做个 SaaS landing page"直接丢给 Claude Code / Cursor / Codex，几秒钟之内确实能拿到一份能跑起来的 Next.js 页面，但这条链路有一个非常隐蔽的代价——它输出的不是"产品"，而是 slop。同一个 prompt 在不同 session 里产出的 hero 区配色、卡片圆角、阴影强度、CTA 文案、字体层级高度雷同，因为这些 Agent 共享同一组默认视觉先验和训练分布里的高频模式。换句话说，你以为是 prompt 在驱动结果，实际上 prompt 只是在采样一条预训练里早就收敛好的均值路径。传统 prompt 直出的链路可以抽象为五段：用户短句 → Agent 默认系统提示 → 模板化脚手架(create-next-app、shadcn 默认主题、Tailwind 默认调色板) → 同质化输出 → 用户再补 prompt 微调 → 下一轮更深的同质化。这个循环每多走一次，系统就在视觉税的路上走得越远，而用户以为"自己在迭代"，其实只是在均值附近做布朗运动。

五步法拆解：从需求到可上线的语义闭环

把 vibe coding 从"随便聊聊"升级成工程流水线，关键在于把模糊意图强制收敛成可验证的中间产物。下面这套五步法把整个过程切成五个语义边界清晰的阶段，每一步都有自己的输入契约、输出契约和退出条件。

1. 访谈 (Interview)。这一步不是"开始写代码"，而是用结构化提问把业务背景、目标用户、关键场景、转化指标、视觉气质、可访问性约束全部问出来。Claude Code 的 Plan mode 在这一阶段最有用：它把对话从"代码生成"切到"需求澄清"，强制 Agent 先提问、再输出方案。访谈的核心输出是一份对话纪要 + 一份初步的 spec 草稿，而不是任何代码片段。提问的颗粒度决定了后续 Agent 自由发挥的空间——问得越细，slop 概率越低。

2. 克隆 (Clone)。拿到访谈结果后，需要选一个 reference——可以是同行业的成熟站点，也可以是设计师的 Figma，也可以是 GitHub 上的开源模板。Claude Code 在这一步通常会通过 GitHub MCP server(参考仓库 https://github.com/modelcontextprotocol/servers)直接 fork 或 clone 参考仓库，把它作为视觉锚点。这一步的关键不是"抄代码"，而是把参考站点的布局骨架、组件层级、信息密度、节奏感固化下来，作为后续合并的输入。参考仓库在这里承担"对照样本"的角色，而不是"复制源"。

3. 合并 (Merge)。把访谈纪要 + 克隆下来的参考代码放到同一个 spec.md 里，由 Agent 合并出第一版项目骨架。这里的合并是语义级别的：不是把两段 CSS 拼接起来，而是让 Agent 理解"我要做的产品"+“参考站点的样式语义”，然后用 Next.js + Tailwind + shadcn + Framer Motion 这套零基础组合重新生成。spec.md 此时第一次成型，文件结构大致包括：产品定位、目标用户、关键场景、页面清单、组件清单、视觉规范、动效清单、可访问性要求、上线标准九个章节。Next.js 项目骨架可以参考 https://nextjs.org/docs,Tailwind 规范参考 https://tailwindcss.com/docs。

4. 重构 (Refactor)。第一版骨架几乎肯定有冗余：命名不一致、组件职责混乱、动效过度、配色不收敛、重复 utility class。这一步让 Agent 主动删减、统一变量、抽公共组件，并通过 Vitest / Playwright 自动写测试，验证关键交互链路没被改坏。具体测试写法可以参考 Playwright 文档 https://playwright.dev/docs/intro 与 Vitest 文档 https://vitest.dev/guide/ 来约束。重构阶段不允许新增视觉特性，只允许删减和收敛。

5. 动画 (Animation)。最后一步才上动效。用 Framer Motion 在 hero、卡片悬浮、滚动揭示、菜单展开等位置加微动画，所有动效必须可被 prefers-reduced-motion 媒体查询关闭，避免动效叠加造成新的视觉税。动效是 spec.md 里独立的一节，而不是写到一半临时加的补丁——一旦允许 Agent 在重构阶段自由发挥动效，几乎一定会出现 hero 区自转动 + 按钮脉冲 + 卡片悬浮浮起三层动画叠加的低信号场景。

spec.md:Agent 行为的唯一真理源

[数据] 在 vibe coding 实践中，80% 以上的"返工"来自同一份需求被 Agent 以不同方式理解。spec.md 的作用就是把"口头意图"固化成一份机器可读、人类可审、人机共信的契约。它的最小骨架通常包括：产品定位、目标用户、关键场景、页面清单、组件清单、视觉规范、动效清单、可访问性要求、上线标准。任何后续的 prompt、Plan、Review 都必须以 spec.md 为锚点，Agent 不在 spec.md 之外做任何自由发挥。一旦 spec.md 写定，Claude Code 的 Plan mode、Cursor 的 spec 视图、Codex CLI 的 --spec 参数都可以直接消费它，跨 Agent 复用性极高；团队里新加入的工程师也只需要读懂 spec.md，就能判断后续每个 PR 是否偏离了原始意图。

spec-driven vs copy-paste 范式

对比之下，spec-driven 范式把"知识"从 Agent 的大脑里搬到仓库里，让 vibe coding 第一次具备工程意义上的可审计性。

多工作树并行，避开文件冲突

Vibe coding 的一个反直觉点：同时让 Agent 在多个 worktree 里推进，比串行推进更安全。每个 worktree 绑定一个子任务(例如 worktree-A 负责 hero,worktree-B 负责 pricing,worktree-C 负责 FAQ),Agent 在各自目录里只读共享 spec.md，只写自己的文件子树。这样做有三个收益：第一，文件冲突被隔离在边界内，不同 Agent 不会互相覆盖对方的产物；第二，任意一个 worktree 翻车可以直接丢弃而不影响主线；第三，review 可以并行进行，合并时通过 PR 走 GitHub Actions 校验，流程参考 https://docs.github.com/en/actions。Claude Code 的工作目录切换、Cursor 的 workspace 隔离、Codex CLI 的 worktree 参数都支持这种模式，具体可以参考 Claude Code 文档 https://docs.anthropic.com/en/docs/claude-code/overview。

治理闭环：可复用模板

# 1. 锁定 spec
$ claude --version          # 自检 Agent 状态
$ claude doctor            # 鉴权 + MCP 连接性自检
$ cat spec.md | claude     # 把 spec 作为唯一上下文喂入

# 2. 多 worktree 并行
$ git worktree add ../wt-hero    -b feat/hero
$ git worktree add ../wt-pricing -b feat/pricing
$ git worktree add ../wt-faq     -b feat/faq

# 3. 每个 worktree 内独立 Plan -> Build -> Review
$ cd ../wt-hero
$ claude "按 spec.md 实现 hero,完成后跑 vitest"

# 4. 合并回主线 + 自动化校验
$ git checkout main
$ git merge feat/hero feat/pricing feat/faq
$ gh pr create --base main --title "vibe: 五步法首版"
$ gh pr checks watch       # 等 GitHub Actions 全绿

[观察] 这套治理闭环的核心不是"用哪个 Agent"，而是"谁拥有上下文"。spec.md 的 owner 是人，不是 Agent——人决定要不要更新 spec,Agent 只能消费 spec。这种权力分配让 vibe coding 摆脱了"prompt 漂移"的恶性循环，也让团队里的非工程师可以无门槛参与 review，因为他们只需要读懂 spec.md，不需要读懂 React 组件树。当 spec.md 成为团队唯一的真理源，五步法就从个人技巧升级成可治理、可复盘、可交接的工程流程——这正是 vibe coding 从"玩具"走向"产线"的分水岭。

环境前置： Claude Code / Codex CLI 与 Skill 体系

[观察] Skill 体系已经成了 Agent 工程化的事实标准。把同一段"做个 SaaS landing page"的 prompt 分别丢给 Claude Code、Codex CLI、Cursor、Copilot，四家产品在语义层都能理解你的意图，但在工程层走出的是四条截然不同的路径：Claude Code 与 Codex CLI 站在命令行这一侧，把 Agent 视作"可读写本地文件系统的长驻子进程";Cursor 与 Copilot 站在 IDE 这一侧，把 Agent 嵌进编辑器面板、强调 inline edit 的低延迟。Skill 本质是一组带 YAML frontmatter 的 Markdown 文件，运行时把它识别成"可调用的工具/上下文片段"——这是一种把"系统提示词"从源码里抽出来，变成可版本管理、可团队复用的工程产物。理解了这一点，就不会再把 Skill 当作"几条提示词模板"的浅层玩具，而会意识到它是把"模型 → 行动"链路里所有副作用统一接管的中枢层。

Claude Code 与 Codex CLI 的运行时差异

Claude Code 与 Codex CLI 都遵循"CLI-first"的哲学，但细节差异很多，值得在动手前先固化一份对比清单，免得排错时把 A 的报错信息套到 B 上：

这两个 CLI 的"运行时"都不只是一个聊天 REPL(read-eval-print loop)，而是同时跑着文件监听、shell sandbox、token budget 计量、上下文窗口压缩几个独立进程。把它们当 IDE 替代品的工程师通常在第一周就会被"它为什么会自动跑 npm install"吓到——答案是它们默认带了一套受控的 subprocess 权限，需要用 /permissions 或 ~/.claude/settings.json 显式收紧。对比 这两条 CLI:Claude Code 把 plan 模式抬到了命令行一等公民的位置，适合"先讨论、再动手"的工程节奏；Codex CLI 默认更偏 search-then-edit 的轻量路径，适合小步快跑的 snippet 迭代。

Skill 的安装目录与触发机制

Skill 在 Claude Code 里的安装路径有三种 scope:

1. User scope — ~/.claude/skills/<skill-name>/SKILL.md，对当前用户的所有项目生效
2. Project scope — <repo>/.claude/skills/<skill-name>/SKILL.md，随仓库走，适合团队共享
3. Plugin scope — 通过 claude plugin install <plugin-id> 装载，目录落在 ~/.claude/plugins/<id>/skills/

每条 Skill 都是一个目录，目录里至少要有 SKILL.md(运行时识别的入口 manifest)，可选地附带 manifest.json、examples/、scripts/、references/。SKILL.md 的 frontmatter 用 YAML 写触发条件与权限白名单：

---
name: nextjs-scaffold
description: 当用户描述"做一个落地页 / SaaS / 营销页"时,按 App Router + Tailwind + shadcn 组合脚手架
trigger: "(?i)landing|saas|landing page"
tools: [bash, write_file, read_file]
allowed_paths:
  - "./**"
requires_binaries: [node, npm]
---

触发机制分两层：L1 是按正则/关键词匹配的"显式触发",L2 是 Agent 在 plan 阶段根据上下文推断的"隐式触发"。当用户输入命中某个 Skill 的 trigger 字段，运行时就把该 Skill 的全文注入 system prompt 再喂给模型；否则 Agent 会基于 LLM 自身判断去 load_skill('nextjs-scaffold')。后者才是 Skill 真正的工程价值——它把"调用哪一个 Skill"变成一个可被审计、可被回滚、可被 diff 的决策，而不是塞在 system prompt 里的死字符串。

~/.claude/skills 的目录约定

把 ~/.claude/ 展开，通常会长成这样：

~/.claude/
├── settings.json          # 全局偏好:model、theme、permissions
├── skills/                # User scope Skill 集合
│   ├── nextjs-scaffold/
│   │   ├── SKILL.md       # manifest + body
│   │   ├── manifest.json  # 可选:工具白名单 / 依赖声明
│   │   └── references/    # 可选:外部文档快照
│   ├── pr-review/
│   ├── git-commit-helper/
│   └── deploy-vercel/
├── commands/              # Slash Command 集合(短模板,非 Skill)
└── plugins/               # 插件缓存目录

settings.json 是 Claude Code 引入的"项目无关配置"，常用字段包括 default_model、permission_mode(autoaccept / safe / plan)、mcp_servers。与 Cursor 的 settings(JSONC，带注释)不同，Claude Code 走的是严格 JSON，这一选择直接堵死了"在配置里留笔记"的习惯，需要在仓库里另开 docs/agent-config.md。踩坑提醒：升级 CLI 大版本时，settings.json 偶尔会出现字段弃用(例如 model → default_model)，用 claude doctor 一次性 export 出迁移报告比手动 diff 稳得多。

本教程需要的 Skill 集合

围绕"零基础 Vibe Coding 落地页"这条主线，讲师在课程里固化了一套最小 Skill 集合，作为后续 17 节的底座：

[数据] 一份公开的社区调研数据显示，把 Skill 数量控制在 6–10 条以内的项目，其 prompt-cache 命中率(重复前缀被缓存的比例)平均比"塞了 30+ 条 Skill"的项目高 2–3 倍。原因在于 Skill 在每次 turn 都会被完整 prepend 到 system prompt，体积越大，cached token 的有效占比就越低，反而拉高了单次会话的计费成本。取舍 因此本教程坚持"小而精"原则——能用 commands/ 表达的简单 /template 模板，不升级成 Skill；能用 script 一次跑完的固定步骤，不进入 Skill 库。

MCP 集成 vs 原生 API 调用

到了"让 Agent 操作 GitHub"这一步，工程师面前会出现两条路：直接通过 gh CLI 或 REST API 调用，或者通过 GitHub MCP Server 暴露成 Model Context Protocol 工具。这两条路在工程上有清晰的取舍边界：

团队规模小、脚本可读性优先，选 gh + shell 拼装更轻；团队规模上来、需要"工具调用审计 / 跨 Agent 复用 / Token 泄漏面收敛"，就上 MCP。本教程默认走 MCP，核心理由就是把"GitHub token"从 Agent 上下文里彻底移出去——token 只出现在 MCP server 的子进程环境里，而不会进入 prompt 的任何位置。权衡 这一选择的代价是引入了一个新的常驻进程与一份 manifest 配置，需要在 settings.json 的 mcp_servers 字段里显式声明，版本升级时也要留意 schema 兼容性。

官方文档入口：

• Claude Code 总览： https://docs.anthropic.com/en/docs/claude-code/overview
• Model Context Protocol: https://modelcontextprotocol.io/
• GitHub MCP Server 仓库： https://github.com/modelcontextprotocol/servers

把 Skill 体系、CLI 运行时差异、MCP 集成边界这三件事前置理清，后面 17 节里任何"为什么 Agent 这样改文件"、“为什么这次部署没带上环境变量”、"为什么 token 突然出现在 diff 里"的疑问，都能回到这一节的配置层找到根因。环境前置不是开场仪式，而是把后续每一节的排错时间从小时级压回分钟级的杠杆点。

第一步 Grilling Me Session: 把需求问到底

[观察] Skill 体系已经成了 Agent 工程化的事实标准——上一节我们看到了 Claude Code、Codex CLI、Cursor、Copilot 走出四条截然不同的工程路径。但即便选定了 Claude Code 这条命令行长驻子进程的路线，真正决定后续十几个小时是顺畅还是返工的，往往不是模型多聪明，而是你在第一轮对话里把产品意图"问"出来多少。一个典型的反模式是这样的：用户对着 Claude Code 抛出一句"帮我做一个 SaaS landing page，要有 Hero、Features、Pricing、FAQ、Contact，加上暗色主题"，然后期待 Agent 直接出活。问题在于，这句话在语义层确实可执行，但在工程层它同时塞进了至少五类尚未对齐的决策——目标用户是谁、Mock 数据长什么样、技术栈默认选哪个、v1 必须包含哪些范围、可放弃哪些后续功能。Claude Code 默认开启的 Plan mode 不会替你做这些选择，它会按字面意思去规划，然后在某个环节撞上模糊地带再回头追问，代价是后续每一步都带着前一步的歧义。

把这种"事后澄清"前移到开工之前，就是 grilling-me Skill 的设计动机。grilling-me 并不是一个全知全能的需求收集器，它的工作模式非常克制：每次只抛出一道题，等待用户的明确回答，再基于上一题的回答动态生成下一题，直到四条主线——目标用户、Mock 数据、技术栈、v1 范围——都被覆盖。它把"一次性把需求塞进 prompt"的工作模式，拆成了"一段有节奏的对话"，而这段对话本身是可被反复重放、被复盘、被审计的资产。

触发这个 Skill 的成本极低。在 Claude Code 中，你可以把它注册为一个 slash command(参考 Slash Commands 文档 https://docs.anthropic.com/en/docs/claude-code/slash-commands)，用一句话就能唤起整条追问链路，而 Skill 内部的伪代码骨架大致如下：

def grilling_me(initial_prompt):
    # Step 1: parse initial intent, do NOT start coding
    intent = parse_intent(initial_prompt)
    
    # Step 2: enforce 4 mandatory dimensions, no skip allowed
    for dimension in ["users", "mock_data", "stack", "v1_scope"]:
        answer = ask(dimension)            # refuse empty / "TBD" answers
        record[dimension] = answer
    
    # Step 3: dynamic follow-ups based on prior answers
    while has_ambiguity(record):
        followup = next_question(record)
        record[followup.topic] = ask(followup)
    
    return record  # contract for Plan mode

实际触发时只需要一行命令：

/grilling-me 我想做一个面向独立开发者的 SaaS landing page

Skill 收到这句话之后，并不会立刻开始写代码，也不会先给出一个大而全的方案。它会从"目标用户"这一维度切入，问出第一个明确问题——例如"请用一句话描述你理想的首批付费用户是谁"。回答完之后，它再切到"Mock 数据"维度，问"在 Hero 区域你希望展示什么形式的社会化证明？是用户数、营收数字、还是客户 logo"。接下来是"技术栈"维度，问"是否已经有偏好？Next.js + Tailwind + shadcn 是否可接受？是否需要 Framer Motion 做动效"。最后是"v1 范围"维度，问"在 Hero、Features、Pricing、Contact、FAQ 这五件套里，哪几块 v1 必须上线，哪几块可以留到 v2"。整条链路里，Skill 不会替你脑补答案，也不会跳过任何一题。

典型覆盖顺序与每轮议题对照表

需要强调的是，grilling-me 的纪律里有一条硬规则：任何一题都不允许跳过。原因很简单——如果跳过"目标用户"这一题，后面所有 Hero 文案、Features 卖点、Pricing 套餐命名都会失去锚点；如果跳过"Mock 数据",Agent 写出来的 Pricing 三档套餐价格可能是随机的、毫无业务含义；如果跳过"技术栈",Agent 可能默认选择一套与你本地环境、部署目标冲突的方案，例如你想部署到 Cloudflare Pages 但它默认假设 Vercel；如果跳过"v1 范围"，你会得到一份"五件套全做"的膨胀 plan，而你真正想要的往往只是一个能上线分享的最小版本。每一道题都是一个工程决策的"前置签字"，签字不全，后面所有步骤都建立在浮空之上。

[数据] 在该教程配套的实践里，一次完整的 grilling-me Session 通常落在 8 到 12 轮对话之间，平均完成时间约 6 到 9 分钟。最短的一类用例(用户对自己的产品已经想了很久、目标用户与 v1 范围都极清晰)可以在 4 轮内结束；最长的一类用例(用户尚未对目标用户画像形成稳定判断，需要在 Skill 追问中现场厘清)会拉到 14 轮以上。值得注意的是，跳过任何一题从短期看会"省"一轮对话，但从后续 plan → build → review 的总时长看，平均会多消耗 1.5 到 3 倍的返工时间——因为 Agent 会在某个下游环节因为模糊地带再次追问，届时你回答的不仅是缺失的那一题，还要修正前几轮基于错误前提做出的承诺。

把 grilling-me 视为"开工前的合同对齐"，而不是"额外的成本"，是工程师角色翻转里最关键的一个认知转折。在传统工程师的工作流里，需求澄清发生在 PM 与开发之间的人际会议中，产物是一份 PRD 或 ticket；在 Vibe Coding 的工作流里，需求澄清发生在工程师与 Agent 的对话里，产物是一段结构化的、可被 Skill 二次调用的会话记录。这两种工作流里，澄清环节都没有消失，只是被挪了一个位置——挪到了更早、更便宜、更可回放的时段。

Grilling-Me Session vs 一次性 Prompt 的取舍

两种路径并非互斥。一个成熟的 Vibe Coding 实践通常是这样：先用一次性 prompt 做 5 到 15 分钟的"概念验证烟雾测试"，确认 Agent 能理解你想要的整体形态；如果概念验证通过，再回到 grilling-me Session 走一遍正式开工前的需求对齐。这种"先烟雾测试、再正式对齐"的两段式策略，既保留了快速探索的灵活性，又规避了直接开工带来的歧义成本。

实操时还需要注意几个容易踩的坑。第一，不要在 grilling-me 还没走完就急于让 Agent 进入 Plan mode 出方案——你给它的信息越少，Plan 的可执行性就越差，后续 build 阶段会反复推翻自己。第二，回答 grilling-me 的问题时尽量给出"可被代码直接消费的"答案，而不是"我希望感觉专业一点"这种无法落到组件 props 层面的描述。例如回答 Pricing 套餐命名，直接给出"Starter / Pro / Scale"远比"三个档位、第二个最划算"更容易被 Agent 翻译成 Pricing 组件的 tier 数组。第三，如果某一道题你确实没想好，正确的做法是在答案里显式标注"暂时未定，倾向 X，但需要进一步验证"，而不是留空——留空等于授权 Agent 自行脑补，这与 grilling-me 的纪律是直接冲突的。第四，不要把 grilling-me 的输出当成一锤子买卖：在 Plan mode 出方案之后，如果某道题出现理解偏差，应该回到 grilling-me 重做那一题，而不是允许 Agent 在 Plan 里"替你想清楚"。

最后，grilling-me 产出的对话记录本身也是一份可被复用的资产。在后续的 Plan mode、build 阶段、review 阶段，你都可以引用 grilling-me 的某一题作为决策依据，例如"按 grilling-me 第 4 题约定，v1 不包含 FAQ 页"。这种"显式回引"会让你的 Vibe Coding 工作流具备传统软件工程里 spec / blueprint 的可追溯性，而不是一份永远漂浮的 prompt 历史。更多关于 Claude Code 工作模式的设计哲学，可以参考 Claude Code 总览文档 https://docs.anthropic.com/en/docs/claude-code/overview;关于 Skill 与 MCP 标准协议的关系，可以参考 Model Context Protocol 官方文档 https://modelcontextprotocol.io/。

把"把需求问到底"作为开工第一步，看起来慢，但它换回来的是后十几个小时的确定性。grilling-me 不是一次性的负担，而是一种可以反复重放、可以团队复用、可以在 review 时被逐题追溯的需求契约。接受这个纪律之后，后续的 Plan → Build → Review 闭环才真正有了"对齐基线"。

decisions.md 与 spec.md: 长会话的工程契约

[观察] 长 Agent 会话最大的失败模式不是模型推理能力不够，而是上下文蒸发。当 Claude Code 这种命令行长驻子进程在十几个小时、几百轮对话中持续累积，最早的需求陈述、设计抉择、用户偏好往往被压缩、遗忘，甚至被误读成"另一种语义"。补救成本远大于预防成本——一旦用户发现"Agent 做出来的东西跟我最初想要的不一样"，已经可能是第 80 轮的 commit，回滚要重写一整周的对话历史。把"产品意图"在前几轮就固化到磁盘上的工程契约里，是零基础用户唯一能仰仗的对冲手段。

decisions.md 与 spec.md 的角色差异，本质上是 git log 与 README 的关系。decisions.md 是逐字的会话日志，每一轮产生一条记录：谁提了什么、Agent 给出的方案、用户为什么回退、最终采纳哪个版本。它不对内容做二次加工，只保证事实可回溯，任何被涂改过的字段都会破坏审计链。spec.md 则是被聚合、剪裁、抽象后的"当前真相"：同一份产品意图，在第 1 轮、第 50 轮、第 200 轮被反复陈述后，只保留一份被同步进项目仓库的工程契约。spec.md 才是下游所有 Skill 真正消费的输入，decisions.md 只是它的"考古层"。

为了让 decisions.md 的追加过程机械可执行，推荐把每一条决策都固化成结构化字段，而不是写散文。下面的字段集合在 Vibe Coding 工作流里被验证足够覆盖 90% 的工程场景：

id 字段的设计动机是让 spec.md 可以用 D-0042 这种短引用回链到 decisions.md，而不是写一大段自然语言引用，这一招在长会话后期能把 spec 的"决策摘要"章节保持精简。owner 字段看似多余，实则解决了"用户没说就是 Agent 自己定的"这种责任真空——一旦某个决策后续导致返工，可以直接追责到具体某一方。

接下来给出 spec.md 的最小章节模板。它在 Vibe Coding 工作流中应当位于仓库根目录、与 package.json 平级，任何子目录里的 spec.md 都会被 Claude Code 误以为是局部规范：

# spec.md — 项目工程契约

## 1. 产品意图
- 一句话定位
- 目标用户画像
- 验收标准(用户能做什么)

## 2. 技术栈
- Agent: Claude Code
- 框架: Next.js (App Router)
- 样式: Tailwind CSS + shadcn/ui
- 动效: Framer Motion
- 部署: Vercel

## 3. 页面清单
- Hero / Features / Pricing / FAQ / Contact

## 4. 决策摘要
- 引用 decisions.md 中编号为 D-XXXX 的条目

## 5. 已冻结规则
- 不引入付费 SaaS 依赖
- .