零、摘要
在 vibe coding 时代，我们不再一行行写代码，而是用几句自然语言，让模型帮我们“整活”出一大坨代码甚至整个项目。爽感拉满的同时，一个被很多人忽略的底层事实是：这样的开发范式，天然在制造高熵代码库——结构乱、风格散、语义飘、演化史糊成一团，久而久之变成那种“能跑，但没人敢改”的系统。
本文把这种“熵”拆成多个维度：项目分层和依赖是否有规律（结构熵）、命名和写法是否统一（风格/命名熵）、业务概念有没有清晰单一模型（语义熵）、演化轨迹是否能讲出故事（时间熵）、API 和系统行为是否可预测（行为熵），以及知识/所有权和需求本身的混乱程度。然后从模型机制出发解释：大模型只是条件概率机器，优化的是“局部看上去合理、现在能跑”，再叠加采样随机性、上下文局部视野、多 Agent 不同风格等因素，高熵不是意外，而是物理属性。
在此基础上，文章讨论了这种高熵范式对项目、团队、生态和合规的冲击：写功能变得容易，维护和演化变成真正的难题；程序员的核心价值从“会写代码”迁移到“会设计低熵架构、会管理和压缩熵”；监控与日志系统被抬升为理解系统行为的“第二套源代码”；高熵代码甚至会被市场和合约用价格机制惩罚。
最后，本文尝试回答“如何驯服这股熵”：一方面在个人和团队层面，把自己从 coder 升级为 constraint designer / 熵管理者——用固定模板提需求，把重构变成默认动作，用架构约束、术语表、模块边界和 ownership 刻意压熵；另一方面在工具和模型层面，引入“代码熵”的可量化指标（结构熵、命名熵、依赖熵等），用重构样本、多目标优化、repo 画像、规划/执行/审查分工、自动重构 bot 和低熵 AI-native 框架，把高熵生成层关进笼子里，让 AI 写代码这件事，从“爽完就跑”走向“长期可演化”。
本文初版构思、创作于2025年4月，西双版纳。 彼时 Ai coding工具、概念（比如 planner、spec、skills等）还没那么完善。现在回头看，其中很多问题及解决方案，大家也有了共识。 但本文的出发点并不是为了描述这种现象又或是给大家推荐某些好用的工具，而是从熵的视角为大家拆解这个现象，阐述其必然性，并尝试给出一个长期有效的解决方案脉络。
一、vibe coding 和“高熵”整体图景
本文中，“vibe coding/ai coding”不是一个具体工具，而是一种范式：
- 我用自然语言跟模型描述我想要的东西；
- 模型给我产出大段代码、甚至整个项目；
- 我不再逐行写代码，而是通过：“看运行结果”、“看整体体验”、“再聊几句让它改”来驱动整个开发过程。
在这个范式下，使用者越来越不直接操控“代码符号”，而是在高层操控“需求 + 感觉 + 迭代方向”。
于是，一个核心现象就出现了：
在 vibe coding 里，代码和项目的“熵”非常高。
“熵高”在我心里不是一句吐槽，而是一个结构性的特征，几乎可以当成这个范式的“物理属性”：
- 从技术视角来看，高熵来自于模型的生成方式、目标函数、上下文限制、采样策略……
- 从行业视角来看：高熵会倒逼出新的角色、新的工具、新的规范体系，专门用来管理和驯服这些熵。
下面我就按照以下逻辑展开：
“高熵”具体指什么 → 为什么它是必然现象 → 对技术和行业意味着什么 → 如何量化、降低、驯服它“
二、在 vibe coding 里，“熵高”具体体现在哪些维度？
2.1 结构熵：项目形状的无序度
结构熵指的是项目的模块化和分层是否有明确模式：
- 文件/模块怎么划分？
- 层级怎么分（UI / Service / Domain / Infra / Repo ……）？
- 谁可以依赖谁？
在低熵项目里，这些是高度可预测的。在 vibe coding 项目里，很容易变成：
- 同一类功能散在乱七八糟的目录；
- 前端js直接调数据库；
- Service 之间互相随缘调用、又或是重新另起炉灶写一个已经存在的Service；
- util / common 越长越肥，谁都能 include 一下。
从依赖图视角看，就是：依赖关系越来越接近“随机图”。
2.2 风格熵：写法和习惯的无序度
风格熵指的是代码的写法是否统一，包括：
- 命名风格：
getUser,fetch_user,loadMember混在同一层； - 代码风格：有的函数超函数式，有的疯狂 OOP，有的纯过程式；
- 错误处理：有的用异常，有的返回 error code，有的返回
null； - 日志习惯：有的详细 structured logging，有的一句
print("error")。
低熵风格：即使是不同人写的，风格像“同一家公司”。
高熵风格：像 N 个不同团队外包拼出来的。
2.3 语义熵：对业务概念抽象的无序度
语义熵是我特别在意的一层，代码到底在表达什么业务语义，这件事是不是清晰统一？
高语义熵的典型表现：
- 同一个业务概念，有一堆不同叫法：用户（
user,member,account,profile,customer…） - 同一个状态，在不同模块用不同枚举/字段表达；
- 状态机逻辑分散在各处，没有一个清晰的“单一真相”（single source of truth）。
这会导致：
你可以勉强“把功能跑起来”，但没人能说清楚：这套系统在业务语义上到底是怎样一个模型？
2.4 时间 / 演化熵：项目发展轨迹的无序度
时间 / 演化熵指的是，项目随时间演化的“故事”是不是连贯。
低熵演化：
- 每次改动都能看出延续性：“为了解决 X，我们把模块拆成 A/B/C”；
- 历史类似一条主干道+一些分支支线。
高熵演化：
- 一会儿大改目录结构，一会儿模型重写；
- commit message 经常是
fix,update,try again这种； - 你很难复盘“为什么项目今天长这样”。
这种情况下，时间维度上也失去了“秩序感” 。
2.5 行为熵：系统实际行为的无序度
行为熵指的是，遇到各种输入/场景时，这个系统的行为是不是一致、可预测的？
高行为熵的表现：
- 同样的错误，在不同 API 中返回完全不同的格式；
- 同样的边界情况，在不同地方有不同的定义；
- 不同环境（本地、staging、生产）的行为差异巨大，因为配置和部署方式很随性。
行为熵高时：
- 写测试困难；
- 出问题时根因分析很痛苦。
2.6 知识 / 所有人熵：谁懂什么，谁负责什么，全是雾
这层对团队杀伤力很大：
-
许多模块是“我和模型聊着聊着写出来的”，没有明确的“代码之父/之母”；
-
换人之后，新人看到的是：
- 一堆 AI 生成的代码
- 零散的文档和聊天记录
- 很难判断哪些设计是有意的，哪些只是“模型临时发挥”。
于是：
“知识”变成了高熵的、分布在模型、聊天记录、残缺文档和代码中的一个云。
2.7 需求 / 规格熵：系统“该做什么”本身是模糊、飘忽的
在 vibe coding 场景里，需求过程经常是：
- 一边想、一边说、一边生成代码；
- 需求不像传统那样有一份稳定规格，而是散落在对话历史和脑子里。
结果是：
- 同一个行为在不同地方的描述和约束不一样；
- “到底需求是什么”本身就充满不确定性。
当“系统应该做什么”是高熵的，“系统最终怎么做的”肯定更高熵。
综合来看，对我来说，“代码熵”其实是一个多维概念：
结构熵 + 风格熵 + 语义熵 + 时间熵 + 行为熵 + 知识/所有权熵 + 需求熵……
而 vibe coding，几乎在每一维上都有把数值拉高的趋势。
三、为什么 vibe coding 天然倾向于高熵？
这部分我会从：模型机制 + 使用方式 + 工具生态 + 反馈机制几层来看。
3.1 模型本质是“条件概率机器”，不是“全局架构师”
模型干的是：
给定上下文 C，预测下一个 token 的分布 p(token | C)。
它优化的是“在训练数据分布下，下一个 token 的概率尽量大”， 而不是：
- “让整个项目结构尽可能简洁”；
- “让整个代码库熵最小”。
所以它擅长的是：
- 在局部上下文里产生看起来合理的代码片段；
- 模仿“常见套路”。
但它不会：
- 主动给你先画一份架构图（显然，目前不少coding agent工具再尝试这么做）；
- 再去做一套“最小描述长度（MDL）优化”的全局设计；
- 然后再填代码。
局部合理 + 全局不收敛 → 高熵，是自然结果。
3.2 目标函数错位：优化的是“似乎合理”，不是“长期可维护”
训练时的优化目标大多是：loss 最小；pass@k 更高；编译/测试通过率更高；对话满意度更高。
不在训练目标里的：长期维护成本；命名一致性；架构是否“可演化”。
所以模型学到的是：
“写一段看起来合适、能跑、离常见写法不太远的代码”。
而不是：
“在既有约束下写出最低冗余、最低熵、最易维护的实现”。
这在信息论视角就是： 模型偏向高熵的“够用就行”分布，而不是低熵的“极简优雅”分布。
3.3 prompt 驱动，而且 prompt 本身是模糊且随时间漂移的
传统工程里，很多约束是“硬编码”的：
- 目录结构；
- Style guide；
- 测试规范；
- 架构文档；
- review 标准。
在 vibe coding 里，很多变成：
- “写得更简单点”；
- “更 pythonic 一点”；
- “方便以后扩展”；
- “做成现代一点的架构”。
这些自然语言描述：
- 模糊；
- 人的表达会随心情、理解、阶段而变化；
- 项目越长，prompt 风格漂移越大。
于是，“约束本身”的熵就很高，那么在这些约束下生成的代码，自然也是高熵的。
3.4 生成过程是“局部补丁式”的，而不是“全局重构式”的
人在写代码时，往往是：
- 写一段；
- 一看结构不对；
- 回头重构、拆模块、统一命名。
这是一个“写+重构”交替的、主动熵减过程。
而典型 vibe coding 是：
- 我：“加个导出 CSV 功能。”
- 模型：在原文件里堆一段新逻辑。
- 我：“再加个筛选条件。”
- 模型：继续往刚才那块逻辑里加 if/else。
- 如此往复。
模型很少主动说：
“这块已经过于复杂，我先帮你全局重构一下。”
除非你明确提出，而每次重构本身也会带来新的随机性（命名/抽象又变了一轮），多次叠加，熵越来越高。
3.5 训练数据本身就是“高熵 + 混杂风格”
训练数据来自：
- 不同风格的开源项目；
- 不同时期的最佳实践和过时实践；
- 质量参差不齐的各种代码。
模型学到的是“统计上常见的东西”，而“统计上常见”的东西本身就不是一个统一、低熵的风格/架构。
于是它时而给你现代写法，时而给你上古写法，然后两者混在同一个项目里——高熵诞生了！
3.6 解码策略（采样）本身在注入随机性
为了避免模型“每次都写一模一样的东西”，我们会：
- 用 temperature、top-p 等采样策略；
- 不满意就 regenerate；
- 再不满意就换个说法再来。
这等于：
每一次生成都在向系统里注入一点“随机扰动”。
随着时间推移，这个噪声不会消失，而是沉淀在代码和结构中，变成高熵项目的一部分。
3.7 上下文窗口有限，模型视野是局部的
即便上下文很大，也不可能覆盖：
- 整个 repo 的所有文件；
- 全历史；
- 所有依赖关系。
所以模型在很多时候是“在局部视野下做决策”。这就像：
- 一个近视的、天才的实习生；
- 眼前一块看得特别清楚；
- 但全局结构没有完整掌握。
局部聪明 + 全局模糊 → 系统性高熵。
3.8 多模型 / 多工具 / 多Agent带来的“协议熵”
真实工程流程里，很可能同时有：
- 本地 IDE 小模型自动补全；
- 远端大模型写复杂逻辑；
- PR 上有 linter bot、refactor bot；
- CI 工具里还有自动修格式 / 修 import 的小工具。
它们：
- 训练数据不一样；
- 系统 prompt 不一样；
- 风格偏好不一样。
等于给一个项目请了好几个互相不沟通的外包团队，每个都在自己的视野里“帮你优化一下”。 结果全局风格很难不乱。
3.9 反馈机制偏向“短期可用”，而不是“长期健康”
不管是训练时的反馈，还是产品层面的用户反馈，大多都看：
- 这次能不能跑；
- 用户短期满意度；
- 测试/编译是否通过。
很少有机制能直接评价：
- 三个月后的维护难度；
- 重构时的成本；
- 新人上手的心智负担。
于是模型和工具都自然朝着一个方向优化：“先让这东西跑起来再说”。
而“跑起来”这件事，在搜索空间里有无数高熵解法。
四、高熵代码对技术和行业意味着什么？
这里我分几层看：单个项目、团队、开源生态、合规与市场机制。
4.1 对单个项目：从“写难”变成“维护难”
传统开发的难点更多在：
- 抽象业务；
- 写对逻辑；
- 管理复杂度。
vibe coding 把“写出一段能跑的代码”的门槛拉低了。 但因为熵高、结构和语义不统一：
- 写的时候很爽；
- 调试、重构、接手别人的代码会非常痛。
项目会越来越多地落在这样一个状态：
“能跑，但没人想动它。”
这就是“可运行但不可演化的系统”，也就是我心里非常危险的一种形态。
4.2 对团队：知识沉淀和责任归属都变得模糊
高熵项目里：
-
“谁真正理解这系统”这个问题，很难有明确答案；
-
很多模块没有强烈的 ownership；
-
事故发生时，责任划分也变得模糊：
- 是写 prompt 的人的锅？
- 是 review 没看仔细的锅？
- 还是“AI 写的”？
这会倒逼团队必须:
- 在“架构与边界”上更加形式化；
- 在 Owner / Oncall / Code Steward 这些角色上更加明确；
- 在事故复盘和预防上，引入更多结构化的约束。
4.3 对系统可观测性：监控和日志变成“第二套源代码”
因为代码的语义透明度下降，我会越来越依赖：日志、指标、tracing、profile 来理解：
“这个系统在真实世界中到底在干嘛。”
于是 Observability 不再是“nice to have”，而是理解系统行为的主通道。 可以说：
高熵代码 → 低可预期性 → 监控系统变成“新源代码”。
这也意味着：
- 写日志这件事要有体系；
- 日志结构、trace ID 等都要有严格规范；
- 否则、高熵 + 没有 observability，就是彻底瞎。
4.4 对用人标准：程序员的核心能力在迁移
随着vibe coding盛行，以后单纯“会写代码”的价值可能会下降； 而这几种能力会更吃香：
- 设计低熵架构的能力；
- 在高熵代码堆里快速建立心智模型的 debug 能力；
- 从亲自写业务代码，升级为设计规则和工具来指挥和约束 AI 写代码的能力
换句话说：
程序员越来越像“系统设计者 + 熵管理者”，而不仅仅是“代码生产者”。
4.5 对开源和生态：会出现大量“AI 分叉”的变种
大量人会：
- 把某个开源项目丢给模型改；
- 自动翻译语言、重构结构、加一堆定制逻辑；
- 产出一堆“AI 改写版”。
问题是：
- 这类 fork 风格和架构会和原项目差异巨大；
- bug 报告、PR 贡献、升级同步都会变得困难；
- 不兼容变种增多，整个生态的“整洁程度”下降。
这是一种生态层面的熵增。
4.6 对合规与安全：需要新的规范和工具
关键系统上：
- 合约 / 金融 / 医疗 / 核心基础设施；
- 监管和合规部门不可能接受“我们也不太清楚模型写了啥，只知道能跑”。
这会逼着行业去构建：
- “AI 参与开发”的审计记录；
- 哪些模块是 AI 生成、哪些是人工编写；
- 对关键模块强制代码审计和形式化验证。
高熵代码会被视为高风险区域，需要特别对待。
4.7 对商业模式：维护成本会进入计价体系
我可以想见一种模式：
- 外包/SaaS 不仅按功能计价；
- 还按“未来维护成本上限 / 技术债预算”计价；
- 甚至写进合同和 SLA。
在这种生态下：
- 高熵代码会在经济上被惩罚；
- 能够通过工具和流程持续压熵的团队和平台，会形成竞争优势。
五、既然“高熵是本性”，那我怎么考虑“驯服”它？
对我来说，“驯服高熵”的思路不是指望熵消失，而是：
承认生成层高熵，但在更高层和工具层建立“压熵机制”。
我会从四层来想：个人实践、团队工程、工具系统、生态和角色。
5.1 个人层面：从 coder 变成 constraint designer
我写代码时会刻意做几件事：
1）固定生成语法，降低自由度
不随意聊，而是习惯性按模板提需求，例如：
- 明确：输入/输出类型；错误处理策略；日志要求；
- 严格限制：“只写一个函数/一个类，不要额外逻辑”；“不得访问除 X/Y 以外的模块”。
这是我在“帮模型设计一个有限状态空间”。
2）把重构变成“每回合”的默认动作
不是代码乱了再想着“顺便 refactor 一下”，而是：
每加完一个功能，就立刻对那一片区域发起：“请检查刚才改动，给出重构建议并直接实现。”
等于在局部不断做熵减，而不是等熵累积到爆炸。
3）刻意培养“熵感知”
看代码时，我会有意识地问自己：
- 这里是不是开始风格漂了？
- 这里是不是新概念命名又变了？
- 这里的抽象层级是不是忽然跳了？
一旦发现“局部熵开始上升”，就尽早处理，而不是“算了先这样”。
5.2 团队/项目层面：用框架和契约把空间锁死一部分
1）强约束的架构模板
例如：
- 明确规定：
UI -> Application Service -> Domain -> Repository的依赖方向； - 明确每一层的职责；
- 把这些规则写成：文档、linter 配置、甚至是静态分析规则。
再配合使用 AI 时——prompt 里强制说清楚：“所有新增代码必须遵守上述架构。”
2）把命名/术语表 (Glossary) 升级为项目的“一等公民”
- 做一份清晰的 glossary：核心业务概念、官方命名、禁用别名等；
- 模型每次生成时都带上 glossary，让它只能用这套词。
这会有效压低语义熵和命名熵。
3）划清“人写区域”和“AI 写区域”
我的倾向是：
- 核心业务模型、关键算法、人写 + 严格 review；
- UI、外壳、适配层、简单 Glue 交给 AI 写。
这相当于：
在系统里圈出一块“必须低熵”的内核，外面允许高熵，但那一圈可随时丢掉重来。
5.3 工具层面：做“熵的画像、可视化和持续压缩”
1）Repo 画像器：自动提取“家族风格”
工具自动扫描整个仓库，生成：
- 命名风格画像；
- 典型架构模式；
- 依赖层次与边界；
- 常用 Helper/Util 模式。
然后 AI coding 工具在生成时：
- 把这份画像当系统 prompt 的一部分；
- 要求“贴合既有风格”。
等于告诉模型：“你现在是在这个家的传统下写代码。”
2）常驻的重构 bot / 规范 bot
不是一时兴起地 refactor，而是：
-
有 bot 持续地：
- 扫描重复代码；
- 标出可抽象的共性；
- 发现违背依赖规则的地方；
-
自动起 PR 做修复和归一化。
人工 review & merge，这就是一个守在仓库门口的“熵泵”。
3）依赖图 + 熵热力图可视化
- 把依赖图画出来；
- 对每个模块算一个熵指标（命名熵、风格熵、依赖熵）；
- UI 上用颜色标出“高熵区域”。
看到“红色区域”越来越多，大家天然会紧张；工具也可以自动对高熵区域优先安排 refactor 任务。
5.4 生态/角色层面：新职业、新框架、新计价方式
1）新角色：架构牧羊人 / 熵管理工程师
在团队内：
-
有人主要写业务逻辑；
-
有人主要负责：
- 抽象统一；
- 图谱干净；
- 重构规划；
- 工具与规范维护。
后者更像“系统园丁”，主要职责就是让整体熵保持在合理水平上。
2）新一代“AI-native、低熵框架”
未来我很看好一种框架：
-
针对 AI 使用场景专门设计；
-
强限定目录结构、模块边界；
-
完整定义：
- 一种错误模型；
- 一种日志模型；
- 一套标准抽象。
AI 在这样的框架里写代码：
- 自由度少了；
- 但输出更统一、更可控；
- 项目长期健康度更高。
3）按维护成本计价的服务模式
如果外包/SaaS不是只按“功能数量”收费，而是：
- 把“未来维护成本”写进合同；
- 则高熵代码的负面效果会直接以经济方式显形；
- 市场会奖励那些能够：生成快；还控制得住熵的团队。
六、如何给“代码熵”做一个可量化的定义？
从信息论的视角来想：
在某个维度上，如果“系统处于各种状态的概率分布 p(s)”很平均 → 熵高； 如果高度集中在少数几种状态 → 熵低。
对应到代码里，就是： 在命名、结构、依赖、风格等维度上，系统到底有多少种“写法/模式”，以及分布有多散。
6.1 结构熵 H_struct
做法大致是：
-
给每个文件/模块打一个“角色标签”：
UI / API / Service / Domain / Repo / Infra / Util / Test…
-
看依赖图里，“从某个角色 A 调用到各种角色 B 的分布”：
- 如果调用模式很集中（比如 UI 只调 Service），→ 熵低；
- 如果从任何一层出发都可能调到各种乱七八糟的层 → 熵高。
可以对每个角色算一个 entropy，再做加权平均，就是项目的 H_struct。
6.2 命名熵 H_name
步骤：
- 用 embedding / 词向量等方法，把所有标识符 cluster 成“语义簇”：用户相关一簇；订单相关一簇；状态相关一簇……
- 对每个簇内，统计实际使用的名字分布。
极端情况：
- 全用一个名字：熵最低；
- 每个名字都只出现几次：熵最高。
对所有“概念簇”的命名熵取平均，就是 H_name。这衡量的是：“一个概念是否被稳定命名”。
6.3 依赖图熵 H_dep
在依赖图上，可以看以下几个指标：
-
度分布熵：
- 节点的入度/出度是否高度集中在少数节点；
- 还是呈现随机图的扁平分布。
-
随机游走熵：
- 从任意一点随机走几步，看“最后落在哪类节点”的分布；
- 如果很快收敛到某层 → 图有明显结构 → 熵低；
- 如果近似均匀 → 图结构接近 random → 熵高。
-
强连通子图（SCC）分布：
- 大量大号 SCC → 往往意味着“循环依赖严重” → 结构上高熵。
6.4 其他可以量化的熵
- 风格熵：在格式、控制流结构、错误处理风格等维度做分布统计。
- 演化熵：对改动类型、改动范围、commit 模式做统计。
- 行为熵：对 API 返回格式、错误码、状态机转移做统计。
这些都可以变成仪表盘上的指标，用来监控项目的“熵健康度”。
七、典型 vibe 项目里，哪些信号在提醒“未来维护会很痛”？
我自己会特别留意以下“红灯”：
7.1 代码层面
- 超长函数、超长文件大量出现；
any（TS、Python）、动态类型滥用、宽泛的map<string, any>极多；- 用 embedding 或 AST 匹配能轻易找到大量“逻辑类似但实现不同”的重复代码；
- TODO / FIXME 满天飞，尤其是那种：“这里只是简单实现，未处理所有边界情况”的注释。
7.2 结构层面
- 依赖图上大号强连通子图（循环依赖）很多；
util/common/helpers目录体积膨胀并且谁都依赖；- 不同模块对错误处理、返回格式采用完全不同约定。
7.3 工具 / 流程层面
- 测试覆盖率低；
- 测试大多只覆盖 happy path；
- PR 常常动辄上千行，因为每次 AI 改一小块时顺便重写一片；
- 没有固定的 prompt 模板和架构约束文档，每个人都 freestyle 地对模型说话。
这些信号一旦叠加，我会下意识认为：
“这个项目将来改动会非常痛。”
八、从模型训练和工具设计的角度，怎么降低生成代码/项目的熵？
从训练 coding model 和做 ai coding 工具的角度，怎么降熵？
8.1 从模型训练角度
1）多目标优化：把“可维护性”引入奖励
在 RL / 对齐阶段，不只看：编译/测试通过、功能正确。
还要看：cyclomatic complexity、重复度、是否符合 style guide、是否符合某种架构约束。
这些都可以用静态分析工具测出来，给一套“熵分”，作为负奖励，让模型朝“低熵区域”去收敛。
2）用“重构对”数据（before/after）训练
大量喂模型：原本混乱代码 + 重构后的干净版本。
让模型学会：什么叫“解耦”、什么叫“抽象统一”、如何从高熵结构压缩成低熵。
3）训练 house-style adapter
基于有一个通用基础模型；然后针对某些大型 codebase，用它们风格统一、架构良好的代码做 adapter 训练。（开源模型 + 大型企业的代码库，未来可期啊！）
用的时候：先“切换到某个仓库的风格模式”（加载adapter），再生成。
这样可以让模型的输出分布，在具体项目上变得更尖锐、更有“家族感”。
4）拆出“规划/执行/审查”角色
模型可以分成三种能力：
- Planner：只规划架构、模块、接口；
- Coder：只根据规划实现；
- Reviewer/Refactorer：专职审核和压熵。
训练中就按照这种 pipeline 来，让模型整体行为更接近“人类的成熟工程流程”。
ps：目前好像很多coding model/agent系统已经是这么做的。
8.2 从 AI coding 工具设计角度
1）契约先行：先生成/维护设计文档，再生成实现
工具流程设计成：
- 先得到一份 machine-readable 的设计：模块列表、依赖关系、接口和数据结构；
- 再按设计生成代码；
- 之后任何修改必须：同时更新设计、禁止只在代码层偷偷搞事（tie doc-code 有木有！）。
这样，设计层可以保持相对低熵，把实现层的高熵“关在框架里”。
2）把 repo 画像塞进系统 prompt
AI coding 工具接入仓库时，自动做：风格画像、架构画像、命名规范提炼。
然后在每次调用模型时：系统 prompt 始终附带这份“仓库宪法”。
让模型在一个强先验下生成，而不是每次都从通用分布采样。
3）强制集成 formatter / linter / type checker / tests
每次生成 patch：
- 工具自动跑：格式化、lint（含架构规则）、类型检查、相关测试。
- 不通过就自动把错误反馈给模型，让它自己修到过为止。
这样，人类看到的是“已经在规则下收敛过一轮”的版本。
4）内置去重 / 复用引擎
工具维护一个本地“代码片段库”，遇到新需求时：
- 先搜有没有类似实现；
- 若有，优先建议复用/抽象；
- 再考虑新生成。
这可以显著降低“同一功能 N 种实现”的命名熵和结构熵。 （说起来这个东西好像目前还没有人做？codex、Claude code好像都没有，cursor有吗？很久没用了）
5）按区域控制“创意度”（temperature 分区）
- 对核心逻辑、基础设施区域：采用更保守的采样（接近 greedy）；
- 对 UI 文案、动画、样式：才允许更高 temperature。
简单说：该严肃的地方别 vibe；该玩耍的地方随便 vibe。
写在最后。首先感谢你耐心读完，如果你对本文的话题感兴趣，且有充足的时间和耐心，强烈推荐阅读本文第二版——Max版本。 Max版修订于2025年12月，不仅对原文每个章节做了细化与重构，还更加系统地从模型训练、系统设计、工具设计等角度阐述如何做“熵管理”。 高能预警，Max版字数 3w+。
