我終於成為了全棧開發，各種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>

二、先來做一些小工具

2.1 從R1的對話工具說起

自從春節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目錄，可以很快地拉出一個頁面服務。

2.2. 補充各種小工具

到上面，我們有了一個類似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服務和日誌管理能力，但缺乏資料集管理和評測能力，而同類型的諸如百鍊，這樣的服務都有提供資料集管理和評測能力。而我們在除錯一個工作流的效果的時候，是需要對同樣的一波輸入，多輪迴放，並且進行評測，這個評測本身最好也依賴一個獨立的工作流去實現。

整個過程涉及對頁面的改造、服務端實現等，是一個較為複雜的新需求，而這個過程全部都是我來搞定，接下來講講完整的實現。

3.1 需求設計

先進行需求設計，既然需要資料集管理與評測，則需要有一個明確的入口，這裡設計每個工作流應用，可以管理自己的資料集，並且在資料集管理頁面中進行批次執行和評測，所以在入口的設計就是在Dify的左側選單，增加一個入口，叫做“資料集管理與評測”，如圖所示：

在左側欄，加入一個選單，專門做資料集管理

那麼，資料集從哪裡來呢，可以從日誌中已經執行過的結果中去取，所以在檢視日誌的時候，需要新增一個入口，讓使用者能夠很容易的加入到資料集：

在日誌提供加入資料集按鈕，自動把這條日誌加入到資料集

當然也可以手動錄入資料集，接下來需要去設計“資料集管理與評測”的內部細節，加入資料集，在進入左側選單後會展示，並且可以進行管理（增刪改查的一套），後續的頁面是一套簡單的CRUD的新的管理頁面，以及評測內容管理頁面，採用類似上面的Bolt.new+Cursor可以快速的完成，這裡就不過多的介紹了，主要說明在原來的產品上，如何進行這幾個入口的改造。

那麼設計完了，先寫一篇設計文件，將前後端如何去實現給完整的寫出來，接下來就可以開幹了。

3.2 前端開發

先來寫前端，為什麼是前端呢，因為資料都可以mock，先把介面這些給做清楚，能夠具備一個完整視角，寫完前端也就更清楚後端如何去寫了。