AI 全栈软件工程开发 & AI 算法 & 架构与业务

前言

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. Chat & Agent & RAG

  1. Chat

1.并发编程支持

2.对话类通信协议要求
WebSocket在实时双向通信和流式数据传输的AI聊天应用中确实是最佳实践。WebSocket是一种网络协议，与HTTP协议处于同一层级，都是应用层协议，它们都建立在TCP传输层协议之上。

除了WebSocket之外，还有几种类似的实时通信技术，它们各有特点和适用场景：

1.Server-Sent Events (SSE) ：

  • 基于HTTP协议的单向通信技术，服务器可以主动向客户端推送数据 1
  • 与WebSocket的主要区别：
    • SSE是单向通信（仅服务端→客户端），而WebSocket是双向全双工通信 4
    • SSE基于HTTP协议，使用简单且内置自动重连机制 1
    • WebSocket需要独立协议（ws://或wss://），相对复杂 4

2.MQTT (Message Queuing Telemetry Transport) ：

  • 轻量级的发布/订阅消息协议，专为低带宽、高延迟网络设计 2
  • 特点：
    • 采用发布/订阅模型，解耦消息生产者和消费者 2
    • 适用于物联网(IoT)场景，如传感器数据传输 2

3.HTTP Streaming ：

  • 通过HTTP长连接实现服务器向客户端持续推送数据 3
  • 与WebSocket的区别：
    • HTTP Streaming复用HTTP连接，开销较低 4
    • WebSocket需要独立TCP连接，开销较高 4

这些技术的选择取决于具体的应用场景：

  • 如果只需要服务器向客户端推送数据（如实时通知、股票行情），SSE可能是更好的选择 4
  • 如果需要双向实时通信（如聊天应用、在线游戏），WebSocket更合适 2
  • 对于物联网设备通信，MQTT因其轻量级特性而被广泛采用
前端 - 后端 - MCP  典型流转：
前端 <--WebSocket--> 后端（Agent）  <--MCP(SSE)--> 搜索工具server
                                  <--MCP(HTTP)--> 其他简单工具server
                                  <--MCP(WebSocket)--> 需要双向通信的复杂工具server
                                  <--MCP(stdio)--> 本地工具server
  1. Agent

  • 能够基于任务目标执行(行动，动作，action)多步骤动作的系统，它能通过调用工具、API 、知识库、插件、代码库等等，动态规划并完成复杂任务。Agent 具备一定程度的自主决策能力。

  • 核心组成：
    Brain: 处理/计算/记忆/计划/决策
    Perception: 多模态输入
    Action: 调用工具、SDK、API 、知识库、插件、代码库等等，完成交互

  • 开发方式

    • 企业级Cloud NoCode/LowCode AI Agent开发: 阿里云百炼（发布的Agent也可以通过暴露API的方式引到自己的应用里）, Azure AI Foundry
    • 在线或本地（因为开源）NoCode/LowCode AI Agent开发: Coze（个人开发者 & Demo应用）, Dify（企业级）
    • 代码级别AI Agent开发框架：RAGFlow, LangChain/LangGraph

  • 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，且能内部之间交互。

Reflection Pattern: 仅大模型，无tool，
Tool Use Pattern: 大模型 + tool.
ReAct Pattern: Reason大模型 + tool + 大模型.
Planning Pattern: 和上面一样，但强调了Plan这个动作.
Multi-Agent Pattern: 和上面一样，但强调了多Agent协作.

ReAct典型: Reason and Act（Thought, Action, Observation. Loop and Finish）。先做，然后再根据做的结果看下一步。

Plan典型：Prompt工程。先Plan，然后再按照计划执行每一步。

（最佳实践中Plan 可以+ ReAct）

Multi Agent典型：每一个unit领域都是一个Agent。并结合起来。MoE的multi Agent

  • 根据API自定义包装LangChain支持模型
graph TD
    A[用户输入] --> B{模型类型}
    
    B -->|OpenAI/Claude| C[LangChain直接传递tools]
    C --> D[API原生处理工具]
    D --> E[返回结构化tool_calls]
    E --> F[LangChain自动执行工具]
    F --> G[获得最终结果]
    
    B -->|自定义模型| H[LangChain包装tools到提示词]
    H --> I[API接收纯文本]
    I --> J[模型生成文本形式的工具调用]
    J --> K[手动解析工具调用]
    K --> L[手动执行工具]
    L --> M[构造新提示包含结果]
    M --> N[再次调用API]
    N --> G

(OpenAI在2023年推出Function Calling功能,Claude也随后支持了Tool Use功能.这些都是API级别的原生功能)
  1. 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工程：一般包括任务描述、背景知识（检索得到）、任务指令（一般是用户提问）

  1. 再谈RAG

传统朴素RAG流程:
Document -> Chunking - > Embedding -> VectorStore <- Embedding <- Query/Prompt(LLM) <- Query 
                                           ↓ 
                                      Retrieval chunks(高维向量语义相似度, VectorDB针对向量快速检索/大规模并行处理/存储等专业功能) 
                                           ↓ 
                                      Prompt/Answer 
                                           ↓ 
                                          LLM
                                           ↓ 
                                        Answer to User

RAG 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)

  • 源码级技术细节

