ttttstc 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，逐项判断下列信息是否足以支撑首层决策：
- 目标、用户价值和成功标准；
- 范围、当前状态和明确非目标；
- 硬约束；
- 3–5 个候选业务或质量属性驱动力；
- 数据分类、所有权、安全与信任边界；
- 团队、时间、预算和运维能力；
- 验收标准。
缺失信息只有在可能改变首层决策时才构成阻塞。非阻塞 Unknown 记录后继续，不追求信息完美。
在已授权项目内主动获取
答案可从已授权项目中发现时，主动做最小只读检查：先看架构文档、项目入口、模块边界、配置和部署描述，再按证据缺口缩小范围。不得为了“熟悉项目”无边界扫描。
超出已授权范围的调研确认门禁
需要访问已授权范围之外的资料时，必须先输出调研提案并停止。提案必须说明：
- 哪个首层决策缺少证据；
- 准备获取什么信息、从哪里获取；
- 调研范围与明确不做的内容；
- 预期关闭哪些 Unknown；
- 是否涉及外部访问、敏感数据、额外成本或账号权限；
- 确认问题：
是否授权我按以上范围开始调研？
用户明确确认前，不得访问新来源、启动调研工具或输出正式架构方案。
访谈门禁
项目证据仍不足时，只问会改变高价值决策的问题：
- 每轮最多 3 个问题；
- 先问影响最大且无法从项目发现的问题；
- 说明答案会改变哪类决策；
- 不询问可安全延迟到详细设计的问题。
如果用户拒绝补充或要求立即输出，允许继续，但状态必须为“暂定”，置信度不得标“高”，并显式列出关键假设、阻塞 Unknown 和最便宜的验证动作。
第三步：从第一性原则推导
读取 references/methodology.md，按顺序完成：
- 把业务目标转为 3–5 个有优先级的架构驱动力；
- 把模糊质量要求转为可观察、可测量的场景；
- 找出核心业务能力、系统边界、数据所有权、信任边界和团队所有权；
- 列出候选决策，并分类为
现在决定、现在只定边界、明确延迟； - 只保留 3–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 图代替决策理由；
- 为低概率变化购买昂贵的可选性；
- 忽略团队认知负载和运维能力；
- 用“大而全”掩盖关键证据不足；
- 以“最佳实践”代替当前约束下的权衡。