品味即代码：将人类审美编码为智能体的“垃圾回收”机制

本文深入探讨Harness Engineering中维护长期质量的核心机制——反熵与垃圾回收。当智能体以远超人类的速度生成代码时，技术债务会被指数级放大，代码库面临不可逆的“熵增”风险。OpenAI的解决方案是：将人类的“品味”编码为自动化规则，建立定期运行的清理流程。文章详细解析了“品味不变量”的概念（结构化日志、命名规范、文件大小上限等），展示了如何将评审意见、重构PR转化为持续执行的机械规则

王解

1072人浏览 · 2026-03-08 13:45:13

王解 · 2026-03-08 13:45:13 发布

摘要：本文深入探讨Harness Engineering中维护长期质量的核心机制——反熵与垃圾回收。当智能体以远超人类的速度生成代码时，技术债务会被指数级放大，代码库面临不可逆的“熵增”风险。OpenAI的解决方案是：将人类的“品味”编码为自动化规则，建立定期运行的清理流程。文章详细解析了“品味不变量”的概念（结构化日志、命名规范、文件大小上限等），展示了如何将评审意见、重构PR转化为持续执行的机械规则。同时，结合“文档园丁”的实践案例，揭示在AI驱动的开发世界中，保持代码库“信号纯度”是智能体高效协作的前提。

引言：当“AI Slop”成为新的技术债务

想象一下：你有一支不知疲倦的“实习生团队”，他们能在你睡觉时产出3.5个PR，能连续工作六个小时不休息。但他们有一个致命的缺点——会复制代码库中已有的任何模式，无论好坏。

你临时绕过了service层直接查询数据库？没关系，下次他们会在十个地方都这么干。你写了一个命名风格奇怪的函数？恭喜你，这种风格将成为新的“标准”。你在某个模块留下了一个TODO注释？他们会认为这是可接受的代码质量。

OpenAI团队给这种现象起了一个生动的名字：“AI Slop”——由AI生成但质量参差不齐的代码积累。就像厨房里的残渣剩饭，如果不及时清理，很快就会腐烂发臭，最终整个系统变得难以维护。

在传统开发中，技术债务的积累是线性的。但在AI驱动的开发中，它是指数级的。一个坏模式一旦进入代码库，就会被AI无限复制，像病毒一样蔓延。如果不能有效对抗这种“熵增”，再强大的AI引擎也只会加速系统的崩溃。

这正是“品味即代码”这一理念诞生的背景。

[图1：AI Slop扩散示意图 - 左侧一个坏模式被AI复制到多个模块，右侧清理流程阻止扩散]

一、技术债务的指数级放大：一个警示

在深入解决方案之前，我们先理解问题的严重性。

1.1 反直觉的现象

AgentsMesh的实践者发现了一个反直觉的现象：技术债务会被AI指数级放大 。这个观察来自52天的实战经验：

当你在某个模块做了一个临时性的妥协（比如绕过service层直接查数据库）
Agent会把这个模式学走
下一次它生成类似功能的代码，它会复用这个“先例”
这个坏模式开始系统性复制到多个模块

人类工程师遇到糟糕的代码，通常知道“这是个坑，绕开它”。但Agent不会做这个判断——它看到的是：这个代码库里有这样的模式，所以这是合法的做法。

1.2 信号纯度的重要性

这意味着仓库里代码质量的 “信号” 比人写代码时重要得多：

好的工程实践是主体 → Agent就放大好的工程实践
临时性的妥协是主体 → Agent就放大技术债务

作者的实际应对是：中间多次停下来专门清理技术债务，不发新功能，只做重构。目的不是为了“代码好看”，而是为了维护仓库里工程信号的纯度 。

[图2：信号纯度对比图 - 左侧好模式多，AI复制好模式；右侧坏模式多，AI复制坏模式]

二、品味不变量：什么是值得编码的“品味”？

OpenAI团队引入了一个核心概念：“品味不变量”（Taste Invariants）——那些关于代码风格和质量的、可以机械化为规则的判断标准。

2.1 品味不变量的范畴

在实践中，品味不变量涵盖多个层面：

