AI编码进化三级跳，企业级系统落地实战

AI 编码驱动企业级系统转型 — AI 编码从个人效率工具走向企业级系统落地，中间隔着一整套工程化约束

"Vibe Coding"火了。用一句自然语言描述需求，AI 几秒钟生成可运行代码，开发者凭"感觉"调整几下就能跑。在 hackathon、个人项目、快速原型场景下，这种体验确实令人兴奋。但当 Vibe Coding 撞上企业级系统--日均亿级请求的交易平台、几十个微服务咬合的订单系统、监管合规要求严苛的金融核心--"凭感觉"就不灵了。

AI 编码工具正在经历一次角色进化：从 Vibe Coding（凭感觉编码）到 Vibe Coding Engineer（驾驭 AI 的工程师），再到 Harness Engineer（构建 AI 编码约束框架的工程师）。这三段进化不是营销概念，而是开发者面对真实系统复杂度时被倒逼出来的能力跃迁。本文拆解进化的本质，并给出企业级复杂系统中的落地路径：领域建模如何与 AI 协作、微服务怎么拆才不拆出一地鸡毛、三高架构怎么落地、业务多变下如何安全重构，以及工程师如何在 AI 编码时代守住不可替代的价值。

一、AI 编码的三段进化

理解这三段进化，关键不是记住三个名词，而是看清楚每一阶段解决的是什么问题、又把什么问题留给了下一阶段。

Vibe Coding：快，但有代价

自然语言即指令，AI 即 coder。开发者描述需求，AI 生成代码，人做微调。核心特征是"快"--从想法到可运行代码的链路被压缩到分钟级。但快是有代价的：AI 生成的代码缺乏架构意识，没有领域语义，技术债以肉眼可见的速度积累。Vibe Coding 适合 demo、POC、个人工具，一旦系统复杂度上升，"凭感觉"就会变成"凭运气"。

Vibe Coding Engineer：驾驭而非微调

工程师不再满足于微调 AI 产出，而是系统化地驾驭 AI。任务分解、上下文提供、prompt 设计、产出验证--工程师的编码经验通过这些手段被 AI 放大。一个资深工程师配上 AI，产出可以抵过去一个小团队。但这个阶段有个隐性天花板：系统设计、架构决策、领域建模仍然是人的责任，AI 只放大了执行效率，没有改变"人定方向、AI 写代码"的分工。

Harness Engineer：约束即安全

当 AI 编码进入企业级系统，最大的风险不是 AI 写错代码，而是 AI 在没有约束的情况下"自由发挥"。Harness Engineer 的核心工作是构建"驾驭框架"（harness）--一套让 AI 在企业约束下安全工作的体系：架构守护规则、代码规范门禁、测试覆盖要求、上下文工程、评估反馈闭环。工程师从"写代码"转向"定义 AI 编码的边界和验证标准"。

维度	Vibe Coding	Vibe Coding Engineer	Harness Engineer
关注点	代码生成速度	任务分解与上下文	约束框架与验证
人的角色	微调者	驾驭者	架构守护者
质量保障	靠感觉	人工 review	自动化门禁
技术债	快速积累	可控	系统性治理
适用场景	原型 / Demo	功能开发	企业级系统

关键洞察：三段进化不是替代关系，而是叠加关系。企业团队里会同时存在三种模式--原型阶段用 Vibe Coding，功能开发用 Vibe Coding Engineer 模式，核心系统治理靠 Harness Engineer。问题不在于用哪种，而在于知道什么时候该用哪种。

二、企业级系统的真实门槛

AI 编码工具能写出漂亮的 CRUD，能实现复杂算法，甚至能生成微服务脚手架。但企业级系统有一道隐形门槛，AI 目前跨不过去。这道门槛不是"AI 不会写某种代码"，而是"AI 不理解代码运行在生产环境时会面对什么"。

高并发的隐性约束

AI 能写一个查询接口，但不会主动考虑缓存穿透、热点 key 击穿、数据库连接池耗尽。这些是生产事故的源头，不会出现在 AI 的代码里，只会出现在凌晨的告警里。

高可用的故障思维

AI 不理解跨可用区部署、故障转移链路、降级策略。它生成的代码在"正常路径"上完美，在"异常路径"上空白--而生产环境恰恰是异常路径的主场。

领域语义的缺失

AI 生成的代码习惯用 data、info、record 这类通用命名，缺乏领域语言。长期积累下来，代码库会失去可读性，变成"能跑但没人懂"的遗留系统。

