前言、人人都是开发者？

编码正在变得越来越简单。N 年之前就有低代码平台让非技术人员用“拖拉拽”的方式搭建页面，在大语言模型迅猛发展的今天，各种 AI 编程助手更是让“人人都是开发者”成为可能，外网火爆的 8 岁小孩哥用 Cursor 写游戏的新闻让许多人惊呼“编程门槛已被彻底打破”。

然而，我在使用 Cursor 写代码的时候发现它并不是那么听话，跟它说一个需求它常常脑补一些别的功能，让它改一个 bug，可能又顺带着引入一个别的 bug。在长时间跟 Cursor“斗智斗勇”之后，我发现要让 AI 成为靠谱的开发者同事，还并不仅仅是会生成代码那么简单。真正的开发能力源于对系统性思维的掌握，而非单纯的代码编写技巧。就像一个优秀的建筑师不仅需要懂如何堆砌钢筋混凝土，更需要掌握空间规划、力学原理甚至有美学思维，一名优秀的开发者不仅要会堆砌代码，更需要具备领域建模、业务流程抽象、上下游协同等更全面的能力。

本文将探讨在 AI 时代，哪些开发者背后的隐藏技能仍然不可或缺，以及如何让在企业内真正落地“人人都是开发者”。

一、建模：万物皆有模型

什么是“建模”？建模就是“构建模型”的缩写，是将不同的、复杂的现实世界抽象为通用的、便于理解的形式。在软件开发中，建模意味着识别出系统中的关键元素及其关系，并以结构化的方式表达出来。

《Thinking in UML》一书把所有的软件系统抽象为人、事、物、规则 这几个核心要素，

• 人：系统的使用者和参与者，具有不同的角色、权限和行为特征

• 事：系统中发生的活动、事件和流程

• 物：系统中的资源、数据和对象

• 规则：定义系统运行边界和约束的各种条件

这种抽象的模式亘古不变，并且会让原本复杂的世界变得简单清晰很多。比如，设计一个在线选课平台，用人、事、物、规则来建模的话，可以画一个类似的图

基于这个底层模型，可以设计数据库表的结构，比如学生信息都有哪些，课程的信息都有哪些，学生跟所选课程之间的关系通过什么表来记录等等。

这个底层模型需要开发者事先跟 AI 讲清楚达成共识，否则一句话需求“设计一个在线选课系统”，在现阶段很难让 AI 直接生成可用的版本。如果你再有个性化的需求，AI 就更无法帮你实现出来了。

二、画流程图：让复杂过程可视化

之前听一个架构师讲，“凡是动词都有其流程”。在确定系统的底层模型之后，需要再把核心的流程图画出来。流程定义了业务如何运转、数据如何流动、用户如何与系统交互。比如要实现“学生登录系统”这个动作，健壮的系统需要考虑到通过什么方式认证身份，如果用户名不合法要怎么处理，密码遗忘要怎样找回等等流程。比如，

流程图是开发者与业务人员的共同语言，它能够清晰展示业务逻辑和系统工作流，发现潜在的逻辑缺陷和优化空间，是开发实现和测试验证的基础。

在实际开发中，AI 已经可以根据自然语言描述生成流程图代码（如 Mermaid 或 PlantUML），但开发者可能仍需要手动微调，确保流程符合业务需求。

三、确定通信协议：系统互联的桥梁

在对流程图达成共识之后，需要进一步设计交互协议/API。这些 API 出现在不同的对象相互通信的交互点。比如上图的前端与后端有一个交互是“发送登录请求”，那么就需要有一个 API 的定义。完善的 API 文档应包括 URL、请求格式、响应格式、认证方式等信息。这个用户登录 API 的文档可能如下：

