Imported from Kemou2333/Kemou2333.github.io (
AGENTS.md). Install upstream withnpx skills add Kemou2333/Kemou2333.github.io. Copyright stays with the author.
Kemou 个人博客：AI 项目总说明
这份文件是本项目交给 Codex、Kimi、Claude Code 等 AI 时的唯一首要说明。开始任何工作前先完整阅读本文件；普通发文不需要重新研究或改写网站。
1. 项目身份与唯一正式版本
- 这是 Kemou 的个人博客，基于 Astro/Fuwari 修改。
- 正式本地仓库就是包含本文件的当前目录：
C:\Users\Administrator\Documents\个人博客\模板实验\fuwari-kemou。 - GitHub 仓库：
https://github.com/Kemou2333/Kemou2333.github.io。 - 线上网站：
https://kemou2333.github.io/。 - 正式分支：
main；GitHub Pages 会在推送后自动构建发布。 - 不要从旧压缩包、交接包、其他博客原型或名字相近的目录继续开发。
- 2026-07-26 时，博客只保留一篇正式文章：
src/content/posts/deepseek-users-wont-leave.md；此前的示例占位文章已经删除。
2. Kemou 的沟通与写作偏好
- Kemou 是技术初学者，只会 Vibe Coding。完成任务后用简体中文说明结果，避免只给术语和命令。
- 语音输入经常把“博客”识别成“播客”。当上下文涉及个人网站、文章、Markdown、分类或发布时，默认理解为“博客”；只有明确谈音频节目时才按“播客”理解。
- 博客定位不是教程站，而是公开的个人思考档案：记录 AI、游戏、项目、学习和生活中的使用感想与心路历程。
- Kemou 更常通过语音口述原始想法。AI 应充当采访者、编辑和排版助手，不要替他虚构经历、强行升华或添加与原意无关的行业观点。
- 写作语气应普通、自然、稍微有趣，可以保留吐槽和梗；不要写成营销号、论文、说明书，也避免“随着时代发展”“在这个日新月异的时代”等 AI 套话。
- 可以修正错字、标点、重复和口述病句，但观点、大幅扩写和重写结论必须以 Kemou 提供的内容为依据。
- 涉及新闻、人物发言、价格、产品现状和具体数字时，区分原始材料、公开事实与 Kemou 自己的推论；重要事实在发布前核对来源。
- AI 辅助文章可按 Kemou 的要求在结尾保留创作说明，明确观点来自本人，AI 只负责整理和文字扩写。
3. 最重要的架构原则：发文章不等于重写网页
本博客是内容驱动的静态网站。首页、文章页、分类、标签、归档、搜索、RSS 和 Sitemap 都会自动读取 src/content/posts/。
新增普通文章时，AI 通常只需要：
- 新建一篇
.md或.mdx； - 填写 frontmatter；
- 将图片放进指定目录并在正文引用；
- 构建检查；
- 在 Kemou 明确要求上线时发布。
普通发文不得重新开发首页、分类页、归档页、RSS 或文章模板。只有 Kemou 明确要求新增网站功能、修改布局、动画或整体视觉时，才改前端代码。
4. 文章与图片目录
- 正式文章和随笔：
src/content/posts/ - 正文及封面图片：
public/assets/images/ - 一篇内容对应一个
.md或.mdx文件。 - 文件名只使用小写英文、数字和连字符，例如
first-week-with-codex.md。 - 文件名就是网址的一部分，发布后不要随意改名。
- 图片文件名也使用小写英文和连字符；正文使用
/assets/images/文件名引用。 - 不要把图片转成 Base64，不要把临时截图留在项目根目录。
5. 新文章标准流程
5.1 先整理内容
如果 Kemou 提供的是语音口述：
- 先找出他真正想说的 2–4 个中心点；
- 对缺少的个人体验或态度进行少量追问；
- 整理成保留第一人称和原有语气的初稿；
- 让 Kemou 确认标题、观点和删减；
- 最后再写入 Markdown 文件。
不要因为原始口述不够“完整”，就擅自添加大量自己的内容。
5.2 创建文章文件
可以运行：
pnpm new-post -- article-slug也可以直接创建文件。标准 frontmatter：
---
title: 文章标题
published: 2026-07-26
description: 用一两句话具体说明文章谈什么。
image: /assets/images/example-cover.webp
tags: [AI, DeepSeek, AGI]
category: AI 与工具
draft: false
---字段规则：
title：尊重 Kemou 原本表达，不改成营销号标题。published：首次发布日期，格式YYYY-MM-DD。updated：只有实质修改旧文章时才添加。description：约 30–80 个汉字，避免空泛宣传。image：封面路径；无封面时写''，不要编造路径。tags：通常 2–5 个，只保留真正有检索价值的词，避免为了凑数加入人名。category：优先使用四个主分类。draft：未确认公开时设为true；Kemou 明确发布后才设为false。
正文标题从 ## 开始，页面会自动将 frontmatter 的 title 作为一级标题。
6. 分类与统一颜色
四个主分类：
AI 与工具：AI 使用体验、普通用户视角、工具记录。学习与项目：大学、学习方法、个人项目。游戏与体验：PC、主机、掌机和游戏感想。生活随记：生活观察、通勤、做饭和短随笔。
分类颜色不得由 AI 临时选择。唯一配色入口是：
src/utils/accent-utils.ts固定规则：
AI 与工具→ 青蓝学习与项目→ 蓝紫游戏与体验→ 珊瑚橙生活随记→ 薄荷绿
新分类会按名称获得稳定颜色。文章 frontmatter 不得添加 color、accent 等颜色字段，也不要在组件里写行内色值。
7. Markdown 与图片注意事项
- 图片必须有有意义的替代文字：
- 引用使用普通 Markdown：
> 引用内容- 当前处理链曾出现引用框开头的
**加粗**没有渲染、直接露出星号的问题。创作说明等内容优先使用普通文字，或构建后确认 HTML 确实生成了<strong>。 - 引用框和侧栏标签已经做过紧凑与阴影裁切修复；不要重新给它们添加大面积外阴影或无条件
overflow-hidden。 - 封面尽量选择清晰、构图适合裁切的图片；首页卡片和文章页会自动使用同一封面。
- 封面建议至少为
1000×1000，首页缩略图在高分辨率屏幕上才不会因放大而发糊；不要为了节省很小的体积而使用明显有压缩痕迹的图片。 - 正文可以自然使用
**加粗**、列表和引用突出层次，但不要整段连续加粗，也不要为了“像 Markdown”而机械堆格式。
8. 视觉维护规则
涉及前端视觉修改时，额外阅读 设计思路与注意事项.md。
- 新拟物语义：外壳凸起；输入框、相框和读数槽下沉；按钮悬停抬升、按下下沉。
- 光源统一为左上反光、右下投影。
- 塑料与亚克力只能反光，不能使用霓虹外发光。
- 优先复用
src/styles/main.css的公共类和src/styles/variables.styl的设计令牌。 - 不要为了一个页面复制整套阴影、颜色或动画。
- 标签和分类按钮位于会裁切内容的卡片中；修改阴影时必须检查亮色模式下是否出现方形截断。
- 尊重
focus-visible和prefers-reduced-motion。
9. 验证规则
- 修改前先运行
git status，保留用户未提交的改动。 - 不直接编辑
dist/、.astro/和node_modules/。 - 一批修改完成后运行一次：
pnpm.cmd build- 构建成功即可停止；只有失败时才修复真实错误并重试。
- 文章有图片或视觉修改时，检查一次首页和文章页；亮色模式下额外检查阴影、裁切和排版。
10. 发布方式与“一键发布”的边界
根目录的 一键发布博客.cmd 是给 Kemou 双击使用的本地发布工具。
它会：
- 检查当前是否为
main； - 获取 GitHub 最新状态，避免覆盖远端更新；
- 运行正式构建；
- 只暂存
src/content/posts/和public/assets/images/的变化； - 自动提交并推送到 GitHub Pages。
它不会：
- 把 Word、聊天记录或任意纯文本自动转换成一篇完整文章；
- 自动理解内容、选择标题和配图；
- 上传 CSS、组件、脚本或配置修改；
- 将 GitHub 密钥写入网页。
因此标准协作方式是：
Kemou 口述/编辑内容
→ AI 整理并新增 Markdown 与图片
→ Kemou 确认
→ 双击“一键发布博客.cmd”
→ GitHub Pages 自动更新没有后端并不影响这种本地一键发布。不要在公开网页中加入直接写 GitHub 的“管理后台”，因为那会要求在浏览器暴露高权限凭据。若以后确实需要网页后台，必须另行设计安全的认证和服务端存储。
涉及网站代码、样式、配置或本发布工具本身的修改时，不要依赖一键发布；由 AI 明确选择文件、构建、提交并推送。
11. Git 与发布安全
- 已有未提交改动默认属于 Kemou，不得覆盖、丢弃或偷偷加入当前提交。
- 不使用
git add -A处理混合工作区；明确选择本次相关文件。 - 推送前先同步远端，禁止强推和覆盖远端历史。
- 只有 Kemou 明确要求上线，或正在处理已上线内容的发布型后续修改时，才推送。
- 推送后只确认一次 GitHub Pages 任务；若仍在运行，等到成功或明确失败。
- 正常文章发布无需 PR，按项目既有方式直接更新
main。
12. 项目清理边界
- 当前 Git 仓库和 GitHub 云端是正式版本。
- 可以清理明确的旧工程副本、空交接包、旧压缩包及可重新生成的缓存。
dist/和.astro/可以重新生成，但不要手工修改。node_modules/占用较大，但本机一键发布依赖它；除非准备重新安装依赖，否则保留。- 删除旧目录前必须确认它不是当前正式仓库，并报告释放的大致空间。
13. 完成任务后的汇报
用简短的简体中文说明：
- 新增或修改了什么；
- 文章分类、标签和公开状态；
- 构建是否成功；
- 是否已经推送并部署；
- 是否保留了其他未提交改动；
- 如有删除，说明删除了什么、释放多少空间、是否能从 Git 历史或云端恢复。
用户向说明见 内容发布指南.md；视觉细节见 设计思路与注意事项.md。