企业官网建设流程全解析

最近在折腾 IDE 侧 AI 编程工具时，不少朋友问我：现在 Claude Code 这么火，能不能直接在 IDEA 里用，而不是开个终端切来切去？答案是能，而且不仅能接 Claude Code，还能把国内的 GLM 也一起集成进去。配置好之后，代码生成、解释、重构、写单测这些操作都能在编辑器里直接完成，流程顺了很多。

这篇文章我把整套过程完整梳理一遍，从选型、配置到实战，再到踩坑记录，所有步骤都是实测过的。适合已经装了 JetBrains 系 IDE（IDEA、PyCharm、WebStorm 等）、想给自己配一套 AI 编码助手但又不想完全抛弃原有开发习惯的同学参考。

1. 内容整体设计与思路拆解

1.1 为什么要把 Claude Code 和 GLM 集成进 IDEA

先说痛点。Claude Code 的能力确实强，尤其在理解长上下文、生成高质量代码、写测试用例这些场景下表现突出。但默认它是跑在终端里的，而大部分 Java、Kotlin、Python 开发者的主战场是 IDEA。来回切窗口、复制粘贴代码片段、再把结果粘回去，这种操作极其打断心流，效率反而下降了。

另一个实际问题是价格和网络。Claude 的 API 按 token 计费，国内直连稳定性也很一般。而 GLM 有国内可用的 API 端点，还有免费的模型档位，处理日常任务完全够用，成本敏感场景下是很好的补充。

把两者同时集成到 IDEA 里，本质上就是做一个“双引擎”的工作台：Claude Code 负责重活，比如跨文件重构、生成整套测试、分析复杂 Bug 根因；GLM 负责轻量任务，比如方法注释、单函数生成、代码翻译、日常问答。两条通道并存，既保住了质量，又控制住了成本。

我在实际使用中最大的感受是：这消除了“AI 在另一个窗口”的割裂感。代码上下文不落地，找文件、看报错、改代码全部在 IDEA 内部完成，这才是 IDE 集成 AI 的正确打开方式。

1.2 选型思路：走“外部工具 + 终端模拟”路线

将 Claude Code 和 GLM 接入 IDEA 的现有插件市场里其实已经有第三方 AI Assistant 插件，比如一些能对接 Anthropic API 的插件，但大多有几个问题：更新不及时、支持模型列表不完整、配置繁琐、偶尔还有隐私顾虑。更重要的是，这些插件往往套了一层自己的 UI 和提示模板，没法完全发挥 Claude Code 原生命令、多文件编辑、自动测试执行这些能力。

我选择的方案是：保留 Claude Code 和 GLM 原生命令行工具，通过 IDEA 的 External Tools 和自定义运行配置把终端命令和编辑器交互打通。这样有四个明显优势：

• 命令行工具的版本更新由官方控制，IDEA 集成层只需要调用，不接触到核心逻辑。
• 原生的会话管理、文件读写能力、工具调用能力都能保留，不是套壳。
• 切换模型时只需要改环境变量或配置文件的 model 字段，不用换插件。
• GLM 这种国内模型同样适用，配置方式完全一致，只是 API Base URL 和模型名称不同。

在实际配置之前，我强烈建议先在系统终端里把 Claude Code 和 GLM 的命令行工具跑通一次，确认 API Key 有效、能正常对话，再进入 IDEA 集成阶段，不然后面排错很难分清是工具问题还是 IDEA 配置问题。

2. 核心细节解析与实操要点

2.1 前置条件与工具安装

在开始之前，确认以下环境：

• JetBrains 系 IDE 版本在 2023.1 或更高（我用的是 IntelliJ IDEA 2024.1，低版本也能跑，但部分 UI 配置入口位置可能不同）。
• JDK 17 及以上（用于 IDEA 本身和某些工具链）。
• Node.js 18 及以上（Claude Code 原生基于 Node 运行时）。
• 一个有效的 Claude API Key。
• GLM 平台的 API Key 和 API Base URL，例如https://open.bigmodel.cn/api/paas/v4（以平台实际开通为准）。

安装的命令在 macOS 上大致是：

# 安装 Claude Code（npm 方式） npm install -g @anthropic-ai/claude-code # 验证 claude --version

如果用的是 GLM 的官方命令行工具，通常是 Python 包方式：

pip install zhipuai # 或按官方文档安装对应 CLI

这里有个容易踩的坑：macOS 上 Node 版本太旧会导致 Claude Code 安装失败或运行时异常，建议直接用 nvm 装一个 LTS 版本。Windows 环境则要确保 PATH 里能看到 node.exe 和 npm 目录，不然 IDEA 调外部工具时会报“Cannot run program”之类的错误。

