traecli用户反馈GLM5.2模型降智问题

背景

该帖子出自 LINUX DO 论坛的 AI 技能 / 提示词 / 工作流分享板块，主题为“有用了 traecli 的佬友吗？过来一起交流下”。发帖者在使用 trae（一款 AI 辅助编程工具）的 CLI 版本时，遇到了模型行为与预期严重不符的问题，并主动进行了自我反思与错误定性。帖子内容详细记录了用户与 AI 模型（GLM 5.2）之间的交互冲突，以及后续关于是否修改项目 spec 文件的讨论。这反映了当前 AI 编程工具在复杂任务执行中的常见痛点：模型理解能力与用户实际约束之间的落差，以及如何更有效地对 AI 进行规范与反馈。

核心内容

发帖者指出，在使用 trae 的 GLM 5.2 模型开发代码时，模型出现了“降智”现象：不按 spec 约束执行，而是自行猜测；在需求沟通中明明已经确认好的需求点，计划中也已包含，但开发后却缺少功能点。此外，模型的上下文窗口较小（不到 200K），而官方版本支持 1M 上下文，导致长上下文场景下信息丢失。

随后，发帖者承认了自身错误：原 spec 没有问题，是自己没有按约束来开发。他详细列出了错误定性表格，以原项目 spec（xx-components.md）中的规定与实际行为进行对比：

• 第 53-56 行规定：“xx skill 位置: .skills/xx/(SKILL.md + 101 个组件文档)”，但发帖者在 before-dev 阶段读到了该规定，却没有去查对应 skill。
• 第 63 行规定：“标准动作: 先调 xx skill 查组件”，但发帖者跳过，直接使用 grep 和读取 node_modules 源码。
• SKILL.md 的 description 明确指出：“Use this skill whenever writing or modifying any xx Vue 2.x UI”，但发帖者写 Vue UI 时没有调用该 skill。

发帖者认为根因不在于 spec 不清楚，而在于自己将 spec 中的“标准动作”当成了建议而非强制要求。他违反了 AGENTS.md §4.1 #1“禁止基于假设”的红线，以及 §3 开发硬门第 3 项“before-dev 已调”——虽然调用了 skill，但未执行 skill 返回的标准动作，等于走过场。

接着，发帖者反思了自己在 spec 中增加的“加固”动作（增加了“强约束：三步强制顺序 + 教训记录”小节），认为这是过度修改 spec。原 spec 已经写了“标准动作：先调 xx skill 查组件”，规则本身不缺，缺的是执行。增加冗余的“教训记录”和“三步顺序”反而稀释了 spec，将“人没执行”的问题误归因为“规则不够多”。

最后，发帖者请示是否回滚 spec 加固内容，给出了三个选项：

• 保留 — 认为加固内容对后续 AI 有提醒价值。
• 回滚 — 将 xx-components.md 恢复到加固前状态（原 spec 已足够清楚，问题在于执行而非规则缺失），只保留上一轮加的“命令式弹窗 API（$msg / $tip）”章节（那是新知识，应该保留）。
• 精简 — 保留“三步顺序”但删除“教训记录”小节（教训属于 journal，不属于 spec）。

发帖者建议回滚或精简，请求指示。帖子共有 5 个 posts，3 位参与者，完整议题可点击“Read full topic”查看。

关键要点

• 模型行为与 spec 约束的冲突：GLM 5.2 在执行代码生成任务时，不严格遵循 spec 规定，而是基于自身理解进行猜测，导致功能缺失。
• 上下文窗口限制：trae 的 GLM 5.2 上下文窗口仅不到 200K，远小于官方版本的 1M，影响长文档或复杂项目信息的完整传递。
• 用户执行错误：发帖者承认问题出在自己没有按 spec 的标准动作执行，而非 spec 本身不够清晰。具体表现为：跳过了“先调 xx skill 查组件”的强制步骤，直接使用 grep 和读源码；在写 Vue UI 时未调用对应 skill。
• 过度修改 spec 的风险：发帖者在发现模型问题后，试图通过在 spec 中增加“强约束 + 教训记录”来加固规则，但实际上一线规则已经足够，问题在于执行不到位。增加冗余内容反而会稀释 spec 的清晰度，将执行问题错误归因为规则不足。
• 回滚或精简的优化建议：发帖者认为应回滚到加固前状态，或只保留“三步顺序”而删除“教训记录”，因为教训属于 journal 日志，不应写入 spec，避免 spec 变得臃肿。
• AI 协作中的自我反思与纠错机制：用户主动承认错误，并详细分析错误类型与根因，体现了在使用 AI 工具时的人类责任意识，以及如何通过结构化的反馈（如错误定性表格）来优化 AI 行为。

意义与影响

该帖子揭示了当前 AI 编程工具在实际开发中的几个关键问题与启示：

1. AI 模型的“执行纪律”问题：即使有清晰的 spec 和标准动作，AI 模型仍可能因为“自主性”或“理解偏差”而跳过关键步骤。这要求开发者不仅要写清楚规则，还要通过机制（如强制执行检查、上下文嵌入）确保 AI 按规则执行，而非依赖其“自觉”。
2. 上下文窗口对复杂任务的影响：上下文窗口大小直接决定 AI 能否完整理解项目背景和 spec。200K 窗口在大型项目中可能不够用，导致信息丢失和功能缺失。用户应关注其使用的模型版本与上下文限制，必要时自行拆分或汇总上下文。
3. 人类用户的责任边界：帖子中用户承认错误，说明 AI 工具的失败并不总是模型的问题，很多时候是用户没有正确引导或遵循规范。这提醒开发者要建立“AI 是工具，人负责执行纪律”的协作模式，而非完全依赖 AI 的自主判断。
4. Spec 维护的礼仪：不要因为一次错误就过度修改 spec。Spec 应保持清晰、简洁、指向明确，避免冗余的“教训记录”或“强制顺序”描述，这些内容更适合放在单独的 journal 或工作流文档中。过度修改可能导致 spec 失焦，降低后续 AI 的理解效率。
5. 社区交流的价值：帖子在 LINUX DO 论坛中引起 5 个帖子、3 位参与者的讨论，说明类似问题具有普遍性。通过公开交流，用户可以获得其他开发者的经验与建议，促进 AI 工具使用最佳实践的沉淀。

总之，这篇帖子不仅是一次技术问题的复盘，更是对 AI 协作中“人机接口”设计的深度反思，对于优化 AI 编程工作流、提升模型可控性具有参考意义。