<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>工具 on Seunghoon Choi</title><link>https://seunghoonchoi.com/zh/tags/%E5%B7%A5%E5%85%B7/</link><description>Recent content in 工具 on Seunghoon Choi</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Tue, 16 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://seunghoonchoi.com/zh/tags/%E5%B7%A5%E5%85%B7/index.xml" rel="self" type="application/rss+xml"/><item><title>AI 结果审核的陷阱：别为了抓错误，降低结果的上限</title><link>https://seunghoonchoi.com/zh/column/dont-lobotomize-the-model/</link><pubDate>Tue, 16 Jun 2026 00:00:00 +0000</pubDate><guid>https://seunghoonchoi.com/zh/column/dont-lobotomize-the-model/</guid><description>&lt;p&gt;&lt;img src="https://seunghoonchoi.com/images/col-qa.jpg" alt="A magnifying glass beside a laptop"&gt;&lt;/p&gt;
&lt;p class="inline-image-caption"&gt;检查不是减少产量的任务，而是发现并纠正实际错误的任务。&lt;/p&gt;
&lt;p&gt;文字超出了幻灯片边界。直到发送前一刻，我才看见。 Excel 里还留着 &lt;code&gt;#REF!&lt;/code&gt; 错误，表格边框有的单元格有、有的没有。Word 文档里，本该删掉的 Markdown 符号还原样留着。这不是审美问题，而是结果坏掉了。 AI 生成的 Office 文件常有这类失误。所以审核工具是需要的。问题在于，审核工具应该介入到哪里。&lt;/p&gt;
&lt;h2 id="审核是抬高下限"&gt;审核是抬高下限&lt;/h2&gt;
&lt;p&gt;审核工具该做的事，是抬高结果的下限。跑出幻灯片的文字、坏掉的公式、未替换的占位符、文档里残留的 Markdown，这些不管给谁看都是问题，应该被检测出来。 这类错误越早抓越好。靠人最后肉眼找，太细碎；原样交出去，又太致命。如果文件由 AI 生成，就需要一个自动回头检查 AI 明显漏掉缺陷的装置。 但这里很容易越线。一个为抓错误而做的工具，某个瞬间会开始强制风格。&lt;/p&gt;
&lt;h2 id="把风格当错误会降低上限"&gt;把风格当错误，会降低上限&lt;/h2&gt;
&lt;p&gt;有些审核工具会把字体数量、项目符号数量、字数、边距、颜色、信息密度都当成唯一正解。“幻灯片只能用两种字体”，“项目符号不能超过六条”，诸如此类。 这些规则有时有用，但不是永远正确。技术文档、投资报告、讲义、一页式演示，没理由都用同一种密度和样子。 如果把这些规则做成绝对标准，就会出现奇怪的事：模型即使做出了更好的结果，也会因为不像过去的标准答案而被扣分。那审核工具就不再是抬高结果下限的装置，而成了降低结果上限的装置。&lt;/p&gt;
&lt;h2 id="区分错误和选择的问题"&gt;区分错误和选择的问题&lt;/h2&gt;
&lt;p&gt;加入检查项之前，应该先问两个问题。 第一，即使用户意图或偏好不同，它是否几乎总是缺陷。 例如坏掉的 &lt;code&gt;#REF!&lt;/code&gt; 公式、被推到幻灯片外的图形、未解决的占位符，通常没有理由原样交付。 第二，更强的模型也会想避免这个问题吗。 如果更好的结果有可能故意违反某条规则，就不要把它断定为错误。信息密度、配色、字体数量、边距、句子长度，都属于这里。&lt;/p&gt;
&lt;p&gt;核心很简单：更强的模型也会想避开的失败，审核工具应该挡住。更强的模型也可能有意选择的表达，审核工具就不该挡住。&lt;/p&gt;
&lt;p&gt;&lt;img src="https://seunghoonchoi.com/images/inline/column-dont-lobotomize-the-model.jpg" alt="AI 结果审核的陷阱：别为了抓错误，降低结果的上限"&gt;&lt;/p&gt;
&lt;p class="inline-image-caption"&gt;好的检查工具不应抹掉模型的创造性尝试，而应只找出真正有缺陷的输出。&lt;/p&gt;
&lt;h2 id="不是所有问题都能黑白分明"&gt;不是所有问题都能黑白分明&lt;/h2&gt;
&lt;p&gt;真实文件审核里，判断不会总是干净分开。文本框重叠、文字溢出、字号过小、图片比例变化，很可能是缺陷，但也可能是有意表现。 所以审核结果要分级。确定的结构性缺陷标成 &lt;code&gt;ERROR&lt;/code&gt;。需要再用眼睛确认的项目放成 &lt;code&gt;WARN&lt;/code&gt;。 &lt;code&gt;WARN&lt;/code&gt; 不是定罪，而是确认请求。没有这个区分，工具要么太弱，要么太粗暴。&lt;/p&gt;
&lt;h2 id="自动检查不能替代最后判断"&gt;自动检查不能替代最后判断&lt;/h2&gt;
&lt;p&gt;AI 生成 Office 文件时，很多缺陷来自它看不到最终结果。模型写入坐标和单元格值，但可能没有充分确认最终渲染画面，也可能没有正确反映用户刚修改过的最新文件状态。 所以自动检查是必要的。生成后应该重新读取文件，检测可测量的缺陷。公式错误、画布越界、残留 Markdown 这类问题，应该在最后由人发现前先由机器过滤。 但自动检查不能替代最后判断。语境、意图、读者、发表场景，不能只看一个文件就完全知道。好的审核工具必须清楚自己确切知道的范围。&lt;/p&gt;
&lt;h2 id="我为什么做-office-file-inspector"&gt;我为什么做 Office File Inspector&lt;/h2&gt;
&lt;p&gt;基于这些原则，我整理了 Office File Inspector。这是一个开源工具，用来在 AI 生成的 PowerPoint、Excel、Word 文件中寻找明确缺陷。 目标不是把结果物做成一种模样，而是早点挡住明确失败，把更好选择的余地留给模型和人。 审核工具不能变成削弱模型可能性的工具。好的审核抬高下限，不压低上限。&lt;/p&gt;</description></item></channel></rss>