企业官网建设流程全解析

这次我们来看一个很热的方向：用 AI 辅助挖洞。这里的核心工具是 Claude Code，Anthropic 官方推出的终端编程代理工具。它不是 IDE 插件，而是一个直接跑在终端里的 AI Agent，能读项目代码、搜索文件、执行命令、多轮修改，最后把审计结论整理成报告。

对做 SRC、代码审计、渗透测试的人来说，它的价值不是“自动拿洞”，而是把重复劳动压下去：读代码、找危险函数、梳理接口、生成修复建议，这些都能交给它。更关键的是，它在本地不是重模型，不吃显卡、不占显存，硬件门槛几乎为零；真正消耗的是模型 API 的 token。

这篇文章会从零开始：装 Node.js、安装 Claude Code、配置模型 API、启动交互式对话、做一轮代码审计、写批量任务脚本，再讲常见报错怎么处理。适合两类人：刚接触 AI 编程助手的安全新人，以及想把日常代码审计流程化的 SRC 玩家。

1. Claude Code 核心能力速览

先把大家最关心的规格和门槛列出来，后面再逐个展开。

这里要澄清一点：Claude Code 本身不做本机大模型推理，也不是漏洞扫描器。它是一个能理解代码、能调用终端工具的 Agent，相当于把“代码审计员 + 命令执行器 + 报告助手”打包成了一个命令行程序。所以别把它当成 nmap 或 SQLMap 的替代品，它更适合做“需要理解和推理”的审计任务。

2. 适用场景与安全边界

2.1 适合谁、解决什么问题

• SRC 漏洞挖掘者：接到的授权测试项目往往代码量大，人工读全量源码不现实。Claude Code 可以先做粗筛，把危险函数、外部输入入口、权限校验缺失位置标出来，你只需要针对可疑点做人工确认。
• 安全工程师：日常代码审计、上线前自查、第三方组件风险评估，可以用它快速生成审计草稿，再人工复核。
• 开发人员：修复漏洞时让 AI 解释漏洞原理、给出修复建议，比自己翻文档快很多。
• 安全教学场景：拿一个授权靶场项目，让 AI 一行行解释漏洞成因，比看文字教程直观得多。

2.2 不适合什么场景

• 未获得授权的目标：绝对不要用 Claude Code 去审计、扫描不属于你的系统。
• 大规模指纹识别、端口扫描、漏洞批量探测：这些不是 Claude Code 的强项，建议交给专业扫描器。
• 本地离线模型场景：Claude Code 默认依赖云端模型 API，需要网络可达，并非一个本地离线大模型工具。
• 完全无人值守的自动挖洞：当前 Agent 的准确性还不足以替代人类判断，必须保留人工复核环节。

2.3 合规边界

用 AI 辅助挖洞，前提永远是授权。SRC 平台测试要在平台规则允许的范围内进行，企业内部审计要有书面授权，代码样本要脱敏，涉及用户数据的文件不要喂给云端模型。以下几点必须刻在脑子里：

• 只处理你拥有或已获授权的代码与系统。
• 不把敏感业务数据、客户信息、密钥文件作为 prompt 内容发送。
• 测试环境与生产环境隔离，批量任务优先指向本地搭建的靶场。
• AI 给出的结论只能作为参考，所有漏洞必须人工验证后再写入报告。

这一点我会在后面的批量任务部分再强调一次，因为批量模式下最容易“跑过头”，一个脚本把不该扫的目录全部扫了一遍。

3. 本地部署环境准备

Claude Code 是一个 Node.js 命令行工具，环境准备比本地大模型简单很多，不装 CUDA，不配显卡驱动。

3.1 操作系统

Windows 10/11、macOS、常见 Linux 发行版都可以。Windows 下建议用 PowerShell 或 Windows Terminal，也可以用 Git Bash 跑 bash 脚本。本文的批量任务示例会同时给出 bash 思路，方便在 Git Bash、WSL 或 macOS/Linux 下直接使用。

