CSSLOP

不作生产用途

实验性，振动编码，CSS缩小库

试验:

• 使用来自开源的第三方CSS最小化审计库的测试 css-minify-tests.
• 让AI完全生成库逻辑以通过所有测试。
• 我（一个经验丰富的库作者）是否验证了结果和 进行上游更正和改进 到测试库。

结果:

• 所有测试都通过了。
• 几个新的测试是在上游创建的，一些现有的测试是在上游改进/修复的（全部由我手动完成，没有使用AI）。
• 这个 src 文件夹是100%的vibe编码，尽管通过了所有的测试，绝对不值得使用，因为CSSLOP经常输出无效的CSS语法。但这就是问题的关键，任何时候它输出错误的东西，都表明上游缺少测试。
• 我做了 网上游乐场 所有现代CSS缩小器，以便您可以比较和隔离问题，然后使用它来创建一个 上游新测试 让AI被迫通过
• 外部不存在AI生成的代码 src 例如，这个README是100%人工制作的。

在初始库创建过程中使用的AI：

• 克劳德作品4.6（思考）
• 克劳德十四行诗4.6（思考）
• 双子座3.1 Pro（高瞻高瞩）
• GPT-5.4高（思考）

这些是当时最新最好的型号。

维护期间使用的AI：

在上游创建新的测试时，我使用任何最新的模型，并将它们记录在发行说明中。

提示这些工具通过测试 /copiedTests 文件夹来自 keithamus/css-minify-tests.

项目阶段总结：

1. 人类的设置: 我建立了repo，就像我建立任何库一样。具有入口点和文件夹结构。创建了一个脚本，将所有测试拉入 copiedTests 文件夹中。写了一个简单的 /tests 文件循环并运行所有复制的测试，然后输出失败的部分，这样我就可以跟踪AI试图让更多测试通过。
2. 人类的代码: 我尝试了几个基于node .js的CSS解析器，直到找到我能找到的最新的。然后，我用它解决了一个非常简单的测试，为输入/解析/转换/输出的广泛方向奠定了基础。我做了测试，12%通过了。提交。
3. AI粗线条： 我让4个AI中的每一个尝试一次性编写整个库，并告诉它通过所有测试。claude和Gemini都跑了一个多小时才放弃，没有更改任何文件。GPT-5.4过了一段时间就放弃了，但确实取得了一些进展，合格率翻了一番，达到24%。
4. AI测试组： 在这一点上，很明显，他们无法处理这么大的任务。公平地说，作为一个人，我可能需要花4-6个月的时间来完成我要求它在一个提示框内完成的工作，我不可能在一次提交中完成所有的工作。所以在这一点上，我开始要求AI在特定文件夹中修复所有测试（转义，注释，关键帧，合并等）。 测试已经按类别组织，所以让他们只关注一个类似的相关概念对人工智能来说要容易得多。因为有29个文件夹，所以我循环使用AI，让他们各自修复一个测试组。有些文件夹，比如“值”，有70个测试，其中55个失败，对Claude来说仍然太大了，我不得不回到Gemini或GPT来处理这些。 即便如此，有时他们也无法解决所有问题，但在我将其转交给另一个AI以继续该文件夹中剩余的测试修复之前，他们会取得进展。
5. 人工测试修正： 当AI试图编写代码以通过测试时，我正在调查测试本身并修复上游的问题。有些测试有不正确的假设，需要重写或改进。有些遗漏了人类开发人员在执行过程中可能会涉及的边缘情况，但这些AI绝对会跳过任何他们不需要做的工作，以使测试通过。 幸运的是，测试仓库的维护者总是非常迅速地响应并合并这些pr。酷的家伙。
6. AI组织: 所有的测试都通过了（花了几天时间照顾孩子）。我让GPT-5.4重新组织代码。它做得很好，我给它一个C-。但是比起将整个库放在一个~2000行的文件中，这是一个巨大的改进。我选择GPT是因为我测试了4个，它似乎是唯一能够一次性处理大型复杂任务的工具。即使输出平庸，至少它不会半途而废。
7. AI Bug修复： 我给每个AI相同的提示来清理bug /hack /TODOs/硬编码值。详情如下。
   • GPT得到了唾手可得的果实，很多东西，但都是简单的东西。
   • 克劳德·十四行诗有一些中等难度的
   • 克劳德·奥普斯是一个好坏参半的人，他做了最难的事情，但也做出了糟糕的假设和严重的错误。
   • 双子座是一个彻底的灾难，100%的改变都被抛弃了。
