提示词写法与反模式

核心结论

提示词的本质是把任务交代清楚，不是念咒语。

网上那些“神奇咒语”大多没用。真正影响输出质量的是：信息完整度和约束明确度。

可抄的结构模板

任务：[一句话说清要做什么]

背景：
- [相关信息 1]
- [相关信息 2]
- [现状/问题]

要求：
1. [具体要求]
2. [具体要求]
3. 不要 [明确排除项]

验收标准：[怎么算做完了]

五个部分里，背景和不要做什么最容易被省略，也最影响结果。

五个高频反模式

反模式一：太短

❌ "优化一下这段代码"

AI 不知道优化什么——性能？可读性？内存？结果大概率是给你重写一遍，还改了你不希望改的地方。

✅ "优化 queryUsers 函数的性能：
    现状是循环里逐条查库，1000 条数据耗时 3 秒
    要求改成批量查询，保持函数签名和返回结构不变
    验收：1000 条数据耗时降到 500ms 以内"

反模式二：一次给一堆任务

❌ "重构项目 + 加测试 + 更新文档 + 顺便看看有没有 bug"

出问题你要回滚一大片，而且根本没法逐步验证。

✅ 拆成四次，每次验收通过再进入下一个

反模式三：不写排除项

AI 倾向于“多做一点”。不写明确排除，它就会顺手改你不想动的东西。

✅ "...不要改动与本次任务无关的代码，不要新增依赖"

这句能省掉你一半的 diff 审查时间。

反模式四：只描述症状不报错信息

❌ "运行报错了，说模块找不到"
✅ "运行 npm run dev 报错：[完整堆栈粘贴]"

堆栈里有文件名、行号、调用链。你概括成一句话，等于把最有价值的信息扔了。

反模式五：没有验收标准

任务做完了吗？AI 说做完了就是做完了？

✅ "验收：npm test 全部通过，且手动打开 /login 页面能正常登录"

三个进阶技巧

技巧一：让它先复述理解

复杂任务开始前加一句：

先用你自己的话复述一遍你要做什么，我确认后再执行。

它理解错了，你一句话就能纠正；等它做完再发现，返工成本高十倍。

技巧二：给示例

说不清要什么的时候，给个例子最快：

输出格式参考这个例子： [贴一个你满意的示例]

比描述十句话都管用。

技巧三：明确角色和读者

你是一个有 10 年经验的前端架构师， 给一个刚工作一年的开发解释这个概念。

角色决定深度，读者决定表达方式。同一件事，讲给专家和讲给新人，写法完全不同。

对话中的迭代

第一版不满意很正常。有效的追问方式：

❌ "不行，重写"
✅ "整体方向对，但第三部分太啰嗦，压缩到 100 字以内，
    另外补一个具体的代码例子"

说清楚哪里不对和想要什么，而不是笼统否定。

判断提示词够不够好的标准

问自己：把这段话发给你同事，他能直接开工吗？

不能，就补信息。这个标准比任何技巧都实用。

下一篇

常见报错排查手册——环境问题的速查表。