3.2 Node.js

Claude Code 依赖 Node.js，官方要求 Node.js 18 及以上版本，建议直接用 LTS 版本。

先检查本机是否已安装：

node -v npm -v

如果提示找不到命令，需要先安装 Node.js。安装完成后重新打开终端，再次确认版本。

3.3 网络与 API 密钥

Claude Code 默认调用 Anthropic 的模型 API，因此需要能够访问模型 API 服务，并准备好 API Key。如果你使用的是兼容 Anthropic 接口的第三方模型服务，则需要准备：

• API 接口地址（Base URL）
• API Key
• 该服务实际支持的模型名

这部分会在下一章展开，先知道需要这三样东西就行。

3.4 磁盘空间和端口

Claude Code 本体是一个 npm 包，安装后占用磁盘空间很小，一般几百 MB 以内，大头是全局缓存和日志。它默认不启动 Web 服务，所以几乎不占端口；但如果你的项目里有自动化脚本或插件启用了本地服务，仍要注意端口冲突。

建议准备一个专门的工作目录，用来放授权测试的源码副本、输入素材、输出报告和日志，避免和日常工作目录混在一起。

4. 安装 Claude Code 与模型接入

4.1 安装 Claude Code

使用 npm 全局安装：

npm install -g @anthropic-ai/claude-code

安装完成后查看版本：

claude --version

如果能正常输出版本号，说明主体安装成功。如果出现claude 不是内部或外部命令，一般是 npm 全局 bin 目录没有加入 PATH，重新安装 Node.js 或手动把 npm 全局目录加入环境变量即可。

4.2 配置模型 API

Claude Code 支持两种主要认证方式：

• 使用 Claude 官方账号登录，走 Claude 订阅或官方 API 计费；
• 使用 API Key 环境变量，适合脚本化、自动化场景。

使用 API Key 时，在终端里配置环境变量。Linux / macOS 下：

export ANTHROPIC_API_KEY="你的-API-Key" export ANTHROPIC_BASE_URL="https://api.example.com" export ANTHROPIC_MODEL="你的模型名"

Windows PowerShell 下：

$env:ANTHROPIC_API_KEY = "你的-API-Key" $env:ANTHROPIC_BASE_URL = "https://api.example.com" $env:ANTHROPIC_MODEL = "你的模型名"

注意几个点：

• ANTHROPIC_BASE_URL只有在使用第三方兼容接口时才需要配置，直接用官方 API 时不需要。
• ANTHROPIC_MODEL必须填服务商实际支持的模型名，不能随便填。填错会出现类似xxx is not a model this version of claude code recognizes的报错。
• 环境变量只对当前终端窗口生效。要长期生效，可以把 export 写入~/.bashrc或~/.zshrc，PowerShell 用户可以用setx或写入$PROFILE。

这种环境变量方式的优点是很干净，不污染系统配置，适合在多个项目之间切换不同的模型服务。缺点是你得记住当前终端用的是哪套配置，别切了目录忘了环境变量。

4.3 验证模型连接

配置完环境变量后，先跑一个最简单的命令，确认模型可以直接对话：

claude -p "你好，请用一句话介绍你自己"

如果正常返回一段自我介绍，说明 API Key、Base URL、模型名三个配置都通了。接下来就可以进入正式项目。

5. 第一次启动与基础功能测试

5.1 进入项目目录启动

准备一个已获得授权的测试项目，进入目录后启动交互式 Claude Code：

cd /path/to/your-authorized-project claude

启动后你会进入一个交互式终端界面，可以像聊天一样输入指令。Claude Code 会自动感知当前目录下的文件结构，并在执行命令前请求你的确认。这是它的安全机制：Agent 要执行 shell 命令或修改文件时，会让你先点头。

这里建议第一轮先用“只读”指令，不要让它马上改代码。

5.2 基础功能测试

进入交互界面后，按顺序测试几个能力：

