我如何利用 AI 委员会来解决模糊的工程问题

单个 AI 助手很有用，但对于复杂的软件架构来说还远远不够。

如果你使用 AI 的目的不仅仅是自动补全，你就会发现一种模式：单个模型会提出一个方案，看起来很不错，你实施了它，然后三天后，你发现了一个巨大的架构缺陷。

这并不是模型的失败，而是你流程的失败。单个模型很少会挑战它自身的假设。

为了解决模糊的问题，你需要一个 AI 委员会（AI Council）。这并不是一个新平台，而是一种工作流，通过多个 AI 上下文从不同角色对提案进行评审。

目标是将 AI 的使用转变为一种受控的工程工作流。

以下是该工作流：

• 问题陈述 (Problem Statement)：你界定问题。 • 架构智能体 (Architect Agent)：一个基于源码的智能体创建一个包含权衡方案的提案。 • AI 委员会评审 (AI Council Critique)：不同的 AI 角色对提案进行评审。 • 反馈综合 (Feedback Synthesis)：一个智能体评估所有反馈并识别冲突。 • 异议登记簿 (Objection Ledger)：你记录所有异议、其严重程度以及解决情况。 • 人工治理 (Human Governance)：你决定计划是否就绪，或者是否需要进行下一轮。 • 执行智能体 (Executor Agent)：一个独立的上下文负责实施计划。 • 审计智能体 (Auditor Agent)：第三个上下文根据原始规范对代码进行审计。

力量源于角色分离。不要只问“你觉得怎么样？”。为不同的 AI 会话分配特定的角色：

• 系统思考者 (System Thinker)：评估系统性风险和边界。
• 批判性审查者 (Critical Reviewer)：挑战假设并发现逻辑漏洞。
• 简化者 (Simplifier)：发现不必要的复杂性。
• 备选方案审查者 (Alternatives Reviewer)：提出不同的方法。

最重要的部分是异议登记簿 (Objection Ledger)。如果没有它，反馈就会变成模糊的意见。登记簿会迫使你解决每一个疑虑。你将异议标记为 Open（开启）、Accepted（接受）、Rejected（拒绝）或 Resolved（已解决）。这创建了一个可审计的决策记录。

你不会成为“复制粘贴”的瓶颈。基于源码的智能体负责综合。你充当治理者 (Governor)。你不做体力活，你掌控关卡。

你掌控决策：

• 何时停止迭代。
• 何时批准规范。
• 何时接受最终风险。

将此方法用于高风险重构或不明确的架构。不要将其用于琐碎的 Bug 修复。只有当错误设计的代价很高时，这种开销才物有所值。

从小处着手。使用一个审查者和一个简化者。你会立即看到它的价值。

Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii