你可能听过很多人对大语言模型(LLM)的评价:有人觉得它是开发者工作史上最具颠覆性的生产力工具,也有人认为它不过是个被过度吹捧的“小把戏”,对“严肃写码”的专业人士没多大帮助。
身为 GitHub 的资深工程师,曾直接参与 Copilot 项目开发,我自己则对 AI 有着截然不同的看法:它并非“万能钥匙”,却也绝不是鸡肋。想从它身上获益,就要**“正确使用”**。以下是我在工作中实打实用到 AI 的场景,或许能给你一些启发。
我最常做的一件事,就是在敲代码时直接开着 Copilot——它基本扮演“自动补全大王”的角色。尤其在写惯用语言(如我熟悉的 Ruby on Rails)时,Copilot 提出的建议常常就是一些模板式、重复性较高的代码块,大大节省了我手动敲那些“套路”代码的时间。
其实大部分开发者都有过这样的经历:项目要用 Golang 或 C/C++,可你更擅长的是其他语言。
这么做的最大收益:我不用耗费大量精力去读陌生语言的风格指南,就能比较快速地做出一个还过得去的实现。
当然,这里“可靠性”依然需要依赖专业人士把关,AI 只是“第一视角审稿人”。但在时间紧、又要小规模改动的场景下,这种策略非常有用。
除了写生产代码,我有时也会写各种一次性脚本或工具——比如做一些数据抓取、分析,或验证某个概念的可行性。
在这种一次性场合,LLM 基本能让我写脚本效率提升 2~4 倍——尤其是一些繁琐的解析、正则匹配、格式转换等,只要需求描述清晰,LLM 一下子就能给出大部分“底层代码”,让我少写很多“机械键盘输入”。
当我接触一个全新技术或领域(例如最近在学 Unity)时,我几乎是**“人在哪里,我就把 LLM 带到哪里”**:
我发现从 GPT-3.5 开始,我很少碰到它“胡诌”的情况(尤其学习那些已有大量材料的领域)。而且可以“随时提问+随时检查”,比传统看文档、Google 搜索更灵活更高效。对我这种热衷沉浸式学习的人来说,“LLM = 24 小时在线的个人家教”。
一般情况下,我修 bug 的经验比 AI 强,所以我不会第一时间把 bug 丢给它。然而偶尔我会遇到一个棘手、我死活没看出问题的 bug,这时我就“死马当活马医”,把相关文件和报错一并扔进 Copilot Chat,问它:“你看得出问题在哪吗?”
所以,我把它当作“平时不用、关键时刻救急”的修 bug 小助手。毕竟它“一次咨询几分钟”,对我不算浪费。
我经常要写一些内部技术文章、架构决策记录等,对此我很少让 AI 直接生成,因为我偏爱自己的行文风格,且我也不想被那种“八股文”式的回答同化。
基本上,我让 LLM 做一次审校就够了,它常给出一些风格建议,但我更重视它是否捕捉到了拼写或关键细节的纰漏。
有人说,大语言模型正颠覆程序员的工作;也有人觉得,它不过是个“过度宣传的噱头”。就我自己的感受而言,“LLM 能否帮到你”很大程度上取决于你怎么用它。
**总之,对我来说,LLM 并不意味着“所向披靡”,却足以让我在至少一半的工作内容里,效率提升至少 2~4 倍。**如果你也在“误用” LLM,不妨试试这些思路,或许会发现它的潜力还远未被你激发。