虽然我经常谈论 AI 编程能力的不足，但是我使用 AI 进行编程非常的早，并且，日常使用的非常多。
在 LLM 开始引起关注的那段时间，我就开始尝试在本地运行一些模型来辅助编程。在那个时候，互联网上，只有 chatgpt 可以不太稳定的访问，基本很难找到好用的服务。
机缘巧合，我当时拿了一笔离职补偿，思考了很久，花了几万买了一个几乎是顶配的 RMBP。这给了我很大的方便，让我有机会在本机部署30甚至70b的模型。依靠 Ollama 上部署的 LLama 2和几个 uncensored 的模型，我开始尝试进入一些比较陌生的领域，例如多年不写的 CPP。
从那时起，我就没有满足仅仅找到工具来使用，而是多次尝试自己实现一些辅助工具帮助我编程。
在 AI 的帮助下，我成功的写出了可以在 PostgreSQL 上运行GPU计算的插件，对一些小规模的模型尝试做有针对性的微调，取得了还不错的结果。
在这段时间，我开始尝试用 kimi 的 API 驱动一些开发工作，Lichi 就是这个阶段开始开发的。虽然这时候我也订购了 github copilot等工具，也开始使用 cursor，但是对我来说，更主要的工作流程还是有限的使用 AI 生成代码片段，由我自己组装。
这其中有过很多让我有点哭笑不得的挫折，不过总的来说，没有 AI，很多工作是我几乎没办法做的。而且无论 AI 服务还是模型本身，都在快速的发展，用起来还是越来越顺手的。
第一个比较大的转折是随着 deepseek 的发布，长推理模式和MOE成为被广泛追捧的流行架构。这使得一些有挑战的问题可以得到解决。2025 年上半年的时候，我遇到过一个复杂的 duckdb 查询问题，简单的说，我需要找出热电厂运行数据中，持续运行的时段，将每次停机前后各两小时的数据提出，保留稳定运行的时段。在我详细介绍了问题后，deepseek进行了长达两万多字的推理，然后给了一个让我震惊的漂亮方案，灵活的使用了 asof join和 window function。我是用纯 SQL 实现过神经网络算法的重度 SQL 用户，但是 AI 给出的这个答案仍然让我深感震惊。
随着 cursor 的快速发展，我开始逐步的深入 vibe coding 模式。直到近期，我订了一年的 glm 服务，开始结合 claude code 和 cursor，尝试更深入的写作模式。
我始终还是不太能接受完全的使用 claude code 这样的工具，完全脱离具体的代码来开发。不过总的来说，我也有三种情况是自己不写程序的。
- 问题太难我不写，这种情况下，往往 ChatGPT 能给出最好的答案和讲解
- 问题太容易我不写，通常非常简单的问题，cursor的代码补全就可以给出够用的实现
- 问题不太难也不太容易的我也不写，通常通过 cursor 或者 claude code 的对话讨论，多次迭代可以解决问题。
除去这三种情况，还是有一些情况我会自己开发的，比如：
什么时候要介入 AI 的工作
关键性的架构问题
例如，我在学院中的几个项目中，都需要处理长时间的 AI 推理过程，这种架构，你放手让 AI 处理，它一定非常机智的给你塞一些奇怪的实现，比如不上锁的多线程，用同步 IO 访问 API 的协程代码。
这些东西你说一定有多大问题，也不一定，如果你写的都是些玩具，那可能永远也不会发现有什么不对。
但是我知道，正经的开发工作不应该是这个样子。实际上，cursor解决这些问题的水平，跟我十五年前差不多，这种方案是满足不了我的。
我最终给出的方案是，将长时任务放到独立的进程中运行，这样的架构有几个显著的好处。
- 开发比较平滑，开发调试阶段可以用命令行运行，不需要走完复杂的服务链路。这也有利于测试
- 足够健壮，即使开发过程中反复热重启，也不至于打断正在运行的后台任务，同样，我们安全的中断任务程序，不会影响服务。
- 这种架构可以平滑的发展为 service + serverless 的分布式架构，通过容器集群，将无状态，快速响应的服务，与需要保持长时运行，不需要频繁响应外部通信的后台任务实例。但是如果一开始后台任务就是多线程或者协程模式，那么微服务化就需要彻底的重写
用 AI 为我省出来的时间，我可以精心的梳理构造出这个多进程架构，现在它已经初具规模。
我用过 langchain 和 langgraph，作为一个 AKKA 老用户，我其实不太期待这类工具能翻出什么花，后面我会单独写一下，在拒绝了 langchain 到 dify 的一系列工具后，我自己鼓捣了个啥。
再例如，我在处理高度动态的数据模型时，有我惯用的套路，我会借用一到两个 PostgreSQL 的 JSONB 字段，管理各种动态信息。这种设计思路，可以解释给 AI ，但是让它自己从头写，它往往是想不到的。
开发风格介入
还有一个经常遇到的问题是前端调试。或许是网络上可以广泛的搜集到关于前端开发的资料，AI在前端开发中表现的非常优秀，随着 cursor 的快速发展，特别是 claude code 的加入，我已经很少手写前端了，但是仍然有一些问题需要我手工处理，例如 AI 特别喜欢使用那个臭名昭著的蓝紫色配色方案。
工具链规划
第四个常见的问题是，AI在写 Python Web项目时，沉迷直接用 SQLAlchemy 的 metadata 自动同步数据库结构。但凡正经做过一些工程开发的同行，都应该知道这种方式有多不靠谱。所以我都会明确的要求 AI 配置好 alembic。实际上，给出明确的技术指标后，AI可以把这个事情做的不错。
最后一个问题是测试，AI 总是极力推崇 pytest 而不是 Python 内置的 unittest。我倒不是说 pytest 很差，而是这个东西其实远远没有 AI 所相信的那么先进，unittest和pytest是两个长相迥异，但是功能上基本同质的两个工具，它们都有一些可以内置功能就做的很好的事情，也各自有一些要依赖第三方组件支持的情况。有什么用什么，都可以。将来我准备单独写一篇文章比较这两类测试工具。
如何让 AI 工作更好
这里我们套路 AI Web 项目一些行之有效的方法。通常，这种项目是 Python 技术栈，主要是用外部的 API 实现 AI 功能。
我会习惯采用最小依赖，例如项目管理工具和测试，我会倾向尽量使用 python 内置的工具。但是为了团队协作方便，我现在也会比较多的使用 uv 管理项目，通常 cursor 在识别 uv 项目的结构时，不一定能一次性做好，可以手工配置 .vscode/settings.json ，告诉 AI 项目结构。当然，比较让人欣喜的是，AI其实能把这些配置写好，它需要只是你告诉它，你需要它去做这些工作。
很多同行，包括一些业内顶尖的同行，会比较抵触手工 debug。 Debugger 确实有一些缺陷，但是其实很多问题用 debugger 可以更快的发现。所以我会要求 AI 帮我配好调试器。尽管这半年我也就用过那么两三次，但是它很清晰的展示了一些 AI 生成代码中隐藏的低级错误。
Claude 发展出的 MCP 和 skill ，都是非常有力的方法论。例如在前端调试中，浏览器 devtools mcp 是非常有效的，借助它可以让 cursor 和 claude 直接看到页面。但是有时候我们需要明确的提醒 AI，调用 mcp 实际查看一下页面布局。
我自己也写了几个 mcp ，功能不算复杂，但是效果还是很让人惊喜的，例如我可以在 mcp 内部埋一个带 RAG 的 agent，让它自己生成 lisp 代码来操作 emacs，甚至不需要很大的模型，我只用了一个 0.6B 的qwen 3。
从经验来开，即使在claude和cursor中使用同一个模型后端，claude也更擅长完成复杂的长程工作。但是它也经常会过度的修改我的代码，例如未经允许就乱改数据库结构。而cursor就会更保守一些，现在的cursor已经不太会做一些需要我rollback的错误修改，但是它也确实不太擅长处理过长的提示词指令。我在尝试将一些行之有效的方法定义成 skill，使它们可以扬长避短。后续有了好的经验，可以深入讨论一下 claude code 的skill。