AI 编程（1）—— 开发模式的改变

2022 年 11 月，ChatGPT 的发布掀起了大语言模型（LLM）的普及浪潮。两年多过去，AI 编程已成为 LLM 应用最成熟、进展最迅猛的方向之一。从最初手动复制 ChatGPT 给出的代码到 Cursor Agent 全自动编码测试运行，人机协同编程的方式已经迭代了好几轮，AI 编程也已完全融入到我的开发工作流之中。

AI 可以提升效率，我花 20% 的时间和 AI 对话编程，它能解决我 80% 的问题，AI 给我带来 2x 甚至 5x 的效率提升。AI 也可以辅助思考，任何问题都可以为我做查漏补缺、延伸创造力。AI 甚至还有一种容易让人上瘾的魔力，它的每一次响应都像是抽盲盒一样，我可以一直期待 AI 会给我带来什么样的代码和答案。

我目前的开发模式已经严重依赖 AI，严重到会因为 AI 没有及时给我 Tab 建议而心生烦躁。有时在没有 AI 辅助的情况下，我甚至都不想写一行代码。可以稍微戏谑一下，这跟断网断电没啥区别，可以宣告原地下班了。

我目前 80% 的任务是可以和 AI 协同完成的：

• 代码编写
  • Demo/MVP 构建
  • 上下文代码补全
  • 脚本/工具编写
  • 命令补全
  • 语言转译
  • 单元测试编写
• 代码维护
  • 代码解释
  • 代码重构
  • Bug 定位/修复
  • 代码漏洞检测
• 信息获取
  • 解决方案搜索
  • API/SDK 文档查阅
  • 知识入门
  • 问题验证
• 需求设计
  • 技术选型
  • 架构对比
  • 原型图复刻
  • 简单任务拆解
  • 简单需求分析设计
  • 简单架构分析设计
• 逆向分析
  • 分析网络请求
  • 破解代码混淆
• 数据处理
  • 数据分析
  • 数据格式化
  • 数据构造
• 文档和流程
  • 文档编写
  • Git Commit 编写
  • Dockerfile/K8S/Helm 文件生成
• 更多其他灵光一闪的用法......

可以说，AI 几乎参与到我工作中的每个环节。

在 AI 辅助我完成任务的过程中，我也深深地意识到， AI 不只是在替我们完成一个个独立任务。在更高的维度上，它是在重构整个开发模式，它将会永久且不可逆地改变我的开发模式和思维。

这一篇，我将从一位后端开发者的视角，拆解 AI 是如何改变开发模式的。你会看到，开发中的每一个环节，都可能正在发生悄然但深刻的转变。

模式改变

代码生成 —— 0 到 1 的重构

以往脑子里总会蹦出一些点子，但真正落地的少之又少。不是不想做，而是卡在第一步：新领域不熟、实现成本高、工时太长…… 这些现实问题一次次打击了我的行动力，想法最终也都被搁置了。

即便有了行动，为了能构建 MVP 快速落地，我依然是需要手写代码的。复杂一点的还需要做技术选型和技术调研，稍不注意就陷入细节，离目标远了。这对光有想法不懂技术的同学来说会更加苦恼，「只差一个程序员」的抱怨不绝于耳。

想法的落地，最难的就是迈出从 0 到 1 这一步，毕竟万事开头难。从 到 2 到 3，甚至是无穷，反而没那么难。而借助 AI，我们能轻松得帮迈出这关键一步。

现在，任何人都可以把想法交给 Cursor，然后安静得坐在电脑前，看 Cursor 一顿输出，几分钟后一个符合你预期的应用就跑起来了，这个过程几乎是全自动的。这种体验就像是「赛博巫术」，第一次见的人无不惊叹。Cursor 也正因如此火出了技术圈。

这背后的核心，其实是它将强大的代码生成能力与极致的使用体验结合在了一起，让「从 0 到 1」真正变得轻而易举。

当然，目前通过 AI 生成的应用，多数仍停留在 Demo/MVP 层面，它仅在功能表现上看起来符合预期。如果产品足够简单，直接投入使用是没有问题的。反之，实际放出去给用户使用，或许还有很大的改进空间。至于后续项目的可维护性、健壮性，则取决于使用者运用 AI 能力的高低了。

不过，这已经很棒了，它已帮我们迈出最难的第一步了。

我用 AI 来实现如下的从 0 到 1 工作：

• [想法验证] 我能否通过 Chrome 插件实现一键采集当前页面的网络请求；
• [管理后台 MVP] 请分析一下服务端的代码仓库，为我搭建一个管理后台；
• [工具库思路] 请帮我实现一个结合配置文件、环境变量、命令行参数的配置解析库；
• [Demo 实验] 我想了解如何才能正确处理 gRPC 双向流的错误；
• [新知识学习] 请用 Todo List 示例为我展示一下前端技术的进化史；
• ......

我能借助 AI 达成如下目的：

• 执行力变强，它帮我迈出 0 到 1 最难的一步；
• 想法能以更低成本、更加快速地得到验证，技术不再可能是绊脚石；
• 无需前置的知识储备，关注业务价值，快速搭建 Demo/MVP；
• 脱离代码细节，更专注于知识验证和应用；
• 改变学习方式，最好的学习方式就是「Talk is cheap, Show me the code」；

AI 让从 0 到 1 变得轻而易举，也让我们真正有机会专注于最有价值的部分。现在不再是做或不做的问题，而是试或不试的问题。

一切皆可 AI 起步，开发的工作方式，正在悄然改变。现在你可以说：「从 0 到 1，只差一个 AI」了。

代码补全 —— 人机协同

