RepoIntermediate

Sentinel：审查你的 AI 所写代码的守护者（并把修复方案带给你）

当你用 AI 构建时，速度背后藏着一个风险：AI 是以"构建者模式"在写代码——乐观、想象着一切顺利——而它对自己的 bug 是盲目的。一个泄露到 git 的密钥、一条会让别的客户看到你数据的查询、一个用键盘的用户根本按不到的按钮。Sentinel 是一个你安装到你的 agent 里的守护者，它会从 18 个方面审查代码，而它和其他一切工具的区别是压倒性的：它不只指出问题，还把最小修复方案以及防止问题重现的测试一起交给你。它免费，住在 GitHub 上，在这里我会教你什么时候用它、为什么它重要，以及如何用一条命令安装它。

Jun 25, 202612 min

这是给谁的？

给任何用 AI 构建软件的人——哪怕你不会编程。如果你让一个 AI 帮你做一个 app、一个后端或一个函数，它会替你写代码……但没有人来审查它有没有留下漏洞。这份资源给你一个免费的守护者，它会替你审查，并用人话向你解释。你不需要懂安全：这个守护者替你懂。

1. 那个时刻：当 AI 写代码的速度超过了你审查的速度

那个时刻总是以同样的方式到来。你对你的 AI 说"帮我做我 app 的登录"，三十秒后你就有了能跑的代码。你测了一下，能进去，它能用。你转向下一个功能。再下一个。AI 产出的速度快到你作为一个人根本没法一行一行地审查。就是在这个确切的时刻，那个沉默的风险出现了。

因为 AI 写代码不像一个多疑的审计员。它是以我们所说的"构建者模式"在写：乐观、想象着唯一的一条顺利路径、专注于"让它能跑"。而在那个模式下，它从物理上就无法看见自己的 bug——就像你没法给自己挠痒痒一样。代码是能跑，没错。但"能跑"和"是安全的"是两回事。

这样想象一下

构建就像匆忙地做一桌宴席：你专注于把菜端出去，而不是你有没有把煤气开着没关。审查是相反的心态：走进那间空的、冷的厨房，寻找有什么可能会着火。这是两个不兼容的大脑。Sentinel 就是那第二个大脑——那个事后拿着手电筒进来、寻找你在做菜时看不见的那个开着的煤气的人。

2. 那份痛：AI 看不见的 bug 才是最贵的

这份痛是真实而诚实的——它不是世界末日，而是一场代价高昂的事故。以下是 AI 一次又一次无意中留下的经典故障：

"构建者模式"看不见的东西

一个密钥（一个 API 密钥、一个密码）被直接写进代码并上传到 git——它会永远留在那里，哪怕你事后删掉。

一条忘了按用户过滤的数据库查询 → 一个客户可以看到另一个的数据。这是任何多用户 app 中最贵的故障。

一个没有访问保护的 endpoint：任何拿到 URL 的人都能进去。

一个用鼠标能用、但对于用键盘或读屏软件浏览的人却是隐形的按钮（一个无障碍故障，有时还是违法的）。

个人数据（邮箱、电话）被无意中写进了日志。

真正让人痛的不是 bug 本身：而是你什么时候发现它。你会在一个用户投诉时、有人把数据泄露出去时、罚单送到时才发现。到那时它已经上生产了。一个 bug 的成本随着它被发现所花的时间而增长——而 AI 看不见的那些，恰恰是最晚才浮出水面的。

能解释这一切的那个数据

一个在每一步都有 85% 命中率的 agent 听起来不错……直到你把 8 步串起来：0.85⁸ ≈ 端到端 27% 的成功率。错误不在于不用 AI——而在于没有第二个大脑来审查第一个放过去的东西。那就是 Sentinel。

3. 那个习惯：审查不是一次性的，而是每次 AI 碰代码时都要做

这里是那个改变行为、而不只是改变认知的关键：Sentinel 不是那种用一次就完事的东西。它是一个习惯。每次你的 AI 写或改重要代码时，你都在把它当作合格之前让 Sentinel 审查一遍。就像系安全带：你不是"想起来才做"，你总是做，自动地做。

那些你总是应该把代码交给 Sentinel 的时刻：

这个习惯的 4 个时刻

在你把 app 上生产（让全世界看到它）之前 → "这个安全吗？"。

当 AI 碰了敏感的东西时：登录、支付、数据库、用户数据。

在接受一个改动之前审查它时（一个 PR、一个新分支）。

每隔一段时间做一次总体复查——因为昨天还安全的东西可能被今天的一个改动弄坏了。

Sentinel 的黄金法则

Sentinel 不会停在"这里有个问题，祝你好运"。它遵循一条适用于所有严肃工程的法则："没有测试，修复就没做完"。所以，对于它确认的每一个真实 bug，它给你带来两样东西：最小修复方案，以及一个回归测试——一个小小的检验，确保那个 bug 永远不会再回来。抓到 bug 是一半；把它永远封死是另一半。

