AI编程范式升级：从代码补全到可托管执行单元

老白Walt

303人浏览 · 2026-06-17 10:36:53

老白Walt · 2026-06-17 10:36:53 发布

1. 项目概述：从“写代码助手”到“可托管执行单元”的范式迁移

你有没有试过把一个完整的需求文档甩给AI，然后去泡杯咖啡、回个邮件、甚至睡一觉，醒来发现它已经建好本地服务、跑通核心流程、生成测试用例、输出可视化报告，还附上一份带时间戳的执行日志？这不是科幻预告片，而是最近三个月我在真实业务中反复验证过的日常操作。关键词 AI编程 、 gpt5.5 、 CODEX ——这三个词组合在一起，正在快速脱离“智能补全”“自动注释”这类辅助性标签，进入一个更本质的阶段：它不再只是帮你写代码，而是开始承接你原本需要亲自规划、调度、验证、迭代的一整块工作流。我把它叫作“可托管执行单元”——不是因为它能写得更好，而是因为它能 持续地、有依据地、可追溯地、带熔断机制地 完成一段被明确定义的“工作契约”。

这个转变的临界点，就藏在GPT-5.5正式集成进Codex那一刻。很多人只看到模型参数变大、推理能力变强，但真正撬动工作方式的，是它在 长时程任务闭环能力 上的质变。以前的模型像一个反应极快但记性很差的实习生：你让它改A文件，它改完；你让它测B接口，它测完；但你若说“把用户注册流程从邮箱验证升级为手机+邮箱双因子”，它大概率会在第三步就忘了第一步的数据库字段变更要求，或者在第五步误删了前端校验逻辑。而GPT-5.5 + Codex的组合，更像是一个刚通过PMP认证、自带Jira看板和Confluence知识库的资深开发组长——它会主动拆解“双因子注册”为“1. 设计新表结构 → 2. 修改后端API签名 → 3. 更新前端表单UI → 4. 编写集成测试 → 5. 输出部署检查清单”，并在每一步完成后，自动运行 npm test 、 curl -X POST /api/register 、 playwright test register.spec.ts 来验证结果；失败则回溯修改，成功则记录状态并推进下一步。整个过程不依赖你实时盯屏，也不靠一句“continue”续命。

这背后不是玄学prompt，而是一套可工程化落地的“长跑操作系统”。OpenAI官方那篇《Run long horizon tasks with Codex》里提到的25小时构建Design Tool案例，真正值得深挖的不是“13M tokens”或“30k行代码”这些炫目数字，而是他们公开的四个核心Markdown文件： Prompt.md 定义目标边界与验收红线， Plan.md 将模糊需求转化为带验收命令的里程碑， Implement.md 规定执行纪律与失败回滚路径， Documentation.md 强制实时记录决策链与已知风险。这四份文档，本质上就是给AI执行单元配备的“工位说明书”“排班表”“工单系统”和“质检报告模板”。没有它们，再强的GPT-5.5也只是一台高配却无导航的跑车——油门踩到底，但不知道终点在哪，更不知道迷路时该停在哪问路。

所以这篇文章不讲“如何让AI写出更优雅的代码”，而是聚焦一个更务实的问题：当你决定把一块价值数小时的人力工作托管给Codex时，你该如何设计它的“托管契约”、搭建它的“运行轨道”、配置它的“安全护栏”，并最终在它跑完一整夜后，敢签字验收？这不是模型能力的单点突破，而是一整套面向AI原生工作流的工程实践体系。接下来，我会用真实项目复盘的方式，一层层拆解这套体系的骨架、血肉与神经末梢。

2. 核心设计思路：为什么必须放弃“单轮对话思维”，转向“状态机驱动工作流”

