提示词维护，到底在解决什么问题

消息提到，OpenAI的Eric Provencher建议在切换模型时复审技能、AGENTS.md和任务提示词。他还把技能描述为存为Markdown文件的提示词，可包含资源和脚本，最适合特定工作流或应用。

对求职者来说，这条动态的价值不在工具本身，而在它点出的一类日常任务：提示词和项目指令不是一次写好就归档的文档，而是会随模型换代、任务变化而失效的工程资产。面试官想听的，往往不是你背了多少提示词技巧，而是你有没有“复审—取舍—验证”的习惯。

面试怎么讲取舍和迭代

Provencher建议保持技能范围描述简短精确，例如Postgres schema迁移技能只在创建或修改迁移、或检查其发布时触发。他也指出，要求模型在每次改动前阅读多份文档或完整项目概览，对修一个拼写错误来说属于过度要求。

这两条正好是面试可用的例子。假设场景：你负责一个内部代码助手，最初规则要求每次改动前通读项目概览，结果小改动也慢。你可以讲自己如何把规则拆成“默认精简、涉及迁移或发布时再指向对应文档”，并说明你用什么信号判断改动有效——比如同类任务是否还需要反复补充说明。注意，这是模拟思考方法，不是真实工作经历，讲的时候要标明。

两类方向关注点不同：偏应用开发的岗位更看你能否把提示词接入实际流程并维护边界；偏产品工程的岗位更看你能否把用户需求翻译成可触发的规则。读岗位描述时，还要确认它说的是设计策略、跟踪效果，还是参与模型训练测试——这些词背后的日常差别很大。

没直接做过，怎么补准备

不必空谈概念。从你已有的项目里挑一个，把提示词、规则文档和任务边界重新梳理一遍：哪些描述过宽、哪些强制阅读是浪费、完成标准是否写清。把这次梳理过程整理成可讲的案例，重点说你的判断依据，而不是结果多漂亮。

如果简历里要写成果，只写实际完成的，例如“[实际记录：把某规则从每次触发改为按场景触发]”，不要编造数字。

一个实际可做的小建议：找一条你写过的提示词，试着删掉一半字数，看任务是否仍能完成；把这次删改的前后对比记下来，面试时就是现成的取舍素材。