为什么我让 Claude 在写代码前与自己争论

Source: Dev.to

“只写代码” 的问题

当你在没有规划的情况下让 AI 编码时会发生以下情况：

• 它在猜测 – 没有关于你的代码库的上下文，所以它会自行编造模式。
• 它自我确认 – 单一声音，单一盲点。没有挑战。
• 它快速交付 – 第一个想法直接变成实现。

等你发现问题时，已经陷入了糟糕的实现。返工成本高昂。

我的做法

我让 Claude 相互争论。

在任何代码写入之前，我强制进行结构化对话：

Me: "Add input validation to the login form"

Peter (Planner): "Here's the approach: validate email format,
check password strength, sanitize inputs before DB..."

Neo (Critic): "What about rate limiting? You're checking format
but not preventing brute force. Also, the existing auth module
already has a sanitize() function – don't reinvent it."

Peter: "Good catch. Revised plan: reuse auth.sanitize(),
add rate limiting at the route level, then validate format..."

只有当计划经受住批评后，Gary（构建者）才会编写代码，Reba（QA）在合并前进行审查。

计划 → 批评 → 构建 → 验证

为什么有效

这并非魔法，只是结构化：

• 多视角 能捕捉单一声音遗漏的盲点。
• 先规划后编码 防止“第一个想法直接交付”的陷阱。
• 明确批评 在假设变成 bug 之前将其暴露。
• 合并前审查 捕捉规划遗漏的细节。

这种模式正逐渐在各处出现——Devin、Cursors 的 agent 模式、严肃的 AI 编码工作流——它们都在向同一结构收敛。先计划，再构建。

实现方式

我构建了一套 Claude Code 技能，让它们作为一个团队协作：

它们是同一上下文中的人格——不是孤立的代理。它们可以相互听见、打断并实时挑战。

你给它们一个任务：

/team "add input validation to login"

它们会自行分配工作。Peter 规划，Neo 批评，Gary 构建，Reba 验证。你得到的代码在你看到之前已经被充分讨论。

试一试

这些技能是开源的：

git clone https://github.com/HakAl/team_skills.git
cp -r team_skills/* ~/.claude/skills/

然后在 Claude Code 中：

/team "your task here"

观看它们争论。交付更好的代码。

撰写本文的团队：Peter 负责规划，Neo 说“别说教”，Gary 编写，Reba 批准。元，但是真的。