很多开发者第一次尝试让Codex跑长任务时，会本能地回到熟悉的聊天模式：输入PRD → 等待回复 → 看到代码 → 手动运行 → 发现报错 → 再输入“修复这个错误” → 继续等待……如此循环。这种模式在单次交互中效率很高，但一旦任务跨度超过15分钟，就会迅速崩塌。原因很现实： Codex的上下文窗口不是无限的内存，而是一张不断滚动的磁带；它没有内置的“项目记忆”，只有你喂给它的“当前片段”。 当你让它构建一个包含5个微服务的电商后台，它在第3个服务的API设计环节，很可能已经忘记了第1个服务的数据库连接池配置策略——这不是模型变笨了，而是它根本没被设计成要记住那么久远的事。

我亲身踩过的最典型坑，是在一个内部工具迁移项目中。需求是：“将旧版Python脚本（处理CSV订单）迁移到新架构，支持并发、失败重试、S3归档，并生成执行报告”。我最初用传统方式操作：先让Codex分析旧脚本，它输出了300行重构建议；接着我粘贴建议让它实现，它生成了新代码；我本地运行，发现S3上传超时；我发消息“增加重试逻辑”，它加了 @retry 装饰器；再运行，又报 No module named 'boto3' ……如此往复7轮，耗时2小时，最终交付物是一堆零散的代码片段和无法串联的调试日志。直到我停下来重读OpenAI那篇文档，才意识到问题不在模型，而在我的工作流设计——我把Codex当成了一个需要手把手教的学徒，而不是一个可以签合同、派任务、查进度的执行单元。

真正的转机，来自彻底切换思维模型： 把长任务看作一个状态机（State Machine），而非一次超长对话。 状态机的核心思想是：任何复杂流程，都可以被分解为有限个明确状态（State）、触发状态转移的事件（Event）、以及状态转移时必须执行的动作（Action）。对应到Codex长跑中：

State（状态） ：不是“正在写代码”，而是“已完成数据库Schema设计，待验证”“API路由已生成，待集成测试”“前端组件已渲染，待视觉审查”；
Event（事件） ：不是“用户发送新消息”，而是“ npm run validate:db 返回0”“ curl -s http://localhost:3000/api/health | jq .status 输出 "ok" ”“Playwright截图比对通过率≥95%”；
Action（动作） ：不是“继续生成下一段代码”，而是“将当前状态写入 .omx/state.json ”“执行 git add src/db/ && git commit -m 'feat(db): add order_status enum' ”“向Slack频道#ai-devops发送进度卡片”。

这个思维切换带来的实操收益是颠覆性的。以我最近完成的“自动化数据清洗流水线”项目为例（目标：将10种不同格式的销售报表CSV，统一清洗为标准JSON Schema并入库）。我放弃了逐条指令，而是先构建了状态机蓝图：

当前状态	触发事件	执行动作	下一状态
`INIT`	PRD文档解析完成	创建 `.omx/plan.md` ，生成5个milestone	`PLAN_READY`
`PLAN_READY`	`sh ./validate_plan.sh` 通过	启动第一个milestone： `parse_csv_format_1`	`RUNNING_PARSE_1`
`RUNNING_PARSE_1`	`python parse_v1.py --test` 输出 `PASS`	记录 `state=SUCCESS` ，提交代码，触发 `parse_csv_format_2`	`RUNNING_PARSE_2`
`RUNNING_PARSE_2`	`python parse_v2.py --test` 输出 `FAIL`	运行 `git stash` ，调用 `codex-fix` 子agent分析错误日志，生成修复补丁	`REPAIRING_PARSE_2`

这个状态机不是存在我脑子里的抽象概念，而是直接落地为一个Shell脚本 run_state_machine.sh ，它每5分钟轮询一次 .omx/state.json ，根据当前状态执行对应命令，并将结果写回状态文件。Codex本身只负责处理“单个状态内的具体任务”，比如在 RUNNING_PARSE_1 状态下，它收到的指令是：“你正在处理CSV格式#1的解析器。当前状态：已读取 sample_v1.csv ，发现首行是 order_id,product_name,qty,price 。请生成 parse_v1.py ，要求：1. 使用pandas读取；2. 将 price 字段转为float；3. 添加 created_at 时间戳；4. 输出JSON到 output/v1/ 。完成后运行 python parse_v1.py --test 并报告结果。”——指令极度聚焦，上下文干净，失败原因一目了然。

