当前位置：首页 > news >正文

AI 写完了，别人却看不到：Vibe Coding 作品如何秒级公开

news 2026/8/10 13:14:34

AI 写完了，别人却看不到：Vibe Coding 作品如何秒级公开

Vibe Coding 把“做一个网页”的门槛压得很低。

说清楚想要什么，代码助手可以补出页面结构、样式和交互；再来几轮调整，原本需要半天才能拼出来的小作品，很快就能在浏览器里运行。问题也恰好出现在这里：页面能打开，不等于别人能打开。

localhost只对当前电脑有效，127.0.0.1更像是给开发者留的一扇内门。想把作品发给朋友，通常要再准备一台服务器，处理域名、部署、证书和端口。作品本身已经完成，分享却还没有开始。

这次让代码助手做了一张写给朋友的数字明信片。页面完成后，再把它从本机送到公网，看看这份 Vibe Coding 作品能不能真正被别人打开。

转折点放在 NATAPP 内网穿透服务上：不先搭一台专门的服务器，而是让本地页面继续运行，再给它接上一条公网入口。这样要验证的就不再是“能不能把网页写出来”，而是“写完之后，别人能不能直接打开”。

先把作品做出来

页面需求从一开始就限定得比较具体：纯 HTML、CSS 和 JavaScript，不引入后端依赖；移动端优先；文字不能溢出；以及一只牛博，以及https://natapp.cn/这个网址。

这种描述比“帮忙做一个好看的页面”更适合 Vibe Coding。视觉方向、交互动作和约束条件先写清楚，后续修改才有可以对照的东西。页面做成单页，也让后面启动本地服务变得简单，不需要先处理数据库或接口。

最终页面采用左右分栏：左侧是问候、收件人和交互入口，右侧是牛博的插画。手机端再把插画移到上方，文字顺着往下排。明信片的形态保留了边框、邮票和纸胶带这些细节，但没有继续堆叠卡片和按钮，浏览时更像是在读一张网页做成的纸片。

这类小作品很适合用来检验 Vibe Coding 的边界。页面的第一版往往很快，真正花时间的是把“看起来像个页面”收紧为“真的能送出去”：主图不能依赖一个随时失效的临时地址，文字要在窄屏里折行，按钮必须有明确动作，页面加载后还要保持完整的视觉秩序。明信片不需要复杂业务逻辑，却把前端作品常见的几件事都带了进来。

本地能看，还差一个可分享的地址

页面第一次启动在4173端口。浏览器能正常打开，交互也没有问题，但这个地址只在开发机上成立。用手机访问时，浏览器并不知道另一台电脑上的localhost指向哪里。

端口本身不是技术难点，端口和隧道配置保持一致才是。免费 Web 隧道创建时，本地端口填写为5173，因此本地静态服务也切到5173。先确认端口未被占用，再启动服务，最后用curl检查返回状态，避免把“页面打不开”和“隧道没连上”混在一起排查。

这里的验证结果是一个很朴素的HTTP/1.0 200 OK。它不能说明公网已经可用，只说明本机的 Web 服务已经在正确的端口上工作。把问题分开后，后面出现错误时，判断会快很多。

本地页面的最后一次检查放在浏览器里完成：牛博插画能加载，正文没有被裁掉，按钮可以点击，打开祝福后页面不会突然横向滚动。到这里，Vibe Coding 负责的部分已经结束，作品也具备了被别人看到的条件，只是还缺一个外部入口。

免费 Web 隧道的配置很短

在 Natapp 后台创建免费隧道时，协议选择 Web，本地端口填写5173。这一页还有一个容易被忽略的地方：免费隧道的公网域名由系统随机分配，适合临时演示和测试；如果需要长期固定地址，再考虑固定域名或付费隧道。

隧道创建成功后，在隧道列表中取得对应的authtoken。客户端靠它登录并建立隧道，所以它应该被当作凭证保存。配置完成后，客户端只需要读取本地配置，运行时等待连接状态变为 Online。

到这一步，Natapp 还没有把代码搬到云服务器。页面依旧运行在本机，客户端通过出站连接连到中转服务，外部请求再沿着这条连接回到本地5173端口。这个结构也解释了为什么本地网络没有公网 IP，仍然可以被外部访问。

authtoken的角色也要分清。它用于客户端和隧道服务之间的身份识别，并不是发给访问者的网页密码。页面需要临时对外分享时，浏览器访问的是系统分配的公网地址；是否对访问者额外启用访问令牌、IP 规则或应用自身登录，则是另一层控制。把两者混成一个概念，最容易在演示完成后留下不必要的安全口子。

让本地页面真正走到公网

客户端启动后，终端会返回一个随机的公网地址。这里的操作没有重新部署项目，也没有改动页面代码，只是为本地服务增加了一条对外可达的路径。

公网地址第一次拿到时，最值得做的动作不是马上转发给别人，而是从另一条网络验证。开发机自己访问成功，只能说明本机到隧道的路径没有问题；手机关闭 Wi-Fi 后再打开，才能证明请求确实经过了公网入口。

这张明信片在浏览器中的呈现和本地版本一致：牛博插画、问候文字和展开祝福都还在，外链也能继续点击。对分享者来说，发送出去的不再是一个只能自己解释的localhost，而是一条别人点开就能看到的地址。

手机验证又多了一层。很多本地地址发到微信里，接收者还要先复制链接、切到浏览器，再处理一次打开动作；这次直接把公网域名发到微信，内置页面可以正常加载明信片，没有额外跳转。首屏插画和标题一起出来，分享动作从“解释怎么打开”变成“点开就能看”。这里的“秒开”是这次设备、网络和页面资源规模下的实际观察，不把它延伸成所有微信版本和所有网络条件下的固定结果。

手机画面也暴露了一个容易被忽视的事实：公网地址首先要适合被分享。桌面浏览器里看起来正常的页面，放进微信内置环境后还要经得住窄屏、地址栏和长页面的共同挤压。明信片的插画被放在首屏上方，标题和问候顺着向下排，阅读路径没有被切断。

“秒级公开”到底指什么

这里的秒级，不是把代码从零写完只需要几秒，也不是承诺所有网络环境都拥有相同的响应时间。它指的是：本地服务已经正常运行后，启动客户端、获得公网地址，再让外部设备打开页面，这段发布动作很短。

为了观察访问体验，使用多地 Ping 工具对公网域名做了节点测试。中国地区 230 个监测点参与测试，页面中的节点全部显示为绿色；表格给出平均值为 36ms，个人感觉很不错了。

公网地址不是把整个本机目录交出去

静态页面能被公网访问，不代表同一个目录里的所有文件都应该被访问。页面资源、运行日志和客户端配置最好分开放：网页根目录只保留index.html、插画和确实要被浏览器加载的静态资源；authtoken配置文件放在根目录之外，并且不提交到仓库。这样即使服务目录被直接列出或有人猜测常见文件名，也不会顺手拿到客户端凭证。

临时展示可以用随机域名，发给熟人之前也应该先用无痕窗口打开一次。页面能否正常加载、外链是否有效、浏览器地址栏是否真的已经不是127.0.0.1，这三件事花不了一分钟。需要长期开放的内容，则要把访问令牌、IP 规则、应用登录和访问日志一起放进计划里。隧道只负责把入口带到公网，谁能进来、进来后能做什么，仍然要由页面和访问规则共同决定。