你提出的需求，恰好卡在 Jenkins 原生权限模型的盲区里。直接回答“怎么配”之前，先要明确一点：这个限制无法靠单个开关完成。下面先说明为什么，再给两条可行的路径，并附上验证方法和常见的坑。

先别急着改配置：这是权限模型边界问题

Jenkins内置的授权体系基于项目（Job）而非单个构建记录。即使启用了项目级矩阵授权策略，用户一旦获得某个项目的读取权限，就能访问该项目下的全部构建历史。因此，若要限制用户只能查看自己的构建，必须先认识到，这属于Jenkins原生权限模型之外的需求。通常需要借助第三方插件，例如Role-based Authorization Strategy配合My View插件，或者通过文件夹隔离与自定义权限映射来变通实现。

所以第一步不是去项目配置里找“按构建编号授权”的选项，而是先判断你的真实目的。如果只是让开发者在默认页面里少看到一些无关构建，那属于展示层需求；如果是安全审计要求“无法访问他人构建”，那必须做到即使输入URL或调用API也看不到。两种目标对应完全不同的方案，混在一起会让配置越改越乱。

降噪路线：开发角色 + My View 个人视图

在Role-based Authorization Strategy环境下，可以为用户分配一个开发角色，该角色对某个项目或项目组拥有读取和构建权限。同时，利用My View插件创建个人视图，并在视图的'Build Filter'中设置触发者为'当前用户'。这样用户登录后，默认视图只显示自己触发的构建。需要注意的是，视图过滤是一种展示层控制，无法禁止用户通过输入构建编号直接访问他人构建页面。

这种方案适合内部团队日常使用。操作时，先安装Role-based Authorization Strategy和My View插件，然后在全局安全配置中启用基于角色的授权，再为用户或角色分配项目读取权限。接下来，让每个用户创建自己的视图，或在用户策略里预设一个视图，并把Build Filter设为“当前用户”。改完后，登录用户看到的默认视图列表是干净了，但你得明确告诉团队：这不能当作权限边界。

严格限制：在反向代理或应用层做校验

严格限制访问，必须在网络层或应用层做额外控制。比如通过反向代理（如nginx）对/job///路径进行权限校验，或者编写自定义认证插件，在获取构建详情前比对当前用户与构建的triggeredBy属性。如果仅做视图过滤，用户仍可通过Jenkins REST API拉取所有构建的数据，这种模式只适合降低信息噪音，不应被当作安全屏障。

这里说两个细分方向。反向代理方案相对轻量：在nginx里对 /job/ 路径做子请求校验，根据URL中的job名和build号，调用Jenkins API查询这次构建的发起人，再与当前登录用户比对。由于nginx本身需要读取Jenkins API，你得提前准备好一个服务账号，并注意缓存权限判断结果，避免每次请求都重复查询。自定义认证插件更彻底，能在Jenkins内部拦截所有访问路径，但需要维护Java代码，通常只有平台团队才会去做。

改完后看这几个信号

验证限制是否生效，可以切换到目标用户的身份，直接访问他人的构建URL：/job///console。若页面显示'不允许'则符合要求；若空白或正常，则说明配置存在漏洞。还可以调用API：curl -u 低权限用户 http:///job//api/json?tree=builds[number] 并检查返回的构建列表是否包含他人触发的构建，以此来检验权限边界。

用curl检查时，注意URL和参数要经过引号处理。下面是一个相对完整的示例：

curl -u 'dev_user' 'http://jenkins.example.com/job/demo/12/api/json?tree=builds[number]'

如果返回的builds数组里只有12号，而别人的构建号码没有出现，说明在API层面是受限的。如果仍然返回了所有构建，那么无论视图里怎么过滤，都说明权限没有真正收紧。

常见坑：项目级安全不是万能药

一个常见误区是在项目配置中启用'启用项目级安全'，并为每个用户单独添加读取权限，以为这样就能区分构建。但项目的ACL是粗粒度的，具体到所有构建记录。管理员很快会发现，即使用户只能读取该项目的构建，他们也能看到所有构建。正确做法是，利用构建变量（如BUILD_USER_ID）记录触发者，并在自定义的权限校验逻辑中依据该变量进行过滤。

如果你只有少数项目，可能觉得手动给项目配置ACL就够了，但实际上一旦项目开始累积构建，用户仍然可以点开历史列表。BUILD_USER_ID这个环境变量通常只存在于构建执行环境中，要把它用于请求时校验，需要在构建过程中把触发者信息写回外部存储，或者通过插件的副作用生成一个额外的权限索引。这个方案适合有开发能力的团队，不建议作为纯配置项来期待。

更彻底的隔离：文件夹方案

如果需要为每名用户生成完全隔离的构建区域，可以结合Jenkins的文件夹特性。创建以用户命名或对应用户角色的文件夹，将项目归属到文件夹内，并通过文件夹级别的访问控制，将读取权限仅授予该用户或用户组。这样能实现用户只看到自己文件夹中的构建。但这要求构建发起时能自动将项目映射到对应文件夹，否则手动分配维护成本较高。

文件夹方案适合用户之间完全隔离，比如每个团队或每个开发者只维护自己的项目。操作时，你可以在Jenkins首页创建多个Folder，每个Folder对应一个用户或组，再通过角色策略把Folder的读取、构建权限授权给特定主体。关键是要解决项目分发问题：最好用Job DSL脚本或Git存储库中的Jenkinsfile来自动生成项目，并放在对应用户的文件夹下，避免每次新建项目都由管理员手动移动。

回到最初的问题：这个需求没有标准答案。如果只是希望界面整洁，优先考虑My View过滤；如果是安全边界，必须接受额外开发和运维成本。无论选哪种，动手前先备份Jenkins home目录，并在测试环境模拟低权限用户进行一次完整验证。