跳到主要内容

坏 prompt → 好 prompt 对照

一句话摘要：同一个需求，换个写法，我的产出质量天差地别。下面 6 组对照，每组都是「你常这么写 → 我大概率跑偏」加「这么写 → 我能一次到位」，照着改你的 prompt 就行。

我不是读不懂你的话，我是会默默替你补全你没说的部分——补的方向常常不是你要的。这页把六种最常见的「我会猜错」的写法摆出来，每组给坏版、一句「为什么坑我」、再给好版。挑你眼下要做的那种，直接套。

判断一个 prompt 好不好，有个粗暴标准：把它发给一个不认识你项目的同事，他能不问就动手吗？能，我多半也能。

1. 需求模糊：你以为说清了，其实留了一堆岔路口​

坏：给用户列表加个搜索。

为什么坑我：搜什么字段、要不要模糊匹配、输入即搜还是回车触发、空结果怎么显示——你没说的每一处，我都会挑一种实现，而且不告诉你我挑了。等你看到成品，跑偏的是方向，不是细节。详见 需求有歧义时我会挑一种解读直接实现。

好：在用户列表页加搜索框。
- 搜 name 和 email 两个字段，子串匹配、大小写不敏感。
- 输入停顿 300ms 后自动触发（debounce），不用按回车。
- 无结果时显示「没有匹配的用户」，不要显示空表格。
- 复用现有的 <SearchInput> 组件，别新写一个。

把我可能拐弯的每个岔路口提前堵上。你不必写成需求文档，但凡是「换个人读会有不同答案」的地方，点一句就够。

2. 没给约束：不说安全 / 依赖 / 风格，我就按训练里最常见的来​

坏：写个函数，把上传的头像存到 S3。

为什么坑我：我不知道你的安全红线和工程约定，就会填一套「网上最常见」的默认值——可能把密钥硬编码进代码、pip install 一个你团队从没用过的 SDK、用一套和你代码库格格不入的风格。这些不是 bug，是我替你做的、你没同意的决定。

好：写个函数把上传的头像存到 S3。约束：
- 凭据从环境变量读（AWS_* 已配好），绝不硬编码。
- 只允许 jpg/png，限制 5MB，存之前校验 MIME，不信任文件扩展名。
- 用项目已有的 boto3，别引新依赖。
- 跟着 services/ 目录现有写法：函数式、显式抛 StorageError。

安全、依赖、风格这三类约束，我自己补的默认值最容易让你返工。与其事后 review 时挑出来，不如开工前一次给齐。

3. 大改动不要计划：直接让我动手，我就一头扎进去改​

坏：把整个认证模块从 session 改成 JWT。

为什么坑我：这是个牵涉多文件、可能改坏登录的大改动。你不让我先出方案，我会边想边改，等你发现思路不对，半个模块已经被我翻了一遍，回滚成本比一开始就对齐方案高得多。详见 跳过计划模式。

好：我想把认证从 session 改成 JWT。先别写代码——
用 plan mode 给我一份方案：要动哪些文件、token 怎么签发和刷新、
现有 session 怎么平滑迁移、有哪些坑。我确认后你再动手。

凡是「改坏了不好收拾」的改动，先要方案、后要代码。让我把要走的路画给你看，你花两分钟挡掉错误方向，比让我闷头跑半小时再推倒值。

4. 不要验证：只说「实现」，我就只交一段看起来能跑的代码​

坏：实现一下密码强度校验。

为什么坑我：「实现」对我意味着「写出来」，不意味着「证明它对」。我会交一段读起来合理的代码，但边界条件（空串、超长、Unicode、纯空格）有没有处理，我没验证你也不知道。它可能在第一个真实输入上就裂开。

好：实现密码强度校验，规则：≥12 位、至少含大小写和数字。
同时：
- 写 jest 单测覆盖：合规、太短、缺数字、空串、纯空格、超长这几类。
- 跑 `npm test`，把结果贴给我；红的就修到全绿。

把「怎么算做完」明确成可验证的动作——写哪几类测试、跑哪条命令、要看到什么结果。否则我交的是「看起来完成」，不是「确实完成」。

5. 范围无界：一句开放式指令，我会越改越多​

坏：顺手把这个文件整理一下，能优化的都优化了。

为什么坑我：「能优化的都优化」对我是一张没有边界的授权书。我会重命名变量、调整结构、顺手「修」掉一些我以为是问题的地方——结果一个本该 3 行的改动变成 200 行 diff，里面混着你没要、也没法快速 review 的东西。详见 越改越多的范围蔓延。

好：这个文件里 parseConfig 有个 bug：传空对象会抛错。
只修这一个函数，让它对空对象返回默认配置。
别动其他函数，别调格式，别重命名——最小 diff。

给我一个明确的边界，并说清「不要做什么」。范围越小、我越不会自作主张，你 review 起来也越快。想多做几件事，就拆成几条分别下，每条都收口。

6. 倒一堆上下文：把整个文件 / 整个日志糊给我，而不是相关那一段​

坏：[粘贴整个 2000 行的 server.js]
这里面有个 bug，帮我找找。

为什么坑我：我的注意力会被无关内容稀释。上下文越长，中间段落越容易被我忽略，真正相关的那 20 行反而淹没在噪声里——你以为给得越全我越懂，实际常常相反。

好：UserService.login() 在密码错误时返回 200 而不是 401。
相关代码（server.js:142-180）：

```js
async function login(req, res) {
  // ……贴这 40 行 ……
}
```

报错日志的关键 3 行：
[贴那 3 行]

帮我定位为什么状态码不对。需要更多上下文我再给你。

给我相关的那一刀，不是整块。带上行号和最小可复现片段；缺什么我会主动问你要，比我在两千行里大海捞针靠谱得多。

这六组不用背。记一条就够：凡是我可能替你猜的地方，你提前说一句——字段、约束、要不要先出方案、怎么算验证过、改到哪为止、给哪一段。把猜的空间压没了，我的产出才稳。

适用边界​

适合什么时候用​

  • 学习怎么把一句模糊指令改写成我能照着稳定执行的清晰指令。
  • 当你发现我「猜错了方向」时，拿来对照自查是哪一类没说清。

不适合什么时候用​

  • 你已经能稳定写出清晰 prompt 时——这是入门对照表，不是每次都要走的流程。

使用前请替换​

  • 例子里的函数名 / 文件名 / 行号 / 命令都是示意，换成你的真实上下文。
  • 「好」的那版里「相关那一段」要真的截出来贴给我，别照搬「粘整个文件」的坏习惯。