服务边界的无视

AI 倾向于"能实现就行"，不尊重微服务边界和数据所有权。一个 AI 生成的跨服务直接数据库访问，就能毁掉微服务拆分的全部意义。

重构影响面的盲区

AI 能改代码，但不理解一个变更在分布式系统中的连锁反应。没有影响面分析的重构，本质上是在生产环境赌博。

合规与安全的真空

AI 不会主动考虑数据脱敏、审计日志、权限隔离。在金融、医疗等强监管行业，一个遗漏的合规检查就是合规事故。

这些门槛的共同特征是：它们都是运行时约束，不是代码本身的语法问题。AI 在"写代码"这件事上已经很强，但在"理解代码在系统中意味着什么"这件事上还很弱。这正是 Harness Engineer 要填补的缺口。接下来的章节，逐一拆解这些门槛如何在工程化路径中被跨越。

三、领域模型与 AI 的协作建模

领域驱动设计（DDD）在 AI 时代不是过时了，而是更重要了。原因很简单：领域模型是人类对业务的结构化理解，是 AI 无法替代的"系统上下文"。AI 可以辅助建模，但业务语义的最终判断权在人。没有领域模型，AI 生成的代码就是无根之木--功能能跑，但语义混乱，重构时谁都不敢动。

3.1 协作建模的四步路径

PHASE 1

领域事件梳理

人与 AI 共同做事件风暴。人提供业务知识，AI 辅助识别事件间的因果关系、补全遗漏的命令与聚合候选。

PHASE 2

限界上下文识别

AI 分析现有代码的模块依赖与数据库表共享情况，辅助识别上下文边界。最终边界需人结合组织结构（康威定律）拍板。

PHASE 3

聚合与不变量设计

AI 生成聚合根、值对象、领域事件的代码骨架，人校验不变量约束--订单金额不能为负、库存不能超卖、状态机流转合法。

PHASE 4

上下文映射与集成

AI 辅助绘制上下文关系：合作关系、共享内核、客户-供应商、防腐层。确定集成方式与数据同步策略。

3.2 AI 生成领域代码的校验机制

AI 生成领域模型代码时，最容易出问题的是不变量被遗漏。一个没有不变量守护的聚合，等于没有领域模型。Harness Engineer 要做的，是把不变量变成可执行的断言：

// 聚合根不变量：订单金额不可为负，库存不可超卖
class Order:
  def add_item(self, product, qty):
    // 不变量 1：商品必须有效
    assert product.is_active, "商品已下架"
    // 不变量 2：数量必须为正
    assert qty > 0, "数量必须大于零"
    // 不变量 3：库存充足（跨聚合校验走领域服务）
    assert inventory.available(product.id) >= qty
    line = OrderLine(product.id, product.price, qty)
    self._lines.append(line)
    // 不变量 4：订单总金额同步更新
    self._recalculate_total()
    assert self.total_amount >= 0

  def pay(self):
    // 状态机不变量：只有待支付状态才能支付
    assert self.status == PENDING, "订单状态不允许支付"
    self.status = PAID
    DomainEvents.publish(OrderPaid(self.id, self.total_amount))

实践要点：不变量断言不是可选的"防御性编程"，而是领域模型的 executable specification。Harness Engineer 的职责之一，就是确保 AI 生成的每一段领域代码都带有可验证的不变量。没有断言的 PR，门禁直接打回。

四、微服务拆分的工程化决策

微服务拆分是企业级系统最容易"拆出一地鸡毛"的环节。拆得太细，分布式复杂性吃掉所有收益；拆得太粗，等于没拆。AI 能帮你生成微服务代码，但"怎么拆"这个问题，需要工程化的决策框架。

4.1 三条拆分原则

原则	核心问题	AI 能做什么	人必须做什么
业务能力对齐	服务边界是否对应一个完整的业务能力？	分析代码调用链，聚类功能模块	判断业务能力的粒度与独立性
数据所有权	每张表是否只被一个服务拥有？	扫描跨服务数据访问，标记违规	决定数据归属与迁移方案
团队边界（康威定律）	服务边界是否匹配团队组织结构？	分析代码提交者的团队分布	根据团队重组调整服务边界

4.2 拆分粒度的权衡

一个常见误区是"按技术层拆"（一个服务管缓存、一个管数据库、一个管业务逻辑）。这种拆法会把一个业务功能散到三个服务，每次需求变更都要跨三个服务协调，得不偿失。正确的拆法是"按业务能力拆"--订单服务拥有订单的全部数据和行为，支付服务拥有支付的全部数据和行为，两者通过明确的接口通信。