4. 它到底审查什么：18 个方面

Sentinel 从 18 个维度扫描，分成两大组。你不必全部理解它们——但看到它们能让你体会到它替你做的事有多大：

8 个经典安全维度：代码里的密钥、没有保护的 endpoint、跳过按用户过滤的查询、在规模上会变得极慢的数据库配置、放错的安全响应头、日志里的个人数据、未经验证的输入，以及有已知漏洞的依赖。

10 个"构建者模式的盲点"：AI 在构建界面和逻辑时一次又一次犯下的那些反复出现的 bug——把 Enter 从聊天框里偷走的键盘快捷键、对键盘隐形的按钮、微妙的内存泄漏、重复的标识符、被静默吞掉的错误。这第二组是那个秘密配方：它诞生于一套在许多轮真实审计中打磨出来的质量协议，而不是网上一份通用的清单。

让它可靠（而不吵闹）的东西

对任何扫描器的恐惧都是它会把你淹没在误报里。Sentinel 做的是另一回事：对每一个疑点，它在上报之前先试着自己反驳它（会不会是误报？那个"密钥"只是个示例？那条查询真的是多用户的吗？）。它只上报那些经受住了这个怀疑的东西。5 个真实的发现胜过 20 个吵闹的。

5. 怎么安装：一条命令

Sentinel 是一个 Claude Code 的 skill（那个在你终端或编辑器里工作的 AI 助手）。它一条命令就能装好，然后在你所有项目里都可用。如果你用 Claude Code，这就是你唯一要输入的东西：

bash

/plugin marketplace add MentexDev/neuralos-sentinel
/plugin install neuralos-sentinel@neuralos-sentinel

用的是别的助手（Cursor、Codex、Gemini CLI）？Sentinel 遵循开放的 skills 标准，所以在那里也能用 npx skills add MentexDev/neuralos-sentinel 跑起来。装好之后，你不用什么奇怪的命令去调用它：你正常地对你的 AI 说话就行。

最简单的方式：直接跟它说

装好之后，你什么都不用记。你对你的 AI 说这样的话："用 Sentinel 扫描这个项目"、"这段代码在上传之前安全吗？" 或者 "审查这个改动，找找安全 bug"。AI 会识别出意图并自己激活这个守护者。就这么简单。

6. 可以直接复制的 prompt

为了让你不用去想该说什么，这里给你完整的、从头到尾的 prompt。把它粘进你的 agent（Sentinel 已经装好），填上 [方括号]，然后让守护者去干它的活：

用 Sentinel 审计我的代码text

我想让你用 neuralos-sentinel skill 扫描我的代码，以 read-only 模式（没有我的 OK 不要改任何东西）。

要审查的目标：[整个项目 / 这个文件夹 / 这个文件 / 你做的最后一个改动]
技术栈 / 技术：[比如 Next.js + PostgreSQL 数据库，或"不确定，看代码"]
上下文：[比如 "这是一个有多个用户/客户的 app，所以数据绝不能混在一起" · "它有登录和支付" · 你知道的任何信息]

遵循 Sentinel 的流程：扫描 18 个维度，对每个发现进行 VERIFICA（核实，排除误报），并给我一份按严重程度排序的报告。对每个真实问题：用人话告诉我它是什么、它在哪个文件里、为什么它重要、提议的修复方案以及封死它的测试。最后给一个"我审查了并排除了什么"的板块，好让我相信你没有编造警报。

先不要应用任何改动：先给我看报告，由我来决定修什么。

7. 轻松之路：谁做什么

因为 Sentinel 住在你的代码 agent 里面，最好搞清楚什么是通过聊天发生的，什么是你做的。这比看上去简单：

agent 自己做的（通过聊天）

读你所有的代码并从 18 个方面扫描它。

核实每个发现，好不给你误报。

给你写清晰的报告，附上每个真实问题的修复方案和测试。

你来决定的（一次点击 / 一个"好"）

批准你想让它应用哪些修复（Sentinel 是 read-only 的：没有你的许可它不碰任何东西）。

真正地轮换一个曾经暴露过的密钥（那要在服务商的面板里、通过网页去做）。

决定一个发现是否适用于你的情况（你才了解你的业务）。

诚实：Sentinel 不是什么

它不是魔法，也不是一个能抓住一切的杀毒软件。它是一张针对最常见、最昂贵故障的高置信度网——它不能替代一次为银行做的专业安全审计。而且因为分析是由你的 AI agent 做的，代码会在那个 agent 运行的地方被处理（就像你交给它的任何请求一样）。Sentinel 不增加任何通往第三方的出口通道：它找到的东西都留在你的会话里。