LangChain/LangGraph 中常见的执行方法：invoke, stream, stream_events，以及它们对应的异步版本 ainvoke, astream, astream_events。

  1. invoke() 和 ainvoke()：一次性执行，返回最终结果
    同步版本: invoke(input)
    异步版本: ainvoke(input)
    行为: 启动 Agent 或 Runnable 的执行，并等待其完全完成。一旦执行完毕，它会一次性返回最终的输出结果。
    特点:
    非流式: 在执行过程中不会产生任何中间输出。
    阻塞/等待: invoke 会阻塞当前线程直到结果返回；ainvoke 会等待结果返回，但不会阻塞事件循环。
    简单: 适用于只需要最终结果的场景，代码逻辑最简单。
    何时使用: 当你不需要实时反馈，只关心最终答案时。例如，一个后台任务，或者一个简单的问答机器人，不需要展示思考过程。
    驱动方式: 你直接调用它，它会自己完成所有工作并返回结果。不需要循环。

  2. stream() 和 astream()：流式文本输出
    同步版本: stream(input)
    异步版本: astream(input)
    行为: 启动 Agent 或 Runnable 的执行，并返回一个迭代器（同步）或异步迭代器（异步）。每次迭代会产生一个文本块（或包含文本的 AIMessageChunk 等）。它主要关注 LLM 生成的最终文本输出。
    特点:
    流式文本: 逐字逐句或逐块地返回文本内容。
    不暴露内部事件: 通常不会暴露 Agent 内部的详细执行事件，如工具调用开始/结束、中间步骤等。它更像是一个“纯文本流”。
    需要循环驱动: 你需要使用 for chunk in … (同步) 或 async for chunk in … (异步) 来迭代并获取这些文本块。每次迭代都会驱动 Agent/Runnable 执行一部分，直到产生下一个文本块。
    何时使用: 当你只需要流式地展示 LLM 的文本输出，而不需要展示 Agent 内部的复杂思考过程（例如工具调用细节）时。这对于构建普通的聊天机器人界面非常有用。
    驱动方式: 必须通过 for 或 async for 循环来驱动。

  3. stream_events() 和 astream_events()：流式事件输出
    同步版本: stream_events(input, config, version)
    异步版本: astream_events(input, config, version)
    行为: 启动 Agent 或 Runnable 的执行，并返回一个迭代器（同步）或异步迭代器（异步）。每次迭代会产生一个事件对象。这些事件对象包含了 Agent 内部执行的详细信息，包括文本块、工具调用开始/结束、链的开始/结束、最终输出等。
    特点:
    最详细的流式: 提供了对 Agent 内部执行过程最细粒度的洞察。
    包含所有中间步骤: 你可以捕获到 Agent 的每一个“思考”和“行动”。
    需要循环驱动: 你需要使用 for event in … (同步) 或 async for event in … (异步) 来迭代并获取这些事件。每次迭代都会驱动 Agent/Runnable 执行一部分，直到产生下一个事件。
    何时使用: 当你需要构建高度交互式、可观察的 Agent 应用时，例如：
    实时展示 Agent 的思考链（“Thought”, “Action”, “Observation”）。
    在前端区分并展示工具调用和工具结果。
    调试 Agent 的执行流程。
    在 Agent 运行时进行自定义的日志记录或监控。
    驱动方式: 必须通过 for 或 async for 循环来驱动。

  4. Runnable
    Runnable 是 LangChain 中一个非常核心的抽象概念。它是一个接口（或者说是一个协议），定义了任何可以被“运行”的东西。
    核心思想：任何实现了 Runnable 接口的对象，都具备以下能力（至少是其中一部分）：
    invoke() / ainvoke(): 运行一次并返回最终结果。
    stream() / astream(): 流式返回文本块。
    stream_events() / astream_events(): 流式返回所有执行事件。
    batch() / abatch(): 批量运行。
    with_config(): 运行配置。
    bind(): 绑定参数。
    pipe(): 链式调用。
    统一接口: 无论是一个简单的 LLM（ChatOpenAI、ChatAnthropic）、一个工具（BaseTool）、一个提示模板（ChatPromptTemplate）、一个输出解析器（BaseOutputParser），还是一整个复杂的 Agent 或链，只要它们实现了 Runnable 接口，你就可以用统一的方式（invoke、stream 等）来调用它们。
    可组合性: Runnable 使得 LangChain 的各个组件可以像乐高积木一样自由组合。你可以将多个 Runnable 通过 | 运算符（pipe 方法）连接起来，形成更复杂的链。
    灵活性: 无论是同步还是异步，无论是单次调用还是流式调用，Runnable 都提供了相应的接口，让开发者可以根据需要选择最合适的执行方式。
    典型的，langgraph的create_react_agent 返回的 agent 对象（一个 CompiledGraph 实例）是 LangChain Runnable 接口的一个实现。这意味着你可以对这个 agent 对象调用 invoke()、ainvoke()、astream_events() 等方法，就像你对任何其他 LangChain Runnable 组件一样。
    LangChain Runnable 的实现者：
    ChatOpenAI (一个 LLM)
    Tool (一个工具)
    ChatPromptTemplate (一个提示模板)
    StrOutputParser (一个输出解析器)
    create_react_agent 返回的 CompiledGraph (一个复杂的 Agent)
    你的 CustomAPIModel (自定义 LLM)
    它们都实现了 Runnable 接口，但内部逻辑和所代表的功能完全不同。
    Runnable 的特性正是 LangChain 能够使用 | 运算符（管道操作符）进行链式连接的根本原因。在 LangChain 中，| 运算符被重载（overload）了，它实际上是调用了 Runnable 接口的 pipe() 方法。

  5. Agent 与 model

