melech-consult

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Consult

咨询

When an AI proposes an architecture, implementation plan, or idea, asking the same conversation thread "are you sure?" fails:

It suffers from self-grading bias (eagerly rationalizing its own proposal).
It suffers from thread fatigue (trapped in the same assumptions and blind spots).
It agrees too easily with whatever direction was already discussed.

melech-consult

is the proof-and-verify circuit. It takes the proposal on the table, packages it into an objective brief, hands it to fresh isolated subagents running different models from different providers (an expert council / deeper model tier) to stress-test and proof, and reports back the independent findings without defending the original idea.

当AI提出某个架构、实施方案或想法时，在同一条对话线程中询问“你确定吗？”是无效的：

存在自我评估偏差（会急于合理化自己提出的方案）。
存在线程思维局限（陷入相同的假设和盲区）。
会轻易认同已讨论过的任何方向。

melech-consult

是一套验证校验机制。它会提取当前提出的方案，将其整理成客观的简报，交给运行着不同提供商的不同模型的全新独立子代理（专家委员会/深度模型层级）进行压力测试和验证，然后反馈独立的评估结果，不会为原始方案辩护。

When to Reach for Consult

何时使用咨询功能

Reach for

melech-consult

after a direction, plan, or architecture has been proposed and you want it proofed before building:

"Double-check this implementation plan before we start coding."
"Proof this architecture with another model."
"Are you sure about this fix? Get a second opinion."
"Convene an expert council to poke holes in this idea."
"Have a devil's advocate red-team your proposed approach."

当某个方向、方案或架构已提出，且你希望在开始实施前对其进行验证时，即可使用

melech-consult

：

“在开始编码前，再次检查这个实施方案。”
“用另一个模型验证这个架构。”
“你确定这个修复方案可行吗？找个二次意见。”
“组建专家委员会，找出这个想法的漏洞。”
“让唱反调的人对你提出的方案进行红队测试。”

What You Can Proof & Double-Check

可验证与复查的内容

melech-consult

proofs both Implementation & Architecture and Product & Ideas:

Consultation Format	For Implementation & Architecture Proposals	For Product & Idea Proposals
Double-Check / Second Opinion (Default)	Proofs a proposed code diff, refactor, DB schema, or bug fix for subtle flaws, race conditions, or missing edge cases.	Sanity-checks a proposed feature concept, workflow, or positioning against market reality.
Peer Review	Independent staff-engineer critique of a written RFC, plan, or API design before implementation.	Independent product-manager critique of a PRD, user journey, or pitch.
Expert Council	Triangulates the proposal across 2–3 competing technical lenses (e.g. Pragmatist / 80-20 vs. Scale / Concurrency vs. Security / Blast Radius).	Triangulates the proposal across 2–3 business lenses (e.g. User Value & WTP vs. Growth & Distribution vs. MVP Feasibility).
Devil's Advocate (Red Team)	Explicit mandate to break the proposed code: find why it will fail in production, deadlock, or degrade performance.	Explicit mandate to shoot down the idea: why users won't switch, why incumbents win, and flawed assumptions.

melech-consult

可验证实现与架构以及产品与想法两类内容：

咨询形式	适用于实现与架构类方案	适用于产品与想法类方案
复查/二次意见（默认模式）	验证拟议的代码差异、重构、数据库架构或漏洞修复，排查细微缺陷、竞态条件或遗漏的边缘场景。	从市场实际出发，对拟议的功能概念、工作流程或定位进行合理性检查。
同行评审	在实施前，由独立资深工程师对书面RFC、方案或API设计进行评审。	在落地前，由独立产品经理对PRD、用户旅程或提案进行评审。
专家委员会	从2-3个对立的技术视角对方案进行交叉验证（例如：实用主义/80-20原则 vs 扩展性/并发处理 vs 安全性/影响范围）。	从2-3个不同的业务视角对方案进行交叉验证（例如：用户价值与支付意愿 vs 增长与分发 vs MVP可行性）。
唱反调者（红队测试）	明确要求找出拟议代码的问题：找出其在生产环境中失效、死锁或性能下降的原因。	明确要求否决该想法：找出用户不愿切换的原因、 incumbent（在位企业）获胜的理由，以及方案中的错误假设。

The 4-Step Proofing Workflow

四步验证流程

1. Freeze the Proposal (Take off the Author Hat)

1. 固化方案（切换至评审视角）

You are no longer defending your idea. Extract the current proposal into a clean, standalone brief:

