有了 AI 之后发觉自己的写作技能都退化了. 难得有想法, 于是自己动手写下来. 想到什么写什么, 和最佳实践肯定差得远. 可能有些遗漏和错误, 请各位指正. AI 最适合的场景是可以快速验证正确性或者正确性的优先级不高的小规模编码. 例如快速原型, 一次性的小工具, 严格约束的子模块等场景. 对我来说 AI 最大的意义是拯救了我的之前很多的个人烂尾项目. 这些项目都是由于之前某些灵机一动的点子在 Github 上新建仓库, 但后来又因为时间问题或者拖延症犯了搁置下来的. 有了 AI 协助之后可以快速将自己的灵感落地成可运行的程序, 这种"低阻力"加上接近即时反馈的感觉特别棒. 又因为买了 Google AI Pro 的订阅, 每次 quota 额度没用完就感觉亏了哈哈. 但 AI 只是降低了启动的成本, 类比一下就是 AI 只是开了空调, 让你冬天起床出被窝的时候不冷, 不赖床的决心还是要自己下的. AI 非常适合用于某个领域的入门级别的辅助学习, 以及对一些中小型开源项目或是大型开源项目子系统的导读和协助理解. AI 可以很容易地生成教程, 提供实时问答服务, 或是对已有教程和代码提供解释. 现在主流 AI 模型用来协助世界名校开源 CS 课程学习绰绰有余(本科阶段的课程肯定够用了), 很多使用祖传凑数教材的过时课程和混子老师可以被完全替代. 同时, 利用 AI 模型对于多语言输入的良好支持, 英语也不再是学习的阻碍. Google Live 和 OpenAI 的实时语音功能还可以拿来练习某些专业领域的口语交流(例如面试和日常工作场景), 这种涉及大量英文术语和特定专业知识的交流是普通英语老师完全无法提供的教学内容. 总结一下就是 AI 可以极大缓解接触新领域和新项目时的畏难情绪, 也就是 1 中说的降低 "启动成本". 用户可以没有心理包袱地挑战之前不敢深入的大型项目或是实现复杂的需求原型 (例如做一个类似 VSCode 中的 LSP 系统或是 DSL, 探索新版本 cpython 的某个子模块的内部实现等). AI 在开发过程中可以减少一些编码部分的工作量, 但是编写开发文档和代码 review 部分的工作量不减反增. 甚至因为要跟上 AI 的思路以及全局上下文同步和增加对 AI 的约束, 这两部分的工作量还增加了非常多. 之前的自己写代码 + AI 补全的方式, 用户会实时更新自己的思路, 实际上也就完成了大部分 review 工作. 而现在编写开发文档 + Agent 生成这种方式, 用户对代码的掌控感会大幅降低, 需要在 review 过程投入大量时间和精力.因此 review 过程需要减少惰性(比如避免对于某段代码第一眼看不懂就直接问 AI 的情况), 给自己留一些思考的时间, 增强对 AI 生成内容的掌控. 不然随着开发进度推进, 对项目的黑盒感会极大增加. 使用 AI 并不意味着过程中可以放松, 在计划稍大的项目(超过一万行代码)时, 用户的思路必须比手动编码时更加清晰. 如果长期在一知半解的状态下 review AI 生成的代码, 并依赖 AI 进行 debug 修改, 项目结构很有可能越改越烂. 当项目增长至 AI 无法自己 debug 解决问题时, 人工 debug 的过程就会很痛苦, 等同于还技术债. 为了尽可能避免这种情况, 除了每次认真 review 之外, 完善的日志系统和基于此的 profiler 是很有必要的. AI 配置文件至关重要, 需要良好的组织和管理 例如 ~/.gemini/ GEMINI.md 和 ~/.claude 这种 Global Rules 刚上手时我习惯在单个 Rules 文件里写 AI 需要遵守的规则, 但是单个文件中的规则到了五六百行时 AI 对规则的遵守程度就会明显下降. 因此需要将它拆成几个不同的 rules 文件, 方便 AI 索引, 减少单次执行时上下文的消耗, 增加 AI 生成内容的准确性. 具体做法就是 GEMINI.md 中写一些全局指令和其他 Protocol 文件的路径作为索引. 特定的 Protocol 保存特定领域的规则, 例如 Git Protocol 专门写生成 git commit message 的格式指令, Testing Protocol 专门写测试过程中要遵守的指令等. 不过即便是这样, Gemini 3 pro 的模型对于规则文件的遵守程度也显著差于 Claude (Sonnet 4.5 和 Opus 4.5). 也就是说 Claude 对于 ~/.gemini/ GEMINI.md 的支持比 Gemini 更好. 我从许多 Antigravity 的评论区都找到了"Gemini 对规则遵守能力较差"的观点. 我明确写了 "没有用户明确指令, 不要自行执行后续修改", 结果 Gemini 有时还是会自作主张, 在当前修改的人工 review 阶段自动开始下一个阶段的代码修改. 完成一个子任务后的工作 AI 生成代码之后, 多问一句 "现在的实现和官方推荐做法相比如何? 业界最佳实践是什么?" 往往可以得到更好的结果. 完成一个子任务后, 让 AI 生成一份总结上下文的交接文档, 然后新开一个窗口读取它(压缩上下文执行新的任务), 避免过长的上下文造成精度下降. 观察 AI 生成代码或 Debug 时的 Thinking 过程可以更好地了解 AI 当前的工作状况和思路. (也可以意外发现某些有趣的思考过程) 例如让他写 commit message, 需要完整统计本次的所有修改. 从 thinking 过程中可以知道它有时候会"偷懒", 不运行 git status -u 而是只靠以往的上下文来统计, 因此经常遗漏修改. 这时候就要在 AI protocol 里增加这条约束. Agent 生成代码的能力和执行操作的能力是不同的. 以 Antigravity 为例, Claude 模型在规则文件还不完善时执行命令行操作有时报错, 查看 thinking 过程可以发现它会把 linux 命令语法放到 windows cmd/powershell 中使用, 需要在 rules 文件中提醒它. Gemini 在这一点上做的更好. 需要把握 AI 的能力边界, 知道 AI 擅长做什么, 不擅长做什么. AI 受限于当前的上下文长度限制, 对于大项目是不可能有全面的了解的. 因此 AI 最适合用于编写有明确接口和约束条件的子系统. 但即使规则清晰且做好了上下文同步, 在项目规模增加后, 多个子系统的编码思路和风格依然有差异. 正因如此, 使用 AI 协助编写完一个上万行代码的项目, 我回头再看的时候总会有想重写一遍的冲动. (虽然很多模型号称有上百万的 Context Window, 但规模一上来, 生成的代码质量以及回答的速度会有明显下滑, 无法时刻都顾及全局的设计和思路.) 对于 AI 编写的模块代码或者引入的不熟悉的库, 最好设计成插件式尽可能解耦. 万一出了问题方便替换. AI 模型的训练时间往往落后半年到一年, 因此不能保证信息是最新的. 完全由 AI 推荐库(哪怕你要求它去网上搜索最新资料, 给出对比列表和推荐理由)可能会忽略某些最近才发现的坑(比如 xx 库对异步和多线程的支持有缺陷, xx 库有了更完善的替代方案), 这时候想要迁移到其他库就考验模块设计时的耦合度了. AI quota 的消耗速度最快的时候主要是 debug 过程, 测试过程以及时常出现的 Agent terminated due to error(使用 Antigravity). 这种 error 很坑, 明明没收到回答但是 quota 是实打实的扣掉了. 多来几次 quota 就完全耗光, 但项目一点没进展. 用付费的 Google AI Pro 账号和学生账号都试过测试过, 不太可能是 VPN 连接节点问题, 因为 Gemini 3 pro 极少出现这种问题, 而 Claude 的模型出现次数非常频繁, 几乎不可用. AI 正常生成代码时的 token 消耗速度其实比想象的低很多, 因为每次生成之后都需要人工每行 review 一遍(除了 CSS 代码)才敢放心 commit. AI 执行任务时也需要人工监督 AI 在执行生成代码或者测试/debug 时, 有时候会陷入死循环. 这时需要手动结束任务并告诉他一些额外信息, 或者问他"为什么任务执行了这么久? 死循环的原因是什么?". 我遇见的 AI 死循环有两种, 第一种是无限输出相同的无意义信息, 比如持续输出 "Go.". 第二种就是 debug 过程中反复执行同样的失败测试流程(例如执行前后端 E2E 测试时, 明明前端测试服务器没开, 还在持续执行相同的失败测试流程). 这时候如果不手动结束任务就是白烧 token 了. AI 执行指令的策略 我设置的是一些只读命令允许自动执行, 例如 git status, dir, ls 之类的. 其他涉及修改的指令都要人工允许. 关于 AI "降智" 首先可以确定的是, 单次对话窗口内容过长肯定会导致输出内容质量下降, 需要手动压缩上下文转移到新窗口中. 执行任务的时间点问题, 理论上说应该避开北美 PST 时间的使用高峰时段. 以 UTC+8 (北京时间)来看, 个人体感是下午和晚间时段出现 "Agent terminated due to error" 以及输出缓慢/降智的情况会增加. UTC+8 晚间时段,北美应该在凌晨, 我用的是加州节点, 这时候也频繁出现高负载的类似表现, 难道是亚洲地区高峰? 以 Gemini 3 pro 模型为例, 从下午三四点开始就会少量地出现"Agent terminated due to error"错误, 然后到晚上 10 点之后恢复正常. Antigravity 中的 Claude 系列模型则是任何时候都有可能高频出现 "Agent terminated due to error", 且上下文长度限制比 Gemini 要严格得多. 我一个人的统计样本太小, 仅作不严谨参考. 至于模型是否降级, 单从用户端也不太好测试, 无法确认是单纯模型输出不准还是服务端降级. 明明使用的一直是 Gemini 3 pro, 但输出内容中显示的模型信息五花八门, 有 Gemini 1.5, 还有 Gemini 2 pro exp 等等. 以收费的 Google AI Pro 的订阅为例, 在没有触发周限额的状态下, Gemini 3 Flash 在某些场合的输出质量反而比 Gemini 3 pro 更好(例如按要求生成符合规则的 commit message), 我就搞不懂其中的差异了. 最近 Antigravity 也是问题频频, quota 策略还频繁调整, 导致这些测试失去了意义, 等稳定下来再进一步测试吧.