起点是身份源
角色要绑到真实账号上才有意义，统一身份或目录服务未就绪时，只能先做岗位与账号的映射表。怎么排：把身份源对接放在第一周，与客户方 IT 约定测试账号与属性字段，避免开发完成后才发现拿不到部门信息。
分级早于切片
知识切片一旦入库，后补密级标签就要重切、重建索引，这是权限项目里返工成本最高的一环。怎么做：先出字段与文档清单，请数据负责人分级，再按结果生成切片元数据；顺序颠倒几乎必然返工。
切片写入过滤字段
检索过滤依赖切片自带的部门、密级与项目标签。为什么强调同步设计：事后补标签需要重跑全量文档，还要重新校验过滤器，工期不可控；切片阶段多花一天，比上线前返工一周划算得多。
抽测留返工窗口
抽测几乎总会发现标签缺失或过滤条件写错，需要改配置并重跑。怎么排：把抽测放在上线前两周，后面留出一轮返工与复测；压到最后三天，就只能带着已知问题上线，风险由业务承担。
客户方待办要列清
权限排期卡住的往往不是开发，而是在等客户方给东西。做法：开工第一周出一张待办清单，列出身份源接口、字段密级确认、账号清理与样例文档四项，逐项写明期望提供时间与不提供的后果，会上确认并记入纪要；我方按约定时间准备，未按期提供的顺延，不影响既定的工期与责任边界。
适用与不适用
适合谁
- 正在为 AI 应用排期的项目经理
- 权限整改与数据治理并行推进的企业
- 需要向管理层解释工期的技术负责人
不适合谁
- 只有单一角色、无数据隔离需求的工具
- 组织架构长期不变、角色极少的小团队
典型场景
某零售集团的门店运营助手计划六周上线。第一周对接统一身份与花名册，第二周完成角色与字段清单，第三周确认数据分级，第四周带标签切片入库并实现检索过滤，第五周抽测与返工，第六周评审。分级确认晚了几日，是主要导致整体顺延的依赖项。
可执行步骤
- 先确认统一身份源可用，并拿到测试账号、部门属性与完整组织层级字段。
- 完成角色与可见范围清单，交业务负责人逐条确认，作为数据分级依据。
- 在切片入库之前完成字段与文档分级，并形成可执行、可校验的标签规则。
- 抽测后预留一轮返工与复测，通过后再安排上线评审与灰度放量计划。
常见坑
- 把权限排到开发末期，切片早已入库，补标签要全量重跑，工期与索引双双失控，返工成本最高。
- 身份源未就绪就开工，角色绑不到真实账号，测试只能靠手工造数据，结论不可信，上线后必然暴露。
- 抽测紧贴上线，发现问题时已无返工窗口，只能带病上线，运行期补救的代价明显更高，问题往往拖到上线后才被发现。
自检与验收清单
- 身份源与测试账号是否在第一阶段就绪并可用
- 数据分级是否在切片入库前完成，并留档确认
- 切片元数据是否包含部门、密级与项目三类标签
- 抽测之后是否预留一轮返工与复测的时间窗口
常见问题
能不能先上线再补权限？
不建议。切片入库后补标签要重切与重建索引，还要重跑全部抽测用例，实际耗时通常超过一次做完。若必须分阶段，至少先做检索层过滤，否则越权内容会以模型回答的形式直接流出。
分级由谁做、要多久？
由客户方数据负责人牵头，业务配合标注字段与文档密级。耗时取决于文档量与争议条款数量，而不是技术复杂度，所以要在项目启动时就发起，不要等到开发需要标签时才提，否则一定卡在关键路径上。
身份源对接卡在哪？
常见是拿不到部门属性、测试账号审批慢、属性命名与预期不一致。规避方式是启动会上就确认需要哪些属性、由谁提供测试账号、多久能批下来，并把这些写进项目计划而不是口头约定。