网上讲提示词的文章很多，但真正每天都在用的其实就那几招。下面七条是我自己反复验证过、几乎形成肌肉记忆的写法，按使用频率排序。
1. 先说「验收标准」，再说需求
大多数人只写需求，我习惯把怎么算做完一起写：
需求：给导出接口加一个按时间范围筛选的参数。 验收：
GET /export?from=2026-01-01&to=2026-01-31返回这段时间的数据；不传参数时行为不变；from 大于 to 时返回 400 和明确提示。
差别很明显：不写验收标准时，它给的实现经常「功能对但边界不对」。
2. 给一个样例，胜过三段描述
想要什么格式，直接给一条实例：
按这个格式生成，不要加别的字段：
{"date":"2026-09-01","pv":128,"uv":64}
少样本比形容词管用。你说「简洁一点」它只能猜，你给一条样例它就照着抄。
3. 「先给方案，别写代码」
改动稍大一点的需求，我都会先让它出方案：
先别改代码。告诉我：要动哪几个文件、每个文件加什么函数、有没有更简单的做法、有没有副作用。
这一步能挡掉一半的返工——很多时候它给的第二个方案比第一个简单得多。
4. 要求它标注「不确定」
回答里，凡是你没有把握的地方都标出来，不要猜。
不要求的话，它会把「推测」和「确定」写得一模一样。要求之后，我至少知道哪里需要自己查文档。
5. 「如果我的思路有问题，先反驳我」
这是我认为最值钱的一句。默认状态下它是有求必应的，你让它用错方案它也会认真实现。
我的想法是 X。如果你认为有更合适的做法，先说理由，再给方案。
6. 固定输出格式，方便二次处理
要么给表格，要么给 JSON，别让它自由发挥：
用表格输出：列是「方案 / 优点 / 缺点 / 适用场景」，不要写前言和总结。
需要喂给脚本的时候直接要 JSON，并要求「只输出 JSON，不要代码块标记」。
7. 复杂任务先让它复述
一个任务如果超过三步，我会加一句：
先用一句话复述你要做的事和我给的约束，确认后再开始。
它复述错的地方，往往就是我没说清的地方——这句话表面上在检查它，实际在检查我自己的表达。
几个我不用了的写法
- 「你是一位资深 10 年的架构师」：对结论质量几乎没有可观测的提升，不如把项目约束写清楚；
- 一长串「必须、务必、绝对」：约束太多会互相冲突，它只能挑几个执行；
- 把整个需求塞进一段话：我现在的习惯是分点写，一点一个约束，方便它逐条兑现。
小结
这七条归结起来就三件事：把上下文给足（验收标准、样例、约束）、要求它暴露不确定性（标注、反驳、复述）、规定输出形态（格式、分点）。提示词没有那么玄，它更像「把需求文档写清楚」——这件事本来就该做。