featurevisor 是做什么的？
你正在帮助用户使用 Featurevisor，通过 Git 进行特性管理。一个 Featurevisor 项目是一个 YAML（默认）或 JSON 定义的仓库。CLI 会对其进行检查和测试，并构建静态的 JSON 数据文件，应用程序通过 SDK 在本地对其进行评估。每项任务都位于以下两个方面之一：
- 项目端：创作和查询定义（特性、分段、属性、全局变量、测试）并运行
featurevisorCLI。 - 应用端：加载数据文件并通过 SDK（
@featurevisor/sdk、React、Vue 或其他语言）进行评估。
这个技能涵盖了这两方面，适用于 Featurevisor v4。文档索引位于 https://featurevisor.com/llms.txt，完整文本位于 https://featurevisor.com/llms-full.txt。当某个主题未包含在以下参考资料中时，请获取它们。
了解你的受众
工程师、产品经理、营销人员以及那些描述需求但不了解 YAML 的人都在使用 Featurevisor。请相应调整：
- 翻译意图。“为 10% 的荷兰用户打开横幅”是一个灰度发布规则。你自己完成映射，然后用他们的语言报告结果：发生了什么变化，谁受到影响，以及接下来会发生什么。
- 常规更改： 提高百分比、在全局捕获规则上方添加规则、添加特性、为 QA 强制启用特性。自信地完成这些操作。
- 风险更改： 重命名规则键、更改
bucketBy、更改变异权重、降低百分比、归档仍被引用的内容。这些操作会在用户结果之间移动。直接说明（“一些用户会在会话中途丢失特性”）并在继续之前确认。 - 闭环。 更改后，用一两句话说明一旦发布会发生什么。例如：“一旦合并并且 CI 部署了数据文件，大约 10% 的荷兰用户会看到横幅，其他用户什么都看不到。”
- 提供目录 给任何希望查看项目而不是阅读 YAML 的人（使用目录进行视觉审查）。
首先了解情况
此技能中的示例使用默认脚手架，该脚手架没有环境。当项目配置了环境时，在 evaluate、benchmark、assess-distribution 和 build --print 中添加 --environment=<名称>。常规的文件构建涵盖所有环境。
尚无项目？先访谈，再生成脚手架
如果工作树中没有 featurevisor.config.js，则不存在 Featurevisor 项目。如果用户在应用程序仓库中，这是 SDK 的工作：请参阅应用程序集成（SDK），并在项目仓库（而不是这里）创作定义。如果他们想要一个新项目，请先询问这些问题，因为之后编写的每个文件都依赖于它们：
- 环境？ 默认没有环境，规则是直接列表。
--example=with-environments会给出明确的staging和production。 - 集合？ 默认无。仅为独立审查的树提供集合：从开发到暂存再到生产的发布渠道，或无关的表面区域，如店面和管理后台。首先阅读 sets-promotions.md。
- 消费者？ 一个应用程序可以使用默认的
all目标，该目标没有选择器，包含所有活动定义。多个表面通常会有类似web、ios和android的标签，以及每个表面一个目标。 - 文件格式？ YAML（默认）或 JSON。
- 什么标识用户？
userId、deviceId，或两者兼有（bucketBy: { or: [userId, deviceId] }）。lint 要求每个特性都有bucketBy，因此这决定了每个特性声明什么以及哪些属性首先出现。
在一个空目录中生成脚手架，放在自己的仓库中，与应用代码分离：
npx @featurevisor/cli@latest init
npm install
--example=with-environments 会给出环境键化的规则，--example=environments 会给出作为发布渠道的集合，--example=sets 会给出独立的表面。CLI 设置表列出了所有示例。然后根据访谈答案调整 featurevisor.config.js。templates/example-project/ 是一个完整的 v4 项目，通过了 lint 和测试，可用作了解各部分如何组合的参考。
现有项目？在接触任何内容之前检测版本和形态
确认项目在其包清单和 lockfile 中已安装 @featurevisor/cli，并通过 npm ls @featurevisor/cli 确认。然后在项目中运行已安装的 CLI：
npx featurevisor --version
它必须解析项目自己的二进制文件。如果缺少或 npx 提供下载包，请停下来询问有关恢复项目锁定依赖项的问题。不要仅仅为了检测版本而安装远程 CLI 或升级依赖项。
- 4.x：本技能中的所有内容均适用。
- 3.x：v3 语法不同。它在规则中使用
segments和requiredFeatures而不是统一的conditions，并且缺少变量条件、组合、continue、测试checks、场景和几个运算符。不要将 v4 语法写入 v3 项目。保持在 upgrading-to-v4.md 中列为 v3 语法的范围内，并在请求需要 v4 时提供升级。 - 2.x：例如
scopes:、environments/目录或应用代码中的createInstance等形态。首先提供 upgrading-to-v3.md。
消费者决定你可以发布什么。 v4 数据文件需要 v4 SDK：v3 SDK 不理解统一的 conditions，因此规则会停止匹配。数据文件 schemaVersion 只是信息性的，不会使旧 SDK 拒绝该文件。在引入运行时能力（如累积覆盖或更新的运算符）之前，请确认每个使用该数据文件的应用程序的 SDK 版本。如果未知，请询问用户。针对 SDK 兼容性矩阵 检查每个 SDK。原生版本号不同，因此不要假设每个兼容的 SDK 都是 4.x 版本。仅仅 CLI lint 成功并不能确定运行时支持。测试检查和场景需要兼容的 CLI 运行程序，这与消费者支持什么是一个独立的问题。
然后读取配置：
npx featurevisor config --json --pretty
npx featurevisor info
四个值会改变你编写的一切的形态：
sets：当为true时，每个定义都位于sets/<set>/下，命令需要--set。首先阅读 sets-promotions.md。environments：当声明时，特性rules、force和expose，以及全局变量overrides，是按键环境映射的。没有它们时，它们是直接列表，并且expose是布尔值或标签列表。parser：对于 `