人工智能能取代开发者的哪些工作（以及哪些不能）

替代、增强、保持不变：一个简单框架

关于“人工智能会对开发者做什么”的讨论很容易变得混乱，因为我们常常把工具和责任混在一起。工具可以生成代码、总结工单或建议测试。责任则是当建议出错时团队仍须承担的那部分内容。

本文使用一个简单框架——替代（replace）、增强（augment）、保持不变（untouched）——来描述有截止日期、遗留代码、生产事故和期望可靠结果的真实团队的日常工作。

“替代”是什么意思（以及不意味着什么）

替代意味着人工智能在有明确护栏的情况下，大多数时候能够端到端完成任务，而人的角色转为监督和抽查。

示例通常是有边界的工作：生成样板、在语言间翻译代码、草拟重复性的测试用例，或产出首轮文档。

“替代”并不意味着“没有人类责任”。如果输出破坏了生产、泄露数据或违反标准，团队仍需负责。

“增强”是什么意思

增强意味着人工智能使开发者更快或更全面，但它并不能在没有人类判断的情况下可靠地完成工作。

这是专业工程中常见的情况：你会得到有用的草稿、替代方案、快速解释或可能的 bug 清单——但开发者仍需决定什么是正确、安全、适合产品的。

哪些保持“保持不变”

保持不变意味着核心责任仍由人主导，因为它需要上下文、权衡与问责，这些不容易通过提示压缩。

可以想到：协商需求、选择系统级约束、处理事故、设定质量门槛，以及在没有唯一“正确”答案时做决定。

为什么以责任为单位来分析

工具变化快。责任变化慢。

所以，与其问“AI 能写这段代码吗？”，不如问“谁对结果负责？”这种框架把期望固定在准确性、可靠性和问责上——这些比炫酷演示更重要。

我们所说的“开发者责任”是什么

当人们询问人工智能能“取代”开发的哪些工作时，他们常指任务：写函数、生成测试、起草文档。但团队不是交付单个任务，他们交付的是结果。这就是开发者责任重要的地方。

常见的一组责任

开发者的工作通常不仅限于编程时间：

• 交付（Delivery）： 把模糊的想法变成按时上线的工作软件。
• 质量（Quality）： 正确性、可维护性与防止回归。
• 安全与隐私（Security & privacy）： 安全默认、数据处理与威胁意识。
• 运维（Operations）： 保持服务运行、理解故障模式并响应事故。
• 沟通（Communication）： 与产品、设计、支持和其他工程师保持一致。

这些责任横跨整个生命周期——从“我们该建什么？”到“它安全吗？”再到“凌晨三点它挂了怎么办？”

为什么这不只是一个核对清单

每项责任实际上包含许多小决策：哪些边缘情况重要、哪些指标表明健康、何时缩减范围、修复是否可以安全发布、如何向利益相关者解释权衡。AI 可以帮助执行这些工作的片段（起草代码、建议测试、总结日志），但责任在于对结果负责。

交接点为何会失败

分工失败常发生在交接边界：

• “QA 会发现的”——但没人定义什么是质量。
• “安全会审查”——但设计已经锁定了高风险的选择。
• “运维会处理”——但服务根本没按可运维性构建。

当所有权不清时，工作就会掉进缝隙里。

决策权：谁决定 vs 谁执行

讨论责任时，一个有用的方法是看决策权：

• 谁决定需求、权衡与可接受风险？
• 谁执行实现与验证？

AI 可以加速执行。决策权——以及对结果的问责——仍需要有一个人的名字在旁边。

人工智能通常可以替代的工作（有护栏）

当工作可预测、低风险且易于验证时，AI 编程助手确实非常有用。把它们看作一个快速的初级队友：善于产出首轮结果，但仍需要明确指令与仔细检查。

在实践中，一些团队越来越多地使用“vibe-coding”平台（如 Koder.ai）来加速这些可替代的片段：生成脚手架、接线 CRUD 流程，从聊天中生成 UI 与后端代码的初稿。关键同样是：护栏、评审与明确所有权。

