此次检测围绕功能性、易用性和中文特性展开，为企业了解平台的送检功能与软件质量提供了第三方检测依据。

检测信息​

依据报告整理的信息图，不是报告扫描件。

检测同时参照《多格低代码开发平台 V1.0 需求规格说明书》。报告指出，受检软件提供了需求规格说明书所描述的功能，在测试环境中运行稳定、操作简便，通过软件产品登记测试。

覆盖从应用搭建到业务协作的主要环节​

本次测试覆盖了平台的应用配置、数据管理、流程协作和输出分析等功能。以下按企业使用场景归纳报告中的测试内容：

• 组织与日常管理：登录、个人中心、首页仪表盘，以及用户、部门、租户、日志、字典、文件、参数、终端、密钥和令牌等管理功能。
• 应用与表单搭建：应用管理、菜单管理、表单设计器、表单设置，以及基础、业务、子表单、容器、图表和布局等组件配置。
• 数据浏览与处理：表单视图管理、筛选、排序、字段隐藏、字段顺序、数据权限，以及导入导出、批量修改和批量删除。
• 流程与协作：工作流分组、设计、节点、触发器、变量、多版本控制、执行实例，以及待办任务和消息通知。
• 打印与分析展示：表单打印、套打、标签设计器、数据绑定、模板导入导出，以及 BI 仪表盘、图表查询、全局筛选和预览展示。
• 接入与界面配置：AccessKey 开放授权、企业及应用配置、主题设置和国际化相关功能。

这些检测内容对应企业从配置应用、采集数据到处理审批、输出结果的常见工作链路，为平台选型与项目交付提供了可核对的功能参考。

关注易用性与中文使用体验​

除功能性测试外，报告还检查了消息与结果是否易于理解、输入与输出是否清晰，以及严重后果操作是否提供明显警告和确认。

中文特性测试涉及中文界面、信息提示和帮助内容的使用习惯，以及 GB18030-2022 编码支持。相关项目在本次报告中的结果为“通过”。

如何理解这份报告​

CMA 是检验检测机构资质认定标志。本次取得的是带有 CMA 标识的软件产品登记测试报告，其结论针对报告列明的送检样品、测试范围和测试环境；不将其扩大表述为产品获得了独立的“CMA 产品认证证书”。

报告中的 V1.0 是受检样品版本名称，与本站按研发历史整理的 v0.1～v0.9 阶段编号不作自动对应，也不据此认定本站手册已切换到另一产品版本。实际项目仍需按所部署版本、开放模块、权限和业务配置进行验收。

本文新闻发布日期为 2026 年 10 月 27 日，检测与报告日期以上表为准。报告资料查阅可通过组织的正式商务渠道联系，提供方式遵循报告使用要求。

了解平台与开始使用​

• 产品使用手册：从登录、工作表到流程协作，按任务查找操作说明。
• 组织与角色权限：了解用户、角色、功能授权和数据范围的关系。
• API 文档：了解系统接入、认证签名和数据接口。
• 在线体验：使用组织提供的账号与权限体验实际功能。

想处理一批记录，却先忙着翻了好几页​

月底需要导出一段时间内的事项，筛选结果已经出来，却分布在多页列表中。用户一页页勾选，翻到最后还要重新确认：前面的选择是否保留，有没有漏掉某一页，这次操作究竟包含了多少条？

记录一多，重复选择就容易打断工作。更麻烦的是，当前页全选与全部结果全选看起来相近，实际范围却可能相差很多。批量操作能否省事，取决于选择过程是否清楚、执行前能否确认目标。

DuogeX v0.9 改进筛选结果的跨页全选与批量操作确认，并完善列表导出的分批查询和后台 Excel 生成，让批量处理更贴近日常工作中的真实规模。

选择不再围着页码转，而是围着业务范围走​

先筛选出本次需要的记录，再决定处理当前页还是全部符合条件的结果。用户的关注点可以从“还剩几页没勾选”，回到“这是不是本次业务需要的范围”。

