我的简易 AI 编码设置 (2026年1月)

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

我的设置

我同时使用 Codex 和 Claude Code，并根据任务在它们之间切换。
VS Code / Cursor IDE 扩展让我能够添加上下文、查看代码并快速进行调整。

我现在很少使用 Cursor Agent Mode 或 Composer。（即使使用 Opus 4.5，运行环境很重要——我在 Claude Code CLI 或扩展中得到的结果更好。）

Cursor 仍然有一些便利功能，例如浏览器编辑，这对前端工作尤其有用。

我经常同时运行两个模型，分别处理代码的不同部分或互补的任务，并让 Codex 审核 Claude 的输出并进行后续修改。

IDE 扩展！亵渎！滚开！ 😂 留在我这儿！

Codex GPT 5.2（深度思考）

Codex 不需要大量上下文、计划或复杂提示——只要提供正确的指引，它通常能一次就正确完成，但它 非常、非常慢。

我主要在需要深度思考的复杂任务中使用它：

• 复杂的 bug
• 强类型
• 高数据准确度的任务（例如转换或抓取数据而不出现幻觉）
• 代码审查
• 重构
• 解释代码库或单个代码片段

常用的后续提示

• “还有什么需要重构的吗？”
• “简化此文件。”
• “这段代码能运行，但是否存在维护、安全或架构方面的问题？”
• “这段代码能运行，但有没有更好的实现方式？请给出选项。”

Claude Code / Opus 4.5

使用 Opus 4.5 的 Claude Code 非常快速且准确。它有时比 Codex 更需要一些引导，常会向你提问或添加一个 计划。你也可以手动触发“计划模式”。我对计划模式的效果评价不一——我喜欢它，但对于已有的代码库，我更倾向于进行小范围、封装好的改动；即使没有计划，Codex 通常也表现更好。

我在大多数编码任务中使用它：

• 新功能
• 添加测试 / 类型
• 创建 React 组件
• 快速原型

常用提示

• “为一个库设计接口。”
• “基于此模式实现类似的方法。”
• “创建一个实现 X 的组件”（它会一次性完成并提供良好的用户体验）。
• “重命名此函数/文件并更新所有引用和测试。”

Claude Code 与 Codex CLI

我也安装了 CLI。传说它们拥有更强大的运行环境，并且有些功能会先在 CLI 中出现，随后才在 IDE 扩展中跟进。

• IDE 扩展提供单线程工作流：你需要不断引导模型，审查它生成的每一行代码，进行内联修改，测试并验证。只能有一个并发会话（除非你把仓库克隆到另一个文件夹并打开另一个 IDE 窗口，我有时会这么做）。
• CLI能够实现更 并行、免手动的工作（别把它和“随意编码”混淆——你仍然需要阅读、验证并确保代码符合预期）。
• 在同一代码库上并发运行 CLI 时，需要考虑冲突、分支和工作树管理。有时它们可以互不干扰，但并非总是如此。我觉得这有点麻烦，除非真的需要一次性推送大量内容，否则会避免使用。

并非所有工作类型和仓库都适合使用 CLI 并行编码。

我认为 CLI 有用的情形

• 一次性 PoC
• 迁移（见下文 Ralph Loop 编码）

oop 编码

大家都在讨论的技术……我开始尝试它，感觉它是实现免人工/并行自动化工作的终极方案。

Codex 在一次性、单提示的小规模迁移上表现出色，但对于更长、更复杂、可重复的任务（比如过去表现不佳的 “codemods”），在循环中运行 CLI 可以产生惊人的效果。

关键是让模型一次只处理 一次只处理单个任务，完成后停下来验证，然后再继续。这个 “循环” 方法可以让你将许多小而可靠的转换串联起来，而不会让模型或代码库负荷过重。

Miscellaneous / Tips and Tricks

• 关于 MCPs？
  仅在需要时使用它们（例如，前端代码使用 Chrome/Playwright，文档使用 Context7 等）。

• 关于 Cursor Rules、Agents.md、Claude.md？
  模型正在变得更擅长自行找到正确的上下文，但如果它们反复出现同样的错误，请将规则添加到相应的 .md 文件中。（有一个方便的 GitHub Action 可以在代码审查期间触发，以更新这些文件。）

