前言

AI會改變開發模式甚至行業崗位

1.AI 軟件工程開發

工程方向

1.1. AI Developer Studio （playground級）

開發平臺/工具一般包含多種先進的LLM，并開放了很多定制化設置，供用戶開發。相比于純ChatGPT這種使用工具，AI Developer Studio是基于AI的工作平臺。
一般來說，滿血的賬號費用都較高，免費使用的閹割了很多功能，僅開放一小部分數據訓練、參數調整以及少量LLM供選擇。

1.Vertex AI (Geogle)

• Vertex AI Studio：Multimodal、Language(text/tasks/code…)、Vision(video/image…)、Speech(audio…)

• LLM (Large Language Model) prompt: Zero-shot prompting / One-shot prompting / Few-shot prompting

• Prompt design:
  1.freedom:大模型直接問答
  2.structured(Context給出背景，Example給出想要的input和output，以規訓重點，最后Test)：大模型根據你的偏好，save一個特定大模型，回答你的問題

• How to design Prompt（Prompt工程師）:
  Be concise
  Specific and clearly-defined
  ask one task at once
  ask to classify instead of generate(要選擇題最好不要發散式)
  include examples

• temperature(概率分布): 對回答的隨機程度進行調優， 0-1, 0是確定, 1是隨機, 即越靠近0概率越大
  top K: 對回答的概率最高的一部分答案進行隨機
  top P: 對回答的概率最高的答案進行累加，直到累加值達到top P，即對回答的概率最高的答案進行隨機

• 模型調優(Model tuning):
  How to customize and tune a gen AI model:
  越來越偏技術：
  1.Prompt design: Input(required) Context(optional) Example(optional)
  2.Adapter tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.監督，給出一小部分樣本調優參數
  3.Reinforcement tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.非監督調優
  4.Distilling(Student model weight updates): 在Geogle cloud可以做, 可以更加生成特定模型。我理解就是遷移學習。

• Difference between AI and Machine Learning:
  輸出確定的、“舊的”東西，用學術的話，輸出的是Number、Discrete、Class、Probability的，叫ML。
  能輸出“新的”東西，用學術的話，輸出的是Natural language、Image、Audio（即所謂的非結構化數據），叫GEN AI。
  舉個例子，如果輸入貓狗圖片，且每張圖片label是文字“貓”、文字“狗”。訓練后模型最后能預測貓狗，這叫ML。
  如果輸入大量的貓狗圖片，且按照你想要的方式進行訓練（這里涉及到模型了，具體需不需要lable或者怎么lable有疑惑）。訓練后模型最后能生成新的貓狗圖片，這叫Gen AI。

• AI Develop
  Data Security，開源的模型，私有化部署local AI(teacher student…)

2.Azure AI Foundry (Microsoft)

1.2. Agent & RAG

1. Agent

• 能夠基于任務目標執行(行動，動作，action)多步驟動作的系統，它能通過調用工具、API 、知識庫、插件、代碼庫等等，動態規劃并完成復雜任務。Agent 具備一定程度的自主決策能力。

• 核心組成：
  Brain: 處理/計算/記憶/計劃/決策
  Perception: 多模態輸入
  Action: 調用工具、SDK、API 、知識庫、插件、代碼庫等等，完成交互

• Agent 設計模式
  Reflection pattern：LLM審核LLM（LLM串）
  Tool use pattern：Tool, Database, API and MCP
  ReAct pattern：Reasoning and Acting. 由于推理類模型發展，由R模型自己出調用方式及順序。再串通用模型（G模型）。
  Planning pattern：升級成任務維度。每個任務交給一個ReAct Agent。
  Multi-agent pattern：升級成人類組織維度。每個工作交給特定職位Agent，且能內部之間交互。

2. RAG, Retrieval Augmented Generation

• RAG：Retrieval-Augmented Generation的縮寫，指“檢索增強生成”，這是一個跨越檢索和生成任務的框架，通過先從數據庫或文檔集合中檢索到相關信息，然后利用生成模型（如Transformer模型）來生成最終的輸出。工程領域。

