我厌倦了每次会话都要向 AI 重新解释我的 codebase

Source: Dev.to

问题 — 为什么 AI 编码工具让人沮丧

每个使用 AI 辅助编码的开发者都知道同样的痛点：

1. 打开一个长期存在的项目。
2. 提出一个合理的问题 – 例如，“我们的认证流程是如何连接到用户服务的？”
3. AI：
   • 编造答案，
   • 要求你粘贴文件，或
   • 说它无法访问代码库。

于是你会 粘贴文件，解释结构，得到一个部分答案，关上笔记本电脑，然后 在下次需要帮助时重复整个过程。

正是这个循环促使我构建了 Atlarix —— 不是另一个聊天 UI，而是针对 真实 问题的解决方案：AI 对你的项目没有持久、结构化的理解。

为什么“把文件倾倒到上下文”是错误的方法

你的代码库不是一个平面的文件列表；它是一个 图：

• 函数调用其他函数。
• API 路由调用服务。
• 服务写入数据库。
• Webhooks 触发工作者。
• 类继承自基类，而其他类也继承自这些基类。

一位在项目上工作了一年的资深工程师通过 查询脑中的图 来回答问题，而不是重新阅读每个文件。
如果 AI 也拥有那张图会怎样？

Atlarix 实际做了什么

1. 解析并构建蓝图

文件监视器在每次保存时更新受影响的节点，自动保持图谱最新。

2. 基于查询的 AI 交互

当你提出问题时：

1. 查询图谱以获取相关节点。
2. 仅将这些节点注入到 AI 上下文中（≈ 5 K 令牌）。

之前 – AI 扫描所有内容 → ~100 K 令牌 → 缓慢、昂贵、混乱。
之后 – AI 查询图谱 → ~5 K 令牌 → 快速、准确。

这就是 RTE + RAG 的核心：

• RTE（往返工程） 构建图谱。
• RAG（检索增强生成） 对其进行查询。

记忆决策 – 项目记忆

两个 markdown 文件位于 ~/.atlarix/：

蓝图模式 – 可视化架构设计器

• React Flow 画布 – 将您的系统可视化为图表。
• 拖拽容器（例如 Auth API、Worker Service、DB Layer）。
• 添加 beacons（特定路由、函数、处理程序）。
• 绘制边缘以表示关系。

可视化图谱同时充当 设计界面 以及 AI 的唯一真实来源。

新功能工作流

1. 设计 在蓝图中进行架构设计。
2. 点击 “Generate Plan” → AI 将蓝图（期望）与实际运行系统（实际）进行比较，并生成 ATLARIX_PLAN.md。
3. AI 每条消息实现一个任务，随后等待您的审阅。
4. 批准 → 迭代 → 发布。

架构优先开发：先进行设计，然后让 AI 完全按照您设计的内容实现。

模式与权限 – 解耦控制

模式

权限

这些维度是独立的。示例组合：

• Autonomous + Ask – 代理可以进行计划/研究，但不能写入。
• Direct + Build – 你拥有完整的写入权限，且没有委派。

这种分离确保，例如，Reviewer 永不编写代码，而 Research 代理永不执行命令。

v3.0 – “可靠性” 发布

• Workspace storage & path resolution 重新设计——现在可以正常工作。
• .atlarix/ 文件夹系统已巩固——memory.md 与 spec.md 能够在会话之间可靠持久化。
• create_directory 和文件工具中的相对路径现在能够正确解析到工作区根目录。

有时最重要的发布是让现有功能变得可靠的那一次。

教训（我会做的不同之处）

1. 更早使用 SQLite

   • 当前的蓝图是 JSON 缓存的。完整的 ANTLR4 解析加 SQLite 持久化（PIVOT）在路线图上，所以我本应更早承诺这种架构。

2. 以更少的提供商启动

   • 支持八个云提供商以及 AWS Bedrock、Ollama 和 LM Studio 看起来很炫，但它增加了巨大的表面面积。我本会先用三个提供商启动，随后再扩展。

3. 为权限 UI 分配更多时间

   • 实现批准/拒绝流程——AI 提出每个文件更改，用户在任何操作运行前看到差异——是值得的，但我低估了所需的工作量。

开始使用

• Website: (link to be added)
• 如果你在使用 AI 编码工具时总是碰到同样的壁垒——一次又一次地重新解释你的代码库——不妨试试 Atlarix。

你的项目每次会话都会在原始上下文上耗尽 token 配额，而你希望 AI 真正理解你的架构。很想知道 Atlarix 是否为你解决了这个问题。

如果你已经构建了类似的东西，或以不同方式解决了代码库即图的问题，我真的很想了解你的方法。请在下方留言！