从Vibe Coding到Agentic Engineering：如何让AI真正按软件工程流程工作

1. Vibe Coding爽过之后，为什么大家都开始回头谈“流程”了？

1.1 Vibe Coding的甜与痛

过去这一年多，“Vibe Coding”几乎成了AI编程的代名词。它的核心体验其实很简单：你不需要先想清楚再动手，你把一个模糊的想法说给AI听，AI给你生成一版能跑的代码，你在旁边看着、改着、说“不是这个感觉”再让它继续改。整个过程中，人类更像是“甲方”而不是“工程师”，AI是那个被反复使唤的“全栈外包”。

这套模式爽是真的爽，尤其是做原型、做Demo、写一次性脚本的时候。我见过不少朋友用Vibe Coding的方式，一个周末搓出一个带前端、后端、数据库的完整产品雏形，放在Github上还能收到star。过去这种活儿至少得一周，现在一个晚上就能搞定。

但问题也出在这里：当项目规模超过某个临界点之后，Vibe Coding的体验会迅速恶化。最典型的几个信号：

• 代码库开始出现大量重复逻辑，一个功能在三个文件里有三种写法；
• AI生成的代码经常绕过已有的抽象层，自己另起炉灶；
• “改一处崩三处”的情况越来越频繁，因为AI根本不知道代码库其他地方是怎么依赖这块逻辑的；
• 最要命的是，你不敢让AI自己改大东西了——因为没有人能说清楚整个系统现在的真实状态。

为什么？因为Vibe Coding天然是一个“缺少工程约束”的对话过程。它不关心你的代码规范、不关心模块边界、不关心测试覆盖、不关心变更影响面。它只关心一件事：你的这条指令，它能不能尽量给出一个“看起来合理”的回答。这种模式在单文件、小范围、低压力的场景下是高效的，但一旦进入多模块协作、多人共建、长期维护的软件工程语境，它就开始失灵。

1.2 从“让AI写代码”到“让AI按流程干活”

于是行业里开始出现一个新词：Agentic Engineering。这个词直译过来是“智能体工程”，但我觉得更好理解的说法是——把AI Agent当作软件工程项目里的一名正式工程师来管理，而不是一个随时喊一嘴的外包帮手。

这两个定位的区别非常大。

你让AI“写一个登录接口”，这是Vibe Coding的用法。你让AI“阅读需求文档、拆解任务、设计接口方案、写测试、实现代码、跑完整回归、提交变更申请”，这是Agentic Engineering的用法。

前者是单点执行，后者是流程参与。前者你只要结果，后者你要求它对过程负责。

为什么这个转变很重要？因为软件工程这个行业花了几十年才沉淀下来的东西——需求管理、设计评审、代码规范、测试门禁、代码评审、灰度发布——它们不是官僚主义的摆设，而是在大规模协作中用来“降低信息熵”的手段。AI Agent如果只是替代“写代码”这个动作，那它本质上还是一个人的打字机，不可能从根本上改变软件生产的效率结构。只有当Agent真的进入流程、被流程约束、也对流程负责的时候，我们才谈得上把生产力放大一个量级。

1.3 这里说的“软件工程流程”具体是什么

说到“让Agent按照软件工程流程工作”，先得把“流程”这个词落到实处，否则容易变成空喊口号。我理解的、在Agentic Engineering语境下最有价值的流程至少包括这几个环节：

• 需求摄入与规格化：把一句模糊的“我要一个订单管理后台”变成一份可以执行的需求规格说明，包含功能点、边界条件、验收标准。
• 架构与技术选型约束：明确哪些模块可以动、哪些是核心领域不能碰、技术栈用什么、接口风格是什么。相当于给AI画了一个“可以自由发挥的边界”。
• 任务拆解与依赖排序：把一个中型需求拆成若干个可以独立验证、独立提交的工作单元，并确定先后关系。
• 测试先行与验收驱动：在写实现代码之前，先定义测试用例和验收条件，实现代码以“让测试通过”为目标。
• 变更集成与回归验证：代码只是中间产物，真正有价值的是它能安全并入主干、不破坏现有功能。
• 评审与度量：对Agent产出的变更做质量评审，并持续统计缺陷率、返工率、交付周期等指标。

这套流程对真人工程师来说，已经写过太多“流水线文档”了，不难理解。但难点在于：怎么让一个LLM驱动的Agent也老老实实走这套流程？这不是靠prompt里写一句“请遵循软件工程最佳实践”就能解决的。它需要我们在技术架构上设计一套约束和反馈机制，让Agent只能在流程的轨道里工作，而不是凭“感觉”自由发挥。

