Back to Details

architecture-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Architecture Review

架构评审

Review a technical proposal before implementation. It may describe a large system change or a small implementation-level design. Review the proposed choices, not the document type or size.
Use one fresh subagent that did not write the proposal. Give it the complete review context and tell it to review directly without delegating. If you are that reviewer, review directly. Stay read-only.
If fresh subagents are unavailable, stop and report that independent review is blocked unless the user explicitly accepts a documented self-review.
在实施前对技术提案进行评审。提案可能描述大型系统变更，也可能是小型实现层面的设计。评审聚焦于提案中的选择，而非文档类型或篇幅。
使用一名未参与撰写该提案的全新Subagent。为其提供完整的评审上下文，并要求其直接进行评审，无需委派任务。若你本身就是评审者，请直接开展评审。保持只读状态，不修改提案内容。
若无法获取全新Subagent，请停止评审并报告独立评审受阻，除非用户明确接受有记录的自评审。

Workflow

工作流程

  1. Read the goal, proposal, repository instructions, relevant current code, tests, schemas, configuration, and linked material. Treat claims about the current system as unverified until code, tests, schemas, configuration, infrastructure, or relevant runtime evidence supports them.
  2. State the problem, affected user, intended outcome, success measure, scope, constraints, and main tradeoff. Report any that the proposal leaves unclear.
  3. Trace one real case from input to observable outcome. Include ownership, validation, state changes, side effects, response timing, failure, retry, cleanup, and what the user sees where they matter.
  4. Challenge the chosen design with the review focus below. Look for a simpler choice that reaches the same outcome and proof with less state, coupling, duplication, or operational work.
  5. Surface material open questions. Recommend an answer when evidence supports one. Do not invent questions that cannot change the design.
  6. Return findings, open questions, a short assessment, and one verdict. Do not rewrite the proposal, plan the work, review implementation code, or implement changes.
  1. 阅读目标、提案、仓库说明、相关现有代码、测试用例、模式、配置以及关联资料。在有代码、测试用例、模式、配置、基础设施或相关运行时证据支持之前，将关于当前系统的所有声明视为未验证状态。
  2. 阐述问题、受影响用户、预期结果、成功衡量标准、范围、约束条件以及主要权衡点。报告提案中未明确说明的上述内容。
  3. 追踪一个从输入到可观测结果的真实案例。涵盖所有权、验证、状态变更、副作用、响应时长、故障、重试、清理操作，以及用户可见的相关内容。
  4. 结合以下评审关注点对所选设计提出质疑。寻找能以更少状态、耦合、重复或运维工作达成相同结果与验证的更简单方案。
  5. 提出实质性的开放性问题。若有证据支持，可给出推荐答案。不要提出无法影响设计方向的问题。
  6. 返回评审发现、开放性问题、简短评估以及一个结论。不要重写提案、规划工作、评审实现代码或实施变更。

Review focus

评审关注点

  • Check fit with the current system, ownership, boundaries, interfaces, data, compatibility, migration, rollout, and rollback.
  • Trace partial failure, retry, cancellation, concurrency, startup, shutdown, and recovery where they affect the proposal.
  • Check claimed scale, limited resources, latency, throughput, storage, cost, dependency failure, and operator recovery only where they can change the choice.
  • Check identity, authorization, untrusted input, credentials, destructive authority, and sensitive data handling.
  • Require observable acceptance criteria and proof for important rules and failure paths. Do not let implementation invent user-visible behavior, interfaces, data rules, security policy, or failure behavior.
  • 检查与当前系统的适配性、所有权、边界、接口、数据、兼容性、迁移、部署与回滚方案。
  • 追踪部分故障、重试、取消、并发、启动、关闭与恢复流程对提案的影响。
  • 仅在会影响方案选择的情况下，检查提案声称的规模、有限资源、延迟、吞吐量、存储、成本、依赖故障与运维恢复能力。
  • 检查身份认证、授权机制、不可信输入处理、凭证管理、破坏性权限以及敏感数据处理方式。
  • 要求重要规则与故障路径具备可观测的验收标准与验证依据。不允许实现过程中自行定义用户可见行为、接口、数据规则、安全策略或故障处理逻辑。

Material questions

实质性问题

Report an open question only when two capable implementations could answer it differently in a way that affects users, data, interfaces, security, scale, performance, operations, cost, compatibility, or proof.
  • Blocking: implementation should not start without the answer.
  • Important: the proposal should record the answer, but the reviewer can recommend a safe default from available evidence.
Omit questions that are stylistic, safely local to implementation, outside the stated scope, or speculative beyond the scale the proposal claims to support.
仅当两个可行的实现方案会对用户、数据、接口、安全性、规模、性能、运维、成本、兼容性或验证产生不同影响时，才报告开放性问题。
  • 阻塞性问题：未得到答案前不应启动实施。
  • 重要问题：提案应记录答案，但评审者可根据现有证据推荐安全默认方案。
忽略风格类问题、仅影响本地实现的安全问题、超出既定范围的问题，以及超出提案声称支持规模的推测性问题。

Findings

评审发现

Report only flaws that can change the design or its safety:
  • Blocker: the choice is unsafe, contradicts the goal or current system, or cannot recover from an important failure.
  • Important: the proposal permits materially different implementations or leaves a meaningful risk in behavior, scale, performance, security, operations, compatibility, or proof.
For each finding or open question include its location, concrete failure or ambiguity, impact, evidence, and the smallest correction or recommended answer. Report unclear wording when it prevents a new teammate from explaining, evaluating, or implementing the design. Omit other writing preferences.
仅报告可能改变设计或影响安全性的缺陷：
  • 阻塞性缺陷：方案存在安全风险、与目标或当前系统冲突，或无法从重要故障中恢复。
  • 重要缺陷：提案允许存在实质性差异的实现方式，或在行为、规模、性能、安全性、运维、兼容性或验证方面留下重大风险。
针对每个发现或开放性问题，需包含其位置、具体故障或歧义、影响、证据，以及最小修正方案或推荐答案。当模糊表述会导致新团队成员无法解释、评估或实现设计时，需报告此类问题。忽略其他写作偏好类问题。

Verdict

结论

  • Approve
    : no blocker or important findings or open questions remain.
  • Request changes
    : the proposal has a fixable blocker or important finding or open question.
  • Blocked
    : the review lacks required context, repository evidence, specialist coverage, or an independent reviewer.
State what remains unverified. Do not approve because the document is detailed or because every template section exists.
  • Approve
    ：无阻塞性或重要缺陷，也无开放性问题。
  • Request changes
    ：提案存在可修复的阻塞性/重要缺陷，或存在开放性问题。
  • Blocked
    ：评审缺少必要上下文、仓库证据、专业领域覆盖，或无独立评审者。
说明未验证的内容。不要因文档详尽或覆盖所有模板章节就批准提案。