目录摘要一、这个项目到底是什么二、为什么这个项目特别适合用 Codex三、我不是把 Codex 当 AI我是把它当“技术协作者”1. 先让它读项目再让它动手2. 明确告诉它什么能改什么不能改3. 让它先收敛方案再执行实现四、这个项目里Codex 真正帮我解决了哪些硬问题1. 前后端运行时冲突Windows 能跑服务但跑不动引擎2. 8080 端口占用问题不在代码在旧进程3. 前端 UI 不是“能用就行”而是反复重构4. Bot 模式里开关不是“创建时生效”而是“落子时持续生效”五、我如何把 Codex 用到“像工程师”而不是“像聊天机器人”方法一任务必须拆成可验证的小步方法二要求它同步维护文档方法三让它解释“为什么这么改”六、这个项目当前做到哪一步了已完成正在逼近的阶段七、我对 Codex 的真实评价八、结语总结摘要很多人对 Codex 的理解还停留在“帮我补代码”“帮我写函数”的层面。但这次我在做一个智能围棋机器人系统时真正感受到的不是“AI 帮我写几行代码”而是它开始具备了工程协作伙伴的价值。这个项目并不简单后端要接 KataGo 引擎前端要做智能分析工作台还要考虑人类棋风模型、机器人陪练、局域网访问、后续移动端扩展以及未来的机械臂与视觉识盘接口。整个过程中Codex 不仅参与了编码还参与了架构拆分、UI 重构、WSL/Windows 运行时隔离、接口联调、错误定位与文档沉淀。这篇文章我不想写成“AI 真香”式流水账而是尽量从技术角度复盘Codex 在一个真实项目中到底能帮到什么程度怎么用它才更像一个高级开发协作者而不是随机生成器。一、这个项目到底是什么我做的是一个智能围棋机器人系统目标不是单纯做一个“棋盘网页”而是搭出一个可持续扩展的 AI 围棋中枢。当前已经落地的核心能力包括围棋局面分析AI 下一步推荐教学提示与讲解开关机器人陪练联机模式基础能力标准模型与人类风格模型切换Web 工作台局域网访问准备为移动端、视觉识盘、机械臂控制预留接口整个技术栈大致如下KataGo / 分析引擎↓C 查询层 / GTP 或 JSON 路线↓Python Gateway统一 API↓React Vite Tailwind 前端工作台↓未来扩展移动端 / AR识盘 / 机械臂硬件这不是一个 demo而是一个正在往“产品化原型”推进的系统。二、为什么这个项目特别适合用 Codex很多项目不适合一上来就让 AI 深度参与因为需求边界不清、代码规范混乱、技术选型飘忽不定AI 很容易越写越歪。但这个项目恰好满足了 Codex 发力的几个关键前提有明确的目标系统围棋分析、陪练、教学、联机有逐步推进的技术路线引擎接入、接口统一、前端消费、局域网放开有清晰的约束不随意删文件、优先修改现有代码、记录进度文档有真实工程问题端口占用、Windows/WSL 运行时冲突、接口模式切换、UI/UX 重构也就是说Codex 在这里不是“瞎猜需求”而是在一个可验证、可迭代、可复盘的工程环境里工作。这时它的价值就会被放大。三、我不是把 Codex 当 AI我是把它当“技术协作者”这是整个过程里最重要的一点。如果你只是对 Codex 说一句“帮我做个围棋项目”那最后多半只会得到一堆中看不中用的代码骨架。但如果你像和一个真正的工程同事协作一样去使用它效果会完全不同。我的做法大概是这样的1. 先让它读项目再让它动手我一开始不是让它立刻生成代码而是先要求它阅读当前目录下的文件判断项目开发进度说明下一步应该做什么经我确认后再继续这一步非常关键。它逼着 Codex 先建立上下文而不是直接“脑补”。2. 明确告诉它什么能改什么不能改比如我会持续强调这些约束尽量修改原文件不要随意删除重建每完成一步就更新项目记录文档前端必须遵守既定设计规范保持 React Vite Tailwind 的目录分层逻辑要优先用 Hook 解耦不要把接口写死为 127.0.0.1你会发现AI 不是不听话而是你不给约束它就只能用“统计学平均答案”来应付你。3. 让它先收敛方案再执行实现有些时候我不是直接让它改而是先问当前阶段卡在哪里这个问题的根因是什么下一步最优先该做什么有哪些可选方案这样做的好处是Codex 会从“代码生成器”切换到“问题分析器”的角色。四、这个项目里Codex 真正帮我解决了哪些硬问题如果只是写几个组件、拼几个页面那不能说明什么。真正让我觉得它有工程价值的是它参与解决了几类很现实的问题。1. 前后端运行时冲突Windows 能跑服务但跑不动引擎这是我遇到的一个非常典型的问题。前端页面虽然能打开但一切进入分析、陪练、评级等真实引擎逻辑时就会报错[WinError 193] %1 不是有效的 Win32 应用程序Failed to fetch表面上看像接口挂了实际上根因是Python 网关可以在 Windows 上启动但底层引擎链路更适合 WSL/Linux 环境运行。最后做的不是“强行让所有东西都在 Windows 原生跑”而是做了更合理的运行时分层Windows 原生 Python允许启动网关但对引擎能力返回结构化 503WSL/Linux作为标准后端运行环境真正承载分析引擎网关健康检查接口暴露运行时信息增加 WSL 启动脚本和说明文档这件事说明一个很现实的问题Codex 最有价值的地方不是帮你“凑出能跑的代码”而是帮你把错误的工程路径掰正。2. 8080 端口占用问题不在代码在旧进程还有一次页面一直访问异常乍看很像前端或接口路径写错了。但继续排查后发现真正的问题是旧的 Windows Python 进程一直占着 8080新启动的 WSL 网关其实根本没接管到正确端口后来做了几件事清理旧的 python_gateway/app.py 占用进程脚本化检测谁在监听 8080确保 WSL 版本网关真正监听在 0.0.0.0:8080启动脚本自动识别是否已有正确进程运行这类问题非常能体现 Codex 的一个优势它可以把“定位问题 - 给出命令 - 修改脚本 - 更新文档”这一整串链路连起来。3. 前端 UI 不是“能用就行”而是反复重构项目后面最花精力的其实不是底层引擎而是前端工作台。一开始页面虽然能工作但存在很多问题棋盘不够突出顶部留白过大控制区信息堆叠陪练配置和分析档位重复交互路径不够直观小白用户看不懂参数后来我们连续做了几轮产品化重构三栏式工作台布局赛博暗黑风格棋盘点击即落子推荐点发光环可视化教学栏与推荐开关解耦Pro 模式与简洁模式分层段位与引擎能力拆分人类风格模型做吸附式档位展示预留实景识盘与硬件中枢入口这让我意识到Codex 在前端里最适合扮演的角色不是“设计师”而是设计约束的执行者状态逻辑的实现者重构节奏的推进者前提是你必须把设计原则说得足够明确。4. Bot 模式里开关不是“创建时生效”而是“落子时持续生效”这个问题挺隐蔽但很典型。当用户在机器人陪练模式中切换“推荐点开关”或“教学提示开关”时界面看起来切了但实际对局期间点击并没有产生预期效果。原因在于之前这些选项只在创建 bot game 时写入后续每一步落子请求并没有同步更新当前开关状态。后来的修正方式是/bot_games/{id}/move 请求中携带 enable_recommendation 和 enable_teaching后端在每一步中更新当前对局配置前端点击开关后不需要重建整局也能即时生效这个问题很有代表性因为它不是“写个接口”那么简单而是涉及状态源头在哪配置是一次性写入还是持续同步交互预期和系统实现是否一致这种问题如果让人纯靠肉眼扫代码往往要花很久。让 Codex 参与做链路级排查效率会高很多。五、我如何把 Codex 用到“像工程师”而不是“像聊天机器人”这是我最想分享的部分。方法一任务必须拆成可验证的小步我几乎不会让它一次性重构整个系统而是像这样推进先改 client_bootstrap再接 analysis_query再做 bot game再处理 live room再优化 UI/UX再放开局域网访问再补文档和启动脚本每一步都可以验证。这样 Codex 的输出质量会显著提高。方法二要求它同步维护文档我反复要求它每完成一个阶段就更新项目记录文档。这件事看起来像“形式主义”但实际非常有用因为它会迫使 AI 持续回答这三个问题我们现在做到哪里了刚刚改了什么下一步应该是什么这能显著减少后续上下文漂移。方法三让它解释“为什么这么改”只看代码是不够的。我会追问这个错误的根因是什么为什么选方案 A不选方案 B这个改动会影响什么未来 App 化、视觉识盘、数据库接入时是否还能复用这会把 Codex 从“执行层”拉到“设计层”。六、这个项目当前做到哪一步了如果从工程成熟度来看我认为项目现在已经走过了最危险的“原型失控期”进入了“可以演示、可以迭代、可以扩展”的阶段。目前大体处于这个位置已完成KataGo 能力接入主链路Python Gateway API 跑通React 前端工作台落地分析、陪练、联机基础模式接通推荐点、教学栏、机器人模式联动修复WSL 运行标准化局域网访问初步放开UI 进入可演示级状态移动端、视觉识盘、硬件控制已预留接口思路正在逼近的阶段在线房间体验强化学生/学校体系数据库接入用户段位与对局记录持久化实景识盘输入链路App 化与跨端适配机械臂协议与硬件联动换句话说现在它已经不是“想法”而是一个真正有机会继续长成产品的系统。七、我对 Codex 的真实评价如果非要我用一句话总结那就是Codex 最强的地方不是替你写代码而是当你已经知道自己要做什么时它能帮你把工程推进速度拉高一个量级。但它也不是万能的。它依然有几个边界你不给清晰约束它就容易发散你不做阶段验证它可能一路写偏你不盯产品逻辑它会默认走“技术正确但体验平庸”的路线复杂项目里它更适合“协作推进”而不是“完全放权”所以正确的用法不是“AI帮我做完这个项目”而是“这是目标、这是约束、这是当前状态、这是下一步请在这个边界内推进并持续给我可验证结果。”这两种用法结果完全不是一个量级。八、结语这次做智能围棋机器人项目让我对 Codex 的看法发生了很大变化。它已经不只是一个“自动补全工具”也不只是“写代码助手”。在复杂项目里只要你给它清晰的目标、稳定的上下文、严格的工程边界它可以逐步承担架构推进代码实现状态解耦问题定位跨层联调文档沉淀工程节奏管理我更愿意把这种能力理解为一种面向真实项目的 AI 协作式开发。而这个围棋项目就是我目前为止最有说服力的一次实践。总结如果你也在做一个复杂项目尤其是涉及前后端、AI 引擎、UI 重构和运行环境切换的系统我非常建议你别再把 Codex 只当“写函数工具”了。真正高价值的用法是把它纳入你的工程协作流让它参与节奏、参与拆分、参与排错、参与演进。你会发现AI 编程真正的壁垒不是模型本身而是你是否会组织它。