Jev 系统架构师

Jev 系统架构师 是做什么的？

目的

运用此技能来确定：

1. Jev 是否应被纳入系统
2. Jev 的边界应精确划在哪里
3. 哪些判断应转化为 Choice、Score 或 Noul 问题
4. 每个判断应看到什么状态
5. 哪些问题应同时运行
6. 普通代码应如何组合结果
7. 不确定性应如何改变系统行为
8. 在生产使用前应如何评估集成效果

这主要是一项架构和分解技能。

有关确切的 SDK 语法、请求/响应字段、模型、限制或特定版本的 API 行为，请阅读当前的 TypeSafe 文档，并在可用时使用 TypeSafe 的官方代理技能。

不要发明 API 字段。

---

核心思维模型

Jev 不是应用程序。

Jev 不是工作流引擎。

Jev 不是自主代理。

首选的架构是：

应用程序状态
      ↓
有界语义问题
      ↓
     JEV
      ↓
类型化判断 + 概率
      ↓
确定性应用程序代码
      ↓
路由 / 排序 / 验证 / 询问 / 升级 / 执行

模型提供可编程的判断。

代码拥有：

• 控制流
• 权限
• 计算
• 确定性规则
• 持久化
• 事务
• 副作用
• 工具执行
• 授权
• 策略执行

仅在普通软件需要对非结构化或模糊信息进行语义理解时才使用 Jev。

---

触发条件

当系统包含类似以下形状的边界时，考虑使用 Jev：

非结构化或上下文信息
                ↓
     需要进行有界判断
                ↓
 软件需要一个类型化值才能继续

强候选包括：

• 意图分类
• 语义路由
• 内容审核决策
• 文档分类
• 证据验证
• 引用检查
• 语义护栏
• 风险信号
• 消息解释
• 候选选择
• 排序维度
• 相关性判断
• 情绪或紧急性
• 用户请求解释
• 工具/函数选择
• 从已知候选集中提取
• RAG 段落过滤
• 工作流分类
• 质量判断
• 策略与案例比较
• 模糊匹配
• 实体对齐
• 升级决策

同时检查代码中是否存在以下症状：

LLM → 散文 → 解析器 → JSON → 验证 → 重试

或：

大型正则树
庞大的 if/else 语义分类器
返回任意 JSON 的基于提示的分类器
仅用于做出有界决策的代理循环
用于简单分类的昂贵推理模型

这些是潜在的 Jev 插入点。

---

默认不使用 Jev

优先对以下情况使用普通代码：

• 算术
• 已在结构上表示的确切日期
• 数据库查找
• 精确字符串匹配
• 权限
• 授权
• 模式验证
• 确定性业务规则
• 已知变换
• 对已知数字排序
• 加密操作
• 能可靠解决问题的精确解析器

当所需输出本质上是开放式的时，优先使用生成模型：

• 写作
• 摘要
• 解释
• 头脑风暴
• 代码生成
• 长文综合
• 开放式研究
• 多步推理

Jev 可以通过在它们周围做出有界决策来支持这些系统，但不应被迫扮演生成角色。

---

步骤 1 — 寻找判断边界

检查从输入到输出的工作流。

标记每个软件实际上在问以下问题的点：

“我有信息，但我需要理解它的含义，然后才能知道走哪条确定性路径。”

对于每个候选边界，写出：

输入状态： 存在什么信息？

判断： 需要什么语义确定？

输出： 什么有界值能让代码继续？

动作： 代码将用答案做什么？

风险： 如果判断错误会发生什么？

不要立即实现 Jev。

首先确定确定性代码是否能更可靠地解决问题。

---

步骤 2 — 应用 Jev 适合性测试

当大多数以下条件成立时，判断是 Jev 的强候选：

• 输入包含自然语言或上下文数据。
• 所需输出可以是有限的。
• 软件需要以编程方式获取答案。
• 知识渊博的人可以快速做出判断。
• 可以明确描述判断。
• 不确定性是有用的信息。
• 可以针对示例或标签测试结果。
• 代码可以在判断后掌握动作。

