为什么 multi-file 改动比单文件危险得多？

4 类高频翻车：(1) 重复造已有的 utility 函数；(2) 改了调用方忘改类型定义；(3) import 被 AI 顺手清错；(4) 改动半径超出原本需求。单文件错了一眼能看出，跨文件错了 reviewer 也容易漏 —— 接口、类型、import、状态流、样式、测试可能一起被带偏，回归排查成本翻 5 倍。

改动多文件之前应该先让 AI 做什么？

两步铺垫："(1) 先不要改代码，根据 src/app + src/components + src/services + src/types 这些路径，总结项目结构 —— 每个目录作用、这次任务最可能改哪些文件、哪些不该碰；(2) 列 change list —— 改哪些文件、为什么改、依赖关系、可能影响哪些现有逻辑。"这两步 5 分钟做完，能拦下 80% 的"AI 又造了一份现有 utility"。

怎么明确告诉 AI 哪些文件不准动？

在 prompt 里写显式 boundary："只允许修改 [file A, file B]；禁止修改 [file C, file D]；不能新增 dependency；不能重构 shared 逻辑。"千万别说"重构整个模块"—— 那等于发无限权限。明确范围后 AI 跑偏概率从 40% 掉到 5%。最稳的句式是把"不要碰什么"写在前面，比"只改什么"更有约束力。

Multi-file 改完后最小 validation checklist 应该跑什么？

4 项必跑：(1) typecheck —— 接口对齐没；(2) 最小 smoke test —— 改动涉及的关键页面手测一遍；(3) import / export 检查 —— 有没有循环依赖或漏 export；(4) 关键路径手测 —— 用户实际用到的核心 flow 走一遍。让 AI 帮你列这份 checklist："基于这次改动，列出最小验证清单 —— 跑哪些命令、测哪些页面、哪些边界最容易坏。"

改 API contract 时为什么要按层逐步改？

API contract 一变，type 定义、service 调用、UI 渲染三处必须同步。一次让 AI 全改完看似快，实际上 reviewer 看不出哪层先错 —— type 错还是 service 错？按层走的顺序是 type → service → UI，每层改完先 typecheck 再进下一层。Vibe Coding 在 multi-file 场景的核心原则不是"快"，而是"每步可追踪"。

多文件协作与项目级修改

⏱️ 25分钟

引用上下文、控制改动范围、保持一致性

🔒

注册解锁完整内容

免费注册，即可查看全部内容

✓完整章节内容
✓视频教程
✓代码示例
✓学习社群