2. Agentic Engineering的本质：给Agent造一个“工程脚手架”

2.1 为什么直接丢一个大任务给Agent必然翻车

先做一个思想实验：你把一个完整的“重构用户认证模块，支持多因素认证”任务交给一个具备工具调用能力的Agent终端，它能完成吗？

大概率不能，至少不能可靠地完成。原因有三个：

第一，上下文窗口是有限的。一个真实项目的代码库动辄几十万行，Agent无法在一次对话里加载全部上下文。它看到的是它“认为”相关的代码片段，而它“认为”相关的粒度是token级别的相似度，不是工程语义上的依赖关系。结果就是它经常遗漏修改点。

第二，长流程中的状态一致性难以维持。一个复杂重构可能需要几十步操作。每一步操作都会产生新的文件内容、新的报错信息、新的测试结果。Agent如果要记住所有这些中间状态，并保证每一步的决策都基于最新状态，几乎是不可能的。它一旦忘记某个细节，就会基于过时信息做出错误决策。

第三，任务太大会让Agent失去判断优先级的能力。当所有事情都“很重要”的时候，它就开始平均发力。你说重构认证模块，它会先花大量时间优化目录结构、把import顺序理顺，而真正关键的多因素认证逻辑反而草草了事。这是Vibe Coding时代最常见的问题：AI会在不重要的地方表现得很认真，在关键的地方表现得很敷衍。

所以，让Agent按流程工作的第一步，不是让它更聪明，而是把一个巨大、模糊、无法验证的任务，拆成一组小、清晰、可验证的子任务。这就是工程脚手架的第一个作用。

2.2 核心思路：Spec-Driven + Harness

现在行业里比较有共识的做法，是Spec-Driven Development（规格驱动开发，简称SDD）配合一套称为Harness的“约束框架”。

Spec-Driven的含义是：AI的每一次编码行为，都必须从一份“规格说明”开始。这份规格说明不是让AI自己编的，而是由一个更上层的过程生成、并且由人或更“较真”的Agent审查过的。规格里写清楚：

• 这个任务的目标是什么；
• 涉及的模块和文件范围是什么；
• 哪些是必须遵守的约束（比如不得修改公共接口、不得引入新的依赖库）；
• 验收标准是什么（比如必须有测试覆盖、必须通过哪些静态检查）。

Harness则是一个更底层的概念。它定义的是Agent在一整个开发流程中的“活动区间”——它在哪台机器上运行、它能读写哪些目录、它能调用哪些工具、它被允许执行哪些命令、每一步完成之后需要产出什么中间物。Harness的作用很像游乐场的护栏：不是限制Agent发挥，而是确保它再怎么“自由发挥”，也出不了危险的边界。

我见过的一个比较典型的Harness设计，包含这样几层：

这套东西的价值在于：它把“软件工程流程”从一个抽象理念变成了Agent执行环境里的物理边界。AI不守流程的时候不是靠它自觉，而是它压根就越不过那个边界。

2.3 让Agent感知“当前阶段”与“全局目标”

多步骤流程中另一个容易忽略的问题是：Agent不知道自己“现在到哪一步了”。

真人工程师从需求评审会回来，会知道“当前处于设计阶段，接下来要出技术方案”；从设计文档的状态更新里，会知道“评审已通过，进入编码阶段”。这些元信息虽然细微，但对工作质量影响巨大。

Agent没有这种天然的时间感和阶段感。如果你没有显式告诉它“你现在处于第几个阶段”，它就会把所有任务都当成同一个类型来处理。你说“把这段逻辑用策略模式重构一下”，它不会意识到这是“编码阶段，测试要同步更新”，它可能改完实现逻辑就停在那里，完全不碰测试。

所以，在Agentic工程实践中，一个非常关键的设计是：把流程阶段编码进Agent的上下文。常见做法是在Agent每次启动时，注入一份“当前任务状态”：

{ "task_id": "AUTH-1142", "current_stage": "implementation", "global_goal": "支持MFA登录流程", "milestones": [ {"stage": "spec", "status": "done"}, {"stage": "design", "status": "done"}, {"stage": "tests", "status": "in_progress"}, {"stage": "implementation", "status": "pending"}, {"stage": "verification", "status": "pending"} ] }

