先说清楚立场：Microsoft 365 Copilot 是很强的产品，深度绑定 M365 生态的云端协同场景里，它的体验属于第一梯队，这点没有争议。但落到具体环境，问题来了——我接触的政企单位里相当一部分是内网或物理隔离环境，机房墙上贴着"禁止外联"。Copilot 的能力依赖微软的云端服务链路（具体形态以微软官方文档为准），内网里没有这条通路，再强的能力也到不了桌面。这篇聊的不是谁替代谁，而是一个务实的补充思路：内网环境里，文档 AI 的需求怎么落地。
先把场景差异摆清楚
Copilot 的形态是云服务：账号、算力、数据链路都在云端，宿主是微软生态的 Word、Outlook、Teams。这套设计在联网企业环境里是顺的，在内网环境里是断的——不是产品缺陷，是形态和环境的错配。同样，不少优秀的 AI 写作工具也都建立在云端服务之上。内网单位面对的是一个共性约束：文档不能出去，云端能力进不来。
这时候需要的是另一种形态：能力跑在本地、宿主跑在本地、数据全程不出域。
补充思路：本机智能体加本地模型
察元AI文档助手走的就是这条路：WPS 文字做宿主（信创环境里 WPS 本来就是标配），模型端点指向内网的 Ollama、LM Studio、Xinference 等本机推理，文档智能体服务只监听 127.0.0.1。三层全在墙内，一个字节不出门。
它能干的活正好覆盖内网文字岗的高频需求：错别字批注钉到具体错字、批量替换带预览确认、插表格行列、多文档交叉校对、敏感信息筛查，二十九个内置助手不联网也能用。要走智能体路线，Claude Code、Codex CLI、Cursor 经 MCP 接入，一条命令注册：
claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62588/mcp验证服务在线：
curlhttp://127.0.0.1:62588/healthz返回online即通。内网里的实际用法，比如发布前终检一次跑完：
帮我做发布前终检：错别字、标点、数字前后一致性、表格与正文是否一致；全部用批注输出；最后给我一份问题分级摘要（严重/一般/建议）分级摘要直接给到审核人，问题钉在原文批注上，复核不用来回翻。
内网里的模型策略
墙内的模型从哪来是绕不开的问题。纯内网就上 Ollama、LM Studio、Xinference 这类本机或内网推理，DeepSeek、Qwen、GLM 都有本地部署版本；能连内网服务器的，用 OneAPI 之类网关把几路模型统一成一个 OpenAI 兼容端点，察元侧只认端点不认厂商，换模型不动应用。校对、术语统一、敏感信息筛查这类任务，本地模型的性价比已经够看，真要较真的长文生成，留给人工把关。写回侧不必担心失控：未确认的操作只返回 preview，批注类必须显式 confirmed 才落盘，AI 动的每一笔都有迹可循。
形态对比，不比强弱
客观摆几个维度。云端方案（Copilot 等）：模型能力强，生态协同深，但依赖网络通路，数据链路出域，费用按订阅和用量。本地方案（察元加 Ollama）：离线内网原生，开源可审计（Apache-2.0），数据不出域，模型能力受本机算力限制，复杂生成任务的质量与云端旗舰有差距。两套形态各自成立，选择标准不是哪个更好，而是你的环境允许哪个：允许出域且深度使用 M365 的组织，Copilot 值得投入；内网隔离的组织，先把本地方案跑起来是正事；混合环境的单位两套并存、按场景分流，也完全合理。规模往上走时，本地方案也有台阶：科室共享上 Docker 服务版，数百人以上看至臻版工作空间，路是通的。
几点务实提醒
第一，本地模型按任务选型：校对、术语统一这类任务本地模型够用且性价比高，长文创作和复杂改写先实测再定预期。第二，内网部署不等于免安全管理：模型端点、知识库、批注数据都在墙内，权限和备份照样要有人管。第三，AI 输出一律是辅助参考，公文定稿、合同签署的责任链不因工具变化而变化，涉密事项的管理制度更不会因为用了 AI 就豁免。
环境决定形态，形态决定选型。内网不是 AI 能力的禁区，只是换了一条实现路径——先把文档这个最高频的场景在墙内跑顺，就是当下最务实的一步。
