Base44 是一套以对话为主要入口的 AI 应用构建平台，把界面生成、数据实体、身份验证、后端函数、外部集成与托管发布放在同一个工作区。使用者可以先用自然语言描述产品，再在实时预览和管理面板中检查结果，逐步补充页面、数据规则、角色权限和自动化流程。它既能用于公开网站，也能用于登录后的业务应用、内部运营工具、客户门户和带 AI 能力的服务。
这种一体化体验减少了搭建前端、数据库、身份系统和部署环境的前置工作，却不会代替产品定义、权限建模、质量验证和持续运维。把一句模糊想法变成能运行的页面只是起点；真正决定项目是否可用的，是数据边界是否清楚、每个角色是否经过测试、外部调用失败时能否恢复，以及团队是否理解平台托管能力与可迁移能力之间的差异。
本文依据 2026 年 8 月 8 日可访问的官方文档和明确标注的第三方资料整理。Base44 的功能与套餐变化较快，因此计划权益、信用额度、模型可用性和测试功能都应以购买或发布时的工作区为准。文中会明确区分当前文档能力、正在逐步开放的功能、路线图表述和小样本用户评价。
Base44 将自然语言需求转成一个运行中的应用，并把应用放进受管理的环境。编辑器围绕 AI 对话、实时预览和仪表盘展开：对话负责创建或调整页面、实体、表单、权限和逻辑；预览用于走通交互；仪表盘用于检查数据、用户、域名、日志、安全与发布状态。
它因此不只是静态落地页生成器。官方开发文档覆盖持久化数据、登录与角色、实时更新、服务端函数、外部集成和托管，也说明可以通过 JavaScript SDK、CLI 或外部前端使用 Base44 后端。团队可以从无代码式对话开始，也可以在需要时进入代码、GitHub 和本地协作流程。
官方快速入门展示了从描述应用、生成页面与数据、在预览中测试，到配置权限并发布至托管地址的完整路径。生成结果可以读写记录、验证用户、执行后端逻辑和触发工作流，并非只有视觉稿。
但是平台无法替团队判断业务规则是否正确，也无法自动证明一个权限不会泄露租户数据。生成的结账页可能遗漏退款路径，成功的接口演示也可能没有处理限流、重复请求或部分失败。Base44 提高实现速度，产品负责人仍需定义验收标准，开发者和安全人员仍需审查高风险边界。
Wix 在 2025 年 6 月 18 日宣布完成对 Base44 的收购，并表示 Base44 将继续作为独立产品和业务运营。这是一项公司事件，不能据此推导 Wix 的任意能力已经集成进 Base44，也不能把 Wix 套餐或技术承诺自动套用到 Base44。
TechCrunch 在 2026 年 6 月报道 Base44 开始推出专用模型 Base1。这里的关键词是“逐步推出”，不是所有账号都已具备同一模型和同一额度。若项目依赖 Base1，应在自己的实时编辑器中确认可见性、成本和行为，而不是把报道转写成普遍可用承诺。
Default 模式会根据请求修改应用，适合范围明确的功能变更；Discuss 模式用于讨论方案而不改动项目，适合先梳理实体、角色和风险；Edit 模式侧重在预览中选择元素并调整视觉表现。手工视觉编辑与 AI 辅助修改的信用消耗可能不同，应查看工作区的实时提示。
实践中，先在 Discuss 中消除歧义，再用 Default 实施窄范围变更，通常比连续发出宽泛指令更可控。间距、颜色和单个组件样式可留给 Edit，而权限和数据逻辑应写成包含角色、条件、状态与排除项的验收规则。
Base44 可以生成页面和组件，并允许通过对话和视觉编辑继续调整。实时预览适合检查主要路径，但不能只看首屏。需要用真实长度的名称、空数据、错误消息、长表格、窄屏和键盘导航来验证布局。
“看起来完整”不等于“状态完整”。至少检查加载、无结果、校验失败、无权限和外部服务超时等状态。多语言项目还要验证长文本和导航溢出，不能用占位卡片推断正式内容的表现。
平台提供托管数据实体和记录管理界面，AI 可创建字段并连接表单、列表和业务视图。开发者文档描述了灵活的数据层、实时订阅和实体访问规则。设计阶段应先命名稳定的业务对象，再定义所有权、租户关系和允许状态。
身份验证只回答“用户是谁”，授权规则才回答“他能看到或修改什么”。多租户应用应让每条私有业务记录都带组织关系，并用两个不同组织的测试账号尝试越界读取和写入。隐藏按钮不能替代服务端的数据权限。
适用套餐可使用后端函数处理不应放在浏览器中的逻辑，例如敏感 API 调用、Webhook 验证、支付状态确认和需要机密凭据的转换。凭据应放入平台的秘密管理设施，不应写进提示词、普通字段或客户端代码。
Base44 还区分内置集成、带授权连接器和通过 OpenAPI 规范导入的工作区自定义集成。每个连接都应记录所有者、授权范围、凭据过期后的处理方式，以及分页、限流和重复事件策略。接口返回成功一次，不足以证明同步流程具备生产可靠性。
当前官方文档说明：2026 年 7 月 6 日起创建的应用使用 Workflows，较早的应用可能保留 Automations，一个应用只会出现其中一种。Workflows 支持计划任务、实体变化、应用内 Agent 对话和连接器事件等触发方式，也能串联动作、条件、延迟并查看每次运行状态。
因此，旧教程中的 Automation 菜单不能直接套到新项目。新流程要明确触发条件和终态，避免一次更新再次触发自身；涉及邮件、付款或外部记录的步骤要保存幂等标识。维护旧应用时，应先确认它实际显示哪套自动化界面。
每个应用可获得 Base44 托管地址，并从编辑器发布。符合套餐条件时可连接自定义域名，平台负责证书签发与续期。也可以保留外部前端的托管方式，再连接 Base44 的数据和函数。
发布仍然需要版本和回滚纪律。上线前应确认角色测试、安全扫描、秘密有效性、关键集成、数据迁移和域名状态；上线后用新用户会话重新验证，而不是只依赖管理员的既有登录状态。
官方文档说明，Builder 或更高套餐支持 ZIP 下载和 GitHub 连接。GitHub 流程支持双向同步、本地开发、分支与拉取请求。项目还可以使用代码视图、CLI 和 JavaScript SDK，但具体资格与测试状态应在当前套餐中确认。
导出前端代码和数据不等于完整复制托管运行环境。托管身份验证、数据库基础设施和主机并不会自动变成一套可自托管替代品。迁移计划必须单独安排账号、数据、文件、函数、工作流和域名的接管。
Base44 文档说明可通过移动浏览器以及 iOS、Android 构建器应用创建和编辑项目，发布后的 Web 应用也可添加到主屏幕。部分域名或安全管理工作仍可能需要桌面端，因此移动端更适合作为补充工作面。
应用商店产物是围绕已发布 Web 应用的安全 web-view 封装，不是独立原生重写。当前文档明确指出，这条路径不提供原生推送通知和完整离线模式。开发者账号、商店材料、隐私披露和最终审核仍由应用所有者负责。
创业者可以快速搭建带登录、表单、记录和单一核心流程的早期产品，用真实交互验证需求，而不只是展示点击原型。第一版应证明一个用户旅程和一个业务结果，而不是一次模仿成熟平台的全部页面。
若产品包含市场撮合，可先人工处理一侧；若包含推荐，可先采用可审计规则。把不确定部分留在可替换位置，避免在需求尚未验证时建立复杂数据和自动化依赖。
库存追踪、入职清单、服务队列、审批记录和项目看板都适合由实体、角色与 Workflows 组合实现。此类工具的价值在于贴合特定流程，而不是追求无限通用。
内部系统仍可能含员工、客户或财务数据。接入前要定义主数据来源：Base44 是权威系统，还是其他系统的镜像？发生冲突由谁处理？这些决定必须写入流程，而不是留给同步脚本猜测。
身份验证和实体权限可用于订单查询、文件提交、请求跟踪或合作伙伴资产门户。关键设计是让每条记录拥有明确的用户或组织归属，并在查询和后端函数两端执行边界。
测试时应使用两个真实隔离的组织账号，主动尝试访问对方记录。个性化首页只是外观，底层接口是否拒绝越权才是门户能否上线的标准。
团队可构建销售管道、客户成功概览、互动网站和带 AI 的文档处理工具。指标必须有明确定义、来源字段、时区和缺失值规则，并应与原系统对账。AI 结果应与已验证记录分开，重要动作需保留人工批准。
对于主要以内容发布为目的的网站，还应比较传统内容管理系统的编辑流程、重定向、SEO 和可访问性能力。Base44 的优势更明显地体现在页面背后还需要数据、登录或业务动作的场景。
明确目标用户、核心问题、唯一关键流程和必须保存的数据。列出公开或私有、角色、敏感字段、外部集成、预期规模以及第一版明确不做的内容。提示词应描述行为与验收条件，而非只写“做一个现代应用”。
例如，应写明请求属于某个组织、只有该组织成员可查看、经理批准时需记录操作者和时间。这样的约束能帮助 Agent 生成更合理的数据和权限结构。
要求 AI 先给出实体、关系、角色和失败场景，不立即修改项目。让它列出假设，并逐项确认。此阶段适合解释租户字段、Webhook 验证或用户资料分表等技术选择，也能减少后续返工和额度浪费。
先实现注册、创建一条记录、正确角色查看记录并执行一个有意义动作。不要在首次生成中同时加入所有仪表盘、集成和自动化。完成后刷新页面、换会话并检查实体、字段、验证和权限是否符合预期。
逐实体检查创建、读取、更新和删除权限。把外部凭据放入秘密设施，确保第三方调用在后端函数或托管集成中执行。运行安全扫描并人工审查建议；用不同角色账号尝试未授权读写。
一次连接一个服务，记录账号和授权范围，分别测试正常、错误和重复事件。工作流要定义触发器、步骤、条件、延迟、终态和重放标识。修改资金或客户状态的流程应提供人工核对队列。
准备长名称、空字段、特殊字符和边界值，在桌面和移动浏览器中检查导航、焦点、表单错误、慢请求和角色差异。若要提交商店，先验证 Web 应用，因为封装不会自动修复网页里的问题。
导出重要数据和代码，保存已审查版本，记录套餐与集成，重新运行安全扫描。条件允许时先向有限用户发布，观察关键事件、失败函数、工作流运行和额度消耗，并预先知道如何撤回或回滚。
“增加审批页”过于模糊；“经理只能批准本组织的待处理请求，批准时记录操作者和时间”才是可测试规则。功能和视觉修改应分开，让权限正确后再调整样式。
不要把身份验证、数据重构、支付和视觉改版塞进同一提示词。窄范围变化更容易比较、测试和回退。另存简短变更日志，记录需求、提示词、受影响实体、测试和发布时间。
Base44 分开计算消息额度和集成额度，模型、动作复杂度、计划任务和外部调用都可能影响消耗。使用 Discuss 先明确方案，过滤无关事件，能批处理时减少重复调用，并持续查看实时用量。
记录实体、导出数据、函数、集成、秘密、域名和身份假设。在套餐支持时使用 GitHub 或定期 ZIP 导出。主动断开集成、让授权过期、发送重复事件和缺失字段，确认用户能看到可操作错误，运营人员能够恢复或对账。
重点检查处理不可信输入、身份、服务角色、付款、Webhook 和外部 API 的代码。确认验证和授权发生在服务端，搜索暴露凭据与测试值。内置扫描是检查工具，不是安全证明；高风险应用仍需独立审查。
能够描述用户、流程和验收标准，但不想为早期验证组装整套技术栈的团队最容易获得价值。产品经理和设计师也可把静态原型升级为带真实记录与角色的功能原型。
依赖表格、表单和聊天协调特定流程的团队，可以建立更结构化的内部工具。代理机构应提前约定工作区、域名、数据、账单和维护归属，避免交付后所有权不清。
开发者可用生成界面快速起步，通过代码、GitHub、CLI 或 SDK 增强控制。若项目从第一天就要求自托管、特殊数据库保证、完整离线或深度原生能力，则应考虑更可控的基础设施。
主要编辑器运行于浏览器，发布应用可在桌面和移动浏览器访问。官方文档还说明存在 iOS 与 Android 构建器应用，但部分高级管理仍需桌面端完成。
符合套餐条件时可使用 GitHub、ZIP 导出，并通过 CLI 和 JavaScript SDK 开发。商店路径可生成 IPA 和 AAB，但本质是 web-view 包装；不能把它宣传成完整原生运行时，也不能假设具备原生推送和离线模式。
当前官方账单文档列出 Free、Starter、Builder、Pro 和 Elite 五个自助套餐。本文不固化美元价格、应用数量或额度，因为这些内容可能独立变化。购买前应在实时套餐表逐项核对所需功能、计费周期、区域价格和工作区资格。
AI 构建和编辑交互使用消息额度，外部集成与自动化动作使用集成额度；具体消耗会随模型和操作变化。不能只用初次生成成本估计长期费用，还要计入迭代、定时任务、第三方服务、域名与应用商店开发者费用。
GitHub、代码导出、自定义域名、后端能力或商店提交等功能可能依赖套餐。先列出不可缺少的生产能力，再核对当前表格。不要只比较额度，也不要把某次试用中的功能视为永久权益。
Lovable 同样强调提示词驱动的 Web 产品生成；Replit 更接近带 AI Agent 的通用云开发环境；Bolt 提供浏览器内代码项目与 Web 开发流程。比较时应看生成栈、后端选择、Git 流程、设计控制和离开平台时的迁移工作。
Softr 偏向带结构化组件的门户与内部工具；Retool 和 Microsoft Power Apps 在企业连接器、治理和管理方面更成熟。它们可能需要更多配置，却更适合已有企业生态或严格治理需求。
常规技术栈需要更多工程和运维投入，但给予运行时、数据库和部署的最大控制。深度原生应用、受监管系统、特殊性能要求或核心优势依赖自有基础设施时，定制开发通常更稳妥。
Product Hunt 和 G2 页面同时出现正面与负面体验，但参与者是自选样本。访问时 G2 仅有 4 条评价，Capterra 仅有 3 条，绝不能据此得出普遍质量或可靠性结论。应用真实角色、数据量和最难集成做试点，比依赖聚合分数更可靠。
官方安全扫描覆盖权限缺口、暴露凭据、登录验证、依赖漏洞和浏览器安全头，但平台明确要求应用所有者审查设置。隐私文档说明默认在美国存储数据，面向符合条件套餐和创建时间的欧盟或英国选项正在逐步开放，并区分存储位置与处理位置。敏感或受监管数据必须按当前合同、地区和子处理方另行评估。
代码和集合数据可在符合条件的套餐导出，但托管身份、数据库与主机不会作为等价自托管组件一起交付。若将来离开平台，需要迁移账号、数据、文件、集成和工作流。应用归你所有与运行环境可立即复刻是两件不同的事。
商店包是 Web 应用包装，目前没有原生推送和完整离线模式。完全自定义身份流程与完整白标登录界面当前也不受支持，白标属于规划表述。StoreKit、Google Play Billing 或 Base1 等逐步开放能力，都不能当作现有普遍权益承诺。
平台没有一个适用于所有应用的统一规模结论。查询结构、集成、生成代码和流量都会影响性能。Workflows 的 2026 年 7 月转换也说明教程可能很快过时。业务关键项目应运行负载和故障测试，并向 Base44 确认当前限制与支持响应。
可以。官方文档覆盖界面、数据实体、身份验证、后端函数、集成、工作流和托管发布。但“生成完成”不等于“可生产”，权限、测试、成本和运维仍需团队验收。
基础应用可以通过对话和视觉编辑创建，不要求先写代码。复杂数据模型、安全、集成与迁移会受益于技术知识；开发者也可使用代码视图、GitHub、CLI 和 SDK。
当前文档列有 Free，以及 Starter、Builder、Pro、Elite 付费档。权益和额度会变，应在实时套餐页确认，不应只依赖本文或旧截图。
消息额度用于 AI 构建或编辑交互，集成额度用于外部连接和自动化动作。消耗取决于模型、复杂度和动作，最准确的数据来自工作区的实时用量。
符合条件的套餐支持 ZIP、GitHub 和实体数据导出。但导出不会把托管身份、数据库和主机变成自托管等价物，完整迁移仍需架构与数据计划。
符合条件时可执行商店准备检查并生成提交包，开发者账号、上架材料和审核由所有者负责。产物是 web-view 包装，当前不具备原生推送和完整离线能力。
正确配置可见性和实体权限，把凭据放入秘密设施，运行安全扫描，并用每个角色的测试账号尝试越权。高风险或受监管应用还需要与数据等级匹配的独立安全和合规审查。
官方文档支持二者，但都可能受套餐与工作区资格影响。连接域名后由平台管理 HTTPS；GitHub 可用于版本控制和本地协作。购买前应核对当前要求。
它们是两代自动化系统。2026 年 7 月 6 日起创建的应用使用 Workflows，旧应用可能保留 Automations，一个应用只显示其中一套。
当产品适合托管平台，且团队验证了权限、可靠性、成本、可迁移性和支持时可以使用。若完整基础设施控制、深度原生移动、特殊规模保证或受监管部署不可妥协，应选择更可控的架构。
