是基本功，但别神化它
我的观点很明确：是基本功。大多数团队没有专职 prompt 工程师，产品效果的好坏，一大半取决于谁把 prompt 写明白了。prompt 本质上是 PRD 的延伸：角色、任务、约束、输出格式、语气，全在里面。prompt 写得烂的 PM，需求文档通常也写得含糊。
到什么程度算会？一个自测标准：拿到一个业务需求，你能在一小时内写出初版 prompt、搭个小评测集、跑出第一版通过率，并且说清下一步优化点在哪。做不到这个，就还停留在「了解」。
但也别神化。网上那些「价值百万的提示词秘籍」基本是营销，模型能力上去之后，很多花哨技巧自动失效。prompt 工程是手艺活，不是黑魔法。
要掌握到什么程度
PM 不需要会训练模型，但这几样得熟：写 system prompt，把角色、任务、边界、输出格式说清楚；用 few-shot，给三五个典型例子让模型照着做；要结构化输出，让模型返回 JSON 方便程序处理；会拆任务，复杂需求拆成几步串起来，而不是指望一句话搞定。
一个合格的业务 prompt 通常是五段式：角色（你是谁）、任务（要做什么）、约束（不许做什么）、输出格式（按什么结构返回）、例子（两三个输入输出样例）。五段写齐，效果一般不会差；缺了哪段，问题往往就出在哪段。
比写更重要的是会评。我的做法是建一个几十到一两百条典型 case 的评测集，覆盖常见情况和边界情况，每改一版 prompt 全量跑一遍，看通过率变化。凭感觉调 prompt 是最大的坑：你觉得「明显变好了」，一跑评测，修好了三条，弄坏了五条。
写 prompt 的心法
心法就一句话：把模型当成一个能力很强、但完全不了解你业务背景的新同事。你给他布置任务会怎么说，prompt 就怎么写。要什么输出、不要什么、特殊情况怎么处理，都写明白。
给例子时选典型的，别选刁钻的。一次只改一个变量，不然你分不清是哪个改动起的作用。举个我经历过的例子：客服场景做意图分类，把 12 类意图的定义写进 prompt，每类配两三个例句，准确率从七成出头拉到九成以上。靠的不是什么高深技巧，就是把分类标准写清楚了，而这本来就是 PM 的活儿。
补一句心态上的：prompt 初版写得烂不丢人，丢人的是不评测就上线。手感是跑出来的，改过十版 prompt 的人，比看过十篇教程的人懂得多。这门手艺没有速成班，只有一轮一轮的迭代。
prompt 还要像代码一样管起来：版本化、改动留痕、能回滚。改 prompt 上线和发版是一个级别的事，我见过运营同学在后台随手改了句提示词，客服机器人当晚答非所问，排查了半天才定位到。
边界在哪
有三件事 prompt 干不了。
一，复杂任务别指望一个神 prompt，拆成 workflow 或 Agent，每个环节单独可控、单独可测。
二，prompt 会随模型升级失效。换模型版本必须回归测试，GPT 换代时一批产品效果回退，就是没做这一步。
三，prompt 不是护城河。用户套几句话就能把 system prompt 套出来，这类泄露事件出过不少，别往里面放机密。真正的壁垒在你的数据、流程和场景理解里。
还有个容易被忽视的点：把「不做什么」写进去，和「做什么」同样重要。客服机器人要写明「不承诺退款时效、不评价竞品、不讨论敏感话题」，这些负向约束是无数次线上事故换来的经验。模型天生乐意接话，你不拦着，它什么都能聊。
判断一个 prompt 方案健不健康，看改动频率：如果天天在打补丁，说明任务该拆链路或者换模型了，靠 prompt 修修补补是有上限的。
还有个现实趋势要知道：模型每升级一代，对 prompt 的容错就高一截，以前要精雕细琢的技巧，现在大白话也能出活。所以别把精力押在奇技淫巧上，把任务描述、评测集这些硬功夫做扎实，它们不随模型换代贬值。