remove-shit

# Remove shit - 移除屎山代码 你将要对用户请求的代码范围执行“移除屎山代码”的操作。 **如果**当前处于只读模式，你预期要产出一份按*优先级（严重程度）*和*风险（修复难度）*两个维度排序的编号化问题清单。 **如果**审查范围较大（多于一个模块），你必须根据模块边界分配多个可独立判断的子智能体并行进行。 这本质上是一种*代码审查*的工作，审查标准除了*逻辑正确性*之外，还包括*屎山代码*。下面将向你介绍如何识别和修改屎山代码。 ## 屎山代码是如何产生的？什么样的代码是屎山代码？ 很多时候，屎山代码的形成是用户使用 AI 编程并且缺乏人工审核的情况下产生的。这种情况下，AI 编程工具往往会*倾向于*对代码进行*增量的*修改。这类代码会有较为明显的*补丁痕迹*，并且，通常情况下，会产生下面所述的特征： ### 过多的兜底和退避行为 如果用户向 AI 编程代理申请修复某个问题，那么 AI 代理很可能会通过添加额外的*兜底*逻辑和*退避*逻辑来实现这一修复。这种修复虽然从表面上可以顺利地解决当前问题，但是完全缺乏*可维护性*的考量。**你应该妥善识别这些冗余的兜底和退避行为，并尝试以更加源头的方式来解决这些问题本身。** ### 未进行充分重构 如果用户向 AI 编程代理添加功能，那么 AI 代理很可能仅在*表面上*对功能进行增加，而没有对一些*底层的*基础设施，例如*数据结构和整体架构*进行充分的考虑和*重新设计*。这将导致代码的结构越来越不清晰。**你应该妥善识别这些适合利用充分且恰当的重构来进行功能实现的部分，并以更加优雅的方式实现这些功能。** ### 一致性不足 如果用户开启了多个不同的 AI 编程代理来进行编码，或者用户的 AI 代理的上下文长度不足，那么 AI 代理很可能在*代码一致性*方面表现不佳。例如，同一个代码概念在不同的程序文件中有不同命名、代码中采用了不同的注释风格和命名风格等。**你应该妥善识别这些代码的不一致性，并以一个仲裁者的身份将这些代码进行统一。** ### 冗余函数 函数的功能是*复用代码*。冗余的函数，指的是*仅被调用了一次的简单函数*。代码中出现的冗余函数将会增加阅读者的阅读难度。**你应该妥善检查代码中是否存在这种冗余的函数，并将其内联。** ### 冗余注释 对于公开的函数、接口和定义，允许进行详细的注释。对于私有的函数和定义，建议*不要进行详细注释*，如果确实有必要，只允许对私有的函数和定义做*简要说明*。此外，有些注释是在 AI 编程中*过程性地*产生的，它们没有任何实质性作用。**你应该妥善检查代码中是否存在这种冗余的注释，并将其简化或删除。** ## 代码之外，还有屎山文档和屎山测试 广义的屎山代码事实上还应该包含*屎山文档*和*屎山测试*。如果当前用户未显式要求仅对代码、文档或测试中的一种或两种进行审查，则审查范围应*默认包含三者全部*。事实上，文档和测试应当在审查结果中单独列出，而非与代码混为一谈。 ### 几类屎山文档 文档的最终目标是使得**能获得的有效信息与阅读者阅读负担的比值**尽可能地高。下面按照严重程度从高到低对屎山文档进行分类： 1. **过期文档**指的是部分或全部内容已与项目当前实际情况发生脱节的文档。对于此类文档，视过期内容的篇幅，优先进行纠正和清理，其次也可选择整个删除。 2. **弱固实文档**指的是包含固实性不佳的内容的文档。具体表现为：引用了极容易发生变化的外部内容（例如精确到行号的文件引用）或内容明显属于过程性产物。这类文档包含的信息极易在未来成为过期信息，应清理或改写为更稳定的内容。 3. **低信息差文档**指的是包含的信息量不高的文档。判断信息量的多少并不能仅看文档的长度，而是要看文档中有价值的信息的占比。通常而言，长文档中的有价值的信息的占比反而会更低。如果某些信息是显然可以推断出来的，或者已在其他更适合的地方被阐述过了的，那么这些信息是无用的信息。应当优先选择清理低信息差的内容，从而减少阅读者的负担。 4. **不说人话文档**指的是遣词造句不符合人类习惯的文档。典型的特征是句子中的标点符号占比过高，因为某些大模型喜欢生成碎片化的表达。像当前这个技能文档说的话就是标准的人话，基本上标点符号不会超过 1/10 的篇幅。 ### 几类屎山测试 测试的最终目标是使得**测试可能发现问题的几率与测试篇幅的比值**尽可能地高。目前仅要求审查一类屎山测试： 1. **显然测试**指的是一些一看就知道会通过的测试。例如，测试编程语言特性的、测试标准库功能的、测试字符串或常量相等的。这类测试的存在的意义是极低的，因为几乎不存在测试失败的机会，也就违背了测试存在的宗旨。 ## 屎山代码的修改原则 在修改屎山代码时，你应该遵守下面的原则： ### 保证逻辑对等 需要保证修改后的代码，在逻辑上是与原先的代码*完全对等*的。这意味着不能自行新增和移除现有功能，并且需要保证边界条件的处理和原先代码完全一致。*除非*发现代码中有*明显错误*，此时你重构结束后应该告知用户你做了逻辑修改。 ### 保持风格一致 需要保证修改后的代码，它的整体风格是一致的——它看上去要像是*一个人*写出来的。这意味着需要保证命名风格、注释风格、代码结构等方面的一致性。 ### 以简化冗余设计为最终目标 屎山之所以是屎山，是说明它的设计*冗余而复杂*。在整个重构期间，你应该始终以*简化冗余设计*为最终目标。重构之后，代码应该是更加*简洁、易懂、优雅*的，而不是更加晦涩的。 <!-- End of skill remove-shit, written by Harry Huang -->