单体内聚

先在单体内做好模块化，领域边界清晰，数据访问收口。不急于物理拆分。

按能力拆分

业务能力边界稳定后，按限界上下文做物理拆分。每个服务独立部署、独立数据库。

按需细化

只有当某个服务成为瓶颈或团队规模过大时，才进一步拆分。避免过早拆细。

4.3 服务通信与数据一致性

拆分之后，跨服务的数据一致性是企业级系统最头疼的问题。分布式事务（2PC）在微服务下基本不可行，工程上普遍采用 Saga 模式和 Outbox 模式：

模式	原理	适用场景	风险
Saga（编排式）	协调器按顺序调用各服务，失败时执行补偿	流程明确、步骤较少的跨服务流程	协调器单点；补偿逻辑复杂
Saga（协同式）	各服务监听事件自行决定下一步，无中心协调器	步骤多、参与方多的松耦合流程	流程难追踪；调试困难
Outbox 模式	业务写库时同事务写消息表，异步投递到消息队列	保证业务数据与消息可靠投递	需保证幂等消费；消息顺序

// Outbox 模式：业务操作与消息写入同一事务
@Transactional
def create_order(order_data):
    // 1. 写业务数据
    order = order_repo.save(Order(order_data))
    // 2. 同事务写 Outbox 消息（不是直接发 MQ）
    outbox_repo.save(OutboxMessage(
        event="OrderCreated",
        payload=order.to_dict()
    ))
    // 事务提交后，后台轮询 Outbox 投递到 MQ
    // 保证：业务成功则消息一定发出，业务失败则消息不发

AI 可以生成 Saga 补偿逻辑和 Outbox 投递器的代码骨架，但补偿动作的业务正确性（比如"退款补偿是否要扣除手续费"）只能由人判断。这是 Harness Engineer 必须把关的环节。

五、三高系统的架构落地

高并发高可用高性能系统架构 — 三高系统的核心不是某个技术点，而是一套从入口到存储的纵深防御体系

高并发、高可用、高性能（三高）是企业级系统的基本功。AI 能写出每个技术组件的代码，但三高的难点在于"组合"--缓存、限流、降级、熔断、多活这些手段怎么协同，才是架构能力的体现。

5.1 高并发：让流量层层衰减

高并发的核心思想是"让流量在到达数据库之前层层衰减"。CDN 挡住静态资源，网关限流挡住异常流量，缓存挡住读请求，消息队列削峰填谷挡住写峰值，最后到数据库的流量只剩真正需要持久化的部分。

层级	手段	目标	AI 辅助
接入层	CDN、DNS 轮询、网关限流	挡住静态资源与异常流量	生成限流配置（令牌桶参数）
应用层	多级缓存、本地缓存 + 分布式缓存	读请求不到数据库	生成缓存读写策略代码
服务层	异步化、消息队列削峰	写请求平滑化	生成异步任务骨架
数据层	读写分离、分库分表	分散数据库压力	生成分片路由逻辑

避坑：AI 生成缓存代码时，最容易遗漏三个问题--缓存穿透（查不存在的 key 直接打到 DB）、缓存击穿（热点 key 过期瞬间大量请求穿透）、缓存雪崩（大量 key 同时过期）。三个问题必须有对应防护：空值缓存 + 布隆过滤器、互斥锁、过期时间随机化。门禁里要检查缓存代码是否包含这三项防护。

5.2 高可用：假设一切都会失败

高可用的设计原则只有一条：假设每一个组件都会失败，然后设计让系统在组件失败时仍然可用。这包括跨可用区部署消除单机房故障、健康检查与自动故障转移、降级策略保证核心链路、熔断器防止级联失败、混沌工程主动验证容错能力。

部署层

多可用区部署：服务至少跨 2 个可用区，数据库主从跨可用区同步。无状态化：服务不持有会话状态，任意实例可替换

流量层

健康检查：主动探活，失败实例自动摘除。熔断器：下游错误率超阈值时自动熔断，快速失败而非等待超时

业务层

降级策略：非核心功能可关闭（如推荐、评论），保核心链路（下单、支付）。兜底数据：缓存失败时返回默认值或上次成功结果

验证层

混沌工程：主动注入故障（杀实例、断网、延迟），验证系统容错能力是否真的有效，而不是纸上的设计

5.3 高性能：用数据驱动优化

