这几个月我把自己的 AI 编程工作流固定成了一个组合Claude Code GLM-5 Superpowers。先说结论Claude Code 负责在终端里读写代码、执行命令GLM-5 作为推理大脑承接复杂设计和代码生成Superpowers 则是一整套 skills 技能包负责让模型在关键时刻别跑偏。三个东西单独用都不算出奇但拼成流水线之后最大的变化就是AI 交付全栈项目这件事从偶尔成功变成了稳定可复现。下面我会把安装、配置、省 token 的方法、技能库拆解以及一次完整全栈实战的过程全部摊开讲给正在用或准备用 Claude Code 的朋友一份可抄的作业。1. 为什么是这三件套不是三个工具是一条流水线1.1 Claude Code 是手能干活的终端 Agent很多人以为 Claude Code 只是另一个聊天窗其实它更像是一个把模型接入命令行与文件系统的 Agent。它能够读取项目目录、修改文件、执行 shell 命令、在出错时读取日志并自我修复。对一个全栈项目来说这等于拥有一个会操作整台电脑的助手。默认模型体验足够好但有两个现实问题一是 API 成本二是模型能力上希望可以替换甚至多模型协同。这就引出了 GLM-5。我举一个直观的例子在传统对话式 AI 里你说给我加一个用户登录功能它给你一段代码在 Claude Code 里你说同样的话它会自己去读你的路由文件、数据库模型、前端页面然后把需要的文件一并改掉并跑起测试。这差别非常大也意味着它需要更稳定的模型输出和更强的守规矩能力。如果你让它自由发挥一个 500 行的项目问题不大但如果是 5000 行、十几个文件的真实项目没有约束机制它很容易改一处崩一处。这也是我把第三件套 Superpowers 加进来的动因。1.2 GLM-5 是脑可插拔的模型层Claude Code 并不是只能绑死某一个模型。只要把端点指到兼容 Anthropic API 的地址再配置好认证 tokenClaude Code 就会把完整的工具调用请求发给那个端点。GLM-5 这类模型接入之后我实测体会最明显的有三点中文需求理解更自然、代码生成的长上下文稳定性不错、调用成本相比高频商用模型有明显优势。尤其在做中文前端界面和需求文档时GLM 对语义的把控更贴近我们的表达习惯。这里要给新手提醒一句模型层替换不是换皮而是整个推理引擎换了。Claude Code 的 Agent 能力比如文件读取、终端命令、多文件协作这些外骨骼能力依然由 Claude Code 提供模型只需要负责理解指令、调用工具、生成代码。理解了这一层你就明白为什么模型可以换来换去工作流不会塌。这套思路在热词里也能看到像Claude Code 接入 DeepSeekClaude Code 接入 ChatGPT本质上都是在做同一件事。1.3 Superpowers 是规矩用 skills 约束模型的输出模式如果说 Claude Code 和 GLM-5 解决的是能不能做Superpowers 解决的是做得靠不靠谱。Superpowers 本质是一个开源的 skills 集合把先思考再动手写代码前先写计划做完功能要验证这类工程纪律封装成模型可调用的技能协议。每个技能是一个带 frontmatter 和说明的 Markdown/脚本包模型读到 description 匹配后就会按技能流程执行。这保证模型不会突然放飞自我。Superpowers 还有一个兄弟项目 OpenSpec把需求规格先行的流程固化下来。热词里那句让 AI 稳定交付全栈项目我的 Claude Code OpenSpec Superpowers 三件套实战本质上就是用 Claude Code 执行、Superpowers 控制步骤、OpenSpec 卡规格这三层配合。这三件套的关系我习惯理解为同一条产线上有手、有脑、有标准化作业手册。手再快、脑再强没有作业手册也做不出稳定复现的质量。2. 安装与初始化从零搭出这套组合2.1 Claude Code 安装含 Windows PowerShell 报错解决方案Claude Code 的安装非常简单前提是 Node.js 18 以上环境。安装命令一句就够npm install -g anthropic-ai/claude-code然后确认版本claude --version如果你在 Windows PowerShell 里安装后运行 claude 报在此系统上禁止运行脚本这类的错本质是 PowerShell 的执行策略限制了脚本运行。临时解决办法是在当前会话放开Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass要长期解决可以在管理员 PowerShell 中设置Set-ExecutionPolicy RemoteSigned或者直接用 npx 方式启动npx anthropic-ai/claude-code。我推荐正式环境用全局安装因为后续要配合环境变量和 CC Switch 做配置全局命令调用最省心。下载安装时如果遇到速度慢或失败的情况优先检查 Node 版本和网络而不是反复重装npm 缓存也可以用npm cache clean --force清理后再试。注意如果你下载的是桌面版或 VS Code 插件版底层能力和命令行版基本一致但配置模型端点的入口可能不同。我建议命令行版作为主力插件版作为辅助查看 diff 的界面两条互补比只用其中一条顺手很多。2.2 Superpowers 安装与位置说明Superpowers 是开源技能集目前推荐用官方安装脚本拉取npx workswarm/superpowerslatest install它会自动把技能包安装到对应 AI 工具的配置目录。对 Claude Code 来说目录通常是~/.claude/skills如果你在用 OpenCode它也兼容。装完之后可以列目录确认ls ~/.claude/skills你会看到一堆技能文件夹每个文件夹里都有一个SKILL.md这就是模型读取技能定义的核心文件。它的 frontmatter 里写了技能名称和描述模型会根据当前任务语义自动决定是否激活某个技能。算不上黑魔法本质上是一种可控的上下文注入。关于安装我见过太多人卡在这一步网络不通导致 npx 拉取失败、权限不足导致写入~/.claude失败、Node 版本太老导致脚本语法报错。前两个问题好解决权限就用 sudo 或手动给用户目录写权限第三个就老老实实把 Node 升到 18 以上。装完以后不要急着把所有技能都塞进去保留常用的一部分就够了原因我在第 4 节展开。2.3 GLM-5 接入前的准备工作在接 GLM-5 之前你要确认两件事一是有一个能调 GLM-5 的 API Key二是拿到它兼容 Anthropic 协议的接口地址。不同版本的 GLM 开放情况不同有的版本直接给 Anthropic 兼容地址有的只有 OpenAI 兼容地址需要用转发层转换。我为了少折腾方案是优先用官方 Anthropic 兼容网关没有的话再上一层 claude-code-router 这类本地工具做协议转换。这个问题不要小看很多同学配了半天连不上就是地址格式不对。我个人不建议为了省事在代码里写死 Key环境变量更合适好处是安全且便于切换。下一节给完整配置看完基本十分钟内能跑起来。3. 核心配置细节如何让 Claude Code 稳定走 GLM-5 并省下 token3.1 三个环境变量搞定模型切换Claude Code 识别模型供应商主要看这几个环境变量。以 Linux / macOS 为例export ANTHROPIC_BASE_URLhttps://你的GLM兼容端点 export ANTHROPIC_AUTH_TOKEN你的API密钥 export ANTHROPIC_MODELglm-5然后启动claude控制台初始化时显示的模型名就是 GLM-5 了。在这个模式下工具调用、文件读写、终端执行这些 Agent 能力都保持不变变的只是背后的推理引擎。如果你希望配置长期生效可以把这几行追加到~/.bashrc或~/.zshrc里echo export ANTHROPIC_BASE_URLhttps://你的GLM兼容端点 ~/.bashrc echo export ANTHROPIC_AUTH_TOKEN你的API密钥 ~/.bashrc echo export ANTHROPIC_MODELglm-5 ~/.bashrc source ~/.bashrc接好之后我强烈建议你在一个临时目录里先做一次冒烟测试让 Claude Code 创建一个简单的 Node 脚本并运行确认模型能正常调用工具。这一步能排除绝大多数配置问题比直接上大项目省心得多。3.2 用 CC Switch 管理多套模型配置热词里频繁出现claude code cc switch ollamaCC Switch 是维护多套配置的小工具。它本质上帮你管理多个环境变量组合想做 A/B 对比时一键切换比每次手动 export 方便很多。尤其当你需要在云模型和本地模型之间来回换的时候手动改环境变量真的太容易出错了。我目前的日常配置有两套云模型配置GLM-5负责需求理解、架构设计、涉及长上下文的复杂生成。本地模型配置Ollama 起的模型负责不敏感代码的快速格式化、简单脚本生成。CC Switch 里把两套配置写好后切换时点一下再重新打开 Claude Code 就生效。需要注意的是切换配置前最好先清空当前会话上下文或者干脆重启会话避免旧上下文里的模型属性与新的不一致导致后续工具调用接口报错。这个坑我踩过症状是模型切换后幻觉变多、工具调用莫名失败重启会话后一切恢复正常。3.3 省 token 的几个硬操作Claude Code 默认会把大量项目文件读进上下文token 消耗自然涨得快。我的经验按使用频率排序不是每个会话都挂所有 Superpowers 技能。把不需要的 skill 文件夹移出~/.claude/skills减少模型扫描技能的次数。技能太多确实会影响信息密度和决策速度。复杂任务拆分多个会话。一个全栈项目如果从头到尾塞在一个会话里上下文中间段容易失忆我会按模块拆成规格设计会话后端实现会话前端联调会话用--resume恢复配合项目 README 和 specs 作为交接依据。及时用 /compact 压缩上下文。长对话卡顿时让模型把要点压缩成摘要再接续效果比硬往下聊好很多。控制权限确认频率。频繁确认本身不消耗 token但每次确认前的系统提示和候选命令会影响上下文能用acceptEdits的模式尽量规划清楚再执行。这些动作单独看都是小事合在一起同样任务 token 消耗能差出 30% 到 40%。对个人开发者和非企业用户来说这就是要不要继续用的分界线。4. Superpowers 技能体系拆解这些技能分别解决什么问题4.1 SKILL.md 机制模型是怎么学会按技能办事的每个技能包本质上是一个目录里面有SKILL.md和可能附带脚本、模板。SKILL.md的 YAML frontmatter 里最关键的是name和description。当模型分析用户请求时会拿请求语义和各技能 description 做匹配命中了就把该技能的正文拉入上下文按里面写的步骤执行。这里有一个很重要的实践认知技能正文是提示词 可执行步骤 模板的结合体不是硬编码的程序。所以即使官方技能不够用你也可以自己写一个 SKILL.md把自己项目的规范沉淀成技能。下面是一个极简示例--- name: project-convention description: 当修改这个项目的 JavaScript 文件时强制使用项目规范。 --- # 项目规范 - 所有新组件必须使用函数组件不使用 class 组件。 - 状态管理统一使用 zustand不使用 redux。 - 提交前必须运行 npm run lint。写好后放到~/.claude/skills/project-convention/SKILL.md下次模型改这个项目的 JS 文件时就会自动把这个技能内容拉进上下文。团队协作时这比让每个人都去反复粘贴规范文档高效得多。换句话说Superpowers 给你的不仅是一堆现成技能更是一种把自己团队的工程经验变成模型可调用资产的方法。4.2 常用技能盘点与选择建议结合我在实际项目里的使用频率按价值从高到低排技能/能力干什么用我的使用场景plan/think动手前先拆分任务、给出步骤复杂重构、接入新依赖write-better代码生成后做自查与改进建议每次生成的代码过一遍browser浏览器自动化验证页面前端页面、E2E 场景desktop桌面自动化需要操作 IDE 之外的软件web联网检索资料查文档、查版本、查更新我一开始把全部技能都装上结果发现模型在简单任务上也会犹豫要不要先调用 plan要不要联网这类决策噪音反而影响效率。后来我把技能按项目类型裁剪做前端项目只留 browser、plan、write-better做后端只留 plan、write-better。这个教训值得拿出来说技能的 value 在于合适时介入不在于多。每次新增技能前问自己一句这个技能是否在 90% 的场景里都有用没有就缓存起来别拖累上下文。4.3 OpenSpec 为什么能和它们配合OpenSpec 解决的问题是AI 改动太随意。它要求项目有一个 specs 目录里面按特性放规格文件每个规格包含需求背景、设计约束、验收标准。Claude Code 在改代码前先读 spec改完后按验收标准逐条检查。Superpowers 负责的是具体操作时的纪律OpenSpec 负责的是更高层的需求边界。我建议的落地方式不用 OpenSpec 工具链全部功能只先遵循它的目录约定和验收清单思路已经能让 AI 交付的稳定度上一个台阶。在工程中唯一要克制的是别把规格写到太细否则模型把所有时间花在读文档上产出反而慢。规格和代码的平衡点通常是你自己能在 10 分钟内讲完整个项目的功能边界规格文档也就应该控制在 10 分钟能读完的量级。5. 全栈项目实战从 OpenSpec 规格到一套可运行应用的全流程5.1 项目背景与规格先行为了验证这套组合我挑了一个算不上大但五脏俱全的任务做一个家庭记账小应用前端 React Vite后端 Python FastAPI数据存 SQLite核心功能是三张表账目、分类、预算和一个月度统计接口。我先在项目里建了specs/目录写了一个精炼的规格文件结构类似这样specs/ overview.md features/ accounting/spec.md statistics/spec.md其中overview.md的内容很克制只写了核心信息功能列表记账、分类管理、月度统计。非功能要求后端接口统一返回 JSON前端页面从上往下展示当月支出占比整个项目必须能在本地一条命令启动。验收标准添加一条账目后列表立即刷新月度统计数字和手工计算一致。这一步大约花 20 分钟但这 20 分钟直接决定了后面 AI 干活的边界。没有这份规格的时候我试过让 Claude Code 直接做一个记账应用结果它把 UI 框架从我指定的 React 换成了 Next.js还自作主张加了用户注册登录。有了规格这种偏航次数明显减少了。5.2 Claude Code 会话从读规格到出任务清单启动方式cd ~/projects/finance-dash claude --permission-mode acceptEdits进会话后第一句就是先读 specs 目录下的所有文件然后列出你要完成的任务清单用 todo 形式给我。由于有 OpenSpec 的规格兜底模型没有直接从写代码开始而是先输出任务拆解再去建目录和脚手架。我观察到的真实执行顺序大致是读 specs规划目录结构。初始化前端 Vite 项目。初始化后端 FastAPI 项目。实现 SQLite 数据模型和接口。前端页面联调。启动服务自测。这个过程中 Superpowers 的 plan 技能会在较复杂的一步比如数据模型设计之前主动弹出执行步骤write-better 会在每个生成文件后补充一段审查意见。这帮我省掉了大量来回追问的沟通成本。你不需要懂 prompt 工程只要按先读规格、再列任务、再执行的顺序推它一把输出质量就会明显提升。5.3 中途调整需求与最终验收做到一半我提了个新需求前端加一个最近 30 天支出趋势的简易折线图。这种需求在纯聊天式 AI 里最容易翻车因为模型容易重新生成一版不兼容的前端。但在三件套下因为有完整的 specs 和已运行的项目结构Claude Code 只改了对应组件和统计接口没有动其他模块。最后我让它跑一遍验收启动前后端、打开页面、新增一条账目、核对统计数字。模型报了一次后端接口路径写错的问题它自己读日志定位并修复了。整体跑通后我再人为检查了一遍核心逻辑和依赖版本没有发现明显问题。这套流程的实际意义不在AI 写得多完美而在于出问题时可定位、可回滚、可验收。对我这种偏全栈的独立开发者来说这才是把 AI 从玩具变成生产力工具的分水岭。你完全可以把同样的方法应用到自己的副业项目和内部工具里规模不大但流程是完整的。6. 实际使用时踩过的坑以及和 Codex / 本地模型方案的取舍6.1 乱码、报错、会话丢失那些让人崩溃的细节在 Windows PowerShell 下Claude Code 中文乱码是最常见的问题之一。原因是终端默认代码页不对。在执行 claude 前先运行chcp 65001把代码页切到 UTF-8乱码基本就消失了。安装阶段最常见的是 PowerShell 执行策略报错前面已经给了解决办法。再补充一个容易被忽略的点如果你用npx方式启动它每次都会检查更新项目大时启动会慢几秒如果你网络不稳定甚至可能误报安装失败。此时优先使用全局 npm 包或者锁定版本更稳。对话历史的保存问题也有不少人问。Claude Code 的会话默认会在本地落盘路径通常在~/.claude/projects/下对应项目名的目录。想找回之前的会话用claude --resume按列表选择即可。如果你需要把对话导出成可分享的文本可以用claude --output-format stream-json session.json这类方式记录原始输出。提醒如果你在团队共享机器上使用~/.claude/projects里会存有完整对话内容里面可能包含密钥或业务代码建议定时清理或专人保管。这个目录往往容易被忽视一旦泄露比丢代码还麻烦。6.2 和 Codex 怎么选我现在的判断标准这半年讨论最多的对比就是 Codex 和 Claude Code。我的观点很实际选工具先看工作流落在哪里。如果你的工作流主要在 GitHub 上拉 PR、review、处理 issueCodex 的集成体验更顺。如果你的工作流在本地终端需要自由地读写文件、跑命令、跨项目重构、控制多模型接入Claude Code 更灵活。两者不是替代关系。我甚至会同时开着让 Codex 负责后台的 issue 任务Claude Code 负责当日主力开发。但要提醒一句同时开两个 agent 改同一个目录极易产生文件冲突最好用两个不同的分支或工作目录。工具再多守好分支纪律才是第一位的。6.3 本地模型和远程模型的取舍以及 VS Code/桌面的补充热词里还有一条是VS Code Claude Code 插件接入本地大模型 Ollama。如果你对数据敏感或不常联网本地模型配合 Ollama 可以用但就我的实测复杂全栈任务的代码质量距离云端模型还有明显差距。我现在的策略是梯度使用琐碎脚本、格式化、批量改注释用本地模型架构与核心业务逻辑用 GLM-5 这类强模型。CC Switch 的价值在这里最明显。至于 VS Code 插件和桌面版它们解决的问题主要是看得见 diff、点得动确认适合做 code review 和零散修改主力长会话我还是建议在终端里跑因为终端模式对上下文和脚本的掌控最强插件版在某些操作上反而多了一层 UI 开销。如果你只是想在编辑器里快速问问题插件版完全够用但如果你要让 AI 连续干一两个小时的全栈活终端会话的稳定性和可控性会高很多。最后分享一条个人经验教训三件套的威力三分之一来自工具本身三分之二来自你给的信息结构。规格不清、上下文混乱的时候再好的模型也白搭。我跌倒过好多次把 specs 写好、按会话切任务、技能按需裁剪之后稳定度才真正上来。如果你也想搭这套组合别急着把工具全装齐先从一个只有 500 行的真实小项目开始把流程走顺再逐步加技能、加规格。这样你会用得更顺手。
AI 全栈项目三件套：Claude Code+GLM-5+Superpowers
这几个月我把自己的 AI 编程工作流固定成了一个组合Claude Code GLM-5 Superpowers。先说结论Claude Code 负责在终端里读写代码、执行命令GLM-5 作为推理大脑承接复杂设计和代码生成Superpowers 则是一整套 skills 技能包负责让模型在关键时刻别跑偏。三个东西单独用都不算出奇但拼成流水线之后最大的变化就是AI 交付全栈项目这件事从偶尔成功变成了稳定可复现。下面我会把安装、配置、省 token 的方法、技能库拆解以及一次完整全栈实战的过程全部摊开讲给正在用或准备用 Claude Code 的朋友一份可抄的作业。1. 为什么是这三件套不是三个工具是一条流水线1.1 Claude Code 是手能干活的终端 Agent很多人以为 Claude Code 只是另一个聊天窗其实它更像是一个把模型接入命令行与文件系统的 Agent。它能够读取项目目录、修改文件、执行 shell 命令、在出错时读取日志并自我修复。对一个全栈项目来说这等于拥有一个会操作整台电脑的助手。默认模型体验足够好但有两个现实问题一是 API 成本二是模型能力上希望可以替换甚至多模型协同。这就引出了 GLM-5。我举一个直观的例子在传统对话式 AI 里你说给我加一个用户登录功能它给你一段代码在 Claude Code 里你说同样的话它会自己去读你的路由文件、数据库模型、前端页面然后把需要的文件一并改掉并跑起测试。这差别非常大也意味着它需要更稳定的模型输出和更强的守规矩能力。如果你让它自由发挥一个 500 行的项目问题不大但如果是 5000 行、十几个文件的真实项目没有约束机制它很容易改一处崩一处。这也是我把第三件套 Superpowers 加进来的动因。1.2 GLM-5 是脑可插拔的模型层Claude Code 并不是只能绑死某一个模型。只要把端点指到兼容 Anthropic API 的地址再配置好认证 tokenClaude Code 就会把完整的工具调用请求发给那个端点。GLM-5 这类模型接入之后我实测体会最明显的有三点中文需求理解更自然、代码生成的长上下文稳定性不错、调用成本相比高频商用模型有明显优势。尤其在做中文前端界面和需求文档时GLM 对语义的把控更贴近我们的表达习惯。这里要给新手提醒一句模型层替换不是换皮而是整个推理引擎换了。Claude Code 的 Agent 能力比如文件读取、终端命令、多文件协作这些外骨骼能力依然由 Claude Code 提供模型只需要负责理解指令、调用工具、生成代码。理解了这一层你就明白为什么模型可以换来换去工作流不会塌。这套思路在热词里也能看到像Claude Code 接入 DeepSeekClaude Code 接入 ChatGPT本质上都是在做同一件事。1.3 Superpowers 是规矩用 skills 约束模型的输出模式如果说 Claude Code 和 GLM-5 解决的是能不能做Superpowers 解决的是做得靠不靠谱。Superpowers 本质是一个开源的 skills 集合把先思考再动手写代码前先写计划做完功能要验证这类工程纪律封装成模型可调用的技能协议。每个技能是一个带 frontmatter 和说明的 Markdown/脚本包模型读到 description 匹配后就会按技能流程执行。这保证模型不会突然放飞自我。Superpowers 还有一个兄弟项目 OpenSpec把需求规格先行的流程固化下来。热词里那句让 AI 稳定交付全栈项目我的 Claude Code OpenSpec Superpowers 三件套实战本质上就是用 Claude Code 执行、Superpowers 控制步骤、OpenSpec 卡规格这三层配合。这三件套的关系我习惯理解为同一条产线上有手、有脑、有标准化作业手册。手再快、脑再强没有作业手册也做不出稳定复现的质量。2. 安装与初始化从零搭出这套组合2.1 Claude Code 安装含 Windows PowerShell 报错解决方案Claude Code 的安装非常简单前提是 Node.js 18 以上环境。安装命令一句就够npm install -g anthropic-ai/claude-code然后确认版本claude --version如果你在 Windows PowerShell 里安装后运行 claude 报在此系统上禁止运行脚本这类的错本质是 PowerShell 的执行策略限制了脚本运行。临时解决办法是在当前会话放开Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass要长期解决可以在管理员 PowerShell 中设置Set-ExecutionPolicy RemoteSigned或者直接用 npx 方式启动npx anthropic-ai/claude-code。我推荐正式环境用全局安装因为后续要配合环境变量和 CC Switch 做配置全局命令调用最省心。下载安装时如果遇到速度慢或失败的情况优先检查 Node 版本和网络而不是反复重装npm 缓存也可以用npm cache clean --force清理后再试。注意如果你下载的是桌面版或 VS Code 插件版底层能力和命令行版基本一致但配置模型端点的入口可能不同。我建议命令行版作为主力插件版作为辅助查看 diff 的界面两条互补比只用其中一条顺手很多。2.2 Superpowers 安装与位置说明Superpowers 是开源技能集目前推荐用官方安装脚本拉取npx workswarm/superpowerslatest install它会自动把技能包安装到对应 AI 工具的配置目录。对 Claude Code 来说目录通常是~/.claude/skills如果你在用 OpenCode它也兼容。装完之后可以列目录确认ls ~/.claude/skills你会看到一堆技能文件夹每个文件夹里都有一个SKILL.md这就是模型读取技能定义的核心文件。它的 frontmatter 里写了技能名称和描述模型会根据当前任务语义自动决定是否激活某个技能。算不上黑魔法本质上是一种可控的上下文注入。关于安装我见过太多人卡在这一步网络不通导致 npx 拉取失败、权限不足导致写入~/.claude失败、Node 版本太老导致脚本语法报错。前两个问题好解决权限就用 sudo 或手动给用户目录写权限第三个就老老实实把 Node 升到 18 以上。装完以后不要急着把所有技能都塞进去保留常用的一部分就够了原因我在第 4 节展开。2.3 GLM-5 接入前的准备工作在接 GLM-5 之前你要确认两件事一是有一个能调 GLM-5 的 API Key二是拿到它兼容 Anthropic 协议的接口地址。不同版本的 GLM 开放情况不同有的版本直接给 Anthropic 兼容地址有的只有 OpenAI 兼容地址需要用转发层转换。我为了少折腾方案是优先用官方 Anthropic 兼容网关没有的话再上一层 claude-code-router 这类本地工具做协议转换。这个问题不要小看很多同学配了半天连不上就是地址格式不对。我个人不建议为了省事在代码里写死 Key环境变量更合适好处是安全且便于切换。下一节给完整配置看完基本十分钟内能跑起来。3. 核心配置细节如何让 Claude Code 稳定走 GLM-5 并省下 token3.1 三个环境变量搞定模型切换Claude Code 识别模型供应商主要看这几个环境变量。以 Linux / macOS 为例export ANTHROPIC_BASE_URLhttps://你的GLM兼容端点 export ANTHROPIC_AUTH_TOKEN你的API密钥 export ANTHROPIC_MODELglm-5然后启动claude控制台初始化时显示的模型名就是 GLM-5 了。在这个模式下工具调用、文件读写、终端执行这些 Agent 能力都保持不变变的只是背后的推理引擎。如果你希望配置长期生效可以把这几行追加到~/.bashrc或~/.zshrc里echo export ANTHROPIC_BASE_URLhttps://你的GLM兼容端点 ~/.bashrc echo export ANTHROPIC_AUTH_TOKEN你的API密钥 ~/.bashrc echo export ANTHROPIC_MODELglm-5 ~/.bashrc source ~/.bashrc接好之后我强烈建议你在一个临时目录里先做一次冒烟测试让 Claude Code 创建一个简单的 Node 脚本并运行确认模型能正常调用工具。这一步能排除绝大多数配置问题比直接上大项目省心得多。3.2 用 CC Switch 管理多套模型配置热词里频繁出现claude code cc switch ollamaCC Switch 是维护多套配置的小工具。它本质上帮你管理多个环境变量组合想做 A/B 对比时一键切换比每次手动 export 方便很多。尤其当你需要在云模型和本地模型之间来回换的时候手动改环境变量真的太容易出错了。我目前的日常配置有两套云模型配置GLM-5负责需求理解、架构设计、涉及长上下文的复杂生成。本地模型配置Ollama 起的模型负责不敏感代码的快速格式化、简单脚本生成。CC Switch 里把两套配置写好后切换时点一下再重新打开 Claude Code 就生效。需要注意的是切换配置前最好先清空当前会话上下文或者干脆重启会话避免旧上下文里的模型属性与新的不一致导致后续工具调用接口报错。这个坑我踩过症状是模型切换后幻觉变多、工具调用莫名失败重启会话后一切恢复正常。3.3 省 token 的几个硬操作Claude Code 默认会把大量项目文件读进上下文token 消耗自然涨得快。我的经验按使用频率排序不是每个会话都挂所有 Superpowers 技能。把不需要的 skill 文件夹移出~/.claude/skills减少模型扫描技能的次数。技能太多确实会影响信息密度和决策速度。复杂任务拆分多个会话。一个全栈项目如果从头到尾塞在一个会话里上下文中间段容易失忆我会按模块拆成规格设计会话后端实现会话前端联调会话用--resume恢复配合项目 README 和 specs 作为交接依据。及时用 /compact 压缩上下文。长对话卡顿时让模型把要点压缩成摘要再接续效果比硬往下聊好很多。控制权限确认频率。频繁确认本身不消耗 token但每次确认前的系统提示和候选命令会影响上下文能用acceptEdits的模式尽量规划清楚再执行。这些动作单独看都是小事合在一起同样任务 token 消耗能差出 30% 到 40%。对个人开发者和非企业用户来说这就是要不要继续用的分界线。4. Superpowers 技能体系拆解这些技能分别解决什么问题4.1 SKILL.md 机制模型是怎么学会按技能办事的每个技能包本质上是一个目录里面有SKILL.md和可能附带脚本、模板。SKILL.md的 YAML frontmatter 里最关键的是name和description。当模型分析用户请求时会拿请求语义和各技能 description 做匹配命中了就把该技能的正文拉入上下文按里面写的步骤执行。这里有一个很重要的实践认知技能正文是提示词 可执行步骤 模板的结合体不是硬编码的程序。所以即使官方技能不够用你也可以自己写一个 SKILL.md把自己项目的规范沉淀成技能。下面是一个极简示例--- name: project-convention description: 当修改这个项目的 JavaScript 文件时强制使用项目规范。 --- # 项目规范 - 所有新组件必须使用函数组件不使用 class 组件。 - 状态管理统一使用 zustand不使用 redux。 - 提交前必须运行 npm run lint。写好后放到~/.claude/skills/project-convention/SKILL.md下次模型改这个项目的 JS 文件时就会自动把这个技能内容拉进上下文。团队协作时这比让每个人都去反复粘贴规范文档高效得多。换句话说Superpowers 给你的不仅是一堆现成技能更是一种把自己团队的工程经验变成模型可调用资产的方法。4.2 常用技能盘点与选择建议结合我在实际项目里的使用频率按价值从高到低排技能/能力干什么用我的使用场景plan/think动手前先拆分任务、给出步骤复杂重构、接入新依赖write-better代码生成后做自查与改进建议每次生成的代码过一遍browser浏览器自动化验证页面前端页面、E2E 场景desktop桌面自动化需要操作 IDE 之外的软件web联网检索资料查文档、查版本、查更新我一开始把全部技能都装上结果发现模型在简单任务上也会犹豫要不要先调用 plan要不要联网这类决策噪音反而影响效率。后来我把技能按项目类型裁剪做前端项目只留 browser、plan、write-better做后端只留 plan、write-better。这个教训值得拿出来说技能的 value 在于合适时介入不在于多。每次新增技能前问自己一句这个技能是否在 90% 的场景里都有用没有就缓存起来别拖累上下文。4.3 OpenSpec 为什么能和它们配合OpenSpec 解决的问题是AI 改动太随意。它要求项目有一个 specs 目录里面按特性放规格文件每个规格包含需求背景、设计约束、验收标准。Claude Code 在改代码前先读 spec改完后按验收标准逐条检查。Superpowers 负责的是具体操作时的纪律OpenSpec 负责的是更高层的需求边界。我建议的落地方式不用 OpenSpec 工具链全部功能只先遵循它的目录约定和验收清单思路已经能让 AI 交付的稳定度上一个台阶。在工程中唯一要克制的是别把规格写到太细否则模型把所有时间花在读文档上产出反而慢。规格和代码的平衡点通常是你自己能在 10 分钟内讲完整个项目的功能边界规格文档也就应该控制在 10 分钟能读完的量级。5. 全栈项目实战从 OpenSpec 规格到一套可运行应用的全流程5.1 项目背景与规格先行为了验证这套组合我挑了一个算不上大但五脏俱全的任务做一个家庭记账小应用前端 React Vite后端 Python FastAPI数据存 SQLite核心功能是三张表账目、分类、预算和一个月度统计接口。我先在项目里建了specs/目录写了一个精炼的规格文件结构类似这样specs/ overview.md features/ accounting/spec.md statistics/spec.md其中overview.md的内容很克制只写了核心信息功能列表记账、分类管理、月度统计。非功能要求后端接口统一返回 JSON前端页面从上往下展示当月支出占比整个项目必须能在本地一条命令启动。验收标准添加一条账目后列表立即刷新月度统计数字和手工计算一致。这一步大约花 20 分钟但这 20 分钟直接决定了后面 AI 干活的边界。没有这份规格的时候我试过让 Claude Code 直接做一个记账应用结果它把 UI 框架从我指定的 React 换成了 Next.js还自作主张加了用户注册登录。有了规格这种偏航次数明显减少了。5.2 Claude Code 会话从读规格到出任务清单启动方式cd ~/projects/finance-dash claude --permission-mode acceptEdits进会话后第一句就是先读 specs 目录下的所有文件然后列出你要完成的任务清单用 todo 形式给我。由于有 OpenSpec 的规格兜底模型没有直接从写代码开始而是先输出任务拆解再去建目录和脚手架。我观察到的真实执行顺序大致是读 specs规划目录结构。初始化前端 Vite 项目。初始化后端 FastAPI 项目。实现 SQLite 数据模型和接口。前端页面联调。启动服务自测。这个过程中 Superpowers 的 plan 技能会在较复杂的一步比如数据模型设计之前主动弹出执行步骤write-better 会在每个生成文件后补充一段审查意见。这帮我省掉了大量来回追问的沟通成本。你不需要懂 prompt 工程只要按先读规格、再列任务、再执行的顺序推它一把输出质量就会明显提升。5.3 中途调整需求与最终验收做到一半我提了个新需求前端加一个最近 30 天支出趋势的简易折线图。这种需求在纯聊天式 AI 里最容易翻车因为模型容易重新生成一版不兼容的前端。但在三件套下因为有完整的 specs 和已运行的项目结构Claude Code 只改了对应组件和统计接口没有动其他模块。最后我让它跑一遍验收启动前后端、打开页面、新增一条账目、核对统计数字。模型报了一次后端接口路径写错的问题它自己读日志定位并修复了。整体跑通后我再人为检查了一遍核心逻辑和依赖版本没有发现明显问题。这套流程的实际意义不在AI 写得多完美而在于出问题时可定位、可回滚、可验收。对我这种偏全栈的独立开发者来说这才是把 AI 从玩具变成生产力工具的分水岭。你完全可以把同样的方法应用到自己的副业项目和内部工具里规模不大但流程是完整的。6. 实际使用时踩过的坑以及和 Codex / 本地模型方案的取舍6.1 乱码、报错、会话丢失那些让人崩溃的细节在 Windows PowerShell 下Claude Code 中文乱码是最常见的问题之一。原因是终端默认代码页不对。在执行 claude 前先运行chcp 65001把代码页切到 UTF-8乱码基本就消失了。安装阶段最常见的是 PowerShell 执行策略报错前面已经给了解决办法。再补充一个容易被忽略的点如果你用npx方式启动它每次都会检查更新项目大时启动会慢几秒如果你网络不稳定甚至可能误报安装失败。此时优先使用全局 npm 包或者锁定版本更稳。对话历史的保存问题也有不少人问。Claude Code 的会话默认会在本地落盘路径通常在~/.claude/projects/下对应项目名的目录。想找回之前的会话用claude --resume按列表选择即可。如果你需要把对话导出成可分享的文本可以用claude --output-format stream-json session.json这类方式记录原始输出。提醒如果你在团队共享机器上使用~/.claude/projects里会存有完整对话内容里面可能包含密钥或业务代码建议定时清理或专人保管。这个目录往往容易被忽视一旦泄露比丢代码还麻烦。6.2 和 Codex 怎么选我现在的判断标准这半年讨论最多的对比就是 Codex 和 Claude Code。我的观点很实际选工具先看工作流落在哪里。如果你的工作流主要在 GitHub 上拉 PR、review、处理 issueCodex 的集成体验更顺。如果你的工作流在本地终端需要自由地读写文件、跑命令、跨项目重构、控制多模型接入Claude Code 更灵活。两者不是替代关系。我甚至会同时开着让 Codex 负责后台的 issue 任务Claude Code 负责当日主力开发。但要提醒一句同时开两个 agent 改同一个目录极易产生文件冲突最好用两个不同的分支或工作目录。工具再多守好分支纪律才是第一位的。6.3 本地模型和远程模型的取舍以及 VS Code/桌面的补充热词里还有一条是VS Code Claude Code 插件接入本地大模型 Ollama。如果你对数据敏感或不常联网本地模型配合 Ollama 可以用但就我的实测复杂全栈任务的代码质量距离云端模型还有明显差距。我现在的策略是梯度使用琐碎脚本、格式化、批量改注释用本地模型架构与核心业务逻辑用 GLM-5 这类强模型。CC Switch 的价值在这里最明显。至于 VS Code 插件和桌面版它们解决的问题主要是看得见 diff、点得动确认适合做 code review 和零散修改主力长会话我还是建议在终端里跑因为终端模式对上下文和脚本的掌控最强插件版在某些操作上反而多了一层 UI 开销。如果你只是想在编辑器里快速问问题插件版完全够用但如果你要让 AI 连续干一两个小时的全栈活终端会话的稳定性和可控性会高很多。最后分享一条个人经验教训三件套的威力三分之一来自工具本身三分之二来自你给的信息结构。规格不清、上下文混乱的时候再好的模型也白搭。我跌倒过好多次把 specs 写好、按会话切任务、技能按需裁剪之后稳定度才真正上来。如果你也想搭这套组合别急着把工具全装齐先从一个只有 500 行的真实小项目开始把流程走顺再逐步加技能、加规格。这样你会用得更顺手。
