刚开始使用大模型时，我也收集过不少“万能提示词”。它们通常很长，包含角色设定、思考步骤和一连串强调语，看上去像某种能稳定召唤好答案的咒语。实际用久了会发现，决定结果的往往不是句式有多神秘，而是我们有没有把任务说明白。
模型并不知道我脑中的默认条件。只说“帮我写个方案”，它只能猜方案给谁看、解决什么问题、需要多长、能投入多少资源。猜对了像惊喜，猜错了也不代表模型没能力，更多时候只是信息没有对齐。
先说清楚要完成什么
一个有效请求首先要有明确目标。与其说“介绍一下 Docker”，不如说“为第一次接触 Docker 的前端开发者写一篇入门说明，读完后能理解镜像和容器的区别”。后一句不仅给出了主题，还说明了读者和预期结果，模型更容易判断该讲到什么深度。
如果任务来自真实场景，再补一点上下文会更有用。例如准备内部分享，可以说明听众人数、已有基础和分享时长；排查程序问题，可以提供报错信息、运行环境、相关代码以及已经尝试过的办法。上下文不是越多越好，关键是它是否会影响答案。
把限制条件摆在桌面上
很多不满意来自隐藏的约束。我们心里想着“不要太正式”“预算不能超过两千元”“只能用现有技术栈”，却没有告诉模型。它自然会给出一个逻辑成立、但无法落地的答案。
所以我会提前写明必须遵守的边界：篇幅、语气、时间、预算、技术版本、不能采用的方法，以及哪些信息需要谨慎处理。限制不必写成复杂规则，简单的一两句话就够了。比如：“使用通俗中文，控制在 800 字以内，不假设读者会 Linux 命令。”这比事后反复要求“再简单一点”省事得多。
指定交付形式，并给一个小例子
同样的内容，可以是一段说明、一张表格、一份检查清单，也可以是可直接运行的代码。如果答案要复制到邮件、文档或程序中，提前规定输出格式，能减少很多整理工作。例如：“先给结论，再列三条理由，最后给出一份可执行清单。”
当风格或结构难以用语言描述时，一个简短示例尤其有效。想让模型生成商品标题，可以提供一条满意的标题，并指出希望保留的是长度和语气，而不是让它照抄内容。示例的作用是建立参照物，不需要准备许多条；一两个清晰样本通常比“高级、专业、有网感”这类模糊形容更可靠。
信息不足时，先让模型提问
并非每次都要一次性写出完整提示词。对于需求访谈、旅行规划、技术选型、简历修改等依赖个人情况的任务，我常在末尾加一句：“如果缺少会影响结论的信息，请先问我不超过三个关键问题，再开始回答。”
这样做适合答案分支很多、选错方向会浪费大量时间的场景。反过来，如果只是改一句文案、解释一个概念，就没必要增加问答流程。也要注意限定问题数量，否则模型可能像填写调查表一样追问细节。让它优先询问真正影响结果的变量，沟通会更轻松。
把第一次回答当作可修改的草稿
提示词不是提交后就不能更改的考试答案。面对复杂任务，更自然的方式是先获得一版，再给具体反馈：“第二部分太抽象，请增加一个日常例子”“保留结构，但删掉重复内容”“这段代码需要兼容 Python 3.10”。反馈越指向明确的位置和问题，下一版通常越接近预期。
我常用的通用模板其实很短：
我想完成【目标】。背景是【必要上下文】，面向【对象】。请遵守【约束】，并以【输出格式】交付。参考风格或示例：【可选示例】。如果关键信息不足，请先问我最多三个问题。
这个模板不必每项都填。简单任务只说目标即可，复杂任务再逐步补充。真正值得练习的不是记住一套固定口令，而是辨认：对方要完成这件事，还缺哪几块信息。把任务说清楚、看到结果后继续校准，大模型就会从偶尔灵光的聊天工具，变成更稳定的协作伙伴。