使用的 SKILLS 以及生成的小说：novel-skills

现阶段 AI 在各个领域都得到了广泛 的应用。AI 很能好地保证产品的下限，但若不深度参与，仅靠 AI 自动驾驶还是难以产出优秀的作品。现阶段 AI 更多的能担任辅助角色，全功能的 AI 只能寄望于其进一步进化。

用 AI 写小说是我探索其能力边界的一次尝试。从产出来看结果不算理想，不过整个过程还算是有趣。

SKILL 编写流程

Skill 的编写也是一个循序渐进的过程，下面是这个 Skill 调教的一个大致过程。

1. 先按照自己的理解给定基础框架，然后让 AI 帮助完善细节。该阶段可借助 Copilot、Codex 等工具辅助进行 Skill 的编写。
2. 让 AI 使用 Skill 开始按章进行写作。观察 Skill 的工具调用情况，了解 AI 是否有按照预定的流程进行工作，有哪些流程可以优化。对于未按预期执行的步骤，调整 Skill 加强约束。
3. 查看产出的小说摘要文件，完善 Skill 摘要生成的约束。
4. 随着小说长度的增加，摘要文件持续增加。密切关注摘要内容的变化，及时修改 Skill 调整摘要以适应小说的创作。

小说创作 SKILL 的设计

• 大多 AI 模型只有 128K 的上下文，换算成中文字符大约为15万。要加上系统prompt、控制字符、对话历史等，实际留给小说的上下文远低于这个数。为了让 AI 对完整剧情有所了解，必须将小说内容先总结成摘要再喂给 AI。
• 过于简洁的摘要会让 AI 缺少必要的信息，导致剧情不连贯甚至矛盾。过于详细的摘要不但会导致上下文超限，更会分散 AI 宝贵的注意力，适得其反。可以说摘要设计是这个 SKILL 设计的核心难点。
• 设计初期考虑使用图数据库、向量数据来辅助 AI 理解小说情节。实际操作下来发现对于小说创作而言，经过合理设计的 Markdown 已可以很好的满足需求。引入数据库反而是在自找麻烦。
• 小说的摘要按照树形结构进行组织。
  • 小说总纲，里面包含小说总体的剧情简介以及完整章回简介。总纲里的章回简介只包含标题和一句话简介。每章的具体摘要放在独立文件中。每章的具体简介里包含关键剧情，情节伏笔等。
  • 角色小传放在单独文件夹里。角色索引文件里将角色分为主角、配角、组织等，并给各角色一个简要介绍。每个角色的详细介绍放在独立文件中。角色详细介绍包括人物性格、和其他人物关系以及关键剧情介绍等。
  • 世界观设定也有独立的索引文件。索引文件中包含简要的世界观介绍。核心场景、关键设定有自己独立的设定文件。
• 摘要的维护和使用。
  • SKILL 里明确要求每章完成后必须对相关的摘要文件进行更新。
  • 最初设计是让 AI 根据情节需求自己决定需要读取哪些摘要。实际使用过程中发现 AI 经常漏读关键内容。对轮工具调用不但费 Token，速度还慢。考虑当前的章回数还不是很多，因此写了个 tools 一次性加载所有摘要。注：最初想设计成 SKILL 的 Script，但其执行前会做很多环境检查，使用体验不佳。
• 当前 SKILL 需要改进的地方。
  • 现在的摘要有些太“啰嗦”，随着作品长度的增加很容易超过上下文限制。需要进一步优化摘要约束，只保留重要内容。
  • 在作品长度增加后一次性加载所有再要摘要将不再可行，需要回归按需加载。需对摘要加载工具进行调整，一次性加载必要的摘要文件。然后在 SKILL 里给出详细的按需加载指导。
  • 设计初期没有考虑分卷问题。每卷也应当有各自独立的摘要，利用该摘要来指定本卷的创作方向。
  • 需要设计 checklist 列表，避免出现伏笔丢失，人物去向没有交代的问题。

小说完成情况

1. 已完成 10 万字左右，总共24章。
2. 小说名字： 《他们都劝我冷静，然后我疯了》 发布在番茄小说。通过 签约认证 ，未通过 作品推荐 审核。
3. 由于让 AI 写小说的主要目的是验证 AI 能力，近期应当不会继续更新。

小说创作系统搭建

1. 使用 LangChain Deep Agents 作为 Agent 开发框架。
2. 小说创作知识通过 SKILL 提供。
3. 通过 tools 为平台提供图数据库读写等额外的能力（未实际使用）。