• LLM應用方案。將大模型應用于實際業務場景遇到幾個問題：1.無法具備全部知識（包括實時數據、非公開數據、私有數據、私有專家知識等） 2.幻覺（無法具備全部知識）3.數據安全 4.微調計算成本較高

• 核心思想：檢索 增強 生成。檢索體現在：私有數據/數據存儲到向量數據庫（因為結合了transformer訓練時數據處理word embedding）后高效的檢索能力，召回目標知識。生成體現在：大模型+Prompt工程，將召回的知識合理利用，融入到Prompt里，大模型更根據目前的提問+能夠參考相應的知識（上下文），生成目標答案。主要分三個階段：數據準備、數據召回（向量搜索出最相近的k個數據庫）和答案生成

• 向量數據庫：Faiss等等

• 詞嵌入Embedding：將高維、稀疏的離散數據，如文本、圖像、用戶行為等，映射到低維、稠密的連續向量空間。通過向量形式能夠精準捕捉數據間的潛在語義關系，使得計算機可以通過幾何距離，如歐氏距離、余弦相似度，來量化分析數據的相似性和相關性。

• 提示詞工程（Prompt Engineering）

Tips:
Prompt工程：一般包括任務描述、背景知識（檢索得到）、任務指令（一般是用戶提問）

3. 再談RAG

傳統樸素RAG流程:
Document -> Chunking - > Embedding -> VectorStore <- Embedding <- Query/Prompt(LLM) <- Query ↓ Retrieval chunks(高維向量語義相似度, VectorDB針對向量快速檢索/大規模并行處理/存儲等專業功能) ↓ Prompt/Answer ↓ LLM↓ Answer to UserRAG 2.0 針對不足，進一步在流程編排和工程/算法上做優化:
RAGFlow框架

1.3. LangChain & LangGraph

LangChain for LLM Application Development:

• LangChain is a open-source framework for developing applications powered by language models(LLM Applications).
• python version(packages) & JS/TS version(packages)
• Composition and modularity
• Components / Off-the-shelf chains: Off-the-shelf chains make it easy to get started. Components make it easy to customize existing chains and build new ones.

modules：

• Components fall into the following modules:
  1.Models
  2.prompt and output parsers
  3.index(for RAG)
  4.Chain(eg. prompt + LLM + output parsing. And more and more application chains)
  5.Agents(LLM base, Memory(chatbot), Action)

Models, Prompts, Output Parsers: API/Local. (LangChain’s hello world)

Memory: LLMs are stateless. Chatbots appear to have memory by providing the full conversation as context. However, LLMs API is charge by token. Langchain provide some memory tricks, feature like keep just a number of conversiation/tokens.

Chains: use ‘MoE’ idea in Enginner. Intertesting.

Q&A with Documents: word embedding, vector database, index. query come, after this, give LLM. Stuff method, simple RAG. Additional 3 methods: Map_reduce/Refine/Map_rerank

Evaluation: use LLM to evaluation answer.

Agent: pre/cus tools.

• LCEL

LangChain Expression Language (LCEL): 異步、批處理和流支持
eg. 代碼里寫chain = prompt | model | output_parser，類似學linux操作系統里的linux命令的piple概念。

• ReAct
  The ReAct (Reasoning and Acting) pattern is a framework for building AI agents that combine reasoning (thinking) with acting (taking actions).Break Down.

Built an agent from scratch.

Prompts: can import. allow reusable prompts(LangChain hub).

Tools: get a tool from the library.

Others: pattern is also like graphs.

• LangGraph

Knowledge Graph 知識圖譜：是結構化的語義知識庫，用于迅速描述物理世界中的概念及其相互關系。實體,關系,實體。

圖數據庫：Neo4j

LangGraph 是一個結合 LangChain 與知識圖譜（Knowledge Graph）的應用，旨在通過結構化的知識庫增強語言模型的理解和響應能力。

