提示词越写越长，为什么反而不管用了？

1

我第一次觉得一大坨提示词管不住，是在做内容的时候。

大家很喜欢给 AI 加各种去 AI 味的要求嘛，我以前也会这么做。

结果不对，就再补一条。句子太整齐，加一条。语气不像人，再加一条。不要这个词，不要那个句式，开头要怎么写，结尾怎么写，慢慢地就全塞进同一段提示词里了。

一开始，这种操作确实有用。AI 犯了一个很具体的错误，你把错误写进限制里，下一次可能就不犯了。问题是，内容创作里的错误很少只有一个来源。比如说句子太整齐，可能是人物材料太薄，也可能是整篇只有抽象判断，没有具体事情。结尾像总结，还可能是你要求它把文章写完整，也可能是它根本不知道作者最后想停在哪里。

这些问题最后都被写成“禁令”，全部在同一条 Prompt 里。每次有新问题，就继续往后加。久而久之，里面同时放着写作要求、事实要求、平台要求、格式要求、禁词、审查规则和这一次任务的材料。哪些是每篇都要遵守的，哪些只对这次有用，还有一些已经被后来的要求改掉了，慢慢就分不清了。

所以说，约束越来越多以后，它反而不管用了。

2

后来我开始写小说。我原本想先让 AI 写，写完以后自己看一遍，再决定要不要另外做一次去 AI 味。开始写以后，我没有刻意放很多这类约束。我给了人物角色、世界书和背景，也把人物当时的心理状态、行为和反应写清楚。

结果出来以后，发现效果好的不得了，以至于我看了十来分钟。至少在我的判断里，那些文字没有明显的 AI 味。

这次没有靠一串禁令解决问题。人物卡先告诉 AI，这个人怎么理解事情，他跟其他人是什么关系，什么反应符合这个人。世界书确定故事发生的环境，哪些事情已经发生，哪些条件不能随便改。背景材料提供人物过去经历过的事。写到当前这一段，再补上他现在的心理状态、动作和眼前的冲突。

每一份材料只处理自己负责的部分。写某个场景时，AI 不用在一条长 Prompt 里重新辨认人物、背景、语气、心理和行为之间的关系。它读到的内容已经放在对应的位置，知道这一段要调用什么。

这两次经历放在一起，我才发现，继续增加限制，未必能解决内容的问题。有些去 AI 味要求是在修句子，可缺的东西可能在句子出现以前。人物没有写清楚，世界没有写清楚，作者的判断也没有写清楚。到了生成那一步，再加十条禁止使用的句式，只是在成品上继续补洞罢了。

约束仍然有用。不过详细的细节，类别这些都要写清楚。问题出在所有约束都堆在顶层，每次任务都让 AI 从头读一遍，再让它自己判断哪一条最重要。大家也都知道，AI有幻觉，也会漂移的。

3

我现在把 Prompt 分成 3 个级别。

快速原型级的目的很简单，先让它跑起来。这个阶段解决的是能不能做。你有一个想法，先让 AI 给出一版，看这个方向是否成立。临时整理一份材料，先跑出一个结果。一两句话能开始，就不用先写一套完整规范。

原型阶段如果一开始就管目录结构、异常恢复、每个输出字段和十几条验收标准，很可能东西还没有跑起来，人已经把时间花在维护说明上了。很多想法试完就会放弃，这时候先追求完整，做的是后面可能根本用不到的工作。

开发级处理的是能不能稳定地做。任务已经跑通，也确定还会继续使用，就要开始管架构、代码规范、测试、依赖、权限、边界和验收标准。输入错了怎么办，中途失败以后从哪里继续，修改一个部分会不会影响其他部分，输出怎样才算完成，这些问题都要进入 Prompt 或项目说明。

这个阶段的提示词通常会变长，因为它确实要把执行条件写清楚。长没有问题。开发级的麻烦来自缺少边界。任务明明要反复运行，Prompt 里却只有一句目标，没有测试，没有失败处理，AI 每一次都可能按自己的理解重新做。

管理级处理一组已经存在的能力。系统里已经有 CLI、Skill、MCP、脚本、材料和 Agent。CLI 能执行命令，Skill 保存一套工作方法，MCP 连接外部服务，脚本处理重复的机械步骤，材料提供任务需要的背景，Agent 负责一个领域里的工作。