遇到的问题以及解决方案

根据我的最初预想，小说的摘要及人物小传等知识使用层次化的 Markdown 来存储，方便人工审阅。人物关系等信息通过图数据库存储，并通过向量数据库提供前期剧情的搜索。实际使用过程中发现，图数据库和向量数据库的使用必须给定详细的规范，如果只提供基础的读写接口，AI 无法很好的利用数据库能力来辅助写作，引入的问题远高于解决的问题。此外良好的 Markdown 结构设计已足以支持小说写作。

当使用一个工具时，该工具的所有知识需要加入到对话的上下文中。如果 Agent 用到的工具很多，且这些工具都有详细的使用知识，则会占用很多宝贵的上下窗口。为了解决该问题可以将这个工具作为独立的 SubAgent，将工具使用的详细说明放到 SubAgent 中。

Deep Agents 默认提供了文件读写工具，通常情况使用该工具实现文件读写即可。但在明确要求加载 outline 目录内设有知识的情况下依旧会根据自己的判断只加载部分文件。似乎在上下文过长时 AI 的遵从性会下降（注： AI 所使用的 Transformer 本就是 注意力机制 ，AI 和人一样，内容多了就容易丢失重点）。

为了保证摘要的完整加载，同时文件分别加载所带来的 AI 多次决策问题，需要提供一个一次性加载所有摘要知识的接口。尝试在 SKILL 里增加加载摘要的脚本。可能是出于安全等问题的考量， Deep Agents 在执行脚本前会对脚本做非常多的检查，即使在 SKILL 里明确要求直接执行也无法避免。最终将该脚本封装成 LangChain 的工具。

阿里百练平台为每个模型提供了 100 万免费 token。使用过程中发现只进行了几轮对话一百万 token 就会耗尽。后切换到 DeepSeek。DeepSeek 应当是主流 API 里最便宜的了，如果缓存命中，每百万的输入0.2元。对于小说写作任务，有着大量的缓存命中。随着章节的增加，写一章小说的 Token 消耗会持续增加。写到20章时，写一遍，再审阅一遍，一章花费1～2元。

OpenClaw 本质是一个带记忆模块的Agent管理工具，并通过 IM 的集成极大增强了用户体验（虽然现阶段依旧是个玩具）。或许 OpenClaw 这样可以通过 “记忆” 持续学习并可以通过 SubAgent 分工合作完成任务的 AI 工具会成为今后一段时间 AI 的发展方向。

为了探索 AI 能力的边界，开了一个试验性项目 Sequoia 。Sequoia（红杉）世界上最大的树，寓意一颗小小的种子终有一天可以长成参天大树。

AI Agent 框架选型

为了方便验证想法，因此希望框架可以帮忙完成MCP/SKILL调用、交互界面、SubAgent创建等大部分常规工作。这样我可以聚焦记忆模块和关键工具模块的设计。同时尝试通过prompt让 AI 自己决定如何来使用这些工具。在研究过主流AI开发框架后最终选定了 LangChain Deep Agents。下面是考虑的一些框架。

Pydantic AI

可以说 Pydantic 是 Python 界数据校验框架的事实标准。在很早之前就简单了解过 Pydantic AI，Pydantic AI 的 API 也算是比较易用。但实际使用过程中发现 Pydantic AI 的 SubAgent 管理功能非常弱，涉及 SubAgent 的操作会很不方便。且 Pydantic AI 没有配套的 UI，想要一个易用的交互 UI 得花不少功夫。

CrewAI

CrewAI 是个多代理编排框架。强项是 SubAgent 的协同管理，可以轻松实现多 Agent 协同。CrewAI 的发展势头不错，且非常易用。不过 CrewAI 的记忆模块和框架深度绑定。由于我想探索如何精确的管理 AI 的记忆，因此放弃。

LangChain Deep Agents

LangChain 是使用最为广泛的 AI 框架，拥有完整的生态。Deep Agents 是 LangChain 团队推出的 Agent 框架，可以完美的融入 LangChain 生态。记忆模块作为独立组件，可以方面用户自行扩展。可以使用 Agent Chat 和自己的 Agent 交互，免去了 UI 的相关工作。

项目现状

目前搭建了基础的项目框架。利用 Deep Agents 框架本身能力提供了 SKILLS支持、SubAgent 管理、本地文件读写等功能。

按照我的预想，记忆应当通过“文本+图数据库+向量数据库”共通管理。为此我自己添加了向量数据库和图数据库的集成。

