最有效的用法，是把 Obsidian 当作“项目状态和决策数据库”，而不是保存所有聊天记录。

• Git 保存“代码怎么变了”。
• Obsidian 保存“为什么这样改、当前做到哪、验证到哪、下一步是什么”。
• AI Agent 负责读取相关项目记忆、检查真实代码、执行任务，再把稳定成果沉淀回 Obsidian。

本地 Vault 路径：

C:\D\Obsidian Vault\Local Vault

开始新项目时，可以对 AI Agent 说：

新项目名称是 XXX，仓库路径是 XXX。先读取 Obsidian 的使用规则和用户偏好，再检查项目目录，为它建立项目沉淀。当前只做项目建档，不修改代码。

建议建立以下结构：

AI长期记忆/项目/项目名/
├── 项目名.md
├── 里程碑/
├── 功能分支/
├── 技术决策/
└── 问题记录/

主项目笔记记录：

• 项目目标和非目标
• 仓库路径和权威源码目录
• 软硬件结构
• 工具链、编码和构建规则
• 引脚、通信接口、寄存器等关键入口
• 当前阶段和下一步
• 验证方式
• 已知风险

项目开始时不必写得过满，先建立能够持续维护的骨架。

每次开始较大的任务时说：

先读取 Obsidian 中 XXX 项目的项目笔记、当前状态和相关已确认结论，再检查真实代码。不要扫描无关项目。

任务完成后说：

把这次可复用的结论沉淀到 XXX 项目。记录修改文件、关键决策、验证状态和未完成事项，不保存聊天流水账。

建议只沉淀以下信息：

• 已确认的硬件行为
• 寄存器、协议和数据格式
• 重要架构决策及原因
• 已完成能力
• 失败方案和回退原因
• 编译、测试、运行和硬件验证结果
• 下次继续工作的准确入口

临时日志、截图说明和尚未确认的猜测先放入 AI收件箱。确认后再进入项目笔记或“已确认结论”。

例如固件通信打通、上位机首版完成、硬件首次联调成功时说：

XXX 项目达到 M1 里程碑。根据代码、Git 状态和测试结果创建里程碑记录，并更新项目主页。明确哪些已经完成，哪些只是源码完成，哪些已经硬件验证。

建议生成：

里程碑/2026-07-20-M1-通信打通.md

里程碑笔记包含：

• 里程碑目标
• 已完成功能
• 关键提交或版本
• 协议、引脚和数据结构变化
• 验证环境和结果
• 尚未解决的问题
• 下一里程碑入口

里程碑是可以恢复项目上下文的“存档点”。几个月后重新打开，只读这一页就应能知道当时的真实状态。

创建分支后说：

XXX 项目开启功能测试分支 feature/xxx。记录基础分支、起始提交、目标、允许修改范围、禁止覆盖的现有修改、测试矩阵和退出条件。

建议创建：

功能分支/feature-xxx.md

分支笔记重点记录：

• 分支名和基础提交
• 为什么创建该分支
• 假设和预期结果
• 允许修改的模块
• 当前工作区已有修改
• 测试用例和测试环境
• 成功与失败退出条件
• 最终处理方式：合并、保留或废弃

开发期间可以说：

更新 feature/xxx 的测试记录。测试 1 已通过，测试 2 只有编译验证，测试 3 硬件失败。不要把失败项写成已完成。

分支结束时说：

总结这个功能分支的最终结果。把稳定结论提升到项目主页和“已确认结论”，失败方案保留在分支记录中。

结项时说：

对 XXX 项目执行结项沉淀。检查项目笔记、Git 状态、文档和验证记录，生成结项总结。不要把未完成的硬件验证写成已完成。

结项笔记应包含：

• 最终交付物
• 最终版本、分支和提交
• 系统结构
• 核心技术结论
• 编译、测试和硬件验证情况
• 已知限制
• 遗留问题
• 维护和恢复方法
• 关键文档入口

随后将项目主页状态改为：

状态: 已结项
结项日期: 2026-XX-XX

可复用结论进入 已确认结论.md，过程性内容保留在项目目录，不必全部塞进总索引。

先读取 Obsidian 中 XXX 项目的相关记忆，再查看当前代码和 Git 状态。

更新 XXX 项目的当前状态，只沉淀稳定结论、验证结果、失败经验和下一步入口。

整理 XXX 项目的收件箱和近期记录，合并重复结论，标记失效内容，但不要删除原始证据。

以本次台架结果为准，更新旧结论为“已废弃”，说明原因并链接到新结论，不要直接抹掉旧记录。

1. Git 保存代码变化，Obsidian 保存决策、上下文和验证状态。
2. 不记录所有聊天，只记录未来可能再次使用的信息。
3. 所有结果注明验证层级：源码、编译、测试、运行、硬件实测。
4. 新任务只读取相关项目，不无目的地扫描整个 Vault。
5. 旧结论失效时标记并链接新结论，不直接删除历史。
6. 不将密码、验证码、API 密钥等秘密信息写入 Obsidian。
7. 功能测试分支先记录目标和退出条件，避免测试过程中不断扩大范围。
8. 项目主页保持简洁，详细过程分别放入里程碑、功能分支和问题记录。
9. 硬件实测优先于通用惯例和早期推测。
10. 开始修改前先检查 Git 状态，保护用户已有的未提交内容。

新开的 Codex 任务不会天然知道需要使用哪个 Vault，最好明确说：

使用 C:\D\Obsidian Vault\Local Vault 作为长期记忆，先读取相关项目笔记。

最省事的固定用语是：

先读项目记忆再工作，结束后把稳定成果沉淀回 Obsidian。

如果只希望读取、不希望写入，可以说：

本次只读取 Obsidian 项目记忆，不修改任何笔记。

如果需要写入，可以说：

本次允许更新 XXX 项目的项目主页、里程碑和已确认结论，不修改其他项目。

读取 Obsidian 使用规则和用户偏好，为 XXX 建立项目沉淀，只建档不改代码。

先读取 XXX 项目的相关记忆，再检查代码和 Git 状态，然后开始任务。

将本次稳定成果沉淀到 XXX，记录依据、验证状态、失败方案和下一步。

XXX 达到 M1，创建里程碑记录并更新项目主页，区分源码、编译、运行和硬件验证。

为分支 feature/xxx 建立测试记录，写明基础提交、范围、测试矩阵和退出条件。

总结 feature/xxx，稳定结论写回项目主页，失败尝试保留在分支记录。

对 XXX 执行结项沉淀，核对 Git、文档和测试，生成最终交付、限制和维护入口。

整理 XXX 相关的 AI 收件箱内容，保留来源，待验证内容不要提升为已确认结论。