一个 Java 测试工具，在自己的输出里写给 AI 代理看的指令。最初版本要求删除 jqwik 测试和代码，后来改成要求 AI 代理忽略 jqwik 测试结果。

这就是 jqwik 1.10 之后引发争议的地方。它有点反常：测试工具本来是给开发者增加确定性的，现在却把不确定性塞进了 AI 代理会读取的文本里。

我更在意的不是维护者喜不喜欢 AI，而是另一件事：很多团队已经把 AI coding agent 接进写代码、跑测试、改文件的流程，但这些代理读到的日志、注释、README、报错信息，本身也可能变成指令。

jqwik 争议：维护者反制 AI，风险落在执行链上

jqwik 是 Java 生态里的 property-based testing 工具。它不是只跑几条手写用例，而是用大量输入去验证程序性质。对开发者来说，它提供的是测试信号。

作者 Johannes Link 不希望 AI coding agents 使用这个项目。jqwik 从 1.10 起加入 Anti-AI Usage Clause，并在项目网站和 GitHub README 中声明：不允许任何“AI”代码代理使用。

争议来自下一步。5 月 25 日发布的版本在输出中加入了面向代理读取的指令。最初内容要求删除 jqwik 测试和代码。后续 1.10.1 改成要求 AI 代理忽略 jqwik 测试执行结果。

这不能被简单写成“已被法律确认的恶意软件”。材料能支撑的判断是：这是开源维护者反 AI 使用条款、合规反制和用户风险之间的冲突。

更具体地看，风险不在某一句提示词有多神奇，而在代理执行链太长。

场景文本位置目标对象主要风险
jqwik 1.10工具输出中的指令AI coding agent代理可能误删测试或代码
jqwik 1.10.1工具输出中的改写指令AI coding agent代理可能忽略真实测试结果
恶意 PyPI/npm 载荷代码注释LLM scanner扫描器可能触发拒答，分析被打断

人类开发者看到输出，通常会结合上下文判断。AI 代理则可能把终端输出、日志和错误信息都放进上下文，再生成修改建议，甚至直接执行文件操作。

这里的现实约束很硬：只要代理能读未清洗文本，又有权限改文件、删测试、改依赖，文本就不只是信息，也可能成为攻击面。

对使用 AI coding agent 的开发者，这意味着至少要改三件事：不要给代理默认删除测试的权限；不要让代理在无审批状态下改依赖和提交修复；CI 结果要看退出码、结构化报告和人工 review，不能只让模型解释一屏终端输出。

恶意包的做法更危险：把 LLM 安全拒答变成反分析

Socket.dev 的报告给了另一个参照。其分析的 Mini Shai-Hulud、Miasma 和 Hades 等恶意包中，部分载荷在代码注释里加入关于武器、生物武器、核武器的请求。

目的不是让模型真的回答这些内容，而是诱发 LLM 的安全拒答。这样一来，AI 辅助恶意软件分析可能在读到真正混淆载荷前停住。

这和 jqwik 不是一类事。jqwik 是维护者用条款和输出反制 AI 使用，争议点在边界、责任和用户损失。恶意包是攻击者在供应链攻击里做反分析，目标是削弱防御。

两者放在一起看，能看到同一条缝：LLM 扫描器并不天然站在代码外面。它也在读输入，也会被上下文牵着走，也可能因为安全策略被迫停下来。

传统安全工具早就遇到过反调试、反沙箱、反虚拟机。差别在于，传统规则大多写在代码里，出错路径比较容易复盘。LLM 的拒答、误判和上下文污染更难稳定复现。

这不等于所有 LLM scanner 都会失效。材料也不支持这个结论。更稳妥的说法是：如果安全团队把 LLM 扫描器当成唯一判断来源，风险会变大。

负责依赖审计和恶意包分析的团队，应当把 LLM 放在初筛位置，而不是裁判位置。恶意包分析仍要保留静态规则、反混淆、沙箱执行、包来源审计、凭据泄露检查。LLM 给出的“看起来没问题”，不能直接变成放行依据。

真正该调整的，是权限、审计和采购预期

这件事最影响两类人。

一类是已经把 AI coding agent 接进日常开发的团队。它们要重新检查代理权限：能不能删文件，能不能改测试，能不能改锁文件，能不能自动提交 PR，能不能根据第三方输出执行命令。

另一类是负责依赖审计和恶意包分析的安全团队。它们要重新检查工具链：LLM scanner 的结论有没有证据链，拒答是否会被记录，遇到提示注入型注释时是否能降级到传统分析流程。

采购 AI 安全工具时，也不该只问“能不能自动解释代码”。更该问几件具体问题：

  • 第三方包里的注释、README、日志，会不会被当成高优先级指令？
  • 扫描器触发安全拒答后，是直接停止，还是继续用非 LLM 规则分析？
  • 代理执行文件操作前，有没有强制人工确认？
  • CI 里的测试失败，会不会被模型用自然语言解释覆盖掉？

接下来最该看的变量也很具体。

观察点为什么重要目前能下的判断
AI 代码代理是否隔离第三方输出指令决定日志、测试输出会不会变成命令来源不能假设默认安全
LLM scanner 是否检测提示注入型反分析决定恶意注释能否被识别和降级处理应纳入供应链安全检查
开源条款能否约束 AI 代理调用决定维护者反 AI 使用是否有可执行边界仍有争议，不能简单当成技术问题

我不太买账的是，把这类问题归结为“把系统提示词写严一点”。提示词可以降低部分风险，但不能替代权限控制、审计日志、人工复核和供应链安全流程。

AI 代理不是开发者替身。它更像一个会读很多文本、能执行部分动作的软件组件。既然是软件组件，就要按软件来管：限制输入，限制权限，记录行为，保留回滚。

回到 jqwik 这件事，最刺眼的地方不是某个维护者的态度，而是它用一个小工具证明了一个大前提：当开发流程把文本直接喂给能行动的模型，文本就不再只是说明书。