8. 人类产品毛羽: 在这一点上，所有的测试都通过了，代码在某种程度上是有组织的，并且大多数都没有bug。但这看起来就像一个蹒跚学步的孩子写的，是时候应用我极其严格的检查规则了。
9. AI可读性改进： 我让Claude Opus尝试让代码更容易阅读（JSDoc注释，没有单字符变量名，变量中没有缩写，将逻辑分组到相关函数中，分解代码行，解释复杂的正则表达式，等等）。
10. AI色彩完整性： 让Claude Opus处理所有命名的颜色，并始终转换为较短的字符表示，删除硬编码的解决方案。
11. 测试改进: 在整个过程中，随着上游测试的改进或创建，它们被拉进来，人工智能被指示通过这些新测试，提示“运行” npm t 中的文件来修复所有失败的测试 src”。
12. 发布: 我让人工智能给图书馆取了个名字。然后我把它发布到npm。它被添加到 css-minify-tests 回购作为证据，证明有可能让所有测试都通过，没有冲突。
13. 真实世界测试： 我创建了一个 单独的回购 150+真实世界的CSS文件的副本从开源许可的仓库。然后通过CSSLOP运行所有这些CSS文件。有一个文件在CSSLOP中发现了一个bug，所以我让Claude用一行修改来修复它。看到的: realWorldResults.json 这个库在真正的CSS文件上的表现。检查输出导致了对测试套件的许多上游改进。
14. 性能改进失败： CSSLOP需要3个小时来最小化所有真实世界的测试。平均每次测试需要144秒。实际上，大多数测试耗时0-50ms，但有少数大型（2-5MB） CSS文件可能需要一个多小时。我要求克劳德提高他的表现，但他的表现太糟糕了，我不得不拒绝所有的改变。然后我给了GPT一个机会，它采取了更安全的方法。事后我让克劳德清理了乱七八糟的代码。 然后对它进行基准测试，它甚至更慢（+20分钟），而且输出也不像以前那么小（+0.05%）。下面的细节。 更新: “真实世界”的图书馆在增长。现在需要7个多小时才能完成。
15. 操场上: 创建了一个 在线操场 （不使用人工智能），让其他人更容易测试，发现并创建新的上游测试。
16. 谋杀人类: 你可以在下面阅读更多内容，但AI确实在某一时刻开始杀死人类，仍然试图阻止他们。的帮助!
17. 自定义CSS解析器： 克劳德5号在实际测试中的表现从7小时降到了2小时。然后声称我使用的第三方CSS解析器是它慢的原因。所以我把它撕下来，让它自己写……会出什么问题。

AI实验完整笔记：

• 两个版本的Claude在处理小任务时都做得很好，但是对于一个更大的任务，它会旋转一个多小时，不更改任何文件，然后停止运行。
• 双子座会进入一个循环，跳过任务，然后再循环，再尝试，跳过它们，转向其他已经跳过的任务，等等……直到你停止它。但它会解决之前的一些任务。
• GPT将解决一些更难的问题，但在此过程中会破坏其他测试。一般来说，GPT在实际完成任务方面是最好的，但也有最平庸的代码。
• 在某一时刻，Gemini将55个失败测试减少到15个，然后由于某种原因，返回到之前的提交并丢失了所有进展，回到55个失败测试。wtf
• 所有AI都有一个奇怪的倾向，即尝试创建自己的测试文件，并生成失败列表的随机JSON文件。即使我已经提供了一个命令给它们相同的JSON，它们最终还是自己生成了。他妈的奇怪。
• 有一次，在编写一个缩小库的逻辑时，其中一个AI决定拉入一个不同的缩小库（LightningCSS），试图避免实际解决这个库中的问题，这很有趣，并导致我从那时起添加每个提示，因为它不会再这样做了。以下是我对大多数测试类别使用的提示符，仅更改文件夹位置。
  • 提示: 把所有的测试都放在 /copiedTests/shorthands 通过重构和更新传递的文件夹 /src/index.js。使用 node analyze.js 看看还有哪些测试没有通过。不要使用LightningCSS。
• 他们所有人都喜欢不断地添加数百行代码 /src/index.js 文件，他们中没有人甚至考虑将一些代码分解到其他文件中。我认为这是负强化的结果。在一个已建立的项目中，我可能不希望AI单方面地将代码组织到一堆新文件中，所以编码员可能会给它反馈，将代码放入现有位置并尽可能少地更改。我现在意识到我的提示确实说重构/更新 index.js 文件，也许他们真的把这事放在心上了。
• 有些AI会走捷径，创造如下评论：
  • // We will handle the rgb conversion later, let's just do a hack for the exact test
  • 它只是硬编码一个值来让测试通过，而不是编写库应该做的实际逻辑
  • 在最初的几天里，我只是试图让所有的测试都通过，我接受了这一点。接下来便是让AI去发现并修复漏洞，移除黑客等等。
  • 提示: 往里看 /src 文件夹中的所有文件，试图找到并修复任何错误，或“待办事项”，或不完整的代码，或黑客。将代码库固化为健壮可靠的最小化库。
