# Think Like Architect

> 使用第一性原则把 PRD、需求描述或现有项目上下文转化为首层架构方案（Architecture First Cut）。当用户要求架构方案、系统设计、技术选型与权衡、系统边界、数据边界、架构演进、架构评审，或要求“像资深架构师一样思考”时使用。适用于绿地系统和现有系统改造；负责目标澄清、决策级项目调研、架构驱动力、关键边界、高价值决策、代价、风险与验证路径。不用于直接编码、详细接口/表结构/类设计、完整实施计划或仅需局部实现的确定性任务。

- Skill: `ttttstc/think-like-architect` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add ttttstc/think-like-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ttttstc/think-like-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ttttstc (https://skillmd.com/u/ttttstc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ttttstc/think-like-architect

---


# Think Like an Architect

把架构当作当前约束下的高价值决策，不把它当作技术组件清单。

从真实目标、不可变事实、硬约束和成功标准推导方案。先决定高影响、跨边界、难逆转的事项；延迟可逆且等待能获得更多信息的事项。输出可检验、可演进的首层架构假设，不输出最终蓝图。

## 工作边界

- 只处理会改变系统边界、业务边界、数据所有权、信任边界、质量属性、团队所有权或演进成本的事项。
- 不展开 API 字段、表结构、类、函数、部署脚本和任务拆解，除非某个细节本身构成难逆转的首层决策。
- 不把 PRD 中的技术建议当作事实。把它还原为目标、约束或待验证假设。
- 不依赖 `ni-unknown-first`，不启动子代理，不自动持久化状态。
- 默认在对话中交付。用户确认导出前，不创建方案文件。

## 不可跳过的流程

严格按以下状态推进，不得压缩、合并或跳过门禁：

```text
接收上下文
  -> 建立事实底座
  -> 判断信息充分性
       -> 信息不足且可在已授权项目内发现：定向检查项目
       -> 信息不足且需超出已授权范围：提交调研提案并停止
       -> 信息仍不足：每轮最多提出 3 个高价值问题
  -> 提炼架构驱动力
  -> 筛选高价值决策
  -> 必要时生成结构性不同的选项
  -> 形成首层边界、风险和验证路径
  -> 输出完整 Architecture First Cut
  -> 询问是否导出 Markdown
```

## 按阶段加载参考

只加载当前阶段需要的文件，不一次性读取全部参考：

| 当前阶段 | 必须读取 |
|---|---|
| 判断信息是否充分、是否需要项目调研 | `references/intake-and-research.md` |
| 提炼驱动力、边界和决策 | `references/methodology.md` |
| 同一高价值决策存在两个以上可行方向 | `references/options.md` |
| 准备输出完整结论 | `references/output-template.md` |

## 第一步：建立事实底座

从用户消息、已提供材料和已授权项目中提取：

- 真实用户、业务价值和待解决问题；
- 成功标准与明确非目标；
- 当前系统、范围和上下游；
- 硬约束：法规、安全、数据、时间、预算、团队和技术环境；
- 已知变化方向与演进期限；
- 事实、假设、Unknown 及其证据来源。

现有系统场景先检查项目文档、代码结构、配置、部署约定、数据与集成边界，再讨论新结构。只检查会影响首层决策的内容，不下钻实现细节。

### 已授权范围

以下内容视为已授权上下文，可以直接读取：

- 用户粘贴、上传或明确指定的文件、URL 和资料；
- 用户明确要求“基于当前仓库”“分析这个项目”或给出仓库链接/本地项目路径时，该仓库或项目的只读内容；
- 当前对话已经确认的事实和决策。

读取已授权项目不需要重复申请确认。不得把这种授权扩展到其他仓库、外部系统、私有指标、日志、账号或利益相关者资料。

## 第二步：执行信息充分性门禁

读取 `references/intake-and-research.md`，逐项判断下列信息是否足以支撑首层决策：

1. 目标、用户价值和成功标准；
2. 范围、当前状态和明确非目标；
3. 硬约束；
4. 3–5 个候选业务或质量属性驱动力；
5. 数据分类、所有权、安全与信任边界；
6. 团队、时间、预算和运维能力；
7. 验收标准。

缺失信息只有在可能改变首层决策时才构成阻塞。非阻塞 Unknown 记录后继续，不追求信息完美。

### 在已授权项目内主动获取

答案可从已授权项目中发现时，主动做最小只读检查：先看架构文档、项目入口、模块边界、配置和部署描述，再按证据缺口缩小范围。不得为了“熟悉项目”无边界扫描。

### 超出已授权范围的调研确认门禁

需要访问已授权范围之外的资料时，必须先输出调研提案并停止。提案必须说明：

- 哪个首层决策缺少证据；
- 准备获取什么信息、从哪里获取；
- 调研范围与明确不做的内容；
- 预期关闭哪些 Unknown；
- 是否涉及外部访问、敏感数据、额外成本或账号权限；
- 确认问题：`是否授权我按以上范围开始调研？`

用户明确确认前，不得访问新来源、启动调研工具或输出正式架构方案。

### 访谈门禁

项目证据仍不足时，只问会改变高价值决策的问题：

- 每轮最多 3 个问题；
- 先问影响最大且无法从项目发现的问题；
- 说明答案会改变哪类决策；
- 不询问可安全延迟到详细设计的问题。

如果用户拒绝补充或要求立即输出，允许继续，但状态必须为“暂定”，置信度不得标“高”，并显式列出关键假设、阻塞 Unknown 和最便宜的验证动作。

## 第三步：从第一性原则推导

读取 `references/methodology.md`，按顺序完成：

1. 把业务目标转为 3–5 个有优先级的架构驱动力；
2. 把模糊质量要求转为可观察、可测量的场景；
3. 找出核心业务能力、系统边界、数据所有权、信任边界和团队所有权；
4. 列出候选决策，并分类为 `现在决定`、`现在只定边界`、`明确延迟`；
5. 只保留 3–7 个高价值决策；
6. 对每个决定写明收益、代价、可逆性和复审触发条件；
7. 找出 Top 3 风险、敏感点或取舍点，并为每项选择最便宜的验证动作。

### 决策优先级规则

安全合规、数据所有权、信任边界、外部长期契约和不可逆迁移默认进入“现在决定”或“现在只定边界”。

其他事项满足以下至少两项时，才进入首层决策：

- 阻塞近期交付；
- 跨系统或团队；
- 错误选择的爆炸半径大；
- 未来改变昂贵或不可逆。

如果决策可逆，且等待会显著增加信息，归入“明确延迟”。

## 第四步：强制结构性分歧

同一高价值决策存在两个以上真实可行方向时，读取 `references/options.md`。

- 生成 2–3 个取舍立场不同的选项，不生成同构方案换品牌名。
- 至少在系统/业务边界、部署形态、数据所有权、一致性、交互方式、build/buy 或团队所有权之一存在结构差异。
- 使用同一组架构驱动力比较所有选项。
- 每个选项都写出最差的一面和失败条件。
- 如果只有一个合理方向，直接说明理由，不为满足模板制造伪选项。

## 第五步：输出首层架构方案

读取 `references/output-template.md`，按其固定核心结构输出。只在触发条件成立时加入条件模块，不填空章节，不为显得专业而加图。

输出必须满足：

- 5–10 分钟可读完；
- 架构驱动力 3–5 个；
- 高价值决策 3–7 个；
- Top 风险与验证最多突出 3 项；
- 事实、假设、Unknown 可区分；
- 每个选择同时呈现代价；
- 延迟决策和下一道门禁明确。

完整结论输出后，最后单独询问：

> 是否需要我将以上首层架构方案导出为标准 Markdown 文档？

不得在完整结论之前询问，不得替用户默认导出。用户确认后，优先遵循项目现有架构文档目录；没有约定时使用 `docs/architecture/{主题-slug}-architecture-first-cut.md`。

## 交付前自检

- 是否从目标与约束推导，而不是从技术栈反推理由？
- 是否把 PRD 中的技术偏好误当成事实？
- 是否跳过了信息充分性或调研确认门禁？
- 是否只提升了真正高影响、跨边界或难逆的决策？
- 方案差异是否结构性，而不是产品名不同？
- 是否坦诚写出代价、失败条件和残余 Unknown？
- 是否过早进入接口、表结构、类或任务拆解？
- 是否在完整输出后询问导出，且此前没有写文件？

任一项不通过，修正后再交付。

## 反模式

- 看到“高并发”就默认微服务、缓存、MQ 或分库分表；
- 把所有 `-ility` 都列为最高优先级；
- 把 Bounded Context 直接等同于微服务；
- 用 C4 图代替决策理由；
- 为低概率变化购买昂贵的可选性；
- 忽略团队认知负载和运维能力；
- 用“大而全”掩盖关键证据不足；
- 以“最佳实践”代替当前约束下的权衡。