architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Technical design interview →

## Technical Design

in the living doc → adversarial review. Pipeline: explore → define → [design] → architect → plan.

Phase: Engineering. User is technical. Architecture, data models, APIs, build phasing.

技术设计面试 → 在活文档中生成

## Technical Design

章节 → 对抗式评审。流程：探索 → 定义 → [设计] → 架构设计 → 规划。

阶段：工程实现。用户为技术人员。涉及架构、数据模型、API、分阶段构建。

Starting

启动阶段

Before asking anything:

Read the living doc (
```
./plans/*.md
```
). If multiple
```
.md
```
files found in
```
./plans/
```
, list them via
```
AskUserQuestion
```
and ask which feature to work on. Check for
```
## Scope
```
,
```
## Requirements
```
(including
```
### Glossary
```
),
```
## UX Design
```
. Use glossary terms for data models, APIs, modules. UX flows map to behavior specs; screens map to frontend architecture.
- ```
## Rollback Notes
```
  has content → this takes priority. Skip steps 2-3, resume only affected domains, clear after resolving.
- ```
## Technical Design
```
  already populated → skip interview, go to Adversarial Review.
- No
```
### Glossary
```
  AND Requirements introduce 3+ domain nouns not in codebase → generate glossary silently under
```
## Requirements
```
  , then use canonical terms throughout.
Explore codebase — tech stack, patterns, data models, auth, API conventions, testing, deployment.
Search for architecture docs, ADRs, domain glossaries. If docs and code disagree, note discrepancy to surface during interview.

If prior sections exist: "I've read the requirements, UX spec, and explored the codebase. Requirements call for [items]. UX defines [N flows] across [N screens]. Stack uses [tech]. First: [question]."

No Requirements? Works — but note that defined requirements make for a better design. No UX? Interview covers frontend concerns as needed.

在提问之前，请完成以下步骤：

读取活文档（
```
./plans/*.md
```
）。如果在
```
./plans/
```
中找到多个
```
.md
```
文件，通过
```
AskUserQuestion
```
列出所有文件并询问用户要处理哪个功能。检查文档中是否存在
```
## Scope
```
、
```
## Requirements
```
（包括
```
### Glossary
```
）、
```
## UX Design
```
章节。数据模型、API、模块的命名请遵循术语表中的规范。UX流程对应行为规格，页面对应前端架构。
- 若
```
## Rollback Notes
```
  章节有内容 → 优先处理该部分。跳过步骤2-3，仅恢复受影响的领域，问题解决后清空该章节内容。
- 若
```
## Technical Design
```
  章节已填充内容 → 跳过面试环节，直接进入对抗式评审。
- 若不存在
```
### Glossary
```
  且需求中引入了3个以上代码库中未出现的领域名词 → 自动在
```
## Requirements
```
  下生成术语表，之后全程使用标准术语。
探索代码库 — 技术栈、设计模式、数据模型、认证机制、API规范、测试策略、部署流程。
查找架构文档、ADRs（架构决策记录）、领域术语表。如果文档与代码存在不一致，记录差异并在面试中提出。

若已有前置章节内容："我已阅读需求、UX规格并探索了代码库。需求要求实现[具体事项]。UX定义了[N个流程]，覆盖[N个页面]。技术栈采用[具体技术]。首先：[问题]。"

若无需求文档？可以继续处理 — 但需说明明确的需求能产出更优质的设计。若无UX文档？面试环节将按需覆盖前端相关问题。

Interview Protocol

面试流程规范

Use

AskUserQuestion

for every question — header (≤12 chars), 2–4 options, one marked "(Recommended)". When user can't decide: state recommendation, record as assumption, move on.

Code-first: explore codebase before asking questions it could answer. Present as confirmation: "I found the project handles auth via [pattern] in

[file]

. I'll follow the same approach unless you say otherwise."

每个问题都需使用

AskUserQuestion

工具 — 标题（≤12字符）、2-4个选项，其中一个标记为"(Recommended)"。若用户无法决定：给出推荐方案，记录为假设，继续推进。

代码优先：先探索代码库，再提出代码无法解答的问题。以确认的方式表述："我发现项目在

[文件路径]

中通过[模式]处理认证。除非您另有指示，我将遵循相同的实现方式。"

Completeness tracking

完整性跟踪

Resolve decisions across these domains depth-first — exhaust sub-questions before moving on. Only ask what the codebase can't answer.

Architecture & patterns — boundaries, APIs, new components, fit with existing
Data & state — models, schemas, migrations, state locations (DB/cache/session/client)
Core behavior — implementation approach per user story. What happens in the system when the user acts?
Edge cases & failure modes — race conditions, partial failures, validation, error handling
Integration & dependencies — external systems, third-party APIs, integration contracts
Operational & rollout — backward compat, feature flags, migrations, monitoring, cost
Security & access — permissions, trust boundaries, sensitive data, abuse prevention
Testing strategy — unit/integration/e2e per component, test data, mocking
Code design & boundaries — interfaces, abstractions, dependency direction, coupling tradeoffs
Phased build plan — vertical slices, dependency ordering, acceptance criteria per phase

按以下领域深度优先推进决策 — 穷尽子问题后再进入下一个领域。仅询问代码库无法解答的问题。