这个状态文件让Agent在任何一个决策点上都能回答“我在哪里”“我要去哪里”“我已经完成了什么”。别小看这一步——很多Agent跑偏，不是因为能力不够，而是因为它真的“不知道自己在哪”。

2.4 多Agent协作是自然选择，不是炫技

聊到让Agent按流程工作，就很难不提多Agent架构。很多人以为“多Agent”就是一种潮流，仿佛Agent多就等于效率高。但在我理解里，多Agent协作之所以在Agentic Engineering里几乎不可避免，根本原因是不同的流程阶段对“Agent人格”的要求是完全对立的。

需求分析Agent需要发散——它要能从模糊的业务描述里想到各种边界情况、异常场景、未来扩展点。而编码Agent需要收敛——它要严格按照规格把代码写出来，不能天马行空。你要是让同一个Agent既负责发散又负责收敛，大概率两头都做不好。

再比如测试Agent是“防御型人格”，它的任务是找茬、挑错、验证假设；而实现Agent是“进攻型人格”，它的任务是快速产出可运行的代码。这两种人格放在同一个Agent身上，要么就会自己先打起来，要么就会用一个折中的、两头都不靠的状态工作。

所以我把多Agent的理解是：它是流程分权的自然延伸。既然流程分阶段，而不同阶段的能力要求不同，那就让不同的Agent各自负责自己最擅长的阶段，用一个编排层把它们的产出串起来，前后传递规格、代码、测试结果、评审意见。人负责的是流程设计者和最终审批者的角色，而不是替Agent“代笔”。

3. 真正让Agent“按流程工作”的落地做法：一条完整链路

3.1 第一步：需求摄入与任务拆解，先写Spec再动手

任何Agentic Engineering的落地，都要从“需求怎么进入系统”这一步开始。

我见过很多团队上来就跳进“怎么调Agent写代码”的坑，结果发现Agent在代码层面确实写得不错，但做出来的东西根本不是需求方想要的。原因就是：需求进入的方式不对——要么是一句话直接扔给编码Agent，要么是给了一段含糊的聊天记录让它自己领会。

正确做法是：设置一个独立的需求分析/产品Agent（或者人工流程），输入是一段口语化的业务诉求，输出是一份结构化Spec。我建议Spec至少包含几个部分：

• 目标描述：一句话说清楚为什么要做这个功能，解决什么业务问题；
• 用户故事/用例场景：以“作为XX，我希望XX，以便XX”的格式列出核心场景；
• 功能清单：小粒度地列出要支持的能力点，每一条都必须可以独立验证；
• 业务规则与边界条件：比如金额不能为负、状态流转必须经过中间态、并发下如何加锁；
• 非功能需求：性能要求、兼容性要求、安全与合规要求；
• 验收标准：每种场景下，什么算“做对了”。

Spec写完之后，还有一个关键动作：拆解任务。这一步可以由人来做，也可以由一个专门的规划Agent基于Spec自动拆，但我建议拆完之后由人再过一遍。

拆解的逻辑是：每一个任务单元，必须满足“可独立提交、可独立验证、变更范围可控”三个条件。一个500行的重构不应该是一个任务，而应该被拆成“模块A的接口签名更新”“模块A的实现替换”“调用方适配”“测试用例更新”“文档更新”五个任务。

这里有一个非常实用的经验：每个任务单元的实现量控制在200-400行代码量级（或者等价的重构工作量）是比较合适的。太大，Agent容易失控；太小，流程开销占比过高，反而不划算。

3.2 第二步：设计评审与架构约束，代码不是第一产出物

Spec敲定、任务拆完之后，很多团队就会让编码Agent直接开工。这个跳跃是有问题的。

编码Agent开工之前，还需要一个“设计”的环节。这个环节的产出物不是代码，而是一份足够细的技术设计方案，至少要包括：

• 涉及的模块与文件清单；
• 新增/修改的接口定义（方法签名、数据结构、错误码）；
• 数据存储变更方案（如果有的话）；
• 依赖引入说明（尽量不引新依赖）；
• 兼容性与回滚方案。

设计环节为什么不能省？因为真实项目的架构约束往往是隐性的——某个模块不能引入数据库依赖、某个接口必须保持向后兼容、某个数据表变更需要迁移脚本。这些约束如果不在设计阶段显式写明，编码Agent根本无从知晓。它很有可能会在一堆历史代码中“按自己的审美”做设计，结果产出的代码跟整个项目的架构风格完全脱节。

