团队拿到一批不理想的 AI 输出时，最常见的反应是换模型。换模型当然值得测试，但很多问题在这一步之前就已经发生了。
输入里没有用户、场景、材料边界和输出标准，模型只能猜。它猜错以后，再强的模型也很难替团队补完一份不存在的需求。
Prompt 是给模型的产品规格
一份可用的 Prompt，至少要让模型知道它服务谁、处理什么输入、完成什么任务、不能越过哪些边界，以及结果将被谁使用。
这和需求文档的逻辑很接近。产品经理不是把一句想法转交给开发，而是把目标、场景、约束和验收写成双方能理解的契约。Prompt 也应该承担同样的工作。
角色只是其中一小部分。真正影响输出的，通常是上下文是否完整、任务是否具体、输入材料是否可靠、输出格式能否被后续系统消费。
示例比形容词更有用
“专业一点”“写得有深度”很难执行，因为每个人对这些词的理解都不同。一个合格样例和一个不合格样例，反而能更快说明边界。
示例不是为了让模型照抄。它帮助团队把原本模糊的偏好变成可以讨论的标准：哪些信息必须出现，哪些表达不能接受，结构要稳定到什么程度。
但示例也不能代替真实输入。如果样本只覆盖最顺利的情况，Prompt 在演示里会很好，到了真实场景仍然会失控。
迭代要有记录
Prompt 不是写完一次就结束。每次修改都应该留下三个信息：改了什么，为什么改，用同一组样本验证后有什么变化。
没有固定样本，两个版本就无法比较。没有版本记录，团队也很难判断效果变化来自 Prompt、模型、知识库还是输入数据。
这也是我把 Prompt 看成产品规格而不是文案技巧的原因。它需要版本、评测和责任人，也需要和数据、工具权限、失败处理一起设计。
Prompt 也有能力边界
清楚的规格可以减少歧义，但不能制造模型没有的知识，也不能修复错误数据。需要实时信息时，系统要提供可靠工具；需要高风险判断时，产品要设置校验和人工复核；需要稳定结构时，代码层还要继续验证输出。
所以遇到坏结果，我不会先寻找“更厉害的咒语”。我会先检查需求是否完整，输入是否可信，评测是否一致，失败时是否有兜底。
如果这份说明交给一个真实同事，他仍然不知道该做什么，那模型大概率也不会知道。