类别	具体示例	说明
日志规范	结构化日志强制	所有日志必须是JSON格式，包含requestId、timestamp等必填字段
命名规范	类型命名约定	接口类型以I开头，枚举类型以Enum结尾
文件结构	文件大小上限	超过500行的文件自动标记为需要重构
性能约束	平台级可靠性要求	关键路径的响应时间必须<200ms
注释规范	TODO格式要求	TODO必须包含责任人ID和创建日期

这些规则不像架构约束那样“生死攸关”（违反依赖方向会导致编译失败），但长期忽视会导致代码库的可读性、可维护性持续下降。

2.2 从主观到客观的跨越

“品味”这个词本身就带有主观色彩。不同的工程师对“好代码”有不同的理解。但在AI驱动的开发中，我们需要将这种主观判断转化为客观规则。

OpenAI的做法是：将团队的集体品味提炼为一组可执行的规则。这些规则不是某一个人的偏好，而是团队经过讨论达成共识的“黄金原则” 。

例如，关于日志的规范可能包括：

// ✅ 符合品味的日志
{
  "timestamp": "2026-03-07T10:30:00Z",
  "level": "info",
  "message": "User logged in",
  "requestId": "abc-123",
  "userId": "user-456",
  "duration": 123
}

// ❌ 不符合品味的日志
"2026-03-07 10:30:00 - User 456 logged in (took 123ms)"

前者是结构化的、可查询的；后者是人类可读但机器难以分析的。将这种偏好编码为规则后，所有AI生成的日志都会自动遵循前者。

三、反熵机制：对抗代码库的自然腐化

品味不变量解决了“规则是什么”的问题，但还有一个更根本的问题：如何确保规则被持续执行？

3.1 熵增定律在软件工程中的体现

热力学第二定律告诉我们：孤立系统的熵总是增加。代码库也是如此——如果没有持续的能量输入（维护工作），它必然会走向混乱和无序。

在AI驱动的开发中，这种熵增被大大加速。每天3.5个PR的吞吐量意味着：

文档与代码的同步性迅速下降
代码风格的一致性被稀释
架构边界被模糊
技术债务以肉眼可见的速度积累

OpenAI团队最初试图用人力对抗熵增：每周五花20%的时间清理“AI slop” 。但这种方法很快就暴露出问题——它无法扩展。当代码库达到百万行级别，7个人的20%时间根本不足以清理AI一周产生的混乱。

3.2 垃圾回收的启发

解决方案来自一个意想不到的领域：编程语言的垃圾回收（Garbage Collection）。

在内存管理中，GC定期扫描堆内存，识别并回收不再使用的对象。这个过程是自动的、持续的、无需人工干预。OpenAI团队意识到：代码库也需要这样的“垃圾回收”。

于是，他们建立了定期的清理流程，将所谓的“黄金原则”直接编码进仓库。这些原则是机械的、有主见的规则，保持代码库对未来代理运行清晰和一致。

[图3：反熵机制工作流程图 - 定期扫描 → 检测问题 → 自动修复PR → 人工确认 → 合并]

四、从评审意见到自动化规则：品味编码的过程

品味不变量不是一次性定义的，而是在开发过程中持续积累的。

4.1 编码循环

OpenAI团队描述了一个关键的反馈循环：

发现问题：在代码评审中，人类工程师发现一个重复出现的品味问题（如日志格式不规范）
评估可自动化程度：判断这个问题能否用自动化规则捕获
编写规则：将品味编码为Linter规则或结构测试（这些规则本身也是Codex生成的！）
提交规则：将新规则提交到代码库，与业务代码一起版本控制
强制执行：从此，所有未来代码都会自动遵守这条规则

这个过程意味着：人类的品味被捕捉一次，然后在每行代码上持续强制执行 。

4.2 规则优先级的动态调整

随着项目的演进，规则的优先级也在动态调整：

初期：关注最基础的品味规则（日志格式、命名规范）
中期：增加性能约束、文件大小上限
后期：引入更复杂的架构一致性规则

这种渐进式的规则引入，避免了“一次性大爆炸”式的重构，让团队和AI都能逐步适应。

4.3 新旧思维的对比

这个转变深刻体现在工程师的思维模式上：

旧思维	新思维
“这段代码风格不对，我来改一下”	“如何让AI下次不再生成这种风格？”
“让我在评审意见中指出这个问题”	“让我把这个问题编码为自动化规则”
“每个PR都要人工检查日志格式”	“日志格式检查已经自动化了”
“品味是主观的，没法自动化”	“品味是可以提炼为规则的”