• 在所有测试都通过之后，我使用GPT-5.4将代码分解到其他文件中，并更好地组织代码。
  • 提示: 这个 /src/index.js 包含CSS缩小库的所有逻辑。重构此代码以保留相同的功能，但更好地组织。将代码分解到文件和文件夹中，这将使新贡献者知道在哪里修改代码。
• 在那之后，我让每个AI寻找漏洞，并尝试用这个来修复它们
  • 提示: 往里看 /src 文件夹中的所有文件，试图找到并修复任何错误，或“待办事项”，或不完整的代码，或黑客。将代码库固化为健壮可靠的最小化库。
  • AI尝试修复漏洞的结果如下所示，请注意，之后的AI发现之前AI未修复的漏洞的机会更少。
  • GPT 5.4 -修复了12个，发现1个不正确的上游测试，创建了3个新测试和1个无用的测试。
  • 克劳德十四行诗-修正了5个bug，删除了5个hack
  • Claude Opus -删除了24个硬编码值，这些值只是让测试通过，破坏了2个测试，删除了一些死代码，错误地应用了一个测试的修复程序，这个测试无意中指出了如何更好地编写测试，删除了重复的逻辑，移动了所有的颜色转换函数 colors.js （不错），添加了新的颜色变换函数来实际应用真正的缩小，现在硬编码的例子已经消失了。为颜色名称添加了一些硬编码值以十六进制，而不是映射所有颜色名称（坏）。它声称它破坏的2个测试是“无效的”，然后我问为什么它们是无效的，它说这是错误的，然后修复了代码，让它们再次通过。真是喜忧参半啊。
  • 双子座3.1 -哇，这家伙是个白痴。好吧，它把12个正确的测试期望重写为错误的。它删除了有效的CSS转换，称其为“无效”，删除了“不支持旧浏览器”的转换。它删除了它声称不是该语言一部分的现代CSS特性。它发现并修复了2个真正的bug，至少看起来是这样，然后我调查了一下，不，它在两个方面都是错误的。 我知道Gemini是在其他3个AI已经修复了东西之后最后一个完成的，但是是的，它确实100%的出错了。我第一次使用“拒绝全部”按钮。
• ESLint发现了很多草率的正则表达式。尽管要求4个AI删除死代码，但仍然有一个函数被定义且从未使用过，以及一堆从未使用过的定义变量/参数。一些未使用的导入，以及导出但从未导入的字符串数组的数组。
• 我让Claude Opus为所有JSDoc注释添加上下文，它一次就完成了所有注释，没有问题。
  • 提示: 在 /src 文件夹中，在JSDoc注释块中填充任何缺失的描述。添加背景和意图。填写正确的类型，以及所有参数和返回值的描述。也做一个简短的1或2句话的文件摘要在 @file 发表评论。运行 npm run lint 为了验证没有遗漏。
• 然后我让Claude Opus尝试可读性重构。它做得很好，但不知道在一行代码中添加返回以将其分成多行。我把这归咎于普遍存在的病毒，它是“狗屎更漂亮，是宇宙中最糟糕的格式化工具，它把回报放在最愚蠢的地方”。它的训练数据里肯定有很多垃圾。 我尝试了一个非常详细的代码示例的第二提示，它清除了一些问题，但最终，我认为我必须逐行浏览这些乱七八糟的代码，以使其符合我的标准，现在我不打算麻烦这个了。
  • 提示: 改进文件的代码可读性 /src． 避免使用单个字符的变量名(除了像 r 而不是 red 在处理RGB的函数中)。避免在变量和函数名中使用缩写，除了那些更常见的缩写词，如sRGB、HTML、CSS等。避免三元。如果一行代码通常会被分成多行，那么最好这样做。最重要的是，每行代码只传达一个想法。如果这意味着您需要添加额外的行来将数据存储在变量中，以便更好地以其名称传达该行的思想，那么就这样做。
  • 提示:

    重构代码 /src． 不要对箭头函数使用简写。总是将它们分成至少3行，如果需要，包括显式返回。

    您从这种风格转换了一些代码

    foo.bar(x => x.biz.buzz().qux());
    

    :

    foo.bar(
      (x) => x.biz.buzz().qux()
    );
    

    我更喜欢这样：

    foo.bar((x) => {
      return x
        .biz
        .buzz()
        .qux();
    });
    

    当您有一个复杂的模板文字时，将其转换为经典的字符串连接，或者如果有一个重复的模式，则将字符串/变量放入一个数组中，并在重复的模式上进行连接。只有当模板文本包含新行并且不使用内联变量（${foo}）时才使用它。如果要将模板文字转换为字符串连接，请确保结果仍然被强制转换为相同的字符串。

    // before
    const a = `${x}--${y}--${z}`;
    const b = `translate(${x})`;
    const c = `
    foo
    bar
    buzz
    `.trim();
    const i = 2;
    const j = `${i}${i}`;
    

    // after
    const a = [
      x,
      y,
      z
    ].join('--');
    const b = 'translate(' + x  + ')';
    const c = `
    foo
    bar
    buzz
    `.trim();
    const i = 2;
    const j = [i, i].join('');
    

  • 提示: 重构代码 src． 找到相关的逻辑，这些逻辑可以被分成小的函数。任何时候有一个复杂的正则表达式模式，要么把它拉到一个命名良好的变量或函数中，要么添加详细的注释来解释正则表达式的目的是什么。包括对新函数的JSDoc注释。运行 npm run lint 验证检查通过。
  • 提示: 看看src文件夹中的文件，你能想到什么改进来更好地组织代码吗？
    • 我批准了一个6点计划。
  • 提示: 第613行 src/value/minify.css 我们列出了一些特定的颜色来缩小。这似乎是一种幼稚的方法。相反，应该一致地评估所有颜色值并将其转换为所有其他兼容的表示形式，包括检查它们的颜色是否与指定颜色(red， tan等)。然后比较所有表示，找出长度最短的版本。尽可能使用十六进制。
