0. 术语速查：看到这些词不用慌
你不会自己敲这些东西——真正动手的是你指挥的 Codex / Claude。但它在向你汇报时会用到下面这些词，所以你只需要“看到时知道大概指什么”即可，不用记住怎么用。
repo（代码仓库）：项目所有代码存放的地方，放在 GitHub 上。你几乎不用亲自打开它——你的 AI 助手会。
commit（一次存档）/ 回滚：每次改动都会被记成一个带说明的存档。不满意可以“回滚”到之前任何一次存档。这是你最重要的安全网——几乎没有什么改动是不可逆的。
main（上线分支）/ push（推送上去）：代码一旦进入 main 就会自动上线。所以简单记：“进了 main = 用户就能看到了”。
deploy（部署 / 上线）：把改好的东西正式发布到线上，让人能访问。
前端 / 后端：前端 = 用户看到、点击的界面；后端 = 界面背后取数和计算的部分。你日常关心的几乎都是前端（详见第 3 节）。
Worker / R2 / D1：都是 Cloudflare 上的东西。Worker = “运行网站的程序”，R2 和 D1 = “存数据的两种仓库”。你不用记它们的区别，只要知道它们都在 Cloudflare 那一侧，AI 会替你分辨。
1. 大图景：这个 dashboard 是怎么工作的
最简单地说，dashboard = 页面代码 + 数据 + 线上运行环境。用户看到的是一个网页，但背后有几个系统各司其职。
你 / 分析师
通过 Codex / Claude 提需求：改文案、查数据源、更新图表、解释异常。
→
GitHub
保存 dashboard 代码和修改历史。
→
Cloudflare
把代码变成线上网站，并提供数据存储。
实用理解：GitHub 像“项目文件夹 + 版本历史”；Cloudflare 像“线上服务器 + 数据仓库”；Codex / Claude 是你操作这套系统的助手。
为什么你需要知道这些
你不需要记住每个技术细节，但需要知道“问题可能发生在哪一层”。否则很容易把数据过期误判成前端 bug，或者把页面文案问题误判成数据问题。
如果是前端问题：通常表现为页面不好读、图表顺序不符合研究逻辑、文案太技术化、筛选器不好用。
如果是数据问题：通常表现为某个页签没更新、某个品牌是空的、数值和预期对不上。
如果是上线问题：通常表现为“改是改了，但线上还是旧的”，或者这次上线本身失败了。
2. GitHub 和 Cloudflare 分别是什么
这是两家不同的公司、两种不同的工具，几乎所有互联网产品背后都会用到类似的一对角色：一个负责保存和管理代码，一个负责把代码真正跑起来给人访问。先分别理解它们，再看它们怎么配合。
GitHub：代码的“云盘 + 完整改动史”
GitHub 是全世界软件团队存放代码的标准地方。你可以把它想成专门为代码做的 Google Drive，但多了一件关键的事：它记录每一次改动——谁、什么时候、改了哪几行、为什么。
它保存代码。整个项目的代码都放在一个叫 repo（仓库）的地方，是唯一的“权威版本”。
它记住所有历史。每次改动都是一个带说明的存档（commit）。任何一次都能翻出来看，也能回滚。这就是为什么改错了几乎不可怕。
它本身不运行网站。GitHub 只是“存放和记账”的地方，像一个图书馆或档案室——它不负责把网站跑给用户看。那是 Cloudflare 的活。
Cloudflare：真正把网站“跑起来、发出去”的地方
Cloudflare 是一个云计算平台。当有人打开一个网址，真正响应、把页面送到他屏幕上的就是 Cloudflare。它做两件对我们重要的事：
运行网站。它拿到最新代码，处理用户的每一次访问，把 dashboard 显示出来。
存放数据。网站要展示的销售、情绪等数据，也存在 Cloudflare 上（分文件仓库和数据库两种，AI 会替你分辨）。代码和数据是分开存的——这点很重要，第 5 节会再讲。
一句话记住：GitHub = 代码住的地方 + 完整改动史；Cloudflare = 把代码变成能访问的网站、并存放它的数据。你通过 Codex / Claude 指挥它们，自己不用直接操作。
它们怎么配合（做菜的比喻）
GitHub像写下并存好的“菜谱”，每次改动都留痕，随时能翻回上一版。
→
Cloudflare像照着最新菜谱做菜、上菜的厨房，客人吃到的成品由它端出来。
→
Dashboard就是端上桌、交给投资团队看的那道菜。
所以流程永远是：改动先进 GitHub（改菜谱），Cloudflare 再据此更新线上网站（重新做菜）。反过来不行——线上不会凭空变化，除非代码进了 GitHub。
本项目：一个主网站 + 几个后台“取数机器人”
你不需要记任何程序的名字，只要有个大致印象：这个 dashboard 由一个主网站（你和投资团队实际看的那个页面），加上几个在后台默默跑的取数程序组成——后者定时去各个数据源把最新数据抓回来存好。两者的更新方式不同（第 4 节细讲），但对你来说只要记住：改页面是一回事，数据靠后台自己刷新是另一回事。
登录墙（Cloudflare Access）：整个 dashboard 藏在公司登录后面，只有组织账号能看。没登录直接打开会被挡在登录页——这不是故障。看线上页面时，用组织账号登录 https://ai-glasses.arcavenue.workers.dev/ai-ar-tracker 即可。
3. 前端和后端：在这个项目里是什么意思
“前端 / 后端”不是职位名称，而是系统分工。你以后大概率主要关心前端，因为那决定投资团队实际看到什么、怎么筛选、怎么读图。
前端：用户看见和操作的部分
页面布局、文字、tab 顺序、图表样式、筛选器、空状态、说明文案。你最常调的是这一层。
dashboard 页面
图表体验
分析口径说明
后端：页面背后的取数和计算
页面怎么把数据读进来、后台怎么把数据抓回来存好、口径怎么算。通常只在“数据不更新”或“口径要变”时才需要动。
数据存储
取数逻辑
后台抓取程序
对分析师最实用的边界：你主要会让 Codex / Claude 调前端展示，让 dashboard 更符合你的分析习惯。后台抓取、数据存储这些属于基础设施，通常不是你的日常范围；你只需要知道它们存在，出问题时让 AI 先定位是哪一层，而不是自己去猜。
前端调优通常包括什么
把页签名称、段落说明、空状态文案改成投资团队能直接理解的语言。
调整图表顺序，让最关键的判断先出现，而不是按工程实现顺序出现。
减少不必要的数据来源或补丁式图层，让每张图的来源尽量单一、清楚。
把默认视图改成更贴合实际使用习惯的那个。
把技术性的报错提示改成“该怎么办”，例如“数据暂未更新，请稍后再看”。
后端通常什么时候才需要关心
页面本身正常，但数据明显过期。
某个页签一直是空的，且确认不是筛选条件导致。
上游数据口径变了，取数或计算逻辑得跟着调。
某个后台抓取程序跑失败了，需要让 AI 去查它的运行记录。
4. 上线流程：哪些是自动的
主 dashboard 的上线流程是自动化的。你或 Codex 把代码推到 GitHub 的 main 分支后，Cloudflare 会自动接手后续步骤。
1. 改代码由 Codex / Claude 按你的要求修改。
→
2. 进入 GitHub main改动被存进上线分支。
→
3. 自动上线Cloudflare 自动接手，几分钟后线上就是新版本。
你不用记任何命令。“进 main → 自动上线”这一步是全自动的，AI 会替你完成。你只需要知道它已经发生了，以及大约几分钟后线上才会变。
一个例外：只有主网站是这样自动上线的。后台那几个取数程序不跟着一起走，需要单独发布——这属于 AI 的活，你只要知道“改了后台的东西，不会因为一次普通上线就自动生效”。
你真正要记住的不是命令，而是三种改动的边界
改页面（最常见）：进 main 后主网站自动上线，几分钟见效。
改后台取数程序（少见）：需要单独发布，不会随主网站自动生效。
只换数据、不动代码：通常连上线都不用——把新数据放到原来的位置，页面下次读取就是新的了。
5. 数据从哪来：代码和数据是两回事
这一节只想让你记住三个概念，具体的文件名、存储位置这些细节，交给 AI 去查就好——你不用背。
概念一：页面只“读”数据，不自己去抓
dashboard 是个只会读数据、把它画成图的展示层。它自己不会去更新数据。数据是由另外一批后台程序、按各自的节奏抓回来、存到 Cloudflare 上的；页面每次打开，只是把当时存着的最新数据读出来显示。
这条概念的直接用处：当某张图数据看起来过期或为空时，十有八九不是页面代码坏了，而是“负责抓这块数据的后台程序这次没跑成功”。别急着让 AI 改页面。
概念二：不同图的数据，来自不同来源、更新节奏也不同
每个 tab 的数据来自不同地方，刷新快慢也不一样。你不用记谁是谁，只要有个印象“来源各不相同”，这样看到某块数据没动、别块动了，不会觉得奇怪：
自动定时抓取（最常见）：大部分销售类数据由后台程序定时自动去外部数据平台抓取、存好。没更新时先怀疑“这次抓取有没有成功”。
外部供应商定期投放：有一部分数据是外部供应商大约每月交付一次，节奏偏慢是正常的。
人工快照：个别数据目前还是人工定期更新的。
后台持续监测：市场情绪、VITURE 官网这类，由专门的监测程序持续跑、不断写入。
你完全不需要记住哪块数据属于哪种。真要排查时，直接问 AI：“这张图的数据从哪来、多久更新一次、最近一次更新是什么时候？”它会替你查清楚。
概念三：数据源越少，越不容易出错
一张图每多接一个数据来源，就多一个可能出问题的点：某个源没更新、口径不一致、时间范围对不齐，解释起来也更绕。所以让 AI 优化页面时，“减少不必要的数据来源、让每张图的来源尽量单一清楚”本身就是一个合理的目标，不只是为了好看。
6. Codex / Claude 维护工作流
对你的 analyst 来说，最现实的工作方式不是自己打开代码编辑器，而是让 Codex / Claude 做改动，然后自己 review 结果。这个流程应该像和一位工程同事协作。
先说业务目标。例如：“我希望中国电商页更适合快速判断哪个品牌在增长，而不是展示所有细节。”
要求先定位层级。让助手先判断这是前端、数据、还是部署问题，不要直接改。
限定改动范围。例如：“只改 HTML 文档”或“只改 dashboard 前端，不碰 tracker”。
让它解释验证方式。你不需要懂所有命令，但要知道它怎么确认没有改坏。
最后你看结果。重点看页面是否更符合分析逻辑，而不是代码写得是否漂亮。
好的协作方式：你负责判断“这个展示是否帮助投资判断”；Codex / Claude 负责判断“应该改哪个文件、怎么验证、会不会碰生产资源”。
7. 常见维护场景
你的主要维护场景会是调页面：让 dashboard 更好读、更符合你的研究框架、减少不需要的数据来源或多余的解释文字。后台的数据抓取更像基础设施，通常只在“坏了”或“口径变了”时才需要介入。
最常见：调页面
文案、布局、页签、图表样式、筛选逻辑、分析说明。改的是页面本身。
|
偶尔：确认数据来源
让 AI 说清某张图的数据从哪来、多久更新一次。先定位，不急着改。
|
较少：动后台
市场情绪、VITURE、某个抓取程序不更新。让 AI 谨慎处理。
典型请求怎么说（直接照着讲给 AI 就行）
- “这张图的数据从哪来、多久更新一次、最近一次更新是什么时候？先别改任何东西。”
- “这个页面文案太技术化了，帮我改成投资团队能直接看懂的语言。”
- “把这个页签里图表的顺序，改成更贴合我研究思路的顺序。”
- “全球电商这张图好像没更新。先别改代码，帮我查是不是负责抓这块数据的后台程序最近没跑成功。”
- “VITURE 这块数据是空的。先帮我判断：是页面显示的问题，还是后台数据本身就没进来？”
几个具体例子
例子 A：你不喜欢某张图的默认展示
这通常是页面问题。你可以让 AI 调默认页签、默认指标、图例顺序、图表高度、说明文案。一般碰不到数据那一层。
例子 B：某个品牌数据看起来没更新
先别改页面。让 AI 查这张图的数据来源和最近更新时间——大概率是后台抓取的问题，不是页面的问题。
例子 C：你想删掉一个不再有用的数据块
这是“页面 + 数据依赖”的边界问题。让 AI 先确认这块数据是否还被别的图用到，再动手删，避免连累其他图表。
8. 如何 review Codex / Claude 的改动
你不需要逐行读代码，但应该按以下清单 review。这样可以避免“看起来改好了，但其实引入了新风险”。
1. 目标是否达成页面是否更符合你的分析方式？有没有误删或没突出你关心的信息？
2. 范围是否受控如果你只要求改页面，问一句：“你有没有动到数据或后台的东西？”——只改该改的地方。
3. 数据口径是否更清楚页面有没有说明白：数据来自哪里、更新时间意味着什么、哪些是“替代指标/近似值”而非精确销量？
4. 是否可以反悔问 AI：“这次改动能一键回滚吗？有没有删掉任何线上数据？”正常情况下答案应是“能回滚、没删数据”。
5. 是否验证过让 AI 说明它怎么确认没改坏——比如它自己打开页面看过、或查过数据。你不用懂细节，但要看到它验证过。
9. 几条红线：AI 提议做这些时，先停一下
这些规则主要靠 AI 自己遵守，你不用记技术细节。但如果它的方案里出现下面这类动作，就多问一句“真的有必要吗？有没有更安全的做法？”——这些是少数可能造成不可逆后果的操作。
新建或删除数据库 / 数据仓库项目用的是几个共享的、已有的数据仓库，别的团队也在用。正常维护绝不需要新建或删除它们——真要这么做，先停下确认。
给数据文件改名、或换存放位置页面是按固定名字去读数据的。刷新数据 = 用同名的新文件覆盖旧的，不是改名或换地方，否则页面就读不到了。
把原始数据文件塞进 GitHubGitHub 只放代码。销售明细、原始语料这类数据文件不该进 GitHub（它们另有存放的地方）。
以为“上线一次”就把所有东西都更新了普通上线只更新主网站；后台那几个取数程序需要单独发布。数据没跟着变，别默认是 bug。
为了“测试一下”动用付费的 AI 额度线上跑的某些 AI 功能用的是按量付费、额度有限的密钥（花的是真钱）。本地试验时不该动用它——这条 AI 知道，你听到“用生产密钥来测”时留个心。
10. 给 Codex / Claude 的提问方式
你会主要通过 Codex / Claude 维护，所以最有效的提问不是“帮我修一下”，而是给它边界。
好的提问（有边界）
“先确认数据来源，别改任何东西。”
“只改页面文案，先别上线。”
“改完先自己验证，再告诉我你验证了什么。”
容易出问题的提问（太笼统）
“刷新一下数据。”
“帮我上线。”
“这个图不对，修一下。”
没有边界，AI 可能动到你没预期的东西。
维护三问（拿不准时就问 AI 这三句）：这是页面问题、数据问题，还是上线问题？这块数据从哪来、多久更新一次？这一步能不能反悔（可回滚、不删线上数据）？