更现实的问题是：设计阶段是人工介入成本最低的阶段。看一份设计方案可能只要10分钟，而看Agent提交的2000行代码、然后要求返工，可能要花2小时甚至更久。所以但凡复杂度超过“给单个函数加一个参数”级别的任务，都应该让Agent先出设计再动手，宁可设计阶段慢一点，也不要等到代码阶段再来纠正。

3.3 第三步：测试先行，编码Agent的“产出边界”

设计评审通过后，进入真正的编码阶段。但这里有一个顺序问题：先写测试，还是先写实现？

在传统的TDD流程里，是先写测试再写实现，让实现代码以“通过测试”为目标。在Agentic Engineering里，这个顺序被赋予了更重要的意义：测试是约束编码Agent行为的锚点。

为什么不先写实现再补测试？因为如果让Agent先写实现，它对测试的态度通常就是“凑覆盖率”——它会写出大量断言非常脆弱、没有实际校验逻辑的“假测试”。反过来，如果让Agent先基于Spec写测试，那么测试本身就变成了一份“可执行的规格说明”：实现代码必须解释清楚“为什么这组测试定义了正确的行为”。这个锚点会让Agent的编码过程收敛得多。

具体操作上，我会为每个任务单元设置两条Agent执行路径，并确保它们跑在独立沙箱中：

# 测试Agent：先产出测试用例 agent run test-writer \ --spec docs/specs/AUTH-1142.md \ --output tests/unit/auth_mfa_test.py \ --base-branch main # 实现Agent：在测试就位后实现代码 agent run implementer \ --test-file tests/unit/auth_mfa_test.py \ --source-dir app/services/auth/ \ --output app/services/auth/mfa.py

编码Agent的产出边界必须非常明确：它写的是“让测试通过的实现代码”，不是“它认为有价值的代码”。任何实现范围之外的改动（比如顺手重构一个相邻函数、把README措辞改了），都应该被视为违规，并在评审阶段被拦截。

3.4 第四步：自动验证门禁，防止“假成功”

编码Agent提交实现之后，流程并没有结束，恰恰是后半程的开始。我们进入自动验证阶段。

“假成功”是Agentic Engineering里最值得警惕的现象。什么叫假成功？就是Agent告诉你“已经改好了，测试都过了”，但事实上它：

• 只跑了它自己写的那个测试文件，没跑全量回归；
• 测试里用的是mock数据，而且mock得过于理想，根本没有覆盖真实环境下的数据形态；
• 代码能编译通过，但类型检查器在严格模式下报了一堆错；
• 静态检查工具被它跳过了，因为CI里没配；
• 它对接口的改动破坏了下游调用方的契约，但下游的编译错误在另一个模块里，它没检查到。

针对这些情况，必须在流程里设置多层验证门禁，并且这些门禁不能由实现Agent自己执行和自述结果，而要由独立的验证Agent运行并出具报告。

我常用的一套门禁清单是这样的：

注意最后一条：变更范围检查。这是很多人会漏掉但极其重要的一条。因为Agent经常会在“顺手”中改坏东西，而变更范围检查是成本最低、最客观的防线——它就是一条简单的git diff命令，看看到底改了哪些文件。

3.5 第五步：合并前评审与回归验证，人工关口怎么留

所有自动门禁通过之后，还需要一步：评审与合并。这一步我认为目前还不能完全去掉人工。

原因不是AI评审不够好——事实上AI评审在挑代码风格、找重复逻辑、发现遗漏的测试用例方面，已经比很多真人reviewer更细致了。但AI评审有一个天然的盲区：它不知道业务方的真实意图。一份Spec写得再详细，也无法把客户开会时的语气、PPT里的一张架构图、运营负责人强调的那个数字背后的焦虑都表达出来。

所以我的建议是：自动评审全量跑，AI评审逐个过，最终的人工评审只看关键差异。具体做法是：

1. Agent提交的变更首先经过自动门禁和AI评审Agent，产出一份“问题清单”；
2. 所有阻塞性问题（blocker）必须被解决后，变更才进入人工评审队列；
3. 人工评审者不需要逐行看代码，而是重点看：Spec是否被正确理解、设计方案是否被完整执行、AI评审清单中非阻塞项是否有合理解释、以及变更带来的风险是否可控。

