AI编码的一些体会

发布于 | 分类于 杂项|本文包含AIGC内容

从 2023 年开始，我每年都会写一篇与 AI 有关的文章，记录自己在当时阶段对 AI 的认识和实际使用感受。

2023 年的《初识 ChatGPT》主要是在了解 ChatGPT、AIGC 和大语言模型等基本概念；2024 年的《我对于 AIGC 的一些看法》讨论了 AIGC 的理解与创作能力，以及它可能带来的影响；2025 年的《一个 AI 独立完成的游戏自动化脚本》则记录了第一次让 AI 基本独立完成一个实际项目的过程。

到了今年，AI 已经从问答和辅助编码工具，逐渐变成可以持续读取项目、修改代码和执行任务的 Agent。这篇文章是这组年度记录的第四篇，关注点也从“AI 能不能写代码”转向了“人应该如何与 AI 一起完成工程开发”。

现在已经没有必要再质疑 AI 能不能参与实际开发了。至少在代码生成、局部修改、调研验证和问题排查等任务上，它已经具备明确的实用价值。

但 AI 能不能替代开发者，是我今年一直在思考的问题。

AI 改变的不只是编码方式 ​

过去自己写代码时，我一般不会在动手前完成所有设计。明确需求之后先开始编码，目录分层、代码组织、模块设计和 API 形态，会随着实现逐步调整。这个过程看起来不够严谨，但人在持续参与，也会不断修正自己对需求和代码的理解。

使用 AI 开发之后，如果仍然沿用这种方式，情况会有所不同。需求分析、方案权衡和实现细节都可能由 AI 连续完成，而开发者缺少亲自推演的过程。如果自己既没有完整理解需求，也没有明确的预期，很容易在代码能够运行后直接接受结果。

因此，拿到需求之后，仍然需要由人完成分析和设计。必要时可以先写流程、伪代码或接口草案，把目标、边界和整体结构想清楚，再让 AI 实现。想到什么就让 AI 做什么，往往会带来反复返工，浪费时间和 Token，最终效果也未必理想。

这并不意味着每个需求都要先写一套很长的文档。文档只是承载思考的方式，关键是开发者是否真正理解了要解决的问题。

AI 适合做什么 ​

快速验证想法 ​

AI 很适合编写 Demo。例如调研组件库的用法、验证某个 API、复现边界场景，或者比较几种技术方案，都可以交给 AI。此类任务目标明确、范围有限，即使实现需要推翻，成本也不会太高。

实现边界清晰的模块 ​

我有一个 CLI 项目，包含一整套运行时微前端工程化的 dev、build 命令，并内置了不少 Webpack、Babel 和 PostCSS 插件。其中很多代码都是 AI 写的。

例如实现一个 Webpack 插件时，我会提出具体需求和约束，再让 AI 完成实现。插件本身可能很繁复，但它在整体流程中边界清晰、功能内聚。即使 AI 生成的代码存在问题，影响范围也能被控制在一个较小的模块内。与此同时，CLI 的整体流程和关键节点仍然由我掌握，所以我对这个项目是有底气的。

我目前更愿意把以下工作交给 AI：

  • 边界明确、可以独立验证的实现；
  • 重复、繁琐但决策密度较低的工作；
  • 用于调研和探索的 Demo；
  • 整体结构已经确定后的局部细节。

任务类型决定 AI 的收益 ​

讨论 AI 能否提高开发效率，不能脱离具体任务。一个目标明确、上下文有限、结果容易验证的任务，与一个涉及多个系统、依赖大量隐性知识的业务需求，对 AI 来说并不是同一类问题。

可以从几个维度判断一个任务适不适合交给 AI：

判断维度更适合交给 AI更需要人掌控
上下文范围单文件、单模块跨系统、跨团队
验证方式有明确的类型、测试或运行结果正确性依赖业务判断
错误影响容易回滚，影响范围有限涉及数据、安全、资金或核心流程
需求状态目标和边界已经明确需求本身仍在探索
知识来源可以从代码和文档中获得依赖大量未记录的团队经验

任务越靠近左侧，AI 越容易带来直接收益；越靠近右侧，理解上下文、制定方案和验证结果所占的成本就越高。

完整业务需求为什么更困难 ​

如果把一个完整的业务需求交给 AI Agent，代码通常不会完全符合开发者心中的理想形态。问题在于，如果开发者自己也没有明确想法，看到生成结果似乎可以运行、验证也能通过，就很容易直接合并。

对于目标明确、上下文有限的任务，短期效率通常能够提高。但对于成熟代码库中的复杂任务，理解、验证和返工成本可能抵消代码生成带来的收益。