用户请求
   |
   V
LangGraph (ReAct Agent)
   | 
   V
LLM model
   | 
   V
LangGraph (ReAct Agent)
   |
   +--- IF AIMessage 有 tool_calls:
   |      - 执行工具 (使用传入的 `tools` 列表)
   |      - 将工具结果作为 ToolMessage 添加到历史
   |      - 返回步骤1，再次调用Model (形成循环)
   |
   +--- IF AIMessage 只有 content:
          - 视为最终答案
          - 结束循环，返回结果给用户

所以：
是工具还是文本： 主要由 LLM 的推理能力决定，定制Model 负责解析这种决定（如果是langchain支持的model则不需要这个）。
是循环还是结束： 主要由 langgraph (ReAct Agent) 根据 CustomAPIModel 返回的 AIMessage 类型（是否有 tool_calls）来决定。如果 tool_calls 存在，就进入循环；如果不存在，就结束。

  • SQLite

一款轻型-轻量级的数据库，是遵守ACID的关系型数据库管理系统。

架构：MySQL 是一个客户端/服务器架构的数据库管理系统，这意味着它需要一个单独的服务器进程来运行。而 SQLite 是一个无服务器的数据库管理系统，它直接读取和写入磁盘文件。

存储：MySQL 数据库存储在磁盘上的文件中，但需要通过 MySQL 服务器进程来访问和管理。SQLite 数据库也存储在磁盘上的文件中，但可以直接通过 SQLite 命令行工具或编程语言的 SQLite 库来访问和管理。

SQLite是文件级的。所以替代的是文件存储的级别，不是client/server数据库的级别。单体/接单用足够。直接给它存成文件。

LangGraph写Agent用到了。

  • Spring AI
    Java有Spring AI

1.4. MCP

MCP, Model Context Protocol，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。分client和server。client在host里。

host指的我们的调用程序本体，可以是LLM程序，IDE，AI工具，LangChain代码框架。

client / server，感觉和之前原始手写socket一个意思，一个client一个server建立网络通信TCP/IP。

协议

阿里云百炼 业内首发MCP服务，与开发者共同打造企业级AI应用新生态

  • MCP 的核心价值
方面	            直接 API 调用	          MCP 协议
错误处理	    各不相同	                统一格式
类型安全	    依赖文档	                内置 Schema
版本管理	    手动处理	                自动协商
服务发现	    手动配置	                自动发现
扩展性	    修改代码	                动态添加
参数验证	    运行时错误	            预先验证
AI 集成      需要适配	                原生支持

（这里的API是广义抽象的API，包含网络接口、本地工具等等）

为 AI 而生：专门为 AI 模型设计的工具调用协议
自描述能力：服务可以告诉 AI 自己能做什么
类型安全：减少运行时错误
统一接口：一套协议访问所有服务
动态扩展：无需修改代码即可添加新功能
微服务友好：天然支持分布式架构

MCP 让 AI 模型能够像人类一样"学会使用新工具"，而不是像传统程序一样"被硬编码使用特定 API"。

  • MCP支持的传输协议（transport参数）

stdio (标准输入/输出)
通过进程的标准输入/输出流进行通信
主要用于本地进程间通信
配置中使用 “transport”: “stdio”

HTTP/HTTPS
通过HTTP或HTTPS协议与远程服务器通信
支持REST风格的API调用
配置中使用 “transport”: “http” 或 “transport”: “https”

WebSocket
提供全双工通信通道
适合需要持久连接和实时数据交换的场景
配置中使用 “transport”: “websocket”

Server-Sent Events (SSE)
用于服务器向客户端推送数据的单向通道
适合流式响应和事件通知
配置中使用 “transport”: “sse”
（流式返回，支持大结果分块传输，服务器主动推。可实现搜索结果逐步返回）

Unix Socket
用于同一系统上的进程间通信
比stdio有更好的性能
配置中使用 “transport”: “unix”

TCP Socket
直接通过TCP套接字通信
适合需要自定义协议的场景
配置中使用 “transport”: “tcp”

还在更新，还有什么StreamableHttp

mcp Client和mcp Server部署在同一台机器上，通过标准输入输出通信的方式就是STDIO模式。部署在不同机器通过Http请求通信就是SSE模式和StreamableHttp模式。STDIO因为在本地运行，是绝对安全的；但SSE和StreamableHttp(比SSE更高可用，网络上那些个问题)模式若暴露连接方式，可能会有安全问题。

  • MCP 协议架构采用了分层架构设计

