过去两年,AI 行业经历了一场静悄悄的范式转移。
2023 年,所有人都在讨论「AI 如何理解人类意图」——我们期待模型能读懂模糊的需求、补全缺失的上下文、容忍随意的表达。那时的产品逻辑是 让 AI 适应人。
到了 2026 年,现实给出了不同的答案。在钉钉推进 AI 落地的过程中,我们观察到一个清晰的趋势: 高效使用 AI 的团队,不是那些等待模型更聪明的人,而是那些主动调整自身行为模式去适配 AI 能力边界的人。
这不是妥协,而是杠杆。
从「理解人类」到「人类适配」的范式转变
早期 LLM 产品的叙事是「自然语言即界面」。理论上很美,工程上却遇到了硬约束:
| 维度 | 期望(2023) | 现实(2026) |
|---|---|---|
| 意图理解 | 模糊指令 → 精准执行 | 模糊指令 → 随机输出 |
| 上下文 | 无限记忆 | 有限窗口 + 注意力稀释 |
| 稳定性 | 一次成功 | 需要迭代与验证 |
| 成本 | 忽略不计 | Token 经济学成为硬约束 |
当模型能力增长曲线遇上真实业务场景的复杂度,一个工程事实浮出水面: 提升输出质量最快的路径,不是等模型升级,而是优化输入质量。
这就是「主动适应」的起点。下面通过两个真实工作流案例,展开说明这种适应是如何发生的。
案例一:会议纪要工作流 —— 钉钉 A1 生成 + 悟空纠错
问题:单模型无法兼顾速度与精度
钉钉 A1 的会议纪要能力很强:实时转录、说话人分离、要点提取,端到端延迟控制在秒级。但在实际使用中,我们发现一个系统性问题:
A1 擅长「快」,但不擅长「准」。
具体表现:
- 技术术语识别错误(如将
gRPC听成G R P C,将K8s展开为Kubernetes但上下文丢失) - 决策与讨论混淆(把「我们考虑一下」记成「已决定」)
- 行动项遗漏(尤其是非明确指派的隐性任务)
如果等待 A1 的模型升级,周期是月级。但如果 主动适应 AI 的能力分布,解决方案就在眼前。
工作流设计:两阶段流水线
[会议音频]
↓ (实时转录,低延迟)
[钉钉 A1] → 初版纪要(速度快,80% 准确)
↓ (异步处理,高推理)
[悟空 Agent] → 纠错 + 补全 + 结构化(精度高,95%+ 准确)
↓ (人工确认)
[最终纪要] → 归档 + 待办分发
关键设计决策:
- 不要求 A1 做它不擅长的事。A1 的职责被明确限定为「快速生成草稿」,而非「输出最终结果」。
- 悟空作为纠错层。悟空(Hermes Agent)接入会议上下文(议题、参会人背景、项目文档),对 A1 的输出进行二次推理:
- 术语校正:对照项目词汇表修正识别错误
- 意图消歧:区分「讨论」「决策」「待办」
- 行动项提取:基于角色与上下文推断隐性任务
- 人类角色变为「确认者」。最终输出只需人类快速扫读确认,而非逐字校对。
悟空纠错层的 Prompt 工程
from dataclasses import dataclass
from typing import Optional
@dataclass
class MeetingCorrectionPrompt:
"""悟空纠错层 Prompt —— 人类为 AI 设计的验证协议"""
project_context: str # 项目背景、技术栈、关键术语表
participants: list[str] # 参会人及其角色
a1_draft: str # A1 生成的初版纪要
known_decisions: list[str] # 会前已知的决策点
def render(self) -> str:
return f"""## Role
你是会议纪要纠错专家。你的任务是对钉钉 A1 生成的初版纪要进行精确校正。
## Project Context
{self.project_context}
## Participants
{chr(10).join(f"- {p}" for p in self.participants)}
## A1 Draft
{self.a1_draft}
## Correction Rules
1. **术语校正**:对照项目上下文修正技术术语。保留原始缩写,不要过度展开。
2. **意图分类**:将每条内容标记为 [讨论] / [决策] / [待办]。
- 只有明确说"我们决定""就这么做"的才算 [决策]
- "考虑一下""后续看看"属于 [讨论]
3. **行动项提取**:识别所有待办,包括隐性指派。
- 格式:[待办] 任务描述 @负责人 (截止日期)
4. **不要添加 A1 未提及的内容**。你的职责是纠错,不是创作。
## Output Format
按以下结构输出:
### 校正后的纪要
(逐条列出,标注 [讨论]/[决策]/[待办])
### 变更说明
(列出你做了哪些校正及原因)
"""
# generated by hugo AI
这个 Prompt 的本质是 人类主动为 AI 定义验证边界。不是让悟空「自由发挥」,而是给它一个精确的纠错协议。这就是「适应」:人类学习如何向 AI 发送可验证的指令。
效果与成本
| 指标 | 单用 A1 | A1 + 悟空 | 纯人工 |
|---|---|---|---|
| 端到端时间 | 2 分钟 | 5 分钟 | 30 分钟 |
| 准确率 | ~80% | ~96% | ~98% |
| 人类介入时间 | 10 分钟校对 | 2 分钟确认 | 30 分钟 |
| Token 成本 | 低 | 中(纠错层 ~2K tokens) | N/A |
关键洞察: 两阶段工作流的总成本低于单模型反复迭代。A1 的快 + 悟空的准,组合起来比任何单模型都划算。
案例二:个人知识管理工作流 —— 钉钉收集 + 悟空编译
问题:知识碎片化与 AI 幻觉
个人知识管理的经典困境:
- 信息散落在聊天记录、文档、邮件、网页
- 收藏 ≠ 掌握,多数内容再也没看过
- 用 AI 总结?容易产生幻觉,丢失关键细节
2024 年的做法是让 AI 直接总结一堆链接。结果:摘要看起来流畅,但细节经不起推敲,引用不可追溯。
主动适应的思路是:不把 AI 当「总结器」,而是当「编译器」。
工作流设计:收集 → 编译 → 查询
[日常收集阶段]
钉钉聊天记录 ─┐
钉钉文档 ├→ [钉钉收藏/标签] → 原始素材池(未处理)
网页剪藏 ┘
[编译阶段](每日/每周触发)
原始素材池
↓ (提取、去重、关联)
[悟空 Agent] → 结构化知识库(Markdown + 向量索引)
↓ (生成元数据)
[知识图谱] → 标签、关联、时间线
[查询阶段]
自然语言提问
↓
[悟空 RAG] → 基于编译后知识库的回答(可追溯引用)
人类适应的关键设计
1. 收集阶段:人类定义「什么值得保存」
AI 无法自动判断信息的价值。人类需要主动建立收集规则:
from dataclasses import dataclass
from enum import Enum
class ContentType(Enum):
DECISION = "decision" # 决策记录
INSIGHT = "insight" # 洞察/经验
REFERENCE = "reference" # 参考资料
PROBLEM = "problem" # 问题与解法
@dataclass
class CollectionRule:
"""人类定义的收集规则 —— 价值判断仍由人完成"""
content_type: ContentType
trigger_keywords: list[str]
source: str # 钉钉群/文档/网页
retention_days: int
def should_collect(self, text: str) -> bool:
return any(kw in text for kw in self.trigger_keywords)
# 示例规则
RULES = [
CollectionRule(
content_type=ContentType.DECISION,
trigger_keywords=["决定", "确定", "方案", "结论"],
source="钉钉项目群",
retention_days=365
),
CollectionRule(
content_type=ContentType.PROBLEM,
trigger_keywords=["报错", "解决", "排查", "原因"],
source="钉钉技术群",
retention_days=180
),
]
# generated by hugo AI
适应点:人类不再期待 AI 自动发现重要信息,而是主动定义收集规则。AI 只负责执行规则。
2. 编译阶段:悟空作为「知识编译器」
编译器的核心职责不是总结,而是 结构化 + 可追溯:
@dataclass
class KnowledgeCompilationPrompt:
"""悟空知识编译 Prompt —— 将碎片信息编译为结构化知识"""
raw_materials: list[dict] # 原始素材:{source, content, timestamp, author}
existing_knowledge: str # 已有知识库(用于去重与关联)
def render(self) -> str:
materials_str = "\n\n".join(
f"### 素材 {i+1}\n来源: {m['source']}\n时间: {m['timestamp']}\n"
f"作者: {m['author']}\n内容:\n{m['content']}"
for i, m in enumerate(self.raw_materials)
)
return f"""## Role
你是知识编译器。你的任务是将碎片化信息编译为结构化、可追溯的知识条目。
## Raw Materials
{materials_str}
## Existing Knowledge Base
{self.existing_knowledge}
## Compilation Rules
1. **不丢失细节**:保留原始数据、代码片段、关键引用。不要过度概括。
2. **可追溯**:每条知识必须标注来源(素材编号)。
3. **去重与合并**:如果与已有知识重复,标注为 [更新] 或 [补充]。
4. **结构化输出**:每条知识按以下格式:
### [类型] 标题
- **来源**:素材 X
- **时间**:YYYY-MM-DD
- **上下文**:(简要说明背景)
- **内容**:(保留原始细节)
- **关联**:(指向相关知识条目)
- **标签**:#tag1 #tag2
5. **不添加原始素材中不存在的内容**。如果信息不完整,标注 [待补充]。
## Output
按上述格式输出编译结果。
"""
# generated by hugo AI
适应点:人类为 AI 定义了严格的编译规则——不创作、不概括、可追溯。这就像编译器不会改变程序语义,只会优化表示形式。
3. 查询阶段:RAG + 可追溯引用
编译后的知识库支持精确查询:
用户:"上次我们讨论 gRPC 超时问题的结论是什么?"
悟空 RAG:
→ 检索编译后的知识条目
→ 返回:
[决策] gRPC 超时配置方案
来源:素材 3(钉钉技术群 2026-05-12)
结论:统一使用 30s 默认超时,关键路径配置 60s
关联:[问题] gRPC 超时导致级联故障(素材 2)
关键区别:回答不是 AI 生成的「流畅摘要」,而是 对编译后知识的精确检索。幻觉率从 ~15% 降至 <2%。
效果对比
| 维度 | 传统收藏 | AI 直接总结 | 钉钉收集 + 悟空编译 |
|---|---|---|---|
| 信息保留度 | 高(但从不看) | 低(丢失细节) | 高(结构化保留) |
| 可追溯性 | 无 | 弱 | 强(来源标注) |
| 幻觉率 | N/A | ~15% | <2% |
| 查询效率 | 低(手动翻找) | 中(模糊匹配) | 高(向量 + 标签) |
| 人类投入 | 收藏 1 秒 | 无 | 定义规则 30 分钟/周 |
案例三:反馈驱动进化 —— 钉钉与悟空的强化学习闭环
前两个案例展示了人类如何主动适应 AI 的能力边界。但故事没有到此为止。 适应的更高阶段,是人类通过自然行为为 AI 提供反馈信号,驱动系统持续进化。
这就是从「人类适应 AI」到「AI 通过人类反馈加速进化」的闭环。
问题:模型迭代周期太长
传统模型升级路径:
收集数据 → 人工标注 → 微调训练 → 评估上线
周期:4-8 周
成本:标注 + 算力 + 工程
这个路径的问题是: 反馈延迟太长,标注成本太高,且标注质量不稳定。
但在钉钉和悟空的真实使用场景中,用户每天都在产生高质量的反馈信号——只是过去没有被系统化采集和利用。
自然反馈信号:用户行为即标注
用户在钉钉和悟空中的每一个交互行为,都隐含着对 AI 输出质量的评价:
| 用户行为 | 隐式反馈信号 | 奖励值 |
|---|---|---|
| 直接采纳 AI 输出(无修改) | 高质量 | +1.0 |
| 轻微修改后采纳 | 基本可用,需微调 | +0.5 |
| 大幅重写 | 方向对但质量差 | +0.1 |
| 完全忽略/重新生成 | 低质量/错误 | -0.5 |
| 点赞/收藏 AI 输出 | 超预期 | +1.5 |
| 举报/标记错误 | 严重错误 | -1.0 |
| 多次追问同一问题 | 首次回答不充分 | -0.3 |
关键洞察:这些信号不需要用户额外操作,而是从自然使用行为中提取的。用户不需要「标注数据」,他们只需要正常使用产品。
钉钉会议纪要场景的反馈采集
from dataclasses import dataclass
from enum import Enum
from datetime import datetime
class FeedbackType(Enum):
ACCEPTED_DIRECTLY = "accepted" # 直接采纳
ACCEPTED_WITH_EDITS = "edited" # 修改后采纳
REGENERATED = "regenerated" # 重新生成
IGNORED = "ignored" # 忽略
LIKED = "liked" # 点赞
REPORTED = "reported" # 举报错误
@dataclass
class MeetingFeedbackSignal:
"""从钉钉会议纪要工作流中采集的反馈信号"""
meeting_id: str
output_id: str # AI 输出版本 ID
feedback_type: FeedbackType
edit_distance: float # 修改幅度(0-1,0 为无修改)
user_role: str # 反馈者角色(主持人/参会人)
timestamp: datetime
context: dict # 上下文:会议类型、时长、参会人数等
def to_reward(self) -> float:
"""将反馈行为转化为奖励值"""
base_rewards = {
FeedbackType.ACCEPTED_DIRECTLY: 1.0,
FeedbackType.ACCEPTED_WITH_EDITS: 0.5,
FeedbackType.REGENERATED: -0.5,
FeedbackType.IGNORED: -0.3,
FeedbackType.LIKED: 1.5,
FeedbackType.REPORTED: -1.0,
}
reward = base_rewards[self.feedback_type]
# 编辑距离惩罚:修改越多,奖励越低
if self.feedback_type == FeedbackType.ACCEPTED_WITH_EDITS:
reward *= (1.0 - self.edit_distance)
# 角色权重:主持人的反馈权重更高
role_weight = 1.5 if self.user_role == "主持人" else 1.0
return reward * role_weight
# generated by hugo AI
悟空知识管理场景的反馈采集
@dataclass
class KnowledgeQueryFeedback:
"""从悟空知识查询中采集的反馈信号"""
query_id: str
response_id: str
user_action: str # "click_source" / "follow_up" / "copy" / "ignore"
time_spent: float # 用户在回答上停留的时间(秒)
follow_up_query: str | None # 是否有追问
def to_reward(self) -> float:
"""基于用户行为的奖励函数"""
reward = 0.0
# 复制/引用回答 → 高质量信号
if self.user_action == "copy":
reward += 0.8
# 点击查看原始来源 → 用户信任但需要验证(中性)
if self.user_action == "click_source":
reward += 0.2
# 有追问 → 首次回答不完整
if self.follow_up_query:
reward -= 0.3
# 停留时间过短 → 可能不相关
if self.time_spent < 3.0:
reward -= 0.2
# 停留时间适中 → 认真阅读
elif 5.0 < self.time_spent < 30.0:
reward += 0.3
return max(-1.0, min(1.5, reward)) # 截断到 [-1, 1.5]
# generated by hugo AI
奖励函数设计:从反馈到强化学习
采集到反馈信号后,下一步是将其转化为强化学习的奖励函数。这里的关键挑战是:
- 稀疏性:不是每次交互都有显式反馈
- 噪声:用户行为受多种因素影响
- 延迟:某些反馈(如知识查询的实际价值)可能延迟显现
from typing import Optional
import numpy as np
class RewardModel:
"""基于人类反馈的奖励模型"""
def __init__(self,
explicit_weight: float = 1.0,
implicit_weight: float = 0.6,
temporal_decay: float = 0.95):
self.explicit_weight = explicit_weight # 显式反馈权重(点赞/举报)
self.implicit_weight = implicit_weight # 隐式反馈权重(采纳/忽略)
self.temporal_decay = temporal_decay # 时间衰减因子
def compute_reward(self,
explicit_signal: Optional[float],
implicit_signal: Optional[float],
days_since_interaction: int = 0) -> float:
"""
计算综合奖励值
Args:
explicit_signal: 显式反馈(点赞=+1.5, 举报=-1.0, None=无)
implicit_signal: 隐式反馈(采纳=+1.0, 忽略=-0.3, None=无)
days_since_interaction: 交互后经过的天数(用于延迟反馈)
Returns:
综合奖励值 [-1.5, 2.0]
"""
reward = 0.0
weight_sum = 0.0
if explicit_signal is not None:
reward += explicit_signal * self.explicit_weight
weight_sum += self.explicit_weight
if implicit_signal is not None:
reward += implicit_signal * self.implicit_weight
weight_sum += self.implicit_weight
if weight_sum == 0:
return 0.0 # 无反馈信号
# 归一化
normalized_reward = reward / weight_sum
# 时间衰减:延迟反馈的权重递减
temporal_weight = self.temporal_decay ** days_since_interaction
return normalized_reward * temporal_weight
def batch_compute_rewards(self, feedback_batch: list[dict]) -> np.ndarray:
"""批量计算奖励值,用于 DPO/GRPO 训练"""
rewards = []
for fb in feedback_batch:
r = self.compute_reward(
explicit_signal=fb.get("explicit"),
implicit_signal=fb.get("implicit"),
days_since_interaction=fb.get("days", 0)
)
rewards.append(r)
return np.array(rewards)
# generated by hugo AI
强化学习加速进化:DPO/GRPO 训练闭环
有了奖励信号,就可以构建持续学习的闭环:
[用户使用钉钉/悟空]
↓ (自然行为)
[反馈信号采集] → 隐式 + 显式反馈
↓ (奖励函数)
[奖励模型] → 每条 (prompt, response) 的奖励值
↓ (偏好对构建)
[DPO/GRPO 训练] → 模型参数更新
↓ (评估 + 灰度)
[新版模型上线]
↓
[用户继续使用] → 新的反馈信号...
关键优势:
- 数据零成本:不需要专门的标注团队,用户日常使用即产生训练数据
- 反馈实时性:从采集到训练上线可缩短至天级(而非月级)
- 偏好对齐:奖励信号直接来自真实用户,而非标注员的假设
- 长尾覆盖:自然使用场景覆盖各种边缘情况,远超人工标注的覆盖范围
效果:进化速度的量级提升
| 指标 | 传统标注微调 | 反馈驱动强化学习 |
|---|---|---|
| 数据获取成本 | 高(人工标注) | 接近零(自然行为) |
| 迭代周期 | 4-8 周 | 1-3 天 |
| 偏好对齐度 | 中(标注员代理) | 高(真实用户) |
| 长尾场景覆盖 | 低 | 高 |
| 模型质量提升/月 | ~5% | ~15-20% |
核心洞察:当人类主动适应 AI(提供高质量输入、设计工作流)的同时,也在为 AI 提供高质量的反馈信号。这两个过程是同一枚硬币的两面:
- 人类适应 AI → 提升当前输出质量
- AI 学习人类反馈 → 降低未来适应成本
这是一个 正向飞轮:人类越擅长使用 AI,产生的反馈信号质量越高;AI 从高质量反馈中学习,能力越强;AI 能力越强,人类适应的成本越低。
适应的三个层次
从上述三个案例中,可以提炼出人类主动适应 AI 的三个层次:
1. 输入层:Prompt 工程成为基本功
这不是写几句好听的提示词。工程化的 Prompt 是 结构化输入协议——如上面两个案例中的 dataclass 模板。当团队开始用类型系统定义 Prompt 时,本质上是在 为 AI 设计 API 规范。
2. 工作流层:重构而非叠加
低效的做法是在现有流程上「加一层 AI」。高效的做法是 围绕 AI 的能力分布重新设计流程:
- 会议纪要:A1 做快的部分,悟空做准的部分,人做确认的部分
- 知识管理:人定义价值规则,悟空做结构化编译,RAG 做精确检索
- 反馈进化:人自然使用产生反馈信号,奖励模型转化为强化学习信号,DPO/GRPO 驱动模型持续进化
关键原则: AI-native 工作流假设 AI 会犯错,因此将人的角色从「执行者」转变为「架构师 + 验证者」。
3. 组织层:新角色与新指标
主动适应 AI 的组织,开始出现新的工程角色:
- AI Workflow Engineer:设计人机协作流程,而非训练模型
- Prompt QA:测试 Prompt 的稳定性与边界条件
- Token Economist:优化输入输出比,控制推理成本
对应的指标也从「模型准确率」转向:
- 首次可用率 (First-Pass Usability):AI 输出无需修改即可使用的比例
- 迭代轮次 (Iteration Count):达到可用状态需要的交互次数
- Token ROI:业务价值 / Token 消耗
为什么适应比等待更划算
一个简化的成本模型:
@dataclass
class AdaptationCost:
"""适应成本 vs. 等待成本"""
prompt_engineering_hours: float # Prompt 工程投入
workflow_redesign_hours: float # 工作流重构投入
training_hours: float # 团队学习成本
@property
def total_adaptation_cost(self) -> float:
return (self.prompt_engineering_hours +
self.workflow_redesign_hours +
self.training_hours)
@dataclass
class WaitingCost:
model_improvement_months: float # 等待模型提升的月数
monthly_opportunity_cost: float # 每月机会成本
competitor_advantage_loss: float # 竞争劣势损失
@property
def total_waiting_cost(self) -> float:
return (self.model_improvement_months * self.monthly_opportunity_cost +
self.competitor_advantage_loss)
# 经验法则:适应成本通常是等待成本的 1/5 - 1/10
# generated by hugo AI
模型能力的提升是线性的(受限于算力、数据、算法突破),但 人类适应 AI 的收益是指数级的——因为适应过程本身就是知识积累,可以复用、组合、规模化。
适应不是妥协,是杠杆
有人担心:主动适应 AI,是不是意味着人类在「迁就」机器?
恰恰相反。回顾技术史:
- 程序员学习汇编语言,不是迁就 CPU,而是获得对硬件的精确控制
- 工程师学习 SQL,不是迁就数据库,而是获得结构化查询的能力
- 设计师学习 Figma 的约束系统,不是迁就工具,而是获得可复用的设计语言
适应 AI,本质上是学习一种新的抽象层。 这个抽象层的特点是:
- 概率性而非确定性:输出需要验证,而非信任
- 上下文敏感:输入质量决定输出质量
- 可组合:小 Prompt 组合成大工作流
掌握这个抽象层的团队,获得的不是「AI 助手」,而是 可编程的认知杠杆。
写在最后
2026 年的 AI 工程实践已经证明: 最强大的 AI 系统,不是最聪明的模型,而是人与模型之间最高效的协作协议。
人类主动适应 AI,不是终点,而是起点。当我们学会如何向 AI 发送高质量输入、如何设计容错的工作流、如何通过自然行为提供反馈信号时,我们实际上在构建一个 正向飞轮:
人类适应 AI(高质量输入 + 结构化工作流)
↓
AI 输出质量提升
↓
人类自然行为产生高质量反馈信号
↓
奖励模型 + 强化学习(DPO/GRPO)
↓
AI 能力进化 → 适应成本降低
↓
人类进一步适应...
这个飞轮的核心引擎,不是算力,不是数据,而是 人类主动适应 AI 的意愿与能力。
这个范式的名字,也许就叫 AI-Native Engineering。
你在团队中观察到哪些「主动适应 AI」的实践?欢迎在评论区分享。