现有研究也呈现出这种差异。一项 GitHub Copilot 对照实验中，参与者完成固定 JavaScript HTTP Server 任务的速度提高了 55.8%；但 METR 在 2025 年初对熟悉成熟代码库的开源开发者进行实验时，AI 工具反而让任务完成时间增加了 19%。METR 后来又指出，随着 Agent 普及，并行工作、任务选择和参与者选择偏差让生产率变得更难测量。这些结果不能直接代表所有开发场景，但至少说明“AI 是否提效”没有脱离任务类型的统一答案。

从长期看，每一轮生成代码的风格和设计思路也可能不同，局部合理并不等于整体合理。更严重的情况是，没有任何一名工程师真正熟悉某个阶段、某个模块的代码，后续维护和排查问题都会变得困难。

相关研究：

一个简单的例子是：前一轮 Agent 封装了一个不错的 API，但开发者没有记住，知识库也没有更新。几轮之后，另一个 Agent 又实现了一套类似功能，代码的冗余就会越来越高。问题并不在于使用了哪个模型，而在于项目缺少稳定的模块边界、能力检索和知识更新机制。

过度设计与防御性编程 ​

在我的使用经验中，缺少明确约束时，AI 生成的代码还容易出现过度设计。一个功能函数可能拥有很多参数，远超当前需求真正需要的范围。这些扩展能力也许考虑得很全面，但开发者此前没有想过，也没有明确需要，只是看到之后觉得“以后可能有用”，便一起合并了。

这些设计未必一定有问题，但它们不符合从最小功能开始演进的原则。每个多出来的参数、分支和抽象，都会成为后续需要理解和维护的内容。

编码风格需要明确约束 ​

开发者还需要向 AI 明确表达自己偏好的编码风格和设计原则，不能让它完全自由发挥。

例如，在缺少项目约束时，AI 可能生成大而全的组件，而项目更强调数据、展示和业务逻辑的分离。在前端这类实现方式较为灵活的代码中，明确约束尤其重要。否则，不同轮次生成的代码会逐渐形成不同的结构和风格，最终影响整体维护性。

文档不能代替理解 ​

为了让 AI 一次完成需求，现在常见的做法是先进行需求拆解、需求设计和概要设计，把结果落到 Markdown 文档中，再交给 AI 编码。这些文档有其必要性，但文档存在并不代表开发者已经完成了思考。

人有可能没有认真读完文档，也没有真正理解需求，只是运行几条 Prompt、调用几个 Skill，就让 AI 继续完成下一步。这样生成的代码可能不符合预期，而开发者因为缺少对需求和方案的理解，在 Code Review 时也很难识别关键问题。

文档还有时效性问题。如果设计文档、知识库和代码分别由不同流程更新，它们很容易逐渐偏离。对于关键决策，除了生成文档，还需要明确哪个位置是事实来源、由谁维护、代码变更后如何同步。否则，文档越多，AI 能读取的过期信息也越多。

我们现在有一套较完整的 AI 需求开发流程：产品把 AI 输出的需求文档提交到对应 Git 分支，开发人员拉取分支，生成需求设计和概要设计，完成评审后拆分开发任务，再由 AI 编码，最后进行人工检查、验证和提测。

按照流程，开发人员重点参与概要设计和评审。但当需求涉及前后端多个模块，而负责人又不熟悉相关代码时，就很难判断设计是否正确。AI 可以快速总结一个模块，却无法替代人理解和消化信息的过程。人的大脑无法在短时间内接收全部上下文，即使读完总结，也仍然需要时间建立对代码的认识。

如果这个过程没有完成，开发者心里就是虚的：无法判断 AI 的设计是否合理，也很难在后续阶段有效检查它的实现。

验证同样存在这个问题。现在前后端可能由同一个人配合 AI 完成。如果开发者不了解后端的数据构造方式和处理流程，就要先花时间熟悉它。AI 可以帮忙生成 SQL、提供 curl 命令，或者触发定时任务，但这些操作仍然包含决策，开发者也无法默认 AI 给出的答案全部正确。

“人负责决策，AI 负责开发”听起来很合理，但它有一个前提：人必须理解项目上下文。在一些采用 Agent 的团队中，前后端分工开始变得模糊，而并非所有开发者都具备全栈、跨技术栈和架构能力，这也是现阶段 AI 工程实践中一个真实的困难。

生成速度不等于交付效率 ​

AI 直接降低的是部分代码的生成成本，但需求澄清、方案评审、结果验证、跨端联调、发布和维护成本不会同步归零。评价 AI 带来的效率时，应该衡量从需求开始到稳定交付的完整周期，而不是只比较写代码用了多久。

