设计师的AI编程初探：从Gemini到Claude Code的协作思考与实践

刚接触 Gemini 的时候，着实为“自然语言”编程的能力感到惊讶，甚至每晚都带着兴奋熬夜体验。但随着使用深入，我发现 Gemini 更像一个精巧的玩具——它反应迅速，界面友好，但生成的代码结构往往只是堆砌，更像是为快速满足普通用户的需求而设计。

后来，经朋友介绍，我开始使用 Claude Code。体验了一段时间后，对于如何与AI协作进行“编程”，我有了一些新的感想。

于人：调整心态与协作模式

• 概念设计与工程设计分工：在构思阶段，我会让 Gemini 扮演产品策划或创意总监的角色，请它提供一些宏大的概念和方向。对于AI给出的宽泛想法，我自己再补充具体的细节。而在真正开始搭建项目框架时，我会转向 Claude Code，让它来负责工程结构的设计。这时要切记“抓大放小”，专注于整体架构的健壮性，而不要过早陷入局部UI或交互的细节里，那些可以等基础稳固后再慢慢优化。

• 警惕“平庸”与“急躁”：必须清醒认识到，AI直接生成的内容往往是“平均水准”的，缺乏真正的创新火花。若想做出有突破的设计，思想上的创新与融合必须由人来主导。同时，长期使用AI容易让人变得“急躁”——那种“所说即所得”的即时反馈，会不自觉提升我们对问题解决速度的预期。当遇到一个棘手难题迟迟无法突破时，反而要提醒自己沉住气。经验告诉我，每一次卡壳，背后暴露的往往是底层设计的大问题。保持乐观，急事缓办。

• 主动学习与“理科化”思维：当一个小问题反复无法解决时，不要只是让AI直接给出答案。应该引导它从底层逻辑和顶层规则进行分析。在这个过程中，仔细观察AI的推理路径，学习它解决问题的思维方式。设计师要学会与AI协作提问，而不是单向下达指令。在向AI描述问题现象时，应尝试运用工程思维，将问题“理科化”：善于通过打日志来定位问题，用正确和错误的数值对比进行交流，让讨论更加精确。

于 Agent：建立规范化的工作流

在使用AI工具前，必须进行必要的规划和思考，而不是直接把模糊的想法扔进提示词。

• 善用模式切换：以 Claude Code 为例，要熟练掌握其 Shift + Tab 模式切换功能：

  • 自动模式 (⏵⏵ accept edits on)：在修改文件或运行命令时不再询问，直接执行。适用于已确认无误的重复性操作。
  • 计划模式 (⏸ plan mode on)：仅用于分析代码、制定方案，不会实际编写代码或运行任何命令。适合在动手前理清思路。
  • 普通模式：默认的交互模式，每一步操作都需要确认。

• 文档驱动，持续维护：每次开始一项工作前，仔细建立并阅读相关的 .md 文档。文档内容应简短精炼，专注于该项目特有的信息（通用认知无需赘述），并解释清楚专项需求的来龙去脉。文档需要持续更新，及时补充那些重复出现、需要纠正的规则。每次完成任务后，也要整理文档，删除过时或无意义的内容，只保留高价值信息。

• 建立任务闭环：每完成一个独立的专项任务，就将过程中的关键日志和（特别是重复出现的）纠正性规则更新至 .md 文档中。同时，为下一个任务预先建立 .md 规划手册（你可以给AI这样的提示词：“请精炼这份报告，创建一个便于AI理解和工作的专项指导手册。”）。之后，通过 /clear 命令清空对话上下文，在一个“干净”的环境中让AI阅读这份执行手册，再开始新任务。

• 关注性能与代码健康：要有阶段性总结和维护的意识。除了实现功能，还要关注性能和兼容性适配。同时，保持代码整洁，定期排查和清理旧数据、脏数据以及硬编码。

总结

当工程规模增长、功能变得复杂时，最令人沮丧的感受莫过于：某些问题似乎永远修不好，或者修复一个Bug会引发更多的小问题。

在借助AI工具解决问题的过程中，我确实趟了不少坑，走了不少弯路，但也学到了很多。我将这些过程中的思考记录下来，既是为了自己回顾，也希望对未来进一步的提炼总结有所帮助。

我并不精通编程，文中的观点与做法必有不足与偏颇之处，权当抛砖引玉，期待在云栈社区与大家有更多交流。如果这些来自设计师视角的、关于AI编程协作的粗浅思考，能恰好对你有所启发，那将是我莫大的荣幸。