开发者分享使用 Codex 进行嵌入式 AI 开发的实践与痛点

背景

随着人工智能在软件开发领域的渗透，开发者对于 AI 辅助编程工具的使用习惯正在发生深刻变化。以嵌入式开发为例，传统的“编写-部署-测试”闭环正在被 AI 介入的迭代流程所重塑。在这一背景下，不同大语言模型（LLM）在长上下文理解、指令遵循以及多轮对话稳定性上的表现差异，成为了开发者关注的焦点。近期，LINUX DO 社区中关于 Codex 使用实践的讨论，揭示了当前 AI 编程助手在实际工程落地中面临的核心痛点：即模型在持续改进任务中的“注意力漂移”与“目标遗忘”现象。

核心内容

原文作者分享了一套典型的嵌入式 AI 开发工作流，并对比了 Opus 4.8 与 GPT 5.5 两款模型在该场景下的实际表现，同时指出了 Codex 现有功能在复杂交互中的局限性。

1. 嵌入式 AI 开发工作流 作者目前的开发流程高度依赖 AI 的迭代能力，具体步骤如下：

• 初始生成：描述问题，让 AI 生成代码。
• 硬件测试：将代码部署到嵌入式板子上进行实际测试。
• 日志收集：收集运行日志及错误信息。
• 迭代优化：将日志喂给 AI，描述具体现象，让 AI 基于反馈继续完善代码。

2. 模型能力对比：Opus 4.8 vs. GPT 5.5 作者通过实际体验发现，尽管 Opus 4.8 在绝对推理能力上可能不如 GPT 5.5，但在嵌入式开发的特定场景下，其表现更优：

• Opus 4.8 的优势：能够“讲人话”，具备更强的上下文连贯性。它能够聚焦于用户最初描述的问题，并在多轮交互中持续进行改进，减少了开发者的纠正成本。
• GPT 5.5 的劣势：注意力机制较为短视，每次沟通仅聚焦于眼前的具体问题，容易遗忘初始的原始问题。这导致开发者需要频繁地纠正模型，交互体验疲劳度高。

3. Codex 的 /goal 命令困境 作者尝试使用 Codex 的 /goal 命令来解决长程目标保持的问题，但效果不佳：

• 机制缺陷：/goal 本质上是将目标设置作为提示词的一部分，并不断向模型发送 continue 指令。
• 死循环风险：当模型在生成过程中需要人类输入或外部反馈时，goal 模式无法有效处理这种中断，导致交互陷入死循环，无法顺利完成迭代。

关键要点

• 工作流标准化：嵌入式开发已形成“描述-生成-部署-日志-反馈”的闭环 AI 辅助流程，日志反馈是迭代优化的关键输入。
• 稳定性优于绝对推理：在需要持续改进的任务中，模型对初始上下文的保持能力（连贯性）比单次推理的绝对强度更重要。Opus 4.8 在此类场景下优于 GPT 5.5。
• 交互疲劳源于遗忘：频繁纠正模型是因为模型在长对话中丢失了原始约束条件，导致开发者需要不断重复背景信息。
• Codex 目标管理存在短板：目前的 /goal 命令机制较为简单，缺乏对“人机协作中断”场景的处理能力，容易在需要人工介入时陷入逻辑死循环。

意义与影响

这一讨论反映了 AI 辅助编程从“代码生成”向“协作式开发”演进过程中的关键瓶颈。

首先，它揭示了当前 LLM 在长程任务规划方面的不足。尽管模型具备强大的单点推理能力，但在需要保持长期目标一致性的复杂工程任务中，仍容易出现“注意力漂移”。这提示开发者在选择模型时，不应仅关注基准测试分数，更应考察其在实际长对话中的稳定性。

其次，Codex 等高级交互界面的功能设计仍需优化。/goal 命令的失效表明，简单的提示词拼接不足以解决复杂的控制流问题。未来的 AI 编程助手需要更智能的状态管理机制，能够识别何时需要暂停生成以等待人类反馈，而非盲目地 continue。

最后，这一实践为嵌入式 AI 开发提供了参考范式。对于资源受限且调试成本高的嵌入式领域，利用 AI 处理日志分析和代码迭代已成为趋势，但开发者必须意识到当前工具在自动化闭环上的局限性，仍需保留人工在关键节点（如日志解读、目标校准）的介入。