用 /grill-me 压力测试你的方案

每个方案，第一遍读起来总觉得完整。你亲手写的，结构合理，步骤连贯，感觉可以动手了。

然后实现一开始，漏洞就冒出来了：

• "等等——如果用户在这个操作触发时已退出登录，会怎样？"
• "这个假设两端同时部署。但实际上不会。"
• "我们从来没说过迁移中途失败该怎么办。"
• "如果同时有两个这样的操作在跑，我们到底选了哪个策略——后写者胜，还是冲突即报错？"

每一个都是当初没问的五秒钟问题。每一个在实现到一半时浮出水面，都要花好几个小时返工。提问与重建的成本比大约是 1:200。

/grill-me 工作流反转了这种不对等。你花二十分钟让 LingCode 审问方案，在任何代码存在之前。在这个窗口里找到的每一个漏洞，都是你之后不需要再返工的时间。

在以下情况运行 /grill-me：

• 你刚写完一个实现方案，感觉"差不多了"。
• 你即将迈出不可逆的一步（Schema 变更、公开 API、数据回填）。
• 方案涉及的系统，你的理解不如将来审 PR 的人深入。
• 过去十分钟里你有过两次"直接开干吧"的冲动。这种冲动通常意味着方案还没经受足够的压力测试。

不要对一行代码的小修小补使用它。也不要对已经执行过的方案使用它（那是代码审查，属于另一个技能）。审问的窗口是"方案写好"到"代码开始"之间。

AI 编程工具的默认行为是友好且顺从的。而这恰恰是审问时最不需要的。请明确地设定框架：

I want you to stress-test my plan. Play a hostile interviewer
who's trying to find every hole in this design before we
commit to it.

Rules:
- Interrogate every decision branch. If the plan says "the
  service handles this case," ask what happens in five
  variations of that case.
- Don't be agreeable. If I hand-wave, push back. If my answer
  introduces a new assumption, grill that too.
- Walk the failure paths, not just the happy path. What
  breaks? Who sees it? How do we recover?
- Don't propose fixes mid-grill. Just surface the questions.
  We'll address them in a separate pass.

Here's the plan:

然后粘贴方案，或引用方案文件路径。"不要中途提修复建议"这一条很重要——一旦审问变成共同设计会议，对抗性的张力就消失了，效果也就大打折扣。

LingCode 会开始连续发问。你的本能反应是先回答简单的。忍住。按顺序回答，优先回答那些让你感到不舒服的问题——那里通常才是真正的漏洞所在。

一次好的审问对话大概是这样的：

• LingCode："第 4 步说你从旧列回填新列。顺序是什么——先写新代码再回填，还是先回填再发布代码？"
• 你："先回填。"
• LingCode："那么，从回填开始到回填完成之间写入的行怎么处理？旧代码还在写旧列。"
• 你："呃。嗯……"
• LingCode："对——所以光靠回填还不够。迁移窗口期间你还需要双写。方案应该把这个单列为一步吗？"

这段对话只需九十秒。它揪出的 bug，如果留到生产环境调试，要花上整整一天。这个比例，就是这个技能存在的全部理由。

被审问时最大的诱惑是为方案辩护。别这样做。每个问题只有两种有效回应：

• "答案是这样的。"如果你真的知道会发生什么，就直接说。LingCode 会继续追问。
• "我不知道。"把它标记为待解决问题。LingCode 会保留这份清单。

无效回应："到时候再说"、"框架会处理"、"不会有人踩这个情况"。每一个都是推迟了的漏洞。审问的意义就在于不推迟。

大多数方案只覆盖了顺利路径。审问应该重点探查出错时会发生什么：

Now walk only the failure paths. For each step:
- What's the most likely way this step fails in production?
- What's the rarest catastrophic way it can fail?
- If it fails partway through, what state is the system in?
- Who notices first — automated alert, user complaint, no one?
- What's the rollback path, in commands or steps, not "we'd
  roll back"?

Don't accept "we'd handle it" — name the mechanism.

这一轮通常能找出比第一轮更多的问题。顺利路径经过了充分的演练；假设正是埋藏在失败路径里的。

方案常见的失败模式是：每个步骤单独看都没问题，但步骤之间的接缝却没人管。要专门针对这些接缝进行审问：

• "第 3 步写入缓存，第 5 步从缓存读取。一致性模型是什么——写后读有保证吗？"
• "第 4 步部署 API，第 6 步部署客户端。第 4 步上线时，还在使用旧版本的客户端会怎样？"
• "第 2 步执行迁移，第 7 步在回滚时反向执行。它们真的互为逆操作，还是只是'差不多'？"

排序 bug 就藏在步骤的接口处。明确命名每个接口并对它们进行审问，能揪出逐步审查时漏掉的偏差。

当 LingCode 问题问完了（或者更可能的是，你的时间用完了），结束会话：

End the grill. Compile a single list of open items we surfaced
that aren't yet resolved in the plan. For each one:
- The question.
- The status (unanswered, answered but plan not updated yet,
  or "won't fix — accept the risk").
- Where it should land in the plan if we adopt it (which
  step gets amended, or where a new step belongs).

Don't propose specific fixes — just the open-item list.

这份清单就是这次审问的交付物。它也是一次残酷的诚实检验——如果清单很长，说明你的方案还没准备好执行。现在知道，总比后来发现要好。

把待解决清单带回方案文件。对每一项：

• 通过澄清已解决？更新相关步骤的描述，让它不再模糊。
• 需要新增步骤才能解决？在正确的位置加入这一步，并重新编号。
• 接受为已知风险？在方案中加入"已知风险"部分，写下这个决定。未来的你（或审查者）需要看到这是经过深思熟虑的，而不是被遗漏的。

将方案修订单独作为一次提交，与代码分开：

git commit -m "Amend plan after /grill-me pass — add dual-write
step, document migration rollback path"

现在，方案已经经过压力测试。带着检查点去执行它（参见下一篇教程）。你预先花在审问上的时间，就是你之后不需要花在返工上的时间。

将审问工作流封装为一个技能，让 /grill-me 每次都能一致地调用它：

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Triggers: 'grill me', 'stress-test my plan', 'poke holes', 'find gaps', 'play devil's advocate', 'interview me', 'is this plan complete', 'what am I missing'. Actions: hostile interviewer, walk decision branches, surface unresolved assumptions, list open items (NOT direct fixes). Output: open-items list the user must answer before implementation. Anti-pattern: making suggestions instead of asking questions.
---

Play a hostile interviewer stress-testing the user's plan or
design. Find holes before any code is written.

Rules of engagement:
- Interrogate every decision branch. If a step says "handles
  this case," ask what happens in five variations.
- Don't be agreeable. Push back on hand-waving. If an answer
  introduces a new assumption, grill that one too.
- Walk failure paths as thoroughly as happy paths. For each
  step ask: most likely failure, worst-case failure, partial
  failure, detection, rollback.
- Probe interfaces between steps — consistency, versioning,
  deployment ordering, inverse migrations.
- Do not propose fixes mid-grill. Just surface the questions.
- Accept only "here's the answer" or "I don't know." Reject
  "we'll figure it out later" — that's a deferred hole.

When the user closes the grill, compile a single list of open
items: question, status (unanswered / answered-but-not-in-plan
/ accepted risk), and where each should land in the plan.

Don't write code, don't amend the plan file directly. The
output is the open-items list.

保存为 ~/.lingcode/skills/grill-me/SKILL.md——请参阅安装技能了解具体位置以及技能如何被发现。

获取 LingCode →