工程师Dan McKinley撰文《Prompts Aren't Real》，基于在生产环境让Agent可靠运行的经验，提出提示词不是核心资产，可自我修正的评测与优化系统才是。消息提到，这一观点来自实践总结，并非招聘结论。对想投Agent产品岗的人，它更像一道职责核查题：你应聘的到底是打磨提示词，还是搭评测与优化闭环？

两类职责，准备方向不同

如果团队把重心放在提示词上，日常可能是写模板、调措辞、按场景改指令，产出快、反馈直接，但经验容易随模型迭代贬值。如果重心在评测与优化，工作会围绕定义“可靠”、设计评测集、归因bad case、验证迭代是否真的变好展开，节奏慢，却更接近系统能力。

假设一个模拟场景：同一句“回答不准确”，一类做法是改提示词再试一次；另一类做法是先查评测集里这类问题占比多少、上次改动是否让其他场景回退。两种做法对候选人的要求不同，前者偏表达与场景理解，后者偏度量设计与因果判断。

面试时问清团队重视什么

不要直接问“你们重视提示词还是评测”，对方容易给标准答案。可以换成具体问题：团队怎么定义Agent的“可靠”？效果不好时，第一反应是改提示词还是先查评测？评测集由谁维护、多久更新一次？上线前有没有固定的回归验证？

从回答里听三件事：有没有稳定的评测资产，效果归因是否有流程，产品岗在其中是执行还是设计。如果对方只说“提示词写得好就行”，而你对评测闭环更感兴趣，就要判断这个岗位的成长空间是否匹配。

提前准备：把经历翻译成评测语言

想往评测与优化方向准备，不必先假设自己会搭系统。可以先梳理过去是否做过效果度量、bad case归因、迭代验证类工作，用[实际记录]这类具体经历说明你如何判断一次改动是否真的有效。

如果缺少直接经验，可以练习把一个小任务拆成“目标—评测标准—失败样例—验证方式”，面试时讲清你的思考过程，而不是只强调会写提示词。同时向目标岗位核查：这个职责是否真实存在、由谁承担、产品岗能参与多深。

一个实际可做的小建议：挑一个你用过的Agent产品，写下三条你认为它“不可靠”的具体表现，再各想一条验证方式。带着这份记录去面试，比背观点更能问出团队的真实重心。