跨页选择并不意味着可以忽略筛选。相反，选择覆盖的记录越多，越需要在前面把条件设置准确。日期范围、状态、业务类别等条件应根据应用实际字段核对，避免把无关记录一起纳入操作。

执行前的确认也很重要。对于批量修改或删除，确认对象与数量有助于及时发现范围错误；对于导出，则还需要检查输出字段和顺序。同一批目标可以用于不同操作，但每种操作的影响并不相同。

业务结构示意，帮助理解本篇场景。

当前页全选与全部结果全选分别提供，操作前核对范围。界面取自当前演示环境。

一次月度导出，可以怎样做得更清楚​

假设需要输出本月某类事项。先设置相应筛选与排序，查看列表中的代表性记录，确认日期、类型等信息符合预期。如果结果为空或数量明显异常，应先检查筛选与权限，而不是直接继续导出。

确认范围后，根据实际入口选择当前页或全部筛选结果。这里要特别看清界面提示：当前页只包含眼前这一页，全部结果则可能跨越多个页面。不要把菜单里的两个选项当作同一件事。

接下来检查导出字段。接收方需要哪些信息，字段顺序如何安排，是否含有不应外发的内容，都应在生成之前确定。把这些信息说明白，往往比导出后再删列整理更容易保持交付一致。

任务发起之后，继续查看实际处理状态。后台生成让输出过程能够分步处理，但发起成功不等于文件已经生成。收到结果后打开实际文件，核对字段、记录数量和关键业务值，才算完成这次交付。

批量范围越大，核对就越要靠前​

跨页批量能力仍遵循当前账号的权限、应用配置和部署限额。某个操作入口没有开放，不应通过临时扩大账号权限来代替问题检查。对于结果不明确或部分失败的任务，也需要先确认已经完成的范围，再处理剩余部分。

修改和删除与导出还存在不同风险。执行前应先确认目标，必要时做好保留或恢复安排；请求超时不能简单理解为没有执行，更不能不核对就整批重复提交。

v0.9 希望减少的是逐页重复选择的负担，同时让范围确认更靠近业务目标。筛选准确、选择清楚、结果可核对，批量操作才能真正帮助用户把时间放回需要处理的工作上。

本文回顾 v0.9 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：批量与输出、工作表与数据。

查看更新日志对应阶段，了解该阶段的其他变化。

对方只需要看结果，为什么要收到整套材料​

项目协作中，经常需要把一项结果交给组织外的人：让合作方查看一份汇总，让相关人员了解某条记录，或者围绕指定内容做一次核对。对方需要的是这次协作相关的信息，而不一定需要进入整个内部应用。

发文件很直接，但文件会形成新的副本；发截图方便，却不适合阅读更多内容；另建内部账号则需要额外考虑授权和后续维护。选择怎样交付信息，本身就是协作的一部分。

DuogeX v0.8 建设受控分享能力，增加分享策略、目标处理、审计和外发链接处理，让资源交付可以围绕明确的访问范围与条件展开。

把“分享什么”和“允许怎样访问”一起考虑​

分享之前，先明确目标资源。接收方需要查看一条业务记录、某个视图结果，还是一份已开放的汇总？资源不同，允许展示的内容和访问方式也可能不同，不能只因为都有一个链接，就认为权限范围相同。

在目标资源支持的设置中，分享者再核对密码、有效期等访问条件。设置的目的不是增加操作步骤，而是让这次外部阅读有一个可说明的范围。链接交付之后，接收方按照该分享要求进入，读取允许开放的内容。

分享也不等于开放整个应用。接收方知道某个资源的分享链接，不会因此获得该组织其他记录或管理功能的访问权。对于包含敏感信息的业务，选择资源和检查实际可见字段，应先于发送链接。

业务结构示意，帮助理解本篇场景。

带密码的分享入口，接收方先验证再阅读开放内容。界面取自当前演示环境。

发出链接之前，先当一次接收方​

以一份允许外部阅读的汇总结果为例，有权人员首先核对结果本身：统计口径是否正确，当前内容是否适合对外提供，是否包含本次协作以外的信息。只有源内容适合交付，访问设置才有意义。

