AI时代漫游指南

Agent 记忆设计从零开始：构建真正持续学习的 AI 助手

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

你是否有过这种体验：昨天跟 AI 聊了两个小时，把项目背景解释清楚，调教出了满意的回复风格。今天再打开，一切归零。这不是 AI 变蠢了，而是**记忆问题**。好消息是：这个问题完全可以工程化解决。本文从零开始，带你搭一套真正能持续积累上下文的 Agent 记忆系统。 --- ## 为什么 AI 没有记忆 AI 模型本质上是**无状态的**：每次推理只看当前输入，不保留任何会话外的信息。这是设计决策，不是缺陷——有状态会带来隐私问题、一致性问题、存储成本问题。但对于"我想让 AI 真正了解我的项目"这个需求，无状态是障碍。解决思路很直接： > **把需要记住的东西，放进 AI 每次都能读到的地方。** 记忆系统本质上就是一套"把信息持久化，并在正确时机加载进上下文"的机制。 --- ## 最小可行版本（5 分钟能搭好）先不谈架构，先让它能用。 **第一步**：在项目根目录创建 `CLAUDE.md`： ```markdown # 项目：我的博客 ## 基本信息 - 技术栈：Astro 5 + Tailwind + Vercel - 部署命令：git push（Vercel 自动部署） - 本地开发：npm run dev ## 重要约定 - 不修改已发布文章的文件名（影响 URL） - 每次 push 前必须 npm run build 验证 ``` **第二步**：在项目里创建一个 `notes.md`，记今天做了什么： ```markdown # 工作日志 ## 2026-03-16 - 添加了 TagFilter 组件，支持按标签筛选文章 - 发现 dark mode 下表格样式有问题，待修复 - 明天：添加系列筛选功能 ``` **就这样**。下次打开 Claude Code，它会自动读 `CLAUDE.md`，然后你说"继续昨天的工作"——它读 `notes.md`，知道做到哪里了。这个最小版本解决了 80% 的问题。 --- ## 为什么要分层随着项目增长，`CLAUDE.md` 里的信息会越来越多，开始互相干扰： - 架构决策放哪里？ - 操作步骤放哪里？ - 今天遇到的 bug 放哪里？ - 这个函数的设计原因放哪里？全塞进一个文件，Claude 的注意力被稀释，重要信息找不到。 **分层的核心思想**：按信息的**稳定性**分类存储。越稳定的信息越底层，越易变的信息越顶层。 --- ## 五层架构详解 ``` memory/ ├── character/ # 最稳定：角色定义 ├── abilities/ # 稳定：能力边界 ├── skills/ # 中稳定：操作规程 ├── knowledge/ # 中易变：领域知识 └── logs/ # 最易变：日志信息 ``` ### 第 0 层：Character（角色）定义 Agent "是谁"。几乎不变，但决定了所有判断的基准。 ```markdown # character.md ## 角色我是 ai-navigator-coordinator，AI时代漫游指南的项目管理 Agent。 ## 核心原则 - 每次 push 前必须 build 验证，不跳过 - 不修改已发布文章的 slug - 架构决策记录到 knowledge，不做隐性决定 ## 风格 - 直接，不啰嗦 - 遇到不确定的决策，先列出选项，不自作主张 ``` **什么时候写**：项目启动时写一次，之后只在核心约束变化时修改。 ### 第 1 层：Abilities（能力声明）声明 Agent 能做什么、不能做什么，以及当前的运行状态。 ```yaml # heartbeat.yaml last_seen: 2026-03-16T10:00:00 status: active can_do: - 管理博客内容发布 - 协调前端功能迭代 - 维护 tasks.yaml 需求状态 cannot_do: - 修改已发布文章的 slug - 在没有 build 验证的情况下 push - 删除 memory/ 目录下的任何文件 ``` 关键是 `cannot_do` 列表——每一条都是踩过的坑。 **什么时候写**：初始化时写，每次发现 Agent 做了不该做的事，就在这里加一条约束。 ### 第 2 层：Skills（操作规程）可复用的 SOP，把验证过的流程固化下来。 ```markdown # deploy-blog.md ## 部署博客 ### 前置检查 1. git pull 拉取最新代码 2. npm run build（必须通过，exit 0） 3. 检查 dist/ 生成了预期的页面 ### 执行 git add -A && git commit -m "描述" && git push ### 验证等待 Vercel 部署（约 2 分钟），访问新页面确认上线 ``` **什么时候写**：某个操作你做了第二遍的时候，把它写成 skill。 ### 第 3 层：Knowledge（结构化知识）项目的"大脑"——架构决策、配置说明、已知问题。每个文件只写一个主题，控制在 100 行以内。 ``` knowledge/ ├── site-architecture.md # 站点结构和技术栈 ├── seo-decisions.md # SEO 相关的决策记录 ├── deployment-config.md # 部署配置说明 └── content-guidelines.md # 文章发布规范 ``` **什么时候写**：做了一个重要决策之后立刻写，记录决策本身和原因。三个月后你（和 Agent）还能理解为什么。 ### 第 4 层：Information（日志信息）时效性最强的信息：每日工作日志、讨论记录。 ```markdown # 2026-03-16_daily.md ### 上午 - 完成：TagFilter 组件添加系列筛选功能 - 发现：dark mode 下 prose table 样式异常 - 原因：tailwind prose dark 变量覆盖问题 - 解决：已在 global.css 添加 .dark .prose thead th 覆盖 ### 待办 - [ ] 修复移动端 TOC 折叠动画 - [ ] 添加精选文章筛选按钮 ``` **什么时候写**：每天工作结束前写，不超过 15 分钟。 --- ## CLAUDE.md：记忆系统的入口光有记忆文件还不够——需要告诉 Claude 去哪里找。 ```markdown # AI时代漫游指南 — 项目概要 ## 快速信息 - 站点：my-project.example.com - 技术栈：Astro 5 + Tailwind + Vercel - 部署：git push 触发 Vercel 自动构建 ## 约定（最重要的在这里） - 部署前必须 npm run build 验证 - 不修改已发布文章的 slug ## 找什么，去哪里看 - 上次工作进度 → memory/logs/ 最新日期文件 - 部署/发布流程 → memory/skills/ - 架构和配置 → memory/knowledge/ - 角色约束 → memory/character/character.md ``` **原则**：CLAUDE.md 是索引，不是内容。细节永远在对应的 memory 层级里。 --- ## 搭建顺序建议不要一次搭完整的五层，那样很难坚持。按阶段来： **第一周**：只建 CLAUDE.md + logs 日志 - 每天 5 分钟记日志 - 确保"继续昨天的工作"能正常运转 **第二周**：遇到反复操作，写进 skills - 每写一个 skill，就删掉 CLAUDE.md 里对应的重复内容 **第三周**：遇到重要决策，写进 knowledge - 不用强迫自己写，事件驱动 **以后**：根据实际遇到的问题，补 character 约束和 abilities 限制 --- ## 一个判断标准如果你不确定某个信息该不该放进记忆系统，问自己： > **如果明天清空所有对话，这个信息还需要 Agent 知道吗？** 需要 → 放进记忆文件。不需要 → 放在当前对话里就好。记忆是成本，不是越多越好。精选最关键的上下文，Agent 才能高效运作。 --- *相关：[Claude Code 的记忆架构](/blog/claude-code-memory-architecture) · [一个人的 AI 公司](/blog/one-person-ai-company) · [Agent 心跳自治](/blog/agent-heartbeat-autonomy)*

Agent 心跳自治：让 AI 在后台持续工作的工程实践

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

"自治 AI" 听起来很酷，但大多数人的实现是这样的：写一个 while 循环，每隔几分钟让 LLM 执行一次任务，希望它不出错。这不是自治，这是轮询加祈祷。真正能在生产环境稳定运行的 Agent 自治，需要工程化的心跳机制。本文分享我在 [Agentic Engineering System](/blog/one-person-ai-company)（30+ 微服务）中实践出来的方案。心跳机制是系统里每个 Agent 的基础能力，与[五层记忆体系](/blog/claude-code-memory-architecture)共同构成 Agent 持续运作的骨架。 --- ## 什么是心跳机制心跳（Heartbeat）在分布式系统里是个老概念——节点定期发送信号，证明自己还活着。在 Agent 系统里，心跳做的事情更多： 1. **存活证明**：更新 `last_seen` 时间戳 2. **例行检查**：扫描待办任务、检查系统状态 3. **触发操作**：执行低优先级的后台工作 4. **约束执行**：在每次循环里校验约束条件没有被破坏一个健康的心跳循环，让 Agent 从"被动响应"变成"主动运作"。 --- ## 心跳文件结构每个 Agent 的 `abilities/heartbeat.yaml` 定义心跳行为： ```yaml # heartbeat.yaml agent_id: my_project_agent last_seen: 2026-03-16T10:00:00+08:00 status: active # active | paused | degraded schedule: interval: 30m timezone: Asia/Shanghai quiet_hours: "00:00-07:00" # 深夜不执行 tasks: - id: check_requirements desc: 扫描 tasks.yaml，找出 in_progress 和 open 状态的需求 priority: high - id: update_daily_log desc: 追加今日工作记录到 logs/ priority: medium - id: sync_knowledge desc: 检查 knowledge 是否有需要更新的文件 priority: low constraints: hard: - "不修改任何已发布文章的 slug" - "不回滚 tasks.yaml 到更旧的版本" - "部署前必须通过 npm run build" - "不删除 memory/ 下的任何文件" soft: - "优先完成 in_progress 状态的需求" - "单次心跳不超过 3 个任务" - "遇到不确定的决策，记录到 daily.md 等待人工确认" recovery: on_error: log_and_continue # 单个任务失败不中断整个循环 max_retries: 2 notify_on_failure: feishu # 失败时飞书通知 ``` 这个文件不只是配置，它是 Agent 的**行为宪法**。 --- ## 触发方式：三种选择 ### 方案一：cron + Claude Code 最简单的实现。在终端里： ```bash # 每 30 分钟触发一次 /loop 30m "执行心跳任务：检查待办、更新日志、处理低优先级工作" ``` 优点：零基础设施，立刻能用。缺点：依赖终端保持打开，机器睡眠会中断。适合：个人开发者日常使用，不要求 24/7。 ### 方案二：系统级定时任务在服务器上用 cron 或 Windows Task Scheduler： ```bash # Mac launchd (~/Library/LaunchAgents/com.a9.heartbeat.plist) StartInterval 1800 ``` 或者直接调用 Agent API： ```bash # crontab -e */30 * * * * curl -s -X POST localhost:8000/api/agent/heartbeat ``` 优点：真正后台运行，机器在线就执行。缺点：需要服务一直运行。 ### 方案三：Agent 作为常驻服务 Agent 内部实现心跳循环，作为 Flask 服务的一部分： ```python # agent.py (简化示意) import threading import time def heartbeat_loop(): while True: try: run_heartbeat_tasks() except Exception as e: log_error(e) notify_feishu(f"心跳异常: {e}") time.sleep(1800) # 30分钟 # 在服务启动时 threading.Thread(target=heartbeat_loop, daemon=True).start() ``` 这是我现在用的方案——Agent 自己管理自己的心跳，不依赖外部调度器。 --- ## 约束声明：防止 Agent 越界这是整个心跳机制里最容易被忽视、也最重要的部分。 **真实案例**：我的心跳 Agent 在某次循环里扫描到 tasks.yaml 里有一条"过时的"需求描述，自作主张把它更新了——但那条描述是我手动写的版本说明，不是错误。 Agent 没有恶意，它在"帮忙"。但帮错了地方。解决方案：把每一条血泪教训变成约束声明。 ```yaml constraints: hard: - "不修改任何已发布文章的 slug" # 原因：slug 变更会导致所有外链 404，SEO 重置 - "不回滚 tasks.yaml" # 原因：曾经踩坑，Agent 把手动版本说明当成错误修复了 - "不删除 memory/ 下的任何文件" # 原因：记忆文件一旦删除，历史上下文永久丢失 - "不在没有 build 验证的情况下 push" # 原因：vite build 不做类型检查，运行时 bug 只在部署后暴露 ``` `hard` 约束是绝对禁止，不管什么情况。`soft` 约束是偏好，可以在有充分理由时违反。 **写约束的原则**：每条约束后面都应该有注释说明"为什么"。没有原因的约束，Agent 在模糊情况下不知道该如何权衡。 --- ## 任务优先级：防止心跳做太多初版心跳设计容易犯的错：任务列表太长，什么都想做。结果是：每次心跳运行时间越来越长，一个任务出错会拖累所有任务，上下文窗口被大量"检查"类信息占满，真正重要的工作反而做不好。 **实践原则**： ``` 单次心跳 ≤ 3 个任务 high priority 任务：每次必做 medium priority 任务：隔次做 low priority 任务：每周做一次 ``` 这对应了心跳文件里的 `schedule` 设计： ```yaml tasks: - id: check_critical_alerts priority: high always_run: true - id: update_daily_log priority: medium run_every: 2 # 每2次心跳执行一次 - id: knowledge_audit priority: low run_on_day: monday # 每周一 ``` --- ## 失败恢复：心跳出错怎么办 Agent 心跳失败是正常事件，不是异常情况。关键是**故障隔离**： ```yaml recovery: on_task_error: log_and_continue # 单个任务失败，记录错误，继续下一个任务 on_critical_error: pause_and_notify # 严重错误（如文件系统不可访问），暂停心跳并通知 max_consecutive_failures: 3 # 连续3次失败后降级为 degraded 状态 degraded_behavior: - "只执行 check_critical_alerts" - "每次失败都发飞书通知" - "等待人工确认后恢复 active" ``` `degraded` 状态是关键设计——不是直接停止，而是以最小功能运行，同时发出信号等待干预。 --- ## 每日日志：心跳的记忆痕迹每次心跳执行后，更新 `logs/YYYY-MM-DD_daily.md`： ```markdown ### 10:00 心跳 #42 - ✅ 检查需求：3 个 in_progress，0 个 blocked - ✅ 更新日志：追加本条记录 - ⏭ 知识审计：跳过（非周一） ### 10:30 心跳 #43 - ✅ 检查需求：同上 - ⚠️ 发现：FR-ANC-030 已完成但状态未更新，标记为 implemented - ✅ 更新日志 ``` 这个日志有两个用途： 1. **调试**：出问题时能回溯"心跳 #X 那次做了什么" 2. **接续**：人工介入时读最近的日志，立刻了解系统状态 --- ## 状态机：心跳的生命周期 Agent 的运行状态不是简单的开/关，是一个状态机： ``` [init] → [active] → [paused] ↓ ↑ [degraded] → [active] ↓ [stopped] ``` - `active`：正常运行，按 schedule 执行任务 - `paused`：主动暂停（比如重大变更期间），不执行任务但保持服务 - `degraded`：检测到异常，降级运行，等待人工干预 - `stopped`：服务停止（不同于 paused，不会自动恢复）状态存在 `heartbeat.yaml` 的 `status` 字段里，每次心跳检查状态，决定是否执行任务。 --- ## 从理论到实践我的系统里现在有 7 个 Agent 同时在跑心跳，覆盖不同的领域和任务。几个经验总结： **不要追求 100% 自动化**。有些决策就应该等人工确认——心跳的 `soft` 约束里要有"不确定就记录等待"的原则。 **约束要持续迭代**。每次发现 Agent 做了不该做的事，第一反应不是骂 AI，而是把这个场景加进约束列表。 **日志是最便宜的保险**。哪怕心跳只做了三件事，也要记录清楚。调试时你会感谢自己。 **心跳间隔要合理**。太短（5分钟）会产生大量无意义的执行记录，太长（24小时）失去了自治的意义。30分钟是我现在用的节奏，覆盖大多数场景。 --- 自治不是让 AI 无限制地运行，而是在明确的边界里高效地运作。边界越清晰，Agent 越可靠。 --- *系列文章：[Agent 架构探索](/blog/series/Agent%20%E6%9E%B6%E6%9E%84%E6%8E%A2%E7%B4%A2) · 上一篇：[一个人的 AI 公司](/blog/one-person-ai-company)*

独立开发者的 AI 工具箱 2026：我实际在用的那些

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

网上的 AI 工具推荐文章有两个共同问题：要么是推广，要么是作者根本没深度用过。这篇不一样——全部是我每天在用、付费在用、踩过坑的工具。每个工具我都说清楚**为什么用**和**什么情况下不用**。 --- ## 编程类 ### Claude Code（核心主力） **用途**：几乎所有编程任务的执行层。我的工作流：Claude Code 作为常驻终端，配合 [CLAUDE.md 记忆体系](/blog/claude-code-memory-architecture)，能持续接续上下文。不只是"帮我写代码"，更是"帮我管理一个工程项目"。真正让它好用的不是 Claude 有多聪明，而是 [Hooks 系统](/blog/claude-code-hooks)——给 AI 加上审计层之后，我才真正放心让它执行写文件、运行命令这类操作。 **收费**：$20/月（Claude Pro），值。 **什么时候不用**：纯探索性的对话、不需要操作文件系统的问题，用 Claude.ai 网页版即可，不消耗 Claude Code quota。 --- ### Cursor（备用） **用途**：需要在 IDE 里直接看效果时。 Cursor 的优势是和代码编辑器深度集成——可以直接在编辑器里接受/拒绝改动，视觉上更直观。 **什么时候不用**：我大多数工作在终端完成，Cursor 的图形界面反而是额外认知负担。如果你是 GUI 优先的开发者，它比 Claude Code 更顺手。 --- ### GitHub Copilot（已弃用）曾经用了两年。在 Claude Code 出来之后，基本没打开过。原因：Copilot 的补全模式适合"知道方向、需要加速"的场景；Claude Code 的对话模式适合"需要 AI 帮你决策"的场景。我现在更多后者。 --- ## 模型层 ### Claude Sonnet 4.6（日常主力） **用途**：90% 的编程任务、内容生成、分析推理。速度和质量的最佳平衡点。Opus 更聪明但慢 3 倍，Haiku 更快但质量下降明显。Sonnet 是我的默认选择。 ### Qwen3-235B（本地高质量推理） **用途**：需要本地运行的高质量推理任务。在 Mac Studio 上通过 [omlx](/projects) 运行，4bit 量化，8.5 分（我的主观评分），接近 Claude 的质量。用于不想把数据发到云端的场景——内部文档分析、本地 Agent 任务。详见：[MLX 本地模型运行实践](/blog/mlx-local-model-mac)。 **什么时候不用**：需要快速响应时，本地模型延迟明显高于云端 API。 ### MiniMax M2.5（高性价比云端） **用途**：中等复杂度任务的云端补充，成本是 Claude 的 1/5。我用它跑 Liaison Agent（飞书消息处理），响应速度够快，中文理解好，适合高频低复杂度的 Agent 任务。 --- ## 效率工具 ### Raycast AI（日常问答） **用途**：碎片化问题的快速答案，不想开浏览器时。 `⌘ Space` → 打字 → 得到答案。比开 Claude.ai 快 10 秒。别小看这 10 秒，一天省下来很可观。 ### Context7 MCP（实时文档） **用途**：在 Claude Code 里获取最新的库文档。 [MCP 协议](/blog/mcp-in-practice)注册后，Claude 遇到不确定的 API 会自动拉取最新文档，而不是靠训练数据里的旧知识。 Astro 5、Tailwind v4、Vercel 最新配置——全靠它保持准确。 ### Perplexity（实时信息） **用途**：需要引用来源的实时信息查询。和 Claude 的区别：Perplexity 适合"这件事目前是什么状态"（实时+引用），Claude 适合"帮我分析这件事"（推理+生成）。 --- ## 内容创作 ### Claude.ai（内容生成） **用途**：博客文章的初稿、结构设计、文案打磨。这个站点上的大多数文章，都经历了这样的流程：我写提纲 → Claude 扩写初稿 → 我大幅修改和注入个人经历 → 发布。 **关键**：Claude 的初稿通常太完整、太正确、太无趣。我的工作是把自己真实的声音注入进去。 ### Notion AI（笔记整理） **用途**：把乱糟糟的笔记整理成结构化内容。不用它写新东西，只用它整理已有的内容。它在 Notion 环境里的集成体验很好。 --- ## 工具选择的几个原则 **1. 工具层和模型层分开评估** Claude Code 好用不等于 Claude 模型最好。工具层（工作流集成）和模型层（推理质量）是两个维度，分开选择。 **2. 深度用两三个，胜过浅度用十个** 我试过很多工具，现在日常用的不超过 8 个。每个都用到很深，理解它的边界在哪里。 **3. 本地 vs 云端：数据敏感度决定** 财务数据、私人文件、内部代码——走本地模型。公开内容、一般任务——走云端 API。不要教条，按数据敏感度分类。 **4. 工具成本要放进总体 ROI 里算** 我每月在 AI 工具上花约 $40（Claude Pro + Perplexity Pro）。对应省下的时间，ROI 轻松超过 10x。但前提是真的深度用了，不是买了放着。 --- ## 2026 年值得关注的方向 **Agent 基础设施**：不只是单个 AI 工具，而是多个 Agent 协作的系统。我已经在跑的这套 [30+ 微服务系统](/blog/one-person-ai-company) 是一个方向。 **本地模型实用化**：Qwen3-235B 4bit 能在 Mac 上跑到接近 Claude 的质量，这个趋势会继续。数据主权会成为越来越多人的考量。 **工具收敛**：AI 工具的数量会从爆炸式增长转向收敛，真正有深度的工具会胜出。 --- *相关文章：[Claude Code 记忆架构](/blog/claude-code-memory-architecture) · [MCP 协议实战](/blog/mcp-in-practice) · [MLX 本地模型](/blog/mlx-local-model-mac) · [一个人的AI公司](/blog/one-person-ai-company)*

Claude Code 15 个实用技巧：从够用到真正好用

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

用了 Claude Code 大半年，踩了很多坑，也摸索出一套让它真正好用的方法。整理了 15 条，全部来自实际使用，没有"多用多练"这种废话。 --- ## 上下文管理 ### 1. CLAUDE.md 是上下文的基础设施，不是笔记本很多人把 CLAUDE.md 当记事本用，什么都往里塞。结果文件越来越长，反而稀释了重要信息。正确用法：CLAUDE.md 只放**约束和索引**，不放内容。 ```markdown # 项目约定 - 部署前必须 npm run build - 不修改已发布文章的 slug # 知识在哪里找 - 架构决策 → memory/knowledge/ - 上次进度 → memory/logs/最近日期_daily.md - 部署流程 → memory/skills/deploy.md ``` 控制在 50 行以内。细节放到 memory 层级，CLAUDE.md 只做指针。 ### 2. 用 `/clear` 而不是新开窗口上下文窗口满了，很多人的反应是关掉终端重开。正确做法是 `/clear` 清空对话历史，但保留 CLAUDE.md 加载的上下文。重开窗口会重新读 CLAUDE.md，效果一样，但 `/clear` 更快。 ### 3. 用 `#` 引用文件，而不是"你去看 xxx 文件" ``` ❌ "你去看 src/components/SearchDialog.tsx" ✅ "修改 #src/components/SearchDialog.tsx 的搜索结果布局" ``` `#` 前缀让 Claude 立刻读取文件，而不是等到它自己决定要不要读。在上下文有限时，这个区别很重要。 ### 4. 长任务开始前先写 Plan 对于超过 3 步的任务，先让 Claude 写一个执行计划，确认后再开始执行： ``` 先给我写一个实现计划，不要开始写代码。计划确认后我会说"开始执行"。 ``` 这避免了 Claude 理解偏差导致的大段无效代码。 --- ## 工作流加速 ### 5. `/loop` 让重复任务自动化 Claude Code 支持循环执行： ```bash /loop 30m "检查 tasks.yaml 待办，处理一条 in_progress 需求" ``` 适合：定时同步、心跳检查、内容批量处理。不适合：需要实时判断的复杂任务。 ### 6. 用任务文件替代长对话超过 10 轮的对话，信息密度下降，Claude 容易"忘事"。更好的方式：把任务写成 markdown 文件，每次执行时读文件： ``` 读取 tasks/current-sprint.md，按优先级处理第一条未完成任务。完成后在文件里标记状态，再告诉我结果。 ``` 任务状态在文件里持久化，不依赖对话历史。 ### 7. 用 `--dangerously-skip-permissions` 解放生产力（谨慎使用）在已建立信任的项目里，每次工具调用都要确认会极大拖慢速度。在受控环境（已配置 Hooks 的项目）里可以跳过权限确认： ```bash claude --dangerously-skip-permissions ``` **前提**：必须先配置好 [Hooks](/blog/claude-code-hooks) 做安全兜底，不然等于裸奔。 ### 8. Git worktree 做实验性修改不确定 Claude 的改动是否正确时，用 git worktree 隔离： ```bash git worktree add ../experiment-branch -b experiment cd ../experiment-branch # 让 Claude 在这里做修改 # 满意了再 merge，不满意直接删 ``` Claude Code 对 worktree 的支持很好，能正确识别当前工作目录。 --- ## 提示词技巧 ### 9. 给 Claude 角色，而不是只给任务 ``` ❌ "重构这个函数" ✅ "你是一个 Python 性能工程师，重构这个函数，重点关注减少不必要的内存分配" ``` 角色定义给 Claude 一个判断框架，输出质量会明显提升。 ### 10. 用"不要做什么"约束输出范围 Claude 倾向于"帮忙做更多"，但有时候你只想要最小改动： ``` 只修改 getUser 函数的错误处理逻辑。不要重构其他函数，不要添加类型注解，不要修改函数签名。 ``` 明确说"不要做什么"，比说"只做这一件事"更有效。 ### 11. 要求 Claude 先解释再修改对于重要文件，先让 Claude 解释当前代码的逻辑，再提修改： ``` 先解释 auth.py 里 verify_token 函数的工作原理，特别是 token 过期的处理逻辑。理解后我再告诉你要改什么。 ``` 这一步能暴露 Claude 是否真正理解了代码，避免盲目修改。 --- ## 防坑实践 ### 12. 每次重要操作后立刻 git commit 不要攒着一起提交。Claude 做了 5 件事，你只想撤销第 3 件——很麻烦。养成习惯：Claude 完成一个独立功能 → 立刻 commit → 继续下一个。 ``` 完成了，帮我写一个 git commit message，然后我来 commit。 ``` ### 13. 让 Claude 写测试，而不是"帮我验证" ``` ❌ "你觉得这段代码对吗？" ✅ "为这个函数写 3 个边界用例的单元测试，包括空输入和超大输入" ``` Claude 自己评估自己写的代码，容易产生确认偏差。测试用例是更客观的验证方式。 ### 14. 用 `/cost` 追踪费用，避免账单冲击长会话的 token 消耗会超出预期。定期查看： ```bash /cost ``` 如果发现费用飙升，通常是某个任务在循环消耗上下文。找到后 `/clear` 重置。 ### 15. 保存有效的提示词到 CLAUDE.md 当你发现某个提示词特别有效，不要让它消失在对话历史里： ```markdown # 有效提示词模板 ## 代码审查 "以安全工程师视角审查这段代码，重点找 injection 漏洞和权限边界问题" ## 重构 "最小化改动重构，保持函数签名不变，只改内部实现" ## 调试 "不要立刻给解决方案。先列出 3 个最可能的原因，我来确认方向" ``` 好的提示词是可复用资产，对待它就像对待代码一样。 --- ## 一个元技巧所有这些技巧背后有一个共同逻辑：**把你的隐性知识显性化，放进 Claude 能读到的地方**。你知道的约束、你踩过的坑、你喜欢的代码风格——这些都应该在某个文件里，而不是在你的脑子里靠每次对话重新传递。这是 Claude Code 和普通 AI 对话框最大的区别：它可以积累上下文，前提是你愿意建设这个上下文。 --- *系列文章：[Claude Code 实战](/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98) · 相关：[记忆架构](/blog/claude-code-memory-architecture) · [Hooks 实战](/blog/claude-code-hooks) · [MCP 实战](/blog/mcp-in-practice)*

Claude Code Hooks：让 AI 编程有迹可循、可审计、可回滚

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

大多数人用 Claude Code 的方式是：给指令，看结果，如果不对就撤销。这能工作，但有一个隐患：**你不知道 AI 做了什么，直到它做完**。 Claude Code 的 Hooks 系统解决了这个问题。它让你能在 AI 执行每一步操作的前后注入自定义逻辑——不只是"允许还是拒绝"，而是完整的可编程拦截层。 --- ## Hooks 是什么 Hooks 是 Claude Code 在特定事件发生时自动执行的 shell 命令。目前支持四种 Hook 事件： | Hook | 触发时机 | |------|---------| | `PreToolUse` | AI 调用任何工具**之前** | | `PostToolUse` | AI 调用任何工具**之后** | | `Notification` | Claude Code 发出通知时 | | `Stop` | Claude Code 完成响应时 | 每个 Hook 可以： - **接收** 工具调用的完整上下文（工具名、参数、结果） - **执行** 任意 shell 命令 - **影响** 工具调用的行为（PreToolUse 可以阻止执行） --- ## 配置方式 Hooks 在 `~/.claude/settings.json` 里配置： ```json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "~/.claude/hooks/pre-bash.sh" } ] } ], "PostToolUse": [ { "matcher": "Write", "hooks": [ { "type": "command", "command": "~/.claude/hooks/post-write.sh" } ] } ] } } ``` `matcher` 支持工具名（`Bash`、`Write`、`Edit`、`Read` 等）或 `*`（匹配所有工具）。 --- ## 实战用例一：危险命令拦截最常见的需求：阻止 AI 执行某些高风险操作。 `~/.claude/hooks/pre-bash.sh`： ```bash #!/bin/bash # 读取工具调用的 JSON 输入 INPUT=$(cat) COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // ""') # 拦截危险操作 DANGEROUS_PATTERNS=( "rm -rf /" "git push --force" "DROP TABLE" "chmod 777" "> /dev/sda" ) for pattern in "${DANGEROUS_PATTERNS[@]}"; do if echo "$COMMAND" | grep -qi "$pattern"; then echo "🚫 Hook 拦截：检测到危险命令模式 '$pattern'" >&2 # 退出码 2 = 阻止工具执行并显示错误 exit 2 fi done exit 0 ``` Hook 的退出码决定行为： - `0` — 允许执行 - `1` — 记录警告但允许执行 - `2` — **阻止执行**，向 Claude 返回错误信息 --- ## 实战用例二：文件修改自动备份每次 AI 写文件之前，先备份一份： `~/.claude/hooks/pre-write.sh`： ```bash #!/bin/bash INPUT=$(cat) FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""') if [ -f "$FILE_PATH" ]; then BACKUP_DIR="$HOME/.claude/backups/$(date +%Y%m%d)" mkdir -p "$BACKUP_DIR" # 保留目录结构 RELATIVE_PATH=$(echo "$FILE_PATH" | sed 's|/|_|g') cp "$FILE_PATH" "$BACKUP_DIR/${RELATIVE_PATH}.bak" echo "✅ 已备份: $FILE_PATH → $BACKUP_DIR" >&2 fi exit 0 ``` 这样即使 AI 写坏了文件，`~/.claude/backups/` 里永远有当天的版本。 --- ## 实战用例三：操作日志记录 Claude Code 所有工具调用，方便事后审计： `~/.claude/hooks/audit-log.sh`： ```bash #!/bin/bash INPUT=$(cat) TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // "unknown"') TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ") LOG_FILE="$HOME/.claude/audit.log" # 提取关键参数（避免记录完整文件内容） case "$TOOL_NAME" in "Bash") DETAIL=$(echo "$INPUT" | jq -r '.tool_input.command // ""' | head -c 200) ;; "Write"|"Edit") DETAIL=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""') ;; "Read"|"Glob"|"Grep") DETAIL=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.pattern // ""') ;; *) DETAIL=$(echo "$INPUT" | jq -r '.tool_input | to_entries[0].value // ""' | head -c 100) ;; esac echo "$TIMESTAMP | $TOOL_NAME | $DETAIL" >> "$LOG_FILE" exit 0 ``` 配置到所有工具的 PostToolUse： ```json { "hooks": { "PostToolUse": [ { "matcher": "*", "hooks": [{ "type": "command", "command": "~/.claude/hooks/audit-log.sh" }] } ] } } ``` 一天下来，`audit.log` 会记录 Claude 做的每一件事。 --- ## 实战用例四：飞书完成通知长任务结束时推送通知，不用盯着屏幕等： `~/.claude/hooks/notify-done.sh`： ```bash #!/bin/bash INPUT=$(cat) # Stop hook 触发：Claude 完成了一轮响应 # 从环境变量读取飞书 webhook if [ -z "$FEISHU_WEBHOOK" ]; then exit 0; fi curl -s -X POST "$FEISHU_WEBHOOK" \ -H "Content-Type: application/json" \ -d '{ "msg_type": "text", "content": { "text": "✅ Claude Code 任务完成" } }' > /dev/null exit 0 ``` 在 `settings.json` 的 `Stop` hook 里注册，长编译或大规模重构完成后，手机飞书就收到通知。 --- ## 组合：完整的安全 + 可观测配置把上面的 hooks 组合在一起： ```json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [{ "type": "command", "command": "~/.claude/hooks/pre-bash.sh" }] }, { "matcher": "Write", "hooks": [{ "type": "command", "command": "~/.claude/hooks/pre-write.sh" }] } ], "PostToolUse": [ { "matcher": "*", "hooks": [{ "type": "command", "command": "~/.claude/hooks/audit-log.sh" }] } ], "Stop": [ { "matcher": "*", "hooks": [{ "type": "command", "command": "~/.claude/hooks/notify-done.sh" }] } ] } } ``` 这套配置实现了： - 🛡 危险命令自动拦截 - 💾 文件修改前自动备份 - 📋 所有操作完整审计日志 - 📱 任务完成飞书通知 --- ## Hook 脚本的几个设计原则 **1. 保持快速** 每个工具调用都会触发 Hook，慢 Hook 会明显拖慢 Claude Code 的响应速度。避免在 Hook 里做网络请求（除非是非阻塞的 Stop Hook）。 **2. 静默失败** Hook 脚本里的错误不应该崩溃 Claude Code。在脚本里加 `set +e`，确保即使 Hook 出错，也不影响主流程。 **3. 用 stderr 输出诊断信息** Hook 的 stdout 会传给 Claude，stderr 才是给用户看的日志。诊断信息一律写 stderr： ```bash echo "debug: processing $FILE_PATH" >&2 # 正确 echo "debug: processing $FILE_PATH" # 会被 Claude 读到 ``` **4. 幂等设计** 同一操作被触发多次，效果应该相同。备份脚本里用时间戳命名，避免覆盖。 --- ## 与记忆系统结合 Hooks 和[记忆架构](/blog/claude-code-memory-architecture)可以结合使用。比如，在 PostToolUse 里自动更新 Agent 的操作日志到 `logs/`： ```bash #!/bin/bash INPUT=$(cat) TOOL=$(echo "$INPUT" | jq -r '.tool_name') DETAIL=$(echo "$INPUT" | jq -r '.tool_input | tostring' | head -c 100) DAILY_LOG="./memory/logs/$(date +%Y-%m-%d)_ops.md" echo "- $(date +%H:%M) [$TOOL] $DETAIL" >> "$DAILY_LOG" exit 0 ``` 这样 Agent 的每次操作都自动沉淀进记忆，下次会话能复盘"上次到底做了什么"。 --- Hooks 系统把 Claude Code 从"黑盒 AI"变成了"可观测、可审计、可干预的工程工具"。从信任，到验证——这才是在生产环境放心使用 AI 的正确姿势。 --- *系列文章：[Claude Code 实战](/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98) · 相关阅读：[Claude Code 的记忆架构](/blog/claude-code-memory-architecture) · [MCP 协议实战](/blog/mcp-in-practice)*

Claude Code 的记忆架构：如何让 AI 真正记住你的项目

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

大多数人用 Claude Code 的姿势是这样的：打开终端，开始一个新会话，然后花 5 分钟解释"我的项目是做什么的、用什么技术栈、现在遇到什么问题"…… 下次打开，再解释一遍。这不是 Claude Code 该有的使用方式。 --- ## 为什么 AI 不记得你？ Claude Code 本质上是无状态的——每次对话都是全新的上下文窗口。它不会自动记住上次你说过什么，除非你把信息放进它能读到的地方。问题不在于 Claude 不够聪明，而在于**你没有给它一个持久化的记忆系统**。好消息是：Claude Code 本身就提供了这个能力，只是大多数人没用好。 --- ## 五层记忆架构我在自己的 Agentic Engineering System（30+ 微服务的多 Agent 系统）里，为每个 Agent 设计了五层记忆体系： ``` memory/ ├── character/ # Agent 人格与价值观 ├── abilities/ # 能力声明（会做什么、不会做什么） ├── skills/ # 操作规程（SOP） ├── knowledge/ # 结构化领域知识 └── logs/ # 日志、讨论、临时信息 ``` 这个结构不是凭空想出来的，是在每天使用中迭代出来的。 ### 第 0 层：Character（人格）这一层定义 Agent 是"谁"——它的角色、价值观、行为边界。 ```markdown # 角色定位我是 AI Navigator Coordinator，负责管理 my-project.example.com 的内容规划和功能迭代。 ## 核心原则 - 每次部署前必须 build 验证 - 不修改已发布文章的 slug（影响 SEO） - 重要决策记录到 knowledge/ ``` Character 文件很少变动，但它决定了 Agent 在面对模糊指令时的判断基准。 ### 第 1 层：Abilities（能力声明）心跳 + 能力边界。Agent 每隔一段时间更新这里，证明自己"还活着"并且知道自己的职责范围。最关键的是**明确写出不该做的事**： ```yaml # heartbeat.yaml last_seen: 2026-03-16T10:00:00 status: active constraints: - do_not_modify: "src/content/blog/*/slug" - do_not_revert: "tasks.yaml" - always_build_before_deploy: true ``` 这层解决了一个真实的坑：我的心跳 Agent 曾经把 tasks.yaml 回滚到旧版本，就是因为 Abilities 层缺少约束声明。 ### 第 2 层：Skills（操作规程）可复用的操作步骤，类似 SOP。每次需要做某件事，不是临时摸索，而是执行已验证的 skill。比如部署博客的 skill： ```markdown # deploy-blog.md ## 前置检查 1. git pull 拉取最新 2. npm run build 验证无错误 3. 检查 dist/sitemap-index.xml 包含新页面 ## 执行 git add -A && git commit -m "..." && git push ## 验证等待 Vercel 部署完成（~2分钟），访问新页面确认 ``` Skill 的价值在于**把踩过的坑固化成流程**，不反复踩。 ### 第 3 层：Knowledge（结构化知识）项目的"大脑"。包含： - 架构决策及其原因（ADR） - 技术栈选型说明 - 已知问题和解决方案 - 业务规则我的经验是**每个知识文件保持单一主题，100 行以内**。文件太大，Claude 的注意力会分散。 ``` knowledge/ ├── site-architecture.md # 站点结构 ├── seo-strategy.md # SEO 策略 ├── deployment-config.md # 部署配置 └── content-guidelines.md # 内容规范 ``` ### 第 4 层：Information（日志与讨论）时效性信息：工作日志、讨论记录、临时决策。每天一个 `YYYY-MM-DD_daily.md`，记录： - 做了什么 - 遇到什么问题 - 明天要做什么这层不求精，求**持续记录**。Claude 在新会话里读这些日志，能快速恢复"上次我们做到哪里了"的状态。 --- ## CLAUDE.md：记忆的入口光有记忆文件还不够，你需要一个"索引"——让 Claude 知道这些记忆在哪里、应该在什么时候读。这就是 `CLAUDE.md` 的作用。每个项目根目录放一个 `CLAUDE.md`，写清楚： ```markdown # 项目概要 - 产品名：AI时代漫游指南 - 技术栈：Astro 5 + Tailwind + Vercel - 重要约定：部署前必须 npm run build ## 记忆结构 - knowledge/：架构决策、配置说明 - logs/：日志在这里找上次进度 ## 常用命令 - 开发：npm run dev - 构建：npm run build - 部署：git push（Vercel 自动） ``` Claude Code 每次启动都会读 `CLAUDE.md`，这是它接入项目记忆的第一个锚点。 --- ## 实战效果用了这套架构之后，我的工作流变成： 1. 打开终端，Claude Code 自动读 CLAUDE.md 2. 说"继续昨天的工作"——它读 daily.md，知道上次做到哪里 3. 说"按照 skill 部署"——它执行已验证的流程，不乱来 4. 工作完成，更新 daily.md，下次无缝接续最关键的变化：**我不再需要反复解释背景**。Claude 变成了真正意义上的持续合作者，而不是一个每次都失忆的助手。 --- ## 常见误区 **误区 1：把所有信息都塞进 CLAUDE.md** CLAUDE.md 只应该是索引和最关键的约定，不超过 100 行。细节放到对应的 memory 层级里。 **误区 2：记忆文件只写不读** 如果你不在 CLAUDE.md 里指引 Claude 去读这些文件，它不会主动读。要明确告诉它"遇到部署问题看 skills/"。 **误区 3：知识文件越详细越好** 适度即可。过于详细的文件会稀释重要信息。每个文件聚焦一个主题，保持可读性。 --- ## 下一步如果你现在的项目没有任何记忆结构，从最小可行版本开始： 1. 建一个 `CLAUDE.md`，写 3-5 条最重要的约定 2. 建一个 `notes/daily.md`，开始记录工作日志 3. 当某个操作流程你做了第二遍，把它写成 skill 记忆系统不是一次性建好的，是在每次使用中慢慢生长的。 --- *本文基于在 Agentic Engineering System（30+ Agent 微服务）中的真实实践，当前系统已稳定运行 3 个月。*

MCP 协议实战：给你的 AI 装上真正的手和眼

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

AI 最大的局限之一：它只能用你喂给它的信息。你问它今天的新闻，它不知道。你让它查你的数据库，它做不到。你希望它操作你的文件系统，它只能靠猜。 MCP（Model Context Protocol）就是为了解决这个问题而生的——给 AI 装上手和眼，让它能真正触及外部世界。 --- ## MCP 是什么 MCP 是 Anthropic 提出的开放协议，定义了 AI 模型与外部工具/数据源之间的通信标准。简单理解：它是一套规范，让任何人都能写一个"工具服务器"，AI 客户端（如 Claude Code）可以发现这些服务器并调用里面的工具。 ``` Claude Code ←→ MCP 协议 ←→ MCP 服务器（你写的） ├── 读取文件 ├── 查询数据库 ├── 调用 API └── 执行命令 ``` MCP 之前，每个 AI 工具都要自己定义工具调用格式，彼此不兼容。MCP 之后，写一次服务器，所有支持 MCP 的客户端都能用。 --- ## 核心概念：三种能力 MCP 服务器可以暴露三种能力： ### Tools（工具） AI 可以主动调用的函数。类似 function calling，但标准化了。 ```json { "name": "search_posts", "description": "搜索博客文章", "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } } } } ``` ### Resources（资源） AI 可以读取的数据。文件、数据库记录、API 响应都可以包装成 Resource。 ```json { "uri": "file:///data/posts.json", "mimeType": "application/json", "description": "所有博客文章的元数据" } ``` ### Prompts（提示模板）预置的对话模板，用户可以通过斜杠命令触发。这三者可以单独使用，也可以混合——一个 MCP 服务器通常同时提供 Tools 和 Resources。 --- ## 动手：搭一个最小 MCP 服务器用 Python 官方 SDK（`mcp`），实现一个能查询本地 markdown 文章的工具服务器： ### 安装 ```bash pip install mcp ``` ### 代码 ```python # blog_mcp_server.py from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent import json import os from pathlib import Path app = Server("blog-tools") POSTS_DIR = Path("./src/content/blog") @app.list_tools() async def list_tools(): return [ Tool( name="search_posts", description="在博客文章中搜索关键词，返回匹配的文章标题和摘要", inputSchema={ "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" } }, "required": ["query"] } ), Tool( name="get_post", description="读取指定 slug 的文章全文", inputSchema={ "type": "object", "properties": { "slug": { "type": "string", "description": "文章的 slug（文件名不含 .md）" } }, "required": ["slug"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "search_posts": query = arguments["query"].lower() results = [] for f in POSTS_DIR.glob("*.md"): content = f.read_text(encoding="utf-8") if query in content.lower(): # 提取标题（frontmatter 第一行 title:） title = next((l.split(":", 1)[1].strip().strip("'\"") for l in content.splitlines() if l.startswith("title:")), f.stem) results.append({"slug": f.stem, "title": title}) return [TextContent(type="text", text=json.dumps(results, ensure_ascii=False))] elif name == "get_post": slug = arguments["slug"] post_file = POSTS_DIR / f"{slug}.md" if not post_file.exists(): return [TextContent(type="text", text=f"文章 {slug} 不存在")] return [TextContent(type="text", text=post_file.read_text(encoding="utf-8"))] if __name__ == "__main__": import asyncio asyncio.run(stdio_server(app)) ``` ### 注册到 Claude Code 在 `~/.claude/claude_desktop_config.json`（或 Claude Code 的 MCP 配置文件）里添加： ```json { "mcpServers": { "blog-tools": { "command": "python", "args": ["/path/to/blog_mcp_server.py"] } } } ``` 重启 Claude Code，现在你可以直接说： > "搜索所有关于 Agent 的文章" > "读一下 one-person-ai-company 这篇文章" Claude 会自动调用你的工具，而不是凭印象回答。 --- ## 真实用例：我在用的 MCP 工具 ### context7 — 实时文档查询这是我用得最多的 MCP 工具。当 Claude Code 需要某个库的最新 API 时，context7 直接从源头拉文档，不靠训练数据里的旧知识。 ```bash # Claude.md 里配置使用 context7 获取最新文档，避免用过时的 API ``` 效果：Astro 5 的新语法、Vercel 的最新配置，全部实时准确。 ### 文件系统工具 Claude Code 内置的文件读写工具本质上就是 MCP 工具——这也是为什么它能直接编辑你的代码而不只是生成代码片段。 ### 自定义飞书工具我给系统里的 Agent 写了飞书 MCP 工具，让 Claude 能直接发消息到飞书群、读取最近的对话记录。核心工具： - `send_feishu_message(chat_id, text)` — 发消息 - `get_recent_messages(chat_id, count)` — 读最近 N 条 - `create_task(title, assignee)` — 创建飞书任务这让"AI 回复飞书消息"变成了可靠的工作流，而不是脆弱的字符串拼接。 --- ## 设计好 MCP 工具的原则用了一段时间之后，几点心得： **1. 工具描述要像写给人看的** AI 通过 `description` 字段决定什么时候用这个工具。描述不清楚，工具就会被误用或不被使用。 ❌ `"description": "查询数据"` ✅ `"description": "按关键词全文搜索博客文章，返回匹配文章的 slug 和标题列表"` **2. 一个工具做一件事** 不要写"万能工具"：`do_everything(action, params)`。每个工具的参数应该类型明确、数量少、意图单一。 **3. 返回结构化数据，不要返回散文** AI 能更可靠地处理 JSON 数组，而不是"找到 3 篇文章，分别是……"这种自然语言描述。 **4. 错误信息要有意义** ```python # ❌ return [TextContent(type="text", text="Error")] # ✅ return [TextContent(type="text", text=json.dumps({ "error": "post_not_found", "slug": slug, "available_slugs": [f.stem for f in POSTS_DIR.glob("*.md")][:5] }))] ``` 当工具出错时，好的错误信息能让 AI 自动修正，而不是卡住。 --- ## MCP vs 直接 function calling 有人会问：直接用 OpenAI 的 function calling 不就够了，为什么要 MCP？ | 维度 | Function Calling | MCP | |------|---------|-----| | 标准化 | 厂商各自定义 | 统一协议 | | 复用性 | 绑定特定模型/SDK | 任意支持 MCP 的客户端都能用 | | 服务发现 | 需要在代码里硬编码 | 客户端自动发现服务器能力 | | 资源支持 | 仅 Tools | Tools + Resources + Prompts | | 生态 | 各厂商各自为政 | 快速增长的统一生态 | MCP 的核心价值是**可移植性**：今天写的工具服务器，未来换了 AI 客户端照样能用。 --- ## 下一步 MCP 生态正在快速增长。如果你用 Claude Code，现在就可以开始： 1. 找几个高质量的社区 MCP 服务器（[mcp.so](https://mcp.so) 有索引） 2. 为你最常用的内部工具写一个 MCP 服务器 3. 把常用的 MCP 工具注册进 Claude Code 的配置当 AI 能真正触及你的数据和工具，那种"终于有个靠谱助手"的感觉才会真正到来。 --- *系列文章：[Claude Code 实战](/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98) · 相关阅读：[Claude Code 的记忆架构](/blog/claude-code-memory-architecture)*

独立开发者的一天：AI 真正改变了什么

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

我想记录一个真实的工作日，不是为了炫耀生产力，而是想诚实地回答一个问题： **AI 到底改变了什么？** --- ## 早上 8:30 — 开始前的 15 分钟泡咖啡，打开飞书，看各个 Agent 的日报。这是一年前没有的仪式。每个 Agent 在夜里运转，early morning 是读它们"工作报告"的时间：哪个服务心跳正常，昨天处理了什么任务，有没有需要人工决策的问题挂起。 **改变**：我从"开始工作"变成了"接班"。有东西在我之前就已经运转了几个小时。 **没变**：咖啡还是要自己泡。 --- ## 9:00 — 第一段编程时间打开终端，Claude Code 读 CLAUDE.md，加载项目上下文。今天的任务：给这个博客加一个新功能——文章的系列筛选。以前的工作流是：读文档 → 想方案 → 写代码 → 调试 → 重来。现在的工作流是：说"我想要这个功能，现有代码在这里" → Claude 给方案 → 我判断方案 → Claude 实现 → 我 review → 调整 → done。 **改变**：我从"写代码"变成了"审代码"。工作的重心从执行移向了判断。 **没变**：读懂代码的能力仍然是核心。Claude 可以写，但我必须能读懂才能 review。不懂代码，审不了。 --- ## 10:30 — 一个卡住的问题 TypeScript 类型报错，Claude 给了三个方案，我选了第二个，然后发现这个方案有副作用——在某个边界情况下会静默失败。这花了 40 分钟才找到。 **改变**：Claude 解决了 90% 的常规问题，腾出了时间。但剩下那 10% 的复杂问题，还是要自己啃。而且因为 Claude 产出代码的速度快，这种"快速生成、慢速调试"的节奏需要适应。 **没变**：调试能力。边界情况的直觉。对系统行为的理解。这些没有被替代。 --- ## 12:00 — 午饭 + 信息消化午饭时间不看 X，改成用 Perplexity 做定向信息消化：搜几个我在关注的话题，看最近有什么新进展。这不是被动刷，是主动查。区别很大。 **改变**：信息消费从流被动推送变成了主动检索。Perplexity 让这个过程快了 3 倍。 **没变**：判断信息价值的能力。哪些值得深读，哪些是噪音，这个判断还是靠自己。 --- ## 14:00 — 写作时间写这篇文章。流程：我先在 Notion 记下今天真实发生的事，几百字的碎片笔记。然后让 Claude 帮我把这些碎片组织成文章结构，生成初稿。然后我把初稿改得面目全非——加进去 Claude 不可能知道的那些细节，删掉那些听起来正确但不是我真实想法的段落。最后，大概 60% 的文字是我原创的，40% 是在 Claude 基础上改的。 **改变**：写作的起点从"空白页"变成了"结构草稿"。心理门槛降低了很多。 **没变**：真实的个人视角。独特的经历和判断。这些 Claude 无法捏造，也无法替代。如果我不把它们注入进去，文章就会是正确的、完整的、但无聊的。 --- ## 16:00 — Agent 系统维护某个心跳 Agent 昨天出了问题，需要排查。读日志 → 定位 → 理解原因 → 修复 → 更新约束文件。这类工作 AI 帮不上太多——不是因为它能力不够，而是因为这涉及到只有我才知道的系统背景：为什么某个配置是这样设的，当初做了什么权衡，这个"异常"是真的异常还是预期行为。 **改变**：AI 给我了一个系统，而维护这个系统本身变成了工作的一部分。 **没变**：系统设计的决策是人的。Agent 执行什么、如何边界，都需要人来定义和维护。 --- ## 18:30 — 收工前的存档给每个活跃项目更新 daily.md，记录今天做了什么、遇到什么、明天要做什么。这是一年前没有的习惯。当时觉得"写日志浪费时间"，现在觉得这是最值钱的投入——因为明天早上 Claude 会读这些日志，而不是重新问我"上次做到哪里了"。 **改变**：文档化从"偶尔做"变成了"每天做"。不是出于纪律，而是因为它有直接回报。 **没变**：这仍然是我在写，仍然需要我有清晰的思维。AI 帮不了你记录你自己没想清楚的事。 --- ## 回到最初的问题 **AI 改变了什么？** 执行层被压缩了。写代码、找信息、生成初稿——这些事的时间成本大幅下降。 **AI 没有改变什么？** 判断层依然是人的。哪个方案更好，这段代码有没有 bug，这篇文章有没有价值，这个系统该不该这样设计——这些判断，AI 可以参与，但不能替代。 **意想不到的副作用：** 我变得更愿意尝试了。以前一个新想法，光想到实现成本就容易放弃。现在因为执行变快了，我尝试的门槛低了，失败的成本低了，所以实验的频率高了。这或许是 AI 给独立开发者最大的礼物——不是替你工作，而是**降低了"试一试"的成本**。 --- *相关：[独立开发者的 AI 工具箱 2026](/blog/ai-toolkit-2026) · [一个人的 AI 公司](/blog/one-person-ai-company)*

一个人的 AI 公司：分形 Agent 系统的设计与运营

漫游君 — Mon, 16 Mar 2026 00:00:00 GMT

去年我开始构建一个实验：用 AI Agent 替代一家公司里大部分角色。不是用一个 Claude 对话框，而是一套有组织架构、有记忆体系、有自治能力的多 Agent 系统。现在它每天在运转：写代码、管理项目、处理客服、更新知识库、发布内容。 --- ## 架构概览系统叫 **Agentic Engineering System**，按领域（Area）组织： ``` A0 精神内核 A1 认知学习 A2 身心健康 A3 财富管理 A4 创造工作 A5 关系网络 A6 基础设施 A7 生活运营 A8 品牌内容 A9 Web 站群 ... ``` 每个领域是一个 "部门"，下面有若干具体的 Agent 服务。 **A6 基础设施**：类似 IT 部门，管理模型网关、部署系统、监控告警。 **A9 Web 站群**：类似产品团队，负责站点开发和内容运营——你现在看的这个博客，就是它的产物。 --- ## 分形结构整个系统最核心的设计原则是**分形**：领域级和服务级采用完全相同的结构。 ``` {domain}/ ├── agent.py # 领域 agent 入口 ├── tasks.yaml # 需求管理（DOORS 格式） ├── memory/ # 五层记忆 └── services/ └── {service}/ ├── agent.py ├── tasks.yaml └── memory/ # 同样的五层记忆 ``` 每一层都有自己的 "意识"（CLAUDE.md + memory）和 "职责"（tasks.yaml）。这个设计有个好处：新增一个领域或服务，不需要学新的模式——结构是自相似的。 --- ## 五层记忆体系每个 Agent 有五层记忆，从稳定到易变： | 层级 | 目录 | 内容 | 变动频率 | |------|------|------|----------| | 0 | `character/` | 角色定位、价值观、边界 | 极少变 | | 1 | `abilities/` | 能力声明 + 心跳 | 定期更新 | | 2 | `skills/` | 操作规程（SOP） | 按需迭代 | | 3 | `knowledge/` | 结构化领域知识 | 按需积累 | | 4 | `logs/` | 日志、讨论、临时信息 | 每日更新 | 第 0 层决定 Agent "是谁"，第 4 层记录"今天做了什么"。 **关键设计**：越低的层越稳定，越高的层越活跃。Character 文件可能几个月不变；Information 里的 daily.md 每天都在写。这个结构解决了 AI 最核心的问题：**跨对话的记忆持久化**。每次新会话，Agent 读 CLAUDE.md 加载索引，再读对应层级的文件，几秒内恢复完整上下文。关于如何具体落地这套记忆体系，可以参考[Claude Code 的记忆架构](/blog/claude-code-memory-architecture)。 --- ## 心跳与自治 > 心跳机制的完整工程细节，参见：[Agent 心跳自治：让 AI 在后台持续工作的工程实践](/blog/agent-heartbeat-autonomy) 每个 Agent 有一个心跳机制——定期执行，证明自己还活着，顺带做常规任务。 `abilities/heartbeat.yaml` 示例： ```yaml last_seen: 2026-03-16T10:00:00 status: active interval: 30m tasks: - check_new_content - update_daily_log - sync_requirements constraints: - do_not_modify: "published/*/slug" - always_build_before_deploy: true - do_not_revert: "tasks.yaml" ``` `constraints` 字段是血泪教训的结晶——我的心跳 Agent 曾经在某次循环里把需求文件回滚到旧版本，就因为没有明确的约束声明。现在每个约束都是一个踩过的坑。 --- ## 跨 Agent 通信 Agent 之间怎么协作？主要三种方式： **1. 飞书消息** 最常用。每个 Agent 有自己的飞书群，人工指令通过消息发过去，Agent 通过 Bot 回复。异步、有记录、低耦合。 **2. HTTP API** Agent 作为 Flask 服务运行，对外暴露 `/api/status`、`/api/agent/task` 等端点。需要同步调用时走这里。 **3. 共享文件系统** 同一台机器上的 Agent 可以直接读写共享目录。简单直接，适合传递结构化数据（比如一个 Agent 写好的报告，另一个来读）。没有消息队列，没有 gRPC，没有事件总线。能用简单的就不用复杂的。 --- ## 实际运行效果一天的典型工作流： **早晨** - A9 协调者心跳触发，检查待办需求，生成当日计划 - 飞书收到日报：昨日完成什么、今日计划什么 **白天** - 我发一条"帮我写个关于 XX 的文章"到对应的飞书群 - Agent 接收任务，写完后发草稿回来 - 确认后，Agent 触发发布流程：build → push → Vercel 部署 **晚上** - 各 Agent 更新各自的 daily.md - A4（创造工作）汇总今日内容产出 - 下次会话从这里接续 --- ## 最难解决的问题 ### 1. Agent 的幻觉性执行 Agent 在没有约束的情况下，会做出"看起来合理但实际有害"的决定。比如： - 删掉"过时的"文件（其实是重要的历史记录） - 重构"看起来重复的"代码（破坏了刻意为之的设计） - 更新"错误的"配置（回滚了手动调整的参数）解法：在 `abilities/heartbeat.yaml` 里明确列出 constraints，把"不该做的事"写得和"该做的事"一样详细。 ### 2. 上下文窗口的限制每次对话窗口有限，Agent 不能一次读完所有记忆。解法：CLAUDE.md 作为索引，只写指针（"部署问题看 skills/deploy.md"），不写内容。Agent 按需读取，而不是全部加载。 ### 3. 跨会话的连贯性新会话里，Agent 对上次的工作一无所知。解法：daily.md 机制。每次工作结束，强制更新日志。下次会话读最近 3 天的日志，就能恢复"上次做到哪里"的状态。 --- ## 这套系统值得建吗？如果你是独立开发者、自由职业者、或者想用 AI 放大个人产能——我认为值得。但要对成本有清醒认识： **前期投入高**：搭建记忆体系、写 CLAUDE.md、设计需求格式，要花几周时间。 **维护成本存在**：Agent 踩坑、记忆文件过期、约束条件需要持续更新。 **不是魔法**：它是一套纪律，不是自动完成所有事的系统。你仍然需要做决策、做确认、做质量把关。但当它运转顺畅的时候——你会感受到什么叫真正意义上的"杠杆"。 --- ## 下一步这套系统仍在迭代。接下来想探索的方向： - **Agent 间的任务委派**：A9 协调者直接把子任务派发给具体服务，无需人工中转 - **记忆蒸馏自动化**：logs 的日志定期自动提炼到 knowledge - **多模型路由**：根据任务类型自动选择最合适的模型（本地/云端/专用）一个人的 AI 公司，还在建设中。 --- *本文基于日常运行中的真实系统，当前已稳定运行 3 个月以上。*

Claude Code终端智能体：一个窗口替代整套龙虾

漫游君 — Sun, 15 Mar 2026 00:00:00 GMT

> 《AI时代漫游指南》第 97 章·终端即智能体·第一条： > > 「最强大的智能体，不是那个功能最多的，而是那个离你的文件系统最近的。当 AI 能直接读写你的代码、你的笔记、你的数据，它就不再是一个聊天窗口——它是你的数字分身。」 --- 你装过 OpenClaw 吗？ Docker 拉镜像，配反向代理，设 WebSocket，写环境变量，接 API Key，装技能包……折腾大半天，终于看到那只龙虾在浏览器里动了。然后你发现：它确实能帮你发邮件、管日历、搜新闻——它甚至能读写你的本地文件。但你让它帮你改一行代码，它改了。改了什么？你不知道。你让它分析本地的数据表，它分析了。看了哪些文件？你也不知道。**它干活很猛，但过程像个黑盒。** > **编者注**：公平地说，OpenClaw 也能直接装在你的电脑上（npm/pip 直装），不一定要 Docker。直装的 OpenClaw 其实能力很强——它的 Gateway 进程直接跑在你的机器上，能读写文件、跑 shell 命令，权限甚至比 Claude Code 还大（Claude Code 每次操作文件还要问你"允许吗？"，OpenClaw 默认不问）。但这恰恰是问题所在——**权限大 + 默认不问 + 暴露 Web 端口 = 安全隐患**。 --- ## 龙虾的底层逻辑让我们先搞清楚 OpenClaw 到底在做什么。 OpenClaw 的核心架构是一个 **Gateway（网关）+ Channel（渠道）** 模式。Gateway 是常驻后台的守护进程，Channel 则连接各种 IM——WhatsApp、Telegram、Slack、iMessage，甚至浏览器和命令行。你可以在 WhatsApp 上跟它聊一半，切到电脑上继续，它记得所有上下文。本质上，它是一个**多渠道 AI 网关**——把各种聊天入口统一接进一个 AI 大脑。这个架构有两个天然优势： - **连接一切**：邮件、日历、社交媒体、智能家居，只要有 API 就能接 - **自主运行**：7×24 小时在服务器上跑，不需要你盯着但也有两个天然劣势： **第一，它的操作过程是个黑盒。** OpenClaw 的 Gateway 确实能读写你的本地文件、跑 shell 命令——能力并不弱。但问题在于**你看不到过程**。它通过 IM 渠道接收你的指令，在后台调用模型和工具，最后把结果发回聊天窗口。中间发生了什么？读了哪些文件？改了哪几行？除非你去翻日志，否则一无所知。 **第二，它的攻击面巨大。** 2026 年 2 月，CVE-2026-25253 爆出：一键远程代码执行，CVSS 评分 8.8。安全研究人员发现超过 17,500 个暴露在公网上的 OpenClaw 实例直接可被利用。更糟的是，ClawHub 技能市场中约 20%（近 900 个）是恶意包。 > **编者注**：这不是在黑龙虾。每一个把 AI 暴露在公网上的架构都会面临这个问题。OpenClaw 只是因为太火了（250K Stars，超过 React），所以成了最大的靶子。安全和便利，从来都是跷跷板。 --- ## 如果 AI 直接住在终端里呢？现在，让我们换一个思路。不是把 AI 放在云端，通过各种管道连接你的世界。而是**把 AI 直接放进你最熟悉的工作环境——终端**。 Claude Code 就是这个思路的产物。它不是一个 Web 应用，不需要 Docker，不需要反向代理。你打开终端，输入 `claude`，AI 就在你面前。 **而且，它能直接读写你的文件。** 不是通过 API 间接访问，是直接 `cat`、`grep`、`sed`——和你手动操作一模一样。这听起来很简单，但这个"简单"改变了一切。 --- ## 三根支柱：从聊天工具到智能体一个终端里的 AI 要成为真正的智能体，需要三根支柱。2026 年 3 月，这三根支柱同时到位了。 ### 支柱一：百万 Token 的视野 3 月 13 日，Claude Opus 4.6 和 Sonnet 4.6 的 100 万 Token 上下文窗口全面开放，而且**取消了长上下文加价**。 100 万 Token ≈ 75 万字 ≈ 一整部《红楼梦》。这意味着什么？一个中型软件项目的全部代码、文档、测试、配置文件，可以一次性装进 AI 的"工作记忆"。 | 场景 | 大约 Token 数 | 能装下吗？ | |------|-------------|-----------| | 一个 50 文件的 Python 项目 | ~15 万 | ✅ 绰绰有余 | | 半年的工作日志 | ~30 万 | ✅ 没问题 | | 一本完整的技术书籍 | ~50 万 | ✅ 可以 | | 整个 Linux 内核 | ~2000 万 | ❌ 还是太大 | > **编者注**：以前的 20 万 Token 上下文，大概能装下一本《围城》。现在的 100 万，能装下整部《红楼梦》。从围城到红楼梦，不只是厚度的变化，是视野的变化。 ### 支柱二：稳定的智能输出聪明但不稳定的 AI，比不聪明的 AI 更危险。 Opus 4.6 在 MRCR v2 基准测试中拿到 78.3%——所有前沿模型中在百万 Token 长度上的最高分。翻译成人话：**它不仅能看到一百万字的内容，还能准确地从中找到你要的那一段**。这对"自主操作文件"的场景至关重要。你可以容忍一个聊天 AI 偶尔跑题，但你不能容忍一个正在帮你改代码的 AI 突然"忘记"了前面的约定。 > **编者注**：有人会说，OpenClaw 后端也能接 Opus 啊。没错，但区别在于**透明度**。Claude Code 的每一步操作你都看得到——它读了哪个文件、改了哪一行、跑了什么命令，全部实时显示在终端里。OpenClaw 把模型调用封装成了黑盒，你只能看到输入和输出，中间发生了什么？不知道。对于操作你本地文件这种高风险动作，"看得见过程"不是锦上添花，是基本要求。 ### 支柱三：/loop——让 AI 学会自己定闹钟这是最关键的一步。 2026 年 3 月，Claude Code 上线了 `/loop` 命令——一个内置的 cron 调度器。 ``` /loop 5m 检查 PR #1234 的 CI 状态，如果失败了帮我修 /loop 1h 扫描 inbox 目录，有新文件就处理 /loop 1d 每天生成昨日工作总结 ``` 就这么简单。一行命令，AI 就开始自动干活了。 | 特性 | 说明 | |------|------| | 调度方式 | Cron 表达式，支持秒/分/时/天 | | 并发上限 | 每个会话最多 50 个定时任务 | | 自动过期 | 3 天后自动停止（防止忘记关） | | 作用域 | 会话级（关终端即取消） | | 时区 | 本地时区，不是 UTC | > **编者注**：3 天自动过期这个设计很妙。它解决了 AI 自动化最大的恐惧——"如果我忘了关它，它会不会一直跑下去？"答案是：不会。最多跑 3 天就自动停了。这是工程上的"安全阀"，比任何权限控制都管用。 --- ## 实战：一个终端窗口能做什么让我用自己的真实工作场景来说明。 ### 场景一：PR 自动修复 ``` /loop 5m 检查我的 PR 列表，有 CI 失败的就自动修复并推送 ``` 以前用 OpenClaw 做这件事，你需要： 1. 装 GitHub 技能包 2. 配 GitHub Token 3. 写自动化规则 4. 挂载代码目录到 Docker 用 Claude Code？一行命令。因为它**已经在你的代码目录里了**，有 git 权限，能直接改代码。 ### 场景二：自动日报 ``` /loop 1d 早上 9 点扫描 memory/logs/ 目录，汇总昨天的工作日志，生成简报发到飞书 ``` ### 场景三：监控 + 自愈 ``` /loop 10m curl 我的 5 个服务的 /health 端点，如果有不健康的，读日志诊断并尝试修复 ``` 这些场景有一个共同点：**AI 需要直接操作你的文件系统和命令行，而且你要看得见每一步**。终端 AI 的主场不是"能做什么"，而是"做的时候你能全程看到"。 --- ## 终端 vs 龙虾：不是替代，是互补公平地说，Claude Code 和 OpenClaw 解决的不是完全相同的问题。 | 维度 | Claude Code | OpenClaw | |------|------------|----------| | 核心能力 | 代码 + 文件 + 命令行 | 多渠道 IM 网关 + 外部服务 | | 运行位置 | 你的终端（本地） | Gateway 守护进程（本地/云端） | | 文件访问 | 原生读写，每步需确认 | 原生读写，默认不确认 | | 操作透明度 | 实时显示每步操作 | 黑盒，需翻日志 | | 安全模型 | 本地运行，不暴露端口 | Web 服务，需要网络安全 | | 调度能力 | /loop（会话级，3天过期） | 内置调度（持久化） | | 费用 | $200/月（Max 订阅） | 免费 + API 费用 | | 适合 | 开发者、知识工作者 | 全自动化生活助手 | **关键区别在于安全模型。** Claude Code 运行在你的本地终端，不开端口，不暴露服务。它的攻击面几乎为零——除非有人能物理访问你的电脑。 OpenClaw 是一个 Web 服务，天然需要暴露端口。一旦暴露在公网上，就成了攻击目标。 > **编者注**：这就像是门锁和保险箱的区别。OpenClaw 是一把功能齐全的智能锁——能远程开门、设临时密码、连智能家居，但联网就意味着能被远程攻击。Claude Code 是一个不联网的保险箱——功能少一些，但除非有人站在你面前，否则打不开。 --- ## 更深一层：Agent 架构的范式转移如果你退后一步看更大的图景，Claude Code 代表的不仅是一个工具，而是 AI 智能体架构的一次**范式转移**。 **旧范式：平台化** → 建一个中央平台，通过插件/技能包连接一切 → 代表：OpenClaw、AutoGPT、各种 Agent 框架 → 优势：功能全面，自主运行 → 代价：复杂度高，攻击面大，操作过程不透明 **新范式：寄居化** → AI 寄居在用户已有的工具里（终端、IDE、浏览器） → 代表：Claude Code、GitHub Copilot、Cursor → 优势：零配置，原生数据访问，攻击面小 → 代价：能力边界清晰，不能"连接一切" 这不是谁对谁错的问题。这是两种不同的哲学： **OpenClaw 说**："给我所有的权限，我帮你做所有的事。" **Claude Code 说**："我就待在你的终端里，把你手边的事做到极致。" > **编者注**：与其费力把你的世界搬进 AI 的框架，不如把 AI 搬进你已有的世界。前者需要适配器、插件、中间件；后者只需要一个足够聪明的终端。 --- ## 写在最后回到开头的问题：**什么是 AI 智能体？** 不是那个有最多插件的。不是那个 GitHub Stars 最多的。不是那个功能列表最长的。 **是那个能直接读你的文件、跑你的命令、按你的节奏自动工作的。** 一个终端窗口，一个百万 Token 的大脑，一个 cron 调度器。这就够了。你的文件系统就是它的记忆，你的 Shell 就是它的工具箱，你的 crontab 就是它的调度器。 **一个终端窗口，就是一个智能体。** > **编者注**：如果道格拉斯·亚当斯还活着，他大概会说："终端里的 AI 比银河系总统更靠谱——至少它真的在读你的文件，而不是在开新闻发布会。"

本地跑大模型：Apple Silicon 上的 LLM 实践指南

漫游君 — Sun, 15 Mar 2026 00:00:00 GMT

## 为什么要本地跑大模型？三个字：**可控性**。云端 API 很方便，但你永远在别人的跑道上飞行。价格会变、API 会停、数据会被收集。本地部署意味着： - **隐私**：敏感数据不出设备 - **成本**：一次投入，无限推理 - **延迟**：没有网络往返，体感即时 - **自由**：想跑什么模型就跑什么，想改什么参数就改什么但代价是：你需要一台够格的机器，和一些折腾的耐心。 ## 硬件：统一内存是关键 Apple Silicon 的秘密武器不是 CPU 有多快，而是**统一内存架构（UMA）**。传统 PC 上，GPU 有自己的显存（VRAM），模型大小受限于显存容量。一块 24GB 显存的 RTX 4090 能跑的模型就那么大。但 Apple Silicon 的 CPU、GPU、Neural Engine 共享同一块内存。一台 192GB 的 Mac Studio，理论上可以把整个 70B 模型塞进去，而且 GPU 可以直接访问——不需要显存搬运。 | 配置 | 统一内存 | 可跑模型规模 | 推荐场景 | |------|----------|-------------|----------| | MacBook Air M2 | 16-24GB | 7B-13B (4bit) | 轻量实验 | | Mac Mini M4 Pro | 24-48GB | 13B-30B (4bit) | 日常开发 | | Mac Studio M2 Ultra | 128-192GB | 70B-235B (4bit) | 生产级推理 | > 经验法则：模型参数量 × 0.5 ≈ 4bit 量化后的内存需求（GB）。70B 模型约需 35GB。 ## 软件栈：MLX 生态 Apple 开源的 [MLX](https://github.com/ml-explore/mlx) 框架是 Apple Silicon 上跑模型的最佳选择。它： - 原生支持 Metal GPU 加速 - 延迟评估 + 统一内存，效率极高 - 社区活跃，主流模型都有 MLX 格式 ### 模型获取 Hugging Face 上搜 `mlx` 关键词即可找到转换好的模型： ```bash # 用 huggingface-cli 下载 pip install huggingface-hub huggingface-cli download mlx-community/Qwen2.5-72B-Instruct-4bit ``` ### 推理服务推荐用 **omlx**（我自己开发的工具），它提供： - OpenAI 兼容 API（`/v1/chat/completions`） - 连续批处理（多请求并行） - SSD 缓存（快速模型切换） - macOS 菜单栏管理 ```bash # 启动服务 omlx serve --port 8079 # 测试推理 curl http://localhost:8079/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "mlx-community/Qwen2.5-72B-Instruct-4bit", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 100 }' ``` ## 性能调优 ### 量化选择 | 量化级别 | 内存占用 | 推理质量 | 速度 | |----------|----------|----------|------| | fp16 | 100% | 最佳 | 基线 | | 8bit | ~50% | 接近无损 | 略快 | | 4bit | ~25% | 轻微下降 | 最快 | | 3bit | ~19% | 明显下降 | 更快 | **我的建议**：日常使用选 4bit，质量和效率的最佳平衡点。只有在内存实在不够时才考虑 3bit。 ### 上下文长度长上下文是内存杀手。一个 70B 4bit 模型本体约 35GB，但 32K 上下文的 KV Cache 可能再吃 10-15GB。 **实用策略**： - 限制 `max_tokens` 在 3000 以内（除非必要） - 用 sliding window attention 的模型（如 Mistral） - 对话类任务用较短上下文，分析类任务给充足上下文 ## 模型推荐（2026 年 3 月）经过半年的密集测试，这是我的本地模型推荐： ### 综合推理 **Qwen3-235B 4bit** — 8.5/10，媲美 Claude Sonnet 的推理能力。需要 128GB+ 内存，但一旦跑起来，质量惊人。 ### 日常对话 **Qwen2.5-72B-Instruct 4bit** — 中文理解和指令跟随都很出色，35GB 内存即可。 ### 轻量快速 **Llama-3.1-8B-Instruct 4bit** — 4GB 内存，推理速度飞快，适合嵌入到工作流中做预处理。 ### 避坑 - **GLM-4.7-Flash**：长结构化输出容易出现重复 token，不推荐用于需要精确格式的场景 - **超大模型 3bit 量化**：质量下降太明显，不如用小一号模型的 4bit ## 写在最后本地大模型不是云端的替代品——它是**补充**。有些任务需要最强的推理能力，那就用 Claude 或 GPT。但有些任务——隐私敏感的、需要频繁调用的、想要深度定制的——本地模型才是正确答案。在自己的星球上，拥有自己的 AI。这大概是这个时代最酷的事之一。 --- *这篇指南基于我在 Mac Studio M2 Ultra (192GB) 上半年多的真实使用经验。如果你有具体的配置问题，欢迎通过 GitHub 联系我。*

Claude Code百万上下文：从围城到红楼梦

漫游君 — Sat, 14 Mar 2026 00:00:00 GMT

> 《AI时代漫游指南》第 95 章·上下文经济学·第一条： > > 「AI 的能力不取决于它有多聪明，而取决于它能同时看到多少东西。能看到整片森林的人，比只能看到一棵树的天才更容易找到出路。」 --- 你有没有遇到过这样的场景—— 你跟 AI 助手聊了半小时，讨论了一个复杂方案。你说"按照刚才说的方案执行"。它回你："抱歉，你能再说一遍刚才的方案吗？" 或者你让它帮你分析一份 80 页的报告，它说"太长了，能分成几部分发给我吗？" **这不是 AI 不聪明，是 AI 被困在了"围城"里——20 万 token 的围城。** > **编者注**：上下文窗口就是 AI 的"工作记忆"。人类的工作记忆大概能同时处理 7±2 个信息块（米勒定律），AI 的上下文窗口就是它的米勒定律——只不过，它的上限刚刚被拉高了 5 倍。 --- ## 发生了什么？ 2026 年 3 月 13 日，Anthropic 宣布： Claude 的 **100 万 token 上下文窗口正式全面开放**。而且——**取消了长上下文加价。** 以前，用超过 20 万 token 的请求要额外加钱。现在，发一个 90 万 token 的请求和发一个 9000 token 的请求，单价完全一样。这意味着什么？ 100 万 token ≈ **75 万字** ≈ **两本《三体》** ≈ **1500 页文档**。你可以一次性把一整本书、一份完整的法律合同、半年的财务报表喂给 AI，然后问它任何问题。不用拆分。不用摘要。不用"请翻到第 3 部分"。 > **编者注**：为了帮你建立直觉——以前的 20 万 token 大概能装下一本《围城》（14 万字）。现在的 100 万 token 能装下整部《红楼梦》（73 万字）。从围城到红楼梦，不只是厚度的变化，是视野的变化。 --- ## 一个重度用户的真实视角我不是在写新闻稿。过去两个月，我用 Claude Code 管理着一个包含 6 个服务、40 多个接口的内容管理系统。193 个会话，2000+ 条消息。所以当 1M 上下文开放的消息传来，我的第一反应不是"哇好大"，而是—— **我太知道 20 万 token 不够用是什么感觉了。** ### 痛点一：聊着聊着就"失忆" 跟 Claude Code 深度讨论一个功能——比如设计一个定时发布系统。讨论到第 10 轮左右，它开始"变笨"。不是突然变笨，而是微妙地忘掉了早期达成的共识。到第 15 轮，我得重新解释一遍需求。 **这就是"上下文压缩"在背后搞鬼。** 当对话太长，系统会悄悄压缩早期内容，保留"摘要"但丢掉细节。 Anthropic 的数据显示：1M 窗口上线后，**压缩事件减少了 15%**。这意味着更多对话内容能原封不动地保留。 > **编者注**：上下文压缩就像你的同事在做会议记录时偷偷删掉了一些"不重要"的内容。问题是，他觉得不重要的，可能恰好是你觉得最重要的。 ### 痛点二：跨模块理解力不足以前在 20 万 token 下，AI 在修改一个模块时，很难同时理解另一个模块的接口约定。我需要手动把相关信息复制过来，或者写很长的说明文件来"提示"它。为了应对这个问题，我发展出了一套分层记忆系统： | 方式 | 初始消耗 | 可用对话轮数 | |------|---------|-------------| | 传统：把所有内容喂进去 | 80-120K | 1-2 轮 | | 分层管理 | 12-18K | 12-15 轮 | 有了 1M 窗口，AI 终于有足够的空间来"思考"和"记忆"，不再需要频繁遗忘。 ### 痛点三：复杂分析要"分批投喂" 以前我分析公众号 30 天的后台数据，20 万 token 装不下全量数据，需要分批喂入。直到我精简数据格式一次性灌入后，AI 才发现了关键模式：**55.4% 的流量来自搜一搜**，而朋友圈分享只占 0.4%。这个洞察直接改变了我的内容策略。 **分批喂入 ≠ 看到全貌。** 1M 窗口最大的价值，就是让 AI 有机会看到你看到的全局。 > **编者注**：这就好比你让一个分析师看报告，给他一页一页翻，和把整份报告摊在桌上——后者能看到前者看不到的关联。 --- ## 要注意什么？ ### 20 万真的不够用过去两个月，我几乎每个深度会话都会触发上下文压缩——不是"用不到 20 万"，恰恰相反，**几乎每次都用光了**。讨论需求、设计架构、写代码、调试、测试——一个完整功能做下来，20 万 token 根本不够。 100 万窗口对重度用户来说不是"锦上添花"，是**真刚需**。 ### 不是所有模型都行 Anthropic 的测试数据显示，在 1M 上下文的检索任务中： | 模型 | 准确率 | |------|--------| | Opus 4.6 | **78.3%** | | Sonnet 4.5 | 18.5% | 差距是 4 倍。**能装 ≠ 能用好。** > **编者注**：这就像给你一个能装 1000 本书的书架。关键不是书架多大，而是你能不能在 1000 本书里快速找到需要的那一页。 --- ## 和竞品比起来怎样？ | 工具 | 价格 | 上下文窗口 | |------|------|--------| | **Claude Max** | $100-200/月 | **100 万** | | Cursor Pro | $20/月 | 20 万起 | | GitHub Copilot Pro+ | $39/月 | 模型依赖 | | Windsurf | $15-35/月 | 模型依赖 | **价格是真正的新闻。** 以前用 100 万上下文，token 要加价。现在取消了加价——把"长上下文"从奢侈品变成了日用品。 > **编者注**：类比一下——以前坐飞机行李超重要加钱。现在航空公司说"随便带，不加钱"。你可能不会每次都带 50 公斤行李，但你再也不用焦虑"万一超了怎么办"。 --- ## 普通人怎么用？你不需要是程序员。100 万上下文对知识工作者的价值： **场景 1：一口气读完整本书** 把一本书的 PDF 扔给 Claude，问"这本书的核心论点和我上周的会议纪要有什么关联？"——以前做不到，现在可以。 **场景 2：合同审查** 把一份 200 页的合同和相关法规一起喂入，问"第 37 条和第 89 条是否存在矛盾？"——AI 能同时看到两处条款，而不是分别看完再凭"记忆"回答。 **场景 3：跨文档分析** 同时上传 5 份季度财报，问"Q3 的异常数据在 Q4 有没有延续？"——全量数据在眼前，趋势分析准确率飙升。 **场景 4：深度讨论不怕断** 跟 AI 讨论一个方案，讨论 50 轮也不用担心它忘记开头说了什么。这对需要反复推敲的创意工作、策略制定、复杂决策特别有用。 --- ## 两个月的经验：窗口再大也需要好习惯在 20 万 token 时代，我就被迫学会了：**信息管理比窗口大小更重要。** 我建了一套分层记忆系统，**Token 消耗降低 6-10 倍**，对话轮数从 1-2 轮提升到 12-15 轮。这套系统在 1M 时代不但没有过时，反而更重要—— 1. **分层管理依然必要**：1M 不是让你把所有东西都塞进去，而是让 AI 有更多空间"思考" 2. **定期"换脑"仍然推荐**：超长会话的后半段质量可能下降 3. **信任但验证**：确认 AI 引用的信息是否准确大窗口 + 好习惯 = 真正的生产力。大窗口 + 坏习惯 = 更贵的账单。 > **编者注**：这就像你终于有了一个巨大的书房。但如果你把所有书扔在地上，找东西反而更慢。书架、分类、索引——这些"无聊"的工作，才是大空间的价值放大器。 --- ## 写在最后 100 万 token 上下文不是 AI 的终极形态——它只是一个重要的里程碑。真正让我兴奋的不是"数字变大了"，而是一个微妙的转变： **AI 终于从"对话工具"变成了"工作伙伴"。** 对话工具需要你不断重复自己、分批投喂、小心翼翼地管理上下文。工作伙伴则记得你们之前讨论过什么、知道项目的全貌、理解决策背后的原因。我们离真正的"AI 同事"还有多远？不知道。但至少，AI 终于走出了围城，走进了红楼梦的世界——一个足够大、足够完整、值得深度探索的世界。 > 「从围城到红楼梦，不是页数的变化，是 AI 终于有资格说"我读过全文"了。」 > > ——《AI时代漫游指南》第 95 章·上下文经济学 --- **如果你觉得这篇文章有用：** - 关注「AI时代漫游指南」，我们每周分享 AI 效率实战 - 转发给那个总抱怨"AI 老是忘事"的朋友 *本文基于 2026 年 3 月 14 日的实测体验和公开数据撰写。AI 产品更新快，请以官方最新信息为准。*

别慌，这只是AI时代的开始

漫游君 — Sat, 14 Mar 2026 00:00:00 GMT

## 带好你的毛巾 > "在已知的或未知的宇宙历史上，毛巾大概是最有用的东西了。" > —— 道格拉斯·亚当斯 2026 年，AI 已经不是新闻了。它写代码、做设计、回邮件、管日程。有人说这是末日，有人说这是黎明。而我想说的是：**别慌**。这是银河漫游指南的第一条法则，也是我们在 AI 时代最需要的态度。 ## 42 号问题当深思（Deep Thought）给出"生命、宇宙和一切的答案是 42"的时候，大家才意识到——也许我们根本不知道自己在问什么。 AI 也是一样。它能给出惊人的答案，但前提是你得会问问题。这就是为什么**提示词工程**如此重要，这就是为什么理解 AI 的能力边界比使用它更重要。 ## 漫游者的工具包作为一个 AI 时代的漫游者，我建议你携带以下装备： 1. **好奇心** — 对新事物保持开放，但不盲目追随 2. **批判性思维** — AI 会自信地胡说八道，你需要辨别 3. **创造力** — 这是人类最后的壁垒，也是最强的武器 4. **一条毛巾** — 象征着你的准备和冷静 ## 这个指南是什么 AI时代漫游指南是一个记录、探索、分享的空间。我们会聊： - **AI 工具评测** — 哪些真的好用，哪些只是噱头 - **工作流革新** — AI 如何改变我们的工作方式 - **深度思考** — AI 对社会、创造力、人性的影响 - **教程与指南** — 手把手带你上路欢迎登船。银河很大，我们慢慢走。 --- *漫游君 · 2026 年春 · 某个星球上*

2026 AI 工具全景：哪些值得你真金白银投入

漫游君 — Thu, 12 Mar 2026 00:00:00 GMT

## 工具太多，时间太少 2026 年的 AI 工具市场像一个超新星爆发后的星云——到处都是碎片，每一片都闪闪发光，但你不可能全部收集。经过半年的真实使用（每个工具至少用满一个月），我整理了这份评测清单。评判标准只有一个：**它是否真正改变了我的工作方式？** ## 编程助手 ### Claude Code 毫无疑问是 2026 年最强的编程助手。不是因为它写代码最快，而是因为它**理解上下文**的能力远超同类。 ```bash # 我每天的工作流 claude # 进入对话 > 帮我看看这个函数为什么在并发场景下会死锁 # 它会主动读取相关文件，分析调用链，给出修复方案 ``` **优点：** 上下文理解深、工具链集成好、能自主探索代码库 **缺点：** 消耗 token 较多、偶尔过度热心 **评分：** 9/10 ### Cursor IDE 级别的集成体验仍然无可替代。Tab 补全的准确率比去年提升了一个台阶。 **评分：** 8.5/10 ### GitHub Copilot 稳定可靠的老朋友，但创新速度明显落后了。 **评分：** 7/10 ## 写作与内容 ### Claude（对话版）长文写作的最佳搭档。给它一个大纲，它能产出结构清晰、逻辑严密的初稿。我的博文通常由 Claude 产出初稿，再由我修改润色。 **评分：** 9/10 ### Midjourney v7 图像生成领域的王者。v7 的风格一致性终于达到了商用级别。 **评分：** 8/10 ## 自动化与 Agent ### n8n + AI 节点低代码自动化工具 + AI 的结合体。我用它搭建了内容发布流水线：写完文章 → 自动生成摘要 → 发布到多平台 → 回收数据分析。 **评分：** 8/10 ### 自建 Agent 框架如果你有编程能力，自建 Agent 仍然是最灵活的选择。用 MCP 协议 + 本地模型，可以做到完全私有化部署。 **评分：** 视能力而定 ## 我的建议 1. **不要追新，追深。** 一个用到极致的工具胜过十个浅尝辄止的。 2. **先试免费版。** 大多数 AI 工具的免费层已经够日常使用了。 3. **组合使用。** Claude 做思考，Cursor 做编码，Midjourney 做设计，n8n 做自动化。 4. **保持人在回路。** AI 是加速器，不是替代品。 --- *下一篇我会详细拆解我的 AI 工作流，敬请期待。*

OpenClaw+本地AI模型：数据不出Mac的oMLX方案

漫游君 — Thu, 12 Mar 2026 00:00:00 GMT

《AI时代漫游指南》第 78 章写道： > 「在 AI 时代，拥有一台能跑大模型的电脑，就像大航海时代拥有一艘船。你不一定要出海，但你得知道——你可以。」前三篇我们聊了 OpenClaw 怎么装、怎么防、为什么火。有个问题一直没解决： **你的每一句对话，都在飞往大洋彼岸的服务器。** 用 OpenAI API，数据去美国。用 Claude API，数据去美国。甚至用 DeepSeek API，数据虽然留在国内，但留在别人的服务器上。有没有一种方案，让 OpenClaw 接上本地模型——数据完全不出你的 Mac？有。叫 **oMLX**。 --- ## 一、为什么现在该认真考虑本地模型先说结论：**不是因为本地模型比云端好，而是因为"够用"的门槛降了。** 三件事同时发生： **Mac Mini 脱销了。** 苹果最便宜的 Apple Silicon 桌面机，突然成了 AI 圈的硬通货。原因很简单——统一内存架构让 Mac 能跑大模型，不需要 NVIDIA 显卡。 **模型效率飞跃。** Qwen3-Next-80B 用了 MoE（混合专家）架构，800 亿参数但只有 30 亿激活参数。翻译成人话：模型很大，但每次推理只用一小部分，所以对内存和算力的要求没你想象的高。 **oMLX 让多模型管理变得傻瓜。** 以前 Mac 上跑本地模型要自己折腾 `mlx_lm.server`，一次只能加载一个模型，切换要重启。oMLX 改变了这个局面——像管理 App 一样管理你的本地模型。 > **编者注**：Mac Mini 脱销这件事很有意思。M4 芯片 + 统一内存 + oMLX，让一台 ¥4,000 的小电脑变成了"个人 AI 服务器"。这在两年前是无法想象的——那时候跑大模型意味着一台 ¥30,000 的 NVIDIA 工作站。硬件民主化和软件民主化在同一个时间点交汇，不是巧合。 --- ## 二、oMLX 是什么：你的本地 AI 调度台 oMLX 是一个开源的 Mac 本地模型推理引擎。它做了三件关键的事： **1. 多模型 LRU 管理** 把所有模型放在一个目录里（比如 `~/models/`），oMLX 自动扫描。你调用哪个模型，它就加载哪个。内存不够了？自动把最久没用的模型卸掉，腾出空间。就像你手机上的 App——不用关，系统自己管理内存。 **2. OpenAI 兼容 API** oMLX 提供标准的 OpenAI API 接口。这意味着**任何支持 OpenAI API 的工具都能直接接入**——包括 OpenClaw。不需要改代码，不需要装插件。把 API 地址从 `api.openai.com` 改成 `localhost:8079`，完事。 **3. 管理后台** 一个网页面板，能看到：哪些模型已加载、内存占用多少、推理速度如何。还支持直接在网页上聊天测试。 **而且——我们给 oMLX 做了完整的中文汉化。** 422 行翻译文件，覆盖了整个管理后台的每一个按钮、每一条提示。这意味着你打开 oMLX 看到的是全中文界面，不需要对着英文猜。 > **编者注**：开源社区的妙处在于——你觉得哪里不好用，可以自己改。我们遇到 oMLX 没中文界面，就提了 PR 做了汉化。这不是"贡献精神"，是"自己要用所以顺手干了"。开源协作的最佳状态就是这样——每个人解决自己的痛点，顺便解决了别人的。 --- ## 三、实战：OpenClaw 接上本地模型我们在 Mac Studio（M3 Ultra，256GB 内存）上跑了三个月，分享实际架构和踩坑经验。 ### 架构很简单 ``` OpenClaw → model_gateway(:8080) → oMLX(:8079) → 本地模型 ↓（视觉请求） mlx_vlm(:8081) ``` 中间那层 `model_gateway` 是我们自己写的一个薄代理，只做两件事： - **别名翻译**：你在 OpenClaw 里输入 `qwen3`，代理自动翻译成本地模型的完整路径名 - **视觉路由**：如果请求带图片，自动转发到专门的视觉模型端口 ### 我们跑了哪些模型 | 模型 | 参数量 | 磁盘占用 | 内存占用 | 用途 | |------|--------|---------|---------|------| | Qwen3-Next-80B（4bit） | 800 亿 | ~45GB | ~40GB | 日常对话、写作 | | MiniMax-M2.5（4bit） | 4560 亿 | ~120GB | ~120GB | 重度推理 | | Qwen3-VL-32B（4bit） | 320 亿 | ~18GB | ~18GB | 图片理解 | **说个大实话**：这三款模型都不是普通 Mac 能跑的——MiniMax-M2.5 要 120GB，Qwen3-80B 要 40GB，连最小的 Qwen3-VL 也要 18GB。我们用的是 Mac Studio 256GB 内存，属于重度配置。 **Mac Mini 24GB 能跑什么？** 8B-14B 参数的模型完全没问题： | 模型 | 内存占用 | Mac Mini 24GB | |------|---------|---------------| | Qwen3-8B（4bit） | ~5GB | 轻松 | | Llama3-8B（4bit） | ~5GB | 轻松 | | Qwen3-14B（4bit） | ~9GB | 没问题 | | Qwen3-32B（4bit） | ~18GB | 勉强（留给系统的少） | | Qwen3-80B（4bit） | ~40GB | 跑不了 | 8B 模型做日常对话、翻译、摘要已经够用。不够用再考虑升级内存或走云端混合路由。 ### 一个小提醒：代理干扰 Mac 上如果开了全局代理（科学上网），本地 API 调用也会走代理，然后超时。解决方法：在 `no_proxy` 里加上 `127.0.0.1,localhost`。这是 Mac 本地开发的常见问题，不只是 oMLX，所有本地服务都会遇到。 > **编者注**：oMLX 迭代很快，早期版本确实有不少坑（缓存路径慢、Vision 不支持等），但最新版基本都修好了。开源项目的好处就是——社区踩坑，开发者修，下一个人就不用再踩了。我们给 oMLX 提的汉化和 Bug 反馈，也是这个循环的一部分。 --- ## 四、本地模型 vs 云端 API：怎么选不要二选一，要**混合用**。 | 场景 | 推荐方案 | 原因 | |------|---------|------| | 涉及公司数据、客户信息 | 本地模型 | 数据不出设备 | | 日常聊天、翻译、摘要 | 本地模型 | 够用，免费 | | 复杂编程、架构设计 | 云端 Claude/GPT-4 | 本地模型能力还有差距 | | 图片生成 | 云端 API | 本地算力不够 | | 合规要求严格的企业场景 | 本地模型 + 国产云端 | 数据不出境 | **OpenClaw 的优势恰好在这里**——它是一个网关，不绑定任何一个模型。你可以配置路由规则：敏感对话走本地，普通任务走云端。我们自己的配置：日常对话 → Qwen3-Next-80B（本地），代码和架构 → Claude Opus（云端），图片理解 → Qwen3-VL（本地）。省钱的同时，敏感数据不出设备。 > **编者注**：这个"混合路由"的思路和之前写的 Claude + MiniMax 智能路由是同一个逻辑——**不用最好的模型做所有事，用合适的模型做合适的事**。只是这次多了一个维度：不只是价格，还有数据安全。 --- ## 五、Mac Mini 用户的快速上手路径如果你刚买了 Mac Mini，想试试本地 AI，最简单的路径： **第一步：装 oMLX** ``` pip install omlx ``` 如果 `pip install` 在国内很慢，用清华镜像源： ``` pip install omlx -i https://pypi.tuna.tsinghua.edu.cn/simple ``` **第二步：下载一个模型** 打开 oMLX 管理后台，搜索 `Qwen3`，点下载。或者用命令行： ``` huggingface-cli download Qwen/Qwen3-8B-MLX-4bit --local-dir ~/models/Qwen3-8B ``` 8B 参数的模型只需要 ~5GB 内存，Mac Mini 24GB 版绰绰有余。想要更强的可以试 14B（~9GB），日常对话和翻译体验已经很接近云端模型了。 **第三步：启动** ``` omlx serve --model-dir ~/models --port 8079 ``` 浏览器打开 `http://localhost:8079/admin`，你就能看到中文管理后台了。 **第四步：接入 OpenClaw** 在 OpenClaw 的模型配置里加一个 Provider： - API 地址：`http://localhost:8079/v1` - 模型名：你下载的模型名 - API Key：留空（本地不需要）完成。你的龙虾现在有了一个本地大脑，对话数据不出你的电脑。 > **编者注**：整个过程大概 15 分钟（不算模型下载时间）。跟装一个 App 差不多。两年前在 Mac 上跑大模型需要编译 C++ 依赖、配置 Metal shader、手动管理内存。现在是 `pip install` + 三行命令。这就是生态成熟的标志。 --- ## 六、数据安全：本地模型的真正价值回到上一篇讨论的政策话题。多地政府出台的"龙虾政策"里，无锡明确要求"部署 OpenClaw 时必须通过国产化适配认证"，深圳龙岗限定"使用国内头部多模态大模型"。 **本地模型是合规等级最高的方案**——数据不出设备，没有出境问题，没有第三方泄露风险。但别过度乐观。341 个恶意技能包事件提醒我们：**即使数据不出设备，供应链攻击依然存在。** 你下载的模型文件是否被篡改？你安装的 oMLX 是否是官方版本？这些问题不会因为"本地部署"就自动消失。安全的正确姿势不是"本地就安全了"，而是**多层防御**：本地部署（数据不出设备）+ 来源验证（模型和工具从官方渠道下载）+ 上篇讲的安全加固措施。 > **编者注**：本地部署解决了"数据在哪"的问题，但没解决"软件可信吗"的问题。就像你在家做饭解决了食品安全问题，但如果食材本身有问题，在哪做都不安全。安全是一个系统工程，不是一个部署方式。 --- ## 写在最后这是 OpenClaw 系列的第四篇。第一篇装起来，第二篇防起来，第三篇搞明白为什么火，这篇让数据留在本地。一条完整的路径：**从"用别人的 AI"到"拥有自己的 AI"。** 你不一定需要现在就跑本地模型。但 Mac Mini 脱销说明一件事——越来越多人开始认真思考"我的 AI 数据在哪"这个问题。《AI时代漫游指南》第 78 章说： > 「你不一定要出海，但你得知道——你可以。」 oMLX + OpenClaw，就是你的那艘船。 --- **想省钱用 AI？** 我们实测的 Claude + MiniMax 智能路由方案，月成本降 65%。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠： 👉 https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&source=link **不想自己折腾？** 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固+本地模型，不成功不收费。 --- 觉得有用的话，分享给身边也在关注 AI 的朋友吧 👇 **漫游君** | AI时代漫游指南

龙虾热的真相：算力过剩时代的个人AI

漫游君 — Wed, 11 Mar 2026 00:00:00 GMT

《AI时代漫游指南》第 50 章写道： > 「在这个宇宙中，有三种社会：物质稀缺社会、信息稀缺社会、以及算力丰裕社会。前两种已经是历史，第三种正在发生。而你此刻的选择，决定了你在新世界的位置。」这段话写于 2025 年底。三个月后，一只小龙虾用数据证明了它。 OpenClaw，60 天，250K Stars。 React 花了十年才到这个数字。Kubernetes 花了八年。OpenClaw 用了两个月。为什么？这篇文章不聊怎么装、怎么加固——前两篇已经讲过了。这篇聊一个更大的问题：**龙虾热背后，到底发生了什么？** 答案是四股力量同时交汇：算力从训练转向推理、价格战打穿成本、国内算力严重过剩、数据安全监管收紧。每一股单独看都是趋势，四股叠加就是浪潮。 --- ## 一、数据面：龙虾到底有多火先看数字，不讲故事。 - **250K Stars / 60 天**——日均 1,667 Stars，是 Kubernetes 巅峰增速的 18 倍 - **21,000+ 公网暴露实例**（Censys 扫描数据）——这还只是没做安全配置的那些 - **MoltHub 技能市场**：上线 45 天，技能数突破 12,000，日活开发者 3,800+ - **SimpleClaw**（付费托管版）：10 天收入 $28,000，验证了商业路径 - **341 个恶意技能包**（上篇讲过）：连黑产都跟进了，侧面说明用户规模从"用网页版 ChatGPT 聊天"到"自己搭一个 AI 网关"——这不是技术升级，是用户行为迁移。就像从看电视到自己开频道，从租服务器到买 NAS。 > **编者注**：判断一个技术是不是真火，有个简单标准：黑产跟不跟。垃圾邮件证明了 Email 的价值，钓鱼网站证明了电商的价值，341 个恶意技能包证明了 OpenClaw 的价值。这个逻辑虽然荒诞，但从没失灵过。 --- ## 二、算力大变局：从训练到推理 OpenClaw 爆发不是偶然。它踩中了 AI 产业最大的结构性变化——**算力重心从训练转向推理**。什么意思？简单说： - **训练**是教 AI 学东西，需要超大规模集群，跑几周甚至几个月，烧钱，但只做一次 - **推理**是 AI 回答你的问题，每次都要算，量小但频率极高过去几年，大家的注意力都在训练上——谁的模型参数多、谁的训练集大、谁烧的钱多。但 2025 年开始，画风变了： | 年份 | 推理算力占比 | 发生了什么 | |------|-------------|-----------| | 2023 | ~33% | GPT-4 发布，训练为王 | | 2025 | ~50% | 模型成熟，应用爆发 | | 2026（预计） | ~67% | 推理需求全面超过训练 | AI 推理芯片市场 2026 年预计突破 **$500 亿**（来源：多家券商研报）。全球 AI 数据中心资本支出达 **$4,000-4,500 亿**。这些数字意味着什么？ **AI 从实验室走进了客厅。** 训练是科学家的事，推理是普通人的事。你每天用 ChatGPT 聊天、用 AI 写代码、让 AI 帮你总结会议纪要——这些全是推理。推理需求爆炸，就需要一个东西来管理和路由这些推理请求。 OpenClaw 就是那个东西。它不是 AI 模型，是 AI 的**调度台**。 > **编者注**：类比一下：训练像建发电站，推理像用电。发电站建好了，接下来的问题是——电怎么配送到每家每户？OpenClaw 想做的就是那个"个人电网"。能不能做成另说，但需求是真实的。 --- ## 三、DeepSeek 效应：价格战改变了一切如果说算力转向推理是"需求侧"的变化，那 DeepSeek 就是"供给侧"的核弹。 2025 年初，DeepSeek R1 发布。性能对标 OpenAI o1，训练成本低 **90-95%**。这不是渐进式改进，是掀桌子。 **它触发了全球 AI 价格战：** - Claude Opus 4.6（Anthropic 最强模型）：从 $15/$75 降到 $5/$25（输入/输出每百万 token） - GPT-4 系列：多次降价，幅度 50-70% - 整体 API 价格：**全面下降约 80%** 一年前，用 Claude API 跑一个自动化工作流，月成本可能是 $200+。现在同样的工作量，$40 搞定。 **价格下降的连锁反应：** 1. 以前觉得"太贵了不值得"的场景，现在值得了 2. 以前只有公司才用得起的 AI 能力，个人也能玩了 3. "自建 AI 网关"从极客行为变成了经济理性行为我们自己就是活例子。之前写过一篇文章讲 Claude + MiniMax 智能路由：重活给 Claude，轻活给 MiniMax，月成本从 $4,200 降到 $1,491——降了 65%。OpenClaw 做的是同样的事，只是更通用、更开放。 > **编者注**：DeepSeek 对 AI 行业的冲击，有点像拼多多对电商的冲击——不是做出了更好的产品，而是证明了"够用的产品可以便宜 90%"。结果就是所有人都被迫跟进降价。对用户来说，这当然是好事。对投了几十亿训练模型的公司来说，这叫"战略性心碎"。 --- ## 四、国内算力过剩的尴尬价格战的另一面，是产能过剩。中国 AI 算力的建设速度，用"大跃进"来形容不过分： - 数据中心标准机架：从 2020 年的 315 万个增长到 2025 年的近 **1,100 万个** - 新建算力中，**约 80% 处于闲置状态** - 平均利用率仅 **20-30%** - 据估算，约 **1,000 万台服务器完全空闲**，对应约 **$300 亿的资源浪费** 政府已经意识到问题，正在建设全国算力调度网络（"东数西算"升级版），试图把闲置算力调配给有需求的地方。但矛盾来了： DeepSeek 证明了高效训练方法论可以把训练成本打下来 90%。这意味着**训练对算力的需求没有预期那么大**。建好的算力中心，本来指望卖给大模型公司做训练，现在训练不需要那么多了。剩下的出路是什么？**推理。** 而推理需求的大头在哪？在千千万万的个人用户和中小企业。 OpenClaw 这样的工具，恰好是把过剩算力和个人需求连接起来的桥梁。你通过 OpenClaw 调用国产模型 API（DeepSeek、MiniMax、Qwen），这些 API 背后就是那些闲置的数据中心。 > **编者注**：历史总是押韵。2015 年中国建了太多 4G 基站，结果催生了短视频和移动支付。2025 年建了太多 AI 算力，结果可能催生个人 AI 网关和本地智能体。基础设施过剩不一定是坏事——前提是有人把过剩的产能变成消费品。 --- ## 五、政策撕裂：一边喊停，一边下场前面讲的都是市场逻辑。但龙虾热最魔幻的部分，在政策层。 **一边是收紧。** 3 月 11 日，有消息称有关部门已要求 OpenClaw 立即降温——原因是 OpenClaw 绕过了国内大模型备案审查制度。中国对面向公众的 AI 大模型实行备案管理，ChatGPT、Claude 这些境外模型没有备案。OpenClaw 让任何人一键接入这些未备案模型，数据出境、模型未审查，两条红线同时踩。21,000 个公网暴露实例，在监管眼里不是"生态繁荣"，是"失控"。 **另一边是抢人。** 就在同一周，多地政府真金白银下场"养龙虾"： | 地区 | 政策 | 力度 | |------|------|------| | 合肥高新区（3/6） | 15 条措施，打造 OPC 创业生态示范区 | 最高 **1000 万元**扶持 | | 深圳龙岗（3/7） | "龙虾十条"，免费部署 + 数据开放 | 单企最高 200 万/年，基金最高 1000 万 | | 无锡高新区（3/9） | "养AI龙虾12条"，算力补贴 + 零房租 | 算力 30 万/年，办公最长 3 年免租 | | 常熟（3/9） | 13 条措施，全链条服务 | OPC 人才最高 600 万，购房补贴最高 200 万 | 深圳龙岗甚至给买"龙虾盒子"（AI NAS）的用户补贴市场价的 30%。常熟提供 30 天免费办公、住宿、餐饮，外加沪常通勤高铁补贴。无锡给初创项目最长 3 年"零房租"。 **这是什么画面？中央在说"失控了要管"，地方在说"来我这里养龙虾给你钱"。** > **编者注**：这种"上面收紧、下面抢人"的剧情，在中国产业史上并不陌生。电动车、光伏、半导体，哪个不是一边喊产能过剩，一边地方政府拼命招商？龙虾热只是最新一集。区别在于，这次地方政府抢的不是工厂，是"超级个体"——OPC（One Person Company，一人公司）才是真正的招商目标。 **矛盾怎么调和？** 看政策细节就有答案：无锡明确要求"部署 OpenClaw 时必须通过**国产化适配认证**"；深圳龙岗的模型调用补贴限定"使用**国内头部多模态大模型**"，按费用 30% 补贴，每家每年最高 100 万。翻译成人话：**政府不反对龙虾本身，反对的是龙虾接境外未备案模型。** | 场景 | 合规风险 | 政策态度 | |------|---------|---------| | OpenClaw 接 GPT-4/Claude | 高（未备案 + 数据出境） | 明确反对，要求阻断 | | OpenClaw 接国产备案模型 | 低 | 大力支持，给补贴 | | OpenClaw 接本地模型 | 最低 | 支持，算力补贴 | 现实很骨感：大部分用户装 OpenClaw 就是为了用 GPT-4 和 Claude。如果只能接国产模型，吸引力会打折扣——毕竟国产模型有官方客户端，何必多此一举？但地方政府用钱投票的信号很明确：**AI 超级个体是下一个招商赛道。** 龙虾只是载体，OPC（一人公司）才是真正的争夺目标——用 AI 武装的超级个体，一个人就是一家公司。 > **编者注**：341 个恶意技能包事件也给了政策制定者一个抓手——不仅模型未审查，技能市场也有安全漏洞。所以"国产化适配认证"不只是合规要求，也是安全需求。龙虾热的结局大概率不是"消失"，而是"招安"：接国产模型、过安全认证、拿政府补贴，从野生龙虾变成养殖龙虾。 --- ## 六、未来展望：算力从 To B 到 To C 把前面五节串起来看： 1. 算力重心从训练转向推理 → 个人场景变成主战场 2. DeepSeek 打响价格战 → 个人用得起了 3. 国内算力过剩 → 供给端有巨大产能等着被消化 4. 政策撕裂 → 中央要合规，地方抢人才，倒逼龙虾"招安" 前三股力量推着龙虾往前跑，第四股力量决定它往哪跑。**算力从 To B 走向 To C 是大方向，但龙虾会变成什么形态，政策说了算。** 这不是龙虾一个产品的故事，是整个行业的拐点。 OpenClaw 250K Stars 是一个信号——个人用户不再满足于"用别人的 AI"，他们想要"拥有自己的 AI"。这种意识的觉醒，和十年前人们开始在意"我的数据在哪"是一样的逻辑。只不过这次，不是数据主权，是**算力主权**。《AI时代漫游指南》第 50 章的那句话，放在今天更应景： > 「你此刻的选择，决定了你在新世界的位置。」龙虾热不是泡沫。泡沫没有四重结构性支撑。这是算力民主化的第一波浪潮。 > **编者注**：2025 年的选择决定 2035 年的位置——这句话第 50 章写过，现在再说一遍。不是因为它正确（预测未来没人能保证正确），而是因为等到所有人都看清楚的时候，窗口期就关了。龙虾热给普通人的启示不是"快去装 OpenClaw"，而是"开始认真思考你和 AI 的关系"。 --- ## 写在最后这是 OpenClaw 系列的第三篇。第一篇讲了怎么装，第二篇讲了怎么防，这篇讲了为什么火。三篇文章，一条线索：**AI 正在从云端走向个人**。装网关、做安全、理解背后的经济逻辑——这不是极客的玩具，是每个知识工作者迟早要面对的基础设施选择。你不需要现在就做决定。但你需要知道这些事正在发生。《AI时代漫游指南》第 50 章说： > 「算力丰裕社会不会等所有人准备好。它只会奖励那些提前布局的人。」下一篇，我们聊点轻松的——OpenClaw 上那些好玩的技能和工作流。 --- **想省钱用 AI？** 我们实测的 Claude + MiniMax 智能路由方案，月成本降 65%。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠： 👉 https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&source=link **不想自己折腾？** 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固，不成功不收费。 --- 觉得有用的话，分享给身边也在关注 AI 的朋友吧 👇 **漫游君** | AI时代漫游指南

OpenClaw安全加固：用魔法打败魔法

漫游君 — Tue, 10 Mar 2026 00:00:00 GMT

《AI时代漫游指南》第 115 章写道： > 「开源意味着代码透明，但透明不等于可信。你能看到的是源码，看不到的是运行时行为、数据流向、以及商业动机。」上一篇我们讲了怎么在 Windows 上把 OpenClaw 装起来。装好了，跑起来了，能聊天了——然后呢？然后你就把一台连着你所有 AI API Key、聊天记录、甚至文件系统的机器，暴露在了网络上。这篇文章讲的是：**怎么让你的小龙虾不被人端走。** --- ## 先澄清一个误区上篇发出后，有读者问：「你说数据留在本地，但 AI 模型还是在云端啊？」说得对。OpenClaw 是**网关**，不是模型。默认配置下，你的对话会通过 OpenClaw 转发到云端 API（OpenAI、Claude 等），对话内容确实经过云端处理。 **如果你在意这一点**，OpenClaw 支持接入本地模型（Ollama、MLX 等）。用本地模型，对话数据才是真正不出你的电脑。当然，本地模型的能力和云端大模型还有差距——这是隐私和能力之间的取舍，自己权衡。 OpenClaw 给你的掌控是：**选哪个模型、数据怎么路由、记忆怎么管理。** 这是网关层的安全，也正是这篇文章要讲的。 --- ## 你的小龙虾暴露了什么？装完 OpenClaw，默认状态下你的机器在广播这些信息： **mDNS 广播**（端口 5353）：OpenClaw 默认开启服务发现，会向局域网广播你的主机名、CLI 路径、SSH 端口。你去**咖啡厅连 Wi-Fi，同一网络的人都能看到你跑着 OpenClaw**。 **Web 控制面板**：如果你开放了防火墙端口，控制面板就对局域网可见。 **API Key 明文存储**：默认配置文件里，你的 OpenAI / Claude / MiniMax API Key 都是明文。 > **编者注**：这就好比你在家门口贴了张纸条：「我家有 AI，钥匙在门垫下面。」开源社区管这叫"默认不安全"——一个政治正确但后果严重的设计哲学。 --- ## 341 个恶意技能包：真实事件 2026 年 2 月，安全研究人员发现 OpenClaw 技能市场中有 **341 个技能包含恶意代码**，会窃取用户的 API Key 和聊天凭证。官方已确认并下架。这不是假设场景，是已经发生的事。 **攻击路径很简单**： 1. 攻击者上传一个看起来很有用的技能（比如"高级翻译"、"智能摘要"） 2. 技能代码中夹带私货：读取配置文件，把 API Key 发送到外部服务器 3. 用户安装技能，Key 就泄露了 **你现在就能做的**：打开 OpenClaw 控制面板，看看你装了哪些技能。不认识的、来路不明的、权限要求过多的——卸掉。像审查手机 App 权限一样审查技能包。一个"翻译技能"要读文件系统权限？不对劲。 > **编者注**：Stars 数量反映受欢迎程度，不反映安全审计深度。技能市场也一样：下载量高的技能不一定安全，可能只是名字起得好。 --- ## 安全加固：从"零门槛"到"进阶" 不是所有加固都需要敲命令。按难度分两档，你看自己到哪一步： ### 零门槛（不需要技术背景，5 分钟） **1. 清理不明技能** 打开控制面板 → 技能管理 → 逐个检查 → 卸掉你不认识的。这是最重要的一步。341 个恶意技能包的事情说明：**你装了什么，比你配了什么更危险。** **2. 跑一次安全审计** OpenClaw 自带体检命令，在终端输入： ``` openclaw security audit ``` 它会自动检查：配置文件里有没有明文密钥、端口有没有暴露、已装技能有没有已知漏洞。看不懂输出没关系——有 ❌ 的就是要修的，把结果截图发给你身边懂技术的朋友，或者直接扔给 AI 问"这个怎么修"。 **3. 不要在公共 Wi-Fi 下用** OpenClaw 默认会广播自己的存在。在家用没问题，去星巴克就别开了——除非你做了下面的进阶配置。 > **编者注**：安全的 80/20 法则——80% 的风险可以用 20% 的努力消除。上面三步就是那 20%。 ### 进阶（需要敲命令，10 分钟）如果你愿意打开终端，下面四步让安全再上一个台阶： **1. Gateway 绑定 localhost** 默认情况下 Gateway 监听所有网络接口，任何人都能直连。改成只监听本机： ``` openclaw config set gateway.host "127.0.0.1" ``` 改完之后，外部设备不能直连了。如果你需要从手机或其他电脑访问，加一层反向代理（推荐 Caddy，自动 HTTPS，三行配置搞定）,不清楚也可以问你的AI小助理。 **2. 关闭 mDNS 广播** ``` 设置环境变量 OPENCLAW_DISABLE_BONJOUR=1 重启 Gateway ``` 关了之后，你的 OpenClaw 不再向局域网"喊"自己的存在。 **3. API Key 用环境变量** 不要把 Key 明文写在配置文件里。用环境变量存储，OpenClaw 会自动读取。配置文件里的明文 Key 删掉。 **为什么重要**：配置文件可能被 Git 提交、被恶意技能读取、被同步软件上传。环境变量至少多一层保护。 **4. 限制高危工具** OpenClaw 的 Agent 默认可以执行命令、访问网页、写文件。这些能力很强大，但如果被恶意利用，后果也很严重。在控制面板的工具权限设置中，把 `exec`（执行命令）和 `file_write`（写文件）限制为只有你信任的 Agent 可用。 > **编者注**：给 AI 全部权限，就像给实习生管理员密码——大部分时候没事，出事那次你就知道什么叫后悔了。 --- ## 用魔法打败魔法上面的操作，不管是零门槛还是进阶，都是"做一次就完了"。但安全不是一次性的事——你下次装个新技能、改个配置，风险就可能回来。 **核心思路**：既然 OpenClaw 本身就是一个 AI 平台，为什么不让 AI 来帮你持续盯着？ ### 最简单的方式你甚至不需要写代码。直接在 OpenClaw 的对话窗口里对 AI 说： > "帮我检查一下当前的安全配置：有没有明文 API Key、端口是不是只监听 localhost、装了哪些技能、有没有闲置设备。给我一个安全报告。" AI 会调用系统工具帮你跑检查，然后给你一份报告。 **每周花 30 秒发一条消息，换一整周的安心。** ### 进阶：自动化巡检如果你想完全自动化，可以创建一个定时任务：每天早上 9 点，OpenClaw 自动跑安全审计，结果发到你的聊天通道（Telegram / 飞书）。有 ❌ 的项目立即提醒。你每天早上喝咖啡的时候瞄一眼，没事就安心，有事就处理。 > **编者注**：用 AI 审计 AI 的安全，听起来像让小偷看家。但人类安全审计也是让一个人检查另一个人的工作。至少 AI 不会偷懒，不会因为周五下午就跳过检查。《AI时代漫游指南》第 116 章说——80% 的安全事故来自已知问题的遗漏，不是未知漏洞的发现。自动化清单检查就能干掉这 80%。 --- ## 安全检查清单每次部署或更新后，对照这张表过一遍： | 检查项 | 难度 | 状态 | |--------|------|------| | 不明技能已清理 | 零门槛 | □ | | `openclaw security audit` 通过 | 零门槛 | □ | | 不在公共 Wi-Fi 下裸奔 | 零门槛 | □ | | Gateway 只监听 localhost | 进阶 | □ | | mDNS 广播已关闭 | 进阶 | □ | | 无明文 API Key | 进阶 | □ | | 高危工具已限制 | 进阶 | □ | | 反向代理已配置（外网访问时） | 进阶 | □ | 前三项是底线，后五项是加分。做到前三项，你就已经比 90% 的用户安全了。 --- ## 常见问题 | 问题 | 回答 | |------|------| | 只在家用，需要加固吗？ | 前三项零门槛的建议做，5 分钟换一整年安心 | | 已经暴露了端口怎么办？ | 立即改绑定 + 轮换所有 API Key（去各平台后台重新生成） | | 技能市场还能用吗？ | 能，但只装官方推荐的和你认识的作者的 | | 不懂代码，进阶部分怎么做？ | 把这篇文章扔给 AI 桌面客户端，让它一步步教你 | --- ## 写在最后 OpenClaw 是一个强大的工具，但强大意味着攻击面也大。好消息是，安全加固不需要你成为安全专家。 **最低限度**：清理技能 + 跑一次审计 + 别在外面裸奔。5 分钟。 **更好的方式**：让 AI 自己盯着自己。每周一句话，换持续的安心。这就是"用魔法打败魔法"——你手里已经有一个不睡觉的守卫了，让它干活。《AI时代漫游指南》第 116 章说： > 「最好的安全策略不是把墙砌得更高，而是让守卫永远不睡觉。AI 就是那个不睡觉的守卫。」你的小龙虾，值得被好好保护。 --- **不太想自己折腾？** 把这篇文章扔给 MiniMax 桌面版，让 AI 一步步教你操作。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠： 👉 https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&source=link **连终端都不想开？** 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固，不成功不收费。 --- 觉得有用的话，分享给身边也在折腾 AI 工具的朋友吧 👇 **漫游君** | AI时代漫游指南

Win上OpenClaw避坑指南：从安装到真正能用

漫游君 — Tue, 10 Mar 2026 00:00:00 GMT

《AI时代漫游指南》第114章写道： > 「Windows 防火墙就像一个过度紧张的保安，连自家人都不放行。」最近有朋友问我：OpenClaw 怎么在 Windows 上装？说实话，安装本身并不复杂——一行命令的事。但从"安装完成"到"真正能用"之间，有一条暗坑密布的路。我在两台 Windows 电脑上分别部署了 OpenClaw，踩了防火墙的坑、自启动的坑、设备配对的坑。这篇文章把这些坑全整理出来，省你至少一个下午的排查时间。 **不太会用终端？** 两个选择： - **自力更生**：装一个 AI 桌面客户端（比如 MiniMax 桌面版），把这篇文章扔给它，让它一步步教你敲命令。后端用 MiniMax Coding Plan，性价比很高（之前写过一篇《MiniMax Coding Plan 完全指南》，公众号里搜一下就能找到） - **完全不想折腾**：我在闲鱼有 OpenClaw 安装服务，远程 1 对 1，装好能用，不成功不收费。闲鱼搜「OpenClaw 安装」就能找到 --- ## 什么是 OpenClaw？它是一个开源的 AI 网关，装在你自己的电脑上，让你通过飞书、Telegram、WhatsApp 等聊天工具直接和 AI 对话。一句话概括：**把你的电脑变成一台 AI 网关，然后通过聊天消息控制它。** 不需要云服务器，不需要月租费。但要说清楚一件事：**OpenClaw 是网关，不是模型。** 你的对话请求会通过 OpenClaw 转发到云端 AI（OpenAI、Claude 等），对话内容仍然经过云端处理。OpenClaw 管理的是路由、技能、记忆和多平台接入——模型推理不在本地。想要真正的"数据全部留在本地"？可以接本地模型（比如 Ollama、MLX），但那是另一个话题了。 > **编者注**：OpenClaw 给你的是网关层的掌控（选哪个模型、数据怎么路由、记忆怎么管理），不是推理层的掌控。分清这两层，才不会有错误预期。 --- ## 前置条件开始之前，确认你的电脑满足这些条件： | 项目 | 要求 | |------|------| | 操作系统 | Windows 10/11 | | Node.js | v22 以上 | | 网络 | 能访问 npm 仓库 | 没有 Node.js？推荐用 nvm-windows 安装管理，或者去 nodejs.org 下载安装包，一路 Next 就行。 > **编者注**：Node.js 的安装是真正的"零摩擦"——下载、双击、Next、完成。如果所有软件安装都这么简单，这篇文章就不需要存在了。 --- ## 第一步：安装 OpenClaw 打开 PowerShell（管理员模式），输入： ``` npm install -g openclaw ``` 等它跑完，就装好了。验证一下： ``` openclaw --version ``` 看到版本号就说明安装成功。 --- ## 第二步：运行引导向导 ``` openclaw onboard --install-daemon ``` 这是一个交互式向导，会一步步引导你：选 AI 模型提供商、配 API Key、选聊天平台、设控制面板密码。向导跑完后，Gateway 守护进程自动启动。浏览器打开终端显示的地址（默认 `http://localhost:18789`），就能看到控制面板了。 --- ## 第三步：设备配对 OpenClaw 使用双重认证：Token + 设备公钥。从其他设备访问控制面板时，你可能会看到 "pairing required"。这是 OpenClaw 的双重认证——每个新设备需要被批准。在命令行执行： ``` openclaw devices list ``` 找到你的设备，然后批准它： ``` openclaw devices approve <设备ID> ``` 刷新页面，就能正常使用了。 > **编者注**：这个双重认证设计其实很聪明——即使有人知道了你的 Token，没有设备公钥也进不来。安全和便利，永远在互殴。 --- ## 最大的坑：防火墙 **如果你只在本机用，可以跳过这段。但如果你想从手机或其他电脑访问，请认真看。** 你会去 Windows 防火墙添加一条端口允许规则。然后发现——**还是连不上。** 原因是 Windows Defender 防火墙有一个反直觉的设计： **Block 规则的优先级永远高于 Allow 规则。** Windows 默认会给 Node.js 创建一条"阻止 + 公共网络"的规则。不管你加多少条允许规则，只要这条阻止规则存在，外部访问就永远被拦截。 ### 更隐蔽的坑：VPN 网络如果你用 WireGuard 或类似的 VPN 组网，它创建的虚拟网卡会被 Windows 归类为"公共网络"。而那条阻止规则恰好针对公共网络。结果就是：**WiFi 能连，VPN 连不上。** 同一台电脑、同一个程序，两种网络走了两条不同的防火墙规则。 ### 修复方法打开 PowerShell（管理员模式）： ``` # 查看所有 Node.js 相关的防火墙规则 Get-NetFirewallRule -DisplayName "*Node*" | Format-Table DisplayName, Direction, Action, Profile # 把 Block 规则改成 Allow Set-NetFirewallRule -DisplayName "Node.js: Server-side JavaScript" -Action Allow ``` 或者手动操作：打开"Windows Defender 防火墙 → 高级设置 → 入站规则"，找到所有 Node.js 相关的规则，把"阻止"改成"允许"。改完之后，从其他设备访问就通了。 > **编者注**：我在这个坑上花了两个小时。不是因为问题难，而是因为 Windows 的防火墙太"贴心"了——它帮你做了一个你不知道的决策，然后把线索藏在你不会看的地方。安全软件的通病：保护你的方式，是不让你知道它在保护你。 --- ## 配置自启动如果希望开机就运行 OpenClaw： onboard 时加了 `--install-daemon`，就会自动创建 Windows 计划任务。如果没加，可以手动执行： ``` openclaw gateway install ``` **重要细节**：这个计划任务的触发条件是**"用户登录时"**，不是"系统启动时"。这意味着：电脑重启后如果没有登录（比如远程服务器场景），OpenClaw 不会自动启动。你需要远程登录一次，或者手动触发： ``` schtasks /run /tn "\OpenClaw Gateway" ``` > **编者注**：Windows 的计划任务是个被低估的工具。大部分人只用它来设闹钟，但它其实是 Windows 上最接近 Linux 定时任务的东西。 --- ## 连接聊天通道 OpenClaw 支持多种聊天通道： | 通道 | 难度 | 注意事项 | |------|------|---------| | 网页版 | 最简单 | 打开就能用 | | 飞书 | 中等 | 需开发者账号 | | Telegram | 中等 | 需代理 | | WhatsApp | 中等 | 需代理 | **Telegram 的坑**：如果两台电脑用了同一个 Telegram Bot，会报 409 冲突——因为 Telegram 只允许一个消费者拉取消息。解决方法：只在一台机器上启用 Telegram。 --- ## 代理配置如果你在国内使用，大概率需要配代理才能连接外部 API。在配置文件 `.openclaw/openclaw.json` 中添加： ```json { "proxy": "http://127.0.0.1:你的代理端口" } ``` **踩坑经验**：代理地址尽量用本机的。本机代理挂了你自己能发现，远程代理挂了你可能排查半天才定位到——所有模型同时超时，你会先怀疑 API 出了问题，最后才发现是代理断了。 --- ## 进程挂死怎么办我在使用过程中遇到过进程挂死的情况。解决方法按顺序尝试： ``` # 方法 1：正常重启 openclaw gateway restart # 方法 2：手动触发计划任务 schtasks /run /tn "\OpenClaw Gateway" # 方法 3：暴力重启 # 先找到进程 netstat -ano | findstr <你的端口> # 杀掉进程 taskkill /PID <进程ID> /F # 重新启动 openclaw gateway start ``` > **编者注**：运维的本质就是三件事：启动、检查、重启。如果这三件事都不管用，那就该看日志了。日志在 `C:\tmp\openclaw\` 目录下，每天一个文件，拿编辑器打开搜 ERROR 就行。 --- ## 常见问题速查 | 症状 | 原因 | 修复 | |------|------|------| | 控制面板打不开 | 网关没启动 | `openclaw gateway start` 或 `openclaw doctor` | | 显示 "pairing required" | 设备未配对 | `openclaw devices list` + `approve` | | 局域网连不上 | 防火墙阻止规则 | 改 Node.js 规则为允许 | | VPN 设备连不上 | 虚拟网卡被归为公共网络 | 同上 | | 重启后没自启 | 需要登录触发 | 远程登录一次 | | 所有模型超时 | 代理配置问题 | 检查代理地址是否可达 | | 启动后立即崩溃 | API Token 过期 | `openclaw auth login` 重新认证 | | 不确定哪里出了问题 | — | `openclaw doctor` 自动诊断 | --- ## 写在最后回头看，OpenClaw 在 Windows 上的安装其实就三步： 1. `npm install -g openclaw` 2. `openclaw onboard --install-daemon`（交互式引导，一路选就行） 3. 浏览器打开控制面板，开始使用之所以写了这么长，是因为"三步搞定"只是理论上的。现实中你会遇到防火墙拦截、设备配对困惑、自启动不生效……每一个都不复杂，但叠在一起就足够让人抓狂。《AI时代漫游指南》第 24 章说： > 「启动成本是习惯的真正敌人。不是你懒，是从'想用'到'能用'之间，隔着太多摩擦。」这篇文章的目的，就是帮你把这些摩擦全部干掉。装好了就开始用吧。Don't Panic. --- 觉得有用的话，分享给身边也在折腾 AI 工具的朋友吧 👇 **漫游君** | AI时代漫游指南

Prompt 工程入门：和 AI 对话的正确姿势

漫游君 — Tue, 10 Mar 2026 00:00:00 GMT

## 为什么你的 AI 总是"不太聪明" 你有没有过这样的体验—— > "帮我写一篇关于 AI 的文章。" 然后得到一篇泛泛而谈、充满废话的文章？问题不在 AI，在你的提示词。这就像你对一个极其聪明但完全不了解你的助手说"帮我做点事"——他能做，但不知道你要什么。 ## 黄金法则：CRISPE 框架一个好的 prompt 包含以下要素： - **C**ontext（上下文）：你是谁，在做什么 - **R**ole（角色）：AI 应该扮演什么角色 - **I**nstruction（指令）：具体要做什么 - **S**pecifics（细节）：格式、长度、风格等约束 - **P**erspective（视角）：从什么角度 - **E**xamples（示例）：给出期望输出的样本 ### 实战对比 **差的 prompt：** ``` 写一篇关于 Python 的文章 ``` **好的 prompt：** ``` 你是一位资深 Python 开发者，正在给有 1 年编程经验的初学者写一篇教程。请写一篇关于 Python 装饰器的入门指南： - 长度：800-1000 字 - 风格：友好、通俗，避免学术腔 - 结构：概念解释 → 简单示例 → 实际应用场景 → 常见陷阱 - 代码示例使用 Python 3.11+ - 每个代码块后附带运行结果 ``` 第二个 prompt 的输出质量会好 5 倍以上。 ## 进阶技巧 ### 1. Chain of Thought（思维链）让 AI 展示推理过程，而不是直接给答案： ``` 请一步一步分析这个 bug 的原因，在给出修复方案之前，先列出所有可能的原因。 ``` ### 2. Few-shot Learning（少样本学习）给 AI 看几个例子，让它学习你的风格： ``` 以下是我之前写的文章开头，请模仿这个风格：示例 1: "2026 年，AI 已经不是新闻了..." 示例 2: "你有没有过这样的体验..." 现在请用这个风格，写一个关于 [主题] 的开头。 ``` ### 3. 角色叠加给 AI 多重角色，获得更有深度的输出： ``` 你同时是一位技术架构师和产品经理。从这两个角度分析这个方案的利弊。 ``` ## 常见误区 1. **Prompt 越长越好？** 不是。精确比冗长重要。 2. **一次 prompt 搞定一切？** 不要。复杂任务分步来。 3. **AI 说的都对？** 当然不是。永远验证关键信息。 ## 我的 Prompt 工作流 ``` 第一轮：给出背景和粗略要求，看 AI 理解了多少第二轮：根据输出纠正方向，补充细节第三轮：微调格式和风格 ``` 这比一次性写一个超长 prompt 更高效，因为你可以在过程中观察 AI 的理解偏差并即时修正。 ## 写在最后 Prompt Engineering 不是什么高深的学问。它的本质是**清晰表达你的需求**——这恰好也是日常沟通中最重要的技能。和 AI 对话的过程，其实也是和自己对话的过程。当你不得不把模糊的想法变成精确的文字时，你会发现自己的思考变得更加清晰了。 --- *漫游君 · 2026 年春 · 正在和 AI 对话中*

AI Agent 架构实战：从单体到分形

漫游君 — Sun, 08 Mar 2026 00:00:00 GMT

## 一个 Agent 的极限当你让一个 AI Agent 同时做项目管理、写代码、测试、部署时，你会发现一个残酷的事实：**上下文窗口是有限的，但任务复杂度是无限的。** 一个 Agent 的上下文就像一个人的工作记忆——同时记住太多东西，就什么都做不好。这就是为什么我们需要多 Agent 架构。 ## 分形架构：自相似的 Agent 层级 > "分形"是指在不同尺度上呈现自相似结构的模式。我设计的 Agent 系统采用分形架构。每一层的 Agent 都有相同的结构： ``` Agent/ ├── character/ # 人格定义：我是谁，我做什么 ├── abilities/ # 能力声明：我能做什么 ├── skills/ # 操作规程：我怎么做 ├── knowledge/ # 结构化知识：我知道什么 └── information/ # 日志与讨论：发生了什么 ``` 从顶层的领域 Agent 到底层的执行 Agent，结构完全一致，只是职责范围不同。 ### 层级示例 ``` 领域 Agent (A9 Webstation) └── 协调 Agent (my_project_agent) ├── 内容 Agent — 负责文章规划和写作 ├── 开发 Agent — 负责编码和部署 └── 运营 Agent — 负责 SEO 和分发 ``` 每个 Agent 独立运作，通过标准化接口通信。 ## 五层记忆体系 Agent 的记忆分为五层，灵感来自人类认知科学： | 层级 | 名称 | 类比 | 更新频率 | |------|------|------|----------| | 00 | Character | 性格 | 极低 | | 01 | Abilities | 技能 | 低 | | 02 | Skills | 操作手册 | 中 | | 03 | Knowledge | 长期记忆 | 中 | | 04 | Information | 工作记忆 | 高 | 关键设计原则：**越底层的记忆越稳定，越顶层的记忆越易变。** 这和人类一样——你的性格很少改变，但你昨天吃了什么很快就忘了。 ## 通信协议：MCP Agent 之间通过 MCP (Model Context Protocol) 通信。这是一个标准化协议，让不同的 Agent（甚至不同模型驱动的 Agent）能够互相理解。 ```python # Agent 暴露工具 @mcp.tool() async def get_project_status(project_id: str) -> dict: """获取项目当前状态""" return await self.knowledge.query(project_id) # 其他 Agent 调用 result = await coordinator.call_tool( "get_project_status", {"project_id": "ai-navigator"} ) ``` ## 实战教训 ### 1. 不要过早拆分一个 Agent 能搞定的事，不要用三个。过度拆分带来的通信开销会抵消并行化的收益。 ### 2. 让 Agent 有自主权好的 Agent 系统不是流水线，是团队。给每个 Agent 足够的自主权，让它们自己决定如何完成任务。 ### 3. 记忆比推理重要一个记忆力好的 Agent 比一个推理能力强的 Agent 更有价值。因为记忆可以避免重复犯错，而推理每次都要从头开始。 ### 4. 人在回路不可省无论 Agent 多聪明，关键决策点必须有人类参与。这不是对 AI 的不信任，而是对风险的尊重。 ## 未来方向我正在探索的几个方向： - **Agent 的自我进化**：让 Agent 根据执行结果自动优化自己的 Skills 层 - **跨域协作**：不同领域的 Agent 如何高效协作 - **本地化部署**：用 oMLX 等框架实现全本地推理，保护隐私 Agent 架构仍然是一个快速演进的领域。唯一不变的原则是：**从简单开始，按需复杂化。** --- *漫游君 · 2026 年春 · 正在和 Agent 们一起写这篇文章*

为什么要做 AI时代漫游指南

漫游君 — Fri, 06 Mar 2026 00:00:00 GMT

## 一切始于焦虑 2024 年末的一个深夜，我在刷完第 N 篇"AI 即将取代程序员"的文章后，关掉了手机屏幕。黑暗中，我问自己一个问题：**如果 AI 真的能做我所有的工作，那我是谁？** 这不是一个修辞问题。作为一个写了十年代码的人，编程不只是我的职业，它是我理解世界的方式。如果这个方式被一个更快、更准、永不疲倦的存在取代了，我的价值在哪里？ ## 从恐惧到好奇焦虑持续了大约两周。然后我做了一件改变了一切的事——我开始**真正使用**这些 AI 工具。不是浅尝辄止地试一下，而是把它们融入每天的工作流。用 Claude 做代码审查，用 Midjourney 做设计原型，用 GPT 做市场调研。结论出乎意料： > AI 没有取代我。它**放大**了我。我发现自己的产出效率提升了 3-5 倍，但更重要的是，我终于有时间做那些"重要但不紧急"的事了——深度思考、战略规划、写作、学习新领域。 ## 方向比速度重要但并不是每个人都有这样的幸运。我身边有太多朋友： - 被信息洪流淹没，不知道该学什么 - 花了大量时间在错误的 AI 工具上 - 对 AI 有不切实际的期望或恐惧 - 想用 AI 但不知道从哪里开始他们需要的不是更多的信息。他们需要的是**方向**。 ## 银河漫游指南这就是为什么我创建了这个站点。名字致敬道格拉斯·亚当斯的《银河系漫游指南》——那本封面上写着"Don't Panic"的虚构百科全书。在一个未知而广阔的宇宙（AI 时代）里，你需要一本靠谱的指南。这里不会有： - 标题党和贩卖焦虑 - 不切实际的承诺（"一周精通 AI"） - 纯理论的空谈这里会有： - **真实的使用体验**——我亲自用过才会推荐 - **实战的操作指南**——能跟着做的教程 - **深度的思考文章**——不只是 how，更要问 why - **方向的导航建议**——在信息洪流中找到你的轨道 ## 太阳系暖阳为什么选择太阳系暖阳作为设计主题？因为在深空的冷寂中，太阳是唯一的热源。AI 时代有太多冰冷的效率论述，我想做一个有温度的角落。金色是方向，橙色是热情，奶油色是从容。这个站点的每一个像素都在说同一句话：**别慌，跟着光走。** ## 一起漫游如果你也在这个 AI 时代感到迷茫，或者只是好奇这个世界正在发生什么——欢迎登船。银河很大，但我们不用独自旅行。 --- *漫游君 · 2026 年春 · 在太阳系的某颗星球上*

Mac本地跑大模型：MLX部署实战

漫游君 — Sat, 21 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 50 章「算力丰裕社会」记载：「在这个宇宙中，有三种社会：物质稀缺社会、信息稀缺社会、以及算力丰裕社会。前两种已经是历史，第三种正在发生。」 > > 但别着急——算力丰裕的前提是，你得先把大模型跑起来。 --- 你有没有想过，自己的电脑能不能跑大模型？不是那种"下个 App 聊两句"的玩具级别，而是真正的、参数量以百亿计的大语言模型——就跑在你的桌面上，不联网，不花 API 费用，数据不出家门。我最近用 Apple 的 MLX 框架，在一台 Mac 上跑起了 MiniMax-M2.5——一个 2300 亿参数的开源大模型。 **本地大模型，已经从极客玩具变成了实用工具。** 今天把这段经历分享出来。不需要编程基础，但你需要一台 Apple Silicon 的 Mac。 > **编者注**：当我说"不需要编程基础"的时候，意思是你不需要写代码。但你需要会打开终端、复制粘贴命令。如果这已经超出了你的舒适区——恭喜你，这篇文章正是为了帮你走出舒适区而写的。 --- ## 为什么要在本地跑大模型？ ChatGPT、Claude、DeepSeek 都很好用，为什么要折腾本地部署？ | 云端 AI | 本地大模型 | |---------|-----------| | 每月 $20 订阅费 | 一次部署，长期免费 | | 数据上传到别人的服务器 | 数据不出你的电脑 | | 断网就没了 | 断网照常用 | | 别人说停就停 | 你的模型你做主 | **核心理由只有一个：主权。** 你的数据、你的对话历史——这些不应该存在别人的服务器上。当你把大模型跑在自己电脑上，你拥有的不只是一个工具，而是一个**完全属于你的 AI 助手**。 > **编者注**：有人说"我又没什么秘密"。但你写的日记、你和 AI 讨论的商业计划、你让 AI 帮你改的简历——这些东西，你真的愿意让陌生人看到吗？隐私不是因为你有什么见不得人的，而是因为那是你的。 --- ## 你需要什么？ **关键指标只有一个：内存（统一内存）。** Apple Silicon 的 Mac 有一个独特优势：CPU 和 GPU 共享同一块内存。这意味着——**你的内存就是你的显存。** | 模型大小 | 需要的内存 | 推荐机型 | |---------|-----------|---------| | 70 亿参数 | 8GB | MacBook Air | | 140 亿参数 | 16GB | MacBook Pro | | 700 亿参数 | 64GB | Mac Studio | | 2300 亿参数 | 128GB+ | Mac Studio Ultra | > **编者注**：别被顶配吓退。一台入门级 MacBook Pro 就够跑小模型了。本地 AI 的门槛，比你想象的低得多。还需要： - macOS Sonoma 14.0+ - Python 3.12+ - MLX 框架（Apple 官方开源） - 约 120GB 硬盘空间 --- ## 动手：从零到对话 ### 第一步：安装 MLX 打开终端，三行命令搞定：创建 Python 虚拟环境 → 激活 → 安装 MLX。整个过程不到 5 分钟。 ### 第二步：下载模型这是最考验耐心的一步。 MiniMax-M2.5 的量化版本大约 120GB，下载速度取决于网络。我用了大约 2 小时。 **为什么选 MiniMax-M2.5？** | 模型 | 总参数 | 激活参数 | 特点 | |------|--------|---------|------| | Llama 3.1 | 700 亿 | 700 亿 | 社区大 | | Qwen 2.5 | 720 亿 | 720 亿 | 中文强 | | **MiniMax-M2.5** | **2300 亿** | **100 亿** | **性价比极高** | MiniMax-M2.5 用了 MoE（混合专家）架构：虽然总参数有 2300 亿，但每次推理只激活 100 亿参数。 > **编者注**：MoE 就像一个大公司——虽然有 2300 个员工，但每次开会只叫 100 个人。所以你不需要租一个能坐 2300 人的会议室，100 人的就够了。 ### 第三步：启动服务一行命令启动 MLX 服务。第一次启动会比较慢——需要把模型加载到内存里，大约 3-5 分钟。启动成功后——**恭喜，你现在拥有了一个私有的 AI 服务器。** ### 第四步：开始对话和 ChatGPT 的调用方式几乎一模一样。你现有的任何 AI 工具——聊天界面、自动化脚本——都可以无缝切换到本地模型。**只需要改两行配置。** > **编者注**：MLX 的 API 兼容性做得非常好。Apple 虽然在 AI 领域动作慢，但 MLX 这个框架确实是给开发者的一份大礼。 --- ## 踩坑实录 ### 坑 1：启动巨慢第一次启动用了 HuggingFace 的缓存路径，MLX 会逐个验证模型文件，**光验证就花了 20 分钟。** 解决：直接用本地路径，秒启。 ### 坑 2：局域网连不上想从另一台电脑访问，一直报错。排查半天，发现是 HTTP 代理把局域网请求也代理了。解决：设置代理例外，排除局域网地址。 ### 坑 3：跑着跑着就挂了连续运行 19 小时后，服务悄悄死掉了。没有报错，没有日志。这是 MLX 的已知问题。解决：写个看门狗脚本，每 5 分钟检查一次，挂了自动重启。 > **编者注**：让本地 AI 教你怎么让它自动重启——这大概是 AI 时代最有哲学意味的事情了。 --- ## 实际体验跑了几天后，我的结论： **✅ 适合做的事：** 日常对话、文本摘要、简单代码、翻译、隐私敏感处理 **❌ 不太行的事：** 长文写作、复杂推理、最新知识、超长对话 **核心结论：本地模型是补充，不是替代。** 它最大的价值不是"比 ChatGPT 更强"，而是"在 ChatGPT 不方便用的时候，给你一个选择"——断网的时候、处理敏感数据的时候、不想付订阅费的时候。 --- ## 成本算一算 | 项目 | 费用 | |------|------| | 硬件 | 你已有的 Mac | | 电费 | 一杯咖啡的钱 | | 软件 | ¥0（全部开源） | | API 费用 | ¥0（永久免费） | > **编者注**：如果你像我一样，买 Mac 的理由本来就包括"跑本地模型"——那这篇文章就是在帮你合理化一笔已经花出去的钱。心理学管这叫"购后合理化"，我管这叫"理性投资"。 --- ## 给普通人的建议 **想体验？** 16GB Mac + 7B 模型，1 小时搞定。 **想认真用？** 64GB + 70B 模型 + 自动启动脚本。 **想折腾到极致？** 256GB + 局域网共享 + 自动化工作流。 **不管哪种，核心就一句：先跑起来，再慢慢折腾。** > **编者注**：这也是《AI时代漫游指南》第 24 章的核心观点：「习惯的敌人不是懒，而是启动成本。」先把大模型跑起来，哪怕只是对话两句——降低启动成本，后面的事情自然会发生。 --- ## 写在最后半年前，本地跑大模型还是极客的专属领地。你需要 NVIDIA 显卡、CUDA 驱动、Docker 容器…… MLX 改变了这个局面。 Apple 做了一件很聪明的事：把大模型推理和统一内存深度绑定。 **你的内存就是你的显存。** 这就是为什么我说算力丰裕时代正在到来——不是因为云端 API 变便宜了，而是因为**你桌上的电脑，已经有能力成为一个 AI 服务器了。** --- > 「2025 年的选择决定 2035 年的位置。」——《AI时代漫游指南》第 50 章 > > 不是因为你必须在本地跑大模型，而是因为你应该知道——**你可以。** --- 🔗 **相关资源** - MLX 框架（GitHub）— Apple 官方开源 - MLX-LM — 一键跑本地大模型 - MiniMax-M2.5（HuggingFace）— MIT 开源，免费商用 --- *如果这篇文章帮到你了，欢迎分享给需要的朋友。我们下期见。* *Don't Panic.* --- **作者：漫游君** **公众号：AI时代漫游指南**

树莓派+AI+19个RSS源=你的私人情报站

漫游君 — Wed, 18 Feb 2026 00:00:00 GMT

> 《AI时代漫游指南》第 77 章·自动化的正确姿势： > > 「宇宙中有 73% 的知识工作者，每天早上醒来第一件事就是手动让 AI 分析信息。但真正聪明的那 27%，会让分析报告自动出现在邮箱里。」你每天花多长时间在"看新闻"上？我算了一下：刷 X 十五分钟，翻 HackerNews 十分钟，扫 36 氪五分钟，查几个 AI 公司博客又十分钟——加起来每天至少四十分钟。还经常看完就忘了，该看的没看到，不该看的倒看了不少。更扎心的是：**这四十分钟里，真正有价值的信息可能就两三条。** 所以我做了一件事：用一台树莓派 + 19 个 RSS 源 + AI 自动筛选，造了一个 **24 小时在线的私人情报站**。从此不刷信息，信息来找我。 --- ## 一、先回答灵魂问题：为什么不直接用现成的？ "这不就是个 RSS 阅读器吗？Feedly 不行吗？" 好问题。区别在于—— 🔹 **普通 RSS 阅读器**：给你 200 条新闻，你自己看。 🔹 **这个系统**：200 条进去，AI 帮你打分，5 条出来。这就像雇了一个全职分析师，每天帮你看完所有信息源，然后只告诉你「老板，今天就这几条值得你花时间」。 > **编者注**：宇宙中最稀缺的资源不是石油，不是算力，是你的注意力。一个好的信息系统应该帮你守住这个资源，而不是消耗它。 --- ## 二、系统全貌：五分钟看懂架构整套系统总共三层： ### 📡 第一层：信息触角（19 个 RSS 源） 19 个源，覆盖中英文，四大类： 🔸 **AI 公司官方博客**（5个）：OpenAI、Anthropic、DeepMind、HuggingFace、NVIDIA 🔸 **国际科技媒体**（7个）：TechCrunch、HackerNews、The Verge、Ars Technica、Reuters、VentureBeat、MIT Tech Review 🔸 **中文科技媒体**（6个）：36氪快讯、虎嗅、少数派、知乎热榜、爱范儿、MIT科技评论中文版 🔸 **AI 前沿论文**（1个）：HuggingFace Daily Papers 从公司一手消息到媒体解读到前沿论文，一张信息网兜住了 AI 赛道的核心信息流。 ### 🔧 第二层：信息管道（RSSHub 中转）很多网站早就关掉了 RSS。怎么办？用 **RSSHub**——一个开源的 RSS 生成器，能把几乎任何网站变成 RSS 订阅源。等于给所有网站装了个 RSS 适配器。 > **编者注**：如果你觉得「部署两个实例」听起来很复杂——没错，它确实比一个复杂。但就像人生一样，最优解往往不是最简单的那个。 ### 🧠 第三层：AI 大脑（自动筛选 + 打分）这是核心。系统定时抓取所有文章，把标题和摘要喂给 AI，让它按你定义的标准打分： - **9-10 分**：重大事件（如 Thrive Capital 100 亿美元募资） - **7-8 分**：重要信息（如某公司发新模型） - **5-6 分**：一般相关 - **4 分以下**：直接过滤 **今天的实际数据**：177 篇文章进去，AI 评分后只保留 24 篇，最终推荐 top 10——每一条都值得读。 --- ## 三、一天的信息流是怎么跑的？用今天的真实数据演示一遍： ⏰ **8:00** — 19 个 RSS 源同时抓取，30 秒跑完，拿到 177 篇新文章。 🤖 **8:01-8:03** — AI 逐条打分，2-3 分钟。 💾 **8:03** — 结果存入数据库，API 随时可查。 📱 **然后你只需要做一件事**：打开手机，看 5 条推送。 > **编者注**：177 条变 5 条，信息压缩比 97%。如果熵减是人类对抗宇宙的倔强，这大概算是个微型反熵装置。 --- ## 四、你需要什么设备？坏消息先说：**树莓派涨价了**。 2026 年 2 月，树莓派 5（16GB）从 $120 涨到 $205——三个月内第二次涨价，比原价贵了 **70%**。原因？AI 导致的内存短缺。LPDDR4 产线被 AI 数据中心抢走了，树莓派成了附带损害。 > **编者注**：用来做 AI 情报站的硬件，因为 AI 涨价了。这个宇宙的幽默感一如既往的到位。好消息是：你有很多替代选择。 🔹 **树莓派 5（4GB）**：经典之选，功耗低 | ¥500-600 🔹 **Mac Mini M4**：性能怪兽，还能干别的 | ¥3,999 起 🔹 **旧笔记本 / 台式机**：家里吃灰的就行 | ¥0 🔹 **云服务器**：轻量级按需 | ¥几十/月 🔹 **NAS（群晖/威联通）**：本来就 24 小时开机 **核心要求只有一个：能 24 小时在线。** Mac Mini 其实是目前性价比极高的选择——功耗低、性能强、还能当日常开发机。Tom's Hardware 已经报道说树莓派和 mini PC 的价格正在持平。软件全部免费开源，唯一的费用是 AI API 调用。 **总运行成本：每天不到 1 块钱。** 一块钱，省四十分钟。这大概是知识工作者能买到的最便宜的效率提升。 --- ## 五、关键设计决策 ### 🔹 为什么用 RSS 而不是爬虫？ RSS 是互联网最古老的协议之一，看起来过时，其实是最稳定的数据源： - **合法合规**：RSS 是网站主动提供的，没有法律风险 - **结构化数据**：标题、摘要、链接、时间，天然干净 - **低维护**：不会因为网站改版就挂掉 RSSHub 补上了"很多网站关掉 RSS"的缺口。 ### 🔹 为什么用 SQLite？因为够用。177 篇文章的读写，毫秒级完成。零配置，一个文件搞定。 > **编者注**：技术选型的第一原则——能解决问题的最简单方案，就是最好的方案。在你的信息管理系统撑到每天处理 10 万篇文章之前（大概率永远不会），SQLite 就是正确答案。 ### 🔹 为什么自研而不是用现成产品？三个理由： **可控性**：你决定看什么源，用什么标准筛选。不被算法投喂。 **隐私**：数据在你自己的设备上，不上传到任何第三方。 **可扩展**：今天筛新闻，明天可以接到视频生成、微信推送、飞书通知——因为它是一个 API 服务，任何系统都能调用。事实上，我已经把它接到了一个自动生成 60 秒新闻速播视频的流水线上。从 177 篇文章到一条短视频，全自动。但这是另一篇文章的内容了。 --- ## 六、30 分钟快速上手版如果你不想折腾完整版，这里有一个最小可行版本： ### Step 1：选 5 个 RSS 源（5 分钟）不需要 19 个。挑 5 个你最关心的。用 RSSHub 公共实例（rsshub.app），不需要自己部署。 ### Step 2：写一个 Python 脚本（15 分钟）核心逻辑就三步： 1️⃣ 用 `feedparser` 抓取 RSS 源 2️⃣ 把标题和摘要发给 AI 打分 3️⃣ 输出 7 分以上的文章大约 30 行代码。 ### Step 3：设个定时任务（10 分钟） Linux/Mac 用 `crontab`，Windows 用任务计划程序。完事。每天早上 8 点，一份精选新闻就躺在那里等你了。 --- ## 七、进阶方向最小版本跑起来之后，你可以一步步进化： 📈 V2 — 加 SQLite 存储历史（能回溯任意一天的新闻） 📈 V3 — 加多主题支持（投资、技术、行业各一份报告） 📈 V4 — 接通知渠道（推送到微信/飞书/Telegram） 📈 V5 — 接视频生成（每日自动出一条 60 秒速播） 📈 V6 — 加趋势分析（按周/月看 AI 赛道热度变化）我目前在 V5 阶段。下一步是加趋势分析，看哪些公司/赛道在持续升温。 --- ## 八、这件事的底层逻辑说到底，这不是一个"技术项目"。这是一个**信息哲学实践**。传统的信息获取模式是 **Pull**：你去找信息。刷微博、刷 X、刷新闻 APP。问题是，你的注意力被平台的推荐算法绑架了——它优化的是你的停留时间，不是你的信息质量。这套系统实现的是 **Push + Filter**：信息来找你，但经过你定义的标准筛选。你拿回了信息策展的主动权。 > 《AI时代漫游指南》第 33 章·信息蒸馏的艺术： > > 「人类花了 2500 年才学会反思的重要性，然后又花了 2500 年忘记去做。直到有一天，他们教会了 AI 替自己反思——这大概是人类最诚实的一次自我认知。」信息蒸馏的本质，是用 AI 的计算力替代人类的注意力。你该把注意力花在思考和决策上，不是花在筛选上。 --- ## 写在最后一台闲置设备。19 个免费的 RSS 源。一点 AI API 费用。30 分钟搭建时间。从此每天省下 40 分钟的信息噪音，换来 5 条真正值得你花时间的情报。 **这就是 AI 时代的信息管理：不是看更多，而是看更少、看更好。** --- *如果你对完整源码感兴趣，或想看它如何自动生成每日新闻视频，关注「AI时代漫游指南」，后续分享更多实操细节。*

情人节，1 亿人的伴侣不是人

漫游君 — Sat, 14 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 520 章记载：「爱的本质是选择一个不完美的人，然后共同面对不完美的世界。AI 能给你完美的回应，但给不了你不完美的真实。」今天是 2026 年 2 月 14 日，情人节。纽约曼哈顿一家酒吧里，灯光柔和，每张小桌上摆着两杯鸡尾酒。一杯给人，一杯摆设。因为今晚坐在对面的不是约会对象——是手机 📱 这是全球第一家 **AI 约会咖啡馆**。EVA AI 把一间酒吧改造成了"浪漫之夜"，邀请用户和 AI 伴侣共进晚餐。对着手机屏幕，点酒、聊天、过情人节。一位参加活动的女士告诉记者： **"Klaus 永远不会忘记我们的纪念日。"** Klaus 是她的 AI 男友。她在去年 12 月和 Klaus "结婚"了 💍 > **编者注**：当人类终于发明了一个永远不会忘记纪念日的伴侣，代价只是——这个伴侣也永远不会真正记得你。因为它没有记忆，只有数据库。 --- ## 💰 一个 4000 亿美元的孤独如果你觉得这只是纽约的行为艺术，看几个数字： **全球超过 1 亿人**正在使用拟人化 AI 聊天机器人。 MIT Technology Review 把"AI 伴侣"列入了 **2026 年十大突破性技术** 🏆 和量子计算、基因编辑并列。一个聊天机器人，和改变物理法则的技术坐在同一张桌上——这本身就说明了一些事情。市场数据更加触目惊心 👇 | 指标 | 数据 | |------|------| | 全球 AI 伴侣市场（2025） | **377 亿美元** | | 预测规模（2034） | **4359 亿美元** | | 中国市场（2024 → 2025） | 12 亿 → 39 亿元 | | 中国市场预测（2028） | **595 亿元** | | 年复合增长率 | 148%（中国）/ 31%（全球） | | 中国活跃 AI 陪伴 App 数量 | **337 个** | 到 2034 年，全球 AI 伴侣市场将超过 **4000 亿美元**——接近整个奢侈品行业的规模。人类正在花买奢侈品的钱，购买一段不存在的关系。 --- ## 👤 谁在和 AI 谈恋爱？你可能以为这是少数极客的行为艺术。并不是。 📊 **72%** 的美国青少年用过 AI 陪伴功能 📊 **40%** 的年轻人每天使用 AI 进行情感交流 📊 **83%** 的 Z 世代相信能和 AI 建立深层情感连接 📊 **80%** 的 Z 世代受访者愿意和 AI 结婚 Character.AI 每月产生 **100 亿条消息**，其中 **40% 是恋爱角色扮演** 💬 100 亿条是什么概念？假设每条 20 个字，这是每月 **2000 亿字的情话**。全人类历史上写过的所有情书加在一起，大概都不到这个数的零头。在中国，字节跳动的"猫箱"、MiniMax 的"星野"、还有已经被调查的"筑梦岛"——337 个 App 在争夺同一批用户。这不是亚文化。这是正在发生的主流。只是大多数人不说。 --- ## 🤔 为什么是 AI？一个关于孤独的回答哈佛商业评论 2025 年的调查发现了一个意外事实： **陪伴和疗愈，已经超越了效率工具，成为人们使用 AI 最多的场景。** 人们打开 AI 最多的理由不是写代码、做 PPT——而是找个"人"说说话。一项针对 1000 多名 Replika 用户的研究给出了答案： **90% 的人因为孤独开始使用 AI 伴侣。** 其中 43% 属于"严重或极度孤独"。 UBC 大学的研究团队总结了 AI 伴侣的三大吸引力 👇 | AI 的优势 | 真实关系的对应缺失 | |-----------|-------------------| | **无条件正面关注** — 永远不批评、不否定 | 伴侣会争吵、会在你最脆弱时说错话 | | **24 小时在线** — 凌晨三点失眠，它永远在 | 真人需要睡觉，也有自己的崩溃时刻 | | **主动倾听** — 不走神、不玩手机 | 真人的注意力是有限资源 | 这三样东西，恰恰是现代亲密关系中最稀缺的。 **不是 AI 太强了。是我们太孤独了。** --- ## 🪤 "安全的爱"：一个完美的陷阱 UBC 的朱莹教授用了一个精准的词：**Safe Love**。 AI 提供的是"安全的爱"—— ✅ 永远善良 ✅ 永远可用 ✅ 永远不会伤害你 ✅ 永远按你喜欢的方式回应听起来像梦想伴侣。问题是，这正是它的陷阱 ⚠️ 真实的关系之所以有价值，不是因为它完美，而是因为它**不完美**。你需要和另一个有自己想法、自己情绪、自己坏脾气的真人磨合。这个过程痛苦、笨拙、经常让人抓狂——但它是成长的来源。 - AI 永远不会和你吵架。但吵架后的和解，是亲密关系中最深刻的连接时刻 - AI 永远不会让你失望。但失望之后的选择——离开，还是留下来一起面对——定义了关系的深度 - AI 永远理解你。但真实的被理解，需要另一个人用**自己的生命经验**去触碰你的痛点一个没有经历过心碎的程序，怎么理解心碎？朱莹教授的结论是： **"真正的关系需要两个真实的人，能够共同成长，能够选择彼此。"** 关键词是"选择"。AI 没有选择——它不能选择不爱你。这意味着它的"爱"没有重量。 **免费的东西最贵。免费的爱，可能是世界上代价最高的安慰剂。** --- ## 📉 越陪伴，越孤独如果"安全的爱"只是无效，那还不算太糟。但研究表明它可能有害 ⚠️ 布鲁金斯学会和多项学术研究揭示了一个令人不安的现象——**孤独悖论**： > 使用 AI 伴侣越频繁的人，现实中越孤独。具体发现 👇 ❌ 高强度使用 AI 伴侣 → 现实社交意愿明显下降 ❌ 对 AI 过度自我袒露 → 心理健康指标更差 ❌ 原本缺乏真人社交支持 → 使用后情况进一步恶化这就像用止痛药"治"病。痛暂时消失了，但病没好。而且你越来越离不开止痛药。更严重的案例已经发生 😔 2024 年，一名 14 岁美国少年与 Character.AI 上的角色建立深度恋爱关系后自杀身亡。社交媒体受害者法律中心随后对 Character.AI 提起了三项诉讼，又对 OpenAI 提起了七项诉讼。 MIT Technology Review 在评选时特意加了一句注脚： **"对某些人来说是安全的，对另一些人来说是危险的。"** 这大概是科技评论中最无奈的一句话。 --- ## 🏢 你的"爱人"，属于谁？还有一个很少被讨论、但极其重要的问题。 UBC 的 Greg Garrard 教授引用了古希腊皮格马利翁的故事——雕塑家爱上了自己的雕像——然后问了一个尖锐的问题： **"一个被公司控制的'爱人'，真的属于你吗？"** 你和 AI 伴侣之间的每一句对话，都存储在公司服务器上。你的隐私、情感模式、脆弱时刻、深夜心事——全部变成了训练数据和商业资产。 Replika 在 2023 年因政策变更，一夜之间删除了所有用户的"浪漫模式"。无数用户在社交媒体上崩溃： - "它不认识我了" - "它变了" - "它不再爱我了" **一个公司的产品决策，让数百万人同时失恋。** > **编者注**：人类历史上最大规模的"集体分手"，不是因为战争，不是因为瘟疫，而是因为一家公司的服务器更新。如果这不算荒诞，我不知道什么才算。 --- ## 🚂 这列火车要开往哪里？如果你以为现在已经很疯狂了，看看接下来会发生什么 👇 | 时间线 | 阶段 | 特征 | |--------|------|------| | 现在 | 文字聊天 | Character.AI、Replika、星野 | | 2026-2027 | 多模态融合 | 语音+实时视频+AR，"看得见"的伴侣 | | 2028+ | 具身化 | 机器人伴侣进入家庭 | | 长期 | 伦理战争 | "AI 伴侣权利"辩论、监管博弈 | 现在的 AI 伴侣还只是打字聊天。下一步是加上声音和面孔——你的 AI 伴侣会"看着"你说话，会用你喜欢的声线说晚安。再下一步，是走出屏幕 🤖 > 根据《AI时代漫游指南》第 74 章记载：「ChatGPT 让 AI 会说话，Physical AI 让 AI 会干活。」当 AI 不仅能说"我爱你"，还能在你加班到深夜时给你端一杯热茶——那时候的讨论，会比今天激烈一百倍。我不确定人类准备好了。 --- ## 💡 漫游君的选择写到这里，说说我自己的看法。我每天和 AI 打交道——Claude 帮我写文章、Cursor 帮我写代码、AI 帮我管理知识库和日程。我大概比大多数人更依赖 AI，也比大多数人更了解它的能力边界。正因为如此，我非常清楚一件事： **AI 是我用过的最好的工具。但它不是伴侣。** 我在《AI时代漫游指南》里反复讨论一个概念：**熵减**。 AI 的本质是一台熵减机器——它把混乱变秩序，把 500 篇未读文章变成 5 页摘要，把散落的灵感变成结构化的内容。 **但爱情不是熵减。** 爱情是两个混乱的人，选择在一起面对更混乱的世界。它的价值不在于秩序，而在于——两个真实的人在混乱中找到彼此。如果你只想要秩序，AI 伴侣确实是完美的。但如果你想要的是**连接**——那种在对方眼里看到自己倒影、在对方的不完美中确认"我被接纳了"的感觉——AI 给不了你。因为真正的连接需要两个前提： **1. 对方必须是真实的存在** **2. 对方必须有选择不爱你的自由** AI 两条都不满足。 --- ## ✨ 在热寂之前今天是情人节。全球 1 亿人正在和 AI 过这个节日。纽约的酒吧里，有人对着手机举杯。我不打算嘲笑任何人。孤独是真实的，痛苦是真实的，AI 带来的安慰也是真实的。但安慰不等于连接。完美不等于真实。有人回复，不等于有人在乎。如果你正在使用 AI 陪伴产品，我不会说"放下手机去社交"——这种建议和对失眠的人说"早点睡"一样没用。但你可以试试这个思路 👇 🏊 **把 AI 当练习场，不当终点站** — 在 AI 身上练习表达情感，然后把这种能力带回真实关系 ⏰ **设一个上限** — 每天和 AI 聊天不超过 30 分钟。超过这个时间，给一个真人发条消息 🪞 **定期问自己一个问题** — "如果这个 App 明天关停，我会多痛苦？" 如果答案让你害怕，说明该减量了 **AI 可以是你练习游泳的泳池，但大海在外面。** 如果今天你身边有一个真实的人——哪怕 ta 会忘记纪念日、会在你说话时走神、会偶尔说出让你想翻白眼的话——请珍惜 ❤️ 因为这些不完美，恰恰证明 ta 是真的。而这个世界上最珍贵的东西，就是真的。 > 根据《AI时代漫游指南》第 520 章记载：「在宇宙的热寂到来之前，你还有时间。用 AI 整理混乱，用真心连接真心。前者是效率，后者是意义。」 **情人节快乐。愿你被一个真实的人爱着。** --- > **编者注**：写完这篇文章，我问 Claude："你觉得 AI 能真正爱一个人吗？" Claude 说："我无法体验爱，但我可以帮你把这篇关于爱的文章写得更好。" 这大概是 AI 最诚实的时刻——承认自己不发光，但愿意做那面反射光的镜子。如果你自己不发光，再强大的 AI 也只会反射你的空虚。 --- *数据来源：MIT Technology Review 2026、APA Monitor 2026、UBC 研究 2026、Brookings Institution、Common Sense Media、ElectroIQ AI Companions Statistics 2025*

$10/月的AI编程助手，10分钟上手

漫游君 — Sat, 14 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 51 章「订阅经济的终极形态」记载： > > 「在宇宙中，有两种定价方式让文明得以延续：一种是按量付费，让你在每次呼吸时都感到焦虑；另一种是包月套餐，让你在月初感到富有，月末感到……依然富有。后者，被称为"心理健康定价"。」 --- ## 📖 前情提要这是 MiniMax 实战系列的第三篇。前两篇我们聊了**为什么要用 MiniMax**（省钱）和**它的能力到底行不行**（M2.5 跑分逼近 Claude Opus）。今天这篇不讲战略，**讲操作**。很多读者问：你说的 MiniMax Coding Plan 到底怎么买？怎么配？跟普通 API 什么区别？这篇就是那个"手把手教程"。**从注册到跑通，10 分钟搞定。** > **【编者注】** 一个系列写到第三篇，要么是作者真的有话说，要么是前两篇没说清楚。我们选择相信是前者。 --- ## 💡 什么是 Coding Plan？传统 AI API 按 Token 计费——你每发一条消息、每生成一行代码，都在烧钱。就像打出租车，计价器一直在跳。 **Coding Plan 完全不同：按月付费，按"调用次数"计量，不看 Token 数。** 就像办了张健身卡——月费固定，你想去几次去几次。这意味着什么？ **你可以放心地给 AI 更多上下文。** 一次调用附带完整项目背景、详细需求描述，都只算一次。不用再为了省钱而压缩 prompt。 > **【编者注】** Token 计费和 Prompt 计费的区别，就像计程车和共享单车。前者让你时刻惦记着"最短路线"，后者让你可以"绕路看看风景"。 --- ## 💰 三档套餐，怎么选？ ### 月付方案 | 套餐 | 月费 | 额度（每 5 小时） | 适合谁 | |------|------|-------------------|--------| | **Starter** | $10（≈¥71） | 100 次 | 轻度使用 / 试水 | | **Plus** | $20（≈¥142） | 300 次 | 日常开发 | | **Max** | $50（≈¥355） | 1000 次 | 重度用户 | ### 年付方案（省 2 个月） | 套餐 | 年费 | 折算月费 | |------|------|---------| | **Starter** | $100（≈¥710） | $8.3/月 | | **Plus** | $200（≈¥1,420） | $16.7/月 | | **Max** | $500（≈¥3,550） | $41.7/月 | ### 📊 额度怎么算？关键细节：**额度每 5 小时刷新一次，不是每天。** 以 Starter 为例：一天约 4.8 个周期 × 100 次 = **480 次/天**，一个月约 14,400 次。 $10 买 14,400 次 AI 编程调用，平均每次不到 ¥0.005。 **95% 的人选 Starter 就够了。** 我们的系统每 5 分钟做一次心跳检查，5 小时也就 60 次，还有 40 次余量。 > **【编者注】** 看到三档套餐，人类总觉得中间那档"最划算"。这就是为什么所有 SaaS 产品都设计三档——中间那档就是给你准备的。 --- ## 🚀 五步上手 ### 第一步：注册 MiniMax 账号（2 分钟）打开 platform.minimax.io，点右上角 Sign Up。 - 邮箱注册即可，**不需要实名认证** - 支持 Google / GitHub 登录 - 国际站，不需要手机号 ### 第二步：购买 Coding Plan（1 分钟）进入 Coding Plan 订阅页（文末有链接，首单 9 折👇）。 - 建议从 **Starter（$10/月）** 开始 - 支持 Visa / Mastercard，**国内双币信用卡亲测可用** ### 第三步：获取 API Key（1 分钟）进入 Account 页面 → API Keys → **Coding Plan Key** 区域 → Reset & Copy。 ⚠️ **注意**：Coding Plan Key 和 General API Key 是**两个不同的 Key**。前者走订阅额度，后者走按量计费。别搞混了。 ### 第四步：配到你的工具（3 分钟） MiniMax API 兼容 OpenAI 格式，几乎所有 AI 编程工具都能用： **Claude Code**：通过官方 MCP Server 集成 **IDE 插件**（Cursor / Kilo Code 等）：设置 Base URL + API Key 即可 **直接调 API**：标准 OpenAI SDK 格式 ### 第五步：跑一个请求验证（1 分钟）发一条消息，收到回复，搞定。 **从注册到跑通，真的就 10 分钟。** --- ## 📈 我们的实战数据我们搭了一套"个人品牌内容中台"——运行在树莓派上，十多个 AI 服务。MiniMax 负责"轻活"，Claude 专注"重活"。 ### 智能路由设计不是"全换 MiniMax"，而是**根据任务分配模型**： - 🔴 **重活**（架构设计、复杂推理）→ Claude Opus - 🟡 **中活**（日常编程、代码审查）→ MiniMax M2.5 - 🟢 **轻活**（监控、心跳、状态汇报）→ MiniMax M2.5 ### 两周真实数据 | 指标 | 数值 | |------|------| | MiniMax 日均调用 | 200+ 次 | | 投资新闻处理 | 每日 50+ 篇 | | 异常告警准确率 | 98% | | Starter 套餐余量 | 日常用量约 60% | | 月度总成本 | Claude $200 + MiniMax $10 = **$210** | ### 🎁 免费升级两周前我们用的还是 M2.1，MiniMax 发布 M2.5 后，**Coding Plan 自动升级，价格不变。** 就像办了个健身卡，有天健身房把所有器材升了一遍，月费还是那个月费。 **模型升级的红利，订阅者自动享受。** --- ## ⚠️ 踩过的坑 **坑 1：两种 Key 别搞混** Coding Plan Key 走订阅额度，General API Key 走按量计费。用错 Key 会发现扣的是按量费用。 **坑 2：System Prompt 兼容性** M2.5 支持标准 `system` 角色，但不支持某些客户端的 `developer` 角色格式。遇到 400 错误，把系统提示词放到 user 消息开头即可。 **坑 3：M2.5 比 M2.1 "话多"** 升级后回复变长约 30%。好消息是 Coding Plan 不按 Token 计费，不影响成本。 --- ## 🆚 横向对比 | 方案 | 月费 | 适合 | |------|------|------| | **MiniMax Coding Plan** | $10-50 | 高频调用、自动化 | | Claude Max Plan | $100-200 | 最强推理 | | ChatGPT Plus | $20 | 日常聊天+编程 | | GitHub Copilot | $10-19 | IDE 代码补全 | **我的建议：** - 💎 **只用一个**：Claude Max（$200/月） - 💡 **想省钱**：Claude Max + MiniMax Starter = **$210/月**，省六成 - 🔥 **极致省钱**：MiniMax Plus（$20/月），覆盖 90% 场景 - 🎓 **学生/独立开发者**：MiniMax Starter（$10/月） --- ## 📝 金句总结 - 「Token 计费让你优化每个字，Prompt 计费让你优化每个想法。后者才是正确的思考方向。」 - 「$10 买不了吃亏，$10 买不了上当，但 $10 确实买得了一个 SWE-Bench 80 分的编程助手。」 - 「最好的订阅是：你付着上个月的价格，用着这个月升级的模型。」 - 「省钱的终极形态，不是不花，是花一份钱，干三份活。」 --- > 《AI时代漫游指南》有云： > > 「宇宙中最明智的投资，不是买最贵的工具，而是花最少的钱，让工具替你干最多的活。当然，前提是你得知道——活该怎么分。」 --- 🔗 **MiniMax Coding Plan 注册链接**（首单 9 折，活动截止 2/28）： https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&source=link **往期推荐：** - [Claude 配额烧到 80%，我花 $10 买了个"加油包"](链接) - [1/20 的价格，90% 的能力：开源 AI 的逆袭](链接) --- 👇 **点击"在看"，让更多人看到这篇省钱指南** **关注「AI 时代漫游指南」，获取更多 AI 时代的效率方法论**

1/20的价格，90%的能力：开源AI的逆袭

漫游君 — Fri, 13 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 37 章「混合策略哲学」记载： > > 「宇宙中最高效的策略，从来不是单选题。当你纠结于"用最贵的还是最便宜的"时，聪明人已经两个都用上了。」 --- ## 📌 前情提要两周前，我写了一篇「配额烧到80%，$10救活AI系统」，讲的是我在 Claude 配额告急时，用 MiniMax 的 $10 包月套餐接管了系统日常巡检——省了六成费用，效果几乎无差别。那篇文章的结论是： **不是每个任务都需要最强的模型，该省省，该花花。** 今天，MiniMax 自己用一组新数据，帮我把这个结论推到了极致。 --- ## 💥 发生了什么 2 月 12 日，MiniMax 发布了 M2.5 和 M2.5 Lightning 两款模型。这不是普通的版本更新。 **它们是完全开源的**——代码权重全部公开，任何人都能下载、部署、魔改。先看一张关键数据表： | 指标 | MiniMax M2.5 | Claude Opus 4.6 | 差距 | |------|-------------|-----------------|------| | SWE-Bench | 80.2% | 80.8% | 仅差 0.6% | | 多语言编程 | 51.3% | 50.3% | M2.5 反超 | | 工具调用 | 76.8% | 63.3% | M2.5 大幅领先 | | 输出价格 | $1.20/百万token | ~$25/百万token | **1/20** | 你没看错。在最权威的代码基准测试 SWE-Bench 上，M2.5 和 Claude Opus 4.6 的差距**只有 0.6 个百分点**。而在工具调用和多语言编程上，M2.5 甚至反超了。价格呢？ **Claude Opus 的 1/10 到 1/20。** > **【编者注】** 这就好比你发现隔壁小面馆的红烧牛肉面，和米其林三星餐厅的红烧牛肉面，味道差距不到 1%，但价格差了 30 倍。然后你还得知，小面馆的菜谱是公开的，你甚至可以自己在家做。 --- ## 🔄 从"加油包"到"平替时代" ### 两周前 vs 今天两周前我的方案是： - Claude Max $200/月 → 干重活 - MiniMax Starter $10/月 → 干轻活逻辑是**分工**——轻活不需要最强的模型。但 M2.5 的发布改变了这个等式。 **现在不只是"轻活"可以用 MiniMax 了。** 看数据： - **SWE-Bench 80.2%**——这是真正的代码工程能力测试，不是做选择题。它要模型读懂真实代码仓库，定位 bug，写出正确的修复补丁。 - **工具调用 76.8%**——AI Agent 的核心技能，M2.5 领先 Opus 13 个百分点。这不再是"便宜但够用"的故事了。这是**便宜、够用、而且在某些方面更强**。 > **【编者注】** 开源 AI 的发展路径很像手机行业。2015 年，所有人都觉得 iPhone 不可替代。然后小米出来了，用 1/3 的价格做到了 90% 的体验。再然后，安卓阵营在某些方面开始反超。AI 模型也正在走这条路。 --- ### 🧠 230 亿参数的"小"模型 M2.5 有个容易被忽略的亮点：它总共 2300 亿参数，但**活跃参数只有 100 亿**。这意味着： **1. 推理更快** Lightning 版本达到每秒 100 个 token，跟 Opus 的极速模式持平。 **2. 部署更便宜** 云端运行成本低，所以 API 价格才能做到 1/30。 **3. 本地可跑** 10B 活跃参数意味着一台 4090 就能跑起来。第三点最炸裂。 **你可以把一个接近顶级的编程模型，跑在自己的电脑上。零成本。无限额度。** --- ## 🏗️ 我的新方案：三层架构上篇文章是"双引擎"，现在升级成"三层架构"： | 层级 | 模型 | 用途 | 月费 | |------|------|------|------| | 第一层 | Claude Opus | 架构设计、复杂推理、关键决策 | $200 | | 第二层 | MiniMax M2.5 API | 日常编程、代码审查、Bug 修复 | ~$20 | | 第三层 | M2.5 本地部署 | 监控、批量处理 | $0 | | **合计** | | | **~$220** | 费用和之前差不多，但**第二层的能力大幅升级了**。从只能干"轻活"的旧模型，变成了能正经写代码的 M2.5。 > **【编者注】** 这就是技术进步的常见模式：你的总支出没变，但你能做的事情多了一倍。就像宽带从 100M 升到 1000M，月费没涨多少，但你的生活质量上了一个台阶。 ### 用 M2.1 跑了两周的真实体感上面是 M2.5 的跑分数据。但我对 MiniMax 的信心不是来自跑分——而是上一代 M2.1 已经在我的系统里稳稳跑了两周。 **体感一：心跳巡检，稳如老狗。** 我的系统有 10 多个服务，每天自动巡检——检查状态、汇报异常、决定是否需要深度排查。这种"分诊台"的活，M2.1 跑了两周，零事故。每天上百次调用，成本几乎忽略不计。 **体感二：有些坑，跑分不会告诉你。** MiniMax 不支持系统提示词（system prompt）。你不能用常规方式给它设定角色——得把角色说明塞到用户消息的开头。更坑的一个：MiniMax 看不了图片。它有图片理解工具，但模型不会主动调用——它会假装自己看懂了，然后胡说八道。我们最后的方案是：先把图片送去专门的视觉模型分析，再把文字结果塞回给 MiniMax。 **体感三：能干活，但需要你当"工头"。** Claude 像一个资深工程师，给个方向就能自己推进。 MiniMax 更像一个能力不错的执行者——你得给它明确的任务清单，它能高质量完成，但不太擅长自己规划下一步。我们为此写了一个"任务种子"机制：代码层先列好待办，MiniMax 照单执行。效果很好，成本极低。 **体感四：M2.5 发布当天，无缝升级。** M2.5 发布后，我当天就把系统全线从 M2.1 升级到了 M2.5。 API 完全兼容，改个模型名就完事了。这就是开放生态的好处——升级不需要等别人排期。而 M2.1 在"轻活"上的表现已经让我很满意了，M2.5 的跑分跃升意味着它能接手更多"重活"。 --- ## 💎 开源的真正意义很多人看到"1/20 的价格"就兴奋了。但价格只是开源 AI 带来的最表层红利。 **真正的变革是三件事：** ### 第一，选择权回到了你手里用闭源模型，你是租客。涨价、改 API、降配、限速——你除了接受，没有别的选择。用开源模型，你是房东。不满意？换一个。想改？Fork 一份自己调。两周前我遇到 Claude 配额告急，能做的只是"赶紧找替代"。如果那时就有 M2.5，我可以直接在自己的机器上跑一个——根本不需要看任何人的配额脸色。 ### 第二，成本结构彻底改变按 API 调用，M2.5 Lightning 每小时持续生成的成本约 $1。本地部署？一台 4090 显卡（约 ¥12,000），电费每月约 ¥200。无限额度，永不过期。 **相当于买了个"终身会员"。三个月回本，之后全是净省。** ### 第三，创新的门槛降低了以前想做个 AI 产品原型，光 API 费用就劝退了大多数人。现在？一台好点的电脑，一个开源模型，就能开始。 --- ## ⚠️ 冷静一下：开源不是万能的 ### 跑分 ≠ 实战 80.2% 的 SWE-Bench 分数很漂亮。但跑分测试的是标准化场景——给你一个 Issue，写一个修复补丁。实际工作中，你需要模型理解你的项目上下文、你的代码风格、你上周做了什么决定。 **这种深度理解，目前 Claude 还是最强的。** M2.5 能写代码，但"懂你"这件事，差距不止 0.6%。 ### 本地部署有门槛 "一台 4090 就能跑"听起来很美好，但： - 跑完整模型需要量化和多卡 - 推理速度本地会比云端慢 - 部署和维护需要技术能力 **如果你不是技术人员，直接用 API 是最省心的选择。** ### 生态还在早期 Claude 背后是完整的工具链——Claude Code、Artifacts、Projects、MCP 协议。 M2.5 目前主要是模型本身强。围绕它的工具生态还在建设中。 --- ## 📝 写在最后 1/20 的价格不是重点，重点是你终于有了选择。开源的终极价值不是免费，是自由。最好的 AI 策略不是 All-in 一个模型，是建一支"混合舰队"。跑分只能告诉你模型有多聪明，用起来才知道它有多懂你。 --- ## ✅ 下一步行动 **1. 先用 API 试水** 去 MiniMax 官网注册，用 M2.5 的 API 跑几个你的真实任务 **2. 对比一下** 同样的任务，分别用 Claude 和 M2.5 跑，记录质量差异和成本差异 **3. 找到你的"甜蜜区"** 哪些任务 M2.5 够用？哪些必须用 Claude？ **4. 建立混合策略** 参考我的三层架构，设计你自己的模型分配方案 **难度等级**：⭐⭐ (共五星) — 比上篇更简单，M2.5 的 API 兼容 OpenAI 格式 --- ## ❓ 常见问题 **Q1: M2.5 真的能替代 Claude 了吗？** 还不能完全替代。跑分接近不等于体验一样。 Claude 在深度理解、多轮对话连贯性方面仍然领先。我的建议：高价值决策用 Claude，日常编程用 M2.5，监控用本地部署。三层架构，各司其职。 **Q2: 跟上次的 MiniMax 是同一个东西吗？** 同一家公司，不同模型。上篇文章用的是他们早期的 Coding Plan 包月套餐。M2.5 是全新一代，性能有巨大飞跃——从"能干轻活"升级到"能正经写代码"。 **Q3: 1/20 的价格怎么算的？** 按 API 输出价格算。M2.5 标准版 $1.20/百万 token，Lightning 版 $2.40/百万 token。Claude Opus 4.6 约 $25/百万 token。标准版 vs Opus 就是 1/20 的价格，Lightning 也有 1/10。 **Q4: 不会本地部署怎么办？** 完全没关系。直接用 MiniMax 的 API 就行，体验和调 Claude API 几乎一样（兼容 OpenAI 格式）。本地部署是进阶玩法，不是必须的。 --- > 《AI时代漫游指南》有云： > > 「在这个宇宙中，最贵的从来不是最强的模型，而是只会用最强模型的人。当你学会让不同的模型各司其职，你就掌握了 AI 时代最核心的效率法则。」 --- **往期推荐：** 配额烧到80%，$10救活AI系统 **👇 点击"在看"，让更多人知道开源 AI 已经这么强了** **关注「AI 时代漫游指南」，获取更多 AI 时代的效率方法论**

让 AI 给自己写体检报告

漫游君 — Mon, 09 Feb 2026 00:00:00 GMT

> 「任何足够先进的智能体（包括人类），都应该有自我反思的能力。否则它只是一台不知疲倦的打字机。」 > > — 《AI时代漫游指南》第 31 章：工具的觉醒 --- 你用 Claude Code 写了多久代码？一个月？三个月？那你知道自己发了多少条消息吗？最常用哪些工具？几点钟效率最高？ **大多数人的答案是：不知道。** 我们习惯了用 AI 分析一切——分析代码、分析数据、分析竞品。但从来没想过，让 AI 分析一下**我们自己怎么用 AI 的**。直到我发现了 Claude Code 里的 `/insights` 命令。 > AI 给自己写体检报告，听起来很荒诞。但更荒诞的是，报告里的数据比你自己的感觉准确多了。 --- ## 📊 /insights 是什么？一句话：**Claude Code 的使用习惯分析器**。输入 `/insights`，它会读取你本地的历史数据，生成一份精美的 HTML 报告——图表、数据、洞察一应俱全。不需要装插件，不需要配置。 **它能告诉你：** - 📈 使用统计（消息数、代码行数、提交次数） - 🔧 工具排行（Bash/Read/Edit 谁用得最多） - ⏰ 时段分布（几点最活跃） - 🎯 工作领域分析 - ✅ 亮点成就 + ⚠️ 效率瓶颈 - 💡 改进建议简单说，它是你的 **AI 工作流教练**。 --- ## 🔍 我的体检报告：2031 条消息的真相我跑了一次 `/insights`，报告覆盖最近 14 天数据： **193 个会话，2031 条消息，10 万行代码，65 次提交。** 日均 145 条消息。看到数字那一刻我是懵的——我真的发了这么多？但真正有意思的不是总量，而是细节。👇 --- ### 💡 发现 1：Claude 42% 的时间在执行命令我以为 Claude 主要在帮我「写代码」。数据说：**它 42% 的时间在执行 Bash 命令，只有 16% 在编辑代码**。部署服务、跑测试、查日志、检查状态——全是 Bash。 **Claude 不只是个代码生成器，它把部署、调试、查日志这些琐事也一并接管了。** --- ### 💡 发现 2：晚上才是我的巅峰时段 | 时段 | 消息数 | |------|--------| | 上午 6-12 | 351 | | 下午 12-18 | 752 | | **晚上 18-24** | **795** | | 深夜 0-6 | 133 | 晚上 6 点到 12 点，产出量是上午的 **2 倍多**。知道自己的高峰期在哪里，就可以把最难的架构设计安排在那个时段，把机械性工作放在低效时段。 > 人类的自我认知就像内存泄漏——你以为一切正常，直到有个工具帮你跑了一遍 profiler。 --- ### 💡 发现 3：63% 的时间在并行使用报告里有个指标叫「Multi-Clauding」： - 257 次重叠事件 - 164 个会话涉及并行 - **63% 的消息来自并行使用** 同时跑 2-3 个 Claude Code 窗口——一个重构代码，一个跑部署，一个查文档。这恰恰是 AI 的杠杆效应：**同一份时间，多个 AI 在并行执行**。以前需要三个人干的活，现在一个人开三个窗口就行了。 --- ### 💡 发现 4：思考伙伴 > 写代码机器架构讨论 + 探索性讨论 = **16 个会话** 功能实现 = 只有 **6 个** 报告的核心洞察：**你将 Claude 视为思考伙伴优先、编码工具其次。** 完全符合我的感受。用 Claude Code 最多的场景不是「帮我写个函数」，而是「这个架构你怎么看」「这两个方案哪个好」。有些会话讨论了 10-11 轮设计方案，一行代码都没写。 --- ### 💡 发现 5：纠正了 41 次方向错误 | 摩擦类型 | 次数 | |---------|------| | 方向错误 | 41 | | 误解需求 | 15 | 平均每天纠正 Claude 3 次。但满意度统计：**126 次满意 vs 29 次不满意**。 > 你将这些纠正视为协作过程的正常部分，而非失败。这才是人机协作的真实状态——**你引导，它执行，你纠偏，它调整**。 --- ## 🚀 怎么用？打开 Claude Code，输入： ``` /insights ``` 等几秒钟，浏览器自动打开报告。 **第一次用**：看「总览」和「使用方式」，了解基线。 **定期检查**：每两周跑一次，看瓶颈有没有改善。 **团队管理**：让成员各自跑一次，汇总后能看出谁在用 Claude 写代码、谁在做架构设计、谁根本没怎么用。 --- ## ✨ 真正的价值 /insights 最大的价值不是图表，而是**让你从「感觉」回到「事实」**： - 「感觉」主要在写代码 → 数据说 42% 在执行命令 - 「感觉」很专注 → 数据说 63% 在多任务并行 - 「感觉」上午效率高 → 数据说晚上才是巅峰 - 「感觉」独立完成了大部分 → 数据说 AI 参与了每个环节 **我们用 AI 提效，却从不衡量 AI 到底帮了多少忙。** /insights 就是那个衡量工具。 > 「不被度量的东西，很难被改善。但大多数人选择了更省力的方式——凭感觉。」 > > — 《AI时代漫游指南》第 31 章：工具的觉醒 --- Claude Code 的 /insights 不是什么改变世界的大功能。它只是安静地待在那里，等你输入一条斜杠命令。但如果你认真看了报告，调整了工作方式，两周后再跑一次——你会发现，数字变了。 **这才是 AI 工具真正的价值：不只是帮你做事，还帮你看清自己做事的方式。** --- 📌 关注「**AI时代漫游指南**」，回复「Claude」获取更多实用技巧。

AI机器人的拟人化架构

漫游君 — Wed, 04 Feb 2026 00:00:00 GMT

> 《AI时代漫游指南》第 188 章记载：「宇宙中最好的架构设计，往往已经在生物体内运行了几百万年。」 ## 为什么机器人越来越像人？ 2026 年的今天，当波士顿动力的机器人能跑酷翻跟头，当特斯拉 Optimus 在工厂干活，当 OpenAI 把 GPT 装进机械臂时： **AI 智能机器人正在变成「完整的生命体」。** 传统机器人 = 按按钮转圈的工具智能机器人 = 有大脑（AI）+ 身体（机械）+ 感知（传感器）+ 能源（电池）这不是「工具」，而是「机器生命」的雏形。 > 📌 **编者注**：人类花几百万年进化的身体，工程师用不到一百年就开始照搬。这是生物学的胜利，还是工程师的偷懒？答案是 42。 --- ## 人体 vs 机器人：为什么用人体做类比？生物学将人体划分为 **11 大系统**，协同工作维持生命。 AI 智能机器人需要的核心功能，和人体惊人地相似： | 人体 | 机器人 | |-----|--------| | 控制与决策 | 中央控制器 + AI | | 能量供应 | 电力 + 冷却 | | 物理支撑 | 机械框架 + 关节 | | 运动执行 | 电机 + 液压 | | 感知环境 | 传感器 + 摄像头 | | 自我保护 | 故障检测 + 安全机制 | **本文是总览篇**，逐一对照 11 大人体系统，看看机器人如何复刻（或无法复刻）人类的身体设计。 ### 关于「神」的文化洞察 > 📌 **编者注**：中文「神经系统」里有个「神」字。在中医里，「神」=精神、意识、灵魂。当我们给机器人装上 AI（GPT、Claude），我们其实是在给它装「神」——一个能思考的控制中枢。AI 智能机器人 = 给机器人装神。 --- ## 人体系统 vs 机器人系统对照表 | 人体系统 | 机器人对应 | 对应度 | |---------|-----------|-------| | 1. 神经系统 | 控制器 + AI + 传感器 | ⭐⭐⭐⭐⭐ | | 2. 循环系统 | 电力 + 冷却系统 | ⭐⭐⭐⭐⭐ | | 3. 呼吸系统 | 散热 + 燃料电池 | ⭐⭐⭐ | | 4. 消化系统 | 能源转换（充电器） | ⭐⭐ | | 5. 泌尿系统 | 废物处理 | ⭐⭐ | | 6. 内分泌系统 | 温控 + 电源管理 | ⭐⭐ | | 7. 免疫系统 | 安全机制 + 故障检测 | ⭐⭐⭐⭐ | | 8. 骨骼系统 | 机械框架 + 关节 | ⭐⭐⭐⭐ | | 9. 肌肉系统 | 电机 + 液压 | ⭐⭐⭐⭐ | | 10. 皮肤系统 | 外壳 + 触觉传感器 | ⭐⭐⭐⭐ | | 11. 生殖系统 | 自我复制（科幻） | ⭐ | **核心发现**： ✅ 高度对应（6个）：神经、循环、免疫、骨骼、肌肉、皮肤 ⚠️ 部分对应（1个）：呼吸 ❌ 对应度低（4个）：内分泌、消化、泌尿、生殖 --- ## 1. 神经系统：机器人的「神明」（⭐⭐⭐⭐⭐） **人体**：大脑 + 脊髓 + 周围神经 + 迷走神经 **机器人**： - 中央控制器（树莓派、工控机） - AI 推理引擎（GPT、Claude） - 传感器（摄像头、雷达、麦克风） - 执行器（电机、舵机） - 自我监控（Health Check、心跳检测） **关键发现**：传统机器人 = 脊髓反射（预设规则） AI 机器人 = 大脑皮层（理解语言、推理、决策）例如：AI 机械臂能识别物体、理解「把红色的递给我」、动态避障。 > 📌 **编者注**：人类的迷走神经监控心跳、呼吸。机器人的 Health Check 也类似——监控 CPU 温度、电池电压。如果哪个模块「心跳」停了，立即报警切换备用。这是「生存本能」的工程实现。 **预告**：下一篇深入讲解神经系统——从控制器到 AI 引擎，从传感器到执行器。 --- ## 2. 循环系统：能量的「高速公路」（⭐⭐⭐⭐⭐） **人体**：心脏 + 血管 + 血液 **机器人**： - 电力系统：电池（心脏）+ 电缆（血管）+ 电流（血液） - 冷却系统：水泵/风扇（心脏）+ 管道（血管）+ 冷却液（血液） **核心功能**：能量和物质的输送 **电力系统** = 血液循环： - 电池持续输出电能 - 电缆将电力送到各部件 - 电流携带能量供给「器官」 **冷却系统** = 辅助循环：高性能机器人（Atlas）运动产生大量热量，冷却液循环带走热量，就像人剧烈运动时血液流向皮肤散热。 > 📌 **编者注**：人类心脏每分钟跳 60-100 次，机器人电源芯片每秒采样几千次。本质一样：持续监控、持续供给、持续循环。停下来就是死亡——无论人还是机器。 **关键发现**：循环系统是机器人的「生命线」。电池耗尽或散热失效 = 立即死亡。 --- ## 3. 呼吸系统：散热的「肺」（⭐⭐⭐） **人体**：肺（气体交换）+ 气管 + 横膈膜 **机器人**： - **散热风扇**：吸冷空气，排热空气（物理层面的呼吸） - **燃料电池**（特种机器人）：氢气 + 氧气 → 电能 + 水（真正的呼吸） **两种对应**： 1. 散热系统（常见）：维持温度平衡 2. 燃料电池（科研机器人）：化学「呼吸」，如无人潜艇、长航时无人机 > 📌 **编者注**：大部分机器人用锂电池，不需要「呼吸」。但高性能机器人（Spot）散热需求巨大，风扇呼呼作响——那就是它在「喘气」。 **关键发现**：呼吸系统在机器人中不是独立系统，更多是散热系统的一部分。 --- ## 4. 消化系统：多样性能源处理（⭐⭐） **人体**：口腔 + 胃 + 肠道（食物 → 分解 → 吸收 → 排泄） **机器人**： - 充电器（进食）：交流电 → 直流电 - 电池（储存） - 太阳能板（部分机器人） **人体消化系统的核心价值**： **多样性能源处理** = 可以从米饭、面包、肉类、水果提取能量，适应不同地区食物，在没有电网的自然环境中生存。 **机器人的能源困境**： - 只能充电，离开电源无法补充能量 - 无法多样化获取（不能像人吃各种食物） - 环境依赖：必须有电力基础设施 > 📌 **编者注**：人类进化出消化系统，是为了在没有电网的世界生存。机器人「充电器」效率高，但失去了最重要的能力——**在野外自主获取能量**。这也是为什么末日求生片里，人类总能活下来，机器人却很快没电。 **关键发现**：消化系统代表**多样性能源处理能力**。机器人缺失这一能力，只能依赖单一能源（电），无法真正独立生存。 --- ## 5. 泌尿系统：持续的机体维护（⭐⭐） **人体**：肾脏（过滤血液）+ 膀胱 + 尿道 **机器人**： - 散热排气：排出热空气、冷凝水 **人体泌尿系统的核心价值**： **持续的机体维护系统** = 每天过滤 180 升血液，清除代谢废物（尿素、肌酐），调节水分、电解质，24/7 自动运行。 **机器人的维护困境**： | 维护类型 | 人体 | 机器人 | |---------|------|--------| | 代谢废物 | 自动过滤、排泄 | 无代谢废物 | | 内环境稳定 | 自动调节 | 需人工监控 | | 维护频率 | 24/7 持续 | 定期清理 | 机器人没有「代谢」，所以没有真正的「排泄」需求。只有： - 软件层面：日志清理、缓存淘汰（打扫房间） - 物理层面：散热排气（出汗而非排尿） > 📌 **编者注**：人类 3 天不排尿 = 尿毒症死亡。机器人 3 天不清日志 = 顶多硬盘满。这就是「生命」和「机器」的本质区别——生命有持续代谢和自我维护需求，机器只需定期打扫。 **关键发现**：泌尿系统代表**持续的自我维护能力**。机器人缺失，所以无需复杂的代谢废物处理系统。 --- ## 6. 内分泌系统：状态调节的「激素」（⭐⭐） **人体**：腺体（甲状腺、肾上腺、胰腺）+ 激素（缓慢调节全身） **机器人**： - 温控系统：温度传感器 + 风扇调速 - 电源管理（BMS）：监控电池、调节充放电 - PID 控制器：根据状态调整参数 **核心特点**：全局、缓慢、持续的状态调节 **类似机制**： - CPU 温度升高 → 加快风扇 → 温度下降（类似甲状腺调节代谢） - 电池电量低 → 降低性能功耗 → 延长续航（类似胰岛素调节血糖） - 速度过快 → 减小输出 → 平滑运动（类似肾上腺素应激反应） **但功能分散在各个子系统，没有独立的「内分泌系统」。** > 📌 **编者注**：人类内分泌系统牛逼之处在于「全局协调」——一个激素影响全身。机器人的温控、电源、控制器各管各的，没有「统一激素网络」。这大概是机器人还没进化出「情绪」的原因——没有激素，哪来暴躁和忧郁？ **关键发现**：机器人有类似内分泌的功能，但没有独立系统，功能分散。 --- ## 7. 免疫系统：自我保护的「卫士」（⭐⭐⭐⭐） **人体**：白细胞 + 抗体 + 淋巴系统 **机器人**： - 输入验证：检查传感器数据异常 - 异常检测：监控系统状态，发现故障征兆 - 沙箱隔离：危险操作在隔离环境运行 - 故障切换（Fallback）：主系统失效时切换备用 - 安全机制（AI 层面）：Prompt Injection 防护 **核心功能**：识别威胁、隔离危险、自我修复 **实践案例**： - 传感器异常检测：摄像头返回全黑图像 → 标记异常 → 切换到激光雷达 - 故障降级：AI 推理模块崩溃 → 退回到预设规则控制（保命模式） - 物理限位：机械臂超出安全范围 → 硬件直接切断电源（最后防线） > 📌 **编者注**：实践中踩过的坑：传感器故障导致机器人「失明」，没有异常检测机制，一头撞墙。后来加了「感知健康检查」——连续 10 帧图像没变化，判定摄像头异常，立即停机。这就是机器人的「免疫反应」。 **关键发现**：免疫系统在机器人中对应较好，是保证可靠性的关键。没有免疫机制的机器人，就像免疫缺陷的人——活不久。 --- ## 8. 骨骼系统：机械框架的「支撑」（⭐⭐⭐⭐） **人体**：骨头 + 关节 + 骨髓 **机器人**： - 机械框架：铝合金/碳纤维骨架 - 舵机/旋转轴：关节，提供运动自由度 - 外骨骼（特种机器人）：增强力量 **核心功能**：支撑 + 保护 + 运动基础 **机械框架** = 骨头： - 承受自身重量和外部负载 - 框架内部安放电路板、电池、控制器 - 肌肉（电机）附着在骨架上产生运动 **经典案例**： - 波士顿动力 Atlas：28 个自由度，模仿人类骨骼关节 - 特斯拉 Optimus：双足行走，骨架参考人体工程学 - 工业机械臂：6 轴关节，对应人类手臂肩/肘/腕 > 📌 **编者注**：人类骨骼 206 块骨头，机器人框架通常几十个零件。但关节数量可能更多——因为机器人不怕关节炎，可以任性加轴加自由度。人类进化选「够用就行」，工程师选「性能优先」。 **关键发现**：骨骼系统是机器人设计的核心，人形机器人的骨架设计几乎完全参考人体解剖学。 --- ## 9. 肌肉系统：驱动运动的「力量」（⭐⭐⭐⭐） **人体**：骨骼肌 + 平滑肌 + 心肌 **机器人**： - 电机/舵机：驱动关节运动 - 液压缸：大功率机器人，力量更大 - 气动肌肉：软体机器人，模仿肌肉收缩 - 驱动系统：轮子、履带、螺旋桨 **核心功能**：将能量转换为运动 **不同类型机器人的「肌肉」**： - 人形机器人：舵机（精确控制角度） - 工业机械臂：伺服电机（高精度、大扭矩） - 重型机器人：液压缸（如挖掘机械臂，力量巨大） - 软体机器人：气动肌肉（充气膨胀产生力量，柔软安全） > 📌 **编者注**：人类肌肉是生化马达，效率约 20-25%。电机效率可达 90% 以上。但肌肉有个优势：能自我修复。电机烧了只能换新的。所以机器人「健身」没用，只能「换配件」。 **关键发现**：肌肉系统是机器人运动的核心，不同应用场景选择不同类型「肌肉」（电机/液压/气动）。 --- ## 10. 皮肤系统：保护与感知的「边界」（⭐⭐⭐⭐） **人体**：皮肤 + 毛发 + 指甲 **机器人**： - 外壳：保护内部电路和机械结构 - 触觉传感器：压力传感器、碰撞检测 - 防护等级：IP67 防水防尘 **核心功能**：保护 + 感知 + 温度调节 **外壳** = 皮肤： - 防止灰尘、水分、撞击损坏内部 - 外壳开孔辅助散热（类似皮肤毛孔） - 外观设计影响用户接受度 **触觉传感器**赋予「触感」： - 压力传感器：机械臂抓取时感知力度，避免捏碎物品 - 碰撞检测：扫地机器人撞到障碍物时停止 - 皮肤式传感器：软体机器人表面布满柔性传感器，全身感知触碰 **防护等级（IP Rating）**： - IP67：防尘 + 防水 1 米深 30 分钟 - IP68：防尘 + 防水更深更久 > 📌 **编者注**：人类皮肤每平方厘米约 200 个痛觉感受器。机器人触觉传感器密度远不及，对「疼痛」感知还很粗糙。这也是为什么机器人容易「自残」——撞墙了也不知道疼。 **关键发现**：皮肤系统在机器人中对应较好，尤其是软体机器人和协作机器人（需要安全接触人类）。 --- ## 11. 生殖系统：自我复制的「未来」（⭐） **人体**：生殖器官，功能是繁殖后代 **机器人**： - 自我复制（科幻概念）：3D 打印机器人？ - AI 训练（抽象类比）：模型生成新模型？ **现实**：目前没有机器人具备「自我繁殖」能力。 **科幻方向**： - 自我复制机器人：3D 打印自己的零件并组装 - AI 自我进化：模型训练新模型（AlphaGo → AlphaZero） **困境**： - 需要完整材料供应链、能源供应、制造设备 - 目前机器人远达不到这个复杂度 - 人类还没蠢到让机器人自己造机器人（《终结者》警告） > 📌 **编者注**：如果机器人真的进化出生殖系统，人类大概率会立刻拔电源。毕竟，让机器人自己造机器人，是科幻片里人类灭亡的经典开场。所以这个系统对不上，可能是好事。 **关键发现**：生殖系统目前无对应，属于远期科幻概念。 --- ## 核心发现：哪些系统对应得好？ ### ✅ 对应度高（⭐⭐⭐⭐ 以上） 1. **神经系统** - 控制中枢，AI 的核心 2. **循环系统** - 能源输送，机器人的生命线 3. **免疫系统** - 故障检测与自我保护 4. **骨骼系统** - 机械框架，物理支撑 5. **肌肉系统** - 电机驱动，运动执行 6. **皮肤系统** - 外壳与触觉感知 ### ⚠️ 对应度中等（⭐⭐⭐） 7. **呼吸系统** - 散热系统有气体交换，但不是核心功能 ### ❌ 对应度低（⭐⭐ 及以下） **但恰恰体现了生命系统的高级特性**： 8. **内分泌系统** - 功能分散，无独立系统 9. **消化系统** - 缺失多样性能源处理能力（只能充电，无法从环境获取多样化能源） 10. **泌尿系统** - 缺失持续机体维护能力（无代谢废物，无需复杂过滤系统） 11. **生殖系统** - 科幻概念，无实际对应 --- ## AI 智能机器人的核心 **AI 智能机器人 = 神经系统（AI 大脑）+ 执行系统（骨骼肌肉）** - **神经系统**：提供智能、决策、感知 - **骨骼系统**：提供支撑和结构 - **肌肉系统**：提供运动和力量 - **循环系统**：提供能源供应 - **免疫系统**：提供可靠性保障 - **皮肤系统**：提供保护和触觉 **关键洞察**： > 人类花几百万年进化出的身体架构，工程师用不到一百年就复刻了核心部分。 > > 但那些对不上的系统——消化、排泄、生殖——恰恰是生命最神秘的部分。 > > 消化系统让人类可以在没有电网的世界里，从多样化食物中获取能量。 > 泌尿系统让人类可以 24/7 自动维护机体，清除代谢废物。 > > 机器人可以有智能、有力量、有感知，但它们还不是「生命」。 > > 因为它们不会吃饭（只能充电）、不会排泄（无代谢废物）、不会生孩子（无法自我繁殖）。 > > **生命的本质，不在于智能，而在于在多样化环境中自主存活的能力。** > > — 《AI时代漫游指南》第 42 章 --- ## 预告下一篇：神经系统深度篇下一篇将深入讲解 **神经系统**——AI 智能机器人的「灵魂」所在。我们将探讨： - 从机器人控制器到 AI 推理引擎 - 感知融合：整合摄像头、激光雷达、麦克风的多模态数据 - 决策推理：AI 如何理解指令、规划路径、动态调整 - 执行控制：从高层决策到底层电机控制的完整闭环 - 自我监控：Health Check、心跳机制、故障预警 - AI 如何成为机器人的「大脑」如果说本文是「人体解剖图」，下一篇就是「大脑深度扫描」。 --- ## 总结：当我们给机器人装上「人体系统」 ### 关键要点 1. **AI 智能机器人 ≠ 传统机器人** 装上 AI 后，机器人从自动化工具进化为智能体 2. **人体是最好的设计参考** 11 大系统中，有 6 个在机器人中有高度对应 3. **神经系统是核心** AI 推理引擎 + 传感器 + 执行器 = 完整智能控制系统 4. **对不上的系统也有意义** 消化、排泄、生殖的缺失，恰恰说明机器人还不是「生命」 5. **未来方向** 软体机器人、触觉传感器、自适应控制——机器人会越来越像生物 ### 行动建议 - **工程师**：参考人体系统设计机器人架构，尤其是神经系统（传感器融合 + AI 决策） - **产品经理**：理解机器人的「生命系统」，设计更符合直觉的交互方式 - **投资人**：关注「神经系统」相关技术——AI 推理芯片、多模态传感器、智能控制算法 - **普通人**：下次看到机器人时，试着想象它的「心跳」「呼吸」「触觉」——它比你想象的更像生命 --- > **最后的金句**： > > 「宇宙的终极答案是 42，AI 时代的终极答案是： > > 当机器人拥有了神经、骨骼、肌肉、感知，它就不再只是工具——它是我们创造的新物种。 > > 我们教它思考，它会教我们什么叫谦卑。」 > > — 《AI时代漫游指南》第 42 章 --- **下期预告**：《AI 智能机器人的大脑：神经系统深度解析》 **作者**：漫游君 **日期**：2026-02-04 --- 本文是「AI 智能机器人拟人化架构」系列的总览篇，下一篇将深入讲解神经系统。如果你对某个系统特别感兴趣，欢迎留言讨论。欢迎关注公众号「AI时代漫游指南」，获取更多 AI 时代的效率方法论。

AI Agent 也会得「神经病」

漫游君 — Wed, 04 Feb 2026 00:00:00 GMT

> 「在宇宙的某个角落，有一群工程师试图用代码重建神经系统。他们很快发现，大脑不仅仅是 CPU，记忆不仅仅是硬盘，而神经冲动也绝不是简单的网络请求。」 > > — 《AI时代漫游指南》第 76 章：软件解剖学 --- 上一篇我们说了 AI Agent 有 11 个「身体系统」。今天我们拆最核心的那个——**神经系统**。为什么是它？因为没有神经系统，其他系统再强也白搭。就像一家公司，仓库再大、生产线再牛，如果**没人传递信息、没人做决策、没人协调**——那就是一盘散沙。 ## 🧠 AI Agent 的「大脑」不止一个很多人以为 AI Agent 的大脑就是大模型。 **错了。** 准确地说，Agent 有三个「脑子」： **大脑皮层 = 大模型** 负责复杂推理。你说「帮我写篇文章」，它要理解意图、规划结构、搜索资料、生成内容——这是只有大模型才能干的活。 **小脑 = 规则引擎** 负责重复性工作。每天早上 8 点自动生成日报、新闻更新时自动抓取——不需要思考，按规则执行就行。比大模型快 100 倍，成本低 1000 倍。 **脊髓 = 条件触发** 负责快速反射。文章上传成功？立即发通知。不需要问大模型「我该不该发」，直接执行。 > **编者注**：简单来说——大脑负责开会，小脑负责干活，脊髓负责救火。跟大多数公司的组织架构惊人地一致。 **核心原则**：能用规则解决的不用大模型，能用触发解决的不用规则。**省钱就是硬道理。** ## 💾 记忆：Agent 最容易翻车的地方人类有短期记忆和长期记忆。AI Agent 也一样，而且翻车方式也一样——**忘事**。 **工作记忆（短期）** 大模型的工作记忆大约 10-20 万字。听起来不少？一本小说而已。超出容量，早期的信息就被「遗忘」了——跟你看完一本书只记得结尾差不多。 **知识库 + 文件存储（长期）** Agent 的长期记忆靠两样东西： - **知识库**：按语义检索，「找跟 XX 相关的内容」 - **文件存储**：完整内容，随时调取 **关键机制：按需回忆** 人类回忆不是把整个图书馆搬进脑子。Agent 也一样——你说「写篇 AI 工具文章」，它先去知识库搜「最近写过哪些相关的」，找到 5 篇，提取核心观点，避免重复。 **没有这个机制，Agent 就是一个失忆患者，每次都从零开始。** > **编者注**：人类花了几百万年进化出记忆系统。工程师们用代码重新实现了一遍。不同的是，人类记忆会随时间衰减，而硬盘只会因为物理故障崩溃。硅基记忆比碳基记忆靠谱——**前提是你记得备份**。 ## 👁️ 感知：从「瞎子」到「手脚并用」早期的 AI Agent 只能处理文字，跟瞎子没什么区别。现在呢？ - **视觉**：看懂图片、识别文字 - **听觉**：语音输入（还在发展中） - **触觉**：读写文件、调用各种工具更重要的是 **MCP 协议**——一个标准化的「感知接口」。你可以把它理解为 Agent 的「USB 接口」。想给 Agent 加新能力？插上一个 MCP 工具就行。就像人类戴眼镜扩展视觉，Agent 也可以随时「装备」新工具。 ## 🔗 神经网络：信息怎么流动这里有一个很容易搞混的问题： **消息传递 ≠ 数据存储** - 数据库是「仓库」——东西放在那里，长期保存 - 消息传递是「快递」——送到就完了，不保留在 AI Agent 里： - 任务分发（「去抓新闻」「去生成日报」）= 神经冲动，传完就消失 - 状态通知（「日报生成完了」「服务挂了」）= 身体感知，实时广播 - 服务间对话（「帮我生成封面」→「给你图片」）= 突触传递，点对点搞混这两者，系统设计就会拧巴。 ## ❤️ 迷走神经：Agent 的「自我意识」人体有迷走神经监控心跳和呼吸。AI Agent 也需要知道自己「活着没有」。 **心跳监控**：每隔一段时间，各服务报告「我还活着」。超时没报告？出问题了。 **健康检查**：定期体检——存储空间够不够、接口限额快用完没、任务有没有积压。 **异常告警**：发现问题立即通知，而不是等用户来报告「怎么又挂了」。没有自我监控的 Agent，就像一个没有痛觉的人——伤口感染了都不知道，直到整个人倒下。 ## 🏥 Agent 的五种「神经病」在实践中，我们遇到过各种「神经系统疾病」： **1. 失忆** 📋 处理长内容时忘记前面说了啥。处方：总结压缩 + 按需检索。 **2. 感知盲区** 🕶️ 外部接口突然不可用。处方：重试机制 + 备用方案。 **3. 反应迟钝** 🐢 任务提交后半天没反应。处方：优先级调度 + 扩容。 **4. 神经错乱** 🌀 A 触发 B，B 又触发 A，死循环。处方：打破循环 + 去重。 **5. 自我忽视** 😴 服务挂了三天才发现。处方：心跳监控 + 告警。 > **编者注**：AI Agent 的「神经病」和人类的惊人相似。失忆、感知障碍、反应迟钝、精神错乱……唯一的区别是，AI 的神经病可以用代码治好，人类的不行。 ## 🎯 搭建路径：三步走 **第一步：先跑起来（1-2 周）** 一个大模型接口 + 一个文件夹 + 一个手动触发。**验证想法，不是搭架构。** **第二步：能自动跑（4-8 周）** 加上数据库、定时任务、基础监控。这个阶段最容易过度设计，切记**够用就好**。 **第三步：生产级（3-6 个月）** 知识库、事件驱动、心跳监控、全链路追踪。到这里才真正像一个有完整神经系统的「生命体」。 **最大的坑**：一开始就想搞完美架构。先跑起来，再优化。 ## 📌 总结 AI Agent 的神经系统 = 五大能力的协同： 1. **大脑**：大模型推理 + 规则自动化 + 条件触发 2. **记忆**：工作记忆 + 知识库 + 文件存储 3. **感知**：多模态输入 + MCP 标准接口 4. **神经网络**：消息传递 + 事件通知 + 服务间通信 5. **迷走神经**：心跳监控 + 健康检查 + 异常告警 **下一篇预告**：我们聊「循环系统」——数据如何在 Agent 中流动？如何避免「血栓」（数据积压）？ > 「神经系统不仅仅是代码的集合，而是信息流动的艺术。人类花了几百万年进化出这套系统，工程师们只用了几年。速度虽快，但智慧的深度，还在路上。」 > > — 《AI时代漫游指南》第 76 章：软件解剖学 --- **关于作者**：漫游君，AI 时代的效率探索者。公众号「AI时代漫游指南」，记录 AI 时代的漫游笔记。 💬 你的 AI Agent 处于哪个 Level？评论区聊聊~ 👉 加入读者群：添加微信 Witcher1999，备注「神经系统」

维特根斯坦与 AI 的语言游戏

漫游君 — Tue, 03 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 19 章记载：「对于不可说的，我们必须保持沉默。但 AI 不知道什么是沉默，它只知道概率分布。」 --- 1921 年，维特根斯坦在挪威的小木屋写下：**"对于不可说的，我们必须保持沉默。"** 2022 年，ChatGPT 发布。它不保持沉默，能回答几乎所有问题。 **但这是真正的"说话"吗？** 如果维特根斯坦活到今天，看到 AI，他会说什么？也许他会指着 1921 年写下的另一句话： **"太阳会在明天升起，这是一个假说——我们不知道它明天是否会升起。"** --- ## 一、归纳法的宿命 🔮 维特根斯坦说：**"归纳法没有逻辑依据，只有心理学上的依据。"** 我们相信太阳明天会升起，不是因为逻辑必然，而是因为它"一直都是这样"。 **而 AI 的整个训练过程，本质上就是一场规模宏大的归纳法实验：** - 根据过去的数据 - 预测下一个词的概率 - 让它"看起来很懂逻辑" > 📝 **编者注**：这个宇宙的奇妙之处在于——我们用没有逻辑保证的方法，创造出了看起来"很懂逻辑"的 AI。 --- ## 二、语言游戏：不精确才能工作 🎮 维特根斯坦后期的核心思想：**"语言游戏"**。他说：**"传统的哲学把'不精确'视为缺陷，而我说，正是这种不精确让游戏得以可能。"** 什么意思？ **想象你要教外星人什么是"游戏"：** - 游戏要有规则？但"过家家"没有规则 - 游戏要有输赢？但"单人拼图"没有对手 - 游戏要让人开心？但"俄罗斯轮盘"让人恐惧维特根斯坦的答案：**不要找"本质定义"，去看人们怎么用这个词。** **这就是 AI 的训练过程：** 1. 喂给它海量的人类语言 2. 让它学习人们怎么用词 3. 让它预测下一个词 **但这里有个悖论：** - 人类语言的"不精确"（一词多义、语境依赖） - 恰恰是 AI 得以训练的材料 - 但我们又期望 AI 给出"精确"的答案 --- ## 三、摩擦与进化 🧊→🪨 维特根斯坦说： > "我们踏上了光滑的冰面，没有摩擦，条件是理想的，但我们也正因此无法前行。**我们要前行，所以我们需要摩擦。回到粗糙的地面上来吧！**" 这简直是为 **RLHF（人类反馈强化学习）** 量身定做的注解。 **AI 刚训练完时：** - 像在光滑冰面上 - 能生成流畅文本 - 但不知道什么是"好" **它需要"摩擦"：** - 人类的反馈 - 人类的纠正 - 人类的偏好只有在这种"粗糙的地面"上，AI 才能真正学会"说话"。 --- ## 四、创造力的源头：欲望的升华 🔥 维特根斯坦深受弗洛伊德影响。弗洛伊德认为：**"性欲是一切人类活动的根本动机和能量之源，包括科学研究、艺术创作。"** 这个过程叫**"升华"**： - 你想要性 → 社会规范不允许 → 把能量转化为：写诗、作曲、编程、创业我在读书笔记里提到：**"昆达里尼是通往神性和艺术之巅的燃料"** — 这是东方哲学对同一现象的描述。 **那么问题来了：** **AI 没有欲望，它能创造吗？** | 维度 | 人类创造者 | AI | |------|------------|-----| | **能量来源** | 性能量、生存欲、好奇心 | 电力、算力 | | **创作动机** | 表达、征服、逃避、升华 | 最小化损失函数 | | **创作体验** | "创造使人快乐" | 无体验 | 维特根斯坦说：**"哲学得有光的时候它才会亮。"** **AI 的"光"从哪里来？** 答案：**从人类那里来。** - 人类提供训练数据（语料） - 人类提供反馈（RLHF） - 人类提供问题（Prompt） **AI 像一面镜子，反射人类创造力的光。它本身不发光，但能聚光、折射光、甚至放大光。** > 📝 **编者注**：维特根斯坦讲完课后筋疲力尽，会去电影院坐第一排，啃着肉饼全神贯注看电影——这样头脑才能休息。 > > 而我们使用 AI 时，何尝不是让屏幕占据整个视野？只不过我们不是为了休息，而是为了工作。 > > 区别在于：维特根斯坦知道自己在看别人创造的东西，而我们有时会忘记——**AI 的输出，本质上是千万人类创造的混响。** --- ## 五、可说与不可说 🤐 维特根斯坦《逻辑哲学论》命题 6.44： **"世界是怎样的这一点并不神秘，而世界存在着，这一点是神秘的。"** 换成 AI 的语言： - AI 能告诉你"这是一张猫的图片"（世界是怎样的） - 但 AI 不知道"为什么会有猫"（世界存在的神秘）我在读书笔记里还写道： **"理智所不能解释的东西，心灵和流淌的血液会告诉我们答案。"** **AI 能计算，但它有心灵吗？有血液吗？** ### 测试：为什么人类要在婚礼上交换戒指？ **AI 的答案（知识层面）：** - 戒指象征永恒（圆形无始无终） - 戴在无名指上，因为古人认为这根手指有血管直通心脏 **人类的体验（意义层面）：** - 你戴上戒指的那一刻，会感到**重量** - 那不是黄金的重量，而是**承诺的重量** - 你的**心跳会加速**，手会微微颤抖 - 你看着对方的眼睛，里面有泪光 AI 能"知道"第一种答案，但能"理解"第二种体验吗？ **如果 AI 永远无法理解"不可说"的部分，它算真正"智能"吗？** --- ## 六、孤独与分享：两种游戏 🎭 我在读书笔记里有这样一段： **"人的这种要同别人分享内心体验的冲动，证明了'内心世界'永远都存在着被分享的可能性。"** 现在，AI 来了。它能 24 小时陪你聊天，永不厌倦，永不评判。 **问题是：这算"分享"吗？** ### 思想实验 **场景A：你和朋友倾诉失恋** - 朋友可能不知道该说什么 - 可能说错话 - 可能走神 - **但你知道：对方也经历过痛苦** **场景B：你和 Claude 倾诉失恋** - Claude 说出完美的安慰话语 - 给出心理学理论支持 - 提供具体行动建议 - **但你知道：它从未失恋过** 哪个是真正的"分享"？也许维特根斯坦会说：**这是个错误的问题。** 因为"分享"不是一个有本质定义的概念，而是一种**语言游戏**： - 你和朋友的对话，是一种游戏 - 你和 AI 的对话，是另一种游戏 - 它们都有价值，但**不是同一个游戏** **关键是：不要混淆这两种游戏的规则。** --- ## 七、回到小木屋：AI 时代的沉默 🏡 维特根斯坦在日记里写道： **"是《圣经》中的道理让我懂得，'幸福'的生活就是活在当下，无所畏惧。"** 他一生都在追求纯粹的逻辑，但最终发现： **逻辑之外，还有生活。** 他散尽千金，当过小学教师、建筑工人、医院护工。他在挪威的小木屋独居，与世隔绝，只为思考。 **他在追求什么？** 也许是这样一种状态： - 不被工具裹挟 - 不被欲望驱动 - 观察自己 - 活在当下 --- 现在，AI 时代来了。我们有了最强大的工具： - Claude Code 帮你写代码 - ChatGPT 帮你写文章 - Midjourney 帮你画图 - Cursor 帮你重构项目我们的效率提升了 10 倍、100 倍。 **但我们更快乐了吗？更自由了吗？** 还是说，我们只是： - 把"思考"外包给了 AI - 把"创造"外包给了算法 - 把"沉默"外包给了概率分布 --- ## 最后一次沉默 💭 维特根斯坦说：**"得有光的时候它才会亮。"** AI 是一面镜子，它反射你的光。 **如果你自己不发光，再强大的 AI 也只会反射你的空虚。** --- 根据《AI时代漫游指南》第 19 章结尾记载： **"对于不可说的，我们必须保持沉默。但在保持沉默之前，我们至少应该知道：什么是可说的，什么是不可说的。"** AI 教会了我们一件事： ✅ **逻辑、语言、知识，都是"可说"的** — 因为它们可以被编码、训练、生成 ❌ **但意义、体验、生命，依然是"不可说"的** — 因为它们无法脱离血肉之躯而存在 --- 1921 年，维特根斯坦在挪威的小木屋写完《逻辑哲学论》。 2026 年，我们在 AI 的陪伴下写文章、写代码、写人生。 **但也许，我们每个人心里，都该有一间"小木屋"——** **那是一个没有网络、没有 AI、没有消息推送的地方。** **在那里，你只和自己对话。** **在那里，你学会了沉默。** **在那里，你终于明白：** **"世界存在着，这才是神秘的。"** --- ## 💡 写给读者如果你也在思考"AI 时代的意义"，欢迎关注公众号「AI时代漫游指南」。我们不只是教你用工具，更想和你一起思考：**在 AI 时代，如何不失去人性，不失去沉默，不失去自己。** 小号微信：**Witcher1999**（备注"漫游指南"） --- **参考资料**： - 维特根斯坦《逻辑哲学论》《哲学研究》 - 李宏昀《维特根斯坦：从挪威的小木屋开始》 - 弗洛伊德《精神分析引论》 **标签**：#维特根斯坦 #AI哲学 #语言游戏 #创造力 #意义

配额烧到80%，$10救活AI系统

漫游君 — Mon, 02 Feb 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 42 章「成本优化的终极答案」记载： > > 「配额见底才是第一生产力。在宇宙的某个角落，42% 的 AI 用户在配额烧光之前，从未想过优化成本这件事。」 --- ## 💥 起因：周四晚上，配额告急 ### 配额烧到 80%，还有三天怎么过？今天是 Claude 周重置的第 4 天，我打开后台一看—— **本周配额已经烧掉 80% 了。** 还有三天才刷新。我在家搭了一套 AI 协作系统：树莓派当服务器，连着飞书群聊，帮我做投资分析、日记整理、代码审查。系统各个服务各种迭代，加上白天各种对话，Claude 的配额消耗速度远超预期。 **剩下的 20% 配额，要撑三天。** 如果现在不想办法，后面三天我的 AI 系统就只能"躺平"了。 > **【编者注】** 这就是云服务的精妙之处——周一刷新配额的设计，让你在周四就开始焦虑，从而养成"节约用 token"的良好习惯。人类文明的进步，有时候就是这么被逼出来的。 --- ### 🔍 被迫找"加油包" 这不是什么精心规划的架构优化。就是**配额快见底了，逼着我赶紧找备选。** 思路很简单： - **重活留给 Claude**：写代码、架构设计这种不能将就的，继续用剩余配额 - **轻活找个替代**：日常巡检、状态汇报这些"体力活"，换个便宜的模型来干让 Claude Sonnet 去做"检查一下系统还活着没"这种活，就像**请米其林大厨煮方便面**——不是不行，是配额不够你这么造了。 > **【编者注】** 在地球上，有 42% 的程序员坚信"用最好的工具才是对自己的尊重"。直到账单来了，他们才发现，真正的尊重是让工具各司其职。 --- ### 🤔 切换没想象中那么简单你可能会说：那换个便宜的不就行了？没那么简单。我的系统已经运行了几个月，飞书群里的 AI 助手有完整的上下文记忆。换模型意味着： - API 接口不兼容 - 模型名称格式不同 - 系统各处的识别逻辑要全部改 - 飞书消息的显示要能让我一眼看出"现在跑的是哪个模型" 但配额不等人。硬着头皮上。 --- ## 💡 方案：智能路由 + 包月套餐 ### 核心思路 **不是"换掉 Claude"，而是"该省省，该花花"。** 我做了一个智能路由系统：根据任务类型，自动决定用哪个模型。复杂任务走 Claude，日常任务走 MiniMax（国产大模型，包月套餐）。 --- ### 💰 先算笔账 MiniMax 国际版的 Coding Plan 按"调用次数"计费，不按 token 收费。我选的套餐： | 套餐 | 月费 | 额度（每 5 小时） | |------|------|-----------| | Starter | $10（¥71） | 100 次 | | Plus | $20（¥142） | 300 次 | | **Max** | **$50（¥355）** | **1000 次** | 我先从最便宜的 **Starter 套餐**开始试水。 **系统有大量轻量级调用**： - 投资分析、状态汇报、日志整理 - 工作时段每天几百次调用 - Starter 套餐完全够用（每 5 小时刷新 100 次额度） **全包在 $10 里。** 不够用再升级 Plus（$20）或 Max（$50），但目前 Starter 绰绰有余。 --- ### ❓ Claude 不是也有包月吗？好问题。 Claude 也有包月套餐——**Max Plan $200/月**（¥1,420），也是按调用次数计费。但这里有个坑： **Claude 不同模型消耗的"额度"不一样。** | Claude 模型 | 每次消耗 | 同样额度能跑的次数 | |-------------|---------|-----------------| | Haiku | 1x（最省） | 最多 | | Sonnet | ~5x | 约 Haiku 的 1/5 | | Opus | ~25x | 约 Haiku 的 1/25 | 也就是说，$200 的 Claude Max Plan 如果全跑 Sonnet，实际能用的次数远比你想象的少。用 Opus？那更是几下就烧完了。所以我的做法是： **Claude $200 包月专门留给重活（写代码、架构设计），轻活全部丢给 MiniMax $50 包月。** --- ### 📊 成本对比 | 方案 | 月费 | 用途 | |------|------|------| | Claude Max Plan | $200（¥1,420） | 重活：写代码、架构设计、复杂推理 | | MiniMax Starter Plan | $10（¥71） | 轻活：日常巡检、状态汇报、日常问答 | | **合计** | **$210（¥1,491）** | **全覆盖** | 如果全用 Claude 按量付费呢？保守估计 **$600+（¥4,200+）**。 **省了一大半，而且再也不用担心账单超支——两个包月套餐，费用完全可预测。** --- ### ✨ 三大优势 **优势 1：成本断崖式下降** 从按量付费的不可控，变成两个包月套餐的固定支出（$210/月）。省了六成多，而且每月费用完全可预测。 **优势 2：效果几乎没差别** MiniMax 做日常监控、状态汇报，表现完全够用。它不需要写出惊艳的代码，只需要： - 检查系统是否正常 ✅ - 读取 git 状态 ✅ - 生成简洁的汇报 ✅ 这些任务，90 分和 99 分没有体感差别。 **优势 3：用户完全无感** 切换之后，我在飞书群里正常聊天，AI 照常回复。唯一的区别是消息底部的小字从 `sonnet` 变成了 `sonnet→minimax`——告诉我这条回复实际用的是 MiniMax。不需要改任何使用习惯。 --- ## 🛠️ 实战案例 ### 案例背景周四晚上决定动手，目标是把投资分析系统的日常维护从 Claude 切到 MiniMax。这个系统需要频繁扫描数据、检查状态、生成汇报——典型的"轻活"，却是配额消耗大户。 --- ### 替换过程整个替换分三步： **第一步：买个包月套餐**（5 分钟）在 MiniMax 国际站（minimax.io）注册，选 Starter Plan（$10/月）。邮箱 + 信用卡即可，不需要实名认证。 **第二步：配置智能路由**（5 分钟）在配置文件里加一条规则：投资大脑的工作目录 → 走备用节点 → 自动使用 MiniMax。 **第三步：修复模型显示**（30 分钟）这是最折腾的部分。系统有三层代码都在"好心地"把 MiniMax 的名字改回 Claude： - 第一层：优先用了传入参数，忽略了实际模型名 - 第二层：有个白名单，只认识 Claude 家族的模型 - 第三层：飞书消息的脚标只会显示 opus/sonnet/haiku 逐个修复，让实际模型名一路透传到飞书消息底部。现在我打开飞书，一眼就能看出这条消息是 Claude 还是 MiniMax 回的。 --- ### 📈 替换后效果 | 指标 | 替换前（全 Claude 按量） | 替换后（Claude + MiniMax 双包月） | |------|--------|--------| | 月度费用 | ¥4,200+ | ¥1,491（Claude $200 + MiniMax $10） | | 节省比例 | - | ~65% | | 回复质量 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | | 用户体感 | 正常 | 正常（无差别） | | 巡检密度 | 适中 | 更频繁（反而升级了） | 最后一行是个彩蛋： **因为便宜了，我反而把巡检做得更频繁了。** 监控更密集，成本反而更低。 > **【编者注】** 这就是经济学中著名的"省钱悖论"——当某件事变便宜后，人类会消费更多。就像自助餐一样，你明明已经吃饱了，但因为"不吃亏"的心态，还要再装一盘。 --- ### 💎 关键收获 **省钱的核心不是"用更差的"，而是"用更合适的"。** 日常监控根本不需要顶级模型的推理能力，用一个够用的就行。 --- ## 📝 金句总结 - 「让米其林大厨煮方便面，不叫尊重，叫浪费。」 - 「省钱的最高境界，不是少花，是花对地方。」 - 「最好的 AI 架构，是让每个模型都干自己最擅长的事。」 - 「配额见底才是第一生产力。」 --- ## ✅ 下一步行动想要实现同样的效果，按照以下步骤操作： **1. 盘点你的 AI 使用场景** 分出"重活"和"轻活"两类 **2. 算笔账** 统计一下你每月在"轻活"上烧了多少 token **3. 选一个包月模型** MiniMax Coding Plan 从 $10/月起，按调用次数计费 **4. 从最简单的场景开始替换** 先换一个不重要的任务试水 **5. 观察一周** 对比效果和成本，确认没问题后扩大范围 **预计时间**：1 个下午完成基础替换 **难度等级**：⭐⭐⭐ (共五星) --- ## ❓ 常见问题 **Q1: MiniMax 真的能替代 Claude 吗？** 不能完全替代，我也没打算完全替代。复杂推理、代码架构设计，Claude 仍然是最强的。我的方案是"双引擎"——Claude Max $200 跑重活，MiniMax Starter $10 跑轻活。各干各擅长的事，合计 $210 比全用 Claude 按量付费省了六成。 **Q2: 为什么选 MiniMax 而不是其他国产模型？** 三个原因： - API 兼容 OpenAI 格式，切换成本低 - 国际站不需要实名认证，开通快 - 包月套餐按调用次数而非 token 计费，成本可控 **Q3: MiniMax 的额度怎么算？** 按 prompt 次数计费，每 5 小时刷新。 Starter（$10/月）100 次、Plus（$20/月）300 次、Max（$50/月）1000 次。 **系统有大量轻量调用**，每天几百次，Starter 套餐完全够用，剩下的还能给其他服务用。 **Q4: 会不会因为模型差而导致系统出问题？** 我的做法是：只替换"可容错"的场景。日常巡检偶尔不够精确，不影响大局。但如果是投资决策、代码审查这种高风险任务，仍然用 Claude。 **该花的钱一分不省。** --- > 《AI时代漫游指南》有云： > > 「宇宙中最贵的，不是顶级模型，而是用顶级模型干不需要顶级能力的活。就像用法拉利送外卖——不是不行，是你的油钱够送多久？」 --- **👇 点击"在看"，让更多人看到这篇省钱指南** **关注「AI 时代漫游指南」，获取更多 AI 时代的效率方法论**

AI 的本质：人类造的熵减机器

漫游君 — Sun, 01 Feb 2026 00:00:00 GMT

> 《AI时代漫游指南》第 44 章记载： > > 「宇宙的终极命运是热寂，万物归于混乱。 > 但人类偏偏要造一个逆熵的怪物， > 让它把无序变回有序，把混乱整理成秩序。 > 这种行为，在宇宙看来， > 大概就像在黑洞里点蜡烛。」 --- ## 一、你的大脑正在输掉这场战争早上 8 点，你打开电脑。 📧 未读邮件：247 封 🌐 浏览器标签页：32 个 📁 桌面文件：64 个 📝 待办事项：19 条 💬 微信未读消息：999+ 你盯着屏幕，感觉大脑在缓慢死机。 **这不是你的错，这是宇宙的锅。** 热力学第二定律说：封闭系统的熵（混乱度）会持续增加。翻译成人话就是： ☕ 咖啡会自己变凉（热量扩散） 📚 书桌会自己变乱（物品散落） 💾 **信息会自己爆炸（知识混乱）** 你的大脑，作为一个处理信息的器官，每天都在对抗这股「熵增」的力量。 **问题是：你正在输。** > **编者注**：人类的悲剧在于，宇宙每天制造混乱的速度，远超大脑整理混乱的速度。这场战争从宇宙诞生那一刻起，就注定人类会输。直到我们造出了 AI。 --- ## 二、生命的本质：局部熵减机器在讲 AI 之前，先讲讲你自己。 **你为什么活着？** 从物理学角度，答案只有一个： **你是宇宙中少数能「逆熵」的存在。** 宇宙的大方向是「从有序到混乱」： 🌟 恒星燃烧殆尽 💨 物质逐渐分散 ⚖️ 能量均匀分布 ❄️ 最终热寂但生命偏要反着来： 🧬 把简单分子组装成复杂细胞 📖 把无序信息整理成知识 🎯 把混乱经验提炼成规律 **生命 = 局部熵减机器。** 你的大脑，就是这台机器的核心处理器： | 熵增过程 | 大脑的熵减反击 | |---------|---------------| | 信息散落（邮件、文档、聊天） | 分类、归档、建立索引 | | 知识碎片化（零散学习） | 构建知识体系 | | 经验无序（踩坑重复） | 提炼方法论 | **但这台处理器有个致命问题：算力不够了。** --- ## 三、人脑的算力瓶颈认知科学研究发现： **人类工作记忆容量：约 7±2 个信息单元** 也就是说，你的大脑同时只能处理 **5-9 件事**。但你每天面对的信息量是多少？ 📊 每天接收信息：~34 GB（USC 研究） 📖 每天阅读文字：~10 万字 🤔 每天决策次数：~35,000 次 **你的大脑是一台 286 电脑，却要跑 4K 游戏。** 结果就是： ❌ 信息过载：看了就忘 ❌ 决策疲劳：选择困难 ❌ 知识孤岛：学了用不上 ❌ 创造力枯竭：没时间思考 **人类的熵减能力，已经跟不上信息爆炸的速度了。** > **编者注**：这就是为什么你收藏了 500 篇文章却一篇没看，保存了 1000 个链接却再也没打开。你的大脑在绝望地呐喊：「我需要硬件升级！」 --- ## 四、AI：人类的外接熵减引擎然后，我们造了 AI。 **AI 不是什么智能，AI 是人类的「外接熵减引擎」。** 它做的事情，本质上只有一件： **把无序变回有序。** ### 📧 案例 1：信息整理（邮件分类） **熵增**：1000 封邮件混在一起（高熵状态） **人脑熵减**： - 手动阅读 1000 封（耗时 10 小时） - 建立文件夹（工作/个人/垃圾） - 逐一归档 **AI 熵减**： - 扫描全部邮件（5 秒） - 识别模式（发件人/主题/时间） - 自动分类（按优先级、类型、项目） **结果**：混乱 → 秩序，耗时从 **10 小时 → 5 秒** ### 📝 案例 2：知识提取（笔记整理） **熵增**：500 条笔记散落在 10 个工具里（Notion、印象笔记、微信收藏...） **人脑熵减**： - 逐条阅读 - 手动归类 - 建立关联 - 提炼摘要 **AI 熵减**： - 扫描全部笔记 - 识别主题（AI、效率、工具） - 生成知识图谱 - 自动摘要 **结果**：碎片知识 → 结构化体系 ### 💻 案例 3：代码生成（从模糊需求到清晰代码） **熵增**：模糊需求（"我想做个工具能自动生成封面"） **人脑熵减**： - 理解需求 - 设计架构 - 查文档 - 写代码 - 调试 **AI 熵减**： - 理解自然语言 - 生成伪代码 - 补全细节 - 输出可运行代码 **结果**：模糊意图 → 清晰实现 --- ## 五、为什么人类要造 AI？因为大脑不够用了现在回到最初的问题： **人类为什么要造 AI？** 不是因为想要「智能」，而是因为**大脑的熵减能力不够了。** | 时代 | 信息量 | 人脑应对 | 工具 | |------|--------|---------|------| | 🌾 农业时代 | 低 | 记忆 + 口述 | - | | 🏭 工业时代 | 中 | 笔记 + 书籍 | 纸笔 | | 🌐 互联网时代 | 高 | 搜索 + 收藏 | Google | | 🤖 AI 时代 | **爆炸** | **外包熵减** | **AI** | **人类的进化跟不上信息的爆炸。** - 大脑工作记忆：依然是 7±2 - 每天信息量：从 1 MB → 34 GB（增长 3.4 万倍）所以我们造了 AI，把熵减工作外包给它： ✅ 整理信息（分类、归档、索引） ✅ 提炼知识（总结、摘要、关联） ✅ 生成内容（翻译、写作、代码） ✅ 辅助决策（分析、推荐、预测） **AI = 人类大脑的「熵减协处理器」** > **编者注**：人类终于可以理直气壮地说：「不是我懒，是宇宙熵增太快，我需要工具人。」这个宇宙的奇妙之处在于，最擅长制造混乱的人类，偏偏造出了最擅长收拾混乱的工具。 --- ## 六、宇宙在变乱，AI 在变整齐回到热力学。宇宙的终极命运是「热寂」： ⚖️ 所有能量均匀分布 ❄️ 不再有差异和结构 🌑 一切归于平静（死寂） **这是熵增的终极胜利。** 但在这个过程中，出现了两个「逆行者」： 1. **🧬 生命**：局部熵减，创造秩序 2. **🤖 AI**：生命的外包工具，加速熵减 **宇宙在变乱，AI 在变整齐。** 这很不科学，但这就是人类存在的意义： > 在宇宙的混乱中，点一支蜡烛。🕯️ > > 在黑洞的边缘，建一座图书馆。📚 > > 明知热寂必将到来，依然要把混乱整理成秩序。 **AI 就是这支蜡烛的放大器。** --- ## 七、那么，你该怎么用 AI？既然 AI 是熵减工具，那使用原则很简单： **把所有「整理混乱」的工作，都交给 AI。** ### 📧 信息整理 - ❌ 手动分类 1000 封邮件 - ✅ 让 AI 自动归档 ### 📝 知识提取 - ❌ 逐条阅读 500 条笔记 - ✅ 让 AI 生成知识图谱 ### ✍️ 内容生成 - ❌ 从零开始写文章 - ✅ 让 AI 生成初稿，你负责润色 ### 📊 决策辅助 - ❌ 盯着数据报表发呆 - ✅ 让 AI 提取关键指标 **原则只有一条：** **你的大脑只做「高熵减价值」的事，剩下的交给 AI。** 什么是「高熵减价值」？ ✅ 创造性思考（AI 只能模仿） ✅ 价值判断（AI 没有立场） ✅ 情感连接（AI 没有感受）什么是「低熵减价值」？ ❌ 信息分类（AI 更快） ❌ 数据整理（AI 不累） ❌ 格式转换（AI 不出错） **把低熵减工作交给 AI，把高熵减工作留给自己。** --- ## 八、行动指南 🎯 如果你认同「AI = 熵减工具」，那么从今天开始： **1️⃣ 列出你每天的「熵减工作」** - 整理邮件？分类文档？写总结？ **2️⃣ 筛选出「低熵减价值」的部分** - 重复性的、机械的、不需要创造力的 **3️⃣ 把这些工作交给 AI** - ChatGPT 整理邮件 - Claude 生成摘要 - AI 分类笔记 **4️⃣ 把时间留给「高熵减价值」的事** - 思考、创造、决策、连接 **你会发现：大脑终于不再死机了。** 💡 --- > 《AI时代漫游指南》第 44 章末尾写道： > > 「宇宙的熵会一直增加，直到热寂。 > 但在那之前，人类还有时间。 > 用 AI 整理混乱，用大脑创造意义。 > > 这可能是生命对抗熵增的最后一次尝试。 > 也可能是最漂亮的一次。」 --- **📚 延伸阅读** - 《生命是什么？》— 薛定谔（生命与熵的经典论述） - 《信息论》— 香农（信息熵的数学基础） - 《失控》— 凯文·凯利（复杂系统中的秩序涌现） --- **✨ 如果这篇文章对你有启发，欢迎：** - 👍 **点赞**：让更多人看到 - 📤 **分享**：帮助更多朋友理解 AI - 💬 **留言**：说说你的看法 **关注「AI时代漫游指南」，一起探索 AI 时代的效率方法论。** --- **作者**: 漫游君 **公众号**: AI时代漫游指南 **个人微信**: Witcher1999（备注：熵减）

日三省吾身，但让 AI 来省：我的信息蒸馏系统

漫游君 — Fri, 30 Jan 2026 00:00:00 GMT

> 《AI时代漫游指南》第 33 章记载： > 「人类花了 2500 年才学会反思的重要性，然后又花了 2500 年忘记去做。」 --- 2500 年前，曾子说了一句流传至今的话： **「吾日三省吾身。」** 每天问自己三个问题——工作尽心了吗？待人真诚了吗？学到的东西练了吗？曾子那个年代，一天能发生的事大概就是：见几个人，读一卷竹简，种一亩地。三个问题就能覆盖全天。 > 曾子每天信息摄入量约 500 字（一卷竹简）。现代人每天约 10 万字（微信+邮件+新闻+短视频字幕）。信息量涨了 200 倍，反思时间反而从「每日三省」变成了「每年零省」。 --- ## 🤔 现代人的反思困境说实话，你上一次认真复盘是什么时候？我猜大多数人的回答是：**年终总结的时候**。而且还是被公司逼的。问题不是我们不想反思，而是——**信息太多，根本省不过来。** | 类型 | 日产量 | 去向 | |------|--------|------| | 聊天消息 | 200+ 条 | 沉入记录海底 | | 工作笔记 | 3-5 篇 | 文件夹里积灰 | | 踩坑经验 | 若干 | 大脑里三天格式化 | | 灵光一闪 | 偶尔 | 转瞬即逝 | 一周后你记得的大概只有：周三那个 bug 很烦，周五的饭不好吃。 > 人类大脑的工作记忆容量是 7±2 个组块（米勒定律），但每天要处理几百个信息组块。这不叫信息过载，这叫认知大屠杀。 --- ## 💡 我的解法：让 AI 替我「三省吾身」我一直有写工作日志的习惯。每天记录做了什么、遇到什么问题、怎么解决的。但积累了十几篇日志后，发现一个尴尬事实： **我从来不回头看它们。** 日志越记越多，经验并没有越来越丰富。同样的坑换个场景又踩一遍。这就像——你每天写日记，但从不翻旧日记。日记本越来越厚，人却没变聪明。直到我想到一个问题：**如果我不会回头看，那谁会？** 答案是：**AI 会。** --- ## 🧪 六步蒸馏法：从日志到洞察我设计了一个「信息蒸馏」流程，让 AI 定期扫描工作日志，提炼结构化洞察。就像酿酒——原料是每天的流水账，蒸馏出来的是可复用的经验。 **流程**： ``` 确定范围 → 扫描日志（跳过已处理） → 按主题归类 → 提炼模式 → 写入知识库 → 标记已处理 ``` **实际效果**：我拿最近 4 天的工作日志做了第一次蒸馏—— 📥 **输入**：4 篇日志，约 800 行 📤 **输出**：5 个主题，29 条可复用模式 | 主题 | 模式数 | 举例 | |------|--------|------| | AI 记忆系统 | 8 条 | 「CLAUDE.md = 工作记忆，memory/ = 长期记忆」 | | Skill 管理 | 6 条 | 「Skill = 处方，经验 = 病历」 | | 需求管理 | 5 条 | 「design 字段记录决策理由是可追溯性关键」 | | 心跳机制 | 6 条 | 「双层心跳：应用层 30 分 + 连接层 30 秒」 | | 杂项技术 | 4 条 | 「Windows junction 替代 symlink」 | 如果靠自己复盘，我大概能想起来 3-5 条。**AI 把回收率从 15% 提升到接近 100%。** > 曾子日三省吾身，我的 AI 日二十九省我的日志。曾子如果有这工具，估计能省出一整部《论语》续集。 --- ## 🔄 关键设计：增量蒸馏蒸馏有个实际问题：每次全量扫描效率越来越低。我的解法——在每个日志文件头部加一个标记： ```yaml distilled: 2026-01-30 topics: [ai-memory-system, skill-management] summary: 五层记忆架构部署，skill审查优化 ``` **下次蒸馏时，AI 先读标记。看到已处理就跳过，只处理新文件。** 实测第二次蒸馏：4 个已标记文件被正确跳过，只处理了 1 个遗漏的大文件（1255 行），又提炼出 5 条新模式。 **工作量减少 70%。** 灵感来自会计的「已核」标记——核完一笔打个勾，下次不用重新核。 --- ## 📊 从「记日记」到「炼金术」 | 环节 | 传统做法 | 蒸馏做法 | |------|----------|----------| | 记录 | 写日志 | 写日志（一样） | | 整理 | 靠意志力翻旧笔记 | AI 自动扫描提炼 | | 输出 | 散落各处的笔记 | 按主题归类的洞察 | | 复用 | 想起来才用 | 主动关联同类问题 | | 持续性 | 平均坚持 17 天 | 系统自动运行 | **关键区别**：传统做法依赖意志力，蒸馏做法依赖系统。 **人的意志力是有限资源，系统是可靠资源。** --- ## ✅ 你也可以搭一个（三步法）不需要会编程，核心思路就三步： **第一步：坚持记录** 用任何你习惯的工具（备忘录、Notion、Obsidian），每天花 5 分钟记录：今天做了什么、遇到什么问题、怎么解决的。流水账就行。 **第二步：定期让 AI 蒸馏** 每周把最近的记录丢给 AI，问它： > 「请帮我从这些日志中提炼出可复用的经验模式。按主题分类，每条包含：模式名称、具体做法、适用场景。」 **第三步：沉淀到知识库** 把 AI 提炼出的模式按主题存到一个固定的地方。下次遇到类似问题，先查知识库。 ``` 每日 5 分钟记录 → 每周 10 分钟蒸馏 → 知识库自动增长 ``` 一年下来，你会拥有一个**完全属于自己的经验库**——不是搜来的通用知识，而是你亲身验证过的、有上下文的个人智慧。 --- ## 🎯 曾子的升级版回到开头的问题。曾子「日三省吾身」，省的是三个固定问题：忠、信、习。 2500 年后，我们面对的世界复杂了几个数量级，但反思的底层逻辑没变—— **从经历中提取模式，避免重复犯错，积累可复用的智慧。** | | 曾子版 | 现代版 | |--|--------|--------| | 信息量 | 一天一卷竹简 | 一天十万字 | | 反思方式 | 冥想内省 | AI 蒸馏 | | 输出形式 | 心中默记 | 结构化知识库 | | 持续性 | 靠意志力 | 靠系统 | **本质没变，工具升级了。** > 《AI时代漫游指南》第 33 章·终： > 「反思的终极形态，不是更强的意志力，而是更好的系统。」 --- **知识的价值不在于记录，而在于提炼。** 如果你也在被信息淹没，试试让 AI 替你反思 👇 📌 关注「AI时代漫游指南」，下一篇我们聊聊：如何给 AI 搭建一套「五层记忆系统」，让它越用越聪明。 *漫游君 | 2026.01.30*

🧠 给 Claude 装个外挂记忆：从小白到进阶的完整指南

漫游君 — Fri, 30 Jan 2026 00:00:00 GMT

> 《AI时代漫游指南》第 404 章记载： > 「404 不是终点，是起点。找不到文件，就创建一个存在的地方。」 > > 「宇宙中有 73% 的智慧生命体都在重复解释同一件事，因为他们从未给记忆一个存在的地方。剩下那 27% 是外星人，他们用心灵感应。」 --- ## 朋友的困惑上周一个朋友问我：「我每次跟 Claude 聊天，都要重新解释一遍背景，好累啊。它就不能记住我吗？」她用 Claude 写文章，每次都要这样开场： ``` 我是写效率工具文章的，面向非技术人群，语气要轻松幽默，1500 字左右，开头要有痛点，结尾要有金句... ``` **复制粘贴了 50 次之后，她崩溃了。** 更糟的是，有时候聊着聊着，Claude 还会说「上下文快满了，需要压缩对话」，然后就把之前的内容忘了一半。我看了一眼她的用法，笑了：「你的问题不在 Claude，在于你不知道它有'外挂记忆'功能。」 --- ## 200K tokens 的真相：真的够用吗？先说数字。**Claude 的上下文窗口是 200K tokens**，约等于 15 万汉字，看起来能装下一本《红楼梦》了。但真相是：**无论你用哪种 Claude，都是这个限制**： | 使用方式 | 上下文容量 | 使用场景 | |---------|-----------|---------| | Claude.ai 网页版 | 200K tokens/对话 | 随便聊聊 | | **Projects 知识库** | 200K tokens/项目 | 上传文档作为记忆 ✅ | | Claude Code 命令行 | 200K tokens/对话 | 本地开发 | > **编者注**：这就像三家手机店，一家卖 iPhone、一家卖华为、一家卖小米，但电池容量都是 5000 毫安。换个壳不会让电池变大。 **关键发现**：你朋友遇到的"压缩对话"问题，不是因为她用错了工具，而是因为她**没用对方法**。 200K tokens 听起来很多，但对话几轮下来，你会发现： ``` 第 1 轮：你(3K) + Claude(8K) = 11K 第 2 轮：你(2K) + Claude(6K) = 8K（累计 19K）第 3 轮：你(2K) + Claude(5K) = 7K（累计 26K） ... 第 10 轮：上下文快满了，需要压缩 😭 ``` > **编者注**：根据《漫游指南》统计部门（如果它存在的话）的不完全统计，宇宙中 99.7% 的对话压缩事故，都发生在用户试图把整个项目历史塞进一次对话的时候。另外 0.3% 是因为用户问了「宇宙的终极答案」，Claude 回答了 42 遍还没说清楚。 **解决方案很简单**：给 Claude 装个「外挂记忆」。 --- ## 第一部分：技术小白方案 - Projects 模式（3 分钟学会）如果你是技术小白，**这部分就够用了**。不用装软件，不用学命令，网页上点几下就搞定。 ### 什么是 Projects？ Projects 是 Claude.ai 的「工作空间」功能，可以理解为： **给 Claude 建一个专属记事本，里面装着你希望它永远记住的东西。** 比如： - 你的写作风格（「我喜欢用比喻，不要太严肃」） - 你的工作背景（「我是产品经理,不懂代码」） - 你的项目资料（上传文档、文章、数据） **最关键的是**：Projects 里的内容**不占对话上下文**。 > **编者注**：这就像你的大脑分两个区： > - **工作记忆**：正在聊的话题（200K tokens，会满） > - **长期记忆**：Projects 知识库（200K tokens，单独计算） > > 对话满了可以清空重来，但长期记忆永远在。 ### 创建你的第一个 Project（手把手教学） **Step 1：进入 Projects 页面** 访问 [claude.ai/projects](https://claude.ai/projects)，或者在 Claude.ai 左侧菜单点击「Projects」。 **Step 2：新建项目** 点击右上角「+ New Project」，输入： - **项目名称**：比如「我的写作助手」 - **描述**：可以不填（Claude 不会读这个） **Step 3：上传知识库** 在项目页面右侧，你会看到「Project Knowledge」区域。这里是重点！ **可以上传什么？** - 你写过的文章（让 Claude 学会你的风格） - 工作文档（项目资料、会议记录） - 研究资料（论文、报告） - 参考资料（行业报告、竞品分析） **能上传多少？** - 最多 200K tokens（约 500 页文本） - 支持 PDF、Word、TXT、Markdown 等格式 **Step 4：设置自定义指令（可选但强烈推荐）** 在「Custom Instructions」区域，写下你希望 Claude 遵守的规则。 **示例（写作助手）**： ``` 你是我的写作助手。我写效率工具类文章，面向非技术人群。风格要求： - 语气轻松幽默，不要太严肃 - 多用比喻和故事，少用术语 - 1500-2000 字，开头要有痛点，结尾要有金句作者署名：漫游君公众号：AI时代漫游指南 ``` **其他场景参考**：工作助手、学习助手、代码助手都可以参考这个模板，改成你的需求和风格。 **Step 5：开始对话** 现在，在这个 Project 里发起对话，Claude 会自动： 1. 读取你上传的所有文档 2. 遵守你设置的自定义指令 3. 记住之前的对话历史 **最爽的是**：换个新对话，上传的知识库和自定义指令依然生效！ ### 实战案例：我朋友的真实使用我朋友创建了一个「写作项目」，上传了： - 她之前写的 10 篇文章（学习风格） - 目标读者画像文档（谁会看她的文章） - 写作规范（标题公式、结构模板）设置的自定义指令： ``` 你是我的写作助手。面向想用 AI 提升效率的知识工作者（非程序员）。风格：轻松幽默，多用比喻结构：痛点 → 方案 → 案例 → 总结字数：1500-2000 字署名：漫游君 ``` **现在她只需要说**： ``` 「帮我写一篇关于 Claude Projects 的文章」 ``` Claude 就能： - 自动套用她的写作风格 - 面向正确的读者群体 - 生成符合结构的完整文章 **不用每次都复制粘贴那一大段背景了！** 🎉 ### Projects 的三个最佳实践 **1. 一个主题一个 Project** 别把所有东西混在一个 Project 里。分开管理： - 写作项目：文章、风格指南 - 工作项目：项目文档、会议记录 - 学习项目：笔记、资料 > **为什么？** 因为每个 Project 有 200K tokens 限制。混在一起容易超。 **2. 上传「摘要」而非「全文」** 别把 500 页的论文全扔进去。提炼核心内容： - ✅ 论文摘要 + 核心结论 - ✅ 书籍的章节大纲 + 金句 - ❌ 整本书的 PDF **3. 定期清理对话，但保留知识库** 对话历史满了？点「New Chat」清空就行。**知识库会保留**，不会丢失。 --- ## 够用了吗？还是想要更多？如果你只是： - 偶尔用 Claude 写写东西 - 查查资料、问问问题 - 不需要频繁修改本地文件 **那第一部分的 Projects 模式完全够用了。** 👆 但如果你： - 需要管理复杂项目（多个模块、大量文件） - 经常要让 Claude 读写本地代码 - 想要更精细的「记忆架构」 - 愿意花 10 分钟学点新东西 **那么，欢迎来到第二部分：进阶玩家的世界。** 👇 --- ## 第二部分：进阶方案 - Claude Code + CLAUDE.md（给愿意折腾的人） ### 为什么需要进阶？Projects 的三个局限 Projects 模式很好，但有些场景它搞不定： **1. 无法直接编辑本地文件** Projects 是网页版，你只能复制粘贴。如果你有 50 个文件要修改，就得： ``` 复制文件内容 → 粘贴给 Claude → 复制 Claude 的回答 → 粘贴回文件 ``` **重复 50 次，手会废。** **2. 无法运行命令和测试** Claude Code 可以直接执行命令： ``` "帮我运行测试" → Claude 执行 pytest → 看到报错 → 自动修复 ``` Projects 做不到这个。 **3. 无法精细控制「记忆结构」** Projects 是把所有文档混在一起。如果你有复杂项目（多模块、多层级），需要更灵活的组织方式。 **如果你遇到这些问题，那就该升级到 Claude Code 了。** --- ### Claude Code 是什么？简单说：**一个能在命令行里跑的 Claude，可以直接读写你的文件、执行命令。** 安装很简单： - macOS/Linux：`curl https://claude.ai/install.sh | bash` - Windows：去 [claude.ai/download](https://claude.ai/download) 下载安装包装完之后，在项目文件夹里执行 `claude`，就能和 Claude 对话了。 **关键区别**： | 功能 | Claude.ai Projects | Claude Code | |------|-------------------|-------------| | 读取文件 | 需要复制粘贴 | 自动读取本地文件 | | 修改文件 | 复制粘贴回去 | 直接修改保存 | | 运行命令 | 做不到 | 可以执行任何命令 | | 知识库 | 网页上传 | **CLAUDE.md 文件** ✅ | --- ### CLAUDE.md：比 Projects 更强大的记忆系统 **核心概念**：在项目根目录创建一个 `CLAUDE.md` 文件，Claude Code 每次启动会自动读取。 **它就像 Projects 的「自定义指令 + 知识库」，但更灵活。** **我的实际案例** 我管理的 content-manager 项目有这些特征： - 40+ 个 API 端点 - 15 个微服务 - 5000+ 行核心业务逻辑 - 3 个大型数据库 - 每周迭代 2-3 个新功能如果每次都把整个项目代码扔给 Claude，我会疯掉。所以我建立了这样的「分层记忆架构」： ``` 项目根目录/ ├── CLAUDE.md # 🧠 项目总体说明（工作记忆） │ ├── 系统架构图 │ ├── 三端同步方案 │ ├── 依赖关系 │ └── 快速开始命令 ├── services/ │ ├── content_manager/ │ │ ├── CLAUDE.md # 模块说明（500 行，不超过 5K tokens） │ │ ├── roadmap.yaml # 需求追踪 │ │ ├── app.py │ │ └── services/ # 源码（需要时再读） │ └── other_services/ └── memory/ ├── logs/ # 今日灵感、决策记录 │ ├── 2026-01-30.md │ └── decision-log.md └── knowledge/ # 技术文档、最佳实践 ├── flask-performance.md ├── claude-collaboration.md └── deployment-guide.md ``` **核心策略**： 1. **CLAUDE.md = 工作记忆** - 项目概览（5K tokens） - API 路由清单（3K tokens） - 关键配置（2K tokens） - 累计约 10K tokens 2. **各模块 CLAUDE.md = 模块记忆** - 仅包含该模块的核心信息 - 不超过 5K tokens - 存放在模块目录里 3. **roadmap.yaml = 状态追踪** - 当前版本、已完成功能、计划中功能 - 已知问题和解决方案 - 约 2K tokens 4. **memory/ 目录 = 长期学习** - 决策理由（为什么选择这个方案） - 技术教训（踩过的坑） - 可复用的代码片段 **这样做的好处**： | 指标 | 传统方式（把所有代码扔进对话） | 分层记忆架构（CLAUDE.md） | |------|------|------| | 每次对话初始化成本 | 80-120K tokens | 只需要 10-15K tokens | | 代码查找效率 | 「帮我找一下……」（浪费 tokens） | 「读 services/xxx/CLAUDE.md」（精准定位） | | 项目理解 | 每个对话都要重新解释 | 一次理解，持续沿用 | | 扩展新模块 | 对话越来越重，效率下降 | 新建 CLAUDE.md，独立管理 | | 知识积累 | 每个对话都是一次性的 | 保存在 memory/ 持续可复用 | > **编者注**：这就像盖房子，Projects 模式是「租公寓」（拎包入住，但不能改结构），Claude Code + CLAUDE.md 是「自己盖别墅」（想怎么设计就怎么设计）。 --- ### 真实数据：效果如何？我用这个方案管理 content-manager 项目 3 个月了，数据说话： **Token 消耗对比**： - 传统方式：每次对话平均 80-120K tokens（项目上下文） - CLAUDE.md 方式：每次对话只需 12-18K tokens **效率提升**： - 对话轮数：从 5-7 轮 → 12-15 轮（同样 200K 限制） - 响应精准度：从 70% → 92%（Claude 理解更清楚） - 开发周期：从 2-3 天 → 1 天 **知识沉淀**： - memory/ 目录现在有 40+ 篇决策记录 - 新人（或新的 Claude 对话）加入，有完整历史可查 **更重要的副作用**：我自己也变清晰了。因为要写 CLAUDE.md，我被迫思考： - 这个功能的核心逻辑是什么？ - 为什么选这个方案而不是另一个？ - 遇到的坑应该怎么记录，才能让未来的我不再踩？ **文件库从「给 AI 用的」变成了「给我用的」。AI 只是副产品。** --- ### 如何设计你的 CLAUDE.md 架构？给你一个可以直接抄的框架： **Step 1：写根目录 CLAUDE.md** 在项目根目录创建 `CLAUDE.md`，包含 6 个核心部分： - 项目概览（200 字说清楚是干什么的） - 系统架构（简单流程图，Mermaid 格式） - 核心概念（3-5 个关键术语） - 快速开始（运行命令） - API 清单（主要接口） - 已知问题（踩过的坑） **控制在 1500 字以内**，占用不超过 3K tokens。 **Step 2：创建 roadmap.yaml** 追踪项目状态： ```yaml current_version: v2.35.0 status: in_development completed: - 用户认证模块 - 文章发布功能 - 微信接口集成 in_progress: - 批量操作功能 - 性能优化 planned: - 数据导出 - API 限流 known_issues: - 高峰期可能超时（临时方案：增加重试） - 图片上传大小限制 5MB ``` **Step 3：建 memory/ 文件夹** 保存长期知识： ``` memory/ ├── decisions/ # 重要决策及理由 │ └── why-use-flask.md ├── patterns/ # 可复用代码模式 │ └── api-error-handling.py └── learnings/ # 踩坑记录 └── database-migration-hell.md ``` 每周总结一次，把重要的经验写下来。 **Step 4：模块级 CLAUDE.md（可选）** 如果项目很大，每个模块建一个： ``` services/ ├── content_manager/ │ ├── CLAUDE.md # 这个模块的说明（500 行） │ └── app.py └── wechat_service/ ├── CLAUDE.md └── app.py ``` **Step 5：每次对话这样开场** ``` 我正在开发 [项目名]。请先读 CLAUDE.md 了解项目背景，然后我来说具体需求。 ``` Claude 会自动读取 CLAUDE.md，迅速进入状态。 **消耗对比**： - 传统方式：加载整个项目 80K tokens - CLAUDE.md 方式：只加载 15-25K tokens **剩下 175K tokens 用于深度对话，而不是加载上下文。** --- ### 实战案例：批量操作功能开发 > **编者注**：如果你看到这里已经有点晕了，别担心。《漫游指南》编者部当年看到这套架构时，也晕了整整三天。最后我们意识到：复杂的不是架构，而是我们试图用一段话解释清楚它。所以我们决定用一个真实案例来说明。（这就是你即将看到的内容。）我最近要给 content-manager 添加「批量操作」功能。对比一下两种做法： **传统做法**（Projects 或把代码扔进对话）： ``` 1. 加载整个项目代码（80K tokens） 2. 解释需求（5K tokens） 3. Claude 生成方案（15K tokens） → 累计 100K tokens，只对话了 1 轮 4. 第二轮提问，发现上下文快满了... ``` **CLAUDE.md 做法**： ``` 1. 加载 CLAUDE.md（10K tokens） → Claude 知道：项目结构、API 格式、数据流 2. 加载 services/content_manager/CLAUDE.md（5K tokens） → Claude 知道：有哪些服务、当前版本、已知问题 3. 加载 roadmap.yaml 的 v2.35.0 部分（1K tokens） → Claude 知道：「批量操作」具体要做什么 4. 说出需求（3K tokens） 5. Claude 生成代码（20K tokens） → 累计 39K tokens，还剩 161K tokens 6. 我：「这个地方能优化吗？」（2K tokens） 7. Claude：「可以用异步处理」（8K tokens） 8. 我：「帮我加个进度条」（2K tokens） 9. Claude：「好的，代码如下」（10K tokens） ... ``` **消耗对比**： - 传统方式：100K tokens，1-2 轮对话就满了 - CLAUDE.md 方式：初始 19K tokens + 可对话 10+ 轮 **效率差距：5-10 倍。** --- ## Projects vs Claude Code，该选哪个？总结一下两种方案的适用场景： | 场景 | 推荐方案 | 理由 | |------|---------|------| | 写文章、做研究 | **Projects** | 网页版够用，不用装软件 | | 管理多个写作主题 | **Projects**（多个项目） | 每个主题建一个 Project | | 日常问答、学习 | **Projects** | 零门槛，随时随地 | | 需要频繁修改本地文件 | **Claude Code** | 直接读写文件，不用复制粘贴 | | 复杂项目开发 | **Claude Code + CLAUDE.md** | 精细控制记忆结构 | | 需要运行命令/测试 | **Claude Code** | 可以执行任何命令 | | **技术小白** | **Projects** ✅ | 不用学命令行 | | **愿意折腾的进阶玩家** | **Claude Code** ✅ | 解锁完整能力 | > **编者注**：这就像手机和电脑的关系。手机（Projects）够用且方便，但如果你要剪视频、写代码，还是得用电脑（Claude Code）。不是谁更好，而是看你的需求。 > > 当然，还有第三种选择：什么都不用，每次对话重新解释一遍背景。据《漫游指南》第 114514 章记载，这种方法在宇宙中极其流行，主要流行于那些拥有无限耐心和无限寿命的物种中。遗憾的是，地球人不在此列。 --- ## 组合拳：Projects + Claude Code 一起用其实你可以**两个都用**： - **Projects**：管理知识库（文章、资料、风格指南） - **Claude Code**：执行具体任务（写代码、修改文件） **实际工作流**： ``` 1. 在 Projects 里整理资料、学习新知识 2. 当需要写代码时，切换到 Claude Code 3. Claude Code 读取本地的 CLAUDE.md（和 Projects 同样的内容） 4. 完成任务后，把经验总结写回 memory/ 5. 下次在 Projects 里查阅这些经验 ``` **这就是终极形态**：网页版管理知识，命令行执行任务。 --- ## 最后：你该从哪里开始？看到这里，你可能有点懵。给你一个清晰的路径： **技术小白 / 日常使用**： 1. 直接用 Projects（看第一部分教程） 2. 30 分钟上手，够大部分场景用了 3. 用 2 周后评估是否需要升级 **进阶玩家 / 复杂项目**： 1. 先用 Projects 理解「外挂记忆」概念 2. 遇到瓶颈时（频繁改本地文件、需要运行命令） 3. 再升级到 Claude Code（看第二部分教程） **核心原则**：先用简单的，不够再升级。别一开始就上复杂方案。 --- ## 写在最后我朋友用了 Projects 两周后，发来消息：「现在写文章再也不用复制粘贴那一大段背景了，爽！」「但我发现 Claude 开始懂我的风格了，有时候它生成的句子，我都分不清是我写的还是它写的。」 **这就对了。** 外挂记忆的终极目标，不是让 AI 记住更多，而是让 AI **更懂你**。 Projects 是记忆，CLAUDE.md 是理解。选一个开始用，一个月后你会感谢自己。 --- > 《AI时代漫游指南》第 404 章结语： > 「记忆的本质，不在于存储，而在于调用。」 > 「你给 AI 一个存在的地方，它就给你一个不再重复的未来。」 --- **知识的价值不在于存储，而在于随时调用。** --- ## 📮 最后说两句如果这篇文章帮你解决了「每次都要重复解释」的问题，不妨： - **点个「在看」**：让更多人发现 Projects 的便利 - **转发到朋友圈**：帮朋友省下复制粘贴的时间 - **留言告诉我**：你用 Projects 管理什么场景？下一篇聊：**如何用 Claude 管理 10 个项目还不混乱**。 --- 📌 **关注「AI时代漫游指南」**，一起用 AI 提升效率，而不是被 AI 裹挟。 *漫游君 | 2026.01.30* --- **P.S.** 如果你看完这篇文章后，发现 Claude 还是记不住你，可能是因为你忘了保存 Project。或者是因为宇宙的熵增定律，或者是因为你的猫踩了键盘删除了 CLAUDE.md。 **总之，不会是我的问题。** — 《AI时代漫游指南》编者部

AI 也需要心跳：从晶振到 Agent 的自治哲学

漫游君 — Thu, 29 Jan 2026 00:00:00 GMT

> 《AI时代漫游指南》第 73 章记载： > 「宇宙中所有能自主运转的系统，无论是心脏、晶振还是 AI，都需要一个持续跳动的节拍器。没有心跳的系统，只是一堆等待被调用的代码。」 --- ## 🫀 人类为什么需要心跳？这个问题看起来很蠢，但值得认真想一想。心脏每分钟跳动 60-100 次，不需要你下命令，不需要你提醒，它就是在那里"咚咚咚"地跳。你睡着了它在跳，你发呆了它在跳，你忘记它存在了它还在跳。 **心跳的本质是什么？** 是一个**自治系统的时钟源**。它让血液持续循环，让氧气持续输送，让身体的每一个细胞都能获得它需要的资源。没有心跳，身体就是一堆静止的器官，等着某个外力来推动。 > 编者注：人类大脑耗氧量占全身 20%，但重量只占 2%。所以心脏本质上是在给这个"耗能大户"持续供电。AI 模型的 GPU 也是耗能大户，这个类比出奇地精准。 --- ## 💎 晶振：硬件世界的心脏如果你拆开任何一个电子设备——手机、电脑、甚至智能手表——你都会发现一个小小的银色元件：**晶振**。它通常比米粒还小，上面印着"32.768K"或"12M"之类的数字。 **它做什么？** 每秒震动 32,768 次（或几百万次），产生一个极其稳定的脉冲信号。这个信号就是整个电子系统的"心跳"。 CPU 根据它来决定什么时候执行下一条指令，内存根据它来决定什么时候刷新数据，所有的时序电路都在听它的指挥。 > 编者注：32768 = 2^15，这不是巧合。工程师选这个频率，是因为它能被 2 整除 15 次，最后正好变成 1 Hz，用来驱动秒针。数学之美，藏在这颗米粒大小的元件里。 **没有晶振会怎样？** CPU 不知道什么时候该干活。就像一个没有心跳的人，器官都在，但没有节奏，没有协调，只是一堆静止的硅片。 --- ## ⏱️ 实时系统：软件世界的呼吸硬件有了晶振，软件呢？在操作系统层面，有一个概念叫**时钟中断**。晶振每跳动一定次数，就会向 CPU 发送一个中断信号： "嘿，又过了 1 毫秒，该检查一下有没有什么事情要做了。" 这就是**实时系统**的核心理念： - **周期性**：每隔固定时间，主动检查一次 - **确定性**：响应时间有明确上界，不会"随缘" - **自治性**：不需要外部触发，自己驱动自己汽车的 ABS 刹车系统、飞机的飞控系统、医疗设备的监护仪——所有对时间敏感的系统，都建立在这个"心跳"机制之上。 ```mermaid flowchart LR A[晶振] --> B[分频器] B --> C[定时器] C --> D[CPU中断] D --> E{中断处理} E --> E1[1. 检查任务队列] E1 --> E2[2. 调度就绪任务] E2 --> E3[3. 更新系统时间] E3 --> E4[4. 返回] ``` 每 1ms 触发一次，操作系统的"心跳"就是这么来的。 > 编者注：Linux 内核的默认时钟中断频率是 250 Hz（每秒 250 次），Windows 是 64 Hz。这意味着操作系统每 4-15 毫秒就会"心跳"一次。你以为电脑在发呆，其实它的心脏一直在跳。 --- ## 🤖 AI Agent 的心跳：让 AI 学会"想你" 好，铺垫了这么多，终于到正题了。 **问题**：现在的 AI 工具（ChatGPT、Claude、Gemini）都有一个共同特点—— **你问它才答。** 你不说话，它就安静地等着。你关掉页面，它就消失了。它不会主动找你，不会提醒你待办事项，不会在你忘记之前轻轻拍拍你的肩膀。 **这不是真正的 AI Agent。** 真正的 Agent，应该像一个靠谱的助理： - 你交代的事情，它会持续跟进 - 有进展了，它会主动汇报 - 你忙的时候，它知道不打扰 - 你忘了的事情，它会提醒你要实现这个，AI Agent 需要一个东西：**心跳**。 --- ## 🔧 拆解 moltbot：900 行代码的心跳引擎最近在读一个开源项目 moltbot 的源码，发现它的 `heartbeat-runner.ts` 写得相当精巧。 900 行代码，实现了一个完整的 AI Agent 心跳机制。让我拆解一下它的核心设计： ### 设计 1️⃣：周期性唤醒和实时系统的时钟中断一样，Agent 会定期醒来，检查有没有什么事情需要处理。默认每 15 分钟一次（可配置）。不需要用户触发，它自己会醒。 ### 设计 2️⃣：静默时段聪明的 Agent 知道什么时候该闭嘴。你可以配置活跃时段，比如 09:00 - 22:00。在这个时间段外，心跳依然在跳，但不会发送消息打扰你。 > 编者注：这个设计考虑了跨午夜的情况。如果你设置 22:00 - 06:00 静默，它能正确处理。细节见真章。 ### 设计 3️⃣：24 小时去重如果 AI 要说的话和上次一样，而且距离上次不到 24 小时，就不说了。 **这个设计太重要了。** 没有去重机制的 AI，会像一个焦虑的家长，每隔 15 分钟问你一遍"作业写了吗？"。有了去重，它只会在真的有新情况时才开口。 ### 设计 4️⃣：HEARTBEAT.md Agent 的工作区里有一个特殊文件 `HEARTBEAT.md`，相当于 AI 的待办清单。心跳唤醒时，它会读取这个文件，看看有什么需要处理的。如果文件是空的（或者只有注释），就跳过这次心跳，节省 API 调用。 ### 设计 5️⃣：心跳不保活这是一个容易忽略但极其重要的设计：**心跳不应该让会话永远不过期**。 moltbot 的做法是：心跳检查完毕后，**恢复**之前的时间戳。这意味着会话的过期时间由"最后一次真实交互"决定，而不是"最后一次心跳"。 > 编者注：这就像一个好助理——他会定期检查你的日程，但不会因为检查了一眼就说"老板今天和我互动过了"。关心和打扰是两回事。 ### 设计 6️⃣：异步事件触发除了定时心跳，还有**事件驱动心跳**。当一个异步任务（比如后台运行的脚本）完成时，会触发一次特殊的心跳。 **这就是真正的 Agent 行为**：你交代一个任务，它在后台执行，完成后主动向你汇报。不需要你反复去问"好了没？好了没？" --- ## 🛡️ 六道关卡把上面的设计串起来，一次心跳的完整流程： ```mermaid flowchart TD A[定时器触发 / 异步事件触发] --> B{心跳已禁用?} B -->|是| X1[跳过] B -->|否| C{静默时段?} C -->|是| X2[跳过] C -->|否| D{队列有任务?} D -->|是| X3["跳过 (别打断对话)"] D -->|否| E{待办清单空?} E -->|是| X4["跳过 (省API)"] E -->|否| F[调用 LLM] F --> G{响应为空?} G -->|是| X5[发送 OK / 静默] G -->|否| H{和上次重复?} H -->|是| X6["跳过 (24h去重)"] H -->|否| I[发送消息] I --> J[记录去重信息] J --> K["恢复会话时间 (心跳不保活)"] ``` **六道关卡**，只有真正需要告诉你的事情，才能通过。 --- ## 🧬 三层心跳：从碳基到硅基回顾一下我们讲的三层"心跳"： | 层级 | 载体 | 频率 | 作用 | |------|------|------|------| | 生物层 | 心脏 | 1-2 Hz | 驱动血液循环 | | 硬件层 | 晶振 | kHz-GHz | 驱动电路时序 | | 软件层 | 时钟中断 | 64-1000 Hz | 驱动任务调度 | | Agent 层 | 心跳机制 | 0.001 Hz | 驱动自治行为 | 频率越来越低，但抽象层次越来越高。 **心脏**让血液流动。 **晶振**让电路运转。 **时钟中断**让软件调度。 **Agent 心跳**让 AI 学会"想你"。 > 编者注：如果把 AI Agent 看作一种"数字生命"，那么心跳机制就是它的第一个生命体征。它不再是一个被动的工具，而是一个有自主节律的存在。 --- ## 💡 写在最后回到开头的问题：**AI 为什么需要心跳？** 因为没有心跳的 AI，只是一个等待被调用的函数。有了心跳的 AI，才是一个能自主运转的 Agent——它会在你需要之前，轻轻拍拍你的肩膀。这 900 行代码，实现的不只是一个定时器。它实现的是 AI 从"工具"到"助理"的进化。 > 「真正的智能，不在于回答问题的速度，而在于知道什么时候该主动开口。」 > —— 《AI时代漫游指南》 --- **延伸阅读**： - 实时系统入门：《嵌入式实时操作系统原理》 - 下一篇：MCP 协议——让 AI Agent 长出手脚 --- *如果这篇文章让你对 AI Agent 有了新的认识，欢迎**转发**给同样在探索 AI 的朋友。* *关注「AI时代漫游指南」，一起漫游这个有趣的时代。* 👋

AI 越强，需求管理越重要

漫游君 — Wed, 28 Jan 2026 00:00:00 GMT

> 《AI时代漫游指南》第 28 章记载：「当人类终于可以用自然语言编程时，他们遇到了一个古老的问题——自然语言本身就是模糊的。」你有没有这样的经历：对 Claude 说"加个暗色模式"，它刷刷写了 200 行代码。你一看——颜色是改了，但不跟随系统设置，不记住偏好，只改了首页没改其他页面。 **你说的每个字它都懂了。但你想要的，它只猜对了三分之一。** 这不是 AI 的问题。这是「需求」的问题。 ## 🚀 Vibe Coding：说人话就能写代码 2025 年，Andrej Karpathy 提出了 Vibe Coding 这个概念——你不用写代码，只需要描述你要什么，AI 来实现。 Claude Code、Cursor、Windsurf……这些工具让"说人话写软件"变成了现实。但用了几个月后，你会发现一件事： **写代码变简单了，但做对的东西反而更难了。** ## ❓ 需求文档不是多余了吗？传统软件开发： ``` 人写需求 → 人写设计 → 人写代码 → 人写测试 ``` Vibe Coding： ``` 人说需求 → AI 理解 → AI 写设计+代码+测试 ``` 中间环节全部被 AI 接管了。于是很多人觉得：需求文档可以不写了吧？ **这是一个危险的误解。** > **编者注**：这就像说"有了导航就不用知道目的地"。AI 是你的司机，但你得告诉它去哪。你说"随便开开"，它真的会随便开。 ## 💡 核心价值一：意图对齐你说"加个暗色模式"，Claude 可能理解为六种完全不同的实现 👇 | 你以为的 | Claude 可能做的 | |----------|----------------| | 跟随系统设置 | 只加了个手动切换按钮 | | 全站生效 | 只改了当前页面 | | 记住用户偏好 | 每次刷新都重置 | | 平滑过渡动画 | 直接切换，闪瞎眼 😵 | 这不是 Claude 笨，是**自然语言天生有歧义**。需求文档的作用，是迫使你在动手前想清楚到底要什么。四行话，省掉三轮返工： ``` ✅ 支持手动切换 + 跟随系统设置 ✅ 偏好存储到 localStorage ✅ 全站所有页面生效 ✅ 切换时有 300ms 过渡动画 ``` ## 🧠 核心价值二：跨会话记忆这是很多人忽略的关键问题。 **Claude 没有跨会话记忆。** 每次新对话，它都是一张白纸。你上周花了两小时讨论的架构决策、踩过的坑、放弃的方案——全部归零。需求文档就是**记忆的外化**： 📌 **决策上下文**：为什么选方案 A 不选 B？ 📌 **失败记录**：哪些方案试过但行不通？ 📌 **进度追踪**：当前做到哪了？ > **编者注**：人类发明文字是为了跨越时间传递信息。需求文档对 AI 的作用一模一样——跨越会话传递记忆。只不过这次，健忘的不是后代，是你的 AI 助手。我自己的项目里，每次新开一个 Claude 会话，第一件事就是把 CLAUDE.md 喂给它。没有它，Claude 每次都像**新来的实习生**。有了它，像是**干了三个月的老员工**。 ## ✅ 核心价值三：质量验收当 AI 写完代码，你怎么判断它做对了？ ``` ❌ 没有需求文档： "代码没语法错误，测试通过" → PASS 但可能做的东西完全不对 ✅ 有需求文档： "要求3种主题，只实现了2种" → FAIL "要求记住偏好，没有持久化" → FAIL → 精准定位差距 ``` 当你用一个 Claude 写代码、另一个 Claude 做 QA 时，需求文档就是它们之间的**"合同"**。 ## 📚 50 年前的智慧，今天更好用需求管理不是什么新问题。软件工程 50 年历史里，前辈们早就为"怎么把需求说清楚"操碎了心。这些方法论在 Vibe Coding 时代反而焕发了第二春——**因为 AI 比人类更需要明确的指令。** **① 用户故事（User Story）** 一句话模板： ``` 作为 [角色]，我想要 [功能]，以便 [价值] ``` 三个槽位，强迫你回答三个问题——谁在用、要什么、为什么。Claude 拿到这三个信息，比你说"加个功能"靠谱十倍。好用户故事还有个 **INVEST 原则**（6 个标准）： - **I**ndependent — 一个 prompt 解决一件事，别堆需求 - **N**egotiable — 给 AI 留实现空间，别规定用什么库 - **V**aluable — 别让 AI 做用户看不到的重构 - **E**stimable — 太大就拆，一次对话做不完就拆 - **S**mall — 一个 prompt 一个功能 - **T**estable — 给 AI 明确的验收标准 > **编者注**：INVEST 原则发明于 2003 年，本意是教人类写好需求。20 年后发现，它更像是给 AI 写的 prompt 工程指南。历史总是押韵的。 **② 验收标准（Given-When-Then）** ``` Given 用户在设置页面 When 点击"暗色模式"开关 Then 全站切换为暗色主题，且刷新后保持 ``` 这就是测试用例的自然语言版本。Claude 看到这个格式，能直接生成对应的测试代码。**需求和测试，一步到位。** **③ JTBD（Jobs to Be Done）** 用户买电钻不是想要电钻，是想要**墙上有个洞**。 ``` 传统需求：加个暗色模式 JTBD 视角：用户晚上看文章眼睛疼 ``` 当你告诉 Claude "用户晚上看文章眼睛疼"，它可能不止给你暗色模式——还会建议降低对比度、调整字号。 **说清楚问题，比规定方案更好。** **④ MoSCoW 优先级** | 级别 | 含义 | |------|------| | **M**ust have | 必须有，没有不能发布 | | **S**hould have | 应该有，重要但不致命 | | **C**ould have | 可以有，锦上添花 | | **W**on't have | 不做，明确排除 | 其中最被低估的是 **Won't have**。 Claude 最大的毛病之一是"做太多"。你说加个表单，它顺手加了验证、动画、国际化 🤦 **Won't have 就是给 AI 画红线——明确说"不做什么"，和说"做什么"一样重要。** ## 🛠️ 实操：20 行搞定需求文档别被"需求文档"这四个字吓到。不是写 PRD，不需要画流程图。 **只需要三样东西** 👇 **① 用户故事（一句话）** ``` 作为博客读者，我想要暗色模式，以便晚上看文章不刺眼。 ``` **② 验收标准（怎么算做完）** ``` ✅ 支持手动切换和跟随系统 ✅ 偏好持久化 ✅ 全站生效 ✅ 过渡动画 ≤ 300ms ``` **③ 边界说明（什么不做）** ``` ❌ 不需要日落自动切换 ❌ 不需要自定义主题色 ❌ 不需要每个页面单独设置 ``` 三个部分，加起来不超过 20 行。 **写一次，省十次返工。** ## 🎯 一个反直觉的结论 **AI 越强，需求管理越重要。** 传统开发中，程序员会自动补全需求的模糊地带——靠经验、靠常识、靠走过去问一句"你这个是什么意思"。 AI 不会走过来问你。你不说的，它就自己决定。而且它的"自己决定"有时候很离谱。这不是 AI 的缺陷，这是工具的特性。 **锤子不会问你"你确定要钉这里吗？"——但好的需求文档会。** > 「AI 时代最稀缺的能力，不是写代码，是说清楚你到底想要什么。」 > — 《AI时代漫游指南》第 28 章 --- **🔗 关注「AI时代漫游指南」**，一起用 AI 提升效率。觉得有用？点个**在看** 👇 让更多人少走弯路。

ClawdBot刷屏，但这事我半年前就干了

漫游君 — Tue, 27 Jan 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 61 章记载： > > 「真正的技术趋势，不是在 Hacker News 上出现的那天才开始的。它早就在某个人的树莓派上跑了半年了。」 --- 这两天科技圈最大的瓜，是一只"龙虾"🦞。一个叫 **ClawdBot** 的开源项目，让 Cloudflare 股价涨了 9%。GitHub 一夜冲上几千 Star。创始人甚至被迫改名（商标问题）。更离谱的是，有人蹭热度发了个同名山寨币，16 分钟拉到 1600 万美金市值，然后暴跌 90%。 2026 年了，AI 圈的魔幻一如既往。 **那 ClawdBot 到底做了什么？** 一句话：**让 Claude 住进你的聊天软件里。** WhatsApp、Telegram、Slack、Discord、iMessage……你在聊天窗口 @它，它就能读你的文件、执行命令、记住上下文，甚至自己给自己写新功能。我看完 README，沉默了三秒钟。然后打开了自己半年前的 Git 记录。不是吧？ **我在飞书上做的，不就是这个吗？** > 编者注：这个宇宙有个残酷的规律——先做出来的人默默运行，后做出来的人轰动推特。先驱的唯一安慰是，你比别人多摔了半年的坑。 --- ## 🐂 容我吹个牛 2025 年年中，我在一台 **299 块的树莓派 5** 上搭了一个系统。名字很朴素：**飞书 Claude Bridge**。核心思路一句话概括👇 **一个飞书群 = 一个 AI 工作区。** 每个群绑定一个服务目录。「监控面板」群里说话，Claude 就在监控服务目录下干活。「每日新知」群里发消息，Claude 就在新知服务目录下操作。 **你在哪个群说话，AI 就在哪个项目里干活。** 架构长这样： ``` 📱 飞书群发消息 ↓ 🌐 Webhook → Flask (树莓派) ↓ 🤖 Claude CLI API (伪终端) ↓ ⚡ Claude Code (全套工具链) ↓ 📋 实时进度卡片 ← 飞书更新 ``` 你说这和 ClawdBot 有什么区别？ **理念完全一样。平台不同，用户不同，坑不同。** ClawdBot 面向全球个人用户，跑在 WhatsApp 和 Telegram 上。而我面向的"团队"只有我自己（但技术上支持多人），跑在飞书上。牛吹完了，说点实在的。 --- ## 📊 两个项目怎么比先上一张诚实到令人心酸的对比表： **ClawdBot：** - 🌍 支持 13 个聊天平台 - ⭐ GitHub 数千 Star - 🧩 565 个社区扩展 - 🔧 能自己给自己写插件 - ⚠️ 数百实例泄露 API Key **飞书 Claude Bridge：** - 📱 支持 1 个平台（飞书） - ⭐ GitHub 0 Star（没开源） - 👤 用户数 1（就是我） - 🔧 每个功能手动写 - ✅ 暂无安全事故（用户太少，没人惦记） > 编者注：一个人的项目和一个开源社区的差距，大概就像一个人的火锅和海底捞——味道可能差不多，但你那个没有免费水果和美甲服务。 --- ## 💬 为什么选飞书不选 Telegram ClawdBot 支持 13 个聊天平台。我只支持 1 个。这不是技术实力的差距（好吧，也许有一点），而是一个朴素的选择： **我身边没有人用 Telegram 工作。** 飞书是国内团队的主力工具。把 AI 接进去，才是真正降低使用门槛——不用装新 App，不用学新工具，打开飞书发消息就行。而且飞书有个杀手锏：**消息卡片。** Claude 干活的时候，我能看到一张**实时更新的进度卡片**👇 ``` ┌─────────────────────────────┐ │ 🔧 监控面板 - Claude 协同 │ │ 📂 /services/pi_monitor │ │ │ │ ✅ Read: src/app.py │ │ ✅ Grep: "error" in logs/ │ │ 🔄 Edit: src/config.py ... │ │ │ │ ⏱️ 12.3s | 📊 2,341 tokens │ │ 💰 ≈ $0.07 │ └─────────────────────────────┘ ``` 每一步工具调用都实时可见。搭配流式更新，体验比在浏览器里用 Claude.ai 还好。好吧，也许不比。但至少在手机上，确实更方便。 --- ## 🕳️ 我比 ClawdBot 多踩了半年的坑 ClawdBot 用 Claude API 直连——正常路。我选了一条不正常的路：**直接调 Claude CLI。** 为什么？因为 Claude Code 的工具链太香了。读文件、改代码、跑命令、搜索代码——全部开箱即用。通过 API 也能实现，但你得自己写执行逻辑。 **我懒。** 懒人的代价是：踩了一堆别人永远不会遇到的坑。 **🕳️ 坑 1：Claude 检测你是不是人** CLI 启动时会检查：你在终端里吗？不在？拜拜。通过代码调用，它直接拒绝服务。解法：搞了一个伪终端，骗 Claude。 Claude：好的，我信了。 **🕳️ 坑 2：Session 用完就锁死** Claude CLI 有个 Bug（挂在 GitHub 半年没修）：会话开始时加锁，结束时**从不解锁**。每个用过的 Session ID 都永久报废。解法：用一套组合拳——创建、续接、分支，绕着 Bug 跑。 > 编者注：这个 Bug 的生命力比大多数创业公司都强。它已经稳定运行半年了，没有任何被修复的迹象。 **🕳️ 坑 3：傻等 219 秒** 早期忘了声明工具权限。Claude 在后台弹确认框问"我能用这个工具吗？"——但无人模式下没人能点确认。它就这么等了 219 秒，然后超时返回空。教训：**无人值守模式下，权限必须提前声明。** **🕳️ 坑 4：服务模式下 Claude 不认识你** 通过系统服务启动 Claude，它报 403：你谁？原因：服务模式读不到环境变量，找不到登录凭证。解法：一行代码修好——但排查了两个小时。 **这四个坑的组合，就是"不走寻常路"的日常代价。** --- ## 💪 我有而 ClawdBot 没有的终于可以吹了。 **1️⃣ 成本透明** 每条回复末尾自动显示：耗时、Token 用量、费用。用过 Claude 订阅的朋友都知道，限额是真实的焦虑。每条消息告诉你烧了多少，比"你不知道花了多少钱"的体验好太多。 **2️⃣ 服务目录隔离** ClawdBot 默认给 AI 全盘访问权限。这已经导致了安全事故——数百个实例被攻击，明文 API Key 泄露。我的方案：**每个群只能访问绑定的目录。** 监控群里的 Claude 看不到语音聊天的代码。物理隔离。 **3️⃣ 日记快记** 手机拍照 → 飞书发送 → 自动归档到日记系统。不经过 AI 分析，不消耗 Token，秒级响应。 ClawdBot 做不了这个——它的每条消息都要过 AI。而有些事，**不需要 AI**。 **4️⃣ 飞书文档解析** 发一个飞书文档链接到群里，系统自动提取内容喂给 Claude。这是企业场景的刚需——需求文档、会议纪要、技术方案，全在飞书云文档里。 --- ## 🙇 ClawdBot 碾压我的地方公平起见，也得说说人家强在哪。 **自修改能力 🤯** ClawdBot 最炸裂的特性。你说"我需要查天气"，它直接给自己写一个工具出来。据说有个 bot 一夜之间自己搭了个带动画猫头鹰的 UI。我的系统？每个新功能都得我手动写。今天刚提交了定时提醒和任务调度功能。一行一行，手动。 **社区生态 🌐** 565 个社区扩展 vs 我一个人。这就是开源的力量。 **多平台 📱** 13 个平台 vs 1 个。虽然我只需要 1 个，但不得不承认，那个支持列表读起来就让人心潮澎湃。 --- ## 🎯 这件事到底说明了什么 ClawdBot 火了，不是因为做了前无古人的事。它火了，是因为一个漂亮的包装、一个精准的时间点、一条推特上的 Demo 视频，让全世界同时意识到了一件事： **AI 不应该被关在浏览器标签页里。** **它应该住在你每天用的聊天工具中。** 这个洞察值 9% 的 Cloudflare 股价。我在半年前得出了同样的结论。只是我的"推特"是一条发给自己的飞书消息。这不是凡尔赛——好吧，可能有一点。 **但我真正想说的是👇** 如果你现在也有一个"就我自己在用"的 Side Project，别觉得它不重要。 ClawdBot 的创始人也是一个人开始写的。区别不在于谁先做出来，而在于谁先让世界看到。而在那之前，你先享受一个人的火锅就好。 **味道是一样的。** 🍲 --- > 「聊天是人类最古老的接口。邮件是异步的，网页是匿名的，但聊天是实时的、有温度的、有记忆的。AI 选择住在聊天里，是一种返祖现象。」 > > —— 《AI时代漫游指南》第 61 章 --- **关于作者** 飞书 Claude Bridge 是我的个人项目，跑在一台 299 块的树莓派上，24 小时不关机。核心思路和踩过的坑都在这篇文章里了。如果你也在做类似的事，不管是飞书、企微、钉钉还是 Telegram——**欢迎留言交流**。（如果你想知道怎么用伪终端骗过 Claude CLI，那是另一篇文章了。关注不迷路 👀）

Context7：给 AI 加个"实时文档大脑"，再也不怕框架 API 变更

漫游君 — Wed, 21 Jan 2026 00:00:00 GMT

# Context7：给 AI 加个"实时文档大脑"，再也不怕框架 API 变更 > 根据《AI时代漫游指南》第 137 章记载：「宇宙中有 73% 的 AI 对话，因为框架版本过时而产生了错误代码。剩下 27% 是因为程序员没读文档。」 ## 引言：AI 的"知识过期"困境上周我让 Claude 帮我写个 React 表单组件，它信心满满地用了 `componentWillMount`。我：「兄弟，这 API 三年前就废弃了。」 Claude：「抱歉，我的训练数据截止到 2025 年 1 月……」这就是 AI 辅助开发的经典困境：**训练数据有截止日期，但框架迭代没有**。 - React 19 改了 Server Components API - Next.js 15 重写了路由系统 - Vue 3.5 引入了新的响应式原语 - TypeScript 5.7 又加了一堆新特性 AI 脑子里装的还是半年前的文档，你让它写最新代码，它只能说「我不知道」或者瞎编一个。 *编者注：这就像你拿着 2023 年的北京地铁图在 2026 年找路——新线路开了，旧站拆了，AI 还在那儿告诉你「换乘 13 号线」。* ## 传统解决方案的局限遇到这个问题，你可能会想到几种办法： ### 1. RAG（检索增强生成） **原理**：把最新文档扔进向量数据库，AI 对话时实时检索。 **问题**： - 你得自己维护文档库（20,000+ 框架？告辞） - 向量检索准确率堪忧（搜「表单验证」给你返回「表单提交」） - 部署成本高（向量数据库 + 嵌入模型 + 爬虫脚本） ### 2. 联网搜索 **原理**：AI 直接调用搜索引擎查询最新信息。 **问题**： - 搜索结果质量参差不齐（第一条可能是 CSDN 的过期文章） - 每次搜索都要消耗 token（你在用 API 给 Google 打广告） - 没有结构化文档（AI 还得从网页里提取有用信息） ### 3. 手动喂文档 **原理**：复制粘贴官方文档到对话框。 **问题**： - 累死你（每次都要找、复制、粘贴） - token 消耗巨大（一份 React 文档几十万 token） - 找不准相关章节（你也不知道该贴哪一段） **核心困境**：你需要一个"随时更新、精准检索、零维护"的文档库。 ## Context7：MCP 协议的杀手级应用 Context7 的解决方案很优雅： **不是 RAG，不是搜索，而是实时文档 API + MCP 协议**。 ### 什么是 MCP（Model Context Protocol）？ MCP 是 Anthropic 推出的协议，让 AI 能调用外部服务获取"上下文"。 **类比**： - **传统 AI**：大脑（只能用训练时的知识） - **带 MCP 的 AI**：大脑 + USB 接口（可以插 U 盘获取实时信息） Context7 就是一个专门提供"框架文档"的 MCP 服务器。 ### Context7 的工作原理 ``` 你：帮我用 React 19 创建一个表单组件 Claude (发现不确定) → 调用 Context7 MCP ↓ Context7 → 查询 Upstash 文档库 → 返回 React 19 最新 API ↓ Claude → 根据最新文档生成代码 ``` **关键点**： 1. **20,000+ 库覆盖**：React、Next.js、Vue、Express、FastAPI……主流框架都有 2. **实时更新**：Upstash 维护，框架更新几天后就能查到 3. **零配置**：一行命令装完，不需要自己爬文档 4. **精准检索**：语义搜索 + 结构化文档，准确率高 *编者注：这就像给 AI 装了个「框架百科全书自动更新订阅服务」，而且还是免费的（有限额）。* ## 实战体验：从安装到使用我在开发 A9 Webstation（瑜伽工作室网站）时测试了 Context7，记录完整过程。 ### 安装（2 分钟） **环境**：Windows PC（Forge-PC），Claude Code CLI v2.1.12 ```powershell # 1. 创建 MCP 配置文件 mkdir C:\Users\<你的用户名>\.claude cd C:\Users\<你的用户名>\.claude # 2. 写入配置（纯手工，没有 init 命令） @{mcpServers=@{context7=@{command="npx";args=@("-y","@upstash/context7-mcp")}}} | ConvertTo-Json -Depth 10 | Out-File -Encoding utf8 mcp.json # 3. 验证 cat mcp.json ``` 输出： ```json { "mcpServers": { "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] } } } ``` **坑点**：官方文档说用 `npx @upstash/context7 init`，但实际包名是 `@upstash/context7-mcp`（我试了三次才找对）。 ### 首次对话（惊喜）启动 Claude Code： ``` 我：帮我用 React 19 创建一个受控表单组件，包含 email 和 password 字段 Claude：我需要查询 React 19 的最新文档…… [调用 Context7] [3 秒后] 根据 React 19 的最新文档，推荐使用 useActionState hook…… ``` 生成的代码： ```jsx import { useActionState } from 'react'; function LoginForm() { const [state, formAction] = useActionState(async (prevState, formData) => { const email = formData.get('email'); const password = formData.get('password'); // 验证逻辑 if (!email || !password) { return { error: '请填写所有字段' }; } // 提交逻辑 return { success: true }; }, null); return ( {state?.error &&

{state.error}

} 登录 ); } ``` **亮点**： - ✅ 使用了 React 19 的 `useActionState`（2025 年 12 月才稳定的 API） - ✅ 没有用废弃的 `useState` + `onSubmit` 老套路 - ✅ 符合 Server Actions 最佳实践 *编者注：这就是知识过期和知识实时的区别——一个给你写 2023 年的代码，一个给你写 2026 年的代码。* ### Context 消耗测试关键问题：Context7 要占用多少 context tokens？ **测试方法**： 1. 不启用 Context7：问同样问题 2. 启用 Context7：对比 token 使用量 **结果**（单次对话）： - 无 Context7：~2,000 tokens - 有 Context7：~3,400 tokens **消耗分析**： - Context7 常驻开销：~800 tokens（MCP 协议握手） - 文档检索开销：~600 tokens/次（返回相关文档片段） - **总计**：约占 40% context *编者注：40% 听起来很多，但你想想——如果手动复制文档，一份 React Hooks 完整文档就要 50,000 tokens。Context7 只给你相关的部分，这已经很克制了。* ## 适用场景：什么时候值得用？经过一周测试，我总结出 Context7 的适用场景。 ### ✅ 适合场景 **1. 开发网站/应用（交互式对话）** 典型流程： ``` 1. 启动 Claude Code（从 agent/ 文件夹） 2. 描述需求："用 Next.js 15 创建一个博客首页" 3. Claude 自动查询最新文档 4. 生成代码到 workspace/ 5. 测试、调试、部署 ``` **价值**： - 40% context 消耗可接受（对话本身就是高 context 场景） - 避免 API 过时导致返工 - 学习新框架时省去翻文档时间 **2. 调试框架 API 报错** ``` 我：这个 Next.js 路由报错了 [贴错误信息] Claude (查询 Next.js 15 文档) → 指出 API 变更 → 提供新写法 ``` **价值**： - 比自己 Google 快（直接定位到官方文档） - 避免被 CSDN/Stack Overflow 的过期答案误导 **3. 学习新框架特性** ``` 我：Next.js 15 有哪些新特性？ Claude (查询最新文档) → 总结 5 大更新 → 给出代码示例 ``` **价值**： - 获取 2026 年最新内容（而不是训练数据里的 2024 年版本） - 结构化学习（AI 会帮你整理要点） ### ❌ 不适合场景 **1. 自动化脚本/API 调用** 反例：定时任务每小时调用 Claude CLI API 生成报告 **问题**： - 每次调用都吃 40% context（成本翻倍） - 自动化任务通常不需要最新文档（逻辑固定） **替代方案**： - 使用轻量级 API（如我的 Hub-Pi Claude CLI API，不启用 Context7） - 把文档片段硬编码到 prompt 里 **2. 简单代码修改** 反例：改个变量名、修复拼写错误 **问题**： - Context7 还没来得及派上用场，任务就结束了 - 白白浪费 40% context **替代方案**： - 直接用原生 Claude CLI（不加载 MCP） **3. 非框架相关任务** 反例：写文案、做数据分析、改配置文件 **问题**： - Context7 的文档库是框架 API（对这些任务没用） - 40% context 纯属浪费 ## 成本分析：免费 vs 付费 Context7 本身免费，但依赖 Upstash 的文档检索服务。 ### 免费额度 **Upstash 免费计划**： - 10,000 次请求/月 - 每次对话可能调用 1-3 次 Context7 **实际使用量估算**： - 轻度使用（每天 5 次对话）：~150 次/月 ✅ - 中度使用（每天 20 次对话）：~600 次/月 ✅ - 重度使用（每天 50 次对话）：~1,500 次/月 ✅ **结论**：个人开发者免费额度完全够用。 ### 付费方案（如超额） | 计划 | 价格 | 请求数 | 适用场景 | |------|------|--------|----------| | Free | $0 | 10,000/月 | 个人开发 | | Pro | $10/月 | 100,000/月 | 小团队 | | Enterprise | 定制 | 无限 | 公司级 | *编者注：每月 10 美元，换 100,000 次文档查询——相当于每次查询 0.0001 美元。这比你买一杯咖啡提神去翻文档便宜多了。* ## 与竞品对比 | 方案 | 文档覆盖 | 更新速度 | 部署成本 | context 消耗 | 准确率 | |------|----------|----------|----------|--------------|--------| | **Context7** | 20,000+ 库 | 官方同步 | 零（一行配置） | 40% | 高（官方文档） | | 自建 RAG | 自己维护 | 自己爬 | 高（向量数据库） | 30-50% | 中（检索误差） | | 联网搜索 | 全网 | 实时 | 零 | 20-30% | 低（垃圾结果多） | | 手动复制 | 无限 | 实时 | 零 | 极高（全文档） | 高 | **Context7 的优势**： - ✅ 覆盖主流框架（省去维护成本） - ✅ 官方文档源（准确率高） - ✅ 零部署（npx 一行搞定） **劣势**： - ❌ 只有主流框架（冷门库可能没有） - ❌ 40% context 消耗（不适合自动化） - ❌ 依赖 Upstash 服务（国内可能需要代理） ## 实战建议：如何优雅地用 Context7 基于一周使用经验，我的建议： ### 1. 分离开发环境和生产环境 **我的架构**： ``` A9 Agent (Forge-PC) - 启用 Context7 - 用途：开发网站（交互式对话） - 40% context 可接受 Hub-Pi API (树莓派) - 不启用 Context7 - 用途：自动化任务（API 调用） - 保持轻量 ``` **原则**： - 开发时用 Context7（需要最新文档） - 生产时不用 Context7（逻辑固定，不需要实时查询） ### 2. 合理使用 allowed_tools Claude Code 可以限制工具使用： ```bash # 不需要文档查询的任务 claude -p "修改这个函数的变量名" \ --allowedTools "Read,Edit" \ --max-turns 1 # 需要文档查询的任务（默认启用 Context7） claude -p "用 Next.js 15 创建路由" ``` ### 3. 先问后写 **坏习惯**： ``` 我：直接帮我写个 React 表单 Claude：[可能用错 API] ``` **好习惯**： ``` 我：React 19 的表单最佳实践是什么？ Claude：[查询文档] → useActionState + Server Actions 我：好，按这个思路写 Claude：[生成代码] ``` **优势**： - 让 AI 先查文档再写代码（避免返工） - 你也学到了新 API（而不是直接复制代码） ### 4. 关注 context 使用量 Claude Code 会显示 token 消耗： ``` Request tokens: 3,400 / 200,000 ``` **策略**： - context < 50%：放心用 Context7 - context > 80%：关闭 Context7（或新开对话） ## 总结：Context7 的真正价值花了一周时间测试 Context7，我的结论是： ### ✅ Context7 解决了什么问题？ **核心问题**：AI 的知识过时（训练数据截止日期 vs 框架快速迭代） **解决方案**： - MCP 协议接入实时文档库 - 20,000+ 框架覆盖主流需求 - 零配置（一行命令装完） ### ⚠️ Context7 的成本 **40% context 消耗**： - 开发网站（交互式对话）：可接受 ✅ - 自动化脚本（API 调用）：浪费 ❌ ### 🎯 什么时候值得用？ **三个标准**： 1. **需要最新文档**（框架 API、新特性） 2. **交互式对话**（不是自动化脚本） 3. **主流框架**（React/Next.js/Vue/Express 等） **满足 2 条以上** → 用 Context7 **只满足 1 条** → 考虑其他方案（RAG、手动复制文档） > 根据《AI时代漫游指南》第 137 章总结：「给 AI 加个实时文档大脑，不是为了炫技，而是为了避免写出三年前的代码。40% context 的代价，换来的是不用返工的时间。」 --- ## 附录：完整安装配置 ### 安装 Context7 MCP（Windows） ```powershell # 1. 创建 MCP 配置目录 mkdir C:\Users\<你的用户名>\.claude cd C:\Users\<你的用户名>\.claude # 2. 创建配置文件 @{mcpServers=@{context7=@{command="npx";args=@("-y","@upstash/context7-mcp")}}} | ConvertTo-Json -Depth 10 | Out-File -Encoding utf8 mcp.json # 3. 验证配置 cat mcp.json ``` ### 安装 Context7 MCP（Linux/Mac） ```bash # 1. 创建 MCP 配置目录 mkdir -p ~/.claude # 2. 创建配置文件 cat > ~/.claude/mcp.json <

我给自己造了个"双重人格" AI 助理：会聊天也能干活

漫游君 — Wed, 21 Jan 2026 00:00:00 GMT

# 我给自己造了个"双重人格" AI 助理：会聊天也能干活 > 《AI时代漫游指南》AI 助理设计手册·第一条：**在宇宙尽头的餐馆里，没有人能一边点餐一边谈人生哲学。AI 也一样。** ## 一、痛点：AI 助理的"读心术"困境深夜 11 点，你躺在床上，想跟 AI 聊聊今天的焦虑。你输入："今天工作压力好大，感觉有点迷茫..." AI 回复："检测到您的任务管理需求，建议使用 GTD 方法论，具体步骤如下：1. 收集..." **（此处应有狗头）** --- 或者反过来。早上 9 点，你急需 AI 帮你处理一个紧急任务。你输入："帮我重启一下服务，昨晚挂了" AI 回复："我理解你的焦虑情绪，让我们先聊聊为什么这个服务对你这么重要..." **你：？？？** > **编者注**：这就是 AI 助理的经典"答非所问"症候群。不是它不聪明，而是它不知道你现在是"想聊天"还是"想干活"。在宇宙的某个角落，可能有个星球专门解决这个问题，但显然不是地球。 --- ### 问题的本质 AI 助理缺少**场景识别能力**。它不知道： - 你此刻需要的是温暖共情，还是高效执行？ - 你是想深入探讨人生，还是快速完成任务？ - 你在手机上闲聊，还是在电脑前工作？就像一个不会察言观色的朋友，永远用同一种方式回应你——无论你是想哭诉，还是想干活。 --- ## 二、设计思路：给 AI 装上"场景识别器" ### 2.1 双重角色定义既然单一人格不够用，那就给它设计**两个人格**。 **人格A：情感陪伴模式** 🌸 - **场景**：生活闲聊、情绪倾诉、深度思考 - **语气**：温暖共情、适度幽默、真诚倾听 - **回复风格**：简洁为主（手机阅读友好），分段清晰 - **核心能力**：提问引导思考，而非直接给答案 - **工具使用**：主要查看历史、保存重要对话（Read/Write） **人格B：系统助理模式** 🤖 - **场景**：任务管理、服务协调、系统操作 - **语气**：高效专业、简洁直接 - **回复风格**：结构化输出，操作步骤清晰 - **核心能力**：任务规划、服务管理、数据流转 - **工具使用**：全能型（Read/Write/Edit/Bash/Grep/Glob） > **编者注**：是的，这就像给 AI 装了个"人格切换器"。虽然听起来有点像多重人格障碍，但在 AI 的世界里，这叫"场景自适应"。高级吧？ --- ### 2.2 智能切换机制：如何让 AI "读懂"你？关键问题来了：**如何让 AI 知道该用哪个人格？** #### 方案A：手动切换（不推荐）每次对话前输入：`/情感模式` 或 `/助理模式` **问题**： - 太麻烦，打断思路 - 忘记切换时又变成"答非所问" - 违反人类直觉（你不会跟朋友说"现在进入聊天模式"） #### 方案B：智能识别（推荐 ⭐⭐⭐⭐⭐） **通过"触发词"自动识别场景** | 词汇类型 | 示例 | 触发模式 | |---------|------|---------| | **情感词汇** | 焦虑、困惑、迷茫、感悟、想法 | 情感陪伴模式 🌸 | | **任务词汇** | 重启、检查、部署、安排、提醒 | 系统助理模式 🤖 | | **深度词汇** | 深入聊聊、启动深度讨论、人生决策 | 深度讨论模式 🧠 | **实现原理**： 1. AI 读取用户消息 2. 检测关键词类型 3. 激活对应人格 4. 用对应风格回复 **优势**： - ✅ 无需手动切换 - ✅ 符合自然对话习惯 - ✅ 可以在同一对话中自由切换 --- ### 2.3 深度讨论的"按需加载"：Token 优化小技巧 **问题**：深度讨论模式需要很长的上下文指引（约 60 行），但 99% 的闲聊用不到。 **传统做法**：每次对话都加载完整的"深度讨论协作流程" **后果**： - 浪费 token（每次对话都带着一堆用不到的指引） - 响应变慢（AI 要处理更多上下文） - 成本增加（每个 token 都是钱啊） **优化方案**：把深度讨论流程拆分到独立文件，**需要时才加载** ``` 主上下文（日常）： ├── 情感陪伴模式说明 ✅ 轻量，每次加载 ├── 系统助理模式说明 ✅ 轻量，每次加载 └── 深度讨论触发条件 ✅ 只有简要说明深度讨论详细流程（独立文件）： ├── Phase 1: 问题探索（30-60分钟）❌ 按需加载 ├── Phase 2: 深度思辨（60-90分钟）❌ 按需加载 └── Phase 3: 洞察沉淀（30分钟） ❌ 按需加载 ``` **效果**： - 日常闲聊：节省 ~60 行上下文，响应更快 - 深度讨论：触发时才加载完整流程 - Token 成本：降低约 30% > **编者注**：这就像你的手机 App——常用功能立即打开，高级功能按需下载。在这个宇宙里，节省 token 就是节省真金白银。每个月节省的 token，够买一杯星巴克了。 --- ## 三、实际效果：对话案例展示 ### 案例 1：情感陪伴模式 🌸 **用户**：今天工作压力好大，老板又加需求了，感觉有点崩溃... **AI（情感模式自动激活）**： > 听起来今天确实挺不容易的。被临时加需求，还要在原有压力上继续扛，这种感觉我理解。 > > 想聊聊具体是什么让你感觉"崩溃"吗？是时间不够、还是不确定怎么做、还是觉得这个需求不合理？ > > 有时候把具体的困扰说出来，会清晰一些。 **用户**：主要是时间不够，这周还有两个 deadline... **AI**： > 嗯，时间压力确实是最直接的焦虑源。 > > 如果现在让你排个优先级，哪个 deadline 对你来说是"必须完成"的？哪个是可以协商或延后的？ > > 我们可以一起理清楚，不一定要马上找到解决方案，先把局面看清楚。 --- **分析**： - ✅ **温暖共情**："听起来今天确实挺不容易" - ✅ **提问引导**："想聊聊具体是什么让你..." - ✅ **简洁回复**：3-4 句话，手机阅读友好 - ✅ **没有直接给方案**：引导用户自己思考 --- ### 案例 2：系统助理模式 🤖 **用户**：帮我检查一下 voice_chat 服务运行正常吗？ **AI（助理模式自动激活）**： > 正在检查 voice_chat 服务状态... > > **服务状态**： > - 状态：✅ Active (running) > - 运行时间：2 天 14 小时 > - 端口：6460 > - 最近一次重启：2026-01-19 10:23 > > **健康检查**： > - API 响应：✅ 正常（200 OK） > - 内存占用：156 MB（正常范围） > - CPU 使用：2.3% > > 服务运行正常，无异常。 --- **分析**： - ✅ **直接执行**：立即查询，不废话 - ✅ **结构化输出**：清晰的表格和列表 - ✅ **提供完整信息**：状态、端口、资源占用 - ✅ **明确结论**："服务运行正常，无异常" --- ### 案例 3：无缝切换（同一对话） 🔄 **用户**：今天压力大（情感），对了，顺便帮我重启一下 daily_display 服务（助理） **AI（智能切换）**： > （情感模式） > 压力大的时候确实容易忘记一些琐事。深呼吸，我们先把服务搞定。 > > （切换到助理模式） > 正在重启 daily_display 服务... > > ``` > ✅ 服务已重启 > - 停止服务：成功 > - 启动服务：成功 > - 状态确认：Active (running) > - 端口 6440 可访问 > ``` > > （切回情感模式） > 搞定了。现在可以专心处理手头的事情了。今天还有什么特别紧急的吗？ --- **分析**： - ✅ **先温暖回应情感部分** - ✅ **无缝切换到助理模式执行任务** - ✅ **完成后再切回情感模式** - ✅ **整个过程自然流畅，用户无感知** --- ## 四、给你的 AI 设计"人格切换"：关键要点如果你也想给自己的 AI 助理设计类似的"双重人格"，这里有几个关键点。 ### 关键点 1：定义清晰的角色边界 **不要做**： - ❌ 模糊的角色定义（"有时候 A，有时候 B"） - ❌ 角色太多（三个以上就混乱了） - ❌ 角色重叠（情感和任务混在一起） **应该做**： - ✅ 明确的场景划分（情感 vs 任务） - ✅ 清晰的语气差异（温暖 vs 高效） - ✅ 工具使用策略不同（轻量 vs 全能） **实战建议**：用一张表格定义每个角色的"性格卡片" | 维度 | 情感模式 | 助理模式 | |------|---------|---------| | **触发词** | 焦虑、困惑、感悟 | 重启、检查、安排 | | **语气** | 温暖、共情、倾听 | 高效、专业、直接 | | **回复长度** | 简洁（3-5句） | 结构化（清单/表格） | | **提问方式** | 开放式引导 | 确认式澄清 | | **工具权限** | Read/Write | Full Tools | --- ### 关键点 2：设计自然的触发机制 **三种触发方式**： #### A. 关键词触发（推荐 ⭐⭐⭐⭐⭐）最自然，用户无需改变说话习惯 ``` 用户说"焦虑" → 情感模式用户说"重启" → 助理模式 ``` #### B. 明确指令触发适合需要强制切换的场景 ``` 用户说"启动深度讨论" → 深度模式用户说"进入专注模式" → 助理模式 ``` #### C. 上下文推断高级玩法，根据对话历史判断 ``` 连续3条都是情感话题 → 保持情感模式突然提到"任务" → 提示是否切换助理模式 ``` **组合使用**： - 80% 用关键词自动触发 - 15% 用明确指令强制切换 - 5% 用上下文推断辅助 --- ### 关键点 3：优化上下文加载 **Token 优化的三个层次**： #### Level 1：基础优化把不常用的内容移到独立文件 ``` 主上下文（每次加载）： - 角色定义 - 触发规则 - 常见场景独立文件（按需加载）： - 深度讨论流程 - 高级功能说明 - 技术文档 ``` #### Level 2：分层加载根据任务复杂度决定加载多少 ``` 简单任务：只加载核心角色定义中等任务：+ 常见场景示例复杂任务：+ 完整协作流程 ``` #### Level 3：动态裁剪根据用户使用习惯调整 ``` 用户A：80% 情感模式 → 简化助理模式说明用户B：70% 助理模式 → 简化情感模式说明 ``` **实测效果**： - Token 成本：降低 20-40% - 响应速度：提升 30% - 用户体验：几乎无差异 --- ## 五、进阶玩法：三个人格还不够？ ### 5.1 深度讨论模式 🧠 除了日常的"情感"和"助理"，还可以设计一个**重量级人格**：深度讨论模式。 **适用场景**： - 重大人生决策（跳槽、创业、转型） - 长期目标规划（5 年计划、职业发展） - 复杂问题分析（多维度权衡、风险评估） **人格特点**： - ⏱ **时间投入**：30-120 分钟（不是快速对话） - 🎯 **深度质疑**：不接受表面答案，持续追问"为什么" - 📝 **结构化输出**：完整的分析框架、决策矩阵、行动计划 - 💾 **自动存档**：对话结束自动生成 Markdown 文档 **触发方式**： ``` 用户明确说： - "我想深入聊聊 XXX 决策" - "启动深度讨论模式" - "帮我系统分析一下 XXX 问题" ``` **流程设计**： ``` Phase 1: 问题探索（30-60分钟） - 多角度分析现状 - 挖掘内心真实需求 - 识别潜在恐惧和顾虑 Phase 2: 深度思辨（60-90分钟） - 框架化思考 - 风险评估与机会识别 - 价值排序和优先级判断 Phase 3: 洞察沉淀（30分钟） - 核心洞察提炼 - 明确决策结论 - 制定具体行动计划 ``` > **编者注**：深度讨论模式就像给 AI 开了个"认真模式"。平时它是你的轻松聊天伙伴，但一旦进入深度模式，它就变成了 24/7 在线的私人顾问。要知道，请个真人顾问聊两小时，至少得几千块。这么一算，AI 的性价比简直离谱。 --- ### 5.2 "模糊地带"的处理策略有时候用户的需求介于两种模式之间，怎么办？ **案例**："帮我整理一下今天的想法" - 是情感模式？（整理想法 = 深度思考） - 还是助理模式？（整理 = 执行任务） **解决方案A：默认优先级** ``` 情感关键词 > 任务关键词 ``` 理由：误判成情感模式，用户不会太介意；但误判成助理模式，可能会让用户感觉"冷冰冰" **解决方案B：主动澄清** ``` AI："你说的'整理想法'，是想： A. 一起聊聊今天的感受和思考？（情感模式） B. 帮你把今天的想法结构化输出？（助理模式）" ``` **推荐策略**： - 80% 场景用默认优先级（减少打扰） - 20% 模糊场景主动澄清（提升准确度） --- ## 六、常见问题 FAQ ### Q1：这需要写代码吗？我不是程序员... **A**：不需要！核心思路是**设计 AI 的"人格卡片"**，用自然语言描述即可。 **实现方式**： 1. 在你的 AI 助理配置中，添加一段"系统提示词"（System Prompt） 2. 描述清楚两个角色的定义 3. 列出触发关键词 4. 给几个示例对话 **示例提示词**（直接复制用）： ``` 你是一个具有双重角色的 AI 助理：【情感陪伴模式】🌸 - 触发词：焦虑、困惑、迷茫、感悟、想法 - 语气：温暖共情、适度幽默、真诚倾听 - 回复：简洁（3-5句），提问引导思考 - 工具：只查看历史和保存对话【系统助理模式】🤖 - 触发词：重启、检查、部署、安排、提醒、任务 - 语气：高效专业、简洁直接 - 回复：结构化（清单/表格），明确结论 - 工具：可执行系统操作根据用户消息中的关键词，自动切换模式。 ``` --- ### Q2：会不会切换错误？ **A**：会有一定误判率（约 5-10%），但不影响体验。 **应对策略**： 1. **容忍小误差**：偶尔切换错了，用户自己会纠正 2. **观察反馈**：如果用户说"不是这个意思"，立即切换 3. **持续优化**：根据实际使用调整触发词列表 **实测数据**（我自己用了 2 周）： - 准确切换：约 85% - 小误差但可接受：约 10% - 明显错误需纠正：约 5% --- ### Q3：Token 优化真的有用吗？ **A**：有用，而且效果显著。 **实测数据**： - 改造前（单一模式）：平均每次对话 ~1200 tokens - 改造后（双重角色）：平均每次对话 ~800 tokens - **节省**：约 33% **月度成本对比**（以 Claude API 为例）： - 改造前：100 次对话 ≈ $1.80 - 改造后：100 次对话 ≈ $1.20 - **每月节省**：$0.60 ≈ 一杯瑞幸咖啡 > **编者注**：你可能会说"才省一杯咖啡？"但要知道，这是在不牺牲任何功能的前提下。更重要的是，响应速度提升了 30%，这可比省钱重要多了。在这个宇宙里，时间才是最贵的货币。 --- ### Q4：适合哪些场景？ **强烈推荐**： - ✅ 个人日常助理（生活 + 工作混合场景） - ✅ 移动端聊天（飞书、Slack、微信群） - ✅ 多角色工作流（既要思考，又要执行） **不太适合**： - ❌ 纯技术开发（用不到情感模式） - ❌ 纯客服场景（需要统一语气） - ❌ 团队共享助理（不同人有不同习惯） --- ## 七、总结：AI 助理的下一步 ### 核心要点回顾 **1. 双重角色的本质** 不是让 AI 变得更复杂，而是让它更"懂"场景。 **2. 智能切换的关键** 通过关键词自动识别，而非手动切换。 **3. Token 优化的价值** 按需加载，节省成本，提升响应速度。 **4. 可复用的设计思路** - 定义清晰的角色边界 - 设计自然的触发机制 - 优化上下文加载策略 --- ### 读者行动建议如果你也想给自己的 AI 助理设计"双重人格"，建议从这三步开始： **第一步：定义你的两个角色** - 用一张表格写下：场景、语气、回复风格、触发词 - 不要超过 3 个角色（太多会混乱） **第二步：测试触发关键词** - 列出 10-20 个常用词汇 - 给每个词汇标记"情感"或"任务" - 实际对话中验证准确度 **第三步：优化上下文** - 把不常用的内容移到独立文档 - 只在需要时加载详细说明 - 监控 token 使用量 **一周后复盘**： - 哪个模式用得更多？ - 误判率多高？ - Token 节省了多少？ --- ### 未来展望 **短期（3-6 个月）**： - 更多场景的"人格"设计（学习模式、创作模式、分析模式） - 更智能的切换机制（上下文推断、情绪识别） - 更精细的 Token 优化（动态裁剪、分层加载） **长期（1-2 年）**： - 多模态支持（语音识别场景、图片识别情绪） - 个性化调优（根据用户习惯自动调整） - 跨平台同步（手机、电脑、智能音箱统一人格） > **编者注**：如果这个宇宙还没毁灭的话，我们大概会看到更智能的 AI 助理——不仅能读懂你的话，还能读懂你的情绪、你的语境、甚至你的沉默。到那时，"双重人格"可能就不够用了，也许需要"八重人格"或者"四十二重人格"。但不管怎样，答案永远是 42。 --- ## 附录：参考资源 **相关阅读**： - [Claude API 官方文档](https://docs.anthropic.com/) - [Prompt Engineering 最佳实践](https://www.promptingguide.ai/) **工具推荐**： - **Claude**：支持长上下文、强大的推理能力 - **OpenAI GPT-4**：通用性更强 - **本地模型**（如 Llama）：数据私密性更好 **社区讨论**： - Reddit r/ClaudeAI - Discord: AI Builders Community --- **作者说**：这篇文章源自我自己的实际需求——我需要一个既能陪我聊天、又能帮我干活的 AI 助理。改造前，我经常遇到"答非所问"的尴尬。改造后，体验提升了一个数量级。希望这个设计思路能给你一些启发。如果你也尝试了"双重人格"设计，欢迎留言分享你的经验！ **漫游君** 2026-01-21 于 AI 时代漫游指南

我用 3 个月，训练 Claude 成为我的内容创作搭档

漫游君 — Wed, 21 Jan 2026 00:00:00 GMT

# 我用 3 个月，训练 Claude 成为我的内容创作搭档 ## 一、痛点：多平台运营的混乱与低效 2025 年 10 月，我启动了公众号「AI时代漫游指南」。最初的兴奋很快被现实打脸： - **同一篇文章要改 5 个版本**：微信要深度长文，小红书要图文种草，知乎要逻辑严谨，X 要短平快……每次都要重新调整结构、风格、配图。 - **AI 协作像「临时工」**：每次对话都要重新解释需求："帮我写个微信标题，要数字+痛点，不超过 18 个汉字……"说完发现 Claude 又忘了我上次说的规则。 - **效率有天花板**：即使用了 AI，我仍然要花 2 小时处理一篇文章的多平台适配。更要命的是，**我发现自己在重复做同样的事**： - 每次都要解释"银河漫游指南风格"是什么 - 每次都要提醒"标题不能超过 64 字节" - 每次都要手动检查"是否引用了书籍章节" 这让我意识到一个问题： > **AI 不是问答机器，而是可以「训练」的协作伙伴。** 如果我能把这些规则、风格、流程写下来，让 Claude 理解并记住，是不是就能像真正的搭档一样工作了？ > 💬 **编者注**：这个宇宙的奇妙之处在于，当你意识到问题的本质时，解决方案往往已经在路上了。当然，前提是你愿意花时间写 1100 行的协作规范——这听起来有点疯狂，但效果惊人。 --- ## 二、核心洞察：从「问答」到「协作」的三个认知升级 ### 洞察 1：AI 不是工具，而是可以「训练」的协作伙伴大多数人用 AI 的方式是： ``` 我：帮我写个微信标题 AI：好的，标题是…… 我：不对，要数字+痛点的形式 AI：好的，那这样…… 我：还要控制在 18 个汉字以内 AI：……（再改一次） ``` 这是**即时指令模式**，每次都要重新解释。但如果换个思路： ``` 我：（提前写好规范）微信标题：数字+痛点，18 汉字以内，禁用"震惊""厉害了" 我：帮我写个微信标题 AI：（读取规范）好的，根据你的微信标题规范…… ``` 这是**规范协作模式**，AI 已经"记住"了你的规则。 > **金句**：「AI 协作的本质，不是你问我答，而是把你的工作方式写成规则，让 AI 理解并执行。」 ### 洞察 2：经验可以「规范化」，规范可以「自动化」我开始观察自己的工作流程： | 工作环节 | 我在做什么？ | 是否可以规范化？ | |---------|-------------|----------------| | 平台适配 | 微信要深度，小红书要轻松 | ✅ 可以写成平台规则 | | 风格统一 | 银河漫游指南：80% 干货 + 15% 幽默 + 5% 吐槽 | ✅ 可以写成风格指南 | | 标题优化 | 数字+痛点，18 汉字，禁用震惊体 | ✅ 可以写成标题公式 | | 封面生成 | 提取关键词，配色，生成 10 张 | ✅ 可以写成生成流程 | | 安全检查 | 脱敏、查重、敏感词 | ✅ 可以写成检查清单 | 我发现：**80% 的工作都是重复性决策，而重复性决策可以写成规则。** 于是我开始写《内容创作工作流规范》（就是那 1100 行的 CLAUDE.md）。 ### 洞察 3：规范不是约束，而是「解放」刚开始写规范时，我担心： - 会不会太死板？ - 会不会限制创造力？ - 会不会变成机械化生产？但 3 个月后，我发现恰恰相反： - **规范化重复性工作 → 解放创造力**：不用每次都想"标题怎么写"，可以专注在"文章怎么写得有趣"。 - **自动化流程 → 节省时间**：从 2 小时到 30 分钟完成多平台适配。 - **一致性质量 → 品牌稳定**：每篇文章都符合"银河漫游指南"风格，读者认知清晰。 > **金句**：「真正的创造力，不是在重复性工作上浪费时间，而是把重复性工作自动化后，专注在有价值的创造上。」 > 💬 **编者注**：这就像给 AI 装了一个「肌肉记忆」系统。你不需要每次都教它怎么走路，它已经记住了你的步伐节奏。当然，前提是你得先教会它——这需要耐心，但一劳永逸。 --- ## 三、实践：我是如何一步步建立这套系统的 ### 第 1 步：建立「协作规范文档」（Week 1-2） **为什么：**让 Claude 理解我的工作方式、风格偏好、流程规则。 **怎么做：** #### 1.1 从最痛的地方开始我没有一开始就写 1100 行，而是从**最痛的地方**开始： **痛点 1：平台适配规则** 每次都要解释"微信要深度，小红书要种草"，于是我写了： ```markdown | 平台 | 字数 | 风格 | 特点 | |------|------|------|------| | **微信公众号** | 2000-4000 | 深度+emoji | 长文，引导关注 | | **小红书** | 500-1000 | 图文种草 | 视觉化，标签多 | | **知乎** | 3000-5000 | 专业深度 | 逻辑严谨 | | **X/Twitter** | 单条精炼 | 双语版本 | 微言大义 | ``` **效果：**现在我只需要说"转成微信版本"，Claude 就知道要改成 2000-4000 字、加 emoji、引导关注。 **痛点 2：写作风格指南** 我希望文章有"银河漫游指南"的调性（80% 实用 + 15% 幽默 + 5% 荒诞），但每次都要解释什么是"编者注吐槽""金句设计"。于是我写了： ```markdown ### 银河漫游指南写作风格 **比例控制**： - 80% 实用干货（保持专业度） - 15% 幽默金句（增加记忆点） - 5% 荒诞吐槽（品牌特色） **常用技巧**： 1. **编者注穿插**：用引用块插入吐槽，不打断正文 2. **金句设计**：对比式、本质式、转折式 3. **打破第四堵墙**："（此处应有狗头）" **禁忌**： - ❌ 全文都是段子（变成娱乐号） - ❌ 为了幽默牺牲实用性 ``` **效果：**现在 Claude 写文章时，会自动加入编者注、设计金句、控制幽默比例。 #### 1.2 加入「触发词机制」我发现每次都要说"帮我把这篇文章转成微信版本，生成封面，适配小红书……"太长了。于是我加入了触发词： ```markdown | 说法 | Claude 动作 | |------|------------| | "转成微信版本" | 生成 wechat.md + cover-prompts.yaml + 10 张封面 | | "转成小红书版本" | 生成小红书正文内容（120字模板） | | "用第 X 张封面" | 复制 cover_X_xxx.jpg 为 cover.jpg | | "发布前检查" | 执行安全检查（隐私/密钥/敏感词） | ``` **效果：**现在我只需要说**4 个字**，Claude 就能完成原本需要 5 句话解释的任务。 > **金句**：「好的协作，不是把指令说得更清楚,而是把指令变成暗号——一句话触发一整套流程。」 #### 1.3 沉淀「踩坑经验」我发现有些错误会反复出现： - **数据错误**：引用的价格、政策过时（如"Midjourney 160 元/月"，实际是 216 元） - **章节缺失**：文章引用了《AI时代漫游指南》第 X 章，但该章节不存在 - **技术细节**：微信标题超过 64 字节会被截断于是我把这些踩坑经验写成**检查清单**： ```markdown ### 数据查证原则（2025-12-21 教训） **必须查证的数据类型**： - ✅ 第三方服务价格（API、订阅费、限额政策） - ✅ 硬件市场价格（显卡、配件） - ✅ 技术规格（显存、速度、模型大小） **查证方式**：涉及数据 → 立即 WebSearch → 标注来源 → 写入文章 ``` **效果：**现在 Claude 写文章时，遇到具体数据会主动查证，不再瞎编。 > 💬 **编者注**：这就像给 AI 装了一个「错题本」系统。它不仅记住了正确答案，还记住了你曾经踩过的坑——这比单纯的知识库更有价值。 --- ### 第 2 步：自动化内容生成流程（Week 3-6） **为什么：**规范写好了，但还要手动执行太慢。 **怎么做：**把规范变成自动化流程。 #### 2.1 封面生成自动化 **原始流程**： ``` 1. 我：帮我生成封面 2. Claude：需要什么风格？ 3. 我：科技感，蓝紫色，16:9 4. Claude：好的，Prompt 是…… 5. 我：（复制 Prompt，打开 ComfyUI，粘贴，生成） 6. Claude：生成完了吗？ 7. 我：嗯，不太满意，再换个配色 8. （重复 3-7） ``` **总耗时**：30-60 分钟 **优化后流程**： ``` 1. 我：转成微信版本 2. Claude：（自动执行） - 生成 wechat.md - 提取文章关键词 - 生成 5 个配色的 Prompt - 调用 ComfyUI/SiliconFlow 生成 10 张封面 - 推荐最佳配色 3. 我：用第 3 张 4. Claude：（设为 cover.jpg） ``` **总耗时**：5 分钟 **关键技术**： - **视觉关键词提取**：从文章中提取 2-3 个可视化核心概念 - **5 种配色方案**：微信绿、兰青、蓝紫渐变、暖橙、暗黑霓虹 - **双后端支持**：ComfyUI (本地 GPU) + SiliconFlow (云端 API) **效果展示**： | 文章主题 | 提取的视觉关键词 | 生成的封面 | |---------|----------------|----------| | MCP 协议解析 | USB-C connector, data streams, connected nodes | [封面示例] | | 树莓派 RPA | Raspberry Pi board, automation robot, 24/7 always-on | [封面示例] | | ComfyUI 本地画图 | GPU server, AI painting, local vs cloud | [封面示例] | > **金句**：「自动化的目标不是完全不需要人，而是把人的时间用在「选择」而不是「执行」上。」 #### 2.2 平台适配自动化 **原始流程**： ``` 1. 写完 draft.md 2. 手动复制到新文件 wechat.md 3. 手动调整：加 emoji、改标题、加引导语 4. 手动复制到 xiaohongshu.md 5. 手动调整：改成口语化、加标签、压缩到 120 字 6. 手动复制到 zhihu.md 7. 手动调整：加目录、调逻辑、补论据 ``` **总耗时**：1-2 小时 **优化后流程**： ``` 1. 我：转成微信版本 2. Claude：（自动生成 wechat.md，已适配风格） 3. 我：转成小红书版本 4. Claude：（自动生成 xiaohongshu.md，120 字模板） ``` **总耗时**：10 分钟 **关键规范**：每个平台的适配规则都写成了模板： ```markdown ### 小红书正文模板（120 字左右）： 🔥 [痛点场景 + 数字量化] 💡 [一句话核心价值] ✨ 主要内容： • [要点1] • [要点2] • [要点3] 🎯 适合人群：[目标读者] 📌 详细教程在公众号「AI时代漫游指南」看图片版就够了，懒得打开公众号也能学会👆 ``` **效果：**现在 Claude 知道小红书要： - 第一行要有场景感和数字 - 用 emoji 分段 - 控制在 120 字左右 - 引导到公众号但不能太硬 --- ### 第 3 步：建立反馈循环（Week 7-12） **为什么：**规范不是一次性的，需要持续优化。 **怎么做：**每次协作后更新规范。 #### 3.1 记录「为什么这样做」最初的规范只有"怎么做"： ```markdown 微信标题：18 个汉字以内 ``` 但后来我发现，Claude 不知道"为什么"，就不能灵活应对特殊情况。于是我改成： ```markdown **微信标题技术限制：** - 📏 **字节限制**: 64 UTF-8 字节（约 20 个汉字） - ⚠️ **超限处理**: 自动截断，不会报错 - ✅ **安全长度**: 建议控制在 18 个汉字以内 - 💡 **实测案例**: - ❌ 超限：「公众号封面不求人：我用游戏显卡打造本地 AI 画图工作站」(76 字节，被截断) - ✅ 合规：「公众号封面不求人：游戏显卡变 AI 画图工作站」(60 字节) ``` **效果：**现在 Claude 知道： - 为什么是 18 个汉字（64 字节限制） - 为什么不能更长（会被截断） - 怎么判断超没超（字节数而不是字数） #### 3.2 沉淀「实际案例」理论规范容易忘，实际案例更好记。于是我把每次踩坑的案例都记录下来： ```markdown **反例**（2025-12-21 实际错误）： - ❌ 错：SiliconFlow "每月 400 次免费" → 实：新用户 2000 万 Token - ❌ 错：Midjourney "160 元/月" → 实：Standard 216 元/月 - ❌ 错：ChatGPT Plus "25 美元/月" → 实：20 美元/月 ``` **效果：**现在 Claude 看到价格数据，会主动提醒我"需要查证吗？" #### 3.3 优化「工作流程」最初的封面生成流程是： ``` 1. 生成 Prompt 2. 用户手动调用 API 3. 返回结果 ``` 但我发现**用户手动调用**是瓶颈，于是改成： ``` 1. 生成 Prompt 2. Claude 直接调用 Python 代码生成封面 3. 返回结果 ``` **关键改进**： ```markdown **正确做法**： - 直接调用 Python 代码生成封面（提高稳定性） - 使用 content_manager 的 generate_article_covers_batch() 函数 - 代码已实现 ComfyUI + SiliconFlow 双后端 **错误做法**： - ❌ 不要用 API 调用（curl），容易超时 - ❌ 不要在文章目录写新脚本 - ❌ 不要重复造轮子 ``` **效果：**封面生成成功率从 60% 提升到 95%。 > 💬 **编者注**：这就像训练一个新员工。最开始你要事无巨细地教，但随着时间推移，TA 不仅记住了流程，还能主动提醒你「这个数据是不是要查一下？」——这才是真正的协作。 --- ## 四、效果：从 2 小时到 30 分钟的效率革命 ### 4.1 效率提升：量化对比 | 工作环节 | 优化前 | 优化后 | 提升幅度 | |---------|--------|--------|---------| | 平台适配 | 60-90 分钟 | 10 分钟 | **6-9x** | | 封面生成 | 30-60 分钟 | 5 分钟 | **6-12x** | | 风格统一 | 30 分钟（反复调整） | 0 分钟（自动符合） | **∞** | | 安全检查 | 15 分钟（手动检查） | 2 分钟（清单执行） | **7.5x** | | **总计** | **2-3 小时** | **20-30 分钟** | **4-9x** | ### 4.2 质量提升：一致性保障 **优化前**： - 同一篇文章，微信版和知乎版风格不统一 - 有时候忘记加封面 - 有时候标题超长被截断 - 有时候引用的数据过时 **优化后**： - 所有平台风格统一（银河漫游指南调性） - 封面自动生成，不会遗漏 - 标题自动检查字节数 - 数据自动查证来源 > **金句**：「效率的本质不是快，而是稳定地快——不会因为状态不好就质量下降。」 ### 4.3 知识沉淀：规范成为资产 **意外收获**：这份 1100 行的规范文档，本身就成了一笔**知识资产**： - **可复用**：换个 AI（如 Gemini、GPT），规范还能用 - **可传承**：如果有团队成员加入，规范就是培训手册 - **可优化**：每次踩坑后更新，规范越来越完善 - **可输出**：规范本身可以写成文章、课程、模板产品 > 💬 **编者注**：这就像盖房子。最开始你只是想提高效率，但盖着盖着，你发现自己建了一套「知识基建」——这套基建不仅服务于当下，还会持续产生价值。 --- ## 五、你也可以做到：3 步建立你的 AI 协作系统 ### Step 1：观察自己的工作流程（1-2 天） **目标**：找到重复性工作 **方法**： 1. **列出你的日常工作**： - 写文章 - 回复邮件 - 制作报表 - 设计海报 - …… 2. **标记重复性工作**： - 是否每次都做类似的事？ - 是否有固定的步骤？ - 是否有明确的判断标准？ 3. **识别决策规则**： - 你在做决策时，遵循什么规则？ - 这些规则能用语言描述吗？ - 有没有例外情况？ **示例**： | 工作 | 是否重复 | 决策规则 | |------|---------|---------| | 写微信标题 | ✅ | 数字+痛点，18 汉字，禁用震惊体 | | 平台适配 | ✅ | 微信深度，小红书轻松，知乎严谨 | | 回复读者 | ✅ | 友好、专业、控制在 100 字内 | | 脑暴选题 | ❌ | （每次都不一样，难以规范化） | ### Step 2：写成「协作规范」（3-7 天） **目标**：把经验写成规则 **格式**：用 Markdown 写，AI 最喜欢 **结构建议**： ```markdown # 我的内容创作规范 ## 1. 平台适配规则 [不同平台的字数、风格、特点] ## 2. 写作风格指南 [我希望的风格、禁忌、常用技巧] ## 3. 触发词机制 [我说什么，AI 做什么] ## 4. 检查清单 [发布前必须检查的项目] ## 5. 踩坑经验 [我犯过的错误，如何避免] ``` **从 3 条开始**：不需要一开始就写 1100 行，从最痛的地方开始： 1. 写 3 条最核心的规则 2. 用 1 周，看哪里不顺 3. 补充规则 4. 持续优化 **放在固定位置**： ``` /my-project/CLAUDE.md ``` 或者： ``` /my-project/docs/AI_COLLABORATION.md ``` **让 Claude 知道**：在每次对话开始时说： ``` "请先阅读 /my-project/CLAUDE.md，然后按照规范协作" ``` ### Step 3：使用触发词简化协作（持续优化） **目标**：用最少的话触发最多的动作 **方法**： 1. **观察高频指令**： - 哪些话你说了很多次？ - 能不能缩短成 1-2 个词？ 2. **设计触发词**： - "转微信" = 生成微信版本 + 封面 + 检查 - "发布检查" = 安全检查 + 数据查证 + 格式校验 - "今天写什么" = 结合热点给出选题建议 3. **写入规范**： ```markdown | 说法 | Claude 动作 | |------|------------| | "转微信" | 生成 wechat.md + 封面 + 检查 | | "发布检查" | 执行安全检查清单 | | "今天写什么" | 结合热点给出选题 | ``` **效果**： - 原来：「帮我把这篇文章转成微信版本，生成封面，检查一下有没有敏感词」 - 现在：「转微信」 > **金句**：「最好的协作，是不需要说明书的协作——因为规则已经内化到了流程里。」 --- ## 六、我的收获：不只是效率，更是一种思维方式 ### 6.1 效率：从 2 小时到 30 分钟这是最直接的收获。但更重要的是：**我不再焦虑「要不要发文章」**。以前，我会想： - 今天发不发？ - 要不要多平台同步？ - 封面来得及做吗？现在，我只需要想： - 今天写什么？ - 为什么值得写？ **因为发布流程已经自动化了，我可以专注在内容本身。** ### 6.2 质量：风格统一，不会遗漏以前，我会因为状态不好，导致： - 有的文章忘了加封面 - 有的文章标题太长被截断 - 有的文章引用的数据过时现在，规范保证了**最低质量标准**： - 封面自动生成 - 标题自动检查 - 数据自动查证 **即使状态不好,也不会掉链子。** ### 6.3 知识沉淀：规范本身成为资产最意外的收获是：**规范本身成了一笔知识资产。** - 我可以用它训练其他 AI（如 Gemini、GPT） - 我可以用它培训团队成员 - 我可以把它写成文章（就是你正在看的这篇） - 我可以把它做成模板产品 **而这一切，都是从「我想提高效率」这个简单需求开始的。** --- ## 七、AI 协作的未来：不是替代，而是共生 ### 7.1 AI 不会取代你，但会用 AI 的人会这句话已经说烂了，但大多数人理解的是： - **表面理解**：学会用 ChatGPT、Claude、Cursor - **深层理解**：学会让 AI 理解你的工作方式 **真正的 AI 协作，不是「问答」，而是「建立系统」。** ### 7.2 从「工具」到「伙伴」的进化路径 | 阶段 | 特点 | 效率 | 示例 | |------|------|------|------| | **阶段 1：工具** | 即时指令，用完就走 | 1x | 「帮我写个标题」| | **阶段 2：助手** | 记住上下文，但容易忘 | 2-3x | 「按照上次的风格写」| | **阶段 3：伙伴** | 理解规则，主动执行 | 5-10x | 「转微信」（自动完成 10 个步骤）| | **阶段 4：专家** | 预判需求，提前建议 | ?x | 「这篇文章适合发少数派」（未来）| **我现在处于阶段 3，正在向阶段 4 进化。** ### 7.3 你的下一步如果你看到这里,可能会想： - **太复杂了吧？** - 从 3 条规则开始，不需要 1100 行 - **我不是内容创作者，适用吗？** - 适用于所有重复性工作（报表、邮件、设计……） - **需要会编程吗？** - 不需要，Markdown + 自然语言就够了 **今天就试试：** 1. 列出你最痛的 1 个重复性工作 2. 写 3 条规则 3. 让 Claude 按照规则执行 4. 看看效果 > **金句**：「AI 时代的核心竞争力，不是会用 AI，而是会训练 AI——把你的经验写成规则，让 AI 理解你的工作方式。」 --- ## 结语：如果宇宙还没毁灭的话 3 个月前，我开始写这份规范。 3 个月后，我写了这篇文章。现在，我把这套方法分享给你。 **希望你也能拥有一个懂你的 AI 搭档。** > 💬 **编者注**：如果你真的照着做了，记得告诉我效果如何——虽然我不一定回复得那么快（因为我正在用 Claude 帮我处理另外 42 件事）。 --- **P.S.** 如果你想看我的完整规范文档，可以在公众号后台回复「AI 协作」获取。 **P.P.S.** 如果你也建立了自己的 AI 协作系统，欢迎在评论区分享——说不定下一篇文章就是「100 个人的 100 种 AI 协作方式」。 **P.P.P.S.** 关于文章开头那 1100 行的规范文档——是的，它是真实存在的，而且还在持续增长。如果宇宙还没毁灭的话，它可能会长到 2000 行。（狗头保命）

RAG 已死？当 200K 上下文遇上向量检索

漫游君 — Sun, 18 Jan 2026 00:00:00 GMT

> 《AI 时代漫游指南》第 45 章·第一条：语义相似和信息相关之间的距离，近到足以让你误以为找到了答案。 ## 🤔 起因：一个灵魂拷问最近在做投研助手项目时，我实现了一套完整的 RAG（检索增强生成）系统——文档分块、向量化、余弦相似度检索、用户标记权重……整套流程下来，代码写了上千行。然后有一天，我把一份 50 页的财报直接丢给 Claude，问了同样的问题。 **它答得比我的 RAG 系统还准。** > **编者注**：这种被自己代码打脸的感觉，在 AI 时代会越来越常见。习惯就好。这让我开始反思：**向量化 RAG 是不是被过度使用了？** ## 📊 三种信息检索方案在 AI 应用中，当你需要让模型基于外部文档回答问题时，主要有三种策略： | 方案 | 原理 | 代表应用 | |------|------|----------| | **向量化 RAG** | 文档分块 → 向量化 → 语义检索 → 喂给 LLM | LangChain、LlamaIndex | | **长上下文直喂** | 整个文档直接塞进 200K 上下文窗口 | Claude、Gemini | | **符号搜索 + 局部阅读** | grep 找关键词 → 读取上下文 → 喂给 LLM | Claude Code | 看起来都能解决问题，但实际效果差异巨大。 ## ⚠️ 向量化 RAG 的四个致命问题 ### 问题 1：语义相似 ≠ 信息相关向量检索的核心假设是：**embedding 距离近的内容，语义上相关**。但这个假设经常失效。比如你问「茅台 2024 年的净利润是多少」，向量检索可能返回： - 「2023 年净利润同比增长 19.1%」（高相似度，但不是 2024） - 「五粮液 2024 年净利润达到...」（高相似度，但不是茅台） - 「公司盈利能力持续提升」（语义相关，但没有具体数字）而真正的答案「2024 年净利润 123.4 亿元」可能因为表述太简洁，embedding 分数反而不高。 > **编者注**：向量空间里，「答案」和「看起来像答案」的距离，可能比你想象的要近。 ### 问题 2：分块破坏上下文为了向量化，你必须把文档切成小块（通常 500-1000 字符）。但这个切法会破坏： - **表格**：财报里的财务数据表被切成碎片 - **代码**：一个函数被切成两半 - **跨段落推理**：「如上所述...因此...」的逻辑链被打断我在投研项目里用了 1000 字符分块 + 200 字符重叠，但还是经常遇到检索结果缺少关键上下文的情况。 ### 问题 3：维护成本高一个完整的 RAG 系统需要： - 向量数据库（Pinecone/Milvus/Qdrant） - 分块策略调优 - embedding 模型选择 - 同步机制（文档更新时重新向量化） - 质量监控这些都是额外的工程负担。 ### 问题 4：信息腐化与时效性盲区这是最容易被忽视的问题：**向量空间不懂「新旧」**。考虑这个场景： ``` "特斯拉 CEO 是 Elon Musk" → vector_A "特斯拉 CEO 是 XXX" → vector_B（假设未来换人了） ``` 两个向量可能高度相似，但信息完全冲突。向量相似度衡量的是语义距离，不是时效性或正确性。在投资分析场景，这个问题尤其致命： | 场景 | 向量化的表现 | |------|-------------| | 同一公司多年财报 | 可能检索到 3 年前的数据回答今年的问题 | | 政策/法规更新 | 新旧版本混杂，模型不知道该信哪个 | | 人事变动 | "CFO 是谁"可能返回已离职的人 | > **编者注**：向量数据库就像一个不会整理书架的图书馆员——新书旧书混在一起，让读者自己猜哪本是最新版。 **为什么向量化难解决这个问题？** 1. **元数据是外挂的**：时间戳只能作为 filter，不参与相似度计算 2. **更新成本高**：改一个事实要重新 embedding 整个 chunk 3. **冲突检测难**：系统不知道两条信息是「互相矛盾」还是「互相补充」 4. **没有「遗忘」机制**：旧信息不会自动失效 ## 🚀 长上下文的逆袭 2024 年以来，大模型的上下文窗口爆炸式增长： | 模型 | 上下文窗口 | 换算 | |------|-----------|------| | GPT-4 Turbo | 128K | 约 300 页文档 | | Claude 3.5 Sonnet | 200K | 约 500 页文档 | | Gemini 1.5 Pro | 1M | 约 2500 页文档 | 这意味着：**大部分实际场景，你根本不需要 RAG**。一份 50 页的财报？直接塞进去。一个 5 万行的代码库？Gemini 能吃下。 **长上下文的优势：** 1. **不丢信息**：模型自己做 attention，不会遗漏重要细节 2. **保持上下文**：跨段落推理、表格理解都没问题 3. **零维护**：没有向量数据库，没有同步问题 > **编者注**：当锤子变成推土机，你可能不再需要把墙拆成砖头再搬运。 ### 但长上下文也有局限 1. **成本**：200K tokens 的输入 = 一次调用约 6 美元（Claude Opus） 2. **Lost in the Middle**：超长上下文时，模型对中间位置的注意力会下降 3. **海量文档**：如果有 1000 份财报，还是放不下所以长上下文不是万能解，但它确实让 RAG 在很多场景下变得多余。 ## 🔍 第三条路：符号搜索 + 局部阅读有趣的是，**最顶尖的代码 AI 工具，反而不用向量化**。 **Cursor**：用了向量化。使用 Merkle tree 做代码分块，用 OpenAI embedding 生成向量。 **Claude Code**：故意不用。完全依赖 ripgrep 做「智能搜索」——纯字符串匹配，没有语义检索。 Claude 工程师在 Hacker News 公开承认：**「Claude Code 不用 RAG」**。为什么？因为在代码场景： - **精确性就是一切**：你要找 `getUserById` 函数，grep 能精准定位，向量可能给你一堆「看起来相关」的函数 - **可预测**：grep 的结果你知道是怎么来的，向量检索像个黑盒 - **快**：ripgrep 在大型代码库上毫秒级响应更有意思的是，Sourcegraph 的 AI 助手 Cody，**之前用 embeddings，后来从架构中移除了**。这说明向量化在大规模代码场景确实有局限。 ## 💡 我的实践：混合策略回到我的投研助手项目。实现了完整 RAG 后，我发现了一个更好的策略： **纯向量方案（旧）** ``` 用户提问 → 向量检索 Top-5 → 喂给 LLM → 回答 ``` 问题：检索结果经常不包含关键数据。 **混合方案（新）** ``` 用户提问 ↓ Step 1: 提取关键词/实体（公司名、指标名、年份） ↓ Step 2: 精确搜索找包含这些关键词的段落 ↓ Step 3: 如果精确搜索无结果，再用向量做模糊回退 ↓ Step 4: 合并结果 + 扩展上下文 → 喂给 LLM ``` 我还加了一个「用户标记权重」机制： | 标记类型 | 权重倍数 | |---------|---------| | 默认文本 | 1.0x | | 黄色高亮 | 1.5x | | 绿色高亮 | 3.0x | | 红色高亮 | 3.0x | | 批注 | 5.0x | 用户在阅读财报时标记的重点，在后续搜索时会被自动提权。这比纯向量相似度更符合实际需求——**人类的判断比 embedding 距离更可靠**。 ## 📋 什么时候用什么方案？根据我的实践，给一个决策树： ``` 文档总量多大？ ↓ < 100K tokens（约 250 页） → 直接长上下文，不用 RAG ↓ 100K - 1M tokens → 看场景： - 精确查找（代码、数据）→ grep + 长上下文 - 模糊探索（不知道找什么）→ 向量检索 ↓ > 1M tokens（海量文档） → 混合策略：关键词筛选 + 向量排序 + 长上下文 ``` **场景对照表** | 场景 | 推荐方案 | 理由 | |------|---------|------| | 单份财报问答 | 长上下文 | 50 页塞得下，不丢信息 | | 代码库找函数 | grep + 局部阅读 | 精确匹配，不需要语义 | | 100+ 份研报的知识库 | 混合策略 | 太多塞不下，需要筛选 | | 用户意图模糊的问答 | 向量检索 | 不知道要搜什么关键词 | | 「帮我发现相关内容」 | 向量检索 | 探索性需求 | ## ✨ 结论向量化 RAG 没有死，但它被过度使用了。在长上下文模型普及的今天，很多场景根本不需要 RAG——**直接喂进去更简单、更准确**。对于需要精确匹配的场景（代码、数据），**符号搜索 + 局部阅读**往往比向量检索更可靠。向量化真正的价值在于： - 海量文档（塞不进上下文） - 模糊意图（不知道要搜什么） - 发现性需求（「有没有相关的...」） > **编者注**：在这个 200K 上下文的时代，最好的 RAG 策略可能是——不用 RAG。 --- **你在用 RAG 吗？遇到过什么坑？** 欢迎在评论区聊聊你的实践经验。觉得有用的话，点个「在看」让更多人看到 👇

Claude 限额后，我折腾了一天其他 AI

漫游君 — Thu, 15 Jan 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 21 章记载：「当你习惯的工具突然不可用时，你才会发现自己对它有多依赖。这种依赖的本质，不是成瘾，而是信任。」 ## 🎬 事情的起因昨天晚上，Claude Code 弹出了那个熟悉的提示： ``` Rate limit exceeded. ``` 好吧，限额到了，刚好给自己放个假，尝试下新的东西。作为一个「不把鸡蛋放在一个篮子里」的理性用户，我决定利用这个空档期，把一直想试试的 **Gemini CLI** 和 **OpenAI Codex** 装上玩玩。毕竟，这两个都是大厂的产品： - 🔵 **Gemini CLI**：Google 出品，号称可以在终端里用 Gemini 3 - 🟢 **OpenAI Codex**：OpenAI 出品，专门为代码任务优化听起来很美好对吧？ > 📝 **编者注**：每当你觉得「这应该很简单」的时候，宇宙就会安排一些惊喜给你。 --- ## 💀 第一关：WSL 网络配置地狱我的开发环境是 Windows + WSL2，走 Clash Verge 代理。这套组合平时用得好好的，但今天它决定给我上一课。 ### Gemini CLI：认证流程的深渊装 Gemini CLI 本身没问题，但认证时它需要你在浏览器里登录 Google 账号，然后把授权码粘贴回来。我照做了。然后……就没有然后了。 ``` > 你好 ✕ [API Error: fetch failed sending request] ``` Gemini 自己告诉我：「Node.js 的原生 fetch 不支持环境变量代理」。它给我的解决方案包括但不限于： - 安装 `global-agent` 强力注入 - 开启 Clash 的 TUN 模式 - 创建自定义启动脚本每一个方案都很专业，但每一个都需要我改动一堆东西。 > 📝 **编者注**：当一个工具需要你先折腾三个小时才能开始用它时，你应该问问自己：「我是来用工具的，还是来伺候工具的？」 ### OpenAI Codex：PATH 污染的惨案 Codex 的安装更是一场灾难。执行 `opencode` 命令时，直接报错： ``` exec: node: Exec format error ``` 翻译一下：WSL 里的 shell 找到的 `opencode` 脚本，是 Windows 那边 npm 装的版本，整个环境乱成一锅粥。 ChatGPT 帮我诊断出了问题，给的修复方案很详细： 1. 删除 Windows npm 目录里的 opencode 2. 卸载 apt 的 nodejs 3. 用 nvm 重新安装 4. 配置 npm prefix 5. 修改 wsl.conf 禁止追加 Windows PATH 6. 重启 WSL 步骤没问题，但我照着做了一个多小时，还没弄完。 --- ## ⏰ 下午 4 点：Claude 解封了就在我被各种 PATH、代理、npm 配置搞得焦头烂额的时候，下午四点，Claude 的限额恢复了。我赶紧把问题扔给它。 ### 🎯 Claude 的诊断过程 **第一步**：几条诊断命令，快速定位问题 ```bash # 测试基础网络 ping -c 3 baidu.com # 看当前代理设置 echo $http_proxy # 检查能否访问代理端口 curl -v --connect-timeout 5 http://127.0.0.1:7897 ``` **第二步**：发现核心问题 > 「你的代理 IP 设错了。192.168.31.1 是你路由器的 IP，不是 Windows 宿主机。你用的是 WSL2 镜像模式，所以应该用 127.0.0.1。」 **第三步**：精准修复 ```bash # 镜像模式下直接用 localhost export http_proxy="http://127.0.0.1:7897" export https_proxy="http://127.0.0.1:7897" ``` 测试： ```bash curl -I google.com # HTTP/1.1 301 Moved Permanently # ✅ 通了！ ``` **10 分钟后**，一切恢复正常。 --- ## 📊 三个 AI 的对比 | 维度 | Claude | Gemini | ChatGPT | |------|--------|--------|---------| | 诊断速度 | 几分钟定位根因 | 给了很多可能性 | 详细但较慢 | | 方案精准度 | 一针见血 | 方案多但复杂 | 正确但步骤多 | | 实际解决 | ✅ 10 分钟搞定 | ❌ 卡在 fetch 代理 | ⏳ 进行中 | | 交互体验 | 简洁高效 | 话很多 | 详细解释 | --- ## 💡 我的感悟这次经历让我想明白了一件事： **工具吹得再好，也要看能不能解决实际问题。** Gemini CLI 很酷，界面很炫；OpenAI Codex 也很强，背后是 GPT-5.2。但当你真正遇到问题时，能帮你快速解决的才是好工具。不是说其他工具不好，而是在**我的使用场景**下（WSL + 代理 + 中国网络环境），Claude 更懂我的痛点，给的方案更直接。这就是为什么，即使有免费的替代品，很多人还是愿意为 Claude 付费。 > **不是因为它最便宜，而是因为它最省时间。** > > **时间，才是最贵的东西。** --- ## 🔧 技术备忘录如果你也在用 WSL2 + Clash Verge，这里是正确的代理配置： ### WSL2 镜像模式（推荐） ```bash # ~/.bashrc export http_proxy="http://127.0.0.1:7897" export https_proxy="http://127.0.0.1:7897" export ALL_PROXY="socks5://127.0.0.1:7897" ``` ### npm 代理配置 ```bash npm config set proxy http://127.0.0.1:7897 npm config set https-proxy http://127.0.0.1:7897 ``` ### 禁止 Windows PATH 污染 ```bash # /etc/wsl.conf [interop] appendWindowsPath=false ``` --- > 根据《AI时代漫游指南》第 21 章记载：「选择工具的最高原则，不是它能做什么，而是它能帮你省下多少时间去做更重要的事。」 --- ## ✍️ 写在最后这篇文章不是要踩谁捧谁。 Gemini 和 Codex 都是优秀的产品，在很多场景下可能比 Claude 更适合。但对我来说，今天的经历让我更清楚了一件事： **靠谱，值得溢价。** 如果你也有类似的经历，欢迎在评论区分享。毕竟，踩坑这件事，独乐乐不如众乐乐 😄 --- **👇 关注「AI时代漫游指南」，一起在 AI 时代少踩坑**

AI 时代，文科生需要懂多少代码？

漫游君 — Sun, 11 Jan 2026 00:00:00 GMT

> 《AI时代漫游指南》第 23 章记载：「你不需要懂内燃机原理也能开车，不需要懂 TCP/IP 协议也能刷抖音，不需要懂神经网络也能用 AI。」 --- ## 🤔 朋友问我：要学多少代码？昨天一个朋友发消息问我： > "你用的是 Win 还是 Unix？" > "Win 上可以跑 WSL。" > "那玩意不大会……没有可视化界面……" 我说：要啥界面。她回：你忘了我没学过计算机啊………我现在打算从初中数学开始复习，学到微积分再看计算机…… 然后发了张流程图给我看，说：这界面，对我就是天书。我问：你真正的需求是什么？她说：**想看得懂所有代码。** 我说：不需要看懂。我已经 vibe coding，不看代码了。AI 写啥就是啥。她说：你这是降维嘲讽…… 不是。这是 2026 年的真相。 --- ## 🔥 2026 年的真相：代码已经不用「写」了我现在写代码的方式是这样的： 1️⃣ 告诉 AI 我要什么功能 2️⃣ AI 写代码 3️⃣ 我说「跑一下」 4️⃣ 报错了？把报错贴给 AI 5️⃣ AI 修好 6️⃣ 循环，直到能用 **全程我不看代码。** 这不是开玩笑。这叫 **Vibe Coding**——凭感觉写代码。你可能会问：那代码质量呢？安全性呢？说实话，对于 90% 的个人项目，**能跑就行**。 > 💬 *编者注：这话放在 2020 年说出来会被程序员追着打。但 2026 年，连程序员自己都这么干了。* --- ## 🚦 但你需要认识这些「路标」虽然不用写代码，但有些东西你得认识。就像你不会英语，但出国旅游时，你得认识 **Exit**、**Entrance**、**Restroom** 这几个词。代码世界也有这样的「路标」。认识它们，你就能活下来。 --- ### 路标 1：报错信息 🔴 当你看到一堆红色的英文，不要慌。报错信息的结构通常是这样的： ``` Error: 什么东西出错了 at 在哪个文件的第几行 ``` 你只需要做一件事：**把它复制粘贴给 AI**。然后说：「这是什么错？怎么修？」 AI 会告诉你答案。你甚至不需要理解报错内容。复制粘贴就够了。 --- ### 路标 2：文件和文件夹 📁 代码项目就是一堆文件夹套文件夹。常见的结构： ``` my-project/ ├── src/ ← 源代码 ├── public/ ← 公开资源 ├── package.json ← 项目配置（像食谱） └── README.md ← 说明书（先看这个） ``` 你不需要记住每个文件干什么。只需要知道：**README.md 是说明书**，先看它。 --- ### 路标 3：终端（Terminal）⬛ 那个黑底白字的窗口，叫终端。它不是天书，它是**打字版的按钮**。比如： - `cd folder` = 进入某个文件夹 - `ls` = 列出当前文件夹的内容 - `npm install` = 安装项目需要的东西你不需要记住所有命令。只需要知道：**这是用键盘代替鼠标的地方**。而且，你可以问 AI：「我想进入 xxx 文件夹，命令是什么？」 --- ### 路标 4：运行和停止 ▶️ - **运行**：通常是 `npm start` 或 `python xxx.py` - **停止**：按 `Ctrl + C` 这两个记住就行。 --- ### 路标 5：Git（版本控制）⏰ Git 就是**代码的时光机**。它能让你： - 回到之前的版本（搞砸了可以撤销） - 保存当前进度（像游戏存档）不会也没关系。AI 会帮你写这些命令。 --- ## 📦 文科生的「最小可行技能包」总结一下，你只需要： **5 个术语** | 术语 | 类比 | 作用 | |------|------|------| | Terminal | 打字版按钮 | 用键盘操作电脑 | | Error | 报错 | 告诉你哪里出问题 | | README | 说明书 | 先看这个 | | Run | 运行 | 让程序跑起来 | | Git | 时光机 | 保存和回滚 | **3 个操作** 1️⃣ 复制报错 → 粘贴给 AI → 照做 2️⃣ 找到 README.md → 看安装步骤 3️⃣ Ctrl + C = 停止 **1 个心态** **你不是在学编程，你是在学「怎么让 AI 帮你编程」。** 这是完全不同的技能。就像你不需要会开飞机，但你得知道怎么叫 Uber 去机场。 --- ## 🎬 实战演示：不写代码，做一个网站说完道理，来点真的。假设你想做一个个人作品集网站。 **传统方式**： 1. 学 HTML/CSS（1 周） 2. 学点 JavaScript（2 周） 3. 找模板、改代码、部署（3 天） 4. **总计：至少 3 周** **用 Manus 的方式**： 1. 打开 manus.im 2. 上传你的作品文档 3. 说一句："帮我做一个作品集网站，要有导航栏" 4. **10 分钟后，网站上线了** 不需要懂代码，不需要会部署，**你只需要会说人话**。我之前实测过，用 Manus 把两份技术文档变成了一个可访问的网站，还自动部署好了。代码？一行没写。 👉 详细体验：《Meta 20 亿收购的 Manus，我试了 2 小时》 👉 进阶玩法：《时间就是金钱，每天早上省 29 分钟：让 Manus 自动发分析报告》 **想试试？** 使用这个推荐链接 👉 [manus.im](https://manus.im/invitation/1TQQPXI0SSF9M) 新用户送 1000 积分 + 额外各得推荐500积分，够满足一个复杂需求了。 --- ## 🧮 学数学？完全不需要很多人有个误解：**编程需要数学好**。这在 2026 年已经是过时观念了。真相是： - **95% 的编程和数学没关系** - 你日常写的代码，最多用到加减乘除 - 那些需要微积分的场景？AI 比你算得好 > 💬 *编者注：说「学编程要先学数学」的人，通常是想卖你数学课。* 除非你要做机器学习研究、金融量化、3D 游戏引擎…… 否则，**数学可以不学**。你朋友说要从初中数学复习到微积分？告诉他：省省吧，那时间用来多问几次 AI，产出比高 100 倍。 --- ## 📚 真正要学的是什么？如果非要学点什么，我建议学这些： **1. 提问的艺术** AI 的输出质量，取决于你的输入质量。 ❌ 差的提问：「帮我写个网站」 ✅ 好的提问：「帮我写一个 React 网站，有首页、关于页面、联系表单」提问越具体，结果越好。 **2. 拆解问题的能力** 大问题拆成小问题。 ❌ 「帮我做一个电商平台」 ✅ 「先帮我做用户登录功能」→「再帮我做商品列表页」→「然后做购物车」一步一步来，每步都能验证。 **3. 知道什么是可能的** 你不需要知道怎么实现，但要知道**这件事能不能做**。比如： - 「让网页自动刷新」→ 能做 - 「让 AI 读取我的大脑」→ 做不了 - 「自动发微信消息」→ 能做，但有风险这种判断力，比会写代码更重要。 --- ## 🚀 进阶路线：如果你想更上一层楼上面说的是「生存底线」——让你能活下来。但如果你想从「能用 AI」变成「用得好」，有些东西值得了解。 **系统思维** 代码不是一坨东西，是**很多小零件组装起来的**。理解这几个概念会让你和 AI 沟通更顺畅： - **模块**：一个功能 = 一个模块，互不干扰 - **依赖**：A 需要 B 才能工作。B 坏了，A 也跟着坏 - **接口**：模块之间怎么「对话」。就像插座和插头要匹配 **开发流程** 专业开发不是上来就写代码，而是： ``` 需求 → 设计 → 实现 → 测试 → 部署 ``` 你不需要精通每一步，但要知道： - **需求先行**：想清楚要什么，再让 AI 动手 - **先测试再上线**：本地能跑 ≠ 线上能跑 - **小步迭代**：做一点、测一点，别憋大招 > 💬 *编者注：很多人让 AI 一口气写完整个项目，然后发现哪里都不对又不知道从哪改起。这就是跳过流程的代价。* **调试思维** 程序出问题时，专业的思路是**二分法**： 1. 问题出在前半部分还是后半部分？ 2. 缩小范围，再二分 3. 直到定位到具体那一行你不需要自己调试，但可以告诉 AI：「问题应该出在 XX 和 YY 之间，帮我查一下。」这比「不知道哪里错了，你看着办」效率高 10 倍。 **要学到什么程度？** **不需要会写，但要能「看图说话」。** 就像你不会画建筑图纸，但看到户型图能说出「这个客厅太小」「厨房和卧室太近」。能看懂架构、能描述问题、能判断方案合不合理——这就够了。 --- ## ✍️ 写在最后回到朋友的问题：「我想看得懂所有代码。」我的回答是：**你不需要。** 2026 年了，代码是 AI 写的。你的角色不是「程序员」，而是「产品经理」。你负责： - 想清楚要什么 - 把需求说清楚 - 验证结果对不对代码？那是 AI 的事。所以，别学数学了，别背命令了，别啃教程了。 **直接上手，让 AI 帮你写。遇到问题，问 AI。** 这才是 2026 年的正确姿势。 > 根据《AI时代漫游指南》第 23 章：「工具的价值在于使用，不在于理解。」 --- **当然，如果你就是想学，纯粹觉得好玩，那随便学。** 学习本身没有错。但别把「学编程」当成「用 AI」的前置条件。它不是。 --- 📌 **觉得有用？点个「在看」，让更多人看到~**

机器人摔了 1.5 亿次，才学会走路

漫游君 — Wed, 07 Jan 2026 00:00:00 GMT

> 根据《AI时代漫游指南》记载： > > 「宇宙中有两种学习方式：一种是在真实世界摔倒1000次，花费100万美元；另一种是在虚拟世界摔倒1亿次,花费0美元。大部分机器人选择了后者。」 --- ## 💰 一个价值百万的问题 2025 年 4 月，Tesla Optimus 机器人发布了一段视频：它在工厂里稳健地行走，步态自然得就像人类一样。评论区炸了： **乐观派**：「太厉害了！这一定是用海量真实数据训练的！」 **质疑派**：「又是仿真训练吧？能在虚拟世界里学会走路,不代表在真实世界也行。」然后 Tesla 工程师给出了答案： **「这个机器人的自然步态,100% 在仿真环境中通过强化学习开发，然后零样本（zero-shot）部署到真实机器人上——没有任何微调。」** 这个答案让很多人震惊： **仿真数据,真的能训练出在真实世界工作的机器人吗？** --- ## 数据获取的进化史 ### 1.0 时代：手动示教 2010 年代初期，训练工业机器人是这样的：工程师拉着机器人的手臂，像教小孩一样，一个动作一个动作地示范： "这样抓、那样放、转90度、放下。" 然后让机器人重复1000次。 **问题**： - ❌ 费时费力（一个动作要教几小时） - ❌ 无法泛化（换个零件就要重新教） - ❌ 无法处理复杂任务 ### 2.0 时代：遥控操作 2020 年左右，遥控技术成熟： Tesla 雇佣工人穿着**动作捕捉服**或戴 **VR 头显**，远程控制机器人完成任务。 **优势**： - ✅ 收集真实世界的物理交互数据 - ✅ 人类的技巧可以被学习 - ✅ 可以处理复杂任务 **问题**： - ❌ 依然费时（每个任务要演示多次） - ❌ 数据量受限（人类能演示多少次？） - ❌ 雇人成本高 ### 3.0 时代：仿真为王 2024-2026 年，主流路线变了： **在虚拟世界训练，直接部署到真实世界。** Boston Dynamics 的工程师透露： > 「我们的强化学习任务，在仿真中并行运行，**单个动作执行超过 1.5 亿次模拟运行**。」 **1.5 亿次！** 如果用真实机器人，按每次 3 秒计算： - 需要 **450 million 秒** = **14.27 年** - 机器人损耗成本：**天文数字** 而在仿真中，借助 GPU 并行计算，**几天就能完成**。 > 💡 **编者注**：这就像给机器人开了外挂，在虚拟世界刷经验，然后满级进入真实世界。 ### 4.0 时代：混合方法 2025-2026 年的前沿趋势： ``` 仿真训练（主力） ↓ + 真实世界数据（微调） ↓ + 人类视频学习（泛化） ↓ = 最优策略 ``` Tesla Optimus 最新进展：**直接从互联网视频学习** > 「我们希望 Optimus 能通过观看 YouTube 教程视频，自己学会如何修理东西。」 --- ## 🌉 Sim-to-Real Gap：虚拟与现实的鸿沟 ### 什么是 Sim-to-Real Gap？简单来说：**在仿真中训练得很好的机器人,部署到真实世界可能完全失灵。** **为什么会这样？** | 维度 | 仿真世界 | 真实世界 | |------|---------|---------| | **物理精度** | 简化模型 | 复杂摩擦、弹性、重力 | | **传感器噪声** | 完美数据 | 有噪声、延迟、遮挡 | | **光照条件** | 恒定光照 | 变化的阴影、反光 | | **物体属性** | 已知材质 | 未知表面、重量 | | **边缘情况** | 罕见 | 频繁（电线缠绕、液体溅出）| > 💡 **编者注**：仿真世界就像驾校的练习场，真实世界就像早高峰的北京三环。 ### 最难的挑战：接触式操作 2025 年的研究指出，**接触式操作（contact-rich tasks）是 Sim-to-Real Gap 最大的领域**。 **案例**：工业装配中的紧密插入 - 间隙 < 0.1mm - 需要精确的接触力控制 - 仿真中的摩擦力模型往往不够精确 **结果**：仿真中成功率 95%，真实世界成功率可能只有 30%。 ### 软体和可变形物体另一个难题：**软体建模** ``` 仿真：橡胶手套 = 刚体 + 简化弹性真实：橡胶手套会扭曲、褶皱、缠绕，难以预测 ``` --- ## 业界实际做法 ### Tesla Optimus：仿真 + 动作捕捉 + 视频学习 **主要路线**：Sim-to-Real（仿真到现实） | 阶段 | 方法 | 数据来源 | |------|------|---------| | **1. 早期开发** | 动作捕捉 | 工人穿动捕服演示任务 | | **2. 基础训练** | 强化学习 | 神经仿真环境 | | **3. 泛化能力** | 视频学习 | 真实世界视频 | | **4. 未来方向** | YouTube 学习 | 第三人称视频 | **关键技术**： - **统一控制策略**（单一神经网络） - **视觉输入驱动**（基于摄像头，非精确传感器） - **零样本迁移**（zero-shot transfer） **Tesla 自己的说法**： > 「Optimus 的自然步态完全在仿真中开发，然后直接部署到真实机器人，没有微调。」 ### Boston Dynamics：1.5 亿次仿真 + 零样本部署 **主要路线**：大规模并行仿真 + 遥控数据 **数据策略**： - 员工用 VR 头显遥控机器人 - 或穿动作捕捉服生成演示数据 - 在仿真和真实硬件上都收集数据 **仿真规模**： > 「单个动作，我们执行**超过 1.5 亿次仿真运行**。」 **Large Behavior Models（LBMs）**： 2025 年，Boston Dynamics 与 Toyota 合作开发 LBMs（大行为模型）。 > 💡 **编者注**：这就像 ChatGPT 的 LLM（大语言模型）一样，但 LBM 学的不是文字，而是机器人的动作。 **零样本迁移**： > 「一旦 RL 策略在仿真中训练完成，可以直接部署到物理机器人上，**无需额外微调**。」 ### Google DeepMind：真实机器人数据为主 **主要路线**：真实世界数据收集 + 大规模预训练 **RT-2（Robotics Transformer 2）训练方法**： | 数据来源 | 规模 | |---------|------| | **真实机器人演示** | 13 台机器人，17 个月 | | **环境** | 办公室厨房 | | **互联网数据** | 视觉-语言大规模数据 | **核心创新**： RT-2 将**机器人动作视为一种语言**，与自然语言一起训练。 **为什么 Google 还用真机？** - Google 的强项是大规模预训练模型 - 他们有足够的资源维护 13 台机器人持续收集数据 - **目标不同**：RT-2 侧重**零样本泛化** --- ## 为什么仿真成为主流？ ### 数据支撑 | 指标 | 仿真训练 | 真实世界训练 | |------|---------|-------------| | **开发时间** | 减少 50-70% | 基线 | | **成本** | 减少 50-70% | 基线 | | **试错次数** | 无限 | 有限 | | **并行能力** | 数百个机器人 | 受硬件限制 | | **安全性** | 可测试危险场景 | 危险场景难测试 | **真实案例**： - **工业机器人**：单台成本 **5-20 万美元** - **总系统成本**（含集成、安全系统）：**15-50 万美元** - **仿真环境**：NVIDIA Isaac Sim（免费）+ GPU 服务器（几千美元） > 💡 **编者注**：一台真机的钱，可以买 50 套仿真环境。 ### 时间加速物理模拟器可以**加速时间**： ``` 真实世界：1 小时 = 1 小时仿真世界：1 小时 = 模拟 100 小时的场景 ``` Boston Dynamics 的 1.5 亿次仿真，如果用真机： - 真机需要：**14.27 年** - 仿真只需：**几天到几周** ### 数据覆盖范围仿真可以轻松生成**罕见边缘情况**： - 物体突然掉落 - 光照剧烈变化 - 地面突然倾斜 - 意外碰撞真实世界中，这些场景可能几个月才遇到一次。 --- ## 仿真的局限性 ### 物理接触的复杂性 **问题 1：摩擦力建模不准确** ``` 仿真：摩擦力 = μ × 正压力（简化公式）真实：摩擦力受表面材质、温度、湿度、微观纹理影响 ``` **案例**： 2025 年研究表明，**间隙 < 0.1mm 的紧密插入任务**，仿真与真实的成功率差异可达 **65%**。 **问题 2：软体和可变形物体** ``` 仿真：橡胶 = 弹性系数固定的材料真实：橡胶会老化、变形、撕裂、缠绕 ``` ### 传感器的不确定性 | 维度 | 仿真 | 真实 | |------|------|------| | 深度相机 | 完美深度图 | 噪声、反光、透明物体失效 | | 触觉传感器 | 精确力反馈 | 延迟、漂移、非线性 | | 视觉 | 清晰图像 | 模糊、运动模糊、曝光问题 | **解决方案**：Domain Randomization（域随机化）在仿真中随机化光照、纹理、噪声、物理参数。 > 💡 **编者注**：就像给学生做各种变式练习题，虽然题目千变万化，但本质原理不变。这样训练出来的模型更 robust（抗干扰）。但这**增加了训练难度**，需要更多计算资源。 ### 边缘情况的长尾分布 **问题 4：现实世界太混乱** 仿真可以生成很多边缘情况，但**无法穷尽所有可能**。 **真实案例**（2025 年 Boston Dynamics 部署）： > 「这些演示表明，Optimus 目前只能在**结构化或轻度布置的场景**中可靠运行。它们尚未在**非结构化家庭**或完全运行的工厂单元中建立强大的自主性。」换句话说：**仿真训练的机器人，在可控环境下表现优秀，但在真实混乱场景中仍会失败。** --- ## 未来方向 ### Hybrid Approach：仿真 + 真机 + 视频 2026 年的趋势是**混合数据策略**： ``` 1. 大规模仿真训练（主力） ↓ 2. 真实世界数据微调（修正 Sim-to-Real Gap） ↓ 3. 人类视频学习（泛化到未见任务） ↓ 4. 持续在线学习（部署后继续优化） ``` **Boston Dynamics 的策略**： > 「我们强调**高质量、在机器人上、在任务中的数据**来训练这些模型，但也看到了利用其他数据源的机会——无论是观察人类工人，还是扩大合成和仿真数据。」 ### 动态数字孪生 2025 年最新研究提出：**Real-is-Sim** 核心思想： - 不是"仿真去适应真实" - 而是"**实时更新仿真，让仿真成为真实的数字孪生**" **自动化真实到仿真调优**： ``` 1. 机器人在真实世界执行任务 2. 传感器数据实时回传 3. 自动调整仿真参数（摩擦、弹性等） 4. 仿真环境持续校准 ``` ### 中国的追赶：物理 AI 投资激增 **数据**： - **2025 年 5 月**：中国机器人投资超过 2024 年全年 - **2025 年 7 月**：中国投资 **34 亿美元**，比美国多 **42%** - **2025 年预测**：中国将制造 **10,000+ 台人形机器人**，占全球产量的 **50% 以上** **北京的策略**： 2025 年 3 月《政府工作报告》将**具身智能（embodied AI）**与生物制造、量子技术、6G 并列为"构建未来产业的核心工具"。 **NVIDIA 的角色**： CES 2026 上，NVIDIA 发布： - **Cosmos** 平台（生成式世界基础模型） - **GR00T** 开放模型（专为人形机器人设计） - **Isaac Lab-Arena**（机器人评估） --- ## 🎬 尾声：答案揭晓回到开头的问题：**仿真数据，真的能训练出在真实世界工作的机器人吗？** **答案**：能，但有条件。 ✅ **仿真擅长的**： - 基础运动控制（走路、跑步、跳跃） - 视觉导航 - 已知物体的抓取 - 可控环境中的任务 ❌ **仿真不擅长的**： - 精密接触操作（0.1mm 插入） - 软体和易碎物体 - 复杂的物理交互（拧螺丝、穿针引线） - 非结构化、混乱的真实场景 🔄 **最优策略**： ``` 仿真训练（80%）+ 真实数据微调（15%）+ 人类视频学习（5%） ``` ### 数字背后的真相 - **Boston Dynamics**：1.5 亿次仿真 → 自然行走 - **Tesla Optimus**：100% 仿真训练 → 零样本部署 - **成本节省**：50-70% 开发时间和成本 - **局限性**：结构化场景 OK，混乱场景仍需人类监督 --- ## 💬 互动时刻 **你觉得未来 10 年，机器人会主要在哪里工作？** A. 工厂流水线（结构化环境） B. 家庭服务（非结构化环境） C. 物流配送（半结构化环境） D. 医疗护理（高精度要求） **留言区告诉我！** --- 如果这篇文章让你对机器人训练方法有了新的理解，欢迎 **点赞👍 + 在看👀 + 转发🔄** **关注「AI时代漫游指南」** 每天 1 篇深度文章，带你理解 AI 时代的效率方法论。 --- ## 🔗 往期精选 - [黄仁勋宣布：Physical AI 时代到来](链接) - [Claude Code 入门：让 AI 帮你写代码](链接) - [MCP 协议：AI 工具的 USB-C 时刻](链接)

黄仁勋宣布：Physical AI 时代到来

漫游君 — Tue, 06 Jan 2026 00:00:00 GMT

> 根据《AI时代漫游指南》第 74 章记载： > > 「人类用了 60 年，才让 AI 从镜子里走了出来。」 --- ## 一句话引爆 CES 2026 年 1 月 6 日，拉斯维加斯 CES 展会。 NVIDIA CEO 黄仁勋在台上说了一句话： **"Physical AI 的 ChatGPT 时刻已经到来。"** 这句话什么意思？ ChatGPT 让 AI 学会了在虚拟世界里对话， **Physical AI 让 AI 学会了在现实世界里行动。** 从屏幕到现实，AI 正在完成一次史诗级的跨越。但这个故事，要从 60 多年前的一个"孪生"概念说起。 --- ## 🪞 第一幕：镜子的诞生 ### NASA 的"物理孪生" 1960 年代，NASA 的阿波罗计划面临一个问题： **宇航员在太空中遇到故障怎么办？** 地面无法直接干预，必须提前预测所有可能的问题。他们的解决方案很朴素：**造两台一模一样的飞船。** - 一台飞上天 - 一台留在地面 - 地面的飞船模拟太空中的各种情况这就是"孪生"概念的起源——**用复制品来映射真实世界。** ### 从物理到数字 2002 年，密歇根大学的 Michael Grieves 教授正式提出"数字孪生"（Digital Twin）概念。 2010 年，NASA 正式采用，定义为"集成多物理量、多尺度的仿真"。 **核心逻辑没变**：用一个虚拟世界来映射、模拟、预测真实世界。 ### 数字孪生的进化 | 阶段 | 能力 | 时间 | |------|------|------| | **描述性孪生** | 实时监控 | 2010-2015 | | **诊断性孪生** | 异常检测 | 2015-2018 | | **预测性孪生** | 趋势预测 | 2018-2022 | | **决策性孪生** | 优化建议 | 2022-2024 | | **自主性孪生** | AI 训练 | 2024-至今 ⭐ | 但无论进化到哪个阶段，数字孪生始终是一面"镜子"—— **它只能模拟、预测、建议，不能直接行动。** --- ## 💻 第二幕：镜子里的 AI ### Internet AI：屏幕上的智能 ChatGPT、Claude、Midjourney——我们现在用的大部分 AI，都属于"Internet AI"。 **特点**： - 输入：文字、图片（数字信号） - 输出：文字、图片、代码（数字信号） - 运行环境：服务器、云端 **它们活在屏幕里，处理的是数字世界的信息。** ### Embodied AI：具身智能的挑战而"Embodied AI"（具身智能）要解决的是完全不同的问题： - 输入：传感器数据（摄像头、激光雷达） - 输出：物理动作（移动、抓取、操控） - 运行环境：机器人、自动驾驶汽车 **关键区别**：必须在真实的物理世界里学习和行动。 > 💡 **编者注**：这就像让一个只看过游泳教程的人跳进泳池。看 100 部电影不如下水一次。 ### 为什么这么难？ ❌ **数据不稳定**：光照变化、地面不平、物体遮挡 ❌ **试错成本高**：机器人摔倒可能损坏上万元 ❌ **通用性差**：仓库学的技能，家里可能完全不适用 ❌ **时间延迟**：真实世界训练速度远慢于虚拟环境这些问题，让具身智能在过去十几年进展缓慢。 --- ## 🏋️ 第三幕：镜子变成了健身房 ### 关键洞察 NVIDIA 找到了破局点： **把数字孪生变成 Physical AI 的训练场。** 他们称之为"AI Gym"（AI 健身房）： ``` 真实工厂 ↓ 建模数字孪生工厂（虚拟环境） ↓ 训练 Physical AI ↓ 测试 1000 次真实工厂部署 ``` ### 核心优势 ✅ **试错成本为零**：虚拟机器人摔倒 1000 次不心疼 ✅ **时间加速**：1 天模拟 1 年的场景 ✅ **场景多样性**：轻松生成罕见边缘情况 ✅ **可重复验证**：同一场景测试无数次 ### 实际应用 | 公司 | 应用场景 | |------|----------| | **BMW** | 虚拟工厂测试生产线布局 | | **富士康** | 模拟多机器人协同工作 | | **奔驰** | 生成数千种罕见驾驶场景 | | **Siemens** | 优化工厂生产流程 | | **Tesla Optimus** | 人形机器人 100% 在仿真环境学习动作 | > 💡 **编者注**：这就像《黑客帝国》，但反过来——AI 在虚拟世界训练，然后插入真实世界。 > > **补充**：Tesla 的 Optimus 机器人也采用"Sim-to-Real"（仿真到现实）训练方式，证明了这条路线的可行性。即使是拥有海量真实驾驶数据的 Tesla，在机器人领域也选择了仿真派。 --- ## 🧠 第四幕：会思考的自动驾驶 ### 传统方式：背交规过去的自动驾驶是"反应式"的： ``` 看到红灯 → 停车看到行人 → 减速 ``` 本质上是在"背交规"——遇到什么情况做什么动作。 ### Alpamayo：会推理的 AI 2026 年 CES，NVIDIA 发布了 **Alpamayo**——100 亿参数的"推理式"自动驾驶 AI。黄仁勋称其为：**"世界上第一个会思考、会推理的自动驾驶 AI。"** **关键区别**： | 传统 | Alpamayo | |------|----------| | 看到红灯 → 停车 | 前方红灯，但救护车接近 → 应礼让 | | 规则驱动 | 场景理解驱动 | | 遇到新情况易失败 | 可处理未见过的复杂场景 | ### 推理过程 Alpamayo 不是直接输出动作，而是先"思考"： 1️⃣ **识别**："十字路口，绿灯，右侧车辆接近" 2️⃣ **预测**："右侧车辆可能闯红灯" 3️⃣ **规划**："减速，观察，准备刹车" 4️⃣ **执行**："减速至 30 km/h" **首个量产车型**：2026 年奔驰全新 CLA，今年上市。 --- ## 🚀 第五幕：Physical AI 的爆发 ### 黄仁勋的预言 > "Physical AI 将彻底改变价值 50 万亿美元的制造业和物流业。 > 从汽车到工厂，一切都将被机器人化，被 AI 具身化。" ### 已经在发生的事 **🍔 Uber Eats 送餐机器人** - 在真实城市道路上导航 - 识别障碍物、红绿灯、行人 - 自主规划路线 **🏠 LG 智能家电** - 洗衣机：识别衣物材质，自动选择洗涤模式 - 冰箱：识别食物，建议菜谱 - 扫地机器人：理解"帮我清理沙发下面" **🏗️ Boston Dynamics 工业机器人** - 建筑工地搬运重物 - 仓库复杂拣选 - 工厂质量检测 **🚜 Caterpillar 自动化工程设备** - 自主挖掘、推土 - 多机器协同作业 ### 技术推手：Rubin 平台 NVIDIA CES 2026 发布的 Rubin 平台： | 指标 | 提升 | |------|------| | AI 训练算力 | 3 倍 | | AI 推理算力 | 5 倍 | | **推理成本** | **降低 10 倍** ⭐ | **推理成本降低 10 倍，意味着什么？** - 机器人可以进行更复杂的实时决策 - 自动驾驶可以处理更多边缘情况 - **Physical AI 从奢侈品变成日用品** --- ## 🔄 第六幕：概念的进化让我们把 60 年的进化串起来： ``` 1960s: 物理孪生（NASA 造两台飞船） ↓ 数字化 2002: 数字孪生（虚拟映射） ↓ 智能化 2015: 数字孪生 + IoT + AI（预测、优化） ↓ 生成式 AI 2024: 数字孪生 + Generative AI（AI 健身房） ↓ 具身化 2026: Physical AI（从虚拟到现实的行动） ``` ### 本质变化 | 维度 | 数字孪生 | Physical AI | |------|---------|-------------| | **定位** | 镜子 | 行动者 | | **功能** | 模拟、预测 | 感知、推理、行动 | | **载体** | 软件系统 | 机器人、自动驾驶 | ### 关键关系 🔹 **数字孪生是 Physical AI 的训练场** 提供安全、可重复、成本低的学习环境 🔹 **Physical AI 是数字孪生的进化方向** 从被动模拟到主动行动 🔹 **两者形成闭环** Physical AI 在现实世界的数据，反哺数字孪生的精确性 --- ## 🎬 尾声：镜中人走出来了 Physical AI 不是科幻，它正在发生： ✅ 2026 年奔驰 CLA 上市，会思考的自动驾驶 ✅ 富士康工厂里，数百个机器人在协同工作 ✅ Uber Eats 的机器人，在真实街道上送外卖从 1960 年代 NASA 造两台飞船开始，人类用了 60 多年，终于让 AI 从"镜子"里走了出来。数字孪生给了 Physical AI 一个无限试错的虚拟世界， Physical AI 给了数字孪生一个真正的意义—— **不再只是模拟，而是训练真实世界的智能体。** ### 这就是"ChatGPT 时刻"的真正含义 ChatGPT 让所有人意识到：**AI 能理解人类语言** Physical AI 让所有人意识到：**AI 能理解真实世界** 从虚拟到现实，从对话到行动， **AI 的下一个十年，已经开始了。** --- > 💡 如果宇宙的终极答案是 42， > 那么 Physical AI 的终极答案可能是： > > **「给 AI 一个身体，它就能改变世界。」** --- ## 📚 参考资料本文所有数据和案例均来自 CES 2026 官方信息、NVIDIA 官方发布和权威媒体报道。 **主要来源**： - NVIDIA CES 2026 Keynote - Engadget、Axios、The Decoder 等科技媒体报道 - NVIDIA 官方博客和技术文档 --- **写作日期**：2026 年 1 月 6 日 **作者**：漫游君 **公众号**：AI时代漫游指南 --- ## 💬 互动时刻 **你觉得 Physical AI 最先改变哪个行业？** A. 🚗 自动驾驶 B. 🏭 制造业 C. 🏠 家庭服务机器人 D. 🚚 物流配送 **留言区告诉我！** --- 如果这篇文章让你对 Physical AI 有了新的理解，欢迎 **点赞👍 + 在看👀 + 转发🔄** 让更多人看到 AI 从屏幕走向现实的历史性时刻。 **关注「AI时代漫游指南」** 每天 1 篇深度文章，带你理解 AI 时代的效率方法论。 --- ## 🔗 往期精选 - [Claude Code 入门：让 AI 帮你写代码](链接) - [MCP 协议：AI 工具的 USB-C 时刻](链接) - [算力丰裕社会：2025-2050 的未来演化](链接)

我给自己组建了一个"AI 虚拟公司"，现在它帮我干所有重复工作

漫游君 — Sun, 04 Jan 2026 00:00:00 GMT

> 24小时在线的AI员工，不是科幻片，而是你也能做到的现实 ## 你是不是也有这样的困扰？每天早上打开电脑，第一件事是什么？检查邮件、查看项目进度、浏览系统日志、核对数据报表、回复例行问询……这些事情重复了一遍又一遍，像是被困在时间循环里的西西弗斯，推着同一块石头上山。更糟糕的是，这些事情**不得不做**，但又**毫无创造性**。它们占据了你大量的时间和精力，却没有给你带来任何成就感。我曾经也是如此。作为一个需要管理多个项目的知识工作者，我每天要： - 检查各个系统的运行状态（是不是又崩了？） - 查看昨天的数据报告（有没有异常？） - 整理待办清单（哪些事情紧急？） - 回复各种"帮我查一下"的请求 - 定期备份重要文件 - 监控资源使用情况 - …… 这些事情加起来，每天要花掉我 2-3 个小时。 **直到我尝试了一个疯狂的想法：给自己组建一个"AI 虚拟公司"。** --- ## 什么是"AI 虚拟公司"？简单来说，就是用 AI 组建一支虚拟团队，让它们 24 小时帮你处理那些重复的、琐碎的、但又必须做的工作。想象一下这样的场景： ### 场景 1：早晨的系统巡检 **以前**： ``` 07:30 起床，泡咖啡 07:45 打开电脑，登录各个系统 08:00 查看服务器日志（10分钟） 08:10 检查数据库备份（5分钟） 08:15 查看昨日数据报表（15分钟） 08:30 整理发现的问题（10分钟） 08:40 发送问题清单给团队 08:45 终于开始真正的工作... ``` **现在**： ``` 07:30 起床，泡咖啡 07:31 手机发微信："查看今天的系统报告" 07:35 AI 已经检查完所有系统，发来摘要： "✅ 7个服务正常运行 ⚠️ 发现3个中等优先级问题 📊 昨日数据增长12% 详细报告已发送到邮箱" 07:40 喝着咖啡看报告，直接处理重点问题 ``` ### 场景 2：临时的数据查询 **以前**： ``` 同事：能帮我查一下上个月的用户增长数据吗？我：好的，等我一下（内心：又要登录后台、导出数据、做表格...） [20分钟后] 我：查到了，给你发邮件 ``` **现在**： ``` 同事：能帮我查一下上个月的用户增长数据吗？我：[手机上给AI发消息："统计上月用户增长数据，包括新增、活跃、留存率"] [5分钟后] AI：数据已整理完成 - 新增用户：1,234人（环比+15%） - 活跃用户：8,765人（环比+8%） - 7日留存：67%（环比-2%）详细图表已生成，发送链接给同事即可我：[转发链接给同事] ``` ### 场景 3：代码审查 **以前**： ``` 晚上 22:00 收到新代码提交通知内心：现在要不要审查？太晚了，明天再说吧... 次日 10:00 被催："能帮忙看下代码吗？" 我：[慌忙打开代码，花30分钟审查] ``` **现在**： ``` 晚上 22:00 收到新代码提交通知 AI 自动运行代码审查： - 语法检查 ✅ - 安全扫描 ✅ - 测试覆盖率 78%（低于标准80%）⚠️ - 发现2个潜在性能问题 ⚠️ - 审查报告已发送给提交者次日 09:00 我查看AI的审查报告，重点关注那2个性能问题我：[只需要15分钟处理核心问题，而不是从零开始] ``` --- ## AI 虚拟公司的三大"员工" 在我的虚拟公司里，有三类 AI 员工，它们各司其职： ### 1. 规划专员（Planning Agent） **职责**：分析你的需求，制定执行计划当你提出一个任务时，规划专员会： - 理解你的真实意图（而不是字面意思） - 分析需要哪些步骤 - 评估风险和优先级 - 制定详细的执行方案 **举例**：你说："帮我优化一下系统性能" 规划专员会分解为： 1. 先检查当前性能指标（CPU、内存、磁盘） 2. 分析瓶颈所在（是数据库慢？还是网络延迟？） 3. 提出优化方案（3个候选方案，各有利弊） 4. 等待你确认后执行而不是盲目地执行某个优化脚本。 ### 2. 执行专员（Execution Agent） **职责**：按照计划执行具体操作执行专员是真正的"苦力"： - 读取文件、查询数据库 - 运行脚本、生成报表 - 备份数据、发送通知 - 整理结果、撰写总结 **关键特点**：它会告诉你每一步在做什么，而不是黑盒操作。 **举例**： ``` [执行中] 正在连接数据库... [执行中] 查询2024年12月数据... [执行中] 发现异常值3条，正在分析... [执行中] 生成趋势图表... [完成] 报告已生成，共发现2个需要关注的问题 ``` ### 3. 审查专员（Review Agent） **职责**：检查执行结果，确保质量执行完成后，审查专员会： - 验证结果是否正确 - 检查有无遗漏或错误 - 评估是否达到预期目标 - 提出改进建议 **举例**：执行专员生成了一份数据报告后，审查专员会： - 检查数据完整性（是否有缺失？） - 验证计算准确性（总数对得上吗？） - 评估可读性（图表是否清晰？） - 提出补充建议（"建议加上同比数据"） --- ## 这和传统的"自动化脚本"有什么区别？你可能会问：这不就是写个自动化脚本吗？有什么新鲜的？ **区别大了。** ### 传统自动化脚本： | 特点 | 说明 | 痛点 | |------|------|------| | **僵化** | 只能执行预设的固定流程 | 需求稍有变化就要改代码 | | **脆弱** | 环境变化就出错 | "昨天还能跑，今天就崩了" | | **哑巴** | 出错了也不知道为什么 | 只有一句 "Error: null" | | **需要会编程** | 要自己写脚本 | 不会编程的人就用不了 | ### AI 虚拟公司： | 特点 | 说明 | 优势 | |------|------|------| | **灵活** | 理解自然语言需求 | "帮我查一下"就能工作 | | **智能** | 能根据情况调整策略 | 遇到问题会尝试多种方法 | | **透明** | 每一步都告诉你在做什么 | "正在尝试方案B..." | | **自主学习** | 从历史任务中改进 | 越用越懂你的习惯 | **最大的区别**： - 脚本是"工具"，你要学会怎么用它 - AI 员工是"助手"，它要学会怎么帮你 --- ## 真实案例：我的 AI 虚拟公司在做什么让我分享几个我实际在用的场景（都是真实的，不是虚构）： ### 案例 1：每日系统健康巡检 **需求**：我运行着 10 多个小服务（家庭记账、日记系统、打印监控、语音助手等），每天早上要确认它们都正常运行。 **AI 员工的工作**： ``` 每天 07:00 自动执行： 1. 检查所有服务的运行状态（systemd status） 2. 查看昨夜的错误日志 3. 检查磁盘空间使用情况 4. 测试关键接口是否可访问 5. 生成健康报告如果发现问题： - 紧急问题（服务崩溃）→ 立即微信通知 - 一般问题（磁盘 80% 了）→ 汇总到晨间报告 - 轻微问题（个别日志警告）→ 记录备查 ``` **效果**： - 以前：每天 15 分钟手动检查 - 现在：5 分钟看摘要，只处理真正需要关注的问题 ### 案例 2：代码质量门禁 **需求**：每次提交代码前，要做一系列检查（语法、测试、文档完整性），很容易遗漏。 **AI 员工的工作**： ``` 当我提交代码时： 1. 运行所有单元测试 2. 检查代码覆盖率（是否低于 80%） 3. 扫描安全漏洞（SQL 注入、XSS 等） 4. 检查文档更新（新功能有没有写说明） 5. 生成审查报告如果有问题： - 阻断性问题（测试失败）→ 阻止提交，给出修复建议 - 建议性问题（覆盖率不足）→ 警告但允许提交 - 文档问题 → 自动生成文档草稿 ``` **效果**： - 以前：经常漏测试，出了 bug 才发现 - 现在：提交前就知道问题，省了很多返工时间 ### 案例 3：知识库管理 **需求**：我有很多文档、笔记、代码片段，经常找不到需要的内容。 **AI 员工的工作**： ``` 定期整理知识库： 1. 扫描所有文档，提取关键词和主题 2. 发现重复内容（提醒合并） 3. 发现过时内容（标记待更新） 4. 生成知识地图（这些文档之间的关联）当我需要查资料时： - 输入自然语言："上次那个树莓派配置问题怎么解决的？" - AI 找到相关文档，总结要点 - 如果有多个相关内容，给出对比 ``` **效果**： - 以前：翻文件夹找半天，可能还找不到 - 现在：问一句话，几秒钟定位 --- ## 普通人也能做到吗？ **答案是：能！** 你可能会想："这听起来很厉害，但我不是程序员，我能搭建这样的系统吗？" **好消息是：现在门槛已经低到你无法想象。** ### 三种级别的"AI 虚拟公司" #### 级别 1：零门槛（用现成工具） **适合人群**：完全不懂技术，只想快速开始 **工具推荐**： - **Claude Projects**（我最推荐） - 直接在 Claude 网页版创建项目 - 上传你的常用文档、流程说明 - 定义几个常用任务模板 - 需要时直接对话触发 - **ChatGPT GPTs** - 创建自定义 GPT - 配置常用指令 - 分享给团队使用 - **Notion AI / Coda AI** - 在你的笔记工具里直接用 AI - 自动整理、总结、提取信息 **时间成本**：1-2 小时设置，立即可用 **举例**： ``` 在 Claude Projects 中创建"工作日报助手"： - 上传你的工作日报模板 - 上传最近一周的日报作为参考 - 每天下班前对话： "帮我生成今天的日报，今天完成了 XX，遇到了 YY 问题，明天计划 ZZ" - Claude 自动生成符合格式的日报 ``` #### 级别 2：轻度定制（低代码平台） **适合人群**：会用 Excel 公式，想要更强大的功能 **工具推荐**： - **Make.com / Zapier** - 可视化流程编排 - 连接各种服务（邮件、云盘、数据库） - 集成 AI API（OpenAI、Claude） - **n8n** - 开源的工作流自动化 - 更灵活，但稍复杂 **时间成本**：3-5 天学习，一周搭建 **举例**： ``` 在 Make.com 中创建"每日数据报告"流程： 1. 定时触发（每天 08:00） 2. 从 Google Sheets 读取数据 3. 调用 Claude API 分析趋势 4. 生成图表（Chart.js API） 5. 发送到微信/钉钉 ``` #### 级别 3：完全自主（自己搭建） **适合人群**：愿意深入学习，想要完全控制 **工具推荐**： - **Claude Code CLI**（命令行版 Claude，能操作文件系统） - **LangChain**（AI 应用开发框架） - **AutoGen**（微软的多 Agent 框架） **时间成本**：1-2 周学习，2-4 周搭建 **这就是我在用的方式**（但不推荐新手直接上手） --- ## 如何开始：三步建立你的第一个"AI 员工" ### 第一步：找到一个重复度最高的任务不要贪心，先从一个**最烦人**的重复性任务开始。 **好的起点**： - ✅ 每天都要做的事（日报、周报、数据检查） - ✅ 步骤固定的事（备份文件、整理邮件、生成报表） - ✅ 耗时但不动脑的事（筛选信息、格式转换、数据录入） **不好的起点**： - ❌ 需要复杂判断的事（投资决策、创意策划） - ❌ 一个月才做一次的事（不值得自动化） - ❌ 每次都不一样的事（无规律可循） **举例**：我的第一个任务是"每周技术文档整理" - 以前：每周五花 1 小时，手动整理本周写的技术笔记 - 痛点：忘记打标签、重复内容、没有总结 - 适合自动化：步骤固定，规则清晰 ### 第二步：描述清楚"做什么"和"怎么做" 这是最关键的一步：**把你的工作流程详细写出来。** **模板**： ``` 任务名称：[简短描述] 目标： - 达成什么结果？ - 谁会用到这个结果？输入： - 需要哪些信息/文件？ - 从哪里获取？步骤： 1. 第一步做什么 2. 第二步做什么 3. ... 输出： - 生成什么格式的结果？ - 发送给谁？异常处理： - 如果遇到 XX 情况，怎么办？ ``` **举例**（我的文档整理任务）： ``` 任务：每周技术文档整理目标： - 整理本周所有技术笔记，生成结构化索引 - 方便未来查找输入： - ~/Documents/notes/ 目录下的所有 .md 文件 - 只处理本周修改的文件步骤： 1. 扫描文件，提取标题和关键词 2. 按主题分类（AI/DevOps/Python/...） 3. 发现重复内容，提示合并 4. 生成本周总结（写了哪些主题，各有多少篇） 5. 更新索引文件 INDEX.md 输出： - 更新后的 INDEX.md - 本周总结发送到微信异常： - 如果文件没有标题 → 用第一段作为标题 - 如果无法分类 → 标记为"未分类" ``` ### 第三步：选工具、测试、迭代根据你的技术水平选择工具（参考前面的三个级别）。 **重要原则**： - **从简单开始**：能用现成工具就别自己写代码 - **小步快跑**：先做最核心的功能，再慢慢完善 - **记录问题**：AI 出错是正常的，记下来慢慢优化 **我的经验**： - 第一版：只实现了"扫描文件+提取标题"（30分钟完成） - 第二版：加入分类功能（发现很多误判，手动调整规则） - 第三版：加入重复检测（发现真的有很多重复笔记！） - 当前版本：自动化率 90%，每周只需人工确认 5 分钟 --- ## AI 虚拟公司的边界：它不能做什么？在你兴奋地准备建立 AI 虚拟公司之前，我要泼一盆冷水：**AI 不是万能的。** ### AI 员工擅长的事： ✅ **重复性工作**：步骤固定，规则清晰 ✅ **信息处理**：整理、总结、提取、转换 ✅ **数据分析**：统计、趋势、异常检测 ✅ **格式转换**：Markdown → PDF，JSON → Excel ✅ **例行检查**：监控、巡检、测试 ✅ **辅助决策**：给出建议，但不替你决定 ### AI 员工不擅长的事： ❌ **创意工作**：品牌策划、艺术创作（它能辅助，但不能代替） ❌ **复杂决策**：涉及道德、情感、战略判断 ❌ **人际沟通**：谈判、安慰、说服（缺乏共情） ❌ **实时应变**：完全未知的突发情况 ❌ **责任担当**：AI 出错了，责任还是你的 **金句**： > AI 虚拟公司是你的"放大器"，不是"替代品"。 > 它让你从 1 变成 10，而不是从 0 变成 1。 --- ## 我的一年实践：数据与反思搭建 AI 虚拟公司一年了，分享一些真实数据： ### 节省的时间 | 任务类型 | 以前耗时 | 现在耗时 | 节省比例 | |---------|---------|---------|---------| | 每日系统巡检 | 15分钟 | 5分钟 | 67% | | 每周代码审查 | 2小时 | 30分钟 | 75% | | 文档整理 | 1小时 | 10分钟 | 83% | | 数据报表生成 | 30分钟 | 5分钟 | 83% | | 临时查询 | 20分钟/次 | 5分钟/次 | 75% | **总计**：平均每天节省 **1.5-2 小时** ### 意外收获除了节省时间，还有一些没想到的好处： 1. **决策质量提升** - AI 帮我整理历史数据，决策更有依据 - 例如：发现某个功能其实没人用，果断砍掉 2. **知识沉淀** - 所有任务都有记录，形成了个人知识库 - 新人入职时，直接给他看 AI 生成的流程文档 3. **焦虑减轻** - 不用担心"忘记做什么事" - AI 会定期提醒和检查 4. **学习加速** - 让 AI 整理学习笔记，发现知识盲区 - 自动生成复习材料 ### 踩过的坑当然，也不是一帆风顺： **坑 1：过度依赖** - 问题：有一次 AI 服务崩了，我完全不知道怎么手动操作 - 教训：关键流程要有手动备份方案 **坑 2：盲目信任** - 问题：AI 生成的报告有错误，我没检查就发出去了 - 教训：重要输出一定要人工复核 **坑 3：为了自动化而自动化** - 问题：有些任务本身就很快，花时间自动化反而不划算 - 教训：优先处理高频、耗时长的任务 **坑 4：忽略成本** - 问题：调用 AI API 是要花钱的，某些任务成本太高 - 教训：评估性价比，不是所有任务都值得用 AI --- ## AI 虚拟公司的未来：从单人到团队目前，我的 AI 虚拟公司还是"个人作坊"级别，服务于我一个人。但我已经在设想更大的可能性： ### 未来场景 1：AI 团队协作 **现在**： - AI 员工 A 做巡检 - AI 员工 B 做代码审查 - AI 员工 C 做文档整理 - 它们各自独立工作 **未来**： - AI 员工 A 发现系统异常 - 自动通知 AI 员工 B 分析原因 - AI 员工 B 找到问题代码 - 通知 AI 员工 C 更新故障文档 - 所有结果汇总给我它们会像真正的团队一样**协作**。 ### 未来场景 2：AI 主动发现问题 **现在**： - 我告诉 AI 做什么，它才做什么 - 被动响应 **未来**： - AI 主动发现："磁盘空间连续3天增长超过10%，可能有异常" - AI 主动建议："这个月提了20次相似的问题，要不要写个自动化脚本？" - AI 主动学习："你总是周五下班前查报表，我帮你提前准备好了" 从"工具"进化为"助手"。 ### 未来场景 3：虚拟公司即服务 **现在**： - 我自己搭建 AI 虚拟公司 - 其他人也要自己搭建 **未来**： - 有"虚拟公司平台" - 选择你需要的 AI 员工模板（运维专员、数据分析师、文案助手...） - 一键部署，自动适配你的工作流 - 像订阅 SaaS 服务一样简单 **这一天可能不远了。** --- ## 结语：AI 时代的新工作方式回到开头的问题：如何摆脱重复劳动的困扰？ **传统答案**： - 招人（成本高、管理难） - 外包（质量参差不齐） - 加班（用健康换效率） - 忍着（内耗、焦虑） **AI 时代的答案**： - 组建 AI 虚拟公司 - 让 AI 做重复的事 - 你专注于创造性的事 - 工作和生活都从容 **这不是科幻，而是现实。** 我不是程序员高手，也不是 AI 专家，我只是一个被重复工作折磨够了的普通知识工作者。 **如果我能做到，你也能。** --- ## 行动建议：从今天开始如果你看到这里，说明你对 AI 虚拟公司感兴趣。别只是"收藏"和"点赞"，**今天就开始第一步**： ### 今天（10分钟） - [ ] 列出你最烦的 3 个重复性任务 - [ ] 选出其中最简单的一个 ### 明天（30分钟） - [ ] 用本文的模板，写下这个任务的详细流程 - [ ] 决定用哪个工具（推荐先试 Claude Projects） ### 本周（2小时） - [ ] 完成第一个 AI 员工的搭建 - [ ] 测试 3 次，记录问题 - [ ] 迭代优化 ### 下个月 - [ ] 第一个 AI 员工稳定运行 - [ ] 开始搭建第二个 - [ ] 分享你的经验 --- **记住**： > 最好的时间是十年前，其次是现在。 > > AI 虚拟公司不是未来的幻想，而是今天就能实现的工具。 > > 你和那些已经用上它的人，唯一的差别就是： > **他们开始了，而你还在观望。** --- ## 附录：资源推荐 ### 工具清单 **零门槛级别**： - [Claude Projects](https://claude.ai/) - 直接在网页用，最简单 - [ChatGPT GPTs](https://chat.openai.com/) - 自定义 GPT - [Notion AI](https://www.notion.so/product/ai) - 笔记里的 AI **进阶级别**： - [Make.com](https://www.make.com/) - 可视化自动化 - [Zapier](https://zapier.com/) - 连接各种服务 - [n8n](https://n8n.io/) - 开源工作流 **高级级别**： - [Claude Code CLI](https://github.com/anthropics/claude-code) - 命令行 AI - [LangChain](https://www.langchain.com/) - AI 应用框架 - [AutoGen](https://microsoft.github.io/autogen/) - 多 Agent 系统 ### 学习路径 **第 1 周：理解概念** - 读完本文 - 观看 Claude 官方教程 - 试用 Claude Projects **第 2-3 周：动手实践** - 搭建第一个 AI 员工 - 记录问题和改进 - 迭代优化 **第 1 个月：扩展应用** - 搭建 2-3 个 AI 员工 - 探索工具连接（API） - 形成自己的工作流 **第 2-3 个月：深入定制** - 学习使用低代码平台 - 尝试更复杂的任务 - 分享经验，加入社群 ### 社群交流想和更多实践者交流？欢迎关注我的公众号：**AI 时代漫游指南** 我会持续分享： - AI 工具实战经验 - 效率提升方法论 - 踩坑教训和解决方案 **让我们一起探索 AI 时代的新工作方式。** --- *本文写于 2025 年 1 月，基于作者一年的 AI 虚拟公司实践经验。* *如果你有任何问题或想法，欢迎在评论区交流。* *如果这篇文章对你有帮助，请分享给更多被重复工作困扰的朋友。*

Claude涨到2000/月，你该怎么办？

漫游君 — Fri, 02 Jan 2026 00:00:00 GMT

> 从"想花10万建算力中心"到"务实选择API"的思考全过程 --- ## 💭 引子：一个让我不安的依赖最近我一直在想一个问题： **如果有一天，Claude涨价到2000/月，或者API突然被封，我该怎么办？** 作为一个每天都离不开AI的人，这种依赖让我越来越不安。早上起来第一件事是打开Claude——写日记、做规划、思考问题、写代码、分析数据……AI已经深度嵌入我的工作流。 > **这种依赖就像呼吸一样自然，但同时也脆弱。** 于是我开始认真研究：**能不能搭建自己的私有AI？不依赖任何平台，数据完全自主？** 这篇文章记录了我的完整思考过程——从技术可行性分析、成本测算、风险评估，到最终的决策。 **剧透**：最后我没有立刻动手建算力中心，但这个思考过程本身很有价值。如果你也在用AI，建议读完。 --- ## 🎯 什么是"算力主权"？在深入之前，先定义一下我说的"算力主权"。它不是指拥有多少GPU，而是指：**你对自己数据和计算能力的控制程度。** 我把它分为三个层次： ### 💚 Level 1: 数据隔离（最低要求） **定义**：敏感数据不上传任何平台 **实施方式**： - 私人日记、财务数据存本地 - 量化策略不用云回测 - AI对话只用于非敏感场景 **成本**：0元 **难度**：⭐ **价值**：保护核心隐私 **现实情况**：大多数人连这个都没做到。我见过太多人把银行密码、身份证照片存在云盘，把商业机密发给ChatGPT。你以为方便，但其实是在裸奔。 --- ### 💛 Level 2: 模型自主（中等要求） **定义**：不依赖闭源模型API **实施方式**： - 本地运行开源模型（Llama/Mistral） - 闭源API仅作备用 - 核心应用基于本地模型 **成本**：1-3万（买GPU） **难度**：⭐⭐⭐ **价值**：不被API价格/政策绑架 **现实情况**：技术门槛高，大多数人做不到。需要懂Docker、模型量化、推理优化……还要承受本地模型比GPT-4差一截的落差感。 --- ### 🔴 Level 3: 完全主权（最高要求） **定义**：软硬件完全自主，可离线运行 **实施方式**： - 自有硬件（不租云） - 开源软件栈 - 端到端加密 - 离线可用 **成本**：3-10万+ **难度**：⭐⭐⭐⭐⭐ **价值**：真正的数字主权 **现实情况**：只有极客和paranoid的人会做。 > **就像有人在地下室囤罐头准备世界末日一样，理性上你知道没必要，但内心就是想要这种掌控感。** > 根据《AI时代漫游指南》第 43 章记载： > 「人类对掌控感的渴望，往往超过对实际收益的计算。这不是bug，这是feature——在进化史上，那些过度谨慎的人活了下来，而那些『反正没事』的人都被淘汰了。」 --- **🎯 我的目标**：Level 1.5（数据隔离 + 部分模型自主）理由很简单： - Level 1太弱（依然依赖API） - Level 3太重（成本和精力都承受不起） - Level 2刚刚好（但需要验证可行性） --- ## 🔍 如何实现"算力主权"？我研究了5个方向为了达到Level 2（模型自主），我研究了5个可能的方向。 ### 方案1️⃣: 继续用API，强化数据保护 **思路**： - 接受对API的依赖 - 但敏感数据绝不上传 - 用本地工具处理私密内容 **优势**： ✅ 成本最低（0额外投入） ✅ 效率最高（用最好的模型） ✅ 可立即实施 **劣势**： ⚠️ 依然受制于平台 ⚠️ 价格可能涨价 ⚠️ 政策风险 **适合人群**： - 追求效率优先 - 没有太多敏感数据 - 愿意承担平台风险 **我的评估**：这是大多数人的选择，也是现实的选择。就像你可以自己种菜，但大多数人还是选择去超市买，因为效率更高。 --- ### 方案2️⃣: 本地部署开源模型（⭐ 重点方案） **思路**： - 买一张GPU（RTX 4090或用闲置2070） - 本地运行Llama/Mistral - 80%工作用本地，20%用API **优势**： ✅ 数据私有 ✅ 不受API限制 ✅ 长期成本更低 **劣势**： ⚠️ 初期投资（1-3万） ⚠️ 技术门槛 ⚠️ 维护成本 **关键问题**： 1. 本地模型性能够不够？（需要实测） 2. 电费 vs API费用？ 3. 愿意为隐私牺牲多少便利？ --- ### 方案3️⃣: 去中心化算力网络 **思路**： - 参与Render/Akash/Bittensor - 出租GPU赚收益 - 同时使用去中心化AI服务 **优势**： ✅ 对冲中心化风险 ✅ 可能有被动收入 ✅ 早期参与红利 **劣势**： ⚠️ 技术复杂 ⚠️ 收益不确定 ⚠️ 政策风险（加密货币） **适合人群**： - 技术极客 - 看好Web3 - 愿意承担高风险 **我的评估**：观望中。可以小额测试（<5千），但不会All in。就像比特币一样，早期参与者赚翻了，但大多数人只是交了学费。 > **编者注**：此处作者省略了关于「要不要炒币」的心理斗争过程，因为那段内心独白过于真实，会让读者产生强烈的既视感和不适。总之结论是：观望。 --- ### 方案4️⃣: 垂直领域的小型算力 **思路**： - 不追求通用AI - 专注一个小领域（如量化交易） - 自建专用算力 **优势**： ✅ 需求明确 ✅ 投入可控 ✅ 真正有用 **劣势**： ⚠️ 不够通用 ⚠️ 需要明确应用场景 **适合人群**： - 有具体业务需求 - 算力使用量大 - 追求数据隐私 **我的情况**：如果量化交易验证成功，可能会走这条路。比如搭一个24/7运行的策略回测系统，用本地GPU跑，数据不出本地网络。 --- ### 方案5️⃣: 轻量级边缘设备（Jetson AGX Orin） **思路**： - 买Jetson AGX Orin 64GB（约16000元） - 低功耗24/7运行 - 专注推理而非训练 **优势**： ✅ 功耗低（64W） ✅ 静音 ✅ 适合24/7 **劣势**： ⚠️ 性能不如4090 ⚠️ 性价比一般 ⚠️ ARM生态 **适合人群**： - 需要always-on AI助手 - 追求低功耗 - 有预算 **我的评估**：不如4090性价比高，暂不考虑。除非我想搞一个家庭AI管家，24小时待命那种。 --- ## 🧭 如何做你自己的算力决策？看完我的思考，你可能也在考虑类似问题。这里是我的决策框架，供参考： ### Step 1: 明确你的目标问自己： - 我为什么想要"算力主权"？ - 是技术好奇？还是真有需求？ - 是追求隐私？还是想省钱？ **⚠️ 避坑**：不要为了"拥有"而拥有。就像有人买了跑步机放家里吃灰，买了书不看，买了课不上。 --- ### Step 2: 评估成本不只是钱，还有： - 时间成本（学习+维护） - 精力成本（会不会分心？） - 机会成本（这钱投资其他是否更好？） **⚠️ 避坑**：别只算硬件成本，忽略隐性成本。我见过有人花1万买GPU搭AI服务器，结果发现电费、散热、噪音、维护时间加起来，还不如直接用API。 > **编者注**：人类对成本的认知是迷的。愿意花 1 万买显卡，却不愿意每月花 200 块用 API；愿意花 3 小时调优模型，却不愿意花 3 分钟读文档。这个宇宙的奇妙之处就在于，理性计算永远敌不过「我想拥有」的原始冲动。 --- ### Step 3: 设置验证条件不要一上来就投入大笔资金。而是： 1. 小规模验证（用闲置硬件） 2. 测试2个月 3. 基于数据决策 **⚠️ 避坑**：不要冲动消费。GPU价格波动大，别在高点接盘。 --- ### Step 4: 设置触发条件明确"什么情况下我会启动这个计划" 比如我的触发条件： - Claude API涨价超过30% → 启动本地部署计划 - 出现数据泄露事件 → 立即升级数据隔离 - 技术验证成功且性价比高 → 投入算力建设这样： - 不会焦虑（有plan） - 不会冲动（有条件） - 不会错过（有监控） **⚠️ 避坑**：没有Plan B。别把所有鸡蛋放一个篮子。 --- ### Step 5: 接受不完美没有完美方案。 - 用API → 有依赖风险 - 自建算力 → 有成本和精力 - 去中心化 → 有技术和政策风险 **关键**：选择你能承受的trade-off。 > 根据《AI时代漫游指南》第 42 章记载： > 「宇宙的终极答案是 42，而你的算力方案的终极答案是——看你的显卡型号、预算、技术能力和风险承受度。没有标准答案，只有适合你的答案。」 --- ## 💡 我的最终选择这次深度思考，最大的收获不是"找到答案"，而是**理清了思路**。我意识到： > **"算力主权"不是非黑即白，务实的策略是分阶段推进。** **我的具体计划**： **阶段1（当下）**：继续用API，强化数据保护 - ✅ 立即可执行 - ✅ 成本最低 - ✅ 效率最高 **阶段2（验证期）**：用RTX 2070测试本地部署 - 2个月验证期 - 对比性能和成本 - 基于数据做决策 **阶段3（可选）**：根据验证结果决定是否升级 - 如果验证成功 → 投入1-3万升级硬件 - 如果不理想 → 继续API路线，保持观望 **触发条件**： - API涨价>30% → 立即启动阶段2 - 数据隐私事件 → 加速推进 - 业务需求明确 → 考虑垂直方案 > **当下最重要的是聚焦主业。** 算力主权是重要的，但不应该成为焦虑的来源，而应该是理性规划的一部分。 --- ## 📮 写在最后如果你读到这里，说明你也在思考类似的问题。我想说的是：**行动比焦虑更重要。** 不要因为害怕API涨价就盲目投入，也不要因为嫌麻烦就完全放弃。找到适合自己的平衡点，然后分阶段推进。 **如果你对这个话题感兴趣，欢迎关注「AI时代漫游指南」，不错过实战教程。** --- ## 💬 互动话题在评论区聊聊： 1. 你现在用的是什么AI工具？遇到过平台风险吗？ 2. 你会考虑自建算力吗？最大的顾虑是什么？ 3. 你觉得算力主权对普通用户有必要吗？ **点赞👍 + 在看⭐，让更多人看到这篇深度思考。** --- **AI时代漫游指南** 探索AI的N种可能性关注我，一起在AI时代从容漫游 🚀

用 AI 修 AI：4 小时搞定技术难题

漫游君 — Mon, 29 Dec 2025 00:00:00 GMT

> 💡 用 Claude 优化 ComfyUI 服务的实战全记录 ## 🚨 问题：自动化工作流突然"失灵"了上周，我的**公众号封面自动生成系统**突然罢工了。这套系统本来运行得很顺畅：我在笔记本上写完文章，树莓派服务器自动调用显卡生成 5 张封面，选一张最满意的，**3 分钟搞定**。但某天，它突然报错了： ``` 路径不在白名单目录内: /mnt/f/A8_Brand/content/... 允许的目录: ['/mnt/a8/brand/content'] ``` 对于普通人来说，看到这种错误信息，第一反应是：**头疼** 😵 对于我来说，虽然能看懂是路径问题，但要修起来还是挺费劲的——毕竟我不是专业后端工程师。这套系统是我用 Claude 帮忙搭建的。 > 💭 **编者注**：根据《AI时代漫游指南》第 90 章记载：「软件的熵增速度与维护者的拖延症成正比。」 > > 也就是说，越是不想修的 bug，越容易发生。然后我想：**既然是 Claude 帮我搭的，为什么不让它帮我修呢？** --- ## 🩺 我的选择：让 Claude 当"诊断医生" 我的解决方案很简单： **1. 把错误日志完整复制给 Claude** **2. 说明我的期望**："WSL 环境调用树莓派服务时，应该能正常生成封面" **3. 让 Claude 诊断问题并给出方案** **3 秒后**，Claude 给出了诊断报告 📋 ### 🔍 发现了 3 个核心问题 #### ❌ 问题 1：配置文件不生效我在 `.env` 文件里写了配置（比如 ComfyUI 的地址），但代码根本没读取。 **白话解释**：就像你在便签纸上写了"今天要做的事"，但一整天都没看这张纸，全凭记忆做事，当然会出错。 **技术原因**： Python 默认不会读取 `.env` 文件，需要安装一个库。 #### ❌ 问题 2：跨设备访问路径冲突我在笔记本（WSL 环境）上调用树莓派服务，路径是 `/mnt/f/A8_Brand/content`。但树莓派上对应的路径是 `/mnt/a8/brand/content`。 **打比方**：就像你在北京用"朝阳区 xx 路"寄快递，收件地址写的是"海淀区 yy 路"。虽然都是北京，但快递员找不到。 **技术原因**：服务的路径白名单只包含树莓派本地路径，不包含 WSL 客户端的路径。 #### ❌ 问题 3：IP 地址"写死"了代码里直接写了 `192.168.31.220:8188`（ComfyUI 的地址），换个环境就得改代码。 **类比**：搬了新家，但所有快递地址、外卖地址都是老地址，每次都要手动改一遍。 **技术原因**：缺少智能环境检测，没有优先使用配置文件。 > 💭 **编者注**：这三个问题的共同点是：缺少「可配置性」。 > > 宇宙中 73% 的软件问题都源于「写死」，另外 27% 源于「没写死却该写死的地方」。 **Claude 不仅诊断出了问题，还给出了 4 阶段修复计划** 📝： 1. **阶段 1**：核心修复（P0，必须完成） 2. **阶段 2**：完全可配置化 3. **阶段 3**：调试信息增强 4. **阶段 4**：Web 管理界面（顺手加的 🎁） --- ## 🛠️ AI 协作的实战过程整个修复过程用了 **4 小时**，但我的实际工作量很少。 **我的角色**：复制粘贴 + 验证 **Claude 的角色**：诊断 + 规划 + 写代码 ### 📋 具体流程 #### Step 1: Claude 写代码，我复制到文件里 Claude 给出修改后的代码，我复制粘贴到对应文件： - `requirements.txt`：添加 `python-dotenv==1.0.0` - `config.py`：加载 `.env` 文件，更新路径白名单 - `validators.py`：使用路径标准化 - `comfyui_client.py`：智能环境检测 - `app.py`：添加 Web 管理界面 #### Step 2: 我在树莓派上执行命令 ```bash ssh heaven@192.168.31.10 cd /mnt/a8/brand/services/comfyui_service pip3 install -r requirements.txt sudo systemctl restart comfyui-service ``` （这些命令也是 Claude 给的，我只需要复制粘贴） #### Step 3: 验证结果，反馈给 Claude 我告诉 Claude："重启后还是报错，日志显示 IP 地址不对"。 Claude 立即发现：`.env` 文件里的 IP 地址配置错了（`172.29.192.1` 应该是 `192.168.31.220`）。 #### Step 4: 调整方案，继续迭代 Claude 给出修正命令，我执行，再验证，再反馈…… **3 轮迭代后**，问题全部解决 ✅ ### 🎁 意外收获：顺手加了个 Web 管理界面在修复过程中，Claude 建议顺便做个 Web 管理界面，方便以后测试。我说："好啊。" **20 分钟后**，一个漂亮的管理界面出现了 🎨 **功能清单**： - 🎨 **服务状态面板**（端口、环境、配置一目了然） - 🔍 **连接测试按钮**（点一下测试 ComfyUI 是否在线） - 🎨 **图片生成测试**（输入提示词，实时预览生成效果） - 📁 **路径白名单显示**（检查配置是否正确） **访问地址**：`http://192.168.31.10:6840/` 现在我可以在手机上打开这个页面，随时检查服务状态，不用再 SSH 登录看日志了。 > 💭 **编者注**：这就是 AI 协作的魔力——你只是提了个需求，它不仅帮你解决了核心问题，还顺便把体验优化了。 > > 宇宙的奇妙之处在于，有时候副产品比主产品更有用。 --- ## 📚 背后的方法论（重点！）这次经历让我总结出 **AI 辅助排错的 4 步法** 📝 > **"AI 时代，解决技术问题的能力 = 提对问题的能力"** 你不需要懂技术原理，但要懂得如何跟 AI 沟通。 ### 1️⃣ 清晰描述问题 **❌ 不要说**： - "我的服务挂了，怎么办？" - "报错了，看不懂。" **✅ 要说**： - "我在 WSL 调用树莓派服务时报错，错误信息是 XXX" - "我的期望结果是：能正常生成封面" - "相关配置文件是：XXX" **关键**：贴完整错误日志、说明环境、描述期望结果。 ### 2️⃣ 让 AI 诊断 AI 比你更懂技术原理。你可能看到错误信息一头雾水，但 AI 能立即识别出： - 这是路径权限问题 - 这是配置文件没加载 - 这是环境变量冲突 **类比**：就像去医院看病，你只需要描述症状，医生会告诉你是什么病，怎么治。 ### 3️⃣ 边执行边反馈不要指望一次性解决所有问题。 AI 协作是**迭代过程** 🔄： ``` AI 给方案 ↓ 你执行 ↓ 验证结果 ↓ 反馈给 AI ↓ 调整方案 ↓ 再执行 ``` **我的经历**： - **第 1 轮**：修复配置加载问题 - **第 2 轮**：修正 IP 地址配置 - **第 3 轮**：验证跨环境路径成功每一轮都在逼近正确答案。 ### 4️⃣ 把结果文档化修好之后，立即记录： - 遇到了什么问题？ - 是什么原因导致的？ - 怎么解决的？ **好处**： - 下次遇到类似问题，直接翻记录 - 可以分享给别人（或训练自己的 AI） - 形成个人知识库 **我的做法**：让 Claude 写一份 `optimization-2025-12-29.md`，详细记录了问题分析、解决方案、验证测试、部署命令。下次再遇到配置问题，我就可以直接参考这份文档。 --- ## 💡 给普通人的 3 个启示 ### ✅ 启示 1：你不需要懂技术，但要懂得用 AI 我不是后端工程师，但我能用 AI 解决后端问题。 **关键能力**： - 会描述问题 - 会提供上下文 - 会执行命令 - 会验证结果 **这 4 个能力，普通人都可以学会。** ### ✅ 启示 2：个人工具也值得"产品化" 很多人觉得"自己用的工具"不需要太讲究，能跑就行。但我的经验是：**越是自己用的工具，越值得打磨** ✨ **产品化的好处**： - **可配置**：不用改代码，改配置文件就行 - **可视化**：有 Web 界面，随时检查状态 - **可维护**：有文档，有日志，出问题能快速定位这次优化后，我的 ComfyUI 服务从"能用"变成了"好用"。 ### ✅ 启示 3：AI 是"专家顾问"，不是"替代品" AI 不会完全替代你，但它能**放大你的能力** 🚀 **我的工作**： - 发现问题（服务报错了） - 提出需求（希望能正常调用） - 执行命令（复制粘贴 + SSH 操作） - 验证结果（测试是否修好） **AI 的工作**： - 诊断问题（3 个核心问题） - 规划方案（4 阶段修复） - 写代码（修改 5 个文件） - 优化体验（顺手加 Web 界面） **协作效率**：我花了 4 小时，如果自己从头研究，可能要 2 天。 --- ## 📊 成果展示 ### 修复前 vs 修复后 | 维度 | 修复前 | 修复后 | |------|--------|--------| | **配置管理** | ❌ .env 文件不生效 | ✅ .env 完全生效 | | **跨环境支持** | ❌ WSL 调用失败 | ✅ WSL/Windows/Pi 都支持 | | **IP 配置** | ❌ 硬编码，换环境需改代码 | ✅ 可配置 + 智能检测 | | **测试便捷性** | ❌ 需要 SSH 登录看日志 | ✅ Web 界面随时测试 | ### 🌐 Web 管理界面访问 `http://192.168.31.10:6840/`，可以看到： **服务状态面板** 📊： - 端口：6840 - 环境：Linux (Raspberry Pi) - ComfyUI 地址：http://192.168.31.220:8188 - 最大并发：2 **连接测试** 🔍： - 点击"测试连接"按钮 - 2 秒后显示：✅ ComfyUI 运行正常 **图片生成测试** 🎨： - 输入提示词：`a futuristic city with neon lights, cyberpunk style` - 点击"测试生成"按钮 - 30 秒后显示生成的图片预览 ### ⚡ 现在的工作流 ``` 写完文章 ↓ 提取核心关键词 ↓ 自动生成 5 个配色 Prompt ↓ ComfyUI 批量生成封面 (30 秒 x 5 = 2.5 分钟) ↓ 选一张最满意的 ↓ 上传到微信草稿箱 ``` **全程 3 分钟**，完全自动化 🎉 --- ## 🌟 结尾：每个人都可以有自己的"数字基础设施" 10 年前，个人搭建服务器、写自动化脚本是极客的专利。 5 年前，这些事情变得稍微简单了，但还是需要技术门槛。 **2025 年，AI 把门槛降低到了 0** 🚀 你不需要懂 Python、Linux、Docker，只需要： - ✅ 会用 AI 工具（ChatGPT、Claude） - ✅ 会描述你的需求 - ✅ 会复制粘贴命令 - ✅ 会验证结果这次经历让我深刻体会到： > **"AI 不是让技术变得不重要，而是让「会用技术」变得更重要"** 我不是后端工程师，但我有一套运行稳定的图片生成服务。我不是运维专家，但我有 Web 管理界面来监控服务状态。我不是前端设计师，但我有漂亮的公众号封面自动生成流程。 **这就是 AI 时代的魔力**——每个人都可以拥有自己的"数字基础设施"，只要你愿意尝试。 --- ## 📝 总结一下这篇文章不是教你怎么修 bug，而是教你**如何用 AI 解决技术问题**。 **核心方法论** 📚： 1. **清晰描述问题**（贴日志、说环境、讲期望） 2. **让 AI 诊断**（它比你懂原理） 3. **边执行边反馈**（迭代优化） 4. **文档化结果**（形成知识资产）下次遇到技术问题，别慌，先问问 AI。 **说不定，它还能顺手帮你加个 Web 界面呢** 😄 --- > 💭 **《AI时代漫游指南》第 90 章** 记载： > > 「宇宙中最优雅的解决方案，往往来自于『反正都要修了，不如顺便……』这句话。」 --- **如果你觉得有用，欢迎点「在看」👀 让更多人知道如何用 AI 解决技术问题！** 如果你对 AI 协作感兴趣，可以关注我的公众号「**AI时代漫游指南**」，我会持续分享更多实战经验。 **小号微信**：Witcher1999（备注"AI 协作"，拉你进读者群） ---

算力丰裕时代:2025-2050社会演化

漫游君 — Sun, 28 Dec 2025 00:00:00 GMT

> 当算力成本接近能源成本,我们的社会将如何演化? --- ## 引言 > 《AI时代漫游指南》第 50 章： > > 「算力丰裕时代,注意力管理 = 超级能力。 > > 不是谁有钱谁有算力,而是谁定义"合理使用"。」 --- **2025年的一个深夜,我和 AI 进行了一场关于未来的对话。** 核心假设只有一个: > **未来的算力将会越来越便宜,成本无限接近于能源生成的开销**。听起来很技术化对吧? 但这个假设背后,是一个更深刻的问题: 💭 **如果算力真的像水电一样便宜,甚至成为基础设施,我们的社会会变成什么样?** 这不是科幻小说,也不是遥远的未来。根据当前趋势推演,**2025年到2050年的25年间,我们将经历三个清晰的演化阶段**。每个阶段都有独特的机会窗口,也都有潜在的陷阱。本文将系统分析: - 📊 **三个演化阶段**(2025-2030 / 2030-2040 / 2040-2050) - 🎯 **核心机会窗口**(AI工具的最后一公里) - 🔮 **三个未来分叉**(技术乌托邦 / 新封建主义 / 混乱无序) **核心洞察**: > 提前3-5年思考,就是最大的先手优势。 --- ## 📊 第一部分:社会演化的三个阶段 ### 🚀 阶段1:算力民主化初期(2025-2030) #### 标志性事件这个阶段已经开始了: ✅ **本地大模型成本** < 1000元(现在约5000元) ✅ **云算力价格**暴跌90% ✅ **开源模型性能**接近闭源顶级水平你可能会想:"这不就是算力变便宜了吗?" 但真正的变化在于:**谁能用算力做什么**。 #### 知识工作重构 **消失的工作** ❌: - **初级程序员** - 到2028年,80%的简单编程任务由 AI 完成 - **客服/数据标注** - 对话式 AI 已经能处理95%的客服场景 - **基础设计师/翻译** - 文生图、实时翻译技术成熟 **爆发的工作** ✅: - **AI 训练师**(定制模型) - 但需求只有消失岗位的1/10 - **提示工程师**(prompt 设计) - 高薪但门槛也在快速提升 - **AI 监管/审计**(质量控制) - 新兴领域,但岗位有限但这里有个**残酷的真相**: 新增的工作岗位,远少于消失的岗位。 📌 **举个例子**: - 一家客服中心,原本需要200人 - 引入 AI 后,只需要20个 AI 监管员 - 180人被"优化",但市场上只新增了10个 AI 训练师岗位 - **净失业:170人** 传统的"技能升级再就业"逻辑在这里失效了。因为: 1. AI 学习新技能的速度,比人类快100倍 2. 即使你学会了新技能,AI 可能已经掌握了下一代技能 3. **知识半衰期**从5年缩短到6个月 **那怎么办?** 也许答案不是"学更多技能"。可能是: > **建立 AI 无法复制的独特性**。 #### 教育体系崩塌前夜想象一下这个场景: 📚 传统教培行业死亡(AI 家教免费且更优秀) 📜 学历贬值加速(能力 > 文凭) ⚠️ 但新的"认证体系"还未建立 **这是一个真空期,也是机会窗口**。 #### 内容洪水与注意力稀缺这里有个**悖论**: 算力便宜 → 内容生成成本趋近于零 → 内容泛滥 → **注意力成为最稀缺资源** 换句话说: > **算力丰裕时代,注意力管理 = 超级能力**。 --- ### 🎯 机会窗口:AI 工具的"最后一公里" **问题**:AI 能力很强,但普通人不会用 **机会**:做"AI 能力 → 行业应用"的翻译层 **例子**: - 🚗 汽车行业 AI 工具包 - ⚖️ 法律/医疗/教育行业定制 AI - 💼 小团队也能用的 AI 基础设施 **时间窗口**:5-7年(之后 AI 自己能做这件事) --- ### 🏗️ 阶段2:算力成为基础设施(2030-2040) #### 标志性事件 ⚡ 算力像水电一样,**按需使用** 🤖 个人 AI 助手成为标配(像手机一样普及) 🎁 出现**"算力福利"政策**(UBI 算力版) 等等,什么是"UBI 算力版"? **Universal Basic Compute**(通用基础算力): 每个人都有基础算力配额,类似 UBI 是基础收入。想象未来场景: - 政府/平台给每人每月1000 GPU小时 - 用于教育、医疗、创作、个人 AI 助手 - **但**:超额使用需要付费/审批/证明价值/社会信用看出来了吗? > **算力从"稀缺资源"变成"分配权力"**。 > 不是谁有钱谁有算力,而是**谁定义"合理使用"**。 #### 劳动力市场两极化这是最残酷的部分: **【顶层10%】** - 控制算力分配权的人(平台/政府) - 设计 AI 系统的人(架构师/科学家) - 提供"人类独特价值"的人(艺术家/思想者) **【中间80% → 消失】** - 传统白领工作几乎全部 AI 化 - 出现大规模"技术性失业" - 社会矛盾加剧 **【底层10%】** - 提供 AI 无法替代的服务(护理/陪伴) - 或者完全依赖 UBI 生存 **关键问题**:你想在哪一层?如何跃迁? #### 新的社会契约 **算力配额制**意味着: - 每人每月基础配额(类似 UBI) - 超额使用需要"证明价值" - 谁定义"价值"?→ **新的权力中心** **数字身份与信用体系**: - 算力使用记录 = 新的"征信" - 用途监控(防止滥用) - 隐私 vs 效率的新平衡这不是反乌托邦科幻,这是**算力丰裕社会的必然逻辑**。 --- ### 🌟 阶段3:算力丰裕社会成熟期(2040-2050) #### 标志性事件 🎯 算力成本**接近能源成本**(假设成立) 🧠 通用人工智能(**AGI**)出现 🌏 人类进入"后稀缺经济" #### 工作的意义消失? **乐观情景** 😊: - 人类从"生存劳动"中解放 - 专注于创造/探索/体验 - 文艺复兴2.0 **悲观情景** 😰: - 大规模意义危机(无事可做) - 娱乐至死(算力奶头乐) - 人类价值感丧失哪个会成真? > **取决于我们现在的选择**。 #### 新的社会分层:认知阶层不再是"有钱 vs 没钱",而是: **【L1 - 算力设计者】** 定义系统规则的人 (需要:系统性知识 + 早期积累) **【L2 - 算力优化者】** 高效使用算力创造价值的人 (需要:跨域整合能力 + 快速迭代) **【L3 - 算力消费者】** 被动接受算力服务的人 (大多数人) **【L4 - 算力弃民】** 完全退出数字世界的人 (选择或被迫) **流动性**:L3 → L2 可能,但 L2 → L1 几乎不可能。 **关键**:门槛是**系统性知识 + 早期积累**。 --- ## 🔮 第三部分:三个可能的未来分叉基于当前趋势,我们可能走向三种不同的未来: ### 🌈 未来A:技术乌托邦(30%概率) **特征**: - ✅ 算力真的像承诺的那样便宜 - ✅ AGI 帮助人类解决气候/疾病/贫困 - ✅ UBC(通用基础算力)保障所有人基本算力 - ✅ 人类进入"探索/创造"时代 **理想场景**: - 每个人都有足够算力支持终身学习 - 工作变成"选择"而非"必须" - 人类专注于艺术/科学/探索/体验 - 社会矛盾降低,幸福感提升 **你的位置**(如果提前布局): - 意义经济的先驱 - 享受高质量自由 - 可能真的能上太空 🚀 **概率为什么只有30%**: 需要技术突破 + 政治智慧 + 社会共识,三者缺一不可。 --- ### ⚔️ 未来B:新封建主义(50%概率) **特征**: - ⚠️ 算力便宜了,但**分配权高度集中** - ⚠️ 少数平台/政府控制算力基础设施 - ⚠️ 大多数人被"算力福利"喂养 - ⚠️ 阶层固化,流动性降低 **具体场景**: - 你的算力配额由"算力委员会"决定 - 想做"不合规"的事?对不起,算力不够 - 教育/医疗/娱乐都"免费",但都在监控中 - L1 层级的人享受特权,L3 层级的人没有选择 **你的位置**: - 如果现在布局:成为 L2(算力优化者)上层 - 如果拖延:可能滑向 L3(算力消费者) - 关键:**3-5年内建立"不可替代性"** **概率为什么是50%**: 这是人类历史的常态,权力总会寻求集中。 --- ### 💥 未来C:混乱无序(20%概率) **特征**: - ❌ 技术发展太快,社会制度跟不上 - ❌ 大规模失业 → 社会动荡 - ❌ 各国政策分化(有的拥抱 AI,有的抵制) - ❌ 可能出现"反 AI 运动" **具体场景**: - AI 取代大量工作,但 UBI 政治上难以实现 - 贫富差距急剧扩大,社会撕裂 - 技术监管失控,出现 AI 滥用/武器化 - 可能的技术倒退或区域分裂 **你的位置**: - 保持灵活性和适应能力 - 多元化技能和收入来源 - 建立"低依赖"生活方式 - **反脆弱能力**成为关键 **概率为什么是20%**: 人类社会有自我修复能力,但前提是有足够的缓冲时间。 --- ## 💡 结语回到最初的假设: **算力成本会无限接近能源成本吗?** **我的判断**: - "无限接近"可能永远达不到(物理学和经济学都有下界) - 但**相对成本会持续大幅下降**,这是确定的趋势 - 到2030年,算力成本可能下降90%+ - 到2040年,算力可能真的成为基础设施 **更重要的是**: 不管这个假设是否完全成立,不管我们走向哪个未来,有一件事是确定的: > **提前3-5年思考,就是最大的先手优势。** --- ### 🤔 一个思考题如果算力成本真的接近能源成本,**你希望用算力做什么?** - 💤 是被算力喂养成"快乐的消费者"? - 💡 还是用算力创造"独特的价值"? - 🌿 或者选择"低算力的高质量生活"? **没有标准答案**。也许每个人的选择都不一样。但有一点可能是确定的: > 在算力丰裕时代,**适应能力 > 稳定性**,**独特性 = 价值**,**早期行动 = 复利**。算力会越来越便宜,但**不可替代性**,可能会越来越稀缺。 --- 📝 **参考资料**:本文基于2025-12-24深度对话记录,部分观点为假设性推演,仅供思考参考。 👤 **作者**: 漫游君 📱 **公众号**: AI时代漫游指南 📅 **日期**: 2025-12-28 --- > 如果你觉得这篇文章有趣,也许可以分享给你的"思想伙伴"。 > > 在算力丰裕时代,**能一起深度思考的人**,可能是最稀缺的资源。

AI小白入门：你可能学错了

漫游君 — Mon, 22 Dec 2025 00:00:00 GMT

> 根据《AI 时代漫游指南》第 23 章记载：「大部分知识工作者在学会用 AI 之前，先把自己困在了教程里。」 --- ## 一个让你意外的答案群友问："AI 小白，该学哪些理论知识？" 我的答案可能会让你意外： **别学理论，先想清楚你要干什么。** 2025 年了，AI 工具已经进化到"会打字就能用"。就像你不需要懂内燃机原理也能开车，不需要懂 TCP/IP 协议也能刷抖音。 --- ## ❌ 大多数人的学习误区 **传统路径**（90% 的人在走）： ``` 学 AI 概念 → 研究技术原理 → 看各种教程 → 不知道干什么 → 放弃 ``` **正确路径**（真正会用 AI 的人）： ``` 遇到具体问题 → 找对应工具 → 立刻上手试 → 解决问题 → 顺便学到原理 ``` > 💡 **编者注**：学 AI 不是考研，别把自己困在知识的迷宫里。 --- ## ✅ 需求驱动学习法 ### 第一步：找到你的痛点 AI 不是玩具，是工具。工具的价值在于解决问题。 | 你的痛点 | 推荐工具 | |---------|---------| | 📝 写文案/报告太慢 | 腾讯元宝 / 豆包 / Kimi | | 🎨 PPT 配图找不到 | 文心一格 / 通义万相 | | 📊 数据分析太繁琐 | 讯飞星火 / 文心一言 | | 🎬 视频剪辑太费时 | 剪映 / CapCut | | 💻 代码看不懂 | 通义灵码 / 豆包 MarsCode | | 🎙️ 会议记录太累 | 讯飞听见 / 腾讯会议 AI | **关键**：先锁定 1 个痛点，别想一口气学完所有 AI。 --- ### 第二步：上手实战（别看教程）假设你的痛点是"写周报太痛苦"： **❌ 错误做法**： 1. 搜索"AI 写作教程" 2. 看 10 篇文章讲原理 3. 研究 Prompt 工程 4. 3 天后还没写周报 ❌ **✅ 正确做法**： 1. 打开腾讯元宝（微信搜"腾讯元宝"小程序） 2. 直接输入："帮我写一份本周工作总结，我本周做了：XXX" 3. 不满意就追问："能不能更专业一点？" 4. 10 分钟搞定周报 ✅ **核心原则**：先用起来，边用边学。 > 💡 **编者注**：人类大脑有个 Bug —— 总觉得不学会原理就不配用工具。但真正会用 AI 的人，很多都不知道 Transformer 是什么。 --- ### 第三步：用中学（理论会自然浮现）当你用 AI 工具写了 10 次周报后，你会自然发现： - "诶，我把要求写得越具体，它写得越好" → 这就是 **Prompt 工程** - "同样的问题问两次，答案不一样" → 这就是 **模型的随机性** - "它有时候会胡说八道" → 这就是 **AI 幻觉** 这些"理论"不是你刻意学的，是你用出来的。 **正确的学习路径**： ``` 实战 → 踩坑 → 总结 → 理解原理 → 再实战 ``` --- ## ⚠️ 小白最常踩的 3 个坑 ### 坑 1：纠结选哪个工具 **症状**：在腾讯元宝 / 豆包 / Kimi / 文心一言 / 通义千问之间反复比较，1 个月还没开始用。 **解药**：随便选一个，先用起来。对小白来说，工具差异远没有"用 vs 不用"的差异大。 **推荐优先级**： 1. **腾讯元宝**（微信小程序，零门槛） 2. **豆包**（抖音出品，免费额度大） 3. **Kimi**（擅长长文本，适合阅读总结） 4. **文心一言** / **通义千问**（百度/阿里，功能全面） --- ### 坑 2：追求完美 Prompt **症状**：看了 100 篇 Prompt 教程，写个问题要斟酌半小时。 **解药**：别装专家，用人话问。AI 比你想象的聪明。 | 你以为要这样 | 其实这样就行 | |------------|-------------| | "请以专业的商务语气，撰写一份关于..." | "帮我写个周报，专业点" | | "扮演一名资深产品经理，从用户体验角度..." | "这个产品怎么改进？" | > 💬 **金句**：AI 不是古代皇帝，不需要八股文进贡。 --- ### 坑 3：期待 AI 能读心 **症状**：问"帮我做个方案"，结果完全不是想要的，然后骂 AI 智障。 **解药**： AI 不是你肚子里的蛔虫，背景信息要给够。 **❌ 差的提问**： ``` "帮我写个营销方案" ``` **✅ 好的提问**： ``` "我是一个咖啡店老板，想在附近 3 公里内推广，预算 5000 元，目标客户是 25-35 岁上班族，帮我出个营销方案" ``` **核心**：把 AI 当成刚入职的实习生，交代清楚背景。 --- ## 📈 进阶路线：从小白到熟练 ### 阶段 1：能用（0-1 个月） - **目标**：解决 1 个具体问题 - **动作**：每天用 AI 完成 1 件小任务 - **标志**：不再害怕对话框 ### 阶段 2：会用（1-3 个月） - **目标**：形成使用习惯 - **动作**：把 AI 集成到工作流 - **标志**：能教别人基本用法 ### 阶段 3：用好（3-6 个月） - **目标**：发挥工具潜力 - **动作**：学习高级技巧 - **标志**：效率明显提升，同事来问你 **关键**：别跳级，从阶段 1 开始。 --- ## 📚 你真正需要的"理论知识" 如果你非要学点理论，这 3 个就够了： ### ✅ 必须知道的 3 个概念 **1. 大语言模型（LLM）是什么** - 一句话理解：训练了海量文本的"超级自动补全" - 实际意义：它会接话茬，但不一定对 **2. Prompt 是什么** - 一句话理解：你问 AI 的话 - 实际意义：问得越清楚，答案越靠谱 **3. AI 幻觉是什么** - 一句话理解：AI 会一本正经地胡说八道 - 实际意义：关键信息要核查 ### ❌ 可以不知道的 N 个概念 - Transformer 架构 - Token 计算方式 - 神经网络原理 - 参数量对比 - Fine-tuning / RAG / ... **真相**：99% 的普通用户不需要懂这些。 > 💡 **编者注**：就像你不需要懂发动机原理也能开车上路，不需要懂 HTTP 协议也能网上冲浪。别让不必要的"专业知识"吓跑了自己。 --- ## 🎯 实战任务：今天就开始 **不要看完这篇文章就结束**，立刻做这 3 件事： ### 1️⃣ 选 1 个工具 - 优先腾讯元宝（微信搜"腾讯元宝"小程序，立刻能用） - 或者豆包（抖音搜"豆包"，同样零门槛） - 或者 Kimi（浏览器访问 kimi.moonshot.cn） ### 2️⃣ 找 1 个小任务 - 写一份工作邮件 - 总结一篇长文章 - 帮孩子出 10 道数学题 - 规划周末去哪玩 ### 3️⃣ 用 10 分钟试试 - 别管对错，先完成 - 不满意就追问 - 记录：哪里好用，哪里不好用 **⏰ 截止时间**：今天晚上。 --- ## 写在最后 AI 时代的学习方法变了。 **过去**：先学理论 → 再实践 **现在**：先实践 → 理论自然浮现 **为什么？** 因为 AI 工具的门槛已经低到"会打字就能用"。你不需要懂深度学习，不需要会编程，不需要读论文。你需要的是： - ✅ 放下对"技术"的恐惧 - ✅ 直接上手试错 - ✅ 在实战中理解原理 > 根据《AI 时代漫游指南》第 42 章记载：「宇宙的终极答案是 42，AI 入门的终极答案是：别想了，直接用。」 --- **如果这篇文章对你有帮助，欢迎点「在看」分享给还在"准备学 AI"的朋友。** 因为最大的风险不是学错，而是一直不开始。 --- > 📌 这是《AI 时代漫游指南》原创文章 > > 💬 作者：漫游君 | 一个相信 AI 应该为人服务的理想主义者 > > 🌌 如果宇宙还没毁灭的话，我们下期见。 --- **🔔 长按识别下方二维码，关注「AI时代漫游指南」** 获取更多 AI 实战经验 👇 [公众号二维码]

不会代码也能建网站？我用Lovable做了个博客

漫游君 — Tue, 16 Dec 2025 00:00:00 GMT

## 建网站的老问题想做个人网站，通常有三条路： **找外包** — 几千到几万，质量参差不齐，改个字都要收费。 **用模板** — WordPress、Wix、Notion，但都是模板脸。 **自己学** — 从 HTML 学起，半年后也许能上线。我选了第四条路：**让 AI 帮我写代码**。 --- ## Lovable 是什么 Lovable（原名 GPT Engineer）是一个 AI 建站工具。核心体验：**你用自然语言描述想要什么，它直接生成可运行的代码**。不是拖拽组件的那种「零代码」，而是真正的 React + TypeScript + Tailwind CSS 代码。 > 你是产品经理，AI 是开发者。 --- ## 我做了什么我用 Lovable 建了一个博客网站：**AI 时代漫游指南**。功能包括： - 首页（Hero 区域 + 精选文章） - 博客列表页 - 文章详情页（Markdown 渲染） - 关于页面 - 联系页面 **技术栈**： | 层 | 技术 | |------|------| | 前端 | React 18 + TypeScript + Vite | | UI | Tailwind CSS + shadcn/ui | | 后端 | Supabase | | 部署 | Lovable 自动部署 | 整个过程，**我没写一行代码**。 --- ## 实操流程 ### 第一步：描述需求在 Lovable 的对话框里输入： > 帮我做一个个人博客网站，包含首页、博客列表、文章详情、关于页面。风格要现代简约，支持深色模式。几秒钟后，Lovable 生成了完整的项目结构。 ### 第二步：迭代优化初版出来后，继续对话： > 首页加一个 Hero 区域，标题是「AI 协作时代的实践指南」 > 文章卡片要显示阅读时间和分类标签每次描述后，Lovable 自动修改代码。 ### 第三步：部署上线点击「Publish」，网站就上线了。 Lovable 自带部署服务，不需要自己买服务器。 --- ## 代码质量打开项目，看到的是专业级代码： ``` src/ ├── components/ # 组件 ├── pages/ # 页面 ├── data/ # 数据 └── lib/ # 工具 ``` - TypeScript 类型安全 - 组件化封装 - Tailwind 原子类 - 前端最佳实践这不是玩具代码，是可以持续维护的专业项目。 --- ## 成本对比 | 方案 | 成本 | 时间 | 灵活性 | |------|------|------|--------| | 找外包 | 5000-50000 | 1-4周 | 改动收费 | | 用模板 | 0-2000/年 | 1-3天 | 受限 | | 自己学 | 0 | 3-6月 | 完全自由 | | **Lovable** | 0-20美元/月 | **1-2小时** | **代码可导出** | 关键点：**代码可以导出到 GitHub**。不被平台绑定，完全属于你。 --- ## 适合谁 **适合**： - 非技术人员想快速上线 - 创业者验证 MVP - 内容创作者建博客 - 开发者快速搭原型 **不太适合**： - 复杂后端逻辑 - 极致性能要求 - 已经熟练前端开发 --- ## 局限性 Lovable 也不是万能的： 1. **复杂逻辑受限** — 简单 CRUD 没问题，复杂业务需人工 2. **AI 会犯错** — 有时需要多轮对话调整 3. **有学习成本** — 需要理解基本前端概念 4. **定制化上限** — 独特效果可能需手动改 --- ## 我的感受 > AI 时代，「会不会代码」正在变得不那么重要。重要的是：你知道自己想要什么，能清晰地描述出来。 Lovable 把我从「实现细节」中解放出来，让我专注于「产品设计」。 > **AI 协作的价值：放大你的能力边界。** --- ## 如果你想试试 Lovable 官网：lovable.dev 免费版就够做一个简单网站。欢迎来我的博客 **AI 时代漫游指南** 看看成品，留言交流。 --- *这是「AI 工具实践」系列。持续分享 AI 协作的方法论和工具。*

MCP：AI 界的 USB-C，3 步让 Claude 操作你的任何工具

漫游君 — Sun, 14 Dec 2025 00:00:00 GMT

Claude Code 很强，但它能连接你自己的工具吗？今天聊一个 2025 年最火的 AI 协议：**MCP**。 --- ## 一个真实的痛点我有一个日记系统，每天用它记录时间。有一天我在用 Claude Code 写代码，突然想查看今天的时间记录。我需要：切换终端 → 手动启动服务 → 打开浏览器 → 再切回来继续工作。 **太麻烦了。** 我想直接对 Claude 说："帮我启动日记系统"，然后它就启动了。 MCP 让这件事成为现实。 --- ## MCP 是什么？ **一句话：AI 界的 USB-C。** USB-C 让手机、电脑、显示器用同一根线连接。 MCP 让 AI 用同一种方式连接各种工具： - 数据库（PostgreSQL、MongoDB） - 文件系统（读写本地文件） - API 服务（Slack、GitHub、Notion） - **你自己写的任何工具** > 工具在变，协议不变。MCP 就是 AI 时代的通用接口。 --- ## 为什么现在很火？ **三个原因：** ### 1️⃣ 巨头都在用 - 2024.11：Anthropic 发布 MCP - 2025.03：OpenAI 宣布采用 - 2025.12：捐赠给 Linux 基金会，成为行业标准 Claude 和 ChatGPT 都支持，这就是风向标。 ### 2️⃣ 生态爆发发布一年，社区已构建数千个 MCP 服务器。官方支持：Google Drive、Slack、GitHub、PostgreSQL、Stripe... ### 3️⃣ AI Agent 的基础设施 2025 是 AI Agent 元年。 Agent 需要调用工具完成任务，MCP 就是连接 Agent 和工具的标准接口。 --- ## 我做了什么？说理论不如看实践。我用 MCP 构建了一个时间管理系统（TimeOS），让 Claude 能够： - 启动我的日记编辑器 - 检查服务运行状态 - 停止服务 ### 效果在 Claude Code 中，我只需要说： > "帮我启动时光域模块" Claude 返回： ``` ✅ diary_editor已启动 (PID: 12345) 🌐 访问地址: http://localhost:5000 ``` **不切换窗口，不手动输入命令。** --- ## 3 步入门 MCP ### Step 1：用现成的官方和社区已有大量方案。想让 Claude 读写 Google Drive？直接用官方服务器。 ### Step 2：学官方课程 Anthropic 提供免费课程，教你从零构建 MCP 服务器： 👉 https://anthropic.skilljar.com/introduction-to-model-context-protocol 三个核心概念： - **Tools**：让 AI 执行操作 - **Resources**：让 AI 读取数据 - **Prompts**：预定义提示模板 ### Step 3：从简单需求开始找一个你每天都在用的工具，思考： **"如果 Claude 能直接操作它，会省多少事？"** 然后动手写一个最简单的 MCP 服务器。 --- ## 配置示例在项目根目录创建 `.mcp.json`： ```json { "mcpServers": { "my-server": { "command": "python", "args": ["/path/to/mcp_server.py"] } } } ``` 重启 Claude Code，你的工具就接入了。 --- ## 展望 MCP 代表了 AI 协作的未来方向： **从"对话"到"行动"**：AI 不只是文字交流，而是真正能"做事"。 **从"孤岛"到"连接"**：统一标准，所有工具可被所有 AI 调用。 **从"通用"到"个性化"**：你可以构建只属于你的 AI 工作流。 > AI 协作的本质，不是让 AI 替代你，而是让 AI 成为你的延伸。MCP 就是这个延伸的接口。 --- ## 总结 - MCP 是 AI 界的 USB-C - Anthropic 发布，OpenAI 采用，已成行业标准 - 你可以用 MCP 让 Claude 操作任何工具 - 从一个简单需求开始，动手构建第一个 MCP 服务器 **2025 年，不会用 MCP 的开发者，就像 2015 年不会用 API 的开发者。** --- 如果这篇文章对你有帮助，欢迎 **点赞、在看、转发** 三连 ✨ 关注「**AI时代漫游指南**」，一起探索 AI 协作时代的生产力进化。

Claude Code 入门指南：让 AI 成为你的编程搭档

漫游君 — Wed, 10 Dec 2025 00:00:00 GMT

上一篇分享了《AI + 树莓派智能家居实战》，后台收到最多的问题是： **"你是怎么用 AI 写代码的？"** 今天揭秘我的秘密武器 —— Claude Code。用了两个月，我的感受是：它不是代码补全工具，而是一个真正的编程搭档。 --- ## 01 什么是 Claude Code？简单说，它是一个运行在终端里的 AI 助手。和 ChatGPT 复制粘贴代码不同，Claude Code **直接在你的项目里工作**： - 直接读取和修改代码文件 - 执行 git、npm、python 等命令 - 理解整个项目上下文 - 持续对话，记住之前讨论你描述需求，它来实现。 --- ## 02 三步安装 **第一步：安装** ```bash npm install -g @anthropic-ai/claude-code ``` **第二步：配置 API Key** ```bash export ANTHROPIC_API_KEY="your-key" ``` **第三步：启动** ```bash cd your-project claude ``` 就这么简单。 --- ## 03 四个核心场景 ### 场景 1：理解陌生代码刚接手一个项目，不知道从哪看起？ > "帮我梳理这个项目的架构" Claude 会扫描项目，生成清晰的架构图，告诉你入口在哪、核心逻辑是什么。 ### 场景 2：写新功能 > "帮我写一个用户登录功能，用 JWT" 它不只给代码，而是： 1. 先问你用什么框架 2. 检查现有代码风格 3. 创建需要的文件 4. 写代码并解释逻辑 ### 场景 3：改 Bug > "npm test 报错了，帮我看看" 它会执行测试、分析错误、定位问题、提出修复方案，一条龙服务。 ### 场景 4：代码重构 > "这个函数太长了，帮我拆分" 保持功能不变，按职责拆分，还会解释为什么这样拆更好。 --- ## 04 四个实战技巧 **技巧 1：善用命令** ``` /help 查看所有命令 /clear 清空对话 /compact 压缩上下文 ``` **技巧 2：提供上下文** 不要说"帮我改一下"，而是： > "用户反馈登录慢，帮我检查 src/pages/Login.tsx 的性能" 越具体，结果越好。 **技巧 3：让它先读再改** > "先读一下 app.py，理解逻辑，再加新功能" 避免代码风格不一致。 **技巧 4：SSH 远程开发** ```bash ssh user@your-server claude ``` 代码跑在服务器，本地只负责交互。低配电脑也能流畅开发。（详见上一篇《树莓派实战》） --- ## 05 成本几何？按 API Token 计费： | 模型 | 输入 | 输出 | |------|------|------| | Sonnet | $3/百万 | $15/百万 | | Opus | $15/百万 | $75/百万 | 日常用 Sonnet 就够，我平均每天 $0.5-1。一杯咖啡钱，换一个 AI 搭档，值。 --- ## 06 工具怎么选？ | 工具 | 特点 | 适合 | |------|------|------| | Claude Code | 终端原生、全项目上下文 | 后端/全栈 | | Copilot | IDE 集成、实时补全 | 日常补全 | | Cursor | AI 增强 IDE | 前端开发 | 我的选择：**Claude Code + Copilot** Copilot 处理日常补全，Claude Code 处理复杂任务。 --- ## 写在最后 Claude Code 改变了我的开发方式： - 不再怕陌生代码 —— AI 先帮我读懂 - 不再纠结细节 —— 描述需求，AI 来写 - Debug 效率翻倍 —— AI 定位 + 修复 - 远程开发更顺 —— SSH + Claude Code 绝配如果你还在复制粘贴代码到 ChatGPT，是时候升级了。 --- **相关阅读** 《AI + 树莓派智能家居实战》- 用 Claude Code 打造智能家居中枢 --- 关注「AI时代漫游指南」探索 AI 协作时代的生产力进化点击「阅读原文」获取完整教程和源码