反馈控制:AI 提效的第一性原理

阅读时间：约 18 分钟
关键词：反馈控制 | 负反馈 | 正反馈 | 反馈协议 | 多轮对话 | 收敛策略

先讲一个我亲眼见过的「极限拉扯」。

一位朋友用 Hermes 写一份技术方案。他上来就丢了一句：「帮我写个数据库迁移方案。」

AI 输出了 1500 字。他看了一眼：「不行，太浅了，再详细一点。」

第二轮，AI加了细节，但他发现方向偏了——

    AI假设的是MySQL→PostgreSQL迁移，

    他实际要做的是 Oracle→MySQL。

第三轮，方向对了，但结构像教科书，缺少他项目的具体约束（停机窗口 2 小时、数据量 3TB、需要回滚方案）。

第四轮、第五轮、第六轮……

最终结果？方案确实写出来了，能用。但一共7轮对话，耗时35分钟，token 烧了上万。

问题在哪？ 不是 AI 不够聪明，不是他的需求太复杂。

问题是：他每一轮都在「纠偏」，但他从来没有设计过自己的「纠偏机制」。

他以为多轮对话 = 越聊越准，

但实际上——

没有反馈回路设计的多轮对话，就像没有陀螺仪的导弹：每一轮都在重新瞄准，而不是在修正。

钱学森先生在 1954 年写过一句话，可以说是整个工程控制论的「第一性原理」：

控制质量不取决于前馈的精确性，而取决于反馈回路的设计质量。

翻译成今天的语言：别幻想你的第一版 prompt 能一步到位。把你的精力，花在「怎么让 AI 越改越准」上。

这就是今天要讲的核心。

第一章：钱学森教我们的——反馈，才是控制的灵魂

1.1 前馈 vs 反馈：两个世界观的差异

工程上有两种系统控制方式，代表两种完全不同的世界观。

前馈控制（Feedforward）：

在行动之前，根据预设模型计算好一切，然后执行。不回头，不修正。

自动洗衣机加水 30 升就是 30 升，不管你衣服是 3 件还是 10 件。

反馈控制（Feedback）：

测量实际输出，跟期望输出比较，发现偏差 → 

修正输入 → 

缩小偏差 → 

循环往复，直到偏差趋近于零。

钱学森的洞见在于：现实世界里，前馈永远不够。 因为——

• 你永远无法预设所有变量（模型的参数你算不准）
• 你永远无法预知所有干扰（环境会变化）
• 你永远无法把系统建模到 100% 完美

所以，一个系统真正「聪明」的标志，不是它的前馈有多完美，而是它的反馈回路有多高效。

导弹命中目标，靠的不是发射前把弹道算到毫米级（前馈），而是飞行中不断测量「实际位置 vs 目标位置」的偏差，并持续修正姿态（反馈）。陀螺仪、加速度计、制导计算机——整个系统的精髓，全在反馈回路上。

1.2 负反馈与正反馈：两个相反的力量，同一个机制

钱学森在书中花了大量篇幅讨论反馈的两种基本形态。

负反馈（Negative Feedback）：检测偏差 → 反向修正 → 系统收敛稳定。

恒温器是负反馈：温度低了，加热；温度高了，停止加热。

空调、巡航定速、人体血糖调节，全部是负反馈。

负反馈让系统「保持稳定」，不跑偏。

正反馈（Positive Feedback）：检测偏差 → 同向放大 → 加速变化 → 突破/引爆。

扩音器对着话筒时产生啸叫，是正反馈。

社交媒体上的病毒传播，是正反馈。核裂变链式反应，是正反馈。

正反馈让系统「加速变化」，要么冲到新高度，要么炸掉。

负反馈和正反馈不是「好坏」之分。它们是同一套机制的两个方向

——关键在于：什么时候用哪个？

钱学森先生的原则很明确：

大部分时间用负反馈保持系统稳定运行；

在确认方向正确后，用正反馈加速突破。

伺服机构用负反馈让炮塔精准跟随目标；用正反馈在锁定目标后加速追踪。

