https://blog.tnxg.moe 明日尚未到来，希望凝于心上 Fri, 31 Jul 2026 07:09:30 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN https://blog.tnxg.moe/avatar.png https://blog.tnxg.moe All rights reserved 2026, Lee 默认 https://blog.tnxg.moe/posts/default/obsidian-ai-agent obsidian-ai-agent Fri, 31 Jul 2026 07:09:30 GMT 新项目名称是 XXX，仓库路径是 XXX。先读取 Obsidian 的使用规则和用户偏好，再检查项目目录，为它建立项目沉淀。当前只做项目建档，不修改代码。 建议建立以下结构： ```text AI长期记忆/项目/项目名/ ├── 项目名.md ├── 里程碑/ ├── 功能分支/ ├── 技术决策/ └── 问题记录/ ``` 主项目笔记记录： - 项目目标和非目标 - 仓库路径和权威源码目录 - 软硬件结构 - 工具链、编码和构建规则 - 引脚、通信接口、寄存器等关键入口 - 当前阶段和下一步 - 验证方式 - 已知风险 项目开始时不必写得过满，先建立能够持续维护的骨架。 ## 三、平时开发 ### 任务开始 每次开始较大的任务时说： > 先读取 Obsidian 中 XXX 项目的项目笔记、当前状态和相关已确认结论，再检查真实代码。不要扫描无关项目。 ### 任务结束 任务完成后说： > 把这次可复用的结论沉淀到 XXX 项目。记录修改文件、关键决策、验证状态和未完成事项，不保存聊天流水账。 建议只沉淀以下信息： - 已确认的硬件行为 - 寄存器、协议和数据格式 - 重要架构决策及原因 - 已完成能力 - 失败方案和回退原因 - 编译、测试、运行和硬件验证结果 - 下次继续工作的准确入口 临时日志、截图说明和尚未确认的猜测先放入 `AI收件箱`。确认后再进入项目笔记或“已确认结论”。 ## 四、项目达到里程碑 例如固件通信打通、上位机首版完成、硬件首次联调成功时说： > XXX 项目达到 M1 里程碑。根据代码、Git 状态和测试结果创建里程碑记录，并更新项目主页。明确哪些已经完成，哪些只是源码完成，哪些已经硬件验证。 建议生成： ```text 里程碑/2026-07-20-M1-通信打通.md ``` 里程碑笔记包含： - 里程碑目标 - 已完成功能 - 关键提交或版本 - 协议、引脚和数据结构变化 - 验证环境和结果 - 尚未解决的问题 - 下一里程碑入口 里程碑是可以恢复项目上下文的“存档点”。几个月后重新打开，只读这一页就应能知道当时的真实状态。 ## 五、开启新功能测试分支 创建分支后说： > XXX 项目开启功能测试分支 `feature/xxx`。记录基础分支、起始提交、目标、允许修改范围、禁止覆盖的现有修改、测试矩阵和退出条件。 建议创建： ```text 功能分支/feature-xxx.md ``` 分支笔记重点记录： - 分支名和基础提交 - 为什么创建该分支 - 假设和预期结果 - 允许修改的模块 - 当前工作区已有修改 - 测试用例和测试环境 - 成功与失败退出条件 - 最终处理方式：合并、保留或废弃 开发期间可以说： > 更新 `feature/xxx` 的测试记录。测试 1 已通过，测试 2 只有编译验证，测试 3 硬件失败。不要把失败项写成已完成。 分支结束时说： > 总结这个功能分支的最终结果。把稳定结论提升到项目主页和“已确认结论”，失败方案保留在分支记录中。 ## 六、项目结项 结项时说： > 对 XXX 项目执行结项沉淀。检查项目笔记、Git 状态、文档和验证记录，生成结项总结。不要把未完成的硬件验证写成已完成。 结项笔记应包含： - 最终交付物 - 最终版本、分支和提交 - 系统结构 - 核心技术结论 - 编译、测试和硬件验证情况 - 已知限制 - 遗留问题 - 维护和恢复方法 - 关键文档入口 随后将项目主页状态改为： ```yaml 状态: 已结项 结项日期: 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 收件箱内容，保留来源，待验证内容不要提升为已确认结论。 ]]> admin@leegdhk.org (Lee) https://blog.tnxg.moe/posts/default/stm32f103-fan-controller-keil-pwm-tach-oled stm32f103-fan-controller-keil-pwm-tach-oled Wed, 15 Jul 2026 05:53:03 GMT admin@leegdhk.org (Lee) STM32F103 Keil OLED 风扇控制 https://blog.tnxg.moe/notes/1 note-1 Mon, 25 May 2026 02:35:00 GMT admin@leegdhk.org (Lee)