你有没有遇到过这种场景：每次打开 AI 编程助手，都要重复告诉它「我用 TypeScript」「数据库用 PostgreSQL」「测试用 vitest」。说完一百遍之后你开始怀疑——这东西到底有没有在听？

我也受够了。我在开源项目 IfAI 里做了一个决定：让 CLI 自己记住一切。不过，

不是简单的配置文件，不是硬编码的偏好列表。而是一套完整的跨会话持久化记忆程序——AI 在对话中主动识别、保存、提取你的偏好，下次打开自动加载，零配置、零干预。

一、为什么现有方案都不够好？

主流 AI 助手的「记忆」方案大致分三种：

我的需求很明确：

1. 零新依赖——不引入 SQLite、不引入向量数据库。
2. 人类可读——使用者能用任何文本编辑器打开、修改。按理说，
3. 自动去重——AI 重复提取同一偏好时更新日期而非新增行。话说回来，
4. 性能极致——记忆注入延迟 <1 ms，不影响会话启动速度。
5. 编译时类型安全——方法拼写错误在编译期就报错。不是运行时爆炸，

二、空间隐喻：用「建筑」组织记忆

这是我自认为最得意的设计。

~/.ifai/memories.md
## Preferences ← Hall
### programming-languages ← Room
- 使用者喜欢使用 Rust 编程
- 项目使用 TypeScript 和 Rust
## Decisions ← 另一个 Hall
### architecture
- 采用事件驱动架构

进一步，我引入了Wing的概念。支持三层方法：

Project/Preferences/programming-languages
↑ ↑ ↑
Wing Hall Room

多项目、多使用者的完整空间结构示例：

project/ifai user/alice
├── Preferences ├── Preferences
│ ├── programming-languages │ ├── programming-languages
│ ├── communication-style │ └── communication-channels
│ └── ui-mes │…├── Project Knowledge ├── Decisions
└── …└── Workflow Patterns
project/website-a user/bob
├── Preferences ├── Preferences
└── …└── ，其实，

同一个分类可以区分为「项目级别」和「使用者级别」。互不干扰，

伪代码——方法解析

// 输入: "Project/Preferences/programming-languages"
// 输出: section_title = "## Project
### Preferences
#### programming-languages"
fn parse_path -> MemoryPath {
let parts: Vec<&str> = path.split.collect;match parts.len {
3 => MemoryPath { wing: Some,hall: parts,room: Some },2 => MemoryPath { wing: None。hall: parts,room: Some },_ => Err,}
}
fn section_title -> String {
match &path.wing {
Some => format!,None => format!,}
}

  在编译时生成 enum 与 FromStr 实现，拼写错误在 Cargo build 阶段即暴露：

declare_halls!{
Preferences : "Preferences";ProjectKnowledge : "Project Knowledge";Decisions : "Decisions";WorkflowPatterns : "Workflow Patterns";}
// 编译时自动生成:
// enum MemoryHall { Preferences,ProjectKnowledge。Decisions,WorkflowPatterns }
// impl FromStr for MemoryHall {…
}
// 输入 "Prefernces" → 编译失败 ✓

三、两层记忆架构

热记忆 – 持久化注入程序 Prompt 的小文件

┌─────────────────────────────────────────────────────────────┐
│ 热记忆 │
│ ~/.ifai/memories.md │
│ - 始终注入 system prompt │
│ - ≤ tokens │
│ - AI 可通过 MemorySave 工具实时修改 │
│ - 包含 sections: Preferences / ProjectKnowledge / │
│ Decisions / WorkflowPatterns │
└─────────────────────────────────────────────────────────────┘
↓ 注入至 Prompt
┌─────────────────────────────────────────────────────────────┐
│ System Prompt + │
│ ┌───────────────────────────────────────────────┐ │
│ │ │ │
│ │  │ │
│ │ │ │
│ └───────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↓ 会话结束归档
┌─────────────────────────────────────────────────────────────┐
│ 冷记忆 │
│ ~/.ifai/sessions/YYYY-MM-DD-{id}.md │
│ - 按会话归档。人类可浏览 │
│ - 不自动注入，避免 token 浪费 │
│ - 将来可加语义搜索，作为 RAG 数据源 │
└─────────────────────────────────────────────────────────────┘