接着配置分享所需条件，并以接收方身份打开链接。有密码时，检查验证入口与验证后的页面；打开后，再确认可见资源与预期一致。用管理员已经登录的窗口看到结果，不能替代接收方身份的实际检查。

确认无误后交付链接，并把必要的访问说明一并告知对方，例如需要密码、在什么时间范围内使用，以及遇到访问问题应联系谁。协作结束后，如果不再需要持续阅读，可以按实际管理要求撤销分享。

撤销针对的是后续访问，无法收回接收方已经下载、截图或另行保存的内容。因此，是否可以交付这些信息，仍应在分享之前做出判断，不能把撤销能力当作已经外发内容的回收保证。

阅读结果和收集数据，需要不同的信任判断​

匿名读取与匿名 WRITE 提交是不同能力。READ 分享不能通过更换调用地址就写入记录；WRITE 分享也只在允许的范围内追加数据，仍受令牌、状态、次数和字段等规则约束。

尤其需要注意，匿名提交表示有人提供了一份内容，不自动证明业务事实真实。公开反馈、线索收集可以按低信任输入设计；涉及订单、支付或账号等信息时，接入方需要另行进行业务校验。

v0.8 的受控分享，让外部协作有了更合适的资源入口。把接收方真正需要的结果交出去，并清楚说明访问范围，比一次性发送过多材料更容易管理后续协作。

本文回顾 v0.8 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：分享与外部访问、匿名调用。

查看更新日志对应阶段，了解该阶段的其他变化。

设备已经发出信息，业务为什么还在等人登记​

设备侧发生了事件，信息能够在自己的系统里显示，业务人员却还需要把内容抄进登记表，再通知相关同事处理。设备和业务之间缺少连接时，数据虽然已经产生，后续工作仍依赖人工转述。

在这样的场景里，问题不仅是“能不能收到一条消息”。还需要知道消息来自哪台设备、代表什么事件、对应哪些业务字段，以及后续应该怎样进入应用。缺少这些上下文，收到更多数据也不一定能帮助工作推进。

DuogeX v0.7 推进 IoT 产品、设备、事件、命令队列、会话和 TCP 通信协议处理，为设备信息进入业务应用建立连接基础。

把设备连接和业务处理分开设计，再接起来​

设备侧首先需要解决连接问题：设备身份是否明确，协议是否匹配，会话和通信是否按预期工作。业务侧则需要明确数据的用途：哪些信息值得保存，怎样表达事件，成员从哪里查看和跟进。

这两部分相关，但不能相互替代。设备能够连接，并不等于应用已经建立完整的业务处理路径；应用有一张登记表，也不意味着它能直接理解任意设备上传的数据。接入需要围绕具体协议与业务模型进行配置。

v0.7 的相关建设，是为这些环节提供基础能力。对于普通业务人员，理想的使用方式是在已配置的业务入口中读取相关记录和状态，而不必在日常处理中逐条理解底层通信报文。

业务结构示意，帮助理解本篇场景。

用设备事件登记，说明一条可实施的接入路径​

假设团队希望把某类设备事件作为后续处理的依据。开始之前，维护人员先确认目标设备、协议、事件含义及必要字段。例如，设备标识用来定位来源，事件类型说明发生了什么，时间信息帮助判断前后顺序。

接着，应用建设者根据业务目的安排记录结构与查看入口。不是设备提供的所有字段都必须展示给每位成员；面向处理人员的页面，应保留足以识别事件、理解内容和执行下一步的信息。

接入验证也应按层次进行：先确认连接和事件接收，再检查字段对应关系，最后让业务人员核对记录是否容易理解、后续处理是否符合工作安排。只有最后一环也清楚了，设备数据才真正进入了业务使用过程。

如果需要进一步联动通知或流程，还要另外设计触发条件、处理人及失败后的处理方式。这是具体应用的接入工作，不能仅凭平台具有设备连接能力，就宣称所有设备接入后都会自动完成审批或处置。

从“收得到”走向“用得上”，需要双方共同确认​

设备接入是需要部署、模块与专业配置支持的扩展能力。支持哪些设备、协议、事件与命令，以及当前环境开放到什么范围，应由维护人员确认。设备权限、业务记录权限和自动化工具权限也应分别管理。