结对编程，它是为了解决代码质量低、沟通不足、知识孤岛、开发效率低下等协作开发中的核心问题而提出的一种实践方法。

我最早是在大学的敏捷开发课程中了解过而已，工作这么多年以来，除了在查线上 Bug 时，同事在旁边指指点点外，我至今都还未认真实践过。或许真人结对编程已无缘，但人机结对编程 —— 人机协同，我每天都在经历。

在传统的代码编辑器中，基于 LSP 和 Code Snippets 的代码补全，就算是一种低阶版的人机协同。它只能根据语法进行代码补全，一定程度上能减少人为的低级错误和提升有限的效率。

但在现代的 AI 代码编辑器中，它支持更加先进的上下文代码补全能力，这使得人机协同得到了「从猿到人」的进化。它能做到根据你上下文代码的内容，识别出意图，进行模式匹配，最后帮你补齐代码。

可别小瞧了这 AI 上下文代码补全，它运用了 LLM 的能力和 RAG 技术，不仅能结合当前代码库的内容进行补全，还能给出全网最好的代码片段补全。

这相当于是给你安排了一个世界上最懂写代码的人（全栈 + 最佳实践 + 经验丰富）和你一起结对编程，它会边关注你输入的每个字符，边及时得给你最佳的补全建议。这可以说是把结对编程的理念发挥到了极致。

我在使用 Cursor 写代码时，最期待的事就是能触发「Tab 连招」。AI 能为我补全什么样的代码呢？这种未知很让人兴奋。

就目前而言，我对 AI 给出的补全建议采纳率可以到达 80+%。一方面是 AI 给出的逻辑是正确的，另一方面 AI 给出的代码实在是质量高。

相对于无 AI 的传统代码补全，我个人体感是起码少写 40% 左右的代码，这节省出来的时间几乎可以再做一倍的工作量。

有了 AI 人机协同，它能帮我完成：

• 繁琐枯燥的样板代码补全；
• 编写逻辑复杂的业务代码；
• 重构长代码，拆分成小模块；
• 合并可能出现性能问题的逻辑；
• 补全 API/SDK 的调用；
• 给出最佳实践的代码实现；
• 快速格式化代码片段；
• ......

它能帮我达成如下目的：

• 减轻枯燥感，把更多的精力放在核心的逻辑上；
• 写错索引值或引用的情况不再发生，减少人为的错误；
• 能主动发现隐藏的 Bug，减少 Bug 率；
• 减少 API/SDK 文档的查阅时间；
• Code Review 阶段前置，降低合并被打回的概率；
• 拥有最佳实践的代码，全方位提升代码质量；
• 心流状态不会被打断，更加专注当前的工作；

「人机协同」带来的远不止效率提升。更重要的是，它帮我把工作中那些重复机械的脏活累活给干了，它或许让我有机会再次看到编程应有的样子，它本是一个专注和富有创造力的过程。

不仅如此，「人机协同」还带来了即时的高质量代码注入能力，显著提升了行业整体的代码质量基线。专业经验和最佳实践被具象化成代码补全，并以极低成本在开发者之间传播复用，技术门槛不断降低，「技术民主化」正在快速发生。

人机协同，正在成为新时代的默认开发模式。

方案搜索 —— 内容聚合

在开发过程中，我们很大概率会遇到不熟悉或解决不了的问题，这个时候我们就需要借助搜索引擎或文档来查找解决方案了。

一个有效的方案解决过程一般包含这 6 个步骤：问题拆解 → 关键字搜索 → 筛选资料 → 分析对比 → 内容整合 → 代码实现。

前 3 个步骤是和搜索相关，主要途径是借助搜索引擎。用好搜索引擎是一门学问，能用好搜索引擎的程序员其实并不多。就不说 Google 和百度之间的内容差异了，在同 Google 搜索引擎下，会用和不会用，搜出的内容质量差别是很大的。可以说这也是某些中高程序员引以为傲的能力之一，擅用搜索引擎者可大幅提高解决问题的能力，也可以掌握大量信息差，走在一众同行前面。

而后 3 个步骤和内容整合相关，主要依赖程序员个人的经验和信息处理能力。首先就是要对多个解决方案进行评估，选择出适合当前上下文的方案。然后再从中提炼出核心逻辑，把分散的信息结构化。最后才是代码实现，把文字描述的方案转为工程化可以运行的代码。这 3 个步骤，既费时间，也耗脑力，也很依赖搜索内容质量。它们考验的是认知能力、判断力和工程实现能力，是中高级程序员长期积累的优势所在。

另外，文档查阅也是门技术活。大多数时候，官方文档是最可靠的来源，但也有不少信息混乱、结构不清、阅读体验极差的例外。不会查文档的人翻半天也找不到重点，而会的人不仅能迅速定位到 API/SDK 文档的用法，还能通过文档建立起对整个系统能力的整体认知，写出更系统化、更专业的解决方案。

可见，要想解决一个不懂的问题，对人的要求可不低。

而现在，AI 正在把这些原本需要经验和技巧才能完成的搜索、评估、整合、理解过程，转化为一种自动聚合、结构输出的新模式。

我目前使用 Google 和翻阅文档的频率已明显下降，AI 是真的太方便了：

• 不用再拆解、思考用哪个关键字进行搜索了，只需稍微组织一下语言和需求即可让 AI 完成搜索；
• 不用再逐个浏览链接内容后再自己做总结了，AI 直接把关键内容总结好，并给出解决方案；
• 在得到解决方案后，不用再自己去实现代码了，AI 能按照方案进行代码实现，供你进行补全；
• 方案有不懂的地方还能向 AI 提问，这放以前你留个评论等回复估计都得等个十天八天的；
• 不用从编码工具切换到搜索引擎，减少心流状态的脱离，专注解决问题；
• 文档可能没有给出的完整的代码示例，AI 可以完整给出。