低风险的样板工作

大量开发时间花在搭建项目和接线。AI 经常可以生成：

• 启动文件和文件夹（controller、route、DTO）
• 各层之间重复的“粘合代码”
• 遵循既定模式的简单 CRUD 接口

这里的护栏是保持一致性：确保它符合现有约定，不要发明新模式或引入不必要的依赖。

机械性的重构与迁移

当改动主要是机械性的——跨代码库重命名符号、重新格式化或更新简单的 API 用法——AI 可加速重复工作。

但仍要把它当做一次批量编辑：运行完整测试套件，扫描 diff 以寻找意外行为变化，并避免让它把想要的重构范围之外的东西“改得更好”。

文档草稿（需复核）

AI 可以根据代码与提交说明起草 README、行内注释和变更日志。这可以提升清晰度，但也可能生成自信却不准确的表述。

最佳实践：用 AI 做结构和措辞，然后验证每一条陈述——特别是安装步骤、配置默认值和边缘情况。

基本测试生成作为起点

对于定义良好的纯函数，AI 生成的单元测试可以提供初步覆盖并提醒你注意边缘情况。护栏在于所有权：你仍需决定什么重要、添加反映真实需求的断言，并确保测试能在正确的情况下失败。

线程与日志摘要

当你面对冗长的 Slack 线程、工单或事故日志时，AI 可以把它们转成简洁的笔记和行动项。通过提供完整上下文并在分享前核实关键事实、时间戳和决策来保持准确性。

人工智能主要增强的工作：更快，但不完结

当你已经知道想要什么并需要加速实现时，AI 编程助手最有价值。它可以减少“敲字工作”的时间并提供有用的上下文，但并不能替代所有权、验证与判断。

加速实现（很好的首轮稿）

在有明确规格——输入、输出、边缘情况与约束的前提下，AI 可以草拟一个合理的起始实现：样板、数据映射、API 处理器、迁移或直接的重构。收益在于动力：你能很快得到可运行的初稿。

问题是首轮代码常常忽略微妙要求（错误语义、性能约束、向后兼容）。把它当作实习生的草稿：有用但不权威。

提出方案——需要你验证权衡

在选择方案时（例如缓存 vs 批处理、乐观锁 vs 悲观锁），AI 可以提出备选项并列出权衡。这对头脑风暴很有价值，但这些权衡必须与系统的现实核对：流量形态、数据一致性需求、运行约束和团队惯例。

代码理解与代码库导航

AI 在解释不熟悉的代码、指出模式和把“这在做什么？”翻成白话方面也很有用。配合搜索工具，它能帮你回答“X 在哪里被使用？”并生成可能需要查看的调用点、配置和测试的影响清单。

开发者体验优化：更短的反馈回路

期待一些实用的体验改善：更清晰的错误信息、小示例和可粘贴片段。这些能减少摩擦，但不能替代仔细的审查、本地运行和针对性测试——尤其是会影响用户或生产系统的改动。

产品理解与需求：仍由人主导

AI 可以帮助撰写与优化需求，但它无法可靠地决定我们应该构建什么或为什么要构建。产品理解根植于上下文：业务目标、用户痛点、组织约束、边缘情况与出错代价。这些输入存在于对话、历史与问责之中——模型能总结，但不能真正拥有。

把模糊目标变成可构建内容

早期需求常像“让引导更顺畅”或“减少支持工单”。开发者的工作是把这些翻译成清晰的需求与验收标准。

这种翻译大多是人来做的，因为它依赖于探索性问题与判断：

• 我们在优化哪个用户群体，期望哪些行为改变？
• 什么算“完成”，我们如何衡量？
• 哪些约束是不可谈判的（隐私、性能、截止日期）？

AI 可以建议可能的度量或起草验收标准，但除非有人提供约束，它不会知道哪些是真实的，而且它不会在请求自相矛盾时进行反驳。

权衡与期望管理

