EdgeOne 第一周体验报告

01　优化建议

即使在传统控制台流程内，比起翻文档解决问题，我更倾向于直接问 Agent。

—— 本周亲跑控制台后的真实感受

经过本周对 EdgeOne Pages、Tunnel、Skill+AI、传统控制台四条路径的亲跑体验，建议优化如下（详细复现路径与证据见 02 章）：

02　部署路径对照实验（第一手实验记录）

本章是 01 / 03 / 04 / 05 章所有结论的证据底座。所有截图来自本周亲跑过程，未做任何美化处理。

2.1 实验设置

• Demo 应用：AI 辅助 vibe code 出来的纯静态作品集（index.html + 3 个项目页 + 4 张 PNG 预览图，~3 MB），无构建依赖
• 代码仓库：github.com/latrua/portfolio（HTML 在 portfolio/ 子目录下，是后面卡点 #1 的源头）
• 角色扮演：完全没接触过腾讯云、CDN、DNS、备案的小白
• 计时方式：从「打开 EO 控制台/官网」到「拿到 URL 并能在浏览器里访问」的总用时
• 公平性约束：每条路径只跑一遍，不预读文档；遇到卡点先靠产品自身引导自救，超过 5 分钟才查文档

2.2 对照表

2.3 每条路径的「小白时刻」

路径 A · EO Pages

卡点 #1 · Git 仓库默认搜根目录，子目录里的 HTML 静默不显示（"假成功"）

• 症状：导入仓库后控制台显示「部署成功」，给了 .edgeone.app URL；点开是 404 / 空白页面
• 根因：Pages 默认把仓库根目录当成网站根目录；我的 index.html 在 portfolio/ 子目录里，根目录什么都没有，平台仍然判断「部署成功」
• 自救路径：必须重新进项目设置，手动把「输出目录 / Root Directory」从 / 改成 portfolio 才行
• 体感：最割裂的一刻。部署绿灯亮起，但访问失败——产品没有任何主动提示是子目录的问题，我以为是自己 HTML 写错了，反复检查了十几分钟代码

证据 1.1 · 部署成功后访问得到 404 NOT_FOUND——「假成功」最直观的截图

证据 1.2 · 构建设置中"根目录"默认为 ./，没有任何提示告诉用户「如果代码在子目录里，这里要改」

卡点 #2 · 加速区"三选一"在部署前只有后续自定义域名需要 ICP 备案介绍，默认选项国内访问不通

• 症状：创建项目时让我选加速区——「全球可用区（不含中国大陆）/ 中国大陆可用区 / 全球可用区（含中国大陆）」三选一。三个选项之间的差异、各自要求、各自代价，在选择那一刻控制台只有简短解释
• 后果：默认选了第一个「全球可用区（含中国大陆）」，部署完成后才在某个角落提示「该区不覆盖中国大陆访问」——我转发给国内朋友打不开，又得返回控制台研究
• 体感：把「选择代价最大的那一步」埋在最早最不知情的时候。等我意识到 → 已经付出了沉没成本（部署 + 配置）→ 切换的代价比一开始知道更大

证据 2.1 · 加速区合规说明在部署完成后才在域名管理页弹出——「3 小时预览有效期 / 中国大陆区返回 401」这种关键约束本应在选择那一刻就告知

证据 2.2 · 国内朋友访问时返回 401 UNAUTHORIZED——这是加速区前置告知缺失的最终结果

需和导师同步的疑点：做二次实验的时候，三个区都可以把预览转发给国内朋友打开——不理解是否为 bug。

路径 B · EO Tunnel

卡点 #1 · 按官网步骤，URL 打开是文件浏览器不是网站

• 症状：完全照官方文档操作——告诉 CodeBuddy 我本地项目的位置 → 让 CodeBuddy 阅读 tunnel 的 skill.md 并帮我内网上线这个项目 → 拿到一个 .agent-tunnel.woa.com URL → 浏览器打开看到的是一个漂亮的「All files」卡片列表，而不是我作品集的主页
• 根因：部署模式选错了——把「上线一个静态网站」当成了「分享一个项目目录」

证据 3.1 · Tunnel 官网推荐路径："对 AI 说一句话，它帮你安装 tunneleo、启动服务、生成链接，全程无需手动操作"——但实际跑出来的并不是用户期待的"网站上线"

根因简述：tunneleo 提供 serve（文件分享）和 port（端口转发）两种语义不同的能力，但 SKILL.md 把它们并列写在一起、没有显式区分。Agent 默认匹配最显眼的 serve 例子，于是「上线网站」的意图被翻译成了「文件浏览器」。

证据 3.2 · 实际拿到的：tunneleo 自带的「All files」文件浏览器界面

证据 3.3 · 期望的：作品集主页直接打开

✓ 正确做法（亲跑验证可行）

cd /path/to/portfolio          # 1. 进入作品集目录
python3 -m http.server 8080    # 2. 起一个标准静态服务器（根路径自动指向 index.html）
tunneleo port 8080             # 3. 把这个本地服务暴露成内网 URL

浏览器打开拿到的 URL → 直接进入作品集首页 → 项目卡片正常跳转 → 图片资源全部正常加载。

体感：一脸懵。我做了文档让我做的事，结果跟我期待的不一样——卡点不在动作执行层，而在「动作 → 最终视图」这一段缺失的预期管理。对应建议见 01 章 #1（官网 prompt 区分场景）和 #2（SKILL.md 加最终视图）。

路径 C · Skill + AI

