I'm unclear exactly what you're asking for here - is it that you want the DB links in PROD to only point to other production databases, the DB links in test to only point to other test databases, etc.?

If so creating synonyms is one method - though I think it's better to use private synonyms only created in the users that need them.

A similar approach is to create views to "hide" the link, e.g.:

create view <some_table_name> as
  select * from <remote_table_name>@<remote_prod_link>;

create view <some_table_name> as
  select * from <remote_table_name>@<remote_sit_link>;

The challenge with this is you're changing the DDL between each environment to use a different link. This increases the chance of mistakes 0 e.g. deploying synonyms/views to prod that still use the test links.

To avoid this you can use a database link with the same name in all environments and change its definition in each database:

-- in TEST
create database link db_link 
  using 'test_db_string';
  
-- in PROD
create database link db_link 
  using 'prod_db_string';

Then all code in all environments uses

select ... from <remote_table_name>@db_link

The connect string must be a literal, so you can't bind this. This means the risk of deploying a link with the wrong definition is still possible!

Personally, I prefer using links with the same name in all environments. These change less often so there's less risk of pointing to the wrong database.

Ultimately you'll have to take care to ensure all links point to the right place. It's a good idea to put further protections in place to ensure links don't accidentally point to the wrong place. For example, ensure the firewall closes SQL*Net access between the production and test databases.