The Very First Blog: 为什么要有一个博客
Posted on :: Life

为什么要有一个博客呢？我一直（断断续续地）保持着写日记的习惯。那么，为什么要有一个博客呢？

Slay the Spire Bot

2025 年 12 月，我去了 BGM 游戏展会，在展会上我玩到了 TC 的回合制卡牌游戏（丰饶女神之骰）。我萌生了一个想法，大模型也许可以用来做游戏测试。我的想法是：对于回合制游戏来说，LLM 无法给出游戏的趣味性的评价，但如果 LLM 可以做到一个 “普通玩家的智力水平” 的游玩的话，那么就可以用来做平衡性测试。LLM 至少可以给出 “大部分普通玩家能游玩到什么地步” 的答案，也能详尽地记录数据。在“末日大锄地”的开发经历中，我认为测试玩家很难获得，但是 LLM 可以一直跑。

最近这两年我虽然总是被新闻刷屏，但是我几乎没有碰过大模型。在此之前，我的相关经历只有：

  • 在 ChatGPT 推出之后，我曾经搭建过一个 slack bot 来进行问答。
  • 在 2023 年 11 月左右，玩了 完蛋，我被 LLM 包围了！，这游戏太有意思了。
  • 2025 年 9 月份之前，我还在上班的时候。公司号召用 GitHub Copilot 写代码。但是我和同事们普遍的感受是，模型写的不够好，能生成一些好的函数，也可以 tab 补全一些内容，但是无法大规模地处理问题。

我和 TC 讨论了一番，认为 slay the spire 是一个好的选择——游戏经典，数据量大，社区活跃。因此我开始着手搭建一个利用 LLM 自动游玩的 slay the spire 机器人。我非常活跃地开发了 3 周，最终的 repo 在这里：Hikaru518/slayTheSpireBot。

AI 编程已经这样了吗

在开发的初期最让我惊讶的是，AI 写程序竟然可以这么快又这么好。我使用的是 Cursor。只要描述清楚需求，那么代码就能自然产生出来。我一边和 Cursor 聊天一边写代码。

一开始我会盯着 ai 进行细致的 code review，例如变量名、类的抽象级别等。但是很快的，我就不再关注任何代码细节了。至少针对这个项目，我认为我需要的是：1. 想清楚我应该如何验证每个任务的产出。2. 如果我要控制的是项目的进展和方向，那么我就需要很清晰的 PRD 和 tech design。

自然而然的我就朝着 spec driven development 的方向去了。我划分了版本，确定每个版本要做什么，会花很长的时间和 ai 讨论 prd 和设计，然后拆分成子任务。而对于子任务的实现我基本上不太关心。我只需要关心测试，有时候是单元测试有时候是功能测试。

仅仅有 Prompt 是不够的

我在开发这个 LLM Bot 的时候，我的想法很简单也很单纯：我需要设计一个好的 prompt。

开发前我进行了一些调查。我了解了一下 LangChain 等项目。我也知道 ReAct 的 Agent 设计模式。但是我最终没有使用，我当时的想法是这样的：

  1. 我不应该用 ToolCalling。很多 LLM 应用需要进行 Tool Calling，这是因为上下文不完整。例如一个客服机器人，他得上来先问用户需要什么，这是它并不清楚用户的意图所以无法决策。而作为一个游戏机器人，所有的信息我都已经掌握了，我只需要
  2. 上下文限制我不会遇到。我当时高频使用的 DeepSeek 上下文有 128k，我估算了所有信息，大概也才只有 5k。即使再多一倍信息也够。

相反，我采取了最简单的做法，我应当收集所有的信息，然后塞到一个 prompt 中，反正 LLM 本身也是没有状态的，本来就非常适合回合制。Slay the spire bot 的重心应该在构建 prompt 的工程问题上，例如：如何获得和结构化流派数据、LLM 到底需要知道哪些游戏数据、怪物的属性应该怎么获得、每个怪物的 AI 策略应该是如何的。