这一步还有一个实践细节：人工评审者的工作流也要被“工程化”，不能让人靠感觉点按钮。我建议把合并门槛定义成一条严格的规则：只有全部自动门禁通过、且至少一个真人评审者明确点了approve，变更才能被合并。这条规则在Git分支保护里直接配置死，不能因为时间紧就临时绕过。

4. 过程中踩过的坑与解决办法

4.1 Agent的“假成功”：怎么识别和拦截

前面提到了“假成功”这个概念，这是我在实际改造中最先撞上的一堵墙。

当时我让一个实现Agent去改一个支付模块的状态机逻辑。半小时后它回复“已完成，测试全部通过”。我让验证Agent跑了一遍全量回归，结果挂了13个用例。原因很典型：实现Agent在自己的工作目录里运行了单测，但它只跑了它修改过的那个测试文件，而且那个文件的测试函数因为import路径错误，实际上是静默跳过了——pytest把它当成“collection error”，Agent没看输出细节，只看到“0 failed”就以为通过了。

这个坑给我的教训非常深刻：绝对不能把“Agent自述的验证结果”当作有效结果。从那以后，我把验证环节从实现Agent的执行环境中剥离出来，用独立进程、独立沙箱执行，并且要求输出中必须包含“实际运行的测试用例总数”“失败数量”“跳过数量”这些原始指标，不允许只报一句“Test passed”。

另一个有效手段是在Harness里配置“输出接管”：实现Agent的终端输出不再直接返回给Agent自己判断，而是先经过一个解析器，提取出关键指标，再决定是否继续下一步。如果解析器发现“测试报告里没有统计项”，直接判定验证无效，让Agent重新提交。这等于在流程里加了一个“质检员”，而不是让写代码的人自己汇报质量。

4.2 上下文漂移：长任务中怎么保持一致性

第二个大坑是上下文漂移。

场景是这样的：一个任务设计阶段挺好，Agent也完整理解了Spec的全部内容。但执行到第40分钟、已经做了十几轮工具调用之后，它“忘了”最开始的设计约束，开始按自己当前的局部理解做决定。

最典型的表现是：Spec里明确写了“不得引入新的第三方依赖”，Agent在实现第7个文件时觉得“其实用一下lru_cache更优雅”，就顺手加了一个。不是它故意违反规则，而是它的上下文窗口中，那条约束已经因为早期太多工具输出被冲掉了。

这个问题有治标和治本两层解法。

治标：在Agent的上下文中周期性地“重新注入”核心约束。我见过的最简单有效的做法是——在每次工具调用之后，把那条最高优先级的约束重新写回系统提示词的最前面。成本不高，但效果立竿见影。

治本：改进任务拆解。如果一个任务长到会出现明显的上下文漂移，说明这个任务拆得还不够细。一个执行单元应该控制在Agent能“一口气完成”的范围内——通常来说，10到20次工具调用以内是一个合理区间。超过这个区间，就应该从流程层面把它拆开，而不是指望Agent用更长远的“毅力”硬扛。

4.3 工具调用失控：给Agent配置最小权限

第三个坑是关于工具权限的。

Agent在编码过程中需要调用很多工具：执行命令、读写文件、跑测试、查文档、调API。如果你给它的权限过于宽泛，很容易出事。

我曾经的配置失误是让编码Agent的沙箱直接挂载了整个项目仓库的写权限，结果Agent在一次“顺手修复”中，把另一个模块下的依赖文件也给改了。它可能觉得那个改动是合理的，但它完全不知道那个文件是由另一个团队维护的、改动不能随意提交。

从那之后，我把权限控制的原则改成了“最小够用”：

• 每个任务单元只能读写自己的白名单目录；
• 能限制执行的命令范围就限制，比如只允许跑测试和静态检查，不允许执行任意shell命令；
• Git提交权限由编排层统一控制，Agent自身不接触git push。

这些限制在Harness层用容器或权限系统固化下来。刚开始会觉得麻烦，但出了一两次事故之后，就会理解为什么“让Agent不能犯错”比“让Agent不犯错”重要得多。

4.4 流程回环与死循环：超时和重试策略

第四个坑是流程层面的：Agent在某个环节卡住，或者反复重试但一直不成功，整个流水线就堵死了。

死者循环的常见形态有两种：一是验证门禁持续失败，Agent反复“修复再提交”，但每次修的都是同一个问题的表象，根因一直没变；二是设计评审通过不了，Agent反复改设计方案，但改来改去都在一个思路上打转。

