写好大模型提示词的 7 个实用技巧：从"能用"到"好用"的 Prompt 工程实践

一、为什么要认真写提示词

很多人第一次用大模型时都有同样的感受：同一个模型，别人用起来像资深工程师，自己用起来却经常答非所问。差别往往不在模型，而在提示词。提示词就是我们给模型的“需求文档”，需求写得越清楚，交付物越接近预期。下面是我在写代码、写技术文档、整理资料时反复验证过的 7 个技巧。

二、技巧 1：先交代角色和背景

模型不知道你是谁、在做什么项目。开头用一两句话说明身份和场景，能明显减少“泛泛而谈”。

• 改进前：帮我写一个登录接口。
• 改进后：你是一名有 5 年经验的 Python 后端工程师。我在用 FastAPI 开发一个内部管理系统，用户表已存在，字段为 id、username、password_hash。请写一个登录接口。

第二种写法里，框架、数据结构、使用场景都明确了，模型就不会再去猜你用 Flask 还是 Django。

三、技巧 2：任务要具体，最好可验证

“优化一下这段代码”太模糊。说清楚优化目标：是性能、可读性还是安全性？最好给出可以检验的标准，例如“把时间复杂度从 O(n²) 降到 O(n log n)”“函数不超过 30 行”“补充类型注解”。目标越可验证，结果越容易判断好坏。

四、技巧 3：明确输出格式

需要表格就说要表格，需要 JSON 就给出字段定义。例如：

请以 JSON 输出，字段为：name（字符串）、score（0-100 的整数）、reason（不超过 50 字）。不要输出 JSON 以外的任何内容。

当输出要被程序解析时，这一条尤其重要，可以省掉大量清洗代码。

五、技巧 4：给示例（Few-shot）

与其用文字描述风格，不如直接给一两个例子。比如让模型生成 Git 提交信息时，先给两条符合团队规范的样例，模型会自动对齐格式、语气和长度。示例要有代表性，并且彼此风格一致，否则模型会学到“混乱”。

六、技巧 5：复杂任务拆步骤

一次让模型“分析需求、设计表结构、写接口、写测试”，结果往往每一步都不够深入。更好的做法是拆成多轮：先让它列出需求要点并确认，再设计表结构，再写代码，最后补测试。也可以在一条提示里要求“先列出思路，再给出最终答案”，让推理过程可检查。

七、技巧 6：给出约束和边界

告诉模型不要做什么，和告诉它做什么同样重要。常见约束包括：

• 不要引入新的第三方依赖；
• 不确定的地方请明确标注“需要确认”，不要编造；
• 回答控制在 300 字以内；
• 只修改指定函数，不改动其他代码。

其中“不确定就说明”这一条能有效减少模型一本正经地编造 API 或参数。

八、技巧 7：迭代而不是重来

第一次输出不理想很正常。与其清空对话重新提问，不如在原有结果上指出具体问题：“第 3 步的异常处理漏掉了网络超时，请补上”“表格第二列改成百分比”。模型能利用上下文快速修正，效率远高于从头再来。把效果好的提示词保存成模板，下次直接复用，团队内也可以共享。

九、一个完整示例

把以上技巧组合起来，一个写单元测试的提示词可以是这样：

你是一名熟悉 pytest 的测试工程师（角色）。下面是一个计算订单折扣的 Python 函数（背景）。请为它编写单元测试，覆盖正常折扣、无折扣、折扣上限、非法输入四种情况（具体任务）。参考下面这条测试的写法（示例）。只输出测试代码，不要解释；不要使用 mock 以外的第三方库；如果函数行为不明确，请在注释中写“待确认”（格式与约束）。

实际使用下来，这样的提示词基本一次就能得到可以直接运行的测试代码，只需少量调整。

十、总结

Prompt 工程并不神秘，本质上是把需求说清楚：交代背景、任务具体、格式明确、给出示例、拆分步骤、设定边界、持续迭代。这些习惯不仅适用于聊天式的大模型，也适用于各类 AI 编程助手和智能体开发。希望这 7 个技巧能帮你把大模型从“能用”变成“好用”，欢迎在评论区分享你的提示词心得。