• 代码解释：让它解释当前项目是干什么的。
• 文件定位：让它找到某类功能对应的文件。
• 危险点分析：让它找出项目中需要注意的安全风险。

例如输入：

请解释这个项目的整体结构，重点说明用户输入是如何进入数据库查询的。

观察它的输出：是否准确找到了对应文件，是否给出了文件路径和行号。如果连路径都给不出来，大概率是上下文窗口限制或项目文件过大，需要先在CLAUDE.md或 prompt 里限定目录范围。

这一步的核心目的是判断“这个模型是否可靠”。AI 审计代码时最怕的不是“说错”，而是“一本正经地编漏洞”。所以首次测试一定要拿你已知有问题的旧代码来验证，确认它的判断逻辑和你一致，再放它去做大面积扫描。

6. 挖洞实战：代码审计功能验证

6.1 单文件审计测试

先从单个文件开始，这是最可控的测试维度。比如一个登录接口文件src/login.php，输入：

请审查 src/login.php 中的登录逻辑，重点检查： 1. SQL 注入风险：用户输入是否被直接拼接进 SQL 2. 身份认证绕过：是否存在可绕过的校验逻辑 3. 敏感信息泄露：是否输出内部错误信息 4. 密码存储：是否使用了弱哈希算法 输出格式：风险类型 | 文件:行号 | 危害等级 | 修复建议

判断标准是：

• 每条风险是否对应到真实代码位置；
• 危害等级是否合理；
• 修复建议是否可执行；
• 有没有把安全的代码误报为漏洞。

如果单文件测试通过，再扩大范围到目录级。

6.2 项目级审计测试

对一整个业务模块做审计时，prompt 要更收敛，避免让 AI 一口气扫整个仓库，那样 token 成本高且容易走神。建议按模块分批处理：

你是资深 Web 安全审计专家。请审查 src/controllers 目录下的文件，找出所有从外部获取用户输入并进入危险函数的路径。 重点关注：request 参数、$_GET、$_POST、req.query、req.body 等输入来源，以及 SQL 拼接、命令执行、文件包含、文件上传等危险出口。 输出：漏洞类型 | 文件:行号 | 输入来源 | 危险出口 | 修复建议。

这里有一个实战经验：让 AI 把“输入来源”和“危险出口”分开列，比直接让它找漏洞要准确得多。因为大模型对“漏洞”的判断偶尔会发散，但“输入来源跟踪”和“危险函数匹配”是更机械的任务，准确率更高。先列出可疑调用链，再人工复核，比让它直接下结论可靠。

6.3 接口清单与攻击面梳理

挖 SRC 时经常遇到一个新项目，代码量几万行，接口散落在不同文件里。手工梳理接口要几个小时，用 Claude Code 可以快速生成接口清单：

扫描当前项目，列出所有 HTTP 接口定义。 格式要求：HTTP 方法 | 路由 | 控制器/处理函数 | 是否需要登录 | 是否校验权限 | 接收的主要参数。

生成后，这份接口清单就是攻击面地图。你可以重点看那些不需要登录、没有权限校验、接收文件上传参数的接口，这些都是人工验证的高优先级对象。

6.4 漏洞报告自动生成

找到可疑点后，可以让 Claude Code 帮你把记录整理成标准报告：

根据我们刚才的审计结果，把以下问题整理成 SRC 漏洞报告： 漏洞标题、所属模块、影响版本、漏洞描述、复现步骤、修复建议、参考链接。 请用 Markdown 输出，每个漏洞单独一个小节。

注意：报告只能作为草稿，里面的复现步骤必须人工跑通后再提交。SRC 平台对无效漏洞的惩罚很明确，AI 生成的不实内容是踩坑重灾区。

7. 批量任务：用非交互模式做自动化扫描

Claude Code 交互模式适合“人在回路”的精细操作，批量场景要用claude -p非交互模式。

7.1 单条非交互调用

最简单的非交互调用：