五、文档园丁：反熵机制的典范实践

在前几篇中，我们已经多次提到“文档园丁”。现在，让我们深入理解它作为反熵机制典范的意义。

5.1 文档腐烂的问题

任何软件项目都会面临文档腐烂的问题——文档与代码实现逐渐脱节，过时的描述误导后来者。在AI驱动的开发中，这个问题更加严重：

智能体依赖文档来理解系统
如果文档过时，它们就会产生错误的理解
错误的代码又会进一步污染文档

这是一个恶性循环。

5.2 智能体解决智能体的问题

OpenAI团队的解决方案优雅而深刻：用智能体来管理智能体留下的问题 。

他们创建了一个专门的“文档园丁”智能体，它的工作只有一个：

定期扫描：每天遍历所有文档，检查内容是否与代码实现一致
检测不一致：例如，文档中描述的API接口与代码中的实际接口不符
发现过时信息：例如，文档引用的配置项已在代码中废弃
修复PR：自动发起Pull Request，提出修改建议
标记可疑点：对于无法自动修复的问题，添加TODO注释或创建Issue

[图4：文档园丁工作机制图 - 展示智能体定期扫描文档库、比对代码、发现不一致、发起修复PR的循环]

5.3 如何检测不一致？

文档园丁检测不一致的方法包括：

代码模式匹配：从文档中提取代码示例，与实际代码比对
API规范比对：将文档中的API描述与OpenAPI规范对比
链接验证：检查所有内部链接是否有效
术语一致性：确保文档使用的术语与代码中的命名一致

例如，如果 docs/api/users.md 中描述了一个 GET /users 端点返回 { "id": number, "name": string }，但代码中实际返回的是 { "userId": number, "fullName": string }，文档园丁就会发现这个不一致，并发出修复PR。

5.4 人的角色

文档园丁不是万能的。有些判断需要人类的介入：

模糊的描述是否需要细化？
过时的设计决策是否需要保留作为历史参考？
自动生成的修复是否正确？

在这些情况下，文档园丁会标记问题，提交PR，并邀请人类工程师评审。人类只需确认或微调，而不是从零开始修复。

正如技术债务管理中的智慧：技术债务就像高利贷——最好以小的增量持续偿还，而不是让它复利增长，然后在某天痛苦地一次性解决 。

六、垃圾回收的哲学：从“清理”到“预防”

文档园丁和品味不变量代表的，是一种更深层的哲学转变：从被动清理到主动预防。

6.1 传统的清理模式

在传统开发中，代码库维护通常是“清理模式”：

每隔一段时间进行一次大规模重构
在发布前集中修复技术债务
发现问题后人工修复

这种模式的问题在于：清理的速度永远赶不上污染的速度，尤其是在AI驱动的开发中。

6.2 垃圾回收的预防模式

垃圾回收模式则完全不同：

持续运行：清理不是阶段性的，而是持续的
自动化执行：不需要人工触发，自动运行
规则驱动：基于预定义的规则，而不是临时判断
自我进化：规则本身也在不断优化

OpenAI团队的实践表明，这种模式让代码库的熵保持在一个可控的范围内，不会随着时间推移而不可逆地增加。

6.3 技术债务管理的智慧

这让我想起一个生动的比喻：技术债务就像厨房里的垃圾。如果你每天都清理，只需要几分钟；如果你一周才清理一次，就需要花几个小时面对腐烂的食物；如果你一个月都不清理，整个厨房都会无法使用。

在AI驱动的开发中，这个道理更加重要。因为AI产生的“垃圾”比人类多得多，所以清理的频率也必须高得多。

七、行业视角：Thoughtworks的洞见

Thoughtworks的Birgitta Böckeler在分析OpenAI实验时，将“垃圾回收”列为Harness Engineering的三个核心组件之一（与上下文工程、架构约束并列）。

7.1 三个核心组件

根据她的解读，这三个组件分别是：

上下文工程：持续增强的代码库知识库，加上智能体对动态上下文（如可观测性数据、浏览器导航）的访问
架构约束：不仅由基于LLM的智能体监控，还由确定性的自定义Linter和结构测试强制执行
垃圾回收：定期运行的智能体，发现文档中的不一致或架构约束的违规，对抗熵和腐烂

