架构与工程
Flowtor 的技术架构
采购方、供应商、工厂和物流伙伴在 Flowtor 中协调真实的订单，因此它的工程实现与它的功能同样重要。本页介绍其背后的原则和机制，不做我们无法兑现的承诺。
工程原则
以事实为先
系统反映实际发生了什么，而不是承诺了什么。每次变更都带有来源、时间和操作人，因此 Flowtor 能说明它为何认为某件事属实。
安全内建于设计
各组织相互协作，却看不到彼此的业务。隔离和访问控制是数据模型的一部分，而不是事后加上的一层。
自动化辅助，人来决定
软件监控运营、发现缺口并起草跟进。它不会凭空编造运营状态，应由人做的决定始终留给人。
渐进且可验证的交付
新功能以小步、可审查的方式加入，上线前对照已知基准进行检查。
运营透明
重要的架构决策会被记录并纳入版本管理。关键操作都会记录谁在何时、以何种角色做了什么。
由客户主导的配置
系统行为遵循各组织自己的运营规则，而不是强加一种工作方式。
这些原则如何体现在产品中
组织级隔离
每条记录只属于一个组织，隔离通过服务器端的行级安全（row-level security）强制执行，而不仅仅在界面层面。采购方、其供应商和工厂可以处理同一批订单，而各自只能看到属于自己的内容。
基于角色的访问控制
权限作用于功能和记录类型层面，因此较大的团队也能在所需边界内进行管理。
可追溯的历史记录
关键业务操作都会被记录：改了什么、谁改的、何时改的，以及当时的角色。
受控的变更
版本发布遵循成文的操作手册和生产就绪检查清单，并对照基准进行自动化检查。
Flowtor 所依赖的服务
供您自行尽职调查：以下是目前运行 Flowtor 所涉及的主要外部服务。
- Base44：应用平台、数据库、身份验证和文件存储。
- AI 处理通过 Base44 的 AI 网关进行，目前使用 Google Gemini 模型从文件和邮件中提取信息。
- Resend：通知和邀请等事务性邮件。
- Microsoft 365：在使用该功能时，用于接收订单邮件的邮箱。
- Stripe：在使用在线支付时的支付处理。
我们乐意向您的安全、架构和采购团队介绍平台的构建方式以及数据如何隔离。欢迎随时通过 hello@flowtor.com 提交漏洞报告（负责任的披露）。