开发者需要一个本地、零依赖的 CLI 工具，用于扫描代码库中绕过设计 tokens 的硬编码颜色和非标准间距。

设计系统（Design System）的构建是现代前端工程化的核心。它旨在确保产品在不同页面、不同功能模块上保持视觉和行为的一致性。然而，随着项目规模的扩大和团队成员的增多，一个普遍且致命的问题就会出现，这就是“设计系统漂移”（Design System Drift）。

痛点核心：硬编码的“遗留代码” 当开发人员在编写组件时，为了快速实现某个效果，他们往往会绕过设计系统定义的变量（Design Tokens），直接在 CSS/SCSS 中写下具体的颜色值（如 #ff0000）或间距值（如 17px）。这些硬编码的值，就是设计系统漂移的根源。它们使得系统无法通过中央配置进行统一管理，导致产品在不同地方出现颜色不一致、间距不协调的“小瑕疵”。

痛点严重性与现有不足： 这种漂移的成本是巨大的，它不仅是视觉上的瑕疵，更是技术债务。

1. 维护成本高： 当品牌色或基础间距需要调整时，维护人员必须手动搜索整个代码库，找出所有硬编码的值并进行替换，这极度耗时且容易遗漏。
2. 缺乏量化指标： 现有工具（如 ESLint 或 Stylelint）只能检查代码的语法或结构，它们无法理解“这个颜色值是否应该来自设计系统？”它们缺乏对“设计意图”的理解。
3. 缺乏自动化报告： 开发者需要的是一个自动化、可量化的报告，告诉他们“漂移发生在哪些文件、哪一行，漂移的严重程度是多少”。目前市场上缺乏这种专门针对“设计系统一致性”的扫描工具。

用户画像：

1. 核心用户 (Primary User)： 高级前端工程师（Senior Frontend Developer）或组件库维护者。他们是日常编写和维护组件代码的人，对代码质量和工程化流程有极高要求。
2. 决策用户 (Decision Maker)： 设计系统负责人（Design System Lead）或工程经理（Engineering Manager）。他们关注的是整个项目的可维护性、一致性和技术债务的积累。

典型场景： 在一个拥有数百个组件、使用 Storybook 或类似工具维护的大型企业级应用中，团队刚刚完成了一轮 UI 规范升级（例如，将主品牌色从 #007bff 调整为 #0066cc）。在代码提交和 CI/CD 流程中，开发人员忘记更新某个组件的背景色，导致整个系统在某个角落出现了旧的颜色值。TokenDrift CLI 的作用就是自动扫描，并在 CI 阶段捕获到这个“漂移”，并在报告中精确指出 src/components/Card.module.scss 的第 45 行。

群体规模感与付费能力： 目标用户群体属于大型互联网公司、金融科技公司或成熟的SaaS企业，这些公司必然拥有复杂的、需要高度一致性的设计系统。这些公司具备极高的付费能力，因为工具能直接解决“项目延期风险”和“人工排查成本”，其价值远超 $19 的购买费用。

MVP 范围与核心功能： MVP 必须聚焦于核心价值：扫描并报告硬编码值。

1. 输入配置： 允许用户输入设计系统 Token 的定义文件（例如，一个 JSON 或 YAML 文件，定义了所有合法的颜色、间距、字体等）。
2. 扫描引擎： 接受目标代码目录（如 src/styles），遍历所有 CSS/SCSS 文件。
3. 核心逻辑： 对每个文件中的颜色值、间距值进行正则匹配和解析。如果匹配到的值无法通过已定义的 Token 集合进行验证，则标记为“漂移”。
4. 输出报告： 生成一个结构化的报告（CLI 输出或 JSON），包含：
   • 总漂移分数（Drift Score）：一个 0-100 的量化指标。
   • 漂移列表：文件路径、行号、违规代码片段、建议的 Token 替换值。

技术实现思路：

• 架构： 纯命令行工具（CLI），无后端服务，实现本地化、零依赖（Zero-dependency）的特性。
• 关键模块：
  • Config Loader: 读取 Token 定义文件。
  • File Scanner: 使用 Node.js 的 fs 模块递归遍历目录。
  • Parser Engine: 核心逻辑，使用正则表达式或更复杂的 AST (Abstract Syntax Tree) 解析库来识别 CSS/SCSS 语法中的值。
  • Scoring Algorithm: 根据漂移值的数量和严重程度（例如，颜色漂移 > 间距漂移）计算 Drift Score。

推荐技术栈：

• 语言/运行时： Node.js (最适合构建CLI工具，生态成熟)。
• 核心库： commander 或 yargs (用于CLI参数解析)；cheerio 或自定义正则/AST解析器 (用于CSS/SCSS解析)。
• 部署： npm 包发布，确保零依赖和易于安装。

一个人多久能做出第一版： 如果开发者对 Node.js 和 CSS/SCSS 语法有一定了解，MVP 的核心扫描逻辑（只关注颜色和间距）可以在 1-2 周内完成。由于是本地工具，复杂度可控，不需要处理复杂的网络或用户认证流程。

用户现在怎么凑合：

1. 人工代码审查 (Manual Code Review)： 这是最原始的方式。依赖于团队成员的警惕性和时间。效率极低，且容易疲劳，无法保证覆盖率。
2. 视觉检查 (Visual Inspection)： 开发者在浏览器中查看，发现不一致。这只能发现“结果”，无法定位到“原因代码”。
3. 通用 Linter/Prettier： 这些工具可以检查代码格式和语法，但它们缺乏“设计系统上下文感知能力”。它们不知道 #ff0000 这个颜色值是否应该被设计系统 Token 覆盖。