对希望连接现场信息与管理应用的团队，v0.7 提供了进一步建设的基础。先选择一类明确事件，把来源、字段和处理目标说清楚，再逐步扩展接入范围，比一次连接大量设备却没有使用路径更容易形成可交付的结果。

本文回顾 v0.7 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：岗位与专题应用、版本与限制。

查看更新日志对应阶段，了解该阶段的其他变化。

信息已经录进系统，交付前为何还要重做一遍​

业务单据在应用里填写完成，交付时却又需要复制到文档，调整图片位置，检查分页，再另存为对方需要的格式。原本已经录入过的信息，在输出环节被重新整理了一次。

只处理一份时，这种做法还能应付。遇到多条记录、固定版式或反复交付，手工转抄就容易遗漏字段，模板也可能因为每次调整而逐渐不一致。用户真正需要的是，让已维护好的业务内容更自然地进入交付材料。

DuogeX v0.6 持续完善打印与文件输出，围绕表单打印、Word／PDF 转换、文件类型及图片渲染进行改进，让数据到文件之间的路径更完整。

让模板负责版式，让记录提供内容​

配置好的模板负责安排文字、图片和其他业务内容的展示位置。成员使用时，先选择正确的业务记录与可用模板，再预览输出效果。信息来源仍是业务记录，而不是再手工录入一遍。

这一阶段同时改进批量打印错误返回，并处理复杂图片留白等问题。用户在日常使用中关心的往往就是这些细节：哪些记录没有生成，图片有没有完整呈现，较长的内容是否被截断，最终文件是否能正常打开。

标签输出也在这一时期持续扩展。标签与普通文档的版式目标不同，需要关注纸张尺寸、方向、条码或数据绑定等配置。它们共享“把业务信息变成可用材料”的目标，但不能把一种模板的预览结果当作所有输出格式都已验证。

业务结构示意，帮助理解本篇场景。

标签输出示例：预览记录并查看生成结果，具体文档输出以对应模板为准。界面取自当前演示环境。

从代表性记录开始，避免整批生成后再返工​

准备输出时，先确认要交付哪些记录，以及使用哪一份模板。对于同一类业务，可以选择内容较完整的一条先预览；如果记录中有长文本或多张图片，再挑出这些特殊情况单独检查。

预览时不只看页面是否好看，还要逐项核对业务字段：名称是否来自目标记录，图片是否对应，文字是否有遗漏，分页是否影响阅读。模板里某个字段没有内容，有时是记录本身为空，有时则需要维护人员检查数据绑定。

确认典型情况后再执行批量输出，并按返回提示检查成功、失败或仍在处理的项目。任务已发起，不等于所有文件已经生成；页面上看到预览，也不等于最终 Word 或 PDF 文件一定具有相同效果。

因此，最后应打开实际下载的文件检查。尤其在字体、图片或转换环境发生变化后，这一步很有必要。业务交付关心的是接收方最终读到什么，而不只是系统里某个按钮是否被成功点击。

把输出检查变成交付的一部分​

模板与运行环境需要配套维护。涉及复杂版式时，升级前后都应保留一组代表性记录核对，避免把正常输出当作永远不变的默认结果。输出文件包含哪些字段、可以交给谁，也应按实际业务权限和交付要求检查。

v0.6 的打印与输出完善，希望减少的是信息已经齐备之后的重复整理。让成员把精力留在内容准确与交付核对上，而不是一遍遍从列表复制、粘贴、重新排版。

本文回顾 v0.6 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：打印与文件输出、批量与输出。

查看更新日志对应阶段，了解该阶段的其他变化。

团队扩大后，账号名单已经不够用了​

最初只有几个人使用应用，大家知道彼此负责什么。团队扩大之后，成员分属不同公司、部门和岗位，管理者既希望协作方便，也希望业务信息只在合适的范围内被查看和处理。

这时，一份账号名单很难说明全部关系：同事属于哪个部门，岗位承担什么职责，负责人需要查看哪个范围的数据，临时调岗后原来的权限还在不在？这些问题如果依赖逐个记忆，组织调整就容易留下遗漏。

