我终于成为了全栈开发，各种AI工具加持的全过程记录

ps: 本文的核心目的是记录和分享一次使用多种AI工具，进行全栈开发的过程，解决某些情况下想做点什么事，但被资源卡脖子的情况，所以多体验和分享一些AI工具，来帮助个人扩大职责边界，用于学习和分享。生产环境或者业务开发流程中慎用，需要仔细阅读文章中的各种流程和限制。本文承诺没有一个AI大模型在过程中受到伤害，只有我，在各种调试中破防。

在现实中我们会有一些基础平台的需求，平台运维久了之后，看得到很多有价值的地方（比如要继续提供新的功能模块），都需要慢慢的打磨，但一旦涉及到设计/前端等等协同资源，就会卡脖子了，很多想做的事情，没法做，或者要拖很久，尤其是年底业务高峰期，各种资源都在业务上。

既然被卡脖子，则需要想点办法。在目前的AI时代，技术方面其实很难被卡到脖子的，经常玩编程的小伙伴们都知道，在AI出现前后，学习一门编程语言的效率和体验是完全不一样的，好比我之前学习Rust，直接上来写书（之前有和ChatGPT一起写过一本Rust教材）。除了去学习前端和相关的技术栈，目前有着众多的AI工具，如Cursor、Windsurf这一类AI IDE工具，还有如Bolt.new等AI驱动的前端工程平台，甚至海外还有mgx.dev这样的Multi-Agent的开发平台。

mgx.dev，包括五个角色（项目管理、工程师、架构师、TL、数据分析师），但实际上就工程师在干活

所以本文从一个需求出发，全程记录如何进行全栈开发，其实也很简单，另外会有一些附加的内容，比如基于dify + Bolt.new，很容易能做出来很多有意思的东西，因为Bolt.new这样的工具，更多的是生成前端代码，而Dify天然是Backed as a Service，能很容易拉出来一个应用服务，但正好缺乏前端搭建的能力（补齐了和Coze的核心差距，又更加智能）。

插入一段思考：

<think>

虽然很多内容讲到前端，但实际上并没有取代前端工程师或者其他的含义，关于AI时代和取代，很多人会有技术焦虑。这篇文章并没有传达焦虑，这里我额外的做一些解释，我所理解的AI提效。

好比游戏行业，最近很火的新闻就是 “AI三小时做的游戏，九天挣了12万”，以前游戏制作需要美工、程序等等一起开干，做出来成本比较高，而且制作人在来回拉扯中，往往因为成本和掰扯偏离方向。现在几个游戏制作人直接下场，有激情就能做。工具变简单了，很多游戏美工和程序失业了，但游戏行业真的变差了吗？

依我来看，游戏行业在AI加持下只会更好，因为游戏行业失败的原因有且只有，游戏不好玩了，大家不爱玩了，而现在游戏制作人更容易做出来符合自己脑海里的游戏了，所以能预见可以玩到更多，更有趣的游戏，这对于行业来说是好事，对我玩游戏的人来说也是好事。

而更应该做的则是有制作游戏的激情和思路，避免自己成为工具人，做更多人应该去做的事，而应该定义自己为工具，只去做其中一环，不负责只干活，这样是不行的，每一个参与在游戏行业的人，都应该去踊跃的去使用这些工具，争取做出更好玩的游戏。

</think>

自从春节DeepSeek火的一塌糊涂，一上班，大家都在找「服务器繁忙，请稍后重试」的方案，并且孵化出“满血版R1”、“残血版R1”这样的名词，我也不例外，找了一圈，最后还是回归咱们公司百炼提供的DeepSeek R1的服务，并且一过年回来，就在内部部署的Dify上支持了DeepSeek的模型。

一开工就支持了DeepSeek R1模型的调用，重点是<think>的支持

但仅仅只是支持这个模型使用，是远远不够的，还有很多人没有体验过和DeepSeek R1的对话，所以最好的方案，还是直接进行一个呈现，类似IdeaTalk这种，有一个开箱即用的DeepSeek R1对话的地方，能进行多轮对话，能够进行记忆重置，能够进行<think>和</think>的转义，但Dify原生拉出来的应用落地并不支持<think>的转义，并且页面也比较生硬，现在咱就需要自己上手来撸页面了，成品如下所示。