竞品分析： 目前市场上没有直接对“设计系统漂移”进行量化扫描的工具。一些工具可能提供组件级别的检查，但它们通常是图形化、基于 UI 的，无法深入到代码的底层结构进行自动化、批量的扫描。

你的切入点（Gap）： 你的核心差异化在于：

1. 上下文感知 (Context-Aware)： 不仅是检查代码，而是检查代码是否符合预定义的设计规则。
2. 量化指标 (Quantifiable Metric)： 引入“Drift Score”，将一个模糊的“代码质量问题”转化为一个可追踪、可优化的数字指标，这极大地提升了工具的专业性和价值。
3. 零依赖/本地化： 作为一个本地 CLI，它能保证在 CI/CD 环境下的稳定性和速度，避免了网络依赖和环境配置的复杂性。

变现模式： 采用 一次性买断授权 (One-time License) 模式，针对企业团队（Team/Enterprise）。

• 产品定位： 这是一个“工程质量门禁”工具，而不是一个简单的代码格式化工具。
• 销售对象： 销售给工程团队的负责人（Engineering Manager）或技术部门的采购。

定价建议：

• 基础版（Solo/Small Team）： $19 - $49 (一次性买断)。适用于小型团队或个人项目。
• 企业版（Team/Enterprise）： $99 - $199 (一次性买断，或年费 $199)。提供高级功能，如：
  • 多 Token 源支持（支持多个设计系统）。
  • 集成 CI/CD 钩子（自动在 PR 提交时运行）。
  • 团队报告仪表盘（汇总多个项目的 Drift Score 趋势）。

为什么用户愿意付费： 用户不是为“扫描代码”付费，而是为 “避免项目延期和重构的巨大成本” 付费。

• ROI 论证： 如果一个大型项目每年因为设计系统漂移导致 2-3 周的返工时间，那么 $199 的工具费用在成本面前几乎可以忽略不计。
• 强制性需求： 将其定位为 CI/CD 流程中的“强制质量门禁”，使其成为团队不可或缺的流程工具。

技术趋势：组件化与设计系统成熟： 随着 React, Vue 等框架的普及，组件化开发成为主流。这使得设计系统成为必需品。当设计系统从概念阶段进入到“大规模生产环境”时，其维护的复杂性呈指数级增长，漂移问题也随之爆发。

工程化流程的严格化： 现代软件开发越来越依赖 CI/CD 流程和自动化质量门禁。开发者不再满足于手动检查，他们需要工具来保证代码在进入主分支前，必须通过一系列的自动化质量检查。TokenDrift CLI 正好填补了“设计一致性”这一关键质量维度上的自动化空白。

AI/自动化工具的普及： 开发者对自动化工具的接受度极高。他们习惯于使用各种 CLI 工具来提高效率。一个简单、高效、且能解决高价值痛点的 CLI 工具，天然符合当前开发者工具的消费习惯。

主要难点：

1. CSS/SCSS 解析的复杂性： CSS/SCSS 语法非常复杂，支持变量、混入（mixins）、嵌套等。要实现一个健壮的解析器，不能仅仅依赖简单的正则表达式，需要处理复杂的解析逻辑，这是技术实现上的最大挑战。
2. Token 规则的泛化性： 不同的设计系统可能有不同的 Token 结构（有些是颜色，有些是间距，有些是圆角）。工具必须足够灵活，能够适应多种 Token 定义格式。

可能的护城河或壁垒：

1. 算法和报告的专业性： 核心壁垒不在于扫描，而在于 “Drift Score 的计算逻辑” 和 “报告的深度”。如果能将漂移的严重性（例如，颜色漂移比间距漂移更严重）进行加权计算，形成一套独有的、难以复制的评分模型，这就是强大的护城河。
2. 生态集成： 将工具深度集成到主流的 CI/CD 平台（如 GitHub Actions, GitLab CI）中，并提供最佳的集成体验，形成流程依赖，是长期的壁垒。

第一批用户从哪来：

1. 技术社区（Hacker News / Reddit）： 这是最直接的渠道。在 r/react, r/frontend, r/webdev 等板块，发布关于“设计系统漂移”的痛点文章，并展示 CLI 的 Demo。
2. 开发者工具垂直社区（Dev Twitter）： 在 Twitter 上，与大型设计系统或组件库相关的 KOL 互动，展示 CLI 的使用效果。
3. 内容营销（博客）： 撰写技术深度文章，主题为《如何用代码保证设计系统的一致性？》，并在文章末尾自然地植入 CLI 工具。

用什么渠道和动作起量：

• 动作 1：痛点展示 (Pain Point First)： 不要直接推销工具，而是先展示一个“漂移”的例子（例如，用一张图展示两个页面颜色不一致），然后提出“我们如何用代码解决这个问题？”
• 动作 2：免费试用与反馈循环： 初期提供免费的 CLI 版本，重点收集用户在不同框架（Vue, React, Angular）和不同预处理器（Sass, Less）下的使用反馈，用这些反馈来迭代和完善解析器。
• 动作 3：构建早期用户群： 建立一个私密的 Discord 或 Slack 群组，邀请使用过设计系统的开发者加入，让他们成为产品的“早期测试官”，并根据他们的反馈来优化评分模型。