自动驾驶仪用负反馈修正航向偏差；用正反馈在进场阶段快速对准跑道。

稳定平台用负反馈抵消船体摇摆；用正反馈在捕捉到信号后迅速锁定。

同一个逻辑，同一个威力。接下来，我们就把它用到 AI 对话上。

第二章：Hermes 落地——每一次对话，都是一条反馈回路

2.1 单轮对话 = 前馈，多轮对话 = 反馈

这是最直接的映射，也是大多数人最容易忽略的一点。

单轮对话是前馈系统：你输入一个 prompt，AI 输出一个结果。

没有修正机会。

就像自动洗衣机，一次设定，一次执行。

多轮对话是反馈系统：你输入 prompt → AI 输出 → 你检测偏差 → 你给出修正指令 → AI 再输出 → 你再检测偏差 → ……直到收敛到你想要的结果。

这套流程，跟导弹的制导回路结构完全一样：

发现了吗？这不是比喻，不是类比——这是同构结构。

你每一次多轮对话，本质上都在运行一条反馈控制回路。

区别只是：

导弹的反馈回路是由精密仪器和算法在毫秒级自动完成的；

你的反馈回路是你手动完成的。

而正因如此——

你手动完成的这条回路，质量高不高、效率高不高，完全取决于你「设计」得怎么样。

2.2 负反馈在 AI 对话中的用法：精确指出偏差

负反馈的核心操作就三步：

1. 看：把 AI 的输出跟你的期望对比，找到偏差
2. 说：精确告诉 AI 偏差在哪、偏差多少、方向往哪改
3. 验：检查修正后的输出是否缩小了偏差

这三步听起来简单，但大多数人死在第二步。

错误示范：「不是这个意思，重写。」

→ AI 不知道哪错了、错多远、往哪改。

它只能重新猜。大概率还是偏的。

正确示范：「第三段关于成本分析的结论方向偏了。你目前的分析聚焦于硬件成本，但我需要的是『总拥有成本』视角，包含人力迁移成本（预估 3 人月）和停机损失（每小时约 5 万元）。请以这个口径重写第三段。」

区别在哪？

后者的修正指令是一个「高精度偏差信号」

——AI 能定位到具体段落、具体维度、具体缺失的内容。

就像导弹的制导系统收到的不是「偏了，调一下」，

而是「弹道偏差 X 轴 +3.2 米，Y 轴 -1.7 米」。

负反馈的黄金法则：修正指令的精度，决定了收敛的速度。偏差定位越精确，AI 修正效率越高。

2.3 正反馈在 AI 对话中的用法：放大正确的方向

正反馈往往被忽视，但它的威力巨大。

假设你在让 AI 分析代码架构问题。

AI 的输出中，第三段提出了一个你从未想到的角度——

「当前的单体架构不仅影响部署效率，还隐含了数据耦合风险，这可能是之前性能瓶颈的根因。」

这时候，你如果只说「继续」，你就浪费了一次正反馈机会。

正反馈的正确用法：「第三段关于数据耦合风险的分析非常到位，这个方向是对的，请沿着这个方向继续深入——分析当前架构中具体哪些模块之间存在数据耦合，耦合类型是什么（读耦合/写耦合/事务耦合），并给出解耦方案。」

正反馈 = 告诉 AI 「哪里做对了」+ 「在这个正确方向上继续放大」。

这跟工程师调整系统增益是一个道理：当系统的输出方向正确但幅度不够时，加大增益、加速前进。正反馈是让你快速突破瓶颈的加速器。

第三章：反馈协议——你的 AI 对话「自动驾驶系统」

理论讲完了。现在进入这篇文章最核心的部分：

怎么设计一套让你在多轮对话中高效收敛的「反馈协议」。

3.1 什么是反馈协议？

协议（Protocol），在控制论里指的是「通信双方约定的结构化交互规则」。

在 Hermes 对话里，反馈协议就是你在第一轮就定义好的、贯穿整个对话的「如何纠偏」规则。它包括：

