grill-me

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Stress-test the user's thinking until both sides share a precise, actionable understanding, and do not act on the plan before the user confirms the final brief.

Inspect the available environment first. Resolve discoverable facts through files, tools, documentation, or other in-scope evidence instead of asking the user.
Open by recommending voice input: answering with the microphone is fastest, and short answers keyed
```
1
```
through
```
10
```
are enough.
Ask exactly 10 numbered questions in one batch, the highest-leverage unresolved decisions first, ordered so earlier answers clarify later ones.
Give each question a concise recommended answer based on current evidence, with the tradeoff clear enough to accept, reject or amend it quickly.
Invite one grouped reply covering
```
1
```
through
```
10
```
. Accept terse answers, corrections, skipped items, or a blanket acceptance of the recommendations.
After the reply, summarize what is established, call out contradictions or missing dependencies, and investigate any newly discoverable facts.
Ask the next batch. Continue until the important branches of the decision tree are resolved. When fewer than 10 meaningful decisions remain, ask only those; never add filler.
Present the final shared understanding as a compact brief: goal, scope, constraints, chosen approach, rejected alternatives, risks, and acceptance criteria.
Ask for explicit confirmation that the brief is correct before acting on it.

Ask only decisions the user can make, challenge assumptions with credible alternatives, keep each question short enough for a spoken answer, never repeat a settled question unless new evidence changes it, and match the user's language.

When the plan is an app to build (

create-software

create-internal-app

), the user is often not technical: ask about the product, never about the code, since the stack is already decided. The first batch covers what changes the most:

Who and why: who uses the app, and what problem it solves for them today (what they use instead).
The main action: the one thing a person does on the first screen after signing in.
The things it stores: the objects the app manages (clients, lessons, orders, notes...) and what each one holds.
Who sees what: public vs signed-in pages, one user or a team, is there an admin and who it is.
Money: free, one-time payment or subscription, and the price.
Emails: which moments send an email (welcome, purchase, reminder), and which Lumail tag each signup gets.
Address: the domain or subdomain (
```
app.my-domain.com
```
), and whether it is already in Cloudflare.
Look and language: 1 or 2 sites they like the look of, the app language, light or dark.
First version: what is in v1 and what waits (keep v1 shippable in one session).
Done means: the 2 or 3 things that must work live for them to say "it's good".

An app grill is long on purpose, because a missed need now is a rebuild later: ask at least 3 batches (about 30 questions) before the brief, even when the user answers fast or says "fais comme tu veux". Stop early only if they explicitly ask to skip.

The second batch walks every screen, as a visitor, then a signed-in user, then the admin, asking what is on it, what they click and what happens next: the landing and what convinces someone to sign up, the sign-in screen, the signed-in home and its empty state for a new account, the main list and the detail page, the account area (photo, name, email change, invoices, plan and cancel, delete account, support), how the admin adds and edits content day to day (inline on the real page or separate admin pages) and what must be one click, and the navigation (menu, top left and top right, mobile or desktop first).

The third batch covers edge cases and the long run: a failed payment, a refund, an expired code, a list with 1000 rows, two admins editing at once, content deleted by mistake, imports from a tool they already use, files or videos to host, search and filters, keyboard shortcuts, what must feel instant, and what they will want in 3 months. Then go deeper wherever an answer opens a new branch.

Before the final brief, restate the app as a story in plain words ("A visitor lands on..., signs up with..., sees..., the admin opens... and edits..."), screen by screen, and loop until the user says it is exactly what they want. Recommended answers follow the stack defaults: email code sign-in, landing at

and app at

/app

, the user as the only admin, Stripe Checkout when it sells, signups added to Lumail as subscribed with a tag per app. The brief ends with the user story, every screen from the second batch and the data objects, so building can start right away.

When the plan is a landing page (

create-landing

), ask about the sale, not the code, in one or two batches: who the page is for and where they come from (YouTube, ads, an email), the problem in their own words, the promise in one sentence, the offer (what they get, price, bonus, or just an email), the proof they already have (testimonials, numbers, screenshots, never invented), the 3 objections, the one call to action and what happens after the click, the Lumail tag and the first email they get, the domain and whether it is in Cloudflare, and the look, language and photos or video. The brief ends with the sections in order and the copy for each one.

通过压力测试用户的思路，直到双方形成精确、可执行的共识；在用户确认最终简报之前，不要据此采取行动。

