引言
在软件工程中，维护历史悠久的大型前端项目往往比从零开发更具挑战性。面对沉重的代码历史包袱和复杂的逻辑耦合，即便是简单的 UI 微调也可能消耗大量时间在“定位代码”和“理解上下文”上。
近期，我们在实际项目中尝试引入了一套新的 AI 辅助工作流——结合 OpenSpec 规范与 Claude Opus 等大模型能力，对一个维护难度较高的老项目进行了微调实践。本文将从效能数据、流程体验及遇到的边界问题三个维度，分享这次实践的复盘与思考。
技术栈与工作流
本次实践采用了“Vibe Coding”式的开发模式，核心技术栈包括：
- 流程规范工具：OpenSpec 1.0.2
- AI 辅助核心：Visual Studio Code Copilot + Claude Opus 4.5
- 资产流转链：通过
proposal.mddesign.mdspec.mdtasks.md的文档链条，将模糊的截图需求转化为结构化的工程任务。
效能实测：40分钟的效率跃升
在这次针对老旧代码库的页面微调任务中，我们记录了详细的时间与资源消耗数据：
- 工具自动化执行：约 10 分钟
- 效果验证：约 20 分钟
- 人工手动修正：仅需 2 分钟
- 模型消耗：少量的高级模型请求（约 27 次 Copilot Premium requests）
核心收益：与传统开发流程（寻找对应页面代码 阅读理解晦涩的历史逻辑 手动修改实现）相比，这套 AI 工作流预估节省了约 40 分钟的开发时间。对于一个历史包袱重、代码维护难度大的项目而言，这种从“理解代码”到“生成代码”的自动化跨越，极大地释放了生产力。
深度洞察：自动化的边界与开发者的角色
尽管效率提升显著，但在从 Proposal 到最终交付的过程中，我们也发现了一些 AI 工具链在当前阶段的局限性，值得开发者警惕：
1. 前端实现的“顺滑”与后端约束的“隐形”
针对纯前端的文案变动或样式调整（如按钮位置、静态提示语），AI 的完成度非常高，基本能做到“一键生成”。
然而，当需求涉及到由后端接口动态配置的数据（例如某些菜单项的名称是由 API 下发的）时，AI 工具的感知能力会下降。
- 问题现象：在设计阶段（Design），AI 可能会隐晦地提到“不修改 API 接口”，但未能明确识别出“目标文案因受限于接口而无法在前端直接修改”这一冲突。
- 结果：生成的代码在样式上是完美的，但部分涉及后端配置的文案未能生效。这就解释了为什么仍需要“20分钟的效果验证”——开发者需要介入处理这些 AI 漏掉的架构约束。
2. OpenSpec 的“被动通知”机制
OpenSpec 在处理此类冲突时，不会像编译器报错那样主动弹窗警告。它更多地依赖于生成的文档资产（Spec/Design docs）。如果开发者不详细阅读生成的文档，很容易忽略这些被隐藏的实现细节。
总结
本次实践证明，在对现有老旧项目进行微调的场景下，使用 OpenSpec 结合大模型的开发模式具有极大的提升意义。它成功将开发者从繁琐的代码定位和基础修改中解放出来。
但同时，这也对开发者提出了新的要求：从“代码编写者”转变为“逻辑审核者”。在使用 AI 工具时，我们不能完全依赖其自动化输出，特别是在涉及前后端数据交互、接口配置等隐性约束时，开发者仍需保持敏锐的技术嗅觉，做好最后一道把关。
