涵盖 Cursor、Claude Code、Skills

用过什么 AI 编程 IDE 吗什么感觉知道哪些 Cursor 使用技巧Skills 了解吗你的项目用到了吗你如何看待 AI 对后端开发影响你觉得 AI 会淘汰初级程序员吗AI 带来的最大风险是什么你觉得未来 3 年后端工程师的核心竞争力是什么用过什么 AI 编程 IDE 吗什么感觉我用过几款 AI 编程工具例如 Cursor、Trae、Claude Code其中我日常开发中主要用的是 Cursor根据你自己的使用去说就好我这里以国内用的比较多的 Cursor 为例。目前整体感觉是AI 编程能力进步真的太快了它现在已经不是几年前简单的代码补全工具而是一个可以深度协作的工程助手。我总结了一套自己的使用方法论在接手复杂项目或模块时我不会直接让 AI 写代码而是先让 Cursor 分析整个代码库生成一份包含核心架构、模块职责和数据流的文档。这一步非常关键因为它决定了后续协作的质量。只有当我和 AI 对项目有一致理解时后续产出才会稳定、高质量。对于每个独立的开发任务我都会开启一个新的对话并提供必要的上下文包括需求背景、涉及模块和约束条件。这种方式能显著减少上下文污染让 AI 生成的代码更加精准基本不需要大幅返工。我也会定期删除冗余实现和废弃代码。旧代码会误导 AI 的判断增加上下文噪音长期不清理会直接影响协作效率。AI 是一个强大的知识库和辅助工具可以帮我们快速实现功能、学习新知识。但如果完全依赖 AI 写代码而不理解其原理个人技术能力可能会退化。因此我会坚持几个原则AI 生成代码之后必须人工 Review。关键逻辑必要时自己重写。核心路径必须做压测和边界测试。我希望效率提升但不以牺牲技术能力为代价。知道哪些 Cursor 使用技巧这里是以 Cursor 为例其他 AI IDE 都是类似的。先理架构再动手无论是自己写代码还是让 AI 生成代码都必须先明确需求、整体架构和模块边界。如果在架构模糊的情况下直接编码很容易出现重复实现或职责冲突后期修改成本反而更高。单 Chat 专注单功能新功能或大改动开启新的 Chat并在开头引入项目结构说明或关键文档作为上下文基础。这样可以避免历史对话干扰提高输出质量。功能落地后写指南让 AI 总结实现过程抽象出通用步骤形成“操作指南”。比如新增接口的标准流程、文件导出的统一实现方式等。这些沉淀下来的内容可以在后续类似需求中快速复用。不依赖 AI主动复盘AI 仅作辅助代码生成后需认真 Review理解原理、优化不合理处避免技术停滞。定期删无用代码清理冗余代码减少对 AI 的误导和上下文干扰提升开发效率。用好配置文件.cursorrules定义 AI 生成代码的规则、风格和常用片段.cursorignore指定不允许 AI 修改的文件 / 目录保护核心代码。持续维护文档项目重大变更后让 AI 同步更新文档、记录 踩坑 经验积累团队知识库。让 AI 先 学 项目大型项目先让 Cursor 分析代码库生成含架构、目录职责、核心类等的结构文档作为后续开发的基础上下文。Skills 了解吗你的项目用到了吗Skills 可以简单理解为把“能力”做成可复用、可调用、可组合的模块。为什么要有 Skills传统用法是每次写一大段 Prompt把规则、步骤、输出格式都塞进去这样的话会存在重复、不稳定、难复用、难组合等问题。Skills 的目标是把能力沉淀下来这样可复用、可组合、可被调用、更工程化。AI 像调用函数一样调用能力比如summarize-article- 文章总结analyze-resume- 简历分析generate-interview-questions- 面试问题生成code-review- 代码审查在多人协作场景下我会利用 AI 做 Code Review 辅助。把 PR 内容交给 Cursor让它从可读性、异常处理、一致性和潜在风险角度进行分析然后再人工判断。这样可以提升 Review 的覆盖度但最终决策仍由人完成。这个场景其实非常适合通过 Skill 来固化。我会定义一个专门的 Code Review Skill明确它的职责例如从架构合理性、异常处理完整性、日志规范、边界条件覆盖、安全风险、性能隐患等多个维度进行结构化审查。这样每次 Review 不需要重复写 Prompt只需要调用 Skill就能获得稳定、标准化的分析结果。除了 Code Review我也会定义其他 Skill例如api-endpoint-generator- 按项目统一响应结构与异常模型生成标准化接口代码database-access-review- 审查数据库访问逻辑关注索引使用与慢查询风险refactor-analysis- 先评估影响范围与依赖关系再输出分步骤重构方案security-audit- 扫描 SQL 拼接、XSS、权限绕过等常见安全风险当 Skill 被定义清晰后AI 的角色就从“自由发挥”变成“按规则执行”。这不仅提升输出质量也减少了风格漂移和架构失控的风险。从团队协作角度看Skill 还可以成为一种“隐性规范载体”。新人不需要完全理解所有约定只要调用对应 Skill就能得到符合团队标准的实现建议。这在一定程度上提升了整体一致性。这里 Guide 多提一下回答这个问题的时候你也可以说自己团队用到了一些开源的软件开发 Skills 集合例如 Superpowers 中内置的。你如何看待 AI 对后端开发影响我认为 AI 不会取代后端工程师但会显著改变后端工程师的工作方式和能力结构。AI 将我们从重复的、模式化的工作中解放出来成为我们最强的帮手在编码层面AI 编程工具如 Cursor极大地提升了 CRUD、单元测试、胶水代码的编写效率。以我自己的经验常规业务接口的开发效率可提升 50%~70%尤其是样板代码和重复逻辑的生成AI 表现出色。在架构层面AI 正在催生新的应用范式比如智能体Agent驱动的自动化业务流程后端需要提供更灵活、更原子化的能力接口。传统的大而全接口正逐步拆解为可被 AI 调用的原子化能力。在运维与排障层面AI 可以辅助分析日志、监控告警甚至预测系统瓶颈让问题排查更智能。例如基于 AIOps智能运维的工具可以自动分析异常日志模式定位根因。AI 让后端工程师能更专注于业务建模、复杂系统设计和架构决策这些更具创造性的核心工作。并且AI 同样能够辅助我们更好地完成这些事情。拿我自己来说我经常会和 AI 讨论业务和技术方案它总能给我不错的启发——尤其是在需求拆解和技术选型时AI 能提供多角度的思考。你觉得 AI 会淘汰初级程序员吗短期内不会淘汰但会彻底改变初级程序员的能力结构。以前初级工程师的价值在于写 CRUD 增删改查写基础接口写 SQL 查询语句写基础工具类/配置现在这些工作 AI 都能做得很好甚至更高效、更少出错。但这并不意味着初级程序员会被淘汰——而是他们的价值创造点发生了迁移。未来初级工程师需要具备需求拆解能力将模糊的业务需求转化为清晰的技术任务。业务理解能力理解领域模型和业务规则而不仅是翻译需求。架构感知能力理解系统整体架构知道自己代码在系统中的位置。Prompt 表达能力能精准地描述问题从 AI 获取高质量答案。AI 让编程门槛变低但对理解能力的要求反而更高。未来的初级工程师更像是一个AI 协调者而非单纯的代码编写者。从企业招聘角度看纯编码能力的需求会减少但对能利用 AI 快速交付业务价值的工程师需求会增加。AI 带来的最大风险是什么我认为主要有三个层面1. 技术能力退化过度依赖 AI 会导致工程师自身技术能力的退化尤其是调试能力下降习惯让 AI 排查问题自身对底层原理的理解变浅。代码敏感度下降对好代码和坏代码的判断能力变弱甚至不知道什么是好代码。架构思维退化长期只关注功能实现忽视架构设计和扩展性。2. 架构失控AI 生成的代码往往关注当前功能可用容易忽视模块边界生成代码可能职责不清导致模块耦合严重。技术债务为快速实现功能可能引入临时方案或反模式。一致性不同 Chat 生成的代码风格和模式可能不一致。3. 安全风险尤其需要重视代码漏洞AI 可能生成包含安全漏洞的代码如 SQL 注入、XSS、权限校验缺失。数据泄露不当使用可能泄露公司代码、业务逻辑给外部模型尤其是云端托管的 AI 服务。供应链风险AI 推荐的依赖包可能存在已知漏洞或恶意代码。密钥泄露AI 生成的代码可能硬编码密钥、Token 等敏感信息。因此我认为企业使用 AI 必须建立配套的安全治理体系强制代码审查AI 生成的代码必须经过人工 Review 才能合并。自动化安全扫描集成 SAST静态分析、SCA依赖分析到 CI/CD 流程。明确数据合规边界规定哪些代码/数据不允许发给外部 AI必要时使用私有化部署。访问审计记录 AI 工具的使用日志便于事后追溯。你觉得未来 3 年后端工程师的核心竞争力是什么我认为核心竞争力的焦点会从写代码能力转向以下四个维度1. 系统设计能力AI 非常擅长生成单个功能的代码但系统级设计仍需工程师主导服务拆分与模块边界划分微服务与单体架构权衡数据模型设计与一致性策略接口版本演进策略分布式事务与幂等设计2. 复杂业务建模能力过去我们说 AI 不擅长领域建模但现在情况已经变了。AI 在需求拆解、规则梳理、场景推演等方面已经很强。