Ask 模式做设计评审：提示词模板 + 检查清单，让 Agent 先读后改

很多「Agent 乱改」事故，根因不是模型突然叛逆，而是跳过了设计评审 ：目标含糊、约束未写、选项未比，直接给了可写权限。Cursor 的 Ask（只读）模式天生适合干这件事------让它先读代码与测试，输出风险与方案，不改文件；你选定后再进 Agent。

本文不重复「Ask / Agent / Manual 怎么选」的决策表，只深挖一条路径：设计评审专用提示词 + 合格检查清单 + 先读后改流水线。适合功能设计、重构前评估、技术方案二选一、以及「我怀疑这里有坑但说不清」的时刻。

摘要

Ask 产出决策材料，Agent 才执行；中间必须有人工闸门。
提示词固定五段输出：目标复述、已读材料、选项对比、风险、验收命令。
用检查清单判定合格，不合格就追问，不带糊涂进可写模式。
防漂移：禁止顺手重构；评审与改代码分会话。
选项不超过三个，并写明「现在不要改代码」。

结论：设计评审的质量，取决于你是否给模型「只读 + 结构 + 禁区」，而不是取决于形容词有多严厉。

结论卡

角色	负责	不负责
Ask	读、比选项、列风险	改文件、跑破坏性命令
你	选方案、定禁区、定验收	假装没看见含糊输出
Agent	按选定方案最小改	重新发明需求

背景与边界

Ask 模式在不同客户端版本中的名称与权限细节可能微调，核心是默认不写仓库。若你的版本在 Ask 下仍可触发某些工具，请在提示词里显式写「不要调用写工具 / 不要修改文件」。本文模板按「只读评审」假设编写。

边界：不替代架构评审会议的人际对齐；不保证模型一定读全仓；不覆盖安全渗透测试。大型变更仍建议拆成多篇评审（接口、数据、发布）。

原理：先读后改

无评审的 Agent 回合，常见失败模式是：

用搜索代替理解，抓住局部符号就开始改；
把「可能的优化」写进同一 diff；
测试绿了但行为漂移，人在 PR 里才发现。

先读后改把决策点前移：在还不能写的时候，把分歧暴露出来。人工闸门的成本远低于回滚。

步骤 1：准备锚点材料

开 Ask 前，先 @ 2～4 个路径，而不是「帮我看看整个项目」：

需求/Issue 描述或你自己写的三行目标；
主要入口文件或模块；
相关测试或失败日志；
（可选）现有 ADR / 设计笔记。

同时写清非目标：例如「不升级框架」「不改公开 API 形状」。

步骤 2：粘贴评审提示词模板

可复制模板：

text 复制代码

你现在是「只读设计评审员」。禁止修改任何文件，禁止给出「我已经帮你改好了」的口吻。

## 背景
目标：{一句话}
非目标：{列表}
约束：{性能/兼容/安全/工期}

## 材料
请优先阅读我 @ 的文件；不足再请求我补充路径。读后列出你实际依据的文件与符号。

## 输出（必须用下列标题，不要合并）
### 1. 目标复述（含非目标）
### 2. 现状摘要（基于已读材料，标注不确定点）
### 3. 方案选项（仅 2～3 个）
对每个选项写：做法要点 / 优点 / 代价 / 适用条件
### 4. 风险与回滚
安全、数据、兼容、发布风险；如何回滚
### 5. 建议与验收
推荐选项（或「信息不足」）；给出具体验证命令；明确「现在不要改代码」

若材料不足，停止在第 2 节并列出你需要我 @ 的路径，不要猜测补全业务规则。

把 {...} 换成你的内容。选项上限是刻意的：太多选项等于没有评审。

步骤 3：用检查清单判合格

Ask 返回后，逐项勾：

是否复述目标与非目标？
是否列出读过的关键文件/符号？
是否真有 2～3 个可执行选项（不是假选项）？
是否写清风险与回滚？
是否给出可跑的验收命令？
是否明确现在不改代码？

任一关键项不合格：用追问补齐，例如「第 3 节选项 B 与我们的公开 API 约束冲突，请重写，仍不要改代码」。

步骤 4：人工闸门 --- 写成三行决策

选定后，在笔记或 PR 草稿写三行即可：

text 复制代码

选定：选项 B
禁区：不改 packages/legacy；不改 API 字段名
验收：pnpm test -- filter payments；手动打一条退款样例

这三行是下一会话 Agent 的「合同」。没有合同就不要给可写权限。

步骤 5：新开 Agent 会话执行

推荐新开会话，避免把 Ask 阶段的长探索历史全部回灌。提示词示例：

text 复制代码

按既定方案 B 做最小改动。
禁区：{...}
请先给出将修改的文件列表，我确认后再改。
改完后运行：{验收命令}
不要重构无关模块，不要「顺便」改格式化全域。

若 Agent 想扩大范围，打回 Ask：「范围变更需要重新评审，先只读说明为何必须扩大。」

防漂移四招

模式锁死：评审阶段只用 Ask。
输出锁死：固定标题，拒绝散文诗。
范围锁死 ：@ 路径 + 禁区名单。
会话锁死：评审与改代码分会话。

额外一招：要求选项里必须有一个「什么都不做 / 延后」------防止假对比。

场景示例（缩写）

场景：支付回调幂等加固。

Ask 可能给出的选项 ：A 数据库唯一约束；B 应用层分布式锁；C 先加度量再改。

你的闸门 ：选 A+度量，禁区是不改账单展示模块。

