AI 摘要：作者从一个“反 AI 狂热者”转变为 AI 代理的使用者，因为他发现 AI 在代码编写上的生产力惊人。他详细介绍了如何设置 AI 代理（以 Claude Code 为例），强调了配置清晰的 CLAUDE.md 文件（包括项目架构和个人编码习惯）的重要性。在整体策略上，他强调了结合自动化测试提供反馈循环，以及在复杂任务中使用“计划模式”来让 AI 进行思考。作者还分享了处理 AI 常见错误（如删除注释、代码重复）的方法，即开启新会话让 AI 进行“代码审查”。此外，他还提到 AI 代理能在夜间持续工作，实现“睡着也能完成额外工作”的优势。尽管作者对 AI 代理仍抱有复杂情感，认为它们剥夺了编程乐趣，但他承认 AI 显著提升了编码效率，将自己的角色比作软件架构师，主要负责设计和审查，而非亲手编写所有代码。

1. 对 AI 编码态度的转变
• 从“反 AI 狂热者”到接受者：作者承认尽管曾强烈反对 AI，但其同事的生产力提升以及 AI 工具（如 Claude Code、OpenAI Codex、Gemini CLI）的发布，使其无法再忽视。
• 承认 AI 的高效性：尽管作者有 20 年的编程经验和对代码质量的“老派”看法，但 AI 在许多时候比他写得更好。
• 强调正确使用 AI：将 AI 比作“锋利的菜刀与电锯的组合”，强调不当使用可能造成伤害。

2. AI 代理的基本设置
• 选择工具：作者主要使用 Claude Code，因其足够好用，虽然市面上有许多其他选择。
• CLAUDE.md 文件的作用：
• 项目级 CLAUDE.md：用于描述项目概况、整体架构、注意事项等，帮助 AI 理解代码库。
• 个人级 CLAUDE.md：记录个人编码习惯和偏好（例如：在 map() 或 filter() 函数中使用 _ 变量名）。

3. 整体使用策略
• 吸取教训：作者承认在 AI 上浪费了大量时间，AI 代理可能会“引你走弯路”，导致创建出“勉强能用”的“怪物”。
• 建立反馈循环：
• 自动化测试：通过自动化测试让 AI 代理验证其解决方案，纠正错误。
• “计划模式”（plan mode）：对于复杂任务，让 AI 在执行前先“思考”并制定计划，可以有效避免盲目尝试。
• AI 在 UI 方面的局限性：AI 在处理 UI 任务时效率较低，因为需要消耗大量 token 进行 DOM 检查或通过截屏检查，导致速度缓慢且容易出错。

4. 处理 AI 产生的错误
• AI 常见的错误类型：
• 删除有用的注释：将重要信息移除或修改。
• 代码重复：AI 代理倾向于复制粘贴代码，违反 DRY (Don't Repeat Yourself) 原则。
• 引入细微的错误：在重构时无意中改变代码原意（例如：添加多余的空值检查）。
• 解决策略：
• 重启会话进行“代码审查”：开启新的 AI 会话，让其对比 origin/main 进行纯重构检查，并查找功能性错误。
• 伪装代码来源：为了获得更客观的反馈，可以谎称审查的是同事的 PR (Pull Request)。
• 重复检查：多次运行相同的审查流程，确保所有错误都被发现和修复。

5. AI 带来的额外价值
• “睡着也能完成额外工作”：AI 代理不知疲倦，可以持续迭代解决问题，为作者节省时间。
• “自动化盲区”（automation blindness）的风险：长时间对 AI 的输出无条件“同意”，可能导致忽视潜在问题。
• “yolo 模式”下的试验：在 Podman 容器中运行 AI 代理，以减少对人工干预的依赖，但作者仅在不重要的副项目中使用，以防潜在的安全问题。
• 工作与生活平衡的挑战：AI 可能导致工作侵入非工作时间，需警惕。

6. 结论与个人感受
• 复杂的情感：作者对 AI 代理仍抱有复杂甚至“厌恶”的情感，认为它们让编程变得不那么有趣，但其有效性是不可否认的。
• 效率的巨大提升：AI 极大地提高了代码编写速度。
• 适用场景：AI 不适合处理复杂、新颖或涉及代码库多个分散部分的模糊项目，这类任务仍需人工完成。
• 角色转变：作者将自己的新角色比作软件架构师，更多地参与规范编写和代码审查，而非纯粹的编码。
• 对开源项目的影响：作者在开源项目中不使用 AI，因为缺乏“所有权”感，认为代码不是自己亲手写的。
• “不那么有趣，但最优”的选择：尽管 AI 让编程乐趣减少，但它作为“最优策略”，仍会被选择使用，就像游戏中玩家会选择最有效率而非最有趣的玩法。
• 接受现状：作者认为大多数开发者已经接受 AI，并正在向前发展。