• 分层策略：每轮聚焦一个维度，而不是每轮什么都改
• 偏差检测点：每轮结束后你检查什么
• 修正指令模板：你用什么格式告诉 AI 怎么改
• 收敛判定：什么条件下你认为「可以了，收工」

设计反馈协议，就是把你可能进行的 5-7 轮随机纠偏，

变成 3-4 轮有节奏的系统收敛。

3.2 四层反馈协议框架

基于钱学森的「分级控制」思想，我提炼了一套四层反馈协议。

不需要背，理解逻辑后可以灵活调整。

第 1 轮 — 框架层验证
   目标：方向对不对？
   检查：整体结构、核心论点、关键假设
   修正：「骨架正确吗？缺少什么大模块？有什么完全不需要？」
   输出：AI 给出修正后的框架

第 2 轮 — 内容层纠偏
   目标：内容准不准？
   检查：每个模块的具体论述、数据准确性、逻辑链条
   修正：「第 X 部分的数据需要更新」「第 Y 段的推导有跳跃」
   输出：AI 给出修正后的完整内容

第 3 轮 — 细节层打磨
   目标：质感够不够？
   检查：措辞、格式、引用、一致性
   修正：「措辞偏学术/偏口语」「某处需要一个例子」
   输出：AI 给出打磨后的版本

第 4 轮 — 终验层确认
   目标：是否可交付？
   检查：满足成功标准吗？有无遗漏？
   修正：最后的微调
   输出：最终交付物

这个协议的核心哲学是：

你把原本混在一起的「方向问题 + 内容问题 + 格式问题」，

拆成了四个独立的控制层。

每一层只解决该层的偏差。

为什么这很重要？

因为人的认知有一个致命缺陷：

当我们同时看到三个问题时，我们往往会混杂着反馈，导致 AI 无法确定「先解决哪个」。

分层反馈 = 每一轮 AI 只需要聚焦一个维度的修正，收敛速度极快。

3.3 反馈协议 vs 自由纠偏：效果差异

用同一任务对比：

第四章：完整案例——一次高难度技术方案的 6 轮反馈迭代

下面是一个真实案例的完整还原。

任务：帮一家电商公司撰写「双十一大促系统稳定性保障方案」，

涉及多系统协同、流量预估、降级策略、应急响应——

是一个典型的「高复杂度、高不确定性」任务。

我将展示每一轮的偏差检测、修正指令和效果收敛过程。

第 0 轮：初始 prompt 设定（前馈）

在开始之前，我用了 S01 教的系统观框架定义输入：

【任务】双十一大促系统稳定性保障方案
【背景】B2C 电商平台，日均订单 30 万，预估峰值 300 万
【核心系统】订单中心、库存中心、支付网关、用户中心、物流调度（共 5 个）
【约束】零停机、预算 500 万以内、需包含降级和回滚策略
【输出要求】Markdown 方案文档，包含架构图描述、压测方案、应急预案
【反馈协议】第 1 轮验框架 → 第 2 轮纠内容 → 第 3 轮细粒度 → 第 4 轮终验

第 1 轮：框架层验证

AI 输出：给出了一个 8 章结构（背景分析 → 流量预估 → 系统容量规划 → 架构改造 → 压测方案 → 降级策略 → 应急预案 → 总结）。

偏差检测：

• ✅ 8 章结构覆盖了主要方面
• ❌ 缺少「数据一致性保障」独立章节（大促中库存扣减、订单幂等是关键）
• ❌ 「成本估算」分散在各个章节，不是集中呈现（我需要一个总成本表）
• ⚠️ 「应急预案」排在第 7 章太靠后，应该提前到第 5 章（架构改造后立即讲应急）

修正指令：

「框架方向正确。三处调整：

1. 在『架构改造』后增加独立章节『数据一致性保障』，聚焦库存扣减幂等、订单防重、分布式事务方案。
2. 将『应急预案』提前到第 5 章（架构改造后紧跟应急预案，逻辑更紧凑）。
3. 增加独立的『成本预估总表』章节，汇总各系统改造、压测、人力、备用资源的成本。」