TUI 与 GUI 共用同一套 memory 模块，通过统一 API 完成读写：

┌─────────────┐ ┌─────────────┐
│ TUI 入口 │ │ GUI 入口 │
│ │ │ │
└─────▲───────┘ └─────▲───────┘
| |
| |
┌──▼─────────────▼─────►|
| memory 模块 |
| ├─ io.rs |
| ├─ tool.rs |
| └─ extractor.rs |
└────────▲─────────────┘
|
注入到 system prompt
注册到 Tool Registry

注入实现

fn inject_memories -> String {
let memories = load;format，("{}
{}
",system_prompt。memories)
}

性能实测： K​B 文件注入耗时 18 μs，远低于 100 ms 目标。纯字符串操作，无序列化/反序列化开销。

冷记忆

至于存储位置。/home//.ifai/sessions/YYYY-MM-DD-{id}.md

每次会话结束时自动生成人类可读的会话摘要：

## Summary
使用者请求实现记忆程序外部化提示词功能...
## Token Usage
- Input: ...
- Output: ...
## Memories Extracted
- **Preferences**：使用者喜欢使用 Rust
...

*冷记忆* 不自动注入 system prompt，但未来可以做语义搜索，直接作为 RAG 数据源使用。

四、AI 主动保存：MemorySave 工具

This isn’t passive storage – AI actively recognises your preference during conversation and calls a tool to persist it.

你：记住我喜欢用 Rust 写后端
再看AI，✓ Saved to Preferences/programming‑languages:
使用者喜欢使用 Rust 编程
从工具定义极简来看。json{
{
说到"name"，"MemorySave","parameters": {
说到"path"，"Preferences/programming-languages","content": "使用者喜欢使用 Rust 编程"
}
}
}

带去重的 Section Append 实现 
fn append_to_section(memories: &str,section: &str,entry: &str) -> String {
let content = extract_content_without_date;其实，// “使用者喜欢使用 Rust 编程”
if section_contains {
replace_entry_with_new_date // 更新日期，不新增行
} else {
append_new_entry // 新增行
}


}


The de‑duplication rule ignores timestamps and only compares core content。ensuring that repeated confirmations merely refresh date.

五、会话后批量提取 

The system automatically triggers a memory‑extraction pipeline when a conversation ends:


对话结束 →
判断是否值得提取 →
生成对话摘要 →
调用 LLM提取新记忆 →
合并到 memories.md →
保存会话摘要到 sessions/



The extraction prompt lives in an external file so users can fully customise what gets remembered:




提取规则

再看使用者偏好，编程语言、工具、框架。怎么说呢，从关键决策来看，架构决策、技术选型。至于领域知识，项目特定业务逻辑。

输出格式


使用 TypeScript 而非 JavaScript 


采用 PostgreSQL 作为主数据库


为什么不用 JSON/YAML/TOML？按理说，


`##` 层级天然表达树形结构；易于 git diff 与版本管理。

L​ightweight – 人类直接阅读，无需解析器。

Avoids extra tooling overhead.

Easier backup – copy file.

Simplifies debugging – `cat` 查看全部内容。其实，

Satisfies zero‑dependency principle.

No hidden binary state that could diverge from source control.


为什么不用 SQLite？


No additional compile time or binary size.

The file is instantly human readable . Compared to `sqlite3 memories.db "SELECT * FROM memories"` this is far more approachable.

Easier version control – diffs are clear.

No migration headaches when schema evolves.


为什么用 macro_rules!而不是 proc‑macro？按理说，


macro_rules!是 Rust 内置，零编译开销。

proc‑macro 必须单独 crate，会增加编译时间。

适度元编程即可满足需求，避免过度设计。