1. 项目概述一个开源自动化平台的诞生如果你也像我一样被Zapier和Make.com的定价方案吓到过或者觉得它们的界面复杂得让人头疼那你应该能理解我为什么要花40天时间从零开始构建HarshAI。我的核心诉求很简单我想要一个完全免费、可以自己掌控、并且能轻松构建AI工作流的自动化工具。市面上现有的方案要么是月费随着使用量水涨船高要么是学习曲线陡峭对于想快速把想法变成自动化流程的开发者或小团队来说并不友好。于是我决定自己动手丰衣足食。HarshAI的目标就是成为一个开源的“Zapier杀手”。它不仅仅是一个替代品我更希望它成为一个为现代应用尤其是那些深度集成AI的应用而设计的自动化核心。在过去的40天里我完成了90个规划功能中的44%将一个想法变成了一个具备拖拽式构建器、实时API连接、Webhook触发、完整版本控制并且可以自托管的生产就绪系统。这篇文章我会毫无保留地分享这40天的构建历程、技术选型的思考、实现中的关键细节以及那些只有亲手搭建才会遇到的“坑”。无论你是想了解如何构建一个复杂的SaaS应用还是仅仅想找一个强大的开源自动化工具希望我的经验都能给你带来启发。2. 核心架构与技术选型解析2.1 为什么选择这个技术栈技术选型是项目的基石它决定了开发效率、系统性能和未来的可维护性。我的选择基于几个核心原则开发体验优先、性能与成本平衡、以及生态系统的成熟度。前端Next.js 14 React Flow前端我选择了Next.js 14的App Router。原因在于自动化工作流构建器是一个交互极其复杂的单页应用SPA但同时我们又需要良好的SEO为了模板市场和快速的初始加载。Next.js的服务器组件RSC和客户端组件的混合渲染模式完美解决了这个问题。例如工作流编辑器的画布部分高交互使用客户端组件而模板市场的列表页静态为主则可以用服务器组件渲染提升性能。React Flow是构建节点-连线式界面的不二之选它提供了稳定的拖拽、连接、布局算法让我能专注于业务逻辑而非图形渲染的基础设施。后端Node.js TypeScript后端选择Node.js和TypeScript是出于全栈统一和开发效率的考虑。作为一个单人项目在前后端之间切换上下文时使用同一种语言和相似的工具链ESLint, Prettier能极大减少心智负担。TypeScript的强类型系统在构建涉及大量数据流转工作流中的变量传递和第三方API集成类型各异的请求/响应的系统时是避免低级错误的“安全带”。虽然有人会争论Go或Rust在性能上的优势但对于一个IO密集型大量网络请求的自动化平台Node.js的非阻塞异步模型天生合适且其庞大的NPM生态能让我快速集成各种第三方服务的SDK。数据库PostgreSQL (via Supabase)数据库方面PostgreSQL是关系型数据库中的瑞士军刀。自动化工作流的数据结构非常复杂需要存储工作流定义JSONB类型完美存储节点图、执行历史日志、用户配置、模板元数据等。PostgreSQL的JSONB类型支持高效的JSON查询和索引这对于存储和检索动态的工作流结构至关重要。我选择通过Supabase来使用PostgreSQL因为它不仅提供了托管的数据库还内置了实时订阅、身份验证和存储功能相当于免费获得了一个强大的BaaS后端即服务让我能快速搭建起用户系统。部署Vercel (Frontend) Railway/Render (Backend)部署策略遵循了“前端托管在Vercel后端和数据库可自托管”的原则。Vercel为Next.js应用提供了无缝的部署体验和全球CDN这对于工具的访问速度至关重要。而后端和数据库我虽然用Supabase的云服务进行开发但所有代码和配置都确保了可以轻松迁移到任何能运行Docker的环境如Railway, Render或用户自己的服务器这是实现“Self-hostable”承诺的关键。注意技术选型没有银弹。这个组合非常适合快速启动和迭代。如果你的团队更熟悉其他栈比如Python/Django完全可以用其实现相同功能。核心在于理解每个组件承担的责任并确保它们能高效协作。2.2 系统核心模块设计HarshAI的架构可以清晰地分为四个层次这帮助我在开发时保持模块化避免代码变成一团乱麻。1. 工作流定义层这是用户直接交互的部分核心是一个JSON Schema它定义了整个工作流的“蓝图”。每个节点Node都有类型如http_request,filter,delay、唯一的ID、在画布上的位置、配置参数以及与其他节点的连接关系。这个结构被持久化在数据库的workflows表中。使用JSON Schema的另一个好处是我可以利用它在前端实现配置表单的自动生成和验证减少重复的UI代码。2. 工作流执行引擎这是系统的大脑一个无状态的服务。它接收一个工作流定义和初始触发数据例如一个Webhook的payload然后根据节点间的连线关系按顺序或并行地执行每个节点。每个节点类型都有一个对应的“执行器”函数。引擎的关键职责是管理执行上下文一个在所有节点间传递的数据对象、处理错误、记录日志以及支持分支if/else和循环逻辑。我将引擎设计为纯函数式这使得单元测试变得非常容易。3. 连接器与集成层这是与外部世界沟通的桥梁。每个第三方服务如Gmail、Slack都有一个对应的“连接器”模块。连接器封装了该服务的认证OAuth2或API Key、API端点调用和错误处理。我采用了适配器模式所有连接器都实现统一的接口execute(config, context)这样执行引擎就可以用同样的方式调用它们。为了在“测试模式”下运行而不需要真实凭证我为每个连接器都创建了模拟Mock实现返回静态的示例数据。4. 调度与触发层负责在正确的时间启动工作流。它包含几个部分Webhook接收器一个公开的HTTP端点接收外部事件验证HMAC签名确保请求来源可信然后排队执行对应的工作流。定时调度器基于Cron表达式的后台服务定期扫描需要执行的工作流并将其送入执行队列。队列系统我使用了Bull基于Redis的队列将执行任务排队处理。这带来了两个巨大好处异步执行避免HTTP请求超时和重试机制失败的任务可以按指数退避策略重新尝试。3. 关键功能实现与深度剖析3.1 拖拽式构建器的核心实现构建一个稳定、直观的拖拽式界面远不止是把React Flow组件搬过来那么简单。核心挑战在于如何将画布上的视觉元素节点、连线与后台的工作流数据模型实时、无损地同步。数据同步策略双向绑定与防抖我采用了中心化的状态管理Zustand存储整个工作流的状态。画布上的每一次操作拖拽节点、连接端口、删除元素都会触发一个Action来修改这个中心状态。同时任何对节点配置表单的修改比如填写API URL也会更新到同一个状态树中。这里的关键优化是“防抖”Debounce自动保存。每当状态发生变化我会启动一个定时器比如1.5秒后将最新状态同步到后端。这避免了用户每敲一个字母就产生一次网络请求同时在发生意外浏览器崩溃时数据损失也被控制在很小范围内。React Flow提供了onNodesChange、onEdgesChange等回调让我能精准捕获用户意图。节点类型系统与动态表单系统支持多种节点类型触发器Webhook, Schedule、操作HTTP Request, Send Email、逻辑If/Else, Loop、数据转换Code, JSON Transform。每种类型都需要不同的配置表单。我实现了一个节点注册表将节点类型映射到三个关键部分1) 在画布上显示的UI组件2) 对应的配置表单React组件3) 后端执行器函数。当用户从左侧面板拖出一个“HTTP请求”节点时实际上是在状态中添加了一个{type: ‘http_request’, data: {url: ”, method: ‘GET’…}}的对象。当用户点击这个节点时系统会根据其type动态渲染出对应的配置表单。这种设计使得添加新的节点类型变得非常模块化。连线与数据流验证连线不仅仅是画一条线。在HarshAI中连线定义了数据的流向。每个节点的输出端口都有其数据类型例如string、number、object。当用户尝试将两个端口连接起来时系统会进行类型检查。尝试将一个“HTTP请求”节点的json输出object类型连到一个“发送邮件”节点的subject输入string类型是不允许的系统会禁止连线或给出明确警告。这在前端就预防了许多潜在的运行时错误。实现上我为每个节点定义了一个inputSchema和outputSchema使用类似JSON Schema的结构连线时进行模式匹配。3.2 工作流执行引擎的设计细节执行引擎是自动化系统的“心脏”它的可靠性直接决定了产品的可信度。我的目标是让它像瑞士钟表一样精确、可观测、可恢复。上下文Context与数据传递执行引擎启动时会创建一个初始上下文对象。对于Webhook触发上下文初始值就是Webhook的Payload。这个上下文会在节点间流动。每个节点执行时都可以从上下文中读取数据执行完毕后将输出数据写入上下文通常以一个特定的键如steps.http_request_1.response。我设计了一套简单的模板语言允许用户在节点配置中引用上下文变量例如{{steps.webhook_1.body.email}}。引擎在执行前会解析这些模板替换为实际值。这实现了节点间的数据解耦和灵活引用。错误处理与重试机制“出错是常态而非异常。”在分布式自动化中尤其如此。我的错误处理分为几个层级节点级Try/Catch每个节点执行器都被包裹在try-catch中。任何未预期的错误都会被捕获记录详细的错误信息错误堆栈、输入数据快照并将该节点标记为失败。工作流级错误处理我引入了“错误处理”节点作为一种特殊节点。用户可以在工作流中关联一个错误处理节点到某个操作节点。当操作节点失败时引擎会跳转到对应的错误处理分支执行可以进行通知、记录或补偿操作。全局重试队列对于因网络波动等临时性问题导致的失败引擎会将任务推送到Redis队列Bull中。Bull支持配置重试策略我设置为“指数退避”第一次重试在5秒后第二次在20秒后第三次在60秒后。这大大提高了对瞬时故障的容错能力。分支、循环与并行执行实现逻辑控制是让工作流从“线性脚本”升级为“智能程序”的关键。分支If/Else我设计了一个“条件”节点。用户配置一个JavaScript表达式如data.value 100引擎在运行时用沙箱后面会提到安全地执行它根据布尔结果决定走true分支还是false分支的连线。循环For Each循环节点接收一个数组然后为数组中的每个元素并行或串行地执行其子工作流循环体每次迭代将当前元素注入子上下文。并行执行当一个节点的多个输出端口同时连接了后续节点时引擎会使用Promise.all来并发执行这些下游节点显著提升处理速度。实操心得执行引擎的日志系统至关重要。我为每一次工作流运行生成一个唯一的execution_id并记录下每个节点的开始时间、结束时间、输入、输出和状态。这个“执行历史”功能不仅是调试的救星在用户询问“为什么我的数据没收到”时也是排查问题最直接的证据。3.3 安全与多租户实现作为一个开源且支持自托管的多用户系统安全是绝对不能妥协的底线。我主要从认证、授权、资源隔离和输入安全几个层面着手。认证与用户会话我直接集成了Clerk来处理用户认证。它省去了我自己实现注册、登录、密码重置、社交登录Google, GitHub等繁琐且易出错的功能。Clerk提供了React组件和Node.js SDK让我能轻松在前端保护路由在后端API中获取当前用户身份。所有对工作流、执行历史等资源的API请求都必须携带有效的会话令牌后端会验证令牌并提取user_id。基于用户的资源隔离这是多租户的核心。数据库中的所有核心表workflows,executions,connections都有一个user_id字段。每一条数据库查询都必须显式地包含where user_id ?条件。这是一个铁律。我通过在数据库访问层使用Prisma ORM注入一个全局的查询过滤器来实现这一点自动为所有查询加上用户范围限制从根源上防止越权访问。即使用户A知道了用户B的工作流ID他也无法通过API操作或查看它。Webhook安全HMAC签名Webhook是系统对外暴露的入口必须防止伪造请求。我采用了类似Stripe的HMAC签名机制。当用户为一个工作流创建Webhook端点时系统会为该端点生成一个唯一的密钥。用户需要将这个密钥配置到发送Webhook的外部服务中。外部服务在发送请求时需要用密钥对请求体或特定部分计算一个HMAC签名放在请求头如X-Webhook-Signature中。HarshAI的Webhook接收器在收到请求后用本地存储的密钥重新计算签名并与请求头中的签名进行比对。只有完全匹配请求才会被处理。这确保了只有持有密钥的合法发送方才能触发工作流。沙箱Sandbox与代码执行安全系统允许用户在“代码”节点中编写自定义JavaScript用于数据转换。允许执行用户代码是极其危险的。我的解决方案是使用一个严格的沙箱环境。我评估了vm2和isolated-vm等库最终选择了功能与安全性平衡的vm2。我将用户代码限制在一个纯净的上下文中只注入有限的、安全的工具函数如lodash并彻底屏蔽所有require、process、fs等Node.js核心模块的访问。同时设置执行超时如3秒和内存限制防止恶意或低效代码拖垮服务器。4. 开发历程40天冲刺的实战复盘4.1 第一阶段核心构建器第1-15天这个阶段的目标是打造出产品的“形”即用户看得见、摸得着的交互界面。我的策略是“垂直切片”开发尽快做出一个从创建到保存的最小闭环而不是先做完所有前端再做后端。第1-3天搭建基础框架我用了不到三天时间用create-next-app初始化了项目配置了TypeScript、Tailwind CSS和基本的项目结构。同时在Supabase上创建了数据库项目并设计了最初的数据表users(由Clerk管理)、workflows、nodes、edges。这一步的关键是保持简单表结构只包含最必需的字段后续可以随时通过迁移Migration添加。第4-10天React Flow集成与核心交互这是前端攻坚期。集成React Flow后我首先实现了节点的拖拽放置、连线绘制与删除。然后我构建了左侧的“节点面板”和右侧的“节点配置抽屉”。最大的挑战是状态管理。我尝试了直接使用React Flow的状态但很快发现当需要与后端同步、实现撤销重做时状态变得难以管理。于是我引入了Zustand将所有画布状态和工作流业务状态集中管理逻辑顿时清晰了许多。到第10天我已经可以实现拖出一个Webhook触发器节点和一个HTTP请求节点将它们连接起来配置HTTP请求的URL然后点击“保存”——这个工作流定义能被成功保存到数据库。第11-15天实时连接与UI打磨保存之后下一步是让它“活”起来。我实现了基于Supabase Realtime的实时同步。当用户在A浏览器编辑工作流时其更改会几乎实时地出现在B浏览器中显示一个“他人正在编辑”的提示。这为未来的协作功能打下了基础。同时我花时间打磨UI让画布可以缩放、平移节点选中时有美观的光晕效果连线是平滑的贝塞尔曲线确保整个界面在手机和平板上也能基本可用移动响应式。第一阶段结束时我拥有了一个看起来专业、交互流畅的构建器原型这给了我巨大的信心。4.2 第二阶段执行引擎与基础集成第16-25天有了“形”现在需要注入“魂”。这个阶段的目标是让保存的工作流能够真正运行起来并与真实世界互动。第16-20天构建核心执行引擎我创建了一个独立的Node.js服务后来与主API服务合并专门负责执行工作流。它的核心是一个递归函数executeNode(nodeId, context)。函数会从数据库中读取节点配置根据节点类型调用对应的执行器获取结果后更新上下文然后查找该节点的所有下游节点递归执行。我首先为http_request和delay延迟这两种最简单的节点编写了执行器。为了测试我创建了一个简单的API端点来手动触发执行。当看到配置好的HTTP请求节点成功调用了一个外部API并返回结果时那种成就感无与伦比。第21-25天集成真实API与测试模式接下来是连接外部世界。我挑选了四个最常用的服务Gmail发送邮件、Slack发送消息、Notion创建页面和Twitter现X发送推文。每个集成都是一场“战斗”因为各家的OAuth2流程和API设计都有细微差别。我统一了模式前端引导用户跳转到服务商的授权页面授权后回调到我的后端后端用授权码换取access_token和refresh_token安全地存储到数据库加密存储。执行节点时再取出token来调用API。 同时我深知要求用户在构建阶段就提供真实凭证会极大阻碍体验。因此我实现了“测试模式”。在这个模式下所有连接器都会使用模拟数据。例如Gmail节点不会真的发邮件而是返回一个成功的模拟响应。这让用户可以畅通无阻地设计、调试整个工作流逻辑直到最后一步才需要填入真实凭证并发布。4.3 第三阶段高级功能与可靠性加固第26-35天产品能跑了现在要让它跑得稳、跑得远。这个阶段专注于后台服务、错误处理和系统可观测性。第26-30天后台调度器与Webhook接收器定时任务和Webhook是自动化的两大触发器。我使用node-cron库实现了调度器。它作为一个常驻进程每分钟检查一次数据库找出那些配置了Cron表达式且下一次执行时间已到的工作流将其提交给执行引擎。这里要注意处理系统的时区问题我统一使用UTC时间存储和计算。 Webhook接收器是一个公开的POST端点。我为其设计了友好的URL格式如/api/webhooks/[workflow_id]/[secret]。实现HMAC签名验证后我意识到重试逻辑同样重要。如果工作流执行因临时故障失败用户会丢失数据。因此我将Webhook触发的工作流执行也推入了Bull队列并配置了指数退避重试策略最多重试3次。第31-35天错误处理、日志与仪表盘我开始系统性地为执行引擎添加错误处理。不仅仅是捕获异常还要对常见的API错误如4xx、5xx状态码进行归类提供友好的错误信息。我建立了完整的执行历史记录每一次运行、每一个节点的状态都存入数据库。 有了这些数据我构建了一个简单的分析仪表盘。用户可以在这里看到工作流的总执行次数、成功率、平均耗时等图表。这对于监控自动化流程的健康状况至关重要。我还添加了邮件通知功能当工作流连续失败多次时可以自动发送告警邮件给创建者。4.4 第四阶段模板、版本控制与发布准备第36-40天最后冲刺阶段目标是提升产品的可用性和协作性让它从一个工具变成一个平台。第36-38天模板市场与版本控制我允许用户将任何工作流“发布”为模板。模板只包含节点结构和配置不包含用户的个人凭证等敏感信息。我创建了一个模板库页面用户可以浏览、搜索和“一键使用”模板这能极大降低新用户的上手门槛。 版本控制是另一个专业级功能。每次用户保存工作流时系统都会自动创建一个版本快照。我实现了一个简单的对比界面用户可以查看不同版本间的差异节点增删改并可以轻松回滚到任意历史版本。这相当于为工作流提供了Git般的安全网。第39-40天速率限制与生产部署作为开源项目我必须考虑资源滥用。我实现了基于用户的速率限制Rate Limiting设计了4个层级免费用户、基础用户、高级用户等每个层级在单位时间如每分钟内能执行的工作流次数不同。这通过在API网关层Vercel Edge Functions或自定义中间件使用令牌桶算法来实现。 最后我将前后端代码部署到Vercel配置了生产环境的环境变量确保数据库连接、密钥等都已就绪。当我在公网成功通过自己的HarshAI实例触发了一个工作流并收到Slack通知时我知道一个历时40天、包含44%核心功能的开源自动化平台真的诞生了。5. 遇到的挑战与解决方案实录5.1 状态管理的复杂性陷阱问题描述在开发构建器初期我简单地将React Flow的nodes和edges状态直接用作数据源。但随着功能增加节点配置表单、撤销重做、实时协作状态更新变得散落在各个组件中难以追踪。特别是实现“撤销/重做”功能时需要记录完整的状态快照历史直接操作React Flow的状态变得异常笨拙。解决方案引入中心化、不可变的状态管理。我使用Zustand创建了一个useWorkflowStore。状态树不仅包含nodes和edges还包括工作流元数据名称、描述、选中的节点ID等。所有对画布或工作流的修改都必须通过Store提供的Action如addNode,updateNodeConfig,connectEdge来进行。在这些Action内部我使用Immer库来以“可变”的语法生成新的不可变状态。撤销/重做功能变得非常简单只需在每次状态变更前将当前状态推入一个历史堆栈即可。React Flow画布变为一个纯粹的“视图”它通过useWorkflowStore订阅状态并将用户交互事件转发给Store的Action。避坑技巧在涉及复杂交互的前端应用中尽早采用中心化状态管理。不要等到状态 spaghetti意大利面式代码出现后再重构。Zustand Immer 的组合在简洁性和功能性上取得了很好的平衡。5.2 工作流执行中的循环依赖与死循环问题描述在工作流执行引擎中节点之间通过连线形成有向图。我需要确保这个图是无环的DAG否则执行会陷入死循环。例如节点A的输出连向节点B节点B的输出又连回节点A。此外用户可能无意中创建了非常深的递归链路导致调用栈溢出。解决方案执行前的图验证与执行中的深度保护。静态验证在用户保存工作流时后端会进行一次图分析。使用深度优先搜索DFS或拓扑排序算法来检测图中是否存在环。如果发现环则拒绝保存并前端高亮显示有问题的连线。动态保护在执行引擎中我为每次工作流运行维护一个visitedNodes集合。当引擎要执行一个节点时先检查它是否已经在本次执行中被访问过。如果访问过说明出现了运行时循环可能通过动态条件产生的环路引擎会立即抛出“检测到可能循环”的错误并停止执行。同时设置一个全局的最大执行步数如1000步作为最后的安全网。5.3 第三方API集成的“脏活累活”问题描述每个第三方API都有其独特的脾气。OAuth2的流程有authorization_code、client_credentials等不同授权类型API的速率限制策略各异错误响应的格式千差万别有些服务如Google的API访问令牌过期后需要用刷新令牌去获取新的这需要后台定时任务。解决方案抽象出统一的“连接器”接口与凭证管理服务。定义接口我创建了一个Connector接口要求所有连接器实现authorize(config),execute(config, context),test(config)等方法。凭证管理在数据库中建立connections表存储加密后的API密钥或OAuth令牌。实现一个CredentialManager服务负责令牌的加密存储、自动刷新对于OAuth和安全的检索。错误标准化在每个连接器的execute方法内部捕获所有可能的异常网络错误、API错误等并将其转换为内部统一的ExecutionError对象包含错误代码、用户友好消息和原始错误信息便于引擎统一处理。速率限制为每个需要速率限制的API集成一个简单的内存或Redis令牌桶确保不会触发服务商的限制。5.4 自托管部署的复杂性问题描述承诺“可自托管”意味着我的代码不能依赖任何特定的云服务商特性。在开发初期我大量使用了Supabase和Vercel的特定功能如Supabase Realtime, Vercel Edge Config。如果用户想在自己的服务器上部署这些都会成为障碍。解决方案依赖注入与环境抽象。抽象关键服务我将数据库访问、实时通信、对象存储等操作抽象成接口例如IDatabaseService,IRealtimeService。提供多种实现对于数据库我提供了基于Supabase的实现和基于原生PostgreSQL通过Prisma的实现。对于实时通信提供了基于Supabase Realtime的实现和基于Socket.io的备用实现。在项目配置中用户可以通过环境变量如DATABASE_PROVIDERsupabase|postgresql来选择使用哪种实现。清晰的部署文档我编写了详细的Docker Compose配置和手动部署指南列出了所有必需的环境变量数据库URL、加密密钥、OAuth应用ID和密钥等并提供了初始化数据库的SQL脚本。确保一个熟悉Docker的开发者能在30分钟内完成部署。6. 未来路线图与社区共建40天只是一个开始。剩下的56%功能第41-90天计划将围绕扩展性、易用性和生态建设展开。Phase 5: 集成扩展 (第41-50天)核心是“连接一切”。计划新增20多个预置连接器覆盖CRM如HubSpot、电商如Shopify、支付如Stripe等常见场景。更重要的是AI原生节点集成OpenAI GPT、Anthropic Claude、图像生成等模型让工作流不仅能处理数据还能生成文本、图像进行智能决策。例如可以构建“自动分析客服邮件并生成回复草稿”的工作流。Phase 6: 体验打磨 (第51-70天)这个阶段专注于让产品变得丝滑。包括全面的UI/UX重构优化大型工作流的加载和渲染性能。编写端到端E2E测试和集成测试确保核心功能的稳定性。制作完整的文档、视频教程和交互式示例降低学习曲线。Phase 7: 发布准备 (第71-90天)启动封闭测试收集早期用户反馈。建立社区如Discord服务器让用户能交流使用心得和模板。修复所有高优先级Bug。最后精心准备Product Hunt发布材料向世界正式介绍HarshAI。对开源社区的期待我深知一个人的力量有限。HarshAI的成功离不开社区。我欢迎各种形式的贡献 Bug报告在GitHub Issues中清晰描述问题。 功能建议分享你的自动化需求场景。 集成请求告诉我你最希望看到的下一批第三方服务是什么。⭐ 代码贡献如果你对TypeScript、Node.js或React熟悉欢迎提交Pull Request来修复Bug或实现新功能。我从项目开始就注重代码的可读性和模块化设计以降低贡献门槛。构建一个开源项目就像跑一场马拉松公开构建Build in Public则意味着全程直播。这40天里有连续编码8小时的亢奋也有对着复杂Bug一筹莫展的自我怀疑。但看到代码从零变成一个有生命力的产品看到第一个外部用户成功部署并运行了他们自己的工作流所有的疲惫都烟消云散。这44%的完成度不仅仅是一个数字它代表了一个可用的核心、一个坚实的地基。剩下的旅程我邀请你一同见证和参与。
40天构建开源AI自动化平台：从零到一的技术架构与实现
发布时间：2026/5/27 9:01:42
1. 项目概述一个开源自动化平台的诞生如果你也像我一样被Zapier和Make.com的定价方案吓到过或者觉得它们的界面复杂得让人头疼那你应该能理解我为什么要花40天时间从零开始构建HarshAI。我的核心诉求很简单我想要一个完全免费、可以自己掌控、并且能轻松构建AI工作流的自动化工具。市面上现有的方案要么是月费随着使用量水涨船高要么是学习曲线陡峭对于想快速把想法变成自动化流程的开发者或小团队来说并不友好。于是我决定自己动手丰衣足食。HarshAI的目标就是成为一个开源的“Zapier杀手”。它不仅仅是一个替代品我更希望它成为一个为现代应用尤其是那些深度集成AI的应用而设计的自动化核心。在过去的40天里我完成了90个规划功能中的44%将一个想法变成了一个具备拖拽式构建器、实时API连接、Webhook触发、完整版本控制并且可以自托管的生产就绪系统。这篇文章我会毫无保留地分享这40天的构建历程、技术选型的思考、实现中的关键细节以及那些只有亲手搭建才会遇到的“坑”。无论你是想了解如何构建一个复杂的SaaS应用还是仅仅想找一个强大的开源自动化工具希望我的经验都能给你带来启发。2. 核心架构与技术选型解析2.1 为什么选择这个技术栈技术选型是项目的基石它决定了开发效率、系统性能和未来的可维护性。我的选择基于几个核心原则开发体验优先、性能与成本平衡、以及生态系统的成熟度。前端Next.js 14 React Flow前端我选择了Next.js 14的App Router。原因在于自动化工作流构建器是一个交互极其复杂的单页应用SPA但同时我们又需要良好的SEO为了模板市场和快速的初始加载。Next.js的服务器组件RSC和客户端组件的混合渲染模式完美解决了这个问题。例如工作流编辑器的画布部分高交互使用客户端组件而模板市场的列表页静态为主则可以用服务器组件渲染提升性能。React Flow是构建节点-连线式界面的不二之选它提供了稳定的拖拽、连接、布局算法让我能专注于业务逻辑而非图形渲染的基础设施。后端Node.js TypeScript后端选择Node.js和TypeScript是出于全栈统一和开发效率的考虑。作为一个单人项目在前后端之间切换上下文时使用同一种语言和相似的工具链ESLint, Prettier能极大减少心智负担。TypeScript的强类型系统在构建涉及大量数据流转工作流中的变量传递和第三方API集成类型各异的请求/响应的系统时是避免低级错误的“安全带”。虽然有人会争论Go或Rust在性能上的优势但对于一个IO密集型大量网络请求的自动化平台Node.js的非阻塞异步模型天生合适且其庞大的NPM生态能让我快速集成各种第三方服务的SDK。数据库PostgreSQL (via Supabase)数据库方面PostgreSQL是关系型数据库中的瑞士军刀。自动化工作流的数据结构非常复杂需要存储工作流定义JSONB类型完美存储节点图、执行历史日志、用户配置、模板元数据等。PostgreSQL的JSONB类型支持高效的JSON查询和索引这对于存储和检索动态的工作流结构至关重要。我选择通过Supabase来使用PostgreSQL因为它不仅提供了托管的数据库还内置了实时订阅、身份验证和存储功能相当于免费获得了一个强大的BaaS后端即服务让我能快速搭建起用户系统。部署Vercel (Frontend) Railway/Render (Backend)部署策略遵循了“前端托管在Vercel后端和数据库可自托管”的原则。Vercel为Next.js应用提供了无缝的部署体验和全球CDN这对于工具的访问速度至关重要。而后端和数据库我虽然用Supabase的云服务进行开发但所有代码和配置都确保了可以轻松迁移到任何能运行Docker的环境如Railway, Render或用户自己的服务器这是实现“Self-hostable”承诺的关键。注意技术选型没有银弹。这个组合非常适合快速启动和迭代。如果你的团队更熟悉其他栈比如Python/Django完全可以用其实现相同功能。核心在于理解每个组件承担的责任并确保它们能高效协作。2.2 系统核心模块设计HarshAI的架构可以清晰地分为四个层次这帮助我在开发时保持模块化避免代码变成一团乱麻。1. 工作流定义层这是用户直接交互的部分核心是一个JSON Schema它定义了整个工作流的“蓝图”。每个节点Node都有类型如http_request,filter,delay、唯一的ID、在画布上的位置、配置参数以及与其他节点的连接关系。这个结构被持久化在数据库的workflows表中。使用JSON Schema的另一个好处是我可以利用它在前端实现配置表单的自动生成和验证减少重复的UI代码。2. 工作流执行引擎这是系统的大脑一个无状态的服务。它接收一个工作流定义和初始触发数据例如一个Webhook的payload然后根据节点间的连线关系按顺序或并行地执行每个节点。每个节点类型都有一个对应的“执行器”函数。引擎的关键职责是管理执行上下文一个在所有节点间传递的数据对象、处理错误、记录日志以及支持分支if/else和循环逻辑。我将引擎设计为纯函数式这使得单元测试变得非常容易。3. 连接器与集成层这是与外部世界沟通的桥梁。每个第三方服务如Gmail、Slack都有一个对应的“连接器”模块。连接器封装了该服务的认证OAuth2或API Key、API端点调用和错误处理。我采用了适配器模式所有连接器都实现统一的接口execute(config, context)这样执行引擎就可以用同样的方式调用它们。为了在“测试模式”下运行而不需要真实凭证我为每个连接器都创建了模拟Mock实现返回静态的示例数据。4. 调度与触发层负责在正确的时间启动工作流。它包含几个部分Webhook接收器一个公开的HTTP端点接收外部事件验证HMAC签名确保请求来源可信然后排队执行对应的工作流。定时调度器基于Cron表达式的后台服务定期扫描需要执行的工作流并将其送入执行队列。队列系统我使用了Bull基于Redis的队列将执行任务排队处理。这带来了两个巨大好处异步执行避免HTTP请求超时和重试机制失败的任务可以按指数退避策略重新尝试。3. 关键功能实现与深度剖析3.1 拖拽式构建器的核心实现构建一个稳定、直观的拖拽式界面远不止是把React Flow组件搬过来那么简单。核心挑战在于如何将画布上的视觉元素节点、连线与后台的工作流数据模型实时、无损地同步。数据同步策略双向绑定与防抖我采用了中心化的状态管理Zustand存储整个工作流的状态。画布上的每一次操作拖拽节点、连接端口、删除元素都会触发一个Action来修改这个中心状态。同时任何对节点配置表单的修改比如填写API URL也会更新到同一个状态树中。这里的关键优化是“防抖”Debounce自动保存。每当状态发生变化我会启动一个定时器比如1.5秒后将最新状态同步到后端。这避免了用户每敲一个字母就产生一次网络请求同时在发生意外浏览器崩溃时数据损失也被控制在很小范围内。React Flow提供了onNodesChange、onEdgesChange等回调让我能精准捕获用户意图。节点类型系统与动态表单系统支持多种节点类型触发器Webhook, Schedule、操作HTTP Request, Send Email、逻辑If/Else, Loop、数据转换Code, JSON Transform。每种类型都需要不同的配置表单。我实现了一个节点注册表将节点类型映射到三个关键部分1) 在画布上显示的UI组件2) 对应的配置表单React组件3) 后端执行器函数。当用户从左侧面板拖出一个“HTTP请求”节点时实际上是在状态中添加了一个{type: ‘http_request’, data: {url: ”, method: ‘GET’…}}的对象。当用户点击这个节点时系统会根据其type动态渲染出对应的配置表单。这种设计使得添加新的节点类型变得非常模块化。连线与数据流验证连线不仅仅是画一条线。在HarshAI中连线定义了数据的流向。每个节点的输出端口都有其数据类型例如string、number、object。当用户尝试将两个端口连接起来时系统会进行类型检查。尝试将一个“HTTP请求”节点的json输出object类型连到一个“发送邮件”节点的subject输入string类型是不允许的系统会禁止连线或给出明确警告。这在前端就预防了许多潜在的运行时错误。实现上我为每个节点定义了一个inputSchema和outputSchema使用类似JSON Schema的结构连线时进行模式匹配。3.2 工作流执行引擎的设计细节执行引擎是自动化系统的“心脏”它的可靠性直接决定了产品的可信度。我的目标是让它像瑞士钟表一样精确、可观测、可恢复。上下文Context与数据传递执行引擎启动时会创建一个初始上下文对象。对于Webhook触发上下文初始值就是Webhook的Payload。这个上下文会在节点间流动。每个节点执行时都可以从上下文中读取数据执行完毕后将输出数据写入上下文通常以一个特定的键如steps.http_request_1.response。我设计了一套简单的模板语言允许用户在节点配置中引用上下文变量例如{{steps.webhook_1.body.email}}。引擎在执行前会解析这些模板替换为实际值。这实现了节点间的数据解耦和灵活引用。错误处理与重试机制“出错是常态而非异常。”在分布式自动化中尤其如此。我的错误处理分为几个层级节点级Try/Catch每个节点执行器都被包裹在try-catch中。任何未预期的错误都会被捕获记录详细的错误信息错误堆栈、输入数据快照并将该节点标记为失败。工作流级错误处理我引入了“错误处理”节点作为一种特殊节点。用户可以在工作流中关联一个错误处理节点到某个操作节点。当操作节点失败时引擎会跳转到对应的错误处理分支执行可以进行通知、记录或补偿操作。全局重试队列对于因网络波动等临时性问题导致的失败引擎会将任务推送到Redis队列Bull中。Bull支持配置重试策略我设置为“指数退避”第一次重试在5秒后第二次在20秒后第三次在60秒后。这大大提高了对瞬时故障的容错能力。分支、循环与并行执行实现逻辑控制是让工作流从“线性脚本”升级为“智能程序”的关键。分支If/Else我设计了一个“条件”节点。用户配置一个JavaScript表达式如data.value 100引擎在运行时用沙箱后面会提到安全地执行它根据布尔结果决定走true分支还是false分支的连线。循环For Each循环节点接收一个数组然后为数组中的每个元素并行或串行地执行其子工作流循环体每次迭代将当前元素注入子上下文。并行执行当一个节点的多个输出端口同时连接了后续节点时引擎会使用Promise.all来并发执行这些下游节点显著提升处理速度。实操心得执行引擎的日志系统至关重要。我为每一次工作流运行生成一个唯一的execution_id并记录下每个节点的开始时间、结束时间、输入、输出和状态。这个“执行历史”功能不仅是调试的救星在用户询问“为什么我的数据没收到”时也是排查问题最直接的证据。3.3 安全与多租户实现作为一个开源且支持自托管的多用户系统安全是绝对不能妥协的底线。我主要从认证、授权、资源隔离和输入安全几个层面着手。认证与用户会话我直接集成了Clerk来处理用户认证。它省去了我自己实现注册、登录、密码重置、社交登录Google, GitHub等繁琐且易出错的功能。Clerk提供了React组件和Node.js SDK让我能轻松在前端保护路由在后端API中获取当前用户身份。所有对工作流、执行历史等资源的API请求都必须携带有效的会话令牌后端会验证令牌并提取user_id。基于用户的资源隔离这是多租户的核心。数据库中的所有核心表workflows,executions,connections都有一个user_id字段。每一条数据库查询都必须显式地包含where user_id ?条件。这是一个铁律。我通过在数据库访问层使用Prisma ORM注入一个全局的查询过滤器来实现这一点自动为所有查询加上用户范围限制从根源上防止越权访问。即使用户A知道了用户B的工作流ID他也无法通过API操作或查看它。Webhook安全HMAC签名Webhook是系统对外暴露的入口必须防止伪造请求。我采用了类似Stripe的HMAC签名机制。当用户为一个工作流创建Webhook端点时系统会为该端点生成一个唯一的密钥。用户需要将这个密钥配置到发送Webhook的外部服务中。外部服务在发送请求时需要用密钥对请求体或特定部分计算一个HMAC签名放在请求头如X-Webhook-Signature中。HarshAI的Webhook接收器在收到请求后用本地存储的密钥重新计算签名并与请求头中的签名进行比对。只有完全匹配请求才会被处理。这确保了只有持有密钥的合法发送方才能触发工作流。沙箱Sandbox与代码执行安全系统允许用户在“代码”节点中编写自定义JavaScript用于数据转换。允许执行用户代码是极其危险的。我的解决方案是使用一个严格的沙箱环境。我评估了vm2和isolated-vm等库最终选择了功能与安全性平衡的vm2。我将用户代码限制在一个纯净的上下文中只注入有限的、安全的工具函数如lodash并彻底屏蔽所有require、process、fs等Node.js核心模块的访问。同时设置执行超时如3秒和内存限制防止恶意或低效代码拖垮服务器。4. 开发历程40天冲刺的实战复盘4.1 第一阶段核心构建器第1-15天这个阶段的目标是打造出产品的“形”即用户看得见、摸得着的交互界面。我的策略是“垂直切片”开发尽快做出一个从创建到保存的最小闭环而不是先做完所有前端再做后端。第1-3天搭建基础框架我用了不到三天时间用create-next-app初始化了项目配置了TypeScript、Tailwind CSS和基本的项目结构。同时在Supabase上创建了数据库项目并设计了最初的数据表users(由Clerk管理)、workflows、nodes、edges。这一步的关键是保持简单表结构只包含最必需的字段后续可以随时通过迁移Migration添加。第4-10天React Flow集成与核心交互这是前端攻坚期。集成React Flow后我首先实现了节点的拖拽放置、连线绘制与删除。然后我构建了左侧的“节点面板”和右侧的“节点配置抽屉”。最大的挑战是状态管理。我尝试了直接使用React Flow的状态但很快发现当需要与后端同步、实现撤销重做时状态变得难以管理。于是我引入了Zustand将所有画布状态和工作流业务状态集中管理逻辑顿时清晰了许多。到第10天我已经可以实现拖出一个Webhook触发器节点和一个HTTP请求节点将它们连接起来配置HTTP请求的URL然后点击“保存”——这个工作流定义能被成功保存到数据库。第11-15天实时连接与UI打磨保存之后下一步是让它“活”起来。我实现了基于Supabase Realtime的实时同步。当用户在A浏览器编辑工作流时其更改会几乎实时地出现在B浏览器中显示一个“他人正在编辑”的提示。这为未来的协作功能打下了基础。同时我花时间打磨UI让画布可以缩放、平移节点选中时有美观的光晕效果连线是平滑的贝塞尔曲线确保整个界面在手机和平板上也能基本可用移动响应式。第一阶段结束时我拥有了一个看起来专业、交互流畅的构建器原型这给了我巨大的信心。4.2 第二阶段执行引擎与基础集成第16-25天有了“形”现在需要注入“魂”。这个阶段的目标是让保存的工作流能够真正运行起来并与真实世界互动。第16-20天构建核心执行引擎我创建了一个独立的Node.js服务后来与主API服务合并专门负责执行工作流。它的核心是一个递归函数executeNode(nodeId, context)。函数会从数据库中读取节点配置根据节点类型调用对应的执行器获取结果后更新上下文然后查找该节点的所有下游节点递归执行。我首先为http_request和delay延迟这两种最简单的节点编写了执行器。为了测试我创建了一个简单的API端点来手动触发执行。当看到配置好的HTTP请求节点成功调用了一个外部API并返回结果时那种成就感无与伦比。第21-25天集成真实API与测试模式接下来是连接外部世界。我挑选了四个最常用的服务Gmail发送邮件、Slack发送消息、Notion创建页面和Twitter现X发送推文。每个集成都是一场“战斗”因为各家的OAuth2流程和API设计都有细微差别。我统一了模式前端引导用户跳转到服务商的授权页面授权后回调到我的后端后端用授权码换取access_token和refresh_token安全地存储到数据库加密存储。执行节点时再取出token来调用API。 同时我深知要求用户在构建阶段就提供真实凭证会极大阻碍体验。因此我实现了“测试模式”。在这个模式下所有连接器都会使用模拟数据。例如Gmail节点不会真的发邮件而是返回一个成功的模拟响应。这让用户可以畅通无阻地设计、调试整个工作流逻辑直到最后一步才需要填入真实凭证并发布。4.3 第三阶段高级功能与可靠性加固第26-35天产品能跑了现在要让它跑得稳、跑得远。这个阶段专注于后台服务、错误处理和系统可观测性。第26-30天后台调度器与Webhook接收器定时任务和Webhook是自动化的两大触发器。我使用node-cron库实现了调度器。它作为一个常驻进程每分钟检查一次数据库找出那些配置了Cron表达式且下一次执行时间已到的工作流将其提交给执行引擎。这里要注意处理系统的时区问题我统一使用UTC时间存储和计算。 Webhook接收器是一个公开的POST端点。我为其设计了友好的URL格式如/api/webhooks/[workflow_id]/[secret]。实现HMAC签名验证后我意识到重试逻辑同样重要。如果工作流执行因临时故障失败用户会丢失数据。因此我将Webhook触发的工作流执行也推入了Bull队列并配置了指数退避重试策略最多重试3次。第31-35天错误处理、日志与仪表盘我开始系统性地为执行引擎添加错误处理。不仅仅是捕获异常还要对常见的API错误如4xx、5xx状态码进行归类提供友好的错误信息。我建立了完整的执行历史记录每一次运行、每一个节点的状态都存入数据库。 有了这些数据我构建了一个简单的分析仪表盘。用户可以在这里看到工作流的总执行次数、成功率、平均耗时等图表。这对于监控自动化流程的健康状况至关重要。我还添加了邮件通知功能当工作流连续失败多次时可以自动发送告警邮件给创建者。4.4 第四阶段模板、版本控制与发布准备第36-40天最后冲刺阶段目标是提升产品的可用性和协作性让它从一个工具变成一个平台。第36-38天模板市场与版本控制我允许用户将任何工作流“发布”为模板。模板只包含节点结构和配置不包含用户的个人凭证等敏感信息。我创建了一个模板库页面用户可以浏览、搜索和“一键使用”模板这能极大降低新用户的上手门槛。 版本控制是另一个专业级功能。每次用户保存工作流时系统都会自动创建一个版本快照。我实现了一个简单的对比界面用户可以查看不同版本间的差异节点增删改并可以轻松回滚到任意历史版本。这相当于为工作流提供了Git般的安全网。第39-40天速率限制与生产部署作为开源项目我必须考虑资源滥用。我实现了基于用户的速率限制Rate Limiting设计了4个层级免费用户、基础用户、高级用户等每个层级在单位时间如每分钟内能执行的工作流次数不同。这通过在API网关层Vercel Edge Functions或自定义中间件使用令牌桶算法来实现。 最后我将前后端代码部署到Vercel配置了生产环境的环境变量确保数据库连接、密钥等都已就绪。当我在公网成功通过自己的HarshAI实例触发了一个工作流并收到Slack通知时我知道一个历时40天、包含44%核心功能的开源自动化平台真的诞生了。5. 遇到的挑战与解决方案实录5.1 状态管理的复杂性陷阱问题描述在开发构建器初期我简单地将React Flow的nodes和edges状态直接用作数据源。但随着功能增加节点配置表单、撤销重做、实时协作状态更新变得散落在各个组件中难以追踪。特别是实现“撤销/重做”功能时需要记录完整的状态快照历史直接操作React Flow的状态变得异常笨拙。解决方案引入中心化、不可变的状态管理。我使用Zustand创建了一个useWorkflowStore。状态树不仅包含nodes和edges还包括工作流元数据名称、描述、选中的节点ID等。所有对画布或工作流的修改都必须通过Store提供的Action如addNode,updateNodeConfig,connectEdge来进行。在这些Action内部我使用Immer库来以“可变”的语法生成新的不可变状态。撤销/重做功能变得非常简单只需在每次状态变更前将当前状态推入一个历史堆栈即可。React Flow画布变为一个纯粹的“视图”它通过useWorkflowStore订阅状态并将用户交互事件转发给Store的Action。避坑技巧在涉及复杂交互的前端应用中尽早采用中心化状态管理。不要等到状态 spaghetti意大利面式代码出现后再重构。Zustand Immer 的组合在简洁性和功能性上取得了很好的平衡。5.2 工作流执行中的循环依赖与死循环问题描述在工作流执行引擎中节点之间通过连线形成有向图。我需要确保这个图是无环的DAG否则执行会陷入死循环。例如节点A的输出连向节点B节点B的输出又连回节点A。此外用户可能无意中创建了非常深的递归链路导致调用栈溢出。解决方案执行前的图验证与执行中的深度保护。静态验证在用户保存工作流时后端会进行一次图分析。使用深度优先搜索DFS或拓扑排序算法来检测图中是否存在环。如果发现环则拒绝保存并前端高亮显示有问题的连线。动态保护在执行引擎中我为每次工作流运行维护一个visitedNodes集合。当引擎要执行一个节点时先检查它是否已经在本次执行中被访问过。如果访问过说明出现了运行时循环可能通过动态条件产生的环路引擎会立即抛出“检测到可能循环”的错误并停止执行。同时设置一个全局的最大执行步数如1000步作为最后的安全网。5.3 第三方API集成的“脏活累活”问题描述每个第三方API都有其独特的脾气。OAuth2的流程有authorization_code、client_credentials等不同授权类型API的速率限制策略各异错误响应的格式千差万别有些服务如Google的API访问令牌过期后需要用刷新令牌去获取新的这需要后台定时任务。解决方案抽象出统一的“连接器”接口与凭证管理服务。定义接口我创建了一个Connector接口要求所有连接器实现authorize(config),execute(config, context),test(config)等方法。凭证管理在数据库中建立connections表存储加密后的API密钥或OAuth令牌。实现一个CredentialManager服务负责令牌的加密存储、自动刷新对于OAuth和安全的检索。错误标准化在每个连接器的execute方法内部捕获所有可能的异常网络错误、API错误等并将其转换为内部统一的ExecutionError对象包含错误代码、用户友好消息和原始错误信息便于引擎统一处理。速率限制为每个需要速率限制的API集成一个简单的内存或Redis令牌桶确保不会触发服务商的限制。5.4 自托管部署的复杂性问题描述承诺“可自托管”意味着我的代码不能依赖任何特定的云服务商特性。在开发初期我大量使用了Supabase和Vercel的特定功能如Supabase Realtime, Vercel Edge Config。如果用户想在自己的服务器上部署这些都会成为障碍。解决方案依赖注入与环境抽象。抽象关键服务我将数据库访问、实时通信、对象存储等操作抽象成接口例如IDatabaseService,IRealtimeService。提供多种实现对于数据库我提供了基于Supabase的实现和基于原生PostgreSQL通过Prisma的实现。对于实时通信提供了基于Supabase Realtime的实现和基于Socket.io的备用实现。在项目配置中用户可以通过环境变量如DATABASE_PROVIDERsupabase|postgresql来选择使用哪种实现。清晰的部署文档我编写了详细的Docker Compose配置和手动部署指南列出了所有必需的环境变量数据库URL、加密密钥、OAuth应用ID和密钥等并提供了初始化数据库的SQL脚本。确保一个熟悉Docker的开发者能在30分钟内完成部署。6. 未来路线图与社区共建40天只是一个开始。剩下的56%功能第41-90天计划将围绕扩展性、易用性和生态建设展开。Phase 5: 集成扩展 (第41-50天)核心是“连接一切”。计划新增20多个预置连接器覆盖CRM如HubSpot、电商如Shopify、支付如Stripe等常见场景。更重要的是AI原生节点集成OpenAI GPT、Anthropic Claude、图像生成等模型让工作流不仅能处理数据还能生成文本、图像进行智能决策。例如可以构建“自动分析客服邮件并生成回复草稿”的工作流。Phase 6: 体验打磨 (第51-70天)这个阶段专注于让产品变得丝滑。包括全面的UI/UX重构优化大型工作流的加载和渲染性能。编写端到端E2E测试和集成测试确保核心功能的稳定性。制作完整的文档、视频教程和交互式示例降低学习曲线。Phase 7: 发布准备 (第71-90天)启动封闭测试收集早期用户反馈。建立社区如Discord服务器让用户能交流使用心得和模板。修复所有高优先级Bug。最后精心准备Product Hunt发布材料向世界正式介绍HarshAI。对开源社区的期待我深知一个人的力量有限。HarshAI的成功离不开社区。我欢迎各种形式的贡献 Bug报告在GitHub Issues中清晰描述问题。 功能建议分享你的自动化需求场景。 集成请求告诉我你最希望看到的下一批第三方服务是什么。⭐ 代码贡献如果你对TypeScript、Node.js或React熟悉欢迎提交Pull Request来修复Bug或实现新功能。我从项目开始就注重代码的可读性和模块化设计以降低贡献门槛。构建一个开源项目就像跑一场马拉松公开构建Build in Public则意味着全程直播。这40天里有连续编码8小时的亢奋也有对着复杂Bug一筹莫展的自我怀疑。但看到代码从零变成一个有生命力的产品看到第一个外部用户成功部署并运行了他们自己的工作流所有的疲惫都烟消云散。这44%的完成度不仅仅是一个数字它代表了一个可用的核心、一个坚实的地基。剩下的旅程我邀请你一同见证和参与。
 ❀ 01. 解锁高端防火墙的PPPoE拨号 ❀ FortiGate 配置指南)
