正在打开每日关注
正在打开每日关注
通过验收导向的目标文档与独立进度记录，配合高推理模型执行，减少上下文污染和方向偏移。
我的实践 1. 用 SOL Max 对话，沉淀出 xxx-goal.md SOL 这一代模型聪明程度比以往高出一截，多次对话把多个需求收进一份目标文档, 反而能给模型更好的判断。除了需求还有两个细节需要注意： • 必须是「验收」——写清楚怎样算完成，不留模糊地带(如果你不清楚还有什么模糊地带你就问大模型)； • 执行过程单独记到 xxx-progress.md，不混进 goal 文档。（过多的进度会污染goal上下文） 2. 用梭哈 SOL High 执行， 每隔半小时翻一次 xxx-progress.md 的记录，确认方向没偏。 有任何问题不需要打断 codex 在输入框中补充
Codex 实践下来一个最节省 usage 的配置： - 模型 5.6 Sol - Effort 选择 Extra High 或者 Max - Speed 选择 Standard Ultra 很难用（只是会 spawn 多个 sub agent），Fast 很好用但是太耗 token 了，Ultra + Fast 一个任务就可以把 5h limits 跑完。 按照这个配置可以多消耗 2x-3x 的 token。 https://t.co/RdsskIX9o8
是什么 这是一组关于 Codex 长任务协作的经验观点：先用高能力模型把多个需求收敛为 xxx-goal.md，再用 xxx-progress.md 保存动态执行状态，最后以较高推理强度执行，并周期性查看记录确认方向没有偏航。它把“想做什么”和“做到哪里”拆成两种上下文。
核心设计 关键是把验收标准前置：目标文档不只列需求，还要写清“怎样算完成”，并主动暴露待澄清事项。进度文档承载易变化的工作日志，避免细节污染目标上下文；人类保留方向控制，Agent 持续推进，执行中可补充问题。引用内容还把模型、Effort、Speed 与 token 消耗视为资源配置问题。
关键洞察 这种方法适合需求较多、执行时间较长、需要多轮代码修改的任务。验收条件提供可测试的完成定义，进度记录提供可观察性，定期复核负责轻量纠偏，可减少目标漂移和重复解释。
边界与风险 “更省 usage”及“2x-3x token”属于个人经验，缺少任务基线，不能视为普遍结论。半小时检查可能过稀，高 Effort 也可能只增加成本；实际使用应配合自动测试、阶段性提交、停止条件，并按任务价值选择配置。