AI工具

先说你可能有的误区 很多人（包括我最开始）把 OpenClaw 当成"更聪明的 ChatGPT"来用——遇到问题就问它，让它帮你写代码、找资料、出方案。 这么用不是不行，但你会发现效果不稳定：有时候很惊艳，有时候一堆废话，然后你开始怀疑是不是模型不够好，或者提示词没写好。 问题不在这里。问题在于你没有给它任何上下文，它也不知道你是谁、你在做什么、你有什么标准。 每次对话都是从零开始，它帮你做的事情自然很难持续。 OpenClaw 真正的价值：把你的 SOP 变成可执行的代码 独立开发者每天都在重复一堆事情： 每天早上看任务列表、整理今日优先级 写完文章后要适配到不同平台（微信、小红书、推特） PR 合并后要更新文档、通知相关人员 定期做竞品调研、看行业动态 这些事情不是不会做，是太琐碎、太分散、太容易忘。 OpenClaw 能做的，是让你把这些流程显式地写下来——以 Skill 的形式。一旦写好，下次触发一句话就能跑完整个流程。 比如我写了一个 obsidian-daily skill，每天早上我说"开始今天的工作"，它会： 读今天的 daily note 模板 拉取 Linear 里我的 active tasks 检查 Obsidian 里有没有未完成的昨日任务 整合成一个今日计划，写入 daily note 这个流程我每天都要做，以前手动搞要 10-15 分钟，现在 2 分钟搞定，而且不会漏。 关键在于：Skill 是你写的，按照你的逻辑，调用你的工具，符合你的标准。 不是 AI 猜测你想要什么，而是你把想要的明确告诉它了。 配合你的工作流，而不是替代它 这是第二个容易踩的坑：以为用了 OpenClaw 就要换掉所有现有工具。 不对。它的定位是嵌入到你已有的工作流，而不是颠覆它。 我的工作流大概是这样： 任务管理：Linear 笔记/文章：Obsidian 代码：GitHub + tmux 内容发布：手动（现在部分用 OpenClaw） OpenClaw 没有替代任何一个。它是把这些工具"串"起来的那个层——它知道我的 Linear 任务，知道我的 Obsidian 结构，知道我的 GitHub 项目，可以跨工具协调。 ...

同样用 Claude，为什么 YC CEO 的 AI 比你好用 10 倍？ Y Combinator 的 CEO Gary Tan，最近把自己用 AI 的方式完全开源了。 不是那种「我用 ChatGPT 写邮件」的分享，而是一整套结构化的 AI Skill。他让 AI 像一个真正的技术合伙人一样帮他 Review 代码方案。 我认真拆解了其中最核心的一个：Founder CEO Review。 普通人 vs. Gary：从第一步就不一样 普通人用 AI：「这个代码怎么写？」 Gary 用 AI：先回答三个问题 ① 这是正确的问题吗？换个框架会不会更简单？ ② 什么都不做会怎样？这是真痛点还是假设的？ ③ 12 个月后的理想状态是什么？这个方案是最直接的路径吗？ 光这一步，就已经超过 90% 的人用 AI 的水平了。大多数人拿到需求就开干，Gary 的 AI 第一件事是质疑需求本身。 三种模式，像换挡一样切换 📈 EXPANSION 模式 「10 倍野心、2 倍投入的版本是什么？世界上最好的工程师会怎么做？」 ⚖️ HOLD 模式 「最少改动达到目标？超过 8 个文件或 2 个新类 = 警报」 ...