Agent：只动回调处理器与迁移，跑指定测试。

没有 Ask 时，Agent 常会「顺便」重命名错误码、改日志格式，把评审变成考古。

团队化

把模板放进片段库或 AtomGit 上的 prompts/design-review.md，在公约里写：

超过 N 文件的改动，PR 描述须附 Ask 评审摘要；
评审摘要不合格，评审人有权要求重开 Ask。

这比事后说「你怎么不先设计」更可执行。

踩坑

坑	表现	修正
假选项	三个选项实质一个	要求互斥取舍
未读先评	现状全是猜测	强制列已读材料
评审中改码	Ask 滑成 Agent	重开只读会话
验收含糊	「好好测试」	要具体命令
选项过多	七个方案	压到 2～3

验收标准（对本工作流本身）

同一模板在两个真实任务上跑通
至少一次因检查清单不合格而追问
至少一次 Agent 会话未带回评审噪音
团队有人能不看你演示独立用模板

评审输出范例（缩略）

下面展示「合格」输出应有的气味（内容虚构，结构真实）：

text 复制代码

### 1. 目标复述
目标：为退款回调增加幂等；非目标：不改账单 UI。

### 2. 现状摘要
依据 `RefundWebhook.ts` 与 `refund.test.ts`：当前按 requestId 查询但无唯一约束；不确定点：是否已有历史重复行。

### 3. 方案选项
A. DB 唯一约束 + 冲突转成功
B. 应用层锁
C. 先加重复度量再改

### 4. 风险与回滚
A 需迁移与回填；回滚为撤销迁移并恢复旧查询。

### 5. 建议与验收
建议 A；验收 `pytest ...::test_idempotent_retry`；现在不要改代码。

拿你的 Ask 结果和它对结构，而不是对文采。

和「Decisions 路由」怎么拼

设计评审解决的是「方案选哪个」；路由句解决的是「现在该 Ask 还是 Agent」。推荐嵌套：

路由选 A（Ask）→ 跑本文评审模板；
人选定方案；
路由选 B（改测）→ 终端工作流执行。

两层都固定选项，事故面会明显下降。不必等云端 Decisions API，本地提示词即可。

远程/异步协作时的用法

当设计评审发生在 PR 或 Issue 里：

把 Ask 的五段输出贴进评论；
评审人只批「选项与禁区」，不批文风；
批准后的三行决策贴到 Agent 会话置顶。

这比「语音对齐后各自找 Agent 开改」少很多双线漂移。公约里可写：超过一定行数的 PR 必须附评审摘要链接。

反模式深层剖析

「让 Agent 边看边改边评」看似高效，实则把三种温度的任务混在同一上下文：探索要宽、执行要窄、评价要冷。混温导致：

探索性阅读污染执行；
执行 diff 绑架评价；
评价语气又刺激模型继续「表现」。

分模式、分会话，是在管理温度，不是在制造流程KPI。

把检查清单做成「评审人工具」

若你是审核别人 PR 的人，可以把清单改成评论模板：

text 复制代码

设计评审抽检：
- [ ] 有目标/非目标
- [ ] 有已读材料
- [ ] 选项 2～3 且互斥
- [ ] 有风险回滚
- [ ] 有验收命令
- [ ] 决策三行已写
缺项：请补 Ask，不要直接继续改代码。

这比「我觉得你想得不够」可执行，也减少人身争论。

与 Manual 模式的衔接

高风险一行修改（权限、签名校验、支付金额）可以：

Ask 评审选方案；
Agent 只生成补丁建议；
你用 Manual/自己动手落下最终编辑；
仍跑同一验收命令。

「先读后改」不强制改的人是 Agent；强制的是读发生在改之前。

度量：评审是否真的省事

不要一开始就上复杂指标。两周内数三个数即可：

因范围失控而回滚的 PR 次数；
Ask 后改选项的次数（说明评审在工作）；
无评审摘要的大 PR 数量（应下降）。

若回滚没降，检查是不是清单在「打勾走过场」。

模板库存放约定

建议路径：

text 复制代码

prompts/
  design-review.md
  design-review.check.md
  agent-execute-approved.md

在 Cursor 里用 @prompts/design-review.md 引用。变更提示词也走 PR，避免「某人改了一句禁止项导致全公司行为突变」且无人知。提示词与 Rules 一样，是可执行政策。

何时允许「跳过评审」

公约可白名单极小任务：错别字、注释、严格单文件且有测试守护的文案。白名单要写死；不在名单内的「我觉得很小」不算。跳过时仍建议一句话目标与验收命令------跳过的是选项对比，不是思维。

练习：同一需求两路径对比

选一个真实小需求，分别记录：

路径甲：直接 Agent；
路径乙：Ask 评审 → 决策三行 → Agent。

对比：diff 行数、回滚次数、你是否理解根因。把结果贴到团队频道------比再发一篇安利更有说服力。

结束前的自我提问

下一笔大改前，你是否拿得出「决策三行」？拿得出，再给 Agent 键盘；拿不出，就还在 Ask。

评审的终点是决策，不是更长的分析。

小结

Ask 做设计评审，是把「先想清楚」产品化：只读、结构、清单、闸门、再改。提示词模板负责稳定输出，检查清单负责你不自欺，分会话负责不让历史税污染执行。先读后改不是更慢，而是把返工从 PR 后期挪到成本更低的只读阶段。

草稿未发布 · 作者梧桐秋海 · 活动：九月创作之星、工具实践