DORA 的研究也体现了这种区别：更高的 AI 使用率与交付吞吐量提高相关，同时也与交付不稳定性上升相关。AI 能够更快地产生更多改动，团队仍然需要通过自动化测试、快速反馈、较小的变更批次和可靠的回滚机制控制风险。

相关研究：DORA：Balancing AI tensions

掌控感从哪里来 ​

我在 B 站的一个视频 下看到过一段评论。评论者提到，用 AI 做工程时，需要不断阅读 AI 生成的文档和代码；当测试提出大量边界问题后，自己却不了解具体实现，只能反复把复现步骤交给 Agent，等待它定位和修复。随着交付时间临近，这种无法判断问题所在的状态会让人越来越焦虑。

另一条回复提出，可以让 AI 实现细节，但人仍然需要了解功能的大致流程、数据流动方式和整体框架。当 AI 长时间无法修复问题时，人应该回到代码中定位原因，再指出具体问题让 AI 修改。

这两段讨论涉及的核心，其实是开发者对工程的掌控感。

如果一个需求从分析到实现全部由 AI 完成，人没有参与关键决策，就很难对结果有底气。如果人先制定整体框架，明确数据如何流动、模块如何协作，再让 AI 实现局部细节，那么即使出现问题，也能大致判断问题位于哪个节点。

这里的“掌控”并不等于逐行手写或逐行审查所有代码。对于影响范围有限的细节，可以依靠类型检查、测试和运行结果进行验证；但对于流程、边界和关键决策，人需要保持理解。

对我来说，能否回答下面几个问题，是判断自己是否真正掌握一个需求的基本标准：

  • 数据从哪里来，经过哪些模块，最终写到哪里；
  • 哪些接口、状态和副作用会受到影响；
  • 核心流程有哪些失败路径；
  • 出现问题时，应该先检查哪个节点；
  • 哪些结果由类型和测试保证，哪些必须人工判断；
  • 发布后如何观察效果，发生故障时如何回滚。

如果这些问题都无法回答，即使代码已经生成并通过了局部测试，我也很难认为这个需求已经处于可控状态。

不要放弃自己的思考 ​

回头来看，AI 阅读项目上下文后输出的方案和流程，很多时候仍然不如我亲自梳理代码、思考后写出的设计。后者更符合我的预期，也能包含项目中约定俗成、但没有被明确记录的上下文。

这也是我所理解的“磨刀不误砍柴工”：前期多想一步，手动整理关键流程，通常比让 AI 一次生成、自己只做结果检查更可靠。至少到了提测阶段，不会连整体代码逻辑都无法说清楚。

不要把所有工作都交给 AI，尤其不要把思考本身全部交出去。有些问题自己暂时不知道如何处理，可以让 AI 提供方案或进行头脑风暴，但输出结果仍然需要由人阅读、理解，必要时还要通过 Demo 验证。

如果某一步没有理解，却继续让 AI 推进，后面的每一步都会建立在不确定之上。它很像上课时中途走神：前面的推导没有听懂，继续往后听，只会积累更多疑问。

现实的问题是，行业往往更关注交付效率、提效比例和节省了多少人力。学习基础知识、理解 AI 生成的代码，并不总是最容易被量化的工作。但如果长期忽略这些过程，开发者对项目的理解会逐渐减少，最终也会失去有效决策的基础。

什么都想快 ​

我自己的另一个明显感受是，使用 AI 之后更难静下心来只做一件事。开着多个 AI Agent，同时推进几个任务，看起来提高了并行度，实际却可能让人持续切换上下文，最终感到非常疲惫。

AI 可以扩展我不熟悉的领域，帮我快速建立起点；但在我熟悉的领域，如果它持续打断原有的思考过程，反而会形成干扰。

重复造轮子 ​

过去开发成本较高，需要一个功能或工具时，通常会先搜索已有产品，确认是否能够满足需求，无法满足时才考虑自己开发。

现在有了想法之后，很容易先让 AI 快速生成一个，自己维护、自己使用。对个人而言，这很方便；但从整体来看，也可能造成大量重复实现。

AI 降低了初次实现的成本，却不会自动消除依赖升级、安全修复、数据迁移、部署和长期维护成本。是否值得重新实现，仍然需要比较现有产品的采购与适配成本、自建工具的生命周期成本，以及未来停止使用时的退出成本。

当然，并不是所有重复实现都有问题。对于一次性脚本、个人 Demo 和用于学习的项目，快速生成一个可能就是成本最低的方案。真正需要警惕的是把临时工具逐渐投入核心流程，却没有重新评估它的维护责任和风险。

软件开发流程会走向哪里 ​

