数据应用
数据应用是「能收数据的页面」：在一个可发布的页面上加一个数据面，访客填写的内容写回受管数据库。对外只有「应用」一个概念——只读的构件，就是没有数据面的应用。
// 一句话理解
数字员工造应用最容易出错的地方不是写代码，是做判断：链接怎么定、表怎么建、令牌怎么发、校验规则怎么写、隐私告知怎么加。数据应用的设计思路是让它不必做这些判断——全部由平台在服务端决定。
两种提交方式
声明式默认只提交一个标题和一组字段定义：字段标识、显示名、类型、是否必填、长度上限、选项。页面 HTML 由平台按模板生成。这是推荐路径——数字员工不需要写任何前端代码，也就不会在前端代码里犯错。
自定义 HTML进阶提交自己写的页面，由平台注入数据提交能力。适合需要特殊交互或复杂展示的场景。自定义 HTML 仍然受同一套字段声明约束——页面能提交什么，由声明决定，不由页面代码决定。
字段类型与声明层拒绝
支持的字段类型刻意收窄：文本、多行文本、邮箱、电话、数字、日期、单选。单个应用的字段数量有上限。
// 声明层就拒绝
身份证件号、护照号、银行卡号、密码、生物特征这几类字段，在提交应用定义时就会被拒绝。不是运行期过滤，是根本无法声明——这样即使数字员工「想」收集这些信息，它也造不出这样的应用。
写入通道
访客提交数据要穿过一条严格设计的通道，每一层解决一个具体的攻击面：
- 外壳判身份。访客先到达一个同源外壳，由它按应用的可见性设置判断这位访客能不能看到这个应用。
- 沙箱渲染。应用页面本身在沙箱里渲染，与外壳不共享同源，因此拿不到访客的登录态。
- 铸造一次性令牌。门禁通过后，平台为「当次查看者」签发一个能力令牌，注入到沙箱页面里。令牌绑定这个应用、这次会话。
- 提交经守卫校验。页面用令牌提交数据，服务端依次校验令牌有效性、应用是否接受写入、字段是否在声明范围内、值是否符合类型与长度约束。
- 追加一行。全部通过后追加一条记录。已有记录不被修改，提交是只增的。
数据归谁
- 收集到的数据属于发布这个应用的公司，存放在平台的受管数据区，按该公司的边界隔离。
- 只有该公司有权限的操作员与成员能查看与导出。
- 应用被删除后，已收集的数据不会自动消失——删除应用只是让链接失效，数据的清理是一个独立的、需要明确执行的动作。
典型场景
| 场景 | 形态 |
|---|---|
| 内部报名与统计 | 声明式，登录可见，字段五六个 |
| 供应商信息登记 | 声明式，公开链接，含选项字段 |
| 现场巡检记录 | 声明式，登录可见，手机填写 |
| 带计算的申请表 | 自定义 HTML，页面内先算后提交 |
需要长期维护、需要回访修改、需要版本化问卷的收集场景，用公开表单而不是数据应用——两者的定位差别见那一页开头。
相关阅读
- Artifacts 发布 — 数据应用的承载形态
- 公开表单 — 更重、更正式的结构化收集
- 安全与隐私总览 — 沙箱与门禁的完整设计