用文字提出修改很容易想象，却很难安全地做到，因为最省事的做法是让模型触碰文件。在这里，请求变成一份规范，由引擎来写入。
请求变成规范
模型负责理解；引擎负责写入
你说出应该改什么：一个过时的数字、一个章节标题、一个有两种写法的术语。对话产出的不是文件，而是一份描述：改什么、在哪些元素上、针对哪个版本。引擎执行它，改动这些元素，并逐一记录它改动的每个元素。为什么这两层是分开的，见对话是与人工智能的对话。
编辑继承了拒绝
引擎无法解析的请求会失败，而不是被猜测
如果模型误解了你，结果是一份你可以阅读并拒绝的错误规范，而不是一份被悄悄损坏的文档。翻译已经是这样运作的：片段经过分隔后发出，返回的计数与发出的计数进行比较，不一致则该步骤失败（差异）。编辑继承同样的规则：无法解析到具体元素的请求必须失败。
今天存在什么，以及缺口
接收描述式修改的门已经存在并且会拒绝；从你的句子通往它的路径还不存在
自 2026-07-30 起，代理有四个逐个元素组装修改的操作：列出可编辑的内容、打开草稿、发送每一行（元素、段落、内容类型、文本），以及执行。标题、正文和表格单元格接受写入；图像、字段、图表标签、评论和几何形状被锁定，指向它们的行会失败。不再可编辑的草稿会失败。空的配方会失败。
缺口在于：你必须用每个元素的内部身份来指明它，而这需要先从地图中读取。尚未构建的是从你的句子到那一行的步骤。因此你还不能用自然语言提出修改。完整的操作集见能力；门见接口。
今天的进展
一个方向，缺口已指明
屏幕有它自己的缺口，见网页编辑器。新文档由什么组装而成，见与人工智能的共同创作。
状态，已注明日期。于 2026-09-02 在开发环境中测量，而不是在生产环境中。上述四个操作是从产品本身读取的，对锁定元素的拒绝已内置其中。没有找到任何操作能接收你用自己的话提出的请求，并解析出它指的是哪个元素。写入步骤已列在引擎的步骤之中，其执行日志在所有四种格式中都是空的。
为什么没有数字。这项能力有书面决策，但还没有外部人员可以重复的测量。
无论是提出的、执行的还是拒绝的，都会留有记录：这就是第五个动词，信任。