AI 将官方文档、开源项目、社区讨论等分散知识，自动聚合、过滤、重组，转化为可直接执行的代码实现。

我们不再需要思考如何提取关键词和整合内容，而是直接把问题扔给 AI，然后对 AI 输出的结果做出判断、调整、确认即可。

AI 改变了搜索方式，也改变了解决问题的路径。解决一个技术问题，不再是信息处理的比拼，而是判断力的考验。

过去，谁掌握信息，谁效率更高。现在，谁理解更快，谁走得更远。搜索还在，但它已不是主角。

单元测试 —— 验证闭环的重建

编写单元测试的收益很高，不仅能保障代码逻辑的正确性，还能促进代码模块化、提升可维护性，并在修改后提供可靠的回归验证。而且，它还是一份「活文档」，帮助其他同事快速理解代码。

但更重要的是，单元测试是构建「验证闭环」的核心手段：每写一段逻辑，便有一组测试与之绑定。每次改动逻辑，测试立即验证其行为是否仍然正确。

这种「改动 → 验证 →反馈 → 修正」的循环，是一种理想的开发模式，它能够让我们在不断迭代中保持质量。

然而，单元测试好处多多，但写起来却不容易。首先要确保代码具备可测试性，这就要求代码要有良好的抽象和模块化设计，其次是要构造各种边界条件用例，非常考验编码功底，而且代码量要比源代码多 2 倍是一件很正常的事。

按理来说，编写单元测试是程序员日常工作的重要一环，但在国内快节奏的开发环境下，这件事反而成了负担。大多数时候，代码质量都交由测试团队来保障，单元测试毫无存在感。程序员的单元测试意识也逐渐淡化，其实也是挺无奈和可惜的。

在有了 AI 后，单元测试的编写变得容易多了。我只需向它提出测试需求，它会：

• 先评估代码的可测试性，并自动进行模块化重构；
• 然后通过「打表」的方式（构造输入输出映射）生成边界条件用例；
• 编写并运行单元测试，失败时自动修正逻辑，直至测试通过；
• 最后输出测试覆盖率报告。

整个过程并非总是一气呵成，偶尔仍需人工校正。但总的来说，它已经非常高效。

让 AI 编写单元测试，它能让我达成以下目的：

• 代码可维护性直线上升，AI 会自动对代码进行模块化和抽象；
• 代码质量更高了，搭配上 CI，每次改动会造成的 Bug 提前预知；
• 代码覆盖率轻松到 80% 以上，对代码质量信心倍增；
• 测试用例覆盖齐全，方便其他同事理解和交接代码；
• 测试代码也可作为文档示例，提升与团队的协作效率。

AI 让单元测试的编写变得更加高效，使它成为了一件「顺手就能完成」的事。不再需要额外推动，而是自然地融入到开发的日常节奏中。开发者只需写业务代码，代码质量也能同步得到保障，一举两得。

更重要的是，AI 让单元测试不再是补充动作，而是成为开发过程中持续存在的反馈机制，让验证循环真正得以流转和常态化。

逆向理解 —— 一切皆可黑盒

在日常开发中，真正消耗精力的活是处理各种黑盒。没人交接的旧项目、行为异常的第三方库、接口返回的奇怪响应、前端混淆后的 JS、甚至是自己三个月前写的代码。只要失去上下文，任何系统都有可能变成黑盒。

常见的黑盒大致分为两类：

• 代码理解型：理解他人或旧代码的结构与逻辑；
• 信息挖掘型：解析接口、协议或行为背后的隐藏规律。

面对这些黑盒任务，往往靠的是阅读文档、整理上下游关系、反复调试验证和人为推理。这个过程琐碎、信息割裂，效率极低，很多时候投入数小时依然抓不到重点。

但现在，AI 正在彻底改变我面对黑盒的方式。

只要有代码、日志、接口或请求报文，我就可以直接抛出问题，让 AI 反向推理出底层逻辑：

• 这个项目有实现短信发送的功能吗？都有哪些发送渠道？
• 这个接口什么情况下会返回 422 状态吗？
• 这个中间件逻辑的执行顺序是怎样的？
• 这个三方库为什么要用到策略模式？
• 帮我反解一下这段被混淆的 JS 代码？
• 猜测一下这个 API 的签名计算方式？
• 抓包接口的调用链和数据依赖关系是什么样的？
• 解读接口的字段结构、命名、返回值，尝试推测出字段的业务含义？
• 请用 mermaid 帮我生成流程图、时序图、类图？
• ......

这些提问往往很有效，不需要太多上下文，AI 就能把代码逻辑、调用链路、数据流向梳理得清清楚楚。它就像一个熟悉系统全貌的同事，能清楚得告诉你「为什么」。

在使用 AI 解决黑盒的过程中，我发现这其实是一种逆向工程式理解：从结果推导过程，从现象还原本质，从行为反向建模设计。

AI 赋予我们破解黑盒系统的能力。一切皆可黑盒，黑盒不再是障碍，而是入口。

需求拆解 —— 思维外包化

我们的开发任务都来自于明确的需求，如何让一个需求一步步变为一行行可执行代码的，这就需要我们非常清楚要做的是哪些具体的任务了。一般产品大多数时候是不懂技术边界内的知识的，都是直接把任务拆解丢给开发去完成，最后给个排期就行。需要自己做任务拆解是很常见的事情。

