实战案例复盘：用 ClaudeCodeAgents 完整审计一个认证系统的实现

【免费下载链接】ClaudeCodeAgentsA set of useful QA agents for Claude Code.项目地址: https://gitcode.com/gh_mirrors/cl/ClaudeCodeAgents

开发说"认证系统做完了"，你敢直接上线吗？本文复盘一次真实的认证系统交付审计，看 ClaudeCodeAgents 这套面向 Claude Code 的 QA 智能体集合，如何把"口头完成"变成"证据确凿的验收结论"。

为什么认证系统最需要一次"审计级"验收

认证系统是任何应用的安全命门：JWT 签发、密码重置、会话过期、多租户权限……任何一个环节"看起来能用"，都可能埋下重大隐患。常规的自测只能覆盖快乐路径，而真正的问题往往藏在错误处理、边界条件和集成点里。

ClaudeCodeAgents 恰好是为此而生的工具——它是一套开箱即用的 QA 智能体集合，专门为 Claude Code 扩展代码审查、规范校验、任务完成度验证等能力。与其相信"测过了"，不如让 AI 审计员独立检查一遍。这就是本次实战复盘的主题：用 ClaudeCodeAgents 完整审计一个认证系统的实现。

ClaudeCodeAgents 是什么：一套 QA 智能体全家桶

整个项目由一组 markdown 定义文件构成，每个文件就是一个职责明确的"AI 审计员"，你可以按需召唤、互相协作。核心成员如下：

它们在 README.md 中都有使用场景说明，彼此之间还内置了协作协议（例如 Jenny 发现问题后会建议转交task-completion-validator复核）。

审计路线图：认证系统五步走审计流程

本次审计我们按"需求→功能→质量→规范→实测"五个维度推进，每个维度对应一个专职智能体，避免单一视角的盲区。

第一步：用 Jenny 核对需求与实现的一致性

审计起点是需求文档。把认证规格（如 JWT 过期策略、刷新令牌轮换规则、密码强度要求）交给 Jenny，它会独立阅读代码、数据库 schema 与配置，逐条对照规格输出差距清单。

这一步我们立刻发现了第一个问题：规格要求"刷新令牌 7 天轮换"，但代码里的RefreshTokenLifetime被写成了常量 30 天——规格说 7，实现写 30，这种不一致在人工 review 时很容易被"看起来没问题"糊弄过去。

第二步：用 task-completion-validator 验证功能是否真实可用

接下来验证"功能是否真的能跑"。task-completion-validator的审查方式非常严格：它会检查核心路径是否被 stub、错误处理是否被空 catch 吞掉、测试是否只是在测 mock。

审计中它抓到了两个典型问题：

• 空异常处理：catch (Exception e) { }吞掉了令牌解析失败，用户会收到诡异的 500；
• 假测试：单测只测了mockTokenService，从不走真实签名与验签路径。

这类"测试全绿但一上线就崩"的陷阱，正是认证系统审计里最常见的暗雷。

第三步：用 code-quality-pragmatist 排查过度设计

功能能跑之后，检查复杂度是否配得上需求。code-quality-pragmatist专门打击企业级模式套在 MVP 项目上的过度设计：多余抽象层、杀鸡用牛刀的缓存中间件、三层封装只为调一个接口。

本次它建议砍掉一层ITokenStrategy抽象——项目里只有一种令牌策略，多一层接口纯粹增加心智负担。这个建议同时由Jenny复核：规格并未要求策略可插拔，可以安全简化。

第四步：用 claude-md-compliance-checker 检查项目规范符合性

如果你的项目有 CLAUDE.md，这一步必不可少。claude-md-compliance-checker会逐条比对最近的改动是否违反项目规则，例如"不该创建的文件是否被创建""是否做了需求之外的事"。

审计中发现开发顺手创建了一个docs/auth-notes.md，违反了"除非明确要求，否则不主动创建文档"的项目规则——属于典型的 scope creep，需要回退。

第五步：用 karen 复跑真实场景，做最后兜底

最后请出 Karen——它是唯一坚持"去把代码跑起来"的智能体。Karen 不看代码自我辩解，直接调接口、打数据、查日志。

我们模拟了真实攻击场景：连续 5 次错误密码、跨设备登录、过期令牌访问受保护接口。结果发现"多租户数据隔离"在单租户 fixture 下全通过，但换成真实多租户数据后，查询漏加了tenant_id过滤——只在特定环境下才暴露的高危问题，被 Karen 一跑现行。

实战发现：认证系统最常见的 6 类问题

把五个智能体的报告汇总后，问题清单一目了然：

可以看到：高危问题大多来自"看起来完成"的角落，而 Karen 的实测能力恰好补上了静态审查的盲区。

复盘总结：审计认证系统的 4 条核心经验

1. 多视角交叉审计比单次 review 可靠：需求、功能、质量、规范、实测五路并行，任何单一智能体的盲区都能被队友覆盖。
2. "能跑"和"符合规格"是两件事：Jenny 管规格对齐，task-completion-validator管功能落地，缺一不可。
3. 一定要实测，别只读代码：Karen 的做法（真实调用接口、真实数据、真实日志）是审计的底线。
4. 让智能体之间互相协作：项目内置的跨智能体协议（如file_path:line_number引用格式、统一的严重级别）让多轮审计报告可以无缝拼接。

快速上手：3 步在项目中启用 ClaudeCodeAgents

想在自己的认证系统上复刻这套审计流程？步骤如下：

1. 获取智能体定义：克隆仓库即可拿到全部智能体文件，仓库地址为https://gitcode.com/gh_mirrors/cl/ClaudeCodeAgents，将需要的.md文件放入你的 Claude Code 工作区；
2. 按需召唤：参照 README.md 的场景说明，在对话中指定对应智能体，例如"用 Jenny 核对认证实现与规格"；
3. 串联执行：按 Jenny → task-completion-validator → code-quality-pragmatist → claude-md-compliance-checker 的顺序跑一轮，最后用 Karen 实测收尾。

整个过程零代码侵入——你不需要改一行业务代码，只需要把审计任务交给 Claude Code。

写在最后

认证系统的质量，不该建立在"开发者说做完了"这句话上。ClaudeCodeAgents 的价值，正是把验收从主观承诺变成客观证据：规格有人核对、功能有人验证、质量有人把关、规范有人检查、真相有人实测。下次再听到"认证系统完成了"，不妨让这套 QA 智能体跑一遍，你会看到另一番风景。

【免费下载链接】ClaudeCodeAgentsA set of useful QA agents for Claude Code.项目地址: https://gitcode.com/gh_mirrors/cl/ClaudeCodeAgents