DuogeX v0.5 重点完善公司归属、部门管理范围和业务协作细节，让组织结构与职责授权能够更完整地结合起来。

公司、部门、岗位和角色，分别说明什么​

公司与部门用于表达组织归属和管理结构；岗位帮助描述成员承担的职责；角色用于组织相应的功能与业务授权。它们彼此关联，却不应该被当成同一个设置。

这一阶段增加所属总公司、直属公司等信息，补充部门管理机构属性，并调整部门及下级部门查询范围、角色和岗位的部门过滤。对管理人员来说，这些能力有助于在维护人员和组织时，使用更贴近实际分工的结构。

举例来说，负责某部门事项的成员，与需要跨部门核对资料的负责人，可能使用同一套应用，却不一定拥有同样的数据范围。管理员需要把这种职责差异落到具体配置中，再用不同身份验证实际效果。

业务结构示意，帮助理解本篇场景。

新成员加入，别只完成“创建账号”​

一次完整的入职配置，可以从成员的组织归属开始：账号信息是否正确，所属部门和岗位是否符合工作安排。接着，根据职责分配必要角色，确认需要进入哪些应用、使用哪些菜单和业务动作。

最后一步应当回到成员的实际身份。能否看到应有的入口，能否查到职责范围内的记录，是否可以执行需要的新增、修改或审批动作？这些结果比管理员页面中勾选了多少项更能说明配置是否合适。

对于需要保护的信息，还应进一步核对字段和记录范围。看得到应用入口，不代表有权查看所有记录；能阅读记录，也不代表有权导出、修改或删除。不同层次的授权应按实际业务要求检查，避免一次性给出过大的权限。

成员调岗时，同样需要反向检查：新增职责对应的权限是否已经授予，旧职责相关的访问是否仍然保留，正在处理的待办如何交接。组织字段更新完成，并不意味着整个协作关系已经自动调整完毕。

组织结构要准确，也要能持续维护​

组织管理不是一次性录入。部门名称变化、人员转岗、角色职责调整，都可能影响日常使用。每次变更后，选择典型账号核对菜单、记录和操作，有助于及时发现配置与实际工作之间的偏差。

对普通成员来说，清楚的组织与权限意味着更少遇到无关信息，也更容易找到自己的业务入口。对负责人来说，则是管理范围能够被表达和检查，而不是依赖一个权限过大的共享账号完成所有工作。

v0.5 的组织协作改进，为这种有分工、有边界的使用方式补齐基础。职责先说清，再分配访问和操作，让应用能够随着团队成长持续使用。

本文回顾 v0.5 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：部门与岗位、用户账号、角色与权限。

查看更新日志对应阶段，了解该阶段的其他变化。

提交了申请，为什么还要到处问进度​

申请材料填好了，消息也发出去了，但接下来轮到谁处理、对方有没有看到、最后结果是什么，仍需要逐个询问。业务最容易停顿的地方，往往就在“我已经交出去了”和“下一位知道该做什么”之间。

靠聊天提醒能解决一次催办，却很难成为长期的协作规则。申请数量增加、处理人变化、不同条件走不同路径时，发起人和审批人都需要一个更清楚的工作入口。

DuogeX v0.4 围绕审批协作与业务交互持续改进，完善审批人、条件组、动态条件和流程变量，并调整审批节点、待办中心及节点回显，让表单中的信息能够接上下一步业务动作。

让业务规则落在流程里，让个人任务落在待办里​

一条流程可以表达申请需要经过哪些环节、由谁处理，以及不同条件下怎样流转。这些规则由应用事先配置，普通成员使用开放的申请入口提交内容，处理人在待办中找到属于自己的任务。

对于发起人，重点是提交后能够查到对应申请并跟进进度；对于审批人，重点是清楚看到当前需要处理的事项、相关业务内容与允许执行的动作。流程和待办分别承担不同职责，不能只检查任务数量而忽略业务记录本身。

