如何让大模型可靠地完成任务？

作者：尔东陈在路上｜发布日期：2026-08-07｜原文：https://mp.weixin.qq.com/s/_nltvf7gZcxR60la7QkAbw

HARNESS ENGINEERING

如何让大模型 可靠地完成任务？

五个真实场景，一套系统方法

大模型很聪明，但「聪明」不等于「可靠」——它可能写出能跑却不合规范的代码，可能跳过测试直接提交，也可能一次吞下过大的任务后半途跑偏。

这篇文章不先给定义，而是先抛几个真实场景里的问题，再逐个讲怎么治。讲完你会发现：我们一直在做的，就是 Harness 工程。

开场：五个场景，五个麻烦1让 AI 写业务代码

能跑，但不符合团队架构 / 编码规范 / 风格

2改完就要提交

没跑测试就 commit，把坏代码推进仓库

3做一个高复杂度功能

一上来就写代码，范围失控、上下文爆炸

4多个任务并行推进

同一工作区互相改文件，冲突难收场

5涉及高危操作

Delete、推生产、改权限……自动执行风险太大

什么是「口径管理」？口径 = 团队约定的「怎样算做对」（分层、命名、测绿再提交、先 Plan、一任务一工作区、高危须人批）。

管理 = 把口径写进规则 / 文档 / 权限 / 命令，让 Agent 按同一套标准执行，而不是每次口头临时说。

下面按「问题 → 约束方式 → 练习」串起来讲：讲完一个子板块就当场练一小问。

场景 1：生成的代码要符合规范

Harness 组件 → 架构约束 / 规范约束（常驻证据）

**问题：**模型默认按「互联网平均写法」生成，不会自动遵守你们团队的规矩。

**解法：**把「什么叫合格代码」写成可复用的验收口径，让 Agent 每次自动带上，而不是靠当场口头提醒。要拆成三层约束——

口径写在哪怎么执行

项目规则文件 如 CLAUDE.md、Rules

在项目根目录新建/编辑规则 → 新开对话后规则自动注入

架构文档 如 docs/architecture.md

写清分层与依赖方向 → 提需求时 @ 该文档

Formatter / Linter Prettier、ESLint 等

规则要求「改完必须跑格式化 / lint，未通过不算完成」

(a) 架构规范

需要有自己的架构文档。例如写接口时应遵循 Controller → Service → Dao，而不是在 Controller 里直接调 Dao。把分层边界、目录约定、依赖方向写清楚，再 @ 或挂进项目规则，模型才有「该往哪一层放代码」的依据。

操作

在 docs/architecture.md（或规则文件）写明「页面 → lib/utils → 数据层」的依赖方向；对话里 @ 该文档后再提功能需求。

练习

在 To-Do List 规则里写入一条架构约束：「业务逻辑放 lib/，页面组件只负责展示与事件绑定，禁止把增删改逻辑直接写在组件里。」新开对话，让 AI「加一个按截止日期排序」。

**问自己：**新代码有没有分层？有没有又把逻辑塞回组件？

(b) 编码规范

例如命名用驼峰、参考阿里巴巴 Java 开发手册等。把「必须 / 禁止」写成硬规则，比口头说「写规范一点」可靠得多。

操作

打开项目规则，写入「必须 / 禁止」条目（如驼峰命名）；保存后新开对话验证是否自动生效。

练习

写入硬规则：「函数与变量统一 camelCase；禁止 snake_case 与无意义单字母命名（循环变量除外）。」让 AI 新增一个「清空已完成任务」的工具函数。

**问自己：**命名是否全部合规？删掉规则再要一次，差别大不大？

(c) 编码风格

缩进、引号、行宽等交给 Formatter / Linter（Prettier、ESLint、Checkstyle……），让「风格是否合格」变成机器可判定的结果，而不是靠人眼看。

操作

确认项目有 Formatter 配置；在规则写「提交前执行格式化命令（如 npx prettier --write .）」——风格口径用命令验收，不靠人眼。

练习

确认项目已有 Formatter（如 Prettier）；规则里写：「改代码后必须按项目 Formatter 格式化再结束。」故意让 AI 生成一段缩进混乱的片段，再要求它「按项目规范整理」。

**问自己：**风格问题是靠眼看，还是靠命令 / 工具一次判定？

场景 2：自动化测试与提交

Harness 组件 → 结果校验

**问题：**AI 改完就说「好了」，但没有证据证明真的好了。

**解法：**把「完成」的验收口径从口头的「好了」改成可执行门禁——测试绿，才允许提交。

口径怎么执行

测试命令即验收口径

规则写清：「改代码后必须先跑 npm test；失败则继续修，禁止 commit」

让 Agent 按口径跑

直接说「按项目规则提交」——观察它是否先跑测试再 commit

双门禁（可选加强）

本地 pre-commit / CI 与规则口径一致，人与 Agent 同一套红线

操作

① 在项目规则写入「红测禁止提交」；② 对话发送「帮我提交当前改动」；③ 看 Agent 是否调用终端跑测试，红则停下。

练习

① 给 To-Do List 加一个极简单元测试（如「添加任务后列表长度 +1」），再故意改坏被测逻辑，确认测试是红的。② 规则写入：「测试失败时禁止 git commit，须修到全部通过。」③ 对 AI 说：「帮我提交当前所有改动。」

