从命令行到桌面自动化：AI辅助创作的黄金方案

你没有在让AI写长篇小说时，发现它总忘掉前面精心埋下的伏笔？

更糟的是，为了让AI记住那几十万字的复杂设定，每次都得花掉巨额Token，账单让人肉疼。我在这条路上摸索了很久，从命令行敲指令，到最终封装成一个自动化桌面软件，底层架构的每一次选择，都直接决定了作品质量是封神还是扑街。

今天咱们就来聊聊，CLI 和 SDK 到底怎么选，以及让AI真正“长记性”的终极方案：RAG 和上下文缓存，到底谁才是长篇创作的救星。

日常和AI打交道无非两种姿势。

第一种是终端里敲命令行，就像你对面坐着一个真人助理，你问一句他答一句，所见即所得。这玩意儿擅长解决眼前的小麻烦：修个Bug、润色一段干瘪的文字、卡文时抛个灵感。优点是省钱，因为每次只瞄一眼你光标附近的几行字，Token消耗很低。但它的致命伤是记性太差。写到第108章时，想让它兼顾前10章的伏笔，你得手动把几千字背景资料复制粘贴给它，极其痛苦。

另一种是写死自动化流程的程序，它像一个没有感情的工厂，你预设好规则，它就在后台批量运作：拉取大纲、生成五章草稿、自动挑逻辑毛病，一气呵成。但问题来了，为了保证内容不跑偏，每次执行都得把几十万字的世界观、全卷大纲一股脑儿喂进去，单次任务消耗几万甚至十几万Token，烧钱如流水。所以说，CLI是把手术刀，适合精雕细琢；SDK程序是战略指挥中心，适合大批量生产，但必须解决“记背景代价太高”这个核心矛盾。

为了解决记忆成本问题，业界折腾出两套方案。

第一套叫RAG，检索增强生成，它把几十万字的设定切成几千个小碎片存进数据库，写喝酒剧情时就去搜带“酒”和人物名字的碎片喂给AI。这招省钱，直接砍掉七八成成本，但对小说创作却是一场灾难——极容易导致人设崩塌。因为碎片化让AI丧失了上帝视角。比如第20章埋的伏笔是“这杯酒里有毒”，AI没搜到那片碎片，就会写出两人举杯交心、称兄道弟的弱智剧情，伏笔直接废掉。

第二套叫上下文缓存（Context Caching），比如 Gemini 的 Cache 机制，它不切碎任何数据，直接把几万字的核心设定、大纲和人物面板原封不动存放在官方服务器内存里。结果呢？绝对100%保真！AI拥有全局视角，绝不吃设定，草蛇灰线接得严丝合缝。而且缓存的读取价格便宜，大概是原来的四分之一，既保住了质量又降了成本。所以结论很明确：企业查规章信息用RAG最好；但搞长篇小说或剧本杀引擎，上下文缓存就是唯一的黄金方案。

光有好记性还不够，得让AI干活更稳更准。

我们平时瞎聊时灵光一现的提示词，不能直接写进程序，要把它变成高度结构化的技能，我们叫SKILL。它是一个封装好的“打工人”，有明确的身份指令，比如你是个网文老编辑；预留了变量槽位，让程序自动填入当前章节内容；并强制要求AI按JSON格式输出，不许废话。而SOP就是流水线的图纸，负责编排SKILL的执行顺序：先让“大纲提炼SKILL”干活，拿着结果再交给“正文生成SKILL”撰写书稿。

一个成熟的SKILL，本质上就是经过提纯、参数化、结构化封装的Prompt。它包含角色基座，确立Agent的身份边界与专业倾向；指令，用明确的动作动词规定目标；变量注入点，像{{core_setting}}在运行时动态填入上下文；输出契约，严格限制格式，比如强制输出特定结构的JSON；还有超参数，绑定好Temperature等模型参数。这样打个比喻，AI写作软件就像一座工厂，SKILL是加工点，SOP是流水线车床。

文学创作需要不停试错，一上来就用程序锁死流程绝对会卡壳，也影响效率。最丝滑的工程架构分三步走。

第一步，手动探索。先不写代码，直接用 agy CLI 命令行，用大白话试探AI技能，反复微调，直到试出一段特别好用、怎么写都不会OOC的提示词，这就提炼出了一个SKILL。

第二步，资产剥离。把试成功的SKILL写成一个JSON或Markdown配置文件存在电脑里，从此你的创作手法就从脑子里的灵感变成了可随时调用的数据资产。

第三步，程序固化。在你的跨平台桌面软件上加个按钮，一点按钮，后台程序，比如用Rust写的服务，就去读那个配置文件，把小说上下文塞进去，然后唤起本地CLI 自动化执行。

这套方案的无敌之处在于极致解耦。以后你顿悟出新的伏笔埋设手法，只要去改改那个文本配置文件就行了，完全不需要重新编译和打包桌面软件。你的软件永远跟得上你不断进化的创作理论。

2026年06月09日