Ox Alpha 复杂项目工作流：规划文件、模式切换与代码审查技能

一句话结论

对大型、低级或新语言项目，先用较大的规划文件拆出下一批工作，再在 code/debug 模式间切换，并给模型明确的审查与验证技能，是一套可复用的长任务工作流。

适用场景

• 适合的任务：大型后端、性能优化、低级语言、新语言或需要长时间连续执行的项目。

• 不适合的任务：重复性机械改动（应优先脚本化），或没有测试、没有版本控制的生产仓库。

• 适用的模型版本：Ox Alpha；原帖没有版本快照。

• 适用的客户端、Agent 或 API：评论提到 Kilo、Antimatter、OpenCode 等不同客户端体验，未固定单一 Harness。

• 推荐的推理档位和参数：未公开；code/debug 模式按任务固定并记录，避免同一试验中隐含改变。

可直接使用的内容

原帖没有公开完整 prompt；以下是根据作者描述整理的可复用工作流：

1. 固定仓库 commit、编译命令、测试命令和性能基线。
2. 建立一个总规划文件，记录目标、已知约束、模块依赖、风险和当前待办；把下一批工作拆到独立的小规划文件中。
3. 先让 Ox Alpha 只读规划文件和相关代码，返回“理解到的事实、待确认假设、下一步和验证命令”，不要立刻扩散到全仓库。
4. 实现阶段使用 code 模式；遇到性能、类型、安全或测试问题时切换到 debug 模式，并附原始错误与最小复现。
5. 安装或启用能约束模型的技能：代码审查、规划、正确性验证和调试器使用。技能只描述行为要求，不替代测试。
6. 每批改动后运行编译、单测、集成测试和必要的性能检查；更新规划文件中的事实与未解决问题。
7. 对最终 diff 做一次独立 review，特别检查未定义行为、内存安全、性能回退和无关重构。

原始体验与边界

作者称自己用 Ox Alpha 做原生 D 后端时，较大的主规划文件约 1050 行，并用更小文件拆分后续工作；从 code 切换到 debug 后，后端优化效果变好；代码审查、规划、正确性验证和调试器技能也有帮助。作者没有公开仓库轨迹、完整规划文件或同任务基线。

配置注意

• 规划文件过大可能增加上下文噪声，应把“事实、决策、下一步”分开。

• 性能代码和 unsafe/assembly 代码必须由编译器、测试和人工 review 验证，不能只依赖模型解释。

• 重复性任务优先用脚本；让模型反复执行相同机械操作会增加成本和失败面。