← All writing← 全部文章

From Vibe Coding to Engineering Guardrails: An HVAC Engineer's Notes on AI Agents从 Vibe Coding 到工程护栏:一个暖通工程师的 AI Agent 复盘

LCInformal essay随笔

At the end of my first post, Why I Built This Website, I promised to write next about my "vibe coding" experience—how I divided the work with AI, and what traps only a domain engineer would catch. Instead, two technical essays came out first (on air-cooling limits and warm-water plants), and the site itself outgrew its original shell. What started as a monthly brief and a 3D demo is now three distinct parts on dc-thermal.com: the five-angle AIDC Thermal Observatory (Outlook, Frontier, Products, Countries, and Industry Delivery, alongside the monthly report), AIDC Studio (with 3D campus planning, a site-climate pPUE calculator, and proposals), and Writing.

Along the way, I put most of today's major coding and research agents to work—Claude Code, OpenAI Codex, Grok in Cursor, and Gemini—across single-session pairing, multiplexed terminal task queues, and scheduled weekly, monthly, and quarterly jobs.

Coming back to write this retrospective a few weeks late turned out to be useful. My takeaway now fits in one sentence: AI agents dramatically expand what one engineer can build alone, but "vibe coding" stops working the moment physical numbers and system boundaries enter the picture. What actually kept this project standing was turning engineering judgment into hard, deterministic guardrails.


Trap 1: Letting Process Become the Main Product

For a weekend prototype in a single chat window, vibe coding feels effortless. The moment a project spans weeks and multiple models, memory becomes the first failure mode: a fresh session does not know what yesterday's session verified, what broke in production, or why a design option was rejected. To fix handoffs and prevent overwrites, I adopted structured project records (Journey for current state, plans, and logs; OpenSpec for public behavior contracts).

Handoffs stabilized—and immediately created the opposite problem. Left to themselves, AI agents love bureaucracy. Every task began spawning multi-page plans, dispatch cards, preflight checklists, and status commits. By early October, my single project-state file had swelled to 75 KB. Worse, a private three-year database backfill ran more than 700 high-reasoning model calls—burning through roughly half my account quota—while still leaving historical coverage incomplete.

One evening I halted the queue and wrote a short note in the log: "process became the main product."

The reset was blunt. I cut the state snapshot down to one page, banned status-only commits, deferred secondary equipment categories (like cooling towers) to protect token budgets, and put a simple value gate in front of every large task: Does this change what a visitor sees on the site, or does it teach me something new about how agents work? If neither holds, we do not run it.


Trap 2: Physical and Rating-Point Illusions Only a Specialist Catches

People often worry that language models invent numbers out of thin air. In practice, once you force an agent to read primary datasheets and SEC filings, outright fabrication is rare. The real traps are quieter—they compile cleanly, render neatly, and still violate engineering common sense.

First, mixing incompatible bases and duty points. Agents are fast at pulling numbers from PDFs, and terrible at respecting their operating conditions unless forced. Left unchecked, a draft will line up a server's maximum AC input, a rack's design power budget, and a cabinet's TDP in the same comparison, or repeat a widely shared "600 kW rack" rumor when the vendor's own document states 144 GPUs and gives no rack power at all. On CDUs, an agent will happily quote a brochure's 2.5 MW or 5 MW headline without noticing that at a 41 °C facility-water / 45 °C coolant warm-water point, only 4 K of approach remains—cutting real heat-rejection capacity by a third or more. On our country pages, an early version led with annual electricity in TWh; an engineer building data centers cares first about connectable grid power in MW or GW, and never mixes connection capacity with average load on the same axis without saying so.

Second, saying more than the source. Across dozens of reviews on our equipment deep dives and Frontier research cards, the most frequent defect was not a wrong digit—it was lost qualifiers. Words like "preliminary", "up to", or "in selected regions" quietly disappeared in summary; a conference talk title ("beyond 350 W/cm²") got turned into a shipped product claim; a future shelf-registration limit in a quarterly filing got added to cash already raised. Models have a persistent urge to polish conditional engineering statements into clean, overconfident prose.