API: 用户登录URL: /api/v1/auth/login方法: POST内容类型: application/json
请求体:{  "username": "string", // 用户名  "password": "string"  // 密码}
成功响应 (200 OK):{  "token": "string",       // JWT令牌  "user": {    "id": "string",        // 用户ID    "username": "string",  // 用户名    "role": "string"       // 用户角色  }}
错误响应 (401 Unauthorized):{  "error": "string",       // 错误代码  "message": "string"      // 错误描述}

上下游交互的 API 设计方式与上方类似，只是在企业内部可能会有通信更加高效的 RPC 协议。

当前 AI 可以帮助生成 API 文档，但开发者仍需要理解业务需求，确定合适的接口粒度，评估 AI 生成的接口设计是否符合安全性、性能和可扩展性要求。在与上下游确定 API 协议之后，就可以分别进行开发啦。

四、设计测试用例：AI 质量保障的基石

现在可以让 AI 写代码了吗？且慢。如同再优秀的程序员也会写 bug 一样，AI 也会写出 bug。并且 AI 在开发者的提示之后，可能越改越乱。如果你不懂代码，简直不知道它在修复这个 bug 的过程中，是否引入了新的 bug

让代码没有 bug 的方式是测试。在传统软件行业中，开发者和测试人员是两种不同的角色，测试人员根据对产品流程的理解产出测试用例。良好的测试用例应覆盖所有关键功能和业务场景，包含正常流程和各种异常情况。

在 1990～2000 年，软件开发流行一种“测试驱动开发（TDD，Test-Driven Development）”的方法论，其核心思想是 先编写测试用例，再实现功能代码。TDD 的流程通常被描述为“红-绿-重构（Red-Green-Refactor）循环”。

1. Red 阶段：在编写任何功能代码之前，先根据需求编写一个测试用例。因为功能尚未实现，这个测试用例肯定失败，测试结果显示为红色

2. Green 阶段：编写最基本的功能代码，使其能够通过刚刚编写的测试用例。此阶段的目标是让测试用例通过（变绿），而不用追求完美的实现

3. Refactor 阶段：在确保所有测试通过后，对代码进行优化和重构。此阶段的目标是提高代码的可读性、性能和结构，同时保持测试通过。

由于有测试作为保障，开发者可以放心地进行重构，而不必担心引入新的错误。如此重复循环，逐步完善系统功能。

听起来很不错，但实际落地过程中会面临很多挑战，没有开发者喜欢先写测试用例。由于需要额外编写测试代码，TDD 可能会增加开发时间，尤其对于较为简单的需求，红-绿-重构的流程显得过于繁琐和教条。

但 20 年流行的 TDD 理论有望在 AI 时代重焕升级，毕竟测试用例也可以让 AI 来生成嘛。各种边界条件都让 AI 来想一遍，开发者只需要 review 测试用例，确保测试用例的设计与产品原型保持一致。TDD 就像给孙悟空戴上了“紧箍咒”，让这个 AI Code Monkey 能乖乖替我们降妖伏魔，做牛做马。

五、设置编码规约：一致性的保障

在设计完所有的测试用例之后，在正式写代码之前，还有一件事需要做。为了让 AI 能写出可读性强、扩展性好、风格统一的代码，必须要让它遵循一些约束条件。比如，变量如何命名、代码如何缩进、日志如何打印、异常如何处理等等。

阿里巴巴 Java 开发规约是业内广泛采用的编码规约，可以把强制、建议的规约显式写出来让 AI 遵循，在 Cursor 中可以使用 Rules 来完成对规约的设置，

六、正式编码：一次只做一件事

终于可以开始写代码了，为了让整个开发过程太过发散，避免“胡子眉毛一把抓”，强烈建议“一次只做一件事”，每次代码修改只聚焦在一个功能点，完成之后提交，然后再做下一个。

“一次只做一件事”也体现了软件工程中的单一职责原则（Single Responsibility Principle）：一个类应该只有一个引起它变化的原因。即每个类只负责一个功能领域，每个方法只完成一个明确定义的任务。

体现在 AI 编程上的最佳实践是开发者先写注释，由 AI 生成代码。这样让开发者最痛恨的注释问题也完美解决了。

结语：人人都可以是“创造者”

AI 编程可以说是 AI 应用领域中最早找到 PMF（Product Market Fit，产品市场匹配）的方向之一，并且已经展现出强大的商业化潜力。

AI 工具可以降低开发门槛，提高开发效率，然而，想要真正用好 AI，跟它结对编程，更重要的是建模能力、把复杂的问题拆解成简单任务的能力，以及能跟其他角色更好的协作能力。

AI 时代，必将“人人都是开发者”、“人人都是产品经理”、“人人都是设计师”、“人人都是 XXX”，在这个新的范式里，人人都可以是“创造者”，用 AI 释放自己的想象力、执行力与影响力。不会某项技能不会决定你的天花板，能不能提好问题、能不能带着 AI 一起解决问题，才是 AI 时代的核心竞争力。