WeMakeDevs创始人Kunal Kushwaha：AI承担更多实现工作时，建议工程师本地运行大模型以加深技术理解

如果你问一个开发者关于他的工作流，他能告诉你最新模型快了多少、编码代理现在能处理什么、哪个新工具改善了工作方式。WeMakeDevs创始人Kunal Kushwaha有一个追问：那你自己呢？

Kushwaha的回答从仍然属于工程师的工作开始。他认为，无论使用什么工具，工程师需要足够理解问题来选择方案并解释决策背后的理由；他们仍然对交付的成果负责。当AI承担越来越多实现工作后，这种判断力从何而来？他还提出了一个实践方向：学习在本地运行大语言模型。

这个练习的目的不是替代API调用，而是暴露接口背后的基础设施。Kushwaha说，在本地运行一个模型，然后探索微调以及大规模运行需要什么，能让工程师接触到模型如何运行、各组件如何通信、部署涉及哪些选择。他将其类比为学习Kubernetes：一个工程师可以在生产环境使用托管服务，但仍然从自己搭建和运维过小集群的经历中获益——那种经历帮助他们理解托管服务在替他们做什么。同样的原则适用于团队选择如何部署模型：API、自有硬件和托管平台各有不同的权衡，亲手完成一次本地搭建能提供更多上下文来提出更好的问题。

为什么基础仍然重要？Kushwaha的说法很直接：你学会了如何逃离炒作周期。理解底层让你更容易问出一个工具实际改变了什么、帮助了系统的哪一部分、局限在哪里。没有这种根基，很容易把更好的演示误认为眼前问题的更好解决方案。他并不认为工程师需要知道所有事情——他自己深入使用Kubernetes，仍然会遇到不熟悉的Kubernetes、Linux和网络细节。动手经验提供的是调查未知和做出知情决策的足够上下文。

在代码审查的自动化程度上，Kushwaha与访谈者存在分歧。他预计代理会处理越来越多的审查工作，人类最终可能完全停止审查代码；但他同时认为风险程度应决定对变更的注意力——如果代理在大型促销期间产出一个修复，他仍然希望有人检查。双方一致的底线是：责任不转移给代理。如果出了问题，负责的是你。

需要指出的是，这些建议来自一位从业者的个人经验和类比推理，并非经过系统验证的最优路径。本地运行大语言模型需要相应的硬件和时间投入；当AI工具快速迭代时，个人技能积累能否跟上结构性变化的速度，是这场对话没有回答的问题。