用察元这半年我在技术群和论坛上帮人排过错也见过不少反例有人把日志原样往群里一贴API Key、内网系统域名、待审文档的标题和项目编号全在裸奔。数据不出域是架构层面的事——察元的 MCP 服务只监听 127.0.0.1本机即信任边界模型还能接 Ollama 这类本地端点。但发帖求助的那一刻边界得你自己守。MCP 生态越大、排错帖越多这个问题就越普遍——你贴出去的不只是一段报错还有你们单位数字化工作方式的一个切片。这篇是一份排错时的隐私纪律清单八条每条都有对应的工具配合。一、发日志前先扫密钥特征任何准备外发的日志、配置截图、报错文本先自查一遍密钥特征。终端里一条命令的事findstr /i sk- Bearer api_key password chayuan-log.txt命中任意一项先处理再发。密钥泄露的代价远大于一次排错求助的收益而且贴出去的 Key 爬虫几分钟就能扫到。二、拿不准就先跑一遍敏感信息扫描不确定文档样例里藏了什么直接让察元扫查找疑似身份证号、手机号、银行卡号并批注这句提示词会让 AI 把疑似个人信息逐个钉上批注你按批注逐条处理比肉眼翻快得多。发文之前用它过一遍待贴样例是个低成本的好习惯。三、正式外发用脱密三件套别用手工替换手工替换容易漏也容易把文档结构改坏。察元提供了完整的脱密链路declassify_preview 只做预览、不写盘先看脱密效果确认没问题再走 declassify_apply它需要 confirm、password 和 keywords 三项齐备才会落盘万一脱过头declassify_restore 可以恢复。给外部协作者的样例文档建议一律走这条链而不是在正文里手动打码。密码与关键词分开传口头给别一起躺在聊天记录里。四、内网信息一律打码内部系统域名、服务器主机名、真实用户名、部门全称这些单独看都不算密钥拼起来就是一份内网侦察情报。发帖时替换成 example.internal、用户甲、某科室。端口 62588 这类公开架构事实可以讲但你们内网怎么部署的拓扑别讲。五、截图先看边框排错截图最容易漏的是边框WPS 标题栏上的文档名往往带着项目名或客户名任务栏里还躺着其他业务系统。截图前把无关窗口关掉标题栏打码或者干脆用文本日志代替截图。文本还有个好处外发前能先跑一遍第一条的密钥扫描肉眼扫不动的交给命令。六、最小化复现样例贴给别人的复现样例删掉业务正文只保留结构几段占位文字、一个表格、一个触发报错的提示词。别人要的是复现路径不是你的稿子内容。样例越小帮你的人越多泄露面也越小。七、分清可以公开讲和不该公开讲这条是正面清单服务地址 http://127.0.0.1:62588/mcp、healthz 返回 online、只监听本机回环、无需 Token、46 个 MCP 工具、Apache-2.0 开源——这些是产品公开事实讲出来无妨而且只监听 127.0.0.1 这一点本身就是安全设计值得宣传。不该讲的是你的部署细节、密钥、文档内容。一句话讲架构不讲数据提示词也算数据——把内部人名、项目代号、客户简称写进提示词再截图外发等于把业务地图送人。八、记住工具的边界保密检查助手能给密级标识、涉军涉装、单位身份、联系方式、项目编号、商业秘密分级这类风险提示脱密工具能把关键词处理干净但它们都是辅助参考不替代人工定密。拿不准密级的文档走单位的定密流程别让 AI 替你签字画押。写在最后数据安全不出域这个话题2026 年越炒越热但真正的安全不只在采购选型那一关更在每一次复制粘贴。排错求助前花两分钟过一遍这八条帮你的和不帮你的都会舒服很多。纪律这东西出事一次就要还债一年。