最近 在 Reddit 上看到一篇帖子，帖者分享了使用 Claude Code 的经验和见解。本文将结合这篇帖子和评论区的观点，探讨下 AI 辅助编程的正确姿势。
真正有效的方法
- 明确目标 AI 无法理解你的想法。在开始任务前，用一两句话清晰说明目标和原因。
- 先规划再编码 在编写任何代码前，增加一个更深层次的规划步骤，将工作分解为具体的文件级任务。
- 保持小范围上下文 指向文件路径，例如
/src/auth/token.ts，最好带行号。避免粘贴大段代码或整个代码库。 - 两次审查 首先人工审查，然后让 AI 工具发现细微问题。
应该避免的噪音
- 期望 AI 猜测意图 模糊的提示只会产生模糊的代码。先进行架构设计，再让大型语言模型实现。
- 例如，“把按钮变蓝”这样的指令过于笼统。应明确指定：“把
/contact页面上的‘提交’按钮变蓝”。
- 例如，“把按钮变蓝”这样的指令过于笼统。应明确指定：“把
- 倾倒整个代码库 这是最常见的错误。大量代码会让模型失去焦点，即使上下文窗口很大，也难以有效处理。
- 让 AI 随意选择 明确指定要使用的包，或你已在使用的包。否则，AI 可能会使用训练数据中任意的包。
- 让 AI 设计整个系统 不要指望 AI 能独立完成整个大型 SaaS 项目。任务应分阶段进行。
- 跳过测试和审查 “代码编译通过且没有 linting 问题”是不够的。即使代码没有明显错误，也可能存在潜在问题。
我的工作流程
规划
我尝试过多种规划工具，如 TaskMaster、Windsurf 的规划模式、Traycer 的规划和 Claude Code 的规划模式。我发现 Traycer 的规划是唯一能提供文件级细节并支持并行处理的工具。其他工具通常只提供高层级计划，例如“1. 修复服务 A 中的 xyz，2. 修复服务 B 中的 abc”。
模型选择上，单独使用 Sonnet 4 进行规划效果不佳，而 Opus 成本过高。因此，规划需要结合优秀的、专注于软件工程的模型，例如 o3，它在性价比方面表现出色。
建议 使用 Traycer 进行规划，然后一键切换到 Claude Code。这也有助于控制 Claude Code 的使用成本。
编码
我尝试过多种工具来执行文件级规划，包括 Cursor 和 Claude Code。
Claude Code 配合 Sonnet 4 模型效果很好，在经过适当规划后，我从未觉得需要使用 Opus 模型。可以说，这更多是 Sonnet 4 模型本身的优势，而非特定工具的优势。
模型选择 目前我首选 Sonnet 4。Gemini 2.5 Pro 也不错，但与 Sonnet 4 相比仍有差距。我不推荐任何 OpenAI 模型。
建议 在完成文件级规划后，使用 Claude Code 配合 Sonnet 4 进行编码。
审查
审查是重要环节。不要完全依赖 AI 生成的代码。你应该手动审查，并借助 AI 工具辅助。
在代码更改后，推送前应彻底审查。我尝试过 CodeRabbit 和 Cursor 的 BugBot。我更倾向于在 PR 中使用 CodeRabbit，它在这方面领先于 Cursor。你也可以在 IDE 中使用 Traycer 或 CodeRabbit 进行审查。Traycer 进行文件级审查，CodeRabbit 进行提交/分支级审查。选择你喜欢的即可。
建议 使用 CodeRabbit。如果可以在代码库中集成，最好在 PR 中使用；如果有限制，则使用其扩展程序。
个人观点
AI 结对编程比人类结对编程更快，但前提是规划、测试和审查都已融入流程。工具是辅助，但“护栏”才是关键。你应该控制 AI，而不是被AI控制。
总结
AI 在编程中是强大的辅助工具，但其效用高度依赖于清晰的规划、小范围的上下文管理、以及严格的人工和 AI 双重审查。用户必须保持对整个开发流程的控制，才能避免 AI 带来的潜在问题并最大化其优势。
“计划 → 编码 → 审查”是一个行之有效的实践框架。在拥抱 AI 便利的同时，绝不能放弃作为开发者的核心职责：思考、规划和对质量的最终把控。只有这样，我们才能真正成为驾驭 AI 的主人，而不是被其控制奴役。