4. 开发者画像与需求分层

平台治理最容易犯的错误，是把所有开发者当成同一种人。同一个内部开发者平台，新人可能连"从哪开始"都不知道，而专家却在抱怨"为什么不能直接调 API"。如果只提供一套统一的入口、文档和审批规则，结果往往是新人被复杂度和术语劝退，专家被流程和封装拖慢。开发者画像与需求分层，就是要在设计体验策略和治理规则之前，先回答一个前置问题：我们服务的到底是哪几类开发者，他们各自卡在哪里、需要什么、能承受多少约束。

画像不是标签，而是"目标—能力—约束"三元组

给开发者贴"新手/进阶/专家"的标签很容易，但标签本身不能指导设计。真正可用的画像，需要刻画三个维度：

• 目标：他此刻想完成什么？是"跑通第一个服务"，还是"把服务接入统一网关"，还是"批量迁移 200 个仓库"？
• 能力：他对平台概念、工具链、领域知识的熟悉程度。注意能力是分领域的——一个后端专家可能在 CI/CD 上就是新手。
• 约束：他的时间预算、权限范围、合规要求。专家往往权限更大但时间更紧，新人权限小但需要更多引导。

把这三者放在一起，才能判断一个体验策略是否合适。例如"默认全自动创建资源"对新手是减负，对专家可能是失控；"必须填写 12 个字段的申请单"对合规敏感场景是必要，对实验性需求就是摩擦。

三类典型角色的诉求差异

下面这张图把三类角色在入口、文档、工具、治理四个维度上的核心诉求差异做了对照，帮助你在设计时快速定位"这个功能到底服务谁"。

从图中可以看出，三类角色的诉求并不是"谁更高级"，而是在四个维度上需要不同的默认值和不同的可绕过程度。新手需要强默认、强引导、低自由度；专家需要高自由度、可编程、可审计。进阶角色处在中间，既要稳定交付，又需要一定的灵活性。

从画像到体验策略：默认值分层

体验策略的核心不是"给每个人做一套界面"，而是让默认值随角色变化，同时保留升级路径。一个可落地的做法是：平台为每个操作定义三档默认配置——引导档、标准档、开放档，并根据开发者画像自动匹配初始档位。

以"创建一个微服务"为例，可以设计如下参数分层：

这样设计的好处是：新手不会因为选错版本或副本数而踩坑，专家也不会被"不可改"的默认值卡住。关键在于档位可升级——当新手完成若干次成功部署后，平台可以提示"你已熟悉基础流程，是否切换到标准档"，而不是永远锁死在引导档。

治理规则的分层：约束强度与角色匹配

治理规则同样需要分层。一个常见的误区是"治理越严越好"，但过严的规则会把专家逼到平台外，反而制造影子 IT。更合理的做法是按风险等级和角色能力匹配约束强度：

• 高风险操作（如生产环境数据库变更、公网暴露、权限提升）：无论角色，一律强制审批 + 双人复核，但为专家提供"预审批模板"减少重复沟通。
• 中风险操作（如创建命名空间、配置网关路由）：新手走引导模板自动通过，进阶和专家走策略校验，校验通过即放行。
• 低风险操作（如查看日志、创建开发环境）：全角色自助，仅记录审计日志，不设审批。

这里的关键判断依据是操作的可逆性和影响范围，而不是操作者的角色。角色只决定"默认走哪条路径"和"能否申请例外"，不决定"是否允许"。这样既保证了治理底线，又避免了用同一把尺子量所有人。

画像落地：从假设到可验证的信号

画像不能只靠拍脑袋。平台需要采集可验证的信号来持续校准角色判断，例如：

• 首次成功时间：从注册到完成第一个端到端任务的时间，反映新手引导是否有效。
• 自助完成率：不求助人工支持就完成操作的比例，反映文档和工具是否匹配当前角色。
• 绕过率：通过 CLI/API 绕过控制台完成操作的比例，反映专家是否被界面束缚。
• 审批等待时长：中高风险操作的审批耗时，反映治理规则是否成为瓶颈。

这些信号可以反过来调整默认档位和治理阈值。例如，如果某团队专家的绕过率持续高于 80%，说明控制台对他们来说摩擦过大，应该优先提供 CLI 和 API 的完整能力，而不是继续优化图形界面。

小结：分层不是分裂，而是可升级的默认值体系

开发者画像与需求分层的本质，是承认不同角色在同一平台上的诉求存在真实差异，并用可升级的默认值 + 按风险分级的治理规则来同时服务他们。新手需要被"扶上马"，专家需要被"放开手"，进阶角色需要"稳中带活"。设计时先问三个问题：这个功能默认服务谁？默认值是否可改？改了之后治理是否仍然可控？回答清楚这三个问题，体验策略和治理规则就能落在同一套画像体系上，而不是互相打架。