workspace.deploypages.com/team/members
团队成员
管理工作区访问权和项目责任
A
Admin User
admin@company.com
D
Developer Dave
dave@company.com
V
Viewer Vicky
vicky@company.com
从上传文件到有人负责的发布
静态网站仍然需要所有权、审核、域名变更、回滚决策和清楚的正式环境路径。
1. 开启变更
构建者上传新版本、导出 AI 生成的网站，或把框架 build 发布到工作区。
2. 创建预览
在域名或正式环境状态改变前，团队先取得可审核的静态版本。
3. 一起审核
设计、产品、客户相关人员和工程看到同一个可部署状态，而不是不同 ZIP。
4. 有意识地推进
发布版本看起来正确时，团队能用更清楚的所有权把项目往前推。
避免上线失控的控制项
依角色访问
让部署、域名、账单、删除和工作区设置符合真正应该控制它们的人。
审计可见度
团队能看到改了什么、碰了哪个项目、谁触发发布动作，才比较容易做正确判断。
发布协调
共享工作区能减少预览、域名、版本、回滚和正式环境状态之间的交接混乱。
工作区控制何时变得有价值
价值不在托管工具里聊天，而在于知道谁拥有项目、谁能改正式环境、哪个版本可以推进。
接案与客户工作
把客户预览、正式域名、回滚决策和项目所有权留在工作区，而不是散在个人账号中。
营销与成长上线
让非工程团队有受控路径审核活动页、连接已批准域名，并在上线需要恢复时快速处理。
AI 生成的网站交接
把 AI 导出变成真实团队能认领、审核、更新、保护并接上正式域名的受管理项目。
域名与发布所有权
让自定义域名、正式上线推进、删除和回滚这类高影响动作绑定工作区角色，而不是谁有链接谁就能处理。
常见问题
Q: 什么时候需要共享工作区？
当不只一个人能影响正式环境时就需要：部署、自定义域名、删除、账单、回滚和发布所有权都需要更清楚的边界。
Q: 项目能在个人和团队所有权之间移动吗？
这是静态网站很合理的模型：一开始是个人预览，之后变成客户、公司或团队拥有的项目。
Q: 静态平台为什么也需要访问控制？
静态发布同样有高影响动作：域名、账单、删除、回滚和正式环境发布。团队仍需要清楚责任边界。
从每个静态网站原本就有的部分开始
上传构建好的文件，取得 HTTPS 链接，等项目需要时再加入域名、回滚、访问分析、自动化和团队控制。