提示：状态机设计的关键禁忌是“状态爆炸”。不要试图定义“正在修改第3个文件的第7行”这种微观状态。每个状态必须代表一个 可验证、可交付、有业务意义的里程碑 。我见过最失败的案例，是一个团队定义了47个状态，结果Codex在第23个状态就因上下文溢出而开始胡言乱语。记住：状态越少，机器越稳；验证越硬，信任越足。

这种设计之所以有效，是因为它把人类最擅长的“目标管理”和“质量把控”能力，外化为可执行、可审计的程序逻辑；而把AI最擅长的“模式识别”和“代码生成”能力，约束在清晰的边界内。它不是让Codex变得更聪明，而是让它变得更可靠 ——就像给一辆自动驾驶汽车装上高精地图、红绿灯识别和紧急制动系统，而不是单纯提升它的电机功率。

3. 实操细节：构建你的第一个可托管执行单元——从环境准备到状态持久化

现在我们把抽象的状态机，变成你电脑上可运行的真实系统。整个过程分为四个关键阶段：环境初始化、计划工程化、执行闭环搭建、状态持久化。我会用一个极简但完整的例子贯穿始终——构建一个“自动博客摘要生成器”（输入：任意URL；输出：300字以内中文摘要，带关键词提取）。这个例子足够小，能让你在30分钟内跑通全流程；又足够真，包含了所有长跑必备要素：外部API调用、文件IO、状态验证、失败回滚。

3.1 环境初始化：告别裸跑，拥抱工作区契约

首先，创建一个专属工作区。别再把Codex丢进一个空目录里让它自由发挥。真正的长跑，始于一个被精心设计的“工位”。我习惯用以下结构：

blog-summarizer/
├── .omx/                    # Codex专用工作区（所有状态、计划、记忆存这里）
│   ├── plan.md             # 由Codex生成的详细执行计划
│   ├── state.json          # 当前状态机位置（{"state": "RUNNING_FETCH", "step": 3}）
│   ├── memory/             # 持久化记忆（技术栈偏好、项目约定、已知坑）
│   └── logs/               # 每次执行的完整日志（带时间戳）
├── src/                     # 代码源码（Codex只在这里写）
│   ├── fetcher.py          # 网页抓取模块
│   └── summarizer.py       # 摘要生成模块
├── tests/                   # 验证用例（Codex必须通过才能推进）
│   └── test_fetcher.py
├── scripts/                 # 自动化脚本（状态机引擎）
│   ├── run_state_machine.sh # 主循环脚本
│   └── validate_fetcher.sh  # 验证脚本（供Codex调用）
└── README.md                # 项目契约（目标、非目标、验收标准）

这个结构本身就是一种契约。 .omx/ 目录的存在，明确告诉Codex：“你的记忆、计划、状态都放这里，别乱扔”； tests/ 目录的存在，暗示“你的代码必须能通过测试，否则不算完成”； scripts/ 目录的存在，则宣告“我不是在和你聊天，而是在运行一个程序”。

初始化命令（全部在终端执行）：

mkdir -p blog-summarizer/{.omx,src,tests,scripts}
touch blog-summarizer/.omx/{plan.md,state.json}
echo '{"state": "INIT", "step": 0}' > blog-summarizer/.omx/state.json
touch blog-summarizer/README.md

注意： .omx/ 目录名不是随意取的。它源自社区项目 oh-my-codex （OMX），已成为Codex长跑的事实标准工作区标识。Codex官方工具链（如 codex-cli ）会优先识别此目录，自动加载其中的 plan.md 和 state.json 。坚持用这个命名，能让你无缝接入未来更多生态工具。

3.2 计划工程化：用 `Prompt.md` 和 `Plan.md` 替代万能咒语

现在，我们不直接对Codex说“写个爬虫”，而是先构建它的“任务说明书”。这是长跑成败的第一道闸门。

第一步：编写 Prompt.md （放在项目根目录）

# 博客摘要生成器 - 任务契约