总的来说，我的做法是把这些知识分层，对于每个 prompt，会有以下 4 部分构成：

  1. 静态层（利用了 Cache 机制）。
    • 这里面都是静态内容，包括游戏规则，bot 可以查阅的资料。
    • 例如：关键词效果说明、每个 buff/debuff 的效果、流派策略等等。
    • 这里我并没有采用所谓的“渐进式加载”策略，而是把所有的内容都放到了 prompt 中。
  2. 记忆层。有短期记忆：房间内发生了什么，最近几轮干了什么。也有长期记忆：当前的卡组策略是什么，当前的地图位置、接下来会遇到什么。
  3. Game State。游戏数据。例如战斗中就会有卡牌信息、玩家血量、可采取的行动等。
  4. Game State 相关的动态信息。例如遇到的怪物的技能、AI 策略等。

总而言之，我构建了一个巨长的、但是又很精巧的 prompt，但我当时还是认为，这没关系，反正还没到 128k 的限制。

最终的效果，这个 Bot 的项目在使用 DeepSeek 3.2 的情况下，能够比较稳定地跑到 A0 的第二个 Boss。但是第二个 Boss 是打不过去的。我用了一些其它的 bot，glm 4.7 在构筑牌组的时候很有想法，但是总是会陷入无限循环。qwen3-max-preview 和 DeepSeek3.2 差不多但是价格太贵了。我没有尝试更贵的模型。

我对着这个非常大的 prompt 调试了好久，因为我至少期望它可以通关 A0。但是随着我的研究我发现了一个 Context Rot 的现象，在长上下文中模型表现会很差。我的上下文有时会达到 10k，信息量又极大。而且一旦有一点点信息丢失，都是导致致命的问题（例如忘记一个规则，或者没有弄明白一个 buff 导致没有斩杀）

但是此时我有一种恍然大悟，仅仅有 prompt 是不够的。社区中的各种应用也肯定是出于各种各样的类似的原因，谈论的焦点逐渐从 Prompt Engineering 转向了 Context Engineering。

我一开始很沮丧，这都 2025 年了，我还搁这儿用 ChapGPT 刚出现的时候的办法在写程序，为什么我一开始没有意识到呢？但是现在我觉得，The proof of the pudding is in the eating，Slay the Spire 是一个很好的载体（或者说是 Benchmark），他至少让我获得了

  • 我理解了现在的大模型智能水平。
  • 我在这个过程中了解了大模型的机制（无状态，重视缓存等）。
  • 进行了很多的工程化实践。例如我 somehow 自己实现了某种程度的记忆系统。

我一直犹豫要不要重新重构 Slay the Spire Bot。虽然没有能够通关 A0，但是能够到 Act2 我认为也还算是不错的成绩，而且也算有所收获。另一方面，如果要做一个需要 context management 的内容，也许我应该去做一个别的项目。此时我脑中想的还是一个 Research Assistant（后来我才知道了 NoteBookLM）。

犹豫中我就暂时搁置了这个 Slay the Spire Bot 的项目。

Agentic Coding

搁置了 Slay the Spire 项目之后，我有一段时间没有 Coding，再之后我去了 Hustree 哈老板那里帮忙了一周的餐厅和桌游的开发。

这期间我抽空读了不少博客，让我印象比较深刻的有下面 2 篇文章，在这里也记录一下。我认为看了这两篇就懂了 Context Engineering 的 80%。

从温州 Hustree 哈老板的工作室回来之后，已经马上就到春节了。春节的时候我脑中一直有个想法：我期望可以在手机上也能写程序。既然我现在只用自然语言写代码，那么为什么我需要电脑呢？我完全在云端 host 一个机器，甚至可以是 severless 的，然后通过 SMS bot 利用我的手机写代码。

在大年初一的晚上，我在思考具体实现的时候想到：现在 Skill 这么容易编写（只需要文本），而且 Coding Agent 中的 Agent（指的是例如 Opencode Agent 这样的 Coding 软件中的 Agent 概念）也只可以通过 markdown 编写：只需要给出 prompt，然后可以说明每个 Agent 有哪些 skills。那我完全可以把软件工程的实践拆分成不同的 skills：

  • 一个 agent 加载有限个 skill，这时候一个 agent 的 context 负担不会太重，职责边界也很清晰，完全可以承担。
  • 例如有产品经理 agent，这个 agent 就是把一个用户的 idea 变成一个可靠的产品设计。
  • 又例如有一个架构师，他可以根据产品的内容做技术设计，来考虑关键的技术决策。