当任务需要以下内容时，请保持怀疑：

• 深入思考
• 长推理链
• 许多依赖的中间结论
• 开放式生成
• 自主规划

先进行分解。

---

步骤 3 — 使问题原子化

一个 Jev 问题应代表一个连贯的判断。

不好的例子：

分析此客户，并确定我们是否应退款、他们有多生气、是否存在欺诈可能性以及应由哪个部门处理此案。

更好的例子：

• topic → Choice
• refund_requested → Noul
• fraud_signal → Noul
• frustration → Score

然后在代码中组合这些答案。

目标是：

复杂行为 = 许多小判断 + 确定性组合

当代码可以显式表达策略时，不要将应用程序策略隐藏在一个巨大的语义问题中。

---

步骤 4 — 选择正确的原语

Choice

当应从定义的集合中选择一个确切的答案时使用。

形式：哪一个？

示例：

• 计费 | 技术 | 销售 | 账户
• 退款 | 重新预订 | 信息
• python | javascript | rust | 其他

当提供的选项可能无法涵盖输入时，添加一个“其他”、“未知”或“无”的结果。

Noul

用于其真实性概率有用的命题。

形式：这是真的吗？

示例：

• 客户要求退款吗？
• 此段落回答了用户的问题吗？
• 此消息要求提供凭证吗？
• 简历中说明具有专业的 Python 经验吗？

将输出解释为“是”的概率。

不要将 ~0.5 解释为“中等强度”。

这意味着“是”和“否”的可能性大致相等。

Score

当判断存在于有序维度上时使用。

形式：状态落在该定义光谱的哪个位置？

示例：

• 冷静 / 担心 / 非常沮丧
• 不相关 / 部分相关 / 强相关 / 直接答案

每个级别应描述一个具体的语义条件。

除非其含义被明确定义，否则避免使用未定义的标签，如“差/可以/好/优秀”。

---

步骤 5 — 有目的地设计状态

发送包含回答问题所需证据的最小状态。

优先使用结构化状态：

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

而不是一大段散文。

原则：

• 相关 > 全面
• 结构化 > 扁平化
• 观察到的事实 > 假定的模型知识
• 当前信息 > 过时的嵌入知识

保持观察到的事实与推断的判断可区分。

当问题涉及特定的状态字段时，明确指向这些字段。

---

步骤 6 — 并行提出独立问题

如果多个问题可以从相同的现有状态中得到回答，则优先同时提出它们。

                    ┌── topic
                    ├── urgency
STATE ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

不要创建不必要的串行调用，例如：

Jev → answer → Jev → answer → Jev → answer

当所有三个问题都可以从原始状态评估时。

在投机性问题代价较低且以后可能有用的前提下提出它们。

示例：category、bug_severity、reproduction_quality、refund_requested、frustration

如果 category = billing，代码只需忽略特定于错误的答案。

---

步骤 7 — 仅在存在真实依赖关系时使用多个 Jev 阶段

仅当第一个答案需要以下内容时，才证明第二个 Jev 请求是合理的：

• 获取新证据
• 构造新状态
• 选择下一个候选集
• 确定可以有意义地提出哪些问题
• 遍历层次结构
• 检索下一个判断所需的文档

示例：

步骤 1  哪个产品系列？
   ↓
代码检索该系列中的产品
   ↓
步骤 2  哪个确切产品最匹配？

不要仅仅因为工作流在概念上包含几个步骤就将问题串行化。

---

步骤 8 — 将组合逻辑保留在代码中

Jev 产生语义信号。

代码决定这些信号在操作上的含义。

示例：

topic = billing
refund_requested = 0.94
frustration = high

应用程序代码可以决定：

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

业务逻辑应保持可检查性。

当答案可以从更小的判断构建时，不要问 Jev“我们的整个应用程序应该做什么？”

---

步骤 9 — 将不确定性视为一等信号

绝不要将类型化输出视为等同于事实。

