Refact 转向社区本地版：把项目决定和踩坑记录留给下一次会话

项目改了几周，AI 仍反复问同样的背景：某个接口为什么不能换，哪个依赖有兼容问题，上次为什么放弃一个方案。Refact 社区版值得从“让下一次会话接得上”这个需求来看，而不是把它当成又一个临时聊天侧栏。

先说明当前身份。原 Refact Cloud 已退役，原 smallcloudai/refact 仓库也明确标成归档，并把持续开发指向 JegernOUTT/refact。这里介绍的是这个社区维护的本地项目，不是仍在提供原云端账号、模型额度和付费支持的服务。

保存的是项目知识，不只聊天记录

Memory and Knowledge 文档把记忆拆成几层：知识图谱保留关系与事实，向量索引用于按含义检索，会话轨迹记录按时间发生的工作，任务记忆则保存具有类型的条目。

这些类型包括 decision、spec、gotcha、risk、handoff、progress 等。它们对应的用途很具体：决定记录为什么选一种做法，gotcha 保留容易踩的坑，handoff 留下交给后续工作的信息。与把整段聊天重新塞给模型相比，这些材料更容易知道“现在想找哪一类背景”。

教学情境中，一项数据库迁移因为老客户端兼容而延期，应该留下的是约束、决定和关联文件，而不只是某天讨论过三种方案的长对话。之后继续迁移时，再把相关条目与当前代码一起核对，就有机会少走一遍背景调查。

这些材料留在哪里

当前设计把项目状态放在 <project>/.refact/ 下，包括 knowledge、trajectories、tasks、vecdb 等目录。文件与索引可以被检查和备份，不必只依赖某个云账号里的聊天列表。

图为社区维护仓库提供的界面样例。下方 User memories 展开了可引用的记忆文件和行号，说明记忆有可追踪的材料位置；图中报告内容是项目自己的示例，不代表本文验证了这些诊断结论。

文档进一步说明，检索到的内容会形成 context_file 消息，经路径整理、去重和 token 预算处理后进入模型上下文；代码还可按语法结构切分。它并不是把目录里的所有材料一股脑重复发送。

留下来之后，还要更新

记忆的价值取决于它是否仍适用。兼容限制解除后，旧决定就应被更新或替代，否则长期记忆也可能变成长期误导。社区文档列出新鲜度和过期内容处理，但具体任务仍需要结合当前源码判断。

项目采用 BSD-3-Clause 许可，模型和 embedding 由用户选择的提供方运行。本地保存状态不等于所有请求都离线：选择云 API 时，相关内容仍会按配置进入外部服务。README 也提醒，常驻 daemon 与 TUI 是早期预览，IDE 插件和核心引擎是较稳定的入口。

我会把它放在长期维护同一项目的场景里：先保留少量真正会影响下一次工作的决定和坑点，再检查它们如何被检索。能够说明来源、能够修订的项目记忆，比单纯让聊天窗口“记住更多”更值得留下。