需求工作是让不舒服的权衡浮现的地方：时间 vs 质量、速度 vs 可维护性、新功能 vs 稳定性。团队需要一个人把风险说清楚、提出选项并让利益相关者就后果达成一致。

一份好的规格不仅仅是文本；它是决策记录。它应该可测试、可实现，并且有清晰定义（输入、输出、边缘情况与失败模式）。AI 可帮助结构化文档，但正确性和指出“这里模糊，需要决策”的责任仍在于人。

系统设计与架构决策

系统设计是把“我们该建什么？”变成“我们用什么搭建它，以及在出错时它如何表现？”AI 可以帮你探索选项，但不能承担后果。

选择与现实相符的架构

在单体、模块化单体、微服务、无服务器或托管平台间做选择不是答题，而是适配问题：预期规模、预算限制、上市时间和团队技能都会影响答案。

助手可以总结模式并建议参考架构，但它不会知道你团队的值班轮换、招聘速度，或数据库供应商合同何时续约。这些细节往往决定架构能否成功。

将权衡显式化

好的架构主要是权衡：简单性 vs 灵活性、性能 vs 成本、今天的速度 vs 未来的可维护性。AI 可以快速输出利弊清单，这很有用——尤其是用于记录决策。

但它不能在权衡带来伤害时为优先级做主。例如，“我们接受略慢的响应以保持系统更简单、易运维”是商业选择，而非纯技术问题。

边界、数据归属与失败模式

定义服务边界、谁拥有哪些数据以及部分故障时的行为需要深刻的产品与运维上下文。AI 可以帮你头脑风暴故障模式（“如果支付提供商宕机怎么办？”），但你仍需决定期望行为、客户沟通和回滚计划。

可用的 API 设计

设计 API 就是在设计合约。AI 可以生成示例并指出不一致，但你必须决定版本策略、向后兼容性以及长期愿意支持的内容。

何时不构建（或何时删除）

或许最具架构性的决定就是说“不”——或删除功能。AI 无法衡量机会成本或政治风险。团队能，而且应该去做这类决定。

调试与根因分析的实践

调试是 AI 常显得很厉害的地方——同时也可能悄悄浪费最多时间。助手可以扫描日志、指出可疑代码路径或建议看起来合理的修复。但根因分析不仅是生成解释，而是要证明解释正确。

AI 可以建议；你来确认根因

把 AI 的输出当作假设，而非结论。许多 bug 有多种 plausible 原因，AI 特别容易挑选一个与粘贴的代码片段相匹配的整洁故事，而非运行系统的现实。

一个实用流程是：

• 让 AI 列出可能的原因以及区分它们的证据是什么。
• 重现问题并收集这些证据。
• 只有在修复确实消除了失败现象后再接受修复并验证其不会复现。

重现与证据收集仍由人主导

可靠地重现问题是调试的超级能力，因为它把谜题变成一个测试。AI 可以帮你写最小复现、起草诊断脚本或建议额外日志，但你决定哪些信号重要：请求 ID、时序、环境差异、功能开关、数据形态或并发情况。

当用户报告症状（“应用卡住了”）时，你仍需把它翻译成系统行为：哪个端点阻塞、哪些超时触发、哪些错误预算信号发生变化。这需要上下文：产品的使用方式以及什么是“正常”。

避免“看起来合理但错误”的解释

如果建议无法被验证，就假设它是错的。偏好那些能做出可测试预测的解释（例如“只有在大 payload 时会触发”或“只有缓存预热后才会发生”）。

修补、回滚还是重新设计？

即便找到原因，困难的决定依然存在。AI 可以概述权衡，但人来选择响应方式：

• 快速打补丁以止血。
• 回滚以恢复已知良好行为。
• 重新设计以解决更深层的不匹配（性能、数据模型或假设）。

根因分析最终是问责：对解释、修复以及其不会再来负责。

代码审查：判断与标准无法自动化

代码审查不仅仅是风格检查表。它是团队决定愿意维护、支持并对其负责的时刻。AI 可以帮你看到更多，但不能决定哪些事重要、是否符合产品意图或你的团队能接受哪些权衡。