2.2 API Key 与模型配置

Claude Code 默认通过环境变量读取 API Key，常见变量名是ANTHROPIC_API_KEY。为了方便切换多个 Key，我建议不要写死在系统配置里，而是通过 IDEA 的 Environment Variables 功能传入。

GLM 这边则通常是ZHIPUAI_API_KEY，或者你用的 SDK 自定的变量名。以下是两种在 IDEA 中传环境变量的方式：

方式一（全局生效）：在 IDEA 的 Help -> Edit Custom Properties 或系统 shell 配置文件中写入：

export ANTHROPIC_API_KEY="sk-ant-xxxx" export ZHIPUAI_API_KEY="xxxx.yyyy"

方式二（推荐，只在工具运行时生效）：在 External Tools 或 Run Configuration 里配置环境变量，不会污染全局。

我更推荐方式二，因为 API Key 只出现在项目级别的运行配置里，换项目、换 Key 都方便，也不会写到全局配置文件里被人误读。

还有一点要特别提醒：不要把这些 Key 提交到 Git 仓库。IDEA 的 Run Configuration 默认会写入.idea/runConfigurations/目录，如果团队共享配置，注意排除或使用本地覆盖机制，这是我见到的最高频安全事故。

2.3 IDEA 集成层：External Tools 的定位与局限

IDEA 的 External Tools 是一个“调用任意外部命令并把输出展示在控制台”的机制。它很适合用来接命令行 AI 工具，因为不需要写插件，也不需要编译什么代码，配置几分钟就能跑起来。

不过 External Tools 有几个固有局限，你需要提前知道：

• 它只负责启动一个进程，不会把你的代码选区、当前文件路径自动传给命令，需要靠变量传参。
• 输出是纯文本，没有流式渲染或富文本选项，代码块会以纯文本形式显示。
• 没有原生的“会话保持”功能，每次调用都是独立进程。如果你需要连续多轮对话，必须在命令中指定--resume或--continue之类的参数。

这些局限在实际使用中可以通过一些小技巧弥补。比如通过--input-format把选中内容以文件形式传给工具，或者用一个 wrapper 脚本把每次调用的会话 ID 缓存下来，下次运行自动带入。

2.4 运行配置：支持参数、输出、热切换

IDEA 的 Run Configuration 比 External Tools 稍微“重”一点，但它支持：

• 下拉参数输入，方便切换模型或任务模式。
• 更精细的输出过滤，比如只显示标准输出。
• 独立的环境变量配置界面。
• 可以绑定快捷键，调用非常顺手。

我个人的最终方案是“双轨制”：一个 External Tool 跑交互式 Claude Code（terminal 模式），一个 Run Configuration 跑非交互单次任务（CLI 模式）。前者适合边写代码边问问题，后者适合批量任务，比如一键分析整个模块的代码质量。GLM 也类似，跑单次任务居多，适合轻量问答和代码补全。

3. 实操过程与核心环节实现

3.1 创建 IDEA 外部工具入口

先打开 IDEA 的 Settings/Preferences -> Tools -> External Tools 界面，点击加号新增。我给自己的配置起了个名字叫 “Claude Code Here”。

Program 字段填 Claude Code 可执行文件路径。macOS 上一般在/opt/homebrew/bin/claude或者/usr/local/bin/claude，Windows 上则可能是C:\Users\用户名\AppData\Roaming\npm\claude.cmd。如果你用了 nvm，路径可能要写成~/.nvm/versions/node/v18.20.4/bin/claude。建议先用which claude查清楚。

Arguments 字段可以传这些参数：

--model claude-sonnet-4-20250514 --input-format text --output-format text --verbose

其中--verbose会把详细的 token 使用、耗时都打出来，方便观察成本。

Working directory 用 IDEA 自带的宏：

$ProjectFileDir$

这表示把当前项目根目录作为工作目录，Claude Code 才能正确读取项目结构和上下文。

Environment variables 里填入：

ANTHROPIC_API_KEY=$Prompt$|请输入API Key（首次）

实际上$Prompt$会在每次执行时弹框询问，也可以直接写死。我建议第一次先用$Prompt$确认能跑通，之后再改成环境变量或本地文件读取，免得每次弹框烦人。

3.2 配置 GLM 命令入口

GLM 这边我用的是 Python SDK 的直连方式，不依赖官方 CLI，因为灵活性最高。在 External Tools 里再加一个 “GLM Chat”，Program 填 Python 解释器路径，比如：

