OpenFlow 加了 grill-me：让 AI 先质疑，再执行

OpenFlow v0.4.0 新增 grill-me：不是多一步流程，而是让 AI 在写 spec 前先拷问需求。

上周我改 OpenFlow 的时候，脑子里一直有个很烦的问题。

AI 编程真的缺一个更强的模型吗？

不对。

至少我这几个月的体感不是这样。Claude、Codex、Cursor 这些工具已经够强了。强到什么程度？你给一个清楚的 plan，它真的能一路把测试、实现、修复、验证跑下来。

可问题偏偏出在前面。

很多项目不是死在 coding。是死在 coding 之前，那一坨还没被说清楚的需求里。

你以为自己在让 AI 写代码，其实你是在让 AI 猜谜。

这就很离谱。

所以 OpenFlow 0.4.0 加了一个新阶段：/openflow grill。

名字有点不正经，但它干的事非常严肃：在进入 spec 之前，先把 proposal 拎出来拷问一遍。

AI 编程最怕的不是慢，是太顺

很多人第一次用 AI 编程流水线，会迷恋那种顺滑感。

需求一写，AI 点点头。

spec 一生成，AI 点点头。

代码一开写，AI 继续点点头。

看起来很爽。

但有时候，太顺了反而可怕。像一个没有安检的机场，大家一路小跑登机，直到飞机起飞后才发现行李舱里塞了个不该塞的东西。

我见过太多这种场景：

• 需求里写「支持用户配置」，但没说默认值怎么处理；
• 方案里写「复用现有模块」，但没确认现有模块有没有副作用；
• spec 里写「失败时提示错误」，但没定义哪些错误可重试、哪些错误要中断；
• build 到一半才发现，原来这个需求会改公共 API。

然后 AI 就开始补洞。

补得挺勤快。

也挺吓人。

因为它每补一个洞，都可能顺手挖一个新洞。

OpenFlow 之前已经把 OpenSpec 和 Superpowers 串起来了：OpenSpec 管需求规格，Superpowers 管工程执行，OpenFlow 负责中间翻译。

这个思路没变。

但 0.4.0 补上了一个更像「质检」的环节。

不是让流程更长。

是让流程别那么糊弄。

grill-me 到底在 grill 什么？

/openflow grill 做的事很简单：proposal 或 brainstorming 产出 proposal.md 后，进入 spec 前，AI 会开始反向追问。

不是泛泛地问「你确定吗」。

那没用。

它会抓四类问题。

第一类，隐藏假设。

比如你写「默认启用新流程」。grill 会追问：老用户也默认启用吗？已有配置冲突怎么办？如果用户之前手动关过，要不要尊重旧设置？

这类问题最烦。

也最值钱。

因为它专门戳那种你不想面对的地方。说难听点，很多返工就是从这里开始烂掉的。

第二类，边界情况。

比如「生成 plan-ready.md」。那如果 OpenSpec CLI 不存在呢？如果 Superpowers 没装呢？如果已有 plan-ready.md，但内容过期呢？

别笑。

真实项目里，很多 bug 就是这种「应该不会吧」长出来的。

第三类，方案取舍。

A 更安全，但慢。B 更快，但可能隐藏风险。grill 不会假装世界上只有一个正确答案，它会逼你选。

这一步很不舒服。可不舒服才对。舒服的方案评审，通常只是礼貌互相糊弄。

第四类，现有系统冲突。

这个最像老工程师坐在旁边皱眉：你这个改法，跟之前那个模块的行为是不是打架？

嗯。

这句话我太熟了。

0.4.0 最关键的改动：不是新增命令，是新增“刹车”

OpenFlow 0.4.0 的 changelog 里有三条核心更新：

• 新增可选的 grill-me gate；
• bare /openflow 和直接 /openflow spec 不能再悄悄进入 spec，必须先处理 grill 选择；
• 为生成的 skill 指令补了回归测试，确保多工具目标里这套逻辑不会丢。

听起来像工程细节。

其实这是产品判断。

过去很多工具的问题是：它把「跳过评审」设计成默认路径，把「停下来想想」设计成额外操作。

人当然会跳过。

人类很懒。开发者更懒。凌晨两点的开发者——算了，那已经不是懒，是求生。

OpenFlow 0.4.0 把这个路径反过来了：

你可以跳过 grill。

但你要明确地跳过。

这个差别很小，也很狠。

像提交 PR 前的 checklist。你当然可以不测，但当系统把「是否已验证」摆到你眼前时，你心里会咯噔一下。

/openflow grill 就是这个咯噔。

一次只问一个问题，而且 AI 必须先给建议

我不喜欢那种把问题甩给用户的 AI。

「请确认 A、B、C、D、E、F、G 是否符合预期？」

看着就烦。

你到底是助手，还是问卷星？

所以 grill-me 有两个硬规则。

第一，一次只问一个问题。

它不会把 12 个风险点一口气砸过来。它会像一个认真但有点烦的 reviewer，一次卡一个关键点。

第二，每个问题必须带 AI 推荐答案和理由。

不是只问：

失败时是否需要回滚？

而是问：

失败时是否需要回滚？我的推荐是：需要回滚用户可见状态，但保留调试日志。理由是用户状态不能半成功，日志又是排查入口。

这就完全不一样了。

前者是在把认知负担扔给你。

后者是在帮你做决策。

