方寸 · 诗词创作画布

这个项目是什么

方寸是一个中国古典诗词创作工具。你在格子里填字，它实时告诉你平仄对不对、押韵对不对、哪个位置出了问题、应该押哪个韵部。韵书、词谱、对仗联想、典故检索全在同一个页面里，不用跳转。写完之后一键导出精美图片，发朋友圈或小红书。

Web 端部署在 Vercel，Android 端用 Chaquopy 把 Python 后端塞进了 APK，全离线运行。格律检测引擎已经拆分为独立服务开源。

从 2 月首版上线到现在，迭代了 20+ 个版本——v1.0 格律校验和韵部查询，v1.3 导出图片，v1.6 接入 80 万首历代诗词库，v2.0 组诗和自由诗，v2.1 导出主题扩展到 33 款。

为什么做这个

大家平时写诗用”搜韵”，但搜韵的每个功能都是独立页面——查词谱一个页面，查韵部一个页面，查平仄又一个页面。填一首不太熟悉的词牌，我的流程是：搜韵查词谱 → 截图 → 微信发给自己 → 在下面对着填 → 遇到词穷或者韵部不确定时重新打开搜韵搜索 → 搜完再切回来。

当时调研了社团里写诗的同学，大家用的五花八门：手机备忘录、一款已经停止维护的填词 App、纸笔古法手搓、甚至微信聊天框。没有一个趁手的工具能打造”心流级”体验——写一个字就立刻知道对不对，不用离开当前页面就能完成所有操作。

我自己写诗，是自己产品最忠实的 0 号用户。

我做了什么

格律检测引擎

核心问题是怎么表达格律规则。一首格律诗是若干联的组合，每联有多种合法的平仄变体，押韵还有首句允许邻韵的宽限。很多初学者用自然语言都搞不明白格律的具体规则——穷举法不是不行，只是让诗的规则膨胀大概 16 倍，而且缺乏可解释性。

最终设计是一棵 AST：用 SAME_CATEGORY、RELATION、AND/OR 节点组合出所有格律规则。诗 16 条，词 2500+ 条。这个方案是和 Gemini 聊出来的——我提需求，把格律的规则拆明白，它提供技术路径。AST 的好处是既清晰，又具备可解释性：可以翻译成人类可接受的规则描述，反哺格律教学。

后来把检测引擎拆成了独立服务（checker.sjtuguoxue.space），因为之前格律检测从主站复制了一份到方寸，写论文时又复制了一份，三个项目里的 checker 各自 drift，可维护性太差。现在所有下游统一依赖一个服务，改一处全生效。拆分的边界很清楚——它叫”格律检测”，音韵数据跟着走，释义和词库留在主项目。

导出图片

一开始关注点在”服务于写”，后来发现创作和发布是一条完整链路。社团主要在微信群和小红书活跃，图片是最好的传播媒介。做了 33 款导出主题，叫板”一言 App”——那个 App 是大家常用的出图软件，但会员要 30 块。

主题大部分是和 Claude 协作的，但有几个例外：金乌是用户提需求（“金乌坠地是什么颜色？”），西湖主题是从我自己的感受里生发出来的——一株杨柳一株桃，铺垫了我文学创作的开端，也承载着一些以前的感情故事。我做了埋点，天天看 dashboard，特别关注大家导出图片时偏好什么主题。

发现大家特别喜欢方寸出的图之后，又做了一个历代诗词基建（shi.sjtuguoxue.space），支持在方寸里直接搜索并导入前人作品——80 万首诗词，自动匹配格律。这只是这个数据基建的第一个应用，以后还会有别的用处。

Android 与 WebView

以前作为用户很讨厌支付宝那种往 App 里塞网页的做法。但自己做了之后发现，对于这个量级的产品，WebView 包裹最大的好处是所有代码都是同一份 source of truth——Web 端改了，Android 端重新打包就行，不用维护两套 UI。Chaquopy 把 Python Flask 直接跑在 Android 上，词库查询全离线，格律检测走线上服务。

品牌设计

“方寸”取”方寸之间”——格子、创作空间、心境。Logo 拟态了一个”寸”字：绿横代表平声，蓝竖代表仄声，和 UI 里的平韵绿、仄韵蓝一致；红色的点是项目主题色，也象征格子里的字。当时 AI 出了几版图片都不满意，最后从一个 4×4 格子的图案里提取灵感，用 SVG 手搓的。

过程中的思考

做方寸最大的收获是理解了”工具型产品的心流”。心流不是堆功能，而是消除断裂——每一次离开当前页面去查东西，都是对创作状态的一次中断。搜韵的功能其实很全，但链路不顺畅。方寸做的核心的事是把查韵、检测、填字、出图压缩到一个页面里，让用户不用”切换上下文”。

另一个认知是关于 AI 协作。格律检测引擎是和 Gemini 聊出来的，33 款主题是和 Claude 一起调的。我的角色不是”写每一行代码的人”，而是”知道要做什么、能判断做得对不对的人”。AI 提供技术路径，我负责把领域知识拆明白、把产品判断做对。

Q&A

Q: 你怎么定义”做得好”？有什么衡量指标吗？

没有设 KPI。但做了埋点和 dashboard，天天看——特别关注导出图片大家喜欢什么样的主题。对我来说最实在的指标是：我自己写诗的时候还在用它。其次是社团里有人导出图片发到群里，用的是方寸的主题——这比任何 DAU 数字都让我高兴。做这个项目最开心的一个瞬间，就是第一张优雅的出图被保存到相册的时候。

Q: 为什么把格律检测拆成独立服务？直接放在项目里不行吗？

格律检测本来就是基础设施。一开始是主站的一个功能，方寸做的时候简单复制了一份，写 ACL 论文时又复制了一份，三份 copy 各自 drift。每次改一个 bug 要改三个地方，太痛苦了。拆出来之后，所有下游统一依赖一个服务，从主站到方寸到 CLI 到论文 demo，改一处全生效。

Q: 用 AST 表达格律规则，而不是穷举或正则，是怎么想到的？

和 Gemini 聊出来的。我的算法背景不强，但我很清楚格律规则的结构——变体、邻韵宽限、换韵。穷举不是不行，就是不优雅：诗的规则会膨胀 16 倍，而且丢失了可解释性。AST 的好处是它可以翻译回人类能理解的规则描述，甚至可以反哺格律教学——我写过一个讲这个算法的 slides，虽然讲座还没开成。

Q: 导出图片成了核心吸引力，这是你预期到的吗？

是预期到的。社团主要活跃在微信群和小红书，图片是最好的传播媒介，也能很好地传播品牌。但没预期到的是它在和”一言 App”的对比中成了卖点——一言的会员要 30 块，方寸免费，而且主题更有古典意境。33 款主题里，金乌是用户提的需求，西湖是我自己的私人情感，其余大部分是和 Claude 一起从色彩理论到 blob 布局调出来的。

Q: 做这个项目之前和之后，你对”工具型产品”的理解有什么变化？

之前觉得工具就是功能的集合——有格律检测、有韵书查询、有词语联想，功能全就行。做完之后理解了”心流”才是核心。搜韵的功能比我全得多，但大家写诗的时候还是要截图发微信。差距不在功能，在链路——每一次页面跳转都是对创作状态的中断。方寸做的最重要的事不是”加了什么功能”，而是”减少了多少次上下文切换”。