人人都是开发者？人人都是创造者

发表于 更新于

前言、人人都是开发者？

编码正在变得越来越简单。N年之前就有低代码平台让非技术人员用“拖拉拽”的方式搭建页面，在大语言模型迅猛发展的今天，各种AI编程助手更是让“人人都是开发者”成为可能，外网火爆的8岁小孩哥用Cursor写游戏的新闻让许多人惊呼“编程门槛已被彻底打破”，“5分钟写出一个App/微信小程序”的自媒体文章更让我们这些大龄码农倍感焦虑。

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

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

一、建模：万物皆有模型

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

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

  • • 人：系统的使用者和参与者，具有不同的角色、权限和行为特征
  • • 事：系统中发生的活动、事件和流程
  • • 物：系统中的资源、数据和对象
  • • 规则：定义系统运行边界和约束的各种条件

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

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

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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可能会增加开发时间，红-绿-重构的流程显得过于繁琐和教条。更麻烦的是，在测试过程中需要构造各种测试数据，传统方式不仅麻烦，还可能会遗漏。

好消息是TDD理论有望在AI时代重焕升级，毕竟测试用例、测试数据都可以让AI来生成嘛。

  • • 不想自己写测试用例？只需要告诉AI：请根据PRD用产出测试用例，需要考虑各种边界条件，用Xmind的格式输出。开发者只需要review测试用例，确保测试用例的设计与产品原型保持一致。
  • • 测试数据不好构造？只需要告诉AI：以下是我的建表语句: CREATE TABLE xxxxxx，请针对于XX文件XX方法帮我生成测试数据的insert SQL，正常场景和各种异常场景都要考虑到就可以得到直接能用的测试数据。

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

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

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

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

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

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

体现在AI编程上的最佳实践是开发者先写注释，由AI生成代码。这样每个方法上都有标准的注释，极大增强了代码的可读性。把业务逻辑全部都写完之后，可以让AI把代码的流程图用mermaid语法输出出来，跟PRD中流程做一次double check

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

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

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

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