Claude Code

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。 ...

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 写完 → 审查 → 下一个任务"变成了"分配任务 → 并行监控 → 批量审查合并"。 ...