AI 协作心法：主观能动性与验证闭环

0. 核心复盘：Gemini CLI 安装事件

事件回顾： 在安装 Gemini CLI 时，AI (Comet) 提供了一条基于 Python (pip) 的安装路径。我基于信任执行，结果陷入了权限报错、版本冲突和非官方旧工具的泥潭。

关键转折： 我跳出对话，通过 Google 搜索 "Gemini CLI"，发现官方推荐的是 Node.js (npm) 路径。修正方向后，问题迎刃而解。

后续优化（工程化落地）： 在解决初步问题后，我发现 Obsidian Terminal 每次重启都需要手动输入 export PATH。这不符合“自动化/低切换成本”的原则。 通过进一步探索，我将环境变量写入 ~/.zshrc 配置文件，实现了一次配置，永久生效。这一步将“临时变通”转化为了“稳健的工程解法”。

1. 守 (Shu)：理解 AI 的“能”与“不能”

在默认的协作模式中，我们倾向于将 AI 视为“全知全能的百科全书”或“高级资深工程师”。

• AI 的优势：极其擅长代码补全、样板生成、解释概念、转换格式。

• AI 的默认行为：

  • 迎合性：它倾向于顺着你的思路（即使是错的）继续走，而不是跳出来反驳你。

  • 幻觉/滞后：对于最新的工具链（如 Gemini CLI 的官方变动），它可能基于旧数据（Python 版）一本正经地胡说八道。

  • 路径依赖：一旦对话进入了 "Python 环境配置" 的上下文，它会试图在这个死胡同里修修补补，而不是建议你 "换辆车"（改用 Node.js）。

“守”的误区：完全交出方向盘，盲信 AI 给出的第一条路径。

2. 破 (Ha)：打破“指令-执行”的单向依赖

我们必须打破“我问 -> AI 答 -> 我做”的线性流。这种模式在涉及环境配置、架构选型等高成本操作时，风险极大。

• 破除“权威错觉”：AI 给出的方案（尤其是安装命令、API 调用）只是一个候选建议，而非标准答案。

• 识别“高风险操作”：

  • 涉及系统底层环境（如 sudo、系统 Python、PATH 变量修改）。

  • 路径异常复杂（如需要降级 Python 版本、编译依赖）。

  • 直觉警报：当你觉得“装个小工具不应该这么麻烦”时，通常你的直觉是对的，而 AI 的方案是错的。

3. 离 (Ri)：构建“主观能动性”主导的工程化工作流

建立一种新的协作关系：我是架构师/技术经理，AI 是执行力强但经验不足的初级助手。

✅ 新原则 1：Trust, but Verify (信任，但验证)

对于任何涉及环境变更或长链路的操作，执行“双源验证”：

1. AI 提案：获取 AI 的操作步骤。

2. 官方验证：花费 30 秒，Google 搜索该工具的 GitHub Readme 或官方文档。

   • 案例：AI 说用 pip，官网说用 npm → 听官网的。

✅ 新原则 2：及时止损 (Fail Fast)

如果 AI 提供的方案在前两步操作中连续报错（如权限问题、依赖冲突）：

• 不要让 AI 继续打补丁（它会越补越破）。

• 立即暂停，质疑前提：“是不是路径本身选错了？”

• 重启对话，或者切换信息源（Google）。

✅ 新原则 3：上下文隔离 (Context Hygiene)

• 当发现路走歪了，不要在旧的对话框里纠缠。

• 新建对话（New Chat），清除 AI 的“错误上下文记忆”，给它一个清爽的开始。

🎯 总结

“尽信 AI 不如无 AI。”

AI 是最强大的加速器，但它绝不能成为方向盘。 人的价值在于主观能动性——即定义目标、判断路径可行性、以及在 AI 犯傻时果断接管控制权的能力。

未来的工作流公式： 成功 = 明确意图 + AI 生成草稿 + (人脑直觉 + 官方文档验证) + 迭代执行 + 固化自动化