那次审查跨应用派发时，我先看到的是一种很熟悉、也很容易被忽略的异常：一个本来只需要完成具体工作的任务，开头却多出了一大段内部说明。它不是任务本身，也不是执行这个任务所必需的背景，而是一组关于内部协作、执行纪律和系统边界的要求。
更奇怪的是，这段说明不只出现在父任务里，两个子任务也收到了同样的内容。乍看之下，很容易把问题归咎于执行方：是不是它自作主张加了提示？是不是它把别的上下文带进来了？我沿着派发链路回看，才发现答案并不在执行方，而在一个看似方便的默认开关里。
那一刻我意识到，任务正文和内部纪律其实是两种不同的东西。它们都可能有价值，但不应该因为都写在提示词里，就默认被送给同一个执行对象。外部任务需要的是清楚的工作正文，内部规则需要的是有边界的显式注入。
一段多出来的说明，为什么值得认真查
当时父任务准备让另一个应用完成一项本地工作，并进一步自派两个子任务。结果在记录中，父任务、子任务 A 和子任务 B 的提示词开头都出现了同一段内部前置说明。子任务的命令本身没有显式打开相关开关，却仍然被加上了这段内容。
单看一次，可能有人会说：“多给一点背景，总比信息不足安全。”但这正是问题的入口。背景只有在和当前任务相关时才是帮助；与目标无关的内部规则，进入外部工作正文后，就会变成一种噪声。它会抢占执行者的注意力，让对方先理解一套不属于当前工作的纪律，再去判断真正要做什么。
如果不处理，后果不只是提示词变长。执行方可能误以为自己正在处理内部系统任务，进而把内部限制当成外部任务的业务要求；也可能因为规则之间的层级不清，优先执行了不相关的说明。更隐蔽的风险是，团队会习惯于把“能跑通”当成“派得对”，直到某次任务因为混入了不必要的上下文而做出错误判断。
这件事让我重新意识到，提示词不是越满越稳。它首先是一份给执行者的工作边界，边界画错了，增加内容只会增加误读的机会。
真正的问题不在执行方
最容易误判的地方，是把提示词污染看成执行方擅自发挥。因为我们看到的现象确实像是“它收到了不该收到的话”，于是自然会去检查执行记录、重试任务，甚至考虑给执行方再加一层提醒。
但这次的证据链很清楚：父任务与子任务出现了相同的内部说明，子任务命令里没有显式传入相关开关，而派发器的默认值曾经是开启。也就是说，执行方只是按收到的内容工作，真正改变任务边界的是派发器在发送前自动做的拼接。
我没有先修改执行方的行为，是因为那样只能处理表象。只要派发器仍然默认注入，同样的污染还会出现在下一个任务、下一个子任务，以及任何没有意识到这个开关存在的人身上。排查提示词问题时，第一步不是问谁加了这句话，而是问它在哪个层级被自动加入。
为了确认判断，我没有只看当前代码。真实派发台账保存了每次发送时的提示词开头，可以把父子链路串起来，也能验证同一段内容究竟在哪些任务中出现。当前代码回答“现在怎么写”，历史台账回答“刚才实际发了什么”；两者缺一不可。
把正文、标题和内部 brief 分成三层
后来我把这类提示词拆成了3层来看。第一层是外部工作正文，说明任务要完成什么、输入是什么、交付结果是什么。第二层是标题或主题元数据，它帮助执行方识别任务，却不应该携带一整套内部管理要求。第三层才是内部 brief，只有当执行方确实需要遵守内部仓库、系统或协作纪律时，才应该把它显式加入。
这3层的区别，不是为了让设计看起来更工整，而是为了回答一个实际问题：哪些信息会改变当前任务的做法，哪些信息只是发送方自己的工作习惯？如果一条规则不会影响外部任务的判断，就没有理由默认跟着正文一起过去。
错误捷径是把所有内部规则塞进每一个任务，认为信息越多越安全。这个做法在短期内很省事，因为派发器只需要一个固定模板；但它把筛选成本转嫁给了执行方，也让外部任务承担了不必要的认知负担。更糟的是，内部规则一旦被误当成业务要求，后续的人很难分辨到底哪里是真约束，哪里只是协作方的工作习惯。
我选择把内部 brief 的默认值改为关闭，是因为默认行为应该保护最常见、最容易被误派的外部工作负载。内部任务并没有因此失去能力；需要内部协作时，可以由发送者显式打开。这样的设计把判断放回了真正知道任务性质的人手里。
默认关闭，不等于永远不能注入
“默认关闭”很容易被理解成完全不要内部说明，其实不是。真正的原则是：默认值负责防止无意暴露，显式开关负责表达真实需要。两者配合，才能同时保留效率和边界。
如果当前任务只是让外部执行方完成一个独立结果，那么只保留标题和正文就够了。执行者不需要知道发送方怎样管理内部项目，也不需要被要求遵守与它无关的跨任务纪律。反过来，如果任务确实要读内部材料、修改内部系统，或者必须服从特定协作流程，那么发送者应该明确开启 brief，并承担这个选择带来的责任。
这里的责任感很重要。一个开关如果默认开启，使用者往往不会再判断它是否适用；一个开关如果默认关闭，使用者每次开启都需要说明理由。最小暴露不是把信息藏起来，而是让每一次额外注入都成为一个可解释的决定。
这也解释了为什么默认值属于产品设计，而不只是代码细节。默认值会被大量调用，决定大多数人不做额外思考时系统会采取什么行为。一个错误的默认值，可能比一次明显的操作失误更危险，因为它会安静地重复很多次。
用发送前后两次检查守住边界
这次修复后，我没有只看配置是否从开启变成关闭，而是继续做了父任务自派子任务的真实验证。发送前，记录提示词开头，确认外部任务只保留标题和正文；发送后，再从台账回读父子链路，检查子任务是否同样保持干净。这样才能确认修改影响的是实际发送，而不只是某个局部变量。
这套方法可以概括成一个很小的流程。先把正文、标题元数据和内部 brief 分层；再把默认值设为关闭；发送前记录提示词头部，方便追溯；发送后回读父子链路，确认没有隐式注入；最后用一次真实自派发做端到端验证。每一步都不复杂，但它们共同回答了“系统准备发送什么”和“执行方实际收到什么”这两个不同问题。
失败或边缘情况也要留下位置。比如，父任务本身是内部任务，显式打开 brief 后，子任务是否也应该继承，不能靠猜。它应该成为派发策略中的明确选择，并在台账里留下可追溯记录。又比如，标题为了触发自动命名而进入正文时，仍要检查它是不是只提供主题信息，而没有顺手把内部规则带进去。
一个流程成熟的标志，不是它能偶然派出一次干净任务，而是下一次遇到相同场景时，不需要靠某个人记得“这次要关掉开关”。默认值、记录和实测应该把这个判断固化下来。
下次我会怎么做
下次再审查跨应用派发，我会先问3个问题：当前发送的是外部工作还是内部协作？提示词中的每一层信息分别服务于什么目标？有没有任何内容是因为默认值而被自动加入的？这3个问题能帮助我在看执行结果之前，先确认任务边界有没有被改写。
如果发现父子任务都出现相同的额外说明，我会优先检查派发器的默认路径，再用真实台账核对实际发送内容。只有把“代码怎么配置”和“链路实际收到什么”对上，才能判断根因。修复时，我会优先选择默认关闭、内部需要时显式开启，并保留发送前后的最小记录。
这件事让我重新意识到，真正可靠的协作不是让每个执行者知道一切，而是让它刚好知道完成当前工作所需的内容。表面上我是在清理一段提示词，实际上是在重新划分内部纪律和外部正文的边界。让外部任务保持干净，既是降低噪声的技巧，也是保护任务自主性的基本规则。
我更愿意把它看成一种工作习惯，而不是一个技巧：先分层，再设默认值；先记录，再发送；先回读，再相信。这样做的结果，不只是这一次父任务和子任务恢复正常，而是以后每一次派发，都更少依赖临场记忆，也更少把内部世界无意中带到外部工作里。