大模型写稿很爽，但排版让人崩溃，你有没有过这样的体验？

现在的大模型（如 ChatGPT, Claude, DeepSeek）长文本生成能力已经极其强悍。只要给足提示词，就能瞬间吐出几千字长文。但在实际的办公场景中，我发现用它们来写东西，最后的体验经常是“翻车”的。

为什么？因为在绝大多数的职场和商业环境中，我们并不是在搞纯粹的“自由创作”，而是在撰写高度标准化的文档。体制内公文、法律合同、企业招投标报告、高校科研申请书……这些文档有着近乎苛刻的格式要求。

常规的AI往往无法严格遵循已有的格式要求，而是会脱离你提供的格式要求自由发挥。为了把 AI 写的文本塞进标准模板里，我们不得不小心翼翼地“只保留文本”粘贴，然后再一行一行地重新刷格式。一顿操作下来，调格式、对齐段落的时间，甚至比自己手写还要长。

不仅如此，当前的 AI 交互模式也存在巨大的摩擦力。对于大部分人来说，缺乏一个好用的能够快速上手的app让他们写文档，每次让 AI 写一份新的商业报告或合同，都要不胜其烦地把公司简介、过往项目经历、法务要求等等信息，作为“背景提示词”重新发送一遍，耗费大量的 Token 上下文，更致命的是，把企业的核心商业数据一遍遍地发给第三方云端 API，存在着极大的隐私泄露和合规风险。

天下苦 Word 排版久矣。这就引发了我的一个思考：与其让人类去迁就 AI 的输出格式，何不设计一个 Agent Workflow，将模板直接发给 AI，让它帮你精准填空？

从“从零创作”到“智能填空”¶

基于上述的痛点，我开始构思一个全新的项目：WeaveText (织文)。

它的核心理念其实很简单：在严谨的文档工作中，我们不需要 AI “从零创作”，我们需要的是 AI 基于现有的事实进行“智能填空”。

就像它的名字“织文”一样，我希望这个工具能像编织机器一样，将用户提供的数据填入到用户提供的样例文档所形成的骨架中。你只需要提供少量的基础信息以及一份样例文档，就可以生成一份排版完美、内容详实的千字报告，而且生成的文档会严格保留样例文档的格式。

简单来说，AI在工作过程中，会得到一个有许多占位符的文档模板，它的最终任务就是逐个完成这些填空工作，将模板中的占位符替换为可用的内容。而每个占位符都有着对应的描述，告诉AI应该往里面填些什么。我的想法是，完整的任务应该由一个agent进行，针对每个填写占位符的工作，都创建一个subAgent来进行，主Agent则负责整合必要的信息，帮助subAgent更好地完成天空工作。

这个软件有什么不一样？¶

市面上其实已经有一些支持模板生成的 RPA 软件或效率工具，但它们要么配置门槛极高（需要工程师介入编写正则或脚本），要么无法保护用户隐私。在 WeaveText 的设计里，我重点押注了三个特性：

1. 数据留存在本地 (Privacy First)

在 WeaveText 中，用户可以将自己的常用信息（如个人详细简历、公司法务标准条款、过往十几个项目的脱敏案例）像建库一样保存在客户端本地（通过 SQLite 加密存储）。

当模板解析出需要填写“公司近期 AI 项目经验”时，客户端的 Agent 会自动从你的本地知识库中进行语义检索，提取最相关的信息，在本地组装成 Prompt 去请求大模型。一次录入，终身自动调用。而且支持调用本地部署的大模型接口，核心业务数据永远不落外部服务器，既省去了每次疯狂复制粘贴的痛苦，又彻底打消了企业用户的隐私焦虑。

我们在客户端中使用树状结构保留用户数据，建立文档，描述，数据，表格等等不同的数据对象，分门别类放好。在执行每一个任务时，用户都可以筛选任务中需要用到的信息，让agent只能访问数据库中的部分数据，从而保证上下文整洁。

1. 格式绝对保真 (Format is King)

传统的 AI 写作工具直接吐出不可控的文本，而 WeaveText 的核心使命是“捍卫格式”。我们采用了底层的 Word XML 渲染技术（如基于 Jinja2 的 docxtpl）。
这意味着，你在模板里预留的位置如果设置了“加粗、红色、首行缩进、行距 1.5 倍”，那么最终 AI 生成的这段文字，就会继承这些格式。即使是复杂的动态表格、嵌套列表，也能完美渲染。

1. 智能反向模板化 (Reverse Templating)

传统的文档自动化，需要人类苦哈哈地打开 Word，把里面的文字一个个替换成 {{company_name}}、{{project_bg}} 这样的占位符变量。这不仅反人类，而且太不自动化了。

在 WeaveText 中，你只需要扔给它一份历史填好的真实样例文档。服务端的解析引擎会将其结构化，保留其样式信息，并在内部调用大模型，自动识别出哪些是固定的套话，哪些是因项目而异的“可变字段”。随后，系统会反向帮你生成一个带有底层占位符的标准化模板，并自动生成每个变量填写时使用的prompt，这样后续AI就可以知道这个字段具体需要填写什么。你只需提供样例，剩下的苦力活全交给机器。

这些AI生成模板可以被保存在客户端本地反复调用，并且支持用户进行修改。由于AI只负责填写其中少部分可变字段，上下文很短，生成过程由一个可以检索本地数据库的agent进程负责，上下文较短，不容易出现上下文污染问题。

架构设计¶

为了实现上述构想，同时兼顾个人开发者的服务器成本和用户的隐私底线，我采用了前后端彻底解耦的架构设计：

客户端 (Vue3 / 未来将打包为 Tauri 桌面端)：

它运行在用户自己的设备上，掌握着第三方大模型的 API Key 以及用户的本地私密数据。它负责统筹整个工作流：向服务端查询模板需要什么，从本地数据中“挖”出信息，组装高密度的提示词，调度大模型生成具体的文本片段，并将最终拼装好的数据发给服务端进行渲染。整个过程中，大模型的调用和数据的组织都在用户的设备里发生。

服务端 (FastAPI + Python Docx 引擎)：

Python 是处理复杂文档最成熟的生态。所以我设计了一个完全无状态 (Stateless) 的 API 接口。它不连数据库，不存用户的任何文件。它唯一的使命就是：接收客户端发来的 .docx 模板和键值对 JSON 数据，通过操作 Word 底层的 XML 注入数据，把最终的文件流（Stream）以及样式信息返回给客户端。
用完即焚，干干净净。这种设计极大地降低了服务端的算力和存储成本，避开了最大的数据合规风险。服务端甚至不知道客户端填写的具体业务逻辑是什么。

公开构建的下一步¶

目前，我正在快速推进 MVP 版本的开发。服务端的核心解析、无状态接口与底层渲染引擎已经在测试中，客户端的本地数据流转也初具雏形。

未来，我计划将这个核心引擎开源，或者推出一款极其轻量级的桌面端 App，供大家免费体验。

这个想法还处于非常早期的阶段，写下这篇博客也是为了整理一下思路。

如果你对这个项目感兴趣，欢迎在评论区和我交流。

项目的GitHub仓库：链接文本