AI 在审查中擅长的事

AI 编程助手可以像一双不知疲倦的眼睛，快速：

• 标记可能的 bug、可疑模式、缺失的空检查或不安全的字符串处理。
• 建议更清晰的命名、重构或简化控制流。
• 指出不一致的格式或明显的重复。
• 生成审查问题（“如果这个 API 返回空列表会怎样？”）。

这样使用时，AI 缩短了从“打开 PR”到“注意到风险”的时间。

仍需人类判断的事

审查正确性并不仅仅看代码能否编译。人会把改动与真实用户行为、生产限制和长期维护联系起来。

审查者仍需决定：

• 什么可以发布： AI 能列出问题，但不能决定哪些是阻塞发布的。
• 可读性与可维护性： “技术上正确”的代码仍可能难以理解、脆弱或难以扩展。
• 边缘情况与环境差异： 许多故障是“在我机器上能通过”的问题——配置、数据特性、并发或部署时序。AI 无法可靠推断你的运行时现实。
• 标准与意图： 只有团队知道其约定与风险容忍度。一个更整洁的改动也可能是错误的行为。

实用流程：把 AI 当作协审人员

把 AI 当作第二审阅者，而非最终批准者。让它做有针对性的检查（安全、边缘情况、向后兼容），然后由人来判断范围、优先级以及改动是否符合团队标准与产品意图。

测试策略与质量所有权

AI 可以快速生成测试，但它不负责质量。测试套件是一组关于什么会出错、哪些绝不能出错以及你愿意在没有覆盖所有边缘情况的情况下发布什么的赌博。这些赌博是产品与工程的决定——仍由人来做。

AI 可以起草测试；人设定目标

助手擅长生成单元测试脚手架、模拟依赖并覆盖实现的“好路径”。它不能可靠地决定哪些覆盖重要。

人需要定义：

• 哪些模块因关键或频繁变更而需要深入覆盖。
• 对风险较大的重构与小 bug 修复，“完成”意味着什么。
• 何时投资回归测试，何时依赖监控与回滚计划。

选择合适的测试类型组合

大多数团队需要分层策略，而不是“测试越多越好”。AI 可以帮助编写这些测试，但选择与边界由人主导：

• 单元测试：针对业务规则和棘手边缘情况。
• 集成测试：针对数据库/队列/服务交互。
• 端到端测试：覆盖关键用户路径（少而稳定、高价值）。
• 契约测试：保证跨团队/服务的 API 兼容性。
• 性能测试：在负载下保护延迟与成本。

避免不稳定测试与虚假的信心

AI 生成的测试常与代码过度耦合，生成脆弱断言或过度模拟，导致即便真实行为失败也能通过。开发者应：

• 测试可观察行为，而非内部实现细节。
• 保持确定性的数据并控制时间、随机性与网络调用。
• 审查失败以判断：是真 bug、测试问题还是环境问题。

将策略与风险和发布节奏对齐

好策略应与发布方式匹配。发布越快需要越强的自动化检查与更清晰的回滚路径；发布节奏慢则可承受更重的合并前校验。质量的负责人是团队，而不是工具。

衡量真正重要的结果

质量不是覆盖率百分比。跟踪测试是否在改善结果：更少的生产事故、更快的恢复、更安全的改动（更少回滚、更快的自信部署）。AI 能加速工作，但责任仍在开发者身上。

安全、隐私与合规责任

安全工作少有关于生成代码，更多是关于在现实约束下做权衡。AI 能帮你列出检查项和常见错误，但风险决策的责任仍在团队。

威胁建模需要上下文

威胁建模不是通用练习——重要性取决于你的业务重点、用户与故障代价。助手可以建议典型威胁（注入、认证缺失、不安全默认），但它不会可靠地知道对你的产品而言哪类问题代价最大：账户接管、数据泄露还是服务中断，以及哪些资产在法律上敏感。

应用特定风险往往不像模式那样显现

