把规范写成 Harness：比“写更长 Prompt”有效 10 倍

很多人在大模型落地的早期阶段，通常会先从 Prompt 入手做控制：
当输出不稳定时，就逐步补充一些期望与限制（例如输出格式、边界条件等），
希望让结果更接近可交付标准。

但问题来了：Prompt 越写越像“临时补丁”，越难复用、越难追溯。

我后来得到一个工程化的实作结论：

Prompt 负责“方向”就好(不需要多），
真正决定输出是否可复用、可追溯、可复现的，是 注入Harness（约束护栏）。

1) Prompt 和 Harness 各自负责什么？

• Prompt ：告诉模型“要做什么/往哪个方向推理”
  例如：把需求转成模块清单、把 spec 输出成 JSON、列出 API 草案等。
• Harness ：告诉模型“必须遵守哪些规则/输出必须满足什么约束”

  例如：
  -输出必须是单一 JSON object（不能夹解释文字）
  -必须符合 schema（字段、类型、必填项）
  -对关键边界要有明确说明（范围、假设、错误处理）
  -对“写入类”场景要考虑一致性与可追溯性（最小化要求即可）

一句话总结：Prompt 让模型“会写”，Harness 让模型“写得对、写得稳”。

2) 为什么“Prompt 叠加控制”容易走向瓶颈

因为 Prompt 做工程治理有三个天然缺陷：

• 难复用 ：每个任务都要重写控制点，换项目就得再补一次
• 难审计 ：项目很难对齐“哪些约束是强制的、哪些只是建议”
• 难追溯 ：输出漂移了，难定位是模型、或输入，或 Prompt 某句影响了结果

当你的控制策略只存在于 Prompt 里，就变成“经验写作”，而不是“工程规则”。

3) Harness 的价值：把“项目共识”变成可执行护栏

当你把规范写成 Harness（文件化、结构化），会立刻得到四个工程收益：

• 可复用 ：下一次任务不用再“凭感觉写 Prompt”，直接复用同一套规则
• 可复现 ：相同输入 + 相同 Harness = 可复刻同样的生成链路
• 可追溯 ：失败时能定位到“超时/截断/非 JSON/不符合 schema”等明确原因
• 可迭代 ：规则变更只改 Harness，不需要把一堆 Prompt 全部重写

这就是“有效 10 倍”的原因：
它不是让输出更华丽，而是让输出 更稳定、更可控、更可交付 。

4) Harness 到底能“管什么”？

很多人一听 Harness，会以为它只是“让模型按 JSON 输出”，这仅算入门。

真正的 Harness，是把你项目里 “所有想要执行的工程要求” ，
从“人的经验/口头约定”变成“大模型必须遵守的项目护栏集合”。

按工程维度拆开，Harness 目录通常可以包含这些东西(不止这些)：

• 交付物形态（最表层）
• 输出结构与模板（spec 必须有哪些章节/字段）
• JSON schema / 表格字段约束 / 必填项
• 命名规范（字段名、模块码、文件名、路径风格）
• API 与接口契约（最常用、最能减少扯皮）
• 路径风格、版本策略、错误码格式
• 请求/响应字段约定、分页/排序/过滤惯例
• 幂等键、重试策略、超时策略

5) “按需注入”：Harness 越强，越不能一次性全塞

当你把 Harness 从升级为“项目级治理体系”后，一个现实问题就出现了：

Harness 会越来越大、越来越多、越来越细 。这时候如果还沿用“把所有规则一次性塞给模型”的做法，反而会带来新的不稳定???

按需注入不是优化项，而是 Harness 体系化之后的必选项

• 上下文拥挤 ：规则越多，模型越容易“挑着做”，甚至忽略关键约束
• 成本上升 ：输入越长，token 消耗越高，延迟越长，更容易触发截断与超时
• 冲突风险 ：不同规则域的约束并不同时适用，混在一起会互相打架
• 可追溯性变差 ：出问题，你很难判断哪个约束注入不对/注入过量/注入缺失

按需注入的核心思想

把 Harness 当作“可组合的约束模块”，每次调用只注入与当前任务强相关的子集，让模型在更清晰的护栏里收敛输出。

• 做“模块规划”时：重点注入交付物结构治理 + 领域词典治理
• 做“接口草案”时：重点注入工程接口契约治理 + 安全与权限治理
• 做“写入类流程设计”时：重点注入一致性与事务治理 + 幂等/失败处理
• 做“交付前检核”时：重点注入可观测与运维治理 + 审计口径 + 规范检查清单

一句话总结这一段：
Harness 决定你能管到什么程度；按需注入决定你能不能在不失控的情况下，把这些约束真正用起来。

6) 与大模型交互要学会“无状态+按需注入”

当你开始把规范写成 Harness，你会发现一件很关键的事：

你不是在“调教模型”，你是在“建设工程系统”。
Prompt 再精致，也只是一次性的对话控制；
Harness 才是可版本化、可复用、可审计的工程资产。

它会随着项目迭代不断沉淀，最终变成项目的“隐性经验”转为“显性护栏”。
更重要的是：
Harness 一旦建立，你就获得了三个长期收益——

• 规模化： 新需求复用既有约束组合，产出质量随时间越来越稳
• 做“接口草案”时：重点注入工程接口契约治理 + 安全与权限治理
• 可交付： 输出可验收的工程契约”（结构、边界、错误处理、可追溯）
• 可协作： 团队规则文件怎么写、怎么版本化、怎么按需注入 。

所以一句话总结这篇文章的核心立场：
Prompt 决定你能跑多快，Harness 决定你能跑多远。

当你期待大模型的产出是可复现时, 其实外部 Harness 已经决定这次输出是否在可预期之内 !!!