Linghun

本地优先、证据优先的 AI 编程终端

把大模型接到真实项目、真实工具、真实权限、真实验证和真实上下文里。

English README · 中文白皮书 · English Whitepaper · 更新记录 · App Bridge

npm install -g @linghun/cli
linghun

Linghun 可以理解成：给大模型装上一套工程化外骨骼。模型负责理解、推理和生成；Linghun 负责把模型接到真实项目、真实工具、真实权限、真实验证和真实上下文里。

普通聊天工具可以回答“应该怎么改”。Linghun 更关心另一件事：它有没有真的读过相关代码、有没有真的改对文件、有没有真的跑过验证、有没有把不确定的地方说清楚。

这就是 Linghun 反幻觉系统的价值：不是让模型少说错话那么简单，而是把“读事实、看证据、区分验证范围、拒绝空口完成、说明不确定性”变成运行时约束。模型仍然会推理和生成，但关键工程结论不能只靠模型自信。

Novita x Harbor 榜单记录

Linghun 已完成 Novita x Harbor Agent Benchmark 四个公开 TB2.1 榜单的运行与提交：

特别感谢

更新记录

• 2026-06-27：会话存储、模型流式输出和权限模式继续收敛，降低长对话内存压力，让 Claude / OpenAI 兼容流式输出更稳定，并让自动审核、完全放行等模式的命令与改文件体验更清晰。详见：更新记录。
• 2026-06-26：预检系统扩展为多语言深度层，让模型开工前更快拿到索引、影响范围和语言级预检结果，减少无效读文件、重复探索和返工。详见：更新记录。
• 2026-06-17：终端可见层继续收敛，SourcePack / ReadSnippets 把相关代码片段更快交给模型，用户体感是更少等待、更少重复 Grep/Read、更快进入有效修改。详见：更新记录。

它能帮你做什么

Linghun 面向真实开发，而不是只做演示式问答。你可以直接用自然语言让它：

• 阅读项目结构，定位代码问题；
• 修改文件、生成补丁、解释改动；
• 运行构建、测试、脚本和验证命令；
• 检查 Git 状态，创建稳定点，辅助回滚和交接；
• 用代码索引减少重复读文件；
• 用证据、验证和最终回答闸门约束模型漂移；
• 用反幻觉系统减少“没读代码就下结论”“没验证就说完成”；
• 把失败经验、项目规则和历史上下文变成下一轮少返工的辅助信号；
• 感知用户困惑、焦虑、信任受损、急迫或探索状态，并转成更合适的工程路线；
• 区分局部验证、mock 验证、真实 smoke 和未验证结论；
• 控制长日志、工具列表和上下文噪音，减少无效 token 消耗；
• 把长任务拆成可观察的步骤、后台任务或多智能体探索；
• 根据不同角色切换不同模型，例如规划、执行、审查、总结；
• 记住经过确认的项目规则、失败经验和常用工作方式；
• 在 Windows、PowerShell、中文路径、带空格路径等真实环境里工作；
• 通过 MCP、Skills、Plugins、Hooks、Capability Connectors 接入更多外部能力。

一句话：Linghun 想解决的不是“模型会不会写代码”，而是“模型参与工程时，怎么更稳、更可控、更能交付”。

详见白皮书：2. 用户痛点与实际收益、3. 能力总览。

产品截图

为什么不是普通 AI 聊天壳

真实 AI 编程经常卡在这些地方：

• 模型没读代码就自信回答；
• 改动能运行，但破坏了项目结构；
• 测了一个小命令，却说整个项目都通过；
• 长日志和大文件把上下文挤爆；
• 一轮失败后，下次还在同一个地方漂移；
• 多工具、多模型、多智能体越接越乱；
• Windows 进程、路径、终端兼容性出问题；
• API key、权限、远程通道和本地执行边界不清楚。

Linghun 的思路是把这些问题放到运行时里处理，而不是只靠提示词提醒模型“小心一点”。

它会尽量记录事实、约束权限、保留证据、区分验证范围、控制上下文噪音、给长任务可见状态，并在最终回答里说明哪些已经验证，哪些只是推断。

底座咬合能力代表的是：这些能力不是孤立功能点。读文件会进入 evidence，编辑会进入权限和路径边界，验证会影响最终回答，Git 状态会影响稳定点判断，失败学习会影响下一轮调度，agent/job 的结果只能作为上下文，不能直接冒充 PASS。它们连在一起后，模型不再是单独在聊天框里“尽量小心”，而是在一条可执行、可验证、可回滚、可诊断的工程主链里工作。

详见白皮书：4. Evidence-first 工程闭环、6. 输出侧反幻觉系统、15. 验证、就绪与问题面板。

