发布三篇新文章：Claude Code权限问题、AI工作流、Git Bash中文命令bug排查

Author: hyglgithub

src/content/draft/draft.md

@@ -0,0 +1,159 @@
+---
+title: Claude Code 自动更新权限问题解决
+description: 解决 Claude Code 在 Windows 系统下因 Node.js 自定义安装路径导致的 npm 权限不足问题，实现自动更新功能。
+published: 2026-06-26
+tags: [Claude Code, Node.js, Windows, 权限问题]
+category: 原创
+draft: false
+---
+
+## 问题现象
+
+在 PowerShell 中运行 `claude` 命令时，出现红色警告：
+
+```
+✘ Auto-update failed: no write permission to npm prefix · Run /doctor
+```
+
+根据提示，执行诊断命令 `/doctor`（即 `claude doctor`），发现 `Updates` 区域明确标记为 **`failed (no_permissions)`**：
+
+```
+Updates ⚠
+├ Auto-updates: enabled
+├ Auto-update channel: latest
+├ Last update attempt: failed (no_permissions) — 2026-06-26
+├ Stable version: 2.1.181
+└ Latest version: 2.1.193
+```
+
+这表明自动更新因权限问题而失败。于是手动触发更新：
+
+```powershell
+PS C:\Users\31548> claude update 
+Current version: 2.1.187 
+Checking for updates to latest version... 
+New version available: 2.1.193 (current: 2.1.187) 
+Installing update... 
+Using global installation update method... 
+Error: Insufficient permissions to install update 
+Try running with sudo or fix npm permissions 
+Or consider using native installation with: claude install
+```
+
+错误信息明确提示 **权限不足**，无法安装更新。
+
+---
+
+## 问题根源
+
+### 我的 Node.js 安装位置
+
+我的 Node.js 没有安装在默认的 `C:\Program Files\nodejs`，而是安装在了 **`D:\develop\nodejs`**（如果你也自定义了安装路径，请以你的实际路径为准）。
+
+> 💡 默认情况下，Node.js 会安装在 `C:\Program Files\nodejs`，该目录通常需要管理员权限才能写入。而自定义到 D 盘后，权限规则依然严格，同样需要处理。
+
+查看 npm 全局安装目录：
+
+```powershell
+npm prefix -g
+# 输出：D:\develop\nodejs
+```
+
+`claude doctor` 也证实了 Claude Code 的实际安装位置：
+
+```
+Path: D:\develop\nodejs\node_modules\@anthropic-ai\claude-code\bin\claude.exe
+```
+
+### 为什么"权限不足"？
+
+Windows 操作系统对**非系统盘根目录下的文件夹**（尤其是由管理员账户创建的文件夹）默认会施加较严格的 NTFS 权限。对于 `D:\develop\nodejs`：
+
+- 该目录的**写入权限**默认仅赋予 `Administrators` 组和 `SYSTEM`。
+- 我日常使用的是**普通用户**（非管理员）的 PowerShell，对该目录**没有修改权限**。
+- 当 `claude update` 试图在 `D:\develop\nodejs\node_modules\@anthropic-ai\claude-code` 中**删除旧版本、写入新版本**时，操作系统拒绝访问，导致更新失败。
+
+---
+
+## 解决方案 1：以管理员身份手动更新（不推荐，无法自动更新）
+
+如果你只是想临时解决一次更新，可以**以管理员身份运行 PowerShell**，然后执行 `claude update`。
+
+### 操作步骤：
+
+1. 关闭当前 PowerShell。
+2. 在开始菜单中搜索 "PowerShell"，右键点击，选择 **"以管理员身份运行"**。
+3. 在提升权限的窗口中，执行：
+   ```powershell
+   claude update
+   ```
+4. 更新完成后，关闭管理员窗口。
+
+### 为什么不推荐？
+
+- **每次更新都需要手动提权**，十分繁琐。
+- **无法实现后台自动更新**——Claude Code 的自动更新机制在普通用户权限下依然会因为权限不足而失败，你只能每次都手动干预。
+- 长期依赖管理员权限运行会增加安全风险（习惯性提权可能导致误操作）。
+
+因此，如果你希望一劳永逸，请参考下面的**方案 2**。
+
+---
+
+## 解决方案 2：直接授予当前用户写入权限（长效方案）
+
+通过修改 `D:\develop\nodejs` 目录的 NTFS 权限，为当前登录用户添加"修改"和"写入"权限，让普通用户也能正常执行更新操作。
+
+### 操作步骤（图形界面）
+
+1. **打开文件资源管理器**，导航到 `D:\develop\nodejs` 文件夹。
+
+2. **打开属性窗口**  
+   右键点击 `nodejs` 文件夹，选择 **"属性"**。
+
+3. **进入安全选项卡**  
+   点击 **"安全"** 选项卡，然后点击下方的 **"编辑(E)"** 按钮（修改权限）。
+
+4. **切换用户并勾选权限**  
+   在权限列表中，找到并选中 `Users` 组，然后在下方 **"修改"** 和 **"写入"** 对应的"允许"列打勾。  
+   如果你希望更彻底，也可以直接勾选 **"完全控制"**（推荐，因为更新时需要删除旧文件，完全控制最省心）。
+
+   ![权限设置界面](image.png)
+
+5. **应用并确认**  
+   点击"确定"保存。系统会开始应用权限到所有子文件夹和文件（因为 `node_modules` 内文件极多，这个过程可能需要几十秒到一分钟，**请耐心等待**）。
+
+---
+
+## 验证与后续操作
+
+权限修改完成后，**关闭所有普通权限的终端**，重新打开一个**非管理员**的 PowerShell 或 CMD，执行：
+
+```powershell
+claude update
+```
+
+此时更新流程会正常进行，输出类似：
+
+```
+Current version: 2.1.187
+Checking for updates to latest version...
+New version available: 2.1.193 (current: 2.1.187)
+Installing update...
+Using global installation update method...
+Update successful!
+```
+
+版本升级到最新版（如 2.1.193）。
+
+再次运行 `claude doctor`，检查 `Updates` 状态：
+
+```
+  Updates ✔
+  ├ Auto-updates: enabled
+  ├ Auto-update channel: latest
+  ├ Last update attempt: succeeded — 2026-06-26
+  ├ Stable version: 2.1.181
+  └ Latest version: 2.1.193
+```
+
+此时 `no_permissions` 已经消失，自动更新功能恢复正常。

