复杂任务最怕的，从来不是模型太笨，而是人和模型都以为“对方已经懂了”。
我最近盯着自己和 Codex 的几轮对话，越看越觉得问题不在模型一边。
很多时候，锅也不在提示词“太短”或者“太弱”。
真正的问题更像是：我拿着一套适合熟人协作的高默契表达，去驱动一条又长、又多层、还要求强收口的复杂任务链。
短任务里，这种说话方式很爽。
一句“是这一份”，一句“没错”，一句“处理前三批”，模型如果上下文还热着，基本能接住。
但只要任务一长，链路一多，规则一重，这种高默契短句就会开始反噬。
你以为自己说得很省力。
模型以为自己听懂了。
最后大家一起朝一个“差不多像对的方向”狂奔，然后在收尾时撞墙。
我先把结论直接摆出来：
我的提示词问题不是弱，而是全局规则过重、任务切换过快、上下文省略过多、完成标准不够显式。
这四条里，最致命的不是哪一条单独存在。
而是它们会叠在一起。
我本来就是典型的交付型用户。
我脑子里经常是分层的：业务目标一层、运维动作一层、页面观察一层、提示词方法论一层、skill 体系又一层。
问题是，我脑子里分层，不等于我嘴上分层。
于是模型看到的，不是一个收过口的任务。
而是一团高速切换、默认省略主语、还夹着强规则背景的指令流。
很多人以为规则越多，执行就越稳。
这话只说对了一半。
规则太少，当然容易乱。
但规则太重，也会出另一个问题：主任务会被元规则吃掉。
我自己的现场就很典型。
AGENTS 很强，全局规则很多，边界也很细。
这本身没错，甚至很多时候是必要的。
但副作用也很明显：
说白了，原本用户是要你“把灯打开”。
结果你先开始检查电路规范、配电历史、工具准入、施工边界、默认回执格式。
这些事不能说不重要。
但如果主任务本身没有被单独锁住，它就会被淹没。
规则是护栏，不是主角。护栏一旦站到路中间，车就别开了。
我后来回看自己的对话，发现一个特别稳定的毛病：
我经常在同一串对话里跳层，但不打招呼。
前一句还在说业务目标。
下一句已经跳去产品判断。
再下一句又进了运维执行。
然后忽然开始讨论 skill 清理、提示词结构、页面观感，甚至写作风格。
如果对面是熟人团队，这种切层未必是灾难。
因为大家知道你平时怎么跳。
但模型不是靠“熟悉你的语气”稳定工作的。
模型吃的是上下文证据。
你不切层，它就只能自己猜：
最麻烦的是，这种误判很多时候不是立刻爆炸。
它会先假装一切正常。
等你最后验收时，才发现它收口收偏了。
我特别爱说这种话：
短上下文里，这样说一点问题都没有。
因为对象就在眼前。
可一旦任务拉长，这些句子就会开始变成埋雷器。
因为它们默认了太多前提。
比如“没错”。
到底是在确认：
再比如“处理这前三批”。
对我自己来说，这句话已经很完整。
但模型未必知道你现在强调的是：
高默契短句适合熟人协作，不适合复杂任务调度。
问题从来不是不能这么说。
问题是你不能指望一条长链任务，全靠这种表达稳定跑完。
这也是我自己的责任。
我平时很喜欢要这几样：
这没毛病。
真问题在后半句我经常没说：
做到什么，才算完成。
没有这条，模型就只能自己猜收口点。
它可能觉得：
而我脑子里的完成，往往是另一个东西：
这中间差的，不是一点礼貌表达。
差的是整个收尾机制。
我现在对这件事的判断很直接：
复杂任务不是怕你说得短，而是怕你既短、又跳、还不收口。
所以更稳的做法，不是每次都写一篇巨长提示词。
而是至少把下面三件事单独钉死：
一句话说，这一轮只做什么。
不是“总体上推进一下”。
不是“你看着处理”。
而是明确：
满足哪 1 到 3 条，才算完成。
这一步非常关键。
因为它直接决定模型什么时候该停，什么时候不能自我宣布“已经差不多好了”。
把路径、域名、文件、截图、约束补进去。
不是为了显得专业。
而是为了减少“这个”“那一份”“还是没看到”这种指代漂移。
很多人一聊提示词，就容易走偏。
仿佛这件事的核心，是研究某种神秘咒语。
我现在越来越不信这一套。
提示词的本质，尤其是复杂执行任务里的提示词，本来就更像：
换句话说，这不是“写作小技巧”。
这是任务管理能力。
你给模型的，不只是语言。
你给的是一套调度结构。
如果结构乱了，再强的模型也会漂。
如果结构稳了，哪怕提示词不花哨，任务也能落得更准。
我这次最大的收获，不是“以后要把提示词写更长”。
恰恰相反。
我终于承认了一件事：
我以前很多看起来很高效的表达，其实是在透支上下文。
短任务里，这种透支还能靠默契补回来。
长任务里，它迟早会崩。
所以真正该优化的，不是拼命堆字。
而是把任务写得更分层、更收口。
这不是变啰嗦。
这是把误解成本提前消掉。
不是我不会写提示词，而是我终于不再迷信“半句也能把复杂任务讲清楚”这件事了。
如果你也经常觉得自己明明说得很清楚，模型却总在最后一公里跑偏，建议你别先骂模型。
先回头看一眼：
你给它的，到底是任务，还是默契幻觉？