Third, plausible 3D, misleading diagrams, and over-clever math. In Studio's early 3D builds, AI placed racks in isolation or piped the free-cooling heat exchanger in simple parallel with the chiller because a vendor's simplified brochure schematic drew it that way—missing that in a real plant, return water passes through the economizer exchanger (or its bypass) before entering the evaporator. Later, when integrating the pPUE calculator into Studio, an agent built an elaborate engine with a two-point Carnot fit, IPLV back-solving, and N+1 staging curves. The code was clever, hid its assumptions, and broke older saved snapshots. I tore it out and replaced it with how an HVAC engineer actually frames a concept check: decide first whether air and liquid cooling share one cold source or run separate loops (say, 20/30 °C for air and 30/40 °C for liquid), show an explicit annual load-profile table and a transparent 3%-per-K lift rule, and withhold the answer rather than guess whenever inputs are missing.

Visuals needed the same discipline. I rejected two early AI-drawn equipment figures—one turned cooling-tower water droplets into something resembling a human face at small scale, and another drew a CDU as abstract blocks—before having a subagent draw a structure-true isometric line cutaway from public datasheets, down to the brazed plate exchanger, redundant pumps, check valves, strainer, and drip pan. On the homepage, I went the opposite way and chose abstract heat-field contours over AI-generated "photos" of data halls, so decorative imagery would never masquerade as real piping.


Three Practices That Actually Worked in Multi-Agent Workflows

To build out the Observatory, I ran Claude Code as coordinator alongside Codex, Grok, and Gemini across terminal panes, wired together with a lightweight task runner and scheduled local jobs. Several fashionable multi-agent ideas proved overrated; three unglamorous habits paid off every single day.

  1. Agreement between two models is not correctness—cross-model adversarial review is. When building our first CDU matrix, I had two different models independently extract the same brochures and compared where they agreed. Column and unit errors still survived, because both models misread the same flattened PDF table in the exact same way—and the coordinator model introduced one more error while adjudicating. What changed everything was a strict rule: the reviewer must always be a different model family from the author (for instance, Claude authors and GPT/Codex reviews, or vice versa). Not a single major page on the site passed Round 1. First-round reviews routinely caught 7 to 15 real defects—such as Johnson Controls' Adjusted EBIT filed as operating margin, or a Carrier segment figure read as a company total. Round 2 typically left 1 to 6 fixes; by Round 3, the work held up.

  2. Cheap deterministic scripts first, expensive models second. Asking a frontier model to browse live web pages and verify its own citations is slow, expensive, and brittle against anti-bot 403 blocks or paraphrased web-fetch summaries. Moving mechanical verification into small scripts inside our build check changed our speed and reliability overnight:

    • Word-for-word quote checks (check_quotes): downloads raw HTML and PDFs locally and checks that every public quote appears verbatim in the source text (we even caught an early bug where loose hyphen matching allowed 5 °C to match inside −5 °C).
    • Pixel alignment and layout gates (check_alignment / measure_page): runs headless Chrome to measure vertical coordinates across side-by-side cards. Its first full-site pass caught 53 misaligned rows across 15 pages that my own eyes had skimmed past, which we drove down to zero with CSS subgrid—alongside automated checks for single-line headlines at 1440 px and zero horizontal scroll on 320 px phones.
    • Public-boundary guards: fails the build immediately if any private research cache, internal path, or unapproved asset touches the public bundle.
  3. Hash-lock human judgments so automation cannot drift. Scheduled local tasks now refresh weekly industry indicators, monthly report drafts, and quarterly roadmap candidates—but they write local candidates only and never publish on their own. Every page conclusion, country takeaway, and equipment judgment I approve is fingerprinted with SHA-256 in approvals.json. If a script or an agent alters a single word—even updating a headline ratio after new quarterly filings—CI blocks deployment until I review the change and re-sign it.


Where the Human–AI Boundary Settled

Early on, I reviewed nearly every intermediate step myself and quickly became the bottleneck. Once the script gates and cross-model reviews matured, I stepped out of the middle of the loop and kept only three responsibilities:

  • Framing the questions and setting decidable engineering rules. Rather than letting agents debate whether a large unit counts as an in-row CDU, I gave them a testable rule: 2,300 kW or below with a footprint near a standard rack is in-row; above that, it becomes room-level equipment. Debate turned into a deterministic check. Visual design worked the same way: adopting a neutral "precision instrument" palette where blue and orange represent only cold and hot fluids kept dozens of generated pages visually coherent without micromanagement.
  • Owning every engineering judgment and its failure conditions. An agent can parse five years of hourly NOAA weather observations across 18 stations in minutes, but a human engineer still has to state the boundary condition beside the chart (direct dry-cooler supply to facility water, versus losing another 2–3 K across an intermediate glycol exchanger) and write the "Where I could be wrong" section at the bottom of each essay. Whenever a fact check changes an underlying number, the judgment comes back to me for re-approval.
  • Holding the line on privacy, licenses, and token budgets. Deciding what stays local, how open-source fonts and drawing kits are credited, and when to stop polishing internal plumbing.