当然你能反驳它。你能直接回：「不，我们这个场景不需要回滚」。没问题。grill 会把你的回答写回 proposal.md 的 grill-me 决策记录。

这不是聊天记录。

这是后面 spec 和 build 的依据。

AI 能自己查代码，就别来问我

grill-me 还有一条我很喜欢的规则：

如果问题可以通过查阅代码回答，AI 先查代码再问。

这句话听着普通，但我觉得它很重要。

因为很多 AI 工具表面上在协作，实际在偷懒。

它会问你：「当前项目是否已经有类似模块？」

兄弟，你自己搜一下不行吗？

它会问你：「这个功能是否会影响现有配置？」

你读一下配置解析逻辑不行吗？

它会问你：「测试命令是什么？」

你看一眼 package.json 不行吗？

这类问题问多了，人就烦了。到后来，用户开始随便回答。随便回答之后，AI 再基于随便答案去写 spec。

坏了。

整个流程从这里开始变脏。

OpenFlow 的 grill 阶段把责任往 AI 那边推了一点：能查的先查，查完带着证据来问；不能查的，再让用户拍板。

这才像个助手。

不是一个披着助手皮的问题生成器。

现在的 OpenFlow，是 7 个阶段

0.4.0 之后，OpenFlow 的完整链路是这样的：

proposal → brainstorming → grill(optional) → spec → translation → build → amend → close

你可以把它理解成一条 AI 编程流水线。

proposal 负责轻量需求捕获，通常 3-5 个关键问题，把模糊想法压成 proposal.md。

brainstorming 负责深度设计探索，适合那些一开始就有多条路线、需要做取舍的需求。

grill 是新增的可选压力测试。它不写代码，只挑战 proposal。

spec 调用 OpenSpec，把 proposal 变成结构化规格、任务、场景。

translation 是 OpenFlow 的核心胶水层，把需求视角翻译成工程视角，产出 plan-ready.md。这里不是摘要，而是给 Superpowers 的可执行 handoff：Source Coverage、File Responsibility Map、Implementation Slices、TDD expectations、Validation commands。

build 交给 Superpowers，按 TDD 和 checkpoint 执行。

amend 处理 build 或 close 前发现的需求变更。

close 做一致性验证和归档。

这条链路最有意思的地方在于：OpenFlow 不是替代 OpenSpec，也不是替代 Superpowers。

它不抢活。

它做编排。

OpenSpec 擅长把需求写规矩。Superpowers 擅长把工程执行跑规矩。OpenFlow 把两者接起来，中间再加一道 grill 的质检门。

像流水线上的质检员。

不生产零件，但能拦住坏零件。

那我什么时候该用 grill？

如果你只是改一个 README 标点，别用。

真的别用。

工具不是越重越专业。拿手术刀削苹果，挺装，也挺蠢。

但下面这些场景，我会强烈建议你 grill 一下：

第一，需求会影响公共行为。

比如路由规则、配置默认值、权限判断、状态机、数据迁移。只要改完后别人会依赖它，就别急着 spec。

第二，你在 proposal 里写了“默认”“自动”“兼容”“复用”。

这几个词很危险。

默认谁？自动到什么程度？兼容旧数据还是旧行为？复用模块还是复用概念？

这些词看起来省字，实际藏雷。

第三，方案里有多个取舍。

比如安全 vs 速度，简单实现 vs 长期扩展，用户体验 vs 维护成本。让 grill 帮你把取舍写明白，后面返工概率会低很多。

第四，你准备让 AI 连续执行很多步。

AI 一旦开跑，速度很快。快是好事，但方向错了就是灾难。

先花 5 分钟 grill，可能省掉后面 50 分钟补锅。

安装和使用

如果你已经在用 OpenFlow，升级到 0.4.0 后重新生成 skills：

npm install -g @lininn/openflow
openflow update

新项目初始化：

cd your-project
openflow init --tools claude

支持的工具包括 Claude、Codex、Cursor、OpenCode。

在 Claude Code 里，你可以这样走：

/openflow proposal
/openflow grill
/openflow spec
/openflow build
/openflow close

如果你用 OpenCode，对应命令是：

/openflow/grill

grill 是可选的。

但 spec 前会显式问你要不要 grill。你可以跳过，但不会再「不小心」跳过。

我觉得这就是 0.4.0 的关键。

不是多了一个命令。

是 OpenFlow 开始学会在 AI 开工前说一句：等一下，你这个方案经得起问吗？

结尾：别把 AI 当打字员，也别把它当许愿池

我越来越觉得，AI 编程的下一阶段，不是「让 AI 写更多代码」。

而是「让 AI 更早参与决策」。

不是替你拍脑袋。

是替你找漏洞、逼你说清楚、把含糊的地方钉在文档里。

OpenFlow v0.4.0 的 grill-me 就是这个方向上的一个小按钮。

很小。

但它拦在 spec 前面。

这位置挺关键的。

如果你也在用 OpenSpec、Superpowers、Claude Code，或者你已经被 AI 编程里的“需求没说清，代码先写完”折磨过，可以试试 OpenFlow 0.4.0。

项目地址：

https://github.com/lininn/openflow

安装：

npm install -g @lininn/openflow

下次让 AI 开工前，先 grill 一下。

说不定它问你的第一个问题，就能帮你省掉一次返工。

就这样。