1.2 无代码与低代码：同一现场的两种工种

1.2 无代码与低代码：同一现场的两种工种

本节摘要：无代码与低代码不是两个产品品类，而是同一装配现场里的两种工种：前者用配置零件拼装标准结构，后者在配置够不着的地方写扩展件。NocoBase 的价值在于让两种工种在同一平台上接力。本节划清工种边界、给出交接接口，并帮你定位自己的学习路径。

1.1 立住了「数据模型驱动」这根定海神针，接下来得把现场里的人分分工。很多选型争论之所以鸡同鸭讲，是因为争论双方站在不同工位上：业务人员眼里低代码就是拖拖拽拽，开发者眼里低代码是套壳黑盒。把工种讲清楚，这两拨人才能在同一份图纸上说话。

从一桩真实的接力说起

某设备经销商要一套售后服务台：客户报修、派工、回访、月度对账。前四分之三的活是标准的——数据表、表单、列表、状态流转，配置员两天拼完。最后一步卡住：对账单要按经销商自己的一套佣金阶梯算提成，规则绕得没法用界面配置表达。这时开发者进场，写了一个计算节点插件挂在工作流里，半天收工。业务方全程没离开过浏览器，开发者全程没碰过界面层——两条工种在「工作流节点」这个接口上完成了交接。

这桩接力里的分工逻辑，就是本节的主旨：配置解决标准问题，代码消化长尾问题，平台的价值取决于两者切换的摩擦有多小。切换摩擦小，多数项目停在配置区就收工；摩擦大，配置区拼到一半还得推倒重来。

一、两种工种的工具箱

工具箱的差异背后是抽象层级的不同。配置员面对的每一颗螺丝（字段类型、区块参数、节点选项）都是平台预先验证过的组合，拧错方向顶多不生效；开发者面对的是平台真实的扩展接口，自由度大，错了会真报错。所以现场纪律也不同：配置区的改动鼓励即改即看，扩展区的改动要走版本管理与测试——这个纪律差异在第 4 章讲插件开发时还会强化。

二、交接接口在哪里

NocoBase 把两种工种的交接面设计得很窄、很清楚，常用的有三处。第一处是工作流的自定义节点：开发者把一段复杂逻辑封装成节点，配置员就能像拖普通节点一样在画布上使用它。第二处是自定义操作：按钮背后的请求逻辑由开发者定义，按钮摆在哪个页面、对哪些角色可见，交给配置员调度。第三处是数据源的接入配置：开发者负责把外部库接进来、把视图包装成数据表，配置员拿到手的就是几张能直接用的表。

用一个请求配置看第二处接口的样子——配置员在界面上给按钮绑定自定义请求时，底层对应的配置结构是：

// 「标记为已回访」按钮的自定义请求配置（界面表单填写后生成）
{
  "action": "customize:updateVisitFlag",
  "resource": "service_orders",          // 作用在工单表上
  "params": {
    "filter": { "id": "{{ ctx.record.id }}" },   // 上下文变量：当前行记录
    "values": { "visit_flag": true, "visited_at": "{{ now }}" }
  }
}
​

配置员只需要理解三件事：动作名是开发者给定的、资源选哪张表、参数里的上下文变量指向当前记录。至于服务端如何校验权限、如何写库，全部封装在开发者交付的插件里。接口窄的好处就是本章反复出现的那个词——接力时掉不了链子。

三、你在哪个工位，该学哪些章

工位决定学习路径。纯业务背景、目标是自己部门的台账与审批流：走第 2 章和第 3 章就够了，第 4 章读个开头知道开发者能干什么即可，需要扩展时你知道去哪找人。有开发背景、要负责整个平台的交付：六章全走，重点在第 4 章与第 5 章，因为交付物能不能长期活着，取决于扩展代码的质量和运维的章法。介于两者之间的「超级业务员」——会写点脚本、愿意折腾：第 2、3 章逐节动手，第 4 章的前半段（插件机制、插件管理器）认真读，后半段（脚手架开发）选读。

⚠️ 常见坑：让开发者全程用配置的方式交付复杂项目，或让业务员硬扛需要写插件的活。两种错配的结局都是烂尾——前者的配置会膨胀成没人读得懂的千层嵌套，后者的业务员会在某个深夜对着接口文档怀疑人生。

💡 关键直觉：判断一个需求该归哪个工种，看它的规则能不能画成一张有限状态的图。能画出来的，配置区基本够用；画不出来、要靠「特殊情况特殊处理」的，早点交给代码。

工位问答三则

问一：完全不会写代码，是不是注定玩不转这套平台？恰恰相反，配置区就是为这条路铺的。第 2 章的建模与页面、第 3 章的流程与权限，全程不碰代码；真正需要代码的时刻，你的任务是把需求描述清楚，交给工位上的另一双手。

问二：团队暂时没有开发者，碰到配置够不着的长尾需求怎么办？三条路按序走：先翻插件货架找现成件；再回头审视需求本身，很多「实现不了」其实是「换个说法就能配置」；最后才是外购或招聘。经验上，多数项目一年里真正需要动手写代码的节点屈指可数。

问三：开发者会不会觉得平台碍手碍脚？头两周会，习惯后不会。把平台当成「替代我写代码的工具」会处处别扭，把它当成「业务系统的标准件库」就顺手了——数据访问层、权限体系、界面框架、任务调度，这些每个项目都要重写的地基全部现成，开发者只写真正属于业务的那部分。

工位自测五题（答不上来的题，就是你的学习重点）：
  1. 你要解决的问题，核心数据实体是哪几个？
  2. 实体之间的关系，能否画成一张不含「看情况」的图？
  3. 需求里有没有必须精确到毫秒或高并发交互的部分？
  4. 未来半年的需求变化，最可能发生在数据层还是界面层？
  5. 谁来负责这套应用上线后的值守与演进？
​

装配要点回顾

• 工种同台：无代码与低代码是同一平台上的两种工种，NocoBase 的设计目标是让两者接力而非二选一；
• 边界判断：规则能画成有限状态图的活交给配置，长尾特殊逻辑交给代码，判断工具就是那张状态图；
• 三处接口：工作流自定义节点、自定义操作、数据源接入，是两种工种交接的主要接口；
• 学习路径：工位决定路径——业务走第 2、3 章，开发者主攻第 4、5 章，超级业务员两条腿走路；
• 下一步：1.3 按数据、界面、逻辑、扩展四层盘点预装零件，无论你站在哪个工位，都得知道盒子里出厂带了什么。