Vibe Coding 把“做一个网页”的门槛压得很低。
说清楚想要什么，代码助手可以补出页面结构、样式和交互；再来几轮调整，原本需要半天才能拼出来的小作品，很快就能在浏览器里运行。问题也恰好出现在这里：页面能打开，不等于别人能打开。
localhost 只对当前电脑有效，127.0.0.1 更像是给开发者留的一扇内门。想把作品发给朋友，通常要再准备一台服务器，处理域名、部署、证书和端口。作品本身已经完成，分享却还没有开始。
这次让代码助手做了一张写给朋友的数字明信片。页面完成后，再把它从本机送到公网，看看这份 Vibe Coding 作品能不能真正被别人打开。
natapp-ezgif.com-optimize
转折点放在 NATAPP 内网穿透服务 上：不先搭一台专门的服务器，而是让本地页面继续运行，再给它接上一条公网入口。这样要验证的就不再是“能不能把网页写出来”，而是“写完之后，别人能不能直接打开”。
先把作品做出来
页面需求从一开始就限定得比较具体：纯 HTML、CSS 和 Ja vaScript，不引入后端依赖；移动端优先；文字不能溢出；以及一只牛博，以及 https://natapp.cn/ 这个网址。
这种描述比“帮忙做一个好看的页面”更适合 Vibe Coding。视觉方向、交互动作和约束条件先写清楚，后续修改才有可以对照的东西。页面做成单页，也让后面启动本地服务变得简单，不需要先处理数据库或接口。
把明信片需求交给代码助手
最终页面采用左右分栏：左侧是问候、收件人和交互入口，右侧是牛博的插画。手机端再把插画移到上方，文字顺着往下排。明信片的形态保留了边框、邮票和纸胶带这些细节，但没有继续堆叠卡片和按钮，浏览时更像是在读一张网页做成的纸片。
这类轻量的小作品，其实特别适合拿来测试 Vibe Coding 的能力边界。第一版页面通常出得很快，真正耗时间的，往往是把“乍一看像那么回事”打磨成“确实可以直接发出去”：主图不能绑在一个随时可能失效的临时地址上，文字到了窄屏场景得能自然换行，按钮必须对应清晰明确的动作，页面加载完成之后，整体视觉也得稳得住、不能散。明信片看似不涉及复杂的业务逻辑，但前端作品里那些最常见、也最容易暴露问题的环节，它几乎一个不落都带上了。
本地能看，还差一个可分享的地址
页面第一次启动在 4173 端口。浏览器能正常打开，交互也没有问题，但这个地址只在开发机上成立。用手机访问时，浏览器并不知道另一台电脑上的 localhost 指向哪里。
第一次本地预览页面
端口本身不是技术难点，端口和隧道配置保持一致才是。免费 Web 隧道创建时，本地端口填写为 5173，因此本地静态服务也切到 5173。先确认端口未被占用，再启动服务，最后用 curl 检查返回状态，避免把“页面打不开”和“隧道没连上”混在一起排查。
将本地页面端口调整为 5173
这里的验证结果是一个很朴素的 HTTP/1.0 200 OK。它不能说明公网已经可用，只说明本机的 Web 服务已经在正确的端口上工作。把问题分开后，后面出现错误时，判断会快很多。
在本地 5173 端口打开明信片
本地页面的最后一次检查放在浏览器里完成：牛博插画能加载，正文没有被裁掉，按钮可以点击，打开祝福后页面不会突然横向滚动。到这里，Vibe Coding 负责的部分已经结束，作品也具备了被别人看到的条件，只是还缺一个外部入口。
免费 Web 隧道的配置很短
在 Natapp 后台创建免费隧道时，协议选择 Web，本地端口填写 5173。这一页还有一个容易被忽略的地方：免费隧道的公网域名由系统随机分配，适合临时演示和测试；如果需要长期固定地址，再考虑固定域名或付费隧道。
创建免费 Web 隧道并配置本地 5173 端口
隧道创建成功后，在隧道列表中取得对应的 authtoken。客户端靠它登录并建立隧道，所以它应该被当作凭证保存。配置完成后，客户端只需要读取本地配置，运行时等待连接状态变为 Online。
在隧道列表中取得 authtoken 和公网地址
到这一步，Natapp 还没有把代码搬到云服务器。页面依旧运行在本机，客户端通过出站连接连到中转服务，外部请求再沿着这条连接回到本地 5173 端口。这个结构也解释了为什么本地网络没有公网 IP，仍然可以被外部访问。
authtoken 的角色也要分清。它用于客户端和隧道服务之间的身份识别，并不是发给访问者的网页密码。页面需要临时对外分享时，浏览器访问的是系统分配的公网地址；是否对访问者额外启用访问令牌、IP 规则或应用自身登录，则是另一层控制。把两者混成一个概念，最容易在演示完成后留下不必要的安全口子。
让本地页面真正走到公网
客户端启动后，终端会返回一个随机的公网地址。这里的操作没有重新部署项目，也没有改动页面代码，只是为本地服务增加了一条对外可达的路径。
让代码助手使用本地配置启动公网隧道
公网地址第一次拿到时，最值得做的动作不是马上转发给别人，而是从另一条网络验证。开发机自己访问成功，只能说明本机到隧道的路径没有问题；手机关闭 Wi-Fi 后再打开，才能证明请求确实经过了公网入口。
通过公网地址打开明信片
这张明信片在浏览器中的呈现和本地版本一致：牛博插画、问候文字和展开祝福都还在，外链也能继续点击。对分享者来说，发送出去的不再是一个只能自己解释的 localhost，而是一条别人点开就能看到的地址。
手机验证又添了新门槛。以往，不少本地地址发到微信里，接收者得先复制链接、切到浏览器，再处理一次打开动作；这次直接把公网域名发到微信，内置页面就能正常加载明信片，没了那些额外跳转。首屏插画和标题一并发出，分享动作从“解释怎么打开”变成了“点开就能看”。当然，这里的“秒开”是这次设备、网络和页面资源规模下的实际观察，不把它延伸成所有微信版本和所有网络条件下的固定结果。
在微信内直接打开公网明信片
手机画面也暴露了一个容易被忽视的事实：公网地址首先要适合被分享。桌面浏览器里看起来正常的页面，放进微信内置环境后还要经得住窄屏、地址栏和长页面的共同挤压。明信片的插画被放在首屏上方，标题和问候顺着向下排，阅读路径没有被切断。
“秒级公开”到底指什么
这里的秒级，不是把代码从零写完只需要几秒，也不是承诺所有网络环境都拥有相同的响应时间。它指的是：本地服务已经正常运行后，启动客户端、获得公网地址，再让外部设备打开页面，这段发布动作很短。
为了观察访问体验，使用多地 Ping 工具对公网域名做了节点测试。中国地区 230 个监测点参与测试，页面中的节点全部显示为绿色；表格给出平均值为 36ms，个人感觉很不错了。
公网域名的多地延迟测试结果
公网地址不是把整个本机目录交出去
静态页面能被公网访问，不代表同一个目录里的所有文件都应该被访问。页面资源、运行日志和客户端配置最好分开放：网页根目录只保留 index.html、插画和确实要被浏览器加载的静态资源；authtoken 配置文件放在根目录之外，并且不提交到仓库。这样即使服务目录被直接列出或有人猜测常见文件名，也不会顺手拿到客户端凭证。
临时展示可以用随机域名，发给熟人之前也应该先用无痕窗口打开一次。页面能否正常加载、外链是否有效、浏览器地址栏是否真的已经不是 127.0.0.1，这三件事花不了一分钟。需要长期开放的内容，则要把访问令牌、IP 规则、应用登录和访问日志一起放进计划里。隧道只负责把入口带到公网，谁能进来、进来后能做什么，仍然要由页面和访问规则共同决定。