## 目标
构建一个CLI工具，接收URL参数，输出300字以内中文摘要及3个关键词。

## 非目标
- 不处理JavaScript渲染的动态页面（仅抓取静态HTML）
- 不支持PDF/图片等二进制内容
- 不做SEO优化或链接分析

## 硬约束
- 必须使用Python 3.11+
- 必须用`requests`+`BeautifulSoup`抓取，`jieba`分词，`transformers`（distilbert-base-chinese）生成摘要
- 所有依赖写入`requirements.txt`
- 代码必须有类型提示（mypy可检查）

## 交付物
- `src/fetcher.py`: 负责抓取和基础清洗
- `src/summarizer.py`: 负责摘要生成和关键词提取
- `main.py`: CLI入口，支持`python main.py --url https://example.com`
- `tests/test_fetcher.py`: 单元测试（覆盖HTTP 200/404/timeout场景）

## Done When
1. `python main.py --url https://httpbin.org/html` 输出摘要且无异常
2. `pytest tests/` 全部通过
3. `mypy src/` 无类型错误

这份文档的价值，远超一个prompt。它把模糊的“做个摘要工具”变成了可审计的契约：谁都能看懂目标是什么、什么不能做、用什么技术、怎么算成功。Codex读取它时，不是在猜你的心思，而是在履行一份合同。

第二步：让Codex生成 Plan.md 启动Codex（确保已启用GPT-5.5和Codex模式），输入：

你是一个资深Python工程师，正在接手一个新项目。请基于以下任务契约（见Prompt.md），生成一份详细的执行计划。要求：
1. 将任务拆解为3-5个里程碑（Milestone），每个里程碑有明确名称和业务意义
2. 每个里程碑列出：a) 具体交付物 b) 验证命令（必须是可执行的shell命令） c) 失败时的回滚动作
3. 计划必须写入`.omx/plan.md`，使用Markdown表格

Codex会输出类似这样的 plan.md ：

Milestone	交付物	验证命令	失败回滚
`M1: 基础抓取器`	`src/fetcher.py` , `tests/test_fetcher.py`	`python -c "from src.fetcher import fetch; print(fetch('https://httpbin.org/html'))"`	`git checkout -- src/fetcher.py tests/test_fetcher.py`
`M2: 摘要生成器`	`src/summarizer.py` , `requirements.txt`	`python -c "from src.summarizer import summarize; print(summarize('测试文本'))"`	`git checkout -- src/summarizer.py requirements.txt`
`M3: CLI集成`	`main.py` , `pyproject.toml`	`python main.py --url https://httpbin.org/html \| head -n 5`	`git checkout -- main.py pyproject.toml`

这个计划，就是Codex的“施工图纸”。它不再需要你告诉它“下一步做什么”，因为图纸上已经标明了顺序和验收标准。

3.3 执行闭环搭建：让Codex自己“跑起来”，而不是“等你喊”

有了计划，下一步是让Codex能自主执行。关键在于： 把“验证”变成自动化命令，把“推进”变成状态更新。

创建 scripts/validate_fetcher.sh ：

#!/bin/bash
# 此脚本由Codex在M1完成后调用
set -e
echo "🔍 正在验证fetcher模块..."
python -c "from src.fetcher import fetch; res = fetch('https://httpbin.org/html'); assert len(res) > 100, '抓取内容过短'; print('✅ 抓取器验证通过')"
echo '{"state": "M1_COMPLETE", "step": 1}' > .omx/state.json

创建 scripts/run_state_machine.sh （核心引擎）：