效果：方向锚定。结构从「够用」变成「专业」。

第 2 轮：内容层纠偏（上）——架构改造

AI 输出：框架修正后，填充了完整的架构改造内容。

偏差检测：

• ❌ 订单中心的改造方案只提了「数据库读写分离」，没有考虑峰值 300 万订单/天（是日常的 10 倍）的场景——读写分离不够，需要引入消息队列削峰。
• ❌ 库存中心的扣减方案用了「先查再扣」模式，存在超卖风险——应该用 Redis Lua 脚本实现原子扣减。
• ✅ 支付网关的异地多活方案方向正确，细节可行。

修正指令：

「两个关键技术修正：

1. 订单中心：峰值 300 万/天 = 约 3500 QPS，单靠读写分离撑不住。补充『消息队列削峰 + 异步落库』方案，以 RocketMQ 为例说明架构。
2. 库存中心：当前方案存在超卖风险。改为『Redis Lua 原子扣减 + DB 异步同步』方案，描述 Lua 脚本的核心逻辑。

支付网关部分维持不变，方向正确。」

效果：核心技术方案从「理论可行」升级为「生产可用」。

第 3 轮：内容层纠偏（下）——降级与应急

AI 输出：完成了数据一致性章节和降级策略。

偏差检测：

• ❌ 降级策略只列了「关闭非核心功能」，没有给出分级方案（P0/P1/P2 降级）
• ❌ 应急预案只有文字描述，缺少「响应时间线」——大促中时间就是金钱
• ✅ 数据一致性章节的分布式事务方案（Seata AT 模式）分析到位

修正指令：

「降级和应急方案需要两个关键补充：

1. 降级策略按 P0/P1/P2 三级分级：

• P2（流量达 200%）：关闭推荐系统、用户画像更新
• P1（流量达 250%）：关闭搜索分词优化，降级为精确匹配
• P0（流量达 300%）：关闭非核心报表，保留核心交易链路

1. 增加『应急响应时间线』：从『发现异常』到『执行降级』到『恢复服务』到『复盘』，每个阶段标注责任人、工具、SLA（如：发现异常后 1 分钟内告警，3 分钟内定位，5 分钟内执行降级）。」

效果：方案从「有」变成「可执行」。

第 4 轮：细节层打磨——成本与格式

AI 输出：成本预估总表出来了。

偏差检测：

• ❌ 成本表只列了「硬件扩容」和「人力」，漏了「压测工具费用」和「备用资源租赁」
• ⚠️ 部分章节的措辞偏开发口吻（大量「我们会……」），方案文档应该是「建议……」或「采用……」的第三方视角
• ✅ 架构图 ASCII 描述清晰、各系统改造方案技术深度合适

修正指令：

「两个打磨：

1. 成本表补充两项：压测工具费用（预估 JMeter 集群或云压测服务 30 万）、备用资源租赁（云主机弹性资源预留费用）。
2. 全文统一措辞：把『我们会』替换为『建议』或『采用』，把『你们需要』替换为『运维团队需要』——整体保持第三方方案视角。」

效果：细节到位，专业感拉满。

第 5 轮：终验层确认——遗漏检查

AI 输出：打磨后的最终版本。

偏差检测：

• ✅ 所有章节完整
• ✅ 技术方案经过修正后正确
• ⚠️ 缺少一个「前置条件清单」——方案假设了很多前提（如「Redis 集群已部署」），但没有显式列出
• ⚠️ 没有标注「方案版本」和「适用场景说明」

修正指令：

「质量很好，最后两个小补充：

1. 在方案开头增加『前置条件与假设』小节，列出 5-7 条关键假设（如：Redis 集群已部署且支持 Lua、RocketMQ 已搭建、压测环境与生产 1:1 等）。
2. 在文档末尾标注：版本 V1.0、适用范围（2026 双十一大促）、修订记录占位。」

第 6 轮：收敛——最终交付

AI 输出了包含上述所有修正的最终版本。偏差趋近于零。

收敛统计：

