AI能写代码了,软件工程师还要做什么?

让AI按需求描述写一个接口，代码和测试样例很快就能摆在屏幕上。接下来，团队还要问：旧数据从哪来？谁有权限调用？失败后能否重试？上线后出了错谁回滚？这是流程示意，不是某家公司的真实案例。它说明“写完”与“交付”之间还有一段路。

先把访谈的时间说准

最近一条中文报道把Anthropic CEO Dario Amodei的访谈重新带进了讨论，标题指向“纯编码岗位先被AI重塑”。时间要先说准：这期People by WTF访谈发布于今年2月24日，10月27日的报道是重新传播，不是他这两天的新宣布。

访谈里，主持人特意把coding与software engineering分开问。Amodei的判断是：写代码这一步可能先由模型承担；更广义的软件工程自动化会慢一些，但他也认为端到端自动化未来可能发生。他同时谈到设计、理解用户需求、管理AI模型等环节。这是一位公司负责人的前瞻判断，不能直接换算成某年会减少多少程序员岗位。

对工程师来说，区别落在任务单上。若需求已经写清，只要把固定逻辑变成代码，模型会成为强竞争者。可一张写着“用户注销”的需求单，可能还牵着账户余额、历史订单、审批记录、隐私删除和客服查询。代码能生成，哪个系统是事实来源、哪些记录必须保留、失败后怎样恢复，仍需有人逐项定义并验证。

更难的是找到值得做的需求

但任务单本身，也可能来得太早。在不少商业化项目里，编码处在靠后的执行环节：有人先决定做什么、给谁用、预算从哪里来，工程师才接到功能。往需求端走，比接住测试和上线更难。它要求团队先弄清用户有没有持续发生的问题，现有做法究竟贵在哪里，以及使用者、决定采购的人是不是同一批人。

假设一支团队想做“自动生成经营报表”。AI可以很快写出页面和查询接口；可如果店长仍凭原来的表做决定，财务又不信任无法追溯的数据，做出更多图表也未必带来一笔新订单。这里的难题已经不是代码能否运行，而是报表是否改变决策、谁愿意为这种改变付费、交付与维护的成本能否覆盖收入。这是用于说明问题的假设，不是某家企业的经营案例。

因此，“工程师都去做需求”也不能当作转型口号。产品、销售、业务团队可能早就在找新场景，却仍没有找到可重复成交的路径。工程师能贡献的是把技术可行性、数据质量、试点成本和验证周期带进讨论：先用小范围原型观察谁实际使用、解决了哪一步，再决定是否投入完整系统。看不到业务突破口时，坦诚说“还没验证出值得规模化开发的需求”，比把代码产量当增长更有价值；市场机会也不该由工程师一个岗位独自保证。

顺序要从行业开始

如果想做出更大的改变，顺序还要再往前挪：行业＋技术。先选一个愿意长期理解的行业，找到真正站在业务前线、能拿出客户问题和交付场景的领头企业或团队；看清它怎样获客、服务、结算，哪一步长期耗人力、成本或信任。然后才讨论AI和软件能否把那一步重做成更好的产品或服务。反过来，先拿着一套技术去各行业寻找“可落地场景”，很容易只做出一批演示，离真实交易仍远。

找行业领头羊，也不能只看它的名气。更要看技术人能否接触一线流程，业务方是否愿意开放真实问题、数据与试点，做出的改变能否在多个客户或场景中重复。头部企业有客户和交付能力，也可能有旧流程的惯性。只有这些条件允许反复验证，“行业＋技术”才有机会走出效率工具，形成新服务、新产品，甚至改变原有做法；它不是一个保证成功的职位标签。

这条路可以拆成四环，顺序不能倒过来：

还是拿前面的自动经营报表作假设。行业经验告诉团队门店究竟依据什么补货；可用的私有数据让库存和订单口径对得上；AI给出的建议要进入有人负责的决策流程；最后看这些建议有没有被采纳、是否改善结果、客户是否愿意持续购买。四环连起来，才谈得上用技术改变行业。这里描述的是验证路径，并没有一家企业已经完成这些结果。下文的七格任务链解决另一件事：选定问题后，系统能否可靠交付。