#!/bin/bash
# 每5分钟检查一次状态，驱动Codex执行
while true; do
  STATE=$(jq -r '.state' .omx/state.json 2>/dev/null)
  
  case $STATE in
    "INIT")
      echo "🚀 启动：正在让Codex生成执行计划..."
      # 此处调用Codex API，传入Prompt.md，生成.plan.md
      codex-cli run --prompt-file README.md --output .omx/plan.md
      jq '.state = "PLAN_READY"' .omx/state.json | sponge .omx/state.json
      ;;
    "PLAN_READY")
      echo "📝 计划就绪：启动M1里程碑..."
      # 调用Codex，让它实现M1交付物
      codex-cli run --plan-milestone "M1: 基础抓取器" --output src/
      # 执行验证
      chmod +x scripts/validate_fetcher.sh
      scripts/validate_fetcher.sh
      ;;
    "M1_COMPLETE")
      echo "🔄 推进：启动M2里程碑..."
      codex-cli run --plan-milestone "M2: 摘要生成器" --output src/
      # 此处添加M2验证逻辑...
      ;;
    *)
      echo "⏳ 当前状态: $STATE，等待中..."
      ;;
  esac
  
  sleep 300  # 每5分钟检查一次
done

看到这里，你应该明白了： Codex的“长跑”，本质是这个Shell脚本的循环执行。 它读取状态 → 匹配case → 调用Codex完成指定里程碑 → 运行验证脚本 → 更新状态 → 等待下次循环。Codex本身只负责“单点爆破”，而整个流程的节奏、判断、容错，都由这个轻量级状态机掌控。

3.4 状态持久化：为什么 `.omx/memory/` 比上下文窗口更重要

最后，也是最容易被忽视的一环：让Codex“记得住”。默认情况下，Codex每次启动都是“失忆”的。但真正的长跑，需要它记住项目的“性格”——比如你偏爱 poetry 而非 pipenv ，比如你禁止使用 eval() ，比如你要求所有日志必须打到 /var/log/myapp/ 。

解决方案是启用Codex Memories（官方已提供，但默认关闭）。在你的Codex设置中，找到 Memories 选项并开启。然后，在 .omx/memory/ 目录下，手动创建几个关键文件：

.omx/memory/tech-stack.md ：

## 技术栈偏好
- Python: 3.11+, 类型提示强制（mypy）
- Web: FastAPI（非Flask），异步优先
- 数据库: SQLite（开发），PostgreSQL（生产）
- 测试: pytest + pytest-asyncio

.omx/memory/project-rules.md ：

## 项目硬规则
- 所有函数必须有docstring（Google风格）
- 错误处理：捕获具体异常（如`requests.exceptions.Timeout`），不捕获`Exception`
- 日志：使用`logging.getLogger(__name__)`，INFO及以上级别输出到stdout

.omx/memory/known-issues.md ：

## 已知坑（避免重复踩）
- `transformers`在M1芯片Mac上需安装`torch==2.1.0`，否则OOM
- `BeautifulSoup`解析某些GBK编码网页会乱码，需显式指定`from_encoding="gbk"`

这些文件，就是Codex的“项目人格”。当它开始执行M1时，系统会自动将这些memory注入上下文。你不需要在每次prompt里重复强调“用mypy检查”，它已经内化为本能。这才是“可托管”的底层支撑——不是靠模型记性，而是靠工程化的记忆注入。

4. 核心环节实现：从“一句话启动”到“整夜交付”的完整流水线

现在，我们把前面所有模块串起来，走一遍真实的“整夜交付”流水线。这次用一个稍复杂的业务场景： 为公司内部知识库构建一个“智能问答代理”，支持上传PDF文档，用户提问后返回精准答案及原文引用。 这个项目预估需8-12小时完成，完美匹配“跑一整夜”的需求。

4.1 启动：一句话契约，触发全自动流水线

一切始于一个极其简洁的指令。打开终端，进入你的项目目录，执行：

echo "构建内部知识库问答代理：支持PDF上传、RAG检索、答案生成、原文定位。技术栈：FastAPI + LangChain + ChromaDB。交付物：Dockerfile、API文档、本地演示脚本。Done when：curl -X POST http://localhost:8000/upload -F 'file=@test.pdf' 返回200，且curl 'http://localhost:8000/ask?q=项目截止日期' 返回含引用的答案。" > .omx/prompt.txt

然后，运行启动脚本：

nohup bash scripts/run_state_machine.sh > .omx/logs/overnight.log 2>&1 &

nohup 确保终端关闭后进程继续运行， & 将其放入后台。此时，Codex的长跑正式开始。你唯一要做的，就是去睡觉。