那么，当我们接到一个需求时，首先是把它读懂，再拆分成功能点，明确技术边界，划分模块职责，评估难点风险，排出开发顺序。这个过程听起来很自然，但其实也是个技术活。好的任务拆解应该一目了然，阶段目标明确，分工清晰，工时准确，风险可控，拆解出来的子任务具有连续性和可交付性。但如果拆得不好，问题可就多了，最突出的两点就是任务无从下手和缺乏阶段性产出，越做越迷茫。

任务拆解能力的差异，主要体现在如下几个方面：

• 是否真正把需求想明白，并明确最终目标；
• 是否能梳理出信息的全貌，明确已有资源与上下文条件；
• 是否具备阶段性输出意识，任务拆解是否具有连续性和可交付性；
• 是否考虑清楚异常路径，能否识别潜在风险和边界问题。

这个过程是极具挑战的，需要做很多工作和考量，要让上和下都满意，不是件容易的事。

因此，任务拆解被认为是一种典型的「人类独有能力」：我们要能从混乱的需求中抽象出结构，还要能对未知做出推演判断，这些似乎都超出了机器能胜任的范围。

但现在，AI 正在打破这个假设。它最大的优势在于：可以快速起草一个从多个角度提供结构化的拆解方案，并提示你遗漏的逻辑、边界或前置条件。

我经常让 AI 帮我完成这样的事情：

• 我想要整个账号系统的支持双活，请你帮我参考 OKR 制定的思路拆解一下目标；
• 我想开发一个 Chrome 插件，实现一键采集网页请求，你帮我列一下开发任务；
• 我需要做一个内部管理后台，请你列出基础功能模块；
• 能不能帮我把这项任务拆解成五个步骤，并标出每步的依赖关系；
• 需求只给 3 天时间，请帮我分阶段拆解这个需求；
• ......

大多数时候 AI 给出的答案还算清晰明确，并且还能提供一定的结构、优先级、建议实现方式，甚至补充一些我遗漏的点。

不过，AI 任务拆解仍然有很多局限性：

• 理解力不足，缺乏业务上下文；
• 拆解策略不稳定，同一个问题可能反复输出不同版本；
• 无法进行长线规划，拆出的路径大多停留在短期层面。

所以，在任务拆解这件事上，AI 只是协作者，起到辅助思考的作用。我不会直接照抄它的方案，但会将它作为参考起点，在它的结构之上再做调整。

这其实就是思维的外包。原本需要耗费大量精力的思考型工作，现在都可以交给 AI 先做一版。我们只需在此基础上进行修订和确认，效率提升的同时，思维压力也大幅减轻。

这不是让 AI 替我思考，而是借助它节省思考资源，把注意力集中在真正关键的判断和决策上。

架构设计 —— 策略聚合器

作为一名 10 年的服务端开发，经手过的架构设计少说也有十几个了。从 2015 年至今，火过的服务端技术我基本都线上实操过，单体转微服务、自建机房服务上云、单机部署转 K8S、服务改造转 Linkerd、各种高并发大流量系统、高可用系统、秒杀系统等等...... 期间踩过很多坑，也积累了不少的经验，深知架构设计最难的就是要因地制宜，最合适的，才是最好的。

如今都 2025 年了，常见架构就像是设计模式，早已经被人们给固化下来了。什么高并发架构、高可用架构，你只要一搜，相关的文章多如牛毛。但是，如果你真想套路一番，你就会发现更本就不能落地到你的业务。举个例子，就说做异地多活，网上的资料，阿里、美团给出的方案够厉害吧，Set 化架构，跨区域全球流量调度，数据实现实时同步，能保证全年 SLA 5 个 9。你想复刻做一套，你就会发现根本做不动，服务不具备条件、机房拓扑不合理、底层数据设计有问题..... 网上大厂架构案例顶多就是给你个思路，真正要做架构设计，还得是靠自己。

但正因为如此，架构设计不是照搬套路，而是策略组合 + 资源评估 + 目标博弈的综合平衡。

这其实是一件特别复杂的认知劳动：你需要评估上下文的环境、数据的流动、业务的发展阶段，还得统筹各模块之间的调用链路、数据一致性、流量模型、安全防护、成本预算等等…… 这压根不是从一堆架构图里选一个好看的就行了，而是从混沌中梳出逻辑，在不确定中寻找可行解。

过去每当我面临架构设计任务，通常要先：

• 从头梳理业务目标与边界；
• 整理已有系统与资源约束；
• 拉通核心模块的职责划分；
• 做几种架构草案的可行性分析；
• 和前后端、测试、安全、运维确认接口与边界。

每次设计都像脑内构造一套迷宫，有时甚至要画几张架构图才能看清核心流向。

但现在，AI 的加入让我拥有了一个不知疲倦、永不缺席的「架构合伙人」。

我经常会向 AI 抛出问题：

• 我需要一个高可用的订单系统，能否给我一个异地容灾架构？
• 当前系统需要支持 SaaS 多租户，推荐的租户隔离策略有哪些？
• 请基于我们的业务结构，梳理服务拆分建议及数据库设计注意点；
• 在功能增长迅速的情况下，如何对接入层进行灵活扩展？
• 对当前 Redis 使用方式是否有更合理的降级或备份策略？
• 请帮我整理下支持灰度发布的技术方案，并标出优缺点。

AI 给出的内容往往信息密度极高，不仅列出选项，还能归纳每个选项的适用场景、技术成本、维护风险，甚至引用开源项目和社区案例，让我在思考前就有了结构框架，在博弈时就有了对比维度。更重要的是，它能及时补盲、抛出我没注意的角落，防止局限于个人经验。

当然，AI 的建议也不是完美的：

• 有些方案表面合理，但缺乏足够落地细节；
• 方案有时过于模板化，无法给出因地制宜的建议；
• 评估维度可能存在遗漏，尤其是和业务耦合紧密的部分；
• 有些看似中立的结论，可能是训练数据偏差造成的「算法偏见」。

