项目状态：方案设计。 ai_essay_test 目前包含设计文档与接口约定，未见可运行源码、依赖清单或部署产物。本文讨论的是模块如何协作，不是一个已上线论文审查产品的复盘。
论文里的字号、缩进、引用编号和语义表达，看起来都属于“检查”，实际上需要不同的证据。把全文交给大模型，再让它一次性返回所有问题，很难保证格式判断准确，也很难把建议稳定放回原文。
先解析，再分工
方案从 Word 解析开始：提取标题、正文、样式和参考文献，组织成包含元数据、章节内容与引用列表的 JSON。每个标题或段落分配 section_id，让后续模块指向同一处内容，避免反复按文字猜测位置。
设计选型包括 Python、python-docx、lxml／OpenXML、正则表达式和 Coze 工作流。语义模块还提出 Qwen、FastAPI、LangGraph 与向量检索等候选方案。这些尚未统一成实际依赖，不能写成已经搭建完成的技术栈。
确定性问题不要交给模型猜
解析之后，工作流分成格式、引用与语义三条分支。格式分支检查字号、缩进和标题层级；引用分支对照正文编号与文末列表；语义分支提供疑似错别字、标点和学术表达建议。
这种分工的价值在于减少职责重叠。引用编号是否缺失，可以通过集合差集确定，不必消耗模型推理；表达是否含糊，则需要上下文，也必须允许人工否决。模型输出应当是待复核建议，而不是直接改写原文的指令。
各分支计划输出统一的问题列表，包含类型、位置、说明、建议与严重程度，再由报告模块汇总。预期交付是带批注的 Word 和审查报告，但现有材料只能证明这条链路被设计过，不能证明文件生成已经实现。
已完成的是协议设计，不是运行优化
当前比较具体的成果是节点通讯约定：解析结果和检测结果分别建模，检测模块追加问题，不修改原始文本。这样可以为人工复核保留原文，也让不同检查器有共同的输入输出边界。
长文本语义检查提出了分段窗口与全局术语状态，试图兼顾局部上下文和全文一致性。它是一项设计要求，尚无效果或成本数据。文档中的 Python 片段也带有示例引用集合和未完成的提取逻辑，只能视为算法示意。
因此，本项目没有可报告的已实现性能优化。文献真实性检索、流式推理与推理加速同样属于需求设想，不应因为设计文档里出现名称，就变成作品卡片上的完成项。
第一条可验证链路
下一步应先跑通一份 Word 的解析、一个问题的定位和一条批注的回写，而不是同时搭建全部候选组件。尤其要统一 section_id、字符偏移与目标文本之间的关系：重复句子、跨文本片段和表格内容都会让“按字符串查找”失效。
随后再形成可执行的数据协议，并整理覆盖标题、表格、引用和批注的样本文档集。文献真实性需要可追溯检索来源与人工判断；误报、时延和调用成本，则应留到真实实现与评测之后讨论。
设计依据
主要依据 节点间json通讯协议.md 与 智能体编排平台大纲.md。这里保留的是对文档工具的拆分思路，没有运行效果、准确率或部署成功的主张。