外观
Emacs 社区日报 2026-09-09
自动整理自 Telegram 讨论组，每天更新。内容为 AI 摘要，仅作信息索引与回顾。
Emacs 中文讨论组
🎯 核心热点与专题探讨
专题：Chrome 抢占 Emacs 快捷键 C-g，引发 macOS 用户集体吐槽
群里讨论最激烈的话题之一，是 Chrome 新版本在 macOS 上默认将 C-g（Emacs 用户最常用的取消/打断快捷键）绑定为唤起内置 Gemini 对话框。多位群友表示“烦死了”、“马上把这个快捷键去掉了”，甚至有人直接“杀掉 gemini”。但难点在于这是 Chrome 内置功能，不是独立 App，无法简单卸载；而且 Chrome 每次更新都会自动加回来，需要手动改设置或等待插件方案。这一事件也侧面反映出：工具厂商默认抢走用户熟悉的编辑器快捷键，对 Emacs 用户尤其冒犯。
专题：emacs-mac 停更与 macOS 下输入法切换的替代方案
有群友提到 emacs-mac 分支已停止开发，并质疑为何相关 patch 无法 merge 到 upstream。随后有人分享了一个关键补丁：ns-mac-input-source.patch（https://github.com/LuciusChen/.emacs.d/blob/main/scripts/macos/patches/emacs-32/ns-mac-input-source.patch），用于在 Emacs 内切换 macOS 输入法。不过实际使用反馈两极：有人表示“早用上了”且“没遇到过问题”，也有人指出动态模块实现的同功能存在缺陷——频繁切换后会卡顿、跳回 ABC 输入法，疑似 API 使用不当。最终有群友确认该 patch 就是 emacs-plus 的输入法切换补丁，且动态模块方案可完全替代。
专题：eglot-code-actions 失灵与配置冲突排查
一位群友在调试 eglot-code-actions 选中后无反应的问题，另一位建议用 edebug 逐步跟踪执行过程。最终定位到原因：因为别的问题配置了某个链接（emacs_china/339495），从而导致了这个 bug——属于典型的配置间相互干扰问题。虽然问题找到，但该群友仅表示“找到了但是……”，并未给出最终修复方案，讨论在此中断。
🔑 关键概念与技术解析
- edebug：Emacs 内置的 Lisp 调试器，可逐步执行代码并观察变量状态。群内推荐用于排查 eglot-code-actions 这类“静默失败”问题。
- emacs-mac / emacs-plus：两个常见的 macOS 原生 Emacs 发行版。emacs-mac 曾提供一些独占特性（如输入法切换），现已停更；emacs-plus 为社区维护的 Homebrew 构建方案，可通过 patch 加入类似功能。
- 动态模块（Dynamic Module）：Emacs 支持在运行时加载 C 编写的动态库。这里用来替代 emacs-mac 的输入法切换 patch，但实际使用中出现了“卡顿、跳回 ABC”等稳定性问题。
- pi-undo-tree：一个把 undo 历史可视化为树形结构的库（GitHub: ergenekonyigit/pi-undo-tree），可用于浏览和回溯历史编辑状态。
- GPU Lexer（gpu-lexer）：一个仅 27.4 KB 的语法高亮模型，可直接在浏览器里运行，用于代码高亮。
- 带语法高亮功能的字体（Monaspace Krypton 修改版）：有人通过 OpenType 上下文替代功能，将 HTML/CSS/JS 的语法高亮逻辑直接内嵌到字体中——在字体层面实现高亮，无需编辑器支持。
💎 碎片知识与金句拾遗
- “又干掉一个！蘇記 已被封禁。”——群内 spam 清理记录。
- 关于 Chrome 抢 C-g：“内置在 chrome 里的，怎么杀？chrome 一更新又有了”——更新即复现的痛点。
- 关于 emacs-mac：“我知道的就一个切换输入法的方法”，该补丁现在“动态模块早可以做了吧”。
- “一模一样的有什么不好用的？动态模块写出来的，频繁切换之后，会卡顿，会跳回 abc。”——即使是相同功能，实现方式不同也会带来体验差异。
- 关于 AI 修复代码：“magit unstage stage 折叠我这很容易复现，但昨天 ai 抽奖中大保底了一次性修好了，而且只用了 sol xhigh”——即“高难度模式（xhigh）”下 AI 反而可能一次性解决，且“感觉略微变聪明了？或者 codex 更新发力了”。
- κόσμος 分享 pi-undo-tree 时说：“看起来还挺好玩的”，并追问 “codex 是不是没有回溯或者在历史上 branch 的功能”——暗示用类似树形结构做 AI 编辑历史管理。
- 群友吐槽 GPU Lexer：“llmspeak 看着好累”“非常累，头都大了”——对 AI 生成文本的排版/高亮体验不佳。
- 关于语法高亮字体：“卧龙凤雏”“很有意思，直接为语法高亮定制了字体……利用 OpenType 上下文替代功能，根据 HTML、CSS 和 JS 语法来查找并替换特定的文本字符串。”——有人追问 “怎么适应不同的语言？毕竟不同语言有不同的语法”，暂无答案。
- 有人问 “这个可以在 Emacs plus 里面用吗？”——得到的回答是 “就是 emacs-plus 的 patch”，说明该补丁正是 emacs-plus 的一部分。
🛠️ 值得深入研究的点 (Follow-up)
- pi-undo-tree 与 AI 编辑历史：群友提到 codex 没有“回溯/分支”功能，而 pi-undo-tree 恰好把 undo 历史可视化为树。若能将这种树形结构引入 AI 编辑会话，或许能让 AI 的编辑过程更可控、可回溯。
- gpu-lexer 轻量级高亮模型：27.4KB 的浏览器端语法高亮模型，可在低功耗设备/在线代码编辑器上做即时高亮。值得关注其训练数据和模型设计。
- 语法高亮字体（Monaspace Krypton 修改版）：一种将高亮规则直接编译进字体的“离经叛道”思路。虽然跨语言支持存疑，但作为一种“零编辑器依赖”的渲染方案，值得持续观察。
- ns-mac-input-source.patch 的动态模块替代：群内已有成功案例，但存在“频繁切换卡顿”的坑。若能找到正确的 API 用法，可彻底告别 emacs-mac 停更带来的依赖问题。
观点延伸
今天最值得连起来看的，是 Chrome 抢占 C-g，以及群友对 AI 编辑历史树的兴趣。两件事指向同一个判断：工具是否可靠，不只看它能替你做什么，还看你能否叫停它、撤销它，并确认自己回到了哪里。 前者是控制入口，后者是状态管理。
1. 取消键不是闲置的流量入口
据群友反馈，Chrome 把 C-g 设为 Gemini 入口，且有人遇到更新后设置重新出现。这里不能据此断言所有版本都会重置，但它暴露了一个产品设计问题：厂商眼中的“快捷入口”，可能是用户早已形成肌肉记忆的退出通道。
对 Emacs 用户而言，取消操作尤其不能要求临场思考。把“停下来”变成“再打开一个东西”，破坏的不是偏好，而是出错时的恢复路径。
由此延伸，AI 功能的验收不该只有“能否唤起”，还应包括：关闭选择能否跨升级保留，快捷键冲突是否可发现，中断后是否仍有后台动作继续执行。入口做得再顺，退出不可信，就不适合承担重要工作。
2. 历史树要保存工程状态，不只是聊天分支
群友分享 pi-undo-tree，随后追问能否给 Agent 工具加入回溯和分支。这个方向比“聊天记录画成树”更值得做，但难点也正在这里：回到某条消息，不等于回到那一刻的代码。
一次 Agent 操作可能同时改变文件、暂存区和运行中的进程。只恢复对话，工作区却停留在未来，下一轮推理就会建立在错位的状态上。工程上应先定义节点保存什么：代码基线、补丁、未提交修改、测试结果，以及无法自动撤销的副作用。外部操作不能假装被一次撤销全部抹去。
因此，历史树的核心验收不是“分叉好不好看”，而是从同一节点走两条修复路线，能否隔离修改、比较结果，再可靠地选回其中一条。
3. “一次修好”应该变成可重复证据
当天有人报告 AI 一次解决了 Magit 折叠问题。这是有价值的成功反馈，却还不足以证明模型整体变强。真正能留下来的资产，是触发条件、修复差异和回归检查；否则下次出问题，仍然只能抽奖。
可继续研究／实践
拿这个容易复现的 Magit 问题做一个最小实验：保留故障基线，建立两条独立修复分支，用相同操作序列复测，再演练切回原始状态。记录复现是否消失、是否引入新问题、恢复是否完整。先证明“改错了也回得去”，再讨论让 Agent 自主走多远。
Emacs 轻聊讨论组
🎯 核心热点与专题探讨
专题一：omarchy 发行版——营销产物还是 Linux 大众化的旗手？
本日群内讨论最激烈的话题无疑是 DHH 推出的 omarchy 发行版，观点两极分化严重，甚至演变成了一场关于“什么是发行版”的哲学争论。
质疑方观点：
- “搞了一套 dotfile 硬说自己是发行版”，“完完全全的拿来主义，然后让 AI 改改配置就成发行版了”
- “omarchy 的 theme 也不是自己的”“他目前给我的感觉就是搞了一套 dotfile 硬说自己是发行版”
- “其实 linux 的各种 wayland wm 我都用过，omarchy 没做什么基础建设”
- “炒作了一堆 ai slop stuff”“营销能力点满了”
- 类比 emacs 装几个 package 就自称 fork 是“neoemacs”一样荒谬
支持/中立方观点：
- “一切都有发展顺序的吧，你觉得以后它不会么”——承认当前不足但看好未来
- “它又不是只做了 wm”——肯定整体工作
- “用户界面的处理非常麻烦，有大量的细节很困扰。我为客户做的产品界面，前前后后重构了三四次”——为 omarchy 的 UI 工作辩护
- “你要用过 linux wayland 的各种 wm，你就知道其实 omarchy 没做什么基础建设”——承认现状但暗示方向
- “我相信它是真的有可能流行到大众层面的”——看好 DHH 的旗手作用
- “omarchy 会在 nix 上再套一层”“毕竟是面向普通用户为主，老跟着 arch 天天滚动，不对路”——认为转向 Nix 是正确决策
共识点：
- 双方都承认 omarchy 的“营销水平”确实无人能及
- 都认可“搞技术到最后还是搞人”这一现实
- 对 omarchy 转向 Nix 的决定，多数人认为“是对的”
最终，讨论以“你要用过 linux wayland 的各种 wm，你就知道其实 Omarchy 没做什么基础建设，完完全全的拿来主义，然后让 AI 改改配置，就成一个发行版了”和“我就是省了配置 linux 的麻烦，各方面操作和审美符合标准，不用大改”的务实态度收尾。
专题二：AI 工作流方法论——从 spec-agents 到上下文管理
群内多位成员分享了 AI 开发工作流的实践心得，形成了一套值得记录的“反 spec 流派”方法论。
核心观点：
- “我已经正式放弃 spec-agents 或者说 spec 这一流派的开发方式——已经进入历史博物馆了”
- “这种开发方式反而令太多内容进入上下文，导致上下文污染严重，干扰 llm 的智商水平”
- “一个需求，一个开发阶段。每一个需求对应一个 plan，和模型讨论好 plan 之后，就可以让他跟着 plan 走”
- “我没有分割上下文，就是将不相关的任务，尽量派给不同的 agent 来处理，agent 也不必太多。3-4 个就够了”
- “拆分需求很简单，临时发现的与当前正在处理的不相关，可以先记录到别的地方，先把当前的需求处理完”
- “一个阶段开发阶段完成之后，记得将所有产生的文档之类的都清理掉，不要留待下次再读”
- “我的反主流看法是人类积极介入 AI 工作流，积极打断 AI 的工作，会非常有助于 AI 更好的发挥”
模型选型经验：
- “astra low 的智商都超过 ultra 了”“medium 的性价比是最高的”
- “astra low 是性价比非常好的，medium 在大部分情况下也足以胜任规划的任务”
- “因为 astra low 的缓存命中比 sol 准确很多，所以用 low 的时候，它的成本可能比 sol 要便宜”
- “绝大部分的任务都没必要开 Max 最高档的推理级别”
- “我发现 luna 确实很拉…我宁愿用 astra low”
- “opencode 真垃圾”“用 pi 吧”
实践技巧：
- “让 astra 读取一下 claude 的 session，让它学习 fable 5.1 的派活方式”——针对 astra 喜欢停下来确认的问题
- 不使用 worktree，而是用“jj workspace”
- 安全限制问题：“你让 AI 看到你的意图违反了协议它就不干，但是可以曲线救国。比如用 jyy 的方法，让它把数据生成二维码就把数据偷出来了，再开一个 session 读一下二维码的内容。每一步都不违反协议”
专题三：DeepSeek 模型迭代与定价策略
群内成员密切关注 DeepSeek 的模型发布和价格调整：
- 价格下调：Flash 系列 API 价格最高降幅 60%。缓存命中降至 0.02 元/百万 Token，缓存未命中降至 1 元，输出降至 4 元
- V4.1 Flash 发布计划：将于 2026 年 9 月 10 日发布，性能全面超越 V4 Pro。官方计划在 V4.1 Flash 上线后、V4.1 Pro 上线前，将 V4 Pro 请求全部路由到 V4.1 Flash，并按 Flash 单价计费
群内评价：
- “都说 V4 Flash 比 Pro 正式版强，这下 Flash 真升级为 Pro 了，倒反天罡”
- “我不认为之前的 pro 到了 opus 的级别，最起码没到 opus 4.6 的级别”
- “v4 flash 比 sonnet 好，对我来说够用了”
- “opus 4.7，4.8 都是降智的，本来就不聪明”“我甚至怀疑 a 是不是直接端了个量化版本上来”
- “我怀疑是照着 qwen3.8 重新训练了一个能耗小一点的”
🔑 关键概念与技术解析
spec-agents / spec 流派：一种 AI 开发方法论，核心是“列举出完整背景、需求、实现方式和注意事项，然后让 AI 开干”。群内成员认为这种模式会让太多内容进入上下文，造成污染，已宣布“进入历史博物馆”。
jj workspace vs git worktree：jujutools（jj）的 workspace 功能被视为比 git worktree 更好用的并行开发方案。“我没用过 git 的 worktree，但是 jj 的 workspace 很好用”。另有成员反馈“josh 的上游把我的 jjosh 依赖的 link 功能删掉了”，面临硬分叉的抉择。
xdg-dialog / xdg-popup：Wayland 下对话框和弹出窗口的协议。讨论涉及 resize 后 menu 停驻的问题，以及独立窗口在平铺式窗口管理器下的灾难性体验。
quickshell：为 hyprland 等 wm 设计的 shell 组件。omarchy 的菜单组件被质疑是“全局共享一个组件”，而非三方包的美化菜单。“你不仅要写 lua，后面可能还要 hack quickshell”。
text-input-unstable-v3：Wayland 下的输入法协议。微信通过设置 QT_IM_MODULE=text-input-unstable-v3 实现 Wayland 支持。
UD-IQ2_M：一种量化格式（IMatrix 量化），用于本地模型推理。“DGX 当前服务指标：生成速度约 17.74 token/s，模型：DeepSeek V4 Flash 0731 · UD-IQ2_M”。
💎 碎片知识与金句拾遗
- “成功在 omarchy 装上 emacs，管它什么系统，emacs 才是 os！”——对 Emacs 的终极信仰
- “法不在多，有食则灵。食不在精，碳水就行。斯是陋食，唯得吾心。”——改编自《陋室铭》的“食物铭”
- “安全限制的问题就是不能和 AI 说的太直白……让它把数据生成二维码就把数据偷出来了，再开一个 session 读一下二维码的内容。emmm，我每一步都不违反协议”——AI 安全绕过的实操案例
- “读书人会偷就不算偷，笑死”——对 AI 曲线救国的总结
- “国家反诈 AI 被国内开发者破解，开源项目上线 5 小时后被封号”——“谁敢白嫖国家反诈😁”“在老虎头上捉虱乸”
- “微信用的是 QT 吧，qt 要商用直接签协议就好”——腾讯对 QT 的深度使用
- “腾讯怎么突然识相了”——对微信支持 Wayland 的惊讶
- “微信支持 wayland 了，我 ssh 更新了版本和配置”——及时跟进新特性
- “我用 Linux 和 emacs 的原则就是 我要的留下 不要的滚”——个人软件哲学
- “我是想都用 qt 的程序，然後統一上 blender 那套，icon 用 tango”——UI 统一思路
- “软件美不美还是要看软件开发者，obs 的 ui 我就觉得不丑”——对 UI 的美学判断
- “libreoffice 就丑得一逼，有点像是抄了半截 office 但是没抄全”——犀利评价
- “ubuntu 不如 fedora”“debian 很香”“ubuntu 很复杂”——发行版体验对比
- “niri + noctalia 是当前体验最好的组合”——桌面环境推荐
- “hyprland 实际上不太适合笔记本用户，比较适合大屏多显示器用户”
- “我觉得这种发行版就像是 spacemacs，小白觉得友好，但是装上以后从要学习一套东西变成了两套”——对 omarchy 式发行版的精辟类比
- “vim 的 buffer 刷新做的非常厉害啊”“vim > emacs > edit”——终端刷新性能对比
- “国内这样，关心没啥用”“最近国内不是再抵制非双休企业么？我觉得也不会有什么结果”——对国内社会议题的悲观预期
- “我电脑不休眠不关机”——某人以不关机状态揶揄公司责任
- “狗哥的话犹在耳边”——群内流传的经典语录引用
- “梁圣又有一批卡到了”“重新评级为梁圣”——对 DeepSeek 的戏称
- “数学圈子又有大瓜 堪比演艺圈”——学术圈八卦
- “学术圈为啥对 credit 看这么重 不能全人类共同 credit 吗”“程序员感觉就无所谓 你抄我我抄你”——学术 vs 工程文化对比
- “你怎么装了这个。。。”——对安装某软件的反应
- “松下 Let's Note 与 Linux 兼容性主要在音频和触摸板”“音频，主要是内置扬声器在 Linux 下无法发声”“触摸板，主要是不支持沿着圆形边缘滑动来滚动页面”——硬件兼容性细节
- “vibe 个驱动玩玩”——用 AI 生成驱动的调侃
- “我有 fcitx-config 可以设置”“你得看看它的说明手册”“loadkeys”——键盘布局问题的排查过程
- “omarchy 肯定有方便改的配置吧”——对 omarchy 易用性的信任
- “我是 tty 下终于正常能按”“可以了”——键盘布局问题的解决
- “嗯嗯，忙去吧，一切顺利”——对家人健康问题的关怀
- “我找家乡的先生算了下，我们的新租的房子不能住”“搬过去就这么多事情”——民俗信仰与生活压力的交织
- “钱真是很重要啊😮💨自己过的贫苦点没事儿 上老下小的 正是用钱的时候”——生活的现实
- “我儿子至今还发热呢”“我发热是昨晚才退下去”——家庭健康问题
- “我奶奶那边我还糊弄着呢”“88 了，不敢让她知道”——对高龄老人的保护
- “我一开始免疫力下降有点发玫瑰糠疹”“结果又复阳，玫瑰糠疹好了，直接发了一大片的荨麻疹”——免疫力下降的连锁反应
- “玫瑰糠疹是自限的，只会得一次”——医学知识
- “头晕”“嗓子不舒服是标配了”——新冠症状分享
- “我不发热，我是嗓子不舒服，有强烈的晕船感，但凡走动晕眩感就加剧”——新冠症状分享
- “家里有人阳了你就认命吧”——家庭防护的现实
- “我老婆有症状啥也不测 最后都快好了 测了试纸 然后家里其他人也不防护 然后全部嚯嚯了”——对家人不配合的无奈
- “我当时真的基本是最后一个感染的”“我家里人感染，因为我每天戴口罩，加隔层根本不在一个空间生活”“没事，但是我同事硬是给我送走了”——防护 vs 社交的矛盾
- “我老爸阳了起劲的很，把家里两个老的一起霍霍了”——对家人防护意识的吐槽
- “我前段时间阳完好了”“几天一个症状，持续了一个星期左右”——新冠后遗症分享
- “你还可以记录一下，那个时间和某口服液完全不用身份证就可以买，那个时间用必须身份证买的药品列表”——对疫情政策的观察
- “我一开始免疫力下降有点发玫瑰糠疹”“结果又复阳，玫瑰糠疹好了，直接发了一大片的荨麻疹”——免疫力下降的连锁反应
- “开始我不觉得他能搞起来，我觉得当时 v4 的生态放弃后，社区开发者应该不会再给他开发插件了”——对 noctalia v5 的质疑
- “结果 v5 搞得挺像样，内存占用少了，证明作者技术力是有的，社区开发者还是挺买账的，插件生态马上就赶回 v4 水平了”——对 noctalia v5 的肯定
- “我当时看他给上游 quickshell 没做贡献，还一直说 quickshell 导致内存占用的问题，我还以为他技术力不行，自己搞一套肯定搞不成”——对 noctalia 作者的重新评价
- “其实 omarchy 发展很久了，不是这两天才出来的”——对 omarchy 历史的澄清
- “之前一直是以作者 dotfile 的形式存在吧”“我记得以前就有 iso 吧”——omarchy 的发展史
- “当时还是说的最适合开发者的发行版”——omarchy 早期定位
- “需要发力的我觉得还是设计标准以及实现范例”——对 Linux 桌面的建议
- “有些人是真的有技术无审美”——对技术圈现状的观察
- “我觉得 ai 时代，真的是轮到 linux 当版本之子了，可惜啊，Linux 的桌面到现在还是乱七八糟”——对 Linux 桌面的惋惜
- “Wayland 这么多年了，居然还没替代 x11”——对 Wayland 推进缓慢的感叹
- “wechat 支持 wayland 好事儿”“wemeet 在 wayland 也可以用了”——对腾讯支持 Wayland 的肯定
- “找设计其实可以逛 unixporn”“大部分都是壁纸流”——对 unixporn 的观察
- “我还是觉得 md 设计很好”“gnome 的 adwaita 也不错”——设计偏好
- “得想办法把桌面环境，各种协议统一了”——对 Linux 桌面的期待
- “已经确定是 wayland 了，但是 wayland 也是个老东西了，就这么个老东西，有好多协议还没确定”——对 Wayland 现状的无奈
- “期待 linux 软件上有工业美感不太现实，但是可以从逻辑美感的角度看”——对 Linux 软件的审美观
- “UI 加点圆角和暗色配色就能看了”——对 UI 的简化审美
- “美不美，看外部评价。这东西...美这东西既主观又客观”——对美的哲学讨论
- “blender 的那个好看”——对 blender UI 的肯定
- “gnome 自家的所有软件其实都是很自洽的”“设计也不错，大伙都有 gtk 的话也能统一设计”——对 GNOME 生态的认可
- “我是现在用的 niri，然后全局 adwaita 主题”——个人桌面配置分享
- “如果不用 gnome，他的 ui 就很突兀”——对 GNOME UI 的观察
- “我倒是想看看有没有人能直接通过缝 dotfiles，就能达到 omarchy 同样的水平”——对 omarchy 的挑战
- “营销水平应该没人达到，但是 dotfiles 比 omarchy 审美水平高的，逛逛 unixporn 应该也能找到”——对 omarchy 的承认与比较
- “我已經對折騰這些沒有太大興趣了”——对
观点延伸
今天关于 omarchy 和 AI 工作流的争论，其实指向同一个判断：工具可以替你省掉操作，但不能把故障藏到你无法接管的地方。 评价整合型桌面和 Agent，不能只看第一次启动有多惊艳，还要看第一次出错时，人是否仍有控制权。
1. 整合的价值，不在“缝了多少”，而在“替用户承担多少”
群里一边批评 omarchy 缺少基础建设，一边认可它省配置、统一字体与主题。这两点可以同时成立：原创贡献与整合价值是两本账，不能互相抵消。
更有判断力的证据，是当天的键盘故障：部分按键无法正常使用，而修改配置又要进入依赖这些按键操作的编辑器，最后转到 tty 才恢复操作。单次经历不足以判定整个系统，但它暴露了一个值得测试的问题：修复入口是否依赖正在失效的组件？
这也是 Emacs 配置框架该回答的问题。默认配置再漂亮，如果报错后必须同时理解上游行为和封装逻辑，省下的入门成本就可能变成排障成本。真正成熟的整合，应提供绕过定制层、恢复默认值、保留个人修改的路径，而不只是替用户选好颜色。
2. 该淘汰的不是 spec，而是没有有效期的上下文
“放弃 spec”是当天最锋利的表态，但发言者仍然主张：一个需求对应一个 plan，讨论清楚再执行。这并不是不要规格，而是在拒绝把所有背景、旧方案和临时发现同时塞进当前任务。
据此更合理的延伸是：上下文需要生命周期，不需要宗教战争。 当前目标、不可破坏的约束、验收条件应保持可见；过期计划退出活跃上下文；已验证的结论、接口约定和失败教训则应沉淀下来。把阶段文档一删了之，可能减少干扰，也可能让下一轮重新踩坑。
个人知识系统同理：归档不是遗忘，检索也不是全量重读。需要清理的是过期内容的指挥权，不是历史证据本身。
3. 人的介入，要发生在返工扩大之前
群里提出“积极打断 AI”，值得支持，但不是越频繁越好。有效介入是在目标漂移、改动越界、验证失败时纠偏；无新证据地不断换方向，只会制造另一种上下文污染。好的 Agent 应让人看见当前假设、改动范围和验证结果，而不是逼人盯着输出猜它有没有跑偏。
可继续研究／实践
做一次“接管测试”：桌面在可恢复环境中模拟配置故障，记录恢复耗时与所需知识；Agent 用相近任务比较全量文档和按需上下文，记录验收通过率、返工次数及人工耗时。别争谁更先进，先验证：它究竟消除了复杂性，还是把复杂性推迟到了出错那天。