从 Harness 到 Fulfillment：交付层为什么必须前移

这是一篇用于验证 mason-wechat-article-pipeline 的真实草稿箱测试稿。
内容来源于 Obsidian 笔记，不是临时手写占位文。
核心目的，是验证一条从 obs 笔记到微信公众号草稿箱的稳定发布链。

这条笔记不是在复述通用 Harness 理论，也不是在记录 AI 自己的抽象定义。

这是基于长期 AI coding 过程里的真实交付体感，整理出来的一套交付层判断：

在真实交付里，真正决定效率的，往往不是写代码本身，而是测试链、部署链、环境链是否先被打通。

我的体感比例一直很稳定：

如果 Harness 只讨论上下文、约束、熵管理，却不把测试与部署当成第一公民，那它就还停留在概念层，不是交付层。

一、前几个阶段为什么都不够

1. TDD 解决的是代码正确性，不是交付正确性

TDD 很重要，但它主要解决的是：

它没有天然解决这些问题：

所以 TDD 是必要的，但只够管住“代码”，管不住“交付”。

2. Prompt Engineering 解决的是表达，不是执行系统

提示词工程阶段的核心关注点是：

它的问题是过于聚焦单次交互，容易忽略：

所以提示词工程解决的是“怎么说”，不是“怎么交付”。

3. Context Engineering 解决的是让模型知道更多，不是让系统完成更多

上下文工程往前走了一步，它强调：

但它仍然默认了一个前提：

只要模型知道得够多，它就能更好地完成任务。

真实问题是，很多时候模型不是“知道得不够多”，而是：

也就是说，上下文工程解决的是“看见什么”，不是“打通什么”。

二、Harness 更接近真实工程，但仍然偏模型治理

Harness 比前几代更成熟，因为它开始讨论：

但它在很多文章里的默认重心，仍然是：

这当然对，但它仍然容易低估真实项目里最重的部分：

所以通用 Harness 仍偏“治理 AI”，而不够偏“完成交付”。

三、我更想推进的东西：Fulfillment

如果只继续放大 Harness，还是不够。

我更想推进的是一个更贴近生产现实的判断：

Fulfillment 不是让 AI 更会写，而是让需求真的进入生产完成态。

它的核心不是：

而是：

一句更锋利的话就是：

真正的 AI 工程，不对代码负责，只对 Fulfillment 负责。

四、为什么可重建性必须被拉进来

如果只谈测试、部署、验收，还不够。

因为还有一个更深的问题：

这套系统能不能被重新搭起来。

这意味着我们不能再把关键知识藏在：

它必须被显式化成：

也就是说，未来真正值钱的不是“某次我搞定了”，而是：

我把这件事压成了别人也能重建的资产。

五、这篇测试稿真正要验证什么

这次我不是只想发一篇文。

我真正要验证的是：

  1. 1. obs 笔记能不能稳定转成公众号长文源稿
  2. 2. 固定头图、正文图、固定尾图能不能被 manifest 锁住
  3. 3. Wenyan + inline HTML 链路能不能稳定产出可发布正文
  4. 4. 80 机白名单代发能不能把它送进 Mason说科技 草稿箱
  5. 5. draft/add -> draft/batchget -> receipt -> ontology 这一整条链能不能形成真实闭环

如果这次闭环成立，那 mason-wechat-article-pipeline 才算真的被验证过，而不是“看起来能用”。

六、最后一句

从今天开始，公众号发文这件事，不该再是一次次临时手工操作。

它应该变成一条可验证、可回查、可修补、可重跑的发布链。

而这条测试稿本身，就是对这件事的第一次真实验证。