Architecting Life

最近尝试全程 AI Vibe Coding 搭建一个包含前台和后台的业务系统，高强度使用了 Cursor + Claude Code 编码一个月，消耗完 Cursor 500 次快速请求，以及可能几百刀 Claude Code 的 Token。

在这过程中，99% 以上的时间都是在通过 AI prompt 进行修改（比如修改页面上的一个文案 😃)，可能少于 10 次觉得描述需求太麻烦了而直接顺手改了代码。

在大概完成了一个可用的系统原型之后，踩了不少坑，也对 Vibe Coding 稍微有了一些体会。

PS. 我也是第一次高强度使用 AI 进行辅助编程，可能并没有一开始就遵循一些最佳实践，以及并没有充分利用 Cluade Code 的一些功能，例如 SubAgent、MCP 等，其中一些问题可能有更好的解决方式。

PPS. 这是一个基于 React + Nodejs，同时包含前后端的项目，所有相关经验都基于相关领域的实践得出。

1. 别让 Agent 重复启动调试服务器：控制调试流程

Agent 在调试时容易重复启动调试服务器或多个实例，这会带来端口冲突、环境状态混乱、资源浪费等问题。

实践建议：

• 写一个调试流程规范文档（例如 AGENTS.md 或者 CLAUDE.md），明确什么时候／谁来启动／关闭调试服务器。
• 对话中明确指令：如果已有调试服务运行，则不要再启动；如果要重启，先停止旧实例。
• 利用自动检测脚本或 CI，确认是否已有实例在运行，避免重复。

2. Git 是救命稻草：阶段性提交防止灾难

AI 改起代码来速度很快，并且可以一次修改一大片，虽然效率可以得到很大提升，但也容易带来隐藏问题。若没有及时保存历史版本，一旦出错代价大。

实践建议：

• 每当完成一个可运行阶段（如模块接口完成、核心功能可手动测试通过、样式基础搭建完成等）就提交。
• 写清变更说明，标注：“这个提交中完成了 XXX 模块的基础功能／界面／测试”等。
• 使用分支策略（feature/、bugfix/ 等）在本地／远程做实验，确认稳定再 merge。

3. 设计先行：用 AI 写产品设计＋拆里程碑

虽然现在 AI 的规划能力已经很强，但是受制于上下文长度的限制，还是需要先有整体规划，再分解任务，这样才能让协作不会偏离主要轨道。

实践建议：

• 启动项目时，用 AI 产出一份产品设计文档，包括目标、用户故事、模块、里程碑、界面原型等。
• 为每个模块定义验收标准（什么情况算完成／功能达标）。
• 拆里程碑为具体任务，并设立时间表／优先级；定期检查里程碑是否达成。

4. 模块化开发 + 阶段 Review：AI 驱动，人 Review 护航

在开始开发前，同样通过 AI 的规划能力，把一个模块的开发任务拆分成更细粒度的需求列表，在每个需求做完后人工检查，可以及时纠正偏差，避免在后期需要修改整个系统，成本会越来越高。

实践建议：

• 对每个模块定义输入／输出／边界条件／依赖，AI 完成后由人工测试／评审。
• 可以写自动化测试来验证接口或模块契约。
• 每块模块完成以后，把代码放到主分支或一个共享分支进行集成，确认与已有模块的兼容性。

5. 遇到死胡同要及时干预 + 换思路

在使用 AI 作为主力进行编程时，也需要及时关注 AI 在编码中的处理逻辑和状态，如果 AI 在某个局部实现不断失败，用同一种方式调试没有成果，甚至进入死循环，要果断制止 AI，并且换种方式进行实现。

实践建议：

• 及时观测 AI 的思考行为和路径，当尝试某种实现方式若干次失败就换方案。
• 把问题拆更细，例如先做最简单版本，再逐步扩展复杂性。
• 或许先实现 “让它能工作”的最小可行版本（MVP），再补完细节。

6. 界面 Bug 要“说得明白”：元素 + Class + 路径

开发前端界面时，在纯依赖提示词进行界面修改或者调整时，有些时候纯文本可能无法准确定位到具体的元素，这时就可能因为语义或结构定义不明确导致反复修改而达不到目标。

实践建议：

• 报告 Bug 时附带截图 + 标注元素位置，告诉 AI 这个元素在 DOM 树中路径／Class 名。
• 如果页面结构复杂，通过浏览器 Inspect 或 DevTools 查看具体 Selector，给 AI 用。
• 建立统一的 UI 样式规范或设计系统，明确 Class 命名规则，减少歧义。

7. 任务拆得小：逐步递进比一次性全做强

对于大任务，AI 看似可以一次做完，效率非常高，但迭代反馈慢，很容易导致实际功能偏离预期。

实践建议：

• 给 AI 下任务需从微小模块开始／单页面开始。
• 每完成一个小模块就 Review，再决定下一步；每个小模块都要能被测试／部署／验证。
• 在任务拆解中写出清晰子任务列表，标明顺序及依赖。

8. 分路径优化：先抽象再修样式 / 结构

改结构／样式直接动可能会破坏整个 UI 的一致性，在最坏的情况下，甚至会导致 AI 一直将页面的 React 结构改错，无法修复，这时可以抽象化先行，用小步骤优化更安全。

实践建议：

• 在 UI 或布局变动任务中，先识别公共部分／重复结构（导航栏、侧边栏、按钮样式等），将它们提成组件或共享样式。
• 确保组件接口稳定，再改样式或布局。
• 测试不同屏幕及响应式情况下组件表现，避免因样式变动破碎布局。

9. 清晰指令避免上次对话负担：重设上下文 / 说明任务完整性

AI 的上下文记忆有优也有弊，含糊或依赖隐含背景的指令容易引起误会或出错。

实践建议：

• 下任务时重述所处模块 /目标 /依赖 /已完成背景；如果有必要，提供代码片段、文件路径等。
• 若发现 AI 带入旧任务内容导致偏差，提示它“先忽略之前的任务／上下文，只关注当前任务”；或开启新对话。
• 在任务描述中列出预期行为、边界情况和验收标准。

10. 长对话重启 + 限制 token 膨胀

如果一直在一个会话中进行 Vibe Coding，对话历史太长，除了会因为上下文而耗费 token，也可能让 AI 依赖早前内容造成混淆，进而产生 Bug。

PS. 在某些情况下，Claude Code 甚至会因为上下文太大而导致 CLI 整个卡死不动。

实践建议：

• 在对话达到一定长度时，整理一次当前状态＋进展，总结关键信息，再开启一个新的会话。
• 在新会话中包含必要背景但不带冗余旧内容。
• 做好变更日志或 Review 注释，方便追踪哪些地方从旧会话延续下来。

总结

总的实践下来，AI 在编程领域已经相当可用了，对于一些特定场景的效率提升，可能真的有 10 倍以上。如果现在还有没有接触 AI Coding 的，一定要去尝试一下。

对于大型项目来说，由于上下文长度限制，AI 无法一次性理解项目全部代码，但是在单个组件上，AI 可以很好的完成需求。

个人感觉，在 AI 参与实际项目的编码过程中，架构师或者资深开发者的角色仍然是必不可少的，可以更好的去规划整个项目的架构、工程结构等内容。

并且这还是最近这一年 AI Coding 从玩具到生产可用的变化，可能在未来，AI Coding 真的能完全代替程序员进行开发了？

PS. 以上体会都是基于 Cursor + claude-4-sonnet 或 Claude Code。