所以在架构选型这件事上，AI 更像是一个超级调研员 + 思维催化器，它帮我聚合资料、启发角度、补足盲区，但最终决策仍然需要我根据实际业务做出判断。这个过程我就像和一个策略专家在做头脑风暴。

AI 没有替我做决策，但它加快了我做出决策的速度，也拉高了我做出好决策的下限。很多时候，我只是从 AI 给出的多个草稿中「选出我最喜欢的那一版」，再稍作调整而已。

多模态协同 —— 从视觉到代码的转译

在说明一个系统运行原理时，图相较于文字和代码，更具直观性和表达力，更容易被人们理解。

我们在工作中会接触到各种各样的图，原型图、流程图、时序图、架构图等等。这些图，本质上都是信息的另一种组织形式。

一般情况下我们是无法直接利用图的，我们需要从图中提取到信息后，再转化为目标输出。

对后端来说，图是可读的，却不可调用的。我以前看图的方式，更多像是「辅助理解」，很少能「直接转化为开发动作」。比如看原型图，需要自己获取信息后再做流程梳理和接口设计。

但现在，多模态 AI 让这一切发生了变化。图，终于成为了后端可以直接利用的输入源。

只要我把截图、设计稿、流程图、文档截屏丢给 AI，就能马上提问：

• 这个页面有哪些字段？每个字段对应什么业务含义？
• 这个流程图里有哪些关键节点？分别该怎么建表和建接口？
• 请帮我从这个 UI 图中识别出 API 接口需求；
• 这个接口说明文档拍照截图了，你能帮我还原成 API 实现代码吗？
• 请根据这个系统图列出我需要写的服务和模块结构；
• 这张错误页面截图，你能帮我排查可能的代码位置吗？

可以看到，AI 就像一个视觉上的结构提取器 + 思维翻译官，把图中那些隐含的信息变成我熟悉的结构语言 —— 字段、模型、流程、模块、接口、边界条件。

多模态能力不止于识别图，它还能双向协同：

• 根据模块依赖关系生成调用图；
• 把接口流程画成时序图；
• 帮我可视化数据库表的 ER 图；
• 表结构映射出前端页面布局；
• ......

过去，这些都需要设计工具、人力梳理，而现在，我只需要动口，AI 就能完成。

从视觉走向结构，从图示转为模型，AI 正在重构我们与设计图之间的关系。

图不再仅仅是只读信息，而是可供后端直接调用的开发输入。图是信息源，AI 是翻译器，我们的工作方式，正从「对接需求」转为「编译需求」。

文档生成 —— 沟通的最小成本化

在日常工作中，很多开发是不愿写文档的，这其实是有原因的：写文档真的难，很多时候甚至比写代码还难。

代码是写给机器的，只要语法对、逻辑通，机器就会按照预期执行。但文档是写给人看的，人要能读懂文档，这就要求文档上下文充分、结构清晰、表达准确。这比写代码需要更强的全局思维和逻辑能力。这也是为什么，在不少公司里，哪怕项目做得再复杂，文档却可以完全没有。

更现实的原因是，文档写作常常被当作「额外工作」，它不直接影响产出，不计入绩效，也没人愿意花时间专门去写。

而且大多数开发者本就没有系统的写作训练，写文档全靠感觉。结构清不清晰、有没有示例、读者看不看得懂，全凭经验。写出来也常常没人看，等系统一变更，又得手动更新，不更新文档跟代码又脱节了。一来二去，大家慢慢形成了一种文档写了也没用的心理预设。

但现在，这一切开始变得不一样了。AI 开始成为我写文档的第一助理。

我只需要把代码、接口、改动点贴给它，再补一句「帮我生成接口说明」，它就能起草出一份结构清晰、逻辑完整、语言自然的文档草稿。参数说明、返回结构、调用顺序、示例请求，甚至错误码解析，它都能自动生成，少有遗漏。

最关键的点在于，AI 知道这份文档不是写给自己看的，而是写给前端、测试、产品、甚至未来的自己看的。面对不同读者，AI 会主动调整措辞和重点，写出来的内容不仅合理可读，还能「对症下药」。它会：

• 给前端强调字段含义和接口行为；
• 给测试标注边界值与异常返回；
• 给产品补充业务流程与限制条件。

更让我惊喜的是，AI 不只是会「起草」，它还能「维护」：

• 发现代码逻辑有改动后，它能自动标注出文档的失效段落；
• 只补增量内容，不重写全文；
• 在改接口时提醒我更新参数说明，自动生成 changelog。

这个过程几乎不再需要人工持续跟进做补丁，而是变成了「轻提示 + 快补全」的流畅工作流。

过去我写文档，要靠耐心、靠时间、靠责任感。现在我只需要一句提示语，再加几分钟确认，就能完成一份高质量的文档交付。

AI 把写文档，从一项费力的工作，变成了一项性价比极高的表达工具。

AI 不是让我变成文档专家，而是让我不用变成文档专家也能交付高质量文档。

代码管理 —— 意图的结构化沉淀

代码管理不仅关乎对代码本身的「增删差改」，更关乎我们如何组织这些改动、如何解释它们、如何协作推进它们。一份代码最终能不能交付，不只是写得对不对，还要看它能不能被理解、被记录、被维护。

在现实开发中，Git 无疑是这方面使用最广的工具。

作为一名后端工程师，Git 几乎贯穿了我整个开发周期。但说实话，大多数时候我们对它的使用还停留在基本的「保存代码」和「回退备份」层面。Commit 随便写，PR 没人描述，永远都是「功能优化」、「Bug 修复」，很难从信息中读到有价值的内容。长此以往，版本历史就成了一堆毫无信息量的提交列表。