总耗时 9 分 30 秒，6 轮，40 页专业方案。每一轮的偏差都精确到具体维度，每一轮的修正都单向推进。

如果换成自由纠偏？预估：10-12 轮，30 分钟以上，而且很可能中间出现「第 8 轮回到第 3 轮的问题」这种反复。

第五章：你的反馈控制实操工具箱

工具一：反馈效果快速诊断表

跟 AI 聊了三轮以上还没拿到满意结果？别急着重写 prompt。

用这张表先诊断：

工具二：反馈协议模板（每次复杂任务第一轮贴上）

markdown
【反馈协议】（本轮对话的「纠偏规则」）

1. 分层策略：
   - 第 1 轮：验证框架/结构（方向对不对？缺少什么大块？）
   - 第 2 轮：验证核心内容（技术/逻辑/数据准不准？）
   - 第 3 轮：验证细节（格式/措辞/引用/一致性）
   - 第 4 轮：终验确认（遗漏检查+最终微调）

2. 偏差检测点：
   - 每轮结束后，我会检查 [列出 3-5 个具体检查项]
   - 我将用以下方式标注偏差：[段落号] + [偏差维度] + [修正方向]

3. 修正规则：
   - 局部问题只修改相关段落，不要重写全文
   - 如果我的修正指令不够清楚，请列出你需要澄清的点，不要猜测
   - 「已确认」的部分，后续轮次不要改动

4. 收敛条件：
   - 当连续两轮偏差数量为零时，本轮任务完成
   - 4 轮后如果仍未收敛，检查问题是否出在初始需求定义上

工具三：30 秒反馈自查口诀

每次迭代前，心里过一遍这四个字：

看 → 说 → 验 → 定

• 看（5 秒）：AI 这轮输出跟我预期的偏差在哪？精确到段落/维度。
• 说（10 秒）：我打算怎么告诉 AI 这个偏差？用「位置 + 方向 + 程度」格式。
• 验（5 秒）：AI 下一轮输出后，我花多久能判断偏差是否缩小？（准备好检查清单）
• 定（10 秒）：这轮聚焦什么层？其他层的问题先记下来，这轮不管。

结语：反馈，是 AI 时代的「第一性原理」

钱学森在《工程控制论》里有一段话，我每次重读都会被震到：

「一个没有反馈的系统，必然偏离目标。偏离的速度，取决于系统的复杂度。系统越复杂，偏离越快。唯有反馈，能让一个复杂系统保持在通往目标的轨道上。」

70 年后的今天，这句话的含义甚至比当年更深刻。

今天的 AI 对话系统——无论是 Hermes、ChatGPT 还是任何 Agent——都是人类历史上最复杂的「被控对象」之一。它的输出空间几乎是无限的。它的推理路径是不可完全预测的。它的「个性」会随着上下文微妙漂移。

在这样一个系统面前，「一次性给出完美 prompt」的幻想，注定破灭。

但这不是坏消息。这是好消息。

因为钱学森已经告诉你了：控制质量不取决于前馈的精确性。取决于反馈回路的设计质量。

你不是在跟一个不听话的 AI 较劲。你是在运行一条需要设计的反馈回路。把精力从「打磨完美 prompt」转移到「设计高效反馈机制」上，你会发现——你的 AI 从不听话变成了可驾驭。

从今天开始，给你的每一次复杂对话，装上一个反馈协议。

你会发现你能控制的，远比你想象的更多。

下一篇预告

反馈回路搭好了，你的对话收敛效率大幅提升。但下一个问题随之而来：反馈信号有时候本身就是「噪声」——你怎么知道你给 AI 的修正指令是对的？你怎么防止一次错误的反馈把整个对话带偏？

这就是 S03《黑箱方法：不要试图「读懂」AI，学会「控制」它》 要解决的。钱学森的黑箱哲学：不可知 ≠ 不可控。面对一个你无法透视内部运作的系统，如何通过外部输入输出的映射关系，建立有效的控制策略。

我们下期S03 见。

「控制质量不取决于前馈的精确性，而取决于反馈回路的设计质量。」

——钱学森《工程控制论》，1954