AI浪潮下开发模式的变革
AI 浪潮正在改变软件开发模式，为开发者带来新的机遇和挑战。本文通过实际工作案例讲述了 AI 对个人开发工作的影响，以及 AI 时代下产品开发模式的变革，并分析了大模型时代程序员与 AI 工具的定位，希望能帮助开发人员提前布局，抓住新一轮发展机遇。
为什么你需要 AI？
互联网的发展历程波澜起伏，每个阶段都孕育着巨大的机遇。比如 2014 年左右移动互联网的爆发，移动开发人员的地位也水涨船高，如果你会安卓或者 iOS 开发，薪资很容易就能翻个两三倍。
当移动互联网风口过去，互联网进入稳步发展期后，所有人都在寻找下一波互联网变革的方向。而今年，基于大模型的 AIGC 崛起，开启了互联网的第三个十年。现在我们所处的 AIGC 时代，绝对是不亚于移动互联网的一个风口，因此了解 AI、应用 AI，能让我们抓住时代发展的红利，提升自己能力的同时也能带来个人价值的最大化体现。
这是Stack Overflow 2023 年的开发者调研，从中可以看到有接近 70%的开发者已经在使用/计划使用 AI 相关的工具，60%到 80%的开发者认为接下去一年其工作会因为 AI 发生巨大的改变。
当其他开发者都已经在使用最新颖的 AI 工具去改进自己的开发流程时，你还在使用很原始的开发模式，那肯定是会被时代所抛弃的。
另外，目前大家都沉浸于繁重的业务开发中，利用 AI 工具提升效率，也能够让你有更多的时间去做其他的事情，何乐而不为呢？
AI 对个人开发工作的影响
AI 工具在个人日常开发工作中的实践
业务开发
最近需要做一个 3D 地球，我们让一位从未接触过 3D 开发的同事尝试用 AI 相关的工具去进行这次开发，这位同事毕业一年左右，从来没有接触过 Web3D 开发，借助 ChatGPT 和 Copilot 等工具，他将原来预估需要五天的工作在两天内就搞定了。
可以看到 AI 相关的工具可以极大的提升我们的工作效率，特别是在一些新技术的学习和运用上效果尤为显著，而且 AI 工具给我们带来最大的一个改变在于将传统的被动学习模式，变成了主动学习模式，比如我们用 ChatGPT 去学习的时候，它的每一个回答都针对的是你真正想要了解的问题，因此效率非常高，这种从被动学习到主动学习的转变，能让我们的学习效率成倍的增加。
代码转写
我们公司之前大量的后端服务都是用 PHP 编写的，从 2018 年开始公司转向 Java，这就涉及大量的 PHP 代码转写为 Java 代码。资讯的同事采用 ChatGPT4 进行了资讯种子平台项目的转写，将原本需要四周的工作量缩减到两周就完成了。
代码审查
传统的代码审查，存在一些问题，比如：
- 效率低：需要耗费大量时间，有的时候因为这个原因，会导致团队 CodeReview 的频率很低(之前做过一个调研，很多团队的 CodeReview 频率甚至不到一个月一次)
- 深度不足：团队人员的水平和业务知识储备不同，难以给出有深度/贴合业务的有效建议，只能给一些很浅的 Review 结果，比如格式、基础规范等
- 主观偏好：每个人都存在主观偏好，比如有的人侧重性能，有的人侧重逻辑，Review 时容易遗漏要点
而使用 AI 工具进行 CR，则可以帮助我们解决这些问题。
不仅如此，AI 工具还可以帮助我们发现一些人工不易察觉的问题，提前屏蔽风险，比如下面这个案例：
这是今年五月份的一个线上事故，手炒页面出现了白屏，经排查后发现其中一个原因是一段前端代码存在问题。我们将这段代码发给 ChatGPT，可以看到他在第一条 Review 建议中就精准地识别出了问题所在。
不止如此，在其他的很多场景，AI 工具也能给开发人员带来极大的帮助，比如代码解释方面，就可以用于接手老项目时学习业务相关的代码、阅读开源项目等等。
因此，只要我们结合自身的业务特性和你的工作流去深入分析，一定能找到非常多的点可以结合 AI 工具去加以改进。
如何科学的用好 AIGC 工具
可能有的人使用 AI 工具的时候浅尝辄止，然后并没有解决自己的问题，就感觉这些工具似乎作用并不大。很多人将 AI 工具当成了搜索引擎 Plus 版进行使用。这样肯定是难以发挥它们所有的能力的，想要用好这些 AI 工具，我们必须要了解提示工程(Prompt Engineering)。
结合网上的信息，我们整理了一个提示工程的模板，可以在使用 AI 工具的时候，将提示词拆分成模块化的结构，这样就能够取得比较好的结果：
表格中的每一个指令类型，背后都隐藏着很多信息。
以大模型人设为例，假如我们给出一堆提示词：响应式设计、浏览器兼容性、动画、语义化，大家猜一下，这是哪个方向的开发人员？相信每个人都可以很容易的猜到，这是前端开发人员。因此，假如我们将大模型人设设定为：“你是一名专业的前端开发人员”，大模型在回答信息的时候就会去检索前端开发相关领域的知识。因此大模型人设的本质就是用少量的词语定义大量的行为特征。我们在 CodeReview 的时候，可以让大模型按照某本书的原则去 Review：“请根据 Martin Fowler 的《重构-代码整洁之道》这本书的原则，对如下代码进行 Review”，这也是一种形式上的大模型人设。
上述表格中其他的一些模块也有类似的作用。
关于提示工程，网上已经有非常多成熟的资料，这里就不再赘述，大家感兴趣，可以去看一下这个 github：GitHub - dair-ai/Prompt-Engineering-Guide: 🐙 Guides, papers, lecture, notebooks and resources for prompt engineering
AI 对产品开发模式的影响
AIGC 下的产品开发流程
在 AI 浪潮下，我们如何去开发基于 AIGC 的产品呢？其流程相比于传统的业务开发，也会有一些区别。
我们以一个项目为例：让 F10 可以回答出漂亮的 Pluto+富媒体多模态的画板。
我们需要通过四个环节来完成这个任务：
定义任务
首先是定义明确的任务。这里的任务定义不是传统意义上的需求确认，而是定义整个流程里面哪些内容是由大模型处理的、哪些内容需要由开发人员进行工程化的开发。如下图所示：
蓝色部分即为大模型处理的内容，可以看到会涉及多个模型，这也是目前 AIGC 类产品的通用模式，一般可能会由多模型+工程化协作的方式来完成产品任务。
我们以其中的可视化 DSL 生成模型作为示例进行讲解(其他模型也是类似的)。
这里有一个小技巧，我们怎么判断哪些任务适合由模型处理、哪些任务适合开发人员处理呢？当你能够将一个任务定义为**可统计(Statistical)**类型的任务的时，就特别适合通过模型去处理该任务。
确认分工
这里分为两个阶段：模型训练阶段和模型应用阶段。
在模型训练阶段，此时还没有大模型介入，开发人员需要做的工作包括模型训练人员一起定义大模型友好的数据格式、提供训练数据、标注数据等，如下图所示：
在模型应用阶段，由大模型和开发人员协作进行。开发人员所需要处理的工作包括根据大模型生成的 DSL，进行组件库代码的召回、终端绘图页面的开发、以及多轮 Prompt 等辅助功能的开发：
设计数据
接下来我们需要设计大模型友好的数据格式，以生成数据可视化为例，大模型并不适合一步到位生成最终的可视化绘图代码，其更适合处理的是生成可视化的 DSL 描述代码。我们需要将他生成的信息设计成结构化、高抽象度、低复杂度的格式，并且需要保证训练数据的多样性。
以 Pluto 项目为例：
输入部分，主要是数据描述信息，模型会根据该输入，提取数据特征，确定绘图风格，推荐合适的可视化方式：
输出部分，我们设计了一个与具体组件无关的数据协议：
其中最重要的有两个字段：
· parameters 用于实现效果的微调，模型会针对不同的情况返回不同的视觉和交互的微调参数(比如上图中的 xAxisAttribute)，该字段的值可以根据实际场景进行扩展；
· id 为可视化组件的 Id，用于组件库代码召回。
我们只简单约束了几个字段的名称，松散的约束可以做到和具体组件库与技术栈无关，这样有如下好处：
· 和具体组件库无关，可以引入当前团队已有的组件，因为目前很多团队的 AIGC 产品都涉及对现有功能模块的引用，因此怎么样最大程度的复用现有功能模块，是我们必须要考虑的问题
· 和具体技术栈无关，可以引入其他第三方的组件，不管是 DOM+CSS 写的 UI 组件，还是 D3.js 写的可视化组件，亦或是 Three.js 写的 3D 组件，都可以引入到这套系统中
· 输出结果里面我们注明了可视化图表的类型，这样能够精准召回可视化图表代码，使最终的渲染效果有保障
持续演进
最后是构建一个可持续演进的系统。基于模型的应用有一个非常大的优势，因为模型的质量很大程度上是由其训练数据所决定的，因此整个流程构建完以后，我们只需要持续的去提升数据的质量，就能够带来大模型能力的提升。这里面一般采用的是数据标注和 RLHF(Reinforment Learning Human Feedback，基于人类反馈的强化学习)。
在数据标注部分，不同阶段可以采用不同的方式。
初期可以采用ChatGPT做数据标注，我们给 ChatGPT 提供打分的原则，让其针对初始生成的内容进行标注，这样可以节省大量的人力成本。
中期可以由内部人员进行人工标准，比如运营人员、产品经理、设计师等等，对生成的可视化效果进行人工打分，产生一批数量少，但是质量很高的标注数据。
产品上线以后，可以借助外部用户的反馈进行标注，比如我们给用户提供换图功能或者打分功能，当用户执行相应操作的时候，也会生成标注数据。
经验与教训
当然，在这个过程中，我们也踩了非常多的坑，积累了不少的经验和教训。
大模型任务的合理性
初期我们对于大模型的能力边界没有清晰的认识，因此走了一些弯路，包括：
1、让大模型处理非统计型任务，期望其能无中生有，生成之前所没有的可视化代码
2、设计训练数据时，忽略了大模型友好的重要性
3、没有做任务拆解，期望大模型能一蹴而就(复杂任务必须分而治之，多模型+多步骤)
这里推荐大家看一下LIDA 这篇论文，目前做得比较好的 AIGC 金融工具，比如 FinChat、Pluto 等，其实现思路上，都能看到这篇论文的影子。
组件的质量和数量
如果团队之前在组件化方面的积累不多的话，那么现在就要花费大量的时间去进行组件的开发和优化，因为整个 AIGC 的过程中，最终的代码仍然使用的是组件化召回的方式，如果没有很好的积累，最终召回的代码质量也是很差的，无法生成比较好的效果。比如我们在这个过程中，就遇到过如下问题：
· 示例代码质量太低、存在细节上的逻辑错误
· 组件示例大部分都是具体到某个业务场景的示例（复杂性特别高，大量硬编码逻辑），缺乏最简单的使用示例，上手门槛极高
· 组件示例的代码中没有明显的数据处理和绘图逻辑分离，缺乏组件描述：表达了什么可视化信息？预期接收什么结构的数据集？
· 业务细节，例如数值格式化规范、tooltip 展示信息、轴名称、交互等缺乏足够的前置信息来进一步处理（模型输出的参数不能覆盖这些业务细节）
· 业务适配：AIGC 组件高度封装，灵活性降低，针对不同的业务做适配成本很高
· 泛化能力：目前 AIGC 组件的实现都是针对单个类型组件进行封装，如果需要组合两种不同类型的图表就需要再实现一个新的 AIGC 组件，面对灵活的业务场景，无法实现“智能组件”的需求
· 当 AI 模型由完全生成代码任务转变为仅完成图表推荐和数据特征分析任务后，实际上解决了上游的业务问题，但下游的组件问题形势严峻，由 AI 代码生成回归到规则匹配模式，实现了产品智能化的同时，如何解决可视化组件在技术层面缺乏智能化的问题？
· 组件智能化后，如何解决因为智能化的不确定性导致的产品稳定性问题？智能化与稳定性如何取舍？
· ……
如果初期这些方面考虑得不够全面，后面可能会影响产品的开发进度。
数据的标准化
因为数据可视化模型执行的是推荐操作，因此它对于输入的数据是有严格要求的，这样才能够做到广泛的推荐。因此业务方如果数据没有统一，那么在这个过程中就必须先进行数据的标准化操作。这里建议大家采用数据编排的方式对现有的业务数据进行标准化，即采用类似低代码搭建的方式进行数据处理，这样能够带来效率上极大的提升。
大模型下的编程趋势与机会
当前的软件发展阶段与重心
软件开发已经经历了好几个阶段的发展。
1968 年~2017 年的软件 1.0 阶段，人工编码，开发人员的重心是设计算法：
2018 年由 Andrej Karpathy 提出的软件 2.0 阶段，引入了神经网络，追求自动化，开发人员的重心是处理模型训练数据：
而当前我们所处的软件 3.0 阶段，强调 AI 协作增强，这个阶段研发团队的主要任务不是写代码、执行测试，而是**训练模型、参数调优、围绕业务主题提问或者设计提示词(Prompt)**：
在这种趋势下，我们的基建模式也会发生非常大的改变。以前基建的很大一部分内容是开发组件、接口服务、以及工具，而现在这些可能都会变成构建提示词。
开发人员与 AI 工具的定位
AI 会取代开发人员吗？我认为至少短期内是不会的，因为两者的定位目前是存在一些差异的。开发人员与 AI 工具并不是对立的关系，而是相辅相成、相互协作的模式。
在大模型趋势下，开发人员需要具备三个角色的定位：
第一个是需求分解者。因为我们只有将复杂的业务问题转化为清晰且细粒度的程序问题，才能够通过 AI 相关的工具去处理。
第二个是教练的角色。我们需要通过一些技巧和方法，比如 CoT、few-shot 等，教会大模型如何按照我们的思路去解决问题。
第三个是裁判的角色。因为 AI 工具生成的结果，由于训练数据的时效性、幻觉问题(Hallucination)等等，其准确性是不能保证的，所以我们需要开发人员具备专业的能力去判断这些生存的结果是否正确、是否可用。
而目前 AI 工具更多的还是起到了一个助手的角色，可以大幅度的增强你的能力。
所以短期内开发人员应该是不会被 AI 工具所替代的。AI 非常强大，但我们也不用过分的放大其作用。
挑战和机会
目前基于 AIGC 的产品开发才刚起步，我们面临着非常多的问题和挑战：
不过挑战也同时意味着机会，机会来临时，你是往前踏一步，还是往后退一步？
挑战虽多，但是只要我们能持之以恒的去探索，小步快跑，快速试错，相信我们一定能成功。
道阻且长，行则将至！
学习资料
如果你还没开始进行 AIGC 相关的开发，那么现在就是最好的时机。我们给大家准备了一些入门资料：
概念与趋势
我们找了几个视频，帮助尚未入门的同学先了解下大模型和 AIGC 的一些基础概念和当前的发展趋势，这样有助于明确方向和后续的学习(强烈建议大家关注各大公司的发布会，获取行业第一手资讯)。
Intro to Large Language Models：
https://www.youtube.com/watch?v=zjkBMFhNj_g&t=1419s
大模型的基础概念介绍。
State of GPT：
State of GPT | BRK216HFS - YouTube
GPT 模型的训练流程，了解这些流程，有助于我们和公司的大模型团队合作时的沟通交流。
GitHub Universe 2023：
GitHub Universe 2023 opening keynote- Copilot in the Age of AI - YouTube
AI 会不会取代开发人员？未来的开发模式可能是怎么样的？或许你能从这个视频中找到答案。特别是最后的 Github Workspace，堪称软件开发领域的革命。
OpenAI DevDay：
OpenAI DevDay: Opening Keynote - YouTube
OpenAI 开发者大会，展示了面向未来的 AIGC 产品的形态以及 ChatGPT 的新特性，能给我们的 AIGC 产品带来很多启发。
教程类
AIGC 和深度学习息息相关，因此了解深度学习的基本知识是必不可少的。这里我们推荐大家从下面的资料入手，这些都是我们亲身实践过、对于新手非常友好的资料。为了避免新手选择困难症，我们这里只推荐最基础的 2 个课程，相信大家完成这 2 个课程的学习后，对于深度学习已经入门了，后续该学习什么内容也会有自己的认识和选择了。
《动手学深度学习》：
这是我今年开始学习深度学习所使用的一本书，有配套的视频，非常适合初学者入门深度学习。
Essence of linear algebra：
Essence of linear algebra - YouTube
线性代数的基础知识，非常生动形象，这些知识会在深度学习中用到。
实践类
我们也将团队进行的一些尝试和实践，整理为了文章，包括：
本地搭建和微调低算力大模型
探索 AIGC 可视化之构建模型微调数据集
AIGC F10 产品开发流程
不过这部分涉及公司业务，就不在这里放出来了。
结语
2023 年是 AIGC 爆发的一年，每个人都是摸着石头过河，AIGC 在多个领域都显示出了巨大的潜力，也让我们的开发模式产生了巨大的变革。经过这一年的尝试，相信大家对于 AIGC 都有了一定的认知和积累，2024 年必然会成为 AIGC 大面积落地的一年，希望大家都能抓住这次机会，打造出“无与伦比的”、“Magical”的 AIGC 产品。