Rough Edges and What's Next

Multi-agent workflows today are still much rougher around the edges than polished demos suggest. Over the past few weeks, a local proxy's fake-IP DNS knocked Grok and Gemini offline for hours while Codex kept working; a missing UTC flag caused an October scheduled run to fire eight hours late; a primary review model hit its quota ceiling mid-sprint and forced a reviewer swap; and two active sessions touching the same working tree tripped our SHA-256 scope guard until I made isolated Git worktrees mandatory for parallel work.

Even with those rough edges, this experiment has answered the question I started with. AI agents are not about to replace domain engineers—in fact, the faster code and prose can be generated, the faster an unguarded agent can build an impressive structure on top of a wrong operating point. Put clear physical intuition and deterministic guardrails around these tools, though, and one engineer can now build and maintain an observatory, a 3D system studio, and a verified evidence base that would have taken a dedicated team not long ago.

The tools will keep getting faster; thermodynamics will not change. Let's keep building.

Personal notes from building dc-thermal.com. No employer view is implied.

在第一篇随笔《为什么我建了这个网站》的结尾,我原本打算紧接着聊聊和 AI “vibe coding” 的经历。结果中间先插了两篇讨论机柜风冷边界和暖水冷站的技术文章,网站本身也跟着翻了好几番:从最初的一份行业月报和一个 3D 演示,长成了现在的三个板块——五个视角的 AIDC 热管理观测站(前景、前沿技术、产品、国家与地区、产业交付,加上月报)、集成了园区规划与 pPUE 计算器的 AIDC Studio,以及个人写作。

这段时间里,我把市面上主流的编程与研究 Agent 几乎轮流折腾了一遍——Claude Code、OpenAI Codex、Cursor 里的 Grok,还有 Gemini;试过单窗口对话,搭过终端分屏的任务队列,也跑起了按周、按月、按季度触发的本地定时任务。

现在回过头来交这份作业,结论比一个月前清楚得多,用一句话就能说完:AI Agent 极大地放大了一个工程师的单兵动手半径,但“凭感觉写代码(vibe coding)”一旦碰到真实的物理数字和系统边界,很快就会撞墙;真正让项目跑稳的,是把工程老兵的边界意识变成硬性的检查护栏。


第一个坑:不小心让“流程”变成了主要产品

单次对话写一个小原型时,vibe coding 非常痛快。但只要项目跨过几天、涉及多个模型接力,第一个麻烦马上就来了:新开的会话不知道昨天改了什么、哪些数据核对过、哪个方案已经被否掉。为了解决失忆和互相覆盖的问题,我在仓库里引入了结构化的交接记录(Journey)和行为契约(OpenSpec)。

交接稳住了,新的问题却紧跟着冒出来:如果不加限制,Agent 天生热爱繁文缛节。 每做一件事,它都倾向于先写长篇计划、派发卡、预检清单和状态提交。到 10 月初,光是一份记录项目当前状态的 design.md 就膨胀到了 75 KB;更夸张的是,为了补齐过去三年的私有历史数据库,协调模型在后台跑了 700 多次高强度推理调用,吃掉了账号将近一半的额度,而三年历史的覆盖率依然是残缺的。

那天晚上我把任务停掉,在记录里写了一句话:“流程成了主要产品。”

随后的整改很直接:核心状态文档硬性压缩到一页纸以内;禁止任何只更新状态的空提交;因为 token 预算有限,主动缓掉冷却塔等次要品类的深挖;最重要的是,在启动任何重度后台任务前先过一道价值测试——这件事要么能改变访客在网页上看到的结果,要么能让我对 Agent 学到新东西。 两样都不占的后台“完美主义”,一律不做。


