用途：在写代码过程中应用两个可复用的架构视角，分别用于做决策和审查耦合。核心原则是：一切都是权衡，为什么比怎么做更重要；若分析只剩一个显然正确的选项且没有代价，说明分析尚未完成。该技能作用于代码层面，区别于服务拆分、数据归属等更高层架构话题。
两个镜头： 1）决策/权衡镜头：当你需要在方案、边界、库、同步与异步、单体与拆分、自建与复用之间选择时使用。步骤是：先指出真正在权衡的 2–4 个架构特性（如性能、可扩展性、可测试性、可维护性、容错、简单性、可部署性、安全、可演进性）；列出至少两个真实选项，通常包含“什么都不做/保持现状”；对每个选项明确写出得到什么、放弃什么，强制暴露成本；最后依据第一步的特性做决定，并用一句话说明理由，理由本身才是交付物。注意避免反复重议同一决策、为免责而决策、决策只留在聊天或邮件里等反模式。若决策在架构上重要（影响结构、横切特性、依赖或接口，难以回退，或可能被反复争论），可提供 ADR；若决策编码了未来代码可能违反的规则，可建议用适应度函数（lint 规则、架构测试、CI 检查）自动守护。 2）耦合/Connascence 镜头：用于评估既有代码，如重构、评审、感觉“缠在一起”、决定抽取或合并时。Connascence 指两处代码中改一处就必须改另一处才能保持正确。用三个维度排序：强度（静态弱于动态）、局部性（距离越远越糟）、度数（涉及元素数量）。规则是：两个元素距离越远，它们之间的 connascence 应越弱；强耦合在局部可以接受，在远处则危险。审查流程：识别耦合元素并命名 connascence 类型（名称、类型、含义/约定、位置、算法、执行顺序、时机、值、身份）；按强度×局部性×度数判断，局部且静态通常可保留，远距离且动态应标记；对值得修复的项给出具体弱化方案，例如魔法值改为具名常量（含义→名称）；不要过度重构，消除所有耦合不可能，追求它会制造间接层，只弱化强、远、高度数的情形；同时检查内聚性，低内聚加高耦合是拆分或重组的信号。
使用方式：按当下情境选择镜头，两者可组合；当决策涉及降低耦合（如“是否拆分这个模块”）时同时使用。输出风格要求具体简短，点明特性或 connascence 类型，说明权衡或补救措施即可；始终至少给出一个成本或反方观点，绝不把选择说成免费；投入与风险匹配，小决策用两行权衡说明，只有重要决策才做完整分析、ADR 或适应度函数。参考文件按需加载，需要分类法、特性清单或模板时再读取，不要预先加载。
限制：资料未提供安装命令、平台支持、收费方式或具体运行环境；参考文件（architecture-characteristics.md、adr-template.md、fitness-functions.md、connascence.md）的具体内容暂未提供。