不会写代码？用Codex从零开发AI剧本杀并上线全流程复盘

不会写代码能不能靠 Codex 做出一款能上线的 AI 剧本杀能但有个前提你得愿意把自己当成项目的产品经理和测试员而不是把 Codex 当成许愿池。这篇文章是我用 Codex 从零做 AI 剧本杀 Web 应用、并自动发布上线的一次完整复盘。下面不会只夸 AI 编程多省事也不避讳中间那些环境报错和部署坑。核心链路按实际执行顺序拆开账号准备、CLI 安装、需求拆解、前后端分离、接口联调、部署发布、常见报错排查。适合想用 AI 编程工具做出第一个真实项目的零基础或弱基础读者。1. 先搞清楚Codex 到底能帮你做到哪一步1.1 它解决的不是“替你写代码”而是“把需求变成能跑的系统”Codex 这类 AI 编程智能体和普通的代码补全工具不是一回事。它不只是在你打字的时候提示下一行而是可以读你项目目录里的文件、新建文件、修改已有代码、执行命令、根据报错继续调整。换句话说它更像一个坐在你旁边、能听懂人话的实习生你说“给我加一个创建游戏的接口”它真的会去改后端代码并告诉你接口路径。但这里有个容易被误解的地方AI 能写代码不代表你完全不用动脑。真正决定项目能不能成的是你能不能把一个模糊的想法拆成 AI 能理解的需求。比如“做个剧本杀”这句话太含糊AI 不知道你要做网页版还是小程序不知道要不要登录不知道剧情是手动配置还是 AI 现场生成。需求越具体生成结果越接近你想要的东西。对不会写代码的人来说Codex 的价值不是替代编程学习而是把“从 0 到 1 做出一个能跑的东西”这个门槛大大降低。你不需要懂语法细节但你需要懂流程、懂数据结构、懂怎么验证结果。这个认知如果不建立后面每一步都会卡住。1.2 适合什么人不适合什么人我把适合和不适合的人群分成两类你可以先对号入座。适合尝试的人不太适合的人有明确的小项目想法愿意先做 MVP想一上来就做复杂电商、支付、实时多人游戏愿意看日志愿意把报错原样贴给 AI遇到红字就慌截图都截不完整能接受“先跑通再优化”要求一次生成就完美不接受反复调整愿意了解端口、数据库、部署等基础概念完全拒绝接触命令行和任何配置我见过不少朋友卡住不是因为 AI 能力不够而是因为心态不对。他们希望 Codex 一句话生成一个完美成品生成完发现有问题不知道怎么描述问题也不会看 AI 给的修复建议。实际上AI 编程工具的使用方式和搜索引擎很像你会不会问问题决定了你能不能找到答案。1.3 对“AI 剧本杀”的合理预期我这次做的 AI 剧本杀指的是一种网页版互动推理游戏玩家选择一个剧本阅读角色背景AI 主持人推进剧情玩家选择行动、调查线索、指认凶手最后结算结局。这个范围是相对合理的 MVP。第一版我不建议做太多花活。实时多人联机、语音聊天、3D 场景、可视化剧本编辑器这些都很酷但对第一个 AI 生成的 Web 项目来说复杂度会成倍增加。前后端都要做、部署也要做任何一环出问题你都没有足够经验去排查。先把单剧本、单玩家、网页互动的流程跑通比什么都重要。2. 出发之前先把环境准备到位2.1 账号、CLI 安装与登录Codex 的使用方式大致分两类一是直接在终端里跑命令行工具二是在桌面端或编辑器插件里使用。不管哪种方式通常都需要先完成登录并确保命令行工具能被系统找到。以命令行方式为例常见动作大概是这样的# 登录账号 codex login # 进入项目目录 cd ai-script-murder # 启动交互式会话 codex # 或者直接执行一次性任务 codex exec 为这个项目生成 README并列出启动命令不同版本的安装方式和命令入口可能有差别落地时以你安装的版本为准。如果你是第一次用我的建议是先在任意空目录里跑一次codex让它随便生成一个测试文件确认工具本身可以正常工作再开始做项目。顺序反过来的话你会在“工具问题”和“代码问题”之间来回横跳。2.2 最常见的启动报错找不到 Codex CLI我用的时候遇到过一个很典型的报错大概意思是unable to locate the codex cli binary. set codex cli path or ensure the ...。翻译过来就是桌面端或编辑器插件在调用命令行工具时找不到名为 Codex CLI 的可执行文件。这个问题不是代码问题是环境问题。排查顺序通常是确认命令行工具是否真的安装了直接在终端输入codex --version看看有没有输出。确认安装位置是否在系统 PATH 中。如果提示 command not found说明终端的查找路径里没有这个程序。如果桌面端或插件里有 “Codex CLI Path” 之类的设置项手动指定 CLI 的可执行文件路径。改完配置后完全退出桌面端或编辑器再重新打开让配置生效。这类报错第一次见会觉得吓人其实原因很直白界面工具和命令行工具是两层东西界面工具本身不带编程能力它需要调用命令行工具来干活。找不到 CLI界面自然启动不了。2.3 默认模型还是第三方模型服务Codex 默认的模型配置对新手最友好。你不需要关心模型名、接口地址、参数格式登录之后就能用。但我注意到很多教程会教你把 Codex 接到第三方模型服务上比如接入 DeepSeek 或其他兼容接口目的通常是降低成本或使用自己已有的 API Key。这条路并不是不能走但要注意兼容性问题。Codex 对模型能力有要求如果你配置了它不支持的模型名或者模型的接口返回格式不匹配请求阶段就会直接报错提示这个模型不支持。排查时不要把锅扣在“AI 不会写代码”上先检查配置的接口地址、模型名、Key 是否匹配。我的建议很直接第一次跑通项目用默认配置。等你知道整个项目链路怎么工作了再考虑优化成本。2.4 非程序员也要认识的四个基础概念如果你的编程基础约等于零动手前先用半小时搞懂四个词后面会省很多事。命令行就是一个让你用文字给电脑下命令的窗口。你不用会写脚本但至少要会cd进入目录、运行命令、看懂报错输出。端口网络服务的入口编号。网页应用启动后通常会占一个端口比如 8080、3000。前端要访问后端就得知道后端在哪个端口。数据库存数据的地方。剧本内容、玩家进度、投票结果都存在这里。新手阶段用 SQLite 这种文件型数据库最省事不需要单独安装数据库服务。依赖你的项目引用的第三方代码库。别人写好的功能模块通过包管理器安装到本地。依赖版本不一致是很多诡异报错的根源。这四个概念不需要精通但一定要有印象。因为它们会反复出现在 Codex 给你的对话里也会反复出现在报错信息里。完全不懂的话你连“把报错信息描述给 AI”这件事都做不好。3. 把“AI 剧本杀”拆成 AI 能执行的任务3.1 剧本杀最小流程一个网页版 AI 剧本杀从玩家视角看流程大概是这样的玩家进入首页看到剧本列表。选择一个剧本进入游戏页。阅读角色背景和故事简介。AI 主持人分阶段推进剧情。玩家选择行动或调查线索。推理结束后玩家提交指认凶手的答案。系统判定结果展示结局。这个流程就是项目的骨架。AI 生成代码时本质上是在实现这个流程。你先把这个流程写清楚后面无论是让 Codex 设计数据库还是设计页面都有了一个统一的参照。3.2 第一个版本只做单剧本单玩家我强烈建议第一个版本砍到最简一个剧本、一个玩家、一个网页、不登录、不注册、不做多人在线。存储用 SQLite 或 JSON 文件都行。为什么因为“能跑”和“能上线”是两个标准。单剧本模式下数据结构简单页面也少部署时更不容易出错。等这一版完整上线你再让 Codex 加第二个剧本、加上多剧本管理、甚至加上多人在线都不迟。反过来如果你一开始就做多剧本多角色多结局任何一个小环节出错你都不知道是数据库的问题、前端的问题还是逻辑的问题。3.3 第一轮 Prompt 怎么写给 Codex 的第一轮指令不要只写一句话。你可以按这个结构组织你是一个全栈工程师。 请用 [前端技术栈] 和 [后端技术栈] 做一个 AI 剧本杀 Web 应用。 功能要求 1. 首页展示剧本列表。 2. 玩家选择剧本后开始游戏。 3. 游戏页以对话形式展示剧情玩家可以输入行动。 4. 玩家可以查看已发现的线索。 5. 最后可以提交指认凶手的答案并显示结局。 数据模型 - 剧本标题、背景、角色、线索、结局 - 游戏会话当前阶段、玩家选择、状态 页面 - / 首页 - /games/:id 游戏页 - /result/:id 结算页 暂时不需要登录、注册、支付、管理后台。 请先给出项目结构和数据库设计再开始写代码。这个 Prompt 的关键是先说技术栈再说功能再说数据再说边界。AI 不需要“你觉得这个主意很棒”它需要知道你要什么、不要什么。边界写得越清楚它就越不会自作主张加一堆你用不上的东西。3.4 生成之后先看什么Codex 生成完第一版代码后不要急着看每个文件写了什么。你要按这个顺序检查项目根目录下有没有 README 或启动说明。有没有明确的前端目录和后端目录。后端启动命令是什么前端启动命令是什么。数据库文件是自动创建还是需要手动初始化。有没有环境变量需要配置比如端口、数据库路径。对不会写代码的人最容易犯的错误是看到一堆文件就懵了然后直接问 AI“为什么不能运行”。实际上AI 通常会在生成代码时告诉你启动方法。你先按它说的去启动启动不了再带着具体报错去问。这个顺序很重要。注意第一轮生成后的目标是“能启动”不是“功能全对”。先启动成功再逐步验证功能。4. 前后端分离的开发节奏先接口再页面4.1 为什么前后端分开写更适合 AI 生成前后端分离是这个项目最值得坚持的架构选择。所谓前后端分离就是前端页面负责展示和交互后端服务负责处理数据和业务逻辑双方通过接口通信。前端是一个项目后端是另一个项目各跑各的也可以各自独立修改和重启。对 AI 生成项目来说前后端分离有两个明显好处。第一问题定位更清晰页面显示不对大概率是前端或接口字段问题数据存不下来大概率是后端或数据库问题。第二部署更灵活前端构建成静态文件后可以交给静态托管后端作为服务单独跑互不影响。如果硬把前后端代码混合在一起对没有编程经验的人来说排查难度会大很多。你看到的报错可能来自模板渲染、路由配置、静态文件路径等各种地方不容易判断该找谁。4.2 接口清单先定下来前后端通过接口通信所以接口清单是你和 Codex 沟通的重要工具。我这次先定义了这样一组接口接口方法作用/api/scriptsGET获取剧本列表/api/scripts/:idGET获取单个剧本详情/api/gamesPOST创建一局新的游戏/api/games/:idGET获取当前游戏进度/api/games/:id/actionsPOST提交玩家行动/api/games/:id/votePOST提交指认凶手的答案/api/games/:id/endGET获取结算结局这个清单可以不用一次写全但最好在开发前大致列出来。有了它你可以让 Codex 先实现后端接口再让前端去调用而不是让 AI 凭感觉发挥。4.3 前端页面和交互流前端页面不需要多三个页面足够首页、游戏页、结算页。首页展示剧本卡片点击“开始游戏”。游戏页左边是剧情对话区右边是线索和角色信息区。玩家输入行动后向后端发起请求返回新的剧情内容。结算页显示最终判定结果和结局文案。游戏页是最复杂的页面因为它要同时处理对话展示、玩家输入、线索更新、阶段切换。实现方式上用类似聊天界面的设计最简单后端返回一条消息前端追加一条消息。你把这个思路告诉 Codex它做出来的页面会比传统的表格型界面更适合沉浸式游戏。4.4 联调阶段最容易出问题的四个点前后端都做完后要联调。联调这个词听起来专业其实就是让前端能成功调用后端接口。这一步最常见的坑有四个。端口不一致前端默认访问 3000后端跑在 8080接口请求就会失败。统一端口或者让前端把接口地址配置好。跨域问题前端页面地址是 http://localhost:3000后端接口是 http://localhost:8080浏览器出于安全策略会拦截。后端需要允许来自前端地址的请求。接口地址写死本地调试时接口地址是 localhost部署到服务器后域名变了如果前端代码里写死了 localhost上线就废。最好用环境变量或相对路径配置接口地址。字段名不一致后端返回的字段叫title前端却读name页面上就会显示空白。调试时先看接口实际返回了什么再对照前端取值的字段名。我发现很多新手遇到联调问题第一反应是让 AI 重写前端。其实更应该做的是打开浏览器开发者工具看网络请求的地址、状态码和返回数据然后把这三个信息发给 Codex。信息越具体修复越快。5. 上线之前先把这些场景跑完5.1 完整游戏流程必须走一遍代码能启动不代表功能正确。在上线之前至少要把一条完整游戏流程走通进入首页、选择剧本、创建游戏、读剧情、做行动、发现线索、提交投票、看到结局。每一步都确认界面有反馈、数据有变化。我一般会用小样本先跑一遍而不是直接让 AI 把所有功能都补完。比如先只做一个剧本手动玩一次记录哪些环节卡住。能跑通之后再考虑第二个剧本、批量数据、更多交互。5.2 边界输入和异常交互正常流程走通之后还要测一些“不按照正常操作来”的场景。比如玩家输入一串很长的文字会不会卡死。玩家连续点击“提交”好几次会不会生成多条重复记录。玩家刷新页面之后游戏进度还在不在。玩家输入不存在的剧本 ID 或游戏 ID页面会不会白屏。数据库里没有数据时首页长什么样。这些场景对新手来说可能觉得多余但恰恰是它们最容易在上线后被真实用户踩到。你不需要处理得特别完美但至少要做到“报错不白屏刷新不崩溃”。5.3 后端报错的定位顺序我在开发阶段遇到最多的问题不是 AI 不会写而是我看不懂报错。后来我总结出一个固定的排查顺序很管用。先看后端终端或日志输出有没有红色报错。再看请求的接口路径和方法对不对。然后看接口入参也就是前端传过来的数据是否符合后端预期。接着看接口返回是成功结构还是错误结构。最后才去翻数据库看数据有没有写入或读取异常。比如后端报“session not found”说明游戏会话不存在。这时候不要急着改代码先确认创建游戏的接口是否真的成功了数据库中是否真的有一条 session 记录。很多时候问题不在“找不到”而是前面某一步根本没执行成功。5.4 让 Codex 帮你写测试和跑接口不会写代码不代表不能做测试。你可以让 Codex 生成可以直接执行的接口测试脚本比如用 curl 命令模拟创建游戏、提交行动、获取进度。# 示例创建一局游戏 curl -X POST http://localhost:8080/api/games \ -H Content-Type: application/json \ -d {scriptId: 1}把这个命令交给 Codex让它根据你的接口定义生成一整套测试命令比手动点页面快得多。后端接口验证通过后再回到前端页面做界面测试。这样分工问题会缩小到很小的范围要么是前端交互要么是接口字段不会全搅在一起。建议每完成一个功能就让它跑一次最小验证。不要攒了一堆功能再一起测那时候你连错误是哪次改动引入的都不好判断。6. 自动发布上线从本地到公网6.1 部署方式怎么选本地跑通之后距离上线还差一步把项目放到公网服务器上。部署方式的选择直接决定你后面维护的复杂度。方案适合场景特点静态托管 后端小服务项目访问量不大个人作品前端构建后传到静态托管后端单独跑在一台小服务器上一台云服务器 Docker想长期稳定运行前端、后端、数据库统一用容器管理部署可重复直接在一台服务器上手工部署只跑通流程不追求可复制最快但后续更新麻烦容易漏配置我这次选择的是“一台 Linux 服务器 Docker Compose Nginx”组合。原因很简单Docker 能把环境固定下来本地能跑服务器上大概率也能跑。对非程序员来说这比手工装 Node、装数据库、配 Nginx 要省心得多。6.2 生产环境配置部署到生产环境前要把几个配置单独拎出来不要沿用本地默认值。数据库路径本地可能用的是./data/game.db服务器上也要保证这个目录存在且有写入权限。接口地址前端构建时接口地址要指向服务器的域名或公网 IP而不是 localhost。端口与防火墙后端服务可以使用 8080 之类的内部端口Nginx 监听 80 和 443再把请求转发到后端。HTTPS 证书上线后建议尽快配置 HTTPS。现在很多服务都支持自动申请免费证书配置好后浏览器不会提示不安全。这些配置项看起来多但 AI 可以帮你生成 Dockerfile、Nginx 配置和环境变量示例。你只需要把服务器地址、域名、数据库目录这些信息告诉它。6.3 自动发布流程所谓“自动发布上线”核心思路是本地改完代码推送到代码仓库然后由一条流水线自动完成构建、上传、重启。你不用每次都在服务器上手动敲命令。一个典型的自动发布流程是这样的git push 到 main 分支 ↓ 流水线触发安装依赖、构建前端、构建后端镜像 ↓ 把构建产物和配置文件传到服务器 ↓ 服务器拉取最新代码重启服务 ↓ 健康检查接口确认服务正常代码仓库自带的 CI 功能一般都能支持这种工作流。你只需要让 Codex 帮你写一个部署用的脚本或流水线配置。我给一个示例级别的伪配置实际参数以你用的平台为准# 伪配置示例不要直接照抄 trigger: branch: main steps: - 安装前端依赖并构建 - 构建后端容器镜像 - 上传产物到服务器 - 登录服务器并拉取最新代码 - 重启服务 - 请求健康检查接口确认状态第一次配置自动发布最好先在测试服务器上跑通不要一上来就用正式地址。跑通后以后每次更新就简单了本地改代码提交推送等流水线完成再打开网页看效果。6.4 上线后第一件事服务上线后不要急着得意。第一件事是看日志。# 查看容器日志回到刚才所说的 Docker 部署方式 docker compose logs -f重点看三样东西服务是否正常启动、有没有报错、健康检查接口返回是否正常。再访问一遍线上地址把完整游戏流程在公网环境里重新走一次。这一步能发现很多本地环境测不出来的问题比如接口地址没改、数据库目录没有权限、静态文件路径不对。上线不是终点而是新一轮测试的开始。你前面在本地验证得越细线上翻车的概率越低。7. 非程序员容易踩的五个坑7.1 报错不等于代码写错很多新手看到红字报错第一反应是“AI 不行”。实际上报错信息里包含的往往是解决问题的关键线索。比如找不到文件、没有权限、端口被占用、模型不支持、依赖版本不对这些都和代码逻辑没关系。正确做法是把报错信息完整复制连同你刚才执行的操作一起发给 Codex问它“这个报错是什么原因应该按什么顺序排查”。而不是只问“为什么不能运行”。7.2 路径和权限问题在本地能跑到服务器上跑不了最常见的原因就是路径和权限。本地用户有权限读写当前目录但服务器上的服务进程可能没有权限。数据库目录不存在、上传目录不存在、环境变量路径配错了都会造成诡异失败。遇到这类问题时不要猜先看日志。日志会明确告诉你哪个目录找不到哪个文件没权限。然后去检查那个目录是否存在、权限是否够用。7.3 依赖版本不一致AI 生成的项目会依赖很多第三方库。这些库更新很快新版本可能改了用法老版本可能和新版本不兼容。你本地安装成功不代表服务器上执行完全相同命令也能成功除非你有锁文件把版本固定住。排查思路是确认项目里有没有锁文件比如 package-lock.json 这类文件确认本地和服务器安装依赖的版本是否一致报错信息里提到哪个包就先查那个包的版本。7.4 自定义模型服务配置不兼容如果你使用了第三方模型服务感觉“跑通了”和“真正能稳定用”之间还有距离。Codex 对模型返回格式有要求模型不支持某些能力可能在生成代码过程中突然中断也可能在请求时直接报错。我的经验是不要在生产项目里频繁切换模型。先固定一个配置把整个链路跑熟。想试验新模型就用测试项目不要拿上线项目当试验田否则出了问题你很难判断是代码问题还是模型兼容问题。7.5 别急着加并发和新功能项目上线后你的第一反应可能是“我再加个功能”。我的建议是先压住这个冲动。这个项目最大的成果不是功能多而是你已经掌握了一条完整的“想法到上线”链路。如果要加功能控制节奏一次只加一个每次改动后都完整跑一遍主流程再提交推送。不要同时加多剧本、用户登录、多人在线。改得越多万一出错你越难定位。稳定运行一周比一天上线三个功能更有价值。8. 如果重来一次我会按这个顺序做8.1 推荐的落地顺序把这次项目重新复盘后我给自己定的标准落地顺序是这样的先跑通 Codex 本体确认命令行和登录都正常。用一个空目录测试生成小工具熟悉“生成-启动-报错-修复”循环。写清楚剧本杀的需求和页面清单定义 MVP 范围。让 Codex 生成项目结构、数据库设计和后台接口。用 curl 测所有后端接口。让 Codex 生成前端页面并完成联调。本地走完整流程处理边界输入。配置 Docker、Nginx、环境变量。部署到服务器配置自动发布。线上再走一遍完整流程然后持续观察日志。这个顺序的核心原则是每一步的产出都是下一步的输入每次只解决一个问题。越往后推进你越能体会到前面基础打得牢的好处。8.2 哪些功能可以后置以下功能我都建议放到第二个版本再做用户注册登录、多剧本管理后台、多人联机、实时语音、AI 动态生成剧情、支付和会员。这些功能每一个都会引入新的复杂度而且几乎都涉及安全问题或状态同步不是零基础项目应该优先碰的。把第一版做小做到上线做到有人能打开玩比做一堆半成品功能有意义得多。用户愿意玩懂你的核心玩法比功能列表长不长更值得关注。8.3 给零基础读者的一句实在话用 AI 做项目真正的门槛不是“不会写代码”而是“能不能把一个模糊想法变成明确需求并且愿意在报错面前多走一步”。Codex 可以写代码、改代码、部署代码但替你思考需求和判断结果这件事它替代不了。我这次做 AI 剧本杀的整个过程最大的收获不是做出了一个可以玩的游戏而是建立了一套自己的排查习惯先看现象再看输入再看环境再看参数最后才看代码。这个习惯对以后做任何项目都有用。如果你也想做建议不要去看几十篇教程再动手。安装好工具选一个最简单的剧本开始写你的第一轮 Prompt先让项目能启动再一步步把它变完整。踩过几次坑之后你会发现很多问题不是工具能力不够而是前置环境和输入描述没有处理干净。