最近重度用 Trae 写代码，有个越来越强烈的感觉：Plan / Spec 这套分层思路是对的，但“让用户自己选模式”这件事，可能有点理想化。
我自己的使用轨迹基本是这样：一开始只是小改动，用 Normal 很爽；功能慢慢变复杂，人还是惯性继续用 Normal；等到开始失控，才后悔没早点上 Spec。跟不少人聊过，这种情况其实挺常见。
所以问题可能不是我们有没有 Spec，而是——我们是不是把“当前到底该怎么工作”的判断，过度外包给了用户。
我在想一个更简单的方向：把项目放进一个明确的状态机里，而不是每次单独选模式。比如一个项目始终处在某个阶段：规划、需求、架构、实现、调试。
比如我打开一个以前的项目，可以直接选择当前阶段：是在规划新方向，还是在实现功能，或者是在调试问题；也可以由 Trae 自动感知当前阶段。在这个阶段之上，再去决定采用什么样的工作方式，而不是每次都从 Normal / Plan / Spec 里拍脑袋选一个。
另外两个让我越来越有体感的点：
优化提示词按钮
现在那个“优化提示词”按钮，经常一按就生成一大段我不需要的内容，感觉它是在一个真空语境里优化，而不是在当前工程阶段下优化。
如果我在调试阶段，我更希望它帮我把报错信息、日志、复现步骤说清楚；
如果我在架构阶段，我更希望它帮我补充边界、依赖影响范围；
如果在实现阶段，它应该帮我明确输入输出和约束。
提示词优化本身，其实也应该和阶段联动，而不是一刀切地“写得更复杂”。
skill 能不能也和阶段联动？
现在 skill 更像是独立能力插件，但如果项目处在不同阶段，skill 的激活优先级是不是也应该不同？
-
在规划 / 需求阶段，产品拆解类 skill 优先
-
在架构阶段，结构分析、依赖梳理类 skill 优先
-
在实现阶段，代码生成与补全类 skill 优先
-
在调试阶段，错误分析、日志解读类 skill 优先
也就是说，skill 不只是“可用”，而是“在某个阶段天然更合理”。
如果模式选择、提示词优化、skill 激活，全部建立在“项目当前阶段”这个前提上，很多错配可能会自然消失。逻辑会从“我想怎么用 AI”，变成“我这个项目现在处在什么状态”。
不太确定大家体感如何。