这些问题过去一直靠团队规范去约束，比如约定提交格式、要求写 PR 描述、标记影响范围等等。有些能靠 Git Hook 来约束，有些只能靠人为了。执行成本高，效果却有限。

现在，有了 AI，代码管理终于有了解决这些细节问题的可控手段。

我现在的做法是：功能开发完成后，直接让 AI 来生成 Commit Message，要求它遵循 Conventional Commits 规范，同时补充改动动机和风险提醒。AI 会自动分析改动内容，识别模块归属，归类变更类型，并生成一段结构清晰、上下文完整的提交说明。

甚至在提交前，AI 就能先识别出当前改动中有哪些是和本次任务无关的内容，提醒我拆分提交、规避污染历史。它会告诉我：「你这次修改了 config、utils 和 auth 三个模块，但只有 auth 和这次需求相关，建议拆分 Commit。」

过去这种代码污染 Commit 的问题屡见不鲜，等出问题时才发现难以回滚，难以查明来源。现在只需一句提示，整个提交的清洁度就能大幅提升。

同样地，PR 描述我也交给 AI：「请帮我写一段 PR 描述，前端和测试能看懂那种。」AI 不仅会提取改动内容，还会判断是否涉及接口变更，是否需要同步文档，以及对下游调用是否存在影响。有时候，它还会发现我遗漏了测试用例，并提醒我补全覆盖。

除此之外，我还会请 AI 帮我生成 changelog、release note，或者从特定模块的历史改动中梳理演进路径。例如：「请回顾最近十次关于 auth 模块的改动，帮我整理出设计演进和行为变化。」AI 能总结出每次改动的核心点，列出影响范围，并生成一份适合同步团队的分析摘要。甚至在需要回滚的场景下，它也能自动生成一套相对安全的 rollback 建议。

过去我们理解版本管理，是记录发生了什么。现在，有了 AI，它还能告诉我们为什么会发生、对谁有影响、后续应该注意什么。

Commit 不再只是变更的快照，而是开发意图的表达。PR 不再只是合并动作，而是协作沟通的窗口。Git Log 也从日志记录变成了系统认知的一部分。

AI 让这套流程更清晰、更自动，也更具备表达能力。这不是取代人类的判断，而是帮助我们把判断记录得更明确，把思考传达得更完整。

在 AI 时代下，代码管理开始变得结构化、意图化、知识化。

CI/CD 配置 —— 快速交付闭环

CI/CD 是开发过程中触发最频繁的动作之一。它通过预先编排好的流程，完成代码的构建、测试、打包、部署。而这些流程的核心，就是配置。

在 GitLab 中我们使用 .gitlab-ci.yml，GitHub 则是 .github/workflows。这些配置文件定义了每一步该做什么、何时触发、依赖关系如何。虽然配置内容繁多，但庆幸的是团队内部通常都有一套固定的流程模板，日常开发只需要稍作修改就能复用。所以，大多数人对 CI/CD 配置的编写和理解停留在“复制粘贴 + 改变量”的阶段。

一旦遇到需要非固定 CI/CD 流程的项目时，比如调整构建产物、引入中间步骤、处理多环境部署，就开始显得力不从心。更难的是流程里的操作逻辑。比如：

• 构建命令该放哪里，build 脚本该如何写；
• 产物要如何命名、存储、传递；
• 什么阶段要缓存、何时清理、如何注入变量；
• Makefile、Dockerfile、Helm chart 等配套文件该如何编写。

这些都很少有成体系的文档，尤其是流程逻辑，大多数时候都是个人经验，踩坑踩多了才知道怎么写对。

但现在，有了 AI，这些工作可以交给它代劳了。

你只需要一句自然语言输入：「这是一个 Go 项目，依赖 Redis 和 MySQL，帮我写一个 GitLab CI 流程，包含测试、构建、打包镜像并推送到内部仓库。」，AI 会自动输出：

• 一份 .gitlab-ci.yml，格式标准、结构清晰；
• 自动识别构建方式（go build、make、docker build）；
• 注释写得一清二楚，变量声明、触发条件、依赖关系都交代明白；
• 配套生成 .dockerignore、Makefile、build 脚本，补齐构建细节；

甚至 Dockerfile 也不用自己手写了，只需一句话：「请为这个 Go 项目生成一个支持多阶段构建的 Dockerfile。」，它就会拆分构建阶段和运行阶段镜像，处理 vendor 缓存、编译参数，避免常见路径和权限问题，还会建议如何安全地运行非 root 用户。

如果需要 Helm 支持，只需补一句：「请生成一个 Helm Chart，支持自定义配置，默认用 NodePort 暴露服务。」，它会输出完整的模板结构，加上滚动更新策略、资源限制、Health Check，还会说明哪些值建议按项目场景调整。

更强的是，它还能直接根据项目结构推导部署流程：「请为这个项目生成完整的 CI/CD 流程，部署到测试环境。」，AI 会：

• 自动扫描服务模块、脚本任务、依赖资源（MySQL、Kafka 等）；
• 补齐 CI 流程（测试、构建、打包），加上 CD 部分（部署、回滚）；
• 推导环境变量注入方式，自动生成 changelog 或 summary 输出；
• 给出部署环境的落地建议，比如用哪套 K8s 环境、是否需要 staging 流程。

AI 把这部分变成了自然语言接口。你只需表达目标，它就能生成配置。你只需补充上下文，它就能补全交付逻辑。

CI/CD 不再是代码完成后的后置流程，而是从第一行代码开始，就并行设计的一部分。这也践行了我认为 CI/CD 最重要的理念：「重视阶段性产物，快速落地验证」。