/usr/bin/python3

Arguments 指向我写的一个脚本：

$ProjectFileDir$/tools/glm_chat.py --prompt "$Prompt$"

这个脚本负责从环境变量读 Key，调用 GLM 的 chat completions 接口，并把结果格式化输出。这样有几个好处：

• 不受 GLM CLI 版本迭代影响，逻辑自己可控。
• 可以在 Python 层做简单的日志、缓存、单元测试格式化。
• 未来想接其他国内模型，改脚本即可。

如果你不想写脚本，直接用已有的 GLM CLI 也可以，配置方式与 Claude Code 一致，只是把 Program 和 Arguments 替换成 CLI 入口。

3.3 在 IDEA 中运行并验证

配置完成后，在 External Tools 菜单里点击 “Claude Code Here”，第一次会弹出参数填写框，输入你的问题或代码片段，回车就会在 IDEA 底部的 Run 窗口看到 Claude 的回复。

如果一切正常，你会看到类似这样的输出：

Claude Code v1.0.0 Model: claude-sonnet-4-20250514 • 文件变更分析完成 • 检测到 3 个潜在问题 • 生成重构建议，耗时 2.3s

GLM 那边会直接打印 JSON 或纯文本回复，我用 Python 脚本做了格式化，让输出更易读。

3.4 让 IDEA 自动读取当前文件和选区

工具链跑通之后，最提升效率的一步是让 AI 自动知道你在编辑什么文件、看的是哪段代码。IDEA 的 External Tools 支持变量宏，常用几个如下：

以 Claude Code 为例，经典的用法是把当前文件内容保存为临时文件，然后在提示词里引用。我写了一个 wrapper 脚本claude_idea.sh来处理这件事：

#!/bin/bash # 将 IDEA 变量作为参数传入的文件 CURRENT_FILE="$1" SELECTED_TEXT="$2" # 拼一个临时提示文件 TMP_PROMPT=$(mktemp) cat > "$TMP_PROMPT" <<EOF 请分析项目中的以下文件，并针对选中区域给出优化建议。 文件路径: $CURRENT_FILE 选中内容: $SELECTED_TEXT 请直接给出修改后的代码块，不要额外解释。 EOF claude --input-format text < "$TMP_PROMPT" rm "$TMP_PROMPT"

External Tools 配置：

• Program:/path/to/claude_idea.sh
• Arguments:$FilePath$ $SelectedText$
• Working directory:$ProjectFileDir$

这里有个注意点：$SelectedText$如果太长，会导致命令行参数溢出。我实际测试过，超过几万字符时，shell 会报 Argument list too long。遇到这种情况，方案是改成把选中内容写入临时文件，然后把文件路径传给脚本，而不是直接传内容。

3.5 配置 GLM 上下文提取与代码生成

GLM 的脚本glm_chat.py我做了三档能力：

• 轻量问答：输入一段文字，直接返回回答。
• 代码生成：检测到提示词里包含“生成代码”等关键字时，自动拼接系统提示词，让它生成符合项目语言风格的代码。
• 文件分析：传入文件路径时，读取文件内容并交给模型分析。

核心逻辑大致是：

import os import sys import json import urllib.request API_URL = "https://open.bigmodel.cn/api/paas/v4/chat/completions" API_KEY = os.environ.get("ZHIPUAI_API_KEY", "") def chat(prompt): data = { "model": "glm-4-flash", "messages": [{"role": "user", "content": prompt}], "temperature": 0.3 } req = urllib.request.Request(API_URL, data=json.dumps(data).encode(), headers={ "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" }) resp = urllib.request.urlopen(req) return json.loads(resp.read()) if __name__ == "__main__": prompt = sys.argv[1] result = chat(prompt) print(result["choices"][0]["message"]["content"])

这台脚本跑起来后，GLM 就变成 IDEA 里一个随叫随到的轻量助理。由于 GLM 接口格式是 OpenAI 兼容格式，后续换模型时只要改模型名和端点，脚本无需大改。

4. 常见问题与排查技巧实录

4.1 Claude Code 报错 “command not found” 或 “Cannot run program”

这是最典型的集成初装问题。绝大多数原因是 IDEA 进程的环境变量和系统 shell 不一致。IDEA 在 macOS 上默认通过 LaunchServices 启动，不会加载~/.zshrc中的 PATH，所以即使你在终端里能运行claude，IDEA 里照样找不到。

解决办法：

