AI prompt engineering 深度访谈

开场说明本次圆桌聚焦提示工程，希望从研究、消费者和企业落地等不同角度讨论提示工程究竟是什么。随后嘉宾依次介绍背景：Alex 负责 Anthropic 开发者关系，曾在提示工程团队工作；David 主要帮助客户做微调、提示和语言模型系统搭建；Amanda 领导微调团队，关注让 Claude 更诚实友善；Zack 是提示工程师，参与客户支持、提示生成器和教育材料建设。

Zack 将提示工程概括为让模型完成事情、发挥模型能力，并认为其核心很大程度上是清晰沟通，类似与人交流但又能利用模型对话的“重置”能力反复实验。David 补充说，提示也像一种给模型编程的方式，但不应过度抽象，关键仍是清楚描述任务。同时，提示常嵌入更大的系统中，需要考虑数据来源、RAG、延迟、上下文长度、实验跟踪和版本控制，因此它既像写作，也像工程实践。

Amanda 认为优秀提示工程师需要清晰沟通、理解任务、描述概念，并且比单纯写得好更重要的是愿意快速迭代。她强调真实工作中会在很短时间内向模型发送大量提示，观察哪里被误解并修正。她还指出常见错误是只测试典型案例，而没有构造异常、空输入、无匹配数据或非数据集等边界情况。David 补充，企业客户常高估用户输入质量，真实用户可能拼写混乱、缺少标点或只输入关键词，因此评估集必须贴近真实流量。

嘉宾将机器学习里“看数据”的原则类比到提示工程，认为提示工程师必须仔细阅读模型输出，而不仅看任务是否完成。Zack 举例说，人们常在提示里写“think step-by-step”，却不检查模型是否真的按步骤思考。David 提到写指令时很难意识到自己脑中隐含了多少背景知识，好的提示工程师要能剥离自身假设，把模型完成任务所需的信息完整写出。Amanda 还介绍一种方法：让模型先不要执行任务，而是指出提示中不清楚、歧义或无法理解的地方，并在出错后请模型解释错误和建议改写。

主持人追问模型是否真的能识别自身错误，Amanda 回答说如果明确告诉模型哪里错了，它有时能在查询中发现问题并提出有效修正，虽然成功率因任务而异，但值得尝试。随后她解释自己并不是默认信任模型，而是不断“敲打”模型，测试它能否胜任任务。她指出模型在稍微偏离训练分布或遇到不寻常场景时可能突然不可靠。相比松散构造的数千个样例，她更信任精心设计、覆盖边界情况的几百个提示及其稳定输出。

David 将传统机器学习中的数字信号与语言模型输出进行对比：传统评估常看预测是否正确、logprobs 等数值，而语言模型会输出大量文字，这些文字中包含模型如何理解任务、如何推理、经过哪些步骤等信息。因此提示工程不能只判断结果对错，还要阅读模型回答的细节，从字里行间推断模型为什么这样做，以及提示是否引导了正确的中间过程。

Amanda 强调，最好的提示实践可能直接决定实验失败还是成功。她对忽视提示设计的实验感到不满，因为提示质量可能让模型表现从前 5% 提升到前 1% 或 0.1%，从而改变实验是否成立。她认为，如果研究者愿意花很多时间把实验代码写得很好，却不愿意认真打磨提示，这是不合理的。Zack 也补充，在产品部署中常出现原本“不能上线”的情况，但调整提示后系统突然可用。