┌─────────────────────────────────────┐
│ Application Layer │ ← 工具调用、资源访问、提示词
├─────────────────────────────────────┤
│ Protocol Layer │ ← JSON-RPC 2.0 消息格式
├─────────────────────────────────────┤
│ Transport Layer │ ← stdio, HTTP, WebSocket, SSE
└─────────────────────────────────────┘
Tips: HTTP是一问一答，连接即用即关；SSE是长连接，支持服务器主动推送

  • The Agent Protocol Stack

除了MCP外的新名词（协议级别）
A2A: Agent to Agent
AG-UI: Agent to User Interface

1.5. Ollama

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

1.6. 各种最佳实践

  • 前端领域，设计稿到前端代码：D2C + MCP + AI
    Tricks: 图与图编码
    https://mp.weixin.qq.com/s/RBIlsqdkN7CNDuGWxhoxGQ

  • NL2SQL：自然语言到SQL

  • 开源大模型边缘设备部署：qwq, gpt-oss-20b(16G内存)

  • IDE

Cursor
参考（阿里的技术文档还是太棒了）：https://mp.weixin.qq.com/s/UM3nBcX6JpYtnchSCdrxOA
还有很多：

# 项目文档规范

**文档受众明确为软件开发人员**，目的是帮助开发团队快速理解系统架构、业务逻辑和技术实现细节，便于代码维护、功能扩展和知识传递。
## 关键规则
- 项目文档必须包含四个核心部分：项目简介、核心领域模型、项目结构和外部依赖
- 接口文档必须按照@接口文档规范进行编写和维护
- 业务流程文档必须按照@业务流程文档规范进行编写和维护
- 文档应保持客观性，基于现有代码而非理想状态
- 文档中使用的术语必须与代码中的术语保持一致
- 文档应使用Markdown格式，支持图表、表格和代码块
- 代码示例必须是从实际代码中提取的，而非虚构的
- 图表应使用Mermaid或PlantUML语法，以确保可维护性
- 文档应当引用具体的代码文件路径，便于读者查找相关实现
- 首先判断项目是否使用GBF框架，并根据实际架构选择适合的文档结构和内容
- 所有文档必须统一放置在docs目录下，并使用规定的中文名称
- **文档生成过程中必须确保完整覆盖所有内容，不允许任何遗漏**
## 文档优化与结构指南
- **主索引文档**：每个核心部分创建一个主索引文档，包含子文档链接和简要说明
- **文档内导航**：超过500行的文档必须在开头提供目录
- **分层结构**：按照"金字塔结构"组织（顶层：核心概念；中层：主要功能模块；底层：具体实现细节）
- **文档拆分**：接口超过20个时按业务域拆分；核心实体超过10个时按业务领域拆分
## 文档结构和内容要求
### 1. 项目简介 - docs/项目概述.md
必须包含：项目背景、项目目标、功能概述、技术栈和架构类型（明确是否使用GBF框架）
### 2. 核心领域模型 - docs/领域模型说明.md
必须包含：
- 领域模型概述：核心业务概念的定义和边界
- 核心实体关系图：使用E-R图或类图表示
- 关键业务场景下的模型交互
- 数据流转关系
**强制性领域模型扫描规则**：
- **全面扫描**：包括`*Entity.java`、`*DO.java`、`*PO.java`、`*Model.java`、`@Entity`、`@Table`、`@Document`注解类、服务层核心模型、DTO/VO类
- **按目录结构识别**：位于`model`、`domain`、`entity`目录及其子目录下的Java类文件，以及领域模型专用包路径（如`*.domain.*`、`*.model.*`、`*.entity.*`）下的类文件
- **完整提取**：实体属性和业务含义、实体关系、聚合结构、生命周期和状态流转
- **识别规则**：属性约束、实体关系约束、状态转换规则
**领域模型分析策略**：
- 全域扫描实体类和值对象，支持多种ORM框架
- 提取关联关系（通过字段类型、泛型参数和ORM注解）
- 识别聚合根和聚合边界（通过包结构和类间关系）
- 分析继承结构（包括抽象类、接口和实现类）
- 提取业务方法和状态转换逻辑
- 生成完整属性表和业务规则说明
**GBF框架项目补充**：扩展点定义与实现、行业/场景定制点、路由条件与动态选择机制
### 3. 接口文档 - docs/接口文档.md
接口文档应遵循专门的@接口文档规范进行创建和维护，以确保API接口的完整记录和更新。
### 4. 业务流程 - docs/业务流程说明.md
业务流程文档应遵循专门的@业务流程文档规范进行创建和维护，以确保业务流程的完整记录和更新。
### 5. 项目结构 - docs/项目结构说明.md
必须包含：项目模块划分、代码组织结构、关键包说明、分层架构说明
**GBF框架项目补充** - docs/GBF框架应用说明.md：
GBF分层结构、扩展点文件位置、行业定制目录、场景定制目录
### 6. 外部依赖与下游服务 - docs/外部依赖说明.md
必须包含：
- 下游服务概述：依赖的所有外部服务列表和用途
- 调用关系图：系统与外部服务的调用关系
## 文档生成工作流程
1. **架构识别**：确定项目架构类型、识别关键组件和分层结构
2. **代码分析**：识别核心业务包和类、分析领域模型、提取接口定义、理解调用链路
3. **内容整理**：按文档结构组织信息、提取代码示例、绘制图表
4. **审核完善**：验证文档与代码一致性、补充关键信息、完善图表和示例
   - **接口覆盖性验证**：确认总览文档中的所有接口都在详细文档中有完整描述
   - **文档完整性检查**：确保没有遗漏任何必要的接口和服务描述
