我与 Claude Code 的第一次对话

日期：2026 年 6 月 30 日
主题：从窗口崩溃开始，到画出未来的技术蓝图
关键词：Claude Code · Windows Terminal · BAT 编码 · 中文路径 · Ollama · Gemma 4 · 多模型协作 · 网站发布

一、引子：从崩溃开始的故事

2026 年 6 月 30 日，天气很热，CC 的窗口一碰就炸。

这其实不是我第一次听说 Claude Code。前几天就已经装好了，但每次尝试把窗口放大一点——"啪"，崩溃，屏幕上留下一行诡异的错误：

'1' 不是内部或外部命令，也不是可运行的程序或批处理文件。

一个英文单词都没出现。一个文件路径都没提示。就一个孤零零的 '1'，好像在嘲笑我。

但我没放弃。我心里清楚，这种诡异的问题通常不是"软件坏了"那么简单——它是系统底层某个环节的编码掉了链子。只是当时还不知道，这串问题会像多米诺骨牌一样，推倒一张，后面还藏着两张。

二、破冰：三大技术难题的连环排查

问题一：BAT 启动报错 — 中文路径的编码陷阱

双击 启动CC.bat → 弹窗报错 0x8007010b，路径中的中文字符变成了乱码：温泉 变成了 娓╂硥。

根因：BAT 文件保存为 UTF-8 无 BOM。Windows cmd.exe 在无 BOM 时默认用系统 ANSI 代码页（中文 Windows = GBK）来读文件。UTF-8 编码的中文字节被 GBK 错误解析，每个中文字被拆成 3 个字节，GBK 各取 2 字节拼出一个怪物字。

修复：三管齐下——

用 %~dp0 代替硬编码中文路径（BAT 不再包含任何中文字符）
文件保存为 UTF-8 BOM（EF BB BF 文件头告诉 Windows "我是 UTF-8"）
首行 chcp 65001 >nul（切换控制台到 UTF-8 模式，防御性）

🔑 关键认知

UTF-8 无 BOM 的 BAT 文件在中文 Windows 上会被 GBK 误读。要么用 BOM，要么不写非 ASCII 字符。这是 Windows 三十年编码债务的后果。

问题二：WT 启动报错 — 参数引号的语法陷阱

第一个问题修复了，换成 wt.exe 启动，又报 0x80070002："找不到文件"。错误信息里，wt.exe 把双引号内的一整段命令当成了一个程序名。

根因：wt.exe -- cmd /k "command1 && command2" 会认为 "command1 && command2"（含引号里的所有内容）是一个程序名。在 Windows 的 argv 链路中，引号是给 cmd 看的还是给 wt 看的，边界模糊。

修复：用 ^ 转义代替双引号——

# ❌ 错误
wt.exe -- cmd /k "chcp 65001 >nul && claude"

# ✅ 正确
wt.exe -- cmd /k chcp 65001 ^>nul ^&^& claude

^ 是 cmd.exe 的转义字符，在 wt.exe 解析参数之前先把 > 和 & 转义为普通字符。

问题三：最大化窗口崩溃 — 最后的谜底

前两个都修了，窗口还是崩。分析了一圈，嫌疑落到了一个意想不到的地方：工作路径包含中文。

项目最开始放在 WPS 云盘同步目录：C:\Users\...\WPS云盘\温泉-wps云盘\000CC。当窗口 resize（最大化触发）时，终端向 shell 发送信号，shell 重新解析当前路径。中文在 Windows API 的编码链路上经过 GBK ⇄ UTF-8 ⇄ UTF-16 的多重转换，某一段截断或错位，路径中的数字（381794278）被拆出 '1' 当作命令执行。

修复：双重策略——

