posts/thoughts-on-textual-ai-slop

[giscus[bot]]

posts/thoughts-on-textual-ai-slop

https://hskl.me/posts/thoughts-on-textual-ai-slop

[SomeBottle]

支持好文 \(￣︶￣*\))

个人认为，减少 AI Slop，从另一个角度感觉可以理解成提升人对 AIGC 的掌控度，而不是两眼一闭、脑袋偷懒后任其发挥。

就“掌控度”而言，老实说 AI 时代开发和维护一个项目来多少还是有些“吃老本”的感觉：一方面是设计这一块，我对业务上可能踩的坑等细节越清晰（主要是在老项目上），就越能在 AI 辅助编码的同时发现那些“写歪了”的点，也就越能使得维护出来的项目更便于后续阅读和维护（反之从头开始就在用 AI 应付的玩意，越庞大就越不具备可维护性，因为我不了解其细节，从工程上来说就是一坨潲水）；而另一方面是基础知识这一块，尤其是写前端页面的时候，咱体感正如文中所述，AI 交付的玩意几乎很少一次就达成我的需求，如果没有介入，对咱而言还就确实是 AI Slop，多半还得自己改半天，而要自己上手改，到底得吃以前习得的前端老本（虽然到处在说“前端已死”，但咱认为应该更多指的是独立的前端岗位逐渐合并到了全栈岗位中，实际上要产出和需求对齐的前端依旧少不了人的介入）。

文中提到的注释方面咱也深有体会，大量无意义的注释只会影响阅读（其实就是模型把各种黑话的习惯带进来了），不过好在删除一些注释通常并不会显著影响后续开发，因为目前大多数编码模型有写测试用例来避免“走回头路”的习惯；交叉引用这一块的话其实是可以因地制宜的，比如 Java Doc 就有交叉引用的支持；开发前为了让模型按标准格式来写，我通常也会提前说明按 godoc, python sphinx 等风格写...

感觉 Agent Harness 作为新时代的软工，除了给模型提供环境并约束行为外，其实整体上看来也是在围绕怎样让人对 Agent 系统及其产物的“掌控度”更高，也就是在尝试设计各种方法论去减少 AI Slop。毫无疑问的是人至少在很长一段时间内都仍是不可或缺的一环，持续学习依旧是必要的。 (╹ڡ╹ )

[Subilan]

谢谢些瓶的阅读和评论！我很赞同你最后一段对Agent Harness的总结。

关于注释的维护，包括你所提到的测试用例，我觉得这里最令我担忧的是漂移问题（这个漂移drift也是AI大人教我的黑话，但我觉得好像也没别的词能概括，比如脱钩...过期...过时...？）。为了解决漂移问题，需要让模型在变化多端的Prompt之间维护这些交叉引用和测试用例。而形成漂移的原因和维护交叉引用的困难几乎都出自同一个问题：模型在每一个开发任务中，通常只会根据用户的Prompt探索它所认为相关的局部。这就导致其很难以一个整体或宏观地角度把握这些引用。当然，这里所提到的问题，都是在一个假设性的庞大代码库中。

考虑到注释可以有专门的语法，例如Go中也有交叉引用的注释语法，如果这个问题值得解决的话，我想可以引入一个注释lint的机械性过程，让注释中的交叉引用接受校验，例如引用是否存在、格式是否正确（可以规定不允许引用本地md文件等）等。

关于测试用例，我也担心模型会像堆积文档那样堆积测试用例，引入一些无意义的测试用例。例如在我的一个NodeJS项目中，随着开发的推进，测试用例从最初的一个单元测试1~6个测试用例，到后续所有单测加起来超过300个，每次运行都是300+ passed——但对我而言，无法一下子理解这300个测试都做了什么。当然，从另一个角度来想，由于测试并不参与业务逻辑，堆积了也没什么大的影响......？Anyways.

---

回想起当初还在用复制粘贴模式使用AI生成的代码的时候，我感到一种令人安心的效率提升，因为那个时候还知道自己要的代码片段大致长什么样，而模型往往能给出一个还可以的结果。随着Coding Agent能力的提升，它的自主性和对于非技术背景用户的产品力都大大提升了，代码、编程行为本身被“封装”了。这种抽象的、基于自然语言的编程方式也成为了现在编程的主旋律。一些结果导向的任务会推崇以让AI生成大幅超出自身理解能力的代码。作为程序员群体的一员，我们还是会在意这里面的问题和细节。

我想或许在未来更重要的是不断探索LLM的边界在哪里，从而将human insight放在最有价值的地方。