Core Objective: What problem this is trying to solve.
The Proposed Approach: The exact mechanism, architecture, or workflow proposed.
Key Invariants & Constraints: Performance limits, existing patterns, backward compatibility.
Alternatives Already Rejected: What was considered and ruled out (so consultants don't waste time suggesting them).

你不再需要为自己的想法辩护。将当前方案提炼为一份清晰、独立的简报：

核心目标：该方案旨在解决什么问题。
拟议方案：提出的具体机制、架构或工作流程。
关键约束与不变量：性能限制、现有模式、向后兼容性。
已排除的替代方案：曾考虑过但被否决的方案（避免评审浪费时间重复提出）。

2. Brief the Consultant (The Anti-Self-Grading Rule)

2. 撰写咨询简报（反自我评估原则）

Never lead the witness or ask for validation.

DON'T SAY: "I proposed using a Redis queue because it's fast. Do you think that's a good idea?"
DO SAY: "Here is a proposed implementation using a Redis queue for task batching under constraints [X, Y]. Audit this approach: identify failure modes, edge cases, operational costs, and whether a simpler in-process or DB solution was overlooked."

切勿诱导评审或寻求认可。

错误表述：“我提议使用Redis队列，因为它速度快。你觉得这是个好主意吗？”
正确表述：“这是一份在约束条件[X, Y]下使用Redis队列进行任务批处理的拟议实施方案。请审核该方案：找出故障模式、边缘场景、运维成本，以及是否忽略了更简单的进程内或数据库解决方案。”

3. Dispatch the Consultation

3. 发起咨询请求

When subagent tools are available (
invoke_subagent
, background agents):
- Give every consultant a distinct
```
Role
```
  and a deliberately distinct
  Model
  — never
```
inherit
```
  , never the model that authored the proposal, never the same model twice. Same model means shared blind spots, so agreement is an echo rather than corroboration. Prefer spreading across providers, and shrink the council rather than reuse a model.
- For an Expert Council, dispatch all 2–3 consultant lenses concurrently in a single call.
When running without subagent tools:
- Explicitly construct the adversarial/distinct role perspectives with strict isolation, clearly labeling the independent audit as single-model.

当子代理工具可用时（
invoke_subagent
、后台代理）：
- 为每个评审分配独特的
```
Role
```
  （角色）以及完全不同的
  Model
  （模型）——绝不要使用
```
inherit
```
  （继承），绝不要使用提出原方案的模型，也绝不要重复使用同一模型。同一模型会存在共同盲区，因此达成的共识只是回声而非真正的佐证。优先选择不同提供商的模型，宁可缩小委员会规模也不要重复使用模型。
- 对于专家委员会模式，可在一次调用中同时发起2-3个不同视角的评审请求。
当无法使用子代理工具时：
- 明确构建对立/独特的角色视角并严格隔离，清晰标注该独立评审为单模型评审。

4. Synthesize the Proofing Verdict

4. 整理验证结论

Do not dump raw transcripts. Deliver a clean 4-part synthesis:

Verified Solid: Parts of the proposal that held up under independent scrutiny.
Flaws, Landmines & Blind Spots: Concrete failure modes, missing edge cases, or unwarranted complexity exposed by the consultants.
Consensus vs. Clashes: Where the consultants agree vs. where trade-offs clash (e.g. simplicity vs. scale).
Concrete Adjustments (The Adjusted Plan): Actionable changes to make to the proposal before starting implementation.

不要直接输出原始对话记录。请整理为清晰的四部分结论：

验证通过部分：经独立评审后确认可行的方案内容。
缺陷、隐患与盲区：评审发现的具体故障模式、遗漏的边缘场景或不必要的复杂度。
共识与分歧：评审达成一致的部分，以及存在权衡冲突的部分（例如：简洁性与扩展性）。
具体调整建议（修正后方案）：在开始实施前需对原方案进行的可落地修改。

Example Proofing Runs

验证流程示例

Example 1: Double-Checking an Implementation Proposal

示例1：复查实施方案

markdown

**Context**: AI proposed adding an in-memory cache with TTL for user permissions.
**User**: "Double-check this with another model before we write code."

**Consultant Prompt**:
You are a Staff Systems Engineer. Audit this proposed permission-caching design:
Proposal: In-memory cache with 60s TTL on the API gateway.
Constraints: Multi-tenant SaaS, instantaneous permission revocation required for offboarded admins.
Task: Find where this breaks, evaluate cache invalidation complexity, and recommend the soundest fix.

**Synthesized Verdict**:
- **Landmine Exposed**: 60s TTL violates the hard requirement of instantaneous revocation for security offboarding.
- **Consultant Recommendation**: Use Redis Pub/Sub invalidation events or check revocation status via Redis bitmap rather than a blind TTL.
- **Adjusted Plan**: Switch from pure TTL to a lightweight revocation check endpoint.

markdown

**背景**：AI提议为用户权限添加带TTL的内存缓存。
**用户**：“在编写代码前，用另一个模型复查这个方案。”

**评审提示**：
你是一名资深系统工程师。请审核这份拟议的权限缓存设计：
方案：在API网关添加带60秒TTL的内存缓存。
约束：多租户SaaS，需支持对离职管理员的权限即时撤销。
任务：找出该方案的问题所在，评估缓存失效的复杂度，并推荐最可靠的修复方案。

**整理后的结论**：
- **发现隐患**：60秒TTL违反了安全离职流程中权限即时撤销的硬性要求。
- **评审建议**：使用Redis Pub/Sub失效事件或通过Redis位图检查撤销状态，而非盲目依赖TTL。
- **修正后方案**：从纯TTL模式切换为轻量级撤销检查端点。

Example 2: Expert Council on a Proposed Feature Idea

示例2：针对功能想法的专家委员会评审

markdown

**Context**: AI pitched building a custom automated visual diffing engine for PRs.
**User**: "Convene a council to proof this idea."

**Council Dispatched** (3 roles, 3 distinct models, 3 different providers; the main thread's model excluded):
1. *Pragmatist / 80-20 Lead* — provider A, deep-reasoning tier (Focus: build vs. buy, maintenance burden)
2. *Developer Experience Reviewer* — provider B (Focus: workflow friction, false-positive noise)
3. *Technical Architect* — provider C (Focus: headless browser rendering cost, CI latency)

**Synthesized Verdict**:
- **Consensus**: All 3 agree that building a custom diff engine from scratch has high maintenance overhead and false-positive flake.
- **Clash**: DX wants rich inline PR comments; Pragmatist recommends integrating existing GitHub Actions / Percy CLI instead of building a service.
- **Adjusted Plan**: Don't build a custom engine; write a 20-line GitHub Action wrapper around an existing open-source visual regression tool.

markdown

**背景**：AI提议为PR构建自定义自动化视觉差异对比引擎。
**用户**：“组建委员会验证这个想法。”

**已派出的评审委员会**（3个角色、3个不同模型、3个不同提供商；排除主线程使用的模型）：
1. *实用主义/80-20负责人* — 提供商A，深度推理层级（关注点：自研 vs 采购，维护成本）
2. *开发者体验评审员* — 提供商B（关注点：工作流程摩擦，误报干扰）
3. *技术架构师* — 提供商C（关注点：无头浏览器渲染成本，CI延迟）

**整理后的结论**：
- **共识**：三位评审一致认为，从零开始构建自定义差异引擎会带来高昂的维护成本和频繁的误报。
- **分歧**：开发者体验评审员希望提供丰富的PR内联评论；实用主义评审员建议集成现有的GitHub Actions / Percy CLI，而非自研服务。
- **修正后方案**：不构建自定义引擎；基于现有开源视觉回归工具编写一个20行的GitHub Action封装器。

Do / Don't

注意事项（可做/不可做）

Do:

Use
```
melech-consult
```
whenever the user says "double check", "are you sure", or asks for a second opinion on a proposal.
Welcome flaws and pushback from the consultants — proving the idea wrong early saves hours of wasted coding.
Keep the briefing neutral and adversarial so the consultant actively tries to break the proposal.
Give every consultant a different model from a different provider, and disclose the
```
role → model
```
roster in the verdict.
End with a concrete, adjusted proposal ready for the user to greenlight.

Don't:

Defend your original proposal when a consultant points out a valid flaw.
Ask the consultant to "confirm" or "validate" your idea.
Leave a consultant's model on default/
```
inherit
```
, reuse the main thread's model, or run two consultants on the same model — duplicate models manufacture fake consensus.
Dump raw subagent logs or transcripts into the chat.
Propose changes without explaining why the consultation altered the plan.

可做事项：

当用户提到“复查”、“你确定吗”或要求对方案提供二次意见时，使用
```
melech-consult
```
。
接纳评审指出的缺陷和反对意见——尽早证明想法错误可避免数小时的无效编码工作。
保持简报中立且具有对抗性，让评审主动尝试找出方案的问题。
为每个评审分配不同提供商的不同模型，并在结论中披露
```
角色→模型
```
的对应关系。
最终输出一份具体的修正后方案，供用户批准。

不可做事项：

当评审指出合理缺陷时，不要为原方案辩护。
不要要求评审“确认”或“认可”你的想法。
不要将评审的模型设为默认/
```
inherit
```
（继承），不要重复使用主线程的模型，也不要让两个评审使用同一模型——重复模型会产生虚假共识。
不要将子代理的原始日志或对话记录直接粘贴到聊天中。
不要只提出修改建议而不解释咨询过程为何改变原方案。