我如何利用 AI 议会（AI Councils）解决模糊的工程问题

一个 AI 助手很有用，但并不总是足够。

如果你使用 AI 进行编程，你一定熟悉这种模式：你描述一个问题，模型提出一个方案。看起来不错，你付诸实现。结果三天后你发现了一个巨大的缺陷——架构在边界条件下失效了，或者它将两个本该分离的部分耦合在了一起。

这不是模型的失败，而是流程的失败。单个模型缺乏挑战自身假设的能力。

对于复杂的工程任务，你需要一个 AI 议会（AI Council）。这并不是一个新平台，而是一种结构化的工作流，通过多个 AI 角色从不同角度对同一个方案进行评审。

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

以下是该工作流的运作方式：

• 问题陈述 (Problem Statement)：你界定问题。 • 架构师 Agent (Architect Agent)：一个基于事实依据（source-grounded）的 Agent 创建初始方案。 • AI 议会 (AI Council)：不同的 AI 角色对方案进行评审。 • 反馈综合 (Feedback Synthesis)：一个 Agent 汇总所有反馈并识别冲突。 • 异议账本 (Objection Ledger)：你记录每一项异议、其严重程度以及解决方案。 • 人类治理 (Human Governance)：你决定何时停止或继续。 • 执行 Agent (Executor Agent)：一个独立的 Agent 负责实施方案。 • 审计 Agent (Auditor Agent)：最后一个 Agent 根据原始规范检查代码。

你议会中的角色应包括：

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

秘诀不在于使用更多的模型，而在于角色的分离。当你要求 AI “评审这个”时，你得到的是模糊的回答；而当你要求 AI “找出三个最大的架构风险”时，你得到的是可操作的数据。

你还必须分离上下文。编写代码的 Agent 不应该是审计代码的同一个 Agent。这可以防止 AI 陷入相同的盲点。

人类不从事体力劳动，人类掌控关卡（gates）。你决定反馈是否足够，你决定接受哪些风险。你是工程经理，而不是体力劳动者。

请将此方法用于高风险重构和模糊的架构设计。不要将其用于琐碎的 Bug 修复。只有当错误成本很高时，这种开销才物有所值。

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

Optional learning community: https://t.me/GyaanSetuAi