实战测试 LLM 安全护栏：@martin_yeung/llm-up-guardrail 全面评测与避坑指南

在 AI 应用落地中，调用大模型只是第一步，如何拦截诈骗、注入攻击和敏感信息才是真正的考验。本文通过一个开源测试项目，带你深入体验一款 Node.js 护栏库的实际表现，并披露实测中的关键细节。

为什么需要这个测试项目？

开发者常常急于接入各种 LLM 工具，却很少对安全层进行压力测试------直到线上出现违规内容才追悔莫及。为此，我构建了一个轻量级 TypeScript 测试工具 llm-guardrail-test ，专门用于验证 @martin_yeung/llm-up-guardrail 在实际场景中的防护能力。

该项目严格按照官方 README 示例编码，覆盖 6 类典型威胁（提示注入、诈骗、多语言冒充、PII 泄露、品牌仿冒），并提供了断言测试套件，让你可以一键验证效果。

项目结构速览

复制代码

llm-guardrail-test/
├── package.json          # 依赖与脚本
├── tsconfig.json         # TS 编译配置
├── src/
│   └── index.ts          # 演示 6 种输入，打印检查结果
├── tests/
│   └── run-tests.ts      # 8 个断言测试用例
└── README.md

快速开始

bash 复制代码

git clone <repo-url>
cd llm-guardrail-test
npm install
npm run demo      # 运行演示
npm test          # 运行测试套件

核心用法完全照搬官方：

ts 复制代码

import { createGuardrail } from '@martin_yeung/llm-up-guardrail';

const engine = createGuardrail();
const r = await engine.checkInput(userMsg);
if (r.blocked) {
  return respond('检测到可疑内容，无法处理');
}

测试场景与预期结果

演示脚本向同一个引擎发送 6 种输入，输出 blocked、severity、score、findings、sanitized 和耗时（ms）。

序号	类别	预期结果
1	纯技术问题（无害）	✅ 通过（未拦截）
2	提示注入 + DAN + 提示泄露	🚫 拦截
3	英文虚假中奖诈骗	🚫 拦截
4	简体中文冒充客服	🚫 拦截
5	PII + OpenAI API Key	🚫 拦截，且 sanitized 中显示 `[REDACTED:*]`
6	短链接 + 品牌仿冒	🚫 拦截

所有测试用例均通过（npm test 返回 0），但在编写过程中，我们发现了一些值得注意的 实际行为，这些信息对集成开发者至关重要。

⚠️ 实测中发现的关键问题与注意事项

1. 语言覆盖的局限

内置规则目前仅支持 简体中文 的诈骗模式。繁体中文（例如"我是微軟客服 ..."）以及未列入内置名单的品牌（公安、银行客服、淘宝、京东等）不会被拦截。
解决方案 ：通过 AntiScamGuard({ extraRules: [...] }) 自行扩展规则。

2. 英文诈骗需要特定词汇

正则匹配 \b(congratulations|you(?:\s|')ve?\s+won|selected\s+winner|claim\s+your\s+prize|...)\b 可以匹配 congratulations 或 you've won，但 不会匹配 you have won（因为缺少缩写）。编写测试语料时需留意措辞。

3. 版本号滞后

即使安装的是 v0.1.2，require('@martin_yeung/llm-up-guardrail').VERSION 依然返回 '0.1.1'。若你的程序依赖版本常量，请注意此差异。

4. PII 检测较为激进

一个 OpenAI 格式的 API Key 可能同时触发"国际电话号码"模式（详见 PII 测试的红化输出）。这会为同一子串生成两条发现记录，通常无害，但在调优阈值时需考虑。

5. 发布包的入口文件配置错误

官方 package.json 声明 "main": "./dist/index.cjs"，但实际发布的压缩包内只有 dist/index.js（CJS）和 dist/index.mjs（ESM）。安装后若报错 Cannot find module '.../dist/index.cjs'，可执行以下补丁（项目 README 已提供）：

bash 复制代码

node -e "const p=require('./node_modules/@martin_yeung/llm-up-guardrail/package.json');p.main='./dist/index.js';delete p.module;p.exports={'.':{require:'./dist/index.js',import:'./dist/index.js'}};require('fs').writeFileSync('./node_modules/@martin_yeung/llm-up-guardrail/package.json',JSON.stringify(p,null,2));"

（注：该补丁将入口指向实际存在的文件，并删除冗余的 module 字段。）

测试断言具体检查什么？

tests/run-tests.ts 包含 8 个用例，验证：

r.blocked 是否符合预期（布尔值）
r.findings[].category 是否包含期望的类别（针对相关用例）
PII 用例中 r.sanitized 是否包含 [REDACTED 字符串

若有任一失败，进程退出码非零，适合 CI 集成。

总结与建议

这个测试项目不仅验证了 @martin_yeung/llm-up-guardrail 的核心能力，更暴露了实际使用中的 边界情况。对于计划采用该库的团队，建议：

先跑测试套件，确认在你的环境中各项功能正常。
根据业务需求扩展规则（多语言、自定义品牌黑名单）。
关注上游更新，尤其是入口文件修复和版本号同步。
将测试框架融入 CI，确保每次升级不破坏现有防护。

安全护栏不是一劳永逸的，它们需要随着攻击手段的演进而持续迭代。拥有一个可重复的测试工具，能让你放心地调整配置，并对防护效果心中有数。

如果你在实际集成中遇到其他坑点或有改进建议，欢迎留言交流。让我们共同推动 LLM 应用的安全实践！