我把 Grill Me 搬进了浏览器：grill-me-html

你肯定用过这种需求对齐。

你对 agent 说：“给博客加评论。”它不立刻写代码，而是开始问：谁能发？要不要登录？嵌套几层？先发后审还是先审后发？第三方还是自建？

这套方法有用。Matt Pocock 的 Grill Me 先把“需求还没对齐，AI 已经写完了”这件事钉死；后来的 Batch Grill Me 又把 13 题从 13 轮压到大约 3 轮。

但我自己用久了，还是会烦。

不是问题不好，是交互形态不对。

一次一问，注意力被切碎。分轮批量后，终端里又会甩出一长串文字选项：推荐、理由、A/B/C/D。视觉决策尤其难受——导航用侧边栏还是顶栏、架构是模块化单体还是拆服务，全靠文字脑补。答到后面，你不是在拍板，是在尽快结束。

所以我做了一个 skill：

它保留 design tree 和 frontier，但把每一轮 frontier 做成浏览器里的自适应问卷。你点选项、看 preview、Review 一遍，点 Submit round。agent 自动读答案，推下一轮。frontier 清空后，再给你一页 shared-understanding，确认完才动手。

grill-me-html

一个把需求/设计拷问做成自适应 HTML 问卷的 Agent Skill。按 design tree 的 frontier 分轮提问，支持 soft branching、推荐答案、preview 预览题，以及结束前的 shared-understanding 确认页。

来源: GitHub前往

为什么聊天里对齐，会越对齐越累

手绘信息图：聊天对齐越来越累，三个问题是形态单一、状态不稳、提交路径脆 — 聊天对齐的三个硬伤：形态单一、状态不稳、提交路径脆。

Grill Me 解决的是“猜”。Batch Grill Me 解决的是“慢”。

它们都还没解决第三个问题：决策界面本身。

聊天问答有三个硬伤：

形态单一。 所有决策都长成一段文字。产品边界可以，布局和架构不行。
状态不稳。 长轮次里，你很难一眼看到“这一轮到底要拍哪几件事”。
提交路径脆。 复制 JSON、粘贴回聊天、再说“继续”，任何一步都可能断。

我真正想要的交互更像这样：

这一轮只问现在能问的 frontier
每题有推荐答案
视觉决策能看见 mock
我在浏览器里答完
点一次 Submit
agent 自己继续
最后有一页共识文档让我确认

grill-me-html 就是按这条链路做的。

它继承了什么，又改了什么

手绘对比图：从一次一问、分轮批量，到浏览器问卷 — 同一棵 design tree，载体从聊天一次一问、分轮批量，换到浏览器问卷。

先说继承。

它没有发明新的需求方法论，核心还是 Matt 那套：

概念	含义
design tree	把方案拆成有依赖关系的决策树
frontier	前置条件已定、现在就能问的那一层
recommended	每题给推荐，你是在审核，不是从零发明
先共识再实现	没确认前，不要动手写代码

再说改动。

Batch Grill Me 把“一次一问”改成“一轮问完当前 frontier”。grill-me-html 再往前走一步：

同一套 frontier 逻辑，换一个载体。

载体从终端聊天，换成离线 HTML 问卷
题型从 single / multi，加上 preview
结束方式从聊天总结，换成 shared-understanding.html
提交方式从粘贴 JSON，换成本地 waiter 自动回收答案

如果你已经读过前面两篇，这篇可以当续篇看：

Grill Me          一次一问，逼出 design concept
Batch Grill Me    按 frontier 分轮，减少来回
grill-me-html     把 frontier 做成浏览器问卷，并补上视觉决策和确认页

一轮长什么样

打开后，不是聊天泡泡，而是一张问卷页。

顶部是 round 标题和进度，中间是当前问题，下面是选项。推荐答案会标出来。你选完后，选项有明确的 selected 状态，不是“好像点了又好像没点”。

grill-me-html 问卷页：左侧进度与问题列表，中间是当前问题与推荐选项 — Round 页只展示当前 frontier，不会把整棵树一次性砸过来。

一轮通常 4 到 8 题。中途可以 Review，最后一题后进入答案总览。确认无误再点 Submit round。

Review 页汇总本轮答案，并提供 Submit round 按钮 — Review 不是摆设。它逼你在提交前再扫一眼：有没有随手点了推荐项。

关键能力一：preview，让选项能被看见

这是我做这个 skill 时最在意的一点。

很多决策不是“选一个标签”就能拍板的。比如：

桌面导航用侧边栏还是顶栏
信息架构怎么铺
评论系统用单体、模块化单体，还是拆服务

这些问题如果只给文字 description，人会用自己脑内的默认图去填空。你以为大家选的是同一个“侧边栏”，其实画面完全不一样。

所以 grill-me-html 加了 type: "preview"。

左边还是选项列表，右边是预览面板。悬停或聚焦时更新预览，点击才提交选择。preview 可以是 ASCII / 文本权衡，也可以是离线 HTML 线框。HTML 预览跑在 sandbox iframe 里，不执行脚本，不依赖 CDN。

架构选择的 preview 题：左侧选项，右侧实时系统图预览 — 架构题最适合 preview。你比较的不是三个词，而是三张系统图。

规则也很死：

preview 题的每个 option 都必须有非空 preview 文本
只有 description 不够
抽象政策题继续用 single / multi，别强行套预览壳

一句话说：

能看见再选的，就别逼人脑补。

关键能力二：Submit 之后，agent 怎么自动继续

手绘流程图：提交后写回本地、退出 0，代理终端自动继续下一轮 — Submit 不是 magically 唤醒模型，而是前台 waiter 写回 answers 后退出 0。

这是很多人第一眼会问的：浏览器点了提交，聊天里的 agent 怎么知道？

