AI 编程经验分享

我的工作经验主要集中在后端，对前端等了解有限。借助 AI 我可以开发出还不错的前端。看了一个 Next.js 框架的视频，对前端的目录结构、App Router、服务端渲染有了大概的了解，然后使用 Next.js 和 shadcn 能很快实现一个功能、美观程度都还说得过去的 Web 页面。

然后是产品原型，即使像我一样，没有产品原型设计的开发，利用 Lovable、Google AI Studio 等可以很方便迅速地做出美观，甚至可交互的产品原型图了。不过我个人还是习惯在 Cursor 中直接生成 HTML 代码画产品原型图、这样简洁高效，可控性还不错，AI 基本能按照你的想法通过 HTML 画出原型，可以通过和 AI 对话精确调整原型。

我了解 Spec Coding 是从亚马逊的 Kiro 产品，简单来说 Spec Coding 是在写代码前，先和 AI 一起完善需求文档、设计文档和任务文档。需求文档就是描述到底要实现什么功能，也就是最终的目标和要求。设计文档，会更偏重于怎么去实现这些需求，比如技术方案、架构设计之类的。而任务文档就是把这些设计拆分成具体的任务。

我个人实践下来，没有严格按照它的流程，完成这 3 个文档。不过，它的本质就是在写代码之前，和 AI 充分地沟通。因为人的语言往往是模糊不清楚的，它不像代码确定性很强。我们的想法通过语言、再经过 AI 翻译成代码，这中间损失的信息很大，往往偏离我们的想法。

在写代码之前，我一般是和 AI 充分讨论要完成的功能，我用语言尽可能清晰地描述这个功能，最后让 AI 写一份需求文档，这个文档包含功能描述和技术方案，然后我和 AI 调整完善这个文档，我认为这一份文档就足够了。写这份文档有几点好处，一个是我们的想法往往不太完整，在和 AI 一起完善这个文档的过程中，可以补充一开始没想到的点，让功能更完善。另一个是用这个文档指导 AI 写代码，代码不会和实际想法偏离很远。还有就是如果多人协作开发的话，可以让同事通过此文档了解功能，也就是 “code is cheap, show me your talk!”。

当然，如果修一些简单的 bug，就没必要先写这个文档了，往往简单描述一下 bug，贴一下日志，AI 就能迅速修好。

在用这个文档让 AI 写代码的时候，如果是 demo 项目，让 AI 一次性生成几百、上千行代码，然后简单验证一下，功能正常，就可以提交了。

但是对于严肃开发场景，此时就不能再做甩手掌柜，而是需要人来 review 代码兜底。可以告诉 AI 循序渐进开发，一次完成的代码不要太多，一两百行就足够了，方便人来 review。不过，我觉得现在也不要逐行看代码去人肉 debug，能做到对代码功能有大致了解即可。后面我分享一下提高 AI 代码验证效率的经验。

很多时候 AI 生成的代码并不能完全使用，甚至还会影响之前正常的功能。我觉得可以通过整理代码目录，分模块地组织代码来避免这个问题。比如对于后端代码目录，按照 controllers、services、core、models、clients 等目录组织代码。AI 上下文窗口有限，在提供上下文时，可以只提供给 AI 对应模块最少必要的上下文，AI 生成的代码也只限于某个功能模块内。之前看到某种说法是，把代码看成一棵树，让 AI 去完成叶子节点的功能。

AI 生成代码的效率极高，但是人 review 代码的效率是很低的，如果依靠人逐行 review 代码，这肯定会成为开发流程的瓶颈。可以借助单元测试和接口测试来提高代码验证的效率。在 AI 生成功能代码后，继续让 AI 编写功能的单元测试和接口测试代码，人来 review 测试代码，确保自己能想到的测试用例已覆盖，然后运行测试脚本，验证代码的功能。如果某个用例报错，可以直接交给 AI，让 AI 修复这部分功能。

在 AI 编程时代，自动化测试变得越来越重要，靠此才能匹配 AI 生成代码的效率。坚持写测试脚本，不仅可以验证新功能是否正常，还可以确保 AI 生成的代码没有影响已有功能，不断积累测试能力，避免靠人工重复测试。

代码 lint 检查，也可以验证代码的正确性。它可以检查代码的语法错误、格式规范等，比如少了引号、定义了未使用的变量、导入了未使用的包等。很多 lint 工具能够自动修复问题，自动格式化代码，让代码变得整洁，让强迫症看了赏心悦目。

之前看到过这样一句话，“代码主要是写给人看的，只是顺便可以在机器上运行”。我觉得现在可以改成，“代码主要是写给 AI 和人看的，只是顺便可以在机器上运行”。通过 lint 检查的代码，对 AI 和人阅读更加友好，至少看起来不像一坨屎山了，有了看下去的勇气。

还有一个技巧是，可以通过 git pre-commit 功能，在提交代码之前，自动执行 ruff、eslint 命令，自动检查和修复代码，提高效率。

通过 CI/CD 也可以加速代码的验证，在 GitHub 中可以通过 .github/workflows/xx.yaml 文件配置 CI/CD。我一般会配置几个常用的工作流：测试工作流、lint 工作流、镜像构建工作流、自动部署工作流。

测试工作流，自动执行测试脚本、确保提交的代码功能正常。

lint 工作流，自动检查代码语法错误、格式规范等，确保代码风格统一。

镜像构建工作流，自动执行安装依赖、代码编译、构建镜像的逻辑，至少确保代码能够编译通过，比如对于前端项目，保证 npm run build 是正常的。

自动部署工作流，代码合并到主分支后，自动在测试环境更新最新的服务镜像，快速验证新的功能。

这几个工作流，适合在团队协作开发时使用，每个人都使用 AI 生成大量代码，代码质量无法保证，靠这些自动执行的工作流，在一定程度上，可以对代码质量兜底，也能提升代码检测的效率。

CodeRabbit 也是很多人推荐的代码自动 review 工具，它可以很方便地集成到 GitHub，自动 review PR 的代码，给出代码改进意见，并且提供了修复代码的提示词，可以直接复制到 Cursor，让 AI 改进代码。实际用下来发现 CodeRabbit 容易吹毛求疵，不过也检测出来了内存泄漏等比较严重的问题。另外，我观察到很多公司都在做 code review 工具，像 GitHub Copilot、Cursor BugBot、Claude Code Action。AI 逐渐从写代码，向整个 DevOps 流程延伸。

最后再分享一个 Claude Code 实现自动提交代码的方法，可以创建一个 “commit” 的自定义命令，在命令中描述清楚分支规范、commit log 规范等，让 Claude Code 阅读变动的代码，自动创建分支、提交代码、创建 PR。另外如果配置了 pre-commit，比如提交前执行 lint 检查，Claude Code 在看到没有自动修复的 lint 错误后，还能够自动修复错误，整个过程十分丝滑。