# 业务目标与全局 Harness

## 1. 业务问题

上游每天产生大量需求词和关联数据，来源包含内部、外部、近期、持续、周期和内容后验等不同维度。这些信号彼此交织，但含义保持正交。

系统不能只做词语归类，也不能只生成一批模型文案。它需要把原始信号稳定转化为平台可以持续使用的需求资产，并通过真实内容表现不断校正判断。

## 2. Harness 的定义

本项目中的 Harness 是一套每天自动运行的业务控制结构。它负责：

- 约束各模块只能在自己的边界内工作；
- 规定模块之间交换什么业务产物；
- 保留每一步的输入、输出、reason 和策略版本；
- 让你参与定义规则，而不参与实现和每日执行；
- 让模型行为受数据证据和业务定义约束；
- 让失败、冲突、拒绝和未知状态也可查询；
- 将下游内容结果和线上表现带回下一日评估。

## 3. 推荐结构

采用“C 分层控制闭环为主干，B 事件机制为变化入口”的结构。

- 分层控制闭环保证每日结果稳定、可比较、可追溯。
- 事件机制接收外部信号、人工反馈、内容发现和真实表现。
- 事件不能直接越过模块边界修改正式需求，只能成为新证据或明确的管理指令。

核心结构：

```text
业务协作与策略控制
          ↓
证据收集 → 需求认知 → 评估分配 → 发布、解释与反馈
                                      ↓
                           人 / 寻找 Agent
                                      ↓
                                 内容承接
                                      ↓
                                 真实表现
                                      ↺ 次日证据
```

## 4. 每日核心业务产物

### 4.1 每日证据包

当天全部原始信号及其来源、时间、维度、指标、内容、关系和质量状态。

### 4.2 每日需求认知版本

当天形成的标准需求词、平台需求、层级、多点挂靠、关系和 reason。

### 4.3 每日评估结果

每条需求的需求成立度、局部供给优先级、置信度、行动层和变化原因。

### 4.4 每日需求任务包

两个下游共同消费的唯一标准输出。寻找 Agent 使用结构化执行视图，人使用自然语言理解和反馈视图。

### 4.5 每日决策账本

记录运行批次、策略版本、候选接受与拒绝、模块过程、异常、人工操作和最终发布结果。

## 5. 系统边界

### 5.1 系统负责

- 每日自动采集、认知、评估、分配和发布；
- 基于数据生成 reason；
- 形成可查询的历史过程；
- 自动分析需求变化；
- 生成两个下游视图；
- 接收人和 Agent 的反馈；
- 归因内容表现并进入次日闭环。

### 5.2 你负责

- 定义什么是需求；
- 定义有效来源、维度和业务口径；
- 定义合并、拆分、多挂靠和关系原则；
- 定义评价、行动层、探索和后验规则；
- 审核重要定义变更；
- 对系统无法自行判断的业务冲突作最终裁决。

### 5.3 系统不负责

- 脱离数据自由推演正式需求；
- 用模型常识覆盖上游事实；
- 将一次内容失败直接解释为需求不存在；
- 无记录地修改历史、定义或评分；
- 让某个下游私自维护另一套需求口径。