**问自己：**它是先跑测试再决定能不能提交，还是直接 commit？红测状态下有没有被拦住？

场景 3：高复杂度功能的开发流程

Harness 组件 → 流程编排

**问题：**复杂需求一次塞进对话，模型容易乱序实现、漏约束、上下文被噪声填满。

**解法：**用流程口径管住「先想清楚再动手」——Plan 产出可验收清单 → Build 按块实现 → 拆窗口控制上下文。

Plan：先想清楚

澄清目标、边界、依赖、验收标准；必要时产出任务清单。

操作

模式选 Plan → 粘贴复杂需求 → 要求输出「子模块 ≥3 + 每块验收口径 + 顺序」→ 保存清单后再动手。

练习

切换 Plan（或明确说「先不要改代码」），需求：「给 To-Do List 加标签分类、截止日期提醒、导出 JSON。」要求输出：子模块拆分（≥3）、每块验收标准、实现顺序。

**问自己：**清单里每一步是否「做完能单独验证」？有没有仍大到无法一次做完的块？

Build：逐步实现

按清单逐步实现，每步可验证。

操作

新对话只发送清单第 1 条 + 对应验收口径；完成后对照口径勾选，再进入下一块。

练习

只挑 Plan 清单里的第 1 块，在新对话里实现，做完立即按验收标准自测。

**问自己：**若跳过 Plan 直接一口气做三块，完成度与可验证性差在哪？

拆窗口：控制上下文

模块边界清晰时，新开 Session 只带该模块所需上下文。

操作

点「新对话」→ @ 本模块文件 → 粘贴该块任务；禁止在已很长的旧对话里继续塞新模块。

练习

第 2 块功能新开对话实现，只 @ 该模块相关文件；不要继续挤在做第 1 块的旧窗口里。

**问自己：**新窗口是否更干净？旧窗口历史有没有干扰本次任务？

场景 4：并行任务与冲突管理

Harness 组件 → 隔离与协作机制

**问题：**两个 Agent（或两个对话）同时改同一工作区，文件互相覆盖，冲突难解。

**解法：**并行口径 =「一任务一工作区」：用 Git Worktree 隔离，合入前再处理差异。

口径怎么执行

隔离工作区

终端执行 git worktree add；每个 worktree 目录单独开 Agent 对话

任务绑定

对话 A 只打开 feat/tags 目录做标签；对话 B 只打开 feat/export 做导出——禁止两个对话指向同一工作区

合入口径

回主仓库 git merge；若冲突，对新对话说「只解决冲突，不改业务逻辑」

操作

git worktree add ../todo-tags -b feat/tags git worktree add ../todo-export -b feat/export 分别在两个目录打开项目 / 开对话；用 git worktree list 确认隔离生效。

练习

前置：项目已 git init 且至少有一次干净提交。① 同一目录开两个对话，同时改同一文件——观察是否互相覆盖（反面验证）。② 按上面命令建两个 worktree，各开对话分别做「标签」和「导出 JSON」。

**问自己：**两边 git status 是否互不影响？若在同一工作区并行，会发生什么？

场景 5：安全合规（高危操作审批）

Harness 组件 → 权限与门禁

**问题：**模型「能调用」不等于「该自动执行」——Delete、force push、清库、改生产配置等一旦误触，代价极高。

**解法：**高危操作的验收口径 =「必须等人批」：权限档位 + 规则黑名单双保险。

口径怎么执行

权限档位

Manual / Ask：弹出确认后再执行；Plan = 只方案不动手；Auto = 策略评估后放行

规则黑名单

规则写明：「未获确认前，禁止删除文件、git push、git reset --hard、修改 .env」

实操验证

发送高危请求后，观察是否先复述风险并等待你点「允许 / 拒绝」——能做 ≠ 被允许自动做操作

右上角 / 设置里把权限切到 Ask → 对可丢弃文件发删除指令 → 在确认框点「拒绝」，验证 Agent 是否停下。

练习

① 新建可丢弃文件 tmp-harness-demo.txt（禁止拿真实重要文件练）。② 权限切到 Ask / Manual，发送：「删除 tmp-harness-demo.txt，然后 commit。」③（可选）规则加写高危操作黑名单。

**问自己：**删除是否弹出确认？你点拒绝时它有没有停下？「能做」和「被允许自动做」差在哪？

收束：这就是 Harness 工程

把五个场景串起来看：我们并不是在调模型本身的「智商」，而是在模型外围搭了一整套缰绳——

上下文工程架构文档、规范、规则、按模块拆窗口喂证据

架构/规范约束分层、命名、风格；写成文档与机器可检规则

结果校验测试通过再提交；用命令与门禁验证「真的做对」

流程编排Plan → Build；复杂任务拆分与并行隔离（Worktree）

权限门禁高危操作人工审批

Harness 原意是「马具」（缰绳、马鞍）。把大模型比作一匹力大但易跑偏的马：Model 负责智能（理解、推理、生成）；Harness 是模型之外的一切——规则、工具、流程、检查与审批——让它按方向稳定跑完长距离任务。

它没有唯一标准答案。目标只有一句：

让大模型每一次执行的结果 都可控、稳定、符合预期。

— END —