实际使用中还会遇到抄送和已办。收到抄送，通常意味着需要阅读知会内容；已处理的任务则用于回看意见和结果。区分这些入口，有助于减少“收到消息就以为已审批”“打开任务就以为已处理”的误解。

业务结构示意，帮助理解本篇场景。

待办入口展示查询条件与任务列；当前演示列表为空。界面取自当前演示环境。

以一项申请为线索，看完提交、处理与回查​

假设应用已经配置好一项业务申请。发起人在开放入口填写必要内容与附件，核对页面要求的处理人信息，再执行提交。收到明确结果后，到“我发起”查询这项申请，检查名称、时间及进度是否符合预期。

处理人进入待办时，先确认应用范围和任务上下文，再阅读业务内容。需要补充材料或执行其他动作时，应按应用已经提供的操作处理。不能只看到熟悉的申请名称，就忽略当前节点、发起人及相关附件。

完成审批后，处理人可以到已办中回看；发起人则继续核对流程进度和最终业务状态。某项任务从待办消失，只能说明该入口的状态发生了变化，不能单独证明整条业务已经按预期完成。

顶部审批通知也可以帮助用户找到任务入口，但通知不是待办总账。读过通知不等于执行了审批，没有通知也不能直接推断没有待办。需要集中处理工作时，仍应进入对应任务列表查询。

真正减少催问，需要把交接规则一起确定​

流程启用前，应由相关人员走完一条有代表性的申请：发起人能否提交，处理人能否看到，处理后业务状态是否正确。分支、退回、人员调整和批量提交等情况，也应结合实际设计分别核对。

特别是人员变化时，组织归属、角色权限和待办交接需要一起考虑。系统可以承载处理路径，具体由谁接手、哪些事项需要重新安排，仍需要组织明确。

v0.4 所推进的审批协作，是让“下一步由谁做”更容易被看见。申请不必停留在一条聊天消息里，处理人也能围绕自己的任务入口安排工作，让业务交接逐渐形成可跟进的顺序。

本文回顾 v0.4 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：流程与待办、场景教程。

查看更新日志对应阶段，了解该阶段的其他变化。

一张申请单，常常装不下完整业务​

不少业务天生就包含层次：一张申请有多条明细，一次服务对应一份基础资料，一个事项还需要关联之前建立的业务记录。如果只能在一个长文本里把所有内容写完，后续核对、修改和汇总都会变得困难。

更常见的做法是把相关信息抄过来：复制一个名称，补上一段说明，再把明细放到附件里。短期能交付，长期却容易出现同名资料、多份内容和无法确认对应关系的问题。用户看到的信息“像是相关的”，系统却未必保存了真正的业务关系。

DuogeX v0.3 持续完善子表、表格表单和关联表单处理，改进关联选择、编辑回显及阅读模式，让相关信息可以按业务结构一起维护。

用结构表达关系，减少反复转抄​

主记录负责表达一项业务的整体情况，明细承载其中的多条具体内容；关联字段则用于选择已经存在的其他记录。三者解决的问题不同，但可以共同帮助用户把一件事说完整。

以业务申请为例，申请名称和整体说明可以放在主记录中，具体申请项目放在多条明细里。需要引用已有资料时，通过应用配置的关联入口选择目标。这样，阅读者可以沿着应用设计的结构理解内容，而不必在长篇说明中猜测每段信息属于哪一项。

这里的关键不是让页面容纳更多字段，而是把信息的归属说明白。修改主记录时，用户能够检查对应明细；重新打开申请时，关联内容与编辑回显也应与保存结果一致。v0.3 的相关改进，正是围绕这些日常填写和阅读环节展开。

业务结构示意，帮助理解本篇场景。

从选择资料到核对明细，把一件事填完整​

开始录入之前，先确认哪些内容应直接填写，哪些内容应从已有资料中选择。假设某项申请需要引用一条基础资料，成员应使用对应的关联选择入口，核对名称及必要信息后再确认，而不是只在普通文本框中输入相同名称。

添加明细时，每一行都需要有清楚的业务含义。遇到相似条目，应该检查是否确实代表不同内容，避免为了赶进度重复添加。填写结束后，除了检查主记录的名称与说明，也要逐条检查明细是否完整、关联对象是否正确。