第二个坑:只有领域老兵能拦住的“物理与口径幻觉”

很多人担心大模型凭空编造数字。按我的实际体验,只要强制它去读厂商一手样本和财报原文,纯粹瞎编数字的情况并不多。真正危险的坑要隐蔽得多——它们写成代码能跑通,排成网页也很体面,但工程上是错的。

第一类是把不同口径、不同标况的数字混为一谈。 Agent 非常擅长从 PDF 里抓表格,但如果不盯着它,它会自然地把服务器最大交流输入、机柜设计功率预算和整柜 TDP 放在同一列里比较,或者把网上传言的“600 kW 机柜”当成既定事实(而厂商文档里只写了 144 张卡,根本没给功率)。在整理 CDU 样本时,模型很容易直接摘抄封面上的“2.5 MW”或“5 MW”标称值,却忽略了在 41 °C 设施水进、45 °C 冷却液出的暖水工况下,可用接近温差只剩 4 K,同一台机组的实际换热能力可能直接缩水三分之一。做国家页时也一样:初稿拿年度用电量(TWh)当主指标,但真正建数据中心的人首先关心的是电网能批出多少供电容量(MW 或 GW),而且绝不能把“平均负荷”和“报装容量”画在同一根柱子上不加区分。

第二类是“比原文说得更满”。 在设备深挖页和前沿技术卡的几十轮核查里,抓出最多的问题不是数字抄错,而是限定词丢了。原文里的“初步数据(preliminary)”“最高可达(up to)”“部分地区”在摘要时悄悄消失;学术会议上的一个报告标题(“迈向 350 W/cm² 以上”),转头就被写成了已具备的商业产品能力;财报里未来可分批使用的融资额度,被直接算进了当期已募集现金。模型总有把充满条件的工程事实“润色”成确定性结论的冲动。

第三类是看似合理的 3D 结构、示意图与过度复杂的公式。 在 Studio 早期的 3D 场景里,AI 会把机柜孤零零地摆在房间中央,或者照着厂家宣传册上的简化原理图把自然冷却板换和冷机画成简单的并联——而真实的冷站管路里,回水必须先经过板换(或其旁通),再进入冷机蒸发器。后来把 pPUE 计算器并入 Studio 时,Agent 一口气写出了一套带双点卡诺拟合、IPLV 反推和 N+1 启停逻辑的复杂模型,不仅把假设藏进了黑盒,还把旧版本的存档弄崩了。我最后把它全部拆掉,退回到暖通工程师做概念方案时的真实思考顺序:先定风冷和液冷是同源还是异源(例如风侧 20/30 °C、液侧 30/40 °C),给出一张透明的负荷时间分布表和每升高 1 K 衰减 3% 的简明规则;遇到输入缺失或超界,宁可不显示结果,也不替用户瞎猜。

连配图也是如此。我否掉过两版 AI 生成的设备试点图——有一版把冷却塔底下的水滴画得像一张人脸,另一版把 CDU 画成了抽象积木——最后要求必须对照公开技术规范画出板换、冗余水泵、止回阀、过滤器和接水盘的真实相对结构;而在网站首页,我干脆选了抽象的热场等高线插画,不用 AI 生成的“逼真机房照片”,免得任何一张装饰图在工程细节上误导同行。


多 Agent 协作真正管用的三件事

