Cursor Cloud、Grok Bot 与 Linear：以 yindongliang.com 为例的开发测试与观测闭环

AI 参与说明（Agent：Grok）：本文由 Grok 根据公开站点 yindongliang.com、开源站点仓（现行称呼 tcitry-blog，历史名 tcitry.github.io）与内容仓 tcitry/Blog 的既有公开约定协助整理，整理日期 2026-09-12；同日补充强调「手机指挥、不必坐本机电脑」的便利性。执行入口 Grok Bot；模型标识与 reasoning effort 未取得运行记录；提供方 xAI。示例仅覆盖上述公开站点与公开仓库的工作方式，不涉及任何私有产品；文中未写入任何密钥、账号 ID、Webhook URL 或本机绝对路径。能力边界以官方文档与站内 Agents.md 当日约定为准，不把厂商营销表述当作已在本环境复现的结果。

阅读前先看这几个词

下文用公开站点 yindongliang.com 说明一条「需求 → 编排 → 实现 → 发布 → 观测 → 回填」闭环。英文产品名在术语表后保持固定写法。

先说结论

这条闭环把内容仓与站点仓的发布节奏拆开：内容仓 Blog 可以在质量检查后随时推 main；站点仓（现行称呼 tcitry-blog）的远端 main 就是 production，不能随手推送「保存进度」。

它的核心便利性是：作者不必再坐回本机电脑，把开发、测试、观测一整套都做完。日常用手机（或任意轻客户端）在聊天里下指令、看摘要、做关键审批即可；真正占屏幕、占 CPU、要登录会话的工作，默认落在 Agent Computer 与 Cursor Cloud。这不是另一条旁路流程，而是同一条闭环的默认使用方式。

职责上：

• 作者 负责目标、边界与关键确认：在手机上发 Issue 意图、回复审批、阅读摘要；不必为了「看一眼页面 / 跑一下检查」回到本机 IDE。
• Grok Bot 负责编排：读 Linear、调 MCP、跑 Routine、在 Agent Computer 上做只读核验与截图，需要改仓库代码时交给 Cursor Cloud。
• Cursor Cloud 负责在已授权的 GitHub 仓库实现、检查与开 PR；站点仓合并到 main 才进入 Cloudflare 生产链路。
• 前端视觉 QA 以 Astro 构建产物 / 最终 URL 为判据，对照 Blog 源文件，而不是编辑器预览；截图与浏览器核对也在 Agent Computer 完成，再把结论回传到聊天与 Linear。
• Cloudflare Observability 看 Worker 请求与错误；GA4 看会话与互动。两者互补：Worker 有请求，不代表读者在认真读；静态资源直出时也可能几乎看不到 Worker 日志。

flowchart TB
  phone["手机聊天<br/>下指令 · 审批 · 看摘要"] --> linear["Linear<br/>Project / Issue"]
  phone --> grok["Grok Bot<br/>编排 · MCP · Routine"]
  linear --> grok
  grok -->|"桌面 / 浏览器 / 截图"| box["Agent Computer"]
  grok -->|"编码改动"| cloud["Cursor Cloud<br/>实现 · 检查 · PR"]
  cloud -->|"站点仓谨慎合并 / 内容仓可独立推 main"| main["GitHub main"]
  main --> cf["Cloudflare<br/>Workers Builds + Static Assets"]
  cf --> obs["Observability<br/>Worker 请求 / 错误"]
  cf --> ga4["GA4<br/>会话 / 渠道 / 互动"]
  box --> qa["视觉 QA<br/>产物 HTML / 最终 URL"]
  cf --> qa
  qa -->|"截图 · 差异 · 新建 Issue"| linear
  obs -->|"摘要回填"| linear
  ga4 -->|"摘要回填"| linear
  linear -->|"摘要 / 状态"| phone

1. Linear：把目标与验收写进 Issue

公开实践里，内容相关工作落在 Linear 项目 Blog；站点工程相关工作落在项目 yindongliang.com。这样内容交付与站点发布可以并行跟踪，又不会把「改一篇 Markdown」和「改 Worker / 主题」混在同一条验收标准里。

一份可用的 Issue 通常至少包含：

