你的第一个有效 Prompt

Prompt 不是咒语

很多人刚接触 AI 编程时会有一种误解，觉得 Prompt 是某种需要精心措辞的魔法咒语——用对了关键词就能出奇效，用错了就白搭。

其实不是这样。Prompt 的本质就是任务描述，跟你在 Jira 上写 ticket、在 Slack 里给同事交代任务没什么区别。写得好不好，取决于你有没有把任务想清楚，而不是用了什么花哨句式。

差 Prompt vs 好 Prompt

# [反例] 差 Prompt
$ "写一个处理日期的函数"

# [正例] 好 Prompt
$ "在 src/utils/date.ts 中创建 formatRelativeTime：
   - 输入：ISO 8601 时间字符串
   - 输出：'刚刚'/'X 分钟前'/'X 小时前'/'X 天前'
   - 不使用第三方库
   - 导出为 named export"

差距一目了然。第一个 Prompt 缺少位置、缺少细节、缺少约束，Claude Code 只能靠猜——猜错了你又要花时间纠正，来回折腾反而更慢。

好 Prompt 的四个要素

我总结下来，写 Prompt 其实就是回答四个问题：

1. 位置（Where） —— 在哪个文件、哪个目录操作。不指定位置，Claude Code 可能把代码写到一个你意想不到的地方。

2. 目标（What） —— 要做什么，预期结果是什么。这部分越具体越好。

3. 约束（How） —— 技术约束、风格要求、不能做什么。比如”不用第三方库”、“遵循项目现有的错误处理模式”。

4. 粒度（How much） —— 一次做多少。我的经验是，先让它做一个小的，确认方向对了再继续，远比一口气让它做完要靠谱。

速记：位置 + 目标 + 约束 + 粒度。刚开始可以对着这个清单逐项检查，写多了自然就形成习惯了。

常见坏习惯

我踩过的坑，也见过很多人踩：

一次说太多。 一个 Prompt 里塞了五六个不相关需求，Claude Code 要么顾此失彼，要么生成一大坨你根本不想 review 的代码。拆开来，一次一个，效果好得多。

然后是用行话但不解释的问题。你说”做一下 SSR”，Claude Code 能理解这个概念，但它不知道你要用什么框架、输出格式是什么、跟现有代码怎么集成。越是你觉得”它应该懂”的东西，越值得多写一句。

还有一种常见的问题是只说不要什么。“不要用 any 类型”不如换个说法——“所有参数都要有明确的 TypeScript 类型”。正面描述比负面描述更容易让 AI 产出你想要的结果。

最后，别忽略项目上下文。Claude Code 可以读你的代码，所以告诉它”参考 src/utils 里现有的风格”，比你自己描述半天风格要求管用得多。善用这个能力。