think-like-architect

Think Like an Architect

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

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

工作边界

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

不可跳过的流程

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

接收上下文
  -> 建立事实底座
  -> 判断信息充分性
       -> 信息不足且可在已授权项目内发现：定向检查项目
       -> 信息不足且需超出已授权范围：提交调研提案并停止
       -> 信息仍不足：每轮最多提出 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 和最便宜的验证动作。