src/content/draft/选型决策流程图.png

@@ -0,0 +1,98 @@
+---
+title: 别急着让 AI 写代码：让探索先于执行
+description: 在复杂工程场景下，如何在 AI 的创造力与工程稳定性之间寻找平衡，分享一套 Skill → Exploration → Design → Plan → Execute 的工作流。
+published: 2026-07-03
+tags: [AI编程, 工作流, Agent Skills, Claude Code]
+category: 原创
+draft: false
+---
+
+在复杂工程场景下，如果一开始直接让模型进入执行阶段，往往会暴露出一个典型问题：
+
+> 约束越宽松，模型创造力越强，输出越不稳定；约束越严格，创造力越受限，输出越稳定。
+
+例如，你直接对 AI 说"帮我写一个 RAG 系统"。由于约束很少，模型会产生大量可能性。它可能选择：单体架构、微服务架构、Agentic RAG、Hybrid Search、Query Rewrite、MCP Tool Calling、Memory Enhanced Retrieval。看起来很聪明，但问题是结果高度随机，每次输出可能完全不同，工程稳定性极差。
+
+另一种方式，你把 Prompt 写得极其严格：使用 Spring Boot 3.5、使用 PostgreSQL、必须使用 Redis Cache、必须使用 pgvector、采用 MVC 分层结构、按照指定目录生成代码。结果输出稳定了，但 AI 的创造力几乎被抹掉，它退化成高级代码生成器。
+
+如何在 AI 的创造力与工程稳定性之间寻找平衡呢？下面是我逐渐形成的一套工作流。
+
+---
+
+## Skill：封装领域经验，而非执行能力
+
+很多 Agent Framework 里，Skill 被定义为执行能力，例如 `write_code()`、`search_web()`、`generate_image()`。这是一种很自然的理解，在任务自动化场景下也确实有效。不过，我个人更倾向于另一种用法：把 Skill 用来存储 Principles（原则）、Experience（经验）、Methodology（方法论）。
+
+例如，`backend_architecture` 里面存储的是高内聚、低耦合、模块化、接口隔离、事务一致性、可扩展性。`bilibili_thumbnail_design` 里面存储的是标题主体、低信息密度、用户视角、缩略图可读性、点击率优先。
+
+Skill 不再优先承担执行功能，而更像是一种领域认知的载体。
+
+这种方式的优势在于，它为 AI 提供了明确的认知边界，同时保留足够的探索空间。一套标准可以跨场景复用，使模型更多依赖自身知识进行判断，而不是机械执行固定指令。某种程度上，它更接近人类专家基于经验和方法论进行决策的过程。
+
+这种工作方式的核心并不是告诉 AI："应该怎么做"。而是先告诉 AI："什么才是好的结果"。
+
+---
+
+## Exploration：AI 发散可能路径，人类持续参与决策
+
+当需求提出后，先加载对应领域的 Skill，然后进入方案探索阶段（Exploration）。注意，这里不是让 AI 直接执行，而是先基于现有上下文，在既定边界内生成多种可行方案。
+
+例如，我说"我要做一个浏览器插件"，AI 可以瞬间生成：
+
+- 方案 A：Popup 驱动
+- 方案 B：Content Script 注入
+- 方案 C：Side Panel 方案
+- 方案 D：Background Worker 持续监听
+
+但这只是第一步。接下来，人类通过持续提问、选择和引导，不断缩小解空间：
+
+- 维护成本如何？
+- 开发周期多久？
+- 个人开发是否合适？
+- 是否方便后续扩展？
+
+每一轮问答都在帮助 AI 更精准地接收新的约束，并逐步过滤掉不合适的选项。
+
+AI 负责生成可能性，人类负责持续收紧边界，两者反复交替，方案空间逐步收窄。
+
+从某种意义上说，AI 在这里并不是执行者，而更像一个高速的"可能性生成器"。
+
+---
+
+## Design：人类主导决策，逐步确定方向
+
+经过多轮探索和筛选，Design 逐渐成型。
+
+整个流程变成：
+
+> 模糊需求 → Skill 加载领域经验 → 方案探索（Exploration）→ 多轮人工筛选与提问 → Design
+
+Design 不应该是需求的直接翻译，而应该是探索、权衡与选择之后自然形成的结果。很多时候，用户自己一开始也并不知道最佳方案是什么，只有在与 AI 的交互中，通过不断对比和权衡，方向才逐步清晰。
+
+这个阶段，人类始终掌握决策权。每一步选择都基于人类对业务目标、资源限制、团队能力的判断——这些是 AI 无法获取的上下文。
+
+---
+
+## Plan & Execute：从设计到确定性执行
+
+Design 被确定后，开放式探索基本结束。接下来将 Design 转化为 Plan，即具体执行路径，例如：创建数据库 → 创建 Entity → 创建 Service → 创建 API → 编写测试。
+
+计划确定后，进入 Execute 阶段，按计划逐项执行。此时创造性探索已经基本完成，在很多情况下，可以逐步切换到成本更低、偏执行导向的模型，例如 GPT mini、Qwen、Claude Haiku、本地模型。
+
+---
+
+## 总结
+
+AI 擅长扩展解空间，工程的本质却是不断收敛解空间。真正高效的 AI 工作流，不是让 AI 一开始就直接执行，而是在不同阶段动态调整创造力与约束的比例。
+
+这个过程可以概括为：
+
+> Skill → Exploration → Design → Plan → Execute
+
+前期充分释放 AI 的发散能力，让它在既定原则边界内生成大量可能路径；后期逐步增强约束，将方案收敛为确定性的执行步骤。于是有了这样的变化曲线：
+
+![创造力与稳定性变化曲线](image.png)
+
+创造力与稳定性不是二选一，而是随着工程推进不断调整权重。关键在于把 AI 最强的一面用在它最擅长的地方，而不是一开始就把它锁死。
+
+我越来越觉得，在 AI 时代，开发者的价值重心可能正在发生变化。除了具体实现能力之外，定义原则、组织 Skill、引导方案探索、选择技术路线、持续收紧约束，正在变得越来越重要。 **真正的工程能力，从来不只是执行得更快，而是更早找到正确的方向。**