继续优化 LLM 辅助编码体验的旅程。特别是，我发现与其专注于一个完美的东西，我的使用越来越多样化，跨越几个工作流程，我将其 "拼接" 优缺点： 就我个人而言，我的 LLM 辅助的主力（约 75%？）仍然是 (Cursor) 的 tab 补全。这是因为我发现自己在代码的正确部分编写具体的代码/注释是一种高带宽的方式来与 LLM 进行 "任务规范" 的沟通，也就是说，主要是关于任务规范的部分——用文本沟通我想要的内容需要太多的位和太多的延迟，而在代码中以正确的地方展示它更快。有时 tab 补全模型很烦人，所以我经常切换它的开关。 下一层是突出显示一段具体的代码并请求某种修改。 再上一层是 Claude Code / Codex / 等等，运行在 Cursor 的旁边，我会去使用它们来处理一些功能较大的代码块，这些代码块在提示中也相对容易指定。这些非常有帮助，但总体上仍然是混合的，有时略显沮丧。我不以 YOLO 模式运行，因为它们可能会偏离轨道，做出你不想要/需要的愚蠢事情，我经常按 ESC。我也还没有学会如何有效地使用多个实例并行——一个已经感觉够难的了。我还没有找到保持 CLAUDE[.]md 良好或最新的好方法。我经常需要进行 "清理" 的过程，以符合编码风格或代码品味的问题。例如，它们过于防御性，常常过度使用 try/catch 语句，常常过于复杂化抽象，代码过于臃肿（例如，当列表推导或一行的 if-then-else 可以工作时，使用嵌套的 if-else 结构），或者它们重复代码块而不是创建一个好的辅助函数，诸如此类……它们基本上没有品味。在我逐渐进入一个我不太熟悉的 vibe-coding 领域时，它们是不可或缺的（例如，最近写一些 rust，或者 sql 命令，或者我之前做得较少的任何其他事情）。我还尝试让 CC 在编写代码的同时教我东西，但这根本没有效果——它真的更想写代码，而不是在过程中解释任何东西。我尝试让 CC 进行超参数调优，这非常有趣。它们在所有种类的低风险一次性自定义可视化或工具或调试代码中也非常有帮助，我绝对不会自己编写这些代码，因为这会花费太长时间。例如，CC 可以快速生成 1,000 行一次性的广泛可视化/代码，仅仅是为了识别一个特定的 bug，而在我们找到它后，这些代码会被全部删除。这是代码后稀缺时代——你可以创建然后删除成千上万行超级自定义、超级短暂的代码，现在没关系，这不再是这种珍贵而昂贵的东西。 最后的防线是 GPT5 Pro，我会去处理最困难的事情。例如，我已经发生过几次，我 / Cursor / CC 都在一个 bug 上卡了 10 分钟，但当我将整个内容复制粘贴到 5 Pro 时，它会运行 10 分钟，但最终确实找到了一个非常微妙的 bug。它非常强大。它可以挖掘各种深奥的文档和论文等。我还用它处理其他更重要的任务，例如关于如何清理抽象的建议（结果混合，有时有好的想法，但并非全部），或者关于人们如何做这个或那个的整个文献综述，它会返回相关的资源/指针。 无论如何，编码感觉在多种 "类型" 的编码和许多工具的优缺点之间完全被打开了可能性。很难避免对未能处于集体可能性的前沿感到焦虑，因此随机的星期天洗澡思考和对他人发现的好奇心。