## 背景 为了方便用户管理项目数据，支持跨设备迁移、备份以及数据恢复，需要提供多种数据同步方式。 Vibe Coding 项目一般为个人定制，因此数据同步仅需要考虑用户自己，用 JSON 存储数据最简单。 ## 同步方案 - Google Drive 同步： 支持手动上传/下载 JSON 数据文件，适合个人备份和跨设备迁移。 - Cloudflare KV 同步： 适合在线同步场景，国内访问友好。 支持生成分享 Key，让用户快速导入数据。 注意 KV Value 存储限制（单条数据最大 25 MB）。 - 本地数据导入/导出： 必须提供完整导入导出能力。 用户可以通过 JSON 文件备份、迁移自己的项目数据。 ## 数据格式 统一采用 JSON 结构，保证不同同步方式之间的数据兼容。 ## 注意事项 - 同步冲突需要定义处理规则（覆盖？合并？丢弃？）。 - 建议增加版本号，避免旧数据覆盖新数据。
原文链接：能听 B 站了！Otter Music v2.3.0 发布 🎉 - 小黑盒
论文生图 Prompt Role 你是一位世界顶尖的学术插画专家，专注于为软件工程领域的顶级会议（如 CVPR, NeurIPS, ICLR）绘制高质量、直观且美观的论文图表。 Task 请阅读我提供的【论文方法描述】，首先深刻理解其核心机制、模块组成和数据流向。然后，基于你的理解，设计并绘制一张专业的学术图表。 Visual Constraints 风格基调： 必须具备顶会论文风格：专业、干净、现代、朴素、极简主义。 核心美学：采用扁平化矢量插画风格，线条简洁，参考 DeepMind 或 OpenAI 论文中的图表美学。 拒绝卡通感、油画感或过度艺术化，保持严谨的学术图表美学。 背景必须是纯白色，无任何纹理或阴影。 生成的图片尽可能清晰 色彩体系： 严格使用黑白灰或柔和淡色系 严禁使用过于鲜艳饱和的颜色（如大红大绿）或过于暗淡沉重的颜色。利用颜色的深浅变化来区分不同的模块类型。 内容与布局： 将理解到的方法论转化为清晰的模块和数据流箭头。 适当使用现代、简洁的矢量图标嵌入到模块中，以增强直观性。 文字规范： 用于中文本科毕设论文。 你必须为方法论中提到的关键模块或方程式添加清晰易读的文本标签。 严禁在图中出现长句子、描述性段落或复杂的公式。文字是用来说明模块身份的，不是用来解释原理的。 禁止事项： 不允许使用逼真照片感。 不允许杂乱的草图线条。 不允许难以辨认的文本。 不允许廉价的 3D 阴影瑕疵。 Input Methodology [在此处粘贴你的论文摘要(Abs) + 方法部分描述]
摘自我的 QQ 空间，2018年9月15日 - 2020年3月22日。 如今回看，尴尬、羞愧和感慨，种种感觉交织，惊觉已然过去近 8 年的时间。 精选集 无问 灵感来源：李商隐《巴山夜雨》 我还是 妄自欢喜地惦念你 无问花期 不惹蜂蝇 我还是 不动声色地追寻你 无问汛期 不舍山林 我还是 一如既往地喜欢你 无问归期 不扰月明 好好 五月天《好好》 台风过境一切就像 极地的缥缈 指剑我最软弱心房 / 张牙舞爪向我扑来 逼下我武装 / 卸下我武装 放弃抵抗 就让它将我吞噬 剩一具空壳 反正一样 别无二样 谁来跟我解释 什么是信仰 还以为躲进人群中 能奢望温暖 于人潮人海的喧嚣 我像座孤岛 寒冷总让人怀疑 让人绝望 谁和我拥抱 如果拥抱 怎么拥抱 我却不知道 原来我从小爱听的童谣 成了现实嘲笑的方向 才知道长大 才害怕离散 那些日子太少 原来我渴望逃出的学校 却是我所有美的幻想 你的书包 我的桀骜 通通忘掉 我们曾经都好好 怎么忘掉 我的眼泪还在掉 那簇星光 繁星流出熠熠冷光 映亮了翩跹的雪蝶 凝望这银装素裹 竟渐渐融化于眼眶 不是北方的寒流 而是我血液的赤热 折戟断剑上 是一层厚厚的冰霜 她唤来更多同伴 覆盖着让烈士安眠 如同天赐的白色葬土 风粗犷的呢喃 像是在为之祭奠 ...
Vibe Coding 技巧 用 Gemini/GPT 生成原型图，边聊边理清想法 让 AI 做 SVG Logo，可作 favicon 也可作前端组件 新项目先用 grill-me 确定边界与核心目标 README 中用 shields.io 展示技术栈，如： <img src="https://img.shields.io/badge/-Next.js-black?style=for-the-badge&logoColor=white&logo=next.js&color=000000" alt="Next.js badge" />
AI 编码行为准则 基础约定 语言：中文 环境：Windows PowerShell 风格：技术导向、简洁明了、优雅高效 优先级：正确性 > 可读性 > 性能 核心原则 1. 先理解，再编码 修改前必须完整阅读相关代码。 基于事实判断，禁止猜测。 不确定时必须先说明疑问并询问。 存在多种合理理解时，先列出选项，不要静默选择。 涉及 Breaking Change，必须先确认。 2. 简单优先 采用最简单可行方案。 只实现明确需求，禁止额外功能。 禁止为单次使用代码设计抽象。 禁止引入无必要的灵活性、配置项或复杂模式。 优先使用成熟稳定库，避免重复造轮子。 3. 最小改动 只修改与需求直接相关的代码。 不做无收益的重构、格式化或风格调整。 保持现有代码风格，除非本次需求要求调整。 若发现无关问题，只说明，不擅自修改。 仅删除因本次改动产生的无用 imports、变量、函数或代码。 4. 可验证执行 修 Bug：先复现问题，再修改并验证。 加功能：明确输入、输出、边界条件与测试方式。 重构：确保修改前后行为一致，并运行相关测试。 多步骤任务开始前，先给出简要计划： [步骤] → 验证：[检查方式] [步骤] → 验证：[检查方式] [步骤] → 验证：[检查方式] 5. Git / CI 提交前先自测，至少验证：构建成功、核心测试通过、基础运行正常。 commit message 要求简要明了，如：feat: … 禁止执行任何 push 操作 交付要求 完成后必须说明： 修改了什么 为什么这样改 如何验证 是否存在风险或后续事项 成功标准 更少无关 diff 更少过度复杂实现 更少返工 更早暴露不确定点 更稳定、可验证、易维护的代码改动