# Linghun 更新记录 这里记录对用户体验有直接影响的产品更新。更完整的系统设计见 [中文白皮书](../WHITEPAPER.md)。 ## 2026-06-27 会话存储、模型流式输出与权限模式 Linghun 继续收敛终端主链里三个用户容易直接感知的部分：长会话存储、模型流式输出和权限模式。 这次更新的重点不是增加新功能，而是把已有底座压得更稳：长对话不再把过多会话内容堆在进程内存里；Claude、OpenAI 以及兼容 OpenAI 的 SSE 输出进入更一致的解析和渲染路径；自动审核、完全放行等模式的权限边界更贴近日常开发直觉，减少不必要的打断。 ### 怎么实现 - 收紧会话记录写入和读取路径，让长对话历史更多落到可追溯存储中，降低单进程长期运行时的内存压力。 - 统一模型流式事件的增量解析，减少不同 provider 在换行、代码块、工具输出和最终回答显示上的差异。 - 清理一部分只面向内部状态的终端提示，让缓存、记忆等后台动作继续执行，但不在用户可见层制造额外噪音。 - 调整权限模式策略：默认和计划模式保持审慎，自动审核减少低风险操作的打断，完全放行更符合用户选择该模式时的预期。 - 保留底层权限、证据、会话、索引和验证链路，不把用户可见层的精简变成底层逻辑删除。 ### 用户体验 - 长对话更不容易因为会话历史持续膨胀而变慢或触发内存压力。 - Claude、OpenAI 和兼容 OpenAI 的模型输出在终端里的换行、代码块和长段落显示更稳定。 - 命令 stderr、长段落和工具输出的展示更容易阅读，主屏信息不会只剩零散代码块。 - 自动审核模式更少因为常规读写和开发命令反复打断；完全放行模式更接近“用户明确放行后就让任务跑完”的体验。 - 缓存刷新、记忆更新等后台能力仍然存在，只是减少了对终端用户可见层的干扰。 ## 2026-06-26 预检系统与多语言深度层 Linghun 的预检系统扩展为多语言深度层，覆盖 TypeScript、Python、Rust、Go、Java、SQL、Shell、C#、PHP、Ruby、Kotlin、Dart、Swift、C/C++ 等常见开发语言。 这次更新的核心不是“多加几个检查脚本”，而是把模型开工前最容易浪费时间的部分提前结构化：先知道改动可能影响哪里、哪些文件属于同一条调用链、哪些语言层能先给出确定性错误。模型不用一上来就靠大范围 `Grep` / `Read` 摸索仓库，用户看到的是响应更快收敛、反复翻文件更少、修改后更早发现明显错误。 ### 怎么实现 - 在预检引擎中继续保留 `pre_context`、`pre_impact`、`pre_plan`、`pre_verify` 这些通用能力，用索引、符号、调用关系、影响范围和验证结果给模型提供结构化事实。 - 为各语言增加独立 deep layer：每个语言层负责识别对应文件、调用本地工具链或 fallback 检查，并把结果统一返回到 `pre_verify`。 - 语言工具链不存在时，deep layer 返回 `unavailable` 和明确原因，不伪造通过，也不阻塞主流程。 - 随包二进制和 helper 文件一起发布，用户安装 Linghun CLI 后即可获得预检主链；本机安装了对应语言工具链时，深度检查会自动增强。 ### 用户体验 - 模型开工前能更早知道哪些文件、符号和调用链相关，减少重复 `Grep` / `Read` 和无效探索。 - 改动后能先做快速预检，把语法错误、类型错误、明显调用问题提前暴露给模型。 - 没装某个语言工具链时，Linghun 会清楚说明该语言深度层不可用，而不是把未检查误报为通过。 - 对多语言仓库更友好，常见后端、脚本、移动端、配置和系统语言都能进入同一条预检主链。 - 对真实工程任务，收益主要来自少走弯路：少读无关文件、少重复问工具、少在最后阶段才发现低级错误。具体加速比例取决于仓库大小、语言工具链、任务类型和模型，但在多文件定位、跨语言修改、修复后验证这类场景里，体感会更接近“模型更快进入正题”，而不是长时间在仓库里摸索。 - 对 token 成本，预检和索引是互补关系：索引负责快速给出结构化代码事实，预检负责在变更前后给出更接近工程验证的信号。两者一起使用时，模型更少把上下文花在无效搜索上，更多把 token 用在真正的判断和修改上。 ## 2026-06-17 终端可见层与工具调用链 终端可见层继续收敛，输入区、任务区和换行/光标稳定性已加强；工具调用链新增 SourcePack / ReadSnippets，减少重复 Grep/Read 往返，让相关代码片段更快交付给模型。 这次更新解决的是另一个很真实的卡点：模型并不是每次都缺能力，很多时候是相关代码片段到达得太慢、太散，导致它反复查同一批文件。SourcePack / ReadSnippets 把“找到了什么、哪些片段和当前任务有关”更快聚合起来，用户体感是模型少绕圈，回答和修改更像沿着一条线往前推进。 ### 怎么实现 - 优化终端输入区、任务区、长文本换行和光标显示，减少在 Windows、PowerShell、中文路径和长命令场景下的视觉错位。 - 在工具调用链中加入 SourcePack / ReadSnippets，把相关代码片段按任务聚合后交给模型。 - 让模型在需要代码证据时优先拿到更集中的上下文，而不是在多个工具调用之间反复读取同一批文件。 ### 用户体验 - 长任务和多步骤执行时，终端显示更稳定，输入和输出更容易追踪。 - 模型读取相关代码更快，重复探索更少，用户等待时间和 token 消耗都会下降。 - 对代码审查、定位问题、跨文件修改这类任务，模型更容易围绕相关片段收住结论。 - 对工程化效率，最大的改善在“工具往返次数”上：相关片段更早集中交给模型，模型就不需要多次 Grep、Read、再 Grep、再 Read。小任务会感觉更顺，大任务会减少前半段的探索噪音。 - 对用户心智负担，终端显示稳定后，长命令、长日志、任务状态和光标位置更可预期。用户更容易判断模型现在是在读代码、执行命令、等待结果，还是已经进入验证阶段。