Linghun 开源：一个本地优先、证据优先的 AI 编程终端

大家好，我开源了一个自己长期打磨的 AI 编程终端：Linghun。

GitHub 地址：

https://github.com/linghungegeg/Linghun

一条命令安装：

npm install -g @linghun/cli
linghun

Windows 下也支持：

Linghun

一句话介绍

Linghun 是一个本地优先、证据优先的 AI 编程终端。

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

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

这也是我做 Linghun 的核心原因：现在 AI 并不是不能工作，而是需要被工程化约束地工作。

它能帮你做什么

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

• 阅读项目结构，定位代码问题；
• 修改文件、生成补丁、解释改动；
• 运行构建、测试、脚本和验证命令；
• 检查 Git 状态，创建稳定点，辅助回滚和交接；
• 用代码索引减少重复读文件；
• 用证据、验证和最终回答闸门约束模型漂移；
• 减少“没读代码就下结论”“没验证就说完成”；
• 把失败经验、项目规则和历史上下文变成下一轮少返工的辅助信号；
• 区分局部验证、mock 验证、真实 smoke 和未验证结论；
• 控制长日志、工具列表和上下文噪音，减少无效 token 消耗；
• 把长任务拆成可观察的步骤、后台任务或多智能体探索；
• 在 Windows、PowerShell、中文路径、带空格路径等真实环境里工作；
• 通过 MCP、Skills、Plugins、Hooks、Capability Connectors 接入更多外部能力。

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

为什么不是普通 AI 聊天壳

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

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

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

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

这就是 Linghun 反幻觉系统的价值：不是让模型少说错话那么简单，而是把“读事实、看证据、区分验证范围、拒绝空口完成、说明不确定性”变成运行时约束。

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

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

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

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

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

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

能看到的收益

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

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

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

场景	提升幅度	核心原因
普通问答、简单写代码	+5% ~ +15%	策略更一致，不容易偶尔忘记先读文件，也不会被不必要的闸门打断。
复杂工程任务	+25% ~ +50%	定位、理解、修改、验证这些阶段不再只靠模型建议，而是由调度和验证路径约束。
长期项目维护	+50% ~ +100%	系统能感知多轮失败、信任下降、任务域切换和历史经验，减少跨轮漂移。
多 agent / 多工具调度	+40% ~ +80%	根据 agent 数、workflow 状态、资源压力和上下文压力决定是否并行、降级或压缩。
风险判断、安全边界	+80% ~ +200%	多个闸门从“模型参考文本”升级为系统级执行，减少空口 PASS 和越权动作。
类人格连续性、自我叙事	质变	不是让系统有情绪，而是让系统在长会话里保持策略连续，少在错误时机做错误动作。

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

中文和 Windows 是一等公民

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

中文一等公民意味着：

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

Windows 一等公民意味着：

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

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

核心能力概览

1. 证据优先和反幻觉

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

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

2. 本地工具和编辑安全

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

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

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

4. 验证感知交付

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

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

Linghun 可以用代码索引、搜索、架构证据、工作区快照和大文件保护来减少重复读文件。CLI 包随包携带常见桌面平台的 codebase-memory-mcp 二进制：

• Windows x64
• Linux x64
• macOS Apple Silicon
• macOS Intel

6. Git 稳定点和回滚边界

大改动前后，Linghun 可以检查 Git 状态、创建稳定点、帮助管理 worktree，并把 Git 相关结论绑定到真实仓库状态上。

7. Workflow、长任务和多智能体

复杂任务不应该只靠一条聊天流硬撑。Linghun 支持 Workflow Matrix、durable job、background task、agent transcript、预算、步数、日志、报告和 handoff 边界。

8. 万能插头：连接外部软件和能力

Linghun 的长期方向不只是“一个会写代码的终端”，而是让模型通过统一边界连接更多真实能力。

MCP、Skills、Plugins、Workflows、Hooks 提供扩展入口。Capability Runtime / App Bridge 可以把外部软件能力抽象成 transport、auth、permission、riskLevel、inputSchema、outputSchema 和 provider。

外部应用可以通过 manifest 和 connector 暴露能力，Linghun 再负责自然语言匹配、权限确认、执行、证据记录和结果控噪。

这就是“万能插头”的雏形：模型不用硬编码每个软件，每个软件也不用自己重造一套智能体。能力进入同一条权限、证据、验证和失败降级主线。

快速开始

环境要求：

• 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

一个真实工作流示例

你可以这样说：

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

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

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

当前边界

Linghun 仍在活跃开发中。CLI/TUI、本地工具执行、provider 配置、Evidence-first 工程流、随包代码索引运行时和许多工程控制面已经实现。

部分高级能力，尤其是多平台 native-runner 打包、远程通道产品体验、外部能力生态和公开文档，还会继续成熟。

请把 Linghun 当成一个带证据和权限边界的本地工程助手，而不是可以盲目信任的自治系统。

作者寄语

Linghun 来自我自己长期、高强度使用 AI 编程工具时遇到的问题，也来自一次次真实项目里的开发、返工、验证和复盘。从开始到现在，我都不希望它建立在“拉踩”任何产品或模型厂商的基础上。相反，Linghun 尊重各家模型厂商在训练、推理、工具调用和长上下文能力上付出的巨大成本，也确实受益于这些能力的快速进步。

我的判断是：当下 AI 并不是不能工作，而是还不总能以工程化、可约束、可验证、可交付的方式工作。随着模型继续快速发展，“超级个体”不会只是噱头。真正的关键，是把模型能力接入证据、权限、工具、验证、记忆、成本、长任务和外部能力这些工程边界里。当模型能够以工程化方式工作时，它带来的生产力会非常惊人。

我也相信，未来普惠的 Jarvis-like AI runtime 会比很多人想象得更快落地，而且会以更普惠的方式落地。当然，这只是我的个人预想和推断。模型能力飞速发展的时代，真正值钱的会越来越是创意、判断力和执行力。

开发产品并不容易。如果你觉得 Linghun 对你有帮助，并且经济情况允许，欢迎适度打赏支持。我上一次创业失败后背负了不少债务，也需要养家糊口，同时还需要继续投入更多压测、真实项目测试和产品打磨。上一次创业里我是失败者，但在这一次开发和实践中，我觉得自己并不是。

如果你有更多想法，或者在体验 Linghun 时遇到问题，欢迎联系我，我会尽量一一解决。再次感谢各大模型厂商带来的真实增益，也感谢每一位开发者提供的好思路、好作品和真实反馈。

也希望大家能用 Linghun 做出更好的作品，提升自己的工作效率，少一点被模型“看起来很聪明但没有证据”的回答带偏。相信很多开发者都深有体会。

项目地址和文档

GitHub：

https://github.com/linghungegeg/Linghun

中文白皮书：

https://github.com/linghungegeg/Linghun/blob/main/WHITEPAPER.md

英文 README：

https://github.com/linghungegeg/Linghun/blob/main/README.en.md

许可证：

Apache License 2.0

最后

欢迎大家体验、提 issue、提建议。

如果你也长期用 AI 编程，应该会理解那种“模型看起来答得很顺，但关键事实没读、验证没跑、最后还自信说完成”的痛点。Linghun 想做的，就是把这些工程边界尽量收进运行时，让 AI 不只是会说，而是更稳定地参与真实工程交付。