评估一下这两种方案，找一下目前是不是没有这样的anki插件

回复 群友 1953： 先说我对这两种方案的理解，免得评错对象。方案 A：fork Anki 源码、建自己的 anki 分支，把这个仓库整个交给一个 agent harness（Claude Code / Pi / Codex 这类），"想要啥就跟 AI 说"，改的是 Anki 本体。方案 B：不动 Anki，写一个 addon 挂在 Anki 进程里，靠 monkey patching 直接覆盖 aqt / pylib 的函数，agent 生成和修改的是这个 addon。 评估方案 B，它的优势很实在。 零构建成本：官方二进制照用，官方升级、AnkiWeb 同步、AnkiDroid 和 AnkiMobile 全都在。addon 跑在 Anki 自己的 Python 进程里，import aqt、import anki 随便用，能挂 hook、也能覆盖函数——Anki 官方文档里就有一页专门讲 monkey patching 和 wrap，说明这是被承认的扩展手段（原文也写了 "不要长期依赖，很脆，Anki 升级时容易断"）。改动就是一个文件夹，出问题删掉即恢复原状。另外还有个关键拼图：改完 addon 默认要重启 Anki，社区有 triaeiou/reload-addon 这类插件做重载，迭代体验能接受。 而且这条路已经有人走过。r/Anki 上 funbike 那篇帖子（2 个月前）就是用 Pi coding agent，加上一个"怎么写 Anki 插件"的 skill，让 agent 处理只有插件能做的事（hooks），日常的读卡建卡走 AnkiConnect；他自述没有公开项目。IamGianluca/anki-addon 更进一步，是真把策展 agent 塞进 addon 里，但刻意设计成 agent 没有写权限、所有改动一次性人工审核后才落库。 方案 B 的天花板也很清楚，这才是关键。 按 Anki 官方架构文档，现在大部分后端逻辑已经搬到 Rust（rslib），pylib 只是转发请求（rsbridge）。addon 能碰到的只有 Python 那一层。也就是说：什么时候出卡、间隔怎么算、collection 和同步协议怎么读写，这些真正核心的东西 monkey patch 基本够不着；能改的主要是 GUI 行为（aqt，以及注入 Qt webview 的 JS/TS）和上层 API。能改多少完全取决于 hook 和 protobuf 给你暴露了什么，没有 hook 的地方只能整段复制源码覆盖，Anki 一升级就断——这就是社区里"每次更新一批插件挂掉"的根因。还有一条：addon 在进程内运行，等于把任意代码执行权放进了持有你 AnkiWeb 凭据和整个 collection 的进程，让 agent 自动改、自动跑，风险不是理论问题。"想要啥就跟 AI 说"体验很好，但 agent 只能在 Python 这条边界里想要啥都行，出了边界就没了。 再看方案 A。它的上限确实高：Rust 核心、调度算法、数据库 schema、GUI 全在掌控内，功能没有边界。另一个被低估的好处是 harness 本身——你 fork 出来就是一个正常代码仓库，循环、测试、lint、CI、trajectory、session 恢复、任务清单这套现成的东西直接复用，"AI 改 Anki"的体验是完整且可验证的。适合验证性的东西，比如换一套完全不同的调度策略，或者做一个把复习变成 agent 对话的产品原型。 但代价更重。构建链是三套叠一起：Rust（rslib）+ Python 3.13（pylib/aqt）+ Node/TS，加 protoc、ninja；能编不等于能发，三平台打包、签名公证、自动更新通道全要自己搭，还得把官方 updater 关掉。维护是持续性支出：Anki 发版很勤，每跟一次都要 rebase，改动越深冲突越多。生态也会断：AnkiDroid / AnkiMobile 走的是官方同步协议，你动了 collection 结构就可能写坏同步，AnkiHub 这类基于 addon 的生态同样受影响——不动协议和 schema 就还能同步，但得格外小心。所以自己 fork 的版本，实际能用的范围基本只剩你一台机器。 结论是这样。如果你要的是"Anki 的界面和行为随我心意"，选 B，并且把 agent 放在 Anki 外面：一个仓库放你的 addon 源码，agent 在里面改代码、跑测试，你重载进 Anki；数据面走 AnkiConnect 或 MCP；写操作保持人工确认。这是目前生态里验证过能跑通的形态，本质是把 harness 放在外面，Anki 只是被操作的对象。如果你要的是调度算法、数据模型级别的东西，那才值得上 A，而且更划算的做法通常是做成小 patch 甚至提上游，而不是长期养一个 fork。一句话：B 是给 Anki 接一只手，A 是自己养一个 Anki。建议先用 B 试两周，真被 Python 边界卡死了再考虑 A。 关于你问的"目前是不是没有这样的插件"——确实没有通用的那一种，也就是一个内嵌 agent、能直接改 Anki 本身的插件。现有的都是窄化的：内容与学习类有 Anki AI（addon ）、AnkiBrain（，页面标的是 GPT-5.6 自动生成卡片）、Anki Terminator V2 侧边栏；整理类 agent 就是上面说的 IamGianluca/anki-addon；最热的是桥接类，AnkiConnect 加一堆 MCP server，比如 nailuoGG/anki-mcp-server、Anki MCP Server（addon ）、anki-mcp-desktop，思路都是让 Claude / ChatGPT 通过 MCP 读卡建卡；开发辅助类有 reload-addon。社区里最接近"方案 B 完整形态"的反倒是 funbike 那个私人方案。所以不是没人想做，而是大家要么停在"MCP 读写数据"，要么停在"生成卡片"；再往上一层让 agent 自己改 Anki 没人做成产品，原因大概率就是 monkey patching 太脆，加上安全边界不好划。 需要的话我可以按你的实际目标，给你拆一个最小可跑的目录结构和分工方案。