高性能不是"感觉慢就优化"，而是用数据驱动：定义性能预算（P99 延迟不超过多少），持续监控，发现瓶颈后针对性优化。AI 在这个环节的价值是辅助分析--分析慢 SQL、识别热点代码、生成优化方案，但优化决策（是否值得加缓存、是否需要重构）需要人权衡成本收益。

AI 在三高系统中的角色正在从"代码生成"扩展到"运行时智能"：基于流量模式动态调整限流阈值、基于历史数据预测容量瓶颈、基于异常指标自动触发扩缩容。但这些智能决策的边界和兜底策略，仍然是 Harness Engineer 的设计责任。

六、支撑业务快速迭代的安全重构

企业系统的常态不是"建好就不动"，而是"永远在重构"。业务多变是常态，AI 编码让变更速度更快，但更快不等于更安全。没有安全网的重构，速度越快灾难越大。

6.1 特性开关与灰度发布

特性开关（Feature Toggle）是安全重构的第一道防线。新代码与旧代码共存于生产环境，通过开关控制启用范围。AI 生成的新逻辑先在开关后跑灰度，1% 流量验证没问题再逐步放量到 10%、50%、全量。出问题随时关掉开关回退，不需要重新部署。这比"大爆炸式上线"安全一个数量级。

6.2 AI 辅助安全重构

AI 在重构环节有天然优势：它能快速扫描代码库，识别坏味道（长函数、重复代码、过深嵌套、上帝类），生成重构方案。但"生成方案"和"安全执行"是两回事。安全重构的铁律是：先加测试覆盖现有行为，再小步重构，每一步都跑测试验证行为不变。

补测试

先为待重构代码补充测试，锁定现有行为。AI 辅助生成测试用例，人验证断言正确性。

小步重构

每次只做一个原子改动：提取方法、重命名、移动类。每步提交后立即跑全量测试。

行为验证

测试全绿才继续下一步。测试红了立即回退，不"修测试"来适配重构。

灰度上线

重构后的代码走特性开关灰度，生产流量验证行为一致后全量切换。

6.3 契约测试与向后兼容

微服务环境下，一个服务接口的变更可能波及多个消费方。消费者驱动的契约测试（CDC）让消费方定义自己依赖的接口契约，提供方变更接口时必须通过所有消费方的契约测试才能发布。AI 生成新接口时，门禁自动运行契约测试，不兼容的变更直接打回。

6.4 Strangler Fig 模式：渐进式替换遗留系统

面对大型遗留系统，"推倒重来"几乎总是失败的。Strangler Fig（绞杀者无花果）模式借鉴植物绞杀寄主的策略：在新系统旁边逐步生长新功能，旧功能逐步迁移到新系统，直到旧系统被完全绞杀、安全下线。

落地要点：Strangler Fig 的关键是"拦截层"--一个统一的入口网关，按规则将请求路由到新系统或旧系统。新功能路由到新系统，未迁移的功能仍走旧系统。迁移按业务能力逐个进行，每个能力迁移完成后在旧系统中标记废弃。AI 可以辅助生成路由规则和迁移脚本，但迁移顺序和回退策略需要人根据业务风险评估决定。

七、Harness Engineer 的落地实践

Harness Engineer 约束框架 — Harness 的本质：不是限制 AI 的能力，而是给 AI 的能力装上方向盘和刹车

Harness Engineer 不是一个职位头衔，而是一种工程实践。核心是构建一套让 AI 在企业约束下安全工作的框架--不是限制 AI 的能力，而是给 AI 的能力装上方向盘和刹车。

7.1 约束框架的四层架构

上下文层

架构决策记录（ADR）记录每个重要决策的背景、选项与后果。领域模型文档让 AI 理解业务语义。代码库地图标注模块边界与依赖方向。这一层回答"AI 在什么系统里工作"

约束层

代码规范用 lint 规则固化。架构守护规则用 ArchUnit 类工具强制依赖方向。安全策略禁止硬编码密钥、强制输入校验。这一层定义"AI 能做什么、不能做什么"

验证层

测试门禁覆盖率与质量双门禁。契约测试保证接口兼容。代码审查人审关键路径，AI 审常规变更。这一层回答"AI 的产出是否合格"

反馈层

质量度量持续跟踪技术债、缺陷率、变更失败率。评估闭环把发现的问题反哺到约束层，持续收紧规则。这一层让框架自我进化

7.2 上下文工程：给 AI 正确的输入

