2026-06-23 00:37:38
端午节期间，本来准备出去骑车的。结果一连下了三天的雨。那就找点其他的事情干吧。
第一件事情，清理小窝。把小窝的所有衣物都清洗一下，无死角清理灰尘。这一步干完之后，扔了6个垃圾袋呀。并且移动了个人书桌。移动之后，感觉的确舒服不少呀。后续如果家具变多的话，需要阅读下面几本书：
第二件事情，去旁边的朵云书店溜达。之前骑车总会路过这个书店，周六进去之后，看了一下午的书。感觉拓展了一下被动获取知识的方式。一下午，囫囵吞枣读了下面几本书：
而且在这个地方看湖景，非常好。
第三件事情，去湖边看端午烟花。本周的无人机还表演了端午主题，图片有：龙、舟、屈原、毕业快乐、中考加油等。
端午过去了，第一天上班，比之前有精力多了都。
2026-06-23 00:17:31
近一个月，本人的这个小破站被攻击了5次。幸好设置了邮箱提醒，我能够知道什么时间发生的事情呀。每次给我发送的邮件内容，具体如下：
将其进行统计之后，可以得到一下的结果。
| 时间 | ip | |
|---|---|---|
| 2026.05.16 | 118.212.138.52 | |
| 2026.05.16 | 118.212.138.52 | |
| 2026.06.01 | 1.71.146.47 | |
| 2026.06.01 | 1.71.146.120 | |
| 2026.06.01 | 1.71.146.120 |
话说这个ip有重复的，感觉就是软件扫描后攻击的呀。
自己赶紧修改密码，并且将网站中非常多的垃圾用户给清理了都。
2026-05-10 21:50:25
之前对于滴水湖有了一些介绍，具体内容如下：
本文将这水系结构给完善一下。滴水湖的水系可以总结为六个字——一湖四涟七射
四涟是环绕着滴水湖的四条环形河道。由内而外分别叫做
其中春涟河需要位于环湖二路和环湖三路之间。河道相当之宽，环境也整理的非常好。
围绕着这个春涟河，建立了非常多的公园。其中上海市天文馆就在春涟河旁边。
而夏涟河和秋涟河则位于环湖三路之外，这才是真正的进入住宅区，烟火气息就会突然间增加非常多呀。上一次去欧景小镇看的打铁花，就在河边，很好呀。
冬涟河为他人提醒之后才出现的。
七射，连接滴水湖的七条直线河道。
赤橙黄绿青蓝紫，谁持彩练当空舞。
——《菩萨蛮·大柏地》
由于七射与七种颜色对上了，所以就按照这其中颜色来命名这七条河流。以正北为0°，并顺时针旋转，这七条河流的角度（初略估计，结果取整）分别是。
为什么赤风港角度位于东南呢？我发表出我的猜测：东南为巽卦，表示风；正南为离卦，表示火。两者组合才一起，正好是赤风港呀。
此外，橙和港+蓝云港的连线，将滴水湖一份为二。
为什么左上区建设的那么快呢？因为东北方是上海市区呀。目前的主要人流也都集中于这左上区。
在路上骑车的时候，发现位于河上的桥名是非常有特点的。
位于涟河上的桥，和春夏秋冬相关。
位于七射上的桥，桥名与颜色相关。而且滴水湖湖边的七座桥，晚上的灯光都会有一定的特色的。
不过上面仅仅是一些相关性，有些桥名还与道路相关。
这是对于滴水湖水系的梳理，感觉设计的时候非常用心呀。
如果你的城市设计有对应的内容，欢迎交流呀。
参考内容
2026-05-07 07:00:23
本文中提到的内容已经放置于github仓库了：how to write skills
在 AI Agent 开发中，Skill 是一个被严重低估却又极其重要的概念。它不是一份普通的说明文档，而是一个面向特定任务域的能力封装——通过明确的触发描述、结构化的操作指令和必要的附属资源，让模型在某类任务上表现得更稳定、更专业、更一致。
写好一个 Skill，本质上是在回答三个问题：
如果你正在纠结"如何写出一个结构正确、可触发、可维护的 Skill"，这篇指南就是为你准备的。
网络上有非常多教你撰写Skill的方案，但是不够深入。为了撰写一份能够良好的Skill，本人研读了Anthropic的Skill仓库（仓库网址为https://github.com/anthropics/skills）
在动手写之前，必须先理解 Skill 的天然分层结构。这决定了"什么内容应该放在哪里"
| 层次 | 名称 | 加载时机 | 内容 | 作用 | 原则 |
|---|---|---|---|---|---|
| 第一层 | Metadata | 始终可见 |
name + description
|
始终参与触发判断，决定 Skill 能不能被正确命中 | 触发信息必须放在 frontmatter，不能藏在正文里 |
| 第二层 | SKILL.md 主体 | 触发后加载 | 主流程、关键规则、输出要求、分支策略 | Skill 被触发后的核心工作指南 | 只保留"始终该读"的核心内容 |
| 第三层 | Resources | 按需读取 |
references/、scripts/、assets/ 等 |
复杂场景的补充资源 | 长内容、重复内容、确定性内容放在外部资源 |
Skill的触发信息放在 frontmatter，核心工作流放在 SKILL.md，其余内容按需外移。
Skill 不是越大越好，而是要匹配当前的复杂度阶段。研读了Anthropic的Skill仓库（仓库网址为<https://github.com/anthropics/skills）之后，本人总结出三套Skill模板。按照流程不断变化，重要的事情说三遍：
本文中提到的内容已经放置于github仓库了：how to write skills
本文中提到的内容已经放置于github仓库了：how to write skills
本文中提到的内容已经放置于github仓库了：how to write skills
最小结构：
skill-name/
└── SKILL.md最小 frontmatter：
---
name: skill-name
description: 说明这个 Skill 做什么，以及在什么场景下应该优先使用它。
---最小正文骨架：
# Skill Title
一句话说明目标和适用范围。
## Process
- 第一步做什么
- 第二步做什么
- 遇到例外情况怎么处理
## Rules
- 哪些边界必须注意
- 哪些行为不能做
## Output
- 输出长什么样
- 如果没有固定格式，也要说明输出重点skill-name/
├── SKILL.md
├── LICENSE.txt
├── references/
│ ├── overview.md
│ ├── variants.md
│ └── examples.md
├── scripts/
│ ├── helper.py
│ └── validate.py
└── assets/
├── template.md
└── sample-output.txtskill-name/
├── SKILL.md
├── LICENSE.txt
├── references/
│ ├── overview.md
│ ├── domain-a.md
│ ├── domain-b.md
│ ├── rules.md
│ └── examples.md
├── scripts/
│ ├── validate.py
│ ├── transform.py
│ ├── generate_report.py
│ └── utils.py
├── assets/
│ ├── templates/
│ ├── samples/
│ └── static/
├── agents/
│ ├── reviewer.md
│ ├── analyzer.md
│ └── comparator.md
├── evals/
│ └── evals.json
└── docs/
├── design-notes.md
└── changelog.mddescription 是 Skill 能否被正确触发的核心。写差了，Skill 就很难被命中；写得过泛，又容易与其他 Skill 冲突。所以，一个合格的 description 至少要包含：
下面给出一个推荐公式：
用于 [目标任务]。当用户提到 [典型表达 / 典型场景 / 相近需求] 时，应优先使用此 Skill，即使用户没有明确说出 [关键词]。反例：
用于处理文档。正例：
用于撰写和整理结构化文档。当用户提到 PRD、技术方案、设计文档、决策记录、规范说明，或表达出"帮我把想法整理成正式文档"的意图时，应优先使用此 Skill，即使用户没有明确说出"文档模板"或"需求文档"等术语。写 Skill 时，最常见的问题不是"不会写"，而是"内容放错层"。下面是直接可用的放置规则
下面给出一份我研读后的Skill结构。
内容如下：
---
name: my-skill
description: Explain what this skill does and when it should be used.
---
# My Skill
## Overview
说明这个 Skill 解决什么问题，适用于哪些场景，不适用于哪些场景。
## Process
按阶段说明推荐流程：
1. 先做什么
2. 再做什么
3. 遇到分支时如何判断
## Rules
写关键约束、边界、异常处理和质量标准。
## Output Format
如果输出有稳定结构，在这里给出模板。
## References
说明什么时候需要读取 references/、scripts/、assets/ 中的哪个文件。推荐按以下顺序扩展，而不是一开始建满所有目录：
这样的话，你才可以更好的阅读出内容呀
写完一个 Skill 后，至少检查5个内容
以下问题在撰写 Skill 时最常见：
如果你要新写一个 Skill，可以直接按下面的策略执行：
2026-05-06 21:53:12
在软件开发领域，需要写文档，说明软件的开发流程和细节内容。特别是和AI聊天的时候，以文档为中心的话，以文档来进行，工作开展起来就会非常顺利的呀。上个月之前开发“学位论文审查软件”过程中发现利用文档与AI交流，效率能够快非常多呀。
既然写这个，那么就需要指导软件开发全流程中都有哪些类型的文档，各自解决什么问题：
| 文档类型 | 英文名称 | 核心用途 | 适用场景 |
|---|---|---|---|
| 需求文档 | Requirements Document | 做什么，不做什么，验收标准 | 所有需求都需要 |
| 技术方案/设计文档 | Technical Design Document | 怎么做，为什么这么做，风险点 | 复杂需求、技术选型 |
| 计划文档 | Project Plan | 什么时候做完，谁来做 | 项目排期、里程碑 |
| 接口文档 | API Documentation | 接口定义、参数、错误码 | 前后端联调、服务对接 |
| 数据字典 | Data Dictionary | 表结构、字段含义、索引 | 数据开发、问题排查 |
| 测试文档 | Test Documentation | 怎么测、测了什么、结果如何 | 质量保障 |
| 部署手册 | Deployment Manual | 上线步骤、回滚方案 | 发布上线 |
| 运维手册 | Operations Manual | 告警处理、故障排查SOP | 线上维护 |
| 变更日志 | Changelog | 版本改动、兼容性说明 | 版本升级 |
| 代码规范 | Coding Standards | 命名、格式、提交规范 | 团队协作 |
| README | README | 项目简介、本地启动 | 新人上手 |
| 贡献指南 | Contributing Guide | 提PR流程、分支策略 | 多人协作/开源 |
| 会议纪要 | Meeting Minutes | 决策记录、待办事项 | 评审/讨论会 |
| 事故复盘 | Postmortem Report | 根因分析、改进措施 | P0/P1故障 |
| 安全合规文档 | Security Compliance Document | 权限、敏感数据处理 | 合规要求 |
将其绘制成一张图片，可以见下图（图片由Dall 3生成）
上面一共列举了15份文档，其中对于一个小团队来说，需要的文档为8份（图片由Dall 3生成，本人进行了部分修改）
如果是个人项目的话，根据个人需求来部署。
如果是5-15人团队：8份全部落地
如果是大型的复杂业务复杂，那就再加2份
法则1：文档和代码同生命周期。需求变了，文档跟着更；代码改了，接口文档跟着更。宁愿不写，也不要写了之后一直不更新。
法则2：轻量优先
法则3：就近原则
法则4：谁负责谁写
法则5：善用工具与AI
文档的本质是信息沉淀，目的是降低未来的沟通和协作成本。
中小团队的最佳实践就是：只写能解决实际问题的文档，每份文档控制在一页纸起步。
8份文档说多不多，但覆盖了从需求到上线全流程的关键节点。真遇到问题，你会感谢当初留下这些文字的自己。
参考内容
2026-04-30 00:47:00
上周发现自行车外胎有了深深的裂纹，想起来这外胎都是两年前买的了，上淘宝买两条散装的马牌 GrandSport Race（主要是散装的比盒装的便宜呀）。
昨天到了，于是今天把自行车搬到家中，准备更换轮胎。
轮胎更换完成之后，顺手清理了一些自行车的传动系统。
当我将链条、牙盘、飞轮清理完毕之后，看着重新露出来的银色，心里会有一种很安静的满足感。
（链条油是加在链条上的，而不应该滴在飞轮上；链条上的黑色油污是链条油 + 灰尘的结果；没有链条清洗剂，链条上的油污是擦掉的呀）
这种感觉有点微妙。好像平时一直看着它脏，也不是不能骑，于是就总觉得可以先放着，等以后再说。可真正动手清理的时候才发现，很多东西并没有坏掉，它们只是被忽略得太久了。洗干净以后，那种“恢复原样”的感觉，反而比买一件新东西更让人踏实。
清理自行车的时候，我也在想，生活里大概有很多事情都是这样。看起来乱一点、旧一点，好像也能继续过下去，但那些没有处理的小问题，其实会一点点堆在那里。秩序不会自己回来，很多事情还是要靠人慢慢整理。
相关内容：