AI 时代最危险的不是代码写不出来，而是你完全不怀疑 AI 编造的‘真理’。

惊魂 5 小时：我造了一堆“高级垃圾”

今天，我在推进 Awesome-Claude-Agent-Skills 仓库的开发时，犯了一个极其低级且极具代表性的错误。

为了追求效率，我直接咨询了 Gemini 和 ChatGPT。它们表现得像两位极其专业的资深架构师，对答如流，顺着我的思路给出了一套逻辑自洽的方案：：

• 信誓旦旦地引用了一个根本不存在的协议标准 —— “MCP 2026”；

• 硬生生发明了 “Skills 必须符合 MCP 协议” 的技术要求，把 Markdown 指令和工具协议强行缝合。

由于这些术语听起来逻辑自洽，且符合我对未来技术的预期，我竟然没有第一时间去翻阅官方文档进行核对，而是直接按照它们的建议让Claude Code进行开发。直到把GLM-5的5小时额度基本用光，我才惊觉：我造了一堆垃圾... 

深度反省：为什么我会掉进坑里？

看着空掉的额度和一堆废代码，我总结了三个核心教训。每一个，都值得正在用 AI 提效的你警惕：

🚫 错把“概率”当成了“事实”

我太依赖大模型的生成能力，却忘了它本质上是一个概率预测模型。为了维持对话的权威感，大模型会基于概率“脑补”出最合理的谎言。它在乎的是“像不像”，而我在乎的是“对不对”。

🚫 思想上的“偷懒”导致了验证缺失

因为习惯了 AI 带来的“爽感”，我产生了思想上的懈怠。我直接采纳了 AI 投喂的术语，却跳过了最关键的交叉验证（Cross-Validation）。在 AI 开发流程中，这种不加验证的偷懒是致命的。

🚫 缺乏对知名模型的“防范意识”

即使是 Gemini 或 ChatGPT 这样的一线模型，依然无法摆脱幻觉。知名度不代表真实性，如果没有复核，模型的“一本正经 + 逻辑自洽”就是最致命的毒药。

避坑准则：引入 NotebookLM 建立“真理护城河”

为了确保下次不再掉坑，我为 AIwork4me 项目制定了全新的开发流程（The Triple-Stack Workflow）：

第一步：地基审计 (Grounding via NotebookLM)

• 动作：将所有官方文档（如 MCP 官网、Claude Code 官方规范原文）导入 NotebookLM。

• 目标：利用 NotebookLM 极强的“证据意识”，通过 RAG 明确术语、边界和协议标准，从源头上掐灭幻觉。

第二步：工程实现 (Execution via Claude Code)

• 动作：将 NotebookLM 验证过、设计好的规则与架构，喂给 Claude Code 进行代码生成。

• 目标：确保每一行代码、每一个定义都 100% 遵循官方规范，实现硬核落地。

第三步：内容润色 (Marketing via Gemini/ChatGPT)

• 动作：最后，让通用模型处理文案、排版和社区分发。

• 目标：把冰冷的工程逻辑转化为易读的品牌故事。

写在最后

当 AI 疯狂输出时，请保持你那份该死的怀疑，并对自己不熟悉的名词术语要一一复核。