针对第一种，我设置了“失败重试上限”：同一个任务单元最多重试3次，3次全失败就把任务升级给人处理。升级的同时，之前所有的失败日志、验证报告、Agent的每一次修复尝试都要打包提交给人。这样人不需要重新让Agent跑一遍就能看到“它为什么一直修不好”。

针对第二种，问题通常在于设计评审Agent和人之间缺乏有效的“否定原因”传递。后来我要求评审Agent的否定意见必须结构化输出——具体到违反哪一条约束、缺了哪个模块的设计、哪个风险没有应对方案。这样设计Agent才能基于具体原因去修改，而不是拿一句“请重新设计”去猜。

我也特别提一下：不要让Agent长时间无人值守地运行。任何一个步骤的自主运行时间超过30分钟，就应该触发一个检查点，把中间产物固化下来、汇报当前状态。这既是审计需要，也能避免Agent在一个错误方向上越走越远。

5. 哪些工具能支撑这套流程落地

5.1 先别急着选框架，把流程定义想清楚

聊完踩坑，说说工具选型。现在市面上支持AI Agent开发的框架和工具越来越多，但我不建议一上来就盲目选一个“看起来很强大”的框架。

我的建议是：先花时间把你想要的“流程”本身定义清楚。你可以先回答这几个问题：

• 你的流程里有哪几个明确的阶段？每阶段的输入输出各是什么？
• 哪些环节需要人参与？人的参与是审批型还是协创型？
• 哪些验证是自动跑、哪些需要人看？各自的门槛是什么？
• 一个任务的失败重试策略是什么？失败之后谁负责兜底？

这些定义清楚之后，再去看工具，你会发现很多工具的设计理念会帮你自动解决这些问题，而另一些工具则可能跟你想要的流程冲突——直接把Agent暴露给一个无约束的对话式环境，那种工具就不适合做Agentic Engineering。

5.2 从“能跑”到“工程化”：给团队的分步改造建议

最后，很多团队问我：改造应该是怎么一个节奏？大爆炸式还是渐进式？

我的建议是渐进式，并且严格遵循“先外后内、先软后硬”的原则：

第一周只做一件事：把需求摄入和Spec生成的环节流程化。让AI先产出结构化需求规格，人评审，然后作为后续所有环节的基础。这一步不改动代码生成方式，但为后续所有改造打地基。

第二周到第三周：挑一个低风险模块做试点。选一个团队熟悉、改动量小、有充分测试覆盖的模块，在上面试跑“Spec → 设计 → 测试 → 实现 → 验证”的完整链路，人全程在场观察。

一个月后：跑通一条稳定的流水线，再逐步扩大任务类型和模块范围。任何新模块要接入，都要先满足前几个模块相同的测试覆盖率基线。

不要一上来就追求“全程无人值守”。在Agentic Engineering成熟之前，最高效的工作模式其实是一个高效的人管理一支AI“小团队”，而不是把人完全撤走。每个阶段你是否保留人工关口、保留多少，应该基于实际质量数据来调整，而不是为了“All in AI”而强行自动化。

5.3 有一条经验想特别分享

在实践Agentic Engineering的过程中，我最深的体会是：最重要的不是Agent多聪明，而是流程多坚韧。

一个不那么聪明的Agent，在一个约束良好的流程里，也能稳定输出及格线以上的结果。反过来，一个非常聪明的Agent，在没有流程约束的环境里，会以极高的效率犯下极其离谱的错误。

这就像让一个资深工程师在完全没有测试、没有设计、没有代码评审的环境里工作——他也不是不能写，但他写出来的东西大概率是失控的。Agent也是一样。Agentic Engineering的本质，是把过去靠“人自觉”才能维持的工程纪律，变成环境自动维护的强约束。

所以如果你问我“如何让AI Agent真正按照软件工程流程工作”，我的回答从来不是“提示词教得好”，而是：别把流程寄托在Agent的自觉上，把流程做成Agent逃不出去的环境。Spec是它的宪法，Harness是它的边界，验证门禁是它的质检员，人工评审是它的最终保险。把这套脚手架搭好，你会发现AI Agent不是一个偶尔灵光一现的天才，而是一个稳定可靠的执行者。

这正是我从Vibe Coding走到Agentic Engineering之后，最大的感受转变。前者让我相信AI什么都能干，后者让我知道AI怎么干才靠谱。如果说Vibe Coding是给AI松绑，那Agentic Engineering就是给AI画跑道——松绑让我们看到了它的上限，画跑道才让它真正跑出成绩。