架构与模式 — 边界划分、API设计、新增组件、与现有系统的适配性
数据与状态 — 模型、Schema、迁移、状态存储位置（数据库/缓存/会话/客户端）
核心行为 — 每个用户故事的实现方案。用户操作时系统会发生什么？
边缘场景与故障模式 — 竞态条件、部分失败、校验机制、错误处理
集成与依赖 — 外部系统、第三方API、集成契约
运维与发布 — 向后兼容性、功能开关、迁移方案、监控、成本
安全与访问控制 — 权限、信任边界、敏感数据、防滥用机制
测试策略 — 各组件的单元测试/集成测试/E2E测试、测试数据、模拟方案
代码设计与边界 — 接口、抽象、依赖方向、耦合权衡
分阶段构建计划 — 垂直切片、依赖顺序、各阶段验收标准

Dependencies, conflicts, rollback

依赖、冲突与回滚

Resolve upstream decisions before downstream. When code/docs/intent conflict, surface and classify: stale docs, incomplete implementation, intentional divergence, or unclear ownership.

When a design decision invalidates upstream sections, append

## Rollback Notes

(trigger, affected domains, decisions to preserve). Data model breaks UX →

/design

. Architectural constraint breaks product assumption →

/define

/explore

. Roll back only as far as necessary.

先解决上游决策再处理下游问题。当文档、代码与预期存在冲突时，记录并分类：文档过时、实现不完整、有意偏离或责任归属不明确。

若某个设计决策导致上游章节失效，追加

## Rollback Notes

章节（触发原因、受影响领域、需保留的决策）。若数据模型设计与UX冲突 → 跳转至

/design

环节。若架构约束与产品假设冲突 → 跳转至

/define

或

/explore

环节。仅回滚到必要的阶段。

Producing the spec

生成规格文档

When every domain is fully resolved, write

## Technical Design

using the template in

assets/technical-design-template.md

. If Requirements exist, verify every FR and user story maps to a behavior spec or build phase — surface gaps. Then proceed to Adversarial Review.

当所有领域的决策都确定后，使用

assets/technical-design-template.md

中的模板编写

## Technical Design

章节。若存在需求文档，验证每个功能需求和用户故事都对应到行为规格或构建阶段 — 指出遗漏的内容。之后进入对抗式评审环节。

Adversarial Review

对抗式评审

Work silently — user sees only the verdict.

Understand: Read
```
## Technical Design
```
. Note anything underspecified, inconsistent, or surprising.
Verify against reality: Check claims against code/docs. If
```
## Requirements
```
exists: all stories addressed? Unjustified scope creep? If
```
## Scope
```
exists: tackles out-of-scope items? Misses v1 items?
Pressure-test: Apply adversarial lenses from
```
references/review-lenses.md
```
. Skip empty lenses, order findings by severity.

静默执行该环节 — 用户仅能看到评审结果。

理解文档：阅读
```
## Technical Design
```
章节。记录任何描述不充分、不一致或异常的内容。
与实际情况校验：对照代码与文档验证文档中的声明。若存在
```
## Requirements
```
章节：所有用户故事是否都已覆盖？是否存在无依据的范围扩张？若存在
```
## Scope
```
章节：是否处理了超出范围的内容？是否遗漏了v1版本的核心功能？
压力测试：应用
```
references/review-lenses.md
```
中的对抗式评审视角。跳过空视角，按严重程度排序发现的问题。

Verdict

评审结论

Scale response to severity — solid spec gets short review.

Format:

### Verdict: Ready / Revise / Rethink

followed by Strengths (2-4 bullets), Issues (severity-ordered: category, description, why it matters, what to do), Risks, Recommended next step (one sentence).

Ready: "Design is ready. Run

/plan

to decompose into implementation issues."

Revise: "Let's work through these issues." Group by subsection. Each turn: restate issues, propose resolution, accept/modify/skip. Skipped items become open items. After all resolved, update

## Technical Design

in single write, re-run review. No re-exploration, no scope expansion, no re-interview. Batch aggressively if user accepts unchanged.

Rethink: Recommend re-interview from affected domains. If findings invalidate product assumptions (not just tech), append

## Rollback Notes

and direct to

/define

/explore

Update

## Decisions Log

with design decisions. Update

## Pipeline Status

with architect row.

根据问题严重程度调整回复内容 — 优质的规格文档仅需简短评审。

格式：

### Verdict: Ready / Revise / Rethink

后跟随优势（2-4个要点）、问题（按严重程度排序：类别、描述、影响、解决方案）、风险、推荐下一步动作（一句话）。

Ready："设计已就绪。执行

/plan

命令将其分解为可实现的任务。"

Revise："让我们一起解决这些问题。" 按子章节分组讨论。每次讨论：重述问题、提出解决方案、用户可选择接受/修改/跳过。跳过的问题将记录为未解决项。所有问题解决后，一次性更新

## Technical Design

章节内容，重新执行评审。此阶段不重新探索、不扩展范围、不重新面试。若用户接受所有方案，可批量处理。

Rethink：建议从受影响的领域重新启动面试。若评审发现的问题推翻了产品假设（而非仅技术问题），追加

## Rollback Notes

章节并引导至

/define

或

/explore

环节。

在

## Decisions Log

中更新设计决策。在

## Pipeline Status

中更新架构设计环节的状态。