点着页面改代码
产品经理在测试页点中元素说出改法，几分钟后拿到源码改动、受影响页面和可点击预览。
产品经理在预发布站点发现“加入购物车”按钮颜色不对时，先用浏览器扩展点中那个真实元素，再用一句话说明想改成什么样。扩展会保存元素的 DOM 路径、当前截图和所在页面，同时连接项目仓库与设计令牌库。需求不再是一张圈图和几轮来回确认，而是带着准确定位进入开发流程。
代理沿着元素定位组件、样式来源和令牌引用，先在隔离分支完成修改。若这个按钮被多个页面复用，它会列出所有受影响页面，再为每处生成前后截图。遇到“蓝色”对应多个品牌色阶，产品会把候选颜色放进预览，让提出需求的人当场选定。
改动完成后，发起人收到一个可点击的预览链接。页面旁边附着修改说明、涉及文件、视觉差异和自动测试结果。工程师打开拉取请求后，可以直接审查代码与影响范围；若发现问题，只需在预览页批注，代理便在同一分支继续修订。
起步阶段把范围收在已接入组件映射的 React 项目，优先处理文案、颜色、间距和显隐这类可视改动。它不会直接改动生产环境，也不替团队合并代码。先把“看见问题、说清改法、交出可审查补丁”压缩成一次连续动作。
为什么是现在
9月9日，一则围绕“只把加入购物车按钮改蓝”的互动页面登上 Hacker News；截至9月10日记录为982 points、390 comments、rank 1。S1 讨论直接暴露了简单界面改动被代理过度扩张的问题，使团队更在意准确指向元素、限制改动范围和保留人工审查。
目标用户
核心用户是负责预发布验收的产品经理、设计师和前端负责人。他们在测试页看到具体视觉偏差时，往往无法说出组件名或文件位置。此刻截图工单容易丢失页面状态，也难说明复用范围。若改动临近发布，他们更需要快速获得范围明确、可回退且能由工程师审查的补丁。
最小切入点
浏览器端采用 Chrome 扩展内容脚本。点选时保存 CSS selector、DOM 片段、计算样式、页面地址和截图。服务端先限定已接入映射表的 React 组件，不尝试从任意 DOM 猜源码。仓库侧通过 GitHub App 读取代码，并创建临时分支和拉取请求；GitHub REST API 已提供相关接口。S4 修改只覆盖文案、令牌引用、间距和显隐。用 Playwright 重放已登记路由，产出修改前后截图。遇到多个令牌候选时停止改码，先让发起人选择。
以小博大
第一批用户可从前端外包团队和小型 SaaS 团队中寻找。他们常让产品经理直接验收预发布页面，也承受大量零碎视觉工单。可做一个公开演示仓库，逐条展示元素选择、影响页清单和最终 PR。再把扩展用于真实的开源 React 项目，提交经过维护者确认的微小界面修复。每个合并案例都能成为可信的工作流样本。
竞品与缝隙
怎么赚钱
按连接的代码仓库收费。基础版每个仓库按月订阅，包含固定数量的改动任务和预览构建。超出后按任务计费，避免按席位阻碍产品、设计和测试人员参与。
反方视角
元素与源码的映射很容易失效。动态类名、条件渲染和微前端都会让 DOM 路径指向错误组件。误改共享令牌后，一个局部按钮需求可能波及整站。逐路由构建和截图会拉长等待时间，也会消耗持续集成资源。扩展还需读取页面与私有仓库，权限审查会拖慢团队采用。若产品经理频繁得到错误候选或无关改动，工程师仍要重新定位，信任会迅速消失。继续做的前提是先靠显式组件映射获得高确定性，而非追求适配所有 React 项目。