我基本放弃了 Cursor，将全部 AI 代码工作流转移到 Cloud Code。
Cursor 最近才上线 Plan Mode，CodeX 此前缺乏多轮审阅功能，而 Cloud Code 的 Plan Mode 和审阅功能最符合自己的开发工作流。
vib coding 是一种宣传话术，并不意味着不需要学习编程。
不同人对 vib coding 的定义不同，完全不懂编程的人一句话生成应用与懂编程的人设计架构让 AI 执行，产出质量完全不同。
即使项目 99% 的代码由 AI 生成，只要人工提供了架构、数据库 model 等设计，就不算 vib coding。
博主自己提供了完整的架构、函数方式等设计，AI 只是执行编码，因此他不认为自己在做 vib coding。
使用 Cloud Code 最核心的理念是提升效率，不需要刻意追求最强关键词、最新 MCP 或最强工作流。
新技术不一定稳定，最强工作流不一定适合每个人，把基础功能用好就能满足需求，不应因此感到焦虑。
Cloud Code 最核心的功能是 Plan Mode（Shift Tab），其最大价值在于帮你想清楚问题，而不是替你写代码。
Plan Mode 让你明确自己在做什么，相比其他 AI 辅助编程工具做得更清晰、更好用。
新功能开发时，应先与 AI 明确需求、审阅计划，不要直接让它写代码。
直接让 AI 写代码会跳过了技术选型和实现细节的讨论，人工审阅可以避免不懂的地方被忽略，减少后期错误。
在审阅完 AI 的计划后，应要求它将计划写入 markdown 文档，防止上下文压缩导致细节丢失，并便于分阶段实施。
上下文压缩会丢失之前讨论的细节，文档可作为备份；AI 倾向于给出较复杂的计划，写入文档后可只选择实现第一阶段，避免过度开发。
AI 在编码时可能忽略已有实现而重新创建函数或变量，导致代码冗余，需要人工逐行审阅修改。
AI 无法完全读取整个 codebase，容易忽略已有逻辑而产生重复，若不进行人工检查，项目会很快变得难以维护。
debug 时应让 AI 先思考如何添加 console log 以定位问题，而不是直接修改代码。
AI 可能基于错误猜测直接修 bug 而不回滚错误修改，产生新问题；先通过日志分析数据流向，人工确认方案后再修改，更安全。
debug 和新功能开发应分别在不同的上下文会话中进行，避免因上下文压缩丢失关键信息。
上下文压缩会导致之前添加的 debug log 位置等细节丢失，或使新功能实现的完整性受影响，适时清理上下文很重要。
不要完全信赖 AI，永远要相信自己的判断，主动寻找 AI 的错误。
如果对代码熟悉，人的逻辑推理能力应强于 AI，发现 AI 输出与预期不符时应立即停止并质问，或直接指出可能的 bug 位置。
使用 MCP 实现 debug 自动化并非必需，不需要刻意追求。
MCP 截图精度可能不够，多模态模型能力未必有人眼或人工描述强；有用户系统时处理授权也需不小工作量，找到最快速解决 bug 的方法即可。
Cloud Code 的 Sonos 4.5 模型基本无限量使用且完全够用，Opus 4.1 则很快耗尽。
根据博主的实际使用体验，一周的 Opus 4.1 额度一天就用完，而 Sonos 4.5 几乎没有上限，且生成的代码质量足够。
判断 AI 项目是否安全的两条原则：Plan Mode 使用时间占开发总时间的 70% 以上，并且你 100% 懂自己的项目架构。
如果满足这两点，即使项目 100% 由 AI 编写也没有问题，因为思考和架构控制权仍掌握在开发者手中。