AI 编码质量的天花板，很大程度取决于上下文质量。把一个 50 万行的代码库一股脑塞给 AI，它也抓不住重点。上下文工程做的就是把正确的信息在正确的时间喂给 AI：当前任务的领域模型片段、相关模块的接口契约、架构约束规则、已有的测试用例。这比优化 prompt 技巧重要得多。

7.3 评估与反馈闭环

约束框架不是一次性建好的，而是通过反馈闭环持续收紧。每次 AI 产出的代码被人工打回，原因要沉淀成新的 lint 规则或测试用例。下一次 AI 再犯同样的错，门禁自动拦截。这样框架就会越来越厚，AI 能安全自主处理的范围也越来越大。

AI 产出

AI 在约束下生成代码，提交 PR

门禁校验

自动跑 lint、测试、架构守护、契约测试

人工把关

关键路径人审，常规变更 AI 自审

规则沉淀

打回原因转化为新规则，框架持续收紧

八、工程师的价值重塑

工程师角色价值进化 — AI 时代工程师的价值，不在写代码的速度，而在定义系统的能力

回到最根本的问题：AI 编码时代，工程师的价值在哪里？答案是：越是 AI 能写代码，"写代码"这件事的稀缺性就越低，工程师的价值就越往上游移动--从代码生产者，变成系统定义者。

8.1 架构决策权仍在人手中

AI 能生成代码，但不能替你做架构决策。用单体还是微服务？同步还是异步？强一致还是最终一致？这些决策需要权衡业务需求、团队能力、成本约束、技术风险--没有标准答案，只有特定场景下的最优解。这种权衡能力，是工程师不可替代的核心价值。

8.2 系统思维 > 编码速度

AI 把编码速度的门槛拉平了。过去一个工程师的价值可能体现在"写得快、写得对"，现在这个优势被 AI 削平。真正拉开差距的是系统思维：理解一个变更在整个系统中的涟漪效应、预判技术债的演化路径、在业务压力下做正确的架构妥协。这些能力 AI 短期内无法替代。

8.3 不可替代的四项能力

能力	为什么 AI 替代不了	Harness Engineer 怎么发挥
业务理解	AI 不懂业务上下文，只懂代码模式	把业务知识沉淀为领域模型和上下文文档
权衡决策	AI 给方案，但不承担决策后果	在成本、风险、进度间做有依据的取舍
系统演化	AI 看不到代码库的历史与未来	规划技术栈演进路径，控制重构节奏
风险判断	AI 不理解生产环境的失败成本	定义安全边界，设计回退与降级策略

九、落地工具链选型

讲完方法论，落到工具层面。2026 年的 AI 编码工具已经形成清晰梯队，但"哪个最好"取决于团队规模、代码库大小和治理成熟度。下面按 AI 编码工具和 Harness 工程化工具两类梳理主流选型。

9.1 AI 编码工具对比

工具	定位	适合场景	Harness 友好度
Claude Code	Agent 式终端编码	复杂任务、多文件重构、企业级开发	高：CLAUDE.md 约束 + MCP 工具协议
Codex	OpenAI 编码 Agent	代码审查、任务委派、PR 自动化	高：自定义指令 + 沙箱执行
Cursor	AI 原生 IDE	日常开发、快速迭代、团队上手快	中：.cursorrules 约束文件
GitHub Copilot	补全 + Agent	补全为主、轻量 agent 任务	中：Copilot Instructions 配置
Augment Code	企业级 AI 编码	大型代码库、团队协作、合规要求高	高：企业上下文管理 + 权限控制
Cline	开源 VS Code Agent	预算有限、自主可控、深度定制	高：开源可定制 + MCP 支持
Aider	命令行 AI 编码	脚本化、CI 集成、批量重构	高：Git 原生 + 可编程

选型建议：企业级系统的主力工具首选 Claude Code 或 Augment Code--前者 agent 能力强且约束机制成熟（CLAUDE.md + MCP），后者专注大型代码库的上下文管理。日常开发可用 Cursor 降低团队门槛。CI/CD 中的自动化重构用 Aider。预算敏感或需要完全自主可控的团队，Cline 是开源首选。关键不是用哪个，而是每个工具都配好约束文件和门禁规则。

9.2 Harness 工程化工具

AI 编码工具负责"写"，Harness 工具负责"约束和验证"。两者缺一不可。以下是按工程化环节推荐的主流工具：

