Memory Center 16｜代码和文档怎样分块，才能保留可追溯来源

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

从实际问题出发

检索命中一段文本，却无法说明它属于哪个文件和哪一行，就很难用于工程修改。分块不仅影响模型输入，还决定引用、去重和源码新鲜度检查是否可靠。

文本边界必须可还原

块应保留源标识、行范围和必要的列范围。空白不应占据嵌入请求，超长单行也不能无界交给模型。代码和说明文档的结构不同，分块策略应服从后续读取与定位需求。

代码和文档怎样分块，才能保留可追溯来源：设计链路示意

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

块大小是一种取舍

块过大增加无关信息和成本，块过小会丢失局部上下文。没有一个长度对所有项目都最优；应以真实查询观察是否需要相邻上下文。位置稳定也不能代替内容修订，文件移动或修改后引用仍需复核。

关键源码与阅读方法

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

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

def split_text(text, metadata):
    lines = text.splitlines()
    chunks = []
    buffer, start, size, fenced = [], 1, 0, False

    def append_chunk(content, first, last, **position):
        if content.strip():
            chunks.append({'id': identity('chunk'), 'source_id': metadata['source_id'],
                           'content': content, 'metadata': dict(metadata, line=first, end_line=last, **position)})

    for number, line in enumerate(lines, 1):
        if line.lstrip().startswith('```'):
            fenced = not fenced
        if buffer and (size > 1800 and not fenced or size + len(line) > 6000):
            append_chunk('\n'.join(buffer), start, number - 1)
            buffer, size, start = [], 0, number
        if len(line) > 6000:
            for offset in range(0, len(line), 1800):
                piece = line[offset:offset + 1800]
                append_chunk(piece, number, number, column=offset + 1, end_column=offset + len(piece))
            buffer, size, start = [], 0, number + 1
            continue
        buffer.append(line)
        size += len(line) + 1
    if buffer:
        append_chunk('\n'.join(buffer), start, len(lines))
    return chunks

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

用一个小实验核对设计

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

创建空白文件、普通多行和超长单行样例。
检查每块的来源范围。
将范围还原并对比原文。

**要核对的结果：**所有非空内容应可追溯，块大小控制不能造成静默遗漏。

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

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

适用边界与继续阅读

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

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

专题目录

代码和文档怎样分块，才能保留可追溯来源