Graphs to build Agent:
1.Nodes(Agents or functions), Edges(connect nodes), Conditional edges(decisions)
2.Data/State: State Memory (State Snapshot)
3.Image: can draw the image of your graph.
4.powerfull Tool: Search Tool(like Tavily)
5.persistence and streaming: usefully in long running application.
checkpoints(database, SQL, NoSQL) for persistence.
get individual messages / observation message / token of streaming(not .invoke)
Above of these can config as 2 thread to separate 2 mode. (another model don’t have this model’s persistence/memory)
6.user/human can interrupt the loop and choose(improve)

• SQLite

一款輕型-輕量級的數據庫，是遵守ACID的關系型數據庫管理系統。

架構：MySQL 是一個客戶端/服務器架構的數據庫管理系統，這意味著它需要一個單獨的服務器進程來運行。而 SQLite 是一個無服務器的數據庫管理系統，它直接讀取和寫入磁盤文件。

存儲：MySQL 數據庫存儲在磁盤上的文件中，但需要通過 MySQL 服務器進程來訪問和管理。SQLite 數據庫也存儲在磁盤上的文件中，但可以直接通過 SQLite 命令行工具或編程語言的 SQLite 庫來訪問和管理。

SQLite是文件級的。所以替代的是文件存儲的級別，不是client/server數據庫的級別。單體/接單用足夠。直接給它存成文件。

LangGraph寫Agent用到了。

• Spring AI
  Java有Spring AI

1.4. MCP, Model Context Protocol

MCP, Model Context Protocol，旨在統一大型語言模型（LLM）與外部數據源和工具之間的通信協議。分client和server。client在host里。

host指的我們的調用程序本體，可以是LLM程序，IDE，AI工具，LangChain代碼框架。

client / server，感覺和之前原始手寫socket一個意思，一個client一個server建立網絡通信TCP/IP。

協議

阿里云百煉 業內首發MCP服務，與開發者共同打造企業級AI應用新生態

1.5. Ollama

• Get up and running with large language models.
• 本地部署（非常方便的）多種LLMs
• 支持模型微調
• 支持命令行運行與直接交互、Ollama 的 Python SDK使用、API交互、WebUI

1.6. Coze & Dify

• Coze: 個人開發者 & Demo應用
• Dify：企業級

2.AI 算法

2.1. GenAI算法相關

2.1.1 Transformer

1.絕大多數先進的多模態大模型（如 GPT-4o、DeepSeek、Qwen2.5 等）的底層架構均基于 Transformer，但會根據多模態需求進行擴展和優化。Transformer 的核心優勢在于其 自注意力機制（Self-Attention），能夠高效建模長距離依賴關系，并天然支持并行計算。對于多模態任務（文本、圖像、音頻等），模型會通過以下方式擴展：

• 多模態輸入編碼：將不同模態數據（如文本、圖像、音頻）統一編碼為向量序列。例如：圖像被切分為小塊并通過視覺編碼器（如 ViT）轉換為嵌入向量；音頻通過語譜圖、波形編碼、短時傅里葉變換等預處理方式，預處理為向量序列（my work）。
• 跨模態注意力機制：允許不同模態的嵌入向量在注意力層中交互。

2.Transformer 模型的訓練方式
核心訓練范式：自監督預訓練 + 有監督微調

• 階段 1：預訓練（自監督學習）：讓模型從海量無標注數據中學習通用表示（如語言規律、跨模態關聯）。輸入和標簽均來自同一數據，無需人工標注。典型的方法有掩碼語言建模、自回歸預測、多模態對齊等
• 階段 2：微調（有監督學習）：針對特定任務（如問答、圖像描述生成）優化模型。需要人工標注的輸入-輸出對。指令微調、強化學習等
• 階段 3：推理（部署后）。訓練時需標簽（顯式或隱式），推理時僅需輸入。

references：
Attention is all you need
十分鐘理解Transformer

