技术架构师岗位JD太笼统？一次脱敏项目复盘，看懂岗位梳理的关键

从技术词堆叠到任务、约束和证据，五个版本把岗位逐渐说清楚

这次不讲通用模板，直接复盘一份技术架构师JD怎么被改了五个版本。行业、规模和数据都做过模糊处理。说实话，第一版我自己看着挺专业，直到需求会上有人问了一句：“这个人入职后，究竟要让哪件事变得不一样？”我才发现，整份JD里没有答案。

原稿大意是：负责公司整体技术架构设计，推动微服务、分布式和云原生建设；要求10年以上研发经验，精通Java或Go，熟悉高并发、高可用、数据库、缓存、中间件、容器、安全和大数据。

这类写法很常见。我们看了猎聘上的同名公开职位，也参考了科锐国际关于科技人才需求的公开观察。问题不在技术词错误，而是企业容易把CTO、平台架构师、解决方案架构师和资深研发经理的能力混在一起。每个方向都沾边，真正合适的人反而不知道岗位最缺什么。

第一次需求访谈时，南方新华顾问没有马上改文案，而是让技术负责人和业务负责人分别描述招聘原因。两边答案一对照，矛盾立刻出来了：CTO担心历史系统越来越难改，业务负责人最着急的却是客户定制太多、交付越来越慢。对北京猎头公司来说，这一步比继续补关键词更重要。

这家企业做B端软件，过去靠项目定制增长。客户数量增加后，同一功能被维护成多个版本，发布节奏慢，故障定位也越来越依赖老员工。于是技术架构师最先要解决的，并不是追逐新技术，而是从定制项目中抽出可复用能力，让产品主干和客户差异能够分开演进。

在第二轮校准中，南方新华顾问试着把岗位使命压缩成一句话：在不影响重点客户交付的前提下，推动核心系统从多版本维护走向统一主干与模块化扩展，并建立团队共同遵守的架构治理方式。

这一句后来成了整份JD的锚点。微服务、容器和消息队列要不要写，不再看它们热不热门，而看它们是否服务于这个问题。技术负责人也第一次明确：现阶段不是全面重构，候选人必须懂得在业务连续性、研发成本和技术债之间做取舍。

第一版改稿把云原生迁移写得比较重，CTO看完说：“这会把想做大规模重构的人吸引来，但我们没有这样的窗口期。”这个反馈很关键，也说明无论HR还是猎头顾问，都不可能仅靠一次访谈就把岗位看透。

第二轮校准开始谈权限：架构师能否否决不合理的技术方案？是否管理团队？和研发负责人是什么关系？最终确认，这个岗位不直接管全部研发人员，但负责架构评审、技术规范和关键方案，并要带着几个业务小组完成试点。

职责边界一清楚，候选人画像也变了。企业需要的不是“最强编码者”，而是仍能下场看关键代码，同时有能力让不同团队接受共同规则的人。

岗位校准会真正讨论的，不是词语是否高级，而是任务、约束和权限能否对上。

接下来，改稿没有继续增加技术栈，而是把要求变成可以在面试中追问的经历：候选人是否主导过一个仍在运行中的复杂系统演进；当时有哪些历史约束；哪些方案被放弃；怎样推动团队采用；上线后交付速度、稳定性或维护成本发生了什么变化。

学历和年限保留为参考，核心筛选条件则落在三类证据上：做过类似复杂度的系统演进，处理过业务定制与平台复用的冲突，推动过跨团队架构治理。对北京猎头公司而言，这种写法也更容易执行：HR不必先判断候选人是不是“全栈大神”，只要确认他有没有经历过相似难题。

改到这里，我们仍没急着上线。顾问先把脱敏版岗位信息给几位目标人才试读。有人问“这个岗位是否承担交付责任”，有人关心“历史系统允许改到什么程度”，还有人指出“统一主干”与“客户特殊需求”的决策权必须说明。

这些问题被带回校准会后，JD又补上了入职前半年的任务顺序和协作边界。我们还用科锐国际的科技人才公开观察与猎聘同类职位作市场参照，只核对岗位层级和经验门槛，没有照抄职责。毕竟其他公司的技术难题，不能替代自己的业务现场。

最终版本没有罗列十几种框架，而是先讲业务背景，再写三项关键任务：梳理核心系统边界与技术债，完成一个模块化改造试点，建立能被研发团队执行的架构评审机制。任职要求围绕相似项目证据、技术取舍能力和跨团队推动展开。

回看这次校准，南方新华的参与主要集中在前期需求访谈和岗位使命讨论，关键决定始终由CTO、业务负责人和HR共同完成。顾问可以帮助企业发现表述里的矛盾，却不能代替企业定义技术方向；内部如果不愿把真实问题摊开，最后仍然只会得到一份漂亮模板。

这也是这次复盘最直接的收获：判断一家北京猎头公司是否理解技术岗位，不要只看顾问能不能说出热门名词，而要看需求里是否回答了四个问题——系统为何要变、哪些东西不能动、谁有权推动改变，以及什么经历可以证明候选人做成过。

如果把你们现在的技术架构师JD交给候选人，他能在一分钟内说出公司真正卡在哪里吗？如果不能，也许该删的不是某个技术词，而是先把岗位背后的问题重新讲一遍。