为了把观测站的五个视角铺开,我试过让 Claude Code 做主协调,在终端分屏里调度 Codex、Grok 和 Gemini 并行跑提取和核查。试了一圈下来,有些听起来很酷的多智能体玩法性价比并不高,反而是三件朴素的事每天都在救命:

  1. 两个模型看法一致,不等于结果正确;“异构模型互审”才真正管用。 做 CDU 产品矩阵时,我曾让两个不同的模型独立提取同一批样本,再比对一致项。结果列错位和单位错误还是漏了过去——因为同一张跨页 PDF 表格被压平后,两个模型在同一个地方看走了眼,连负责裁决的主模型也跟着判错了一处。后来我定了一条死规矩:审查者必须和作者来自不同的模型家族(比如 Claude 写的页面交给 Codex/GPT 审,反过来也一样)。这条规矩立竿见影:整个价值链和观测站上线的所有重头页面,没有任何一页在第一轮审查就通过。第一轮通常能抓出 7 到 15 个真实问题(比如把江森自控的调整后 EBIT 当成营业利润率、把开利某个业务板块的数字当成全公司总额),第二轮剩 1 到 6 个,跑完第三轮才真正扎实。

  2. 先跑便宜的确定性脚本,再上昂贵的模型。 让大模型自己联网打开网页核对引用,既慢、又费额度,还经常撞上反爬拦截或抓取工具的自动改写。把机械检查写成小脚本放进发布门禁后,效率完全变了样:

    • 逐字引文检查(check_quotes):把原始网页和 PDF 抓到本地,逐字比对公开页面上的每一句引文(早期连字符宽松匹配曾把 −5 °C 误判成匹配 5 °C,也是靠测试抓出来的)。
    • 像素级对齐与排版检查(check_alignment / measure_page):用无头浏览器直接量并排卡片里标题、数字、标签的纵坐标。脚本第一次跑全站就抓出了 15 个页面里的 53 处错位——很多肉眼扫过去很容易放过——全站改用 CSS subgrid 后降到了 0 处;同时强制检查 1440 px 下的单行标题和 320 px 手机屏上的零横向溢出。
    • 公私边界门禁:构建时自动拦截任何私有目录、原始样本或未授权路径。
  3. 用哈希锁死“人的判断”,不让自动化越界。 现在每周的数据刷新、每月的行业报告和每季度的路线图候选,都交给了本地定时任务自动跑,但它们只准在本地生成候选稿,绝不自动发布。网站上所有由我确认的页面结论、国家热管理解读和设备研判,都会计算中英文 SHA-256 指纹写进 approvals.json。哪怕定时任务只是根据新财报把标题里的一个比例从 77% 改成了 78%,只要我还没审过并重新签名,发布检查就会直接拦截上线。


人和 Agent 的分工最后停在哪里

项目前半段,几乎每一步中间结果都要停下来等我点头,我自己成了最大的瓶颈。等脚本门禁和异构模型互审跑顺之后,我把自己从中间环节撤了出来,只死守三件事:

  • 提问题,定可判定的工程规则。 比如与其让模型反复争论某台大冷量设备算不算列间 CDU,不如直接给一条经验规则:“2,300 kW 及以下、占地接近标准机柜的算列间,往上的归入房间级”,争论立刻变成了可执行的测试。视觉上也一样:全站采用“精密仪器”中性灰,规定蓝色和橙色只准代表冷流体和热流体,不作任何装饰色,AI 改起几十个页面来就不会跑偏。
  • 对最终工程判断和“我可能错在哪里”负责。 AI 可以帮我把 18 个气象站五年的 NOAA 逐时数据算成自然冷却小时数,但必须在图表旁边写清楚“假设干冷器直供设施水,若加乙二醇板换需额外扣减温差”的那个人是我;每一篇分析最后写下反转条件、约定 2027 年底回看的也是我。只要核查改了底层的事实,对应的结论就必须退回来由我重审。
  • 守住合规、隐私与额度边界。 决定哪些资料只能留在本地、开源许可怎么署名,以及什么时候该果断喊停省下 token。

还没解决的摩擦,以及接下来

实话实说,今天的多 Agent 工具链远没有演示视频里那么丝滑。过去这阵子,我遇到过本地代理的 Fake-IP DNS 把 Grok 和 Gemini 同时卡断几个小时(只有 Codex 还能照常干活);遇到过定时任务没写死 UTC 时区,导致十月月报晚跑了整整 8 个小时;遇到过主力审查模型在半途耗尽额度,只能临时切换高强度子代理顶上;也踩过两个窗口同时改同一个工作区、触发脚本防篡改警报的坑——后来凡是并行改动,一律老老实实开独立的 Git worktree。

但即便算上这些磕磕绊绊,这个项目也已经回答了我建站之初的好奇心。AI Agent 不会替代懂物理世界的工程师——恰恰相反,代码和文字生成得越快,一个缺乏工况常识的系统就越容易在错误的假设上盖出一座漂亮的危房。可一旦工程老兵想清楚了物理边界,再用脚本和交叉审查把护栏立起来,一个人能独立搭建和维护的东西,确实已经相当于过去的一支小团队了。

工具还在变快,物理定律不会变。继续动手做点东西。

个人实践记录,不代表任何雇主立场。