我在探索 LLM 辅助编程最佳体验的道路上更进了一步。我发现，我并没有执着于寻找某一个完美的工具，而是日益将我的工作流程分散到几个不同的工具上，并通过组合使用来取长补短。
第一层：日常主力（约占 75% 的场景）
就我个人而言，LLM 辅助编程的主力仍然是（Cursor 编辑器中的）代码自动补全（tab complete）。这是因为我发现，亲自在代码的正确位置写下具体的代码块或注释，本身就是一种与 LLM 沟通“任务需求”的高带宽方式。关键在于“任务规约”的信息量（bits）：如果用自然语言沟通我的意图，信息量太大，延迟也太高；而在代码的正确位置直接展示，速度要快得多。当然，有时代码补全模型也挺烦人的，所以我经常会频繁地打开和关闭它。
第二层：局部修改
再上一层是，选中一段具体的代码，然后让 AI 对它进行某种修改。
第三层：功能模块生成
再往上一层，就是在 Cursor 侧边栏运行的 Claude Code / Codex 等工具。当我需要实现一些功能相对独立、也比较容易用提示词（prompt）描述清楚的大块功能时，就会求助于它们。这些工具非常有用，但总体体验好坏参半，有时会让人有点沮丧。我不会开启“YOLO”模式（即完全放任不管），因为它们可能会偏离轨道，做一些你根本不想要或不需要的蠢事，所以我经常按 ESC 键来中断它。此外，我还没学会如何高效地并行使用多个实例——只用一个就感觉够费劲了。我也没找到一个好方法来维护那个 CLAUDE.md 文件（用于提供上下文），让它保持良好和最新的状态。
使用这些工具生成的代码，我常常需要再过一遍进行“清理”，以符合我的编码风格或代码品味。比如：
- 它们的代码风格过于“防御性”，经常滥用
try/catch语句。 - 它们常常把抽象搞得过于复杂。
- 它们写的代码很臃肿（例如，明明一个列表推导式或单行
if-then-else就能搞定的地方，非要用嵌套的if-then-else结构）。 - 它们会重复代码块，而不是创建一个好用的辅助函数。 诸如此类……基本上，它们缺乏一种“品味感”。
尽管如此，在某些场景下它们又是不可或缺的。比如，当我涉足一个我不太熟悉、更依赖“感觉”来编程的领域时（例如最近写一些 Rust 或 SQL 命令，或其它我以前接触较少的东西），它们就帮上了大忙。我也曾试过让 Claude Code 在写代码的同时教我一些知识，但完全行不通——它只想写代码，而不是一路给你解释。我还试过让它做超参数调优，结果非常滑稽。
此外，在处理各种不那么重要、一次性使用的定制化可视化、小工具或调试代码时，它们也超级有用。如果没有它们，我是绝对不会去写这些代码的，因为太花时间了。例如，为了定位一个特定的 bug，Claude Code 可以迅速生成 1000 行一次性的大量可视化代码，找到 bug 后这些代码就会被全部删除。我们正处在一个代码“后稀缺”时代——你现在可以随心所欲地创建并删除成千上万行高度定制化、用了就扔的临时代码，这完全没问题，代码不再是过去那种珍贵而昂贵的东西了。
第四层：终极防线
我的最后一道防线是 GPT-5 Pro，我用它来解决最棘手的问题。比如，有好几次，我、Cursor 和 Claude Code 三个一起被一个 bug 卡了 10 分钟，但当我把整个问题复制粘贴给 GPT-5 Pro 后，它思考了 10 分钟，最后真的找到了一个非常微妙的 bug。它非常强大，能挖出各种冷门的文档和深奥的论文之类的东西。我也用它来处理其他更重量级的任务，例如，为如何清理抽象概念提供建议（结果好坏不一，有时会提出好点子，但并非总是如此），或者围绕“大家通常如何实现某某功能”这个主题进行一次完整的文献综述，它能返回质量很高的相关资源和参考资料。
总结
总之，在各种不同“类型”的编程任务和各具优劣的工具加持下，编程这个领域感觉完全被打开了，充满了各种可能性。这很难不让人产生一种焦虑感，担心自己没有跟上技术浪潮的最前沿。因此，就有了周日这些胡思乱想，同时也非常好奇大家都有哪些新的发现和心得。