长对话锚定与写作规范
超过 10 轮强制复述目标；违禁句式清单让文案摆脱 AI 腔
本页解决的问题
先给结论「长对话锚定与写作规范」要解决的关键问题是什么？
超过 10 轮强制复述目标；违禁句式清单让文案摆脱 AI 腔
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
理解漂移成因
上下文窗口截断和长文本尾部注意力衰减，让 AI 忘掉早期约定。即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在。
会设 checkpoint
超过 10 轮后，关键操作前强制复述当前目标和关键约束，用周期性锚点对抗遗忘。
消灭 AI 腔
用可搜索的违禁模式清单和自查流程，替代「请写自然流畅的中文」这类空话。
下面是一个模拟对话窗口，假设上下文窗口只装得下最近 20 轮。第 1 轮定了「用 PostgreSQL」的硬约束，拖动滑块增加对话轮数，观察这条约定的命运。然后切换到「开启锚定」，看同样 30 轮之后有什么区别。
灰色划线的消息表示已滑出上下文窗口，AI 看不见它们了。本演示假设窗口容量为最近 20 轮。
复述有固定格式
修改代码、修改配置、部署之前，AI 必须先回顾并复述当前目标和关键约束，格式固定，便于扫一眼确认。
目标以最新一次为准
用户在对话中修改了目标时，复述要以最新一次为准，并明确标注变更，避免新旧目标混在一起。
并行编辑前先重读文件
多个 SubAgent 或多次编辑涉及同一文件时，后续修改必须先重新读取文件当前状态，禁止基于缓存或记忆中的旧内容编辑。这是多 Agent 时代的「乐观锁」。
下面这段文案由 AI 生成，读起来处处透着一股 AI 腔。点击「开始检测」，按 writing-style.mdc 的自查表逐条扫描违禁模式；再点击每一处红色高亮，查看它违反了哪条规则、应该怎么改。
其一，「请用自然流畅的中文」没有用。AI 认为的自然和你认为的自然可能完全不同，必须给出具体的违禁词和违禁句式列表，AI 才能精确执行。交付前逐条搜索违禁模式，发现一处改一处，完成后注明已完成自查，System Prompt 里的违禁句式同样要改。
其二，写作规范独立成文件并设 alwaysApply: false，只在写文案或 Prompt 时手动引用，避免污染编码对话的上下文。
锚定对抗遗忘，清单对抗含糊。长对话里靠周期性复述保住约定，写作上靠可搜索的违禁模式保住风格。两者的共同点是把模糊期望变成可执行动作。
素材来源：对应 rule-opensource.mdc 第十三章「沟通规范」与 writing-style.mdc，开源仓库 itshen/xs_vibe_rules（MIT License）。
从「理解漂移成因」把感觉变成判断
「上下文窗口截断和长文本尾部注意力衰减，让 AI 忘掉早期约定。即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「超过 10 轮后，关键操作前强制复述当前目标和关键约束，用周期性锚点对抗遗忘」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「锚定对抗遗忘，清单对抗含糊。」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「理解漂移成因」走到「会设 checkpoint」
「理解漂移成因」先把问题落在「上下文窗口截断和长文本尾部注意力衰减，让 AI 忘掉早期约定。即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在」上；到了「会设 checkpoint」，讨论继续推进到「超过 10 轮后，关键操作前强制复述当前目标和关键约束，用周期性锚点对抗遗忘」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「理解漂移成因」：上下文窗口截断和长文本尾部注意力衰减，让 AI 忘掉早期约定。即使是 200K token 的模型，注意力在长文本尾部的衰减也真实存在
- 「会设 checkpoint」：超过 10 轮后，关键操作前强制复述当前目标和关键约束，用周期性锚点对抗遗忘
- 「最后的要点」：灰色划线的消息表示已滑出上下文窗口，AI 看不见它们了。本演示假设窗口容量为最近 20 轮
最后的「最后的要点」把讨论落到「灰色划线的消息表示已滑出上下文窗口，AI 看不见它们了。本演示假设窗口容量为最近 20 轮」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。