Core Idea AI 正在重塑工程师的杠杆结构。当一个 IC 可以通过 Agent 集群完成原来一个团队的工作时，EM 作为"人力杠杆中间层"的价值正在下降。我选择在这个转折点离开传统职场，用 AI 重新定义自己的生产方式。 GPT 5.4 又发布了。说实话，最近半年大模型更新的速度快到让人有点麻木——每次刚适应完一个版本，下一个就来了。 但对我来说，真正改变一切的其实不是某个具体模型。是 2025 年底那段时间，我突然意识到：AI 已经不只是"好用的工具"了，它在重构我整个工作方式。 趁这个话题还热乎，聊聊我这半年的一些思考——为什么我从一个程序员，一路晋升到管理层，最后又选择了裸辞跑路。 一、Tipping Point：2025 这一年发生了什么 如果让我选一个分水岭，那就是 2025 年。但这个变化不是一夜之间发生的，而是一整年的量变，最终在年底完成了质变。 早期：AI 只是顺手帮你加个速 2025 年上半年，我们开始用 Cursor 之类的工具来辅助编码。但说实话，那时候的 Cursor 充其量就是 Copilot 的一个优化版——你忘了某个语法糖或者某个 API 的写法，它帮你用 Tab 自动补全一下。本质上事情还是你在做，它只是顺手帮你加点速，人的控制权非常足。 后来有了 Claude Code，大家开始尝试把一些小段代码交给它来写。但很快就发现问题：前端代码它确实写得不错，但后端代码的逻辑能力和上下文理解就差很多。那时候的工具有的用 LSP 来做代码索引，有的直接用 grep 之类的纯文本搜索来找上下文关系。虽然能感觉到在进步，但还是经常出错，每一个小功能点都需要人来把关。 那个阶段，我们只敢让它做一天以内的任务。对于一两个星期的长任务？想都不要想——必须手动拆成一小块一小块的 PR，按照我们的规范一步步来。 转折：12 月的量变到质变 到了 11 月底和 12 月，事情开始不一样了。11 月 24 日 Anthropic 发布了 Claude Opus 4.5，12 月 18 日 OpenAI 发布了 GPT-5.2-Codex。 ...

Core Idea “Agents running in the background” ≠ “Background Agents”。Background Agent 是一个有隔离计算 + 事件路由 + 治理体系的自主交付系统。Ramp 30% PR、Stripe 1300+ PR/周的数据证明：关键不是模型能力，而是 MicroVM 沙箱 + 确定性反馈循环 + 已有基础设施复用 的工程化落地。 零、什么是 Background Agent — 概念框架 在讨论具体实现之前，需要先厘清定义。background-agents.com 给出了一个重要区分： 你可以开多个终端、用 git worktree、甚至在角落放个 Mac Mini 跑 Agent——但那只是 agents running in the background。Background Agent 是一个有完整基础设施和治理体系的自主交付系统。 三层基础设施模型 Background Agent 不是一个工具，而是一个系统。它需要三层基础设施协同： 层 职责 对应实现 隔离计算环境 按需启动沙箱，Agent 在其中安全执行 Ramp: Modal VM / Stripe: EC2 Devbox 事件路由系统 基于触发条件调度 Agent PR 事件、安全漏洞、Slack 消息、定时任务 治理层 权限、审计、故障隔离（blast radius 控制） 人类 PR review、MCP 工具权限控制 Background Agent vs CI/CD 维度 CI/CD Pipeline Background Agent 执行内容 预定义步骤（build → test → deploy） 自主决策（分析问题 → 生成代码 → 验证 → 提 PR） 代码生成 不生成新代码 核心能力就是生成代码 决策能力 无，纯确定性执行 有，能根据上下文选择方案 失败处理 终止或重试 分析原因、自动修复、迭代 高价值落地场景 Agent 最先产生价值的不是"写新功能"，而是大规模重复性工程任务（消灭 toil）： ...

AI 写代码很快，但人类成了瓶颈 如果你用过 Claude Code 或 Cursor，一定体验过这种场景：AI Agent 几秒钟就改完了代码，而你却要花几分钟审查、测试、再给下一个指令。更尴尬的是，当你想同时推进多个功能时，只能在一个 Terminal 里串行等待——Agent 在忙，你在干等。 这就是 AI Native 思维下的新瓶颈：代码生产已经不是问题，人类的注意力和工作流成了限制因素。 Conductor 试图解决的正是这个问题。它的核心理念很简单：既然 AI 写代码这么快，我们就不该一个一个任务串行处理，而应该并发地管理多个 AI Agent。 核心理念：Git Worktree 驱动的并发模式 Conductor 的并发能力建立在 Git Worktree 之上。如果你不熟悉这个概念，可以这样理解： Git Worktree 就像给你的项目开了多个"独立副本"。每个副本共享同一个 Git 历史，但文件是完全隔离的。你可以在副本 A 里改登录功能，同时在副本 B 里修 Bug，互不干扰。 在 Conductor 里，每按一次 ⌘ + N，就会创建一个新的 Workspace（工作区）。每个 Workspace： 有独立的 Claude 对话 有独立的代码副本（基于 Worktree） 有独立的变更历史 这意味着你可以同时开 3 个 Workspace，让 3 个 Agent 并行工作：一个做前端组件，一个写 API，一个修复测试。只要这些任务之间没有太多文件冲突，最后合并就是了。 这种模式彻底改变了开发节奏——从"等 AI 写完 → 审查 → 下一个任务"变成了"分配任务 → 并行监控 → 批量审查合并"。 ...