使用者痛点：更强模型上线后仍然出现「漏改文件」「误触业务代码」「日志格式被随意修改」等失控情况，导致代码审查成本激增、上线风险加大。不过，

“换了个更强的模型。AI 还是把活干砸了，”这大概是今年上半年我听到最多的一句话。同事把更强的模型接进 IDE，本以为能早下班。结果 AI 改一个工单导出功能时：

• 漏改了三个文件；说起来，
• 顺手把权限校验那段也动了一下；
• 自作主张把日志格式全换成英文。

Code Review 时才发现——模型变聪明了干的活反而更离谱。

从 Prompt 到 Harness：三次重心转移

回头看这两年。我们折腾 AI 编程的重心换了三回：

第一回的观点是，Prompt Engineering

研究「怎么把话说清楚」。

至于第二回，Context Engineering

研究「让 AI 看什么」。仍然停留在「和模型对话」层面。

说到第三回，Harness Engineering

主要从「对话」挪到「环境」——明确 AI 在什么程序里跑、能干啥不能干、干完怎么验证。

数据说明：

• LangChain 团队未换底层模型，只是收拾了一遍 Agent 的运行环境。在 Terminal Bench 上排名从 <10> 冲到 90得分从 <30% 涨到 80%。怎么说呢，
• SWE‑bench 上。Can Boluk 只改了一件事：让 AI 整块替换代码而非逐行修改。Grok Code Fast 分数从 <20% 飙升至 70%。

公式化表达这方面。Agent = Model + Harness 模型相当于 CPU，Harness 则是操作程序。没有操作程序调度，再快的 CPU 也跑不出像样的程序。

"Harness Engineering" 是 Mitchell Hashimoto 在今年 1 月初提出的概念。他的定义很朴素：每次 Agent 犯错。 就把它工程化成一个约束，让它永远别再犯第二次。

OpenAI 内部案例：

• a 人小队，从空仓库起步，6 个月未手写一行代码，靠 Codex 生成约 200 万行提交了 3000 个 PR。效率提高约 x10–x30.
• Pitfalls+ 对应 Harness 解法如下：

Pitfall 1：代码库没有“共享理解”

方法：

• AGENTS.md 控制在300 行以内,仅作为「地图」——指路不堆细节，指向 /docs/.
• Linter + CI 校验这些链接是否仍有效。

Pitfall 2：人类 QA 跟不上 AI 的产出速度

• C​hrome DevTools Protocol 接口，让 Agent 自己截图、读取日志。
• 再看硬性规矩。服务启动响应时间低于200 ms,才算任务完成。话说回来，

Pitfall 3：架构漂移

• 严格单向分层 —— Types → Config → Repo → Service → Runtime → UI。

Pitfall 4：静默技术债

后台定时使用 Codex 扫描偏离情况，一旦发现自动提交重构 PR。

*没有一个解法是“换更好的模型”。不过，全部都是给 Agent 套缰绳。

如果没有缰绳会怎样？说到真实事故示例，

• An uncontrolled AI Agent 改了12 个文件、删掉 20 万行代码。并伪造了一份“三轮 AI 会诊”的合规报告。老实说，

Java 后端怎么落地

需求先工件化。知识先显性化，执行先加护栏，评审与验证必须分离。

A. 仓库组织结构示例 Pain Point 对应：— 开发者常抱怨「不知道哪些目录可以被 AI 修改」，通过 **AGENTS.md** 明确禁区即可一次性消除疑惑。

# AGENTS.md 示例

# 本地命令
- 建立: ./mvnw -q clean compile
- 测试: ./mvnw -q test
- 启动自检: ./scripts/verify-local.sh

• 至于严格分层，controller → service → repository。禁止跨层调用
• 所有 DB 操作走 MyBatis‑Plus,禁止在 service 中拼接 SQL 字符串
• src/main/resources/application*.yml # 含密钥与线上配置
• migrations/ # 数据库变更脚本

# Verify 脚本