拓冰网站定制 
一、现在的 vibe coding 似乎有些问题为什么Vibe Coding需要可靠性而不仅仅是能跑。本文主要讨论非专业开发者在使用Vibe Coding进行软件开发时如何提升应用的可靠性。随着AI Coding的普及越来越多没有专业开发背景的人开始能够借助 AI 开发自己的应用。这无疑极大降低了软件开发的门槛。然而大多数非专业开发者在使用Vibe Coding时往往采用的是一种硬蹬的方式不断让AI修改代码直到系统看起来实现了自己设定的目标。但问题是一个看起来完成了需求的软件真的完成了需求吗真正值得思考的并不是程序能不能运行而是程序执行过程是否正确数据是否被正确处理是否影响了其他业务逻辑系统内部是否存在被隐藏的问题在这之后还有如何更强的让AI定位错误及简化整个思考和操作步骤。在进行vibe coding时很多Bug恰恰不是程序崩溃而是在表面一切正常的情况下悄悄产生。1.1 一个非常典型的例子文件覆盖假设系统有一个需求根据不同的数据生成两个文件AI最终生成了下面这样的逻辑生成内容A保存为 文件A生成内容B但由于命名错误也**“保存”**为 文件A整个程序运行过程中不会报任何错误。甚至日志全部正常。但是最后目录里只剩下一个 文件A。那么问题来了这个文件到底是第一次生成的 A还是第二次生成的 B如果开发者没有主动打开文件检查很可能永远不会发现这个问题这种Bug在AI Coding中其实并不少见。尤其是在给AI一个较长的Spec时由于某些细节描述不够明确AI很可能会重复使用变量名重复使用文件名覆盖之前生成的数据忽略本应替换的内容这些问题往往不会导致程序报错因此AI自己也可能认为任务已经完成。真正发现问题的时候往往已经是在最终检查产物甚至是在项目上线之后。1.2 还有一个更隐蔽的例子优惠券再来看一个电商系统系统中存在两张优惠券优惠券A8折过期日期不同优惠券B8折过期日期不同测试阶段如果开发者只验证优惠券能够正常使用系统成功完成打折那么很容易认为功能已经开发完成但实际情况可能是无论输入优惠券A还是优惠券B系统内部始终读取的是优惠券A。如果测试时两张优惠券恰好都是8折那么整个测试过程完全不会暴露问题。直到后来运营将优惠券B修改为9折线上才发现为什么输入B却一直按A的折扣计算这类问题属于业务逻辑错误程序没有崩溃功能看起来也正常但是系统内部真正执行的逻辑已经发生了偏差。对于非专业开发者来说这种问题几乎无法通过看代码发现。1.3Vibe Coding最大的问题不是Bug而是假正确AI非常擅长让程序 “跑起来” 。但真正的软件开发需要保证的是系统内部的状态与开发者真正想表达的业务一致。很多时候页面显示正常API 返回正常自动化测试通过程序没有任何报错。但是系统内部的数据已经出现偏差这种问题我们可以称之为假正确也就是说软件表现出了 “正确” 的外观却没有真正实现正确的业务逻辑。1.4 当 AI 陷入循环修改时怎么办并且还有一个常出现的问题同一个问题重复对话但没有解决AI一直改不好同一个Bug开发者不断发送“还是有问题。”AI不断回复“我已经修复。”于是进入几十轮循环对于专业开发者来说他们可以阅读代码、定位调用链、分析变量流向但对于非专业开发者而言他们甚至不知道Bug出现在哪一个文件哪一个函数哪一次调用哪一个变量。因此他们无法准确告诉AI真正应该修改的是哪里。AI也只能不断代码、不断尝试修改消耗大量Token却仍然无法精准定位问题。1.5 第一次开发没问题不代表后续迭代没问题还有一个经常被忽略的现象第一次开发完成后整个系统似乎运行良好但随着功能不断增加新的修改开始影响旧的逻辑。于是原本正常的功能开始失效新需求修复了一个Bug却引入两个新的BugAI修改A时不小心破坏了B。这其实就是软件开发中经典的回归问题。对于专业团队来说会通过测试、代码审查和持续集成来降低这种风险而对于依赖AI开发的非专业开发者来说这种风险会被进一步放大。1.6 为什么需要一种新的 Vibe Coding 方法因此我们真正需要的并不是一个更会写代码的AI。而是一套能够帮助非专业开发者验证系统是否真正正确的方法。它应该能够帮助发现隐藏的逻辑错误而不仅仅是运行错误帮助定位问题发生的位置而不是让AI无限循环修改帮助验证业务是否真正符合预期而不是只验证结果是否看起来正确在后续迭代过程中持续发现回归问题避免越改越乱。未来随着模型能力不断增强再结合Loop EngineeringAI或许能够自动进入沙箱执行代码、分析报错、自动修复问题但即便如此如果能够提供一种低成本、高精度的辅助方式让AI更快定位问题、减少无效循环、降低Token消耗那么它与更强大的模型并不是替代关系而是互补关系。真正优秀的AI Coding不应该只是让程序能跑而应该让开发者能够相信程序跑得正确。二、为什么日志是 Vibe Coding 的基础设施随着AI Coding的快速发展普通用户使用AI进行Vibe Coding已逐渐成为一种常态。然而Vibe Coding并不意味着可以完全忽略软件工程实践。AI能够帮助开发代码但真正执行需求的是AI而不是开发者本人。对于非专业开发者来说AI生成的代码本质上就是一个黑盒。开发者知道自己提出了什么需求却不知道AI在内部调用了哪些模块修改了哪些文件数据经过了哪些处理最终为什么得到当前结果。即使对于专业开发者而言逐行审查AI生成的代码也是一件成本极高的事情。AI生成代码的速度已经远远超过了人类能够全面Review的速度因此人们开始越来越依赖AI的输出而忽略了传统的软件工程实践。然而这种信任并不意味着AI是绝对可靠的。《Preventing Failures in AI-Driven Software Engineering》 中指出当前AI Coding的一个重要风险就是开发者过度信任AI的输出而缺乏有效的验证机制。那么有没有一种低成本的方法可以帮助非专业开发者了解AI究竟做了什么我认为答案就是日志。日志本身一直存在于软件开发之中但传统日志主要服务于程序员。而对于Vibe Coding来说我们需要的不仅仅是程序日志更需要一种能够解释业务过程的日志。《Preventing Failures in AI-Driven Software Engineering》 同样指出运行时验证日志是确保代码安全以及事后调查AI行为的重要依据日志还必须能够保证真实性、完整性以及可审计性。这恰恰也是当前大多数非专业开发者在Vibe Coding中最容易忽略的一环。三、传统日志并不适合 Vibe Coding专业的日志对于非专业的vibe coding使用者来说并不友好他们真正关心的是刚才我点了按钮系统到底发生了什么因此Vibe Coding所需要的日志并不是增加更多日志而是增加更容易理解的日志。例如用户点击了创建订单 这个操作随后日志能够直接告诉用户收到创建订单请求-验证登录状态成功-验证库存库存充足-计算优惠券使用了优惠券B-计算最终金额原价999 → 折扣899-写入数据库-返回创建成功即使完全不会写代码也能够知道整个业务流程发生了什么这种日志本质上就是把原本隐藏在代码中的业务逻辑翻译成普通人能够理解的语言。当然日志并不是越多越好《Do AI Coding Agents Log Like Humans? An Empirical Study》同样指出日志过少会导致无法定位问题日志过多则会增加系统开销使真正有价值的信息被淹没。因此日志应该按照场景划分为两类开发日志、生产日志开发日志主要用于AI Coding阶段特点信息尽可能详细完整记录业务调用链包含关键变量变化能够帮助AI快速定位问题。而到了生产环境则应切换为生产日志主要记录错误告警性能指标Trace避免大量业务日志影响系统性能。四、实验验证这一节实验随便测试的不想看的可以跳过。4.1 BBS 测试为了验证日志方案的实际效果我首先编写了对应的日志Skill并准备进行第一次测试。为了尽可能模拟非专业开发者进行 Vibe Coding 时的真实场景我没有选择能力最强的大模型而是选用了能力适中的MiniMax-M3希望模型能够暴露出更多问题从而验证日志是否能够帮助定位和修复Bug。整个开发过程完全按照普通Vibe Coding的方式进行没有编写SDD、设计文档等详细说明仅通过自然语言描述需求让AI完成整个系统开发。我向AI提出了如下需求结果有些出乎意料MiniMax-M3一次就完成了整个项目看起来选择的模型还是有些强了不过真正开始使用系统后还是发现了一些接口存在异常。与此同时我编写的日志Skill也已经开始正常工作并成功输出了运行日志不过此时的日志仍然偏向开发者视角可读性并不高后续还需要不断优化让非专业开发者也能够快速理解系统到底发生了什么随后我查看了后端日志确认日志已经完整输出既然日志已经能够完整记录系统运行过程那么接下来便完全按照非专业开发者的思路进行操作不阅读代码而是直接将日志交给AI分析问题。AI很快给出了分析结果并表示已经找到了问题原因。不过对于AI的回答始终需要保持一定的怀疑态度因此我没有直接相信而是继续进行实际测试验证果然问题依然存在于是我没有重新描述整个问题而是提交更详细的整个日志让AI获取更多上下文信息这一次问题顺利得到解决随后我开始测试完整业务流程注册账号-登录后-修改头像在修改头像后又出现了新的问题刷新页面后头像无法正常显示查看前端日志后可以看到如下信息虽然日志内容对于非专业开发者来说依旧不容易理解但这已经不是重点。按照Vibe Coding的思路只需要将控制台日志完整复制给AI让 AI 帮助分析即可AI修改后页面刷新时又输出了新的日志。AI根据日志分析认为当前系统正在通过8080端口访问BBS服务但又提示应该访问8000端口这里其实暴露出了真正的问题由于前端本身就是运行在8080端口因此AI已经意识到请求配置存在异常只是缺少最后一步确认。将这一信息反馈给AI后它很快定位到了错误的请求地址并完成修复问题成功解决通过这次测试我也得到了一点新的体会。对于非专业开发者来说虽然不需要阅读代码但如果能够掌握一些最基础的软件开发概念例如什么是端口、什么是请求、接口等知识在与AI协作解决问题时效率会明显提高。因此我也在考虑是否可以专门编写一套面向非专业开发者的基础教程只介绍Vibe Coding过程中必须理解的一些概念而不涉及具体代码以进一步降低使用门槛。完成以上问题修复后我重新测试了整个业务流程没有再发现新的异常整个BBS系统能够正常运行4.2 电商测试为了进一步验证日志方案的通用性我更换了模型并重新进行了另一组实验。这次依旧采用相同的Vibe Coding流程因此前面的创建项目、生成代码等重复过程就不再赘述直接进入关键测试环节。经过对话后AI成功生成了一个电商系统但hy3太笨了该模型对于部分指令的遵循程度并不理想。例如我要求其为整个项目增加日志但模型并没有一次性完成因此需要继续引导AI为全局代码补充日志完成日志补充后我开始对整个购物流程进行测试很快便发现了一个明显的业务逻辑错误订单结算页面中应付金额竟然变成了负数显然正常情况下应付金额不可能为-841元遇到这种问题时最直接的方法当然是告诉AI应付金额计算错误请修复。但这种描述过于笼统AI 很可能无法准确判断问题究竟出现在优惠券计算、商品金额统计、折扣计算还是最终金额汇总阶段因此往往需要经过多轮修改才能真正定位问题。而这正是日志发挥作用的地方我没有重新描述整个业务流程而是直接将运行日志发送给AI并明确指出应付金额计算结果异常让AI根据完整的调用链分析数据究竟是在什么环节开始出现错误AI很快返回了分析结果并表示已经找到了问题原因不过根据前面的实验经验对于AI的结论仍然需要保持验证的态度因此我并没有直接认为问题已经解决而是继续进行实际测试令人意外的是这一次AI的分析是正确的按照日志定位到的问题进行修改后应付金额恢复正常整个结算流程也能够正确完成相比直接告诉AI金额计算有问题日志不仅提供了完整的数据流转过程还帮助AI快速定位到了异常发生的位置避免了大量无意义的猜测和循环修改。这次实验也进一步验证了前面的观点对于业务逻辑类问题完整的调用链日志能够显著提升AI的定位效率。 非专业开发者无需阅读代码只需要提供包含关键数据变化的日志AI就能够更准确地分析问题所在从而减少反复试错的成本。4.3 换一个没听过的模型继续测试资产管理系统为了避免实验结果受单一模型能力影响我决定继续更换模型测试日志方案在不同模型上的表现。这一次我选择开发一个资产管理系统继续按照Vibe Coding的方式仅通过自然语言描述需求让AI完成整个项目在最开始的开发过程中模型很快便出现了报错虽然终于出现了可以验证日志效果的问题但遗憾的是这个模型在复杂任务上的表现较弱甚至没有完成整个系统的开发导致后续测试无法继续因此只能更换另一款模型。随后我换用了Step-3.7-Flash模型。此前也听不少人提到这个模型虽然能力相对一般但响应速度较快因此正好可以验证日志是否能够弥补模型在问题定位上的不足果然在继续开发过程中很快再次出现了运行错误这一次没有重新描述问题而是直接将运行日志复制给AI。AI根据日志分析调用链很快便定位到了异常原因并完成了修复。完成修复后我继续测试业务流程又发现了新的Bug依旧采用相同的方法将对应日志发送给AIAI 很快定位到了问题所在并顺利完成修复随后继续测试时又发现了文件下载功能存在异常于是再次将对应日志发送给AI让其分析问题最终这个问题同样顺利得到解决连续几次实验下来我开始有一个比较明显的感受当日志能够完整记录业务调用链和关键数据变化时AI的问题定位效率会明显提升。相比于不断向 AI 重复描述这里有问题“这里还是不对”直接提供包含上下文信息的日志能够帮助AI更快理解当前系统状态也减少了多轮来回沟通和无效修改。当然这并不意味着日志能够解决所有问题也不能保证AI每一次都能一次修复成功。但至少在这几次实验中无论是运行异常、业务逻辑错误还是功能缺失只要日志能够完整记录关键过程AI都能够更高效地完成问题定位和修复。这也进一步印证了前面的观点日志不仅是给开发者看的同样也是AI理解系统运行状态的重要上下文。4.4 完整项目验证企业内部资产管理系统前面的几组实验主要验证了日志在局部功能开发和问题定位中的作用。为了进一步验证其在真实开发场景中的效果这一次我不再采用简单 Demo而是按照自己平时的开发流程完整实现一个企业内部资产管理系统。与前几次实验不同这次开发采用了更加完整的工作流首先我编写了项目的Spec并结合前面几轮实验的反馈对日志Skill进行了进一步优化。随后使用Qoder按照Spec一键生成整个项目观察日志方案在完整项目中的实际表现项目生成过程前日志Skill已经自动集成到整个工程中项目首次运行后整体效果比预期更好大部分功能一次性即可正常运行不过这并不意味着整个系统完全没有问题继续深入测试业务流程后很快还是发现了新的Bug按照前面实验形成的习惯我没有继续向AI描述整个业务流程而是直接将对应的运行日志发送给 AI让其根据日志分析问题原因AI很快返回了分析结果并指出了可能存在的问题AI自动修改完后问题顺利解决随后继续测试完整业务流程创建账号后在同一个部门上传了一份文件。按照业务设计管理员应该能够查看该文件但实际测试中却发现管理员列表为空文件并没有正常显示。于是再次查看日志并将日志发送给 AI 分析这一次的问题相比之前更加复杂AI连续进行了三轮修改但始终没有彻底解决问题。直到补充了更加完整的运行日志后AI才真正理解了整个业务调用链以下是给与AI的对话信息在获得完整日志之后AI很快定位到了真正的问题并完成了最终修复整个实验完成后我不敢说AI修复Bug的能力提升了没做大量实验但沟通成本明显降低了。以前遇到问题时我需要不断向 AI 描述我做了什么哪一步出了问题我希望它修改哪里修改之后还有什么现象。整个过程往往需要反复手动敲补充大量上下文信息而加入日志之后这些描述大部分都可以由日志本身完成。AI能够直接从日志中获取完整的业务流程、数据变化以及调用链信息我只需要告诉它**“这里有问题请结合日志分析”** 又或者进一步说哪一个数据有问题 即可。对于不会阅读代码的非专业开发者来说这一点尤为重要日志不仅帮助 AI 更快理解问题也帮助开发者准确表达问题。双方围绕同一份运行信息进行交流大大减少了由于信息缺失而导致的无效修改和反复沟通。经过这一轮完整项目的验证我更加确信前面的观点对于Vibe Coding而言高质量的日志不仅是一种调试工具更是一种连接开发者与AI的沟通媒介。 当日志能够完整、准确地描述系统的运行状态时无论项目规模大小都能够辅助AI定位问题和修复问题的效率。五、面向 Vibe Coding 的日志规范经过前面的多组实验我越来越确信一点对于Vibe Coding而言日志不仅是调试工具更应该成为AI与非专业开发者或专业开发者共同理解系统行为的媒介。经过前面的分析与实验我发现这已经不仅仅是一套日志规范而更像是一种新的Vibe Coding开发方式。本文将这种以可审计日志Auditable Logging为核心通过完整记录业务生命周期、帮助AI与开发者共同理解系统行为的开发方式称为Audit-Driven Vibe CodingADVC。Audit-Driven Vibe Coding并不是一种新的开发框架也不是一种新的AI Agent而是一种开发实践。它强调通过高质量、可审计、面向业务的日志将AI生成的黑盒代码转化为开发者和AI都能够理解的白盒业务流程从而提升Vibe Coding的可靠性、可维护性以及问题定位效率。《Preventing Failures in AI-Driven Software Engineering》中提出了Auditable Logging可审计日志 的概念。论文认为AI软件工程需要能够全面、真实且可验证地记录AI的行为以支持后续的问题调查、责任追溯以及合规审查。日志不仅需要记录系统发生了什么更需要能够反映系统行为与预期之间的偏差从而帮助开发者理解问题产生的原因而不仅仅是知道问题已经发生。这一观点与本文的实验结果高度一致因此在我编写的日志Skill中并没有仅仅增加几条调试信息而是尝试围绕完整的请求生命周期建立一套更加适合Vibe Coding的日志规范。5.1 请求链路日志覆盖规范对于每一个完整业务请求都应确保其整个生命周期能够被完整记录。并非所有请求都会经过所有处理阶段但对于未执行的阶段也应明确记录未执行的原因而不是直接省略日志从而避免请求链路出现信息断层。整个请求链路至少应覆盖以下几个阶段请求到达入口已记录TraceID、路径、方法、来源、关键参数摘要。中间件/过滤器/拦截器每一层鉴权、限流、CORS、签名、租户、幂等等都记录了通过或拦截结果与原因。被拦截/被拒绝未进业务方法明确记录“请求未进入业务逻辑”含拦截层、拒绝原因、返回状态码、业务影响。业务方法执行入口、关键分支、计算过程、数据流转、数据库操作都有日志。响应返回记录了状态码、响应数据摘要、耗时、最终业务结果。异常/错误记录了异常类型、发生阶段、TraceID、对用户或业务的影响、是否已处理。TraceID以上所有阶段包括被拦截、被拒绝、抛异常的分支使用同一个TraceID。分层覆盖涉及到的前端、中间件、接口层、服务层、数据库层、外部调用层都有对应日志。对于AI Coding来说日志覆盖率本身也应该成为交付标准。只要存在任何一个适用阶段没有日志就应当视为本次开发任务尚未完成而不能仅仅因为程序能够正常运行便认为项目已经交付。5.2 日志的真正目标很多人认为日志只是为了方便排查Bug但对于Vibe Coding来说我认为日志承担着另外一个更加重要的职责——把AI生成的黑盒代码转换成普通人也能够理解的白盒业务流程。完整记录一次请求的生命周期并不是为了生成更多日志而是为了完整保留系统运行过程中所有重要的信息这样做至少能够带来几个好处非专业开发者无需阅读代码就能够理解系统内部发生了什么AI可以根据完整调用链快速定位问题而无需重新分析整个项目减少AI在Loop Engineering中反复猜测问题所消耗的Token提高问题定位的准确率减少无效循环修改降低开发者向AI描述问题所需要的沟通成本。例如当请求在登录阶段就被拦截时日志不应该只输出一个401而应该完整说明整个业务上下文[请求被拦截]traceIdabc124 拦截层登录校验 结果拒绝 原因Token 已过期用户未登录 返回状态码401业务影响订单未创建请求未进入业务逻辑 建议请重新登录后再试[请求被拒绝]traceIdabc125 拦截层接口限流 结果拒绝 原因1分钟内请求次数超过阈值100 次 返回状态码429业务影响请求已被限流未进入业务逻辑[请求被拒绝]traceIdabc126 拦截层权限校验 当前用户1002目标资源用户1001的订单 结果拒绝 原因无权访问他人订单 返回状态码403业务影响请求未进入业务逻辑未返回任何订单数据相比传统日志这类日志不仅告诉开发者发生了什么更能够解释为什么会发生以及最终影响了什么业务。5.3 我希望日志能够回答的问题在设计整个Skill时我始终围绕着一个原则即使完全不阅读代码也能够通过日志理解整个系统的运行过程。因此当日志Skill生效后它至少应该能够回答下面这些问题当前正在执行哪个业务步骤这个步骤收到了哪些关键输入当前走了哪个业务分支为什么用户这一步操作带来了哪些数据每一步具体改动了什么每个值是从哪里来的关键计算前后分别是什么值计算后的最终数据是什么最终保存、提交、返回或展示给用户的值是什么数据库操作的真实意图是什么这次数据库操作影响了哪些数据范围最终产生了什么业务结果如果这些问题都能够通过日志回答那么对于非专业开发者来说系统便不再是一个无法理解的黑盒。5.4 一点设想本文并不认为日志能够替代更强大的模型也不认为日志能够解决所有AI Coding问题。但是从前面的实验来看当AI能够获得完整、结构化且包含业务上下文的运行日志时它定位问题的速度和准确率都会明显提升。因此我也产生了一个想法如果未来越来越多的IDE、AI Coding工具能够默认支持这种日志体系那么Audit-Driven Vibe Coding或许能够成为一种新的AI开发实践。它并不依赖某一个模型也不依赖某一个IDE而是让开发者、AI与系统共享同一份业务运行语义使AI不再依赖猜测而是依赖事实进行推理。我认为这也是未来Vibe Coding从能写代码走向可靠开发的重要一步。我最近还在思考一种更好的方式这篇文章6月多差不多这个时间吧就写了现在又有了一种新的想法不过还没成型还要带实验后再写文看看是否好用这篇文章所述的skill以下可能会对你有点帮助不过之后将会结合新的思考一起进行优化。5.5 SKILLskill 地址https://github.com/bit40303-ops/vibe-audit-logger 思考一种驾驭 Vibe Coding 的方式 Audit-Driven Vibe Coding （ADD）
一、现在的 vibe coding 似乎有些问题为什么Vibe Coding需要可靠性而不仅仅是能跑。本文主要讨论非专业开发者在使用Vibe Coding进行软件开发时如何提升应用的可靠性。随着AI Coding的普及越来越多没有专业开发背景的人开始能够借助 AI 开发自己的应用。这无疑极大降低了软件开发的门槛。然而大多数非专业开发者在使用Vibe Coding时往往采用的是一种硬蹬的方式不断让AI修改代码直到系统看起来实现了自己设定的目标。但问题是一个看起来完成了需求的软件真的完成了需求吗真正值得思考的并不是程序能不能运行而是程序执行过程是否正确数据是否被正确处理是否影响了其他业务逻辑系统内部是否存在被隐藏的问题在这之后还有如何更强的让AI定位错误及简化整个思考和操作步骤。在进行vibe coding时很多Bug恰恰不是程序崩溃而是在表面一切正常的情况下悄悄产生。1.1 一个非常典型的例子文件覆盖假设系统有一个需求根据不同的数据生成两个文件AI最终生成了下面这样的逻辑生成内容A保存为 文件A生成内容B但由于命名错误也**“保存”**为 文件A整个程序运行过程中不会报任何错误。甚至日志全部正常。但是最后目录里只剩下一个 文件A。那么问题来了这个文件到底是第一次生成的 A还是第二次生成的 B如果开发者没有主动打开文件检查很可能永远不会发现这个问题这种Bug在AI Coding中其实并不少见。尤其是在给AI一个较长的Spec时由于某些细节描述不够明确AI很可能会重复使用变量名重复使用文件名覆盖之前生成的数据忽略本应替换的内容这些问题往往不会导致程序报错因此AI自己也可能认为任务已经完成。真正发现问题的时候往往已经是在最终检查产物甚至是在项目上线之后。1.2 还有一个更隐蔽的例子优惠券再来看一个电商系统系统中存在两张优惠券优惠券A8折过期日期不同优惠券B8折过期日期不同测试阶段如果开发者只验证优惠券能够正常使用系统成功完成打折那么很容易认为功能已经开发完成但实际情况可能是无论输入优惠券A还是优惠券B系统内部始终读取的是优惠券A。如果测试时两张优惠券恰好都是8折那么整个测试过程完全不会暴露问题。直到后来运营将优惠券B修改为9折线上才发现为什么输入B却一直按A的折扣计算这类问题属于业务逻辑错误程序没有崩溃功能看起来也正常但是系统内部真正执行的逻辑已经发生了偏差。对于非专业开发者来说这种问题几乎无法通过看代码发现。1.3Vibe Coding最大的问题不是Bug而是假正确AI非常擅长让程序 “跑起来” 。但真正的软件开发需要保证的是系统内部的状态与开发者真正想表达的业务一致。很多时候页面显示正常API 返回正常自动化测试通过程序没有任何报错。但是系统内部的数据已经出现偏差这种问题我们可以称之为假正确也就是说软件表现出了 “正确” 的外观却没有真正实现正确的业务逻辑。1.4 当 AI 陷入循环修改时怎么办并且还有一个常出现的问题同一个问题重复对话但没有解决AI一直改不好同一个Bug开发者不断发送“还是有问题。”AI不断回复“我已经修复。”于是进入几十轮循环对于专业开发者来说他们可以阅读代码、定位调用链、分析变量流向但对于非专业开发者而言他们甚至不知道Bug出现在哪一个文件哪一个函数哪一次调用哪一个变量。因此他们无法准确告诉AI真正应该修改的是哪里。AI也只能不断代码、不断尝试修改消耗大量Token却仍然无法精准定位问题。1.5 第一次开发没问题不代表后续迭代没问题还有一个经常被忽略的现象第一次开发完成后整个系统似乎运行良好但随着功能不断增加新的修改开始影响旧的逻辑。于是原本正常的功能开始失效新需求修复了一个Bug却引入两个新的BugAI修改A时不小心破坏了B。这其实就是软件开发中经典的回归问题。对于专业团队来说会通过测试、代码审查和持续集成来降低这种风险而对于依赖AI开发的非专业开发者来说这种风险会被进一步放大。1.6 为什么需要一种新的 Vibe Coding 方法因此我们真正需要的并不是一个更会写代码的AI。而是一套能够帮助非专业开发者验证系统是否真正正确的方法。它应该能够帮助发现隐藏的逻辑错误而不仅仅是运行错误帮助定位问题发生的位置而不是让AI无限循环修改帮助验证业务是否真正符合预期而不是只验证结果是否看起来正确在后续迭代过程中持续发现回归问题避免越改越乱。未来随着模型能力不断增强再结合Loop EngineeringAI或许能够自动进入沙箱执行代码、分析报错、自动修复问题但即便如此如果能够提供一种低成本、高精度的辅助方式让AI更快定位问题、减少无效循环、降低Token消耗那么它与更强大的模型并不是替代关系而是互补关系。真正优秀的AI Coding不应该只是让程序能跑而应该让开发者能够相信程序跑得正确。二、为什么日志是 Vibe Coding 的基础设施随着AI Coding的快速发展普通用户使用AI进行Vibe Coding已逐渐成为一种常态。然而Vibe Coding并不意味着可以完全忽略软件工程实践。AI能够帮助开发代码但真正执行需求的是AI而不是开发者本人。对于非专业开发者来说AI生成的代码本质上就是一个黑盒。开发者知道自己提出了什么需求却不知道AI在内部调用了哪些模块修改了哪些文件数据经过了哪些处理最终为什么得到当前结果。即使对于专业开发者而言逐行审查AI生成的代码也是一件成本极高的事情。AI生成代码的速度已经远远超过了人类能够全面Review的速度因此人们开始越来越依赖AI的输出而忽略了传统的软件工程实践。然而这种信任并不意味着AI是绝对可靠的。《Preventing Failures in AI-Driven Software Engineering》 中指出当前AI Coding的一个重要风险就是开发者过度信任AI的输出而缺乏有效的验证机制。那么有没有一种低成本的方法可以帮助非专业开发者了解AI究竟做了什么我认为答案就是日志。日志本身一直存在于软件开发之中但传统日志主要服务于程序员。而对于Vibe Coding来说我们需要的不仅仅是程序日志更需要一种能够解释业务过程的日志。《Preventing Failures in AI-Driven Software Engineering》 同样指出运行时验证日志是确保代码安全以及事后调查AI行为的重要依据日志还必须能够保证真实性、完整性以及可审计性。这恰恰也是当前大多数非专业开发者在Vibe Coding中最容易忽略的一环。三、传统日志并不适合 Vibe Coding专业的日志对于非专业的vibe coding使用者来说并不友好他们真正关心的是刚才我点了按钮系统到底发生了什么因此Vibe Coding所需要的日志并不是增加更多日志而是增加更容易理解的日志。例如用户点击了创建订单 这个操作随后日志能够直接告诉用户收到创建订单请求-验证登录状态成功-验证库存库存充足-计算优惠券使用了优惠券B-计算最终金额原价999 → 折扣899-写入数据库-返回创建成功即使完全不会写代码也能够知道整个业务流程发生了什么这种日志本质上就是把原本隐藏在代码中的业务逻辑翻译成普通人能够理解的语言。当然日志并不是越多越好《Do AI Coding Agents Log Like Humans? An Empirical Study》同样指出日志过少会导致无法定位问题日志过多则会增加系统开销使真正有价值的信息被淹没。因此日志应该按照场景划分为两类开发日志、生产日志开发日志主要用于AI Coding阶段特点信息尽可能详细完整记录业务调用链包含关键变量变化能够帮助AI快速定位问题。而到了生产环境则应切换为生产日志主要记录错误告警性能指标Trace避免大量业务日志影响系统性能。四、实验验证这一节实验随便测试的不想看的可以跳过。4.1 BBS 测试为了验证日志方案的实际效果我首先编写了对应的日志Skill并准备进行第一次测试。为了尽可能模拟非专业开发者进行 Vibe Coding 时的真实场景我没有选择能力最强的大模型而是选用了能力适中的MiniMax-M3希望模型能够暴露出更多问题从而验证日志是否能够帮助定位和修复Bug。整个开发过程完全按照普通Vibe Coding的方式进行没有编写SDD、设计文档等详细说明仅通过自然语言描述需求让AI完成整个系统开发。我向AI提出了如下需求结果有些出乎意料MiniMax-M3一次就完成了整个项目看起来选择的模型还是有些强了不过真正开始使用系统后还是发现了一些接口存在异常。与此同时我编写的日志Skill也已经开始正常工作并成功输出了运行日志不过此时的日志仍然偏向开发者视角可读性并不高后续还需要不断优化让非专业开发者也能够快速理解系统到底发生了什么随后我查看了后端日志确认日志已经完整输出既然日志已经能够完整记录系统运行过程那么接下来便完全按照非专业开发者的思路进行操作不阅读代码而是直接将日志交给AI分析问题。AI很快给出了分析结果并表示已经找到了问题原因。不过对于AI的回答始终需要保持一定的怀疑态度因此我没有直接相信而是继续进行实际测试验证果然问题依然存在于是我没有重新描述整个问题而是提交更详细的整个日志让AI获取更多上下文信息这一次问题顺利得到解决随后我开始测试完整业务流程注册账号-登录后-修改头像在修改头像后又出现了新的问题刷新页面后头像无法正常显示查看前端日志后可以看到如下信息虽然日志内容对于非专业开发者来说依旧不容易理解但这已经不是重点。按照Vibe Coding的思路只需要将控制台日志完整复制给AI让 AI 帮助分析即可AI修改后页面刷新时又输出了新的日志。AI根据日志分析认为当前系统正在通过8080端口访问BBS服务但又提示应该访问8000端口这里其实暴露出了真正的问题由于前端本身就是运行在8080端口因此AI已经意识到请求配置存在异常只是缺少最后一步确认。将这一信息反馈给AI后它很快定位到了错误的请求地址并完成修复问题成功解决通过这次测试我也得到了一点新的体会。对于非专业开发者来说虽然不需要阅读代码但如果能够掌握一些最基础的软件开发概念例如什么是端口、什么是请求、接口等知识在与AI协作解决问题时效率会明显提高。因此我也在考虑是否可以专门编写一套面向非专业开发者的基础教程只介绍Vibe Coding过程中必须理解的一些概念而不涉及具体代码以进一步降低使用门槛。完成以上问题修复后我重新测试了整个业务流程没有再发现新的异常整个BBS系统能够正常运行4.2 电商测试为了进一步验证日志方案的通用性我更换了模型并重新进行了另一组实验。这次依旧采用相同的Vibe Coding流程因此前面的创建项目、生成代码等重复过程就不再赘述直接进入关键测试环节。经过对话后AI成功生成了一个电商系统但hy3太笨了该模型对于部分指令的遵循程度并不理想。例如我要求其为整个项目增加日志但模型并没有一次性完成因此需要继续引导AI为全局代码补充日志完成日志补充后我开始对整个购物流程进行测试很快便发现了一个明显的业务逻辑错误订单结算页面中应付金额竟然变成了负数显然正常情况下应付金额不可能为-841元遇到这种问题时最直接的方法当然是告诉AI应付金额计算错误请修复。但这种描述过于笼统AI 很可能无法准确判断问题究竟出现在优惠券计算、商品金额统计、折扣计算还是最终金额汇总阶段因此往往需要经过多轮修改才能真正定位问题。而这正是日志发挥作用的地方我没有重新描述整个业务流程而是直接将运行日志发送给AI并明确指出应付金额计算结果异常让AI根据完整的调用链分析数据究竟是在什么环节开始出现错误AI很快返回了分析结果并表示已经找到了问题原因不过根据前面的实验经验对于AI的结论仍然需要保持验证的态度因此我并没有直接认为问题已经解决而是继续进行实际测试令人意外的是这一次AI的分析是正确的按照日志定位到的问题进行修改后应付金额恢复正常整个结算流程也能够正确完成相比直接告诉AI金额计算有问题日志不仅提供了完整的数据流转过程还帮助AI快速定位到了异常发生的位置避免了大量无意义的猜测和循环修改。这次实验也进一步验证了前面的观点对于业务逻辑类问题完整的调用链日志能够显著提升AI的定位效率。 非专业开发者无需阅读代码只需要提供包含关键数据变化的日志AI就能够更准确地分析问题所在从而减少反复试错的成本。4.3 换一个没听过的模型继续测试资产管理系统为了避免实验结果受单一模型能力影响我决定继续更换模型测试日志方案在不同模型上的表现。这一次我选择开发一个资产管理系统继续按照Vibe Coding的方式仅通过自然语言描述需求让AI完成整个项目在最开始的开发过程中模型很快便出现了报错虽然终于出现了可以验证日志效果的问题但遗憾的是这个模型在复杂任务上的表现较弱甚至没有完成整个系统的开发导致后续测试无法继续因此只能更换另一款模型。随后我换用了Step-3.7-Flash模型。此前也听不少人提到这个模型虽然能力相对一般但响应速度较快因此正好可以验证日志是否能够弥补模型在问题定位上的不足果然在继续开发过程中很快再次出现了运行错误这一次没有重新描述问题而是直接将运行日志复制给AI。AI根据日志分析调用链很快便定位到了异常原因并完成了修复。完成修复后我继续测试业务流程又发现了新的Bug依旧采用相同的方法将对应日志发送给AIAI 很快定位到了问题所在并顺利完成修复随后继续测试时又发现了文件下载功能存在异常于是再次将对应日志发送给AI让其分析问题最终这个问题同样顺利得到解决连续几次实验下来我开始有一个比较明显的感受当日志能够完整记录业务调用链和关键数据变化时AI的问题定位效率会明显提升。相比于不断向 AI 重复描述这里有问题“这里还是不对”直接提供包含上下文信息的日志能够帮助AI更快理解当前系统状态也减少了多轮来回沟通和无效修改。当然这并不意味着日志能够解决所有问题也不能保证AI每一次都能一次修复成功。但至少在这几次实验中无论是运行异常、业务逻辑错误还是功能缺失只要日志能够完整记录关键过程AI都能够更高效地完成问题定位和修复。这也进一步印证了前面的观点日志不仅是给开发者看的同样也是AI理解系统运行状态的重要上下文。4.4 完整项目验证企业内部资产管理系统前面的几组实验主要验证了日志在局部功能开发和问题定位中的作用。为了进一步验证其在真实开发场景中的效果这一次我不再采用简单 Demo而是按照自己平时的开发流程完整实现一个企业内部资产管理系统。与前几次实验不同这次开发采用了更加完整的工作流首先我编写了项目的Spec并结合前面几轮实验的反馈对日志Skill进行了进一步优化。随后使用Qoder按照Spec一键生成整个项目观察日志方案在完整项目中的实际表现项目生成过程前日志Skill已经自动集成到整个工程中项目首次运行后整体效果比预期更好大部分功能一次性即可正常运行不过这并不意味着整个系统完全没有问题继续深入测试业务流程后很快还是发现了新的Bug按照前面实验形成的习惯我没有继续向AI描述整个业务流程而是直接将对应的运行日志发送给 AI让其根据日志分析问题原因AI很快返回了分析结果并指出了可能存在的问题AI自动修改完后问题顺利解决随后继续测试完整业务流程创建账号后在同一个部门上传了一份文件。按照业务设计管理员应该能够查看该文件但实际测试中却发现管理员列表为空文件并没有正常显示。于是再次查看日志并将日志发送给 AI 分析这一次的问题相比之前更加复杂AI连续进行了三轮修改但始终没有彻底解决问题。直到补充了更加完整的运行日志后AI才真正理解了整个业务调用链以下是给与AI的对话信息在获得完整日志之后AI很快定位到了真正的问题并完成了最终修复整个实验完成后我不敢说AI修复Bug的能力提升了没做大量实验但沟通成本明显降低了。以前遇到问题时我需要不断向 AI 描述我做了什么哪一步出了问题我希望它修改哪里修改之后还有什么现象。整个过程往往需要反复手动敲补充大量上下文信息而加入日志之后这些描述大部分都可以由日志本身完成。AI能够直接从日志中获取完整的业务流程、数据变化以及调用链信息我只需要告诉它**“这里有问题请结合日志分析”** 又或者进一步说哪一个数据有问题 即可。对于不会阅读代码的非专业开发者来说这一点尤为重要日志不仅帮助 AI 更快理解问题也帮助开发者准确表达问题。双方围绕同一份运行信息进行交流大大减少了由于信息缺失而导致的无效修改和反复沟通。经过这一轮完整项目的验证我更加确信前面的观点对于Vibe Coding而言高质量的日志不仅是一种调试工具更是一种连接开发者与AI的沟通媒介。 当日志能够完整、准确地描述系统的运行状态时无论项目规模大小都能够辅助AI定位问题和修复问题的效率。五、面向 Vibe Coding 的日志规范经过前面的多组实验我越来越确信一点对于Vibe Coding而言日志不仅是调试工具更应该成为AI与非专业开发者或专业开发者共同理解系统行为的媒介。经过前面的分析与实验我发现这已经不仅仅是一套日志规范而更像是一种新的Vibe Coding开发方式。本文将这种以可审计日志Auditable Logging为核心通过完整记录业务生命周期、帮助AI与开发者共同理解系统行为的开发方式称为Audit-Driven Vibe CodingADVC。Audit-Driven Vibe Coding并不是一种新的开发框架也不是一种新的AI Agent而是一种开发实践。它强调通过高质量、可审计、面向业务的日志将AI生成的黑盒代码转化为开发者和AI都能够理解的白盒业务流程从而提升Vibe Coding的可靠性、可维护性以及问题定位效率。《Preventing Failures in AI-Driven Software Engineering》中提出了Auditable Logging可审计日志 的概念。论文认为AI软件工程需要能够全面、真实且可验证地记录AI的行为以支持后续的问题调查、责任追溯以及合规审查。日志不仅需要记录系统发生了什么更需要能够反映系统行为与预期之间的偏差从而帮助开发者理解问题产生的原因而不仅仅是知道问题已经发生。这一观点与本文的实验结果高度一致因此在我编写的日志Skill中并没有仅仅增加几条调试信息而是尝试围绕完整的请求生命周期建立一套更加适合Vibe Coding的日志规范。5.1 请求链路日志覆盖规范对于每一个完整业务请求都应确保其整个生命周期能够被完整记录。并非所有请求都会经过所有处理阶段但对于未执行的阶段也应明确记录未执行的原因而不是直接省略日志从而避免请求链路出现信息断层。整个请求链路至少应覆盖以下几个阶段请求到达入口已记录TraceID、路径、方法、来源、关键参数摘要。中间件/过滤器/拦截器每一层鉴权、限流、CORS、签名、租户、幂等等都记录了通过或拦截结果与原因。被拦截/被拒绝未进业务方法明确记录“请求未进入业务逻辑”含拦截层、拒绝原因、返回状态码、业务影响。业务方法执行入口、关键分支、计算过程、数据流转、数据库操作都有日志。响应返回记录了状态码、响应数据摘要、耗时、最终业务结果。异常/错误记录了异常类型、发生阶段、TraceID、对用户或业务的影响、是否已处理。TraceID以上所有阶段包括被拦截、被拒绝、抛异常的分支使用同一个TraceID。分层覆盖涉及到的前端、中间件、接口层、服务层、数据库层、外部调用层都有对应日志。对于AI Coding来说日志覆盖率本身也应该成为交付标准。只要存在任何一个适用阶段没有日志就应当视为本次开发任务尚未完成而不能仅仅因为程序能够正常运行便认为项目已经交付。5.2 日志的真正目标很多人认为日志只是为了方便排查Bug但对于Vibe Coding来说我认为日志承担着另外一个更加重要的职责——把AI生成的黑盒代码转换成普通人也能够理解的白盒业务流程。完整记录一次请求的生命周期并不是为了生成更多日志而是为了完整保留系统运行过程中所有重要的信息这样做至少能够带来几个好处非专业开发者无需阅读代码就能够理解系统内部发生了什么AI可以根据完整调用链快速定位问题而无需重新分析整个项目减少AI在Loop Engineering中反复猜测问题所消耗的Token提高问题定位的准确率减少无效循环修改降低开发者向AI描述问题所需要的沟通成本。例如当请求在登录阶段就被拦截时日志不应该只输出一个401而应该完整说明整个业务上下文[请求被拦截]traceIdabc124 拦截层登录校验 结果拒绝 原因Token 已过期用户未登录 返回状态码401业务影响订单未创建请求未进入业务逻辑 建议请重新登录后再试[请求被拒绝]traceIdabc125 拦截层接口限流 结果拒绝 原因1分钟内请求次数超过阈值100 次 返回状态码429业务影响请求已被限流未进入业务逻辑[请求被拒绝]traceIdabc126 拦截层权限校验 当前用户1002目标资源用户1001的订单 结果拒绝 原因无权访问他人订单 返回状态码403业务影响请求未进入业务逻辑未返回任何订单数据相比传统日志这类日志不仅告诉开发者发生了什么更能够解释为什么会发生以及最终影响了什么业务。5.3 我希望日志能够回答的问题在设计整个Skill时我始终围绕着一个原则即使完全不阅读代码也能够通过日志理解整个系统的运行过程。因此当日志Skill生效后它至少应该能够回答下面这些问题当前正在执行哪个业务步骤这个步骤收到了哪些关键输入当前走了哪个业务分支为什么用户这一步操作带来了哪些数据每一步具体改动了什么每个值是从哪里来的关键计算前后分别是什么值计算后的最终数据是什么最终保存、提交、返回或展示给用户的值是什么数据库操作的真实意图是什么这次数据库操作影响了哪些数据范围最终产生了什么业务结果如果这些问题都能够通过日志回答那么对于非专业开发者来说系统便不再是一个无法理解的黑盒。5.4 一点设想本文并不认为日志能够替代更强大的模型也不认为日志能够解决所有AI Coding问题。但是从前面的实验来看当AI能够获得完整、结构化且包含业务上下文的运行日志时它定位问题的速度和准确率都会明显提升。因此我也产生了一个想法如果未来越来越多的IDE、AI Coding工具能够默认支持这种日志体系那么Audit-Driven Vibe Coding或许能够成为一种新的AI开发实践。它并不依赖某一个模型也不依赖某一个IDE而是让开发者、AI与系统共享同一份业务运行语义使AI不再依赖猜测而是依赖事实进行推理。我认为这也是未来Vibe Coding从能写代码走向可靠开发的重要一步。我最近还在思考一种更好的方式这篇文章6月多差不多这个时间吧就写了现在又有了一种新的想法不过还没成型还要带实验后再写文看看是否好用这篇文章所述的skill以下可能会对你有点帮助不过之后将会结合新的思考一起进行优化。5.5 SKILLskill 地址https://github.com/bit40303-ops/vibe-audit-logger