答案很无聊，但必须讲清楚：

浏览器本身唤不醒一个空闲 agent。

所以 grill-me-html 不依赖某个平台私有事件总线，而是用一个可移植的 foreground wait contract：

agent 前台跑 run-round.mjs（长超时）
浏览器打开问卷
你点 Submit round
本地 waiter 写出 answers-XX.json
进程退出 0，打印 RESULT {...}
agent 因为 tool call 结束而恢复
立刻读答案，重算 tree，开下一轮

对应命令：

node "$SKILL_DIR/scripts/run-round.mjs" \
  --round 1 \
  --config .grill-me-html/config-01.json

它会：

把 config 注入问卷模板
写出 .grill-me-html/round-01.html
打开浏览器 / 起本地服务
阻塞等待 Submit
写出 .grill-me-html/answers-01.json
打印 RESULT {...} 并退出 0

这套东西在 Pi、Claude Code、Cursor、Codex 里都能跑，前提只有一个：agent 能跑长时间前台命令。

两个硬规则：

不要 background waiter。 一后台，Submit 只写文件，没人接着干。
exit 0 后不要再问“提交了吗”。 直接读 answers，继续。

只有 waiter 跑不起来时，才退回 Copy JSON 粘贴。

关键能力三：结束不是聊天总结，是确认页

frontier 空了，不该直接开写。

很多“对齐过了”的翻车，其实翻在最后一公里：聊天里散落着 3 轮答案，没有人把它们收成一张可确认的决策表。你以为双方理解一致，其实对“已决定”和“还在假设”的边界并不一样。

所以 grill-me-html 在收尾时会生成 shared-understanding.html：

一段共享理解摘要
已拍板决策列表
影响和下一步
仍未关闭的问题（如果有）

shared-understanding 最终确认页，汇总决策与下一步 — 先打开这页，等人明确说“可以做了”，再实现。这是 skill 的最后一道闸。

生成方式：

node "$SKILL_DIR/scripts/build-summary.mjs" \
  --config .grill-me-html/summary.json \
  --out .grill-me-html/shared-understanding.html \
  --open

我自己的使用纪律很简单：

没有确认 shared understanding，就不写代码。

和 Grill Me / Batch Grill Me 怎么选

	Grill Me	Batch Grill Me	grill-me-html
载体	聊天，一次一题	聊天，分轮批量	浏览器问卷
依赖处理	串行走	frontier 分层	frontier 分层 + soft branching
视觉决策	弱	弱	强（preview）
提交路径	聊回去	聊回去	Submit 写本地文件
收尾	聊天总结	聊天总结	shared-understanding 页
更适合	树根不清，关键分歧要单独钉死	方向清楚，细节多，终端里快速过	决策多、有布局/架构/流程选择，想要可点可选可确认

我的经验是：

还在找最大分歧：先 Grill Me
方向清楚、只想快过细节：Batch Grill Me 够用
决策里有“必须看见才敢选”的内容，或者你已经厌烦聊天问卷：上 grill-me-html

三者不是互相取代，是同一条链上的不同界面。

怎么安装

npx skills add wuyuxiangX/grill-me-html -y

全局安装：

npx skills add wuyuxiangX/grill-me-html -g -y

要求很轻：

Node.js 18+
能跑长时间前台命令的 coding agent
本机能开浏览器

然后直接说：

用 grill-me-html 拷问一下这个方案

或者把计划丢给它，让它从 design tree 第一层 frontier 开始。

仓库在这里：

grill-me-html 源码仓库

把 design interview 做成自适应 HTML 问卷的 Agent Skill。

wuyuxiangGitHub2026-07

前往

我现在怎么看这件事

AI 编程这波里，大家很容易把注意力放在“写得更快”。

但真正贵的，往往不是生成代码的那几分钟，而是生成错方向后的返工。Grill Me 系列有价值，是因为它逼你在动手前先承认：你以为清楚的需求，其实到处是空洞。

grill-me-html 想补的，是下一层体验问题：

对齐不该只发生在聊天泡沫里。

当决策变多，当选项需要被看见，当提交后还要自动推进，问卷这种老形态反而更合适。不是因为 HTML 更酷，而是因为它更接近真实产品决策：比较、选择、复查、确认。

如果你已经在用 Grill Me 或 Batch Grill Me，直接拿一个真实需求跑一轮就够了。不必先背 schema。

你会很快知道自己卡在哪：

卡在不会问，那是方法论问题
卡在问完了却选不动，那往往是界面问题

后者，正是我做 grill-me-html 的原因。

常见问题

Q: grill-me-html 是什么？
A: 一个把 design tree frontier 拷问做成浏览器问卷的 Agent Skill。 支持推荐答案、soft branching、preview 预览题、Submit 自动回写，以及结束前的 shared-understanding 确认页。

Q: 它和 Batch Grill Me 什么关系？
A: 方法论兼容，载体不同。 Batch Grill Me 在聊天里按 frontier 分轮问；grill-me-html 把同一层逻辑做成 HTML 问卷，并补上视觉预览和最终确认页。

Q: 为什么点了 Submit，agent 就能继续？
A: 因为 agent 前台阻塞在 run-round.mjs 上。 Submit 写出 answers 文件后进程退出 0，agent 恢复执行并读结果。这不是浏览器 magically 唤醒模型，而是 foreground wait contract。

Q: 什么时候该用 preview 题？
A: 当选项需要被看见时。 UI 布局、信息架构、架构图、before/after 交互模型都适合；纯政策选择题继续用 single/multi。

Q: 可以不经过确认页直接开写吗？
A: 技术上可以，流程上不该。 skill 的默认纪律是：frontier 清空后先生成 shared-understanding，等人确认，再实现。