从最初的copilot tab键补全，到现在的cursor、claude code、codex等各种编程 Agent，基本每个我都在实际的开发任务中使用过，积累了一些个人的AI编程经验，在此记录分享一下。

　

扩展能力的边界

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

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

　

Spec Coding

我了解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自动提交代码

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