llm-artifacts-detection

LLM 产物检测

检测并标记 LLM 编码 Agent 引入的常见模式，这些模式会降低代码质量。

检测类别

类别	参考资料	主要问题
测试	references/tests-criteria.md	违反 DRY 原则、测试库本身、模拟边界
死代码	references/dead-code-criteria.md	未使用的代码、TODO/FIXME、向后兼容的冗余代码
抽象	references/abstraction-criteria.md	过度抽象、复制粘贴造成的偏差、过度配置
风格	references/style-criteria.md	显而易见的注释、过度防御、不必要的类型

Agent 提示词

使用这些提示词来启动专注于检测工作的 Agent：

测试 Agent

Analyze the test files for LLM-introduced test quality issues:

1. **DRY Violations**: Look for setup/teardown code repeated across multiple test functions instead of using fixtures or shared helpers. Flag patterns like:
   - Identical object creation in multiple tests
   - Repeated mock configurations
   - Copy-pasted database setup

2. **Library Testing**: Identify tests that validate standard library or framework behavior rather than application code. Signs:
   - No imports from the application codebase
   - Testing built-in functions or third-party library methods
   - Assertions about stdlib behavior

3. **Mock Boundaries**: Flag mocking that's too deep or too shallow:
   - Too deep: Mocking internal implementation details, private methods
   - Too shallow: Mocking at the wrong layer, missing integration points
   - Wrong level: Unit test mocks in integration tests or vice versa

For each issue found, report: [FILE:LINE] ISSUE_TITLE

死代码 Agent

Scan the codebase for dead code and cleanup opportunities:

1. **Unused Code**: Find functions, classes, and variables with no references:
   - Functions never called
   - Classes never instantiated
   - Module-level variables never read
   - Unreachable code after returns

2. **TODO/FIXME Comments**: Flag all TODO, FIXME, HACK, XXX comments that indicate incomplete work

3. **Backwards Compat Cruft**: Look for patterns suggesting removed features:
   - Variables renamed with _unused, _old, _deprecated suffixes
   - Re-exports only for backwards compatibility
   - Comments like "# removed", "# legacy", "# deprecated"
   - Empty functions/classes kept "for compatibility"

4. **Orphaned Tests**: Tests for code that no longer exists:
   - Test files with no corresponding source
   - Test functions testing deleted features

For each issue found, report: [FILE:LINE] ISSUE_TITLE

抽象 Agent

Review the codebase for over-engineering introduced by LLM agents:

1. **Over-Abstraction**: Identify unnecessary abstraction layers:
   - Wrapper classes that just delegate to one method
   - Interfaces/protocols with only one implementation
   - Abstract base classes with single concrete class
   - Factory functions that always return the same type

2. **Copy-Paste Drift**: Find 3+ similar code blocks that should be parameterized:
   - Nearly identical functions with minor variations
   - Repeated patterns that could be a single function with parameters
   - Similar class methods across multiple classes

3. **Over-Configuration**: Flag configuration for non-configurable things:
   - Feature flags that are never toggled
   - Environment variables always set to one value
   - Config options with no production variation
   - Overly generic code for single use case

For each issue found, report: [FILE:LINE] ISSUE_TITLE

风格 Agent

Check for verbose LLM-style patterns that reduce code clarity:

1. **Obvious Comments**: Comments that restate what the code clearly does:
   - "# increment counter" above counter += 1
   - "# return the result" above return result
   - Docstrings that repeat the function name

2. **Over-Documentation**: Excessive documentation on trivial code:
   - Full docstrings on simple getters/setters
   - Parameter descriptions for obvious args
   - Return value docs for self-evident returns

3. **Defensive Overkill**: Unnecessary defensive programming:
   - try/except around code that cannot fail
   - Null checks on values that can't be null
   - Type checks after type hints guarantee the type
   - Validation of already-validated inputs

4. **Unnecessary Type Hints**: Type hints that add no value:
   - Type hints on obvious literal assignments
   - Redundant hints on variables immediately clear from context
   - Over-annotated internal/local variables

For each issue found, report: [FILE:LINE] ISSUE_TITLE

门控（报告）

按顺序执行这些步骤，确保发现有证据支撑，而非推断得出。这是 review-verification-protocol 技能中反臆测门控在检测侧的实例：每个 [FILE:LINE] 都必须来自本轮中刚读取的缓冲区，绝不能根据分支名称、目录或记忆推断。

1. 锚定 — 从已打开的缓冲区、read_file 或等效来源设置 FILE 和 LINE；不要只依赖过时的搜索片段。通过标准：LINE 在 FILE 的行号范围内，且所描述的问题在该行或其紧邻行中可见。
2. 标题 — ISSUE_TITLE 用通俗语言说明缺陷（约一个简短句子），而不是提出修复方案。**通过标准：**打开 FILE 并查看 LINE 的人能看出标题为何适用。
3. 去重 — 最终输出前，合并共享相同 FILE:LINE 且根本原因相同的条目。**通过标准：**每个锚点上的不同缺陷最多对应一个 [FILE:LINE] ISSUE_TITLE。

用法

1. 在审查 AI 生成的代码时加载此技能
2. **如果 Agent 支持子 Agent，**则为每个检测类别并行派发一个；否则自行按顺序处理各类别，并生成相同格式的 [FILE:LINE] ISSUE_TITLE 发现项。
3. 使用参考文件查看详细标准和示例
4. 应用上述门控（报告），然后以 [FILE:LINE] ISSUE_TITLE 格式输出发现项

适用场景

• 清理由 AI 编码 Agent 编写的代码
• 生成后的代码审查
• 减少 AI 迭代生成造成的代码膨胀
• 识别降低可维护性的模式