低代码平台怎么选？给中小企业的诚实框架

立场先说清楚

我们做低代码平台，所以这篇不是第三方测评。下面这五问，每一问先给"该看什么"的通用判据，再说明在我们自己的平台（Inkwell AI 构建器）上对应的是什么能力，你可以拿这套问题去和任何一家厂商对话。如果读完你觉得低代码不适合你，这也是有用的结论——多买一套用不起来的平台，比什么都没买更糟。

第一问：数据到底在哪，能不能拿得走

这一问最容易被话术盖住。演示时页面都很漂亮，但决定你三年后会不会被绑住的，是数据在不在你手里。

该看三件事：

表结构在谁手上：字段是你自己定义、随时可查的，还是封装在平台内部、只能透过某个页面看到？
能不能整体导出：业务台账能不能导成 Excel，或者通过接口同步到你的其他系统？
退出成本：假设一年后你不想用了，数据以什么形式迁走、谁负责？

在 Inkwell 上，AI 构建出的模块，数据表结构在平台里是可见、可查的（字段口径见 /docs/data-dictionary.html），页面数据可以导出；要和别的系统打通时走接口对接（/docs/api-integration.html）。注意这里的判据是可当场验证的形式，不是"数据肯定归你"这句口头保证。## 第二问：权限能细到什么程度

权限是最不显眼、又最容易在上线后出事的环节。演示阶段没人会问，等发现问题时往往已经很难改。

该看四个层级：

菜单与页面级：不同角色进去看到的功能入口不一样。
操作级：同一个页面里，谁能改、谁只能看。
组织维度：部门与租户之间是否隔离——集团下两个子公司能不能互相看到对方的数据。
数据行级与字段级：例如"销售只能看自己负责的客户""薪资字段对普通主管隐藏"。

前三层在成熟平台上基本是标配。Inkwell 内置角色、权限点与权限树，配合部门与租户的组织骨架（/docs/roles-permissions.html、/docs/org-tenants.html）。

第四层是分水岭。问法要具体：别问"支不支持"，要问"在哪个页面、用谁的账号、点哪几步，现在演示给我看"。只回一句"可以做"的，通常成本会落到你后续的定制预算里——建议把它写成验收项，放进合同附件。

第三问：改一次要花多大代价

低代码的"快"体现在第一次搭建，真正的成本在第二次、第三次改动：业务规则变了、要加字段、审批要多一级。

该看的判据：

谁来做这次改动：必须排原厂的期，还是你自己的业务管理员就能改？
改动粒度：加一个字段、加一条校验规则、调一次审批链，分别是多大操作量？
改坏了怎么办：有没有版本记录能回滚，改之前的样子找不找得回来？
知识留在谁那里：平台里的逻辑是写在只有原厂看得懂的地方，还是留在你团队的文档和指令记录里？

在 Inkwell 里，模块修改靠对 AI 下达修改指令完成，配套错误账本与版本回滚（/docs/builder-modify.html）。这一点决定了第二年你到底还需不需要原厂坐在旁边。## 第四问：手机上能不能用

中小企业的很多动作天然发生在手机上：车间报工、仓库收货、门店盘点、外勤拜访、物业报修。评估时别被"我们有 App"带走，要看能不能干活。

该看的判据：

常用动作在不在首屏：仓库收货要几步，需不需要反复跳页。
弱网环境：车间、地下室信号差的时候，录了一半的数据会不会丢。
拍照与扫码：现场取证、扫物料条码，是平台自带能力，还是要你手输编号。
PC 与手机是不是同一份数据：两边看到的不一致，是双端系统最常见的坑。

Inkwell 的做法是 PC 端构建的模块会同步出现在移动端，数据和权限同源（/docs/mobile-guide.html）。实操建议：拿一个真实场景——比如"仓库收货并拍照留档"——要求现场在手机上走完整流程。

第五问：上线前有没有质量门

这一问是我们的私心所在，因为它"演示看不出、出事才知道"。低代码让改东西变容易，同时也让改坏东西变容易。

该看的判据：

发布前有没有自动检查：字段有没有配错、必填有没有生效、页面引用的数据源还在不在。
发布后能不能回退：出问题时是改回来，还是"覆盖回去"。
改动有没有留痕：谁在什么时候改了哪个模块的什么内容，能不能查。

Inkwell 把这一环做在模块的测试与发布上：发布前有预检，发布时挂载菜单并同步移动端，出问题有错误账本与审计日志可查（/docs/module-test-publish.html、/docs/ai-monitoring-audit.html）。

判断方式很直接：让厂商现在演示一次"故意配错一个字段，看系统怎么拦住"。这一条比看二十页功能清单有效。## 说清楚：什么情况下你不该选低代码

需求是实时算法或控制逻辑：排产优化求解、机器视觉质检这类场景不在低代码的战场——它擅长业务数据、页面与流程，不擅长实时控制。
现有系统跑得挺好，业务三年内不会变：迁移成本换不来收益，先别动。
团队里没人能担任"业务管理员"：全指望外部原厂的话，平台再灵活也用不起来，因为灵活性需要有人用。
你要的是设备联网与产线实时控制：那属于工业物联网的范畴，不是业务系统构建器的交付范围。

一份可以带走的评估清单

把下面五条原样发给每一家候选厂商，请他们逐条书面回答：

我的数据存在哪里、能不能整体导出、迁走的流程是什么？
权限支持到菜单/操作/组织/数据行哪一层，能不能现场演示？
加一个字段、加一条校验规则、调一次审批链，分别谁来做、多久能改完？
同一个业务场景在手机端能不能跑通，双端数据是否同源？
发布前有什么自动检查，出错怎么回退，改动记录在哪儿查？

写完清单你会发现，这五问没有一条是在比功能条目数量。选型真正的分界线，是"能不能当场验证"。

想先看这套问题落成一个真实模块是什么样子，可以从 /docs/quickstart-ai-builder.html 的最小例子入手；如果对"低代码到底是什么、和传统开发以及 AI 构建是什么关系"还没理清，建议先读 /docs/what-is-low-code-platform.html。