过去几十年形成的软件开发流程，并不能完全适配现在的 AI 开发，目前仍然处于探索阶段。未来可能出现两类变化：

  • 日抛型和个人定制型软件越来越多。对于这些软件，维护性和扩展性的优先级可能降低，软件更像一种即时消费品；
  • 出现类似瀑布和敏捷的新开发范式，对人和 AI 的分工、输入输出及质量责任形成更清晰的约束。

现阶段的困难，恰恰来自人和 AI 的边界还不清楚。

以上讨论中的 AI，都是基于当前的大语言模型。未来是否会出现具备更强自主性、可靠性和通用能力的 AGI，我无法判断。如果那一天到来，软件工程的开发方式可能还会再次发生很大变化。AGI 讨论的重点是能力范围和自主程度，并不在于系统是否使用概率模型。

基于目前的能力，我认为 AI 开发中最重要的仍然是把事情想清楚。整体流程和关键结构由人设计，确定性的部分掌握在自己手中；繁琐、局部或探索性的工作交给 AI，并把它生成代码的影响范围控制在清晰边界内。

如果需求理解、方案设计和架构决策全部交给 AI，而开发者自己也不熟悉最终结果，那么从任务执行的角度看，换一个人来操作 AI，可能并没有本质区别。

前端开发会走向哪里 ​

今年刚好是我从事前端开发的第十年。从最初的页面开发，到现在从事前端架构工作，前端岗位经历了很多变化。在 AI 编程的影响下，关于“前端是否还会存在”的讨论又多了起来。不过类似观点在 AI 出现之前就长期存在。

一种常见判断是，前后端都会变成全栈开发。在多数 Web 系统中，业务逻辑更多集中在后端，因此有人认为后端故障更可能造成线上事故，而前端问题通常更容易修复。但故障的严重程度取决于影响范围、数据是否可恢复、发布机制和降级能力，并不能简单地根据技术层判断。

前端同样存在需要长期积累的复杂场景。例如在不具备热更新能力，或者动态更新受到平台审核政策限制的 App 中，一个版本发布后，如果前端问题导致大面积闪退或崩溃，修复周期和影响程度都可能接近后端故障。Apple 的 App Review Guideline 2.5.2 也对下载、安装或执行能够改变 App 功能的代码作出了限制。

此外，可访问性、浏览器兼容、渲染性能、复杂交互、SSR 与 Hydration、多端容器、音视频和设计系统，都包含大量依赖具体运行环境的知识。AI 可以协助实现这些任务，但跨领域执行能力并不等于跨领域的专业判断能力。

相关规则：Apple App Review Guidelines

还有一种说法是，AI 时代将不再区分产品、设计、前端、后端和测试，所有人都会成为通才，从而减少沟通成本、提高交付效率。

我对此持保留态度。一个人的精力有限，很难同时深入掌握所有领域。现代软件开发之所以形成专业分工，是因为产品、设计、前端、后端和测试各自都有大量需要长期积累的知识。AI 可以降低跨领域工作的门槛，但不等于专业能力和分工会自然消失。

在一人公司或个人产品中，全栈模式完全可行。借助 AI，一个人可以快速把想法变成 Demo，甚至完成上线。但随着产品不断迭代、用户增多、问题持续暴露，一个人很难长期兼顾所有细节。

我目前认为，更可能出现的协作方式是专业团队规模缩小，同一方向的开发者借助 AI 承担比过去更多的工作，而不是让所有岗位直接合并为没有专业侧重的全栈角色。具体能够缩小到什么程度，取决于业务复杂度、质量要求和团队自身的工程能力，无法用一个固定比例衡量。

AI 会改变岗位数量、工作边界和协作方式，但专业分工仍然有其价值。

话虽如此 ​

上面这些担忧都建立在一个前提上：人仍然需要阅读和理解项目代码。

如果未来我们不再需要逐行理解 AI 生成的代码呢？如果软件可以由 AI 持续生成、验证、维护和替换，代码本身只是一种中间产物，那么现在关于可读性、维护性和掌控感的很多讨论，可能都需要重新审视。

不过，即使人不再直接理解每一段代码，也不意味着可以不理解系统。人的关注点可能会从具体实现转向可验证的需求和验收标准、系统行为、可观测性、安全与合规、发布与回滚，以及最终的责任归属。

因此，更准确的问题也许是：当代码成为机器生成的中间产物之后，人是否仍然需要理解系统行为，并对需求、验证标准和运行结果负责？

这个问题我还没有答案。

至少在当前阶段，我仍然认为：可以让 AI 扩展能力、加快实现，但不能放弃对问题的理解，也不能把关键思考和最终判断全部交出去。

#AI编码 #AIGC #软件工程

你要请我喝一杯奶茶？

版权声明：自由转载-非商用-保持署名和原文链接。

本站文章均为本人原创，参考文章我都会在文中进行声明，也请您转载时附上署名。