放弃那些冗长的 Shell 脚本，用 JSON5 声明式管理开发环境是什么体验
setup.sh 脚本，里面塞满了 brew install 或者 apt-get，但这种命令式脚本最大的痛点在于：它没有“状态意识”。如果你重复运行一遍，可能会因为软件已安装而报错，或者导致配置文件被重复覆盖。Codify 解决这个问题的核心逻辑是引入了 plan 和 apply 的工作流。这意味着你不再是告诉电脑“去安装这个软件”，而是定义“我的环境应该处于什么状态”。
在实际操作中，你会编写一个 JSON5 格式的配置文件。这里值得一提的是它选择 JSON5 而不是 YAML 或 HCL，很大程度上是为了在保持声明式结构的同时，降低编写门槛，毕竟 JSON5 支持注释且对语法要求没那么苛刻。比如，如果你想配置 VS Code 的插件和 Homebrew 的基础包，你只需要在配置文件中定义资源状态：
{
resources: {
vscode: {
installed: true,
extensions: ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"]
},
homebrew_packages: ["git", "node", "python3"]
}
}当你运行 codify plan 时，它会扫描你当前的系统状态，并对比配置文件，然后输出一个变更清单。这个步骤至关重要，因为它能让你在正式执行前确认：它是否会误删某个已安装的工具，或者是否正确识别了版本差异。确认无误后，执行 codify apply 才会真正触发安装或配置变更。如果后续环境发生了手动漂移，可以通过 codify refresh 来同步状态。
很多追求极致环境隔离的人会提到 Nix，但 Nix 的学习曲线确实过于陡峭，且倾向于接管整个系统路径。Codify 走的是一种“实用主义”的折中路线。它并不试图重新定义操作系统的文件层级，而是通过调用现有的包管理器（目前支持 Homebrew、apt、dnf 等）来完成任务。这意味着它能与你现有的环境完美共存，不需要你为了配置一个 IDE 而重建整个系统。
从资源覆盖率来看，它目前内置了 50 多个资源库，涵盖了 Git、SSH 以及主流的开发工具链。对于大多数开发者来说，这已经足够覆盖 90% 的日常配置需求。
当然，目前的局限性也比较明显。由于私有插件市场尚未完全开放（目前仍处于安全验证阶段），如果你需要一些非常冷门的工具配置，依然依赖于官方维护的资源库。但即便如此，这种声明式管理方案在可维护性上依然完胜几百行且缺乏幂等性的 .sh 脚本。
总结下来，Codify 实际上是给开发环境做了一次“版本控制”。当你换新电脑或者需要同步团队环境时，不再需要翻找那篇过时的 Wiki 文档，只需要一个配置文件，通过 plan 确认，apply 部署，整个开发链路就能在几分钟内快速复刻。