7.2 关于品味的思考

Böckeler还提出了一个值得深思的问题：“你今天的Harness是什么？”

她建议每个团队都反思：

你有pre-commit钩子吗？里面有什么？
你有自定义Linter的想法吗？
你希望对代码库施加哪些架构约束？
你尝试过ArchUnit这样的结构测试框架吗？

这些问题将AI采用从“二元选择”变成了“成熟度梯度”。你可以逐步采用Harness Engineering的原则，每一步都会让人类和AI的工作都更可靠。

八、实践的启示：如何开始你的“品味编码”之旅

对于想要实践“品味即代码”的团队，OpenAI的经验提供了一些实用的起点。

8.1 从小处着手

不需要一开始就构建复杂的规则体系。可以从最简单的规则开始：

强制日志格式：确保所有日志都是结构化的
文件大小限制：超过500行的文件触发警告
TODO格式规范：要求TODO包含责任人

这些规则实现简单，但能立即改善代码库的可维护性。

8.2 让AI生成规则

有趣的是，OpenAI团队的Linter规则本身也是由Codex生成的。这意味着你可以用AI来约束AI——这是一个优雅的递归。

例如，当你需要检查某个命名规范时，可以提示Codex：“生成一条ESLint规则，强制所有接口类型以I开头。”Codex会生成规则代码，你只需要验证和提交。

8.3 区分“严格”与“灵活”

不是所有品味都需要机械化。OpenAI团队的原则是：

边界集中管控：依赖方向、模块边界、安全约束必须严格执行
内部高度自治：具体实现细节、代码风格在一定范围内允许灵活

AI生成的代码未必符合人类审美，但只要正确、可维护、对智能体可读，就OK。这种取舍是基于一个现实：人类注意力的稀缺性远远超过对完美代码风格的追求。

8.4 建立定期的清理流程

最后，建立定期的清理流程，让反熵成为习惯。可以是：

每日：文档园丁扫描，发现并修复小的不一致
每周：集中处理本周积累的技术债务
每月：评审规则体系，添加新的品味不变量

结语：当品味成为代码

在Harness Engineering的拼图中，“品味即代码”可能是最富有哲学意味的一块。它回答了这样一个问题：当AI承担了编码的执行工作，人类的审美和经验将如何延续？

答案是：将品味编码为规则，让机械力持续发挥作用。

这个过程不是对工程师的异化，而是对工程师价值的升华。你的每一次评审意见、每一个重构PR、每一个对代码质量的坚持，都不会随着时间流逝而被遗忘，而是会转化为永恒的规则，在每一行AI生成的代码上持续生效。

正如OpenAI团队所言：“技术债务就像高利贷——最好以小的增量持续偿还，而不是让它复利增长。”

在AI驱动的开发世界中，垃圾回收不是可选项，而是必选项。它是对抗熵增的武器，是保持代码库“信号纯度”的保障，是人类品味在AI时代的延续方式。

下一篇预告：《从Ralph Wiggum Loop到完全自主：智能体如何实现端到端驱动功能开发》
我们将追踪智能体自主性的进化路径，看Codex如何逐步获得自我验证、自我评审、处理反馈的能力，最终跨越临界点，实现从单一提示到端到端功能交付的完整闭环。敬请期待。

欢迎在评论区分享你的看法：在你的项目中，你最想将哪些“品味”编码为自动化规则？

最近openclaw非常火爆，给大家整理了一些免费白嫖token的网站。希望对大家有用
白山智算： https://ai.baishan.com/auth/login?referralCode=IRxQKSvCmf 注册实名:150 元+ 首次调用300 元，合计450 元体验金约2亿token
轨迹流动： https://cloud.siliconflow.cn/i/G4aw22io 1500w token
智谱大模型开放平台链接：https://www.bigmodel.cn/invite?icode=6nBhIl8EAx9QN2uiQIuLxHHEaazDlIZGj9HxftzTbt4%3D 2000w token
火山引擎：https://console.volcengine.com/ark/region:ark+cnbeijing/openManagement/rewardPlan 500w token/天 longcat：https://longcat.chat/platform/usage 5千万token/日
智谱 GLM Coding 链接：https://www.bigmodel.cn/glm-coding?ic=Z8T8OK12LU
阿里百炼：https://www.aliyun.com/product/bailian code plan 首月7.9