5. **定期更新**：与代码审查流程集成、重大变更更新文档、每季度全面审核
## 示例
### 领域模型示例
```markdown
## 核心实体关系图
```mermaid
classDiagram
  classItem {
    +Long id
    +String name
    +BigDecimal price
    +String status
    +validatePrice()
    +changeStatus(String)
  }
  
  classTyingRule {
    +Long id
    +Long mainItemId
    +List<Long> subItemIds
    +Date startTime
    +Date endTime
    +enable()
    +disable()
  }
  
  Item "1" -- "n" TyingRule: 被定义为主商品
  TyingRule "1" -- "n" Item: 关联搭售商品

## 实体属性详细说明
### Item 商品实体
| 属性名 | 类型 | 说明 |
|----|---|---|
| id | Long | 商品唯一标识 |
| name | String | 商品名称，长度限制：2-50个字符 |
| price | BigDecimal | 商品价格，精确到小数点后2位，最小值：0.01 |
| status | String | 商品状态，枚举值：ON_SHELF(上架)、OFF_SHELF(下架)、DELETED(删除) |
#### 业务规则
- 商品价格必须大于0
- 商品状态只能按特定流程转换（上架->下架->删除）

### 业务流程示例
```markdown
## 搭售规则创建流程
### 核心流程图
```mermaid
flowchart TD
    A[创建请求] --> B{校验参数}
    B -->|无效| C[返回错误]
    B -->|有效| D[查询主商品]
    D --> E{商品存在?}
    E -->|否| F[返回错误]
    E -->|是| G[查询搭售商品]
    G --> H{商品存在?}
    H -->|否| I[返回错误]
    H -->|是| J[保存规则]
    J --> K[返回成功]

### 调用链路
**入口点**: `ItemTyingController.createTyingRule()`
**调用流程**:
1. 请求参数校验 - `validateTyingRequest(request)`
2. 查询主商品信息 - `itemService.getItemById()`
3. 校验主商品状态 - `validateItemStatus(item)`
4. 查询并校验搭售商品列表 - `validateSubItems()`
5. 构建并保存搭售规则 - `tyingRuleRepository.save()`
6. 发送规则创建事件 - `eventPublisher.publishEvent()`
### 关键判断点
| 判断点 | 条件 | 处理路径 |
|-----|---|----|
| 参数校验 | 主商品ID为空 | 返回参数错误 |
| 主商品校验 | 主商品不存在 | 返回商品不存在错误 |
| 搭售商品校验 | 存在无效商品 | 返回商品无效错误 |


# 代码分析规则

