在 LaunchDarkly…

当需要改变谁能看到某个功能开关、按百分比灰度、添加定向规则或在环境间复制配置时，通过 MCP 工具安全地完成变更并验证结果。

适用场景

解决思路

1. 先理解 LaunchDarkly 的评估顺序：开关 OFF 时向所有人返回 offVariation；个体目标优先级最高；自定义规则自上而下评估、首个匹配生效；默认规则（fallthrough）兜底。
2. 确认目标环境：用户只说“打开它”时环境不明确，必须确认是哪个环境，默认先询问而非假设。
3. 用 get-flag 拉取目标环境的开关状态，查看 on、fallthrough、offVariation、rules、targets、prerequisites 等字段。
4. 评估复杂度：无规则无个体目标的开关较简单；含多条规则、个体目标和前置依赖的开关需更谨慎处理。
5. 根据用户意图选择工具：打开/关闭用 toggle-flag；按百分比灰度用 update-rollout 且 rolloutType 为 percentage；为特定人群启用用 update-targeting-rules 添加带 clause 的规则；添加具体用户用 update-individual-targets；全量发布用 update-rollout 且 rolloutType 为 variation；从其他环境复制用 copy-flag-config。
6. 写规则、个体目标或百分比灰度前，先确认上下文支持：规则引用的 context kind 或属性必须在该开关评估时存在，否则静默不匹配；个体目标匹配的是 context key 而非 email 等属性；灰度只能按读取该开关处存在的 kind 分桶。
7. 执行安全检查清单：确认环境正确；若变更工具返回 requiresApproval: true，告知用户该环境需要审批、分享 approvalUrl、用 create-approval-request 按响应中的 instructions 创建审批请求，绝不绕过或自动批准；检查前置开关是否满足；考虑新增规则在评估顺序中的位置；始终添加审计注释，生产变更尤其如此。
8. 应用变更：toggle-flag 指定 on、env 和 comment；update-rollout 用 rolloutType: "percentage" 并传入人类可读权重（如 80 表示 80%）且总和为 100，或用 rolloutType: "variation" 加 variationIndex；update-targeting-rules 支持 addRule、removeRule、updateRuleVariationOrRollout、addClauses、removeClauses、reorderRules；update-individual-targets 支持 addTargets、removeTargets、addContextTargets、removeContextTargets、replaceTargets。
9. 变更后用 get-flag 再次拉取开关，确认新状态，并用平实语言向用户描述结果（如“开关现已在生产环境开启，25% 用户看到 true，75% 看到 false”）。
10. 检查副作用：若存在规则或个体目标，确认本次变更与它们的交互符合预期。
11. 处理需要审批的环境：用 create-approval-request 按被阻止响应的 instructions 创建审批请求；告知用户待审批并分享详情；需要时用 list-approval-requests 查看状态；审批通过（reviewStatus 为 "approved"）后用 apply-approval-request 应用；应用后再用 get-flag 验证。
12. 注意 update-rollout 使用人类友好百分比（传 80 而非 80000），工具内部会做权重转换；百分比灰度各 variation 权重总和必须恰好为 100。
13. 注意规则顺序会影响行为，重排规则可能在不改动单条规则的情况下改变结果；个体目标优先级最高，会覆盖所有规则和默认规则。
14. 注意状态为 launched 的开关仍然是 ON（向所有人提供单一 variation）；若要移除开关应使用 cleanup 技能而非定向变更。

适用边界 · 注意事项

• 未配置远程托管的 LaunchDarkly MCP 服务器时不可用。
• 需要绕过审批流程或自动批准时不可用，本技能明确禁止此类操作。
• 想彻底移除已发布的开关时，应使用 cleanup 技能而非定向变更。