必须人工确定技术栈，因codex缺乏工程判断力，无法兼顾端口冲突、并发锁表、数据持久化等真实约束；需按项目性质、分层选型、工具链验证、书面声明四步锁定。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Codex开发全栈项目时，技术栈不能由AI临时拼凑，必须在启动Codex前由你本人明确拍板——AI只执行，不决策，否则生成的代码会前后矛盾、部署失败、后期无法维护。
为什么必须人工确定技术栈
Codex不具备真实工程判断力。它可能给你前端配Vue、后端配Rails、数据库选SQLite，再顺手加个Docker Compose——但当你真去跑起来，就会发现Vue的Vite开发服务器默认端口和Rails冲突，SQLite在多用户并发写入时直接锁表，而Docker Compose里没写volume挂载，重启容器后所有数据清空。这些不是AI“想不到”，而是它根本没运行环境、没业务约束、没团队规范可参照。
配置 OpenClaw 多提供商认证与 OpenAI Codex OAuth 备用方案，实现自动模型切换，适用于多 OpenAI Codex 账户设置。
你才是那个知道“这个项目只做内部工具，上线周期压到3天”或“要支持500人同时在线，必须用PostgreSQL连接池”的人。
四步锁定技术栈
第一步：明确项目性质与交付边界
问自己三个问题：这是演示原型还是生产系统？是否需要后续多人协作？有没有强制的部署环境限制（比如只能上阿里云函数计算）？答案直接砍掉70%的候选技术。例如，“仅需本地运行的个人工作台”就排除K8s、微服务、Redis集群。
第二步：按层收敛选项
前端：若追求极速启动且无复杂交互→【Vite + React】（官方模板开箱即用，Codex对JSX支持最成熟）；若已有UI设计稿且需高保真还原→【Vue 3 + Pinia】（响应式语法更贴近自然语言描述）。
后端：纯API服务且你熟悉Python→【FastAPI】（自动生成OpenAPI文档，Codex能直接读取/docs/json生成调用示例）；若需强类型校验和企业级中间件→【NestJS】（但要求你提前告诉Codex“用装饰器定义DTO”）。
数据库：单机轻量→【SQLite】（零配置，Codex生成migration脚本成功率最高）；需并发读写→【PostgreSQL】（必须手动创建好初始数据库和用户，Codex不会帮你连通认证）。
第三步：验证工具链兼容性
打开终端，逐条执行：node -v && python3 -v && docker --version。任一缺失，立刻剔除依赖该工具的方案。Codex不会提醒你“你没装Docker”，它只会生成一份完美的docker-compose.yml，然后卡在build阶段报错“command not found”。
第四步：用一句话写死技术栈声明
在项目根目录新建一个TECH_STACK.md文件，只写一行：
【Frontend: Vite + React 18, Backend: FastAPI 0.115, DB: SQLite 3.40, Deployment: Static frontend + Uvicorn process】
把这行文字复制进Codex对话框开头，作为后续所有指令的前提。Codex将严格按此上下文生成代码，不再擅自引入Webpack、Express或MongoDB。
两个典型错误避坑法
方法一：别让Codex“推荐技术栈”
输入“帮我选个全栈技术栈”这类模糊指令，Codex会返回一份看似专业实则不可落地的清单：Next.js + tRPC + Prisma + PlanetScale。它不会告诉你tRPC要求你先理解Zod schema，Prisma迁移需手动确认SQL，PlanetScale不支持本地调试。这种输出是幻觉，不是方案。
方法二：拒绝“全自动堆栈生成”
有些插件声称“一键生成MERN全栈”，结果生成的React前端用的是已废弃的class组件写法，Node后端用的是require而非import，MongoDB Schema里字段名大小写混乱。Codex不是编译器，它生成的是“人类可读代码”，不是“机器可运行代码”。你必须亲手核对package.json里的依赖版本、pyproject.toml里的python要求、以及.env.example里是否漏写了DATABASE_URL。