2.2. 傳統AI算法相關

SCI-2區：LSTM-convolutional-BLSTM encoder-decoder network for minimum mean-square error approach to speech enhancement
EI / 中文核心：基于拋物面焦點麥克風預處理和遷移學習的語音增強方法
專利：一種基于混合掩蔽學習目標的語音增強方法

3.架構與業務（架構與垂直領域）

3.1 BPM

3.1.1. BPMN概念

• Business Process Model and Notation，業務流程模型與標記法

BPMN 2.0 最革命性的變化在于引入了可執行性 (Executability)。這徹底改變了BPMN的定位。不僅要統一圖形，更要統一其執行語義和文件格式。它的核心是“建模與執行”(Modeling and Execution)

• BPMN 2.0規范中有一百多個符號，但日常工作中80%的場景只需要用到其中不到20%的核心符號。

1.流對象 (Flow Objects)：流程圖中的主要圖形元素。

• 事件 (Events)：表示流程中發生的事情。用 圓圈 表示。

  • 開始事件 (Start Event)：一個細線圓圈，表示流程的起點。
  • 結束事件 (End Event)：一個粗線圓圈，表示流程的終點。
  • 中間事件 (Intermediate Event)：一個雙線圓圈，表示流程進行中發生的事情（如等待、收到消息）。
  • 消息時間 (Message Event)：一個帶箭頭的圓圈，表示流程中接收或發送消息。

• 活動 (Activities)：表示需要完成的工作。用 圓角矩形 表示。

  • 任務 (Task)：一個原子性的工作單元，不可再分。
    （用戶任務：當流程引擎走到一個用戶任務時，它會暫停該流程實例的執行，并在其內部數據庫中創建一個“待辦任務”記錄，并將其分配給BPMN圖中指定的負責人（assignee）或候選組（candidate group），引擎會一直等待，直到有人通過外部應用（如您的Express應用）來“完成”這個任務；服務任務：需要由系統自動完成的工作（例如調用外部API、發送郵件、處理數據），對于Java來說，可以寫一個Java的業務實現類，然后配置給流程引擎，由流程引擎調用。）
  • 子流程 (Sub-Process)：一組相關的任務，可以折疊和展開。

• 網關 (Gateways)：表示流程的分叉和合并。用 菱形 表示。

  • 排他網關 (Exclusive Gateway)：菱形里一個"X"。表示只有一個分支會被選擇（類似if-else）。
  • 并行網關 (Parallel Gateway)：菱形里一個"+"。表示所有分支都將同時執行。
  • 包容網關 (Inclusive Gateway)：菱形里一個"O"。表示可以有一個或多個分支被選擇。

2.連接對象 (Connecting Objects)：用于連接流對象。

• 順序流 (Sequence Flow)：實線箭頭，表示執行的順序。
• 消息流 (Message Flow)：虛線箭頭，表示不同流程參與者之間的消息傳遞。

3.泳道 (Swimlanes)：用于組織和分類活動。

• 池 (Pool)：代表一個獨立的流程參與者（如一個公司、一個部門）。
• 道 (Lane)：在池內部，用于區分不同的角色或系統（如“申請人”、“經理”、“財務系統”）。

4.工件 (Artifacts)：提供額外的信息。

• 數據對象 (Data Object)：表示流程中需要用到的數據（如“報銷單”）。
• 注釋 (Annotation)：對圖表進行文字說明。

(
更復雜場景也支持，如：
不同類型的事件：定時器事件（等待特定時間）、消息事件（接收/發送消息）、錯誤事件等。
不同類型的任務：用戶任務、腳本任務、服務任務等。
事務性子流程 (Transactions) 和 補償 (Compensation)。
)

3.1.2. BPMN類系統/低代碼系統 前端框架 Logicflow

LogicFlow 是一款滴滴客服技術團隊開源的流程圖編輯框架，它提供了一系列流程圖交互、編輯所必需的功能和靈活的節點自定義、插件等拓展機制。

