键盘替你把话说完了：改写型输入的还原、边界与责任
一、补错字与补语气不是同一类风险
输入预测这件事往前走了一步：从补词到了按意图把一句话补完。这类能力在传播里常被描述成“打字进入按意图补全表达的阶段”。厂商、价格与效果数据都不在本篇讨论范围，值得单独写的是责任结构的变化。
拼写与词序的错，属于形式错。它错得很显眼：读一遍就能看见，改动一次就能修正，错了也没人会把错的内容当真。语义改写的错不一样，它错在意思上，而意思错的内容在形式上是通顺的、得体的、看起来像本人会说的话。这类文本一旦上屏，用户很难在读的时候停下来，因为它读起来没有毛病。发出去之后才发现“我不是这个意思”，责任却已经落在发送者身上，键盘不会为此承担任何后果。
所以做这类能力时的第一原则不是“改得更准”，而是把权限分档、把还原留住、把不该改的句子标出来。三件事都在设计阶段能决定，出事之后再决定就来不及了。
二、核心交付物表：三档改写权限与对应的确认强度
| 改写档位 | 改动范围 | 确认强度 | 还原方式 | 禁改场景 |
|---|---|---|---|---|
| 补词 | 光标处的词或短语，不改已有内容 | 候选列出，接受才上屏；可自动上屏但必须留一键撤销 | 撤销回到原光标位置与原输入 | 无，形式改动可逆 |
| 句内表达改写 | 替换句中若干词或整句语气，句子数量不变 | 需按键确认，不允许与发送键共享同一操作 | 保留改写前文本，可一键回到该版本 | 含时间承诺、金额、数量、责任归属的句子 |
| 整段重写 | 增删句子、改变信息顺序与立场表达 | 需显式预览，确认后才替换，且默认不进入发送流程 | 原文与改写版本各自留存，发送时记录用的是哪一版 | 拒绝、报价、工期承诺、承认过错、亲密关系表达 |
这张表的读法在最后一列。确认强度是产品自己的选择，禁改场景则由内容性质决定：越是“说出去就收不回来”的句子，越不该由一次按键接受来触发。
补词档可以激进，因为它改变的形式。句内改写档必须保守，理由很具体：用户在这一步的注意力在“要不要发”，不在“意思变没变”。整段重写档应该默认关闭或默认预览，因为它的产出已经不能被当作“用户输入”，而是一次代笔。
三、原文可追溯要能做到三层
第一层，改写前的文本要留下。文本框里的内容被替换时，旧版本进一条会话内历史，而不是直接丢弃。技术上不难，难在很多人把它当作临时缓冲区，发送即清理。
第二层，一键还原要存在于发送之前。还原的入口要在改写发生的那个位置出现，不能藏到菜单里；提示的存续时间要短到不打扰，又要长到用户有时间看清它是什么。这条是体验问题，更是责任问题：能还原，说明改动是可选的。
第三层，发送之后还能查看当时用了哪一版。这一层最少被实现，却最关键。一句已经发出去的话，如果双方都不确定当时是本人写的还是机器补的，争论就没有依据。可行的做法是把“该消息是否经过改写、改写来自哪一档、用户是否确认过”作为消息元数据或本地记录留下；在企业系统里，这几项应该进审计而不是留在客户端。
三层缺一层，“还原”就只是文案。
四、哪些句子不该被自动改写
错改成本最高的场景相当集中。工期承诺，一句“下周五给你”被改成“我们会尽快”或反过来被改成更明确的日期，都是事故。拒绝，被改软之后拒绝不再成立，对方会把沉默当默认。报价与金额，任何数值附近的语气改动都可能变成承诺。责任归属，“我这边确认过”与“可能需要再核实”之间差的是一整段后果。亲密关系表达则最敏感，也更不该由产品判断，本篇不讨论表达方式本身，只讨论一件事：这类句子该由规则拦住，而不是由用户谨慎拦住。
拦得住的办法是把判定做成可枚举的规则，而不是模型自觉。可执行的三条：句中出现明确日期、金额、数量或承诺动词时，改写结果只能预览不能自动上屏；句子处于负向表达（拒绝、更正、道歉）时，禁止语气软化；被判定为对外承诺类会话（客户、供应商、合同相关联系人）时，整段重写档位强制不可用。这三条要能被产品负责人读出、能被测试覆盖，否则它们只是文档里的一句话。
还要给用户留一个显式入口：把当前会话标记为“不要改写”。这个开关的存在，比任何一条内部规则都更容易被信任。
五、上下文的隐私边界要写在启用那一刻
补语气要读上下文，这是能力的前提，也是风险所在。要回答清楚的不是“会不会读”，而是四件可核对的事：读了哪些范围（当前会话、历史消息、还是可见的文档），送到了哪里（本地还是云端），留存多久（请求结束后是否立即丢弃、日志里保留了什么），以及能不能关掉（在企业设备上能否由管理策略整片禁用）。
这四件事应该在首次启用时以用户能读懂的形式给出一次，而不是藏在隐私政策里。企业侧还要多一条：员工使用的输入能力属于终端软件的一部分，需要能被集中配置与审计，因为改写发生在员工的对外消息上，责任却归公司。把“哪些会话禁改”做成可下发策略，比培训更有效。
一个具体的判断线：只要改写会读取会话历史，就要考虑对方消息也被一并处理的情形。这不是设置项能解决的，需要明确说明读取范围。
六、学习回路与企业场景的验收清单
用户撤销和拒绝改写，是这套系统里质量最高的负样本，价值高于“接受了哪一版”。因为接受可能只是懒得看，而撤销说明读过了并且不同意。所以反馈回路里要给这两类动作更高权重，并把它们按改写档位、句子类型与场景分开统计，而不是笼统算一个采纳率。同时要把“错改导致的最贵后果”单独建类目：承诺被改动、拒绝被软化、数值被改写，这三类要单列指标，任何一次发生都值得人工看原文。
做进企业产品（客服回复、工单填写、报告批注）时，验收项建议照这几条列：
- 还原可核对：任一被改写的文本都能取到原始版本，两者都被留存
- 错误率按业务分类统计，承诺类与金额类单独看，不与整体采纳率混在一起
- 承诺类字段禁改，工期、金额、责任归属由规则拦截而不是提示词约束
- 审计能区分人写的与机器改的，并记录用户是否确认过改写
- 关闭开关存在且有效，可按角色或按会话下发
- 上下文读取范围在界面上可见，处理时限可被说明
洹拓科技在把这类能力放进交付物时，会先问一句“能不能证明这句话最后是谁写的”。答得出，再谈效果；答不出，这个能力在企业场景里就只能当草稿工具用。责任的边界从来不在模型的把握里，在产品有没有把还原、禁改和留痕这三件事做出来。