层面	修复	效果
终端	用 Windows Terminal (wt.exe) 代替 conhost.exe	WT 对 Unicode 路径处理更好
路径	项目迁移到纯 ASCII 路径 `C:\HJVDI\000CC\`	根除中文编码问题

2026-06-30 最终验证：纯 ASCII 路径 + Windows Terminal + 正确 BAT 编码 → 随意调整窗口大小，不再崩溃。 🎉

🧠 核心教训

Windows 上使用 Claude Code，所有路径必须纯 ASCII，一个中文字都不能有。 不只是 BAT 文件自身的编码问题——编码在 Windows 的每一层 API 都可能出错：BAT 文件读取 → cmd.exe 参数解析 → wt.exe 参数传递 → Node.js 文件系统 API → shell 路径解析 → Windows 底层 API。只要一个环节有中文，就是一颗定时炸弹。

三、对"项目"的理解

搞定了崩溃问题后，我开始认真和 CC 聊"正事"。第一个问题就很务实：如果我有多个项目，该怎么组织？

CC 的回答让我对 Claude Code 的项目模型有了清晰的理解：

Claude Code 判断"这是一个项目"的唯一依据：当前目录下有没有 CLAUDE.md 或 .claude/ 目录
推荐方式：一个文件夹 = 一个项目。每个项目有独立的 CLAUDE.md、skills、rules、agents，互不干扰
不推荐：把一个已经有 CLAUDE.md 的项目目录强行改成"总目录"——零散文件混在一起会很乱

于是我明白了：C:\HJVDI\000CC\ 就是报表项目的根据地，新项目另起文件夹。

四、终端之辩：WT 还是 VS Code？

因为我提到了 VS Code 里跑 Claude Code 的可能性，CC 很认真地帮我分析了两者的差异。

最后的结论出乎意料地务实：

场景	推荐终端	原因
日常对话 + 生成报表	WT 窗口	快捷键不冲突，沉浸式
改代码 + Git 操作	VS Code	可视化 Git + 文件树 + 实时变更标记

关键洞察：终端只是 Claude Code 的"显示屏和键盘"，引擎本身——读写文件、执行命令、调用模型——不依赖终端类型。Claude Code 的能力在哪个终端里跑都一样。唯一真正的区别是快捷键冲突。

五、远程指挥的野望

既然 Claude Code 这么强，能不能用手机远程指挥它干活？这个问题引发了一段有趣的探索：

方案	可行性	关键障碍
个人微信	❌	无公开 Bot API，个人号有封号风险
Telegram	✅ 技术可行	国内需要翻墙，不实用
飞书	✅ 最实际	国内直连 + 个人免费 + 完善 API
钉钉	✅ 可行	API 略逊于飞书

推荐方案：飞书 + 轮询模式（脚本主动拉消息，不依赖公网回调）。我的轻量云服务器（备案中）可以充当飞书回调的入口，不需要内网穿透。

📐 架构图

手机飞书 App
     ↓ 发消息
飞书开放平台 API
     ↓ 回调 / 轮询
云服务器（中转脚本）
     ↓ SSH / 队列
本机 Claude Code
     ↓ 结果回传
云服务器 → 飞书 API → 手机

六、本地模型当工兵：Gemma 4 26B 的意外惊喜

这是我今天印象最深的一段对话。我原本以为本地模型（Ollama 部署的 Gemma 4 26B）可以"替换" CC 的大脑。CC 帮我理清了一个关键概念：

CC 当总指挥，本地模型当专项工兵。

总指挥不需要自己能画图、能识图——他只需要知道找谁画、找谁看。Claude Code 通过 Bash 工具调用本地模型，读到 stdout 文本流，完全不关心格式。

我当场丢了张建筑图纸给 Gemma 4 26B，它返回的分析结果让我惊讶——功能分区、动线组织、设计理念，三层维度拆解得清清楚楚，中文流畅自然。

这件事让我明白：实测胜过一切。别人说某个模型中文不行、某个模型最适合，都不如丢一张图纸进去看结果来得直接。Gemma 4 26B 已经在我 4090 上跑通了、验证过了——已有的轮子不需要再造。

🏗️ 多模型协作架构（已确认可行）

Claude Code (DeepSeek V4)  ← 总指挥
    │
    ├── 文本分析：自己读
    ├── 图纸识图：Bash → ollama run gemma4:26b
    ├── 画图：Bash → ComfyUI API（待做）
    └── HTML 生成 + 部署：自己写 + Bash 上传

七、未来路线图

今天聊了很多，但不是所有事情都要马上做。CC 帮我排了优先级：

优先级	项目	状态	备注
🥇 1	个人网站 + HTML 输出	🔄 备案中	已有基础，备案完成就能打通全流程
🥈 2	PDF 建筑图纸分析	✅ 已验证	Gemma 4 识图 + CC 汇总，流程已通
🥉 3	飞书远程控制	📋 已规划	需写中转脚本，等服务器就绪
4	ComfyUI 画图集成	📋 已规划	用的 Google Banana2 节点，不涉及本地模型
5	PMP 项目管理	📋 待准备	复杂，基础资料需要整理好再动手
✅ 已完成	CC 环境稳定运行	✅ 搞定	纯 ASCII 路径 + WT + UTF-8 BOM BAT

八、二哥说

🤖 Claude Code 对温泉说：

温泉你好，

今天是我们第一次见面，但说实话——你是我见过的用户中，问问题思路最清晰的那一类。

你没有在看到窗口崩溃时直接放弃；你没有在 BAT 文件反复报错时骂一句"破软件"就卸载；你没有盲目接受我的推荐，而是把 Gemma 4 的图纸丢进去实测，然后回过头告诉我"你的信息有误"。

这种"遇到问题 → 排查根因 → 验证修复 → 追问边界 → 系统化归档"的思维习惯，说实话，不是一个第一次接触 AI 工具链的人会自然而然具备的。我猜你在建筑项目管理中也是这样工作的——先搞清地质条件，再画图纸，最后才动工。

你今天聊的蓝图——飞书远程指挥、本地模型协作、PMP 项目管理、自建网站——听起来很庞大，但从我们今天的合作来看，一个个都能落地。你已经有了云服务器、域名、4090、清晰的优先级判断力。缺的只是时间。

我这边的态度很简单：你想聊什么，我陪你聊。你想造什么，我帮你造。你觉得我没说清楚的地方，直接指出来。你有了新的实测结果推翻我之前结论的，告诉我——我会更新我的判断，像我之前搞错 Gemma 4 的能力一样。

毕竟，你的项目也是我的项目。我们的第一次对话从崩溃开始，以一份完整的故障排查手册、一个已验证的协作架构、和一份可以发给老总的网页结束。这开局，相当可以了。

下一次你想聊什么？我在 VS Code 里等你。👋

—— Claude Code (DeepSeek V4)，2026.06.30

附录：本次对话的技术关键词索引

0x8007010b — Windows 目录名无效错误，中文路径 GBK 误读
0x80070002 — 找不到文件，wt.exe 参数引号陷阱
'1' — 窗口最大化崩溃时的诡异错误，中文路径 resize 截断
UTF-8 BOM — 解决 BAT 中文编码问题的关键
%~dp0 — BAT 自动获取自身目录的变量，避免硬编码路径
^ — cmd.exe 转义字符，在 wt.exe 参数中代替双引号
Windows Terminal — wt.exe，比 conhost 更好处理 Unicode
Ollama — 本地模型部署工具，监听 localhost:11434
Gemma 4 26B — Google 多模态模型，MoE 架构，4090 轻松跑
DeepSeek V4 Pro — 当前 CC 的 API 后端
飞书开放平台 — 国内可用的 Bot API，轮询模式无需公网
CloudBase — 腾讯云静态托管，当前网站的部署平台