流萤简历实现AI写文档的细粒度授权机制，设备码+审核链路保障操作可控

当AI开始被允许直接编辑文档，一个看似技术性、实则关乎信任的核心问题浮现：用户如何确认AI“只做被允许的事”？流萤简历在其产品设计中给出了系统性回应——不是简单开放API调用，而是构建了一套覆盖授权发起、范围界定、操作审核与权限校验的闭环机制。这套机制并非理论推演，而是已落地于其AI简历与求职资料工作台的实际交互流程中。

该产品允许用户将特定专题（如某段项目经历）交由AI整理、追加内容或调整页面结构，但前提是完成一次显式授权。关键在于，这一授权并非“一次性授予全部权限”，而是高度结构化的决策过程：用户需明确指定资料范围（根页面）、是否包含后代节点、读写模式（read / review / write）以及有效期限。其中，“review”模式尤为典型——AI可生成修改候选，但必须经用户手动批准后才能生效，审核环节是硬性拦截点，而非提示词中的软性建议。

为支撑这一精细控制，流萤采用设备授权（Device Authorization）协议作为CLI端（命令行工具）与服务端交互的基础框架。其流程如下：终端运行Flowing CLI时，首先向授权服务请求设备码与挑战值（verifier），后者为本地生成的高熵随机字符串，其SHA-256摘要作为challenge发送至服务端；用户随后在浏览器中打开授权链接，登录并确认具体权限范围（如“仅可编辑‘实习经历’页面及其子项，模式为review，有效期2小时”）；浏览器批准后，CLI轮询服务端，提交完整的verifier以完成凭证交换。整个过程中，设备码、识别码与令牌均仅存储摘要，避免明文泄露风险；且单次刷新凭证仅可使用一次，若旧凭证重复提交，系统将直接撤销整个连接，防范重放攻击。

值得注意的是，流萤并未将“复制接入指令”等同于授权本身。该指令仅携带一次性intent，用于预填账号与建议范围，降低用户操作成本，但绝不替代真实会话中的权限确认。这意味着，即使用户将指令文本复制到其他对话环境，也无法绕过浏览器端的身份验证与范围审批环节。这种设计杜绝了因提示词泄露导致长期权限失控的风险。

更深层的保障在于权限的动态校验逻辑。授权时设定的scope（如“可写入A页面及其后代”）仅为上限，实际每次操作仍需实时检查三重条件：

此外，管理员策略、版本控制与额度限制构成第四层过滤。例如，当管理员全局关闭外部写入权限时，所有AI连接的write模式将立即失效；而资料权限解析机制则主动关闭“持链接访问”能力，防止用户撤销邀请后，AI仍可通过旧链接持续访问。

这种多层校验并非过度设计。在文档类应用中，一次误操作可能导致敏感信息外泄或内容被不可逆篡改。流萤将“创建新专题”与“建立AI连接”置于同一数据库事务中，确保二者原子性：要么同时成功，要么全部回滚，避免出现“空专题已创建但连接失败”或“连接已生效但专题不存在”的异常状态。这体现了产品逻辑与工程实现的深度耦合——用户感知的是一次“给AI整理资料”的轻量动作，背后却是身份、内容与权限三者同步建立的严谨过程。

访问令牌的短期化（最长15分钟）进一步压缩了凭证泄露的时间窗口。但系统并未依赖token自有过期机制，而是将连接状态（暂停、撤销、到期）交由数据库实时管理，形成双重保险。轮询机制也经过优化：当响应为authorization_pending或slow_down时，CLI会主动延长等待间隔，而非高频重试冲击服务端。

从行业视角看，当前多数AI文档工具仍停留在“用户输入提示词→AI输出结果→用户决定是否采纳”的粗放模式，缺乏对AI行为边界的显式约束。流萤的实践表明，真正的可控AI协作需回归传统系统安全设计范式：最小权限原则、显式授权、审计追踪与防重放机制缺一不可。尤其在涉及个人简历、求职材料等高敏感场景中，用户需要的不是“AI能写得多好”，而是“我能确信它没越界”。

目前该机制已应用于流萤简历的核心功能链路，其设计细节虽源于单一产品，但所揭示的问题——即AI代理在内容生产场景中的权限边界模糊——具有普遍性。随着更多办公软件集成AI助手，类似细粒度授权模型或将逐步成为行业标配，而非特例。