Anthropic 的一个客户在 24 小时内收到了 2,740 份针对一个职位的申请。
你手动编写的任何提示词，都无法在那么长的时间里保持正确。
阅读那些简历的招聘人员首先会用一个提示词，写着“五年后端经验、初创背景、精通 Python”。
两天后，他们看了第一批简历，发现其实想要的是从零到一的建设者。
提示词已经错了，而他们甚至还没看完第二份简历。
那些交付速度最快的团队已经不再用这种方式编写提示词了。
他们构建了系统，让提示词观察用户实际做出的决策，并在后台自动重写自己。
等到用户注意到自己的偏好有所改变时，提示词早已随之调整了。
这在任何需要人类做出判断、模型辅助决策的场景中都适用：
招聘、客服分流、内容审核、代码审查、交易评分。
下面是如何一步步构建这样一个系统。
提示词不是配置，而是学徒
首先你得转变思维。
配置是你设定后就不再管的东西。
学徒会观察你的工作，捕捉你真正关心的事情，然后进行调整。
你的提示词应该成为第二个。
在 Nick Mayhew 于 Anthropic 舞台上展示的系统中，这个学徒就是一个普通的 markdown 文件。
他们称之为“理想候选人画像”。
没有权重、没有规则、没有流程图。只是用简单的英文描述招聘者到底在招什么样的人。
每次招聘人员批准或拒绝一个候选人，系统都会记录下来。
每条诸如“这个人 Python 经验不够”的评论都会被存储。
每次对手动编辑画像的修改也会被存储。
这堆决策就是提示词更新所依据的训练信号。
为什么是 100 次决策，而不是一次
第一反应是每次操作后都更新提示词。别这样做。
一次决策是噪音。一次拒绝几乎不能告诉你用户真正想要什么。原因可能是这些：
- 用户当时累了或分心了
- 输入的内容很奇怪，与他们的真实偏好无关
- 他们点错了
- 他们在一个明显的例子上快速操作
- 他们故意在测试系统
如果你根据这个重写提示词，你就会开始追逐幻影。
100 次决策才是信号。
你可以看到一个模式：用户一直在拒绝没有初创经验的候选人。
那不是一时情绪，而是一个偏好。现在你可以更新了。
Nick 在台上对此直言不讳。
你每 100 到 200 次决策才会发现模式，而不是每次点击。
成本方面也很重要。
每次操作都运行一个智能模型，预算到中午就烧光了。
分批运行才能让系统在生产环境中存活。
将系统拆分为两层，而不是一个大型 Agent
人们很容易想做一个庞大的 Agent，同时进行评估、学习和更新。
这不可扩展，而且会烧掉你没有的 token。
可行的模式是两层，各有截然不同的工作。
底层是评估器。廉价、快速，对每个输入都运行。
在招聘场景中，就是 Haiku 根据当前画像给每份简历打分。
每天数千次。任务范围窄：接收输入、接收当前提示词、返回结构化判断。
顶层是学徒。更慢、更智能，但很少运行。
它只观察人类做出的决策。
每批决策，它只问一个问题：当前提示词是否仍然匹配用户实际选择的内容？
如果不匹配，它就重写提示词。
大多数团队都跳过了这种拆分。
他们把前沿模型放在每个请求的热路径上，账单爆炸，系统被搁置。
将评估与学习分开，才能让系统在生产中存活。
用散文而非规则编写提示词
这是大多数自改进系统悄悄死掉的地方。
本能是写一个配置：30% 权重给经验年限，20% 给公司级别，10% 给教育背景，关键词标记。
这看起来很严谨。但它产生的系统模型实际上无法更新，因为除了数字以外没有可更新的内容。
而数字无法捕捉招聘人员为什么说“不”。
可行的格式是 markdown 中的普通英文。
“我们希望招到一个从零到一推出产品的人，最好是在少于五十人的初创公司。”
“强大的工程文化比特定的技术栈更重要。”
“红旗标志：只在一千人以上的公司工作过。”
这才是学徒能够实际重写的提示词。
它可以添加一句话、删除一句话、紧缩一个短语。
你无法对加权评分规则做这些操作。
反馈循环就是整个产品
一旦这四个部分就位，系统就可以自主运行。
用户做出决策。评估器根据当前提示词进行评分。
每 100 次决策，学徒读取这堆数据并重写提示词。
下一批输入将根据新版本进行评估。
用户永远不需要考虑提示词。
他们只是继续做出只有人类才能做出的判断。
提示词在底层不断更新。
这正是大多数团队在部署 Claude 系统时所忽略的。
他们把提示词当作一个可以完成的可交付物。
而交付最多的团队则把提示词当作一个始终在学习的一层。
从一开始就按这种方式构建，你就不用再花数周时间调整措辞了。
你把时间花在交付产品上。
关注我并订阅我的 Telegram 频道：
