AI 改稿逐处确认
写作者让 AI 润色定稿时，只接收逐处可批准的文字补丁，避免全文被无声改写或混入隐藏字符。
写作者把接近定稿的文章交给 AI 润色时，通常只想借几个更好的措辞，却担心整段文字被悄悄换掉。尤其是合同、投稿和公开声明，作者需要知道最后留下的每个改动来自哪里。
编辑器插件只读取用户框选的段落，并要求模型以补丁形式返回建议。原文和建议稿并排显示，删除、替换和新增内容按块标色。作者可以接受一句、拒绝一句，或手动改完再继续请求下一处建议，AI 无法直接覆盖整篇文稿。
每次接受后，插件会扫描不可见 Unicode 字符、异常格式和复制时混入的控制符。修改记录保留原句、接受时间与最终文本，导出时还能生成一份干净版本。编辑或法务复核时，作者能逐处说明哪些文字由自己确认过。
早期版本先做浏览器写作场景与常见文档编辑器的补丁面板，支持润色、压缩和改语气三类请求。它不替作者判断事实，不代替协作审批，只把 AI 改稿收束为一连串可见、可撤销的文字选择。
为什么是现在
8月16日，一篇文章质疑 Claude 文本水印会介入措辞选择，使润色后的文字归属成为具体担忧。S2 截至8月17日0时33分，该帖位列第10，记录为121 points和99 comments。S1
目标用户
核心用户是准备提交合同、稿件或公开声明的人。此时文章已接近定稿，事实与立场通常不容重排。他们只想借 AI 调整少量措辞，却必须确认每个字是否仍符合原意。编辑、法务和客户追问改动来源时，还需要拿出逐处批准记录，而不是一份无法解释的整段终稿。
最小切入点
浏览器插件先读取当前选区，并保存原文哈希。模型必须返回结构化补丁，包含定位片段、替换文本和简短理由。前端用文本差分把补丁拆成可独立批准的句块。写入前再次核对选区与哈希，避免文档变化造成错位。控制符扫描独立运行，只报告真实码点与格式异常。首版先覆盖普通网页编辑框，再接入 Word 修订接口。Google Docs 的写入建议接口仍在开发者预览，可作为后续适配。S3S4
以小博大
第一批用户可直接来自此次 Hacker News 讨论中的写作者与开发者。S1 做一个无需登录的选区差分演示，让用户当场看到整段重写被拆成哪些选择。插件商店页面重点展示合同条款和公开声明的前后对照。再用匿名化的改动样例发布技术文章，解释哪些字符被清理，哪些水印无法检测。
竞品与缝隙
怎么赚钱
按席位提供月度订阅。免费版保留基础逐句确认与本地撤销。付费版提供跨文档历史、审计导出和团队策略。模型费用可由用户自带密钥承担，避免订阅被推理成本吞噬。
反方视角
不可见字符扫描很容易被误解为水印检测。Claude 所述方案不加入隐藏字符，而是通过词语选择留下统计信号。S2 因此清理控制符只能解决复制污染，无法验证或移除这类水印。富文本中的脚注、链接和批注会让补丁定位变得脆弱。选区变化后写错位置，可能直接损坏合同或声明。模型也可能漏报改动，结构化返回并不等于内容可信。保存原句与接受时间还会积累敏感文本，带来加密、留存和删除成本。若无法把“字符卫生”与“水印判断”讲清，用户会迅速失去信任。