平台提供的一系列工具页面，包括和多个模型的AI对话，也包括一系列的工具；另外<think>这里替换成了Markdown的```think样式。这些页面和编排，都由AI完成

当然我们需要一个能帮我们从0到1进行自然语言编写页面的工具，这个时候就需要Bolt.new了，Bolt.new是一个开源的自然语言进行产品编写的工具，和MGX那种比较类似：

Bolt.new的首页，你只需要自然语言描述你想要什么产品，代码生成都由AI完成

我们先搭建一个能好好聊天的页面，先打开一个Bolt.new产品，对话式的输入（这里主要Dify的apiKey会明文投出，建议提供服务的时候再进行一次加解密的逻辑）：

使用类似Bolt.new这样的开源产品，尝试生成一个对话机器人页面

但是这样发现效果并不好，让AI纯粹的去写聊天机器人，调试起来比较困难，所以调转车头，看能不能有一个比较美观的框架，然后把Dify落地的对话页面嵌入到页面中，继续输入：

继续对话，生成一个美观的页面，并且嵌入一个页面

好，现在发现非常的OK，然后把代码都下载下来，放进Cursor进行微调（这里忽略微调的过程），在自己本机上安装好node相关的环境，接下来：

npm installnpm run build

可以构建出dist目录，采用Github Pages（https://docs.github.com/en/pages/quickstart）的功能，上传这些构建好的dist目录，可以很快地拉出一个页面服务。

到上面，我们有了一个类似OpenAI GPTs等这样的能直接和DeepSeek-R1对话的地方，并且还能和不同的模型进行切换，能保存记忆，能够重置（一半是Dify的能力、一半是生成的前端代码进行部署）。现在我们不希望仅仅如此，我们在Dify上能搭建出很多有用的工具，比如JSON修复、SQL生成、时序图等等生成的常用小工具的能力，其实也可以通过Bolt.new、Cursor这类工具快速的给Dify配置上前端代码生成的能力，说干就干。

上述生成的页面，我们留下一个扩展，每一个菜单栏，都会渲染一个iframe嵌入页面，并且每个页面，都有一个单独的代码仓库，成果如下，多了一个菜单【研发工具专区】，并且点击后会渲染另一个 Github Pages 孵化的页面，这个页面大概长右边这样，有多个工具集可以选择，每个工具集下，有一系列的小工具。

制作一系列的小工具，比如JSON系列工具、设计画图各类工具等等

每一个这样的页面，可以单独来做，如下所示，这个过程是比较重复和机械化的，上面的过程了解的看官基本都会掌握，就不再继续赘述。同理，非常多的页面都可以这样来做，然后和后端通信的话，就告诉它，点击按钮后，触发dify的API，写个案例就可以了。

小工具和Dify API的通信

这里整个流程就比较清晰了，那么剩下的事情，就是发挥想象力的时候，页面可以嵌页面，页面单独去生成，生成的页面可以通过按钮去触发Dify API的调用，达到AI流程具备页面展示的可能性，并且整个过程很快很高效，调试起来比较耗时间。

上面的过程都是从0到1建设一个工具，并且是新的页面，很多同学会说，你这也不是全栈开发呀，真正的全栈应该能直接对一个已有系统的前后端进行持续开发和迭代，而不是都用小工具来做。这里再来一个完整的需求，这次不是小工具，而是在Dify本身上进行改进。

先讲下背景，Dify本身有很完整的编排、API服务和日志管理能力，但缺乏数据集管理和评测能力，而同类型的诸如百炼，这样的服务都有提供数据集管理和评测能力。而我们在调试一个工作流的效果的时候，是需要对同样的一波输入，多轮回放，并且进行评测，这个评测本身最好也依赖一个独立的工作流去实现。

整个过程涉及对页面的改造、服务端实现等，是一个较为复杂的新需求，而这个过程全部都是我来搞定，接下来讲讲完整的实现。

先进行需求设计，既然需要数据集管理与评测，则需要有一个明确的入口，这里设计每个工作流应用，可以管理自己的数据集，并且在数据集管理页面中进行批量运行和评测，所以在入口的设计就是在Dify的左侧菜单，增加一个入口，叫做“数据集管理与评测”，如图所示：

在左侧栏，加入一个菜单，专门做数据集管理

那么，数据集从哪里来呢，可以从日志中已经运行过的结果中去取，所以在查看日志的时候，需要新增一个入口，让用户能够很容易的加入到数据集：

在日志提供 加入数据集 按钮，自动把这条日志加入到数据集

当然也可以手动录入数据集，接下来需要去设计“数据集管理与评测”的内部细节，加入数据集，在进入左侧菜单后会展示，并且可以进行管理（增删改查的一套），后续的页面是一套简单的CRUD的新的管理页面，以及评测内容管理页面，采用类似上面的Bolt.new+Cursor可以快速的完成，这里就不过多的介绍了，主要说明在原来的产品上，如何进行这几个入口的改造。

那么设计完了，先写一篇设计文档，将前后端如何去实现给完整的写出来，接下来就可以开干了。

先来写前端，为什么是前端呢，因为数据都可以mock，先把界面这些给做清楚，能够具备一个完整视角，写完前端也就更清楚后端如何去写了。

这里因为前端整体功能比较多，这里就简单说明下侧边栏加入一个页面，以及日志页面上增加一个“加入数据集”按钮的模式如何实现。

下面是整体使用Curosr（Dify的前端代码基本都是开源，几乎没有二开，所以无数据安全问题，大家在公司内使用的时候注意代码数据安全）的记录过程，及相关截图。

先大概自己在HTML上改下（要是有这种AI工具就挺好的），然后截图告诉AI，我现在要加个菜单栏。

然后大概自行定位到导航栏的位置，然后直接描述要在什么位置加一个按钮，点击后会触发什么后端接口。 （这个时候后端接口还没有，先假设有了）

这个时候，这个按钮代码生成完了，根据自己的感觉 Accept 一些代码，部署，最开始样式很奇怪（这里忘了截图，想象一下），然后继续让它改样式。

改样式 继续修改样式 继续继续修改样式 这里就简单说明下，但是改了真的很多轮。

改好之后，大概长这样。 但是这个时候后端代码还没有，所以会报错，但是报错没有任何提示，继续让它追加Toast提示。 截图+描述，一定要尽量清晰，然后不要无脑去接受代码，需要看下，理解下，毕竟代码都帮你写好了，Review清楚能事半功倍。

然后还是会继续报错，让他不停的调整： 这个时候，其实应该了解下报错的原理，不能无脑，我这个时候是看了下代码，不懂得地方问了下相关的AI，并且看了下其他地方怎么实现的，然后告诉他应该这样改。 再调试几轮，基本就改好了。

扩宽边界从来不是一件简单的事情，哪怕现在有了很多很方便的AI工具，但AI工具一样是为人在服务，要达成这套模式，我大概梳理了五条技能，这里面达成四条，基本就能独立进行开发，但是复杂的功能还是会陷入无休止的调试，所以有待更多的实验过程。