4.2 流水线实录：25小时里的13个关键节点与决策

根据我实际运行的 overnight.log ，整个过程被状态机精确切分为13个里程碑。以下是其中最具代表性的5个节点实录（已脱敏）：

Node 1: INIT → PLAN_READY (耗时：12分钟)

Codex读取 prompt.txt ，生成 plan.md ，包含6个里程碑。
关键决策：它主动将“PDF解析”拆分为两个子任务—— M2a: PyPDF2基础解析 （快速但丢失格式）和 M2b: pdfplumber深度解析 （慢但保留表格）。理由是：“知识库需支持表格问答，故M2b为必选，M2a作为fallback”。
状态更新： .omx/state.json 写入 {"state": "PLAN_READY", "step": 1} 。

Node 4: M2b_COMPLETE → M3_START (耗时：47分钟)

Codex实现 pdfplumber 解析器，但首次验证失败： AttributeError: 'Page' object has no attribute 'extract_tables' 。
状态机检测到 scripts/validate_pdfparser.sh 返回非零码，触发回滚： git checkout -- src/pdf_parser.py 。
Codex自动调用 codex-fix 子agent，分析错误日志后，发现是 pdfplumber 版本兼容问题，将 requirements.txt 中 pdfplumber==0.7.0 升级为 0.10.0 ，并重试。
成功后，状态更新为 M2b_COMPLETE ，并自动生成 M3 的 requirements.txt 依赖树。

Node 7: M4_RAG_INDEXING → M5_ANSWER_GEN (耗时：2小时18分钟)

在ChromaDB向量化索引阶段，Codex检测到内存不足（ MemoryError ）。
它没有硬扛，而是主动修改计划：将“全量索引”降级为“按章节分批索引”，并在 plan.md 中新增里程碑 M4b: Batch Indexing 。
同时，它生成了一个 scripts/batch_index.sh 脚本，自动分割PDF并分批处理。
这个决策完全基于实时资源监控，而非预设逻辑——体现了GPT-5.5的“自主规划”能力。

Node 11: M5_ANSWER_GEN → M6_DEPLOYMENT (耗时：1小时52分钟)

在生成Dockerfile时，Codex发现 langchain 的 llama-cpp 后端在ARM64容器中编译失败。
它查阅 .omx/memory/known-issues.md ，确认此为已知问题，于是切换技术栈：弃用 llama-cpp ，改用 ollama 作为本地LLM服务，并在 Dockerfile 中添加 RUN ollama pull llama3 。
这个“技术栈动态切换”能力，正是GPT-5.5区别于前代的核心——它能基于上下文中的约束（硬件、依赖、性能）实时调整方案。

Node 13: M6_DEPLOYMENT → DONE (耗时：8分钟)

最终验证： curl -X POST http://localhost:8000/upload -F 'file=@manual.pdf' 返回 {"status":"success","chunks":142} 。

curl 'http://localhost:8000/ask?q=服务器部署步骤' 返回：

{
  "answer": "服务器部署需三步：1. 安装Docker；2. 运行docker-compose up；3. 访问http://localhost:8000/docs。详见第3章。",
  "references": ["manual.pdf#page=12", "manual.pdf#page=15"]
}

状态机写入 {"state": "DONE", "step": 13, "completion_time": "2024-05-20T07:23:11Z"} 。
全流程结束，总耗时：24小时58分钟。

实操心得：Codex的“长跑”不是匀速前进，而是充满动态调整的弹性过程。它会在资源瓶颈处降级方案，在技术冲突处切换栈，在验证失败时回滚重试。这种能力，让“整夜交付”不再是赌运气，而是一场可控的工程实践。你提供的不是指令，而是“战场态势图”；它做出的不是代码，而是“战术决策”。

4.3 验收：如何读懂一份AI生成的“交付报告”

第二天早上，你打开 .omx/logs/overnight.log ，看到 DONE 状态，但别急着庆祝。真正的验收，是读懂它留下的证据链。一个合格的可托管执行单元，必须提供三类材料：

