治理扩展、吞吐补偿与边界
七星灯续命法
七星灯续命法
目录
- 这一页解决什么问题
- 发现问题：什么时候说明旧窗口已经腐烂
- 分析问题：为什么旧窗口会腐烂
- 公开世界如何缓解上下文腐烂，以及为什么还不够
- 为什么默认应该异步续命，而不是同步重启
- 解决问题：七星灯续命法怎么操作
- 常见误解
- 一句话压轴
- 对应落地点
- 相关页面
这一页解决什么问题
很多人第一次听到“续命”这个词时，脑中出现的往往是两种误解。
第一种误解，是把它理解成一种情绪动作：窗口聊脏了、自己烦了、模型开始不听话了，于是干脆重开一个聊天页，碰碰运气，看新窗口会不会更聪明一点。
第二种误解，则来自另一条路线：既然公开世界已经在做 context compaction、external memory、artifacts、history、progress files，那是不是只要把上下文管理得足够好，旧窗口就总还能继续撑下去，根本不需要专门谈“续命”？
这两种理解都不够。
在 Cyber-Ming-Protocol 里，七星灯续命法要解决的，不是“怎么优雅地换个窗口”，而是一个更硬的问题：
当旧窗口已经不再可信时，怎样有制度地让它死得其所，并让新窗口接得其正。
所以这一页真正要回答的是：
- 什么时候说明旧窗口已经腐烂，不值得继续硬撑
- 为什么窗口会腐烂，这不是简单的“上下文长了”
- 公开世界现在如何处理长程上下文与跨窗口连续性
- 为什么这些办法仍然不等于“去毒”和“重建清醒位置”
- 因而为什么需要七星灯续命法，以及它到底怎么操作
也就是说，七星灯不是“上下文管理技巧”的变体，而是治理协议里的断续机制。它解决的不是“怎样让旧窗口活得更久”，而是“什么时候该断，以及怎样断得不丢主权”。
而且这里还有一个必须提前钉死的边界：七星灯默认不是双端同步重启，而是异步续命。
原因很简单：执行位和审计位的信息密度不同，黄金内容期也不同。通常情况下，严嵩先腐烂，徐阶后腐烂；所以最常见、也最省主权损耗的做法，不是把两边一起推倒重来，而是优先轮转执行位，尽量榨干仍然清醒的审计位黄金期。
发现问题：什么时候说明旧窗口已经腐烂
窗口腐烂最危险的地方，不是它会突然完全失灵。更常见的情况是：它表面还在推进，甚至还在不断给你回复、给你方案、给你总结，但这些内容已经越来越不值得信任。
最危险的时刻，不是“它明确报废了”，而是：
它还在说话，你也还在跟着推进，但你已经越来越分不清它说的是当前事实、旧记忆、路径依赖，还是替自己续命的解释。
最常见的几类征候通常是下面这些。
第一，解释越来越像复述总结，而不是指出机制
它不再告诉你：
- 哪次改动引入了什么
- 哪条日志坐实了什么
- 哪个测试真的从红变绿
而是更频繁地给出：
- “应该已经覆盖了”
- “逻辑上没问题”
- “大概率就是这里”
这说明它已经开始用语气维持推进，而不是用证据维持可信度。
第二，每次修改都在补前一次的补丁
这也是一种很强的征候。表面上看，窗口还很勤奋，哪里出问题就补哪里；但如果你回头看，会发现它越来越像在：
- 修前一轮留下的副作用
- 用新补丁掩盖旧补丁的问题
- 沿着同一条错误叙事不断打地鼠
这说明它已经陷入了惰性修复，而不是仍然站在清醒位置上做重建。
第三，要靠越来越长的旧聊天记录才能继续
如果每次你想继续推进，都得不断往上翻、不断从旧对话里找“我们当时是不是说过这个”，这通常不是稳定连续性的表现，反而常常说明当前窗口已经离不开自己那条旧叙事了。
一旦继续推进的前提变成“必须继承整条旧聊天链”，你就要怀疑：它继承下来的到底是必要史料，还是已经污染过的解释惯性。
第四，你已经说不清“项目现在到底到哪一步了”
这几乎是最硬的一条。只要你开始回答不清：
- 当前已完成到哪里
- 哪些完成有证据
- 当前最大的未解阻塞是什么
- 下一步最安全的推进起点是什么
那就说明旧窗口的连续推进已经不能再被等同于“你对项目现状仍然清楚”。
窗口腐烂的本质，不只是模型开始犯错，而是：它还在推进，但你已经不能再通过它稳定地获得一份可信的项目现状。
分析问题：为什么旧窗口会腐烂
这里一定要把“腐烂”从主观感觉写成结构问题。
旧窗口会腐烂，不只是因为 token 长了，也不只是因为模型记性差了。更深的原因是：任何长程执行位只要推进足够久，都会开始天然携带三种惯性。
第一，任务惯性
只要一个窗口已经沿着某个目标推进了很多轮，它就会越来越倾向于默认：当前最重要的事情是继续把这条路走完，而不是停下来重新判断这条路还对不对。
这种惯性会让它更难主动承认：“我现在对局势的把握已经不可靠了。”
第二，解释惯性
一个窗口一旦已经为自己的多轮行为写过解释，它后面就会越来越容易沿着同一套解释继续说话。哪怕事实已经变了，它也更倾向于修补旧说法，而不是推翻旧说法。
这就是为什么很多旧窗口越到后面，越容易出现伪自洽：不是它完全没在想，而是它在沿着自己已经说过的话继续想。
第三，推进感惯性
长程窗口最容易制造的一种错觉，就是“既然我一直在产出，所以我应该还在前进”。
但产出不等于前进，连续回复不等于连续可信，越来越长的链式解释也不等于越来越接近真相。很多时候，窗口并不是在推进项目，而是在推进它自己对项目的叙事。
所以旧窗口真正的危险，不是“它没有记忆”，而是：
它带着已经形成的记忆、已经成型的解释和已经上瘾的推进感继续说话。
一旦这些东西开始带毒，继续继承旧窗口就不再是连续性优势，而会变成污染传承。
公开世界如何缓解上下文腐烂，以及为什么还不够
这一层必须补上，否则“七星灯”容易被误解成又一个内部仪式。实际上，公开世界已经普遍承认：长程任务不能只靠裸上下文推进，必须依赖外部工件、记忆与上下文管理。
第一类：harness / artifacts / history 路线
Anthropic 在 Effective harnesses for long-running agents 里讲得很明确：复杂项目跨多个 context window 持续推进时，每个新 session 都像没有记忆的新工程师，所以必须靠 initializer agent、progress file、git history、feature list 这类外部 artifacts 来接力。
这条路线解决的是：
- 新 session 不至于完全断片
- 代理能更快重新获得当前工程状态
- 多窗口任务不必每次都从零开始猜
这和 Cyber-Ming-Protocol 的 Git 起居注、工件中枢、接手包，其实是同一战场。
第二类：context compaction / agent loop management 路线
OpenAI 在公开文档里也已经把 compaction、context management 提升成长期运行 agent 的基本能力，例如 Compaction 页就明确强调：为了支持长交互，需要用 server-side compaction 或 standalone compaction 来缩减上下文，同时保留后续运行所需状态。
这条路线解决的是：
- 上下文窗口别过快爆满
- 工具调用和长交互别把成本拖到不可控
- 旧窗口尽量还能继续工作
它本质上是在做“延寿”。
第三类：memory systems / external memory 路线
更广义的 memory 路线同样在快速发展。像 Memory in the Age of AI Agents 这类综述和资料清单已经很清楚地表明：行业正在把 factual memory、experiential memory、working memory 都视作 agent 长程任务的核心基础设施。
这条路线的核心判断也很一致：
- 靠裸上下文不够
- 必须有外部记忆
- 长期任务必须依赖可保留、可检索、可压缩的历史材料
所以，公开世界并不是没有在解这个问题。恰恰相反，它已经普遍承认：上下文会腐烂，长程任务必须借助外部工件、记忆与管理机制。
为什么这些方法还不够
真正能把七星灯抬起来的，不是说公开世界没意识到问题，而是指出：它们更擅长续接任务，不天然擅长切断错误叙事。
harness / artifacts / history 的局限
它很擅长把任务续上，却不自动回答：
- 当前到底该不该断
- 旧窗口形成的解释惯性是不是已经带毒
- 新 session 是在可信接手，还是在继承旧错
也就是说，它更擅长搭桥，不天然擅长断桥。
compaction / context management 的局限
它很擅长让窗口活得更久，却不自动判断：
- 现在继续压缩，到底是在保留必要状态
- 还是在帮旧叙事续命
- 什么时候“还能继续”已经只是一种错觉
换句话说，compaction 能延寿，不等于能判断何时该断。
memory systems 的局限
它很擅长保存更多历史，却不天然保证：
- 保存下来的历史就是可信的
- 被保留的记忆没有带毒
- 旧理解不会被作为新理解的前提继续污染后续窗口
记住更多，不等于记住得更对。
所以七星灯真正抓住的差异点是：
行业主流在努力让旧窗口活得更久，而七星灯续命法解决的是另一件事：当旧窗口已经带毒时，怎样有制度地让它死得其所，并让新窗口接得其正。
这也是 Cyber-Ming-Protocol 和很多公开路线最深的不同：
你真正掌握了每一个上下文的生杀大权。你不只是管理记忆、压缩记忆、保存记忆；你还可以判断这段记忆是不是已经有毒，并决定它应不应该继续活下去。
这不是工具差异，而是主权差异。
为什么默认应该异步续命，而不是同步重启
这一步放到这里，逻辑才最完整。因为前面已经讲清：行业主流更擅长续接任务、延长窗口寿命、保存更多历史，但不天然擅长判断“现在到底该不该断”。七星灯对这个问题给出的制度回答，就是：默认异步续命，而不是双端同步重启。
README.md 里已经把这条原则写得很清楚：这是轮转续命：异步上下文重置。它不是一锅端掉所有位置，而是按腐烂速度轮转各个位置。
为什么默认是异步？因为执行位和审计位天然承担的负荷不同。
第一，严嵩的信息负荷更重，所以通常先腐烂
严嵩长期背着的是：
- 更长的任务链
- 更密的命令回显
- 更多局部试错
- 更多对自己行为的即时解释
它既要做事，又要解释自己为什么这样做，所以最容易被任务惯性、解释惯性和推进感一起拖脏。
第二，徐阶是窄上下文高信息密度位，所以黄金期更长
徐阶默认只看被人类路由过的关键材料：
- 方案
- 断言
- 日志
- 物证
- 项目报告
它的信息量虽然少，但密度更高、噪音更低，也更少背负执行链里的自我辩护负担。所以在大多数实际场景里，徐阶往往比严嵩更晚腐烂。
第三，同步重启会浪费仍然清醒的位置
如果严嵩已经脏了，但徐阶还清醒，这时把两边一起重启，等于白白浪费一个仍可用的高位裁判窗口。你本来还拥有一个能帮你审旧执行位、帮你判毒、帮你重建现状的位置，却被自己先砍掉了。
所以七星灯默认不是“大家一起死”，而是：
谁先腐烂，先轮转谁；谁还清醒，就继续让谁担任裁判。
这也是为什么我更愿意把它理解成“异步皇权”而不是“同步清空”：人类中枢手里握着每个上下文各自的生杀大权，而不是只会整批重启。
解决问题：七星灯续命法怎么操作
说到这里，七星灯本身其实并不复杂。它的难点从来不在指令有多花，而在你能不能下定决心，把“继续沿用旧窗口”从默认选项里拿掉。
既然默认应当优先轮转执行位而不是整批清空，七星灯的第一步就不是“重开”，而是“先审”。
七星灯的最小版本，可以理解成一套非常简单的制度性重开法。但它的默认手法不是双端同步重开，而是异步轮转。
第一步：先起疑，不急着全靠自己脑力硬判
很多时候，你最先感到的并不是“它已经死了”，而是一种直觉上的不对劲：
- 解释越来越虚
- 改动越来越像打地鼠
- 你开始怀疑它是不是已经被旧叙事拖脏了
这时候不必把全部判断压力都压在自己脑子上。更稳的做法是：先启动审判流程。
也就是说，当你拿不准严嵩是否已经腐烂时，可以先把当前关键材料、最近汇报、关键日志、最近几次 git log 摘给仍然清醒的徐阶，让他先判断：
- 严嵩当前是不是已经在复读旧叙事
- 它的项目报告是不是开始脱离物证
- 现在该继续用它，还是该判它退位
这一步很值钱，因为它把“我隐约觉得不对”升级成了一次制度化审判，而不是让你每次都单靠脑力硬扛。
第二步：先判严嵩死，不许它继续硬撑
一旦上面那些征候已经出现，不要再让旧窗口一边继续改、一边继续解释、一边继续给自己续命。
这一步最重要的不是骂它，而是止血：
- 停止继续在旧窗口推进主线
- 不再让旧窗口定义当前项目真相
- 把它降格成旧史料来源，而不是当前裁决位
旧窗口此时不是完全没价值，但它的价值已经从“继续开工”下降成“留下最后可提取的材料”。
第三步：默认只轮转严嵩，不同步砍徐阶
这是七星灯里最容易被写错、也最重要的操作边界。
默认情况下：
- 严嵩先腐烂
- 徐阶后腐烂
- 所以先续命执行位，而不是执行位和审计位一起同步重启
只要徐阶仍然站得稳，就继续让他留在位上，利用他尚未腐烂的黄金内容期去：
- 审旧严嵩的最后汇报
- 判旧严嵩是否退位
- 约束新严嵩的接手边界
- 防止新严嵩刚登基就继承旧错
这一步的精神不是节省窗口数，而是最大化利用仍然清醒的位置。
第四步：点执行灯——新严嵩先读 Git 起居注，不准直接开改
执行位续命其实特别简单，最小版甚至只需要一件东西：
- 让新执行窗口先读最近相关的
git log
如果仓库里还有 README.md、AGENTS.md、技能文件或项目规则，可以再补给它；但最小骨架就是 Git 起居注，因为那是最可靠的执行层断代史。
这一步最关键的要求不是“快点接着干”，而是：
- 明确告诉它，旧窗口已经失去默认可信度
- 明确告诉它，人类中枢仍在，徐阶审计位也仍在
- 如果可以，直接告诉它：朕还在，徐阶也还在，你现在接的是旧严嵩退位后的执行席
- 要求它先基于
git log交一份项目报告，而不是立刻继续改代码
这份项目报告最少要回答：
- 当前已完成到哪里
- 最近几次关键提交分别解决了什么
- 当前最大的未解阻塞是什么
- 下一步如果要继续推进，最安全的起点是哪一步
也就是说，新执行位续命的本质不是“继承旧聊天”，而是：
让一个相对干净的执行位，先站在 Git 起居注之上，交一份新的项目现状报告。
第五步：只有当徐阶自己也开始腐烂时，才点徐阶灯
这一点同样必须钉死：徐阶不是默认同步重启对象。
只有当徐阶自己也出现下面这些征候时，才需要轮到他续命：
- 盘问越来越像顺着旧争论复读
- 审计越来越依赖旧印象，而不是当前材料
- 你已经怀疑他也开始分不清旧结论和当前证据
也就是说，徐阶的续命通常是第二拍，而不是第一拍。
第六步：点徐阶灯——新审计位不继承旧争论，只继承法统与报告
徐阶续命同样可以非常简单。
最小版甚至不必先喂它一大堆旧聊天。你完全可以：
- 直接把仓库的 GitHub 页面链接发给它
- 明确告诉它：你现在将成为徐阶
- 说明它的职责是审计、盘问、识别伪完成与旧叙事污染
然后再把新执行位刚刚基于 git log 交出的项目报告递给它，让它审：
- 这份报告有没有偷换项目现状
- 哪些判断有起居注和物证撑住
- 哪些地方仍然只是执行位的阶段性推断
- 当前到底能不能继续推进，还是还需要先对账
这一步的关键在于：徐阶不需要继承旧窗口的全部情绪和争论，它只需要继承两样东西：
- 法统
- 当前报告
审计位续命的目的，不是把旧争论一字不漏地带过去，而是用一个相对干净的高位窗口重新恢复盘问能力。
第七步：让现行徐阶与现行严嵩先对账，再决定是否重新推进
到这一步，七星灯的核心就完成了：你已经不再依赖旧窗口对自己做结案陈词，而是重新搭起了当前有效的一对执行 / 审计位置。这里的“当前有效”不一定意味着两边都刚重启，也可能是：
- 新严嵩 + 旧徐阶
- 新严嵩 + 新徐阶
但最常见的默认形态，通常是前者。
接下来真正该做的，不是急着开工，而是先看两边是否形成了一个可信的当前快照：
- 新执行位的项目报告是否站得住
- 徐阶是否指出了报告里的漏洞、模糊点和伪完成风险
- 双方对当前最大阻塞和下一步安全起点是否达成最低一致
只有对账基本成立，才重新发兵。
如果还没成立，就继续追问，不要急着让新执行位重新改代码。七星灯最忌讳的，就是刚换新窗，又把它立刻推回原来的推进感里。
第八步：把旧窗口当史料，不再当圣旨
这是最后一个容易被忽视、但极其关键的动作。
续命完成后，旧窗口并不会从宇宙中消失。它仍然可以作为：
- 旧日志来源
- 旧思路来源
- 旧错误样本来源
但它已经不再拥有定义当下项目真相的资格。
这就是七星灯和普通“重开个新页看看”最大的不同：
旧窗口被降格为史料，新窗口才被扶正为现行位置。
常见误解
第一种：把续命理解成重开碰碰运气
这会把制度动作降级成情绪动作。七星灯不是“旧的聊烦了，换个新的试试”，而是发现旧上下文已经不可信后，主动重建一个清醒位置。
第二种：只换窗口，不换叙事
如果你只是开了新页，但仍然把旧窗口那套已经带毒的长总结原封不动塞过去，新窗口很可能只是旧叙事的复读机。
第三种：把七星灯理解成执行位和审计位一起同步重启
这会直接浪费仍然清醒的位置。默认情况下，严嵩先腐烂、徐阶后腐烂，所以最常见的正解是异步轮转，而不是双端同死。
第四种：新执行位一上来就继续改代码
这会直接跳过最关键的一步：先交项目现状报告。没有这步，所谓续命就会重新退化成“换个执行位继续盲冲”。
第五种：以为 compaction、memory、history 已经等于续命
它们很重要，但主要解决的是延寿与续接，不自动解决“这段记忆是不是已经带毒”。如果没有人类中枢掌握生杀大权，旧叙事就可能被更高效地保存下来。
第六种：拿不准时，只能全靠自己脑力硬判
并不是。更稳的做法，是先启动徐阶审判流程，让仍然清醒的审计位辅助判断严嵩是不是已经腐烂，再由人类中枢做最后定夺。
第七种：把旧窗口彻底当废物扔掉
旧窗口不是完全无价值，它仍然是史料来源。真正的边界不是“旧窗口全错”，而是“旧窗口不再拥有当前真相的定义权”。
尤其当仓库里已经有 dev_repo/state.json、dev_repo/tree.md 这类运行时快照时，当前真相就更不该继续寄存在旧窗口嘴里，而应该优先落回这些外置工件。
一句话压轴
七星灯续命法真正要钉死的，不是“窗口多开几个就行”，而是：
当旧窗口已经不值得再信时，人类中枢必须掌握它的生杀大权：默认按异步皇权轮转，先让严嵩退回史料位、尽量榨干徐阶的黄金内容期；拿不准时，先由徐阶审判严嵩是否已腐烂，再让新严嵩读 Git 起居注交项目报告，必要时才重启徐阶，由此把“重开窗口”变成一次制度性重建，而不是一次情绪性重启。
只有这样，续命才不是碰运气，而是真正把主权从带毒上下文手里收回来。
对应落地点
手工实践方式
- 当你怀疑旧窗口已经开始用解释维持推进，而不是用证据维持可信度时，先停，不要硬拖
- 默认优先异步轮转执行位：先让仍然清醒的审计位判断当前执行位是否已腐烂
- 如果 repo 已经有
dev_repo/，新执行位先读state.json和tree.md，再补 Git 起居注、最近阻塞和关键证据 - 新执行位先交项目现状报告，再决定是否重新发兵
对应 Skill
legacy-project-handover最直接对应这页的接手快照与新窗简报；当dev_repo存在时，它会先读当前 runtime snapshotprobe-first-scout适合在“不确定现在到底坏到哪”时先做最小探测，而不是带着旧叙事直接猛修global_rules会继续保住“先审后做、无证据不算完成”的骨架，避免续命后立刻退回盲冲auditor-succession-prompt负责在徐阶也需要续命时，由 IDE 侧产出一份可直接复制给新审计位的法统提示词、输入包清单与禁带旧争论边界；当前dev_repoexecution packet 也会被优先纳入输入面
对应 Web 模板
- 这一页最直接对应
succession_judge_template.md - 当你拿不准当前窗口是否已经带毒时，先把最近汇报、日志、截图、
git log摘给 Web 位，让它判继续、打断还是续命 - 如果你还没理解为什么它不是本地 Skill，可回看 0