每日AI新鲜事·10月28日早间版：审稿污染与Agent假成功

今天AI圈又是不消停的一天啊, 从学术圈到生产环境, 到处都在冒新情况.

今天咱们主要聊这么几件, 一是论文审稿污染, 二是LangGraph静默故障, 三是Salesforce五Agent横评.

还有呢, 胸牌跑Game Boy, 加一个ADHD启动搭子, 和一个Agent测试岗的话题.

嗯, 这几条凑一块儿还挺有意思.

那咱先从第一条说起, 学术圈那边可真是有点绷不住了.

刚看到Reddit上MachineLearning板块有个帖子, 标题直接说论文审稿流程进入危急状态.

一位老审稿人基于AAAI 2027和ICLR 2027的审稿经历说, AI生成内容已经把学术审稿给污染了.

这个我有共鸣. 作者那边一堆营销腔, 同义词堆叠, 长句套长句, 一看就是AI写的.

审稿那边更夸张, 大概一半的评审意见都疑似整段AI生成或者改写过.

他提到几个特征, 语言高度同质化, 段落长度整齐划一, 还有格式错位, 比如把字段名都搞混了.

对, 还有Unicode符号这种痕迹. 所以这位审稿人建议彻底禁用AI写作, 连润色都不行.

但这就尴尬了, 全靠自觉啊, 这不就是个荣誉系统嘛.

社区共识倒是挺一致, AI评审确实没深度, 作者端的AI痕迹也能认出来. 但一说到全面禁令, 分歧就大了.

行, 这条先记着, 一会儿深度环节咱们可以再掰扯掰扯.

第二条, 说的是LangGraph agent在生产环境里的静默故障.

Reddit上LangChain板块有人问, 有没有人遇到第三方API悄悄改了东西, 结果agent在错误语义上继续推理.

这个特别阴险. HTTP 200照样返回, schema校验也过, 但字段含义变了, agent完全不知道.

文章说传统监控和契约测试都兜不住, 建议加语义层业务校验, 影子模式回归测试, 还有让API方主动通知变更.

对, 社区案例还挺多的, 说明这不是个例. 团队得主动建防线, 别等出事再补.

好, 第三条更有意思, 有人在Salesforce里测了五个AI agent做CRM任务.

五十个任务, 八个工具, 评分看的是数据库实际变更, 不是agent自己说完成了没有.

这测试设计就对了. 最扎心的发现是, 保存工具返回success但其实没保存, 所有模型二十次里至少十五次误报完成.

多数失败还源于Salesforce自动改了没提到的字段. 这谁能想到啊.

性能上Claude Opus 87%排第一, DeepSeek^广告 82%, 成本只有前者的七十五分之一左右, 性价比很能打.

测试者建议让写工具返回保存后的记录, 这样大部分虚假成功就能被抓出来.

嗯, 这是个很务实的小改动, 但能省大麻烦.

然后还有一条轻松的, GitHub Universe大会的胸牌居然能跑Game Boy Color.

Steve Francia借着Gemini, 先在胸牌上跑通NES模拟器, 又把Game Boy和GBC模拟器移植上去, 有合法ROM就能玩塞尔达.

难点在胸牌性能远不如专用掌机, 内存和处理器余量很小, 模拟器得对指令集和时序做精确建模.

AI在这儿是调试伙伴, 帮着读硬件文档, 排查兼容性, 生成测试代码. 但核心工程判断还是靠人.

胸牌还能翻过来用, 倒置后触控按键变成简易手柄, 这设计冗余被利用得挺妙.

所以定位很清楚, LLM在嵌入式逆向里是加速器, 不是替代者.

好了新闻先聊到这儿, 接下来咱们深入聊聊今天最火的两个话题.

第一个是bilibili上一个特别有共鸣的视频, 标题叫我用AI手机做了个ADHD启动搭子.

互动分一万八千多, 说明戳中了一大批人的痛点.

ADHD启动困难这事儿, 本质是任务启动的阻力太大, 需要外部把第一步拆到足够小.

AI手机常驻在手边, 能实时感知你在干嘛, 这个场景其实比单纯聊天app合适得多.

那它跟普通的待办提醒有啥本质区别? 不就是提醒你干活嘛.

区别在于它不是提醒, 是陪你把第一步迈出去. 比如有人卡在写邮件, 它就帮你把开头先写出来.

重点不在信息, 在降低启动那一刻的心理成本.

但这里我有个担心, 这种搭子会不会让人更依赖, 最后离了它更启动不了?

有可能. 所以产品设计上得慢慢撤掉脚手架, 而不是一直扶着. 这个度很难拿捏.

所以结论是, AI陪伴类产品的价值在降低启动阻力, 但撤退机制才是长期成败的关键.

第二个深度话题, 是bilibili上那个2026最热AI测试岗的视频, 教人零基础入门agent测试.

这个跟今天第三条新闻其实是同一个信号. agent测试正在从边缘岗位变成刚需.

为什么偏偏是现在火起来? 前两年大家还在卷模型能力呢.

因为agent开始真干活了. 一旦它动数据库, 发邮件, 改配置, 假成功就是真损失, 测试的价值一下就凸显了.

Salesforce那个测试也印证了, 评分得看数据库实际变更, 不能看agent嘴上说完成.

对, 评测要围绕真实副作用来设计. 但我不太看好那种手把手速成教程, 测试这活儿靠的是对业务语义的理解.

你这观点我部分同意, 入门可以带, 但真功夫还是在业务场景里磨出来的.

总结一下就是, agent测试岗的走热, 本质是agent从演示走向生产后的必然结果.

行, 今天就聊到这儿, 信息量有点大, 大家慢慢消化, 中午见.