它不是提示词工程，也不是简单 loop 工程

Linghun 支持 prompt、skills 和工作流，但它不把可靠性寄托在“让模型自觉一点”上。

提示词可以告诉模型“请先验证再回答”，但提示词本身不能保证这些事真的发生：

• 写文件前经过权限和路径判断；
• Bash 命令被分类、限制和记录；
• 模型声称“已完成”前有真实验证证据；
• agent summary、job completed 或 remote event 不被冒充成 PASS；
• Git、索引、缓存、记忆、远程审批进入受控路径；
• 失败被复盘，并在下次相似任务中提醒。

所以 Linghun 把关键约束沉到系统层：工具执行、权限、证据、验证、Git、索引、缓存、进程守护、远程入站、失败学习和 transcript 都进入同一条主链。

这也是它和“堆 prompts / 堆 skills / 堆循环”的区别：模型仍然很重要，但事实、权限、验证和成本不再只靠模型临场记住。

详见白皮书：22. 底层能力与 Skill 的边界、17. 中枢调度系统。

能看到的收益

Linghun 追求的收益不是让流程更复杂，而是把真实开发里的隐性浪费拿掉：

• 更少幻觉：关键结论尽量绑定文件读取、工具结果、验证记录和 Git 状态。
• 更少模型漂移：项目规则、失败学习、架构边界和中枢调度会影响后续路线，而不是每轮从零开始猜。
• 更少返工：不把局部成功包装成整体完成，减少“以为好了，后来又要重做”的情况。
• 更低上下文成本：索引、摘要、缓存新鲜度、稳定工具列表和长日志控噪减少重复 token。
• 更容易回滚和交接：Git 稳定点、handoff、agent transcript 和验证边界让任务可以继续推进。
• 更适合长期项目：记忆、失败复盘、项目规则和工作区快照让多轮开发不容易散掉。
• 更适合个人开发者和新手：把资深开发者常做的“先读事实、先留回滚点、先验证范围、先看历史坑”做成默认工作方式。
• 更适合团队和企业：权限边界、私有配置、可诊断日志、远程审批、summary-only redaction 和本地执行边界，让 AI 更容易进入真实项目和内部流程。

白皮书中的目标和观测口径包括：

• 稳定项目、稳定模型、稳定工具列表、稳定 system prompt 的连续工作流，目标缓存命中率区间为 92%-96%。
• 特定高稳定样本接近 98%。
• 上下文完全稳定、输出短、工具/schema 不变化的少数回合可达到 100% 级别命中。
• 中枢调度与连续性收益是架构层面的估计，不是固定提速承诺；实际收益取决于项目、模型、任务和 usage 数据。

白皮书也给出了一组场景化收益估计，用来说明“底座咬合”带来的差异：

这些数字不是精确测量，也不是对任意项目的提速承诺；它们表达的是架构层面的收益估计：收益不只来自“判断更准”，还来自“判断结果真的被系统执行”。

详见白皮书：2. 用户痛点与实际收益、11.5 可引用的缓存目标、17.8 哲学模块闭合 + 人格连续性的场景化收益。

快速开始

环境要求：

• Node.js 22 或更新版本
• npm、pnpm 或其他 Node 包管理器

安装：

npm install -g @linghun/cli

在项目中启动：

linghun

Windows 也支持大写兼容入口：

Linghun

检查版本：

linghun --version

配置模型

启动 Linghun 后运行：

/model setup

配置向导会询问：

• API base URL
• API key
• 模型名称
• 推理等级

API key 默认保存到用户级私有 provider.env，不会写进当前项目。配置优先级是：shell 环境变量最高，其次是用户私有 provider.env，最后才是项目或默认设置。

检查 provider 配置：

/model doctor

详见白皮书：9. Provider Runtime。

一个真实工作流

你可以这样说：

检查这个项目为什么构建失败，修复问题，运行相关测试，如果通过就创建一个稳定点。

Linghun 期望把它变成一条可控闭环：

1. 先看项目结构和相关文件；
2. 形成简短计划；
3. 高风险写入或命令前请求确认；
4. 通过工具运行时修改文件；
5. 运行聚焦验证；
6. 检查 Git 状态；
7. 汇报改了什么、验证了什么、还有什么不确定。

详见白皮书：5. 阶段化工程流程、13. Git 稳定点与 Managed Worktree。

中文和 Windows 是一等公民

Linghun 从一开始就把中文开发者和 Windows 开发环境当成核心场景，而不是兼容补丁。

中文一等公民意味着：