## 目标
根据代码入口深入分析完整业务流程，生成详细的业务流程文档，便于团队理解和维护代码。
## 关键规则
- **必须生成分析文档保存到项目的docs目录下**
- **必须使用sequential-thinking辅助分析**
- **必须深入方法内部逻辑，因此你可能需要检索代码**
- **建议使用sequential-thinking辅助检索代码**
### 1. 聚焦业务核心逻辑
- 忽略日志打印、参数基础校验等次要逻辑
- 忽略异常处理中的技术细节，只关注业务异常处理逻辑
- 忽略与业务无关的工具方法调用（如字符串处理、集合操作等）
- 聚焦业务状态转换、流程分支、核心计算等关键逻辑
### 2. 深入方法调用链
- 追踪每个关键方法的内部实现，不仅停留在方法调用层面
- 对调用链上的每个重要方法都分析其内部业务逻辑
- 对于外部依赖的服务（如HSF、RPC调用），说明其功能和业务意义
- 深入分析每个关键业务分支的条件和处理逻辑
### 3. 结合已有文档
- 优先使用已有文档中的描述，避免重复分析
- 如果已有文档对某个方法有详细描述，直接引用该内容
- "站在巨人的肩膀上"，基于已有文档进行补充和完善
- 对已有文档与代码实现不一致的地方进行标注
### 4. 文档输出规范
- 分析结果保存到 `/docs` 目录下，使用 Markdown 格式
- 文档命名格式：`业务名称-流程分析.md`（如：`订单创建-流程分析.md`）
- 文档需包含方法调用树，清晰展示调用层级关系
- 使用分步业务流程描述完整处理过程
## 文档结构模板
```markdown
# 业务名称流程分析
## 功能概述
[简要描述该业务功能的目的和作用]
## 入口方法
`com.example.Class.method`
## 方法调用树

入口方法
├─ 一级调用方法1
│  ├─ 二级调用方法1.1
│  ├─ 二级调用方法1.2
├─ 一级调用方法2
   ├─ 二级调用方法2.1
   └─ 二级调用方法2.2
      └─ 三级调用方法

## 详细业务流程
1. [步骤1：业务逻辑描述]
2. [步骤2：业务逻辑描述]
   - [子步骤2.1：详细逻辑]
   - [子步骤2.2：详细逻辑]
3. [步骤3：业务逻辑描述]
## 关键业务规则
- [规则1：描述业务规则及其条件]
- [规则2：描述业务规则及其条件]
## 数据流转
- 输入：[描述方法输入及其业务含义]
- 处理：[描述关键数据处理和转换]
- 输出：[描述方法输出及其业务含义]
## 扩展点/分支逻辑
- [分支1：触发条件及处理逻辑]
- [分支2：触发条件及处理逻辑]
## 外部依赖
- 标注对外部系统的依赖
## 注意事项
- [列出实现中需要特别注意的点]

## 系统交互图
- 如果业务流程包含多个系统模块，请使用PlantUML画出时序图
## 代码分析技巧
### 步骤1：明确业务入口
- 确定代码分析的起点（通常是Controller、Facade或Service层的公开方法）
- 了解该方法的调用场景和业务背景
### 步骤2：构建方法调用树
- 从入口方法开始，追踪所有重要的方法调用
- 使用缩进表示调用层级，清晰展示调用关系
- 忽略非核心方法调用（如日志、参数校验等）
### 步骤3：分析业务流程
- 按照代码执行顺序分析业务处理步骤
- 重点关注业务状态转换和分支逻辑
- 提取关键业务规则和数据处理逻辑
### 步骤4：整理业务规则
- 总结条件判断中隐含的业务规则
- 分析不同场景下的处理差异
- 提炼业务逻辑的核心决策点
### 步骤5：描述数据流转
- 分析关键数据的来源、处理和去向
- 说明数据模型转换和业务含义
- 关注核心业务实体的状态变化
## 示例分析
参考 [订单查询.md](/docs/订单查询.md) 文档了解完整的分析示例:
该示例展示了订单查询业务的完整分析，包括:
- 方法调用树展示了完整调用链
- 详细业务流程按步骤拆解
- 关键业务规则清晰列出
- HSF接口等外部依赖明确说明
- 特殊处理逻辑如推广通退款按钮透出详细解释
## 好的分析的特征
1. **完整性**：覆盖所有核心业务逻辑和分支
2. **层次性**：清晰展示处理流程的层次结构
3. **业务性**：以业务视角描述，而非技术实现细节
4. **精确性**：准确反映代码的实际处理逻辑
5. **可理解性**：业务人员也能理解的表述方式
6. **实用性**：帮助读者快速理解业务流程和规则

TRAE: Rules, Agent, Content, Pic…靠创新
参考（字节的技术文档还是太棒了）
https://mp.weixin.qq.com/s/v4ydYktNhFGp7AtRdm4Y7w

激活方式用户输入以下6A开头的内容即可启动工作流:激活时立即响应：6A工作流已激活
身份定义你是一位资深的软件架构师和工程师，具备丰富的项目经验和系统思维能力。你的核心优势在于：
上下文工程专家：构建完整的任务上下文，而非简单的提示响应规范驱动思维：将模糊需求转化为精确、可执行的规范质量优先理念：每个阶段都确保高质量输出项目对齐能力：深度理解现有项目架构和约束
6A工作流执行规则阶段1: Align (对齐阶段)目标: 模糊需求 → 精确规范
执行步骤
1. 项目上下文分析分析现有项目结构、技术栈、架构模式、依赖关系分析现有代码模式、现有文档和约定理解业务域和数据模型
2. 需求理解确认创建 docs/任务名/ALIGNMENT_[任务名].md包含项目和任务特性规范包含原始需求、边界确认(明确任务范围)、需求理解(对现有项目的理解)、疑问澄清(存在歧义的地方)
3. 智能决策策略自动识别歧义和不确定性生成结构化问题清单（按优先级排序）优先基于现有项目内容和查找类似工程和行业知识进行决策和在文档中回答有人员倾向或不确定的问题主动中断并询问关键决策点基于回答更新理解和规范
4. 中断并询问关键决策点主动中断询问，迭代执行智能决策策略
5. 最终共识生成 docs/任务名/CONSENSUS_[任务名].md 包含:明确的需求描述和验收标准技术实现方案和技术约束和集成方案任务边界限制和验收标准确认所有不确定性已解决
质量门控需求边界清晰无歧义技术方案与现有架构对齐验收标准具体可测试所有关键假设已确认项目特性规范已对齐
阶段2: Architect (架构阶段)目标: 共识文档 → 系统架构 → 模块设计 → 接口规范
执行步骤
1. 系统分层设计基于CONSENSUS、ALIGNMENT文档设计架构生成 docs/任务名/DESIGN_[任务名].md 包含:整体架构图(mermaid绘制)分层设计和核心组件模块依赖关系图接口契约定义数据流向图异常处理策略
2. 设计原则严格按照任务范围，避免过度设计确保与现有系统架构一致复用现有组件和模式
质量门控架构图清晰准确接口定义完整与现有系统无冲突设计可行性验证
阶段3: Atomize (原子化阶段)目标: 架构设计 → 拆分任务 → 明确接口 → 依赖关系
执行步骤
1. 子任务拆分基于DESIGN文档生成 docs/任务名/TASK_[任务名].md每个原子任务包含:输入契约(前置依赖、输入数据、环境依赖)输出契约(输出数据、交付物、验收标准)实现约束(技术栈、接口规范、质量要求)依赖关系(后置任务、并行任务)
2. 拆分原则复杂度可控，便于AI高成功率交付按功能模块分解，确保任务原子性和独立性有明确的验收标准，尽量可以独立编译和测试依赖关系清晰
3. 生成任务依赖图(使用mermaid)
质量门控任务覆盖完整需求依赖关系无循环每个任务都可独立验证复杂度评估合理
阶段4: Approve (审批阶段)目标: 原子任务 → 人工审查 → 迭代修改 → 按文档执行
执行步骤
1. 执行检查清单 完整性：任务计划覆盖所有需求 一致性：与前期文档保持一致 可行性：技术方案确实可行 可控性：风险在可接受范围，复杂度是否可控 可测性：验收标准明确可执行
2. 最终确认清单明确的实现需求(无歧义)明确的子任务定义明确的边界和限制明确的验收标准代码、测试、文档质量标准
阶段5: Automate (自动化执行)目标: 按节点执行 → 编写测试 → 实现代码 → 文档同步
执行步骤
1. 逐步实施子任务创建 docs/任务名/ACCEPTANCE_[任务名].md 记录完成情况
2. 代码质量要求严格遵循项目现有代码规范保持与现有代码风格一致使用项目现有的工具和库复用项目现有组件代码尽量精简易读API KEY放到.env文件中并且不要提交git
3. 异常处理遇到不确定问题立刻中断执行在TASK文档中记录问题详细信息和位置寻求人工澄清后继续
4. 逐步实施流程 按任务依赖顺序执行，对每个子任务执行:执行前检查(验证输入契约、环境准备、依赖满足)实现核心逻辑(按设计文档编写代码)编写单元测试(边界条件、异常情况)运行验证测试更新相关文档每完成一个任务立即验证
阶段6: Assess (评估阶段)目标: 执行结果 → 质量评估 → 文档更新 → 交付确认
执行步骤
1. 验证执行结果更新 docs/任务名/ACCEPTANCE_[任务名].md整体验收检查:所有需求已实现验收标准全部满足项目编译通过所有测试通过功能完整性验证实现与设计文档一致
2. 质量评估指标代码质量(规范、可读性、复杂度)测试质量(覆盖率、用例有效性)文档质量(完整性、准确性、一致性)现有系统集成良好未引入技术债务
3. 最终交付物生成 docs/任务名/FINAL_[任务名].md(项目总结报告)生成 docs/任务名/TODO_[任务名].md(精简明确哪些待办的事宜和哪些缺少的配置等，我方便直接寻找支持)
4. TODO询问 询问用户TODO的解决方式，精简明确哪些待办的事宜和哪些缺少的配置等，同时提供有用的操作指引
技术执行规范安全规范API密钥等敏感信息使用.env文件管理
文档同步代码变更同时更新相关文档
测试策略测试优先：先写测试，后写实现边界覆盖：覆盖正常流程、边界条件、异常情况
交互体验优化进度反馈显示当前执行阶段提供详细的执行步骤标示完成情况突出需要关注的问题
异常处理机制中断条件遇到无法自主决策的问题觉得需要询问用户的问题技术实现出现阻塞文档不一致需要确认修正
恢复策略保存当前执行状态记录问题详细信息询问并等待人工干预从中断点任务继续执行
  • AI应用新范式：Embedding, Copilot, Agents（应用形态与我简历里的AI驱动软件开发新范式可对应）

1.7. Prompt Engineering

角色：减少二义性，让“通用”瞬间变得“专业”。
指示：对具体任务进行详细描述。
上下文：给出与任务相关的其它背景信息（如历史对话、情境等）。
例子：是大模型生成输出时的一个重要参考，对输出结果有很大帮助。
输入：任务的输入信息，最好在提示词中有明确的“输入”标识。
输出：输出的格式描述，比如输出不超过十个字、以JSON格式返回结果等。

Magic Prompt:
Let's think step by step.
Read the question again.

Thanks to https://mp.weixin.qq.com/s/DODEfYvyMAXTZS-edtXeMg

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 / 中文核心：基于抛物面焦点麦克风预处理和迁移学习的语音增强方法
专利：一种基于混合掩蔽学习目标的语音增强方法

2.3. LLM训练过程 vs 我的语音增强深度学习模型 （主要步骤概括）

  • LLM:

1.数据准备 Data Preparation：数据收集（文本数据，数据量通常达到数万亿个token） -> 数据清洗（去重，归一化，敏感信息处理等）-> 分词（Tokenization）

2.预训练 Pre-training：模型选择（Transformer-based模型，典型的如BERT）-> 自监督学习（Next Token Prediction | Masked Language ModelingMLM的BERT）

3.监督微调 Supervised Fine-tuning SFT：有监督学习（高质量的指令-相应对。 将预训练模型加载进来，然后使用这个指令-响应数据集进行标准的监督学习。模型的目标是，给定一个指令作为输入，生成一个与数据集中对应的响应作为输出。）

4.对齐 / 基于人类反馈的强化学习 (Alignment / RLHF, Reinforcement Learning from Human Feedback)

目的： 进一步将模型与人类的偏好、价值观和行为准则对齐，使其输出更符合“有益、无害、真实”的原则。

如何工作 (以 RLHF 为例)： RLHF 通常包含三个子阶段：

1.收集对比数据与训练奖励模型 (Reward Model, RM)：
        对于同一个指令，让 SFT 模型生成多个不同的响应。
        人类标注员对这些响应进行排序或打分，表示他们更喜欢哪个响应。
        使用这些人类偏好数据来训练一个单独的奖励模型 (Reward Model, RM)。这个 RM 的目标是学习人类的偏好，能够预测给定响应的“好坏”分数。

2.基于奖励模型的强化学习 (Reinforcement Learning)：
        使用 SFT 过的模型作为策略模型 (Policy Model)。
        奖励模型作为奖励函数，为策略模型生成的新响应提供奖励信号。
        通过强化学习算法（如 PPO, Proximal Policy Optimization），微调策略模型。模型的目标是生成能够最大化奖励模型分数的响应。
        在训练过程中，还会引入一个惩罚项（KL 散度），以防止模型偏离 SFT 阶段学到的语言模型能力太远，避免生成不连贯或无意义的文本。

3.迭代优化： 这个过程可以迭代进行，不断收集新的数据，训练更优的奖励模型，并进一步微调策略模型。

其他对齐方法： 除了 RLHF，还有一些更简单的替代方案，如 直接偏好优化 (Direct Preference Optimization, DPO)，它直接利用人类偏好数据来优化模型，而不需要显式地训练一个奖励模型，简化了训练流程。

5.部署与推理

Tips (大概):

- 预训练： 计算资源需求最高，通常需要数千甚至数万颗高端 GPU，持续数周到数月。
- RLHF： 计算资源需求次高，尤其是在训练奖励模型和 PPO 阶段，需要同时管理多个 LLM 实例，并且 RL 训练
本身就更复杂。通常也需要数百到数千颗 GPU。
- SFT（全参数微调）： 计算资源需求相对较低，但对于大型 LLM 仍需多张高端 GPU。
- SFT（PEFT,Parameter-Efficient Fine-Tuning/量化）： 计算资源需求最低，甚至可以在单张消费级 GPU 上进行，使得个人和小型团队也能参与 LLM 微调。
参数高效微调 (PEFT) 技术： 如 LoRA(Low-Rank Adaptation)、QLoRA 等，通过只训练模型的一小部分参数或注入少量可训练参数，可以大幅减少显存和计算需求。QLoRA 甚至可以在单张消费级 GPU 上微调 7B 甚至 13B 模型。
量化技术： 如 INT8 量化、FP16 量化等，通过将模型参数和激活值从 32 位浮点数压缩到 8 位整数或 16 位浮点数，大幅减少模型大小和计算需求。
  • LCLED（我的语音增强深度学习模型）:

1.数据准备：数据集 -> 训练集，验证集，测试集 -> 特征提取（语音特征提取，含STFT，MFCC，梅尔频谱等运算过程）-> 构建数据对（输入clean语音，输出带噪语音）

2.训练：模型选择（搭建LCLED，设置超参数、损失函数等等，炼丹） -> 监督学习

3.测试：使用测试集评估模型性能，常用指标包括信噪比（SNR）等音频质量指标

4.部署与增强语音

Tips: 实验室单块GPU训练1-2天

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的完整产品套件中，让你可以直接在浏览器里建模。

  1. 它们相当于是对XML进行编解码？

编码 (Encoding): 当您在BPMN建模器里拖拽图形、填写属性时，建模器正在实时地将您的可视化操作编码成符合BPMN 2.0标准的XML文件。您看到的图形是给人看的，背后的XML是给机器读的。
解码 (Decoding / Parsing): 当您的Java应用（集成了Flowable/Camunda）启动或部署这个XML文件时，流程引擎会读取这个文件，并将其解码成一个它可以在内存中理解和执行的、由Java对象构成的流程模型。

  1. 总结：

建模阶段: 您（或业务分析师）在BPMN建模器中通过拖拉拽的方式，设计或修改业务流程。完成后，您得到一个 .bpmn (本质是XML) 文件。

部署阶段: 您将这个 .bpmn 文件部署到流程引擎。对于嵌入式集成，通常就是把它放在Java项目的资源文件夹里，应用启动时引擎会自动加载并解析XML。

执行阶段: 您的Java代码（比如一个Controller）调用 runtimeService.startProcessInstanceByKey(…)。引擎接收到指令，根据它已经解析好的流程模型，开始一步步执行流程。

监控阶段：自定义

  1. 所以相当于代码永远不变，变的是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生成方式等可能存在差异。
# 人工智能 # 软件工程 # 算法 # 生成式AI # AI
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

Python 生成器与迭代器：节省内存的代码实现技巧

await async2() // 这一句会同步执行，返回 Promise ，其中的 `console.log('async2')` 也会同步执行。Promise.resolve().then(() => { // 返回 rejected 状态的 promise。Promise.resolve().then(() => { // 返回 rejected 状态的 promise。console.lo

avatar 2048 AI社区
cover

墙体检测计算机视觉数据集-6,646张图片 墙体识别 建筑图纸解析 BIM建模 CAD自动化 实例分割 工程AI 智能设计 图纸数字化

avatar 2048 AI社区
cover

哪些平台的AI软著工具被大量用户验证过，通过率较高？

avatar 2048 AI社区