类型化输出意味着接口是受限的。

这并不意味着语义判断不可能出错。

对于 Choice 和 Score，检查概率和置信度。

对于 Noul，直接检查“是”的概率。

设计类似以下的行为：

• 高确定性 → 自动化路径
• 中等确定性 → 请求确认 / 收集更多证据 / 更强的模型 / 标记以供审查
• 低确定性 → 不要猜测 / 升级

阈值是应用程序策略。

它们必须反映误报/漏报的成本、可逆性、用户/财务/安全/监管影响。

从示例中复制的阈值不能证明它适用于此系统。

---

步骤 10 — 将置信度门控与风险相匹配

不要使用一个通用的置信度阈值。

示例：

• show_help_article — 低后果
• route_support_ticket — 中等后果
• cancel_subscription — 较高后果
• move_money — 非常高后果

语义判断可能相同，而所需的确定性和确认路径不同。

对于后果重大的操作，Jev 通常应告知受控的决策边界，而不是独立授权副作用。

---

步骤 11 — 在自动化之前设计评估

在生产化 Jev 边界之前，确定代表性案例。

包括：简单正例、简单负例、模糊案例、缺少证据的案例、边缘案例、对抗案例、罕见但代价高昂的失败案例。

记录：状态、问题、预期行为、Jev 答案、概率/置信度、应用程序操作、可用时的真实结果。

评估系统行为，而不仅仅是查看顶级标签是否看起来合理。

对于带阈值的系统，在几个阈值上测量行为。

特别测量：覆盖率/自动化率、误报率、漏报率、人工审查率、错误成本、延迟、成本。

使用实际目标领域数据调整阈值。

---

步骤 12 — 集中管理 Jev 策略

使 Jev 问题、标准、权重和阈值常量易于查找和审查。

优先采用类似以下的结构：

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

或项目相应的等效结构。

不要将语义策略分散在数十个路由处理程序中。

人类审查者应能检查：

• Jev 在判断什么？
• 我们给了它什么定义？
• 什么阈值会触发什么动作？
• 哪些动作是可逆的？
• 当置信度低时会发生什么？

---

步骤 13 — 保留原始判断

在可行的情况下，将有用的原始输出与从中推导出的操作分开保留。

例如：

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

而不是仅存储 priority = high。

这允许重新评估阈值、更改权重、审计行为、比较模型版本、调查失败以及下游分析。

不要保留超出应用程序合理要求的敏感数据。

---

步骤 14 — 在生成式 AI 周围寻找 Jev

Jev 通常在 LLM 周围有价值，而不是取代它。

示例：

输入 → Jev 护栏 → LLM → Jev 引用/质量验证 → 代码决定是否返回

或：

查询 → 检索 → Jev 相关性/注入判断 → 选择的上下文 → 推理模型

或：

用户请求 → Jev 意图/函数选择 → 确定性类型化函数 → 结果

这可以减少委托给开放式生成模型的应用程序控制量。

---

架构审查程序

当被要求审查现有系统以寻找 Jev 机会时：

1. 映射工作流

识别：输入、确定性步骤、语义决策、模型调用、解析器、路由器、工具调用、副作用、人工审查点。

2. 生成 Jev 机会映射

对于每个候选：

• 位置： 当前代码/模块/工作流
• 当前方法： 今天如何做出判断
• Jev 候选： 是 / 否 / 可能
• 原因： 为什么有界语义决策合适或不合适
• 状态： 所需的最小证据
• 原语： Choice / Score / Noul
• 问题： 提出的原子判断
• 组合： 代码应如何使用它们
• 不确定性： 当答案不清楚时会发生什么
• 风险： 错误判断的后果
• 评估： 如何验证它

3. 按杠杆效应排序

优先选择 Jev 可以取代脆弱语义代码、重复 LLM 解析、昂贵的小事推理调用、无界代理循环、重复分类器或明显案例的人工审查的机会——同时保持系统行为有界且可测试。

4. 建议最小的 v

……