诸如此类，我们可以将软件工作拆分成需求、架构设计、任务划分（scrum）、开发、code review、甚至运维（用 cli 或者 mcp 就可以解决）都能交给一个小的 LLM agent。那么剩下的问题就是如何将这些 agent 调度起来。

根据我写 Slay the Spire Bot 的经验，每个 Agent 的复杂度应该是可控的。调度问题暂时可以解决。如果这真的可行，那么很多的其他工作（财务、咨询）也都可以 Agent 替代。我仿佛看到了“一人公司率领着各色职责的 agent 工作”的画面，想到这里我 literally 有一种脑子爆炸🤯的感觉。

但是等等，这真的可行吗？这相当于在用自然语言编程。自然语言是不确定的，UML 的尝试的最终发现不就是发现软件的模型就是很复杂，也许最好的软件解释就是代码本身，There is no easy way。我必须得写一写试试看，出于各种原因，我也必须有一个自己的 workflow。因此最后我写了一个项目，有了 Hikaru518/opencode-config。

关于这个项目的内容我决定在下一篇博客详细介绍。

为什么我需要一个博客？

上述的想法演变都发生在三个月之内。如果三个月之前让我想象我现在写代码的方式，我完全无法想象。

现在，马年春节还没过去，AI 是大家茶余饭后的一个热门话题。我参加多次聚会也不例外，我多次聊起 AI 这个话题。我迫切地想要和他们分享 AI 是如何改变了软件开发，未来的世界会如何进一步自动化。

在初一之前的同学/亲戚聚会中，我提了这个想法，大部分的反应大概可以归类为是：

  • 认为我被 AI 的宣传洗脑了。“不可能，这根本不可能。”
  • 同意 AI 很厉害，但是他关心的是别的事情。“诶，那是不是某个亲戚的小孩工作就难找了。”
  • 同意 AI 很厉害，但他心里想的是另一回事。“噢确实！现在 AI 写代码可厉害了。我按一下 tab 就能补全代码了。”

这些反馈导致了话题无法展开，我的想法在无法得到分享。我有一种微妙的、焦虑的感觉：这个世界将要发生很大的变化，但是周围的人却不关心。我知道我这种想法是杞人忧天，但这种感觉确实存在。

也许可以换个说法，我应该如何说服三个月前的我自己，让他明白我的感受呢？

在过年的这几天，我几乎每天都在 Coding 完善我的想法。这期间我几乎没有和别人聊过这个话题，但是我特别想要和别人分享。直到 4 天前的 2 月 21 日，我和 ps、zzq 在杭州聚会，我们聊完家常之后，我谈起了 ai，我说完了所有的想法，并且 ps 也经历了一次 “wow” 时刻。

说实话，分享的感受非常好。这件事让我认真思考“我需要一个地方来展示我的想法”。我希望可能在某个场合——也许是微信上和朋友聊天，或者是某个聚会，又或者是互联网上的陌生人——我可以这么说： “哇，这个太帅了，我有一个想法，来看看！”，然后我发送了我的博客文章链接。

以上就是我建立这个博客站的初衷。也让我以此为契机来记录一下过去的三个月。

那么，博客里会写什么

我认为大概率有两部分

  1. 某种个人向的回顾总结。这篇文章就是其中之一。
  2. 想要分享的内容。可能是我做了某件事的感受，可能是技术相关，也可能是书评或者影评。

另外，我能保证博客中的文字都会是我写的。而不是 AI 生成或者编辑的。

一些主线相关的内容和吐槽

  1. 几天前 TC 给我发了一个用 LLM 游玩小丑牌的项目：https://github.com/coder/balatrollm，这个项目看起来就比我的 Slay the Spire bot 项目好很多，还有很棒的展示。
  2. Hustree 哈老板带我在温州吃的长人混沌真的很好吃，值得记录一笔。
  3. 关于 Agentic Coding，好朋友 Thrimbda 有一个类似的 Opencode 自动化流程项目：https://github.com/Thrimbda/legion-mind。但是我不知道他是否有类似的心路历程。

--

2026 年 2 月 25 日。

正月还没过去，祝各位新年快乐