我不想再要一个“只会聊天”的 AI 了，所以做了 DreamAxis

梦帮科技

328人浏览 · 2026-03-24 14:49:08

梦帮科技 · 2026-03-24 14:49:08 发布

如果一个 AI coding 工具不能真正进入仓库、不能告诉我它跑了什么、不能解释它为什么失败，那它就还不够像一个合格的开发助手。
本文带你认识 DreamAxis：一个 local-first、默认免注册、带 CLI + Browser Runtime 的开源 Repo Copilot。
版权所有 © 2026 DREAMVFIA UNION

开场：为什么今天的 AI coding 工具，还是经常让人“不放心”？

我们已经见过太多 AI coding 产品演示了：

回答很流畅
看起来什么都懂
聊起架构、代码、调试思路都头头是道

但一旦你把它真正放进本地仓库，问题就来了：

它到底有没有真的跑命令？
它看到的是猜测，还是证据？
它失败时，到底是缺依赖、缺工具链、缺脚本，还是代码本身挂了？
它给你的“建议”，究竟是 grounded，还是只是像那么回事？

DreamAxis 想做的，不是再造一个聊天框。

DreamAxis 想做的是：

把 AI 从“会说话”推进到“会执行、会留证据、会解释失败、会给下一步”。

这也是我觉得它值得被推广、值得被测试、值得被持续打磨的原因。

在这里插入图片描述

图 1：DreamAxis 的 chat-first repo copilot 界面，不只是输出答案，更强调 mode、execution bundle、failure summary 和 runtime evidence。

DreamAxis 是什么？一句话先说清楚

DreamAxis 当前可以被概括为：

一个 local-first 的开源 agent execution platform。

如果换成更接地气的说法，它更像：

一个真正面向 solo developer 的本地 Repo Copilot。

它不把 Chat 当终点，而是把 Chat 当入口。

DreamAxis 当前核心链路是：

Chat → Skill routing → CLI / Browser Runtime → Evidence → Next step

也就是说，用户说一句自然语言，不应该只换来一段漂亮回复，而应该换来：

对 repo 的真实理解
对本地命令 / 页面验证的真实执行
对 stdout / stderr / screenshot 的真实证据
对失败的结构化解释
对下一步行动的 grounded 建议

这就是 DreamAxis 和“普通 AI 聊天工具”最根本的区别。

为什么说 DreamAxis 不是“又一个聊天框”？

如果你只是看界面，DreamAxis 当然也有聊天入口。

但它的真正重点不在“聊天”，而在 执行层。

1）它是 local-first

DreamAxis 默认站在本地优先这一边，而不是先把一切都做成云端托管 SaaS。

2）它默认 no-signup by default

DreamAxis 默认模式是：

AUTH_MODE=local_open

也就是说：

默认不需要公开注册
默认不需要邮箱验证
默认不需要先拥有一个平台账号，才能开始试用

3）它是 runtime-centric，而不是 chat-only

DreamAxis 不是“模型先说，执行以后再说”，而是把 runtime 直接放到产品核心。

当前已经落地：

CLI Runtime v1
Browser Runtime v1（Playwright）
runtime / session / execution 三层可见性

4）它强调 self-hosted provider keys / knowledge / skills

DreamAxis 的方向不是把所有东西都锁进平台，而是更强调：

provider key 由用户自己持有
knowledge 落在本地
skills / runtime / docs 可以持续积累

换句话说，DreamAxis 想做的不是“把你接进某个黑盒”，而是“帮你在本地搭一个真正可持续的 AI 执行底座”。

默认不需要注册，那数据到底保存在哪里？

这几乎是所有人都会问的核心问题。

DreamAxis 当前的数据落点非常明确：

用户 / workspace / provider / runtime / skill / knowledge 元数据：PostgreSQL
Provider API key：加密后保存到 provider_connections
上传的原始文档：本地持久目录
Web token：浏览器 localStorage

所以 DreamAxis 的默认逻辑不是：

“先把你的账号、数据、key 交给平台。”

而更接近：

“你自己部署、你自己持有 key、你自己持有数据、你自己控制执行环境。”