• 在 Program 字段写绝对路径而不是命令名。
• 如果是 nvm 安装的 Node，记得把~/.nvm/versions/node/v18.20.4/bin写进绝对路径。
• 还可以在 IDEA 的自定义属性文件（idea.properties）里追加idea.Process.encoding=UTF-8，避免中文输出乱码。

我踩过最深的坑是：明明终端里claude能跑，IDEA 里却报错。最后发现是 IDEA 启动时的 PATH 根本没包含 nvm 目录，写死绝对路径后立刻好了。

4.2 输出中文乱码

IDEA 的 Run 窗口默认按系统编码解析子进程输出。如果工具输出是 UTF-8，但 IDEA 环境编码是 GBK，就会出现乱码。

处理方式：在 External Tools 配置页面，Advanced 选项卡里把 Output encoding 设为 UTF-8。如果还不行，就在命令外层加一个PYTHONIOENCODING=utf-8（Python）或LANG=en_US.UTF-8（Unix）环境变量。

4.3 GLM API 返回 401 或 403

GLM 的控制台 Key 和 API 端点是两回事，确认你用的是 API 密钥而不是控制台登录密码。另外，部分模型和 Key 存在白名单绑定关系，如果换了模型名但 Key 权限不够，也会出现鉴权失败。

排错建议：先用 curl 或 Python 脚本直接测一次 API，排除 IDEA 配置因素。

curl -X POST https://open.bigmodel.cn/api/paas/v4/chat/completions \ -H "Authorization: Bearer $ZHIPUAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"glm-4-flash","messages":[{"role":"user","content":"hi"}]}'

如果 curl 正常而 IDEA 里不行，问题就出在环境变量传递上。检查 External Tools 的 Environment variables 字段，确认没写错变量名，也没跟全局变量冲突。

4.4 如何应对“一次只回答一个文件”的限制

Claude Code 本身支持一次读取多个文件，但 External Tools 这种方式只能通过宏传入一个文件路径。需要分析多个文件时，我写了一个辅助脚本，接收目录路径，自动找关键文件拼接成提示词再交给模型。

比如：

claude --input-format text <(find "$ProjectFileDir$/src" -name "*.java" | head -20 | xargs cat)

这样能快速让 Claude 对多个文件做整体分析。如果你更习惯一次只处理一个文件的对话模式，那么按原方案使用即可。

4.5 添加自定义 Prompt 模板

我发现固定格式的提示词比随手输入效果好得多。在 IDEA 里实现自定义模板，关键是利用$Prompt$变量的默认值。External Tools 里没法直接给$Prompt$设置默认文本，但我绕了一下：用$Prompt$作为输入框提示，再通过 wrapper 脚本内部做模板拼接。

比如写代码时常用的模板：

PROMPT="请以下要求修改代码： 项目语言: $2 需求: $1 要求：输出完整代码块，不要省略。 "

这样每次点外部工具，只需要输入“给这个方法加个缓存”，脚本会自动补齐格式，模型输出会更规范。

4.6 输出内容不换行

IDEA 的 Run 窗口默认会把行尾符处理成空格，导致多行代码挤成一行。解决方法是：

• Run 窗口右键 -> 勾选“Use Soft Wraps”只是视觉换行，不解决数据问题。
• 真正解决需要在脚本里把输出用\n显式转成 IDEA 能识别的行分隔符，或者在输出时统一加一行分隔线。

我个人的做法是：在 wrapper 脚本末尾加一个标记行：

echo "========= END ========="

这样即使前面行被挤掉，仍然能根据标记判断输出完整度。

5. 进阶用法与效率妙招

5.1 给 Claude Code 绑定快捷键

External Tools 配置好之后，去 Settings -> Keymap 里搜索你给工具起的名字，直接 Assign Keyboard Shortcut。我习惯用Ctrl+Shift+C调用 Claude Code，Ctrl+Shift+G调用 GLM。实测下来，这两个键位不容易和系统快捷键冲突，单手操作也很顺手。

快捷键绑定的意义在于，把“选中代码 -> 按快捷键 -> 拿到建议”这个过程缩短到 2 秒内。一旦养成肌肉记忆，你就很难回到手动复制粘贴的方式了。

5.2 让 GLM 处理 Clippy 风格提问

GLM 的轻量特性非常适合做“代码解释器”：把不懂的代码片段丢给它，让它用自然语言解释。我在脚本里加了一个模式参数--mode explain，输出格式变成“一句话总结 + 分步骤解释 + 补充注意事项”，比直接输出一大段文本更有用。