Apache-2.0開源、支持前端三大框架

（Logicflow用法上，和g2plot/echarts之類的用法類似，代碼里各種配置參數）

（發散聊一下，前端框架很多，如UI框架Element UI/Plus、Ant等等，還有低代碼前端的框架，還有基于三大框架開發的工程化的項目框架即web那一套動態路由等等工程上的問題也全封裝好了）

3.1.3. BPMN類系統后端引擎（BPMN引擎）

Flowable / Camunda 8(Cloud Native)：兩大開源流行的BPMN 2.0流程引擎。可以直接在擋墻微服務里嵌入集成（即引包并配置），也可以獨立部署（即單獨部署一個服務，然后調用）。

問：floable和Camunda 提供拖拉拽設計流程頁面嗎？他們相當于是對xml進行編解碼？舉個例子：我在bpm建模器（如floable和Camunda）拖拉拽建模，會生成xml，然后java代碼里集成floable和Camunda可以解析xml流程，然后執行。所以相當于代碼永遠不變，變的是xml？

答：

1. Flowable和Camunda提供這個頁面嗎？

是的，它們都提供！ 這就是我們之前提到的“BPMN建模器”，它是整個生態系統不可或缺的一部分。
Camunda: 提供一個名為 Camunda Modeler 的免費桌面應用程序。這是業界的黃金標準，非常強大和易用。
Flowable: 提供一個名為 Flowable Designer 的Web應用。它通常集成在Flowable的完整產品套件中，讓你可以直接在瀏覽器里建模。

2. 它們相當于是對XML進行編解碼？

編碼 (Encoding): 當您在BPMN建模器里拖拽圖形、填寫屬性時，建模器正在實時地將您的可視化操作編碼成符合BPMN 2.0標準的XML文件。您看到的圖形是給人看的，背后的XML是給機器讀的。
解碼 (Decoding / Parsing): 當您的Java應用（集成了Flowable/Camunda）啟動或部署這個XML文件時，流程引擎會讀取這個文件，并將其解碼成一個它可以在內存中理解和執行的、由Java對象構成的流程模型。

3. 總結：

建模階段: 您（或業務分析師）在BPMN建模器中通過拖拉拽的方式，設計或修改業務流程。完成后，您得到一個 .bpmn (本質是XML) 文件。

部署階段: 您將這個 .bpmn 文件部署到流程引擎。對于嵌入式集成，通常就是把它放在Java項目的資源文件夾里，應用啟動時引擎會自動加載并解析XML。

執行階段: 您的Java代碼（比如一個Controller）調用 runtimeService.startProcessInstanceByKey(…)。引擎接收到指令，根據它已經解析好的流程模型，開始一步步執行流程。

監控階段：自定義

4. 所以相當于代碼永遠不變，變的是XML

我們把您的Java代碼分成兩類來看，這個概念會更清晰：

a) “流程控制”代碼 (The Orchestration Code) - 這部分【永遠不變】
這部分代碼就是您在Express或Spring里寫的那些通用的、與具體業務步驟無關的代碼。

startProcess(…)
getTasksForAssignee(…)
completeTask(…)
這些代碼就像一個CD播放機。它非常通用，它的功能就是“播放光盤”、“查詢曲目”、“下一首”。不需要為了換一張CD而改造播放機本身。

b) “具體工作”代碼 (The Implementation Code) - 這部分【可能需要補充】
這部分代碼是指BPMN流程圖中“服務任務(Service Task)”背后需要執行的具體業務邏輯，通常是一個JavaDelegate類。

這就像是CD播放機的特效插件。

如果流程變化只是調整順序、修改條件、增減人工審批步驟：
比如審批金額從5000改成3000。比如在總監審批后增加一個“副總審批”的人工任務。
在這種情況下，您只需要修改XML（換一張CD），Java代碼一行都不用動。

