电商供应链的系统建设一般偏向于数据管理类型，但此类系统建设有一个很明显的问题就是前后端开发的沟通成本较高（相对研发成本而言），特别是一些简单加减字段的诉求沟通成本甚至达到 50% 以上，如何将这部分沟通成本降低下来，并保证高质量的交付成为目前亟待解决的问题。

经过对需求和系统页面进行分析，我们得出如下数据：

• 供应链 ≤ 2 人日的需求投入工时占接近 50%，两周的迭代周期，一个前端甚至能接到 10+ 需求，时间碎片化特别严重，而这些需求很简单，基本就是一些字段的加减处理，单选改多选，增加导入导出等等。

• 供应链七成页面属于标准的列表类型，也就是我们常说的（CQUD），这种页面的特点就是交互简单、功能标准，我们常见的功能包括：查询、新建、编辑、批量处理、上下线/删除、导入/导出、查看操作日志、查看详情等。

• 即所谓的契约精神问题，什么时间交付接口描述，并且描述清晰？在现实环境中，这是一个比较难达成的事情。服务端什么时候能够上传接口说明，这个时间不确定，即使确定了，也会出现因为各种因素不符合预期，因为很多情况下一个接口和属性的描述他认为描述清楚了，并不代表你能理解，这个就是信息差，但是真要做到你能够理解服务端一定会付出更多成本，有些人会认为没必要。
• 服务端会修改出入参格式而忘记沟通，可能到了比较滞后的联调甚至测试阶段才发现，而且屡禁不止。

源码和低码学习成本趋势图

低代码和几种跨界工具的学习成本对比

• 阿里低代码引擎：https://lowcode-engine.cn/index 强调可视化配置生成页面；
• 百度 Amis：https://aisuda.bce.baidu.com/amis/zh-CN/docs/index 强调 JSON 配置生成页面。

• Amis JSON 配置能力更加强大，相对于 Lowcode Engine 需要写很多脚本来满足稍微复杂的场景，JSON 配置的学习成本更低，更适合服务端同学快速上手；
• Amis 的文档功能更加强大，可以直接编辑 JSON 查看修改后的结果，这一步可以极大的方便开发学习 API。

1. 没有认清使用人群：B 端低代码产品的绝大部分用户是前端，专业人士用低代码多少有点抵触情绪的，给别人用之前一定要想清楚，他为什么会用？或者说他因为什么才会用？个人认为给前端提供低代码工具做 B 端系统，大概率是行不通的，也许会有效率提升，但是相对专业降级及蹩脚研发体验可能不值一提。
2. 灵活性不足：当遇到某种逻辑的时候，用起来就会很蹩脚或者根本没法做下去，正所谓 “一行代码难倒英雄汉”，只能源码开发一遍，这种不断尝试后的返工确实会让体验大大降低，这种一般受组件不支持或者低代码引擎不支持影响。
3. 功能不完备：其实做好一个页面，要考虑多方面问题：联调、页面管理、发布/回滚、菜单、权限等，这些是不是都考虑在内了，那种体验割裂，流程分散在各个平台的方式一定会被吐槽的。
4. 缺乏设计理念：比如常用组件的一种配置有多种属性命名方式，还有就是功能实现不符合大众认知等等，导致 API 的理解和学习成本巨大。
5. 认知成本高：比如我们目前服务端全栈的场景，他们甚至不知道组件的概念，也不知道所谓的数据驱动，拿到的 PRD 对于页面的描述很有可能只是一大段文字描述，连个像样的线框图都没有，对于一个新手如何做才能还原成和标准交互一样的页面，其实是一个很大的考验，这些细节都是我们需要考虑并解决的。

选择显示姓名，姓名展示，选择禁用密码，姓名隐藏，密码禁用

import React, { useState } from 'react';import { Radio, Form, Input } from 'antd';
type FieldType = {username?: string;password?: string;type?: number;};
const App: React.FC = () => {const [form] = Form.useForm();const [hiddenName, setHiddenName] = useState(false);const [diablePassword, setDiablePassword] = useState(false);
const onValuesChangeHandler = (values: FieldType) => {setHiddenName(values.type !== 1);setDiablePassword(values.type === 2);};
return (<Formform={form}name="basic"labelCol={{ span: 8 }}wrapperCol={{ span: 16 }}style={{ maxWidth: 600 }}onValuesChange={onValuesChangeHandler}autoComplete="off"><Form.Item<FieldType> name="type" wrapperCol={{ offset: 8, span: 16 }}><Radio.Group><Radio value={1}>显示姓名</Radio><Radio value={2}>禁用密码</Radio></Radio.Group></Form.Item>{!hiddenName && (<Form.Item<FieldType> label="姓名" name="username"><Input /></Form.Item>)}
<Form.Item<FieldType> label="密码" name="password"><Input.Password disabled={diablePassword} /></Form.Item></Form>);};
export default App;

{"type": "form","body": [{"type": "radio","name": "type","label": "类型","options": [{"label": "显示姓名","value": 1},{"label": "禁用密码","value": 2}]},{"type": "text","name": "username","label": "姓名","visibleOn": "${type == 1}"},{"type": "password","name": "password","label": "密码","disabledOn": "${type == 2}"}] }

• 快速了解某个组件怎么使用或者概念；
• 复杂的表单联动关系；
• 根据需求生成或者修改页面结构；
• 帮你理解页面配置。

• 根据文档中的组件示例、组件 API 描述、概念描述、示例、存储的 QA 问题等快速生成种子问题。
• Proto 和智能答疑的正负向反馈都会被作为训练数据放入种子问题中。
• 种子问题数量有限（1000 以内），所以会进过一轮人工的验证，比如你如果发现 SearchPage 组件相关的问答不够准确，可以搜索处理对种子问题进行矫正，如下是一个简单的种子问题校准工具。

综合流程整理如上

功能架构图

文 / Steven