可以。只要您的应用描述中要求登录，系统便会自动生成真实的账户管理功能，而非仅提供一个全团队共用的单一密码：管理员可创建其他账户，为其指定用户角色或只读角色，每位账户均拥有独立登录名。账户在「设置」页面创建，系统会生成一次性临时密码，用户首次登录时必须立即更换。
「多个用户」的实际含义
需要登录的生成型应用程序默认支持三种明确角色：管理员、编辑者和只读用户。管理员除使用应用外，还负责账户管理；用户可像管理员一样创建、修改和删除数据，但无权管理账户；只读用户仅能查看内容，无法创建、修改或删除任何数据。每位成员均使用专属用户名登录——并非整个团队共享同一密码，因此所有操作均可精准追溯至执行人。
该功能无需单独开启：只要您的项目描述中隐含登录需求（例如限定团队内部访问，而非面向公众的开放页面），账户管理系统便会自动包含在生成结果中。
账户如何创建
管理员在「设置」页面输入用户名，选择角色（编辑者或只读用户），点击确认后，系统将生成一次性临时密码并仅显示一次——此后该密码既不可被管理员查看，也无法被任何人再次获取。用户需凭此密码首次登录，并在登录过程中强制更换为自己的密码。
账户可被停用——停用操作分两步完成（先单击启用停用状态，再单击二次确认），绝不会调用浏览器原生对话框（此类对话框在部分自动化工具下会导致界面冻结）。管理员无法停用自身账户，亦不可停用最后一个处于激活状态的管理员账户，否则将彻底丧失账户管理能力。
只读角色实际限制了哪些操作
该限制不仅作用于界面层。若只读账户尝试执行新增、修改或删除操作——即使绕过前端界面，直接发起API请求——服务器将在任何数据写入发生前拒绝该请求。这并非简单隐藏按钮，而是对每一次调用施加的强制防护，无论请求来源或触发方式如何。
当前不支持的功能
两项明确限制：第一，角色权限为全局性，不支持按实体或模块精细化控制（例如「该账户可见客户信息，但不可见账单模块」）——权限仅分为「可编辑」或「只读」，覆盖整套应用；第二，生成的应用程序暂不支持双因素认证（2FA）：系统通过一次性临时密码及首次登录强制重置机制保障安全，未引入额外验证因子。若您业务确有更细粒度权限或2FA需求，由于代码基于标准、可导出的Next.js与Prisma构建，开发者可在现有基础上便捷扩展相应功能。