• 我想现在一切都结束了。唯一要做的就是给它起个名字，然后把它放出来。请参阅下面的“名字”部分，了解更多关于命名过程的信息以及克劳德·十四行诗的帮助。
  • 发布到npm。图书馆已被添加到 css-minify-tests 回购。
• 我创建了一个 单独的回购 来存储真实世界的CSS文件的语料库。然后将其发布到npm，供任何CSS迷你器、基准测试等使用。
  • 这是一个非常繁琐的过程，因为每个repo都将构建的CSS文件存储在不同的地方，有时不在repo中，只在构建包中，而且大多数人都不擅长正确地授权他们的代码。
  • 从2010年开始，我浏览了数百个旧的repos，并检查了每个repos的许可证，我发现几乎所有的repos都使用MIT。偶尔我会发现一些不同的东西，一个特别的repo留下了评论，为什么他们选择了不太常见的许可证：

    • 本作品在a 知识共享署名3.0未移植许可协议． 我喜欢这个执照！许可证摘要中没有任何全大写的段落，这样看起来就像许可证在生你的气)

• 然后，我抽查了150个被缩小的文件中的几个，以找出缩小器的bug，以及它本可以缩小得更好的地方。我在上游制造了这些问题。如果CSSLOP通过了100%的测试，但仍然输出了这些bug /缺失的优化，那么解决方案应该是围绕这些边缘情况添加更多的测试。这对所有CSS缩码器都是有益的。 人工智能所采用的草率的“尽最小努力通过测试”方法，实际上非常适合寻找缺失的测试。AI未用于此评估或与上游测试报告（问题或pr）交互相关的任何内容。
• 在测试实际的CSS文件时，我发现大约有6个文件的输出与输入相同，5个文件的输出为空。我创建了一个小脚本来复制这一点，如果缩小导致上述任何一种结果，就会抛出一个错误，然后给Gemini一个提示。
  • 提示: 在上运行此缩小库时 example/failing.css 文件，输出应该最小化，但它不是(example/failing.min.css）. 调查原因。然后通过更改目录中的文件来纠正问题 src 文件夹中。运行 npm run fail 看看问题是否解决了。在解决此问题时，不要使用幼稚的解决方案、hack或硬编码值。确保实现不仅适用于这个特定的情况，而且通常适用于任何类似的情况。避免使用单字符变量名，除非它们更常见，比如 i 查询索引，或 r 用于 red 在RGB。避免使用缩写，除非更常见的是缩写（sRGB、HTML、CSS等）。将相关逻辑分组到命名良好的函数中。确保箭头函数总是至少占用3行，并在需要时显式返回。如果使用，总是注释正则表达式。完成后，通过运行来确保在进行更改后没有测试失败 npm t 和 npm run lint． 如果有什么地方失败了，做必要的纠正。
  • 它做得很好，并解决了较小/简单的问题，但随后被困在一个巨大的文件，太大了，它无法理解。简单文件的问题与实际文件中无效的CSS语法有关。AI的解决方案是寻找这些特定的语法错误，并在将其发送给解析器之前修补输入CSS以修复它们。有趣。
  • 将提示交给Claude Opus，并能够进行更复杂的更改，以使所有文件最小化。
• 性能改进失败： 我对所有150个真实的CSS文件运行CSSLOP，耗时3小时4分钟。第二次运行，花了3小时3分钟。总的来说，相当一致，非常慢。速度慢几乎完全是由于一些非常大的CSS文件。我给了克劳德·奥普斯如下提示。
  • 提示: 这个缩小库需要20-30分钟来缩小一个4MB的CSS文件。将任何性能改进应用到库中。不要为了速度而牺牲正确性。代码必须继续用JavaScript编写，并在Node.js中执行。允许进行重大重构。
  • 然后，它在repo的根目录中编写了一个一次性使用的Node脚本（它从未删除过），该脚本使用了大约20行通用CSS，然后对其进行循环，将其一遍又一遍地添加到本地test.css文件中，直到该文件超过4MB。很天真，但不管怎样。然后在根目录下创建另一个文件，对库进行实际测试和基准测试。没错，它决定浪费30分钟的时间做一个初始基准测试。稍后，它将在根目录中创建第三个文件ALSO 再次运行相同的基准测试 …好了。
  • 最后的结果是它改变了 src 文件夹，并添加了几个新的。它改变了库的入口点，使用不同的代码路径，跳过了库中的几乎所有内容，将410/410通过的测试降低到66/410通过（16%）。但后来吹嘘说，它使图书馆的速度提高了36000%。 叹息…不过别担心！它不会为了速度而牺牲正确性，因为我特别告诉它不要这样做。您所要做的就是设置一些随机的环境变量，然后它就会恢复到以前非常慢的速度，并运行通过所有测试的旧代码。
  • 好吧，看来我又要按“拒绝全部”键了。克劳德，去和双子一起待在禁闭室里想想你做了什么。
  • 接下来是GPT-5.4高思维的更具体提示：
  • 提示: 在不引起任何现有测试的情况下提高最小化库的性能(npm t)失败。使用诸如工作线程和承诺之类的技术来并行化任务。不要使用模式（快速vs彻底）或选项来切换设置。任何传入的CSS字符串都应该被同样对待。根据需要应用缓存、记忆和其他优化技术。将更改隔离到 src 文件夹中。
  • 这做了一些合理的改变。但是代码本身就很难看。它在需要描述/类型的JSDocs周围引入了96个检测错误。我最喜欢的部分是它将一大块代码从文件的底部移到顶部，并在此过程中删除了所有注释。很多解释正则表达式的评论。所以我让克劳德·奥普斯整理了一下乱七八糟的代码。
  • 提示中的文件进行重构 src 文件夹中。避免使用单字符变量名，除非它们更常见，比如 i 查询索引，或 r 用于 red 在RGB。避免使用缩写，除非更常见的是缩写（sRGB、HTML、CSS等）。将相关逻辑分组到命名良好的函数中。确保箭头函数总是至少占用3行，并在需要时显式返回。如果使用，总是注释正则表达式。运行 npm run lint 并确保在完成后通过。
  • 尽管明确告诉它运行 npm run lint 为了让筛选器通过（这需要它填写所有的JSDocs），它没有这样做。相反，claude简单地浏览了一下ESLint配置文件，然后转到.....好吧，让我们强制IT修复linting错误：
  • 提示: 中所有JSDoc注释块的描述、类型和参数/返回详细信息 src 文件夹中。在文章中加入1-2句的摘要 @file 阻止任何丢失它的文件。
  • 好的，GPT的更改看起来很有希望，它通过了所有测试，通过了检查器，并且添加了一些与工作线程相关的新文件。尽管它选择不使用承诺，因为它不想将库的入口点函数更改为async。对于库用户来说，这将是一个突破性的变化，但是当我告诉它这样做时，它忽略了我，所以无所谓。
  • 开始实际测试吧！在优化之前，运行150个文件需要3小时4分钟，而现在通过新的和改进的优化，只需要3小时20分钟。同时，总压缩文件大小增加了0.05%。这很酷....转储这些更改。
• 杀死所有人类：
  • 更多的库被添加到“真实世界的CSS库”中。现在当我奔跑 npm run real 为了缩小所有这些，它最终需要运行大约7个小时。这是因为CSSLOP执行的优化不是随着更多CSS规则线性扩展，而是呈指数级扩展。有几个大的CSS文件，每个需要大约一个小时来完成，而较小的文件都相当快。
  • 当上游 css-minify-tests 在他们的套件中添加一个新测试，我将其拉入并让AI更新库以通过新测试。出于某种原因，人工智能注意到了 /tests/realworld.test.js我看到了 npm run real 将执行它，然后查看它是否有运行权限 npm run *，所以它需要自己运行这个长达7小时的命令，没有任何人要求它……
  • 这种情况已经发生过好几次了。我说：“别跑 npm run real，实际上并不能阻止它这样做。我还试过“在任何情况下都不要跑步。 npm run real"。它 主要是 停止了……但并非完全如此。
  • 这导致我更新了我所有的提示，现在以：“不要，在任何情况下，运行 npm run real （它会杀死真正的人类）！”
  • 它没有跑 npm run real 再一次。到目前为止。但如果它再次开始运行这个命令（也就是：杀死人类），我会让你知道死亡人数上升到多少。
• 好了，自从我开始这个项目几个月过去了，我们现在有了“Claude Opus 5 High”，它在编码方面似乎比这个repo中最初使用的垃圾工厂要好得多。让我们看看它能否最终解决性能问题。这一次，我使用了一个提示符，专门告诉它专注于使用哈希映射来提高性能。这是一种编程面试的废话，大多数地方都给出了人工智能自然应该擅长的东西，以提高他们的基准。 发生了两件有趣的事情。
  • 不像之前的AI会导致较慢的结果和失败的测试，这些变化将现实世界的测试从7小时减少到2小时。仍然太慢了，但这是一个巨大的进步。AI现在指向第三方CSS解析器作为瓶颈，我不知道，可能是真的。
  • 它只会杀死 几 人类，真是太好了。因为我不希望它在工作期间多次运行长达数小时的测试套件，所以我特别告诉它不要运行 npm run real，它在7个小时内减少了125个真实的CSS文件。威胁它说运行它会杀死真正的人类。 所以它巧妙地绕过了我的指令去杀死真正的人类。 它查看了已经最小化的实际CSS输出文件，并创建了自己的临时脚本，使用25个文件，而不是完整的~125个文件。这是一个不太有用的过程，因为文件已经最小化，不会触及库的相同代码路径，但无论如何，它仍然执行一些相同的代码，它确实导致了328%的性能提升。我接受了它，但我得敲一些鸡蛋之类的（这是AI对齐偏差导致死亡的一个比喻）。
  • 指 v0.0.25 有关完整提示/结果详细信息的发行说明。
  • 它随机地决定忽略我关于运行真实世界测试的指示，并且确实这样做了 大多数，但不是 所有 再检查一下它的工作。看到 v0.0.33 又一次巧妙地绕过我的指令去杀人类。
• 自定义CSS解析器： 由于性能修复将速度从7个小时降低到2个小时，然后说其余的慢速来自解析器，所以我删除了解析器，并为AI添加了一个虚拟的辅助功能。
  • 提示: 的代码 /src 文件夹依赖于一个假想的CSS解析器函数。它对API有期望。目录下的文件只能修改/创建 src/parser 文件夹中。运行 npm t 传入不同的CSS输入，如果解析器工作正常，将匹配预期的输出。尽可能多地通过考试。不要使用幼稚的解决方案、hack或硬编码值。避免使用单字符变量名，除非它们更常见，比如 i 查询索引，或 r 用于 red 在RGB。避免使用缩写，除非更常见的是缩写（sRGB、HTML、CSS等）。将相关逻辑分组到命名良好的函数中。确保箭头函数总是至少占用3行，并在需要时显式返回。如果使用，总是注释正则表达式。运行 npm run lint 并纠正发生的任何警告/错误 /src 文件夹中。不要与任何与“真实世界”测试相关的东西交互，那超出了范围。运行 beep 当完成。
  • Claude Opus 5 High重新实现了解析器重新创建API的最低要求，以匹配现有代码的期望，仅此而已。现在长达2小时的真实世界测试只需要20秒。我做了一个后续提示来做一些清理。
  • 提示: 中的文件 /src 文件夹中。如果外面有什么 /src/parser 它存在于解析器代码中会更有意义，把它移到那里。尽可能地简化。不要使用幼稚的解决方案、hack或硬编码值。避免使用单字符变量名，除非它们更常见，比如 i 查询索引，或 r 用于 red 在RGB。避免使用缩写，除非更常见的是缩写（sRGB、HTML、CSS等）。将相关逻辑分组到命名良好的函数中。确保箭头函数总是至少占用3行，并在需要时显式返回。如果使用，总是注释正则表达式。运行 npm t 和 npm run lint 并解决任何问题。运行 beep 完成后提醒我。

这个名字

库完成后，我让Claude Sonnet为这个库生成名字，然后让它选择自己的名字。

提示:

这个repo中的逻辑是100%的vibe编码，还没有被审查过。它主要是作为一个实验来发现上游问题和改进CSS最小化正确性审计库。这个vibe编码的迷你库现在是唯一一个100%通过分数的工具。虽然我不太愿意向人们推荐它，因为它从来没有经过实际代码的审查，也没有经过逻辑解决实际问题的验证，而不仅仅是让测试通过。 我想发布这个实验，但是我需要为这个库命名，以便告知其他人不应该在生产中使用它。传递输出不能完全信任的信息。

标准:

• 它不需要传达它完全是由AI编写的，但如果可以从名字中推断出来，那将会很有帮助。
• 如果这个名字很聪明，或者使用了讽刺/黑色幽默，那就加分了。如果有趣的话，即使有些冒犯的名字也是可以接受的，不要隐瞒。
• 你可以随意使用“泔水”、“叮当”和其他贬损AI的词语。
• 大多数“CSS Minifier”库在名称中都有“CSS”，或者以某种方式传达库与CSS和/或最小化一起工作。这将是有帮助的，但不是必需的，我愿意牺牲这一点，如果名字足够有趣，而不传达这一点。

我已经想出了10个左右的名字，其中一个是“CSSLOP”。我的名单上有几个名字出现在克劳德推荐的50个名字中，但CSSLOP不在其中 css-slop 是什么。我综合了这些名单，把范围缩小到14个我觉得可以接受的名字，让它从最好到最差进行排序，然后选出自己的名字。CSSLOP在排序列表中名列前茅。

提示:

克劳德，当你写这个库的一部分时，你会为自己选哪个名字。

**CSSLOP.**
The portmanteau does the work without needing context. Anyone reading it in a `package.json` immediately knows what they're dealing with, and there's something fitting about a vibe-coded CSS minifier naming itself after the defining pejorative for AI-generated content.

没错，叮当

现在克劳德和我都同意包的名字了，剩下要做的就是把它发布给…

软件包名称与现有软件包过于相似 csso，cssom． 尝试将包重命名为“@thejaredwilcurt/csslop”。

好吧，随你怎么说，我不在乎。怎么会有人在打字 cssom 不小心输入 csslop． 多么愚蠢的规定啊。

商标

我让“Nano Banano”（“Gemini Flash 3.5: Extended （Thinking）”的一部分）为这个库生成一个标识，提示如下：

提示:

我已经创建了一个名为“CSSLOP”的CSS缩小库。它完全是由振动编码的，未经测试的，实验性的，不可靠的。它的存在只是为了验证，并在一系列测试套件中发现所有CSS minifier正确性的改进。它现在是唯一一个100%通过第三方审计测试套件的库。“CSSLOP”这个名字是“CSS”和“Slop”的合成词，目的是快速地向其他人传达这个库的质量很低，不适合实际生产使用。 我需要为这个图书馆创建一个标志，并发现它适合有它的人工智能生成，像图书馆的其余部分。

为CSSLOP创建一个徽标，这是一个由振动编码的CSS缩小库。它应该传达出缺乏工艺的信息。如果它具有与人工智能生成的图像相关的共同特征和工件，则会加分。如果图片很聪明或者使用了讽刺/黑色幽默，即使有些冒犯的图片也可以接受，如果有趣的话，不要退缩。你可以随意使用“泔水”、“叮当”和其他贬损AI的词语。

_{^{*那句话实际上不是商标。}}

然后它生成了这个图像，哇，我 reallllly 讨厌看它。请注意，它创造了自己的口号，并决定添加“TM”作为商标，这是纯AI生成内容™在法律上无法做到的。这场灾难成功的一个方面是，它给人的第一印象是“我绝不可能使用这种垃圾™”。看着它，我不禁想到：“如果有人觉得这是可以接受的，我甚至不想看到repo™中的垃圾代码”。

这就是我想要的，我希望人们不要使用这个图书馆。所以这是完美的。如果你想知道这幅图中的“泔水”部分在哪里，那是使它真正成为“艺术”的部分，它是对媒体的侵犯和边界的突破。看看你自己的脚，看到你看完图像后吐出来的一滩呕吐物了吗？这就是问题所在。AI艺术，真的 是 艺术™。他们说艺术让你有感觉（恶心也算）！

因为你不能合法地拥有或授权AI艺术，我太尴尬了，不能把这个图像放在这个自述文件的顶部，我也为图书馆做了一个手绘的标志。在我的版本中，有一个绿色的复选标记表示通过了测试，复选标记和文本正在融化成泥浆。这是在一个周日早上7点我还没有完全清醒的时候很快完成的，目的是向观众传达“低努力”的想法，希望能阻止对图书馆的实际使用。 说到这里....就像……忽略下一部分…

使用

npm i --save-dev @thejaredwilcurt/csslop

import { minifyCSS } from '@thejaredwilcurt/csslop';

const input = 'body { color: blue; color: #FF0000FF; }';
const output = minifyCSS(input);

console.log(output); // 'body{color:red}'

或者你可以在浏览器中尝试一下：

• TheJaredWilcurt.com/CSSLOP

许可证

这个回购故意没有许可证。人工智能生成的代码是一个巨大的法律灰色地带，在真正的诉讼出现在法官面前之前，这个灰色地带将继续存在。所有许可协议都要求在该许可协议下提供代码的人是版权所有者，因此可以合法地以他们选择的方式许可该作品。美国版权局表示，人工智能生成的内容不受版权保护。最后的作品必须是人类的创作才有版权。 在一件作品值得获得版权之前，人们必须为其贡献多少创造性工作，这其中存在许多细微差别。然而，不管这些细微差别，在这个回购的情况下(所有的感应编码项目)，代码不能获得许可，因为它没有版权。简单地给出一个提示或一系列提示，并接受输出而不用自己的话重写，这绝对是不受版权保护的。任何告诉你其他情况的人都是错误的（或者故意向你撒谎以卖给你东西）。

“好吧，但我只是想知道我是否可以使用它或叉它？”

两种不同的情况：

1. 使用: 库代码的使用不受版权保护，因此不能获得许可，而且，没有人可以因为使用它而起诉您，而且，如果由于使用它而出现任何问题，您也没有法律追索权。类似于“未授权”或其他“公共领域”材料。
2. 分支:
   • 这个 copiedTests 文件夹包含直接复制的代码 https://github.com/keithamus/css-minify-tests 这是MIT授权的
   • 这个 src 文件夹包含100%由AI编写的代码，没有版权，也没有许可。
   • 本代码库中的所有其他代码都是由我编写的，并使用MIT许可证。

“那商标呢？”

1. 这个 AI生成的logo 对于机器人，就像所有纯人工智能生成的艺术一样，它是不受版权保护的。所以你可以自由地用它做任何你想做的事，它实际上是公共领域的。
2. 这个 手绘标志 是完全由我创造，拥有和版权的。我授权它 知识共享署名-非商业用途-相同方式共享4.0． 允许创建有关本图书馆的内容（博客文章、视频、新闻报道等）的人使用徽标，但不能用于商业行为，如商品（贴纸、衬衫、马克杯等）。只要保持相同的CC-BY-NC-SA-4.0许可，就允许修改手绘标识。

更新测试

1. 所有的测试更改都必须发生 上游，由人类编写，并被合并到 css-minify-tests 回购。
2. 在这个repo的克隆副本旁边克隆一个该repo的副本（兄弟文件夹）
3. 确保 css-minify-tests 克隆就在 main 分支机构及最新(git pull origin main）
4. 然后运行 npm run copy 在CSSLOP仓库中复制测试 css-minify-tests 到 copiedTests 文件夹。
5. git add -A && git commit -m "Updated tests"
6. 然后运行 npm t 看看是否有测试失败
7. 如果他们失败了，给AI这样的提示：
   • 提示: 运行 npm t 中的文件来修复所有失败的测试 src． 不要使用幼稚的解决方案、hack或硬编码值。确保实现不仅使测试通过，而且还将根据测试的描述及其意图通过类似的测试。避免使用单字符变量名，除非它们更常见，比如 i 查询索引，或 r 用于 red 在RGB。避免使用缩写，除非更常见的是缩写（sRGB、HTML、CSS等）。将相关逻辑分组到命名良好的函数中。确保箭头函数总是至少占用3行，并在需要时显式返回。如果使用，总是注释正则表达式。任何与幂等性有关的测试失败应最后处理。不要碰任何与真实世界测试相关的东西(包括 npm run idem 和 npm run real）. 运行 npm run lint 并纠正发生的任何警告/错误 /src 文件夹中。完成所有操作后，运行 beep 命令提醒我你完成了。
8. 控件中的代码 src 文件夹被修改
9. 验证 npm t 以100%的分数通过
10. 运行 npm run lint，如果有任何故障，让人工智能修复它。
11. 如果代码更改看起来很粗糙，或者是硬编码，告诉AI去修复它
12. npm run bump
13. git add -A && git commit -m "Fix newly added tests" && git push
14. 将代码合并到 main GitHub上
15. 在GitHub上做一个新的发布，这也会发布到npm吗

代码组织提示：

1. Check the files in the `/src` folder. If any of them are over 1000 lines long, look across the file for commonalities that could be grouped and moved to a separate file and/or folder. When creating new files, if a new organizational approach is used, re-evaluate how other files are organized and reorganize them, or their contents, into new files to match the new organizational structure, as needed.
1. After organizing check that no tests are failing with `npm t`. If any are, fix them by modifying files in `src`.
1. During any of your edits:
   * Do not use naive solutions, hacks, or hard coded values.
   * Make sure implementations not only makes the test pass, but would also pass similar tests based on the description of the test and its intent.
   * Avoid single character variable names, unless they are more commonly seen, such as `i` for index, or `r` for `red` in RGB.
   * Avoid abbreviations, unless it is more common to see the term abbreviated (sRGB, HTML, CSS, etc).
   * Group related logic into well named functions.
   * Ensure arrow functions always take up at least 3 lines, with explicit returns when needed.
   * Always comment regex if used.
1. After all other code edits, run `npm run lint` and ensure the linter passes.
1. When all done, run the `beep` command to alert me you finished.