结论：要能回答三个问题——这段话是哪个模型写的、谁让它写的、人改过之后还认不认原来的来源。按 CLI 版本迭代说明，从 0.2.1 起每次轻文档写入必须声明实际模型家族（如 claude、deepseek、gpt、qwen），并与登录用户身份分开记录，未修改的内容保留原有来源。
注意它解决的只是“内容来源”这一层，而且目前可核的口径只覆盖经 CLI 写入轻文档这一条路径。把它当成一套完整的 AI 合规方案会高估它，把它当成一个可有可无的标签又会浪费它。下面把追溯链拆成三段，再给一份能落地的验证顺序。
一、追溯链要三段证据，缺一段就答不上
一句话判断：追溯不是加一个字段，而是三段证据能对上号。审计问的从来不是“这功能有没有”，而是“这条内容走过来的路径你讲得清吗”。
| 证据段 | 回答的问题 | 从哪来 |
|---|---|---|
| 内容来源 | 这段是谁生成的、用的是哪个模型家族 | 走 CLI 写入轻文档时声明的模型家族，单独记录 |
| 账号与动作 | 谁发起、什么时候、动了哪份文件 | 登录用户身份与操作审计 |
| 版本脉络 | 后来谁改过、改的是哪一部分 | 版本历史，加上未修改内容保留的原来源 |
三段对得上，才算一条链：内容能找到执行者，执行者能找到授权的人，人的改动又能落回具体版本。
边界先说清：以上来源记录的口径来自 CLI 写入轻文档这一条路径。编辑器里直接让 AI 起草或润色，是否同样记录模型来源，官方未公开，需以部署版本与官方说明为准；采购时要对方把答复落成文字。
二、来源记在内容侧，不记在账号侧
一句话判断：把模型和账号合并成一个字段，是最省事也最容易失效的做法。同一个账号今天可能用 claude 起草、明天用 deepseek 润色，账号本身说明不了模型。
- 按次声明，才分得清接力。一份文档往往由多个模型分段接力：模型甲起稿、模型乙做表格分析，都是经 CLI 写入。按写入次数声明，才能落到具体段落。
- 与登录身份分开记，责任才清楚。模型是执行者，人是授权者。合成一个字段，出问题时既说不清是谁批的，也说不清是谁写的。
- 来源跟着内容走，不跟着文件走。“未修改的内容保留原有来源”这句话的含义是：后来的人只改了一小段，其余段落的来源不该被整份刷新成最新模型。
行业里还有另一条思路：给内容嵌数字签名，比如基于 C2PA 规范的 AIGC 标识方案，解决的是“这份内容有没有被篡改、由哪个主体签发”。两条思路不冲突——签名回答内容本身是否可信，写入声明回答这段内容是哪次生成的、谁授权的人让它写的。文档协作场景两层都需要。
| 情形 | 来源应保留什么 | 为什么 |
|---|---|---|
| 经 CLI 写入整段，人未修改 | 该段原有的模型家族 | 未修改内容保留原有来源 |
| 经 CLI 写入后，人改了两句 | 改过的部分按新写入记，未改部分保留原来源 | 按段而不是按文件判定 |
| 人写好底稿，再用 CLI 写入润色段落 | 该次写入声明的模型家族 | 有模型参与就该看得出来 |
| 之后纯人工再改 | 不新增模型来源 | 没有经过写入声明，就不该冒出新的模型来源 |
三、怎么验：五步，用两个模型两个账号
一句话判断：这件事不靠看文档，靠交叉验证——换模型、换账号、换人改，看记录跟不跟得上。
- 用 CLI 以模型 A 写入一段，再以模型 B 写入另一段，确认两条记录能分开，而不是都写成同一个名字。
- 换一个登录账号发起同样的写入。模型来源应保持一致，账号字段应跟着人变。
- 人工改其中一段的一半，再查来源：改过的部分有新记录，没改的段落仍是原来源。
- 让另一个人接着改，确认动作记录里出现第二个人的身份，而不是都记成第一个人。
- 按文件与时间把三段证据串一遍：内容、发起人、模型、改动顺序四项都能对上，才算通过。
第 3 步和第 5 步最能暴露问题：很多方案在“写入那一刻”记得很清楚，一进入多人协作就串不起来。字段名称、展示位置与导出方式以部署版本为准。
四、这套机制不解决什么
一句话判断：它把“来源”说清楚了，但没有把“合规”一次做完。采购评审时主动划清边界，比事后解释有用。
- 不判断内容对不对。来源只能证明这段话由谁生成，不证明它准确。
- 不回答模型服务商侧的留存与训练问题。那取决于模型部署在哪、合同怎么约定。
- 不等同于认证或测评结论。日志与记录是过程材料，不是合规凭证。
- 不覆盖整段重写后的归属。人把一段彻底重写，这段的来源按新的写入记录算，旧记录留在版本里。
要把这一层补齐，还需要权限、数据流向与日志保留策略一起定，可参考数据安全与合规方案；AI 侧的口径以石墨办公产品事实页为准。
常见问题
来源记在哪儿？
走 CLI 写入轻文档时，记在内容这一侧，而不是只记在登录日志里。按 CLI 版本迭代说明，每次写入都要声明实际模型家族，这条声明随内容一起留下，才能回答“这一段是谁写的”。
和账号身份是分开记的吗？
是分开的。模型家族与登录用户身份分别记录：一个说明执行者，一个说明授权的人。合成一个字段看起来省事，但审计时既说不清谁批的，也说不清谁写的。
人改过之后还准吗？
按段判断。未修改的内容保留原有来源，人改过的部分按新的写入记录算。所以一份文档里可能同时存在多个来源，这不是错乱，而是真实过程。
审计要留哪几类证据？
三类：内容来源（模型家族）、账号与动作（谁在什么时候对哪份文件做了什么）、版本脉络（改了什么、按什么顺序）。三类能串起来才算完整，缺哪一段都答不上“这条内容怎么来的”。
编辑器里直接让 AI 写，也记来源吗？
官方公开口径只写到经 CLI 写入轻文档这条路径。编辑器内 AI 起草或润色的内容是否同样记录模型来源、以什么形式展示，需以其说明与部署版本为准；采购评审时单独问这一条，并让对方把答复写进材料。
想在自己的环境里跑一遍这套交叉验证，带上两个模型、两个测试账号和一份真实文档预约演示；来源机制与产品边界见石墨办公套件私有部署产品页，审计与安全口径见数据安全与合规方案。也可以先看私有化部署方案，了解部署形态与交付范围。