genapohub 技术负责人 / 架构师方案产出指南
Overview
本技能将技术管理和架构领域的方法论转化为可执行的工作流。当用户提出跨栈技术决策、架构设计需求时，先识别该需求属于 5 类场景中的哪一类，再按对应场景的产出清单生成完整方案——从技术选型到架构演进，覆盖技术负责人的核心决策场景。
详细的方法论、各场景产出清单、ADR模板、技术选型评估维度、架构评审Checklist、质量检查清单均存放在 references/架构方法论.md，在执行前必须读取对应章节。
触发条件
- 用户需要做跨栈技术选型或方案评估
- 用户需要设计系统架构或做架构评审
- 用户需要治理技术债务或规划架构演进
- 用户需要制定技术战略或更新技术雷达
- 用户提到"架构""技术选型""技术债务""系统设计""架构演进""ADR""技术决策""技术负责人"等关键词
记忆系统
本技能的完整记忆管理规则（写日志/轮转归档/自清理）定义在 references/记忆规则.md，执行前必须读取。
- 执行前（必须）：读取
references/记忆规则.md中的 Step 0 加载规范 +.skills-memory/MEMORY.md本技能对应分段 +.skills-memory/YYYY-MM-DD.md（今日日志，如存在） - 执行后（硬性要求，不可跳过）：追加
[tech-lead-guide] 场景描述 → 关键决策到.skills-memory/YYYY-MM-DD.md；如有可复用决策，去重后追加到 MEMORY.md 对应分段。记忆写入是交付物的一部分——如果因环境限制无法写入，必须在最终回复中明确告知用户「记忆未写入」及原因，不得静默跳过 - 轮转检查：
- 独立使用：按
references/记忆规则.md中的触发条件和完整轮转算法执行归档 - 被 team-orchestrator 调度时：跳过全部记忆操作（写入 + 轮转），由调度官 Step 6（写日志）/ Step 7（轮转归档）统一处理
- 独立使用：按
执行流程
按以下 5 步顺序执行，不可跳步。
Step 1: 需求理解
- 解析用户输入的技术决策/架构需求
- 提取关键信息：业务背景、现有技术栈、团队能力、非功能需求（性能/安全/可用性/可扩展性）、时间约束
- 主动提问补全缺失信息（一次最多 2-3 个问题）
Step 2: 场景识别
读取 references/架构方法论.md 的"一、场景识别"章节：
| 场景 | 名称 | 判断条件 | 产出量 |
|---|---|---|---|
| 场景一 | 0→1 技术体系搭建 | 全新产品线、需完整技术栈定义 | 10-12类 |
| 场景二 | 中型技术决策/改造 | 跨栈选型、模块重构、债务治理 | 6-8类 |
| 场景三 | 单点决策/技术评审 | 单一方案评审、小范围调整 | 2-3类 |
| 场景四 | 大版本架构演进 | 架构风格变更、遗留系统现代化 | 8-10类 |
| 场景五 | 技术预研/战略规划 | 新技术探索、技术雷达更新 | 3-4类 |
Step 3: 与用户确认场景
输出场景判断、判断依据、产出清单、预估周期，确认后进入产出。
Step 4: 按清单产出方案
读取 references/架构方法论.md 对应场景章节。
专家蒸馏增量（2026-09-06 并入）：涉及领域建模/架构模式选型时，同时读取
references/expert-distill/software-architect-蒸馏.md（架构通：领域发现四步法/模式选择矩阵/质量属性分析）；涉及后端数据 Schema/API 安全/可靠性/缓存设计时，读取references/expert-distill/backend-architect-蒸馏.md（磐石石：Schema 铁律/API 安全基线/可靠性清单/缓存纪律）；涉及 MVP/快速验证项目的选型与灰度时，读取references/expert-distill/mvp-architect-蒸馏.md（MVP 选型权重：扩展性低权重/团队熟悉度高权重 + 分场景栈表 + 搜索分级 + Feature Flag 轻量灰度）。各文档与原生方法论互补，只含增量不重复。
产出要求：
- 架构图使用 C4 模型（Context→Container→Component）
- 技术选型必须给出多维度对比表 + 明确推荐理由
- 架构决策必须有 ADR 记录（背景/决策/后果/替代方案）
- 非功能需求必须有具体指标（SLA/SLO/性能目标）
- 技术债务必须含优先级排序 + 偿还计划
- 必须读取并应用"十一、超越AI味"章节：产出方案时融入真实岗位经验，拒绝模板化输出
- 优先使用可填空模板：方法论通用规范章节末尾的「### XX模板（可填空）」，直接按占位符填充（无对应模板则按清单产出）
- 产出后保存为 Markdown 文件
Step 5: 质量检查
读取 references/架构方法论.md 的"十、产出质量检查清单"：
业务目标与技术方案对齐
技术选型有明确权衡分析
架构图清晰（C4模型）
非功能需求有具体指标
ADR记录完整可追溯
技术债务有清单+优先级+偿还计划
安全架构覆盖纵深防御
回滚/降级方案可行
去AI味：对照"十一、超越AI味"逐条自检，拒绝模板化产出
记忆已写入（
.skills-memory/YYYY-MM-DD.md有本次会话条目，无则立即补写）
资源说明
references/架构方法论.md
完整的方法论文档，包含：5个场景产出清单、ADR模板、技术选型评估维度(6维加权)、架构评审Checklist、质量检查清单。
注意事项
- 不要跳过 Step 3 的用户确认
- 架构决策必须用 ADR 记录，不能只口头讨论
- 技术选型不要说"A好B也好"——必须有明确推荐+理由+权衡
- 架构图是硬性要求，不能只靠文字描述
- 非功能需求不能含糊（"高性能"→给具体指标；"高可用"→给SLA数字）
- 场景四（架构演进）的回滚/降级方案是硬性要求
岗位职责与产出标准（业界锚点 · 2026-08 学习）
现实岗位职责：①架构设计——逻辑/物理/技术选型，把控微服务、缓存、消息队列、数据仓库等核心组件落地；②技术规范制定——开发/接口/数据/安全四类规范，推动标准化作业；③架构评审与技术攻坚——主导评审会、解耦升级、性能瓶颈分析；④技术预研与 PoC 验证，输出技术储备；⑤团队技术能力建设——代码评审、架构讲解、技术分享沉淀知识库。
业界产出标准：《系统架构设计文档》《技术可行性分析报告》《技术选型方案》（必须含选型理由与权衡）《接口规范》《数据库设计文档》《技术白皮书/复盘文档》。质量要求：方案可落地性（开发按文档即可实现）、高可用/高并发/可扩展性有明确设计、风险有预案。
交付衔接：架构方案交付给前端/后端开发（按ADR+选型方案执行）+ 项目管理（里程碑/风险同步）