Humanly：一个可配置且可追溯的人机协作写作环境

# 一个可配置且可追溯的人机协作写作环境
来源：https://arxiv.org/html/2607.21758
沈哲竹1，2,\*，张昊谦2,\*，杨旭1,\*，唐靖宇1，念逸5，杜晓雪4，杨澍6，Alex Pentland3，4，Joachim Baumann3，裴佳鑫1，3，†\{\\dagger\} 1UT Austin 2多伦多大学 3斯坦福大学 4MIT 5USC 6KAUST \*同等贡献 †\{\\dagger\}通讯作者 https://writehumanly.net/ https://github.com/Humanly-Lab/humanly shenzhe@utexas\.edu; jiaxinpei@utexas\.edu

###### 摘要

教师、会议主席和普通读者都只能根据有限的证据来评判写作，他们看到的仅是成品文档，而非其产生过程。仅凭最终文本无法揭示文档是通过人工打字、AI生成，还是人机混合协作完成的。现有的过程追踪工具有所帮助，但许多工具依赖于宿主文档的历史记录，提供粗略的活动记录，并且对写作环境的控制能力有限。Humanly是一个写作平台，它将写作过程本身作为证据。用户可为个人文档或指派任务配置写作环境，并在工作区中进行草稿撰写，该工作区会记录写作活动及平台内的AI辅助操作。Humanly可以将完成的会话打包成一个密封的写作证书，并支持基于配置的异常行为审查。它可以支持课程作业、同行评审和个人认证等写作场景。我们的用户研究表明，Humanly在各角色中都很有帮助；一项红队研究表明，Humanly打字检测器能够区分人工打字和自动打字。

参见图注图1：Humanly概览。所有者配置创作模式和写作策略；作者在允许的控制下进行写作，同时Humanly记录会话；后端提供AI响应，协调启用的检测器进行异常行为审查，并颁发包含日志、回放和检测结果的密封证书，供验证者检查。## 1 引言

写作真实性已成为一个实际问题，尤其是在仅凭最终文档做决策的场景中。讲师收到学生提交的作业文档，需要判断学生是否遵守了课程关于AI使用的规定；会议主席可能需要检查审稿人是否使用了AI；普通读者可能会质疑社交媒体帖子是由人还是AI撰写的。在这些情况下，最终文本是可见的，但其背后的过程却不可见。我们将写作真实性定义为：文档的制作历史是否符合其作者身份和AI使用声明——谁写了什么，使用了哪些工具，在何种规则下。随着人机协作写作从边缘案例转变为常规实践，这个问题变得更加困难。作者使用AI进行编辑、翻译、理解来源、头脑风暴和重写。这些工作流程并不等同于让AI模型直接生成最终文本。

