让编码 Agent 先复述意图再动手的权衡提示词
一条可复制的提示词：让 Claude Code/Codex 先确认理解、按 UX/DX/AX 权衡决策、不越界不破坏现有功能。
原始内容
When you hand Claude Code or Codex a long task, add this. If it misunderstood you, 𝘆𝗼𝘂'𝗹𝗹 𝗰𝗮𝘁𝗰𝗵 𝗶𝘁 𝗿𝗶𝗴𝗵𝘁 𝗮𝘄𝗮𝘆: "Before you touch anything, tell me in 2–3 sentences what you think I'm after and what problem we're solving. Start only after I say yes. When there's a tradeoff, weigh all three: → UX: is it easy for users to use? → DX: is it easy for developers to change later? → AX: can the next agent understand it and keep going? Don't touch anything outside this task, and don't break anything that already works. When you're done, tell me in 2–3 lines what you picked, what you gave up, and why."
中文译文
机器翻译，保留原文供核对。
当你把一项长任务交给 Claude Code 或 Codex 时，加上这段。如果它误解了你，你立刻就能发现： “在你动手之前，用 2–3 句话告诉我，你认为我想要什么，以及我们要解决什么问题。只有我说可以之后，你再开始。 遇到取舍时，把这三项都权衡一下： → UX：用户用起来是否容易？ → DX：开发者之后是否容易修改？ → AX：下一个 Agent 能否理解并继续推进？ 不要碰这个任务之外的任何东西，也不要破坏任何已经正常工作的东西。完成后，用 2–3 行告诉我你选了什么、放弃了什么，以及为什么。”
深度解析
是什么：这是一条可直接复制进 Claude Code / Codex 会话的提示词模板，用于委派长任务前的「前置对齐」：要求 Agent 先用 2–3 句复述它理解的目标与问题，得到确认后再动手。
核心设计：模板由四个机制叠加——①复述确认，把误解的成本前置到零代码阶段；②UX/DX/AX 三维权衡框架，要求改动同时考虑用户易用、开发者可维护、下一个 Agent 可接续；③范围与回归约束，明确不许越界、不许破坏已能工作的东西；④事后汇报，用 2–3 行说明选了什么、放弃了什么、为什么。
关键洞察：最有新意的是把 AX（Agent Experience）提升为与 UX、DX 并列的一等维度——在多 Agent 接力开发的现实中，「代码是否对下一个 Agent 可读可续」直接影响迭代效率。整个模板的本质是把人类工程协作中的「需求确认 + 设计评审 + 变更说明」压缩成一段可复用的指令，用极低成本换取意图对齐和决策可审计性。
边界与风险：确认门控会引入交互往返，对小型任务或全自动流水线是额外摩擦；「说 yes 才开始」依赖人在线，削弱了 Agent 的自主性；复述一致也不等于理解正确，权衡汇报的质量仍取决于模型自身判断力，需与测试、代码评审等手段配合使用。
精选追评与案例
补充了可直接照做的 plan gate 流程：先写计划文件，确认范围与风险后再开工。
@Voxyz_ai 同样思路我更狠一点，直接上 plan gate：让它先写个 plan 文件——动哪些文件、分几步、风险点，人确认后才开工。paraphrase 抓得住方向，抓不住 scope；plan 白纸黑字，动手前偏差就暴露了，中途跑漂还能拉回来当锚点。毕竟方向错了重跑，烧的全是最贵的 token。
把理解检查具体化为文件清单，便于尽早发现范围偏差。
@Voxyz_ai pair it with: list the files you plan to touch. a surprise file on that list is the misunderstanding, caught early
中文译文 · 机器翻译
搭配这条一起用：列出你计划改动的文件。清单里出现一个意料之外的文件，就是理解有误，能尽早发现。
给出多次重建的实操经验，强调一句话任务说明与输入输出先行。
@Voxyz_ai same pattern held on my 8 rebuilds this week: one sentence for the job, what goes in and what comes out, before any code. most cores then ran after 2 or 3 rounds of pasting the error back.
中文译文 · 机器翻译
本周我做了 8 次重建，同样的模式都成立：在写任何代码之前，先用一句话说明任务，以及输入什么、输出什么。大多数核心逻辑随后在把报错贴回去 2 到 3 轮之后才跑通。
指出只看总结可能批准错误任务，补上可验证的完成标准。
@Voxyz_ai I’d make those 2–3 sentences include a checkable done-state, otherwise you’re approving a beautifully summarized wrong task.
中文译文 · 机器翻译
我会让那 2–3 句话包含一个可检查的完成状态，否则你批准的就是一个被漂亮总结过的错误任务。
用文件清单作为额外校验，能比摘要更快发现理解偏差。
@Voxyz_ai I also ask for the list of files it plans to touch. A wrong file in that list catches a misread faster than the 2-3 sentence summary does.
中文译文 · 机器翻译
我也会让它列出计划改动的文件清单。清单里出现错误文件，比 2–3 句话的总结更快暴露误读。