GPT-5.2 发布后 Reddit 用户的编码与对话体验

一句话结论

社区反馈显示 GPT-5.2 在遵循项目 .md 工作流和一次性修复部分前后端问题上有明显好评，但停止过早、需要更多提示工程、语气变化和长流程遗忘也反复出现，适合当作待验证假设而非 benchmark。

测试环境

• 环境：ChatGPT/CLI/编码工作流的用户自述；版本、上下文长度、工具和项目大小不统一。

• 输入/配置：一部分用户给模型项目 Markdown 工作流；一部分用户比较 GPT-5.2 与 Claude Opus 4.5 的 debug/fix 任务。

• 结果形式：评论中的主观成功/失败描述，没有统一任务集、运行次数、成本日志或盲评。

输入/配置

可复用的工作流做法是把项目约定、测试命令和完成标准写进仓库 Markdown，再让 CLI 模型按文档执行；比较实验则应固定同一 issue、同一工具权限和同一测试命令。原帖没有公开足够完整的可复制 prompt，因此不把评论包装为完整提示词。

结果数据

• 一位用户表示 CLI GPT-5.2 很擅长按 .md 文档中的工作流执行。

• 一位用户对比称，两次 Claude Opus 4.5（Copilot）debug/fix 后，GPT-5.2 以约两次调用解决同一类问题；另一条更新称 GPT-5.2 曾“一次性”修好后端和前端错误。

• 同一讨论也提到 GPT-5.2 可能更早停止，需要更多提示工程来主动发现/修复错误；另有用户反馈更冷淡、连续性较弱、长任务会忘记上下文或过度调用工具。

• 这些数字和结论均为单个用户的记忆式报告，不能推导总体成功率或与 Opus 的严格成本比。

结论

在已有项目文档、测试命令和明确验收条件的编码任务中，GPT-5.2 Chat 值得作为快速执行/修复候选；应加上“继续检查直到测试通过、报告未解决项”的完成协议，并用自动化 eval 防止过早收工。

局限

• Reddit 用户身份、模型 snapshot、工具配置和任务难度不可核实。

• 体验有互相矛盾的正负反馈，且没有完整输入/输出，无法复现具体成功案例。

• Chat 体验不能替代 SWE-bench 或官方 Thinking 基准；成本比较也可能混合 Copilot、API 和 ChatGPT 计费。

复现步骤

1. 选取 10–20 个真实 issue，给 GPT-5.2 Chat 同一份项目 Markdown、测试命令和工具权限。

2. 预注册完成标准：修复、测试、差异审查和未解决项报告；禁止以“看起来完成”结束。

3. 记录每轮 prompt、工具调用数、停止原因、测试结果、耗时和费用，并与固定版本的其他模型盲评。

4. 单独统计一次成功、需追加提示、误改范围、幻觉引用和测试失败，避免只记住最佳案例。