一家非技术公司想招人专职写提示词，却卡在技能不对口、工作量前重后轻、薪资给不上去的矛盾里。文章拆解这个岗位难设的结构性原因，对比业务兼任、开发兼职、外部顾问、全职专职、供应商五种做法的适用场景，并给出一套以评测集为核心、可交接可回归的提示词落地流程。
一家偏销售性质的公司想给 AI 应用配一个专门写提示词、调提示词的人，结果卡在了几个很现实的问题上：这件事看起来不需要多深的开发功底，找纯开发不对口；工作量集中在上线前那一个月，之后只剩零星维护，工资给不上去；想让业务部门的人兼任，又发现要教的技术细节太多。
这类纠结在中小团队里很常见。它表面上是招聘问题，本质上是一个「这件事该由谁负责、怎么判断做得好不好」的问题。下面把常见的几种思路拆开讲，并给出一套可以直接照做的落地流程。
这个岗位为什么难设
工作量是前高后低
提示词工作在第一版从零到可用时最密集：整理场景、试模型、调格式、处理边界情况。等主流程跑顺，剩下的主要是新场景接入和零星修复。按全职岗位的编制去养一段长尾维护，成本上不划算；按兼职去做前期攻坚，又容易在关键期投入不足。
需求本身是模糊的
提出需求的人往往说不清「好」的标准。业务方会说「回答得更准确一点」「语气再专业些」，这类描述无法直接转成提示词改动。真正的工作量花在把模糊诉求翻译成可验证的输入输出样例，这部分不是纯技术活。
能力栈横跨技术与业务
纯开发擅长写脚本调接口，但不愿意反复和业务对齐口径；纯业务懂场景，但遇到模型输出格式漂移、上下文超长、JSON 解析失败这类问题时没有排查思路。理想人选是中间地带的人，而这种人在招聘市场上本来就少。
五种组织方式，按场景选
| 方式 | 适合场景 | 优点 | 风险 |
|---|---|---|---|
| 产品经理或业务骨干兼任 | 场景集中、只有一两条主链路 | 懂业务、沟通成本最低、成本几乎为零 | 需要补基础工具能力，容易停在「能跑」而不做评测 |
| 内部开发兼职 | 已有研发团队，提示词与代码强耦合 | 上手快，能顺手把调用链和日志做规范 | 单纯靠补贴很难长期占用开发时间，优先级常被挤掉 |
| 外部兼职顾问 | 前期需要突破，内部无人能带 | 按项目或按小时结算，前期攻坚性价比高 | 知识容易留在外部，交接不彻底会变成长期依赖 |
| 全职专职 | 提示词是产品核心竞争力，且场景持续扩张 | 响应快、沉淀完整 | 长尾期人力闲置，招聘难度和成本都高 |
| 供应商整体方案 | 一次性项目、验收标准能写清楚 | 省事，责任在对方 | 报价差异极大，黑盒交付后难维护 |
多数中小团队的现实解是「内部有人负责 + 外部短期补位」：由产品或运营作为需求与验收的责任人，让一位懂点代码的顾问在前期把框架、评测和文档搭起来，之后交回内部维护。
如果确实要招人，重点看这四项
- 需求拆解与沟通。能不能把一句模糊描述追问成三五个具体场景和对应的输入样例，这比会背多少提示词技巧重要。
- 基础工程能力。至少能写 Python 脚本批量调用接口、处理返回结果、跑对比实验，理解什么是 token 上限和结构化输出。
- 评测意识。改完提示词后，能不能拿出「改前对了多少条、改后对了多少条」的数据，而不是凭感觉说变好了。
- 工程可维护性。是否习惯把提示词放进版本管理、写清变更原因、保留失败案例。有 RAG 或结构化抽取经验是加分项，但不是必须。
工作年限上，两三年的技术背景加较好的沟通表达，通常比资深的算法背景更贴合这类岗位。至于薪资，讨论中出现的数字跨度很大：兼职补贴只有几千元，部分城市挂出的专职岗位在 6–8K 区间，而供应商的整体方案报价可以到数万元。这些只能当作参考坐标，具体行情需要按所在城市和岗位实际职责去招聘平台和当地市场核实，不宜直接套用。
一套可执行的工作流
无论人从哪来，流程应该是同一套。核心思路是：先有评测集，再谈优化。
第一步：列场景清单
把所有要用到提示词的业务场景写成列表，每个场景注明输入是什么、期望输出什么格式、失败会造成什么后果。优先做高频且失败代价高的场景。
第二步：准备评测集
每个场景准备 20–50 条真实输入，包含正常样本、边界样本和已知的失败样本。这一步最花时间，但它是后续所有判断的基础。样本注意脱敏。
第三步：跑基线并记录
用固定模型、固定参数跑一遍，把每条的输出和判定结果存档。之后每次改动都在同一份评测集上重跑，对比通过率。
第四步：迭代与回归
改提示词时一次只动一个变量，改完立刻回归。失败案例要及时补进评测集，防止同一个坑踩第二次。
第五步：交接与版本管理
提示词文件、评测集、评测脚本、变更记录放在同一个仓库里，任何人接手都能复现结果。
可以用 promptfoo 这类开源工具把上面的流程串起来，配置文件大致如下：
prompts:
- file://prompts/extract.txt
providers:
- id: openai:<model-name>
- id: anthropic:<model-name>
tests:
- vars:
input: "客户要求退掉上个月买的设备"
assert:
- type: contains
value: 售后
- type: llm-rubric
value: 输出必须是合法 JSON，且包含订单号与意图两个字段
跑批和查看结果分别是 npx promptfoo@latest eval 和 npx promptfoo@latest view，具体参数以官方文档为准，工具迭代较快。
需要注意，跑一次完整评测往往是几十上百次模型调用，耗时可能几十分钟甚至更久，本地笔记本合盖就断。如果团队没有常驻的服务器，可以把评测任务放到一台长期在线的远程机器上执行（比如放在新加坡机房的独享远程 Mac，按月租用、远程连接），保证批量任务不中断、网络出口稳定；如果只是偶尔手动跑几条，本地执行就够了。
找兼职或外部顾问，怎么谈才不吃亏
- 按里程碑结算，不按提示词条数结算。 按条数计价会诱导堆砌数量，而真正有价值的是评测集和通过率。
- 把交付物写清楚。 至少包括：提示词文件、评测集、评测脚本、使用说明、已知问题清单。
- 约定变更责任期。 模型升级或业务规则调整后，提示词可能失效，明确一段时间内的修复义务。
- 要求全程在内部仓库作业。 避免成果散落在个人聊天记录或私人文档里。
- 先做小范围试点。 用一个小场景验证对方的方法论，再决定是否扩大合作。
- 数据脱敏。 涉及客户信息的样本不要原样交给外部人员，也不要在来源不明的第三方平台上调试。
几个容易踩的坑
- 只测「看起来对不对」。 没有评测集的优化等于换一种说法赌博。
- 把提示词存在聊天记录里。 换个人接手就要从零重来。
- 忽视模型升级的影响。 上游模型更新后输出风格和格式可能变化，评测集是唯一的兜底。
- 过度依赖外部供应商。 交付是黑盒，后续每次小改都要重新付费。
- 指望靠提示词解决所有问题。 如果场景本身数据缺失、规则矛盾，再好的提示词也救不回来，这时候应该回头修数据或改产品流程。
小结：先回答三个问题再决定招不招
- 这个场景未来半年会不会持续扩张？如果不扩，倾向内部兼任加短期顾问。
- 团队里有没有人能承担「需求翻译 + 验收」的责任？如果没有，先解决这个问题，招人也留不住。
- 能不能拿出二三十条真实样本作为验收标准？拿不出来，说明需求还没到可以外包或招聘的程度。
把这三问答完，是用兼职、顾问还是全职，答案基本就浮出来了。提示词本身不神秘，难的是把它变成一件可衡量、可交接、可回归的工程事项。