Vibe Coding 框架与模板选型：用垂直样例替代脚手架印象

输入一句需求后，编程 Agent 可以从多个脚手架迅速生成“看起来已经完成”的页面。此时最容易按首屏观感选型：哪个模板组件多、启动快、目录熟悉，就把哪个当基础。真正昂贵的差异通常藏在演示之外，例如目标平台不支持某种运行时、路由与数据加载耦合、模板默认上传遥测、认证方案无法满足租户边界，或升级只能整体重写。

框架选型不是给工具打一个通用分数，而是判断候选是否满足当前产品的硬约束。AI 编程工具选型基准讨论 Agent 产品比较；本文把同样的可复现思想用于代码框架和 starter template。

先冻结约束，后列候选

选型单先写部署形态、支持浏览器与 Node 版本、渲染方式、数据驻留、鉴权边界、无障碍要求、团队语言、构建时限、包管理器及许可证策略。硬约束用 MUST，偏好用 PREFER，未知项用 UNKNOWN。不能把未知项悄悄按满足计分，也不要用几十个权重小数制造虚假的精确度。

例如产品必须静态托管，却选择依赖常驻服务器的默认模板；或必须在企业代理后离线安装，模板启动时却从外部 CDN 拉字体，这类候选应直接阻断。Next.js、Vite 等官方安装文档说明的是各自支持的项目入口，不代表任一入口自动适合你的部署合同。需要先阅读仓库实际版本的文档和弃用提示，不能让模型凭历史记忆猜 API。

候选集合保持小而有差异：现有仓库约定、一个主流候选和必要时一个低复杂度基线通常已经足够说明问题。每个候选固定版本、创建命令、选项、运行时和 lockfile。禁止一个用精简模板、另一个用全功能商业模板再比较构建大小。

用同一个垂直样例揭示真实成本

为所有候选实现同一条窄但完整的用户路径，例如“未登录用户打开列表，登录后提交一条记录，服务返回字段错误时保留输入并允许重试”。样例必须覆盖路由、数据读取、一次写入、加载/空/失败状态、权限检查、测试和目标部署构建。只比较静态首页，会完全漏掉框架的状态和边界成本。

每次实现从干净检出开始，使用同一 API 契约和合成数据，记录命令、人工改动、生成文件、构建输出及未解决问题。Agent 失败或需要反复提示也是证据，不能只保留最好的一次对话。通过编程 Agent 的仓库地图标出框架生成的入口、环境变量、服务器边界和产物目录，再比较它们是否符合目标结构。

检查结果时不要只看代码行数。关键问题是：业务规则能否放在框架外测试；客户端与服务端边界是否可辨认；错误、取消和重试是否可表达；默认缓存是否会改变正确性；构建产物能否在目标环境复现；不需要的能力能否完整删除。对公共接口还要跑Agent API 契约兼容门，避免某个候选只是把类型错误推迟到运行时。

把模板当第三方代码审查

Starter template 不是空白纸。它可能携带依赖、安装脚本、GitHub Actions、部署配置、分析 SDK、示例密钥名、数据库迁移和默认管理员。逐项检查 package.json、lockfile、脚本、环境样例、许可证、远程请求、容器与 CI；未使用的集成应删除并重新验证，而不是留着“以后可能用”。npm 的 package.json 文档定义了脚本、包入口和依赖等实际语义，不能凭目录名推测。

依赖树必须由固定包管理器干净安装。依赖升级与锁文件兼容门同样适用于模板首次引入：解释传递依赖、peer 条件和安装脚本，不删除 lockfile 重新求解来消除警告。若模板包含生成文件，按生成代码所有权边界找到 schema、模板和再生成命令；找不到来源的产物视为不可维护，而不是免费功能。

还要检查默认安全姿态：服务端密钥是否可能打进客户端包，示例认证是否只做 UI 隐藏，CORS 与 cookie 是否采用宽松演示值，错误页是否回显栈信息。不要因为这些都“可修改”就忽略；修改成本和遗漏风险正是选型证据的一部分。

维护证据也要落到所选版本，而不是比较 GitHub 星数。检查官方支持矩阵、版本与弃用政策、安全公告入口、迁移指南、发布制品和文档是否能对应同一代代码；用一个已知弃用 API验证编译或 lint 是否能给出可操作提示。社区活跃度可以作为风险线索，但不能证明未来支持。若候选依赖单一无人接管的模板 fork，应明确由团队承担升级、漏洞响应和兼容测试，而不是把模板原作者当作隐形 owner。

同时记录“采用后第一年”会反复发生的动作：新增路由、调整环境配置、升级依赖、排查生产错误和删除功能。垂直样例若只证明创建项目快，却不能证明这些维护动作可控，选型仍未完成。

记录决定，也演练退出

决策记录应包括约束版本、候选精确版本、垂直样例提交、通过/阻断项、已知未知、接受的代价和复审触发条件。不要写“生态最好”这类无法复算的结论；写清“目标托管环境可由固定命令生成制品”“业务规则在无框架 runner 中通过”“候选 B 需要常驻服务，与 MUST 冲突”。

在正式采用前做一次最小退出演练：把一个业务用例从框架页面移到普通模块，替换一个基础组件，升级一个补丁版本，并从干净环境重建。若数据访问、验证和授权只能存在于框架钩子里，迁移代价已经显现，应在架构上先增加 adapter，而不是等产品扩大后处理。

选定后只合并获胜候选，删除其他试验目录、部署和密钥。首个产品提交继续经过编程 Agent 的改动验证门，并把选型样例转为真实回归测试或明确归档。好的框架不会替团队做架构决定，但会让关键边界可见、可测，并允许未来在证据变化时离开。