这几个月，我发现自己有一个很具体的变化：接到需求后，我打开 IDE 的时间越来越晚了。
以前，我会先启动 VS Code 或 Xcode，搜索类名、翻调用链，再慢慢确认问题在哪里。现在更常见的做法是先打开 Codex/Claude/Trae Work：让它读需求、扫描项目、定位相关模块，并把那些还没说清楚的边界列出来。等我回到 IDE，任务往往已经从“这件事应该怎么做”，变成了“实现已经在这里，跑起来看看哪里不对”。
GPT-5.6 发布后，大家自然会聊模型变强了多少。但本次关注点不同，聊的不是模型，而是承载它的入口，很多人熟悉的 IDE 工作入口，正在以 Codex/Claude/Trae Work 这种方式替代。
所以：
IDE 不会消失，但它正在失去对开发流程的入口垄断。
真正变化大的不是“AI 会不会写代码”，而是代码正在失去开发工作的起点位置。
古法编程 VS AI Coding Agent
古法编程，从文件开始，IDE 是默认入口：
需求 → 打开 IDE → 搜索代码 → 理解问题 → 开发 → 调试
这没有问题，但当任务跨越多个模块时，文件并不是最好的起点。比如：
给 Flutter 应用增加离线同步，后端是 Django，不能破坏现有数据。先读项目，列出受影响模块和迁移风险。
这里面有移动端状态、接口约定、数据库迁移、缓存策略和测试路径。它不是一个文件的问题，甚至还不是一个纯编码问题。
AI Coding Agent 开发，从问题开始，工作流：
需求 → Codex/Claude/Trae Work → 澄清边界 → 阅读项目
→ 方案与修改 → IDE → 调试、验证、收尾
IDE 解决的是“代码在哪儿”；AI Coding Agent 更适合先解决“这件事到底是什么”。
前者管理代码，后者组织意图。两种能力并不冲突，只是分别处在工作的不同位置。
我现在怎么用 Codex
前几天给一个 Flutter 页面加“失败重试”。真正花时间的不是按钮，而是边界：请求中能不能重复点击？页面销毁后任务是否取消？Token 失效怎么处理？保留旧数据时，失败状态怎么展示？
这些问题看起来不起眼，却决定了这个功能上线后会不会埋坑。
现在我的习惯是，先让 Codex 阅读相关代码，讨论实现方案，再完成第一轮修改。然后回到 IDE，断网、恢复网络、切前后台、跑测试，把各种边界条件走一遍。
修 Bug 也是一样。我不再急着全局搜索，而是把日志、复现步骤和相关代码交给 Codex，让它先收敛几个可能的方向，再逐个验证。
这种方式最大的变化，不是 AI 帮我写了多少代码，而是把散乱的信息整理成了几条可以验证的假设。
不过有一条原则一直没变：AI 可以提出假设，运行结果才是最终答案。
IDE 仍然是最后的现场
所以，我并不认为 ChatGPT Work 或 Codex 会取代 IDE。
真正到了调试、断点、Profiler、Flutter Inspector、真机运行这些环节，还是得回到 VS Code 或 Android Studio。代码最终要运行，性能最终要测，Bug 最终要复现。
很多工程上的判断，也是在连续阅读代码时慢慢形成的：一个目录是不是越来越乱，一层抽象是不是已经过度，一个命名是不是开始影响理解。这些更像经验，而不是模型能直接给出的答案。
在我看来，AI 改变的是开发的入口，而不是开发的终点。
所以下面这个问题：
五年后，当接到一个新需求时，你打开的第一个窗口，会是 IDE，还是 AI？
