先做减法：别写"帮我优化这段代码"，要写清楚对象、约束和期望输出——"这段 Python 脚本有重复代码，请提取函数并保持行为不变，输出完整新版"。模型不会读心，信息密度决定结果上限。

再给上下文。这里的"角色设定"不是套话，是在对齐默认假设。让模型"以资深 SRE 的身份"看一段日志，它会更自然地关注超时、重试、资源泄漏这些点。一个例子抵十句描述：给一组"输入到正确输出"的样例，尤其是边界情况的样例，效果立竿见影。

大任务拆小。一次只让模型做一件事：先总结要点，再让根据要点写正文，最后单独润色。一步到位的长任务，中间任何一步偏了，后面全跟着偏。

输出格式要下命令。要表格就规定列名，要 JSON 就给定字段和示例值。模型的格式服从度很高，问题是你不说它就会自由发挥。

最后是迭代心态。把第一次输出当草稿，指出错误让它改，这比反复重写提示词更高效。我现在写复杂 prompt，基本都要和模型"对话调试"两三轮才定稿。

说到底，提示词工程的终点不是技巧熟练，而是你能不能用清晰的语言描述自己到底要什么。这个能力，写需求文档时同样用得上。