1. Codex App
1.1 Codex App 介绍
Codex App 可以理解为一个面向开发场景的 AI 工作台，它把对话、上下文管理、工具调用、文件修改和执行记录放到了同一个界面里。相比只在终端里交互，它更适合处理需要连续推进、反复校验和多轮协作的开发任务。
如果从 Codex CLI 过渡到 Codex App，最直观的变化不是“能力变了”，而是任务组织方式变了。以前很多动作要自己在终端里切目录、拼命令、回看输出；现在可以在一个界面里连续完成提需求、查看上下文、执行操作、修改文件和追踪结果，整体效率更高。
1.2 Codex App 的核心能力
- 多线程：可以同时开多个线程处理不同问题，不互相打断。同一项目可以按任务阶段开不同会话，便于回溯和对比。
- 多项目：在不同仓库间切换更直观，适合并行跟进多个任务。多项目并行时不容易弄乱当前工作状态。
- 技能（Skills）：可按技术栈加载约束，让输出更贴近团队规范。
- 工具调用能力：在界面里直接完成查文档、搜索、页面调试、命令执行等动作。
- 结果沉淀：会话过程和产出都可复用，后续复盘更方便。
1.3 Codex App 的主要优点
- 可视化更友好：会话、上下文、文件改动、执行过程都更容易追踪。
- 更强的任务编排能力：支持先用
/plan做规划、拆解任务，并处理长时间运行任务。 - 上下文管理直观：可以方便看到 context 剩余量，及时调整提问和拆分任务。
- 性能 &资源隔离更好：独立进程、不拖慢编辑器、大项目更流畅
1.4 与 Codex CLI、Codex VSCode 插件的区别
| 对比项 | Codex App | Codex CLI | Codex VSCode 插件 |
|---|---|---|---|
| 交互形式 | 可视化会话 + 工具面板 | 纯命令行交互 | 编辑器内联交互 |
| 任务组织 | 线程/会话结构清晰 | 主要靠命令历史和目录管理 | 贴着代码文件操作 |
| 并行处理体验 | 多线程、多会话更直观 | 需要手动管理多个终端上下文 | 适合围绕当前工程文件推进 |
这三种方式本质不是替代关系，更多是使用习惯交互差异。 如果已经有 CLI 经验，过渡到 App 通常会明显感觉到操作成本下降、上下文管理更轻松。
2. MCP 分享
2.1 MCP 的价值
MCP 可以理解为模型调用外部能力的一套标准接口。有了 MCP，AI 不再只是基于已有知识回答问题，而是可以按需去查资料、操作工具、获取现场信息，再把结果带回当前任务里。
对开发场景来说，MCP 的价值不在于“多了几个工具”，而在于让 AI 的输出更接近真实工作流。很多问题不是靠记忆就能解决的，而是需要查最新文档、看网页信息、复现页面行为或验证执行结果，MCP 正好把这些动作接到了模型能力上。
2.2 Context7：文档检索能力
Context7 主要用于查询技术文档和 API 用法，适合拿来补充模型记忆之外的细节信息。对于框架升级、接口变化、配置项差异、最佳实践确认这类问题，它比单纯依赖模型记忆更稳。
在实际使用里，我更把它当作“文档校对器”。当我们需要确认某个参数怎么写、某个版本行为有没有变化、某个能力官方推荐怎么用时，让 AI 先去查文档，再回来组织答案，结论通常会更准确，也更容易追溯来源。
- 适合场景：框架升级、接口变化、最佳实践确认
- 主要价值：减少凭记忆回答，降低信息过期带来的风险
2.3 Exa：网页搜索与信息获取
Exa 更适合处理时效性强、公开信息分散的问题，比如版本变更、方案对比、社区资料补充、某个工具近期能力更新等。它的作用不是替代文档，而是帮助 AI 快速找到新的外部信息并做初步筛选。
当问题已经超出“官方文档怎么写”这个范围，比如想了解近期生态变化、不同方案怎么比较、网上有没有现成经验时，Exa 会比只靠本地知识更有效。它比较适合拿来做信息补充和外围调研。
- 适合场景：版本变更、方案对比、资料补充
- 主要价值：遇到时效性问题时，信息更新更及时
2.4 Chrome DevTools：浏览器侧操作与排查
Chrome DevTools 这一类浏览器侧工具，适合处理前端页面中的“现场问题”。它可以帮助 AI 直接操作页面、定位元素、查看 Console 和 Network 信息，把原本只能靠口头描述的问题变成可以复现、可以观察、可以验证的问题。
这一点在前端排查里很有价值。很多问题如果只有一句“这里点了没反应”或者“这个请求不对”，信息其实是不够的；但如果 AI 能直接看到页面结构、控制台报错和网络请求，它给出的定位和修改建议通常会更具体，也更容易闭环验证。
- 适合场景：前端问题复现、定位和验证
- 主要价值：把口头描述的问题变成可复现、可验证的问题
3. 项目中的应用
在实际项目中，我更倾向于把 Codex 当作一个“协作式开发流程工具”，而不只是一个代码补全工具。比较稳定的用法是：先用 plan 把需求和边界讲清楚，再按计划分阶段推进编码与验收；当 Context 不足时，及时沉淀阶段性结果，通过新线程继续执行。
3.1 输入需求，生成 plan
这一步的目标不是让 AI 立刻写代码，而是先把需求、范围、约束和交付物讲清楚，避免一开始就偏题。需求描述越完整，生成出来的计划越可执行，后续返工也越少。
我的做法是尽量一次性说明业务目标、涉及模块、边界条件、是否需要兼容旧逻辑，以及希望的输出形式。这样 AI 生成的 plan 通常会包含任务拆解、风险点和阶段性步骤，适合作为后续执行依据。
- 需求尽量包含背景、目标、范围、限制和验收标准
- 明确是要方案、开发计划，还是直接进入编码
- 先 Review
plan，再决定是否开始 Coding
3.2 Review plan，补需求和纠偏
plan 生成后不要直接执行，而是把它当作第一轮需求评审。这个阶段主要看任务拆解是否完整、依赖关系是否合理、有没有遗漏关键边界，尤其要关注是否误解了业务意图。
如果发现缺项，可以直接让 AI 补充到开发计划中；如果发现方向有偏差，也要先纠偏再继续。比起写完再返工，在 plan 阶段修正成本最低。
- 看是否覆盖核心流程、异常分支和验收方式
- 有遗漏就补充，有偏差就立即调整
- 计划通过后，再进入 Coding 阶段
3.3 按 plan 编码并分阶段验收
进入编码后，不建议一次把所有任务跑到底，而是按 plan 分阶段推进。每完成一个阶段，都要让 AI 或人工一起 Review 当前改动，并验证输出是否符合预期，这样更容易及时发现偏差。
如果任务比较大，可以要求 AI 先完成一个子目标，例如先改接口层、先补测试、或先完成页面骨架。把大任务拆成多个可验证的小阶段，整体成功率会更高。
- 不要追求一轮完成全部开发
- 每个阶段结束后都做 Review 和效果验证
- 尽量让每轮输出都可运行、可检查、可回退
3.4 Context 低时沉淀 todo
当 Context 余量过低时，模型通常会压缩上下文，导致前文信息丢失、执行稳定性下降。这时候不建议继续强推，否则很容易出现重复实现、遗漏细节或和前文不一致的问题。
更稳妥的做法是先暂停当前线程，让 AI 根据已有的 plan、已完成代码和当前进度生成一个 todo.md，把“完成了什么、剩下什么、下一步做什么”整理出来，为下一个线程接续做好准备。
- Context 过低时，输出质量通常会下降
- 不要强行在同一线程继续写
- 先沉淀
plan、进度和todo.md，再切到新线程继续
3.5 新线程接续执行
新线程不是简单重开一次对话，而是要把上一个阶段的关键信息有组织地带过去。这样做的重点是减少上下文恢复成本，让 AI 能尽快进入有效执行状态。
通常我会把原始需求、开发 plan、todo.md、已完成内容和当前卡点一起提供给新线程。这样新线程更容易理解当前进度，直接从未完成部分接着做，而不是重复分析一遍。
- 新线程需要读取需求、
plan和todo.md - 明确说明哪些已经完成，哪些还没完成
- 如果有风险点或卡点，也要一并带上
- 补充信息和调整点要同步更新
plan和todo.md
4. CC Switch 的使用
4.1 CC Switch 的定位
CC Switch 就是一个专为 AI 编程 CLI 工具打造的「配置管家」，特别适合频繁切换供应商和多工具并用的开发者
4.2 CC Switch 的主要功能
- 方便进行 AI 工具配置初始化 一键导入和管理多个 AI 编码工具（Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等）的 API Key、Base URL 和模型设置，通过图形界面快速完成初始化，无需手动编辑 JSON、TOML 或 .env 文件。
- 便捷切换不同供应商 支持保存多套供应商配置（包括 Anthropic、OpenAI、Gemini 等 50+ 预设），点击即可一键切换，无需重启终端或修改配置文件，极大提升多模型切换效率。
- 便捷给多 AI 配置 MCP 可视化管理 MCP（Model Control Plane）服务器配置，支持统一添加、编辑和同步到多个 AI 工具。
