Ask 模式做设计评审提示词模板 检查清单让 Agent 先读后改很多「Agent 乱改」事故根因不是模型突然叛逆而是跳过了设计评审目标含糊、约束未写、选项未比直接给了可写权限。Cursor 的 Ask只读模式天生适合干这件事——让它先读代码与测试输出风险与方案不改文件你选定后再进 Agent。本文不重复「Ask / Agent / Manual 怎么选」的决策表只深挖一条路径设计评审专用提示词 合格检查清单 先读后改流水线。适合功能设计、重构前评估、技术方案二选一、以及「我怀疑这里有坑但说不清」的时刻。摘要Ask 产出决策材料Agent 才执行中间必须有人工闸门。提示词固定五段输出目标复述、已读材料、选项对比、风险、验收命令。用检查清单判定合格不合格就追问不带糊涂进可写模式。防漂移禁止顺手重构评审与改代码分会话。选项不超过三个并写明「现在不要改代码」。结论设计评审的质量取决于你是否给模型「只读 结构 禁区」而不是取决于形容词有多严厉。结论卡角色负责不负责Ask读、比选项、列风险改文件、跑破坏性命令你选方案、定禁区、定验收假装没看见含糊输出Agent按选定方案最小改重新发明需求背景与边界Ask 模式在不同客户端版本中的名称与权限细节可能微调核心是默认不写仓库。若你的版本在 Ask 下仍可触发某些工具请在提示词里显式写「不要调用写工具 / 不要修改文件」。本文模板按「只读评审」假设编写。边界不替代架构评审会议的人际对齐不保证模型一定读全仓不覆盖安全渗透测试。大型变更仍建议拆成多篇评审接口、数据、发布。原理先读后改无评审的 Agent 回合常见失败模式是用搜索代替理解抓住局部符号就开始改把「可能的优化」写进同一 diff测试绿了但行为漂移人在 PR 里才发现。先读后改把决策点前移在还不能写的时候把分歧暴露出来。人工闸门的成本远低于回滚。步骤 1准备锚点材料开 Ask 前先24 个路径而不是「帮我看看整个项目」需求/Issue 描述或你自己写的三行目标主要入口文件或模块相关测试或失败日志可选现有 ADR / 设计笔记。同时写清非目标例如「不升级框架」「不改公开 API 形状」。步骤 2粘贴评审提示词模板可复制模板你现在是「只读设计评审员」。禁止修改任何文件禁止给出「我已经帮你改好了」的口吻。 ## 背景 目标{一句话} 非目标{列表} 约束{性能/兼容/安全/工期} ## 材料 请优先阅读我 的文件不足再请求我补充路径。读后列出你实际依据的文件与符号。 ## 输出必须用下列标题不要合并 ### 1. 目标复述含非目标 ### 2. 现状摘要基于已读材料标注不确定点 ### 3. 方案选项仅 23 个 对每个选项写做法要点 / 优点 / 代价 / 适用条件 ### 4. 风险与回滚 安全、数据、兼容、发布风险如何回滚 ### 5. 建议与验收 推荐选项或「信息不足」给出具体验证命令明确「现在不要改代码」 若材料不足停止在第 2 节并列出你需要我 的路径不要猜测补全业务规则。把{...}换成你的内容。选项上限是刻意的太多选项等于没有评审。步骤 3用检查清单判合格Ask 返回后逐项勾是否复述目标与非目标是否列出读过的关键文件/符号是否真有 23 个可执行选项不是假选项是否写清风险与回滚是否给出可跑的验收命令是否明确现在不改代码任一关键项不合格用追问补齐例如「第 3 节选项 B 与我们的公开 API 约束冲突请重写仍不要改代码」。步骤 4人工闸门 — 写成三行决策选定后在笔记或 PR 草稿写三行即可选定选项 B 禁区不改 packages/legacy不改 API 字段名 验收pnpm test -- filter payments手动打一条退款样例这三行是下一会话 Agent 的「合同」。没有合同就不要给可写权限。步骤 5新开 Agent 会话执行推荐新开会话避免把 Ask 阶段的长探索历史全部回灌。提示词示例按既定方案 B 做最小改动。 禁区{...} 请先给出将修改的文件列表我确认后再改。 改完后运行{验收命令} 不要重构无关模块不要「顺便」改格式化全域。若 Agent 想扩大范围打回 Ask「范围变更需要重新评审先只读说明为何必须扩大。」防漂移四招模式锁死评审阶段只用 Ask。输出锁死固定标题拒绝散文诗。范围锁死路径 禁区名单。会话锁死评审与改代码分会话。额外一招要求选项里必须有一个「什么都不做 / 延后」——防止假对比。场景示例缩写场景支付回调幂等加固。Ask 可能给出的选项A 数据库唯一约束B 应用层分布式锁C 先加度量再改。你的闸门选 A度量禁区是不改账单展示模块。Agent只动回调处理器与迁移跑指定测试。没有 Ask 时Agent 常会「顺便」重命名错误码、改日志格式把评审变成考古。团队化把模板放进片段库或 AtomGit 上的prompts/design-review.md在公约里写超过 N 文件的改动PR 描述须附 Ask 评审摘要评审摘要不合格评审人有权要求重开 Ask。这比事后说「你怎么不先设计」更可执行。踩坑坑表现修正假选项三个选项实质一个要求互斥取舍未读先评现状全是猜测强制列已读材料评审中改码Ask 滑成 Agent重开只读会话验收含糊「好好测试」要具体命令选项过多七个方案压到 23验收标准对本工作流本身同一模板在两个真实任务上跑通至少一次因检查清单不合格而追问至少一次 Agent 会话未带回评审噪音团队有人能不看你演示独立用模板评审输出范例缩略下面展示「合格」输出应有的气味内容虚构结构真实### 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」。推荐嵌套路由选 AAsk→ 跑本文评审模板人选定方案路由选 B改测→ 终端工作流执行。两层都固定选项事故面会明显下降。不必等云端 Decisions API本地提示词即可。远程/异步协作时的用法当设计评审发生在 PR 或 Issue 里把 Ask 的五段输出贴进评论评审人只批「选项与禁区」不批文风批准后的三行决策贴到 Agent 会话置顶。这比「语音对齐后各自找 Agent 开改」少很多双线漂移。公约里可写超过一定行数的 PR 必须附评审摘要链接。反模式深层剖析「让 Agent 边看边改边评」看似高效实则把三种温度的任务混在同一上下文探索要宽、执行要窄、评价要冷。混温导致探索性阅读污染执行执行 diff 绑架评价评价语气又刺激模型继续「表现」。分模式、分会话是在管理温度不是在制造流程KPI。把检查清单做成「评审人工具」若你是审核别人 PR 的人可以把清单改成评论模板设计评审抽检 - [ ] 有目标/非目标 - [ ] 有已读材料 - [ ] 选项 23 且互斥 - [ ] 有风险回滚 - [ ] 有验收命令 - [ ] 决策三行已写 缺项请补 Ask不要直接继续改代码。这比「我觉得你想得不够」可执行也减少人身争论。与 Manual 模式的衔接高风险一行修改权限、签名校验、支付金额可以Ask 评审选方案Agent 只生成补丁建议你用 Manual/自己动手落下最终编辑仍跑同一验收命令。「先读后改」不强制改的人是 Agent强制的是读发生在改之前。度量评审是否真的省事不要一开始就上复杂指标。两周内数三个数即可因范围失控而回滚的 PR 次数Ask 后改选项的次数说明评审在工作无评审摘要的大 PR 数量应下降。若回滚没降检查是不是清单在「打勾走过场」。模板库存放约定建议路径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 后期挪到成本更低的只读阶段。草稿未发布 · 作者 梧桐秋海 · 活动九月创作之星、工具实践