从 Linux 0.01 到 AI 开源：星图邻的开源实践

2026年9月17日，Linux 0.01 发布已经过去35年。

在这一天，星图邻正式开始以开源技术组织的形式，对外整理和发布一系列 AI 工程实践。

这并不是为了给某一个项目增加一个"纪念日"的概念。

对栈上月明团队来说，更重要的是借这个时间点，正式公开一件已经持续了一段时间的事情：

把一些经过真实项目验证、具有通用价值的 AI 工程实践，逐步沉淀为开源项目。

目前已经公开的项目包括：

GeoFriendlyChecker v1.0.0：2026年9月16日发布
LeadChat：2026年9月17日开始开源

这两个项目解决的问题并不相同，但背后有一个共同出发点：

很多 AI 应用开发中反复出现的问题，与具体业务并没有强绑定，因此值得被抽象、验证并公开。

一、为什么开始做开源？

过去一段时间，我们参与了不少企业 AI 项目。

在这些项目中，一个比较明显的现象是：

模型本身往往不是最困难的部分。

调用模型、实现对话、接入 RAG，这些事情已经有越来越成熟的工具和框架。

真正耗费时间的，往往是模型之外的问题，例如：

企业知识如何进入系统；
知识更新后如何保持有效；
AI 如何访问已有业务系统；
工具调用如何进行权限控制；
AI 如何参与已有业务流程；
不同模型之间如何切换；
本地模型和云端模型如何统一接入；
数据如何尽量减少不必要的外部传输。

这些问题经常在不同项目中重复出现。

当一个问题已经具有相对稳定的技术抽象，而且不依赖某一家企业的具体业务时，我们更倾向于把它做成一个独立项目。

这也是星图邻成立的主要原因。

二、星图邻是什么？

星图邻是栈上月明团队建立的开源技术组织。

它不是某一款产品的名称，也不对应某一个单独的业务方向。

我们更希望把它理解成一个长期的技术项目集合：

text 复制代码

真实项目
   ↓
问题抽象
   ↓
工程实现
   ↓
开源
   ↓
社区反馈
   ↓
继续迭代

因此，GeoFriendlyChecker 和 LeadChat 只是这个组织目前公开的两个项目。

未来的项目方向也会围绕 AI 工程实践继续展开，但不会预先定义一个过大的产品边界。

三、GeoFriendlyChecker：从网站结构重新理解 AI 可读性

2026年9月16日，GeoFriendlyChecker v1.0.0 发布。

这个项目关注的问题比较简单：

当越来越多的信息通过 AI 进行检索、理解和总结时，一个网站本身是否具备足够好的机器可理解性？

传统的网站优化，很多时候关注的是搜索引擎。

但在 AI 参与信息获取之后，网站还面临另外一个问题：

内容是否能够被 AI 系统准确识别、理解和组织？

因此，GeoFriendlyChecker 从几个维度对网站进行检查，包括：

Structured Data
Meta Information
Content Semantics
AI Readability

项目的一个重要设计原则是：

能在浏览器本地完成的检测，尽量在本地完成。

网站基础结构分析并不一定需要上传到服务端。

因此，这个项目目前更偏向一个本地工具，而不是依赖远程分析服务的产品。

四、LeadChat：从 AI 客服到 Web AI Assistant

LeadChat 最初来自一个比较直接的问题：

怎样让 AI 更容易进入一个现有的 Web 系统？

实际开发过程中，我们发现，"AI 客服"这个定义其实比较窄。

同样的一套 Web 交互能力，也可以用于：

text 复制代码

网站
管理后台
SaaS 系统
客户门户
企业内部系统

因此，LeadChat 更适合被描述为：

一个可以嵌入 Web 系统的开源 AI Assistant。

它的使用方式比较直接，可以通过一段 script 集成到已有页面。

目前的技术栈包括：

text 复制代码

Python
FastAPI
SQLAlchemy
SQLite / PostgreSQL
ChromaDB
LiteLLM
Vue
Docker

模型侧则支持多种 OpenAI-compatible 接口，以及：

text 复制代码

OpenAI
DeepSeek
Qwen
GLM
Ollama

这里我们更关注的是"应用层适配"，而不是绑定某一家模型。

五、对话不只是聊天，也可以成为交互界面

LeadChat 中一个比较典型的实践，是对话式数据采集。

传统的数据采集通常依赖表单：

text 复制代码

姓名
电话
邮箱
需求
自定义字段

而在对话模式下，AI 可以根据已有信息判断缺失字段，并继续进行追问。

例如：

text 复制代码

用户：我想了解一下你们的产品。

AI：可以。请问怎么称呼您？

用户：张三。

AI：好的，张先生。方便留下联系方式吗？

用户：138xxxxxx。

AI：收到。您主要想了解哪一类功能？

最终从自然语言中逐步得到结构化数据。

这类能力可以应用于咨询、信息采集、客户门户以及其他需要结构化输入的场景。

不过，对 LeadChat 来说，数据采集只是其中一个功能。

更大的方向其实是：

