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（主要是散装的比盒装的便宜呀）。
昨天到了，于是今天把自行车搬到家中，准备更换轮胎。
轮胎更换完成之后，顺手清理了一些自行车的传动系统。
当我将链条、牙盘、飞轮清理完毕之后，看着重新露出来的银色，心里会有一种很安静的满足感。
（链条油是加在链条上的，而不应该滴在飞轮上；链条上的黑色油污是链条油 + 灰尘的结果；没有链条清洗剂，链条上的油污是擦掉的呀）
这种感觉有点微妙。好像平时一直看着它脏，也不是不能骑，于是就总觉得可以先放着，等以后再说。可真正动手清理的时候才发现，很多东西并没有坏掉，它们只是被忽略得太久了。洗干净以后，那种“恢复原样”的感觉，反而比买一件新东西更让人踏实。
清理自行车的时候，我也在想，生活里大概有很多事情都是这样。看起来乱一点、旧一点，好像也能继续过下去，但那些没有处理的小问题，其实会一点点堆在那里。秩序不会自己回来，很多事情还是要靠人慢慢整理。
相关内容：
2026-04-26 07:00:34
AI现在已经走进了我们的日常，这里回顾一下我的AI使用经历
2022年就注册了ChatGPT，但是觉得太傻了——问他科研事情搞不定、编造论文内容、幻觉严重等。这么傻的ChatGPT就将其当成一个玩具来用。
到了2024年元旦，发现ChatGPT 4o觉得非常好用。
为了得到更好的回答，去研究了如何和AI进行对话。翻阅了一系列的内容之后，将学习内容整理成文档，并放置于博客。
这个阶段，我主要关注的是如何和AI进行对话。做出来的内容，需要多次进行复制黏贴呀。
2024年，开始使用本地软件。经过挑选，选择使用Cherry Studio。
利用RAG技术，将本地的文档整理成知识库。调用知识库并进而回答一些具体的问题。但是也没有发现有什么飞跃的地方。
不过最近发现鲍捷大佬能够完成这些复杂的操作，并且建立一个复杂的项目——史记知识库 - 让两千年的文字活过来
两千年来我们读《史记》，现在让机器帮我们"看见"隐藏的知识网络。
在线阅读: https://baojie.github.io/shiji-kb | Wiki: https://baojie.github.io/shiji-kb/wiki/ | 报告问题: 提交Issue （推荐截屏+paste） 许可证: CC BY-NC-SA 4.0
学术文献请引用：鲍捷，史记知识库，2026，在线发布于https://github.com/baojie/shiji-kb
——来自项目 史记知识库 - 让两千年的文字活过来 https://github.com/baojie/shiji-kb
2024年下载了Cursor，感觉当时还是编写代码的工具，写文档不好用。放弃。
2025年3月份，为了编写一个“学位论文审查工具”，专门下载了一批AI IDE工具。经过对比之后，最终选择了付费比较简单的Trae国际版。
在Trae的官方教程汇总学习之后，发现这才是我理想中AI工具——markdown文档为中心，以MCP、Skill、Agent为辅助工具，以Git做版本管理，以Obsidian做双链，以rule规则限定项目的内容。
正好自己的日记和博客都是以markdown文档，非常方便使用Trae进行管理。目前已经完全使用Trae来管理我的日记和博客内容。下面是三篇相关的内容呀：
今年3月份龙虾出来了，试用了一下放弃。很多都说要实现手机操控电脑或者服务器。那么问题出现了，为什么不用电脑来操作呀？相对于手机来说，电脑的操作更加精细呀。我的手机也就是一个非生产力工具，不想让它承担太多的功能。（毕竟屏幕太小了，干活也不如鼠标加键盘）相关的思考见下方内容：
2022.11.14 019 手机和电脑如何分工
最近Claude code更新非常快。未来思考一下将Claude code 部署在阿里云服务器上，本地调用。让Claude code的能够执行一些定时任务。
2026-04-25 23:46:10
80岁这天也是周六。按照你的人生规划，你的人生终点定在了90岁，那80岁就是倒数十年了。十年不算短，但足够让人“急”这件事放下，把“要紧”这件事拿起来。
早上，我大概醒在一个离河流或者湖泊不远的地方，有更安静、更柔和的水汽和鸟叫。房间应该是干净且简约的，必须存在三样东西：
第一，书柜：书柜中东西包括下面几类：
第二，离卦图：挂上一张大型的离卦图片。要时刻提醒自己“明两作，离，大人以明德照四方”。要保持年轻的心态，要接近“六二，黄离元吉”
第三，一台电脑（也有可能是其他的智能设备）：电脑中有所有我归档的文件。具体可参考
06:10 起床。先摸摸自己的膝盖和腰，确认今天还能“当人”。然后烧水，泡一杯茶。
07:00 读书。以前是朗诵《中庸》《大学》《论语》，现在还是读，只是更慢。读到一句觉得对，就停下来想：这句话放到今天的我身上，具体要怎么做？
08:00 早饭。一碗粥，一个蛋，一点蔬菜。年轻时你总觉得“吃得随意也没事”，80岁会告诉你：规律就是自由的一种。
09:00 出门走路。绕着水边慢慢走两圈，碰到熟人就聊天，碰不到也不慌。年轻时怕孤独，老了反而学会了和孤独并排走。
10:30 回来做一件小事：整理东西、修个小电器、把日程写清楚。以前你迷恋“干大事”，现在我更喜欢“把小事做完”，因为小事做完了，人就稳了。
12:00 午饭。饭后眯一会。睡不着也闭眼，把脑袋里的杂音关掉。
14:00 下午通常有这样几种安排：当志愿者，给小孩讲“怎么做笔记、怎么把资料整理成体系”；和老朋友见面交换“近况”和“身体”，偶尔也会笑年轻时的傻劲儿——笑完之后，更懂得珍惜；最后是骑车，骑车出去转一转外面的风景。
19:00 晚饭。饭后散步。路过广场舞队伍时，我偶尔也会被拉进去，动作不标准，但气势要到位——你看，我也算当过一次“广场舞霸主”，只不过霸主的意思是：敢上去、敢笑、敢不在乎别人怎么看。
21:00 写日记内容。让生活中的日记完善好呀。
爸妈已经不在了。我在2035年后将他们一一送走。身边还有家人：伴侣、孩子（也可能已经有了他们自己的家）。朋友不多，但够用。留下来的都是那种：平时各忙各的，有事一个电话，能在力所能及的范围内搭把手的人。
我见到2026年的你，最想送你两样礼物。
第一样叫“别急”。你现在很想把很多事一口气做完：论文、专利、立项、补贴、读书、锻炼、写作、陪伴……我知道你焦虑，也知道你有野心。但真正能把你送到80岁的，不是某次冲刺，而是几十年如一日的规律：睡够、动起来、持续学习、持续记录、把重要的事死磕到底。
第二样叫“别省”。不是别省钱，是别省在亲情和身体上。你以为以后还有很多次见面、很多顿饭、很多次出门，80岁的我会告诉你：次数是有限的。能陪爸妈走一段就多走一段；能把话说清就趁早说清；能早睡一天就早睡一天。你省下来的那点时间，最后往往会以更贵的方式还回去。
遗憾的事情有很多，但是最遗憾的事情是你成长环境中很多习惯、技能、思想、思维等都是在你上了大学之后逐步学会的，如察觉别人情绪、观察周围细节、思维高度等，这让你在前期显得傻傻地、呆呆地，进而损失了很多机会。但是也正是你这种一无所有学到现在，你才能够整理出一系列的文档作为家学进而传承进去。正符合“究天人之际、通古今之变、成一家之言”。下面列举几个你思考的内容呀
因为你在2017年就开始用日记和复盘把人生“拧紧”，开始把“人生终点”当作现实边界来规划，开始练习“明两作，离”的那种清醒——少而好学，如日出之阳。你继续这样走下去，80岁的我会很感谢你。
相关内容