网站终于上线了。
我打开链接，左边的标题、文案和按钮都正常。
右边的球员，却消失了，只剩一个孤零零的 10 好。
页面写完了，代码也成功构建了，但产品还不能算真正完成。
我也是到这个时候才发现，Codex 会写代码，和产品真的能用，是两回事。
这篇想讲的，不是 Codex 多厉害。
是一个普通创作者，怎么把一个模糊的世界杯创意，借助 Codex，做成一个别人真的能打开、能测、能保存、能分享的东西。
生成代码只是开始，真正上线并让别人用起来，才算完成产品。
我把整个过程，倒回到最开始，原原本本说一遍。
创意从哪来的
世界杯热度上来了，我刷到有人用 Codex 做了一个世界杯赛程订阅网站。
挺好的工具，但我在想：除了赛程这种”工具型”产品，还能不能做点更有传播性的东西？
我和 Codex 讨论了几个方向：赛程助手、内容生成器、观赛小工具……都挺实用，但都不太”想分享”。
最后定下来一个方向：世界杯人格测试。
从球队人格改成球星人格
一开始想做”测测你像哪支球队”。
后来想了想，否了。
球队太容易和球迷立场绑在一起，你说用户像巴西，巴西球迷开心，但其他球迷可能不买账。
球星不一样，更具体，更有记忆点，也更适合生成个人结果卡发朋友圈。
最终文案定下来：
2026美加墨世界杯球星人格测试，测测你的性格最像哪位球星。
开发之前，先压力测试这个创意
没有上来就让 Codex 写代码。
先问了自己几个问题：
用户为什么会点开这个测试？
愿不愿意认真做完 12 道题？
测完之后，会不会觉得”这说的就是我”？
为什么愿意保存结果或者分享出去？
世界杯结束之后，这个产品还有没有价值？
想完之后，我对这个项目的定位很清楚：它是一个热点传播型小产品，不是一个长期创业项目。
定位想清楚了，后面每个决策都有了判断标准——不是”这个功能酷不酷”，而是”这个功能配不配这个定位”。
第一版要做成什么样
第一版的范围我定得很死：
首页介绍、12道生活化问题、4个人格维度、8种球星人格、代表球星、动态球衣号码、结果卡、保存PNG、分享、重新测试。
MVP 不是随意做个页面，是用尽可能少的功能，让用户完整走完一次体验。
如果只做了题目，没有结果页，用户做完不知道自己是谁，这不是 MVP，这是半成品。
如果只做了结果页，没有可以保存分享的卡片，用户测完没法带走，传播性就没了。
每个功能都要为”完整走完一次”服务，多一个不要，少一个不行。
参考 MBTI，但没有照搬
设计题目和结果系统的时候，我参考了 MBTI 的玩法逻辑，但不是直接抄。
设计了 4 组球场人格维度：
主动进攻 vs 观察判断。团队协作 vs 个人主导。直觉创造 vs 理性计划。逆境爆发 vs 稳定控制。
每道题只影响一个维度，12 道题测完，生成一个四字母代码，对应一个人格类型和一位代表球星。
最终设计了 8 种球星人格：天才导演、绝境终结者、灵感魔术师、永动发动机、闪电突破者、冷静指挥官、沉默守护者、奇迹替补。
视觉和文案，改了不止一次
视觉风格定的是黑色、荧光绿、蓝色运动笔触，加上球星收藏卡的质感。
首页用了超大中文标题，结果页做成可以保存和分享的球星人格卡，看起来要有”想截图”的冲动。
过程中改了不少地方：
首页标题和说明文案改过几轮。开始测试的按钮文案改过。结果页的信息层级调整过，一开始信息堆得太满，看不出重点。球衣号码和代表球星的对应关系也理顺过。
最开始有个问题——不管测出哪个人格，球衣号码都显示 10 号。
后来才改成根据不同球星动态变化，每个人格对应不同号码。
这个细节我觉得值得单独说一下：用户体验问题常常不是大功能出了问题，而是一眼就能看出来的不一致。
号码不对，用户可能不知道哪里错了，但会觉得”这个东西做得不太对”。这种细节，往往比某个复杂功能缺失更影响第一印象。
本地测试的时候，遇到一个奇怪的报错
页面突然显示”127.0.0.1 拒绝连接”。
我第一反应是代码哪里写崩了。
后来发现不是代码的问题——是我本地的开发服务停掉了，根本没在运行。
这个小插曲让我想清楚一件事：遇到报错的时候，要先判断这是代码问题，还是运行环境问题，还是部署问题。
三种问题的排查方向完全不一样，搞错方向只会越改越乱。
发布到 GitHub Pages，第一次失败
代码写完测完，下一步是真正发布到公开网址。
创建了 GitHub 仓库，配置了自动部署。
第一次部署，失败了。
检查了一遍，代码安装、构建、文件上传，全部成功。
问题出在最后一步——发布阶段失败了，由于 GitHub Pages 这个功能我还没有手动启用。
启用之后，重新部署，网站终于能打开了。
但打开公开网址的瞬间，就是开头说的那个场景——左边文案正常，右边球员图片全部消失，只剩一个孤零零的 10 号。
为什么图片会消失
排查了一下，发现问题出在路径上。
代码里图片资源的引用路径，写的是网站根目录。
但 GitHub Pages 实际把网站发布到了一个子路径下，不是根目录。
本地测试的时候，路径是对的，由于本地就是从根目录跑起来的。一旦发布到线上，路径对不上，图片就读取不到。
修改了资源路径，重新部署，图片恢复正常。
这是这次经历里我觉得最重大的一个发现：
本地能运行，不代表线上能使用。代码成功构建，也不代表产品已经完成交付。
中间这一步，往往是最容易被忽略，也最容易出问题的环节。
最终做出来的东西
公开网站：
kankanliuyi-lgtm.github.io/world-cup-personality-quiz
GitHub 仓库：
github.com/kankanliuyi-lgtm/world-cup-personality-quiz
最终的产品包含：12道测试题、4个人格维度、8种球星人格、动态球衣号码、可保存的PNG结果卡、公开访问网址、GitHub Pages自动部署。
这次经历让我确认了三件事
第一，AI 降低了开发门槛，但没有替代产品判断。
Codex 可以很快帮我写出代码，但球队人格要不要改成球星人格、12道题该怎么设计、定位是热点产品还是长期项目——这些判断，从头到尾都是我在做的。
第二，MVP 不是功能少，是完整闭环。
如果只做了一半，用户就走不完整个体验。功能数量不是重点，能不能完整走一遍才是重点。
第三，生成只是开始，验证和上线才决定产品能不能用。
代码写完、本地跑通，离真正能用还有距离。中间的部署、路径、环境问题，每一个都可能让产品在用户面前直接挂掉。
有句话我想单独拿出来说：
以前一个创意只能停在脑子里，目前我可以和 Codex 一起，把它做成别人真正能打开的产品。
但”做成代码”和”做成产品”之间，隔着的那段路，还是要靠人自己走完。
最后
回到开头那张没有球员、只剩 10 号的页面。
正是这个看起来有点尴尬的故障，让我确认了一件事：
AI 可以快速把想法变成代码，但从代码到产品，中间依旧需要不断判断、测试和修正。
这次我没有只得到一个网页。
我完整经历了一次从创意、产品定义、开发、测试到发布的过程。
下一步，我会找第一批真实用户体验，看看他们是否愿意做完，结果是否准确，是否愿意分享自己的球星人格。
如果你也想测一下自己最像哪位球星，链接放在这里：
kankanliuyi-lgtm.github.io/world-cup-personality-quiz
测完了，欢迎告知我，你测出来的是哪种人格。
© 版权声明
文章由作者编辑发布，如有侵权内容，请通过“联系我们” 的QQ或者邮件进行反馈，我们会及时处理。
相关文章
暂无评论...
