★ FEATURED ARTICLE 这两年我身边讨论最多的一个词不是某个新的框架也不是某种语言而是“重构”。大模型走向成熟之后“AI 时代的计算机科学”从一个宣传口号变成了一连串实实在在的变化课程在改研究在改生产工具在改连岗位定义也在改。这篇文章想结合我自己这几年在一线的观察和实操把这轮重构拆开来看重构到底动的是什么哪些东西会留下哪些东西会变成新的形态以及作为学生、工程师和研究者分别应该怎么应对。先说一个我最近的直观感受。以前带新人最花时间的是教他们写代码教他们查文档教他们调 bug。现在完全反过来了代码生成变得极其廉价新人遇到的问题变成了三件新的事第一不知道自己要什么第二不知道怎么把模糊的想法变成一个能被模型理解的任务第三不知道怎么验证模型给出的答案是对的。这其实就是计算机科学正在被重构的缩影。过去我们的核心劳动是“生产代码”现在核心劳动变成了“定义问题、组织上下文、验证结果”。这件事实在太大了值得慢慢拆。1. 为什么是“大重构”而不是“小改进”1.1 工具层的变化触动了生产关系的核心如果只看表面AI 技术对计算机科学的改变好像只是多了一个“自动补全工具”。很多年前我们用 IDE 的自动补全后来用代码片段生成器现在用大模型好像只是效率高了一点。但如果你细看劳动结构会发现这根本不是量变而是质变。传统分工是这样的人来定义问题人来写代码机器负责执行。学校训练的是“人写代码”这个环节工业界评估的也是“人写代码”的速度和质量。而现在划分变成了人负责定义问题模型负责生成代码人负责审查、验证、集成。写代码这个环节正在从“生产活动”变成“审核活动”。这有点像印刷术出现之后抄写员的工作从“抄写”变成了“编辑校对”表面上还是和文本打交道但核心技能完全变了。我接触过一个模拟项目 X开发团队只有三个人要做一个跨平台的数据采集小工具。按照以前的节奏三个人至少要分前端、后端、数据处理三条线光搭框架就得一周。结果他们用了 AI 辅助开发的流式工作流第一天就把全部技术方案讨论完第二天生成原型第三天开始做边界处理和异常恢复。一周之后整个系统的雏形已经能跑了。这个过程中写代码的时间大幅缩减真正的时间花在了需求确认、接口设计、测试方案的讨论上。这就是“重构”为什么用“大”字它不是换一个工具而是把整个计算机科学领域里人的核心技能栈、工作习惯、协作方式都重排了一遍。1.2 三个层面同时发生迁移我更愿意把这轮重构分成三个层面来看教育层、研究层、工程层。教育层重构的是“人怎么学会计算机科学”研究层重构的是“计算机科学怎么产出新知识”工程层重构的是“计算机科学怎么变成可运行、可靠、可维护的系统”。三个层面不是独立的而是互相传导的。教育层的变化最先体现在课程设计上。以前人工智能是计算机科学里的一个分支现在它已经变成很多课程的基础设施。数据结构课开始讨论如何用大模型辅助生成排序代码操作系统课开始讲怎么评估模型生成代码的并发安全性软件工程课更是整个体系都在重写因为传统的瀑布模型、敏捷开发流程在 AI 辅助编码面前显得笨重。研究层的变化也很明显。我熟悉的某个实验室原来主要做程序分析团队成员每天跟静态分析工具、符号执行引擎打交道。现在他们一半的时间在训练和调用大模型用来做自动的 bug 检测、代码修复、测试生成。这些方向以前都被认为是“工具链里的冷门方向”现在突然变成了热门因为模型生成代码的量太大了必须有更好的办法来验证它们。工程层的变化是最直接的。代码助手已经进入几乎所有开发者的日常。真正有意思的是工程层的重构并不只是“写代码变得更快”而是整个研发流程都要重新设计。从需求拆解、方案设计、编码、测试到代码评审、上线监控、故障复盘每个环节都在被 AI 改造。这就逼着每个团队去思考哪些环节应该让模型做哪些环节必须由人来把握。2. 计算机科学教育正在重构2.1 课程体系AI 从“分支”变成了“底色”我观察到的第一个变化是计算机科学课程体系正在把 AI 从一个“高年级选修方向”变成“贯穿各个方向的底色”。以前想学 AI通常是大三之后的事情要先补数学、补编程基础再进入机器学习的专业课。现在很多高校在入门课里就让同学用大模型做小项目然后反推回来学数据结构、学算法。这里有一个争议到底是先学基础还是先用 AI。我的看法是学习路径可以调整但是基础内容的分量不能减。比如模型可以帮你生成一个排序的代码但是你要判断它在处理一亿条数据时会不会崩必须理解时间复杂度和内存布局。模型可以帮你写出一个并发程序但是你要保证它没有数据竞争必须理解操作系统里的线程调度和锁机制。模型可以帮你搭一个推荐系统但是你要理解数据分布对模型效果的影响必须学概率统计和机器学习基础。我认识的一位 A 同学零基础转行做开发他用 AI 辅助的方式学了三个月能做出非常漂亮的网页和脚本。但是一到面试被人问“这个模块如果每天要被调用一百万次你会怎么设计存储结构”他就卡住了。原因很简单因为他没有系统学过数据结构。反向验证模型答案、评估方案优劣都需要底层知识做支撑。所以教育重构的核心不是“把基础课取消”而是“把基础课从背诵型考试改成应用型实践”。未来的课程可能需要做到数据结构课的第一天就让同学用 AI 生成一种数据结构然后让同学去改造它、测试它、分析它的性能。基础还是那些基础但是学习方式和评价方式完全变了。2.2 作业、考核与诚信规则的改变另一个很现实的节点是作业和考试。过去几年几乎所有老师都在头疼学生用 AI 写作业。很多学校的第一反应是禁止但禁止显然不现实。我了解到某高校的新做法挺有意思允许使用 AI 辅助但要求学生完整记录与 AI 的对话过程并且考核的重心转移到了三个新能力上。第一个能力是“质疑”。当 AI 给出一个答案时学生能不能发现其中的错误。第二个能力是“改进”。发现错误之后学生能不能通过补充约束条件、换一种提问方式让模型生成更好的方案。第三个能力是“反思”。最终提交的方案里哪一部分是模型生成的哪一部分是人自己改的修改理由是什么。这种情况下作业题目本身也在变化。以前可能会出“写一个函数完成某某功能”现在可能会出“给定一个不完整的系统描述请先将其拆解成独立子系统再用 AI 辅助完成实现最后说明验证策略”。单纯靠 AI 生成一段代码交差是不行的因为老师考察的恰恰是你和 AI 协作过程中的决策质量。我自己带过一个小项目用了类似的规则参与者必须保留 AI 对话记录并在代码评审时讲清楚每一段关键代码的来源。结果很有意思一半的人只能在记录里展示“我问 AI它回答我粘贴”另一半人会展示“它第一次给错了边界条件我指出来它修正了”。同样是使用 AI后者学到的东西是完全不一样的。这也印证了考核方式的价值工具相同思维不同结果天差地别。2.3 自学路径的迁移从“语法先行”到“任务驱动”教育重构还体现在非科班自学者的路径变化上。以前自学计算机科学几乎只有一条被反复验证的路线先学一门语言再学数据结构再刷题再做项目。这个路线的问题是周期太长很多人学到一半就放弃了。现在有了大模型出现了一条新的学习路径任务驱动型学习。你想做一个工具直接让 AI 帮你搭轮廓然后哪里不会补哪里。这条路径的好处是即时反馈强能让人快速进入“做东西”的状态。坏处也很明显容易变成“只会复制粘贴不懂原理”。我在实践中看到能走通这条路的人都有一个共同习惯他们不会把 AI 当成最终的答案而是当成一个快速生成“待检查的草稿”的队友。每次拿到 AI 的代码他们会自己问一句“这段代码为什么这么写如果不这么写会出什么问题”然后针对回答里的术语再去学基础。所以我给零基础朋友的建议是AI 可以当你的私人助教但不要把它当搜索引擎用。遇到一个不懂的概念不是让它直接给解释就完事而是让它给你一个可以运行的最小例子然后你亲手改几个参数观察行为变化。这种“交互式学习法”比单纯看书效率高很多也比单纯抄代码扎实得多。3. 研究范式与工具链的重构3.1 “AI for CS”与“CS for AI”的双向流动计算机科学领域的研究正在发生两个方向的重构。第一个方向叫“AI for CS”就是拿 AI 去解决计算机科学自身的问题。比如自动程序合成、自动 bug 定位、自动测试用例生成、形式化验证辅助这些方向在 AI 的加持下突然从实验室走了出来。以前这些技术只能处理很小的例子现在借助大模型的模式识别能力可以在真实项目的代码库上跑出有实用价值的结果。第二个方向叫“CS for AI”也就是把系统能力带到 AI 领域。大模型要真正落地必须有训练框架、推理优化、分布式调度、数据管理、评估体系。这些恰好是计算机科学里最经典的方向操作系统、网络、数据库、高性能计算全都有用武之地。前几年大家觉得系统方向有点“古典”现在它成了 AI 落地的刚需。我所在的某团队之前接到过一个很具体的需求一个图像处理 Demo 要布置到边缘设备上模型参数不大但是推理延迟一直压不下来。做算法的人建议换更大的模型做系统的人却花了三天时间把量化、算子融合、内存复用做了一遍延迟直接降了一个数量级。这就是“CS for AI”的典型价值。同样一个模型系统能力不同格局完全不同。这两个方向不是对立的而是会在同一个项目里交汇。比如用大模型生成一个分布式数据处理的配置然后再用分布式系统知识去验证它。AI 负责生成可能性系统知识负责收敛可靠性。这种双向流动会让研究人员的技能栈变得更宽懂算法的人要懂系统懂系统的人也要会跟模型打交道。3.2 核心能力从“生成”转向“验证”这里我想重点聊一个被很多人忽略的变化当 AI 能大批量生成代码、配置、模型结构之后整个领域的关键瓶颈不再是“能不能生成”而是“能不能验证”。生成一个函数很容易但你敢不敢直接用到生产环境生成一个 Pull Request 很容易但你能不能保证它没有破坏原有的边界条件生成一个训练配置很容易但它在大规模集群上跑起来会不会内存溢出、通信开销会不会高到不可接受这些问题传统的“人肉 review 代码”已经应付不来了因为 AI 生成代码的速度太快量太大了。必须要用自动化手段来做验证。这就是为什么类型系统、静态分析、形式化方法、模糊测试、自动测试生成这些原本偏冷门的方向重新被重视。我甚至认为未来计算机科学教育的核心内容之一会是“如何验证未知来源的代码”。不管这代码是人写的还是模型生成的都不重要重要的是你能不能说清楚它在什么条件下是正确、安全、高效的。很多项目对“测试覆盖率高”有一种盲目崇拜但我更推荐把验证理解为一个分层的漏斗。第一层是编译器和静态检查解决语法和类型层面的低级错误第二层是单元测试和集成测试解决逻辑错第三层是代码评审和架构审查解决设计层面的问题第四层是灰度发布和监控解决真实环境里的未知问题。AI 可以帮你快速生成第一层和第二层的材料但是第三层和第四层目前还是人的主导范围。3.3 团队分工的边界正在模糊研究团队的内部结构也在重构。以前一个研究项目通常分得很清楚有人负责想问题有人负责写代码有人负责跑实验有人负责写论文。现在这个边界在模糊。因为 AI 把实现层面的入门门槛降低了一个能清晰描述问题的人不再需要等工程师排期自己就能借助 AI 做出第一版实验。但这也带来了一个副作用团队里“会定义问题”和“会验证结果”的人话语权越来越大。只会执行编码任务的人如果不懂业务、不懂数据、不懂系统很容易被工具替代。相反能想清楚“为什么要做这个实验”“指标怎么设计”“结果怎么解释”的人在 AI 时代反而是稀缺的。我在学校给一些研究生小组做答辩模拟的时候明显感觉到评委关心的东西变了。以前他们会追问“这个算法创新点是什么”现在他们更常问“这个数据是怎么来的”“性能指标是怎么测的”“有没有考虑过模型生成方案的偏差”。这其实就是研究范式的信号数据、验证、可复现正在成为新的核心竞争力。4. 工程实践中的重构代码助手不是终点4.1 代码助手到底能干什么不能干什么作为工程一线的使用者我来聊聊代码助手给我的真实感受。在最熟悉的 CRUD 业务里它的表现确实很稳。你给它一个清晰的需求描述再给它表结构它生成的增删改查接口基本可以直接用。我实测下来简单业务场景的采纳率可以到六成以上时间至少省下一半。但一旦进入复杂场景它就没那么靠谱了。比如跨模块的重构牵涉到十几个文件、多次调用链、状态共享模型会经常“一本正经地胡说”甚至给出看起来很合理、实际上完全跑不通的方案。再比如性能优化模型能从语法层面给出优化建议但无法理解你整个系统的容量规划、瓶颈位置和使用场景。也就是说代码助手擅长的是“单点任务的快速实现”不擅长的是“全局信息的综合权衡”。另一个容易被忽视的问题是 AI 生成代码带来的供应链风险。开发者可能会从 AI 生成的代码片段里引入依赖包但这些包是否安全维护代码里有没有隐藏的漏洞人很容易忽略。我在某公司的朋友就遇到过开发者从模型生成的建议里装了一个小工具库结果那个库已经很久没有维护里面有一个已知的路径穿越漏洞。类似的问题在传统开发里也可能出现但 AI 把这种风险放大了因为它让引入代码变得几乎无感。4.2 新的工作流应该怎么设计我尝试过好几套 AI 辅助开发的工作流最后稳定下来的一套是这样的。第一步用自然语言写清楚需求背景、约束条件和验收标准。第二步让 AI 生成一个粗粒度的技术方案人对方案做取舍去掉明显不靠谱的部分。第三步再让 AI 按选定方案生成实现代码。第四步自动生成单元测试和集成测试。第五步代码评审和人工走查。第六步灰度上线加监控。跟传统流程相比最大的变化是“先方案后代码”这一步被强化了。以前很多开发者习惯拿到需求直接开写代码写完再补文档。现在 AI 的成本低反而应该把时间花在方案的推敲上。因为方案错了AI 生成的代码越多后期返工成本越高。这就像你用复印机原稿不清楚你印得越多废纸越多。我也整理过一个粗略的时间对比。同样一个中等复杂度的业务模块传统方式大概需要十个工作日需求理解一天方案设计一天编码五天测试两天评审和修复一天。用 AI 辅助的工作流编码阶段可以压缩到一天半需求理解因为要组织 prompt、澄清边界反而变成两天。总时间大约五个工作日最明显的变化是“写代码时间”占比从五成降到三成“需求与验证”占比大幅上升。很多团队如果不重新设计流程只是单纯让每个人用代码助手是得不到这种效率提升的因为前端需求不清晰、后端验证没跟上中间那段编码层的加速会被大量返工吞掉。4.3 被重塑的岗位与技能工程岗位的重构是所有人最关心的话题。我尽量客观地讲一下自己的观察。最受冲击的是那些以“按部就班写重复代码”为核心工作内容的岗位比如简单的业务接口开发、简单脚本维护。这部分工作在 AI 的帮助下一个人完全可以干完以前两三个人的活岗位需求自然会缩水。活得更好的是几类人。第一类是架构师因为他们负责的恰恰是 AI 最难替代的部分全局技术选型、系统边界划分、长期演进的权衡。第二类是可靠性工程师当代码量高速膨胀线上稳定性和故障排查能力会变得至关重要。第三类是数据工程师和机器学习工程师因为 AI 是数据驱动的对数据的理解、清洗、治理能力需求会持续增加。所以我的结论不是什么“程序员要完蛋了”而是“只会写代码的程序员要完蛋了”。代码变成了一种表达能力就像今天的英语一样是基础技能而不是核心竞争力。上层建筑变成了问题定义能力、系统设计能力、结果验证能力、沟通协作能力。这些东西恰恰是计算机科学一直强调的科学素养只是被过去“低水平代码重复”掩盖了很久。5. 给现在学生和从业者的几条实操建议5.1 守住底层能力别被模型代偿如果你现在还在学校或者刚工作不久我的第一条建议可能有点反直觉少一点时间研究各种提示词技巧多一点时间把底层能力打牢。因为工具会快速迭代但底层知识的半衰期要长得多。所谓底层能力我指的是数据结构与算法的分析和复杂度意识操作系统和网络的资源管理观念数据库的事务与索引原理以及基本的概率统计和线性代数。这些知识未必每天直接写出来但是它们决定了你面对一个陌生系统时的“感觉”。有这种感觉的人看 AI 生成的代码能凭直觉判断哪里可能有问题没有这种感觉的人只能被模型牵着走出了问题也不知道从哪里查。很多朋友会问底层能力那么多时间不够怎么办。我的建议是抓住两条主线一条是“数据是怎么流动的”从内存到硬盘、从进程到网络、从数据库到缓存另一条是“计算是怎么组织的”从单机到集群、从同步到异步、从批处理到流处理。抓住这两条主线去学效率非常高。5.2 把“问问题”当成一门必修课AI 时代最值钱的能力其实是提问能力。同一个模型你问“帮我写一个订单模块”和问“在一个每日百万订单的电商系统中订单模块要支持取消、超时关单、售后拆分数据库用 MySQL请给出表结构设计和状态机定义重点考虑极端并发场景”得到的结果质量天差地别。前者只描述了功能后者把背景、约束、边界都交代清楚了。我自己的一个习惯是在向模型提问之前先把任务拆成一个清单输入是什么输出是什么有哪些限制条件成功和失败的标准分别是什么优先级排序是怎样的。你把这个清单写好了再丢给模型即使模型第一次结果不理想你也可以针对单个环节追问修正而不是整段推翻重来。这本质上是一个把模糊需求结构化、可验证化的过程恰恰是传统计算机科学里“抽象与分解”能力的现代版本。下面是一个我常用来生成小工具的提示词模板仅供参考你可以根据自己的需求继续加重上下文目标写一个命令行待办事项管理工具 使用语言Python 功能要求 - 支持添加、完成、删除、列出待办事项 - 支持数据持久化到本地 JSON 文件 - 支持按优先级过滤 约束条件 - 不使用外部框架只用 Python 标准库 - 命令行参数风格参考常见的 POSIX 工具 验收标准 - 添加后退出程序再次启动列表不丢失 - 并发打开两个进程操作同一文件时不出现数据损坏 请先给整体模块划分再逐模块给出代码和说明。你会发现我把“验收标准”放在前面这很重要。模型很多时候会自作主张但如果你把验收标准写清楚了它至少会在生成的过程中主动考虑这些约束。你拿到代码之后第一件事也不是看它能不能跑而是对着验收标准一条一条验证。5.3 建立一套自己的验证工具箱既然验证比生成更重要那你一定要有一套可复用的验证工具箱。我的工具箱包括四层第一个是编译器和静态检查包括类型检查、lint、格式检查。第二个是自动化测试不止是 happy path还要覆盖边界条件和异常路径。第三个是代码评审清单我会把常见风险点列成清单比如错误处理是否完整、是否有明显的性能坑、是否有不安全的外部依赖。第四个是运行时可观测性也就是日志、指标、链路追踪。这套工具箱不是一天建成的但你每做一个项目就往里加一点时间久了就会受益。重点是以后不管你用不用 AI 写代码都应该养成“先设计验证方案再动手实现”的习惯。这个习惯能帮你在 AI 输出之外建立自己的判断坐标。5.4 少谈取代多谈分工最后想谈一点心态。我见过不少开发者对 AI 有很强的焦虑也见过一些人反过来把 AI 吹上天。这两种极端都不可取。更合适的视角是把 AI 看成一次“生产要素重组”低层次的重复性编码工作会越来越便宜但高层次的设计、验证、决策工作会越来越值钱。这件事对每个个体来说不是末日而是一次重新定位的机会。我在实际接触过的团队里看到最先受益的往往不是最会用提示词的人而是对系统理解最深的人。同一个代码助手有人拿它来水日报有人拿它来快速产出一个可以讨论的架构草案。工具一视同仁拉开的还是人的认知差距。写在后面重构这个词听起来宏大但落到每个人身上其实就是一些很小的事情换一套工作流补一门以前觉得无聊的课开始认认真真写测试学会把模糊的想法变成可验证的问题。和十年前相比我们做的工作还是围绕计算机系统在转但围绕的方式已经变了。越来越多的时间要从“敲键盘”转移向“思考、提问、验证”这或许会让一些人感到不适但对于真正热爱计算机科学的人来说反而是一个更接近本质的时代。
阅读完成 · 觉得有帮助？
