最近鞭策 Claude Code 写代码的时候，发现了些有趣的现象。
1. “原原本本”与“适度超前设计”的博弈
我把需要实现的场景“原原本本”描述给 Claude Code，它能写得非常周全、滴水不漏。但在整体架构视角下，这个需求完全可以被抽象成一个更加简洁的模型，再去依据模型做实现。
我原本以为 Claude 是可以自动做到这点的（但这也有可能是被 opus 4.6 惯坏了，用得太顺手，对 LLM 的能力有了过度信任），我期望它能从我描述的 zero-shot 或 few-shot 中自行提炼出最佳实践。但现实是，当前的 LLM 依然高度倾向于“听从人类指令”——你的描述有多具体，它的实现就有多具象。
举个例子：当你向他提及走路上山时，他会走最刁钻的路到达山顶，而不是坐隔壁的缆车，即使在这个场景里你只需要他“到山顶”即可。他有可能会问你能不能做缆车，但更多时候还是倾向于听你“随口一说”的提示词干活。
这并非 LLM 能力不足，而是它在强引导性的提示词下，默认会避免写出“Overkill（过度设计）”的代码。然而在某些场景下，适度 Overkill 带来的抽象逻辑反而更清晰。
2. “向后兼容”执念
现在的 AI Coding 工具都有一个通病：喜欢在“屎山”上继续堆砌。
即使在完全不需要考虑对外 API 兼容的场景下，它们也乐衷于做向后兼容。我往往用“重构（Refactor）”一词来向 AI 表达调整欲望，但“重构”这个词还是太温柔了。
AI 会像模像样分析之前的代码（当然也是它写的代码！），我默默看它左脑攻击右脑，最后它给出个不上不下的方案，并且眨巴眨巴眼睛，问我：“您满意这个方案吗？满意的话我将立刻重构。”
我满意你个鬼啊！
3. 授权“破坏性改动”
这种“不求有功但求无过”的选择倾向，让 “破坏性改动（Destructive / Breaking Solution）” 一词的价值就显得尤为关键。
我现在在做重构倾向任务的时候，会直接告诉 Claude Code：
“之前写的都是构思（狗屎）玩意儿，允许做破坏性改动，直接推翻重来！”
LLM 真不是能力不够，试着去打破它的“安全感”，往往能写出更惊艳的代码结构。显然，“破坏性改动”比“重构”表达得更精准、更具魄力。
但话又说回来，发现抽象模型，并描述给 Claude Code 本来就是你的任务。如果把思考环节也外包给 Claude Code，未免有点太放空大脑了。