• 可以用中文、中英混合术语和日常表达描述工程任务；
• 常见诊断、配置、模型、缓存、索引、稳定点和排障路径都尽量支持中文理解；
• 新手不需要先把真实意图翻译成固定英文命令；
• 项目规则、失败学习、记忆、handoff 和长任务摘要可以服务中文工作流。

Windows 一等公民意味着：

• 同时支持 linghun 和 Linghun 入口；
• 认真处理 PowerShell、cmd.exe、Windows Terminal、VS Code terminal、legacy conhost 等差异；
• 认真处理中文路径、空格路径、多盘符、真实 projectPath 和私有配置目录；
• 长任务、验证、runner、job 有进程追踪和可降级守护；
• 取消、超时、退出和中断时尽量做有界清理，减少残留进程拖垮下一轮任务。

这对个人开发者和企业环境都很重要：很多 AI 编程工具在 demo 里顺畅，到了 Windows、多盘符、公司权限策略、中文路径和长任务环境里就开始割裂。Linghun 希望这些真实环境不是二等场景。

详见白皮书：20. Windows 兼容增强、19. Windows 商业级守护与 Native Runner。

核心能力

下面这些不是远期愿景的空泛清单，而是白皮书里已经进入 Linghun 底座或主线设计的能力域。部分能力仍会继续打磨产品体验和跨平台细节，但核心方向已经不是单纯概念。

白皮书第 3 节的能力域在 README 中对应如下：

1. 中文友好和低学习成本

Linghun 不要求用户先背一堆英文命令。你可以用中文、英文、混合术语描述真实工程意图，例如“帮我看下为什么测试失败”“提交一个稳定点”“检查缓存命中率”“配置模型”。

复杂能力会放在 slash command、doctor、details、问题面板、命令面板和渐进展开里。默认体验尽量简单，高级能力需要时再打开。

详见白皮书：产品哲学：强底座、工程化、低学习成本。

2. 证据优先，减少幻觉

Linghun 会尽量让关键回答绑定到实际观察：读过哪些文件、跑过哪些命令、工具返回了什么、Git 当前是什么状态、验证范围到底有多大。

它不是承诺永远不出错，而是尽量不把没有证据的推断包装成确定事实。

反幻觉不是只靠一句系统提示。EvidenceSummary、完成度检查、代码事实检查、架构/边界检查、Git 操作检查、当前外部事实新鲜度规则、final answer retry/downgrade 会一起约束回答。

详见白皮书：4. Evidence-first 工程闭环。

3. 架构系统和 AntiCodeBlob

真实工程里，代码“能跑”不代表结构健康。Linghun 的架构系统会关注模块边界、依赖方向、职责回流、重复 runtime、权限绕行、诊断泄漏、前端/TUI 体验约束和交付一致性。

当用户要求新系统、新功能、新页面、新流程、长任务或跨文件改动时，架构系统会尽量把目标、项目事实、推荐方案、拒绝方案、分阶段拆解、风险、验证项和 nonGoals 组织清楚，避免“先写一坨，后面再补救”。

AntiCodeBlob 提示会提醒模型不要继续堆进 god file、超长函数、深层嵌套或无边界全局状态。它不是授权大重构，而是把架构风险提前暴露出来。

详见白皮书：7. 架构系统。

4. 本地工具和编辑安全

Linghun 内置 Read、Write、Edit、MultiEdit、Grep、Glob、Bash、Todo、Diff、Git 等工具路径。写文件和跑命令会经过权限、路径、安全和结果摘要边界。

它也关注代码卫生：解释应该留在回复、报告或交接里，不应该把“这是临时代码”“我做了什么”这种噪音写进源码。

详见白皮书：10. 工具执行与编辑安全、10.1 代码卫生。

5. 权限、安全和本地隐私

Linghun 默认把代码执行放在你的机器上。模型 provider key 默认保存在项目外的用户私有配置里。远程通道、外部能力、写文件、Bash、Git 和索引刷新都应回到本地权限边界。

详见白皮书：12. 权限、安全与资源边界、12.1 开发者主权、安全与隐私。

6. 验证感知交付

Linghun 不把“运行了一个命令”直接等同于“项目已经完成”。它会区分 PASS、PARTIAL、FAIL、TIMEOUT、STALE、CANCELLED，也会区分聚焦验证、mock 验证、真实 smoke 和未验证结论。

这能减少“看起来已经做完，实际还没闭环”的返工。

详见白皮书：15. 验证、就绪与问题面板。

7. 代码索引和工作区感知

Linghun 可以用代码索引、搜索、架构证据、工作区快照和大文件保护来减少重复读文件。它不会要求模型每轮都从零开始猜项目结构。

CLI 包随包携带常见桌面平台的 codebase-memory-mcp 二进制：

• Windows x64