保存后再打开，是很重要的一次核对。填写窗口中的临时内容，不等于已经形成最终记录；阅读模式里能否看到正确的明细、再次编辑时是否保持原值，才是用户判断结果是否可靠的重要依据。

后续需要调整资料时，先确认修改对象是当前记录中的内容、某条明细，还是被关联的基础记录。不同应用对关联内容的展示与更新方式可能不同，不能因为两个页面出现了同一个名称，就推断修改其中一处一定会同步改变所有内容。

业务关系越清楚，后续交接越容易​

关联选择仍受实际数据权限影响。某位成员没有看到某条资料，可能需要管理员核对其访问范围，而不是临时复制资料绕过选择入口。主子结构发生调整后，也应一起检查新增、编辑、删除和回显，避免只验证新增能成功。

对普通用户而言，关联数据最直接的价值，是少做一次转抄、少猜一次对应关系，让完整的业务背景随着记录一起被阅读。对应用建设者而言，则需要先把这些关系配置清楚，再交给成员按同一条路径填写与维护。

本文回顾 v0.3 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：填写表单与附件、工作表与数据。

查看更新日志对应阶段，了解该阶段的其他变化。

记录越来越多，最费时间的却是“找”​

一张列表最初只有十几条记录，大家从上往下看就能找到目标。几个月后，新的事项不断进入，已处理和未处理内容混在一起，同事每天打开应用，第一件事变成了翻页、查找，再重新确认哪些内容需要关注。

同一份业务数据，不同岗位的阅读目的也不同。跟进人员关心手头事项，负责人希望掌握某个范围内的变化，核对资料的同事则需要查看具体字段。如果每个人都从同一张完整清单重新找起，列表就很难成为高效的工作入口。

DuogeX v0.2 持续完善视图查询，围绕分页、记录详情、快速筛选、排序和字段配置，让用户把注意力放到当前任务需要的信息上。

一份业务数据，可以有不同的阅读方式​

视图不是再复制一份数据，而是围绕阅读目的组织展示。列表保留哪些字段、按什么顺序阅读、通过哪些条件缩小范围，可以结合应用的实际配置来安排。用户不必每次都从全部信息中重新建立自己的阅读顺序。

分页让长列表能够分段浏览；筛选帮助用户找到符合条件的记录；排序则决定应该先看什么。需要进一步核对时，从列表进入详情，补足一行摘要无法容纳的业务背景。这些能力组合在一起，才形成从概览到具体记录的阅读路径。

例如，事项跟进人员可以先按已有状态字段缩小范围，再按照业务中配置的日期字段排序。需要确认内容时打开详情，处理完后继续查看列表中的下一项。具体可用条件、字段与入口，以应用已配置的视图为准。

业务结构示意，帮助理解本篇场景。

按名称筛选后的事项列表，阅读范围收窄到匹配记录。界面取自当前演示环境。

筛选之前，先想清楚这次要回答什么​

一个实用的筛选条件，应该对应一个明确问题：这次是找某个名称的记录，核对某段时间内的事项，还是检查某一类状态？目标越明确，越容易发现条件是否选错，也越容易解释查询结果。

设置条件后，不妨先检查一条符合条件的记录，再留意是否存在原本预期应该出现、实际却没有出现的内容。查询为空，可能是条件过窄，也可能是当前账号没有相应数据范围。清除或重置条件后再次检查，有助于区分“没有记录”和“当前查不到”。

排序同样需要结合业务理解。日期先后、名称顺序和处理优先级并不是一回事。查看多页数据时，保持相同的筛选和排序口径，能减少前后比较时的困惑；如果记录还在持续变化，列表结果也可能随之更新。

成员使用某个视图形成固定工作习惯后，管理员再调整字段或默认视图时，也应关注原来的操作路径是否受到影响。界面更整齐只是其中一部分，更关键的是常用信息能否在合适的位置被找到。

看得清楚，也要守住访问边界​

