我的观点：算，而且是核心部分
system prompt 是 AI 产品的「隐形 UI」。用户感知到的语气、人格、回答风格、什么该答什么不该答，全是它定的。ChatGPT 的讨好型语气、Claude 的谨慎克制、豆包的口语化活人感，这些差异化体验不是模型自带的，是产品团队拿 prompt 和微调调出来的。之前好几家产品的 system prompt 被用户套出来，大家发现动辄几千字，细则多到像员工手册——说明头部团队就是把它当产品文档在经营。
既然它定义体验，PM 就没法置身事外。传统产品里你不会把按钮文案交给工程师自由发挥，prompt 也一样。把它当纯技术实现，等于把产品人格外包了出去。
PM 管什么：行为规范，不是具体措辞
分工上有个度。PM 负责写「行为需求」：人格设定（专业还是亲切）、禁区清单（不碰医疗诊断、不评价竞品）、格式偏好（先给结论还是先给过程）、长答案还是短答案。工程和算法同学负责翻译成具体 prompt 措辞，因为哪些写法对模型有效需要实验，有些反直觉的技巧（角色设定放哪、指令顺序怎么排）不是拍脑袋能定的。PM 亲自下场抠字眼，往往写得又长又自相矛盾——既要「简短」又要「全面」，模型夹在中间两头不讨好。
prompt 必须当代码一样管版本
这是我见过的团队最容易踩的坑。prompt 躺在某个后端配置里，谁都能改，改完不测直接上线，线上人格说变就变，用户察觉到了都说不出哪里不对。正确的姿势：prompt 进 git 管理、变更走评审、每次改动跑评测集回归。评测集不过，prompt 就不许上——这条要写进发布流程，不是靠自觉。出事最多的场景从来不是大改版，而是「顺手优化了一句话」。
badcase 驱动迭代，别靠灵感改 prompt
prompt 优化的正路是从 badcase 出发：收集用户点踩的、客服投诉的、review 出来的问题，先归类归因——知识问题、能力问题还是行为问题。只有行为问题才用改 prompt 解决；知识问题补 RAG，能力问题等模型升级或换模型。拿 prompt 硬治知识问题，写出来的是补丁摞补丁的屎山，几千字之后没人知道哪条还起作用，一删就出别的事故。
补一个节奏上的判断：prompt 迭代别天天改。我的做法是攒一批 badcase 集中改一轮，改完跑全量回归。天天微调，评测集的意义就没了——你不知道今天的分数是行为稳定下来的结果，还是昨天那一刀碰巧改的。
写 prompt 的几条实操常识
虽然具体措辞归工程，但 PM 评审时得看得懂好坏。几条常识：指令要正向具体，写「用三句话总结」比「别太长」有效得多，负面禁令模型经常反着听；规则之间别打架，「回答要全面」和「回答要简短」同时存在，等于把矛盾丢给模型抛硬币；重要规则别埋中间，长 prompt 首尾权重高，夹在中间的条款最容易被忽略；few-shot 示例比抽象描述管用，给一个「标准答案长这样」的样例，顶三行形容词。评审时拿这几条过一遍，能挡掉八成明显有问题的 prompt。