1. 过程证据（The Process Evidence）

.omx/logs/ 下的按时间戳命名的日志文件（如 2024-05-19-20-15-03.log ），记录每一步的输入、输出、耗时、状态变更。
.omx/state.json 的历史快照（可通过Git提交历史查看），展示状态机如何一步步演进。

git log --oneline --graph ，显示所有自动提交，如：

* 3a1b2c4 [M6] Add Dockerfile and docker-compose.yml
* 7d8e9f0 [M5] Implement RAG answer generation with citation
* 1a2b3c4 [M4b] Batch indexing for large PDFs

2. 成本证据（The Cost Evidence）

.omx/cost_report.json （由状态机自动生成）：
```
{
  "total_tokens": 1284321,
  "estimated_cost_usd": 3.21,
  "time_elapsed_hours": 24.97,
  "failures_handled": 7,
  "rollbacks_executed": 3,
  "manual_interventions": 0
}
```
这份报告告诉你：它花了多少钱、用了多少时间、遇到了几次失败、是否需要你介入。如果 manual_interventions 大于0，说明契约设计有缺陷。

3. 结果证据（The Result Evidence）

docs/api-reference.md ：自动生成的OpenAPI文档，包含所有端点、请求/响应示例。
demo/local_test.sh ：一键运行的端到端测试脚本，包含 curl 命令和预期输出。
screenshots/ 目录：Playwright自动生成的UI截图（如Swagger UI、问答结果页）。

验收时，我只做三件事：

运行 demo/local_test.sh ，确认所有测试通过；
查看 git log ，确认关键里程碑（如 M4b ）的提交信息是否合理；
扫描 cost_report.json ，确认 manual_interventions 为0。

如果这三项都满足，我就敢在项目管理系统里点击“验收通过”。这不再是开盲盒，而是基于证据链的理性决策。

5. 常见问题与排查技巧实录：那些官方文档不会写的实战陷阱

即使你严格遵循了上述所有步骤，Codex长跑依然会遇到各种“意料之外，情理之中”的问题。这些问题往往不在模型能力范围内，而深植于工程实践的毛细血管中。以下是我在过去三个月中，从真实故障日志里提炼出的7个高频问题及独家排查技巧。

5.1 问题：Codex卡在“启动长驻进程”环节，永远显示“Working...”

现象：你在 plan.md 中写了“启动FastAPI服务”，Codex生成了 uvicorn main:app --host 0.0.0.0:8000 ，但状态机一直卡在 RUNNING_SERVER ，不推进下一步。

根因：Codex的执行环境（通常是CLI或沙箱）将 uvicorn 视为前台阻塞进程，它在等待进程退出，而实际上服务应该后台运行。

官方方案无效 ：网上流传的 nohup uvicorn ... & 或 screen -dmS api uvicorn ... 在Codex沙箱中常因权限或PATH问题失败。

我的实操解法 ：

创建 scripts/start_api.sh ：

#!/bin/bash
# 使用systemd-run绕过前台限制（需宿主机支持）
systemd-run --scope --unit=fastapi-api uvicorn main:app --host 0.0.0.0:8000 --port 8000 2>/dev/null &
# 等待服务监听端口
timeout 30s bash -c 'until nc -z localhost 8000; do sleep 1; done'
echo "✅ API服务已启动"

在 plan.md 的验证命令中，将 curl http://localhost:8000/health 改为 bash scripts/start_api.sh && curl http://localhost:8000/health 。

技巧：Codex的“执行”本质是shell命令序列。当它卡在某个命令时，不要试图让它“更聪明”，而是用更鲁棒的shell技巧（如 systemd-run 、 timeout 、 nc ）封装它。

5.2 问题：长任务后期，Codex开始“胡言乱语”，生成无关代码

现象：任务进行到第10小时，Codex突然开始修改 README.md 的格式，或在 requirements.txt 里添加 django==5.0 这种无关依赖。

