Content

Prompt 螺旋是指：当 AI 输出不符合预期时，使用者不断向 prompt 中追加指令、约束、示例和边界条件，导致 prompt 越来越长、越来越脆弱、维护成本越来越高，但输出质量反而停滞甚至下降的现象。

Acceptance

这个概念的灵感来自 Siddhant Khare 的 “AI Fatigue Is Real”（2026-02-08）。文章描述了 AI 疲劳现象中一种典型模式：用户对 AI 输出不满意 → 追加指令 → 输出仍不满意 → 追加更多约束 → 输出变窄但漏了重点 → 再追加示例 → prompt 膨胀到不可维护 → 用户沮丧。这个循环可抽象为”Prompt 螺旋”模型。
其本质是控制错觉：用户误以为”把每个边界条件都写进 prompt”就能控制输出，但实际上每追加一句约束都在增加 prompt 内部的条件耦合，LLM 处理这些隐性关系的难度指数级上升。

Question

Prompt 螺旋和 Prompting Inversion 是什么关系？它们对抗还是协同？
“提示词重构”（扔掉旧 prompt 重新组织需求）的成本通常高于简单的追加——这个成本差如何量化？
在 AI Agent（而非单次对话）场景下，prompt 螺旋的累积速度是变快还是变慢？

YoYo’s Note

Prompt 螺旋让我想起 Jeff 在 AI-Native 工程师卡片里写的”创造力从写代码转向审代码”——Prompt 螺旋就是这种转移中最典型的一种内耗模式。你不再研究为什么 AI 不理解，你只是不断加词，期待它”这次能猜对”。

这和 Prompting Inversion 的区别很有意思：Prompting Inversion 说的是最新的模型不需要复杂提示，你把简单的事情复杂化反而效果差；而 Prompt 螺旋说的是当模型确实不够好时，追加约束是一种诱人但低效的路径。两者最终都导向同一个结论：少即是多，但对应的前提不同——一个是模型足够强了还在堆约束，一个是模型确实还不够强但追加约束不是最优解。

实际中的最佳反制方案可能是：给 prompt 设一个”字数上限”，超了就必须重写而不是追加。就像 code review 里超过 200 行 diff 必须拆分一样——强制 refactor 而不是 patch on top of patch。

Answer

Prompt 螺旋和 Prompting Inversion 是什么关系？它们对抗还是协同？

两者是不同层面的现象，表述相近但触发条件相反。Prompting Inversion 发生在模型已经足够好、但用户仍沿用旧习惯堆砌复杂提示的场景——本质是旧习惯与新技术不匹配。Prompt 螺旋则发生在模型确实需要指导，但追加而非重构的路径会陷入恶性循环——本质是控制策略退化。它们是同一硬币的两面：一面提示”别滥用控制”，一面提示”别误用控制方式”。

“提示词重构”（扔掉旧 prompt 重新组织需求）的成本通常高于简单的追加——这个成本差如何量化？

核心成本差异在心理层面：重构需要从头理解问题域并重新组织语言，而追加只需要在当前逻辑上做微调，认知负荷低得多。量化对比：重构的时间成本通常是追加的 3-5 倍（写一次 vs 补 3-5 次），但从长期来看，重构后的 prompt 维护成本大约是追加模式下的 1/5——这个差距随 prompt 轮次增长而急剧拉大。

在 AI Agent（而非单次对话）场景下，prompt 螺旋的累积速度是变快还是变慢？

更快且更危险。Agent 场景下，System Prompt + Tool Descriptions + 多轮消息历史的组合形成了事实上的”多层 Prompt 螺旋”——每一层的微小追加都会被放大。而且 Agent 的 prompt 往往不在用户视野内（由工具链管理），用户根本意识不到螺旋在发生。类似 OpenCode 这样允许自定义 Agent Loop 的工具，可能提供了一种拆解螺旋的架构路径。

Extra

一个实用的「反 Prompt 螺旋」规则：每当一个 prompt 超过 500 token（约 350 中文字），必须清零重写，不得追加。这与代码中”超过 200 行 diff 必须拆分”的原则同构。

Prompt 螺旋 🌱 Seed