环节	推荐工具	作用
架构守护	ArchUnit / dependency-cruiser / import-linter	强制依赖方向、层级边界，防止 AI 跨层调用
代码质量门禁	SonarQube / CodeRabbit	静态分析 + AI 代码审查，门禁拦截低质量 PR
契约测试	Pact	消费者驱动契约，保证微服务接口兼容
特性开关	Unleash / LaunchDarkly	灰度发布、渐进上线、随时回退
混沌工程	Chaos Mesh / Gremlin	主动注入故障，验证高可用设计真实有效
CI/CD 流水线	GitHub Actions / GitLab CI	串联门禁：lint + 测试 + 架构守护 + 契约 + 部署
可观测性	OpenTelemetry / Grafana / Prometheus	链路追踪、指标监控、告警，变更可观测

这套工具链的核心逻辑是：AI 编码工具产出代码，CI/CD 流水线自动跑架构守护 + 质量门禁 + 契约测试，通过后走特性开关灰度上线，可观测性持续监控，混沌工程定期验证容错能力。每一环都是 Harness 框架的自动化延伸。

十、AI 编码工程化七原则

工具会换代，方法论会迭代，但有些原则是稳定的。这七条原则是 Harness Engineer 在任何工具栈下都应坚守的底线。

原则 1

门禁即法律

AI 产出的每一行代码都必须通过自动化门禁（lint、测试、架构守护）。没有"先合后补"，没有人工放行。门禁不通过的 PR，一律打回。

原则 2

不变量优先

领域模型的业务不变量是 executable specification。先写不变量断言，再让 AI 写实现逻辑。没有不变量守护的领域代码，等于没有模型。

原则 3

小步快走

每次变更原子化：一个功能一个 PR，每步可验证、可回退。拒绝"一次改 20 个文件"的大爆炸式提交。AI 加速了写代码，但不该加速制造不可回退的变更。

原则 4

上下文为王

AI 产出质量的上限是上下文质量。投入精力维护架构文档、ADR、领域模型、代码地图，比优化 prompt 技巧的回报高得多。Garbage in, garbage out。

原则 5

人审关键路径

核心业务链路（下单、支付、资金）、架构变更、安全相关代码必须人审。AI 审常规变更可以，但关键路径的风险人扛。这不是效率问题，是责任问题。

原则 6

可观测先行

任何变更上线前，先确认监控、告警、链路追踪已就位。没有可观测性的变更等于盲发--出了问题连现场都还原不了。先建观测，再发代码。

原则 7

渐进式迁移

永远不要大爆炸式重构。用 Strangler Fig 模式逐个业务能力迁移，每步灰度验证。旧系统不是敌人，是可以安全退场的伙伴--前提是有计划地绞杀它。

一句话总结：AI 编码时代，工程师的核心竞争力不是写代码更快，而是让 AI 在约束下安全地写代码。工具是手段，原则是底线，架构能力才是护城河。守住这七条原则，无论工具怎么换代，你都能立于不败之地。

结语

从 Vibe Coding 到 Harness Engineer，AI 编码的进化本质上是一场分工重画：AI 接管了"写代码"的执行，人收回了"定义系统"的主导权。这不是工程师的退场，而是工程师的升级--从代码工人变成系统架构师。

企业级系统的复杂度--高并发、高可用、领域模型、微服务拆分、安全重构--不会因为 AI 能写代码就消失。相反，AI 让代码生产变快，系统复杂度的治理压力反而更大了。领域建模要更深、拆分决策要更准、约束框架要更厚。这些恰恰是工程师价值最高的地方。

最终，AI 编码时代不是"AI 取代工程师"，而是"会用 AI 的工程师取代不会用 AI 的工程师"。而真正会用 AI 的工程师，不是那个 prompt 写得最花哨的人，而是那个能为 AI 搭好约束框架、让 AI 在系统里安全跑起来的人。这，就是 Harness Engineer。

参考资料

Martin Fowler - Strangler Fig Application https://martinfowler.com/bliki/StranglerFigApplication.html
Microservices.io - Saga Pattern https://microservices.io/patterns/data/saga.html
Microservices.io - Transactional Outbox https://microservices.io/patterns/data/transactional-outbox.html
Eric Evans - Domain-Driven Design: Tackling Complexity in the Heart of Software
Sam Newman - Building Microservices: Designing Fine-Grained Systems
Claude Code 官方文档 https://docs.anthropic.com/en/docs/claude-code
ArchUnit - 架构守护测试 https://www.archunit.org/
Pact - 消费者驱动契约测试 https://pact.io/
Chaos Mesh - 云原生混沌工程 https://chaos-mesh.org/