如果流程變化是增加了一個【全新的自動化步驟】：
比如業務部門要求：“在財務審批通過后，系統需要自動調用ERP系統接口來創建憑證。”
這時，需要在BPMN圖上增加一個“服務任務”，并告訴它需要調用一個名為 ErpIntegrationDelegate 的Java類。如果代碼庫里還沒有這個 ErpIntegrationDelegate.java 文件，那么就需要新增這個Java類（安裝一個新的“特效插件”）。

但是，原有的“流程控制”代碼（播放機本身）依然不需要改變。

最終結論
90%的情況下，業務流程的變更都只是邏輯、順序和條件的調整。對于這些變更，您只需要修改BPMN圖（即XML），而您的核心代碼庫保持穩定、無需改動。

這實現了業務流程的熱插拔，將易變的業務規則從相對穩定的程序代碼中解耦出來，這正是流程引擎帶來的革命性優勢。

以單獨部署流程引擎服務為例：1.啟動流程:
前端: 用戶填寫申請表單。
Java后端: 接收表單數據，調用 ApprovalService.startProcess(processDefinitionKey, variables)會返回id。
流程引擎: 啟動流程實例，創建第一個用戶任務（“經理審批”）。
(processDefinitionKey會指向.bpmn文件即流程定義，.bpmn 文件本質上是一個遵循 BPMN 2.0 XML Schema 定義的 XML 文檔)2.經理審批 (用戶任務):
前端: 經理登錄，調用 GET /api/process/tasks/managerId
Java后端: 查詢任務，返回給前端（==和流程引擎交互獲取流程信息==）。
前端: 展示“經理審批”任務。經理點擊“批準”。
前端: 調用 POST /api/process/tasks/{taskId}/complete，傳入 approved: true。
Java后端: 調用 ApprovalService.completeTask()。
流程引擎: 收到完成指令，根據BPMN圖和approved變量，流程流轉到“總監審批”用戶任務。3.總監審批 (用戶任務):
重復經理審批的步驟，只是assignee變成了總監。4.財務審批 (用戶任務):
重復總監審批的步驟，只是assignee變成了財務。5.發送通知郵件 (服務任務):
如果BPMN圖中有這個服務任務，當流程流轉到它時，流程引擎會自動調用您在Java后端實現的 SendEmailDelegate 的 execute 方法。
SendEmailDelegate 執行郵件發送邏輯。
流程引擎繼續推進流程，直到結束。

流程定義（BPMN XML）和流程實例狀態（運行時數據）之間的根本區別: 建筑藍圖 vs. 正在建造的房子BPMN XML文件（.bpmn）：
流程定義。它是靜態的，可移植的，任何符合BPMN 2.0標準的引擎都能解析。
這就像一張建筑藍圖。它詳細定義了房子的結構、房間布局、水管電線的走向、門窗的位置、以及各種施工規范。
它是一個靜態的、通用的設計圖紙。
它不包含任何關于“正在建造的房子”的信息：比如房子蓋到第幾層了，哪個工人正在哪個房間里施工，墻刷了什么顏色，里面住了誰。流程引擎的數據庫（運行時數據）(流程引擎支持N種數據庫，==會自動在連接的數據庫里面建表，自動管理Schema==)：
是流程執行器和狀態管理者。每個引擎實例都有自己的數據庫來存儲運行時（Runtime）的流程實例狀態。
這就像正在建造的房子本身。它記錄了：
這棟房子（某個流程實例）的唯一ID。
房子目前蓋到了哪一步（流程執行到哪個節點）。
房子里有哪些家具（流程變量，比如申請金額、審批意見）。
哪個工人（用戶）正在哪個房間（任務）里工作。
房子的歷史（之前蓋了哪些部分，誰蓋的）。
這些信息是動態的、特定于某個實例的。每個流程引擎都有自己內部管理運行時數據的數據庫表結構和狀態管理邏輯。這些表結構雖然概念上相似（都有任務表、流程實例表），但具體字段、索引、內部ID生成方式等可能存在差異。