在读研三 vibe coding重度使用患者，搞一个小skill

作者：#袁hc 板块：#搞七捻三 在读研三 vibe coding 重度使用患者，搞了个小 Skill 以下描述都是AI上供的，大概检查了以下差不多就是这个意思 最近 vibe coding 用得有点重。 写代码、改论文、做实验、配环境，基本都喜欢先把需求丢给 AI，然后看它一路狂奔。用久了发现一个很有意思的问题： AI 通常不是不干活，而是太会“干活”了。 它可以认真查资料、跑测试、改参数、整理文件、生成报告，最后告诉你： “任务已完成。” 但你打开结果一看： 软件还没真正跑起来，核心功能也没验证，倒是日志、哈希和检查结果非常完整。 于是我做了一个小 Skill，叫 Mainline Guardian。 简单说，它的作用就是： 让 AI 一直记得这件事到底要完成什么。 它主要解决什么问题？ 1. 防止主线被支线带跑 比如一开始的目标是： 做一个能运行的视觉识别小工具。 过程中可能会出现： 查一下 TensorRT 怎么部署 讨论一下模型量化 研究一下 CUDA 算子 顺手改一下 README 再看一下别人 GitHub 上的方案 这些事情都可能有用，但它们本身不是最终目标。 Mainline Guardian 会把这些内容当成“支线”，记录： 为什么要做这个支线 什么时候算结束 得到了什么结论 回来之后主线还差什么 下一步继续做什么 不会出现“查资料查着查着，项目变成资料整理项目”的情况。 2. 防止 AI 用“容易检查的东西”冒充完成 AI 很喜欢检查这些东西： 文件存在 XML 合法 测试通过 哈希一致 shape 数量正确 计划全部打勾 这些检查不是没用，但它们不等于用户真正想要的结果。 所以这个 Skill 会要求先写清楚： 用户怎样判断这个结果真的可用？ 比如不是写： 文件已经生成 而是写： 用户可以在目标环境打开软件，并完成一次核心操作 最后也不能只因为测试通过就宣布完成。对于“用户才能确认”的结果，必须等待用户确认。 3. 防止外部资料直接替项目做决定 经常会遇到这种情况： “资料说应该用方案 A，那我们就用 A。”