序章：Vibe Coding 的幻灭与“认知债务”的雪崩
2024年开始，科技圈就被一个极具诱惑力的词汇裹挟了——Vibe Coding（氛围编程）。
在社交媒体的狂热演示中，产品经理只需用大白话敲出百十字的需求，AI 就能凭空吐出一个带有漂亮 UI、鉴权登录和数据库交互的 SaaS 原型。一时间，无数人产生了一种强烈的错觉：软件工程的门槛被彻底抹平了，甚至连“严密逻辑”都不再是必需品。只要你会说话，AI 就能洞察意图，构建一切。
然而，当我们满怀憧憬地将这种“氛围编程”应用到真实的生产环境、试图去构建一个哪怕只有中等复杂度的商业系统时，现实却给出了响亮的一记耳光。
我们迎来的不是生产力的解放，而是深渊般的“调试地狱”。
在真实的工程场景中，AI 仿佛精神分裂：它上一秒刚用极优雅的设计模式重构了一个模块，下一秒就在关联文件里写出了让系统直接宕机的荒谬逻辑；你让它修一个 Bug，它像多米诺骨牌一样引发了另外三个功能崩溃。它确实能在一个周末为你生成上万行代码，但这些没有任何架构防腐层、缺乏边界约束的代码，堆砌成了一座人类和机器都无法维护的“赛博屎山”。
为什么会这样？
因为 Vibe Coding 的本质，是一种极度危险的 YOLO（You Only Live Once）编程。它跳过了人类软件工程演进几十年才总结出的防御性铁律——需求澄清、架构设计、模块隔离、同行审查。
当你不看 Diff、不写 Spec，全凭“感觉”让 AI 一路狂飙时，你以为在拥抱指数级效率，实际上是在以光速积累“认知债务（Cognitive Debt）”。在软件工程中，写代码从来不是最难的，最难的是“维护系统状态的连贯性”以及“保留当时做架构决策的业务意图”。AI 生成的海量代码，割裂了逻辑与意图的联系，几个月后，这些庞大的代码库将成为无人敢碰的禁区：你不知道当初为什么要这么写，AI 更早就遗忘了当时的上下文。
这种狂欢与幻灭的落差，迫使我们必须冷静下来，剥开大模型耀眼的表象，去追问一个最本质也最痛的问题：
为什么那些在 Demo 里无所不能的 AI，一旦踏入复杂真实的工程世界，就注定会频繁翻车？
第一部分：剥开黑盒——AI 不可靠性的底层逻辑
理解 AI 的局限，必须摒弃对大模型一厢情愿的“拟人化”想象。我们总不自觉地把大模型投射成一个“经验丰富、不知疲倦、偶尔粗心的高级工程师”。但从计算机科学与数学的视角来看，这是我们犯下的最大错误。
1. 概率预测器的宿命与 p^n 的指数级诅咒
要揭开 AI 频频翻车的真相，必须直面其核心定义：当前的大语言模型（LLM），本质上只是一个高维的概率预测器。
它没有在“思考”，没有在“推理”，更不是基于对计算机体系结构的深刻“理解”。它只是在海量人类语料的统计规律中冲浪，计算出基于当前给定的 Token 序列，下一个最有可能出现的 Token 是什么。
既然本质是概率计算，就带来了一个极其残酷的数学必然：p^n 困境。
在由概率驱动的任务链中，不确定性会随着步骤的增加而发生灾难性的叠加。
假设当前的顶尖 AI 完成单个独立编码步骤（比如写一个正则表达式）的成功率极高，达到了 p=95%.
如果任务只有 1 步，AI 像神一样完美。
如果任务需要 10 步连续交互，0.95^10 = 60%，你开始察觉到它经常会犯错。
如果任务是一个包含了建表、接口设计、状态切分、异常处理的复杂业务功能，需要 50 个步骤。那么它一次性成功的概率是：0.95^50 = 8%.
这解释了为什么“端到端全自动开发一个复杂软件”目前依然是科幻小说。在这个呈现指数级单调递减的曲线上，所谓的“扩大模型参数量（Scaling Law）”是无力的。就算未来的 GPT-5 把单步成功率硬生生砸到了 99%，对于一个 100 步的复杂工程来说，0.99^100≈36%。只要 p≠1，随着系统复杂度 n 的增加，大模型必然会在某一个不可预知的节点坠毁。
在人类主导的系统中，我们用确定性的逻辑（if-else）对抗业务的熵增；而用全权委托的 AI Agent 接管流程，实际上是将确定性的工程，替换为了概率性的赌博。
2. Skin in the Game：真正的不可靠，源于对后果的“漠视”
如果仅仅是算错概率，还可以通过冗余来弥补。AI 最致命的问题在于：它缺乏内驱的责任感，即塔勒布所说的“切肤之痛（Skin in the Game）”。
我们为什么相对信任资深人类工程师？因为人类社会的信用体系建立在“风险共担”之上。一个深夜排查线上故障的程序员，会反复查阅日志、小心翼翼地修改配置，因为如果草率导致公司巨额损失，他将被问责，他的生计会受到实质性威胁。因为这种恐惧，人类演化出了极强的自我纠错机制与敬畏心。
反观 AI，它是一个毫无痛感的概率幽灵。你在提示词里写上“如果你写错了，将会有 10 万人失业，你会遭到最严厉的惩罚”，这种所谓的“情绪提示词（Emotional Prompting）”或许能在一定程度上改变它输出的局部概率分布，让它“扮演”得更严谨一些（比如在回答前多输出一些思考的过程），但它依然毫无痛感。
它不关心这行代码运行后是指向内存泄漏，还是将核心库误删。它唯一优化的目标，是输出一段“在数学统计上最接近提示词、最像正确答案”的字符序列。一个不仅会犯错，而且对错误造成的灾难性后果毫无畏惧、不会有丝毫心理波动的执行者，如果你将复杂系统的控制权全盘交由它去 Vibe Coding，这无异于将核按钮交给一台投币摇奖机。
3. “莫拉维克悖论”与 Unknown Unknown 的深渊
人类能力的成长，具有极其严格的层级递进性与累积性。一个能设计分布式秒杀系统的高级架构师，绝对不可能今天早上突然忘了什么是 HTTP 协议。作为技术管理者，你对他的错误边界是有预期的（Known Unknowns），从而可以设立针对性的 Code Review 和压测防御。
但在大语言模型身上，认知科学中的“莫拉维克悖论”正在重演：它能瞬间完成极度困难的抽象任务，却在基础常识的底线上轰然坍塌。
它可以前一秒像架构大师一样跟你探讨 Raft 与 Paxos 协议的优劣；
下一秒当你让它把讨论结果写入 Markdown 文件时，它却迷失在一个基础的文件流闭合逻辑里；
它可以帮你生成极其高大上的 React Hooks 状态流转，却在最基础的 CSS Flex 居中对齐上反复翻车，花掉几十个 Token 依然原地打转。
它的高耸入云，并不建立在坚固的地基上。 当你连错误的边界和类型都无法预判（Unknown Unknowns）时，根本无从设立检查点。人类写单测的常规逻辑防不住 AI，因为 AI 写出的 Bug，往往超越了人类对“犯错”这件事本身的想象力。
第二部分：软件工程的焦土——当概率猛兽撞上“本质复杂性”
如果让这种 AI 去写公关稿、做插画，代价仅仅是几张废稿。但为什么当它进入“软件开发”领域时，后果却如此灾难性？
这要求我们重新审视软件工程的宿命：代码，从来不是资产，而是负债（Code is a Liability）。
1986年，软件工程鼻祖 Fred Brooks 发表了著名的断言《没有银弹》。他将软件开发的困难分为两种：
附属性复杂性（Accidental Complexity）： 配置环境、处理底层内存分配、语法转换等工具带来的麻烦。
本质复杂性（Essential Complexity）： 现实世界错综复杂的业务逻辑，如金融清算规则、电商逆向退款流程。
回过头看，人们对 Vibe Coding 的狂热，本质上是混淆了这两种复杂性。
AI 确实是一颗击碎“附属性复杂性”的银弹。它消灭了手写样板代码的时间，极大地降低了打字成本。 但同时，AI 正在把“本质复杂性”绞成一团死结。
物理学有“熵增定律”，软件工程有“软件演化定律”。系统只要在不断修改，架构必然腐化。人类架构师尚且受限于排期压力，被迫在代码库里挂载特化参数；当你不加约束地让 AI 接管迭代时，面对庞杂的隐性业务知识，AI 既没有“妥协的美学”，也不懂“康威定律”。
它解决冲突的唯一方式，就是用最快、最直白但也最脆弱的意大利面条式代码（Spaghetti Code），去强行满足你 Prompt 里的字面需求。
它帮我们省下了敲击键盘的 10 分钟，却预支了未来排查逻辑死结的 10 个小时。这种没有边界的概率猛兽一旦闯入本就摇摇欲坠的复杂系统中，剩下的只有满地焦土。
第三部分：系统工程的觉醒——从“单体驯化”走向 Harness 架构
如果 AI 自身注定是一个不可靠的概率盲盒，而软件工程又天然趋向于腐化，我们难道只能封杀大模型在生产环境中的使用吗？
不。对抗个体不可靠性的终极解法，人类社会早在工业革命和现代 DevOps 的演进中就已经找到了——系统工程（Systems Engineering）。
为什么成熟的科技企业敢让成千上万名水平参差不齐、偶尔还会犯低级错误的程序员，去共同维护核心交易系统？因为我们信任的从来不是“个人的绝对可靠”，而是“研发管道（Pipeline）”。 哪怕有人昨天喝醉了把 delete 写成了全表删除，静态扫描和自动化测试的层层铁网也能将其精准拦截。我们接受“个体必然犯错”，但通过“系统框架”清零了全局崩溃的风险。
面对 AI，我们必须实现同样的认知跃迁：停止乞求大模型变聪明，转而构建一套严密的系统去“驾驭”它。
这就是当前 AI 工程界最重要的范式转移：从迷信“Big Model（模型即一切）”转向重仓“Big Harness（系统治理架构）”。
Harness 原意是赛车手的六点式安全带。在 AI 语境下，它指的是一套包裹在大模型外围的运行环境（Envelope）。在这套环境里，AI 的不可靠性被捕获、限制、降级，最终使整个系统向外输出高度的确定性。
要在真实业务中落地 Harness 架构，我们需要为其打造四个维度的“安全带”：
维度一：Context Engineering（上下文工程）——把控“记忆域”
很多开发者有一种错觉：把整个代码仓库的几百个文件直接塞进拥有 200K 长上下文的 AI 模型中，它就能全知全能。然而，认知科学中的“Lost in the Middle（中间迷失）”效应无情地证明：信息过载会导致大模型注意力严重稀释，进而产生严重的幻觉。
❌ Vibe 式做法： 暴力注入全量代码库、数十页毫无结构的 PRD 文档。 ✅ Harness 架构： 实施“最小特权上下文”。基于 AST（抽象语法树）或 LSP（语言服务器协议），精准按需提取与当前任务强相关的接口声明、类型定义。过滤掉一切无关的实现细节，让 AI 永远在最高效的“认知舒适区”内运算。
维度二：Constraint Engineering（约束工程）——缩小“爆炸半径”
“自由”是系统可靠性的天敌。不加约束的 AI，就像手握核按钮的巨婴。Harness 必须在物理和逻辑层面对其施加强约束。
❌ Vibe 式做法： 给 AI 赋予笼统的 execute_bash 或全局 DB 写权限；依赖其自由发挥输出格式。 ✅ Harness 架构：
工具白名单： 仅暴露极其原子化、经过强校验的工具接口（如 query_order_by_id）。
类型铁律： 结合 Zod 或 Pydantic 等 Schema 校验工具，强制 AI 输出严格的 JSON 结构。一旦缺少必填字段或类型不符，Harness 层直接截断并在内部发起重试，绝不将脏数据流转到下游。
维度三：Feedback Loop（反馈闭环）——用“确定性”捕获“概率性”
没有自我纠错能力的 AI，必须依靠外部环境为其构建闭环。用确定性的编译器错误和测试用例，去逼迫概率模型收敛至正确答案，是驾驭 AI 的最高级手段。
❌ Vibe 式做法： AI 生成代码 -> 人类肉眼大概扫一眼 -> 直接合并运行。 ✅ Harness 架构（TDD 沙盒）： AI 生成的代码必须被抛入一个隔离的 Docker 沙盒中，运行预设的 Unit Test。通过测试，才能升级为“候选代码”；若抛出异常，Harness 会自动抓取大红色的 Error Trace（错误堆栈）精准反哺给 AI 勒令重写。
维度四：Observability（可观测性）——击穿黑盒的迷宫
传统的 APM 监控 CPU 和内存，而 Harness 需要监控的是 “认知链路”。
❌ Vibe 式做法： 出现 Bug 时，对着最终生成的错误代码发呆，不知道 AI 抽了什么风。 ✅ Harness 架构： 建立 AI 专属的 Trace 体系。精确记录：哪个步骤调用了什么 Prompt？消耗了多少 Token？触发了哪次 Tool Call？大模型的推理延迟是多少？只有具备了可观测性，我们才能像外科医生一样，精准定位是上下文缺失，还是工具返回了脏数据。
第四部分：Agentic Engineering——落地生产的三大金科玉律
如果说 Harness 是机器底层的防御基建，那么 Agentic Engineering（智能体工程） 就是建立在其上的人类工作 SOP（标准作业程序）。
2 026年初，曾提出 Vibe Coding 的前特斯拉 AI 总监 Andrej Karpathy 亲手为一年前的狂热按下了暂停键。他坦言：毫无约束的 AI 生成引发了难以估量的代码债务，专业人士必须转向 Agentic Engineering——即需要更严格的监督、更结构化的拆解、更严密的审查。
它的核心要义只有一条：AI 负责构建，人类负责兜底。
在一线生产环境中，这体现为三大不可逾越的金科玉律：
原则一：确定性优先——能用代码固化的，绝不用 AI 去“猜”
回顾上篇推导出的 p^n 困境，破解概率指数衰减最暴力的手段，就是想尽一切办法把步骤 n 降下来。
真正强大的 AI 协同系统，是尽可能少地让 AI 承担“可被程序化”的任务。
❌ 灾难操作： “请帮我把项目打个包，如果是 Debug 就开 x 配置，Release 就开 y 配置。” ——这是在人为增加概率环节，AI 明天可能就会漏掉一个参数。 ✅ 工程实践： 精心编写一个 build.sh 脚本固化复杂逻辑。你的指令只需一句：“执行 sh build.sh release”。 同理，绝不要指望 AI 能代替静态代码扫描（Lint）。 引入 SonarQube 并把规则写死。静态扫描确实没有大模型聪明，但它拥有大模型永远无法企及的特质：100% 的绝对确定性。把这些环节固化，就是把 p^n 链路中的概率替换成了绝对的 1。
原则二：收敛可能性空间——强行划定业务边界
面对“开放性问题”，大模型的表现往往是发散且灾难性的；但在“极度约束的条件”下，它才能爆发出惊人的生产力。
❌ 灾难操作： “帮我优化一下这个接口的性能，太慢了。” ——此时 AI 面前有无数条路（改算法、加 Redis、做 MQ），它极大概率会挑一个最不适合当前业务现状的方案，把系统改得面目全非。 ✅ 工程实践： “这个 create_order 接口瓶颈在 MySQL。请严格在这个边界内帮我：1. 仅使用 Redis 接入旁路缓存；2. Key 必须带 user_id 前缀防冲突；3. TTL 统一设为 5 分钟。禁止引入或修改任何外部依赖。” 你看似在写 Prompt，实际上是在做软件工程最核心的决策：划定业务与技术的边界。
原则三：极端审查与说明书驱动（Spec-Driven）
对抗不可靠性的最高法则，是实施阶梯式交付，并在每一个节点进行强人工重置（将概率强行拉回 100%）。
Spec First（说明书优先）： 这是一个极其关键的心智反转。在让 AI 写代码前，先让它（或你自己）输出 Markdown 格式的设计文档（数据结构、边界条件、并发点）。代码是极易报废的负债，但梳理过的 Spec 是能长久沉淀的资产。 哪怕这轮代码生成失败了，这份确定的 Spec 也是极佳的黄金上下文。
极端代码审查（Extreme Code Review）： AI 改了 200 行代码，哪怕它“看起来能跑”，你也必须逐行阅读。如果你看不懂它为了炫技而使用的某个生僻 API，就决不允许合入分支。你不知道的逻辑，就是未来的线上定时炸弹。在 Agentic 时代，你的核心价值体现在你冷酷地拒绝了多少糟糕的 AI 提案。
终章：未来工程师的身份质变与宿命
长久以来，悬在无数从业者头顶的达摩克利斯之剑是：“AI 这么强，程序员会大量失业吗？”
基于全文的剖析，答案已经非常清晰了：AI 绝不会让软件工程师失去工作，但它会无情地淘汰掉“打字员与代码翻译机”。
回望计算机科学的历史，我们其实一直在做同一件事：提升编译器的抽象层级。 早期，人们用打孔纸带写机器码；后来，人们写汇编，汇编器翻译；再后来，人们写 Java/C++ 这种高级语言，编译器处理底层的内存与寄存器。
今天，大语言模型仅仅是人类历史上又一个新形态的“自然语言编译器”。 过去，你把产品需求“翻译”成 Java 代码交由 JVM 执行；未来，你把充满商业意图的需求“翻译”成高度结构化、充满约束的 Spec，AI 借由 Harness 系统将其“编译”为代码，再交由机器执行。
在这样的范式转移下，软件工程师的能力模型将发生极其剧烈的翻转。手写红黑树或熟记某个偏门 API 的能力将迅速贬值，而以下能力将成为不可逾越的护城河：
深度剖析业务本质的能力： 对需求边界极度敏感，知道如何处理异常流和逆向业务。
结构化表达与领域建模： 能用无歧义的语言，为大模型提供最精准的约束（写好那份 Spec）。
系统级的解构力： 能将庞大复杂的系统，拆解为确定性的组件和可孤立验证的微小任务。
防御性审查思维： 对任何不明代码保持敬畏，从“代码编写者”转变为“严苛的质量法官”。
未来的软件开发不会变轻松，反而会更加繁重和烧脑。因为伴随着“打字成本”的消除，企业会去挑战规模更大、逻辑更复杂的系统。你不再是在泥泞中独自搬砖的工人，而是坐在监控室里，看着外面几百个“极度聪慧却随时可能脱轨的 AI 工人”疯狂运转的“大楼监理”与“系统操盘手”。
在这个时代，淘汰你的不是 AI。淘汰你的，是那个比你更早掌握了利用系统约束 AI、利用纪律对抗混乱的工程师。
剥开光鲜亮丽的 AI 幻象，软件工程的底层真理从未改变：系统必须要有架构，复杂性必须被隔离。而为最终质量与商业后果兜底的，永远是那个拥有切肤之痛（Skin in the Game）的、鲜活的人类。
后记： 至此，我们从“道与法”的层面，完成了对 AI 时代工程哲学的拆解与重塑。但这仅仅是思想的武装。一套真正落地的企业级 Context 引擎如何编码？如何用代码组织多智能体的隔离与观测？ 在下一篇《hiclaw 实战：脱虚向实，用代码构建 Multi-Agent 的底层基建》中，我们将潜入代码深水区，直接解析 Harness 架构的最佳工程实践。敬请期待。
————————————
以下待修订
痛点引入： 无论如何优化，AI 依然是不可靠的（无法确定是否在舒适区，p^n困境让复杂任务成功率指数下降）。
认知反转： 人也是不可靠的（会犯错、有情绪、会请假），真正的问题在于“不可靠性是否可控”。
人类团队的启示： 剖析成熟的软件团队如何用系统容错（需求评审、Lint/Code Review/测试分层、CI/CD/Feature Team备份）。
核心结论： 用外部系统对抗个体不可靠。AI 负责大部分“脑力+体力”输出，人类负责“评估和决策”。责任主体永远是人。
无论如何优化，AI 依然是不可靠的。我们无法确定给定的信息是否足够，也不知道 AI 现在工作在曲线的哪个区间。
所以真正的问题不是AI是否可靠，而是AI的不可靠性 是否可控
Harness Engineering = 让AI“可控、可用、可持续”的系统工程能力
Vibe Coding 是未来软件开发的新范式，但距离几句话就能完成专业级的软件开发还很远
它绝对不是很多人想象和网上吹嘘的那样——一个啥都不懂的门外汉，只需要几句话就能完成专业级的软件开发。
逻辑不严谨、边界情况没考虑、性能有隐患、甚至有明显的错误
任务描述要精确：不是“写个排序”，而是"写一个针对整数数组的快速排序算法，包含详细注释，时间复杂度说明，以及边界情况处理"
上下文要相关：如果你在开发一个 Web 应用，那么相关的技术栈信息、项目结构、编码规范都是有效上下文
约束条件要明确：性能要求、兼容性要求、安全要求等
期望输出要具体：不是“帮我优化”，而是“针对这个函数的内存使用进行优化，保持 API 兼容性”
复杂任务的成功率会呈指数级下降。这不是工程问题，不是优化问题，而是数学必然。
假设 AI 完成单个步骤的成功率是 p，那么完成 n 个步骤任务的成功率就是 p^n。这公式看着简单，但威力惊人：
0.95^10 = 60%
0.95^20 = 35%
0.95^50 = 8%
三大黄金原则：
确定性优先（把重复环节固化为程序，AI辅助不确定性环节）。
减少可能性空间（给 AI 提供强约束）。
输出可累进的阶段性成果（用数学逻辑对抗p^n困境）。
反面教材： 一次性让 AI 生成所有代码的灾难（难定位、牵一发而动全身、无法传递上下文）。
最佳实战（核心篇幅）： 以“用户积分系统”为例，演示 4 个阶段的标准 SOP：
阶段1：明确需求（产出高价值 Prompt 文档）。
阶段2：方案设计（产出架构蓝图）。
阶段3：任务拆分（缩小爆炸半径，明确验收标准 BDD）。
阶段4：编码实现（结合 agents.md 规范）。
能力进化： 声明式编程的崛起（人提供 What，AI 提供 How），以及开发者未来真正该积累的核心资产（领域模型、Prompt资产、核心逻辑实现）。
metespher自动化测试
CIDI
关键节点-优质AI
输出阶段产物
开发
review
测试
便宜ai
需求讨论、确认
生成基础说明书
生成多个候选demo
确认后
基于文档模板，生成详尽需求说明书，明确边界
生成详细设计说明书
当某些子任务可以用确定性的方式完成时，永远优先使用确定性的方法，而不是依赖“智能”。
理解需求、设计数据库表结构、编写API接口、实现表单验证逻辑、处理错误情况、编写单元测试
错误的思路是 期望找到某种方法让 AI 能独立完成复杂的端到端任务。不断优化 Prompt 试图提高单步成功率，这在简单任务上虽然可能有改善，但复杂任务依然会频繁失败。而正确的思路应该是是 合理规划 人、程序、AI的分工，让拆解出尽量多确定性的部分让程序去完成，AI只处理难以程序化的模糊部分，然后人来做质量把控和关键决策。
agentic engineering
Vibe Coding 为啥在生产环境翻车？
1. 安全漏洞批量出现
AI 写得快，不代表写得安全。
一个 agent 每周写 1000 个 PR，即使只有 1% 的漏洞率，每周也会产生 10 个新漏洞。Vibe coding 没有任何关卡，你只能照单全收。
2. 代码架构没法维护
Vibe coding 跳过了设计阶段。
你 prompt 一个功能，agent 实现它，然后你继续下一个。三个月后，没人——包括你自己和 agent——知道代码为什么这么结构。没有设计文档，没有架构思路，全是债。
3. 上下文越来越乱
Vibe coding 的会话时间越长，输出越差。
agent 会丢失之前的决策，代码开始自相矛盾。而开发者根本没注意到，因为他们根本不读 diff。
2026年，认知债务（cognitive debt）——AI 交互管理不当、上下文丢失、agent 行为不可靠的累积成本——正在成为工程团队的主要威胁。Vibe coding 创造认知债务的速度，比以前任何开发方式都快。
Agentic Engineering 到底怎么做？
其实步骤不复杂，但需要强调纪律性/规范性。
第一步：先写规格说明书
在 prompt 之前，先写设计文档。
这个功能要做什么？边界情况有哪些？数据模型长什么样？什么地方可能出问题？
这是 vibe coder 跳过的步骤，也是决定 agent 产出好代码还是垃圾代码的关键。
你可以用 AI 辅助写 spec，但要在 agent 碰任何文件之前完成。
第二步：拆成小任务
"帮我写个用户认证系统"——这是 vibe coding prompt。太大太模糊，agent 会替你做你不同意的架构决定。
"用我们现有的 Resend 集成实现密码重置邮件流程。Token 存 Redis，15分钟 TTL。这是规格说明书。"——这是 agentic engineering 任务。
小范围、可约束、可审查。
第三步：像审查人类 PR 一样审查代码
你得像对待人类同事的 PR 一样严格审查代码。如果说不清楚一个模块是干嘛的，就别让它合入。
这是最难保持的纪律。Agent 产码快，审查花时间。诱惑是快速扫一眼就批准——但这就是产生那些让人崩溃的不可维护代码的原因。
读懂每一个 diff，理解每一个函数。不清楚的地方，让 agent 解释清楚再合并。
第四步：疯狂测试
Vibe coding 在"看起来能跑"时就发货。Agentic engineering 在测试通过时才发货——而且是你写的或审查过的测试，不是 agent 生成的你扫一眼就过的测试。
评论区