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

2022 年 11 月，ChatGPT 的发布掀起了大语言模型（LLM）的普及浪潮。两年多过去，AI 编程已成为 LLM 应用最成熟、进展最迅猛的方向之一。人机协同编程的方式已经迭代了好几轮了，它已完全融入到我的开发工作流中，几乎每一步都有 AI 的参与。

我目前的开发模式已经严重依赖 AI，严重到会因为 AI 没有及时给我 Tab 建议而心生烦躁，有时在没有 AI 辅助的情况下，我甚至都不想写一行代码。我花 20% 的时间和 AI 对话 battle，它能解决我 80% 的问题，AI 给我带来 5x 甚至 10x 的效率提升。但同时 AI 又一次一次得打碎我对技术和编程的认知，冲破我为自己构建的所谓的壁垒，它让我感到恐惧和焦虑，AI 真是一个让人极度又爱又恨的工具。

这里感叹的是 AI 的效率，不是说 AI 无所不能的强大。在编程这方面，AI 能完成的，人也能完成，只是效率问题。人能完成的，AI 未必能完成。

目前 AI 可以覆盖我日常 80% 的任务了：

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

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 的签名计算方式？
• 抓包接口的调用链和数据依赖关系是什么样的？
• 解读接口的字段结构、命名、返回值，尝试推测出字段的业务含义？
• ......

这些提问往往很有效，不需要太多上下文，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 正在重构我们与设计图之间的关系。

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

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

很多人不愿写文档，其实是有原因的：写文档真的难，很多时候甚至比写代码还难。

代码是写给机器的，只要语法对、逻辑通，它就会乖乖执行。但文档是写给人看的，人可不会客气地说「你写的什么玩意」。这也是为什么，在不少公司里，哪怕项目做得再复杂，文档却可以完全没有。

更现实的原因是，文档写作常常被当作「额外工作」，它不直接影响产出，不计入绩效，也没人愿意花时间专门去写。而大多数开发者本就没有系统的写作训练，写文档全靠感觉。结构清不清晰、有没有示例、读者看不看得懂，全凭经验。写出来也常常没人看，等系统一变更，又得手动更新，不更新文档跟代码又脱节了。一来二去，大家慢慢形成了一种心理预设——文档写了也没用。

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

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

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

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

文档从「程序员记事本」变成了「多人协作锚点」。

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

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

这个过程几乎不再靠人脑强记，也不需要每次都从头再写一遍，而是变成了「轻提示 + 快补全」的流畅工作流。

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

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

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

写在最后

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

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

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

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

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

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

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

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

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