把 Web 中原本依赖菜单、按钮和表单完成的部分交互，逐步增加一种自然语言入口。

因此，我们更倾向于把它定义为 Web AI Assistant，而不仅仅是 AI 客服。

六、为什么本地模型是一个重要的能力？

企业 AI 场景中，一个绕不开的问题就是数据。

知识库、业务数据、内部文档、客户信息等内容，往往具有比较明确的使用边界。

因此，AI 系统除了支持云端模型，也需要考虑本地运行方式。

LeadChat 在设计时保留了这一层能力，例如：

text 复制代码

Ollama
+
Local Embedding
+
Docker

这样可以把模型、Embedding 和应用部署在自己的环境中。

这里真正重要的，并不是"本地模型"这四个字本身，而是：

AI 应用的模型层应该尽可能保持可替换。

云端模型、本地模型、不同厂商的模型，只要接口满足约定，就可以进入同一套应用架构。

这也是 LeadChat 使用 LiteLLM 和 OpenAI-compatible API 的原因之一。

七、RAG 和 Agent 之外，更复杂的是业务系统

在 AI 应用开发中，RAG 解决的是一类问题：

AI 能不能找到相关信息？

Agent 进一步解决：

AI 能不能调用工具完成任务？

但进入企业系统以后，还会出现更多问题：

text 复制代码

Knowledge
Agent
Tool
Permission
Workflow
Business System
Audit

例如，一个简单的业务流程可能是：

text 复制代码

用户：
查询客户订单

        ↓

Agent：
调用 CRM

        ↓

Agent：
读取订单状态

        ↓

发现：
订单延期

        ↓

Agent：
调用售后系统

        ↓

创建任务

        ↓

通知相关人员

真正困难的地方，不再是"让模型输出一句正确的话"。

而是：

如何让模型以受控、可追踪的方式进入已有软件系统。

这也是我们近一段时间持续研究的一个方向。

在一些实践中，我们尝试将旧 ERP、MES、CRM 等系统中的业务对象、属性和关系，转换为 AI 可以理解和调用的业务语义层，再通过受控工具调用让 Agent 与已有系统交互。

这类探索，本质上已经超出了传统意义上的"聊天机器人"。

八、我们理解的 AI 应用，更像是一层基础设施

随着项目逐渐增多，我们对 AI 应用的理解也发生了一些变化。

最初，我们更容易从这样的结构去看问题：

text 复制代码

用户
 ↓
聊天窗口
 ↓
大模型

但真实项目通常更接近：

text 复制代码

用户
 ↓
Web / Client
 ↓
AI Assistant
 ↓
Agent
 ↓
Knowledge / Tools
 ↓
Business Systems
 ↓
Workflow
 ↓
Audit

模型只是其中的一层。

真正让 AI 变成"软件"的，是模型之外的这些部分：

数据；
知识；
工具；
权限；
工作流；
系统集成；
日志与审计。

这也是我们为什么会逐渐把企业 AI 理解为一种 AI Business Infrastructure。

九、为什么选择开源？

我们对开源的理解并不是"把一个产品免费发布出去"。

更重要的一点是：

让工程实现接受真实使用和公开反馈。

代码公开以后，项目面对的不再只有开发者自己的测试环境。

它可能被：

text 复制代码

使用
Fork
Issue
Review
修改
重新实现

也可能会有人指出：

这个设计为什么这样做？

或者：

这里其实应该换一种实现。

这些反馈对于一个工程项目来说，本身就是验证的一部分。

所以我们更愿意把开源理解成：

一种公开的工程验证方式。

十、星图邻接下来会做什么？

目前我们不准备提前定义一个巨大的功能列表。

更现实的方式还是从具体问题出发：

text 复制代码

真实问题
↓
工程实践
↓
抽象
↓
开源
↓
社区验证
↓
继续迭代

GeoFriendlyChecker 和 LeadChat 是目前公开的第一批项目。

后续也会继续整理一些 AI 工具、开发组件和工程实践，并逐步放到星图邻的开源项目中。

十一、写在最后

35年前，Linux 0.01 还是一个很早期的公开项目。

35年后，AI 软件正在经历一个类似的阶段：

很多东西还没有形成真正稳定的工程模式。

我们也还在不断试错。

所以，开源对我们来说并不是：

"我们已经做出了最终答案。"

更接近的是：

我们把目前做出来的东西公开出来，看看它能不能在真实环境中继续生长。

这就是星图邻开始的起点。

从企业项目，到工程实践，再到开源项目。

我们希望把那些值得重复解决的问题，尽可能沉淀下来，交给更多开发者一起验证。

项目地址

GeoFriendlyChecker

GitHub

https://github.com/XingTuLink/geo-friendly-checker

Gitee

https://gitee.com/XingTuLink/geo-friendly-checker

AtomGit

https://atomgit.com/XingTuLink/GeoFriendlyChecker

LeadChat

GitHub

https://github.com/XingTuLink/LeadChat

Gitee

https://gitee.com/XingTuLink/lead-chat

AtomGit

https://atomgit.com/XingTuLink/LeadChat