claude -p "请审查 src/login.js，列出安全问题" --output-format text

指定 JSON 输出，方便后续程序解析：

claude -p "审计 src/api/user.php，用 JSON 输出：漏洞类型、文件、行号、危害等级、修复建议" --output-format json > result.json

result.json可以直接用 Python 或 jq 做二次处理，比如只提取高危漏洞。

7.2 目录级批量审计脚本

下面是一个 bash 脚本示例，思路是遍历指定目录下的源码文件，逐个调用 Claude Code 审查，并把结果追加到报告文件里。实际路径、文件类型、prompt 需要按项目调整。

#!/bin/bash AUDIT_DIR="./src" OUTPUT_DIR="./audit-logs" mkdir -p "$OUTPUT_DIR" for f in $(find "$AUDIT_DIR" -name "*.php" -o -name "*.js"); do echo "=== 正在审查: $f ===" | tee -a "$OUTPUT_DIR/audit_report.md" claude -p "你是 Web 安全审计专家。审查文件 $f，输出漏洞类型、位置、危害等级、修复建议。如果没有问题，只输出 'NO_ISSUE'。" \ --output-format text >> "$OUTPUT_DIR/audit_report.md" 2>&1 sleep 2 done echo "审计完成，报告输出到 $OUTPUT_DIR/audit_report.md"

这个脚本有几个设计要点：

• sleep 2是基础限速，避免请求过于密集触发 API 限流；
• 2>&1把错误日志也写入报告文件，方便排查；
• prompt 里加了“如果没有问题，只输出 NO_ISSUE”，避免 AI 对每个文件都长篇大论，省 token 也方便 grep；
• 指定了find的文件类型，避免把node_modules或vendor目录也扫进去。

7.3 失败重试与日志

批量任务最大的坑是“中途卡住还不知道卡在哪个文件”。所以必须写日志。参考上面的脚本，tee -a会同时把输出打到终端和文件。如果某个文件调用失败，可以先看日志定位到具体文件，再单独重跑：

claude -p "审查 ./src/error.php" --output-format text 2>&1 | tee -a "$OUTPUT_DIR/retry.log"

更稳妥的做法是给脚本加失败重试和超时控制。比如记录当前文件索引，重启脚本时跳过已完成的文件，这样即使中途断了也能续跑。

7.4 批量任务的合规红线

再强调一次：批量任务脚本必须设置严格的文件范围白名单，只放行授权项目的源码目录。不要把find的根目录写成/或用户主目录，否则可能把敏感配置、数据库备份、密钥文件当成审计对象，喂给云端模型。批量任务之前，先手动find一遍，确认扫出来的文件清单里没有不该出现的文件。

8. 资源占用与性能观察

8.1 本地资源占用

Claude Code 是纯终端工具，本地不跑大模型推理，所以不占 GPU、不占显存。资源占用主要来自：

• Node.js 运行时本身，内存占用通常很低；
• 项目文件的读取和索引，大项目会多一些内存；
• 终端渲染和日志输出，可以忽略。

对“显存占用”敏感的朋友可以放心：这个工具不吃显卡，普通办公本、云主机、服务器都能跑。

8.2 成本与延迟

真正的成本在模型 API 的 token 消耗。每次调用都会把系统 prompt、项目上下文、你的输入和模型输出折算成 token。以下因素会显著影响消耗：

• 项目文件数量：一次性加载整个仓库，token 消耗很大；
• 上下文长度：对话轮次越多，历史记录越长；
• 输出长度：让 AI 写长报告比让它输出要点消耗更大；
• 模型选择：不同模型定价不同，实际费用以服务商计费为准。

从实际使用角度，建议先用小范围测试控制成本，不要一上来就让 AI 扫描整个仓库。

8.3 如何观察和优化

在交互模式下，Claude Code 会显示当前会话的 token 使用情况，留意上下文使用比例。当上下文接近上限时，及时开启新会话或让 AI 先总结当前结论，再开始下一轮。

