Vibe Coding Shell、Build 与 Test 反馈环：用新证据驱动下一步

一种常见的“工具反馈”是假闭环：测试失败后改一段代码，换一条测试命令，再删掉一个断言，直到终端出现绿色。过程中每次都有输出，却没有稳定问题、单一假设和可比较观察。最后的绿可能来自测试范围缩小、错误被跳过，或命令根本没有发现目标用例。

Vibe Coding 的反馈环应保持四步不变：提出当前最小假设，选择能区分候选原因的工具动作，读取结构化观察，只根据新增证据决定下一步。它不同于编程 Agent 命令执行回执：回执保存命令事实，反馈环解释这些事实如何改变计划；也不同于编程 Agent 的改动验证门，后者判断最终补丁是否可接受。

先固定问题和基线

循环开始前写出当前失败，例如“修改后的解析器在空 header 用例返回 500，预期 400”，并绑定工作目录、代码 revision、依赖状态和精确入口。不要用“项目 build 不过”当问题，因为一次 build 可能混合配置、生成、类型、打包和静态渲染错误。

第一条命令应能复现问题且没有额外副作用。记录它是否真的执行到目标：测试发现数量、构建阶段名、失败文件、退出状态和首个可行动诊断。Node 进程用退出状态向调用环境表达成功或失败，但 0 只说明程序按自身规则成功结束，不自动证明用户行为正确；非零也要结合具体工具语义解释。

question: 空 header 是否走 INVALID_INPUT 分支
baseline: HEAD 31ac210 + dirty-set d4
probe: node --test test/parser.test.js --test-name-pattern empty-header
expectedSignal:
  beforeFix: one assertion fails with actual 500
  afterFix: same assertion passes; sibling invalid-input cases unchanged

先分类，再动代码

把失败至少分为五类。 INVOCATION 表示参数、目录或测试发现错误；ENVIRONMENT 表示依赖、权限、服务或运行时不满足；COMPILE 表示类型、语法、链接或生成阶段失败；BEHAVIOR 表示程序运行但可观察结果不符；STABILITY 表示超时、竞态或同一输入结果漂移。

分类错误会产生错误修复。模块找不到可能是 import 写错，也可能是命令在错误 workspace 执行；超时可能来自死锁，也可能是测试等待了未启动的服务。先用一个便宜探针区分，再编辑。TypeScript 的项目、构建与 compiler options 会改变实际检查的文件图和 emit 行为；因此同样写着 tsc 的命令若工作目录或配置不同，也不是同一份证据。

调试假设日志适合保存候选原因、预测与反证。反馈环每轮只提升或淘汰一个假设，不能在同一补丁里同时改实现、配置和测试，然后声称不知道哪项起效。

Shell、Build、Test 组成递进阶梯

Shell 探针适合确认文件、版本、进程和命令入口；Build 证明目标模块能经过真实编译与打包图；Test 用独立预言检查行为。三者不是固定先后，而是按当前问题选择最小判别器。改一个纯函数时先跑目标测试，再跑相关 build；诊断缺失生成产物时先检查脚本和生成阶段，不要直接改业务代码。

每轮保持同一核心 probe，新增检查只能解释失败，不能悄悄替换验收。修复后先复跑原失败用例，再跑邻近反例，最后扩到受影响构建或测试集合。Node test runner 会报告用例、suite 与进程级结果；仍需确认目标测试未被 skip、todo 或名称过滤排除。

绿色也要分类：probe-green 只关闭当前假设，local-regression-green 说明邻近行为未回退，acceptance-green 才对应任务验收。不要让一次局部命令成功提前终止所有验证。

从输出中提取信号而不是粘贴噪声

保留退出码、失败阶段、首个根因、相关堆栈、断言 expected/actual、测试计数和完整制品位置。重复堆栈、进度动画和无关 warning 降为附件。若工具支持机器可读报告，优先解析其结构；若只有文本，仍要区分工具诊断与 Agent 推断。

失败签名可以由工具、阶段、主错误码和顶层符号组成。连续两轮签名相同且没有新观测，说明动作没有信息增益，应停止随机改动。签名改变也不必然是进展：从一个类型错误变成十个类型错误，可能只是扩大破坏面。

测试预言审查提醒我们，断言通过的价值取决于 expected 的依据。Agent 不得为了让反馈变绿而放宽断言、增加无条件 catch、跳过测试或缩小发现范围；如果需求确实改变，先更新任务合同并重新接受。

用退出条件收口

一次循环完成时，要么原 probe 按预期从失败转绿且邻近检查未退化；要么某个假设被反证并产生下一条明确 probe；要么因权限、环境、需求或风险阻塞而升级。不能用“再试一个命令”掩盖没有下一条可证伪假设。

最终验证仍按既定门禁执行，并绑定最后一次编辑后的工作树。反馈环的价值不是多跑命令，而是每次工具调用都减少未知：知道失败在哪一层、哪项修复真正改变结果，以及何时继续已经不再合理。

延伸阅读

• 调试假设日志
• 测试预言审查
• 编程 Agent 命令执行回执
• 编程 Agent 的改动验证门