考虑如果一开始就将应用定位成一个带记忆，可以自主学习的完整“人”实现起来会非常困难。最初会尝试利用这个框架来写小说。

小说生功能设计及问题

小说的写作知识完全通过 SKILL 教给 AI。框架只提供文件读写、数据库读写工具，具体怎么用这些工具完全由 AI 自己决定。

AI 对于长文写作的一大难点是 LLM 的上下文长度限制。为了突破 LLM 的限制，必须将小说大纲、设定、章节摘要等信息分别保存，让 AI 在需要时再自行加载。

尝试用 AI 生成了一篇小说的前两章（使用 qwen3-plus）。似乎 AI 对指令的依从性不是很高。虽明确要求使用图数据库保存人物关系等信息，但在我主动要求前没被触发。明确强调了要读取 outline 目录下所有文件，AI依旧会根据自己的想法只读部分内容。

Token 的消耗速度非常惊人。没跑几次就把 qwen3-plus 赠送的 100 万 token 用完了。随着文章长度的增加，上下文长度会持续增长， token 的消耗量也会快速增加。根据最新情况，写完一章后再手动让 AI 审阅一遍 100万 token 就花光了。

后续应当会一边调整 SKILL 一边不定期更新。

小说链接：《他们都劝我冷静，然后我疯了》

py-cggtts 是一个为高精度时间传递领域打造的 Python 工具包，它基于 Rust 编写的高性能 CGGTTS 库（GitHub 仓库），提供了对 BIPM CGGTTS 2E 格式文件 的完整解析能力。CGGTTS（Common-View GNSS Time Transfer Standard）是由国际计量局（BIPM）制定的标准格式，广泛应用于全球守时实验室之间通过 GNSS 卫星进行远程原子钟比对。

项目背景

CGGTTS 本身是纯文本结构，解析起来并不困难。不过 Python 性能一般，且已经有了 Rust 的完整实现，于是尝试将 Rust 的 CGGTTS 库导出 Python 接口。目前将 Rust 导入 Python 生态的技术已经成熟，不少 Python 库都通过 Rust 来提升性能。

项目的主要代码都由 AI 完成。对于接口封装这类本身不复杂但又繁琐的工作，在 AI 的加持下变的轻松加愉快了。

在线阅读： https://vicalloy.github.io/the-guiyou-version-of-dream-of-the-red-chamber/

下载 PDF/EPUB： https://github.com/vicalloy/the-guiyou-version-of-dream-of-the-red-chamber/releases/

国内下载地址：PDF / EPUB

《吴氏石头记增删试评本》，或《癸酉本石头记》，简称“癸酉本”，是通过互联网流出的所谓《红楼梦》旧抄本，其真实性遭到广泛质疑。2008年，网民何莉莉（化名，男性）将癸酉本后28回内容委托刘俊俊（化名，即金俊俊）上传至网络，声称此本为祖父母偶然得到，并由自己和几个表妹抄写过，原本已遗失。

癸酉本文风粗砺，却又高度契合判词与伏笔。不少情节粗看骇人，回看却又合乎情理。

癸酉本的真伪，目前尚无定论。就个人而言，该版结局符合我对名著的“审美”，特创建了这个仓库，方便大家阅读和审阅。

另推荐大家收听红楼梦的有声书。前80回推荐“白云出岫”的红楼梦原文朗读。后28回推荐“鹤鸣小音”的癸酉本石头记后28回。

游戏地址：https://github.com/vicalloy/apple-guardian

小时候练打字的时候玩的最多的是小霸王上的一个空中掉落字母掉打字游戏。
最近看到很多宣传 Cursor 的帖子，另外字节也出了个类似的编辑器 Trae ，于是试着用 AI 编辑器将这个游戏复刻。

项目的大部分代码使用 Cursor 和 Trae 的 Agent 功能自动完成。就初步的体验而言，用自己不熟悉的开发框架写一些小东西 Cursor 这类的 AI 工具确实很好用，少了很多查资料的工作。部分功能反复打回依旧无法正确修改，这时候是需要手动介入。另外两个编辑器的推理速度都不算太理想，特别是 Trae 经常要等挺久。

就个人而言，写玩具 Cursor 和 Trae 很棒。大些的项目还是用 GitHub Copilot 之类的插件更可控一些。

