接手半成品应用需四步：先查项目状态文件确认边界；再通过脚本和git历史定位真实入口；接着手动交互验证能力边界；最后建立codex_context.json锚定上下文。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
接手一个只完成一半的应用，最怕的是不知道哪些功能已实现、哪些逻辑被写死、哪些接口还在占位，更怕直接改出线上事故。Codex不是来填坑的，是来接棒的——但前提是它得先看清你手里这半截项目到底长什么样、卡在哪、还能不能续。
第一步：确认项目边界和当前状态
不要急着打开 src 或看 package.json。先让 Codex 执行：【cd 到项目根目录 → 运行 ls -la】，重点检查是否存在 .codex_state、project_status.md、DEV_NOTES.md 或未提交的 git stash。这些文件往往藏着人工中断时留下的关键线索，比如“登录页UI已切完，但JWT刷新逻辑未接入”或“API mock 已停用，需切换真实环境”。没有这类文件？那就立刻新建一个 project_status.md，用 Codex 帮你补全现状清单。
这一步必须做。Codex 默认不会主动扫描隐藏文件或未提交变更，【如果跳过此步，它会把未完成的 stub 当成正式实现】。
第二步：识别并锁定真实入口链
方法一：从运行脚本反推入口
执行：【cat package.json | grep -A 5 \"scripts\"】，找出 dev、start、serve 等实际启动命令；再对每个命令执行 npm run --if-present xxx -- --help（或加 -v），观察是否输出入口路径、环境变量开关或动态路由配置。很多半成品项目用 dev:admin 和 dev:h5 两个脚本隔离不同阶段，不查清楚就开干，可能在管理后台改了半天，用户实际访问的是 H5 版本。
方法二：从 Git 历史定位最后活跃区
运行：【git log --oneline -n 20 --no-merges -- src/】，看最近修改集中在哪些目录；再用 【git diff HEAD~3 -- package.json】 检查依赖是否新增了未安装的包、scripts 是否被删改。如果最后三次提交都只动了 components/xxx.vue，而 pages/ 下的文件三个月没碰过，那业务入口大概率不在 pages 里。
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
第三步：快速验证已有能力边界
① 找到一个能立即触发的最小交互点，比如点击按钮、输入框失焦、URL 路由跳转；
② 让 Codex 启动开发服务器 → 手动操作复现该动作 → 实时抓取浏览器控制台报错、Network 面板返回状态、以及终端中服务端日志；
③ 对比预期行为与实际行为，生成一份「能力快照」：哪些组件能渲染、哪些 API 返回 200 但 data 为空、哪些事件监听器注册失败但无报错。
这一步操作起来很简单，直接把文件拖进去就行。但注意：不要让它自动修复错误。Codex 在未确认上下文前强行 patch，常会覆盖掉开发者临时注释掉的调试逻辑，导致后续无法回溯问题源头。
第四步：建立可更新的上下文锚点
新建一个 codex_context.json 文件，用 Codex 写入四类字段：
- "last_verified_entry": "src/main.tsx"
- "blocked_by": ["missing auth middleware", "mock API disabled"]
- "safe_to_modify": ["components/OrderSummary", "hooks/useCart"]
- "must_preserve": ["payment flow state machine in store.ts", "all /api/v2/checkout/* routes"]
这个文件将成为后续所有指令的上下文基线。每次 Codex 修改代码前，它都会先读取该文件，判断操作是否落入 safe_to_modify 区域、是否会触碰 must_preserve 条目。下次你中断后回来，只需打开这个 JSON，就能瞬间恢复现场。