AI 擅长识别已知的反模式，但许多事故来自应用特有的细节：权限的边缘情况、临时的管理端点、或意外绕过审批的工作流。这些风险需要理解系统意图，而非仅看代码。

秘钥、权限与保留策略是有意的选择

工具能提醒你不要硬编码密钥，但它不能承担完整策略：

• 秘钥放在哪里（vault、CI、运行时）及如何轮换。
• 最小权限角色与访问审查。
• 数据保留：存什么、保存多久、谁能导出。

依赖与供应链风险

AI 可能会标记过时库，但团队仍需建立实践：固定版本、验证来源、审查传递依赖，并决定何时接受风险与何时投入修复。

合规与审计需要证据

合规不是“加密一下”。它是控制、文档与问责：访问日志、审批轨迹、事故程序和你遵循它们的证据。AI 可以起草模板，但人必须验证证据并签字——因为审计方（和客户）最终依赖的是这些人工签署的证明。

运营、可靠性与事故响应

AI 可以让运维工作更快，但不能接管所有权。可靠性是一串在不确定中做出的决策，错误决策的代价通常高于慢一次决策的代价。

AI 在日常工作的帮助

AI 在起草与维护运维文档——运行手册、检查清单和“如果 X 则尝试 Y”的流程方面很有用。它也能总结日志、聚类相似告警并提出首轮假设。

对于可靠性工作，这意味着更快迭代：

• 监控仪表板与告警描述
• 容量说明与扩缩容启发式
• 错误预算报告模板

这些是极好的加速器，但它们不是工作的全部。

仍由人主导的部分

事故很少完全按剧本发生。值班工程师面对模糊信号、部分故障和钟表的压力做出艰难权衡。AI 可以给出可能原因，但不能可靠地决定是否去呼叫另一个团队、禁用某功能，或是为了保持数据完整性而接受短期的客户影响。

部署安全也是人负责的。工具可建议回滚、功能开关或分阶段发布，但团队仍需根据业务背景与爆发范围选择最安全的路径。

事后分析：学习才是重点

AI 可以起草时间线并从聊天、工单与监控中提取关键事件。人仍需做关键部分：决定什么算“好”的响应、优先修复哪些问题，并做出能防止复发的变更（而不仅仅是处理同样的症状）。

如果把 AI 当作运维文书与模式发现的副驾驶，而非事故指挥官，你会在获得速度的同时不放弃问责。

团队沟通、指导与责任感

AI 可以按需清晰解释概念：“什么是 CQRS？”、“为什么会发生死锁？”、“总结这个 PR。”这能让团队更快前进。但工作中的沟通不仅是信息传递——它是建立信任、确立共同习惯和做出可被信赖承诺的过程。

入职：不止是文档

新开发者不仅需要答案，还需要上下文与人际关系。AI 可以通过总结模块、建议阅读路径和翻译行话来帮助。但人仍需教授“这里重要的是什么”：团队偏好的权衡、在代码库中什么算好，以及当感觉不对时该找谁。

跨角色对齐

大多数项目摩擦出现在角色之间：产品、设计、QA、安全、支持。AI 可以起草会议纪要、提出验收标准或用更中性的方式复述反馈。人仍需协商优先级、消除歧义，并注意某个利益相关者看似“同意”但实际上并不同意的情况。

完成定义与所有权边界

当责任模糊时团队会失败。AI 可以生成核对清单，但无法强制执行问责。人必须定义“完成”意味着什么（测试？文档？发布计划？监控？），以及合并后谁负责——尤其是在 AI 生成代码隐藏复杂性时。

清单：在团队工作流中负责任地使用 AI

• 当 AI 影响决策、估算或作者代码时披露使用情况。
• 验证事实：链接、API、安规声明与“最佳实践”在共享前必须核实。
• 提示中不要包含秘密（密钥、客户数据、事故细节）。
• 把 AI 输出视为草稿；为每个决策指定一个人类所有者。
• 写下团队规范：什么时候允许用 AI、什么时候不允许，并定期回顾期望。
• 偏好小而可审查的改动——避免“大爆炸”式的 AI 重构。