视图表达的是展示方式，权限决定的是可以访问什么。隐藏一个视图、移走一个菜单，并不等于撤销用户对业务记录的访问权。需要控制数据范围时，应核对角色、记录和字段相关设置。

对于团队而言，视图的价值不只是少翻几页，而是让每天重复发生的“找记录”变成一条可以复用的路径。把一份数据按工作目标组织好，成员才更容易从浏览进入真正的业务处理。

本文回顾 v0.2 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：视图与仪表盘、工作表与数据。

查看更新日志对应阶段，了解该阶段的其他变化。

一项业务，为什么会出现好几份“最新表格”​

周一收到一份事项清单，周三同事补了几条，周五汇总时又发现另一个文件里的状态才是最新的。大家都在认真记录，信息却分散在各自手里。查找一条事项，往往要先查聊天记录，再问一句：“你那边还有没有更新？”

表格本身并没有问题。问题在于，当多人持续维护同一项业务时，文件副本很难自然成为一个共同的工作入口。字段名称、填写方式、更新位置都可能不同，最终总要有人把这些差异重新整理一遍。

DuogeX v0.1 从这个基础问题出发，建设应用、表单和记录管理能力：让一项业务有自己的入口，让信息按同一套字段填写，让后续查询和修改围绕同一条记录进行。

从“发给我一份”，走向“到这里维护”​

应用可以围绕一项具体工作组织入口，例如工作事项登记。表单负责说明要填什么，业务记录承载每次填写的内容。成员需要更新信息时，找到目标记录再维护，而不必另存一个文件交给下一位同事。

这看起来只是把填写位置集中起来，却改变了团队协作的起点：讨论一件事时，可以围绕同一条记录核对内容。名称、说明等基础信息先有了统一结构，后续才有条件继续建设筛选、审批与汇总。

这一阶段的重点是建立能持续使用的数据底座。应用创建、字段组件、记录新增、查询、修改和删除，都是让业务从零散材料走向统一维护的必要环节。开始时不用追求把所有部门的工作一次装进去，先让一项业务顺畅运转更有价值。

业务结构示意，帮助理解本篇场景。

新增事项时，名称、说明和状态集中在同一张表单里。界面取自当前演示环境。

从工作事项登记开始，跑完一个小闭环​

以工作事项为例，先确认成员共同需要的信息：事项名称用来识别工作，说明用于补充背景，已有的状态字段用于表达处理情况。字段不是越多越好，真正需要持续填写、查询和交接的内容，才值得进入第一张表单。

应用配置完成后，成员从统一入口新建事项，填写内容并保存。再回到列表找到刚才的记录，打开详情核对名称和说明。这一步能确认“填进去了”，也能帮助团队发现字段是否容易理解、哪些内容需要补充说明。

下一次事项发生变化时，成员继续维护已有记录。负责人检查的也不再是“谁发了哪个版本的文件”，而是这条业务记录现在表达了什么。对于需要长期跟踪的事项，这种连续维护比一次性收集更接近真实工作。

开始使用时，可以先安排少量演示记录，分别体验新增、查找、修改和删除。把录入习惯、字段名称和管理责任确认清楚，再扩展到更多成员，能减少应用上线后反复调整的负担。

先建立共同入口，再逐步增加协作能力​

统一入口的价值，需要成员共同使用才能体现。谁负责填写、什么情况下更新、由谁检查内容，应和表单一起确定。系统提供记录管理能力，业务内容是否及时、是否准确，仍依赖团队的工作约定。

不同成员的可见范围和可用操作也应分别核对。账号能登录，不等于可以维护全部记录；能查看列表，也不等于可以删除数据。初次使用时，最好用实际业务账号走完操作，而不只检查管理员能否完成。

v0.1 建立的是后续演进的起点。对于希望摆脱多份清单反复汇总的团队，可以从一张表单、一项具体业务开始，让“去哪里找、在哪里改”先有一个共同答案。

本文回顾 v0.1 的核心能力，操作入口参见当前手册；实际功能以部署版本、配置与权限为准。

操作说明：快速开始、填写表单与附件。

查看更新日志对应阶段，了解该阶段的其他变化。