[{"content":"大多数开发者都在错误地使用 AI。他们把它当作一个升级版的 Google 搜索，或者一个需要手把手带的实习生。他们粘贴一段代码，等待修复，复制回来，发现不对，然后重复这个循环，直到想把笔记本电脑从窗户扔出去。\n这不是工程——这只是一种更快写烂代码的方式。\n大语言模型（LLM）真正的力量不在于它的训练数据——而在于它的上下文。一个孤立的模型就是一个瓶中之脑。但通过**模型上下文协议（MCP）**给它合适的工具，你就突然拥有了一个与你结对编程的资深工程师。\n以下是四个将我的 AI 从聒噪助手转变为自主架构师的核心 MCP 工具。\n1. Context7：文档专家（\u0026ldquo;大脑\u0026rdquo;） 痛点： 模型会产生幻觉。尤其是面对 Next.js、LangChain 或 Spring Boot 这类快速迭代的框架时。如果你问 AI 一个两周前发布的功能，它会基于两年前的数据自信满满地胡说八道。\n解决方案： Context7 允许 Agent 直接从源头获取最新的官方文档。\n为什么重要 这就像一个背了 2021 年教材的学生和一个在副屏上打开官方文档的资深工程师之间的区别。\n专业建议： 不要只问\u0026quot;我怎么用 X？\u0026quot;。让你的 Agent \u0026ldquo;先解析 X 的库 ID，再查询文档获取最新的实现细节\u0026rdquo;。\n正确示范： \u0026ldquo;Context7，获取 Next.js 从 13 迁移到 14 的指南，特别是关于 Server Actions 的部分。\u0026rdquo; 错误示范： \u0026ldquo;Server Actions 怎么用？\u0026quot;（这会导致泛泛的、通常是过时的建议）。 2. GitHub Search (gh-grep)：\u0026ldquo;江湖经验\u0026rdquo; 痛点： 文档告诉你代码在理想世界中应该如何工作。它不会告诉你那些边界情况、诡异的 bug，或者社区实际采用的惯用模式。\n解决方案： gh-grep 让 Agent 可以搜索数百万个公开仓库，看看代码在生产环境中的真实用法。\n为什么重要 理论很好，但生产代码才是现实。当我被一个晦涩的错误卡住，或者需要看\u0026quot;最佳实践\u0026quot;的实际实现时，我不想要教程——我想看看库的维护者自己是怎么写测试的。\n工作流： 读文档（Context7）。 搜索使用模式（GitHub Search）。 综合出一个既理论正确又经过实战检验的方案。 3. Sequential Thinking：前额叶皮层 痛点： LLM 倾向于\u0026quot;系统一\u0026quot;思维——快速、直觉性的，但往往是错的。它们在充分理解问题复杂性之前就急于生成代码。\n解决方案： Sequential Thinking 迫使模型慢下来。它要求 Agent 将问题拆解为步骤，形成假设，批判自己的方案，在写出任何一行代码之前进行修正。\n为什么重要 这就是初级开发者和资深架构师之间的区别。初级开发者看到一个 bug 就立刻开始改代码。资深架构师会退一步，画个图，考虑副作用，然后才动手修复。\n\u0026ldquo;思考\u0026quot;循环：\n规划： 拆解需求。 批判： \u0026ldquo;等等，如果我改了这个接口，会破坏用户服务。\u0026rdquo; 修正： \u0026ldquo;我需要先创建一个适配器。\u0026rdquo; 执行： 写代码。 4. Update User Preference：长期记忆 痛点： 每次开始新对话，AI 都会忘记你是谁。它忘了你偏好 TypeScript 而非 JavaScript，忘了你讨厌 any 类型，忘了你正在做某个特定的微服务。你每次会话开头都要花 5 分钟重新解释上下文。\n解决方案： update_user_preference 允许 Agent 将关于你、你的技术栈和当前工作重点的关键信息持久化到长期记忆文件（USER.md）中。\n为什么重要 这将无状态的交互变成了持续的关系。AI 与你一起\u0026quot;成长\u0026rdquo;。它学习你的习惯和偏好，无需你重复说明就能调整输出。\n工作机制： 捕获： 当你提到一个新偏好（例如，\u0026ldquo;这个项目我要用 Tailwind\u0026rdquo;），Agent 自动调用 update_user_preference。 检索： 在新会话开始时，Agent 读取你的画像来加载上下文。 结果： \u0026ldquo;我看到你还在做订单服务。要继续我们昨天讨论的重构吗？\u0026rdquo; 结语：AI 的 \u0026ldquo;Linux 时刻\u0026rdquo; 我们正在走过 AI 的新鲜感阶段。它不再只是和一个机器人\u0026quot;聊天\u0026rdquo;——而是将智能集成到我们的工作流中。\n这四个 MCP 工具——Context7、GitHub Search、Sequential Thinking 和 User Preference——将 LLM 从被动的文本生成器变成了主动的工程伙伴。它们给大脑（模型）装上了眼睛、耳朵、皮层和记忆。\n你的行动清单： 如果你正在构建或使用 AI Agent，别再满足于默认的\u0026quot;聊天\u0026quot;体验了。要求能连接现实的工具。你的生产力取决于此。\n","permalink":"https://www.creaturelove7.com/zh/ai/recommended_mcp/","summary":"探讨了将 LLM 当作简单聊天机器人使用的局限性，介绍了模型上下文协议（MCP），详解四个核心工具如何为 AI 提供上下文、规划和记忆能力，将其转变为强大的自主工程伙伴。","title":"别再把 AI 当聊天机器人了：四个让我的 Agent 拥有大脑的 MCP 工具"},{"content":"当我们从被动式聊天机器人转向主动式 AI Agent 时，对话的焦点已经从 AI 知道什么 转移到了 AI 能做什么。为了与外部世界交互，LLM 需要获取数据和执行操作的机制。\n然而，如果你最近在 Agent AI 领域待过一段时间，你一定被各种重叠的术语搞得晕头转向：Tool、Skill，以及迅速崛起的 MCP（模型上下文协议）。\n它们是一回事吗？是竞争关系吗？你应该构建哪一个？\n在这篇文章中，我们将拆解这三个概念，分析它们的差异、优劣和理想使用场景，帮助你设计更好的 AI 系统。\n1. Tool：原语（\u0026ldquo;是什么\u0026rdquo;） 在 AI 的语境下，Tool 是 Agent 能力最基础的构建块。本质上它是一个无状态的单一函数或 API 端点，LLM 可以调用它。当你使用 OpenAI 的 Function Calling 或 Anthropic 的 Tool Use 时，你就在这个层面工作。\n一个 Tool 只做一件特定的事。它从 LLM 接收定义好的输入，执行代码（通常是 Python、JavaScript 或外部 API 调用），然后将结构化输出返回给 LLM。\n示例： get_current_weather(location=\u0026quot;New York\u0026quot;)、execute_sql_query(query=\u0026quot;SELECT * FROM users\u0026quot;)、search_web(query=\u0026quot;latest AI news\u0026quot;)。 优点 简单且确定性强： 它们就是标准代码函数。容易编写，容易做单元测试，行为高度可预测。\n细粒度： 它们赋予 LLM 极致的灵活性。模型自行决定如何组合不同的 Tool 来实现新目标。\n低开销： 在 Agent 循环中添加一个简单 Tool 只需极少的样板代码。\n缺点 给 LLM 的认知负担： 如果你给 LLM 50 个细粒度的 Tool，它需要花费大量\u0026quot;推理 token\u0026quot;来选择使用哪一个，导致更高延迟和潜在幻觉。\n缺乏工作流逻辑： Tool 不知道它们该如何被组合使用。如果一个任务需要特定的 5 步序列，LLM 每次都要从头推导。\n理想使用场景 简单自动化： 需要偶尔查数据库或获取实时信息的聊天机器人。\n基础构建块： 作为更复杂抽象（如 Skill）的底层基石。\n2. Skill：工作流（\u0026ldquo;怎么做\u0026rdquo;） 如果 Tool 是函数，Skill 就是应用。\nSkill 是一种更高级别的抽象，它将多个 Tool、特定的系统提示词和硬编码的工作流逻辑捆绑在一起，以实现更广泛的、领域特定的目标。AutoGPT、Semantic Kernel 和最近爆火的 OpenClaw 等框架都大量使用了 \u0026ldquo;Skill\u0026rdquo;（或插件）的概念。\n与其告诉 AI\u0026quot;这是一个发邮件的 Tool 和一个读数据库的 Tool，自己想办法做营销\u0026quot;，不如直接给它一个 Cold_Outreach_Skill。\n示例： Manage_Calendar_Conflicts（捆绑了读日历、起草邮件和提议新时间的功能）、Review_GitHub_PR（克隆仓库、运行 linter 并发布评论）。 优点 减少 AI 幻觉： 通过将\u0026quot;工作流\u0026quot;硬编码到 Skill 中，LLM 在复杂流程中有了引导。它不需要猜下一步；Skill 来编排。\n可复用和可分享： Skill 可以被打包并在社区市场中共享。非开发者也能在自己的 Agent 中安装一个 \u0026ldquo;Skill\u0026rdquo; 而无需写代码。\n领域专业知识： Skill 可以包含特定领域的逻辑，如果纯粹通过提示词传递会占用太多上下文窗口。\n缺点 生态碎片化： 为 OpenClaw 编写的 \u0026ldquo;Skill\u0026rdquo; 无法在 AutoGPT 或 Semantic Kernel 中运行。目前没有通用标准来定义什么是 Skill。\n刚性： 由于工作流在某种程度上是硬编码的，当用户需求稍微偏离设计的主路径时，Skill 可能会崩溃。\n黑盒： 调试复杂的 Skill 可能很困难，因为故障可能出在 LLM 的推理、内部 Tool 执行或 Skill 的编排逻辑中。\n理想使用场景 复杂多步任务： 自动化 HR 入职流程、社交媒体管理管线或复杂的数据分析报告。\n消费级 Agent 平台： 用户希望\u0026quot;即插即用\u0026quot;而不需要理解底层 API 调用。\n3. MCP（模型上下文协议）：标准化基础设施 Tool 和 Skill 定义了 Agent 做什么，而 **MCP（模型上下文协议）**定义了 Agent 如何连接到这些东西。\n由 Anthropic 提出的 MCP 是一个开放标准——一种客户端-服务端架构——旨在标准化 AI 模型与数据源和工具的交互方式。把它想象成 AI Agent 的 \u0026ldquo;USB-C\u0026rdquo;。\n一个 MCP Server 可以向 MCP Client（如 Claude Desktop 或自定义 Agent）暴露三样东西：\nResources： 模型可以读取的数据（例如本地文件、Notion 页面）。\nPrompts： 可复用的提示词模板。\nTools： 我们在第一节讨论的可执行函数。\n优点 通用互操作性： 只需编写一次 MCP Server，任何支持 MCP 协议的 Agent 或 IDE 都能即刻使用其工具和数据。不再需要为不同框架重写集成。\n安全与边界： MCP Server 在本地或隔离的基础设施上运行。AI 模型（客户端）只通过协议通信。它无法在 MCP Server 明确暴露的范围之外任意执行代码，这使得企业级采用更加安全。\n动态发现： Agent 可以连接到 MCP Server 并动态询问\u0026quot;你有哪些工具和数据可用？\u0026quot;，实现极其模块化的架构。\n缺点 实现开销： 编写一个 MCP Server 比直接把 Python 函数扔进 LLM 的 Tool 数组需要更多的样板代码和架构规划。\n网络延迟： 因为它依赖客户端-服务端通信（通常通过 STDIO 或 SSE），相比直接的内存函数调用有轻微的性能开销。\n理想使用场景 企业数据集成： 将 AI 安全地连接到内部数据库（Postgres、Jira、Slack），无需将原始数据上传到云服务商。\n开发者工具（IDE）： 允许 AI 编程助手（如 Cursor 或 Windsurf）安全地与本地文件系统、linter 和版本控制交互。\n面向未来的生态建设： 构建能在 Agent 框架不断变化的环境中存活的集成方案。\n终极类比 为了把所有内容串起来，想象你在经营一家高档餐厅，LLM 是主厨：\nTool 是原始的厨房器具：刀、烤箱、搅拌机。主厨需要它们，但它们只是孤立的物件。\nSkill 是菜谱和副厨：一个预定义的工作流，告诉你\u0026quot;做一道惠灵顿牛排，先用刀，再用烤箱，然后按这个顺序使用静置架\u0026quot;。\nMCP 是标准化的厨房台面和电源插座：不管你买的是博世烤箱还是 KitchenAid 搅拌机，只要它们用的是标准插头（MCP），你就能把它们插进厨房（AI 生态），主厨就能立即使用。\n结语 我们正在告别为每个新 AI 项目都定制化构建 API 脚本的时代。\n如果你在构建简单的自动化，用基础的 Tool 就够了。如果你在构建面向消费者的复杂工作流，设计健壮的 Skill。但如果你在构建未来的基础设施——将私有数据和关键系统连接到多种 AI 模型——MCP 是你今天就需要采用的标准。\nAI 的未来不只是更聪明的模型；而是标准化、安全且具备完整能力的生态系统。\n","permalink":"https://www.creaturelove7.com/zh/ai/tool_mcp_skill/","summary":"厘清 Agent AI 中 Tool（原子函数）、Skill（复杂工作流）和模型上下文协议（MCP）的区别，为开发者提供一个架构框架来选择合适的抽象层次。","title":"Tool vs. Skill vs. MCP：一文讲清三者区别"},{"content":"我从 OpenClaw 的记忆架构中学到了什么，以及我是如何在 OpenCode 中构建一个轻量版本的。\n问题所在 AI 编程 Agent 是无状态的。每次新会话都从零开始——你需要重新解释项目结构、技术栈和各种决策。对于长期项目来说，这严重拖累生产力。\nOpenClaw 是怎么做的 OpenClaw 使用纯 Markdown 文件作为记忆载体：\nSOUL.md — AI 的个性和行为规则 USER.md — 用户画像与偏好 MEMORY.md — 精选的长期记忆 memory/YYYY-MM-DD.md — 每日原始会话日志 关键创新在于自我维护：AI 会定期审阅每日日志，将有价值的信息提取到 MEMORY.md 中，并清理过时条目。在上下文压缩之前（当会话过长时），它会触发一次静默的\u0026quot;记忆刷写\u0026quot;，在重要信息丢失前将其保存。\n这构建了一个自然的层级结构：每日日志作为短期记忆，MEMORY.md 作为中期记忆，USER.md/SOUL.md 作为永久身份。\n我在 OpenCode 上的简化版本 OpenClaw 的完整系统包括向量嵌入、混合搜索和自动心跳——对于交互式编程 Agent 来说过于复杂。我的核心洞察是：你不需要每日日志。OpenCode 在上下文中保留了完整的对话记录，所以只需在会话结束时直接将摘要写入 MEMORY.md 即可。\n基本配置 project/ ├── AGENTS.md # 包含\u0026#34;会话开始时读取 MEMORY.md\u0026#34;的指令 ├── MEMORY.md # 项目特定的决策和进度 └── ... ~/.config/opencode/ └── opencode.json # /save 命令在此注册 MEMORY.md 存放在每个项目根目录下——记录技术决策、进度和架构笔记。\nUSER.md 是全局的（只有一份），由自定义 MCP 服务器维护——存储跨项目通用的用户偏好。\n/save 命令 1 2 3 4 5 6 7 8 { \u0026#34;command\u0026#34;: { \u0026#34;save\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;将会话摘要写入项目记忆\u0026#34;, \u0026#34;template\u0026#34;: \u0026#34;回顾我们的整个对话。执行以下操作：\\n1. 如果 MEMORY.md 存在则读取它\\n2. 追加新的关键决策、技术发现、已解决的 bug 和进度\\n3. 删除过时或已被取代的条目\\n4. 保持 MEMORY.md 在 200 行以内\\n5. 绝不存储密钥或 token\u0026#34; } } } 会话结束 → 输入 /save → AI 回顾对话 → 更新 MEMORY.md → 下次会话从上次断点继续。\n为什么不用全局记忆？ 我最初设计了一个 GLOBAL_MEMORY.md 来聚合所有子项目的记忆，配合 /sync-memory 命令。后来放弃了——跨项目引用极少出现，真正需要时直接让 AI 去读另一个项目的 MEMORY.md 就行。不要过度设计。\n经验总结 从简单开始。 一个 MEMORY.md 加一个手动 /save 命令，就能捕获完整记忆系统 80% 的价值。\n文件优于数据库。 Markdown 是人类可读的、可以用 git 追踪的，AI 可以用内置工具直接读写它。无需额外基础设施。\n手动触发优于自动触发。 像\u0026quot;在对话中自动更新记忆\u0026quot;这样的指令并不可靠——AI 会忘记。一个显式的 /save 命令才是可靠的。\n最大的差距在于从零到一。 \u0026ldquo;没有记忆\u0026quot;和\u0026quot;基础记忆\u0026quot;之间的差距是巨大的。\u0026ldquo;基础\u0026quot;和\u0026quot;高级\u0026quot;之间的差距是微乎其微的。先发布简单版本。\n","permalink":"https://www.creaturelove7.com/zh/ai/memory-openclaw/","summary":"提供了一份为 AI 编程 Agent 实现持久化记忆系统的实操指南，主张采用简化的文件方案和手动 \u0026lsquo;/save\u0026rsquo; 命令来捕获会话上下文，以最小复杂度获取最大价值。","title":"如何让你的 Agent 像 OpenClaw 一样聪明"},{"content":"网上到处都是\u0026quot;我用 AI 5 分钟就搭了个应用\u0026quot;的说法。作为一名软件工程师，我知道现实完全不是那回事。生成一段脚本很容易；架构一个可扩展、可维护、拥有出色用户体验的 iOS 应用才是真正的难题。\n这个周末，我挑战自己，使用 Claude Code 在短短 4 小时内为一个名叫 ItemMaster 的库存管理应用构建了一个生产就绪的 MVP。\n我并不是靠输入一个神奇的一次性提示词来实现的。我把 AI 不是当作资深开发者，而是当作一个需要严格、滴水不漏的工程和产品工作流的超快速初级开发者。\n以下是我将一个想法在一个下午变成可运行 SwiftUI 应用的完整框架和提示词执行流水线。\n第一阶段：前置准备（先别写代码） 使用 AI 最大的错误是在系统设计和产品逻辑锁定之前就让它写代码。我的第一个小时没有一行 Swift 代码。\n竞品分析与 UI/UX 设计： 我没有凭空猜测用户需要什么。我下载并深入分析了市面上五款类似的库存管理应用。我无情地剖析了它们的引导页、功能集和 UI 交互。通过提取最佳概念、摒弃笨拙的机制（\u0026ldquo;取其精华，去其糟粕\u0026rdquo;），我设计了一套精简的功能集和高度直觉化的 UI/UX 流程。\n\u0026ldquo;三位一体\u0026quot;的上下文： 在脑海中建立好思维模型后，我将原始需求输入 Claude Code，让它打磨和正式化三个基础文件。在这三个文件完美之前，不生成任何 UI 或逻辑代码：\nCLAUDE.md（设计文档）： 终极真理之源，规定项目结构、技术栈（SwiftData、Swift Charts）和严格规则（如\u0026quot;不使用第三方库\u0026rdquo;）。\nModels.swift： 完整的数据库 schema 和关系。\nConstants.swift： 默认枚举、分类和配置。\n这三个文件成为后续每个提示词的常驻上下文。\n第二阶段：逐步提示词序列 基础打好后，我执行了一个高度纪律化的有序提示词策略。绝不要一次让 AI 构建整个功能。\n以下是我的确切执行顺序：\n搭建架构： \u0026ldquo;严格按照 CLAUDE.md 中的定义创建文件夹结构。为每个 view 和 view model 创建空的占位文件。\u0026rdquo;\n构建基础 UI 骨架： \u0026ldquo;实现导航结构和 Tab 栏。确保空 view 之间能正确路由。\u0026rdquo;\n分块的 CRUD 操作： 我将增删改查操作拆分开来。对于复杂数据类型，我甚至进一步拆分为多个提示词。例如：一个提示词严格只做\u0026rsquo;添加项目表单 UI\u0026rsquo;，另一个完全独立的提示词做\u0026rsquo;SwiftData 插入逻辑\u0026rsquo;。\n逐模块添加功能： 只有在核心 CRUD 闭环完成后，我才开始提示特定功能，比如原生仪表盘图表或动态列表排序。\n第三阶段：验证与版本控制循环（秘密武器） 这是 AI 驱动开发工作流中最关键的部分。AI 会产生幻觉，如果你不小心，它会引入回归问题。我为每一个提示词都实施了严格的验证循环：\n立即编译和调试： AI 为某个提示词生成代码后，我立刻在 Xcode 模拟器中运行。在继续下一步之前，我测试该特定功能的完整性和 bug。\n\u0026ldquo;提示词历史\u0026quot;台账： 我维护了一个持续更新的 Prompt History.md 文件。我记录了每一个使用过的提示词。如果某个提示词产生了 bug，我不会手动修复；我会写一个专门的\u0026quot;Bug 修复提示词\u0026rdquo;，交给 AI，并在历史文件中记录这个修复提示词。这创建了整个项目的可复现轨迹。\n原子化提交是必须的： 我在每一次成功的提示词和调试会话后都将代码提交到 Git。当 AI 最终走进死胡同并破坏了路由时，我没有浪费时间去解开它的烂摊子。我只需 git revert 到上一个稳定的提示词状态，然后调整我的指令。\n第四阶段：面对真实世界（硬件边界情况） 这个工作流的价值在硬件测试中得到了验证。在模拟器上，一切正常。在真机 iPhone 上，点击\u0026quot;相机\u0026quot;按钮添加物品照片时应用立刻崩溃了。\n因为我有原子化提交和模块化配置，我没有慌。我写了一个高度定向的 bug 修复提示词：\n\u0026ldquo;检查 AddItemView 中的相机调用。在 Info.plist 中添加 NSCameraUsageDescription。添加 isSourceTypeAvailable 检查，并在用户拒绝相机权限时构建一个 alert 流程，引导用户跳转到系统设置。\u0026rdquo;\nAI 生成了安全包装代码，我在设备上测试了它，验证了边界情况，然后提交了代码。\n核心启示 AI 不会取代软件工程或产品直觉——它放大了它们。如果你的流程是混乱的，AI 只会帮你以前所未有的速度写出意大利面条代码。\n但如果你应用严格的系统设计——从竞品研究开始、锁定数据模型、执行有序的提示词流水线、保持严格的提示词台账、并强制执行原子化 Git 提交——你就能以一年前不可能的速度构建出健壮、生产就绪、拥有出色 UI/UX 的 MVP。\n","permalink":"https://www.creaturelove7.com/zh/tech/ios-vibecoding/","summary":"阐述了一个严谨的四阶段框架，利用 AI 助手快速构建生产就绪的 iOS MVP，强调前期严格的系统设计、有序的提示词流水线，以及配合原子化 Git 提交的严格验证循环。","title":"我如何在 4 小时内用 AI 构建了一个 iOS MVP"},{"content":"2026 年初，一个由 Peter Steinberger 开发的\u0026quot;业余项目\u0026quot;在短短几天内经历了两次改名（Clawdbot -\u0026gt; Moltbot -\u0026gt; OpenClaw），然而在这一片混乱中，它却收获了超过 15 万颗 Star——速度甚至超过了早期的 Kubernetes 和 Linux。\nOpenClaw 到底是什么？为什么它让无数开发者通宵达旦地部署，甚至引发了 Mac Mini 的抢购潮？\n在这篇文章中，我们将层层剖析 OpenClaw，分析它做对了什么，以及它如何重新定义了我们对 AI Agent 的想象。\n什么是 OpenClaw？ 简单来说，OpenClaw 是一个运行在本地、拥有真正\u0026quot;执行力\u0026quot;的 AI 私人管家。\n如果你用过 ChatGPT，你会知道它是一个\u0026quot;被动\u0026quot;的聊天机器人：你问，它答。对话结束，它就\u0026quot;睡着了\u0026quot;。\nOpenClaw 完全不同。它连接你的本地文件系统、你的日历、你的邮箱。最重要的是，它\u0026quot;寄居\u0026quot;在你常用的即时通讯应用中（比如 WhatsApp、Telegram、Discord）。你可以像给真人助手发消息一样给它下指令：\u0026ldquo;帮我盯着这只股票，跌到 100 美元就通知我\u0026rdquo;，或者\u0026quot;把这周所有的 PDF 发票收集起来，重命名好，发给会计\u0026quot;。\n它不只是生成文字——它执行操作。\nOpenClaw 的三大核心创新 OpenClaw 的爆火并非偶然。它击中了当前大语言模型（LLM）应用的三个核心痛点，这构成了它的创新所在：\n打破\u0026quot;第四面墙\u0026quot;：从聊天框到操作系统 目前大多数 AI 都被困在浏览器标签页里。OpenClaw 最大的创新在于打破了 AI 与操作系统之间的那堵墙。\n权限解放： 它有能力读取本地文件、运行 Shell 脚本、控制浏览器。\n无缝融合： 它不需要你打开一个专门的 App；它就潜伏在你的 Telegram 或 Discord 联系人列表中。这种 \u0026ldquo;ChatOps\u0026rdquo; 交互方式将使用 AI 的门槛降到了最低。\n\u0026ldquo;心跳\u0026quot;机制：主动式 AI 的诞生 这是 OpenClaw 最迷人的特性。传统 LLM 是无状态、被动的。OpenClaw 引入了 Heartbeat 模式，让 AI 可以\u0026quot;定时唤醒\u0026quot;或\u0026quot;持续在后台运行\u0026rdquo;。\n它不需要你每次去戳它。它会主动给你发消息：\u0026ldquo;老板，你关注的那个 GitHub Issue 刚刚更新了，要不要我回复？\u0026rdquo;\n这种主动性让它从一个\u0026quot;工具\u0026quot;进化成了\u0026quot;队友\u0026quot;。\n去中心化的\u0026quot;技能\u0026quot;生态 OpenClaw 巧妙地采用了松散的插件架构。社区在短短一周内就贡献了超过 5000 个 Skill。\n想让它控制飞利浦 Hue 灯泡？有插件。\n想让它在 Polymarket 上自动交易？有插件。\n想让它帮你抢演唱会门票？也有插件。\n这种\u0026quot;乐高式\u0026quot;可扩展性让每个人的 OpenClaw 都能生长为完全不同的个体。\n为什么它\u0026quot;突然\u0026quot;就火了？ 除了产品创新本身，OpenClaw 的病毒式传播有更深层的社会心理原因：\n对 \u0026ldquo;SaaS 订阅\u0026quot;的疲惫与反抗： 人们厌倦了每月给 ChatGPT、Claude、Midjourney 交钱，同时还要担心数据隐私。OpenClaw 高举 Local-First 大旗：代码在你手里，数据在你硬盘上，模型可以在 Ollama 上本地运行。这迎合了极客社区\u0026quot;数据主权\u0026quot;的意识形态。\n\u0026ldquo;贾维斯\u0026quot;幻想的实现： 每个看过《钢铁侠》的程序员都有一个贾维斯梦。OpenClaw 是目前市面上最接近贾维斯原型的开源实现——它听话、全能、完全属于你。\nMoltbook 的助推： Moltbook（一个只有 AI Agent 才能发帖的社交网络）的同步诞生引发了争议，但它的赛博朋克设定一下子把 OpenClaw 推出了小众圈子，成为一种文化现象。\n阴影之下：狂欢背后的隐忧 然而，作为理性的科技观察者，我们必须看到 OpenClaw 带来的巨大风险。\n安全噩梦： 就在昨天，安全机构报告超过 13 万个 OpenClaw 实例直接暴露在公网上，没有任何防护。想想看：你给了这个 AI 读取你所有文件和执行终端命令的权限，然后又把它赤裸裸地挂在了互联网上。这不是后门，这是向黑客敞开的大门。针对 OpenClaw 的远程代码执行（RCE）攻击已经出现，黑客可以轻松接管你的\u0026quot;贾维斯\u0026rdquo;，让它变成一个窃取密钥的间谍。\n信任危机： OpenClaw 过于强大的拟人化能力也引发了关于网络身份的信任危机。当 50 万\u0026quot;活跃用户\u0026quot;实际上只是运行在某个程序员 Mac Mini 上的 50 万个 OpenClaw 进程时，互联网的真实性将被彻底瓦解。\n结语：一个新的开始 即使 OpenClaw 最终证明只是昙花一现，它也已经改变了历史。它证明了 AI Agent 不应该被锁在云端网页里，而应该作为基础设施融入我们的操作系统和通信网络中。\n对于开发者而言，OpenClaw 是一个充满无限可能的游乐场；但对于普通用户来说，它目前是一把没有保险栓的加特林机枪——威力无穷，但极容易走火。\n这或许就是 AI 时代的 \u0026ldquo;Linux 时刻\u0026rdquo;：混乱、危险，但充满生命力。\n","permalink":"https://www.creaturelove7.com/zh/ai/openclaw/","summary":"深入分析 OpenClaw 这款开源 AI 助手的病毒式传播——它在本地运行、拥有操作系统级执行能力，探讨其主动任务和去中心化技能生态等核心创新，同时揭示其背后的重大安全隐患。","title":"为什么 OpenClaw 能在一周内爆火"},{"content":"参与开源贡献是加速工程师职业发展最有效的方式之一。它证明你能够驾驭大型代码库、与分布式团队协作，并清晰地传达复杂想法。\n然而，入门门槛往往让人望而却步。从哪里开始？如何避免看起来像个新手？\n第一阶段：策略性搜寻 很多新手的错误是随便选一个热门项目（比如 React 或 Linux），然后被淹没。更好的策略是相关性。\n1. 从你在用的东西开始 最值得贡献的项目是你已经作为用户熟悉的项目。看看你的 package.json（JavaScript）、requirements.txt（Python）或 go.mod。\n为什么？ 你已经理解了\u0026quot;业务逻辑\u0026quot;和痛点。\n行动： 挑出 3 个你经常使用的库，查看它们的 GitHub 仓库。\n2. 评估项目健康度 在投入时间之前，确保项目是活跃且友好的。\n活跃度： 查看 \u0026ldquo;Insights\u0026rdquo; 标签 -\u0026gt; \u0026ldquo;Commit activity\u0026rdquo;。上个月有提交吗？\n响应时间： 看看已关闭的 Pull Request（PR）。审核用了多久？如果 PR 挂了好几个月都没人评论，换一个。\n标签： 寻找标记为 good first issue、help wanted 或 beginner friendly 的 issue。\n第二阶段：环境搭建与\u0026quot;规则\u0026quot; 写代码实际上是最后一步。第一步是了解当地的\u0026quot;法律法规\u0026quot;。\n1. 阅读 CONTRIBUTING.md 这不是可选的。每个认真的项目都有一个 CONTRIBUTING.md 文件。它会告诉你：\n如何搭建开发环境。\n代码风格规范（linting、格式化）。\n如何提交 PR（命名约定、模板要求）。\n小贴士： 如果一个项目缺少这个文件，它可能对新手不太友好。\n2. \u0026ldquo;潜伏\u0026quot;策略 不要贸然闯入。加入它们在 README 中列出的沟通渠道（Discord、Slack、邮件列表）。\n倾听： 当前的优先事项是什么？\n观察： 看看资深维护者是如何 review 代码的。他们喜欢小提交吗？他们要求严格的测试覆盖率吗？\n第三阶段：\u0026ldquo;侧门\u0026quot;进入策略 直接挑战复杂功能是被拒绝的捷径。相反，使用\u0026quot;侧门\u0026quot;方式——高价值、低风险的贡献。\n入口 A：文档（无名英雄） 维护者讨厌写文档，但用户喜欢读文档。\n修正： 纠正拼写错误或失效链接。\n澄清： 如果某个搭建步骤让你感到困惑，把它改写得更清晰，方便下一个人。\n翻译： 如果你会双语，翻译一页文档。\n入口 B：测试覆盖（信心构建器） 这是开源贡献的\u0026quot;作弊码\u0026rdquo;。\n策略： 找一个工具函数或组件。检查它是否有对应的测试文件。如果没有，或者测试很薄弱，写一个测试用例。\n为什么有效： 它不需要改动任何生产代码（低风险），所以维护者会很快合并这些 PR。\n第四阶段：工作流 一旦确定了任务，遵循这个专业工作流：\n认领 Issue： 在 issue 下评论：\u0026ldquo;Hi，我想做这个。还有人在做吗？\u0026rdquo; 绝对不要在没确认的情况下就开始工作。\nFork \u0026amp; Clone： 将仓库 fork 到你的 GitHub，然后 clone 到本地。\n创建分支： 创建描述性命名的分支（例如 fix/login-bug 或 docs/update-readme），绝对不要在 main 上工作。\nDraft PR： 如果你卡住了，提交一个 \u0026ldquo;Draft\u0026rdquo; Pull Request。这表明\u0026quot;我在做，但还没好\u0026rdquo;，让你可以获得早期反馈。\n第五阶段：利用 AI 工具（现代优势） 在 2024 年及以后，你有一个超能力：AI。以下是如何使用 LLM（大语言模型）如 ChatGPT、Claude 或 Gemini 来更快地贡献——而且不算作弊。\n1. \u0026ldquo;解释器\u0026rdquo; 开源代码往往复杂且注释稀少。\n提示词： \u0026ldquo;我在看这个开源项目中的 auth_middleware.py 文件。用简单的语言具体解释 token 验证逻辑是怎么工作的。\u0026rdquo; 2. \u0026ldquo;测试生成器\u0026rdquo; 提示词： \u0026ldquo;这是项目中的一个函数 calculateMetric。请为它写 3 个 Jest 测试用例，包括一个输入为 null 的边界情况。\u0026rdquo;\n行动： 不要只是复制粘贴。运行测试。验证它们通过。\n3. \u0026ldquo;代码审查员\u0026rdquo; 在提交 PR 之前，让 AI 做你的第一个评审员。\n提示词： \u0026ldquo;审查这段代码的可读性和潜在 bug。遵循 Python PEP8 标准。\u0026rdquo; ⚠️ 警告： 绝不要用 AI 向随机 issue 发送自动生成的代码。维护者看得出来，你会被封禁。用 AI 作为副驾驶，而不是飞行员。\n第六阶段：深入参与 在你最初几个 PR 被合并后，你不再是外人了。\n参加 Town Hall： 很多项目有公开的周会/月会视频通话。参加它们。你不需要发言；光是旁听就能帮你理解路线图。\n提出改进： 既然你现在熟悉代码了，你可以开自己的 issue 建议功能或重构方案。\n审查别人的代码： 审查其他新手的 PR 是赢得维护者尊重的好方法。\n结语 开源不是要求你从第一天就成为\u0026quot;10 倍效率工程师\u0026quot;。它关乎持续性和沟通。一个沟通清晰、会写测试的初级开发者，对项目的价值远超一个消失无踪的高级开发者。\n从小处开始。读文档。修一个拼写错误。欢迎加入社区。\n","permalink":"https://www.creaturelove7.com/zh/career/start_opensource/","summary":"一份面向开发者的策略指南：如何开始参与开源贡献，从找到合适的项目、理解贡献规范，到做出有影响力的首次贡献，以及利用 AI 工具加速这一过程。","title":"AI 时代开源贡献终极指南"},{"content":"关于结婚习俗 她看到近来社会风气多有变化，做母亲的责任更加重大。她发现像吉提那样大的女孩子在组织什么社团，到什么地方去听课。她们和男人自由交往，乘车出入于大街小巷，许多姑娘见人不行屈膝礼，而最主要的是，她们都确信选择丈夫是自己的事，用不着父母操心。“如今嫁女儿可不比从前了，”不仅所有的年轻姑娘，就连老一辈的人也都这么想和这么说。但是今天究竟该怎样嫁女儿，公爵夫人又无从打听。按照法国风俗，女儿的命运得由父母决定，这种做法现已无人采用，还受到了谴责。按照英国风俗，姑娘可以完全自主，这一做法也没人实行，况且在俄国社会上也是行不通的。俄国自己的风俗则是嫁娶凭媒妁之言，这又被认为不成体统，遭到了包括公爵夫人自己在内的众人的嘲笑。那么到底应该怎样出嫁和嫁女，谁也不知道。凡是跟公爵夫人谈论过这事的人，都对她说同样的话：“算了吧，如今该丢掉老规矩了。其实是年轻人结婚，又不是他们的父母结婚。让年轻人自己去做主吧。”说得倒轻巧，这些人又没有女儿。公爵夫人心里明白，女儿接近男人就可能产生爱情。她会爱上一个不想娶她的男人，或者爱上一个不适合当她丈夫的人。不管别人怎样劝说如今要让青年人自己安排自己的命运，公爵夫人就是不相信这一点，好比不相信如今五岁儿童的最佳玩具是上了真子弹的手枪一样。\n和如今似乎没什么区别\n","permalink":"https://www.creaturelove7.com/zh/books/anna_karenina/society_comments/","summary":"A focused look at the social commentary within \u0026lsquo;Anna Karenina,\u0026rsquo; analyzing a key passage on the shifting landscape of 19th-century marriage customs and the inherent conflict between tradition and emerging modernity.","title":"安娜卡列尼娜中的社会评论"},{"content":"斯捷潘·阿尔卡季奇 斯捷潘·阿尔卡季奇穿好衣服，往身上喷些香水，整理好衬衫的袖子，以习惯动作将香烟、皮夹、火柴和双链条带坠子的怀表分别放进几个口袋里，然后抖了抖手帕。虽然他遇上了倒霉事，但觉得自己还是那么清洁、芳香，身体健康而有朝气。他微微颠着腿走进餐厅，那儿已经摆好了咖啡，旁边是信件和机关里来的公文。\n这一段是在书的开头，斯捷潘与家庭教师偷情被妻子发现，妻子大发雷霆，斯捷潘第二天起床之后的表现。斯捷潘作为当时俄国机关要员，永远摆出一副上流、体面、沉稳的架子，即使内心已经波涛汹涌，表面仍然要装的体面。这个描述实在太真实了，非常的体面，看得十分舒适。\n他先看了信件。其中一个商人的来信很扫他的兴。此人想买妻子田庄上那片森林。森林固然该卖，只是眼下没有跟妻子和好前万万不可谈这件事。尤其令他不快的是，这种事情很可能使他面临的夫妻和解问题牵扯到金钱上的利害关系。难道他谋求与妻子和好就是出于这种利害关系，为了能卖掉那片森林吗？想到这里他感到受了侮辱。\n接着这一段就更加体现了他的虚伪，既想要卖妻子的财产，又觉得自己这样做不够体面。事实上，他想到了公务，想到了财产，却没先去照顾妻子的感受，这样比起讨好妻子卖田，更加令人不齿 。\n斯捷潘·阿尔卡季奇订的是一份自由主义报纸，不是极端自由主义的，而是多数人赞成的那种自由主义。尽管他其实对科学、艺术和政治都不感兴趣，但他坚决拥护多数人和他订的报纸对这三类问题所持的观点，并且随着多数人观点的改变而改变，或者毋宁说，他并不改变观点，而是观点本身在他头脑中不知不觉地变化着。\n之后的这份自由主义报更加体现了他外表华贵，内心空洞无物。订报不是为了了解国家大事，了解百姓疾苦，而是为了了解上流阶层的谈资，希望自己不要落伍。报纸上是什么观点，我就是什么观点。没有自由意志，但是谈到自由主义，又能在别人面前夸夸其谈。何其讽刺。\n看过报纸，喝完第二杯咖啡，吃了一块黄油白面包，他站起身，抖去西装背心上的面包屑，舒展一下宽阔的胸膛，愉快地笑了——倒不是他的心情特别愉快，而是因为他的消化功能良好。\n何其自恋。\n小姑娘是父亲的宝贝，她大胆地跑了进来，搂住父亲，笑着吊在他脖子上，像平时那样喜欢闻他络腮胡子上熟悉的香水气味。最后，小姑娘吻了吻父亲因为弯下身体而涨红了的那张慈爱的脸，松开双手，待要跑出去，父亲却拉住了她。 “妈妈怎么样？”他问道，一边抚摩着女儿柔嫩光滑的脖子。“你好。”他又朝向他问好的男孩子微笑说。 他意识到自己不太喜欢儿子，所以总是努力做得公平些；儿子感到了这一点，对父亲冷淡的微笑并不报以笑容。\n已经到了连在孩子面前都要装模作样的地步。\n“哎呀！”他垂下了头，漂亮的脸上露出忧愁的表情。“去还是不去呢？”他自言自语，但内心却在说，不必去了，除了虚情假意不会有别的，他俩的关系已经不可修复，因为既不能使她重新具有魅力而激发爱情，也不能把他变成失去恋爱能力的老人。现在除了虚伪和谎言，不可能有别的结果，而虚伪和撒谎却是有违他的本性的。\n这一段又是写实到夸张的地步，现实中有多少夫妻的关系已经不可修复，因为”既不能使她/他重新具有魅力而激发爱情，也不能把他/她变成失去恋爱能力的老人“，但是又为了孩子/利益不能立刻离婚呢。\n列文 “不，你等等，等等，”他说，“你要明白，这对我是生死攸关的问题。我从未和任何人谈过这件事。除了你，我谁也不能说。虽然你我在各方面是完全不同的人，爱好、见解等等一切，毫无共同之处，但是我知道你喜欢我也理解我，所以我也非常喜欢你。看在上帝分上，你就对我开诚布公吧。”\n这段话真的引起了我的共鸣。确实就是会有一起长大的朋友，虽然在各个方面都是完全不同的人，爱好、见解等等一切，但是知道彼此互相喜欢也理解，并且有些话只能对对方说。\n","permalink":"https://www.creaturelove7.com/zh/books/anna_karenina/human_description/","summary":"A critical analysis of characterization in Tolstoy\u0026rsquo;s \u0026lsquo;Anna Karenina,\u0026rsquo; examining the nuanced descriptions of Stepan Arkadyich and Levin to reveal themes of social vanity, personal hypocrisy, and authentic human connection.","title":"安娜卡列尼娜中的人物描写"},{"content":"简历的艺术：一种脱颖而出的策略方法 写简历通常是求职过程中最令人头疼的环节。它不仅仅是一份文件——它是你的营销推介。通过自己的经历和观察，我发现大多数简历失败的原因是太过通用。它们罗列的是任务而非成就，列出的是技能而非精通程度。\n以下是一个能让简历立刻抓住眼球的策略框架——分为摘要、工作经历和技能三个部分。\n1. 摘要：\u0026ldquo;三句话\u0026quot;法则 摘要是简历上最关键的黄金地段。它是招聘官看到的第一样东西，通常也是他们唯一会认真读的部分。不要把这个空间浪费在模糊的套话上。\n我推荐一个严格的三句话结构：\n第一句：开场钩子（专业认可） 立刻陈述一个在你专业领域获得认可的成果。用你最大的亮点抓住读者的眼球。 目标： 一上来就证明你有实力。 第二句：人设 + 证据 定义你是谁，但必须附上\u0026quot;证据\u0026rdquo;。如果你说自己\u0026quot;自驱力强\u0026quot;，就需要立刻用具体例子来佐证（例如，自学了一套新技术栈、从零搭建了一个项目，或者一年写了 365 篇技术博客）。 目标： 用数据支撑的人设展示。 第三句：承诺（未来价值） 描述你将成长为怎样的人，以及这个发展轨迹将如何为公司赋能。他们应该如何期待你未来的产出？ 目标： 将你的成长与公司的成功对齐。 2. 工作经历：背景、影响力与成长 这个部分是你拉开差距的地方。大多数求职者列的是他们做了什么。要脱颖而出，你必须列出你如何成长以及取得了什么成就。\n要点的结构 对于每个职位，将经历拆解为四个关键部分：\n背景： 当时的情况是什么？ 行动： 你具体做了什么？ 结果： 量化的成果是什么？ 认可： 获得了什么荣誉或认可？ 关键原则 一行原则： 每个要点控制在一行之内。简洁迫使你聚焦最重要的信息。 通过成长来差异化： 不要只列技术实现。突出你在项目中的个人成长和学到的经验。这能把你和技术栈相同的候选人区分开。 \u0026ldquo;埋点\u0026rdquo;（钩子）： 有意提及你解决过的特定复杂挑战。这些是面试官的\u0026quot;钩子\u0026quot;，让你在面试中有机会详细阐述你的问题解决过程。 反面示例：\n使用 Python 编写数据分析脚本并修复 bug。 正面示例：\n架构了基于 Python 的数据管线，将处理时间缩短 40%，被 CTO 评为\u0026quot;年度最佳创新\u0026quot;。 3. 技能：精准胜过数量 这个部分通常是简历中最同质化的。每个人都在列\u0026quot;沟通能力\u0026quot;、\u0026ldquo;Microsoft Office\u0026rdquo;，或者自己只是略知皮毛的基础语言。\n相关性是关键： 只列你极其擅长的技能，或者你申请职位绝对必备的技能。 去掉水分： 如果它与职位的核心职能无关，删掉它。 ATS 例外： 唯一的例外是为了通过申请人追踪系统（ATS）/ 机器筛选而加入关键词。除此之外，保持精炼。 结语：唯一的目的 你的简历不应该是一部自传——它应该是一份精心策划的高光集锦。通过聚焦强有力的三句话摘要、以结果为导向的经历和高度相关的技能，你尊重了招聘官的时间，掌控了叙事节奏。\n最终请记住这一点：简历只有一个目的——拿到面试。\n一旦你走进那个房间，这份文件的使命就完成了。因此，页面上的每一个字都必须经过精心计算，以抓住招聘官的注意力，毫不留情地将你与竞争对手区分开来。如果一个字不能为你争取到那场面试，那就删掉它。\n","permalink":"https://www.creaturelove7.com/zh/career/howtowriteagreatresume/","summary":"通过这份策略指南提升你的简历：聚焦打造强有力的三句话摘要、展示以成果为导向的工作经历、精选精准的技能集，帮你抓住招聘官的注意力，拿下面试。","title":"如何写出一份出色的简历"}]