Loop Engineering 背后有一种很重要的工程谦逊：
我们承认自己一开始不会完全正确。但我们不因此放弃工程性。
相反，我们设计一种机制，让系统可以在不确定中学习，在反馈中收敛，在错误中积累结构化经验。
它不是拍脑袋试错，也不是无限迭代。它是一种有记忆、有观察、有回写的工程闭环。 对于确定性系统，好的工程是把规则实现得稳定。 对于不确定性系统，好的工程是让系统持续接近正确。
Loop Engineering 的价值就在这里：它把"我们还没完全想清楚"这件事，从风险，变成了系统演进的动力。
一、Loop Engineering 不是"快速迭代"
Loop Engineering 很容易被误解成"多试几轮""快速迭代""敏捷开发"。但它们并不是一回事。
快速迭代强调速度：
做一个版本，试试看，不行再改。
Loop Engineering 强调闭环：
每一次尝试都必须产生可观察反馈，并且反馈能回到系统设计中，改变下一轮行为。
它不是简单地多做几次，而是让每一轮都具备工程意义。
一个真正的 loop 至少包含五个部分：
- 假设
- 实现
- 运行
- 观察
- 回写
如果没有假设，运行只是碰运气。如果没有观察，失败只是失败。如果没有回写，经验不会进入系统。所以 Loop Engineering 的重点不是"循环"，而是"让循环产生知识"。
二、为什么现代系统越来越需要 loop
传统工程追求的是确定性。
输入是什么，输出就是什么。条件满足，分支执行。数据合法，流程通过。只要代码没有 bug，系统行为就应该稳定。
但现代复杂系统经常面对三类不确定性。
第一类是输入不确定。用户不会按照工程师希望的格式表达意图。他们会省略信息，会使用模糊词，会混合多个目标，会把业务口语、个人习惯和上下文假设揉在一起。
第二类是解释不确定。 同一句话可能有多种含义。同一个行为可能对应多个动机。同一个指标可能有不同口径。同一个反馈可能既是偏好，也可能是误操作。
第三类是环境不确定。 数据会变，规则会变，模型会变，用户群体会变，外部约束会变。一个昨天有效的策略，今天可能变得不稳定。
在这种系统里，工程师不可能一次性列出所有情况。强行追求"一次设计正确"，反而会制造脆弱性。
更合理的方式是承认：
系统的正确性不是预先声明出来的，而是在运行、观察和修正中逐步逼近的。
Loop Engineering 就是把这种逼近过程工程化。
三、Loop Engineering 的核心对象不是代码，而是认知
很多人谈工程，第一反应是代码结构、模块边界、测试覆盖、部署流程。
这些当然重要。
但在 Loop Engineering 里，真正被工程化的对象是认知。
也就是说，我们不是只在改代码，而是在不断回答：
- 我们现在相信什么？
- 这个相信是否被验证过？
- 系统行为和我们的相信哪里不一致？
- 不一致是因为实现错了，还是因为假设错了？
- 新的认知应该沉淀到哪里？
每一轮 loop，本质上都是一次认知校准。
举个抽象例子。
一开始我们可能相信：
用户点击某个按钮，说明他喜欢这个内容。
于是系统根据点击行为优化推荐。
运行后发现，很多点击只是标题吸引，用户很快退出。于是旧假设被修正为：
点击只代表兴趣入口，不代表满意度。停留、收藏、复访、负反馈一起看，才更接近真实偏好。
这时系统不是简单地"改了一个算法"，而是完成了一次认知升级。
Loop Engineering 要求这种升级不是 停留在人的脑子里，而是进入系统。
只有这样，认知才不会丢失。
四、一个完整 loop 应该怎么长
一个成熟的工程 loop 通常有六个阶段。
1. Framing：提出可检验假设
loop 的起点不是"做功能"，而是提出一个假设。
好的假设必须可观察、可失败、可修正。
比如：
如果用户没有明确时间范围，系统应该主动询问，而不是默认最近七天。
这是一个可检验假设。
系统运行后，我们可以观察：
- 用户是否理解这个询问
- 用户是否愿意回答
- 回答后结果是否更准确
- 是否有大量用户觉得被打断
- 默认值是否反而更符合大多数场景
坏的假设通常长这样：
我们要提升智能体验。
这不是假设，而是愿望。它无法直接进入 loop。
2. Encoding：把假设编码进系统
假设不能只写在会议纪要里。它必须进入某种可执行结构。
可能是：
- 代码
- 配置
- prompt
- schema
- spec
- 测试
- 数据标注规则
- 指标口径
- 监控面板
- 评估集
这一步很关键。
因为一个没有被编码的认知，不会稳定影响系统行为。它只会依赖某个人记得。
Loop Engineering 的成熟度，往往体现在团队能不能把"讨论出来的判断"快速变成系统约束。（那这里如何落地呢）
3. Execution：让系统在真实或半真实环境中运行
尽快行动：很多问题只有运行起来才会出现。
静态设计阶段，人会倾向于想象理想输入、理想用户、理想数据和理想路径。但真实世界通常是混乱的。
所以 loop 需要运行面。
运行面可以分层：
- 单元测试
- 集成测试
- 离线回放
- 沙盒环境
- 灰度流量
- A/B 实验
- 线上观测
不同阶段承担不同职责。
-
单元测试验证局部确定性。
-
回放验证历史样本。
-
灰度验证真实用户行为。
-
线上观测发现未知未知。
没有运行，loop 就只是纸面推演。
4. Observation：观察系统偏差
运行之后，最重要的不是立刻修，而是观察。
观察要回答：
- 系统做了什么？
- 为什么这么做？
- 哪一步开始偏离预期？
- 偏离是偶发还是系统性？
- 是输入问题、数据问题、策略问题、模型问题，还是交互问题？
好的系统会主动留下观察线索。
比如：
- 决策路径
- 中间状态
- 输入解析结果
- 候选列表
- 被过滤的原因
- 用户最终选择
- fallback 原因
- 错误类型
- 版本号
- 实验桶
没有这些东西，工程师只能靠猜。而靠猜修系统，通常会制造下一个问题。
5. Diagnosis：把错误分类
Loop Engineering 里很重要的一步是错误分类。
不是所有失败都应该用代码修。可能来自如下可能：
需求假设错误。
数据分布变化。
提示语不清。
用户交互设计不合理。
评估指标选错。
系统边界定义含混。
如果分类错了，修复就会错位。
比如一个系统经常误解用户问题。可能原因有很多：
- 解析器能力不足
- 用户问题本身缺信息
- 产品没有引导用户补充
- 领域词典缺失
- 指标口径不统一
- 日志无法提供足够上下文
- 评估集没有覆盖这类问题
如果一律归因成"模型不行"，就会反复换模型，却不解决真正问题。
Loop Engineering 要求我们把失败变成结构化知识，而不是情绪化结论。
6. Write-back：把新认知写回系统
这是 loop 最容易断掉的地方。
很多团队能发现问题，也能临时修掉问题，但没有把经验写回系统。
结果同类问题会反复出现。
真正的 write-back 可能发生在很多层：
- 改代码
- 改 spec
- 改测试
- 改日志
- 改数据集
- 改 prompt
- 改产品交互
- 改监控指标
- 改评估标准
- 改团队术语
一个问题如果只在聊天记录里被解决，它其实没有被系统解决。只有进入可复用结构，才算完成闭环。
五、Loop Engineering 的几个层次
Loop Engineering 不是单一闭环，而是一组嵌套闭环。
1. Product Loop
关注用户是否真的达成目标。
它问：
- 用户想完成什么？
- 当前系统是否帮到了他？
- 用户在哪一步放弃？
- 哪些交互造成误解？
- 哪些能力其实不需要？
- 哪些默认行为违背预期？
Product loop 让系统不偏离真实需求。
2. Data Loop
关注数据是否支持系统判断。
它问：
- 数据是否完整？
- 口径是否一致？
- 标签是否可靠？
- 样本是否代表真实分布？
- 错误样本有没有被沉淀？
- 新场景有没有进入评估集？
Data loop 决定系统是否越跑越聪明，而不是越跑越乱。
3. Model Loop
关注模型、算法或策略是否有效。
它问：
- 当前方法在哪些样本上失败？
- 失败是否集中在某类输入？
- 是召回问题、排序问题、生成问题，还是约束问题？
- 新版本是否提升了核心指标？
- 有没有引入新的副作用？
Model loop 让能力持续校准。
4. Protocol Loop
关注系统边界是否稳定。
它问：
- 模块之间传什么数据？
- 哪些字段是真相，哪些只是展示？
- 哪些状态可以被恢复？
- 哪些信息可以由前端修改？
- 哪些中间结果需要跨轮保存？
- 哪些结构只是内部临时态？
Protocol loop 对复杂系统尤其重要。
因为很多系统问题不是能力问题，而是边界问题。
数据在模块之间传来传去，语义慢慢漂移。某个字段一开始只是展示，后来被拿来当真相。某个临时状态一开始只服务本轮运行，后来被固化成跨版本协议。
如果没有 protocol loop，系统会逐渐长出隐性耦合。
5. Evaluation Loop
关注"我们怎么知道变好了"。
它问：
- 什么叫好？
- 用哪些 case 测？
- 测试集是否覆盖关键路径？
- 指标是否会被投机优化？
- 线上反馈和离线评估是否一致？
- 失败样本如何进入下一轮评估？
没有 evaluation loop，系统只能靠主观感觉前进。
六、Loop Engineering 和传统工程的关系
Loop Engineering 不是替代传统工程。
它是在传统工程之上，补上对不确定性的处理。
传统工程依然重要：
- 模块化
- 类型系统
- 测试
- CI/CD
- 代码审查
- 监控
- 回滚
- 文档
- 版本管理
但这些更多解决的是"确定部分如何可靠执行"。
Loop Engineering 解决的是：
当我们还不知道什么是完全正确时，如何让系统通过运行逐步接近正确。
所以二者不是冲突关系。
更准确地说：传统工程保证系统不会轻易坏。Loop Engineering 保证系统能持续变好。
七、一个系统有没有 loop，看什么
判断一个系统是否具备 Loop Engineering 能力，可以看几个问题。
第一，系统是否记录中间判断？如果只记录最终结果，不记录过程，就很难定位偏差。
第二，失败样本是否会沉淀？如果失败只是临时修复，不进入测试或评估集，同类问题会重复出现。
第三，协议是否区分真相和展示？如果展示结构、运行状态、业务真相混在一起，系统很快会变得难以恢复和演进。
第四，团队是否有稳定术语？如果每个人对同一个词理解不同，loop 会在沟通层断掉。
第五，修复是否会回写 spec？如果 spec 不更新，下一轮实现仍会踩旧坑。
第六，系统是否能解释自己为什么这样做？不能解释的系统，不一定不能用，但很难持续改好。
八、Loop Engineering 的反面
Loop Engineering 的反面不是慢，也不是瀑布。它的反面是"无记忆迭代"。
典型表现是：
- 每次都在救火
- 每次都说"这个 case 特殊"
- 每次都靠某个人记得背景
- 每次改完都没有新增测试
- 每次上线后才发现协议理解不一致
- 每次复盘都没有进入系统资产
- 每次需求变化都像从零开始
这种团队看起来也在快速迭代，但实际上没有形成 loop。它只是在原地打转。真正的 loop 会留下轨迹。每一轮之后，系统应该更清楚一点：
- 哪些输入支持
- 哪些输入不支持
- 哪些状态可恢复
- 哪些字段是真相
- 哪些错误可自动修复
- 哪些场景必须询问用户
- 哪些行为需要降级
- 哪些 case 已进入评估集
如果系统没有变得更清楚，就说明 loop 没闭上。
九、Loop Engineering 的实践原则
我会把它总结成十条实践原则。
先写假设，再写实现：不知道自己在验证什么，就无法判断结果。
把认知编码进系统： 重要判断必须进入 spec、测试、数据或代码。
中间状态比最终结果更重要：只看最终输出，很难知道系统为什么错。
失败必须分类：不同类型的失败需要不同层面的修复。
不要从展示态反推业务真相：展示是投影，真相应保存在稳定上下文或状态结构里。
每个 fallback 都要有名字：无名 fallback 会慢慢变成不可解释的系统行为。
测试集要吸收真实失败：否则测试只证明旧想象成立。
协议要保守，内部实现可以演进：跨边界的数据一旦固化，就会变成长期约束。
让系统能复盘： 没有 trace 的系统，很难形成高质量 loop。
每轮只收敛一个关键不确定性：loop 太大，会看不清反馈来自哪里。