优化手段：

• 用.gitignore或提示词排除node_modules、vendor、dist等目录；
• 单轮审查只针对一个模块或一个文件，不要贪多；
• 需要全项目梳理时，先让 AI 生成文件索引，再按索引分批审查；
• 报告类任务放到最后一步，避免长输出抢占上下文。

8.4 进程残留与端口问题

批量脚本如果在中途被杀掉，可能残留 Node.js 进程。再次运行前先查看进程：

ps aux | grep claude

Windows 下可以用任务管理器结束残留进程。虽然 Claude Code 默认不监听端口，但部分集成功能或本地辅助服务可能存在端口占用，遇到“端口被占”类错误时，优先查是否有残留进程，而不是盲目换端口。

9. 常见问题与排查方法

这里单独说一下模型名报错。这个错误在网上讨论度很高，普遍原因是用户配置了第三方模型，但模型名和当前 Claude Code 版本不认识。解决办法不是改代码，而是把ANTHROPIC_MODEL或启动参数里的模型名改成服务商实际提供的模型名，或者直接不指定模型名，让客户端使用默认模型。

10. 最佳实践与使用建议

10.1 先小后大，先单后批

第一次使用不要直接上批量脚本。先在交互模式下用单文件审计验证模型的判断能力，确认它确实能给出可用的文件路径和行号，再扩大到模块级，最后才写批量脚本。批量任务上线前，先用 3 到 5 个文件跑通，确认输出格式和 token 消耗在你预期范围内。

10.2 一套最小可运行配置

建议把常用配置固化下来，避免每次重新拼参数。可以在项目根目录放一个CLAUDE.md，写入项目背景、技术栈、审计范围、禁止扫描的目录。Claude Code 会自动读取这个文件作为上下文，这样每次启动它都会自动遵守你的约束。

CLAUDE.md 示例内容：

# 项目约束说明 这是一个已获得授权的 SRC 测试项目。 技术栈：PHP + MySQL。 审计范围：src/ 目录。 禁止扫描：vendor/、node_modules/、config/.env 等敏感目录。 输出要求：所有审计结论必须给出文件路径和行号。

10.3 目录管理

把输入、日志、输出分开管理：

project/ ├── src/ # 授权代码副本 ├── audit-logs/ # 批量任务日志和原始结果 ├── reports/ # 最终漏洞报告 └── prompts/ # 常用 prompt 模板

这样批量任务中途挂掉，你也知道去哪里找断点。

10.4 人工复核是底线

AI 生成的漏洞清单可以帮你省时间，但不能直接交出去。每个漏洞必须人工确认：

• 漏洞是否真实存在；
• 影响范围是否符合实际；
• 修复建议是否适用于当前代码版本；
• 复现步骤是否能在测试环境跑通。

10.5 数据脱敏与隐私保护

不要把真实业务库的备份、用户手机号、身份证号、支付记录等数据放在审计目录里。给 Claude Code 的输入要遵循最小必要原则，只给代码文件，不给业务数据。批量脚本里要增加文件名黑名单，排除.env、backup.sql、*.pem、*key*等文件。

10.6 合规与授权检查单

每次开工前确认三件事：

• 测试对象是否已获得书面授权；
• SRC 平台是否允许使用 AI 辅助工具；
• 输出报告是否包含可公开的敏感信息。

这三项都通过后，再开始实际测试。

最后给一个能直接落地的检查清单：先在一个小型授权项目里跑通单文件审计，确认模型输出能落到报告文件；确认 prompt 能稳定输出“文件路径 + 行号 + 修复建议”；再上批量任务，限制并发，加日志，加断点续跑；全部结果人工复核后，才进入正式报告流程。

Claude Code 的定位是审计助手，不是全自动挖洞系统。把这个边界想清楚，它就能实实在在提高你的 SRC 测试效率。建议收藏备用，等你有授权测试项目的时候，直接照这套流程走一遍。