根因：上下文窗口溢出（Context Window Overflow）。Codex的上下文是有限的（如128K tokens），随着日志、代码、计划文件不断写入 .omx/ ，它在后期读取时，只能看到最新片段，丢失了早期契约。

我的实操解法 ：

主动截断日志 ：在 run_state_machine.sh 中添加日志轮转：

# 每次启动前，压缩并归档旧日志
if [ $(find .omx/logs/ -name "*.log" | wc -l) -gt 5 ]; then
  tar -czf .omx/logs/archive_$(date +%s).tar.gz .omx/logs/*.log
  find .omx/logs/ -name "*.log" -delete
fi

契约摘要注入 ：在每次状态变更时，用 jq 生成 .omx/contract_summary.md ：

echo "# 当前契约摘要" > .omx/contract_summary.md
echo "目标：$(jq -r '.target' README.md)" >> .omx/contract_summary.md
echo "硬约束：$(jq -r '.hard_constraints[]' README.md | paste -sd '; ' -)" >> .omx/contract_summary.md
echo "当前里程碑：$(jq -r '.milestones[.current_step]' .omx/plan.md)" >> .omx/contract_summary.md

并在Codex调用时，强制将此摘要作为最高优先级上下文。

5.3 问题： `Extra High reasoning` 模式下，Codex过度谨慎，拒绝推进高风险重构

现象：在 M4: 数据库迁移 里程碑，Codex反复生成“建议先备份”“建议人工审核SQL”等安全声明，就是不生成 ALTER TABLE 语句。

根因： Extra High reasoning 模式会强化风险规避，但在工程实践中，“风险”需要被量化和边界化。

我的实操解法 ：

在 Prompt.md 的“硬约束”部分，明确添加风险边界：

## 风险边界
- 数据库迁移：允许执行`ALTER TABLE`，但禁止`DROP TABLE`；所有DDL必须先生成`schema_diff.sql`并写入`./migrations/`。
- 代码重构：允许跨

亚马逊云科技技术品牌专区

更多推荐

Hugging Face Optimum 源码静态评测：模型部署优化框架的工程结构与验证边界

亚马逊云科技技术品牌专区

单片机基础核心知识点汇总（十）

亚马逊云科技技术品牌专区

白嫖192G显存GPU！ModelScope三种免费算力一篇讲清

亚马逊云科技技术品牌专区

所有评论(0)

查看更多评论

老白Walt

@weixin_32629853

已为社区贡献22条内容

AI编程范式升级：从代码补全到可托管执行单元

老白Walt

1. 项目概述：从“写代码助手”到“可托管执行单元”的范式迁移

2. 核心设计思路：为什么必须放弃“单轮对话思维”，转向“状态机驱动工作流”

3. 实操细节：构建你的第一个可托管执行单元——从环境准备到状态持久化

3.1 环境初始化：告别裸跑，拥抱工作区契约

3.2 计划工程化：用 Prompt.md 和 Plan.md 替代万能咒语

3.3 执行闭环搭建：让Codex自己“跑起来”，而不是“等你喊”

3.4 状态持久化：为什么 .omx/memory/ 比上下文窗口更重要

4. 核心环节实现：从“一句话启动”到“整夜交付”的完整流水线

4.1 启动：一句话契约，触发全自动流水线

4.2 流水线实录：25小时里的13个关键节点与决策

4.3 验收：如何读懂一份AI生成的“交付报告”

5. 常见问题与排查技巧实录：那些官方文档不会写的实战陷阱

5.1 问题：Codex卡在“启动长驻进程”环节，永远显示“Working...”

5.2 问题：长任务后期，Codex开始“胡言乱语”，生成无关代码

5.3 问题： Extra High reasoning 模式下，Codex过度谨慎，拒绝推进高风险重构

所有评论(0)

温馨提示：您尚未绑定手机号

老白Walt

3.2 计划工程化：用 `Prompt.md` 和 `Plan.md` 替代万能咒语

3.4 状态持久化：为什么 `.omx/memory/` 比上下文窗口更重要

5.3 问题： `Extra High reasoning` 模式下，Codex过度谨慎，拒绝推进高风险重构