待探索的模式

除了以上我目前正在使用 AI 编程的场景外，还有一些我还在探索的场景。这里提两个我日常中最可能落地的场景：AI 脚手架和 AI 线上诊断。

AI 脚手架

脚手架的作用是：在团队内部构建一套统一、可复用的开发模板，方便团队成员快速完成业务开发，降低人员流动导致的沟通成本。

脚手架通常包括以下 6 部分：

1. 服务的核心启动框架，包含服务整体用法定义、生命周期管理等；
2. 丰富、开箱即用的业务组件和工具包；
3. 符合团队基础设施的脚本，包含 Makefile、CI/CD、Dockefile 和各类部署脚本等；
4. 集成团队约束规范，包含目录规范、模块划分规范、API 定义规范、README 规范等；
5. 集成代码经验和最佳实践，如服务流量无损重启、全链路集成日志指标输出、各类依赖可视化数据采集等；
6. 各类围绕服务生命周期管理的命令行工具等，包括项目骨架生成、模块代码生成、服务启动关闭、服务调试等。

综上可见，脚手架其实是一套整合了团队所用、所长的技术工程落地产物，它能一定程度地体现团队的技术实力。

脚手架的内容繁多复杂，尤其是核心框架和组件工具部分。而且，我们对脚手架的基本要求是，要保证绝对的稳定和可靠。因此往往只有几个经验丰富的核心成员才能参与制定脚手架的开发。对于小团队或个人来说，要想拥有一个强大的脚手架还是很不容易的。

但是，现在有 AI 了，我们尝试借助 AI 的能力来探索一下实现一个脚手架的可行性。我们对以上 6 部分进行分别思考：

1. 这个部分要求稳定和可靠，目前 AI 还无法独立完成，只能由开发者来主导设计，AI 作为助手辅助做些编码工作；
2. 同 1；
3. 需要开发者结合团队所用基础设施和技术栈来制定脚本，AI 同样只能做编码辅助工作；
4. 这部分 AI 能比较好地进行支持，可以通过 AI 提示语来约束生成行为，如 Curosr 中的多种触发条件的 Rules。举个例子，可以把目录规范用目录树的形式写在 Rules 中，让 AI 初始化项目时使用 Rules，即可生成符合要求的项目结构；
5. AI 比较难控制如此细节的编码规则，因此依然需要开发者封装成组件和工具库；
6. 部分用于开发阶段的命令可以通过 AI 提示语来实现，比如项目骨架生成、模块代码生成等，而非开发阶段内的，还是依然需要命令行工具来支持。举例，通过 Rules 生成配置模块，提前描述好配置的标准结构体，通过自然语言即可生成。

可以看到，脚手架的核心部分依然需要由开发者来亲自操刀，AI 能做到的只有模板代码生成部分。

鉴于 AI 的上下文长度限制，我们在设计脚手架的用法时可以优先考虑简单，以最少的代码完成较多的操作，这样模板代码能容纳更多的内容，AI 生成不至于偏差过大。比如，服务的核心框架启动：

// 简单
if err := app.Run(); err != nil {
    slog.Error("failed to run app", "error", err)
}

