我平时AI工具用得比较多，基本上已经融入日常开发流程了，差不多占比在60%。像需求分析、技术方案、代码生成、问题排查、单元测试、接口测试、代码Review、文档总结这些，我都会用AI辅助。

只要用得好，AI基本上能覆盖日常开发中的大部分工作：

• 需求拆解
• 技术方案草稿
• 接口设计
• 表结构初稿
• Java业务代码
• SQL编写和优化建议
• 单元测试
• 接口测试用例
• Bug排查
• 日志分析
• 代码Review
• 文档编写
• 周报总结
• 面试准备
• 技术学习

工具上，我主要会用 codex、Claude 这类通用AI，也会用 Cursor这类IDE编码助手。中文需求、业务文档、面试准备这类内容，我也会用通义千问、Kimi、这些工具。不同工具侧重点不一样，通用大模型适合分析和讨论，IDE AI适合结合代码上下文写代码，中文AI适合处理中文材料。

我这个人比较爱捣鼓，哪个工具好用，哪些模型好用，我都会去尝试，去探索比较。包括github新出的一些规范的东西，一些skills啊，我都会去尝试使用。

再使用AI开发的时候，但我不是简单地问一句“帮我实现某个功能”，然后让AI自己去实现并复制代码完事。

我在使用AI会有一套比较固定的规范：

第一，我会先用 Plan 模式。也就是在真正写代码之前，先让AI帮我拆需求、列步骤、找边界条件、识别风险点。比如一个订单支付接口，我会先确认状态流转、幂等、库存、事务、异常回滚、重复请求这些问题，而不是一上来就写代码。这样可以避免代码写完才发现方向错了。

第二，如果需求比较复杂，我会用类似 OpenSpec 的方式先写清楚规格。简单说，就是先把“要做什么、不做什么、输入输出是什么、异常情况怎么处理、验收标准是什么”写明白。这样AI生成代码时不会跑偏，后面测试也有依据。比如新增一个功能，我会先整理接口字段、业务规则、兼容逻辑、错误码、测试场景，再让AI基于这个规格去实现。

第三，我会用 Skills 这种方式沉淀固定能力。比如我们项目里如果有固定的代码风格、日志规范、异常处理规范、分页返回格式、单元测试写法，我会把这些整理成规则，后面每次让AI写代码时都带上。这样AI不是每次从零理解，而是按项目规范来生成，代码更统一。

第四，我会关注 Harness Engineering。这个可以理解成给AI搭好工作环境和验证环境，不只是写提示词。比如让AI能看到相关代码、调用方、实体类、Mapper、测试用例；改完代码后要能跑单元测试、接口测试、静态检查；失败了要把错误日志反馈给AI继续修。也就是说，不是让AI凭空猜，而是让它在真实工程环境里迭代。

第五，我会用一些 Superpowers 类型的工作流能力。我的理解是，把一些高频动作固定成标准流程，比如“先读代码再写代码”“改完必须Review”“复杂任务先Plan”“写完补测试”“失败必须暴露原因”。这些能力不是某个具体工具的魔法，而是把AI用法流程化，让它更像一个受约束的工程助手。

具体到开发流程，我一般是这样用的：拿到需求后，先让AI帮我拆业务，梳理流程和风险点；确认方案后，再让AI结合现有代码生成局部实现；代码写完后，让AI从空指针、事务、并发、性能、安全、业务完整性几个角度做Review；最后让AI帮我补测试场景，编写测试用例，包括正常流程、异常流程、边界值、重复请求和外部依赖异常等。总之确保AI编写的代码质量。

我觉得AI基本上能解决日常开发中的大部分问题，但前提是要会用。提示词要把角色、背景、目标、现有代码、限制条件、输出格式和验收标准说清楚；工程上要有规范、有上下文、有测试、有Review。AI生成的代码不能直接复制提交，必须自己读代码、跑测试、看日志、确认业务逻辑没问题。

所以我的理解是，AI能大幅提高开发效率，也能帮开发人员查漏补缺。用得好，它不只是一个代码补全工具，而是可以参与需求分析、方案设计、编码、测试、Review、文档的完整开发助手。但最终的技术判断、代码质量和业务结果，还是开发人员自己负责。