从 ChatGPT 3.5 发布开始我就一直在使用大模型写代码。当时 ChatGPT 3.5 的编程能力还不是很强只要需求稍微复杂一点生成的代码就不太可靠。因此那时我仍以手写代码为主AI 主要用于查资料和处理一些简单问题。后来我又陆续用过 GPT-4 和 Claude此后也一直在尝试 OpenAI 和 Anthropic 发布的新模型。随着模型能力不断增强我在工作中需要手写代码的场景也越来越少。最近一年我更是基本没有手写过代码只有偶尔刷 LeetCode 时才会自己写一下。这种变化也逐渐影响了我的开发方式。现在开发一个新功能时我通常会先把目标、业务规则和验收条件理清楚再让 AI 探索项目检查还有哪些信息需要补充并根据现有代码提出方案。经过几轮讨论以后一般就能把实现方案确定下来。方案确定后我再让 AI 完成实现。代码修改以后它还要继续运行相关测试和检查能实际执行的功能也尽量自己运行一遍。如果中间发现问题就根据报错继续修改和验证。等这一轮完成以后我再检查和验收最终结果。现在我基本都是按照这个流程来开发需求。不过我不会把需求交给 AI 以后就完全不再参与。对于影响较小的改动我会主要检查测试和最终效果涉及核心业务、安全、性能或者数据变化时再进一步查看具体实现和影响范围。AI 有时会一次修改很多文件如果每次都从头到尾逐行检查Review 会花费大量时间。所以我通常会先了解这次修改涉及哪些业务流程和模块再结合代码改动、自动化测试和实际运行结果进行检查。在过去一两年里很多程序员的工作方式都发生了类似的变化。随着 AI 能够承担越来越完整的开发任务我也开始思考如果探索、实现和验证都可以交给 AI那么程序员以后还能做什么这篇文章会结合我自己的工作经验对这个问题做一次梳理。因为其中不少内容来自个人实践所以难免会有偏颇欢迎大家一起讨论。Vibe Coding 改变了什么以前我主要用 AI 帮我写代码。但现在我会把一项完整的开发任务交给 Coding Agent让它从分析问题开始一直做到实现和验证。以前如果要开发一个自己不熟悉的功能通常需要先查资料、读文档、找示例然后再一点点把代码写出来。如果中间遇到问题还要继续搜索资料并反复调试。在整个过程中查找资料和调试花费的时间最多真正花在写代码上的时间反而比较少。现在这些工作有很大一部分可以先交给 AI。无论是实现新功能、分析 bug还是理解现有项目只要把目标和相关背景描述清楚AI 就可以自己查找项目代码、尝试实现、运行检查并根据结果继续修改。对于需求比较明确的开发任务我通常会直接把需求交给它让它一直做到功能可以运行、相关测试通过为止。在适合 AI 的任务中开发成本降低以后团队有机会在相同时间内完成更多功能代码变更也会变得更加频繁。但开发速度提高并不代表就能提高产品的交付质量。如果需求分析、代码审核、测试和发布流程没有跟上一些没有经过充分测试的改动就可能进入生产环境导致产品问题频发。而且功能实现得越容易团队越有可能跳过需求评审而直接开始开发。以前一个需求要投入几天甚至几周大家通常会认真考虑是否值得做。现在开发成本降低了更需要在开始之前判断这个需求能不能解决实际问题避免最后做出一个没有价值的功能。以前程序员会把大量时间花在写代码上。随着越来越多的开发工作可以交给 AI 完成程序员需要把更多精力放在分析需求、设计方案和验证结果上。如果 AI 只是在对话中生成一段代码这种使用方式仍然比较接近最初所说的 Vibe Coding。现在的 Coding Agent 已经可以自己查找项目文件、制定方案、修改代码、运行测试和排查错误。有人把这种工作方式称为 Agentic Engineering。它和以前最大的区别不是生成的代码更多了而是 AI 开始能够独立完成一段比较完整的开发流程。现在一项需求的流程可以变成先由人明确需求和验收条件再让 AI 探索项目、制定方案、完成实现并自己验证。人不需要接手每一个中间步骤主要负责确认方案有没有偏离目标以及最终结果是不是自己真正想要的。不懂开发的人能不能做出产品一个完全不懂软件开发的人也可以通过 Vibe Coding 做出网站、App 或者小程序。网上经常可以看到“不会写代码几个小时做出一个产品”这样的标题。按照现在 AI 的能力在需求简单、使用现成服务的情况下几个小时确实可以做出几个页面、接入数据库、实现登录和基本的增删改查再把它部署到云平台。不过这时得到的通常只是一个用于演示的 Demo。等真正有人开始使用后就会发现 Demo 和产品的差别。比如用户重复点击后生成了两条数据网络中断后页面和后台的状态对不上更新功能后原来的数据无法正常读取。这时做产品的人就得去查日志、核对数据弄清楚问题出在哪一步。小项目不一定需要一开始就搭建完整的监控和告警系统可以先保留必要的日志定期备份数据并确保发布出错后有办法恢复。等用户数量增加或者某类故障开始频繁出现再根据实际情况补充对应的工具和流程。一个原本不懂开发的人如果能在真实使用中发现并解决这些问题也会逐渐接触到测试、部署、故障排查和数据维护而不只是让 AI 把功能生成出来。AI 时代更需要软件工程即使大模型能处理的上下文越来越多也很难自动获取项目需要的全部信息。有些资料没有写进仓库有些文档已经过期AI 也可能找不到与当前任务真正相关的内容。在这些情况下它可能会重复实现已有功能或者修改公共逻辑时遗漏其他受到影响的模块。现在很多工作都可以让 AI 自己完成但前提是它能看到足够的项目信息和业务信息。如果某条规则只在会议里讨论过或者只存在于某个人的记忆里而 AI 不了解那么 AI 就可能按照自己的理解补全最后做出一个能运行但不符合需求的功能。哪些信息应该补进项目哪些功能还需要人工验收要根据实际风险来决定。如果希望 AI 不只是生成代码而是能够自己完成探索、实现、测试和修改项目本身也要为这种工作方式做一些调整。现在常说的 Harness Engineering关注的就是这些问题AI 能看到哪些上下文可以使用哪些工具怎样运行项目和测试必须遵守哪些约束失败以后怎样得到反馈并继续修改。模型能力很重要但只靠临时写一段更长的 Prompt并不能解决这些问题。项目里的文档、开发脚本、测试、日志、浏览器工具、权限限制和 CI共同决定了 AI 能不能把一项任务真正做完。用可交互 Demo 确认需求Vibe Coding 改变的不只是程序员写代码的方式也在改变产品、设计、开发和测试之间的协作方式。以前产品经理编写需求文档设计师制作原型和视觉稿开发人员再根据这些内容实现功能。需求文档和设计稿可以描述页面结构和主要流程但很难完整展示操作中的状态变化。例如表单提交失败后是否保留输入内容、重复点击是否会产生多次请求、加载和空数据状态怎样切换通常要在页面可以实际操作后才能确认。现在产品经理可以借助 AI 快速制作可交互的 Demo把需求文档中的流程提前做出来。团队可以直接体验页面跳转、表单操作和各种状态再根据实际效果修改需求。相比只看文档和设计稿这种方式更容易发现流程是否顺畅、信息是否完整以及有哪些情况没有考虑到。设计师也可以使用 AI 快速生成不同的页面方案再根据产品定位和使用场景继续调整。等主要流程和需求边界确认以后可以让 Coding Agent 根据 Demo 和相关文档进行正式开发团队再根据验收条件检查最终结果。Demo 主要用来确认需求和交互不能直接代替正式开发。正式开发仍然要结合现有项目处理权限、数据校验、异常流程和兼容性等问题。把项目规则写进文档同一个功能在不同项目里的写法可能完全不一样。有的项目要求所有接口都返回统一的数据格式例如{ code, message, data }有的项目则直接返回业务数据发生错误时再使用另一套错误响应格式。有的项目允许在 Controller 中查询数据库有的项目则规定所有数据库操作都必须放在 Service 或 Repository 中。开发者长期参与项目以后通常知道当前项目应该遵守哪套规则。但 AI 不一定了解这些背景。如果没有相关上下文它可能会在探索和实现过程中做出错误假设导致功能虽然可以运行但代码风格却和项目原来的写法不一致。为了减少这种情况团队最好把这些规则写下来包括目录怎样划分、文件和变量怎样命名、接口怎样返回错误、日志需要记录哪些信息以及新增功能需要补充哪些测试。通用规则可以放在AGENTS.md或项目文档中让 AI 在修改代码前先读取这些内容。除了通用规范项目中的业务背景也需要适当记录下来。项目代码是长期迭代出来的有些看起来不太合理的逻辑背后可能有具体的业务原因也可能是为了处理以前出现过的问题。这些信息如果没有留下记录后来维护代码的人很难知道当初为什么这样写AI 也容易误删仍然有用的逻辑。可以在模块目录下放一份README.md简单说明当前目录的作用、包含哪些模块以及模块之间怎样分工。例如一个常见的 Web 项目会把接收请求、处理业务规则和读写数据库拆到不同模块中。README 可以说明当前目录负责哪一步、会调用哪些模块以及哪些逻辑不应该放在这里。每次 PR 合并后可以让 AI 根据代码改动更新对应目录的README.md再由提交者检查内容是否准确。这样能够降低文档维护成本也更容易让文档跟上代码变化。把重要规则变成自动检查把规则写进文档只是第一步。AI 可能漏看某条规则也可能看到了却理解错误。如果一条规则必须长期遵守最好再通过测试和工具进行限制。例如项目规定 Controller 不能直接访问 Repository。除了在文档里说明还可以增加架构测试或 Lint 规则。以后无论是 AI 还是人写出了不符合要求的代码CI 都会直接失败。如果错误信息还能说明应该通过哪个模块访问AI 就可以根据反馈继续修改。每次 Review 发现 AI 犯错时也可以多想一步。如果是因为缺少业务背景可以更新项目文档如果某种错误反复出现可以增加测试、类型约束或 Lint如果某类任务总要执行相同的步骤可以整理成脚本或固定流程。这样一次 Review 不只是修正当前代码也会让后面的开发流程更可靠。随着项目里的文档、工具和自动检查不断完善AI 能够独立完成的工作也会越来越多。把 UI 规范整理清楚多人同时使用 AI 开发前端页面时很容易出现 UI 风格不统一的问题。如果项目里没有明确的设计规范模型只能根据当前需求自行选择布局和样式。不同人分别生成的页面很可能按钮大小不同、表格间距不同甚至连弹窗、表单和操作区的布局都不一致。团队可以把常用组件和页面规则写清楚包括字体大小、颜色、间距、圆角、按钮类型、表单布局、表格样式、弹窗宽度以及加载、空数据和错误状态应该怎样展示。例如新增和编辑页面使用抽屉还是弹窗危险操作使用什么颜色删除前是否需要二次确认表格操作按钮放在哪里这些都可以提前确定。如果项目已经有组件库可以让 AI 开发页面前先查找仓库中已有的组件和相似页面能复用就不要重新实现同时参考现有页面的布局和样式让新页面保持原来的 UI 风格。PR 要容易评审一个 PR代码合并请求最好只完成一件事不要把业务功能、代码重构和性能优化混在一起。例如需求只是给订单列表增加一个“退款状态”筛选条件正常情况下只需要修改查询参数、后端接口和页面筛选项。但 Agent 执行任务时可能顺便重构了查询方法、修改了其他页面的筛选组件或者重新格式化了一批文件。最后一个很小的需求变成了多个文件的大范围改动。评审者既要确认退款筛选是否正确又要检查那些额外修改会不会影响原来的功能。遇到这种情况最好删掉与当前需求无关的改动确实需要的重构则单独放到另一个 PR 中。PR 的范围越清楚评审者就越容易理解这次修改的目的也越容易发现真正重要的问题。大型重构也不要一次改完可以拆成几个能够单独理解、验证和回滚的 PR。这样其中一步出现问题时不需要撤回全部改动。现在我通常会先让 AI 根据需求和代码 diff 检查一遍看看有没有无关改动、遗漏的异常场景或者可能影响其他模块的地方。低风险修改可以根据它提供的验证结果和最终效果来判断涉及核心业务和高风险模块时再由开发者结合业务和现有代码进行 Review。测试不能只根据实现来写让 AI 写完业务代码后再让它根据这段代码生成测试是一种很常见的做法。但如果 AI 看到的只有实现代码它写出来的测试往往只是在验证这段代码当前的行为。例如订单退款后应该进入refunded状态但代码错误地把状态更新成了completed。如果让 AI 直接根据这段实现补测试它很可能也会断言结果是completed。测试虽然通过了但业务逻辑却是错的。因此在生成测试之前还要把需求和验收条件告诉 AI。订单在什么情况下可以退款、已经发货的订单怎样处理这些规则都应该一起提供给 AI再让它生成测试。除了正常流程还要根据功能补充异常场景。例如用户可能连续点击多次提交按钮第三方接口也可能超时。测试需要根据实际业务来判断应该覆盖哪些情况不能只看现有代码写了什么。普通业务逻辑需要有单元测试核心流程和其中长期稳定的关键规则还要用端到端E2E测试覆盖。每次部署到测试环境或生产环境前都跑一遍确认主要流程仍然可以从头走通。这样也能在发布前多一道检查。AI 自己验证以后人还要验收这里需要区分两种不同的验证。第一种是 AI 对自己实现的验证。它可以运行单元测试、E2E、Type Check 和 Lint也可以启动项目、操作浏览器、查看截图和日志。发现问题后继续修改再重新运行这些检查。相比写完代码后只说一句“已经完成”这种方式更可靠也能减少人工排查一些低级问题的时间。第二种是人对最终结果的验收。它要确认的不是“代码是否符合 AI 对需求的理解”而是“AI 的理解本身是否正确”。前面退款状态的例子里如果 AI 一开始就理解错了业务规则它可能同时写出错误的实现和错误的测试最后所有检查都通过但功能仍然不符合真实需求。所以AI 自己验证和人工验收是两回事。对于影响较小、容易恢复并且有明确自动验收条件的修改可以主要检查最终效果如果 CI、监控和回滚机制也足够可靠还可以直接合并。对于支付、权限、数据迁移和核心业务规则仍然需要人工仔细验收。高风险代码要重点审核不同代码出错后造成的影响不同审核时也不能采用同样的标准。修改按钮颜色或者页面间距只需要确认页面显示正常。新增查询条件、调整表单字段这类影响范围较小的改动主要检查是否符合需求以及有没有影响原来的功能。支付、权限、金额计算、数据库迁移和生产环境配置则需要检查得更仔细。审核这类代码时要确认数据会怎样变化执行失败后能不能恢复重复执行会不会产生问题以及这次修改会影响哪些已有功能。支付就是这类高风险功能。支付流程通常会涉及回调处理、订单状态更新和发货等多个环节。支付平台有时会重复发送同一个回调因此回调处理需要保证幂等避免同一笔订单被重复记账或者重复发货。订单状态和发货记录如果需要一起更新还要考虑其中一步执行失败后怎么处理。支付成功后可能继续触发通知或者奖励发放某个环节失败以后需要确定是重新执行整个流程还是只重试失败的部分。后续发生退款时还要结合原来的支付记录、订单状态和发货结果继续处理。商品是否已经发出、奖励是否已经发放都会影响退款流程。相关逻辑通常分散在多个模块中开发时需要把整个流程和状态变化一起梳理。为了保证支付流程可靠开发时需要处理幂等、事务、重试和补偿并通过测试验证不同状态下的结果。功能上线以后还要通过日志和监控确认回调、状态更新和后续任务是否正常执行。团队可以提前列出高风险模块并明确对应的审核人员。这些代码无论是手写的还是 AI 生成的都要有人批准合并并对上线后的结果负责。低风险修改则可以在自动验证足够可靠以后逐步减少人工检查。先把单个 Agent 跑顺再考虑并行当一个 Agent 已经能够比较稳定地完成需求分析、代码修改和验证以后还可以同时运行多个 Agent分别处理不同的需求。配合独立的分支或 Worktree一个人可以同时推进几个互不影响的任务。不过并行的 Agent 越多任务拆分、代码冲突和最终整合的成本也越高。如果几个 Agent 同时修改相同模块或者大家都建立在同一个错误假设上最后可能需要花更多时间收拾结果。所以并行不是越多越好。更合理的顺序是先把单个 Agent 的工作流程和验证方式建立好再从少量、边界清楚的任务开始并行。如果连一个 Agent 的结果都不能可靠验证增加更多 Agent 只会让错误产生得更快。程序员以后应该提升什么能力理解业务和产品在过去的软件开发流程中最常见的分工是产品经理编写需求、设计师负责出图、程序员负责实现。在这种协作方式下程序员更多关注的是怎么实现只需要按照需求完成对应的功能。现在 AI 已经能够根据明确的需求完成功能实现单纯把需求转换成代码的能力已经不像以前那样稀缺了。程序员需要更多地参与需求分析理解功能背后的目的并判断当前方案是否真的能解决问题。例如当产品经理提出增加签到功能时可以先问清楚签到的目的是什么。是希望用户每天打开应用还是希望已经离开的用户重新回来目标不同后面的方案也会不同。如果输入给 AI 的内容只有“开发一个签到功能”模型会直接生成签到页面、签到接口和奖励逻辑。至于用户为什么不活跃、签到能不能改善活跃度以及有没有更简单的办法仍然需要团队自己分析。签到能不能提高活跃度光靠讨论也很难确定。可以先看看现有数据找一些用户了解他们为什么不再使用或者先做一个小范围版本观察实际效果后再决定是否继续投入。目标问清楚以后还要继续确认功能边界。以签到功能为例哪些用户可以签到、是否支持补签、奖励发放失败后怎么处理都需要在开发前确定。需求文档如果没有写到这些内容开发时还是得一项项确认。这些信息没有写清楚AI 就会按照自己的理解进行补充。有时它的理解符合项目要求有时却可能偏离实际需求。给 AI 描述任务时也不一定要把每一个实现步骤都规定好例如要求它必须修改哪个文件、调用哪个函数。只要项目边界比较清楚更重要的是告诉它目标是什么、有哪些限制、怎样才算完成以及最后要按照什么条件验收。具体怎样查找代码和完成实现可以先让 AI 自己探索。不过这也不代表只说一句“帮我做一个签到功能”就够了。实现步骤可以交给 AI需求目标、业务规则和验收条件仍然要尽量写清楚。判断方案和控制风险让 Agent 完成开发任务时程序员还要判断它给出的方案是否适合当前项目。例如用户提交表单后需要发送一条通知AI 可能会建议接入消息队列把通知发送和失败重试放到异步任务中。这种做法适合请求量较大、不能阻塞主流程的场景。但如果当前请求很少发送失败后直接重试就能满足需求引入消息队列反而增加了部署和维护工作。项目发展到一定规模以后消息队列可能确实有必要。但当前阶段是否需要使用要看请求量、失败后的影响以及团队有没有能力维护这套系统。方案确定以后还要继续检查它会带来哪些风险。例如增加了哪些依赖修改失败后能不能恢复上线以后怎样观察运行情况。把这些问题提前考虑清楚后面的开发和维护会轻松很多。提升审美AI 生成的 UI 很容易出现千篇一律的问题例如重复使用渐变色、圆角卡片、大标题和数据面板。即使换一个项目最后生成的 UI 仍然可能是相似的风格。所以程序员还需要具备基本的视觉判断能力。页面完成后要对照设计稿检查布局、组件尺寸、间距、字体和颜色再实际操作一遍确认弹窗、表单校验和加载状态是否符合设计。AI 能提高学习效率但不能代替练习除了写代码AI 对学习新知识的帮助也很大。以前接触一个陌生领域时通常要自己搜索资料再从官方文档、博客和问答网站里查找相关内容。遇到一个具体问题时可能需要同时了解几个不同的概念再把这些信息组合起来才能找到合适的解决方法。现在可以先问 AI让它解释基本概念、说明不同做法分别适合什么场景或者根据当前的问题列出需要了解的知识。遇到不理解的地方也可以继续追问不需要每次都重新搜索。我以前刚开始做后端开发时对很多后端和云服务方面的知识都不熟悉。遇到 AWS 容器化部署、S3、Route 53 和 DNS 解析之类的问题时经常需要同时查阅几份文档。官方文档虽然写得很完整但刚接触这些服务时我也很难判断应该先看哪一部分。现在再遇到类似问题我会先把目标、运行环境和报错信息发给 AI让它帮我分析可能的原因和排查顺序。这样可以少走很多弯路不用一开始就盲目搜索。不过这种方便也容易让人产生一种已经学会了的感觉。这和看教程差不多。看别人操作时总觉得每一步都懂等关掉教程自己动手时才发现很多地方还是不会。AI 可以帮助我们查资料、解释概念也可以在遇到问题时提供思路但最后还是要自己实现和调试。我以前学习新知识时经常会问自己三个问题它是什么为什么要这样做可以不这样做吗有没有更好的方式现在这些问题都可以拿去问 AI不过不能只看它给出的答案。还要自己试一下看看它说得对不对放到实际项目里能不能用。保留编码和调试能力程序员仍然需要保留编码和调试能力。平时亲自参与编码和调试可以帮助程序员熟悉模块之间的调用关系理解状态是怎样变化的也能积累故障排查经验。有了这些经验再检查 AI 生成的代码时就更容易发现其中的问题。初学者使用 AI 时最需要注意的是黑盒问题。如果看不懂生成的代码只知道它可以运行那么这段代码对自己来说就是一个黑盒。项目出现问题后既不知道原因在哪里也不知道应该修改哪一部分只能继续把报错发给 AI再用新生成的代码替换原来的实现。这种方式用得多了代码很容易越改越乱。当前的报错消失以后新的修改又可能影响其他模块。由于不清楚每次改动的原因后面即使发现问题也很难判断哪些代码应该保留哪些代码应该撤回。平时可以自己做一些感兴趣的小项目也可以刷刷 LeetCode。在不用 AI 的情况下自己把代码写完并解决其中的问题可以避免长期依赖 AI 以后连基本的编码和调试都不知道该怎么下手。工作中的大部分代码可以交给 AI 完成不需要每次都逐行检查。但对于关键模块和高风险改动自己仍然要能看懂主要逻辑也要知道它为什么这样改。AI 连续修改几次都没有解决问题时程序员还得能够自己继续排查。了解 AI 工程应用程序员还需要了解一些 AI 工程应用方面的知识。大多数应用开发者不需要训练大模型也不需要深入研究底层算法。平时可以先了解 RAG、Tool Calling、AI Agent 和结构化输出等技术知道它们分别适合解决什么问题。以后很多软件可能都会加入智能搜索、文档问答、内容生成和自动执行任务等功能。程序员需要了解这些功能怎样接入现有系统以及接入过程中要处理哪些问题。例如AI Agent 在读取文件、发送邮件或者操作数据库时只能获得当前任务需要的权限不能访问无关数据也不能执行超出范围的操作。模型返回的数据也不能直接使用。即使要求它返回 JSON系统仍然要检查字段类型、取值范围和业务规则。遇到模型超时、返回错误或者结果不完整时程序也要有对应的处理方式。还要考虑提示词注入、敏感数据泄露、调用成本、重试策略和结果追踪等问题。这些都属于 AI 功能接入真实系统以后必须处理的工程问题。产品工程师和技术专家AI 的出现会让更多程序员有机会成为产品工程师。产品工程师通常在某一项技术上有足够的深度同时也能够参与产品、设计、前后端、测试、部署和运营。遇到一个需求时他可以从问题分析开始一直跟到功能上线和用户反馈。在过去一个程序员可能因为不懂设计、后端或者部署很难独立做出一个完整产品。现在他可以让 Agent 探索自己不熟悉的部分完成方案、实现和验证再由自己判断最终结果把想法更快地变成可以使用的产品。产品工程师仍然需要和产品经理、设计师、测试人员协作。区别在于他会关注完整的交付过程从业务目标、方案设计一直跟到上线和用户反馈不会在完成自己负责的代码后就结束。技术专家也会长期存在。数据库、编译器、分布式系统、安全和基础设施等领域依然需要长期研究特定问题的技术专家。这些领域往往涉及复杂的性能、可靠性和安全问题需要根据系统的实际运行情况长期分析和验证不是把代码生成出来就算解决了。AI 更擅长处理规则明确、重复性较高的任务。按照现有页面增加一个相似的管理页面或者按照固定格式补一组接口这类工作已经可以交给 AI 完成大部分内容。但真实项目中的方案不能只看代码能不能生成还要判断它是否符合业务目标、能否接入现有系统以及团队能不能长期维护。产品工程师需要决定功能应该怎样做技术专家则要解决性能、可靠性和安全方面的问题。这两种方向都会长期存在。总结Vibe Coding 已经明显改变了程序员的工作方式。无论是在现有项目中增加功能、修改业务逻辑还是排查问题AI 都可以参与需求分析、方案讨论、代码修改和测试。现在的 Coding Agent 还可以自己探索项目、运行程序、发现问题并继续修改AI 的角色正在从代码生成工具变成能够执行完整任务的 Agent。以后程序员可能不再需要花那么多时间直接编写代码但仍要把需求想清楚判断方案是否适合项目并对最终的改动和运行结果负责。提高 AI 开发效率的关键也不再只是怎样写好一次 Prompt。团队还要把业务知识、项目规则、测试方法和运行工具整理好让 AI 知道应该做什么也能够自己判断有没有做对。AI 每次犯错以后如果能把对应经验继续补充到文档、测试和工具中后面的工作就会更可靠。代码可以交给 AI 完成。哪些修改可以在自动验证后直接合并哪些必须经过人工验收以及上线后出现问题应该怎样处理要由程序员和团队根据风险提前确定。