我让 Claude Opus 5.5 跑整个系统的全项目测试，测试到有一个比较极限的场景有 BUG ，于是我让 Agent 自己提了一个 jira 工单，然后呼叫对应模块的 owner 来解决这个 bug ，但是 owner 告诉我，他看不懂我的工单里是在说什么
于是我查看了一下 Agent 生成的工单，工单写的十分详细，但是根本没有重点，只是把我们做过的实验全部放上去，并且自创了一堆词汇，这些词汇讲道理我在 Claude 内其实能大致看得懂意思，因为我基本上习惯了 Agent 的这种语言习惯，或者说简化词习惯，并且如果我看不懂的话我可以追问我的 Agent ，但是收到工单的 owner 几乎无法理解这份工单里的词汇和表格。
这份工单给人的感觉就是极其精炼的废话连篇，毫无重点，哪怕我和 Agent 重复强调只说我们复现的 bug 的场景和条件，但是不论是他上传上去的 log 还是对场景的描述都是事无巨细并且为了避免篇幅超长而使用极简词汇，导致它生成出来的工单无法被没有上下文的 owner 解读，除非 owner 直接让他那边的 Agent 来阅读这份工单，但可惜的是，此模块的 owner 没有搭建自己的基于 Agent 的工作流，也不会直接把整份工单交给 Agent 来复现和解决 BUG ，他更倾向于阅读源码来理解 BUG 发生的原理，而且这位同事非得拉着我看源码探讨代码的逻辑机制。
不过我之前还让 Agent 提了一份工单给另一位同事，那位同事显然直接把整份工单喂给了他的 Agent 并且让他的 Agent 解决 BUG ，给出提交，然后附上了一份全 Agent 生成的工单回复，显然他的工单回复也是极其晦涩难懂的，但是我这边的 Agent 能看懂他的回复，并且验收了他提交的改动，同时还测到了一个潜在风险，并要求同事针对潜在风险补充一份提交，同事也是全 Agent 工作流，很快就提交了，并解释了原理，我的 Agent 验收通过后，最后交付了提交，全程我几乎没有怎么参与，基本上都是我的 Agent 和同事的 Agent 在通过工单来交流。
从这两份工单不难看出，AI slop 的核心来源就是对于表达重点的把握不准，由于对于接收信息的对象的阅读习惯和工作流的不了解，导致工单出现了 slop 的情况，真是废废又废废啊。
后面我甚至让 Agent 自己去参考历史工单里面人类提出的工单总结提炼为 skill ，但是它基于 skill 写的工单依旧是没有可读性。
Select Language