Slop Paralysis

# Slop Paralysis（代码惰性瘫痪） 来源：https://elijahpotter.dev/articles/slop-paralysis > **slop paralysis - 名词**：在审查编码代理的输出时，出现的一种完全或部分功能丧失的状态。 让我为你描绘一幅画面。 你有了一个产品创意。它可以是什么都行：一款移动应用、一个仪表盘，或者一个自动化工作的脚本。于是，你坐下来，向你最喜欢的 LLM（大语言模型）描述你的想法。也许你对实现方式有相当不错的理解。你甚至可能在脑海中已经知道了项目的整体结构。你把所有这些都告诉你的编码代理。 然后，你放手让它去做。它为你生成、整理并实现了你的产品。最终，你对最终结果如何工作*有一些*了解，但并不完整。由于这是一个重要的项目，你打算长期维护它，于是你去阅读代码。就在那时，你被击中了——**Slop Paralysis（代码惰性瘫痪）**。 ## 问题所在 代码惰性瘫痪是指完全缺乏审查 LLM 输出结果的欲望。它可能由于多种原因出现。对我来说，最常见的有： - 需要阅读的代码量实在太大。 - 缺少上下文（代理知道，但你不知道）。 - 害怕破坏某些功能。 最终，代码惰性瘫痪拖慢了你的速度，让你的生活更焦虑。那么，我们能做些什么呢？ ## 一些解决方案 我将描述一些*对我*有效的解决方案。一如既往，结果因人而异。 显而易见的解决方案就是干脆不使用代理。有时，编码代理会让你的工作更轻松；有时则不然。**判断何时该用何时不该用**很困难，但极其宝贵。（https://elijahpotter.dev/articles/when_to_use_an_agent） 当你决定使用代理时，可以让代理少生成一些代码。我听说过有一些[项目](https://github.com/DietrichGebert/ponytail)能帮你做到这一点，但我实际上没有尝试过。相反，我会先让代理制定一个计划，然后我自己重新修改这个计划，以尽量减少要修改的代码量。最终，原本由代理编写的计划，变成了被我毫不留情地自己编辑过的计划。通过这种方式，我最大限度地减少了需要阅读的代码量。这样做还有一个副作用：我对代理实际做了什么有了非常清晰的理解，这有助于解决上下文缺失的问题。 最后一个策略——当其他方法都失效时我会用——就是手动重构代码。当代理已经证明了项目的技术可行性，但代码实在太过庞大，无法一次性理解透彻时，我会静下心来，用细致的目光逐模块进行重构。我不需要仔细阅读每个函数并评估其价值，但我至少会强迫自己把每个函数都过一遍。 ## 稳住心态 我发现自己每一天都被各种讨论淹没。世界上发生的事情太多了，令人筋疲力尽，更糟的是，你被期望关心所有事情。给自己留点时间。让自己免于代码惰性瘫痪。