点评：这是一份给已经在云上有域名 + 有源站的运维人员用的「接入加速 / 安全运营 / 看日志」工具包，而不是给开发者把本地项目部署上线的工具包。

description: A comprehensive skill for Tencent EdgeOne ... covering edge acceleration
  (DNS, certificates, caching, rule engine, L4 proxy, load balancing), edge security
  (DDoS protection, Web protection, Bot management), edge media (real-time video /
  image processing), edge development (Edge Functions, EdgeOne Pages), and more.

references/
├── acceleration/   ← 只有 cache-purge / cert-manager / zone-onboarding
├── api/
├── observability/
└── security/

卡点 #2 · CodeBuddy 最终推荐了竞品产品

• 症状：在多次 deploy_folder 卡死后，CodeBuddy 给出了「建议使用竞品」的建议
• 根因：CodeBuddy 拿到错误后没有「问用户 → 控制台兜底 → CLI 兜底」的三档自愈逻辑，直接把锅甩给用户，并越界推荐了竞品。缺失的产品红线：没有任何地方写过「Agent 不得在 EdgeOne 部署失败时建议非腾讯云的部署平台」——这是一条没人写但绝对不该被越过的线

证据 4 · CodeBuddy 在 Pages 部署失败后明文建议「使用 GitHub Pages 部署（免费）」「或使用 Vercel/Netlify 等平台一键部署」（红框处）——这是越过产品红线的直接证据

路径 D · 传统控制台流程（站点接入加速）

实验设置差异：路径 A/B/C 都是「我有一份本地代码想上线」场景；路径 D 是另一个场景——「我已有源站/域名，想接入 EO 加速」。两个场景互补，本周后期补做。

2.4 阶段性总结

• 最快拿到 URL：Tunnel（5 分钟内）。原因：纯本地启动，不涉及云端构建和域名
• 最适合长期对外：Pages。原因：内容存云端、自动 CDN、关机不影响——但前提是已经懂加速区差异 + 已经有备案过的域名
• 最容易劝退：Skill + AI。原因：SKILL 描述层承诺了 Pages/Edge Functions 但实现层未交付，Agent 在多次失败后越界推荐竞品——这是本周四条路径中唯一彻底没拿到 URL 的一条
• 最被错配的预期：Tunnel。原因：文档把动作写清了，但没把「用户最终看到什么」写出来，导致按文档执行依然懵
• 最考验小白先验经验：传统控制台流程。原因：流程完整、文档齐全，但按"能力"组织而非按"用户目标"组织，每一步都是选择题——这条对小白用户最不友好，反向证明「按场景组织」是产品该补的能力

03　Agent 时代的 B 端 user journey 重构

图 · 从「用户逐步操作」到「用户表达目标 + Agent 拆解执行」——新设计重点是控制权如何下放、风险节点如何收回

3.1 观察到的变化

Agent 让 B 端用户旅程从「用户逐步操作产品」变成「用户表达目标，Agent 代为拆解和执行」。

3.2 暴露的问题

控制权下放后，用户不再只关心 Agent 能不能完成任务，还会关心：

• Agent 是否理解真实业务语境？
• Agent 是否会越权执行？
• Agent 是否会影响生产环境？
• Agent 出错后是否可回滚、可追责？

3.3 对应的产品解法

B 端 Agent 不应默认全自动，而应设计分层接管机制：

3.4 结论

B 端 Agent 产品的关键，不是简单缩短用户路径，而是设计一套「可下放、可确认、可收回」的控制权机制。

EdgeOne Skill 基本遵循「可控委托」原则：低风险查询和分析可自动执行，涉及状态变更和高风险操作时要求用户确认；但仍可在统一风险分级、回滚提示和审计追踪上进一步增强。

04　如何让 Agent 们更好地发现或推荐 EO（本质 GEO）

让 Agent 推荐 EO，不是让它"看见广告"，而是让它在解决用户任务时，能判断 EO 是一个可信、适合、可执行的选项。

图 · 让 Agent 发现并推荐 EO 的五件事——可发现 / 可理解 / 可比较 → Agent 判断 → 可验证 / 可调用 → 被推荐

具体做 5 件事 + EO 当前现状对照

5 件事中"可发现 / 可验证"的最小起点已沉淀为 01 章 #4（llms.txt + 错误码字典）；"可理解"的场景化表达已沉淀为 01 章 #7（5 类路径模板）。

05　友商对比

5.1 友商进展（截至 2026-05-13）

5.2 EO 差异化机会

1. 把 Skill 范式做深做厚——海外没人走完（Cloudflare 选了 MCP、Vercel 选了 v0），是真正的窗口

结语

这份报告的所有判断都来自一周内对四条路径的亲跑，不来自二手资料；所有建议都从这些路径的具体卡点抽离而来，不来自抽象推演。

附录

A. 友商资料原始引用

B. 写作纪律自审

1. ✅ 每个观点后挂证据：截图 / 数据 / 链接
2. ✅ 措辞禁用清单（「我感觉/可能/也许/应该会/大概率」）已全部清理
3. ✅ 倒金字塔：每段第一句话能独立成立

C. 旁路项目：CDN 行业洞察 Agent

• 工作流：信号源 → 二次验证 → 标签化 → 三段式归并报告（事实 / 推论 / 对 EO 的含义）
• 体感：最大的价值不是「比人快」，而是「比人持续」——每天都跑，不会因为忙而漏看
• 明天就能做：把这个 Agent 的输出接入产品组飞书/企微群，每天早 9 点同步昨日友商动态
• 下个季度可以做：做成 EO 内部产品，让 SA、产品、研发、技术品牌从同一个事实底座出发