提问即设计 · Prompt 是你能写的最短的设计文档
上一篇讲了 Spec 和上下文,那是”给 Agent 的背景资料”。这一篇讲你每天几十次敲下的那一句话——它才是真正驱动 Agent 的方向盘。
很多人没意识到:你的 Prompt 质量,直接决定了代码质量。 不是”影响”,是”决定”。
一次提问,决定了一片搜索空间
先看两种提问方式的对比。
第一种:
帮忙写一个订单提交接口。
第二种:
项目用分层架构,当前需要新增订单提交能力。
- 目标 service 层实现订单创建逻辑,在 controller 层提供统一响应。
- 约束;保持现有 DTO 命名;写入失败需返回可追踪错误码;禁止在 controller 写业务规则。
- 输入:
OrderCreateRequest;输出:OrderView。- 过程,再给核心代码,再给测试边界。
- 验收、职责单一、无重复规则、接口兼容现有版本。
两种写法都可能得到能跑的代码。但第二种远更容易得到可合并的代码。
区别在哪?你的提问方式决定了 Agent 的搜索空间,搜索空间决定了候选实现的结构质量,结构质量再决定后续维护成本。
第一种提问,把 Agent 扔进了一片无边无际的可能性海洋——它可以用任何架构、任何命名、任何错误处理方式。它会挑一个”看起来最常见”的,而那个常见方案大概率不匹配你的项目。第二种提问,已经把搜索空间收窄到了一个小房间里,Agent 只需要在这个房间里找最优解。
你给的约束越清晰,Agent 的自由度越小,产出越可控。 这不是限制 Agent,而是帮它聚焦。
六段式 Prompt 结构
把第二种提问抽象出来,一套实用的工程化 Prompt 可以分成六段:
| 段 | 作用 | 例子 |
|---|---|---|
| Context | 定义上下文 | ”项目用分层架构,Go + Postgres” |
| Goal | 声明目标 | ”在 service 层实现订单创建” |
| Constraints | 列出边界和约束 | ”不新增依赖;不在 controller 写业务” |
| Interface & Data | 约定接口数据 | ”输入 OrderCreateRequest,输出 OrderView” |
| Process | 规定执行路径,要求分步产出 | ”先划分模块,再写代码,再写测试” |
| Review | 明确验收标准 | ”职责单一、无重复、接口兼容” |
不一定要死守这个格式,但只要覆盖到这几个要素,生成结果会稳定很多。
它对应的正是上一篇讲的好 Spec 三特征——意图清晰(Goal)、约束明确(Constraints)、验收可测(Review)。Prompt 就是 Spec 的一次性微缩版
(轻量 Spec = 一段结构化 Prompt),大功能才升级成文档。核心心法
不该是一次性的聊天记录,而该当作可审阅、可迭代、可复用的设计文档来管理。团队里推行这个做法,一开始大家觉得麻烦,后来发现返工次数明显少了。
需求含糊时,别直接要代码——先让它提问
六段式适用于你已经想清楚的场景。但很多时候你自己也没想清楚,这时候硬写 Prompt 反而是在”用模糊约束换模糊结果”。
更好的做法:让 Agent 先反问你。
先不要写代码。请基于以下业务描述提出 8 个澄清问题,
覆盖:目标用户、核心流程、失败场景、性能约束、
兼容范围和上线节奏。等我回答后,再输出实现方案。
业务描述:[你模糊的想法]看着慢,实际经常能省掉后续数小时的返工。因为 Agent 提出的问题,往往正是你没想到的边界——它逼着你在动手前把模糊地带钉死。
这和上一篇 Spec 指南里那句”让 Agent 先说计划再动手”是同一个思路:把对齐前置。计划错了你能立刻拦,而不是等它写完一堆再推翻。
💡 主流工具的 Plan 模式(Claude Code、Codex、Cursor)本质上就是把”先提问/先给方案再动手”产品化了——Agent 先给你 A/B/C 几个候选,你选定后再执行。日常小事你可以手写”先提问”的 Prompt,复杂功能就直接进 Plan 模式。
反模式 Prompt 当扭蛋机
新手最常见的坏习惯,是把和 Agent 的对话当成”试试看”的随机行为
,一句话丢过去,拿到结果就用,不行就再抽一次。写小脚本时这没问题。但一旦进入稍微复杂的项目,这种”扭蛋式提问”的问题会迅速放大:
- 每次抽到的实现风格都不一样,代码库很快变得七拼八凑
- 你没有沉淀下任何可复用的东西,下次还得重新抽
- 你把”判断结果好不好”的责任完全交给了运气
真正高效的人,是把好用的 Prompt 存下来、改进、复用——存成自定义命令、存成 Skill、存进团队的 Prompt 库。一次投入,长期收益。
小结
- 你的 Prompt 质量直接决定代码质量——它定义了 Agent 的搜索空间。
- 工程化 Prompt 覆盖六段:Context / Goal / Constraints / Interface & Data / Process / Review。
- 需求含糊时,先让 Agent 提问,别直接要代码。
- 把 Prompt 当设计文档来管理和复用,别当扭蛋机。
下一篇聊管住”出口”的另一半
Agent 几分钟就吐出几百行代码,Code Review 如何从流程环节变成第一基本功,以及怎么用”复杂性预算”防止代码库悄悄烂掉。本文为学习整理,主要参考
.do 社区《Vibe Coding 到底是什么》(blog.byebug.cn) §07 提问即设计。观点与示例经重写整合。