• 目标：读者可见结果或工程结果是什么（例如某篇 Agents 文档上线、某导航入口可点）。
• 验收：以最终 URL 或构建产物可核对的条件为准，而不是「源文件已保存」。
• 边界：只动内容仓还是也动站点仓；是否允许推站点 main。

完成时，Done 评论应留下可核对痕迹：文件路径、提交 SHA、必要时生产 URL。这样后续 Observability / GA4 摘要、视觉 QA 回填，都能挂回同一条 Issue，而不是散落在聊天里。

2. Grok Bot：编排默认发生在 Agent Computer 上

Grok Bot 适合做闭环的编排层，而不是把所有编码都挤在同一个长对话里，也不是把作者拴回本机电脑：

• 用 MCP 读取或更新 Linear Issue、查询 Cloudflare 侧只读信息（以当前已连接的 Connector / MCP 为准）。
• 用 Routine 做周期性摘要（例如 Observability 摘要），把「信号」写回 Linear，并在聊天里用短结论通知作者；作者用手机就能跟进。
• 默认在共享的 Agent Computer 上工作：读公开页、截图、整理 Markdown、对照产物。除非作者点名本机路径或明确要求使用本机，否则不要改到作者的笔记本电脑上操作。
• 需要改 GitHub 仓库代码、跑仓库内检查、开 PR 时，把实现交给 Cursor Cloud，并在委派说明里写清仓库、分支约束、验收与不得推送站点 main 的条件。

便利性验收可以很具体：作者离开本机桌面后，仍能完成「开任务 → 看实现进展 → 审截图 / 摘要 → 批准合并边界 → 看观测回填」；需要坐回电脑的步骤应只剩少数真正需要本机文件或本机硬件的例外。

编排时仍要遵守审批边界：发送、删除、改生产配置、调用写权限工具，应停在人工确认点（确认也可以在手机上完成）。只读核验与草稿可以先跑完再汇报。

3. Cursor Cloud：实现落在 GitHub，站点 main 即生产

Cursor Cloud 在已连接的 GitHub 仓库上改代码、跑测试或检查、提交并开 PR。对 yindongliang.com 这条链路，最重要的仓库边界是：

内容仓可以「随时提交」不等于可以跳过渲染与链接检查；站点仓「能推」不等于「该推」。主题改动应先进入独立主题仓，再由站点固定来源与 lockfile 消费——本文不展开主题仓细节，只强调：生产发布入口是站点 main，不是内容仓 main。

4. 前端视觉 QA：以构建产物为最终导向

站内约定写得很清楚：内容是否正确、可读、可达，判据是 Astro 构建后的 HTML 与最终 URL，而不是 Obsidian 或其他编辑器内的预览效果。视觉核对同样不必作者打开本机浏览器：由 Agent Computer 打开页面、截图，再把关键帧与结论送回聊天 / Linear。

Agent 侧可执行的核对顺序是：

1. 打开预览环境或生产 URL（以任务允许的环境为准）。
2. 在关键节点截图：首页入口、文档导航、正文标题与加粗、配图、窄屏布局。
3. 对照三层：Blog 源文件 → Astro dist/ HTML → 最终 URL。
4. 检查导航是否可达、图片是否走公开 CDN 模式（公开约定为 https://cdn.yindongliang.com 一类路径）、CJK 加粗是否踩 CommonMark 定界陷阱、响应式是否可读。
5. 发现缺陷时新建或回填 Linear Issue，再由 Cursor Cloud 修源文件或站点工程；修完后仍以产物 HTML 复验。

CJK 加粗是常见假阳性来源：句末标点必须放在闭合 ** 之外；否则源文件「看起来加粗了」，产物里却是字面量星号。视觉 QA 应直接看渲染结果，而不是只搜 Markdown。

5. Cloudflare：构建、静态托管与 Observability

对 yindongliang.com，公开技术路径是：站点工程构建出静态 dist/（及搜索索引等），由 Workers Static Assets 提供访问；Workers Builds 连接站点 main，在云端执行构建与部署。手动 Wrangler 发布只应视为备用，不是日常主路径。

观测时注意边界：

