把改散的方案完全归因于上下文太长，通常会漏掉另一半原因：约束在某一轮被你自己改掉了。两者表现相似——后面几轮都在错误的基础上继续细化。判断顺序建议反过来：先把多轮修改记录按轮次摊开，标出最初三条硬约束第一次失效的那一轮，再决定是压缩上下文重述约束，还是回头改目标。如果重述固定约束后输出又回到原来的方向，问题偏向遗忘；如果重述后仍然跑偏，说明目标本身已经变了，需要先确认需求而不是继续调工具。

OJO 方案越改越散，多数不是单一原因。操作上先摊开每轮修改记录，用最初三条硬约束逐轮打勾打叉，找到第一次变成叉的轮次；再从那一轮的需求句里看有没有冒出最初的受众、渠道或风格要求。适用场景是多轮迭代的长方案任务；验证方式是重述约束后重跑同一轮修改点，对比方案骨架是否回到原方向；风险边界是：目标被有意修改时，重新约束只会把新目标压回去，所以要先确认这次改动是不是真的要改。

把多轮修改记录按轮次摊开

只看最后一版方案，看不出跑偏从哪开始，也分不清是模型输出漂移还是自己换了诉求。建议把每次交互整理成一行，字段固定为四个：轮次、本轮新增要求、本轮删掉的要求、方案变化点。第四个字段写方案结构上的变化，比如章节被合并、目标人群被替换、交付形态从清单变成文档，而不是抄一句“优化了表达”。

记录可以在每次改完后手动补一行，也可以从对话历史里回填。下面是可直接用的表格骨架，放进任意表格工具或 Markdown 表格都行：

轮次 | 本轮新增要求 | 本轮删掉的要求 | 方案变化点
-----|--------------|----------------|----------------
R0   | 初始需求 + 三条硬约束 | — | 初始方案骨架
R1   | 增加成本估算 | 无 | 在原有结构上加一节
R2   | 面向另一类读者 | 无 | 开头受众描述被替换
R3   | 更口语 | 删掉了“必须给字段表” | 表格消失，改为段落描述

摊开之后先找两类行：一是“删掉的要求”非空的行，二是“方案变化点”影响骨架而非措辞的行。这两类行通常就是跑偏的入口。记录表的用途是让判断有依据，不要指望它自动分析，靠自己逐行看更可靠。

标出约束第一次消失的那一轮

定位方法很朴素：回到最开始的输入，把当时写死的三条硬约束抄出来，做成一个固定的检查列，逐轮对每一版方案打勾或打叉。打叉的标准要提前约定，建议用“方案里能不能直接找到对应内容”来判断，找不到就是叉，不因为“意思大概有”而放行。

硬约束（R0 固定）
C1 必须给出可执行的字段表
C2 面向一线执行人员，不写给管理层
C3 只保留一种主方案，不给多选

轮次 | C1 | C2 | C3 | 备注
R0   | √  | √  | √  | 基准
R1   | √  | √  | √  | 加成本估算，骨架未变
R2   | √  | ×  | √  | 受众描述换成管理层视角
R3   | ×  | ×  | √  | 表格被删

第一次出现叉的那一轮就是起点，上例是 R2。把这一轮的本轮新增要求和方案变化点对照看，判断它是被挤掉的还是被主动删的。如果同一轮里新增要求和某条硬约束方向冲突，比如新增“面向决策层汇报”，那 R2 的叉很可能是目标变更带来的，不是上下文问题。这一步只做定位，不要急着改提示词。

把关键约束提到每轮输入开头再试一次

定位到轮次后，可以先做一个低成本验证：把三条硬约束固定放在每轮输入的开头，三行写完，再写本轮修改点。这么做的作用是把约束从长上下文中间挪到最近位置，减少被后续内容稀释的可能。

【硬约束，本轮不得违反】
1. 必须输出可执行的字段表，字段含名称、类型、是否必填
2. 读者是一线执行人员，不写管理层汇报口径
3. 只给一种主方案，不列多个备选

【已确认、不再讨论】
- 交付形态：单份文档

【本轮修改点】
- 在字段表后面补一段成本估算的说明
- 其余部分保持不变

对比方式建议控制变量：用同一轮的修改点，一次不带重述、一次带重述，各生成一版，只比较三件事——三条硬约束是否都还在、方案骨架是否与 R0 一致、本轮修改点是否被落实。重述后三条都在且骨架没变，可以把问题记作上下文稀释；重述后仍然缺某条，多半是这条约束和本轮要求本身冲突，需要回到人这边确认取舍。注意重述会占用输入长度，约束多于五条时建议只保留最硬的三条，其余移入快照文件。

区分是上下文变长还是自己改了目标

这一步是为避免把人的目标漂移误判成工具问题。判断线索集中在需求句本身：回看从跑偏轮次开始的新增要求，看有没有出现最初完全没有的受众、渠道或风格要求。比如最初写的是“给执行同事看的内部说明”，后面几轮冒出“给客户看”“要能发公众号”“语气更像宣传稿”，这些不是模型自己加的，是需求被换了。

• 新增要求里出现了新的读者对象：目标已变，先确认是否真的要换受众。
• 新增要求里出现了新的发布渠道或格式：多半是交付形态变更，需要重写硬约束而不是补丁式修改。
• 新增要求只涉及详略、举例、顺序：属于正常细化，跑偏更可能是约束被稀释。
• 自己说不清为什么要加这条：先搁置，回到快照里的未决问题，不要直接塞进下一轮输入。

如果确认目标变了，正确做法是重开一组硬约束并把轮次归零，而不是在旧记录上继续追加。继续追加会让前后约束互相打架，输出看起来更散。

给长任务留一份约束快照

多轮任务超过五六轮后，靠记忆维持约束不现实。建议每轮结束维护一份短快照，四段固定：硬约束、可放弃项、已确认结论、未决问题。硬约束写不能动的；可放弃项写优先级低、被挤压时可以砍的，用来避免模型为了保住所有要求而稀释重点；已确认结论写已经定稿、后续不再讨论的内容；未决问题写还没定的，避免下一轮又被当成新需求提出来。

# 约束快照 v3（每轮结束时更新）

## 硬约束
1. 必须输出字段表（名称/类型/是否必填）
2. 读者：一线执行人员
3. 只给一种主方案

## 可放弃项
- 背景段落可压缩
- 示例数量可减少

## 已确认结论
- 交付形态：单份文档，不做演示稿
- 术语统一用内部现有叫法

## 未决问题
- 是否需要附一份上线检查清单（待确认）

更新方式建议固定为三步：每轮结束先看硬约束有没有被改动，改动就升版本号并写明原因；再把本轮定下来的内容从“未决问题”移到“已确认结论”；最后把下一轮要提的要求先对照硬约束检查一遍，冲突的先解决冲突再发起请求。快照控制在半屏以内，太长就会被忽略；每次发起新一轮时把它原样放在输入开头，和本轮修改点分开写。