• 语音模式
  我开始更多使用 Wisprflow，但我仍然喜欢打字，这样可以整理我的思路。

• 上下文窗口
  现在不必过于担心（Codex 表现非常好，Claude 具备自动压缩功能）。我建议尽可能频繁地开启新会话以重置上下文窗口——当然，前提是不丢失已有的上下文。

• 自动化重复任务
  Claude Code 支持斜杠命令和子代理，以自动化推送、提交、审查、运行测试等操作。

Caveats / Constraints – Working with Production Software

我在全新项目中使用 AI 编码的方式与在旧的/生产代码库中编码有显著差异。现代模型能够在大型仓库中有效工作，但仍有一些约束需要注意，同时对代码本身进行的改进可以显著提升速度和产出。

1. Spaghetti Code

• 大块、相互无关的代码会 膨胀上下文窗口，导致模型变慢且令牌利用率低下。
• 解决方案：
  • 减少循环依赖。
  • 将组件封装在明确的接口后面。
  • 强制执行明确的架构和模块边界。

如果你的应用程序腐烂，它也会腐烂你的上下文。

2. To Rewrite or Not Rewrite

• 当模型的上下文窗口被填满时，它会采用 “上下文压缩”。
• 同样的原理适用于遗留代码库：一旦技术债务和过时的决策累积，捕获意图、总结当前状态并重新开始（通常称为重写）可能更高效。

现在重写东西从未如此便宜！

3. Missing Verification Loop

• 不能自行验证输出的模型需要 更多的引导，且无法持续工作。
• 人工验证必须 提交并保存（例如通过测试、lint 规则、类型检查或代理上下文）以供后续更改使用。
• 模型擅长 生成测试，但它们 不能取代真实的验证——即人类判断系统是 正确 的过程。

4. Testing Chicken‑and‑Egg Paradox

• 非模块化代码难以测试。
• 缺少测试会破坏验证循环，导致代码难以更改和测试。
• 解决方案：
  1. 编写经人工验证的测试并提交。
  2. 关闭验证循环，使新代码和改进能够安全地由人类和编码代理共同添加。

5. Code Is Not the Bottleneck Anymore – Verification Is!

“如果你的 Pull Request 没有提供它能工作的证据，你并没有更快地交付——你只是把工作向下游转移。” – Addy Osmani

• 代理可以快速生成可靠代码，但 确保正确性 现在成为瓶颈。
• 主要罪魁祸首：
  • 手动代码审查。
  • 手动测试。
  • 运行缓慢的自动化测试套件。

加速这些环节（例如并行化测试、使用更快的 CI 流水线或改进审查工具）将提升将代码交付到生产的速度。

6. The Kitchen‑Sink Paradox

• 模型的行为类似人类：如果看到脏水槽，它们只会在上面再放一个盘子。
• 除非明确指示，否则它们不会重构或改进代码。
• 每当你进行更改时，也请模型 对该部分代码进行改进——尤其是围绕验证（测试、类型注解、lint 规则等）的改进。

7. Risk of Change Is a Limiting Factor

• 代码现在已经很便宜；我们应该更多实验，而不是因为代码“老旧”或复杂就回避重大更改。
• 大规模更改的主要障碍是 回归风险。
• 紧密的验证循环（全面的测试、静态分析、持续集成）是降低该风险的关键。

即使拥有优秀的测试实践（这很少见），代码量和更改越多，错误和风险也会随之增加——企业需要接受并管理这种风险。

生产就绪的 AI 辅助开发快速检查清单

通过解决这些约束并采用上述检查清单，您将使生产代码库的 AI 辅助开发更快、更安全、更易维护。

结论

你并不落后——保持简单，勇敢尝试，并且每天进步。当这句话出自 Sunil 时听起来更好：

“你并不落后，保持简单，勇敢尝试并每天进步…”

推荐阅读

• Boris Claude Code Setup
• Where Good Ideas Come From for Coding Agents
• Just Talk To It – The No‑BS Way of Agentic Engineering
• How to Ralph
• AI Writes Code Faster. Your Job Is Still to Prove It Works