-
在代码触达用户前消灭缺陷：我在Redis向量集合实现中就验证了这点。虽然最终我都能自行修复所有bug，但Gemini/Claude的代码审查能立即消除大部分问题。
-
加速创意验证：让LLM快速编写可抛弃的测试代码，立即验证解决方案的性能表现和可行性。
-
开展结对设计：将你的直觉、经验和设计品味，与LLM内化的博士级知识相结合。虽然LLM有时会提出愚蠢方案，但也会闪现惊人洞见——你的价值就在于规避局部最优陷阱。
-
规范化的代码生成：在明确规范下让LLM完成部分代码编写。
-
跨界技术探索：比如用68000汇编编写Amiga演示程序时，可将LLM作为特定知识的外接模块。
一年半前我写过《2024年初的LLM与编程》，当时LLM已显实用价值，但这18个月的进步彻底改变了游戏规则。不过要充分发挥其效能，使用者需要具备特定素质并遵循最佳实践。
拒绝"氛围编程"
当前阶段，LLM是优秀的放大器，却是糟糕的独奏者。虽然它们能在严格监督下加速开发（我的做法是追求同等时间内产出更多/更好的代码），但面对复杂目标时，独立工作的LLM往往会产生冗余、脆弱且充满局部最优解的代码体系。日常实践让我坚信：人机协作才能实现最高质量。这需要两个关键前提：使用者必须具备出色的沟通能力，以及丰富的LLM交互经验。
提供完整上下文
当需要LLM协助实现或修复代码时，必须提供完整信息：
- 相关论文
- 目标代码库的完整上下文（尽可能全部）
- 你对解决方案的全部认知，特别要包括：
- 看似优秀实则欠佳的方案及其缺陷
- 尚未完善的优质方案雏形
- 代码必须遵守的约束条件和风格规范
选对LLM工具
编程任务应优先选用：
- Gemini 2.5 PRO：语义理解更强，擅长发现复杂缺陷
- Claude Opus 4：有时在新代码生成方面更优
关键原则：
- 始终直接使用最先进的基座模型
- 避免任何会分割上下文的RAG方案
- 保持人工控制：手动在终端与LLM界面间传递代码
未来展望
尽管自主编程代理备受关注，但目前保持"人在循环中"仍能最大化开发效能。未来当AI足够成熟时，人类将专注于决策"做什么"和"怎么做"。现阶段建议定期测试代理能力边界，但多数时候保持主导地位。另外也要警惕因意识形态拒绝使用LLM而导致的技术落后——与LLM协作所需的技能体系本身就需要时间积累。或许正如古谚所云：“中庸之道才是美德”。
请启用JavaScript查看Disqus评论。
rss订阅 | twitter | 谷歌群组 | 旧版站点：