说到代码里的硬编码，其实挺常见的。
比如我们做视频生成工具时，早期就直接写了：
文件路径：/Users/apple/Documents/...
封面标签："育儿心得"、"亲子阅读"
视频尺寸：1080×1920
当时看着没问题，结果一换电脑、换文章、换平台，全崩了。
更麻烦的是，这些值在好几个地方重复写死。改一个地方，漏三个，bug 像雨后春笋一样冒出来。
第一个坑：别把具体当成唯一解
这让我想到生活里也到处都是“硬编码”。
比如：
- “我只会用这个软件做 PPT”
- “笔记只存在这个文件夹”
- “文章只能是文字形式”
- “工作流程必须按这个顺序”
听起来很稳定？其实是在给自己设限。
一旦环境变了——软件更新了、文件夹丢了、平台规则改了、流程要调整了——你就卡住了。
回到正题：抽象不是为了复杂，是为了灵活
消除硬编码的过程，其实就是练抽象思维。
不是记住“文件放 /Users/apple/Documents”，而是理解：“应该放在项目同级目录，路径由输入决定”。
也不是死记“封面标签是育儿心得”，而是学会：“标签得从内容里自动提取关键词”。
更不是硬套“视频必须 1080×1920”，而是想明白：“尺寸得看场景，手机竖屏，电脑横屏”。
抽象的本质，就是找到那些不变的规律。
说到这个，有意思的地方来了
抽象不是让你脱离现实，反而是让你能更自由地面对具体。
当“视频尺寸”变成可配置参数后，你不仅能做竖屏，还能一键切换成横屏。
不是抛弃细节，而是拥有了更多选择。
当“封面标签”变成自动提取逻辑后，每篇文章都能匹配自己的主题。
不是失去个性，而是让每个个体都更贴合自己。
好的抽象，其实是通往更多可能性的桥梁。
现在有个小测试，帮你发现隐形硬编码
我会问自己一个问题：
如果换一个场景、换一个工具、换一个人来做这件事，我的方法还成立吗？
如果答案是不是，那说明某个环节被写死了，该重新抽象一下了。
写在最后
代码里的硬编码容易发现，因为编译器会报错、测试会失败。
但思维里的硬编码很难察觉，因为它不会报警，只会让你在变化面前感到无力。
消除硬编码，本质上是在训练一种能力：
在任何具体情境中，看到背后的通用结构。
这种能力，在代码里叫“架构设计”，在生活里叫“通透”。