最近大家都在讨论那期 AI 访谈标题很吓人“编程正在‘死’去AI 自动研究的‘闭环时代’已至”。作为一个过去十年靠写代码吃饭、这两年又重度依赖 AI 辅助干活的人我第一次看到这个观点时也觉得过于夸张。但仔细听完访谈里的论证加上自己团队已经在跑的 AI 自动化研究闭环我的判断变了传统意义上“人肉写代码”的工作方式确实在快速萎缩但编程这件事本身不会死它只是换了一个生态位。死掉的是“编码员”这种角色活下来的是“组织代码生产的人”。这篇文章不打算复述访谈全文而是想结合我自己踩过的坑和验证过的流程聊聊编程死亡论到底在说什么、AI 自动研究闭环长什么样、哪些岗位最先被波及以及不同阶段的开发者现在还能做点什么。内容偏实操也会给一些可以直接拿去用的工作流和避坑清单。1. 编程死亡论的真正逻辑死掉的不是编程是“手写代码”的垄断地位1.1 “编程死亡”到底在说什么那期访谈里那位 AI 领域的资深研究者说编程正在“死”去并不是说以后没有软件了而是指一个非常具体的转变通用代码生成已经从“需要人逐行实现”变成了“模型根据描述直接生成”。当模型能在绝大多数业务场景里稳定产出可用代码时手写普通逻辑的边际成本会趋近于零于是“程序员”这个身份中最容易被量化的部分——编码速度、语法熟练度、API 记忆量——就失去了市场定价权。这和当年打字员行业的消亡逻辑很像。打字员消失不是因为“写东西”这件事没了而是因为写字工具变得足够简单每个人都能自己完成文本生产。编程正在经历同样的过程只是替代工具从“键盘”变成了“对话式模型”。你需要描述清楚你想要什么、确认它给出的结果对不对而不是亲手逐行敲出每个逻辑分支。这里有个很多人忽略的点编程的本质不是“写代码”而是“把问题形式化”——把一个模糊的业务需求拆解成数据结构、算法、边界条件和异常处理。模型确实能生成代码但它不会替你做“形式化”这一步。它只会在你已经定义清楚问题之后帮你把方案快速变成代码。所以真正缩减的是“从形式化到实现”之间的低创造性劳动而不是“从现实到形式化”这一段高认知工作。1.2 从“如何写”到“如何描述”程序员的接口正在改变过去十年程序员的日常是面对编辑器思考怎么把一个函数写出来、怎么调试一个报错、怎么调通接口。这个过程的本质是“人与机器之间通过编程语言沟通”。但现在模型的介入改变了沟通链路人用自然语言描述意图模型负责翻译成编程语言人再负责审查翻译结果。这条链路里编程语言本身变成了模型的输出格式而不是人的主要输出物。于是核心能力从“构造语句”变成了“鉴别语句”——你必须能看出 AI 生成的代码哪里有问题、哪里缺了边界条件、哪里与业务逻辑不符。这反而把“代码审查”的重要性提到了历史最高点。举个我自己的例子。以前我需要写一个数据清洗脚本会先想字段类型、空值策略、并发的坑然后花四十分钟敲出来再花二十分钟测试。现在我会直接给模型一段描述“这个 CSV 有三列时间字段格式不统一需要标准化成 ISO8601空值按前向填充处理输出到新文件。”模型三十秒给出完整脚本我花五分钟检查正则边界、确认时区处理逻辑再跑最小测试。输出质量大概率比我自己写的还稳定但前提是我能看出它可能在时区转换那里犯错。这就是“接口改变”的含义人不再直接操作机器语言而是操作“意图描述”。但如果你不具备判断输出质量的能力这个接口就变成了单向的、你只能全盘接受或全盘拒绝效率反而更低。1.3 AI 自动研究的“闭环”到底是什么意思访谈里那句“AI 自动研究的闭环时代已至”我猜很多人只是把它当成一句口号。实际上在我见过的一些已经跑起来的团队里这个闭环已经具体到可以画成一条流水线需求定义 → 自动检索背景资料 → 生成候选方案 → 自动执行方案 → 收集结果 → 校验正确性 → 形成报告 → 根据报告重新修正需求 → 进入下一轮迭代。也就是说AI 不只是帮你写某一段代码而是帮你完成一个“研究-实现-验证-总结”的循环。传统模式里这个循环需要几个角色接力产品经理提需求、研发做技术调研、开发写代码、测试做校验、工程师写总结文档。现在模型可以把中间三段压缩到一起人只在两端参与——定义目标和判断结果。我团队里最近在跑一个模拟项目 X目标是分析一组波动数据的周期性特征并生成可视化报告。我只需要告诉系统“我想知道这组数据的主周期、置信区间以及周期性是否随时间变化”系统会自动查资料选算法、写 Python 脚本执行分析、生成图表、计算统计量、最后输出一份带结论的报告。整个过程大约四十分钟放在以前够我前期调研和写脚本一整天。但注意一点我不会直接采信报告结论而是抽了三个统计量手工校验了一遍。所以“闭环”的关键价值不是“全自动干活”而是把人类专家从重复劳动中解放出来让专家把时间花在问对问题、验证结论上。换句话说AI 闭环不会取代专家但会淘汰“只会在流水线上拧螺丝”的岗位。2. 影响范围复盘谁先被波及谁反而更值钱2.1 可替代性分层从风险最高到相对安全我用一个简单的四层分法来看编程岗位的 AI 替代风险越往下越安全层次典型工作内容替代风险原因第一层样板代码、CRUD 接口、简单的页面逻辑极高模型见过海量同类代码生成质量稳定第二层数据处理、脚本编写、SQL 取数、报表开发高只要数据结构和结果格式描述清楚模型也能稳定完成第三层已有系统的功能改造、跨模块集成、测试用例设计中等模型缺乏完整上下文需要人工输入大量背景信息第四层架构决策、算法创新、业务建模、性能调优低需要实时权衡约束、经验判断和长期的系统理解第一层已经非常明显地在消失了。现在很多公司招初级开发进来的头半年就是写增删改查和维护接口这部分工作 AI 已经很擅长导致初级岗位的需求数量在缩减。第二层的风险取决于模型对特定业务数据结构的理解程度但只要你描述精确替代效率很高。第三层里模型更多扮演“高级辅助”的角色因为系统上下文太大模型不可能自动掌握所有模块的历史设计决策需要人手动喂信息。第四层反而是增值的——能做架构和算法决策的人用 AI 以后产能会放大好几倍。我自己带过一个刚转行的新人他刚来第一周去写一个内部工具的登录接口花了两天。后来我让他用模型解释整体代码结构、自己描述接口需求并生成代码他半天就完成了但代价是他说不清为什么要用某种鉴权方案。这恰好印证了上面那张表模型解决“怎么实现”但没有解决“为什么这样设计”后者依然需要人来兜底。2.2 团队协作流程的重构代码量不再是 KPI编程死亡论对研发协作模式的影响比个人技能层面更大。以前一个功能的开发流程是需求评审 → 详细设计 → 编码 → 自测 → 联调 → 发版。现在 AI 介入后编码这个环节被压缩到极限取而代之的是两个新环节需求形式化描述和输出结果验证。需求形式化描述意味着产品经理、研发负责人甚至运营都需要能把自己想要的逻辑写得足够精确让模型能据此产出可用代码。这不是为了讨好 AI而是为了减少迭代次数。描述越模糊生成的代码废稿越多算力和时间反而浪费得更厉害。输出结果验证则要求团队建立一个轻量级但是强制性的校验机制。AI 生成的代码、分析结论、调研报告一律不默认可信必须有独立于生成过程本身的验证手段。比较简单的做法是让另一个模型基于同样需求生成第二个版本再用代码对比或测试用例交叉验证。这个做法成本不高但能拦截大量看似合理实则错误的输出。于是团队的岗位结构也在跟着变。以前团队的中间层是“编码熟练工”现在更吃香的变成了“流程设计者”——能把任务拆解成模型友好的子问题、设计自动校验规则、并能在模型输出偏差时及时纠正方向的人。代码审查的权重从“挑语法毛病”变成了“审查逻辑正确性和架构一致性”这其实对老开发者是利好因为经验的价值在审查场景下反而更突出。2.3 教育与职业发展基础学科的重要性反而上升这里有个反直觉的结论AI 越强基础学科越重要。原因是模型生成的错误通常是“流畅的错误”——它会在逻辑上自洽地给出错误结论尤其在没有经过严格验证的领域。如果你不具备基本的数学、统计、计算机系统知识你根本看不出哪里有问题。举个例子让 AI 做一个 A/B 实验效果分析它会非常漂亮地输出“转化率提升了 5%p 值为 0.04结论有效”但如果你不懂样本量和效应量的关系可能看不出它把样本量写少了导致统计功效不足或者没做多重比较校正。这种错误不会报错也不会生成警告只会让结论方向悄悄跑偏。没有统计学基础的人会直接采信有基础的人会追加一步功效校验。所以在教育层面未来编程课的重心会从“教你怎么写 for 循环”变成“教你怎么拆解问题、怎么验证结论、怎么理解系统约束”。大学里的算法、概率论、操作系统这类课程不仅不会过时反而会成为硬通货。而那些只会背 API 和语法、不会做价值判断的人面临的压力会越来越大。3. 亲测有效的 AI 自动研究闭环流程3.1 一套可以在团队里直接复制的闭环模板我把现在跑的 AI 自动研究闭环整理成了一个模板每一步都对应具体的输入、输出和质检手段。不是只有研究机构能用任何需要“调研-验证-产出”的团队都能改造成适合自己的版本。步骤输入输出质检方式1. 任务拆解自然语言描述的大目标若干个子任务、每个子任务的成功标准看子任务之间是否有依赖冲突、成功标准是否可验证2. 方案设计子任务列表每个子任务的技术选型、实现思路用模型交叉生成两套方案对比取舍3. 代码/实验生成方案文档可执行的代码、脚本、实验步骤审查关键边界条件、跑最小测试集4. 自动执行执行环境运行日志、结果文件、图表检查退出码、输出格式、关键统计量与预期是否一致5. 结果汇总所有执行产物结构化报告、可视化图表人工抽查关键指标必要时重新计算6. 迭代修正报告 原始目标下一轮任务描述、修正计划判断偏差来自描述、方案还是数据定位调整第一步是整个闭环里最难的部分因为把复杂目标拆成可执行的子任务需要你对该领域有足够判断力。模型可以帮你生成候选子任务列表但最终拍板的是人。我通常会让模型给三个拆分版本然后由我合并成一个而不是直接使用其中一个。第二步里有个技巧不要太早让模型进入编码。先让它输出“用什么技术路径、为什么这么选、潜在风险是什么”相当于让它先做设计再写代码。跳过设计直接生成代码经常会出现“代码很精美但方案本身不成立”的尴尬。比如让模型分析时间序列它写了一个很干净的回归脚本但完全没考虑数据存在自相关导致结论失真。设计评审阶段大概率能把这个坑提前暴露。3.2 结果评价方法三明治校验法AI 闭环最容易踩的坑是默认输出正确性。我用了很久后沉淀出一个行之有效的校验策略可以叫“三明治校验法”分三层第一层是对同一个任务让模型生成两个独立版本。这要求我用两份不同的描述甚至让两个不同的对话上下文来生成。目的是利用模型在生成空间里的随机性产生不完全一致的答案。如果两个版本结论高度一致可信度会提升如果差异很大说明任务描述里有模糊地带或者问题本身有多解。第二层是用确定性工具去交叉验证模型的输出。比如模型算出“平均值是 42.5”我用一个独立的统计库重新算一遍模型说“这段代码的时间复杂度是 O(n log n)”我跑一组规模梯度数据实测。这一层是为了拦截“语法正确但数值错误”的问题。第三层是人的领域判断。这层没有替代品因为模型不知道你的业务约束。比如模型推荐了一个在统计上看起来最优的库存策略但你的供应商补货周期只有五天它不知道这个约束所以结论对企业来说不可行。人的工作就是把这类隐含约束装回去。这套方法在项目里跑了几个月实际收益很明确伪报错率模型觉得没问题、但实际上有问题从刚开始的接近百分之二十降到了百分之五以下。代价是每轮闭环大概多花 15% 的时间做校验但比起错误结论带来的返工成本这个投入非常划算。3.3 人机协作的边界哪些环节必须保留人工我总结了几条“不要让 AI 单独完成”的红线第一条涉及账号权限、资金操作、生产环境变更的代码必须有明确的人工审批记录。哪怕 AI 生成了一百次相同结果第一百零一次也可能因为上下文变化而生成错误内容。人在最终变更之前的确认不是流程仪式而是风险卡点。第二条结论会被外部使用的分析报告必须有人复核关键数据来源和分析依据。AI 在信息溯源上依然非常薄弱它会混淆来自不同文档的数字或者把模拟数据当真实数据使用。人需要检查引用、来源和时间线。第三条新领域的高风险决策不要让 AI 自动驱动“研究闭环”。什么意思呢如果团队成员对该领域完全没有经验就无法判断模型给出的方案是否合理此时闭环很容易产生“看起来很专业、实际根基不稳”的结果。正确做法是先人工做出一个最小可行模型让团队建立领域直觉再用 AI 闭环加速扩展。这三个边界本质上是同一条原则AI 自动研究闭环适合解决“你已经知道怎么做、但做不完”的任务不适合解决“你完全不知道怎么做、需要人来定义成功标准”的任务。这个区分能帮你避免很多被模型带着跑的弯路。4. 应对编程变局需要重学的能力与仍然值钱的老技能4.1 新一代开发者必备的能力清单如果你还处在职业早期或者说刚刚开始接触编程我认为下面几个能力是未来两年内最值得投入的任务拆解能力把大目标拆成模型能理解、能反馈的小步骤并定义每个步骤的完成标准。这是新的“编程语言”因为自然语言描述本身就是你与 AI 交互的接口。验证设计能力在拿到 AI 输出之后能设计一套最小实验去检验它对不对。不需要复杂但要能击中要害。上下文管理能力AI 生成的可用性高度依赖你提供的上下文信息。学会组织高质量 prompt不只是写一段话而是要像给新同事交接任务一样背景、目标、约束、示例、验收标准一个都不能少。纠错与反推能力当 AI 产出的结论不合理时能反向定位到底是描述错误、方案错误还是执行错误。这种“调试自然语言”的能力会越来越像传统程序员的“调试代码”能力。这里补充一个实操层面的建议每天花二十分钟做“描述练习”。挑一个你熟悉的小功能先不写代码用两三段话把它描述清楚包括输入输出、边界条件、异常处理然后让 AI 生成实现对照你的预期检查。坚持一个月你对“描述质量决定输出质量”会有非常直接的体感。4.2 哪些传统技能在 AI 时代反而更值钱有一批老技能不会消失反而会因为稀缺性而升值架构设计能力。AI 生成的是局部代码不是整体架构。知道系统应该拆成多少个模块、模块之间用什么方式通信、数据一致性如何保障这些决策仍然需要人来定。架构能力越强AI 的产出越能被有效编排否则 AI 只是在制造一堆积木没人知道怎么搭。统计与实验素养。AI 自动研究闭环的核心是“结论的可信度”而可信度判断依赖统计思维。懂假设检验、懂置信区间、懂实验设计的人在 AI 时代相当于既懂业务又懂审计价值比纯编码高很多。长期维护思维。AI 擅长从零生成一个可以跑的函数但不擅长为一套跑了两年的系统做兼容性改造。懂技术债、懂版本兼容、懂历史包袱的开发者能利用 AI 快速理解旧代码同时避免拍脑袋式重构。领域业务知识。不管模型多强大它不了解你们公司的客户、供应链、合规流程、历史决策。最熟悉业务的人才能给模型输入真正有效的约束条件也才能在模型给出建议时判断它在现实世界里走不走得通。4.3 给团队管理者的落地建议管理者比个人开发者更需要关注闭环转型因为涉及组织架构和分工调整。我观察下来比较顺利的团队普遍采取了这三步第一步建立“AI 使用分级”制度。哪些任务允许 AI 自动生成并直接使用哪些必须经过人工审查哪些禁止使用。标准可以按“影响范围”和“错误代价”两个维度画一个二维矩阵影响小且错误代价低的用全自动影响大或代价高的必须人工介入。第二步改造代码评审流程。代码评审的重心从“检查风格和命名”变成“检查逻辑正确性、架构一致性和隐含约束是否被覆盖”。评审需要结合对适用场景的理解和数据校验结果建议让资深工程师参与而不是全部甩给初级。第三步重新定义团队角色。可以增设“AI 流程工程师”或者叫“自动化研究协调员”角色职责是维护 AI 工作流模板、沉淀高质量的提示词资产、跟踪模型输出质量指标。这个角色不一定是新增招聘可以从团队里逻辑清晰、表达能力好的成员转岗。这三步落地以后团队最大的变化是同样的工作量人力消耗明显下降但角色也随之变化。介意变化的成员需要提前沟通让他们从“更擅长编码”转向“更擅长审查和决策”尽量给足技能转型的时间。5. 常见误区与避坑记录5.1 误区一AI 自动写代码那就不用测试了这个误区在刚接触 AI 编程的人里极其普遍。他们觉得模型已经“很聪明”生成结果看起来又完整于是跳过测试直接上生产。我身边真实发生过的事AI 写的一个日期处理函数在处理跨年数据时把默认年份填错了团队没测就发布了导致一周的数据统计全部错位花了好几天才追回。AI 生成的代码在“常见路径”上非常可靠但一旦进入边界路径——空指针、并发冲突、格式化差异、跨时区、极端输入——就可能出现很隐蔽的错误。这些错误不会给你任何警告因为代码本身“能跑”。所以结论是AI 进入生产环境测试不是放松了而是比重更大了。只是测试策略从“先写代码再测”变成了“先想清测试用例、再让 AI 生成代码、用用例做闸门”。5.2 误区二提示词写得越详细越好我刚开始也以为提示词越详细越好后来发现不是。提示词的核心不是“长”而是“结构完整”。结构化包含以下要素就够了角色或背景、任务目标、输入数据说明、约束条件、输出格式、验收标准。多余的情绪化描述、无关背景、互相冲突的要求反而会让模型输出偏离。比如你说“帮我用最优雅的方式写一个爬虫注意一定要快别被屏蔽最好用异步并且要有断点续传”这听起来很全但“优雅”“快”这些词没有可度量标准模型会尽量猜测然后很可能在难点上选择错误方向。更好的写法是“实现一个网页列表抓取脚本要求并发度为 10请求失败自动重试两次支持从 last_id 参数断点续传输出 JSON 格式到指定文件。”我在实践里还发现给模型一两个输入输出示例比解释十句话更有用。一个“小样本示例”往往能让模型立刻对齐你要的格式和逻辑风格这比任何措辞优化都高效。5.3 误区三基础学科没用了可以直接让 AI 完成思考这是最危险的一个误区。简化逻辑是“既然 AI 能写代码、能分析数据、能读论文那我还学算法和概率论干什么”但我反复验证过AI 在研究闭环里犯的错误恰恰需要基础学科去发现。举一个统计学的例子。有一次 AI 闭环生成了一份“两变量相关系数显著”的报告相关系数 0.86p 值很小。表面看结论没问题但我去画出散点图发现关系其实是非线性的——线性相关系数高只是一个巧合模型因为默认选择了皮尔逊相关所以完美地错过了非线性关系。如果我不懂相关方法对分布和线性的假设就会直接把错误结论写进报告。模型适合做“拟合”但不擅长“怀疑自己的假设”。基础学科是你的“怀疑工具包”。AI 给你一个结论你用概率论去检验抽样误差用算法分析去评估复杂度用系统知识去判断边界——这套能力越强你能放心交给 AI 的任务就越多。误区实际体验正确做法AI 写代码不用测边界路径出错率远高于预期先定测试用例再生成代码用例做闸门提示词越长越好结构化短描述优于冗长叙述用角色、目标、约束、示例、验收五要素基础学科无用错误结论必须靠基本功识别把概率论、算法、系统知识当成验证工具包最后分享一个我一直在用的小技巧如果你也想开始拥抱 AI 自动研究闭环建议别急着上大项目而是找一个过去需要你半天时间、重复性高的任务试着跑一轮上面的闭环模板。第一次会很慢因为你要额外做校验和筛选但坚持三轮之后你会明显感受到“原来我的时间可以花到更有价值的地方”。我个人这几年最大的感受是编程没有死它只是从“亲手搭建”变成了“指挥与验收”。那些还在焦虑的人在纠结农具会不会取代农民而我已经把自己定义成了新式农场主——管的范围更大干的活儿更少但对收成的责任一点没少。这不是什么宏大叙事就是一个在一线干活的人直观感受到的生产方式变迁。