• Observability 面向 Worker 请求、错误与相关日志。文章主体若以静态资源方式直接提供，可能几乎没有可归因到业务 Worker 脚本的请求日志；不能把「控制台很安静」误读成「没有流量」。
• 内容更新触发生产构建时，常见机制是 Deploy Hook（向配置好的 URL 发 POST）。Hook 返回成功只表示构建请求被接受，不表示生产内容已更新。具体 secrets、Hook URL、是否已接通，以站点仓当前部署文档与平台记录为准——本文不复述、不发明任何密钥或账号侧配置。
• 发布是否成功，以生产域名上的实际页面与验收记录为准，不以 GitHub check 绿勾或内容仓提交成功代替。

官方能力入口见文末 Cloudflare 文档链接；账户内菜单名称与配额可能变化，接入前应对照当日控制台。

6. GA4：会话与互动，补上「请求 ≠ 阅读」

Cloudflare 侧回答的是「边缘 / Worker 看见了什么请求」；GA4 回答的是「浏览器里发生了怎样的会话与互动」。二者不要互相替代：

• 用官方 GA4 界面查看 sessions、渠道、互动类指标即可满足大多数个人站点复盘。
• 可选地，存在托管的 GA4 MCP 连接器（见站内 Ryze AI 文），便于在助手里做只读查询；不是本闭环的必选项，也未在本文实连。
• 明确边界：Workers 日志条数 ≠ pageviews，更不等于「认真读完」。静态直出、缓存命中、爬虫与真实阅读，都会让两侧数字对不上；解读时应说明口径，而不是强行对齐。

把 GA4 摘要写回 Linear 时，只写可公开的聚合结论与时间范围，不要粘贴属性 ID、原始导出或含个人可识别信息的细表。

便利性清单：人可以不在本机电脑前

把「能不能在手机上把事办完」当成闭环是否成型的验收项，而不是额外故事线：

1. 下指令：作者在手机聊天里描述目标与边界，Grok Bot 写入或更新 Linear Issue。
2. 做实现：编码与仓库检查在 Cursor Cloud；本地文件整理、截图、只读打开页面在 Agent Computer。
3. 做确认：需要人工批准的步骤，用短问题 / 摘要回到手机；不要求作者为了点一次「继续」回到 IDE。
4. 看结果：视觉 QA 截图、Observability / GA4 摘要回填 Linear，并在聊天给一句话结论。
5. 例外才回本机：仅当任务依赖作者本机路径、本机硬件，或作者明确要求时，才转到本机电脑。

脱敏边界

本文可以写、且已经写到的：

• 公开域名、公开仓库名与历史名对照、公开 CDN 主机名模式。
• 内容仓 / 站点仓的分支角色，以及「站点 main = production」这一工程约束。
• 产品级能力名称：Linear、Grok Bot、Cursor Cloud、Workers Static Assets、Workers Builds、Observability、GA4、Deploy Hook。

本文故意不写、读者也不应在公开文中寻找的：

• 任何 API token、Deploy Hook URL、.env / .dev.vars 内容、OAuth client secret。
• Linear / Cloudflare / GA4 的账号 ID、属性 ID、Zone 数量、团队 slug 或内部项目代号。
• 私有产品名、内网路径、未公开的预览 Worker、未验收的配置细节。
• 伪造的流量数字、虚构的「已上线」状态，或把代码准备完成说成生产已切换。

跨项目调研若再沉淀公开文，只保留可核验的公开能力与通用流程；删掉项目名、改称「本应用」并不等于完成脱敏。

关联阅读

• Grok Bot 实践指南：官方与社区最佳实践、使用方法与适用场景：共享 Agent Computer、审批模型、Skill / Routine 演进与适用场景分级。
• Ryze AI Google Analytics MCP：托管 GA4 工具、接入方式与选型边界：可选的托管 GA4 只读 MCP；本闭环不依赖它。
• Context7 源码分析：技术架构、MCP 运行原理与检索链路：另一类 MCP facade 与托管边界，便于理解「助手调工具」与「源系统权威」的分工。

资料来源

站点仓远端 URL 可能仍使用历史仓库名；文中统一用现行称呼 tcitry-blog，需要精确 clone / repo 字段时再查实际 GitHub 标识。Deploy Hook、构建 secrets 与首次上线验收状态，请直接查阅站点仓部署文档与 Cloudflare 控制台记录，不要从本文反推。