做系统架构决策时用：在AI能写代码的时代，用领域建模…

当讨论涉及系统设计、技术选型、跨组件/跨团队集成、破坏性变更、合规或AI工具评估时，用一套以「忠诚度」为基础的五支柱架构思维流程来避免做出无法交付的「完美」方案。

适用场景

解决思路

1. 开场声明：'I'm using the Human Architect Mindset skill to guide you through systematic architectural thinking.'
2. 在任何架构变更前先问自己：'Am I optimizing, or am I betraying?'——区分是在既有承诺约束内优化，还是为微小收益破坏承诺
3. 把「忠诚度」作为基础：坚持已选模式（不因新框架流行就抛弃架构）、遵守契约（保持API兼容、尊重废弃时间线、不为内部便利破坏下游）、把决策做到底（遇到困难不轻易转向，承认所有架构都有问题，忠诚就是解决它们）、为全局一致性接受局部次优
4. Phase 1 领域发现：先问领域而非技术，识别领域专有词汇，暴露隐藏复杂度和边界情况，弄清真实用户是谁；关键问题包括'我们实际在解决什么问题？''谁在乎它能不能用？''这个领域独特在哪？''在[X]边界情况下会发生什么？'；产出是领域模型
5. Phase 2 系统分析：映射所有组件及依赖，识别外部依赖（供应商、API、服务），追踪失败路径（什么坏了会导致什么坏），找出监控和告警缺口；关键问题包括'这依赖哪些外部系统？''[组件]失败时会怎样？''它坏了谁会被通知？''最近有什么我们无法控制的变化？'；产出是带依赖图和失败模式的系统图
6. Phase 3 约束映射：在提方案前先暴露所有约束——技术约束（哪些不能改）、组织约束（谁必须批准）、业务约束（预算、时间线、合规）、政治约束（谁有权、谁有上下文）；关键问题包括'必须集成哪些遗留系统？''谁需要签字？''预算约束是什么？''适用哪些合规要求？''即使错了也不能改的是什么？'；产出是约束矩阵（固定 vs 灵活）
7. Phase 4 AI分解规划：识别离散有界任务，为每个任务定义输入/输出契约，建立验证点，为需要判断的地方规划人工检查点；关键问题包括'这个任务能独立验证吗？''AI有全部所需上下文吗？''这个块失败会怎样？''人类判断在哪里重新介入？'；产出是边界清晰的任务分解
8. Phase 5 方案综合：生成符合约束的选项，对照系统关注点评估，对照领域需求验证，明确呈现权衡；关键问题包括'这真的解决了领域问题吗？''它如何失败？恢复方式是什么？''它符合我们的约束吗？''我们在权衡什么？'；产出是带明确权衡的推荐方案
9. 设计AI任务边界时确保四点：清晰的输入/输出契约（无成功标准歧义）、有界上下文（AI拥有全部必要信息、无需猜测缺失上下文、自包含可验证）、结果可验证（人能检查、测试能验证、错误可检测）、失败隔离（一个块失败不级联、可重试或回退、不污染共享状态）；避免'Make it better''Fix the bugs''Refactor the system'这类无界任务，改用'把这个函数从回调改成async/await''给这3个API调用加网络失败错误处理''根据这些示例为这个纯函数写单元测试'
10. 在AI解决各个块后，必须有人验证每个块确实可用、把块集成起来、处理块之间的缝隙、确保整体一致性
11. 评估AI-first开发：技术发现（Rust/WASM能否提升关键路径性能、多智能体编排如claude-flow能否简化工作流、是否需要跨会话持久记忆如agentdb、向量搜索/RAG如ruvector能否增强体验）；边缘AI（边缘LLM能否本地处理以降低延迟/成本、哪些功能应离线可用、敏感数据是否应留在设备上、混合架构是否可行）；智能体模式（是否适合agentic工作流、Claude Agent SDK能否构建可复用agent、哪些MCP集成有帮助、应并行还是串行spawn agent）；自学习能力（能否从用户行为学习、什么反馈回路能让它越用越聪明、在哪里捕获隐式信号如编辑/时间/接受、A/B实验能否优化AI行为）；项目文档（是否创建项目专属SKILLS.md、哪些架构决策应记录供AI上下文、如何确保跨会话行为一致）；面向用户的技能（解释技能帮用户理解复杂AI输出、行动技能把建议转为下一步、转换技能转成不同格式、验证技能帮用户核实AI声明、学习技能教用户获得更好结果、领域技能如/legal-review、/code-refactor）；持续验证（哪些自动化测试验证每个功能、如何确保每次提交通过所有测试、部署后测试失败的回滚策略、是否实现pre-commit hooks或watch mode测试）
12. 评估工具时参考：性能用Rust/WASM（CPU密集、延迟关键路径）；多智能体用claude-flow（复杂工作流、并行任务）；持久化用agentdb（agent状态、跨会话记忆）；向量搜索用ruvector/pgvector（RAG、语义搜索、嵌入）；边缘LLM用Phi-3/Gemma 2B/TinyLlama（设备端、离线、隐私敏感）；浏览器AI用WebLLM/Transformers.js/ONNX（浏览器内推理、低延迟）；Agent SDK用Claude Agent SDK（自定义agent、工具使用、MCP）
13. 自学习模式参考：反馈回路（收集用户纠正，随时间提升准确率）；偏好学习（追踪选择并应用模式，无需配置的个性化）；错误纠正（把错误反馈回去，减少重复错误）；领域适应（在用法上微调，专精词汇）；A/B实验（测试变体，优化提示/行为）；隐式信号（编辑、时间、接受，静默推断满意度）
14. 在项目根目录创建SKILLS.md：记录应用专属模式供AI上下文、捕获领域词汇和约束、定义项目专属触发词、记录架构决策、加速人类和AI的上手、跨会话保持一致行为
15. 规划持续验证架构：pre-commit hooks（提交前跑受影响测试）、watch mode（开发中持续测试）、回归套件（每功能测试覆盖）、集成测试（API契约验证）、视觉回归（UI一致性检查）、回滚触发器（测试失败自动回滚）
16. 避免常见错误：不要跳到技术方案（先完成Phase 1领域发现再谈技术）；不要忽略约束（在Phase 3先映射约束再提方案，能交付的70%方案胜过不能交付的完美方案）；不要漏掉外部依赖（在Phase 2映射所有外部依赖，问'如果供应商明天改API怎么办？'）；不要给无界AI任务（定义清晰输入/输出契约，每个AI任务都要有可验证的成功标准）；不要没有人工检查点（在AI块之间插入人工检查点，验证后再继续）；不要忽略政治（明确询问团队边界、审批链、谁有权谁有上下文）；不要过早优化（问'我们实际是什么规模？12个月后需要什么规模？'按那个设计，而不是假设的百万级）
17. 记住人类独有的决策：决定构建什么（产品愿景、战略）、理解它是否解决问题（领域专长）、驾驭公司现实（政治、审批、关系）、防止系统崩溃（跨边界系统思维）、做价值判断（权衡、优先级、伦理）、维持非理性忠诚（即使'优化'也坚持的承诺）
18. 与AI助手协作时建立操作层面的忠诚：让AI优先考虑你声明的架构（推荐符合你已选模式的方案而非通用最佳实践、标记会破坏你架构承诺的建议、尊重你的技术债偿还优先级）；保护你的承诺（建议破坏API契约的变更前先警告、突出'优化'会背叛既有决策的地方、问'你承诺了X，这会改变它，继续吗？'）；在上下文内记忆（对话内保持一致、引用早先决策、不与你已建立的指导矛盾）；同时承认AI不能跨会话记忆、不能绕过安全约束、不能永久承诺
19. 操作化AI忠诚：把架构决策写进AI能读的文件（CLAUDE.md、ARCHITECTURE.md）；会话开始时重申关键承诺（如'我们用React不用Vue，保持向后兼容，无理由不加依赖'）；挑战AI建议时问'这尊重我们既有的架构承诺吗？'；指示AI'在建议破坏既有模式的变更前，明确标记出来'
20. 应用SDD（Spec Driven Development）三阶段：Phase 1 CONSTITUTION（人类定义不可破坏的规则，用类型层/编译期、Schema/运行时校验、测试/CI门禁、文档/人工审查四层强制，包含技术栈锁定版本、目录结构、命名约定、编码标准、反模式、安全要求、性能预算、测试要求）；Phase 2 BLUEPRINT（人类批准架构，五级规格层级：Constitution不可变规则→Functional Specs做什么→Technical Specs怎么做→Task Specs原子工作单元→Context Files实时项目状态；功能规格含用户故事和验收标准、带唯一ID的需求、边界情况和错误状态、带指标的非功能需求；技术规格含架构图、精确字段类型的数据模型、API契约、组件契约；任务规格含原子工作单元、input_context_files、definition_of_done精确签名、依赖、验证命令）；Phase 3 SUPERHUMAN（AI以机器精度执行，追求命名零冲突、100%分支覆盖、结构刚性、每个函数链接需求ID、每个公共接口完整文档、每个失败模式显式处理）
21. 维护可追溯链：INT-AUTH-01（意图）→REQ-AUTH-001（需求）→TASK-AUTH-003（任务）→src/services/auth.ts:42（代码）→TC-AUTH-003（测试），每行代码都能追溯回人类意图
22. 按角色清晰矩阵分工：人类负责定义成功标准、定义不可破坏规则、做权衡决策、驾驭组织约束、验证质量标准、审查和接受交付物；AI负责生成任务规格、执行原子任务、达到100%测试覆盖、维护可追溯性
23. 在合适时应用SDD：绿地系统且需求清晰、重构且质量标准必须提升、与需要机器可解析规格的AI agent协作、质量不可妥协（受监管行业、安全关键）；不要强行用于探索和原型（Constitution太早）、需求确实不清（Blueprint不可能）、单人小项目（开销超过收益）

适用边界 · 注意事项

• 探索和原型阶段不要过早套用SDD的Constitution
• 需求确实不清晰时不要强行做Blueprint
• 单人小项目不要用SDD，开销超过收益
• 不要在没有完成Phase 1领域发现前就跳到技术方案讨论