此模式用来读陌生项目源码效果很理想。接手一个旧项目时，我习惯把核心 Service 类丢给 GLM 解释，再配合 Claude Code 做重构，两者分工，效率翻倍。

5.3 会话管理与上下文延续

命令行 AI 工具的无状态特性在多数单次任务里没问题，但要连续对话时就麻烦了。Claude Code 原生支持会话恢复参数：

claude --resume <session_id>

问题在于 External Tools 每次调用都不知道上一个 session 是什么。我的方案是，在 wrapper 脚本里把每次生成的 session_id 写入项目目录下的.claude-session文件，下一次运行时自动读取并带入--resume参数。

GLM 由于是 API 调用，我就在脚本里维护消息历史列表，按轮次存成 JSON 文件。这样同一个 IDEA 项目里，GLM 能记住前面几轮聊天的背景，不用反复粘贴上下文。

5.4 用 Run Configuration 做嵌入式任务面板

比 External Tools 更进一步的是，在 IDEA 的 Run Dashboard 里把 Claude Code 配置成可重复运行的任务。通过自定义运行配置（Python 或 Shell Script），每次运行都带上指定的提示词或任务定义。

我最常用的是把“单元测试生成”做成一个独立运行配置，选中文件后运行它，Claude 自动扫描源码并生成单测。Run 窗口会显示耗时和 token 统计，方便追踪成本。

6. 安全与成本管理的几点建议

6.1 API Key 不要硬编码

Claude Code 和 GLM 脚本都不要在代码里明文写 Key。IDEA 的环境变量字段虽然比明文好，但它会存进.idea目录的 XML 文件里。我更建议用本地的未跟踪文件，比如.env，并在 wrapper 脚本中用 dotenv 方式加载。

具体来说，在项目根目录放一个.env（加入.gitignore），里面写：

ANTHROPIC_API_KEY=sk-ant-xxxx ZHIPUAI_API_KEY=xxxx.yyyy

wrapper 脚本里用工具加载，比如用set -a; source .env; set +a，这样 Key 只会留在本地，不随项目共享。

6.2 控制 token 消耗

Claude Code 在处理大型代码库时，一次上下文窗口可能消耗数千 token。尤其是自动把整个项目所有文件塞进去的做法，很容易让账单快速攀升。

我的个人策略是：

• 轻量任务只用 GLM，因为成本通常低一个数量级。
• Claude Code 只处理需要深度理解的任务，且通过明确提示词限制输出长度。
• 在 wrapper 脚本里统一加--max-turns和--max-output-tokens参数，防一手失控。
• 定期检查 API 平台上的消耗报表，看看哪个项目、哪个模型占了大头。

6.3 隐私与代码安全

把代码发给外部模型，就要默认它会被服务方记录。公司项目、未公开模块、涉及敏感数据的代码，不建议直接通过这个方案处理。如果一定要用，先在内部做个脱敏，把变量名、字符串、注释改成占位符再发。

我一般设了两套工具链：一套是 Claude Code/GLM，处理个人项目或开源代码；另一套是公司内部部署的模型或合规网关，处理工作相关代码。真需要外部模型时，会先在本地对敏感信息做一次替换。

7. 实战效果复盘与后续扩展空间

这套方案我持续用了约两个月，整体感受是“集成之后回不去了”。最明显的效率提升点是代码评审和测试用例生成：以前人工逐文件 review 要半小时，现在 Claude Code 先筛一遍，直接指出可疑区域，我再集中精力复核，时间压缩到原来的三分之一。GLM 这边，我主要用于接口文档注释、异常分支补充、SQL 改写这类碎片化任务，量大但不需要多深推理，免费档位就够用，基本零成本。

后续还可以扩展的方向包括：

• 把 wrapper 脚本升级成 IDEA 插件，直接加 Side Panel 显示流式输出。
• 接入项目本身的构建日志，让 Claude Code 在编译失败时自动分析错误并给修复建议。
• 把对话历史和 MR、Issue 关联起来，实现“AI 助手记住每个功能分支的上下文”。

从配置角度看，这套方案的价值在于“原生命令行能力 + IDE 交互”的最佳平衡，没有引入笨重框架，也没有锁死某一家模型。哪天 Claude Code 更新了更好的模型，或者 GLM 出了更强的版本，改一行配置就能切换。

我个人在实际操作中最大的体会是：不要追求一步到位的完美配置，先按最简路径跑通，再逐步加上快捷键、会话管理、多文件分析这些进阶能力。AI 工具集成这件事，动手跑通一次比看十篇教程都管用。