前言

本文是写给做基于LLM的应用开发团队的。我不否认很多吸睛的prompt很有传播性，这也是我想要学习的能力。但本文是写给正在做开发的人，以及给他们配置资源的老板们和创业公司CXO们。

本来我也没想专门撰文来写自己在这方面的观点，因为这在我来看很显然。但今天我却看到一帮在做开发和跟开发者关系密切的人对于 17岁高中生写了个神级Prompt，直接把Claude强化成了满血o1。这篇文章有着过度的关注，甚至有人觉得应该招这样的Prompt Engineer。这样我觉得应该发声来说一点不同的声音了，要不然很多在这方面没主见的人就要被媒体对异常信息的放大效应所误导。

LLM应用开发者们遇到的问题已经够多了，能让他们不在这上面踩坑就别踩了。

1、分析 Thinking-Claude

本文的反面案例就是这个Thinking-Claude，首先解释一下什么我觉得它在实际应用开发中很差，以及我不建议招写出这样prompt的人。

1.1、效果的改进来源

首先我承认，这个prompt大概比很多人自己写的prompt的效果感觉好一些。虽然我自己懒得测它的效果，但我相信大家对此趋之若鹜不至于有太离谱的偏差。

这个prompt为什么效果好，来源于：

• 作者是让LLM根据meta-prompt来生成和润色的，不是自己拍脑袋写。

• 用的模型是Claude 3.5 Sonnet，目前最强通用模型。

• 有足够的耐心来调优，据说调了80多版。

说实话，感觉他的效果好的人，如果也能用这样的方式，或者说只用前两步+10次调优，大概率在自己的任务上比他这个效果还好。

这就好像说你拿一个屎一样的prompt给了足够强的模型也能出一个不错的结果，Thinking-Claude原始的meta-prompt思路在我看起来也屎，但不妨碍出来的效果就是比大部分人拍脑袋没调过的人的效果好。这不是这个原作者强，或者说最终prompt好，而是用的工具好。大家用同样的工具方法论能有更好的效果。

这个方式也不是作者首创的，Anthropic官方的prompt指导视频中就提了这个方式。文字稿脱水稿参见 Anthropic官方 深入探讨prompt工程 | 全文脱水中文版

真的想学习好的prompt思路的人应该去看Anthropic的这个指导。不过其中的思路更多是为顶级LLM准备的，差模型上可能未必有用。

1.2、Thinking-Claude的问题是什么

很多推崇这个prompt的人并没有看过其中的内容，原版在：

https://github.com/richards199999/Thinking-Claude/blob/main/model_instructions.md

很长，而且是英文版，由于避免在本文引用太多外部内容，我这里就不贴中文版全文了。

这个prompt直接读来最大的问题是：

【1】不少内容描述的非常模糊，即使是对于人来说也很难准确理解和进行操作。例如他开头部分的一句：

Claude's thoughts should flow naturally between elements, ideas, and knowledge.
Claude的思绪应该在各个元素、想法和知识之间自然流动。

到底这是不是一个合适prompt我相信在公众中有争议，但Anthropic官方在前面的视频中强调，prompt的一大要求是清晰、表达是否准确、完整是好的prompter的首要要求。在这个标准下，这句话堪称负面典范。

用我的话说，好的prompt，应该是说给另一个不熟悉你的人后，他在没有任何后续对话和交流的情况下就能完全按照你的原始意思进行执行。而对这句话的理解大概一千个人会有一千个执行方式。

【2】主体部分全部都是一些大而空洞的描述。很难迭代，看起来也没有做过多少消融实验。例如其中的一段是：

# Strategic Meta-CognitionClaude should maintain awareness of:1. Overall solution strategy2. Progress toward goals 3. Effectiveness of current approach4. Need for strategy adjustment5. Balance between depth and breadth
# 战略元认知Claude应该保持对以下事情的警觉： 1. 总体解决方案策略 2. 目标进展 3. 当前方法的有效性 4. 需要调整策略 5. 深度与广度的平衡

这其实就已经体现出了大家在prompt写不好的时候，LLM给出的那种大而空的框架性描述。

当然我相信这段prompt可能会有一些作用，虽然很难确定到底有多大用。但假设LLM应用的开发者接手了一个这样的prompt，如何对其进行改进来优化一些它没能解决的badcase呢？应该说是非常头大，这堪称最糟糕的屎山。面对普通的屎山还可以归咎于其代码量太大，而这整个prompt的文本量不算大，但可维护性极低。

【3】LLM任务分解困难

LLM应用的效果优化中，大部非技术的人都知道“把一个不够好的环节进行拆分”是一种有效的渐进优化方式。

但这个整个prompt几乎无法做很有效的workflow分解，想优化？还是丢掉它重新来做设计吧。实际上我今天有交流的认为这个prompt还行的PM就是这么打算的。

【总结】

其主要问题在于极其差的可维护性，以及接近于黑盒状态的不可解释和监控性。这对于现阶段LLM应用的软件工程是很要命的。

当然从成品来说，如果它能满足你现在的需求，拿过来用没问题。前提是你并不承担得到它的成本，而且你有选择不用它的权力。但如果你的Prompt Engineer下属花费了1个月给你交付了这么一个东西呢？我肯定不会给他打什么好绩效的。

但说回来，原作者自己弄出这个prompt的成本就低么？其实也不低，迭代了80多版，如果是现在已经在实际应用中调过prompt的人，用他的方式去重新做，效果大概会更好。这也不是一个适合做demo的途径。

2、端正对于Prompt Engineer的预期

正如我年初写的 为什么我不建议去指望找一个AI产品经理【2024Q2】中提到的一样：我们不要指望找到一个全能的AI产品经理，来解决我们自己尚未思考清楚的问题，因为这种人很难找到。

现在我们也不要指望去找到一个天才的Prompt Engineer来解决我们自己所有没想清楚的问题，因为这也很难找到。

对于团队来说，需要的是一个合格的Prompt Engineer，能够稳定交付、能够比较好的发挥模型能力。我们找不到、也招不起一个真正天才的Prompt Engineer，这不现实。

我目前看到的很多对Thinking-Claude感兴趣的人虽然在AI公司中，但其实大多都是并不调prompt的人，是他们自己都还不是一个合格的Prompt Engineer。

Prompt并不是一个很难得事情，但需要时间投入，而且没有什么之前的经验可以参考。现在一线写Prompt的人很多思维既不敏捷，学历也未必多光鲜，“但手熟尔”，而他们写的不错，他们也是在这短暂的时间内成长起来的。合格的Prompt Engineer需要的是持续投入，不是光鲜的学历、丰富的各领域知识、很懂飘渺玄幻的思维方式、计算机科班的背景，都不是。

世上很多事情没有那么快的捷径，虽然LLM已经是捷径了。想提升写prompt的能力，还是去看一些正经的内容吧，信不过别人，总信得过Anthropic官方吧。说那些建议的人决定着Claude模型的post-training调教方向，难道你想跟他对着干？

尾记

在我写这篇吐槽文之前，我正在构思下一个项目的实现方案，可能会在单次用户请求之内调用1000次以上的LLM。可能很多人认为这是天方夜谭，而我刚做完的一个方案就在单次用户请求之内调用100-300次Claude 3.5 Sonnet。我在一年多前就提出了这种可能性，而至今仍有很多人觉得这种方案不可能，这点我也无能为力。