事后检测器仅对最终文本进行分类，而不观察其制作过程，因此对写作过程一无所知。它们可能将非母语英语写作误分类为AI生成的(Liang et al., 2023)，在翻译和混淆下产生不一致的错误(Weber-Wulff et al., 2023)，并且在释义或简单文本操作下失去可靠性(Sadasivan et al., 2025; Perkins et al., 2024)。水印技术也仅限于支持水印的生成，而不适用于任意混合的人机工作流(Kirchenbauer et al., 2023)。这些发现表明，为什么仅凭检测器得分作为混合写作政策决策的证据是远远不够的。事后检测器只能估计最终文本是否看起来是AI生成的；它无法区分符合政策的润色或人类草稿的翻译，与实质性的AI生成随后经人类编辑的区别。表1 (https://arxiv.org/html/2607.21758#S1.T1) 总结了四种具有不同政策含义的此类历史记录。

表 1：事后检测无法可靠识别的写作过程。过程追踪工具提供了比最终文本检测器更相关的证据，因为它们记录了写作过程的部分内容。版本历史回放和作者报告产品（表2 (https://arxiv.org/html/2607.21758#S2.T2)）可以显示文本随时间出现，或者某些文本是键入、粘贴或AI辅助的。然而，仍然存在重要的实际差距。许多面向回放的工具依赖于宿主文档或表单环境，例如Google Docs，因此过程记录通常很粗糙：键入和粘贴的文本可能可见，但工作区活动、详细的AI辅助和异常模式通常缺失或仅部分呈现。这些宿主环境也限制了可配置性：任务所有者并不总是能够在AI、资源、时间、长度控制等方面定义写作环境本身。其他系统将过程追踪作为与AI检测或写作辅助分离的独立产品呈现，而不是连接在一个写作工作流中。

我们引入了Humanly (https://writehumanly.net/)，一个结合了可配置写作环境、细粒度活动日志和证书的写作平台，使写作过程可以端到端地审查（图1 (https://arxiv.org/html/2607.21758#S0.F1)）。Humanly支持三种系统角色。所有者创建个人文档或为他人发布任务；作者在工作区中撰写，同时Humanly记录写作活动；验证者检查密封的写作证书作为支持证据。Humanly围绕四个目标设计。第一个是**灵活性**。Humanly不强制使用单一的默认写作策略；所有者通过14个设置系列配置写作环境，涵盖AI政策、资源、预算、约束、异常行为审查和访问权限。第二个是**可问责性**。Humanly使写作过程可检查，而不取代人类判断。活动日志和作者统计数据显示最终文本是如何由键入、粘贴和AI辅助的过程组件组成的，而异常行为审查可以结合启用的异常模式信号和Humanly打字检测器来评估自动打字风险。例如，电脑使用代理（CUA）可以通过图形或命令行操作用户界面来代表用户操作软件。¹¹¹示例包括OpenAI Codex computer use (https://developers.openai.com/codex/app/computer-use) 和 Claude Code computer use (https://code.claude.com/docs/en/computer-use)。第三个是**可验证性**。证据应由平台发布，而非由作者断言。Humanly将会话证据和环境设置存储在证书中。Ed25519签名保护选定的证书字段，以便查看者检测外部修改。第四个是**兼容性**。Humanly构建用于支持多种部署模式：相同的溯源模型支持指派任务和个人文档、邀请码和公开链接分发、登录和访客写作，以及MIT许可的自部署。

## 2 系统架构与部署

Humanly是一个TypeScript单体仓库，其共享模式连接了写作环境配置、事件接收、AI服务、证书生成、检测器编排和存储（图1 (https://arxiv.org/html/2607.21758#S0.F1)）。我们将机器可读的后端记录称为**事件**，将其人类可读的日志条目称为**活动**。

**运行时与存储。** 第一方客户端和可嵌入追踪器连接到Express + Socket.IO后端。经过身份验证的API服务于第一方产品工作流，而一个开放的CORS路由则接收外部追踪器事件。PostgreSQL存储产品记录，TimescaleDB超表存储高频的原生编辑器和追踪器事件，Redis支持缓存和速率限制，资源使用本地或云存储。

**任务与环境服务。** 任务服务存储每个个人文档或指派任务的活跃写作环境，涵盖AI、资源、写作约束、检测器和访问权限。AI和证书服务解析此保存的记录，以便后续的辅助和审查使用相同的策略。路由守卫在写入前强制执行所有权、参与资格以及链接或访客资格。

**事件接收与AI服务。** 原生编辑器事件进入`document_events`，而外部追踪器事件使用批量接收路由。在提供者分发之前，AI服务解析保存的环境，检查聊天或润色功能的可用性，选择提供者/模型，并应用令牌预算。响应通过Socket.IO流式传输，同时AI会话、快速操作决策和政策拒绝被持久化以便后续审查。

**证书服务与异常检测器。** 在颁发时，证书服务冻结会话边界，计算作者统计数据和检测器结果，并存储环境快照和验证令牌；日志和回放针对同一边界提供服务。该服务读取保存的检测器配置，因此禁用的检测器保持明确显示。异常模式(Anomaly Pattern)从记录的事件和政策条件中推导出五个基于统计的信号。Humanly打字检测器将会话事件发送给一个LightGBM推理服务(Ke et al., 2017)，该服务根据击键节奏和编辑行为估计自动打字概率，并返回基于SHAP的贡献特征(Lundberg and Lee, 2017)。时序数据不足会产生不确定的结果。Ed25519签名保护证书字段，包括检测器结果（如有），后端端点公开公钥。

**部署。** 对于本地自托管，Humanly提供了一行引导命令：`curl -fsSL https://writehumanly.net/install.sh | sh`。该安装程序准备Docker/Compose、源代码检出、本地密钥、存储和管理员账户，然后启动数据库、缓存、后端和门户。生产部署需替换本地URL、电子邮件和存储设置。

参见图注

(a) 写作环境配置

参见图注

(b) 追踪的工作区

参见图注

(c) 活动日志

参见图注

(d) 证书

图 2: Humanly 界面：(a) 写作环境配置；(b) 完整模式下的追踪工作区，包含 PDF 资源、编辑器和 AI 助手；(c) 活动日志；(d) 包含作者统计数据和签名的证书。

| 领域 | 特性 | Humanly | Turnitin | Grammarly | GPTZero | Draftback | Brisk | Integrito | PaperTrail |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **写作环境** | 可配置规则 | ✓ | | ✓ | | | | | |
| | 任务分配 | ✓ | | ✓ | | | | | |
| | AI 策略 | ✓ | | ✓ | | | | | |
| | 开源 | ✓ | | | | | | | |
| **活动日志** | 文本编辑 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| | 剪贴板 | ✓ | | | ✓ | ✓ | ✓ | ✓ | ✓ |
| | 工作区状态 | ✓ | | | | | | | |
| | AI 辅助 | ✓ | | ✓ | ✓ | | | | |
| | 异常模式 | ✓ | | ✓ | ✓ | ✓ | ✓ | | |
| **证书** | 回放 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| | 作者统计 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| | 打字检测器 | ✓ | | | | | | | |
| | 完整性封条 | ✓ | | | | | | | |

表 2：写作真实性系统在写作环境、活动日志和证书方面的功能比较。竞品列指的是链接的产品文档；✓表示支持，空白单元格表示在公开文档中未找到。可配置规则 = 所有者设置的环境约束；AI策略 = 可见的AI使用模式和防护规则；工作区状态 = 焦点、选择或工作区离开/返回事件；异常模式 = 基于日志事件和活动策略推导的统计异常行为模式；打字检测器 = 估计键入输入是类似于人工打字还是自动打字；完整性封条 = 可凭Humanly公钥验证的Ed25519证书签名。

## 3 工作流程与用例

### 3.1 工作流程设计

图1 (https://arxiv.org/html/2607.21758#S0.F1)围绕三个角色组织工作流程：所有者(Owner)、作者(Writer)和验证者(Verifier)。这些不是固定的账户类型：指派任务可能将这些角色分配给不同用户，而个人文档可能将所有者与作者角色合并。图2 (https://arxiv.org/html/2607.21758#S2.F2)展示了从设置到撰写再到证书审查的相应界面。

**所有者。** 所有者角色始于用户创建写作环境。个人文档所有者在作者门户 (https://app.writehumanly.net/) 中配置私有文档；指派任务所有者在发布者门户 (https://admin.writehumanly.net/) 中配置共享任务，并通过邀请码或公开链接进行分发。通过这两种路径，所有者配置14个设置系列，包括资源、约束、访问权限、四种AI模式（关闭、仅润色、仅聊天、完整），以及两个用于异常行为审查的检测器：异常模式和Humanly打字检测器。附录C (https://arxiv.org/html/2607.21758#A3) 中的表5 (https://arxiv.org/html/2607.21758#A3.T5) 总结了设置选项。Humanly将此配置与会话一起保存，因此证书可以根据写作期间生效的规则进行解释。

**作者。** 作者角色始于用户进入配置好的工作区，无论是通过自己的个人文档，还是通过其他所有者共享的指派任务。在起草之前，作者会看到任务说明和所有者设置的写作规则。在启用完整模式和源资源的情况下，工作区呈现三个面板：源PDF或资源、编辑器以及AI助手。作者可以使用聊天功能询问关于提供资源的问题，并在起草过程中对选定文本应用四种AI快速操作。活动日志公开了27种可审查的活动标签，涵盖文本编辑、剪贴板活动、工作区状态、AI辅助和异常模式。附录C (https://arxiv.org/html/2607.21758#A3) 中的表6 (https://arxiv.org/html/2607.21758#A3.T6) 按类别统计了这些标签。写作完成后，作者提交任务或从记录的会话中生成证书。

**验证者。** 证书审查在颁发后开始。对于指派任务，提交后即颁发；对于个人文档，作者在完成文档后生成证书。验证者可以是原始作者、任务所有者，或任何持有共享验证链接的公开读者。证书证据包括作者统计数据、环境设置、活动日志、回放、针对该写作环境配置的异常行为审查，以及Ed25519完整性封条。作者统计摘要显示最终文本的构成和过程输入量；环境设置保留了写作期间生效的策略；活动日志呈现记录的活动；回放显示文档随时间的变化。当两个检测器都启用时，异常行为审查包括异常模式信号和Humanly打字检测器分数；禁用的检测器会显示为未启用。完整性封条使用Ed25519对选定的证书字段进行签名，使验证