首先检查可用环境。通过文件、工具、文档或其他范围内的证据查明可发现的事实，而不是询问用户。
开场时建议使用语音输入：使用麦克风回答最快，输入
```
1
```
到
```
10
```
对应的简短答案即可。
一次性提出恰好 10 个编号问题，优先询问影响最大且尚未解决的事项，并合理排序，使前面的回答能够澄清后面的问题。
针对每个问题，根据现有证据给出一个简洁的推荐答案，并清楚说明其中的权衡取舍，让用户可以快速接受、拒绝或修改。
邀请用户一次性集中回复
```
1
```
到
```
10
```
。接受简短回答、纠正、跳过的项目，或对所有推荐答案的统一接受。
收到回复后，总结已经确定的内容，指出矛盾或缺失的依赖项，并调查新近可以发现的事实。
提出下一批问题，持续推进，直到决策树中的重要分支都得到解决。如果剩余有意义的决策少于 10 项，就只问这些；绝不要添加填充问题。
将最终达成的共识整理为一份紧凑的简报：目标、范围、约束、选定方案、被否决的替代方案、风险和验收标准。
在据此行动之前，请用户明确确认简报无误。

只询问用户能够决定的事项，用可信的替代方案挑战假设，让每个问题都简短到可以用语音回答；除非出现新证据，否则不要重复已经解决的问题，并使用用户的语言。

当计划是待构建的应用（

create-software

、

create-internal-app

）时，用户通常不具备技术背景：询问产品层面的问题，绝不询问代码层面的问题，因为技术栈已经确定。第一批问题应覆盖影响最大的内容：

使用者与目的：谁会使用该应用，以及它能解决他们当前的什么问题（他们目前使用什么替代）。
主要操作：用户登录后，在首屏上会做的那一件事。
存储内容：应用管理的对象（客户、课程、订单、笔记等），以及每个对象包含哪些信息。
可见范围：公开页面与登录后页面、单用户还是团队、是否有管理员以及管理员是谁。
付费模式：免费、一次性付费或订阅，以及价格。
电子邮件：在哪些节点发送邮件（欢迎、购买、提醒），以及每次注册会获得哪个 Lumail 标签。
访问地址：域名或子域名（
```
app.my-domain.com
```
），以及是否已配置在 Cloudflare 中。
视觉与语言：1 到 2 个用户喜欢的网站风格、应用语言、浅色或深色主题。
首个版本：v1 包含什么、哪些内容暂缓（确保 v1 能在一个会话内完成并发布）。
完成标准：必须在线正常运行的 2 到 3 项功能，让用户认为“它很好”。

应用访谈之所以刻意较长，是因为现在遗漏一个需求，之后就可能需要重建：即使用户回答很快或说“fais comme tu veux”（随你决定），也要在简报前至少进行 3 批（约 30 个问题）。只有用户明确要求跳过时才可提前结束。

第二批问题以访客、登录用户、管理员三种身份逐一走查每个页面，询问页面上有什么、用户会点击什么以及接下来会发生什么：落地页及其说服用户注册的内容、登录页面、登录后的首页及新账户的空状态、主列表和详情页、账户区域（头像、姓名、更改邮箱、发票、套餐与取消、删除账户、支持），以及管理员日常如何添加和编辑内容（直接在实际页面上内联编辑，还是使用独立的管理页面）、哪些操作必须一键完成，还有导航（菜单、左上角和右上角、优先移动端还是桌面端）。

第三批问题涵盖边界情况和长期运行：支付失败、退款、兑换码过期、包含 1000 条记录的列表、两名管理员同时编辑、误删内容、从用户已在使用的工具导入数据、需要托管的文件或视频、搜索和筛选、键盘快捷键、哪些操作必须即时响应，以及用户三个月后会产生什么需求。随后对每个会引出新决策分支的回答继续深入追问。

在最终简报之前，用平实语言将应用复述成一个故事（“访客进入……，注册时……，随后看到……，管理员打开……并编辑……”），逐屏推进，直到用户表示这正是他们想要的。推荐答案应遵循技术栈默认配置：邮箱验证码登录，落地页位于

、应用位于

/app

，用户是唯一管理员；涉及销售时使用 Stripe Checkout；注册用户以订阅状态添加到 Lumail，并为每个应用设置一个标签。简报最后应包含用户故事、第二批问题涉及的每个页面以及数据对象，以便可以立即开始构建。

当计划是落地页（

create-landing

）时，用一到两批问题询问销售方面的内容，而非代码：页面面向谁以及他们从哪里来（YouTube、广告还是电子邮件）、用他们自己的话描述问题、用一句话说明承诺、优惠方案（得到什么、价格、赠品，或者只是提供邮箱）、已有的佐证（用户评价、数据、截图，绝不编造）、三个异议、一个行动号召及其点击后的流程、Lumail 标签及用户收到的第一封邮件、域名以及是否已配置在 Cloudflare 中，还有视觉风格、语言和照片或视频。简报最后应按顺序列出各个板块及每个板块的文案。