Memory Center 04｜代码、文档、任务和长期知识应该如何分工

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 04 篇，位于“问题与设计思想”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

接口代码说明当前结构，设计文档解释当时取舍，任务记录说明最近做过什么。实际开发项目中，这三类内容可能互相冲突；系统需要表达冲突的原因，而不是简单选择最后写入的一段话。

让信息保留自己的身份

源码事实随索引代际重建，文档和 Wiki 有来源及修订，记忆有确认与生命周期，任务会话有主体和项目绑定。分开管理使过期处理更明确：重建代码索引不应删除人工知识，撤回知识也不应改写源码。

代码、文档、任务和长期知识应该如何分工：设计链路示意

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

统一检索不等于统一权威

不同内容可以共同召回，但结果必须保留类别和时间。当前源码与旧文档冲突时，需要重新核对实现；模型生成的总结则应保留推断或待确认状态。active 的选择机制说明，存过的数据并不必然持续可见。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/platform/knowledge.py，函数 active，起始行 140。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

    def active(self, workspace_id):
        from memory_center.platform.wiki_sources import WikiSources
        result = [('wiki', page) for page in WikiSources(self.store).pages(workspace_id)]
        for kind in ['document', 'wiki', 'memory']:
            with self.store.db.connection() as connection:
                rows = connection.execute('SELECT payload FROM records WHERE kind=? AND workspace_id=? ORDER BY id',
                                          (kind, workspace_id)).fetchall()
            for row in rows:
                item = json.loads(row[0])
                if item['status'] == 'active' or (kind == 'memory' and item['status'] == 'confirmed'):
                    result.append((kind, item))
        return result

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

为同一接口建立代码、旧文档和新修订。
撤回旧知识。
检查查询是否仍能区分来源与当前状态。

**要核对的结果：**验证生命周期影响的是可见性，而非把历史来源悄悄改写成新事实。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。

专题目录

代码、文档、任务和长期知识应该如何分工