这时继续把所有说明复制进顶层 Prompt，会出现另一个问题。同一套写作规则可能被复制到几条 Prompt 里，规则修改以后，每一处都要跟着改。有一处没有更新，下次执行就会同时读到两个版本。一个工具明明有自己的调用说明，顶层又写了一遍。时间一长，没人知道哪一份才是现在使用的版本。

4

把它暂时想成一家公司，会容易理解一些。

顶层 Prompt 像经理，下面这些东西是不同的执行单元。它们不一定都是人，所以我不直接把它们叫员工。经理不需要亲自掌握每一个执行步骤。它先接收人的目标，判断任务属于哪一种，再找到对应的执行单元。

找到以后还没有结束。经理要确认这个执行单元拿到了需要的材料，知道输出要交到哪里，也知道怎样才算完成。结果回来以后，经理按验收标准检查。通过了，任务才进入下一步。没有通过，就看是材料缺了、执行过程错了，还是一开始就找错了执行单元。

经理不亲自补做执行单元的工作。它负责分配、验收和上报。

经理如果一边分配，一边在结果不对的时候自己动手补，这一次的任务可能完成了，系统却没有留下可重复的处理方法。下一次遇到同样的问题，它还会临时补一次。执行单元哪里有缺口，说明书哪里没有写清楚，也不会被修正。

每个执行单元都要带自己的说明。它适合处理什么任务，应该怎么调用，边界在哪里，失败以后怎么处理，这些都不能缺。

适用条件告诉经理什么时候找它。调用方式告诉经理要给它什么材料，用什么入口启动。边界写清它能做什么，哪些决定要留给别的执行单元或者人类。失败处理说明报错后是否重试，要不要换候补，哪些现场记录必须保留。

说明书写在执行单元旁边，具体能力也留在那里。写作方法留在对应的 Skill 里，服务连接方法留在 MCP 里，重复步骤交给脚本。任务需要背景时，再去读取相关材料。某项能力更新，只改它自己的说明，不用到几条顶层 Prompt 里逐个找旧版本。

管理级 Prompt 因此会越来越短。具体要求没有消失，它们只是离开了顶层。顶层保留目标、路由条件、验收标准和异常处理。至于一篇文章怎样审查，一个服务怎样连接，一段脚本接收什么参数，由对应的执行单元自己说明。

信息也不用一次全部塞给 AI。它可以先看有哪些材料，判断当前任务需要哪一份，再去读正文。写小说时读人物和世界设定。查资料就去找对应材料。执行操作的时候，再调用工具。没有用到的东西，不必每次都跟着 Prompt 进入任务。

系统并没有变简单。复杂度被拆开了。以前一个人维护一大段 Prompt，现在要维护执行单元的职责、说明、材料位置和验收关系。写一条长指令需要表达能力，把这些东西长期放在正确的位置，需要另一种能力。

经理也可能找错执行单元。验收不通过，就要重新分配，不能自己把剩下的工作偷偷补完。两个执行单元的职责重叠，需要提前指定谁主责，另一个负责复核或者在失败时接手。执行过程中报错，就保留失败记录，按说明重试或者切换候补。仍然没有结果，再交给人类判断。

有些任务根本找不到对应的执行单元。这个时候经理要报告缺什么，停在哪一步，已经试过哪些办法。它不能假装自己找到人了，也不能换一个不相关的工具把格式凑出来。报告失败也是管理的一部分，因为人类需要根据这份报告决定，是补一个新的能力，还是这次直接由人处理。

5

快速原型级、开发级和管理级不会互相取代。

我临时试一个想法，还是会用快速原型。要把它做成可以长期运行的东西，就要进入开发级。等系统里已经有很多工具、Skill、脚本和 Agent，任务开始跨过多个执行单元，才需要管理级 Prompt 出来分配和验收。

同一个系统里，3 个级别也可能同时出现。经理收到目标以后，交给一个开发级能力稳定执行。里面遇到一个从来没有试过的步骤，仍然可以先用快速原型跑一遍。原型验证可行，再补测试和边界，最后登记成经理以后可以调用的执行单元。

所以，Prompt 写得短不代表水平更高，写得长也不代表一定有问题。要看它正在处理哪一级的任务。原型没有跑起来，先谈组织没有意义。执行单元连自己的边界和验收标准都没有写清楚，顶层再会调度也找不到合适的能力干活。

以前我写 Prompt，注意力常常放在这一句话够不够准确，还有没有漏掉一条限制。现在我会先看这件事应该放在哪里，哪一部分应该长期保存，谁负责执行，谁来验收，失败以后回到哪里。

以后写 Prompt，最关键的能力是组织能力。