1. 为什么要从“复制粘贴”升级到 Harness
1.1 复制粘贴式 AI 编程的痛，我自己先踩了一道
先说个我自己的真实经历。前两年团队里开始大规模用 AI 写 Java 后端代码，大家的使用习惯几乎一致：在对话框里把需求描述一遍，让 AI 生成一个类或接口，然后把代码复制到 IDE 里，跑一下，能编译就提交。
听起来效率很高，但用着用着就发现问题了。第一个是风格崩坏。同一个 Controller，有人让 AI 生成的是Result<T>统一返回，有人生成的是直接返回Map<String, Object>，还有人让 AI 自己发挥，搞了个ResponseEntity<Object>。代码库里混了三种风格，review 的时候真的会怀疑人生。
第二个问题是“跑的起来”和“符合规范”完全是两码事。AI 生成的那一大段代码里，最常见的就是重复造轮子。明明项目里已经有PageQuery、PageResult这样的基础设施，AI 会因为不知道这些类的存在，又一次生成自己的分页实现。你说它错了吗？语法没错，但放到工程里就是灾难。
第三个问题更隐蔽——上下文管理。你在对话框里持续加需求，AI 对上下文的把握一开始还行，对话一长就开始“失忆”，前一个回答里说要加 Redis 缓存，后一个回答里又把缓存删了。到头来你要么反复纠正它，要么干脆放弃继续对话，重新开一个窗口，从头再描述一遍。
这些问题的本质，其实不是 AI 不够聪明，而是少了工程化的约束。复制粘贴的方式，等于把 AI 摆在了一个“一次性临时工”的位置上——它不了解你的代码库、不熟悉你的团队规范、不知道你的基础设施，你也不给它反馈闭环。那它能给出的东西，自然只能是一个“看起来差不多”的泛化答案。
1.2 Harness 是什么，它和 Agent、对话式编程有什么区别
后来我接触到了 Harness 这个概念。这个词本身直译是“马具、缰绳”，放到 AI 编程里，含义非常精准：不是让 AI 完全自由发挥，而是给它套上一套工程化的“缰绳”，让它在既定的轨道、既定的上下文、既定的反馈机制里工作。
很多人会把 Harness 和 Agent 弄混。我自己的理解是这样的：
- Agent 是一个“能自主规划、调用工具、执行任务的 AI 程序”，核心在于思考与行动的能力；
- Harness 是“一个承载 Agent 运行的最小工程框架”，核心在于连接与约束。
打个比方，Agent 是发动机，Harness 是整辆车。发动机再好，没有一个能装油箱、轮子、方向盘、刹车系统的车架，它就只能原地打转。放到 Java 后端这个场景里，Harness 负责的事情包括：把代码库索引进来、把规范文档喂给模型、把可用的工具（比如 Maven 构建、测试运行、Git 操作）注册进去、把每次任务的输入输出和反馈记录下来。
对话式编程是“你一句我一句地让 AI 写出代码”，Harness 则是“你给 AI 一个仓库，告诉它目标，它在大致的轨道上自行探索，最后交付一个符合约定的结果”。前者是写作文，后者是带约束的工程任务。
1.3 为什么 Java 后端特别需要 Harness 这类工程化工具
Java 后端和其他领域相比，有几个非常“吃工程约束”的特点，我实际用下来感触特别深：
第一，Java 是强类型语言，且有严格的编译期检查。
AI 生成的代码，如果类型对不上、泛型写错、异常没处理，编译直接失败。复制粘贴模式下，你光修编译错误就能耗掉大量时间。一个能自动跑 Maven 编译并把错误反馈给 AI 的 Harness，能把这类来回拉扯的成本大幅压缩。
第二，Java 后端项目往往有严格的分层结构和约定。
Controller、Service、Mapper、DTO、VO，每一层有每一层的职责和命名规范。AI 如果不了解这些约定，生成的代码就是“独立可运行，融入即崩溃”。Harness 可以把项目的结构说明、规范文档、示例代码全部注入上下文，让 AI 从源头就知道“在这里该按什么套路写”。
第三，Java 后端的依赖管理、并发模型、事务机制、Spring 容器生命周期，都是“隐性知识”。
这些内容很难靠提示词一两句话教给 AI，因为它需要真正的代码库上下文。Harness 通过代码检索和索引，能把这些隐性知识变成 AI 可以随时查阅的“参考资料”。
2. Harness 方案的核心设计与思路拆解
2.1 理解 Harness 的三大核心组件：上下文、工具集、反馈循环
我在团队里推动 Harness 落地时，把整个方案拆成了三个核心组件。你理解了这三个东西，基本上就理解了所有 Harness 类工具的用法。
上下文（Context）：这是 Harness 和“裸用 AI”差别最大的地方。裸用 AI 时，你能喂给它多少上下文取决于对话框的长度限制，而且这段上下文是一次性的，关掉窗口就没了。Harness 则会把项目的代码库索引成本地或私有化的向量数据库，在每次任务执行时，动态检索与任务相关的类、接口、配置片段，拼装成上下文喂给模型。关键在于，这个上下文始终反映你仓库的最新状态，不会像对话那样聊着聊着就过期了。
工具集（Tools）：Harness 不只是让 AI 写代码，它会暴露一组经过封装的操作接口给 AI 调用。在 Java 后端场景中，最常用的工具包括：文件读取与写入、Maven 编译、测试执行、Git 提交与分支操作、搜索代码库、执行 SQL 或调用接口。AI 每一次调用工具，都会产生可以被记录和审计的结果。
反馈循环（Feedback Loop）：反馈是工程化的灵魂。复制粘贴模式下，AI 永远不知道它生成的代码后来被改成了什么样——是删了很多，还是大改过，它完全没概念。在 Harness 里，每次人工 review 后的代码变更、编译报错信息、测试失败信息，都会回灌到上下文中，作为后续生成的“经验参考”。这也是为什么 Harness 用得越久越顺手，而普通对话式 AI 用得再久也是那个水平。
2.2 Java 后端场景下 Harness 的推荐技术栈
我试过几条不同的路线，有直接用开源方案的，也有基于商业工具二次封装的。综合团队上手成本、可维护性和实际效果，我给出一套目前用下来最稳定的组合：
| 组件类型 | 推荐方案 | 说明 |
|---|---|---|
| 模型底座 | DeepSeek（部署私有化版本）或 Codex | 代码理解能力强，上下文窗口大，私有化部署还能满足数据合规要求 |
| Harness 层 | DeepSeek Harness（社区开源版） | 支持自定义 Skill、工具注册、代码索引，二次开发成本适中 |
| 代码索引 | 基于 Java 的语义索引方案 | 按包名、类名、方法签名、注解做索引，避免用纯文本向量检索导致的“找不准” |
| 构建与验证 | Maven + JUnit + Testcontainers | 给 AI 一套可以“自测”的编译和测试环境，而不是让它盲写 |
| 执行门户 | GitHub Actions 或自建 CI 流水线 | Harness 产出的变更必须走 MR + 流水线，禁止直接推主干 |
这套组合里，核心思路是把 AI 生成的代码当成交付物而不是最终物。每一段 AI 生成的内容，都要经过编译、测试、review 三道闸门，才能进入主干。Harness 在这里扮演的角色，就是把这套流程从“人肉围堵”变成“自动整流”。
2.3 为什么选择“先约束风格，再开放能力”
我在配置 Harness 时，做过一个很重要的策略选择——先约束 AI 的输出风格，再逐步开放它能调用的工具能力。这个方向如果反了，后面会很难收拾。
第一阶段的约束，主要是通过项目内的AGENTS.md或自定义 Skill 文件来实现。在这个文件里，明确写了代码风格要求、分层规范、统一返回格式、异常处理规范、命名约定、不允许重复造轮子的基础设施清单（比如已有的PageQuery、BaseController）。AI 在每次生成代码前，都会被强制读取这一份“规则书”。
第二阶段才开放工具。比如允许 AI 自己执行 Maven 构建，允许它跑单元测试，允许它读取项目日志里的报错。开放工具的节奏一定是跟着团队成熟度走的，刚开始如果 AI 有太多工具，反而容易把仓库改乱。
我自己踩过的坑是：一开始为了追求“全自动”，把写文件、提交 Git、执行构建全都开放给了 AI。结果某一次 AI 在改配置类的时候，直接把application.yml里的数据源地址给改了，还自动提交到了本地分支。幸好当时还没有自动推远端，不然就是一次生产事故。所以我现在对团队的要求是：先让 AI 只输出建议，人工确认后再写入；等稳定运行一段时间，再逐步放开写权限。
2.4 和传统 Agent 方案相比，Harness 更适合团队协作的四个原因
市面上 Agent 方案很多，但如果你是要在 Java 后端团队里落地，我强烈建议优先考虑 Harness 形态，理由有四个。
第一，Harness 是配置即代码，所有 Skill、规则、工具定义都存在 Git 仓库里，可以走 MR 评审。这个对团队协作太重要了。传统 Agent 的 Prompt 存在个人账号或本地配置里，完全是黑盒，同事问你“你怎么让 AI 写出来的代码这么规范”，你总不能把自己的对话记录甩给别人吧。Harness 的规则是团队共享资产，可以像代码一样版本化、演进、review。
第二，Harness 的每一次任务执行都有日志和产物记录。AI 生成了什么文件、改动了哪些行、测试结果如何，都有迹可循。出了问题不是“AI 乱写的，没办法”，而是能掏出日志逐条回溯。
第三，Harness 天然支持多项目、多团队的复用。你可以做一套 Java 后端的 Skill 库，直接套到不同项目上，只需要改几个配置项。而传统对话式 AI 的调教，换一个项目就得重来一次。
第四，Harness 能和现有 CI/CD 流水线无缝衔接。AI 的输出不是一个“代码片段”，而是一个“代码变更”，这个变更可以直接推送到 MR 里，触发流水线编译、测试、部署。传统“复制粘贴再改改”的模式，永远做不到这一点。
3. 实操过程：从零搭建一套 Java 后端 Harness 环境
3.1 环境准备与安装：DeepSeek Harness 安装全流程
如果你确定要在本地或服务器上搭建 Harness，我先给一个可复现的安装流程。以 Ubuntu 服务器 + Docker 部署为例子，整个流程大概半小时能跑通。
先做基础准备：安装好 Docker 和 Docker Compose，准备好模型服务的 API Key。如果你想用 DeepSeek 官方 API，直接在官网申请；如果想私有化部署，用 Ollama 或 vLLM 拉一个 DeepSeek 的量化模型也行，但硬件要求高一些，至少需要一张 24GB 显存的显卡。
然后克隆代码仓库并进入项目目录：
git clone https://github.com/your-harness-repo/deepseek-harness.git cd deepseek-harness接下来编辑环境变量文件，核心是配置模型 API 地址和 Key：
cp .env.example .env vim .env在.env里需要重点关注这几个配置项：
LLM_PROVIDER=deepseek DEEPSEEK_API_KEY=sk-xxxxxxxxxxxxxxxx DEEPSEEK_MODEL=deepseek-coder-33b-instruct CONTEXT_STORE_DIR=./data/context_store SKILL_DIR=./skills这里的CONTEXT_STORE_DIR是代码索引的存放目录，SKILL_DIR是自定义 Skill 的存放目录。编辑完保存，然后执行：
docker compose up -d启动完成后，通过docker compose ps确认各容器状态，如果全部是Up状态，说明服务起来了。之后可以用 SDK 连接到 Harness，也可以直接用它提供的 Web 界面测试。
注意：DeepSeek Harness 安装看起来简单，但最容易出问题的是模型服务连不上。如果你用的是本地 Ollama 部署，要确保 Ollama 的端口（默认 11434）能被 Harness 容器访问到。我在 Docker 网络配置上卡过很久，后来直接用
--network host解决的，省去一堆端口映射的麻烦。
3.2 配置 Java 项目上下文：让 AI 真正“懂”你的代码库
Harness 装好之后，最重要的一步就是让 AI 理解你的 Java 项目。这一步做不好，后面全是白搭。
首先要做代码索引生成。在 Harness 的配置目录下，新建一个harness.yaml配置文件，然后指定代码库路径：
repo: path: /workspace/your-java-backend include: - "src/main/java/**/*.java" - "src/main/resources/**/*.yml" - "pom.xml" exclude: - "target/**" - "node_modules/**"这里include决定 AI 能检索到哪些文件，exclude用来排除构建产物和无关目录。配置好之后，执行索引命令：
harness index update索引完成后，Harness 会生成一份代码库结构性描述，包括顶层包结构、核心类、常用注解、依赖关系。你可以手动查看这份结构描述，确认 AI 是不是真的“看懂”了：
cat data/context_store/java-repo-structure.json我一般会重点检查几个关键类是否被识别到，比如CommonResult、BaseController、PageQuery这些基础设施类。如果它们不在索引里，AI 就还是会自己造轮子，Harness 的约束效果就会大打折扣。
然后是注入项目规范。在SKILL_DIR下创建一个java-backend-rules目录，里面写一个SKILL.md文件，内容就是把团队规范翻译成 AI 能执行的指令。
举个例子，我的SKILL.md里长这样：
# Java 后端开发规范 ## 分层约定 - Controller 层只做参数校验和结果包装，业务逻辑一律放在 Service 层 - Service 层禁止直接返回 Entity，必须转成 DTO 或 VO - Mapper 层只做数据访问，不允许写业务判断 ## 统一返回格式 - 所有接口必须返回 CommonResult<T> - 成功时 code=200，message="success" - 业务异常时抛出 BizException，由全局异常处理器统一转换 ## 禁止重复造轮子 - 分页参数统一使用 PageQuery - 分页结果统一使用 PageResult - 禁止自定义 BaseController 之外的公共基类写完这个文件后，在 Harness 里加载这个 Skill：
harness skill load java-backend-rules加载后，AI 每次被分配任务时，都会先读取这份规范，再开始干活。这一步的效果立竿见影——生成的代码从“能用”变成“团队风格统一”。
3.3 核心实操：用 Harness 完成一个典型的 Java CRUD 接口
我拿团队里一个典型的“用户管理”模块来演示实际执行流程。假设需要新增一个GET /api/v1/users/{id}接口，返回用户详情。
在 Harness 里发布任务的方式，可以直接写一段指令，比如：
harness run "在 user 模块中，新增一个根据 ID 查询用户详情的接口。要求： 1. Controller 路径为 GET /api/v1/users/{id} 2. 返回 CommonResult<UserDetailVO> 3. 调用 UserService.getUserDetail(Long userId) 实现业务逻辑 4. 用户不存在时抛出 BizException，错误码为 USER_NOT_FOUND 5. 不要修改现有其他文件"Harness 拿到任务后，会自动进行一系列操作。首先是检索上下文，它会在索引库里找到user模块下相关的 Controller、Service、Mapper、Entity、VO，以及CommonResult、BizException这些基础设施类。然后它会编写代码，生成新的UserController方法、UserService接口方法、UserServiceImpl实现方法（或复用已有逻辑）、UserDetailVO，最后还要自检编译并执行测试。
执行完成后，Harness 会输出一个变更清单，我在实操过程中看到的典型输出是这样的：
[Harness] 已生成以下变更： - src/main/java/com/example/user/controller/UserController.java（新增 1 个方法） - src/main/java/com/example/user/service/UserService.java（新增接口方法） - src/main/java/com/example/user/service/impl/UserServiceImpl.java（新增实现） - src/main/java/com/example/user/vo/UserDetailVO.java（新增文件） [Harness] 已执行编译：成功 [Harness] 已在 UserControllerTest 中新增测试用例：通过这时候我作为工程师，不需要从零写代码，而是在这个变更清单上做 review。重点检查三件事：一是接口路径和参数是否符合需求；二是异常处理是否走统一规范；三是 DTO 字段命名和类型是否和数据库实体对齐。如果 review 发现问题，直接在评审意见里反馈，Harness 会基于反馈重新修改代码。这个迭代循环，比“复制粘贴再手动改”的效率高得多。
3.4 落地 Harness 时会遇到的配置细节
如果你已经装好了 Harness 准备投入实战，有几个配置细节我建议提前处理好，不然会在实际使用中频繁踩坑。
第一个是 Maven 私服地址的注入。公司内部的 Java 项目一般都会用 Nexus 或 Artifactory 做依赖管理，AI 在编译时如果拉不到私有依赖，构建就会失败。我在 Harness 的环境变量里显式配置了MAVEN_OPTS=-Dmaven.repo.remote=https://nexus.internal.com/repository/maven-public/，并且确保 Harness 容器能访问到私服地址。
第二个是本地缓存目录的持久化。Maven 依赖下载非常耗时，如果每次任务跑完容器重启后都要重新下载，体验会非常差。我在 Docker Compose 里把~/.m2目录挂载成数据卷，保证依赖缓存长期保留。
第三个是数据库连接信息的管理。Harness 执行测试时如果需要连数据库（我强烈建议用 Testcontainers 起本地容器），要确保能拿到测试环境的连接信息。这个信息不要硬编码在 Skill 里，而是通过环境变量注入，避免密钥泄露。
第四个是成本控制。Harness 在后台自动迭代的次数可能比你想象的多，每次迭代都要调用模型 API，产生了 token 费用。我一开始没做限制，一个月下来账单有点吓人。后来在 Harness 配置里加了单任务最大调用次数限制，默认 5 次，超过就自动停止等待人工接管，成本一下子降到了原来的一半以下。
3.5 这个方案适合什么样的 Java 后端项目
讲到这里，有必要泼一点冷水。Harness 不是所有项目的银弹，我自己认为有三类项目尤其适合引入，也有两类项目我建议先观望。
适合的类型，首先是基础设施稳定的业务系统。这类项目有统一的技术栈和规范，AI 生成的代码大部分能直接复用已有模式。其次是团队规模在 5 人以上的中大型项目。人多了之后，统一规范的成本本来就高，Harness 把规则沉淀成 Skill 文件，能显著减少沟通成本。第三是需求重复度较高的 CRUD 密集型系统。用户模块、订单模块、商品模块之间有大量相似结构，Harness 对这种“模板相似但不完全一样”的场景处理得非常好。
不适合的也有两类。一类是从零到一的技术预研项目，这种项目本身没有既有规范，代码结构每天都在变。Harness 的上下文索引更新跟不上变化速度，反而会误导 AI。另一类是对代码性能要求极高的底层中间件项目，像自研 RPC 框架、数据库驱动这种，AI 生成的代码风格再统一也没用，性能瓶颈和并发问题的处理需要极强的领域经验，目前还很难通过工程化约束来解决。
4. 常见问题与排查技巧实录
4.1 问题一：Harness 生成的代码编译不过，怎么办
这是最常见的问题，原因也很简单——AI 从索引里拿到的依赖信息过期了。项目里的某个接口签名变了，但因为代码索引不是实时更新的，AI 还在按旧签名生成代码，自然编译不过。
我的排查步骤是：先看 Harness 的执行日志，找到它引用了哪些类；再到 IDE 里手动搜这些类的当前定义，对比签名差异。如果是签名变了，那就先执行harness index update更新索引，再重新运行任务。另外还有一个做法，是给 Harness 加一个“编译失败自动重试机制”，让 AI 在拿到编译错误信息后自我修正两三次。大部分编译错误，AI 在看过报错内容后都能自己改对，真正要人工介入的其实很少。
经验教训：不要一看到编译失败就手动改代码。先让 Harness 自己迭代修复，通常两轮以内能解决 80% 的编译问题。当然也要设一个上限，别让它无限重试，那是在浪费 token。
4.2 问题二：AI 改了很多不该改的文件，仓库变更失控
这个问题在 Harness 刚上线时最容易出现。AI 为了完成一个小需求，顺手“优化”了 10 个看起来不太规范的类，导致 MR 看起来像是重构了整个项目。
应对方案是设置变更白名单。在 Harness 的harness.yaml里，明确指定 AI 可以修改的文件路径模式：
workspace: allowed_edit_paths: - "src/main/java/com/example/user/**" - "src/main/resources/mapper/**" forbidden_edit_paths: - "src/main/java/com/example/config/**" - "pom.xml"这样做了之后，AI 生成的变更都集中在需求相关的模块里，review 起来非常清爽。这个限制同样有助于防止 AI 改掉一些“看起来可以优化但实际上不能动”的核心配置类。
4.3 问题二：提示词写了没用，AI 就是不按规范走
如果你发现 AI 总是无视 SSR 规范，八成是因为规范文件没有真正加载进去，或者规范文件本身写得不够“机器可读”。
我先检查 Skill 是否已经加载，可以执行：
harness skill list查看java-backend-rules是否在列表中。如果在，但还是不生效，大概率是规范文件写的太笼统。比如“代码要整洁”“注意性能”这种话，AI 读完是不会有任何具体行为的。规范必须具体到可以逐条判断对错的程度。
我举个例子。如果你写“Controller 层要轻”，AI 无法判断什么叫轻。但如果你写“Controller 方法体内禁止出现超过 20 行的业务逻辑，超过必须抽取到 Service 层”，AI 就能照着执行。规范文件里每一条都应该是这种可验证的硬规则，而不是模糊的方向指导。
4.4 高频问题速查表
| 问题 | 可能原因 | 快速解法 |
|---|---|---|
| AI 生成的类找不到项目已有类 | 代码索引过期 | 执行harness index update刷新索引 |
| Maven 编译失败，提示依赖缺失 | 容器无法访问私服或本地缓存为空 | 检查 MAVEN_OPTS 配置，持久化 .m2 目录 |
| AI 改动了非目标文件 | 未配置编辑白名单 | 在 harness.yaml 中配置 allowed_edit_paths |
| 输出风格混乱，用了两种返回格式 | Skill 文件未加载或规则不具体 | 执行harness skill list检查，将规范写成可验证硬规则 |
| 单次任务消耗 token 过多 | 自动迭代次数没限制 | 配置 max_retry 参数，建议 3-5 次 |
| 测试用例总是连不上数据库 | 测试环境连接信息未正确注入 | 使用 Testcontainers 管理测试数据库生命周期 |
4.5 逃不过的坑：私有化模型和 API 模型的取舍
最后聊一个比较现实的选型问题。如果你在团队里推 Harness，一定会遇到“用开源私有化模型还是商业 API 模型”的争论。
我自己两套都试过，感受很直观。私有化模型（比如 DeepSeek 本地部署的开源版本）的优势在于数据不出内网，合规方面基本没问题，适合公司代码敏感性比较高的项目。但部署成本和维护成本高，而且模型能力迭代滞后，如果公司用的技术栈比较新（比如 Spring Boot 3.2 的新特性），它可能不太了解。
商业 API 模型（比如 Codex）的能力更强，上下文窗口更大，生成代码的准确率更高。缺点是要把代码片段上传到外部 API，很多公司对此有顾虑。折中方案是：把项目敏感信息做脱敏处理后再传给 API，同时在 Harness 层面设置过滤规则，自动抹掉配置中的密码、密钥、内网 IP 等敏感信息。
我的建议是，如果是 50 人以内的小团队，直接用商业 API 模型配上 harness 做提示词过滤，性价比最高。如果是大公司且代码资产敏感，那必须上私有化，这一点没有讨论空间。
5. 给 Java 后端工程师的落地建议
5.1 不要一上来就追求全自动，先做半自动
如果你的团队还在“复制粘贴”阶段，我不建议你一步到位地上 Harness 全自动流程。我踩过的坑告诉我，全自动的前提是团队已经有了非常明确的规范，而大多数团队其实没有。
我的落地路径是：先让 AI 只生成代码建议，由工程师手动复制到 IDE，然后在人工 review 通过后，把这次“生成→修改→定稿”的过程标记为一次成功实践，回传给 Harness 作上下文沉淀。跑通 20 到 30 个任务后，规范文件、用户反馈这些素材都丰富了，再逐步开放 AI 的写文件权限。
这种渐进式的推进方式，团队心理负担小，不会有人说“AI 抢我饭碗”，反馈质量也高。
5.2 Skill 是团队资产，要像代码一样管理和演进
我在团队里立了一个规矩：任何人在用 Harness 时发现的规范漏洞或新约定，都必须写回到java-backend-rules这个 Skill 文件里，并且走 MR 评审。Skill 文件的变更记录，就是团队工程规范演进的真实历史。
每一条规则都需要写清楚“是什么”和“为什么”。比如“禁止在 Service 中直接调用RestTemplate访问外部接口”这条规则，如果只写禁止，AI 不理解为什么，它可能下次换个WebClient绕过规则。但如果你写“外部接口调用必须通过ExternalCallClient封装，以便统一处理鉴权、超时和链路追踪”，AI 就会理解约束背后的意图，执行得更稳。
5.3 这个方向后续还可以怎么演进
最近我在折腾的一个方向，是把 Harness 和前后端分离项目的接口联调打通。后端 Harness 生成好接口后，自动生成 OpenAPI 文档，再根据前后端包名约定，让 Harness 联调检查接口参数和返回结构是否与前端调用一致。这一步如果走通了，前后端联调会大大减少。
Harness 这个工具真正改变的不是“AI 会不会写代码”，而是“团队怎么收编 AI 的生产力”。它把 AI 从一个只会打零工的临时工，变成了真正能参与工程化生产流程的一环。这个思路对 Java 后端来说，尤其值得试一试。
我现在个人的体会是，工具选型固然重要，但真正起作用的是团队对“AI 编程”这件事的定位转变。复制粘贴是在把 AI 当搜索引擎，Harness 是在把 AI 当结对编程的同事——需要给它规则、给它上下文、给它反馈，而不是期待它天生就懂你的工程。这个转变本身就值回投入了。
