企业官网建设流程全解析

一、现在的 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 还有一个更隐蔽的例子：优惠券

再来看一个电商系统，系统中存在两张优惠券：
优惠券A：8折过期日期不同
优惠券B：8折过期日期不同

测试阶段，如果开发者只验证：

• 优惠券能够正常使用
• 系统成功完成打折

那么很容易认为功能已经开发完成，但实际情况可能是：

• 无论输入优惠券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，却引入两个新的Bug；
• AI修改A时，不小心破坏了B。

这其实就是软件开发中经典的回归问题。对于专业团队来说，会通过测试、代码审查和持续集成来降低这种风险，而对于依赖AI开发的非专业开发者来说，这种风险会被进一步放大。

1.6 为什么需要一种新的 Vibe Coding 方法？

因此，我们真正需要的，并不是一个"更会写代码"的AI。而是一套能够帮助非专业开发者验证系统是否真正正确的方法。

它应该能够：

• 帮助发现隐藏的逻辑错误，而不仅仅是运行错误；
• 帮助定位问题发生的位置，而不是让AI无限循环修改；
• 帮助验证业务是否真正符合预期，而不是只验证结果是否"看起来正确"；
• 在后续迭代过程中持续发现回归问题，避免越改越乱。

未来，随着模型能力不断增强，再结合Loop Engineering，AI或许能够自动进入沙箱执行代码、分析报错、自动修复问题；但即便如此，如果能够提供一种低成本、高精度的辅助方式，让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：

依旧采用相同的方法，将对应日志发送给AI：

AI 很快定位到了问题所在，并顺利完成修复，随后继续测试时，又发现了文件下载功能存在异常：

于是再次将对应日志发送给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 Coding（ADVC）。

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，而应该完整说明整个业务上下文：

[请求被拦截]traceId=abc124 拦截层=登录校验 结果=拒绝 原因=Token 已过期，用户未登录 返回状态码=401业务影响=订单未创建，请求未进入业务逻辑 建议=请重新登录后再试

[请求被拒绝]traceId=abc125 拦截层=接口限流 结果=拒绝 原因=1分钟内请求次数超过阈值（100 次） 返回状态码=429业务影响=请求已被限流，未进入业务逻辑

[请求被拒绝]traceId=abc126 拦截层=权限校验 当前用户=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 SKILL

skill 地址：https://github.com/bit40303-ops/vibe-audit-logger