• 简体中文

      • 向 AI 描述业务权限

      不用先学习 API。向 AI 说明业务事实，并要求它使用当前应用的权限开发 Skill。对于没有说清楚的访问边界，先补充业务决定，再生成授权。

      可直接改写的需求模板

      请在当前 NocoBase 3 应用中开发销售权限，读取通用 App 开发 Skill，并使用已安装的 nocobase-app-plugin-authorization Skill；涉及默认范围、共享或限制时读取对应 Skill。

岗位：销售助理只读；销售工程师编制报价；项目经理维护自己负责的项目；交付专员安排订单交付。
页面：助理和工程师进入项目/报价；交付专员只进入订单。页面访问与业务操作分开配置。
报价：工程师可以查看非保密参考报价，只能编辑本人编制报价的金额和备注。提交还要求项目属于其负责区域；跨区域的本人草稿可编辑但不可提交。
协作：提案团队可接手指定报价，编辑和提交都需要授权；提交要同时校验报价及其真实父项目。共享不授予缺少的岗位操作。
限制：保密记录不能因共享而重新开放。请说明限制覆盖哪些操作，是否需要集合级约束。
关系：交付专员可关联有效团队、维护检查项和协作备注，不能直接修改团队资料、归属外键或内部备注。
继承：用户可同时有个人岗位和团队岗位，移除团队来源后保留个人职责。
管理：仅指定管理员可调整权限集分配和规则。
验收：准备不同用户与归属/区域/保密记录，验证允许、拒绝、直接 API 请求、关系操作回滚及撤销后的行为；不要用超级管理员代替普通用户验证。

      让 AI 交付什么

      要求先给出岗位 × 页面 × 操作 × 数据范围的表格，并标出缺失的业务决定。实现后说明哪些规则可在设置中调整，哪些字段或关系能力由代码定义，以及新增操作需要怎样接入。

      要求后端真正应用数据范围和字段限制，不只是隐藏按钮。对审批、提交、交付等操作，还需要业务状态校验和事务。初始化权限只能建立缺失配置，不应每次启动覆盖管理员调整。

      如果当前应用没有需要的插件、范围策略或团队成员模型，让 AI 明确指出并补齐相应开发工作。参考权限示例插件的岗位和交接设计，不要把演示账号、固定记录 ID 和练习重置功能复制到正式系统。

      已有系统调整的表达方式

      不要只说“给经理更多权限”。可以说：“让经理查看本区域报价，但保持金额只能由编制人编辑；允许经理提交其负责项目的报价，并保留保密限制。现有成员和其他权限分配不能被重置。”这样的描述能明确新增能力与必须保留的边界。