近来有着和数位从事后端工作的工程师展开交流, 从中发觉了一种饶有趣味的情形, 那便是, 他们当下进行代码编写的方式, 跟两年之前是全然不一样的了。成了日常的, 并非“用不用AI”的问题, 而是“怎么跟AI合作”的, 这样一个问题。从写代码到审代码有一位身为同事的人, 做了五年Java开发, 他跟我讲述, 如今他每一天的工作具体过程情形大体是这样子的:首先让AI去生成一个基础的版本, 接着他耗费大部分的时间用来查看代码, 对逻辑进行修改, 对边界条件加以修正。他声称自己此刻感觉好似一个“代码编辑”, 而非“代码作者”。这话听起来略微有些刺耳, 然而细细去思量, 这实际上并非是降级, 而是分工发生了改变。AI所擅长的究竟是什么呢? 是能够迅速生成那种符合语法要求、结构合理的代码骨架。它并不理解业务, 不明白你们公司所具有的历史债务情况, 也不清楚为何这个接口要如此进行设计, 然而它却能够在一秒钟之内为你提供十种实现方案。人类所擅长的是什么呢? 是去判断哪一种方案是真正能够行得通的, 是明确哪些地方是会掉入陷阱的, 是知晓哪些代码在三个月之后会致使团队整体遭受严重挫折而崩溃的。问题在于这个转变来得太快了。没人教过你审AI代码的能力学校进行编程教学, 教授的是有关“怎么写”的内容, 如今却忽然转变为“怎么审”, 然而却没有人曾教导过你这一套新的技能。有不少开发者这样, 我是见过的, 他们把AI生成的代码拿到手, 跑通之后就上线了, 结果会存在什么情况呢?这不是AI的错是人的问题。倘若你将AI视作当作“写代码的工具”, 那你的确会被它给坑害。然而要是你把它看成“一个水平尚可但时常犯下低级错误的实习生”, 你便晓得该去做什么了——你需要, 需要test, 需要询问“为何这般编写”。被忽略的现实AI代码的质量在下降这里讲出一个并非那么让人感觉舒适的事实, 那就是, 伴随AI模型日益变得“聪明”起来, 它所生成的代码质量, 反倒呈现出下降的态势。为什么当下的模型训练数据之中, 存在着数量巨大的AI生成代码, AI依托这些代码展开学习, 进而生成更多带有AI风格的代码, 这构成了一个正反馈循环, 只是其方向出现偏差。人类所撰写的代码是存在着“意图”的, 具体表现为, 为何要如此进行设计, 为何要选用这个数据结构, 为何要在这个特定的地方添加注释。而AI所编写的代码唯独只有“模式”, 原因在于, 它曾见识过与之相似的代码, 故而它进行模仿。当你促使AI去生成一个微服务架构时, 它会给到你一系列看起来颇具专业性的代码, 呈现出K8s配置, 还有API网关以及日志收集等内容, 这些全都具备。然则这些东西到底真的适用于你的业务状况吗, 抑或是仅仅由于它在训练数据当中曾经见到过呢?这便是为何审代码的能力相较于写代码更为重要之地。你必须能够做出判断: 这一套架构究竟是切实所需的, 还是AI仅仅在展示自身能力而已。真正的分水岭现在行业里开始出现两种开发者先来说第一种情况, 完全寄希望于AI, 所写的提示词花哨繁杂, 然而自身却对底层逻辑一窍不通。一旦AI出现报错, 就会陷入茫然不知所措的状态, 仅仅只能更换一个提示词再次尝试。就是这类人, AI越是具备超高的智能, 他们面临的风险就越大。第二种, 自身知晓技术, 借助AI来使流程加速。对于AI产出的代码, 其不会盲目相信, 会去询问“彼时的时间复杂度是多少”, 会发出疑问“并发安全与否呢”, 同时会有所询问“是否有着更为优良的设计”。就是这样的人, AI越是智能化聪慧, 此人便越是强大有力。一个区分界限并非在于你是否能够去运用人工智能, 而是在于你有没有那种评判人工智能输出品质程度的本事。以下是针对开发者的三条建议, 千万别把AI当作黑盒: AI所生成的每一行代码, 你个个都必须可以解释清楚这么写背后的缘由。要是解释不清晰, 那就千万别上线使用。进行测试相比较于代码尤为重要: 以前或许你编写100行的代码配上10行的测试。当今AI帮你撰写了1000行代码, 你就理所应当配备200行测试。可不是可有可无的选择, 是绝对必需的状况。得维持依靠手写代码的能力: 每周保证起码创作出一段不借助AI的代码。并非是出于念旧之情, 而是为了保有你对代码的直觉反应。最后说出这么一句。程序员不会被AI取代, 然而, 那些单单只是会写代码, 却一丁点儿都不懂得思考的程序员, 会被AI取代。