在网上收集了一些中国的人口数据，做了一个人口变化的统计图表。近年来出现了不少使用 Python 实现前端 Web 界面的工具。这次的图表使用 plotly 实现，使用 Python 做数据处理，并输出 html 图表。

项目地址： https://github.com/vicalloy/china-population
在线查看图表： https://vicalloy.github.io/china-population/

数据分析

1. 出生人口中 2016 年到达2000年后的高点，之后出生人口断崖式下降。
2. 2022 年首次出现死亡人口大于出生人口，人口出现负增长。
3. 将 20 ～ 60 岁作为劳动力。也是在 2022 年首次出现劳动力的负增长，之后还将一直持。注：养老金压力山大。
4. 2024 年幼儿园的入学人数掉的非常厉害，再过几年就蔓延到小学了。
5. 2022 年高考录取人数为 1000 万，预计之后较长一段时间都将维持在 1000 万左右。

一些预测

1. 接下来几年幼儿园因缺少生源，要关停一批。
2. 生源不足问题逐步蔓延到小学。
3. 学区房地位下降，成为房价下跌的主力。学区房快速下跌的窗口期没几年了。

股票工具。设置股票的止损点和营收点，在到达止损点或营收点时发起消息推送。提供一个简易点web服务器用于查看相关股票的当前价格。

注：

• 支持的推送平台有 Telegram / Bark 。

用法

编辑规则文件

提醒规则使用 Json 格式进行描述。编辑规则并保存为文件 rule.json 。

[
  {
    "stock_code": "sh000001",
    "stock_name": "上证指数",
    "base_price": 3200,  # 基准价格，用于计算涨幅
    "alarm_price_min": 3100,  # 止损点
    "alarm_price_max": 3400  # 营收点
  },
  {
    "stock_code": "sz000333",
    "stock_name": "美的",
    "base_price": 54,
    "alarm_percentage_min": 0.15,  # 止损点 base_price * (1 - alarm_percentage_min)
    "alarm_percentage_max": 0.15  # 营收点 base_price * (1 + alarm_percentage_max)
  },
]

启动 Web 服务器

docker run --rm \
    -v `pwd`/rules.json:/app/rules.json \
    -p 8000:8000 vicalloy/magpie:latest \
    python -m magpie server -r ./rules.json

在浏览器中访问网址 http://localhost:8000/ 。

检查股价

docker run --rm \
    -v `pwd`/rules.json:/app/rules.json \
    magpie:latest \
    python -m magpie check -r ./rules.json \
    --datasource qq \
    --bark-token $(bark-token) \
    --tg-token $(tg-token) \
    --tg-chat-id $(tg-chat-id)

可以通过设置 crontab 的方式定时执行股价的检查。

备注

• 使用 Bark
  • 请在 iPhone 上安装 Bark 客户端，并获取对应的 Token 。
• Using Telegram
  • 创建一个 Bot 并获取对应的 Bot token
  • 创建一个 Group ，并将刚创建的 Bot 添加到该Group，然后获取 Group 对应的 chat id.
    • 例如: https://web.telegram.org/a/#-1045009696 -1045009696 就是 chat id.

10 9,10,11,12,13,14 * * * sudo docker run ....

最近蓄须，每天拍一张照片记录变化，为此衍生出的项目。

1. 根据眼睛位置自动对齐照片，并自动生成视频（ gif 和 avi ）。
   • 人脸检测使用 face-recognition 。
   • 图片位置修正使用 opencv-python 。

在线体验地址 https://huggingface.co/spaces/vicalloy/GFPGAN

AI技术在图片生成领域有了不错的进展，现在已经可以通过文字生成质量不错的图片了。之前就一直想尝试用AI人脸修复将画中的人脸修复成照片，只是迫于拖延症一直未能真正动手。这些天试了一下，发现这个想法切实可行，就是修复出的效果算不上出色。

Tips

1. AI 照片修复实际上是让 AI 对图片进行自行“脑补”的一个过程，所以原图细节一定不能过多（图片一定要小，或是），不然不利于 AI 软件的自行发挥。
2. 樱木花道的输出效果不太好，再小丢失的细节又过多，因此加了个高斯模糊。注：理论上加高斯模糊比单纯的缩小图片效果要好，大家可以对其他图片试试。
3. 应当是缺少样本，外加人脸检测时，如果胡子过长截取人脸时会丢失部分胡子。古人的长须无法完整修复。
4. 过于“漫画化”的图片是无法识别到人脸的。

效果

樱木花道

唐太宗李世民

乾隆

韩熙载

宋太祖赵匡胤