Harness实践 ，开发应该多向运维同学学习

在网易云音乐做技术管理的十年我始终有一个观点运维的技术路径比开发快半拍。不是说运维技术更强而是运维面对的问题更纯粹——对面坐着的是机器不是业务。机器没有情绪不会改需求不会今天说高可用明天说先跑通再说。正因为如此运维更早被逼着把问题想清楚怎么描述一个系统的状态怎么让变更可追溯怎么让一个新人接手不靠口传心授这些问题开发也有只是业务的噪音把它们遮住了让大家觉得能跑就行是个合理答案。大道至简运维走过的那条路开发迟早要走。不是因为谁规定了而是软件活得够久之后那些被遮住的问题会一个一个冒出来为什么新人上手要三个月为什么改一个字段要开半天会为什么 AI 生成的代码采纳率只有百分之十几我们今天讲 Harness Engineering提了不少听起来很新的概念——但有时候回头一看答案也许早就写在别人的笔记本上了。01当 k8s 重新定义运维之后k8s 出现之前运维靠的是手艺。服务怎么部署、怎么扩容、故障了怎么恢复这些东西散在每个运维的脑子里、Shell 脚本里、还有那些没人敢动的 wiki 里。人越老越是座孤岛离职了就带走一切。这个问题 Google 碰得更早。2003 年他们内部跑着 Borg论文里那句话我一直觉得是整件事的核心用户用声明式配置语言向 Borg 描述任务。不是告诉它执行第一步第二步而是告诉它我要的最终状态是什么让机器自己负责抵达。k8s 后来把这个思路带出了 Google变成了整个行业的基础设施语言。但这里有个问题值得停下来想想为什么是DSL不是程序也不是自然语言用程序当然可以Pulumi、CDK 就是这么做的。但程序描述的是过程不是状态。你写创建一个 3 副本的 Deployment代码里一定会混进异常处理、顺序依赖、各种副作用。系统最后跑成什么样得把代码在脑子里跑一遍才知道。而且程序没有静止形态它是活的复杂度没有边界Review 从哪里切都不对。Google Cloud 2020 年有篇文章《Understanding Configuration as Data in Kubernetes》说得很直接IaC 虽然被广泛采用但有个根本缺陷——代码在开发者意图和运行时行为之间建立不了契约。意图藏在执行逻辑里没有一个能被单独审查的表达层。用自然语言呢问题反过来了——表达力太强强到可以轻松说出那些荒谬性不显而易见的话。“部署一个高可用的服务”每个人读完都点头但副本数是几跨几个可用区节点挂了怎么办歧义不报错只在生产事故里现身。Dijkstra 1978 年说过这句话拿到今天的 AI Prompt 工程里还是一记响亮的耳光。DSL 站在两者中间各取所需。像程序一样精确模糊就是编译错误像自然语言一样可读不用理解执行流程就能看懂意图。更关键的是DSL 描述的是想要什么不是怎么做到——这是人和机器之间最干净的契约层。以 k8s 最常见的场景为例部署一个用户服务apiVersion: apps/v1 kind: Deployment metadata: name: user-service spec: replicas: 3 # 我要 3 个副本 selector: matchLabels: app: user-service template: spec: containers: - name: user-service image: user-service:1.2 resources: requests: memory: 256Mi cpu: 250m limits: memory: 512Mi没有先拉镜像再启容器再注册负载均衡。你只是描述了终态k8s 自己负责抵达并维持它。任何人读这份 YAML不需要理解执行流程就知道这个服务长什么样。k8s 的 YAML 能成为云原生的通用语言不是因为 YAML 格式多优雅——批评它的人多了去了——而是背后那个设计决策在正确的抽象层上用正确的表达介质。02Spec Coding 说对了方向但停在了半途后端研发正站在十年前运维站过的那个路口。行业现在有个共识叫Spec Coding。先写 Spec再让 AI 生成代码用 Spec 约束 AI 的边界把 Spec 当需求和实现之间的桥梁。方向是对的但大多数团队卡在了一个尴尬的地方Spec 本身没被认真对待。今天大多数团队的 Spec本质上是加了点结构感的自然语言。写在 Markdown 里、Notion 里、飞书里格式挺整齐但机器没法校验歧义还在跟代码之间没有任何强绑定。项目启动那天是准的三个月后开始漂移六个月后成了历史文献。这和 Google Cloud 批评 IaC 的问题一模一样意图和运行时行为之间没有契约。更根本的问题是自然语言 Spec 没法被引擎驱动。只能喂给 AI然后祈祷它理解正确。没法生成确定性的结构没法校验和代码是否一致没法在字段变更时自动追踪影响范围。AI 很擅长 Programming写出能跑的代码。但在没有约束的情况下持续做 Software Engineering它做不好。Google 在《Software Engineering at Google》里说的那句话我觉得是整件事的核心一个系统真正的成本不在写下它那一刻而在它存活的每一天。Spec Coding 的思路是对的但它需要一个前提Spec本身必须是形式化的。运维领域喊了很多年Infrastructure as Code真正让这口号落地的不是更好的文档规范是声明式 DSL——机器可解析、可校验、可驱动的表达介质。后端研发需要的是同样意义上的一次形式化跃迁。03DSL-SPEC后端研发的表达归宿同样的场景换到后端。“查询用户详情包含所属公司信息”这需求再普通不过。写进自然语言 Spec每个人都读得懂但 DTO 怎么组织、关联关系怎么处理、Converter 和 Assembler 谁来写全靠 AI 自由发挥也全靠 Review 兜底。用 DSL-SPEC 描述它长这样entity user { Long id 主键 PK String name 姓名 Long company_id 所属公司 FK Date created_at 创建时间 } entity company { Long id 主键 PK String name 公司名称 String location 地址 } entity project { Long id 主键 PK String name 项目名称 String status 状态 (ACTIVE / DONE) Long user_id 所属用户 FK Date started_at 开始时间 } dto user_with_company_dto { fromEntity: user expandList: [ { foreignKey: company_id # 通过外键正向扩展 field: company dto: company_base_dto # 嵌入公司基本信息 }, { foreignKey: user_id # 反向扩展一个用户对应多个项目 field: projects dto: project_base_dto } ] } readPlan searchUserList { return: user_with_company_dto pagination: true orderBy: created_at DESC query: company.name like #companyNameLike # 按公司名模糊搜索跨表访问无需手写 join AND created_at #createdFrom # 注册时间范围 AND created_at #createdTo AND projects contains (status ACTIVE) # 至少参与一个进行中的项目 filter projects: # 返回的项目列表只保留进行中的 status ACTIVE }不需要写 Converter、DataAssembler、Manager 接口、SQL 关联查询。只是描述了数据的意图——我要一个用户 DTO嵌套公司信息通过 company_id 关联。引擎自己生成所有结构性代码。两者的设计哲学是同一枚硬币k8s YAMLTocoAI DSL-SPEC描述的是服务的终态数据结构的意图机器做的是调度、维持状态生成结构性代码人不需要关心如何部署、扩容如何写 Converter、Assembler歧义处理格式错误即报错结构冲突即校验失败变更成本改 replicas 值其余不动改一个字段级联自动更新太阳底下没有新鲜事。UML 当年想做的事本质上和这个是一回事——对业务的高程度抽象。它的思路没问题但那个时代的环境不支持它落地没有 AI抽象和代码之间的鸿沟还得靠人填需求一变大家先改代码UML 就落后了。就像 2005 年你想做个性化歌单没有机器学习协同过滤歌单只会比榜单传播效率更差。不是想法不对是环境没到。AI 时代到来让这件事第一次真正有了落地的土壤。我们不过是在用 AI-native 的方式重新做一遍 UML 想做但没做成的事。DSL-SPEC 不是另一种需求文档也不是 prompt 模板。它是系统唯一的真相来源——人类可读机器可解析引擎可驱动。Spec和代码的关系永远是不是≈。04能 DSL 化的就尽量 DSL 化当然研发没有运维那么纯粹。不是所有东西都能 DSL 化。强行 DSL 化的尽头是造出另一门编程语言那就走回头路了。但在能 DSL 化的部分就应该尽量 DSL 化。我深深认为以后的 Spec Coding 一定是这样一个结构DSL-Spec 为骨骼NLP-Spec 为血肉。骨骼决定系统不会塌血肉负责填满那些只能意会的业务细节。两者各归其位才是真正的系统维护之道。运维同学花了十年才等来 k8s。我们不用等那么久了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】