AI Coding on Codexer

当 IDE 不再是主角：AI 编程代理如何重塑开发者工作流

Mon, 06 Jul 2026 10:00:00 +0800

七月初，Hacker News 上有一个帖子引发了两百多人的激烈讨论。标题很直白：「I’m opening VSCode less and less every day」，我每天打开 VSCode 的次数越来越少了。

发帖者是一个有九年经验的开发者。他不是 AI 布道师，也不是硅谷 KOL。他只是一个每天写代码的普通工程师，在描述一件他最近才意识到的微妙变化：他不怎么需要 IDE 了。

从「写代码」到「读代码」

这个转变是怎么发生的？他描述了一个渐进的过程。

最早是 AI 插件进入 VSCode。那时他还是主力写代码的人，只不过 AI 会帮忙补全或建议。他写得少了，读得多了，读 AI 生成的代码，判断是否采纳。

然后 Claude 的桌面应用出现了。一开始他觉得不好用，还是留在 VSCode 里。但随着桌面端不断迭代，IDE 插件反而变得臃肿卡顿，他慢慢把注意力从代码编辑器转移到了 AI 桌面应用上。

现在是这样的：他在 Claude（或 Codex）的终端里描述需求，AI 生成改动，他在应用里看 diff。只有需要深入审查时，才切回 VSCode。

结果就是，「I rarely open VSCode now. I rarely write code now.」

以及那句让评论区破防的话：「I miss writing code.」

评论区里的代际分裂

HN 的评论区完美展现了当下开发者群体的认知分裂。

有人共鸣：「我也快到卸载 VSCode 的边缘了，只用轻量级编辑器处理 .env 文件之类的，几乎不手动写代码了。奇怪的时代。」

有人反击：「你们的代码品味为零吧？现在没有一个模型写代码能比我自己写得更好，我完全无法理解为什么有人能接受模型生成的那些粗糙货色。」

有人理性：「AI 让开发者少写代码，但不应该让我们理解得更少。如果你怀念写代码本身，那说明你真正在乎这门手艺。」

还有人提供了一个被高频引用的新角色框架，来自 Boris Cherny 的分类：

AI 编程代理的下一个战场：从「聊着写」到「编排式开发」

Sun, 05 Jul 2026 10:00:00 +0800

2026 年已经过半。如果你在过去半年里用过任何 AI 编程工具——Codex、Claude Code、Cursor、Copilot——你应该已经习惯了一个基本模式：打开终端，描述需求，看着模型改文件，然后你检查、确认、提交。

这种模式解决了很多问题。但它也制造了一个新问题。

问题不在于模型不够聪明。GPT-5.4 能写的代码比大多数初级工程师都好。Claude Sonnet 对大型代码库的理解深度已经超过了很多工作三年的开发者。真正的瓶颈在别处：当需求从"改一个函数"变成"实现一个跨多个仓库的功能"时，聊天窗口装不下所有上下文。

DoorDash 最近开源了一个叫 Agentic Orchestrator 的工具，它的设计哲学直接回应了这个问题。我仔细读完了它的整个 README 和架构设计，这篇文章想和你聊聊它背后的范式转变。

聊天模式的三个天花板

在理解编排模式之前，先看看聊天模式到底卡在哪。

第一，上下文是单线程的。 你和模型之间的对话历史就是唯一的记忆载体。当你从「实现用户登录」聊到「重构权限系统」再聊到「优化数据库查询」，最后让模型写一个新的 API 时，它看到的是一段可能已经超过 200K token 的聊天记录。前面的关键决策早就被压缩到注意力窗口的边缘了。这不是模型的问题，是聊天这个交互形式的结构性缺陷。

第二，质量检查发生在最后。 聊天模式下，你写完一大段代码才去跑测试、做 review。如果发现架构层面的问题（比如循环依赖或接口设计不合理），代价往往是一大段对话白费。更糟的是，很多时候你会选择「将就改改」，因为推倒重来的心理成本太高了。

第三，无法并行。 一个人的注意力和一个聊天窗口只能同时处理一件事。如果你手上有三个独立的需求，你只能串行——聊完一个、提交、再聊下一个。代码可以并行写，但人不行。

这三个问题不是靠更强的模型能解决的。它们需要的是流程设计。

编排式开发的核心思想

Agentic Orchestrator 做的事情，本质上就是把一个高层的功能需求拆解成一个多阶段的工程流水线：

KB 构建 → 需求澄清 → 技术调研 → 方案设计 → 路线图规划 → 分阶段实现 → 终审 → 发布

这里面有几个关键设计，值得展开说。

1. 上下文不是聊出来的，是建出来的

这个流水线的起点不是聊天，是知识库构建。在真正动手写代码之前，系统会先扫描整个仓库，自动生成一份结构化的知识图谱：架构约定、API 接口面、依赖关系、测试验证方式。这份 KB 会被缓存，只在代码发生变化时增量更新。

这意味着什么？意味着后面的每个阶段——需求澄清、方案设计、代码实现——都不是在凭记忆工作，而是在读一份经过结构化整理的项目文档。同一个仓库里的后续功能可以复用同一份 KB。你的项目越大，这个设计的价值就越高。

2. 质量关口前置到计划阶段

传统做法是你写完代码再 review。编排模式的做法是：先让 AI 审查计划，再让 AI 写代码。

具体来说，在路线图规划和阶段计划生成之后，系统会启动多个并行的"计划评审专家"——它们分别从架构合理性、结构完整性、需求覆盖度、安全性、性能、测试覆盖这六个维度独立评分。任何一个评审专家要求修改，计划就会自动迭代。

这个设计背后有一个朴素但深刻的工程直觉：在计划阶段改架构，比在代码写完后重构便宜一百倍。

从 Claude Code 迁移到 Codex 的诚实指南：12 项配置全映射与 1 个死胡同

Sat, 04 Jul 2026 10:00:00 +0800

你用 Claude Code 已经大半年了。

你的 .claude/ 目录里堆满了精心调教过的配置：十几个 MCP 服务器、五个专用的 subagent、一套精确到命令级别的权限白名单，还有一堆 hooks 脚本。每次 claude 回车，一切都运转得像瑞士手表一样精准。

但你也注意到了，Codex 这边的变化越来越快。0.140 版本加入了 /import 命令，0.142 进一步完善了沙箱和 hooks 机制。你开始琢磨：是不是该试试搬过去了？

这个问题我问过自己，也帮几个团队实际走过一遍。结论是：大部分迁移是机械的，小部分需要重新理解，有一个地方必须用额外工具绕过去。 这篇文章把 12 个配置项一一拆开，告诉你每一步会发生什么。

30 秒速览：能迁吗？

问题	答案
大部分配置能迁移吗？	能。12 个配置项中 9 个可以直接迁或简单改造。
最快路径？	`codex` 里敲 `/import`，然后手动处理 3 个问题。
自动迁移覆盖什么？	指令文件、MCP 服务器、Skills、slash 命令、自定义 API 端点。
需要手动处理的？	权限模型、hooks 格式、subagent 包装方式。
唯一的死胡同？	Anthropic Claude 模型。原生 Codex 只能用 OpenAI 模型。
死胡同的解法？	注册一个 OpenAI 兼容网关作为 `model_provider`，继续用 Claude 跑代码。

本文基于 Codex CLI 0.142.5（2026 年 7 月 1 日）和 Claude Code 2.1.178 实测。如果你用的是更老的 Codex，先升级，/import 命令在 0.140.0 之前根本不存在。