把四环放回自己身上看，我一直在技术侧做数据，能搭AI工作流，运营方面也有一定积累。这些能力让我有机会把数据口径、流程执行和使用反馈连起来，但它们不会自动变成对某个行业的深入理解，更不能证明商业闭环已经跑通。下一步，我想先找到愿意开放一线流程、允许合规使用私有数据并能一起试点的行业领头企业或团队，与业务负责人确认一个反复出现、确实有成本的问题。让AI工作流进入日常决策后，记录谁持续使用、效果能否复核、谁愿意付费以及交付成本，再判断能否复制到更多场景。这是对未来路径的设想，不是已经取得的商业成绩。

代码生成提速，瓶颈会移动

Amodei在访谈中还借用一个工程思路：当一条流程中的某个环节大幅加速，其他没跟上的环节就会成为新的限制。放到软件项目上，代码生成快了，如果需求仍反复改、测试环境不稳、接口责任不清，整件事不会跟着等比例提速。原来花在敲键盘上的时间，可能转移到定义约束、审查生成结果、接入旧系统和处理运行中的问题。这里是分析框架，不是所有团队都已经测出的统一结论。

效率研究测的并非同一件事

研究给这件事增加了两层现实感。Google Cloud的DORA团队在2025年报告中，汇集近5000名技术从业者的调查和访谈。报告观察到AI采用与软件交付吞吐、产品表现呈正相关，但与交付稳定性仍有负相关；报告还强调，AI必须指向清楚的用户问题，以用户为中心的工作方式会放大它对团队表现的正向关联。相关性不能证明AI造成了每个结果，更不能证明某项功能已经找到付费市场。它提醒团队，生成更多变更之后，需求反馈、测试和版本管理未必自动跟上。

另一种证据来自受控任务。METR在2025年请16名熟悉自己开源仓库的开发者完成246项真实任务，比较允许和不允许使用当时AI工具的情况。在这组任务中，允许用AI的一组平均耗时反而多19%。这个数字不能被写成“AI让所有程序员都变慢”：样本是成熟开源仓库，工具也是2025年上半年的版本。METR在2026年2月的后续说明中又说，随着开发者更依赖AI，新的实验出现参与者选择和并行任务计时等偏差，当前工具究竟带来多大加速，不能从那轮数据可靠估计。

DORA观察的是团队交付关联，METR测的是特定开发者完成特定任务的时间。一个看系统表现，一个看任务耗时；研究方法、样本和工具年份都不同。把它们摆在一起，能检验“代码快了，项目就一定快”这句话，却不能算出岗位还剩多少年。

先核行业问题，再把变更走到运行

那软件工程师今天能把时间放到哪里？先在需求单前补一页：这是哪个行业流程中的问题，谁正在受它困扰，现有替代办法是什么；若谈商业化，还要分清使用者和付费决策者，并写下什么行为会证明方案有用。随后再拿最近一个自己参与的变更，顺着这条链走一遍：

这七格不是人的永久领地。AI代理正在扩展到测试、代码审查和系统操作；Amodei在原访谈里也承认，广义工程将来可能被端到端自动化。今天值得练的能力，未必永远都由人独占。

更可行的做法，是在当前行业里主动接住一个完整问题。先跟真正使用这项服务的人看一次现有流程，再和需求提出者核对：这个功能要改变哪项工作，怎样知道它被持续使用。接着让AI写初版，亲自说明边界，找一个失败路径，验证旧数据接口，写清上线后怎样发现错误、怎样撤回。若前面两问没有答案，换一个更强的模型可能会产出更长的代码，却仍找不到愿意使用或付费的人。

如果家里有正在选专业的学生，也别把“AI会写代码”直接推成“编程不用学”。学编程仍能帮助他理解系统、检验模型输出；但未来不能只靠敲键盘的速度竞争。让他选一个愿意观察的行业，找可能使用的人问清麻烦，再做一个小项目，测试异常，观察交付后有没有人真的用。做完后若发现没人需要，也算得到一个重要结果：下一次该改的问题，可能在代码写下之前。

—— 算力与远方，一个技术人的数据观察与成长记录。