NocoBase 2.2 Beta 的变化不只是一组新功能。多工作区、新移动端、新评论区块，以及 AI 知识库和工作流能力的持续增强，都在补齐 V2 的实际使用体验。对已经运行 V2 的团队而言，更关键的信号是新增的 /v/ 分支：它将作为面向 V2 的独立前端入口，承接后续功能演进。
这意味着升级评估不能只看功能清单。访问入口、反向代理、缓存策略、监控指标和回滚路径，也需要进入发布检查表。
多工作区开始改变应用的组织方式
多工作区适合解决同一套系统中存在多组业务上下文的问题。例如，不同部门、项目或客户空间可以拥有相对独立的工作界面，用户不必在一个不断膨胀的导航树中寻找入口。
团队在启用这一能力前，需要先明确几个边界：
- 工作区是按部门、项目还是租户划分。
- 哪些数据需要跨工作区共享，哪些必须隔离。
- 用户切换工作区后，角色和权限是否随之变化。
- 自动化工作流应该绑定单个工作区，还是作为共享能力运行。
摘要没有给出多工作区的具体权限模型，因此不能直接把“工作区”视为安全隔离边界。正式迁移前，应使用普通用户、管理员和跨部门用户分别验证菜单可见性、数据访问范围与操作权限。
移动端与评论区块补上协作链路
新移动端的价值不只是缩小页面。审批、现场录入、任务处理等场景通常发生在手机上，交互密度、表单长度和网络状态都会影响完成率。升级测试应覆盖真实设备，并重点检查长表单、附件上传、弹窗、横竖屏切换和弱网恢复。
新评论区块则让讨论更接近业务记录。团队可以围绕客户、工单、合同或任务保留上下文，而不是把沟通全部散落在外部聊天工具中。
评论也会带来新的治理问题：谁能查看和删除评论，评论是否包含敏感信息，记录被归档后评论如何处理，以及通知是否会造成噪声。将评论用于关键业务前，最好同步制定权限与保留策略。
/v/ 入口为何比普通路由更值得关注
独立的 /v/ 前端入口为 V2 后续演进提供了清晰边界。对运维团队来说，它也提供了分阶段验证的可能：保留当前入口，同时让测试用户或部分流量先访问 /v/，观察错误率、加载性能和关键流程完成情况。
需要注意，摘要并未说明 /v/ 的部署拓扑、资源目录或代理要求。下面是一个可以这样实践的假设示例：假设旧前端运行在 127.0.0.1:13000，V2 前端运行在 127.0.0.1:14000，由 Nginx 统一暴露域名。实际使用时，请替换域名、端口，并以 NocoBase 实际部署文档为准。
upstream nocobase_current {
server 127.0.0.1:13000;
}
upstream nocobase_v2 {
server 127.0.0.1:14000;
}
server {
listen 80;
server_name nocobase.example.com;
location = /v {
return 308 /v/;
}
location /v/ {
proxy_pass http://nocobase_v2;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://nocobase_current;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
配置完成后，可以先检查语法并验证两个入口。把示例域名改成自己的地址：
sudo nginx -t
sudo systemctl reload nginx
curl -I http://nocobase.example.com/
curl -I http://nocobase.example.com/v/
如果实际部署由同一个 NocoBase 服务直接处理 /v/，则不需要拆分两个 upstream。此时更重要的是确认代理没有重写或截断 /v/，并检查静态资源请求、前端路由刷新和登录回跳是否正常。
AI 知识库与工作流要按业务结果验收
本次版本继续提升 AI 知识库和工作流能力，但 Beta 阶段不宜只验证“能否调用”。更有效的测试方式是准备固定数据集和可重复任务：给知识库放入一批已知文档，记录标准问题的答案与引用；给工作流准备成功、失败、超时和重复触发样本。
AI 输出存在不确定性，知识库检索也可能受文档质量影响。涉及合同、财务、人事或外部通知时，应保留人工确认节点，并记录输入、输出、模型配置和工作流执行结果。这样升级前后才能进行可比较的回归测试。
Beta 版本的落地检查表
建议把 2.2 Beta 先部署到预发布环境，不要直接替换生产入口。一次稳妥的评估至少应覆盖：
- 备份数据库、附件、插件配置和环境变量，并实际演练恢复。
- 盘点自定义插件、主题、页面和工作流，确认它们在 V2 入口中的兼容性。
- 分别验证桌面端、移动端以及
/v/深层链接刷新。 - 检查多工作区切换后的权限、数据范围和自动化行为。
- 验证评论的可见性、删除权限、通知与敏感信息处理。
- 使用固定问题集回归 AI 知识库，使用固定事件集回归工作流。
- 为旧入口保留明确的回滚路径，并监控前端错误率、接口失败率和登录异常。
2.2 Beta 展示了 NocoBase V2 的方向：工作空间更清晰，移动协作更完整，AI 与自动化继续深入，而 /v/ 则为这些变化提供独立承载入口。现阶段最合适的采用方式是小范围验证、量化比较和可回滚发布，而不是仅凭新功能数量决定升级。