对重视隐私、可控性、可迁移性的开发者来说，这不是细节，而是立场。

DreamAxis 现在已经能做什么？

说得更具体一点，DreamAxis 当前已经不是一个空概念，而是有一条相当清晰的产品能力线。

Chat modes

当前 Chat 支持四个主模式：

understand
inspect
verify
propose_fix

CLI Runtime

可以在安全边界内针对 workspace 执行本地命令，拿到：

stdout
stderr
exit code
runtime execution 记录

Browser Runtime

通过 Playwright 执行页面打开、文本抓取、截图、基础验收验证。

Knowledge

把内置文档、上传文档、repo 文档变成可检索知识资产，不再只是“聊天附件”。

Doctor

检查本地基线与 workspace readiness，包括：

Git
Node.js
pnpm / npm
Python
Docker
Browser Runtime

这让 DreamAxis 更像一个真正的本地 AI 助手平台，而不只是一个会输出文字的模型外壳。

DreamAxis 最值钱的地方：verify / troubleshoot

如果一定要说 DreamAxis 当前最值得看的能力，我会选这条线：

它开始把 verify / troubleshoot 做成真正的产品能力，而不是模型表演。

DreamAxis 不满足于只告诉你：

“这个可能有问题”
“建议你检查一下依赖”
“你可以再看看配置文件”

它更想做到的是：

真正跑验证链路
真正读取失败输出
真正分类失败类型
基于证据给 grounded next step

Troubleshooting summarizer

DreamAxis 当前已经把 chat trace 里的失败信息结构化出来，包含：

failure_summary
failure_classification
stderr_highlights
grounded_next_step_reasoning

失败类型首版已经覆盖：

dependency_or_install
missing_toolchain
repo_not_ready
script_or_manifest_missing
code_or_config_failure
browser_or_runtime_failure
unknown

这意味着当一次 verify 失败时，DreamAxis 不应该再只是把一大段 stderr 原样扔给你，而是会尽量直接告诉你：

失败发生在哪个 probe
它更像哪一类问题
第一条高信号错误是什么
你下一步更该修环境、修依赖、修脚本、修配置还是修代码

这件事听上去像“只是 UI 更清楚了”，但实际上它非常重要：

因为 AI coding 工具一旦不能把失败讲清楚，开发者对它的信任就会迅速下降。

在这里插入图片描述

图 2：DreamAxis Runtime 控制台，能直接查看 host、session、execution、artifact 和父子 execution 关系，适合作为审计面板。

DreamAxis 和 Codex / Claude Code / OpenClaw 是什么关系？

DreamAxis 并不是想简单复制 Codex、Claude Code 或 OpenClaw。

它更像是在承认这些桌面 AI 助手已经定义了一个现实标准之后，再往前走一步。

先对齐现实标准

DreamAxis 明确承认今天桌面 AI assistant 的统一基线就是：

Git
Node.js
包管理器（pnpm / npm）
Python

这不是“文档前置条件”，而是桌面 AI coding 的现实地基。

再补上更强的可观测性

DreamAxis 比较想继续做强的是：

local-first
no-signup by default
runtime-backed evidence
CLI + Browser 双执行面
self-hosted provider keys
skills + knowledge + runtime 的长期积累

如果说 Codex / Claude Code 更像“强大的 agent CLI”，那么 DreamAxis 当前更像：

一个以 Chat 为入口、但以 Runtime / Evidence / Audit 为核心的数据面与执行面产品。

这也是它最有机会形成差异化的地方。

当前边界也必须讲清楚：DreamAxis 现在不是什么

一个项目要值得长期跟踪，除了讲自己已经做成了什么，也要讲清楚它现在还不是什么。

DreamAxis 当前边界很明确：

proposal-only
- propose_fix 只给建议，不自动写文件
不自动执行高风险写入动作
- 默认只自动执行安全、只读、可解释路径
不是完整 autonomous multi-agent OS
- role registry 和 execution foundation 已有基础，但还不是全自动多 agent 系统

我反而觉得这很加分。

因为比起“什么都说自己能做”，DreamAxis 现在更像是：