1.4 适用场景与选型对照：什么时候拿出这套积木

1.4 适用场景与选型对照：什么时候拿出这套积木

本节摘要：用一张场景适配矩阵回答「什么活该派给 NocoBase」：中后台业务系统是主场，轻协作与重消费级交互是客场，数据角色极重的纯分析场景建议换工具。本节给出对照表、判定流程和一手案例展开，让选型从感觉变成工序。

零件盘完了，轮到接活。选型错误是低代码项目返工的第一大来源——不是平台不行，是把平台派去了不该去的现场。本节先给矩阵，再给判定流程，最后拿一桩真实项目从头到尾走一遍选型过程。

从一个工单说起

某连锁口腔诊所连锁化后，总部接到三个需求：顾客预约与回访管理、门店营收日报、面向顾客的在线挂号小程序。三个需求先后来问「能不能用 NocoBase 做」。判定结果并不一致：预约与回访是标准的中后台台账加流程，主场，直接接；营收日报涉及多门店数据汇总与复杂报表导出，客场，平台做数据采集与基础呈现，重型报表部分交给现成 BI 工具组合完成；在线挂号小程序面向公众、并发与体验要求高，不属于它的射程，最终小程序单独开发、接口对接平台里的预约表。同一批需求里判断出三种答案——这就是选型矩阵的用法。

图 1-3 场景适配矩阵：主场、客场与禁区

一、用户群体光谱与各自的拿法

矩阵之外，还有一条「人」的坐标。围绕 NocoBase 的用户大体排成一条光谱：一端是零代码配置的业务骨干，中间是愿意写少量脚本的超级业务员，另一端是全栈开发者。光谱上的位置决定了你能吃到平台哪一段红利：业务骨干吃到的是「需求当天落地」，开发者吃到的是「不必从脚手架开始造轮子」。选型时把未来使用者的位置也想清楚——把平台交给一屋子不愿碰配置的业务人员，或把插件开发排给只会拖拽的团队，都是派工错位。

判定动作可以用一段清单固定下来，每次接活前过一遍：

接活前三问（抄到工单模板里）：
  问一：使用者是谁？
        内部角色为主 → 继续；公众为主 → 停，走客场或换工具评估
  问二：数据长什么样？
        能画出表与关系图 → 继续；以文档、音视频等非结构化为主 → 慎重
  问三：流程能不能画成状态图？
        能 → 继续；充满「看情况」的口头规则 → 先梳理再评估
  三问过关 → 按第2章流程立项装配；未全过 → 回到矩阵找分工
​

二、与其他路线的对账

选型的另一半是把候选路线摆上台面对账。四条常见路线的成本结构各不相同：SaaS 表单工具起步最快，但字段与数据所有权受限，按人头计费长期不便宜；纯表格协作工具适合轻协作，流程与权限是短板；自研框架自由度最大，成本曲线也最陡；NocoBase 落在中间偏左的位置——起步快如 SaaS，数据主权与扩展性接近自研，代价是需要有人维护这套自托管环境。

对账时要算三笔账。直接成本：许可证（开源版零费用，商业插件按需）、服务器、维护人力。迁移成本：现有数据搬进来的工作量，外部数据源能大幅压低这笔账。退出成本：哪天不用了，数据能不能整库带走——开源自托管在这笔账上有天然优势，数据始终在你自己的数据库里。

⚠️ 常见坑：只按「当前需求」选型，不看三年后的需求走向。第一个应用通常很轻，真正的考验是第二年第五个应用进来时，权限模型、数据源、插件之间的纠缠。选型时预想一下那个场景，再决定要不要私有化、要不要提前规范命名。

💡 关键直觉：低代码平台的选择题，本质是问「我的需求有多少比例落在标准零件的覆盖范围里」。比例高于七成，配置路线稳赚；低于五成，不如直接自研。

预算细账：一单中型交付的成本结构

选型对账最终要落到钱上才作数。以一单中型交付为例——三个页面、五张表、两条流程、两批角色，从立项到上线按一个月排期：

成本结构参考（单位：人日）：
  需求拆解与蓝图          3 至 5 人日
  数据建模与样例验收      2 至 3 人日
  页面与流程装配          5 至 8 人日
  权限与角色试锁          1 至 2 人日
  培训、上线与观察期      2 至 3 人日
  合计                   约 13 至 21 人日
  另计：服务器与环境维护  每月约 0.5 至 1 人日
​

对照两条替代路线看这笔账：外包开发承接同范围需求，报价通常以人月计、交付以季度计；SaaS 工具按人头交年费，功能边界由平台说了算。低代码路线的成本大头在「人的时间」而不是「许可证费用」，这也是团队配置熟练度本身构成资产的原因——第二单做同量级的活，人日往往能砍掉近半，熟练度红利随项目数复利增长。

把这笔账写进立项材料还有一层作用：管理预期。业务方看到周期承诺时，也该看到配套条件——需求冻结节奏、值守安排、培训投入。成本账与预期账一起摆上桌，交付才不会赢在上线日、输在六十天后。

选型之后：两周试点计划

判定了「主场」别急着全量立项，先跑两周试点。试点的价值是用最小成本验证矩阵判断：选需求里最典型的一条业务线（一张表、一个页面、一条流程），配置员全职投入，开发者在旁待命。试点产出三样东西：可演示的最小应用、真实用户的直观反馈、以及一份数据——配置员实际花了多久。这份数据是全量立项预算的最好依据，比任何经验公式都准。

试点计划骨架（十工作日）：
  第 1 至 2 天   蓝图：一张表、一个页面、一条流程的定稿
  第 3 至 6 天   装配：建模、页面、流程，每日可演示
  第 7 至 8 天   权限与试锁：两个角色，越权抽查通过
  第 9 天        真实用户试用，收集摩擦点清单
  第 10 天       复盘：预算修正、全量立项的 go 或 no-go
​

试点「no-go」不是失败，恰恰是选型矩阵在起作用——花十个人日确认一条路不通，好过花两百人日撞了南墙再回头。试点通过与全量立项之间还该有一个动作：把试点里随手堆的配置按本册纪律重整一遍，样机的债不带进正稿。

装配要点回顾

• 矩阵先行：主场（内部用户、表与流程密集）、客场（平台只承担一段工序）、换工具（消费级交互与极端并发），接活前先定位；
• 三问判定：用户、数据形态、流程可画成状态图，三问过滤掉大多数错误立项；
• 对账三笔：直接成本、迁移成本、退出成本，开源自托管在退出成本上有天然优势；
• 使用者光谱：业务骨干、超级业务员、开发者的位置决定学习与派工策略；
• 下一步：1.5 走进生态备件库，看看插件、文档、社区这些外部零件怎么领用。