Rules 可以这样写（下面代码片段用 ~~~ 是因为样式问题，实际使用时用 ``` 代替）：

在要求创建项目目录结构时，请必须参照如下规范进行创建：
~~~
├── api                     # OpenAPI/Swagger规范、JSON模式文件、协议定义文件
├── assets                  # 项目使用的其他资源（图像、Logo等）
├── build                   # 打包和持续集成
│   ├── ci                  # CI配置文件和脚本
│   └── package             # 云、容器、操作系统包配置和脚本
├── cmd                     # 项目主要的应用程序
│   └── myapp               # 应用可执行文件目录
├── configs                 # 配置文件模板或默认配置
├── deployments             # IaaS、PaaS、系统和容器编排部署配置和模板
├── docs                    # 设计和用户文档
├── examples                # 应用程序或公共库的示例
├── githooks                # Git的钩子
├── init                    # 系统初始化和进程管理配置
├── internal                # 私有的应用程序代码库
│   ├── app                 # 应用程序实际代码
│   │   └── myapp           # 具体应用程序代码
│   └── pkg                 # 应用程序共享代码
│       └── myprivlib       # 私有库代码
├── pkg                     # 外部应用程序可以使用的库代码
│   └── mypubliclib         # 公共库代码
├── scripts                 # 用于构建、安装、分析等操作的脚本
├── test                    # 外部测试应用程序和测试数据
│   └── data                # 测试数据目录
├── third_party             # 外部辅助工具、fork的代码和其他第三方工具
├── tools                   # 项目的支持工具
├── vendor                  # 应用程序依赖关系
├── web                     # Web应用程序特定的组件
│   ├── app                 # 前端应用，如SPA
│   ├── static              # 静态资源
│   └── template            # 服务端模板
└── website                 # 项目网站数据
~~~

同时，在 `cmd/service/main.go` 中的内容，必须是如下的代码：
~~~
package main

import (
    "log/slog"
    "os"

    "example/app"
)

if err := app.Run(); err != nil {
    slog.Error("failed to run app", "error", err)
    os.Exit(1)
}
~~~

其他模板代码的生成也是类似，可以通过 Rules 来约束。

这里带来的最大的改变就是，命令行工具可以被自然语言代替，自然语言的修改非常直观，任何人都可以修改，而且生效快。后续团队内可以共同维护一份 Rules，这样就可以形成一种新的基于 AI 的脚手架规范了。比较好的实践如下：

• 尽可能让脚手架代码片段精简，避免 Rules 过长；
• 建议为脚手架相关的代码生成维护单独的上下文对话环境；
• 在 Cursor 中能用 @ 来引用 Rules 是最好的。如果嫌麻烦，建议用精确的语言来描述引用场景。

目前基于 AI 的脚手架思路也不算完美，AI 的上下文长度和随机性会导致生成出来的内容不稳定，这对于脚手架来说不是很能接受。不过对于个人开发者来说，已经能算得上可用了。

AI 线上诊断

我个人所在的团队维护着两三百个服务，总服务实例数达七八百个，每天日活 2kw+，处理客诉和线上问题都是家常便饭。如此多的服务，链路是非常复杂的。从用户客户端到服务的数据存储，再到物理机器资源，期间请求经过的每个环节都可能发生问题。

一旦发生线上问题，就需要立即进行定位，但因为链路复杂，要找到根因还需要一些人力的参与。又由于线上问题的紧急性，恢复是最重要的事，头痛医头或许能缓解个一两分钟，但找出根因才能真正解决问题。因此，线上问题就要求能被快速、准确得诊断出来。

目前我们有一系列的监控和预警策略，但还不够，被预警出来的只是表现，内部成因关系还得靠人力来排查梳理。在分秒必争的线上环境，人难免会有紧张情绪，如果是大半夜被叫醒，那状态可能更加崩溃，排查思路混乱，恢复时间会被拉长。

这些监控和预警是基于数据的，一旦有了全链路数据，那么事情就好办了。这里我拿一个最近发生的线上问题来举例。

AI 可以把预警数据作为输入起点：

• 举例 1：
  • 1. 登录失败，预警出 16 错误码，触发 AI 分析；
  • 2. AI 分析登录 16 错误码的日志，发现是 Token 签发服务失败（需明确告诉 AI 是 Token 签发服务失败，而不是其他原因）；
  • 3. AI 分析 Token 签发服务失败的原因，发现 redis 延时（需明确告诉 AI 是 redis 超时大，而不是其他原因）；
  • 4. AI 分析出第一个原因（人工也可能会在这一步判断是否需要继续分析，改哪个服务的问题）;
  • 5. AI 继续分析 redis 延时问题，发现只有 redis 集群的 A 机器节点有高延时问题，其他机器节点正常（需要明确告诉 AI 是 A 机器节点延时，而不是其他机器节点）；
  • 6. AI 分析机器节点上的资源监控，发现有短时间的闪断；
  • 7. AI 分析操作日志，回溯闪断原因，结合阿里云日志，发现机器有做热迁移导致；
  • 8. 问题追查结束，并给出可能的解决方案；
• 举例 2：
  • 1. 域名解析失败，登录率下降，触发 AI 分析；
  • 2. AI 这时需要有 DNS 相关日志；
  • 3. AI 分析 DNS 日志，发现是 DNS 解析失败；

可以看到 AI 是否能全自动、准确地诊断的前提是需要满足如下前置要求：

• 尽量有全链路的日志数据，网络层 - 服务层 - 机器层；
• 准确的日志聚合格式，如明确错误的依赖服务；
• 准确的分析指标，如明确多少延时是异常延时；
• 准确的预警数据，AI 以此作为切入点；
• 准确的服务依赖关系，如说明某个服务依赖于哪些服务；
• 准确的服务描述，如说明某个服务是做什么的、是否可以重试、是否可以降级；
• 服务的代码变更记录；
• 线上动作变更记录，如服务发版、线上扩容、机器调整等；
• 时间窗口，如明确问题发生的时间窗口；

这些数据不仅要有详细准确的上下文信息，而且还要具备确保格式基本统一。只要团队内提前设计好数据规范，上报到同一个数据仓库，把数据喂给私有模型（或者提供数据查询接口写个 MCP）即可。这个可以团队内定个脚手架来强制实现。

AI 最终给出的还只能是诊断结果和操作建议，真正要做恢复的动作还是要有人来决策。

写在最后

当人们提到 AI 编程，第一反应通常是：写得更快了、效率更高了、Bug 更少了。但如果我们只关注这些表层变化，就还没真正看到 AI 带来的转变。

AI 编程，不只是工具变强了，而是整套编程的思维结构正在发生变化。我们不再是告诉机器怎么做，而是把目标交给它，由它反推该怎么做。程序员的角色，也因此发生转变，从「代码生产者」，转为「意图定义者、过程引导者、结果审校者」。

输入的边界也在变化，不再只是函数名和参数，而是目标、偏好、上下文和权衡。

程序员的角色，也不再只是写代码，而是：

• 判断 AI 给的方案是否合理；
• 明确你的业务目标是什么；
• 优化生成结果，提升整体设计质量；
• 组合多个工具，完成更复杂的交付；
• 最重要的，是用清晰的语言，定义你要的结果。

当代码变成结果，写代码本身就不再是核心竞争力。

编程边界的重新定义，意味着程序员未来的核心价值，是「知道要做什么」，而不是「知道怎么做」。AI 已经可以学会「怎么做」，但「做什么」仍然是人类最稀缺的能力。这是一场从操作型工程思维，向决策型系统思维的迁移。也是一场从语言编程，到意图编程的跃迁。

编程的边界，正在重构。程序员的角色，也即将重生。从写代码的人，变成让 AI 写出正确代码的人。

---

上面已经覆盖了大部分工作了流程了，还有几个是 AI 目前还不能完全胜任的，或者说只能做最简单的那一部分。比如，架构设计、需求拆解、CI/CD等。这些依然是需要人参与其中的。

下一篇，我将聚焦另一个更现实的问题：AI 到底还不能做什么？程序员还有哪些不可被替代的能力？