科幻作家对 LLM 的态度最近几乎成了 AI 写作话题里绕不开的争论点。多数反感这是我在各类访谈、创作谈、知识库讨论和私下交流中得到的印象。注意这不是某家机构给出的严谨调查结论更像一个声音非常集中的观察很多正在写科幻小说的人对把大语言模型引入文学创作这件事非常警惕。但真正值得追问的不是“他们为什么反感”而是“他们反感的是什么”。反感“让 AI 直接生成一篇文章然后署上自己的名字”是一回事反感“用本地模型整理资料、做格式转换、搭一个可控知识库”又是另一回事。把这两件事分开之后很多争论就能落到具体问题上了。我想先把科幻作家的反感原因拆开讲清楚再介绍一种最近社区里关注度很高的“LLM wiki”方法最后给出一条可复现的落地路径用文档驱动模型、用知识库约束模型、用日志验证输出。这篇内容适合既关心创作伦理、又想知道 LLM 到底能怎么被规规矩矩使用的人。1. 科幻作家的反感大多是在反对“自动生成”这件事1.1 反感从哪来创造力、风格和作者身份的稀释我最早看科幻作家公开表态时以为反对点是“AI 写得不够好”。后来发现不是。很多反对者承认 LLM 能写出语法通顺、结构完整的段落但他们更在意的是当一段文本可以被自动拼接出来时创作过程里最难的“选择”被取消了。写小说不是一个“从空白到成品”的直线过程。要决定主角在第一章看到什么、哪个细节暗示结局、哪句话该收着不说。这些决定组成作者风格也组成作者身份。如果 LLM 在几秒内把大量常见桥段重新组合成一篇看起来像模像样的文本那么创作中最珍贵的个人选择就被稀释了。这也是很多科幻作家反感的核心不是机器写得快而是机器把“写得好”这件事变成了一种统计平均。一个人耗费数年建立的表达风格在模型眼里只是一组概率分布。这种不对等很容易让人产生被冒犯的感觉。1.2 反对创作被当作统计也反对“看起来像人写”的幻觉另一个反感点更技术化LLM 会生成看似合理但没有来源的内容。很多刚开始使用大语言模型的创作者会让模型直接写一段“科幻设定”然后被输出内容的流畅性说服忘记检查里面有多少内容是编造出来的。这事在文档处理场景里尤其危险。如果你让模型总结一段技术资料模型可能在总结里加入原文没有的结论。如果你再把这个总结拿去当创作素材那最终作品里就会掺入无法追溯的虚假信息。作家对“幻觉文本”的容忍度很低因为写作的第一条底线是“作者要为自己写出的每个字负责”。一旦模型自动生成的内容进入署名文本责任主体就变模糊了。读者认为是作者写的作者却说模型生成的到底谁对这段话负责这种不确定性比技术不成熟更让人反感。1.3 科幻作家对 AI 话题天然敏感不是无知你们有没有发现聊 LLM 最激烈的一群人反而是最懂 AI 想象的科幻作家。写了几十年人工智能题材的人对“机器生成文本”这件事早就有预判。他们不是不知道 LLM 的能力而是太知道“技术乐观叙事”后面还跟着什么平台化、标准化、被消费、被平均。所以当我看到有些讨论把科幻作家的反感归结为“跟不上技术”时会觉得这个判断太轻率。科幻作家对待 LLM 的态度更像是常年研究某类物种的人突然在野外见到活体时的警惕既兴奋又知道它需要边界。2. 反感背后的真问题LLM 适合处理文本不适合凭空创造观点2.1 大语言模型的本质是“下一个词的概率预测”要理解科幻作家的反感为什么有道理先得回到“LLM 是什么”这个问题。大语言模型通过海量文本学习词与词之间的统计关系输入一句话后它计算最可能接下去的词不断重复直到形成完整段落。这意味着 LLM 没有自己的立场也没有“必须表达”的冲动。它更像一面语言镜子把语料中大量出现的表达方式映射到你的问题上。它不是观点创造者而是文本重组者。这个区别很重要。当你把创作当成“表达某种非说不可的东西”时LLM 天然不适合做核心作者。但当任务变成“把这堆材料整理成清晰的摘要”LLM 反而非常可靠因为那本来就是对已有文本的重组。2.2 把创作拆成结构任务和风格任务结论会完全不同我习惯把写作任务拆成两层结构任务和风格任务。结构任务包括切分章节、整理时间线、检查设定一致性、生成人物关系表、把零散笔记变成大纲草稿、把长资料压缩成摘要。这些任务有明确输入、明确输出格式也和创造力关系不大。LLM 可以胜任。风格任务包括决定叙述视角、打磨语气、选择隐喻、安排悬念、判断哪些内容要留白。这些任务高度依赖个人审美和意图交给 LLM 容易得到“像模像样但毫无锋芒”的文本。很多反感情绪其实是对风格任务被滥用的反弹。把这两层分开之后你会发现“用不用 LLM”不再是非黑即白的问题而是“在哪个环节用、以什么方式用、控制到什么程度”。2.3 用 LLM 处理文档的现实问题场景都是“结构化再造”结合社区里高频出现的使用场景LLM 真正稳定发挥的地方基本集中在文档处理长文档摘要几十页访谈记录压缩成几百字的要点。信息抽取从零散笔记里提取日期、人物、项目名输出成表格。格式转换自由文本转 Markdown、JSON、CSV。知识库问答只基于指定文档回答问题不引用文档外内容。辅助润色在保留原意前提下修正语句而不是重写。这些场景的共同点是素材已经存在目标格式清楚结果可以被人工检查。把 LLM 放在这个位置它更像一个可配置的文档处理引擎而不是“代笔机器”。科幻作家的反感也会在这里明显降低。3. LLM wiki把“提示词”升级成“工作流文档”的方法3.1 社区里流传的 LLM wiki到底在讲什么最近热词里大量出现“llm wiki”“karpathy 的 llm wiki 方法文档”“llm wiki 怎么用”背后是一套被反复整理的方法论。它和 Andrej Karpathy 在公开分享中强调的理念一脉相承LLM 应当被用于可控的、可验证的软件任务而不是单纯的自由聊天。社区把这类方法整理成 wiki是因为它需要沉淀角色定义、任务说明、输入输出格式、验收标准、失败处理。它不是一个临时提示词而是一套长期维护的规则文档。核心思想可以概括为不要在下一次对话里重新解释任务而是让模型每次从一份标准文档开始执行。这也被很多人称为“文档驱动开发”。3.2 agent.md用文档描述角色、输入、输出和边界在 LLM wiki 的知识体系里agent.md 是常见入口。它通常是一个 Markdown 文件用来描述某个 LLM 智能体的全部行为边界。一个典型 agent.md 会包含这些信息角色定义这个智能体是做什么的服务于什么场景。目标它要完成什么任务不做什么。输入允许读取哪些文件、哪些目录禁止读取哪些内容。输出格式要求返回 Markdown、JSON还是表格。工作流程先做什么再做什么遇到冲突怎么处理。禁止事项不编造来源不擅自改写原文不回答文档外问题。验收标准满足什么条件才算任务完成。把这段文档放到任务目录里让 LLM 每次先读它再开始工作。这样不管换模型、换客户端、换项目执行规则都能保持一致。这比每次人工敲一段长提示词要可靠得多。3.3 为什么文档驱动比现场聊天稳定用过 ChatGPT 或本地模型的人都知道聊天窗口里的指令容易“越聊越偏”。一开始它记得你是让它做摘要聊到第三轮它可能开始自由发挥。原因是上下文里的指令被其他内容干扰了。文档驱动通过固定入口解决这个问题每次任务都从同一份 agent.md 启动减少遗忘。输出格式固定后续处理更容易自动化。规则可以版本管理哪里改过随时可查。出错时可以对照文档排查要么是文档没写清要么是模型执行偏差。这也回应了科幻作家对“不可控”的担忧。LLM wiki 方法要做的就是让模型行为尽可能可预期、可审计。它不是让 AI 更会创作而是让 AI 更听话地处理材料。4. 实操用 LLM wiki 思路搭建个人知识库4.1 准备阶段Markdown 知识库加规则文档想落地这套方法不需要很复杂的架构。先准备一个文件夹里面放你真正要用的资料比如笔记、访谈整理、技术文档、小说设定片段统一用 Markdown 保存。然后在这个目录里新建一份agent.md。第一版不用写长先写三条核心规则只回答给定文档里出现过的内容。如果没有找到依据直接回复“资料库中没有相关内容”。输出用 Markdown每个回答末尾附上参考文件路径。这就是最简化的 LLM wiki。它解决的问题是模型不会凭空发挥也不会用“可能”“也许”来掩盖文档缺失。4.2 连接 LLM本地运行还是在线接口接下来要决定模型在哪里跑。两种方式各有适用场景方案优点需要注意本地运行AnythingLLM、LM Studio、Ollama 等数据不出本地适合处理未公开的创作稿、访谈资料需要一定 CPU/内存/显存运行速度取决于机器配置在线 API部署简单模型能力更强速度快材料会被发送到服务端敏感内容要谨慎如果目标是处理自己的小说稿、采访录音转文字、未公开设定我更推荐先用本地模型跑通。这样心理负担小也更容易说服周围反感 LLM 的创作者文稿从头到尾没有离开过自己的电脑。如果你的机器配置不高可以选小一点的模型或把任务拆短一次只处理一个文件。低配置能跑通不代表适合批量处理这个边界要心里有数。4.3 从 Obsidian 到 AnythingLLM一套简单流程Obsidian 是很多写作者和知识管理爱好者在用的 Markdown 笔记工具。它的优势是本地文件、双链、目录清晰。你可以先把知识库在 Obsidian 里整理好每个主题一个 Markdown 文件。然后打开 AnythingLLM 这类知识库问答工具新建一个工作区把你整理好的 Markdown 文件夹拖进去。AnythingLLM 会把文档拆块、向量化之后你就可以在对话框里提问。它的提问本质就是知识库检索加 LLM 生成条件越明确回答越稳。建议在工作区里把系统提示词写成你 agent.md 的简化版你是一个个人知识库助手。只依据工作区文档回答用户问题。如果文档中没有答案直接说明没有找到。回答必须标注参考文档名。不得补充文档外信息。这样你就在“模型参数 文档检索 规则提示”三层约束下使用 LLM。即使模型本身有幻觉倾向也会被文档检索结果和规则提示压住。4.4 网页共享先在内网测试再谈权限AnythingLLM 支持搭建一个 Web 界面让同一局域网内的其他设备访问。这个功能适合小团队共享知识库比如几个作者合用一个设定文档库或者一个开发小组共享技术文档。这里要提醒一句不要顺手把服务端口暴露到公网。如果只是想让局域网内的同事或朋友访问把服务监听地址设为局域网 IP加访问口令就够了。如果确实需要外部访问要走合规的部署方案配上身份认证、访问控制和日志而不是直接开一个裸端口。这类操作看起来是小事但对内容安全影响很大。个人知识库里可能有未公开小说稿、读者信息、合作内容一旦暴露出去责任很难收场。宁可先用内网测试也不要冒这个险。5. agent.md 标准模板与关键参数让模型不说废话、不超时、不跑偏5.1 一个够用的标准模板刚接触 LLM wiki 的人最容易问“agent.md 到底怎么写”。下面给一个通用结构你可以直接复制再按自己的文档目录改参数# 角色 你是个人知识库文档助手负责处理用户提供的 Markdown 文件。 # 目标 基于工作区文档回答用户问题辅助摘要、抽取、格式转换。 # 输入 - 目录/path/to/your/knowledge-base - 格式Markdown、纯文本 - 禁止读取目录外的任何文件 # 输出格式 - 使用中文回答 - 开头给出结论 - 正文列出依据 - 末尾标注参考文件路径 - 如无依据只回复知识库中没有相关内容 # 工作流程 1. 读取 agent.md 2. 检索与问题相关的文档片段 3. 基于片段组织回答 4. 检查是否遗漏关键信息 5. 输出并附参考来源 # 禁止事项 - 不得编造数据 - 不得补充文档外结论 - 不得对原文做价值判断 - 不得在回答中隐藏“不确定” # 验收标准 - 回答内容均可在给定文档中找到出处 - 无依据时明确说明 - 输出格式保持稳定这个模板对应前面提到的 LLM wiki 结构适合做知识库问答、文档摘要和工作流辅助。真正使用的时候你可以把“输入目录”换成实际路径把“输出格式”改成项目需要的结构。5.2 模型参数怎么调温度、长度、上下文和并发写文档只是第一步实际运行里最常被忽略的是参数设置。我觉得几个参数值得重点关注temperature控制随机性。文档摘要、知识库问答建议调到 0.2 到 0.5。太高会自由发挥太低会显得机械。如果是头脑风暴可以调高一点但知识库场景要调低。max tokens / 最大输出长度决定回答最长能写多少。摘要任务要根据原文长度和预期摘要长度设定太短会被截断太长会拖慢响应。上下文长度一次能塞进去的 token 数。知识库问答不是把整篇文档都丢进上下文而是先检索相关片段再把这些片段喂给模型。如果做了向量检索就不需要担心超长文档塞不进去。并发数本地模型跑批处理时并发太高容易把内存和显存占满。一开始先设 1 到 2等单条任务稳定了再慢慢加。我遇到过很多次“模型越跑越慢”的情况最后发现不是模型坏了而是同时开了太多请求CPU 和内存都打满了。5.3 遇到“request timed out”和空响应先排查这四个地方热词里有一条报错很典型llm request timed out. the model did not produce a response before the mod...翻译过来就是模型在限定时间内没有生成响应请求超时。拿到这个报错不要马上怀疑模型有问题。按顺序排查先看模型服务是否正常在模型客户端里手动发一条最短消息看有没有响应。再看资源占用CPU 是否满了、内存是否快满、磁盘读写是否异常。然后看输入长度是不是一次性塞了太多文档导致推理时间远超超时值。最后看超时配置客户端默认超时时间是不是太短本地慢模型需要更长的等待时间。常见的解决办法有四种把长文档拆成小片段处理、降低并发数、延长客户端超时时间、换一个更小更快的模型。不要反过来把超时无限调大那样问题会被掩盖下一次任务卡住时你反而更难定位。6. 回到科幻作家的反感可控使用才是和解方式6.1 LLM wiki 方法为什么能让反感的人接受一部分科幻作家的核心担忧是“不可控”。一个模型连资料来源都说不清你没法判断它哪句话可信哪句话是幻觉。这种状态当然不适合进入创作流程。LLM wiki 方法做得最扎实的一件事就是把“不可控”变成“可控”。它要求你预先定义角色、输入、输出、边界和验收标准要求模型输出时必须标注来源要求没有依据时明确说“不知道”。这些规则不是为了限制模型能力而是为了让使用者重新掌握判断权。当你能在每一条回答后面看到参考文件路径能通过日志检查模型读了哪些文档能通过 agent.md 让模型每次保持同一种行为模式时LLM 就不再是一个黑箱而是一台可以校对、可以审计的文本处理工具。对反感的人来说这种状态更有讨论基础。6.2 动手边界先从三个不重要的任务开始如果你看完这篇文章想亲自验证这套方法是不是靠谱我的建议是不要一上来就搭一个宏大知识库也不要直接用它写小说章节。先选三个不影响主任务的小事把你最近读过的几篇访谈整理成结构化摘要。把零散创作笔记按时间线重排成 Markdown 列表。准备一个只有五六个文档的小知识库在 AnythingLLM 里测试“只依据文档回答”的效果。跑通之后你可以对照 agent.md 的验收标准检查输出有没有编造内容每条结论能不能定位到来源格式是否稳定这三个问题通过之后再考虑把 LLM 接入更核心的工作流。如果连这三个小任务都经常跑偏那说明不是模型问题而是规则文档没写好或者输入文档太乱。这时候要先修复资料目录再调整提示词而不是继续加大并发或换更大模型。6.3 别把工具神话也别把所有使用都一概而论聊到最后我想说一个更现实的观点LLM 不是用来替代作者判断的至少在目前的形态下不是。它擅长的是对已有材料进行重组、摘要、检索和格式转换。它不知道你想表达什么也不理解一个故事为什么必须有那个“留白一句话”。所以真正成熟的用法是把 LLM 放在“执行者”和“助手”的位置上而不是放在“创作者”的位置上。文档驱动、知识库检索、输出检查都是为了让它在边界内发挥优势。这也许就是与科幻作家达成和解的路径。不要求所有人都接受 LLM也不要求所有文本都经历模型处理。只要每个人都能明确说出我在哪个环节用了工具、输入是什么、输出怎么验证那么工具就只是工具判断权始终在作者手里。
从科幻作家的警惕到LLM wiki：用文档驱动让大模型可控
科幻作家对 LLM 的态度最近几乎成了 AI 写作话题里绕不开的争论点。多数反感这是我在各类访谈、创作谈、知识库讨论和私下交流中得到的印象。注意这不是某家机构给出的严谨调查结论更像一个声音非常集中的观察很多正在写科幻小说的人对把大语言模型引入文学创作这件事非常警惕。但真正值得追问的不是“他们为什么反感”而是“他们反感的是什么”。反感“让 AI 直接生成一篇文章然后署上自己的名字”是一回事反感“用本地模型整理资料、做格式转换、搭一个可控知识库”又是另一回事。把这两件事分开之后很多争论就能落到具体问题上了。我想先把科幻作家的反感原因拆开讲清楚再介绍一种最近社区里关注度很高的“LLM wiki”方法最后给出一条可复现的落地路径用文档驱动模型、用知识库约束模型、用日志验证输出。这篇内容适合既关心创作伦理、又想知道 LLM 到底能怎么被规规矩矩使用的人。1. 科幻作家的反感大多是在反对“自动生成”这件事1.1 反感从哪来创造力、风格和作者身份的稀释我最早看科幻作家公开表态时以为反对点是“AI 写得不够好”。后来发现不是。很多反对者承认 LLM 能写出语法通顺、结构完整的段落但他们更在意的是当一段文本可以被自动拼接出来时创作过程里最难的“选择”被取消了。写小说不是一个“从空白到成品”的直线过程。要决定主角在第一章看到什么、哪个细节暗示结局、哪句话该收着不说。这些决定组成作者风格也组成作者身份。如果 LLM 在几秒内把大量常见桥段重新组合成一篇看起来像模像样的文本那么创作中最珍贵的个人选择就被稀释了。这也是很多科幻作家反感的核心不是机器写得快而是机器把“写得好”这件事变成了一种统计平均。一个人耗费数年建立的表达风格在模型眼里只是一组概率分布。这种不对等很容易让人产生被冒犯的感觉。1.2 反对创作被当作统计也反对“看起来像人写”的幻觉另一个反感点更技术化LLM 会生成看似合理但没有来源的内容。很多刚开始使用大语言模型的创作者会让模型直接写一段“科幻设定”然后被输出内容的流畅性说服忘记检查里面有多少内容是编造出来的。这事在文档处理场景里尤其危险。如果你让模型总结一段技术资料模型可能在总结里加入原文没有的结论。如果你再把这个总结拿去当创作素材那最终作品里就会掺入无法追溯的虚假信息。作家对“幻觉文本”的容忍度很低因为写作的第一条底线是“作者要为自己写出的每个字负责”。一旦模型自动生成的内容进入署名文本责任主体就变模糊了。读者认为是作者写的作者却说模型生成的到底谁对这段话负责这种不确定性比技术不成熟更让人反感。1.3 科幻作家对 AI 话题天然敏感不是无知你们有没有发现聊 LLM 最激烈的一群人反而是最懂 AI 想象的科幻作家。写了几十年人工智能题材的人对“机器生成文本”这件事早就有预判。他们不是不知道 LLM 的能力而是太知道“技术乐观叙事”后面还跟着什么平台化、标准化、被消费、被平均。所以当我看到有些讨论把科幻作家的反感归结为“跟不上技术”时会觉得这个判断太轻率。科幻作家对待 LLM 的态度更像是常年研究某类物种的人突然在野外见到活体时的警惕既兴奋又知道它需要边界。2. 反感背后的真问题LLM 适合处理文本不适合凭空创造观点2.1 大语言模型的本质是“下一个词的概率预测”要理解科幻作家的反感为什么有道理先得回到“LLM 是什么”这个问题。大语言模型通过海量文本学习词与词之间的统计关系输入一句话后它计算最可能接下去的词不断重复直到形成完整段落。这意味着 LLM 没有自己的立场也没有“必须表达”的冲动。它更像一面语言镜子把语料中大量出现的表达方式映射到你的问题上。它不是观点创造者而是文本重组者。这个区别很重要。当你把创作当成“表达某种非说不可的东西”时LLM 天然不适合做核心作者。但当任务变成“把这堆材料整理成清晰的摘要”LLM 反而非常可靠因为那本来就是对已有文本的重组。2.2 把创作拆成结构任务和风格任务结论会完全不同我习惯把写作任务拆成两层结构任务和风格任务。结构任务包括切分章节、整理时间线、检查设定一致性、生成人物关系表、把零散笔记变成大纲草稿、把长资料压缩成摘要。这些任务有明确输入、明确输出格式也和创造力关系不大。LLM 可以胜任。风格任务包括决定叙述视角、打磨语气、选择隐喻、安排悬念、判断哪些内容要留白。这些任务高度依赖个人审美和意图交给 LLM 容易得到“像模像样但毫无锋芒”的文本。很多反感情绪其实是对风格任务被滥用的反弹。把这两层分开之后你会发现“用不用 LLM”不再是非黑即白的问题而是“在哪个环节用、以什么方式用、控制到什么程度”。2.3 用 LLM 处理文档的现实问题场景都是“结构化再造”结合社区里高频出现的使用场景LLM 真正稳定发挥的地方基本集中在文档处理长文档摘要几十页访谈记录压缩成几百字的要点。信息抽取从零散笔记里提取日期、人物、项目名输出成表格。格式转换自由文本转 Markdown、JSON、CSV。知识库问答只基于指定文档回答问题不引用文档外内容。辅助润色在保留原意前提下修正语句而不是重写。这些场景的共同点是素材已经存在目标格式清楚结果可以被人工检查。把 LLM 放在这个位置它更像一个可配置的文档处理引擎而不是“代笔机器”。科幻作家的反感也会在这里明显降低。3. LLM wiki把“提示词”升级成“工作流文档”的方法3.1 社区里流传的 LLM wiki到底在讲什么最近热词里大量出现“llm wiki”“karpathy 的 llm wiki 方法文档”“llm wiki 怎么用”背后是一套被反复整理的方法论。它和 Andrej Karpathy 在公开分享中强调的理念一脉相承LLM 应当被用于可控的、可验证的软件任务而不是单纯的自由聊天。社区把这类方法整理成 wiki是因为它需要沉淀角色定义、任务说明、输入输出格式、验收标准、失败处理。它不是一个临时提示词而是一套长期维护的规则文档。核心思想可以概括为不要在下一次对话里重新解释任务而是让模型每次从一份标准文档开始执行。这也被很多人称为“文档驱动开发”。3.2 agent.md用文档描述角色、输入、输出和边界在 LLM wiki 的知识体系里agent.md 是常见入口。它通常是一个 Markdown 文件用来描述某个 LLM 智能体的全部行为边界。一个典型 agent.md 会包含这些信息角色定义这个智能体是做什么的服务于什么场景。目标它要完成什么任务不做什么。输入允许读取哪些文件、哪些目录禁止读取哪些内容。输出格式要求返回 Markdown、JSON还是表格。工作流程先做什么再做什么遇到冲突怎么处理。禁止事项不编造来源不擅自改写原文不回答文档外问题。验收标准满足什么条件才算任务完成。把这段文档放到任务目录里让 LLM 每次先读它再开始工作。这样不管换模型、换客户端、换项目执行规则都能保持一致。这比每次人工敲一段长提示词要可靠得多。3.3 为什么文档驱动比现场聊天稳定用过 ChatGPT 或本地模型的人都知道聊天窗口里的指令容易“越聊越偏”。一开始它记得你是让它做摘要聊到第三轮它可能开始自由发挥。原因是上下文里的指令被其他内容干扰了。文档驱动通过固定入口解决这个问题每次任务都从同一份 agent.md 启动减少遗忘。输出格式固定后续处理更容易自动化。规则可以版本管理哪里改过随时可查。出错时可以对照文档排查要么是文档没写清要么是模型执行偏差。这也回应了科幻作家对“不可控”的担忧。LLM wiki 方法要做的就是让模型行为尽可能可预期、可审计。它不是让 AI 更会创作而是让 AI 更听话地处理材料。4. 实操用 LLM wiki 思路搭建个人知识库4.1 准备阶段Markdown 知识库加规则文档想落地这套方法不需要很复杂的架构。先准备一个文件夹里面放你真正要用的资料比如笔记、访谈整理、技术文档、小说设定片段统一用 Markdown 保存。然后在这个目录里新建一份agent.md。第一版不用写长先写三条核心规则只回答给定文档里出现过的内容。如果没有找到依据直接回复“资料库中没有相关内容”。输出用 Markdown每个回答末尾附上参考文件路径。这就是最简化的 LLM wiki。它解决的问题是模型不会凭空发挥也不会用“可能”“也许”来掩盖文档缺失。4.2 连接 LLM本地运行还是在线接口接下来要决定模型在哪里跑。两种方式各有适用场景方案优点需要注意本地运行AnythingLLM、LM Studio、Ollama 等数据不出本地适合处理未公开的创作稿、访谈资料需要一定 CPU/内存/显存运行速度取决于机器配置在线 API部署简单模型能力更强速度快材料会被发送到服务端敏感内容要谨慎如果目标是处理自己的小说稿、采访录音转文字、未公开设定我更推荐先用本地模型跑通。这样心理负担小也更容易说服周围反感 LLM 的创作者文稿从头到尾没有离开过自己的电脑。如果你的机器配置不高可以选小一点的模型或把任务拆短一次只处理一个文件。低配置能跑通不代表适合批量处理这个边界要心里有数。4.3 从 Obsidian 到 AnythingLLM一套简单流程Obsidian 是很多写作者和知识管理爱好者在用的 Markdown 笔记工具。它的优势是本地文件、双链、目录清晰。你可以先把知识库在 Obsidian 里整理好每个主题一个 Markdown 文件。然后打开 AnythingLLM 这类知识库问答工具新建一个工作区把你整理好的 Markdown 文件夹拖进去。AnythingLLM 会把文档拆块、向量化之后你就可以在对话框里提问。它的提问本质就是知识库检索加 LLM 生成条件越明确回答越稳。建议在工作区里把系统提示词写成你 agent.md 的简化版你是一个个人知识库助手。只依据工作区文档回答用户问题。如果文档中没有答案直接说明没有找到。回答必须标注参考文档名。不得补充文档外信息。这样你就在“模型参数 文档检索 规则提示”三层约束下使用 LLM。即使模型本身有幻觉倾向也会被文档检索结果和规则提示压住。4.4 网页共享先在内网测试再谈权限AnythingLLM 支持搭建一个 Web 界面让同一局域网内的其他设备访问。这个功能适合小团队共享知识库比如几个作者合用一个设定文档库或者一个开发小组共享技术文档。这里要提醒一句不要顺手把服务端口暴露到公网。如果只是想让局域网内的同事或朋友访问把服务监听地址设为局域网 IP加访问口令就够了。如果确实需要外部访问要走合规的部署方案配上身份认证、访问控制和日志而不是直接开一个裸端口。这类操作看起来是小事但对内容安全影响很大。个人知识库里可能有未公开小说稿、读者信息、合作内容一旦暴露出去责任很难收场。宁可先用内网测试也不要冒这个险。5. agent.md 标准模板与关键参数让模型不说废话、不超时、不跑偏5.1 一个够用的标准模板刚接触 LLM wiki 的人最容易问“agent.md 到底怎么写”。下面给一个通用结构你可以直接复制再按自己的文档目录改参数# 角色 你是个人知识库文档助手负责处理用户提供的 Markdown 文件。 # 目标 基于工作区文档回答用户问题辅助摘要、抽取、格式转换。 # 输入 - 目录/path/to/your/knowledge-base - 格式Markdown、纯文本 - 禁止读取目录外的任何文件 # 输出格式 - 使用中文回答 - 开头给出结论 - 正文列出依据 - 末尾标注参考文件路径 - 如无依据只回复知识库中没有相关内容 # 工作流程 1. 读取 agent.md 2. 检索与问题相关的文档片段 3. 基于片段组织回答 4. 检查是否遗漏关键信息 5. 输出并附参考来源 # 禁止事项 - 不得编造数据 - 不得补充文档外结论 - 不得对原文做价值判断 - 不得在回答中隐藏“不确定” # 验收标准 - 回答内容均可在给定文档中找到出处 - 无依据时明确说明 - 输出格式保持稳定这个模板对应前面提到的 LLM wiki 结构适合做知识库问答、文档摘要和工作流辅助。真正使用的时候你可以把“输入目录”换成实际路径把“输出格式”改成项目需要的结构。5.2 模型参数怎么调温度、长度、上下文和并发写文档只是第一步实际运行里最常被忽略的是参数设置。我觉得几个参数值得重点关注temperature控制随机性。文档摘要、知识库问答建议调到 0.2 到 0.5。太高会自由发挥太低会显得机械。如果是头脑风暴可以调高一点但知识库场景要调低。max tokens / 最大输出长度决定回答最长能写多少。摘要任务要根据原文长度和预期摘要长度设定太短会被截断太长会拖慢响应。上下文长度一次能塞进去的 token 数。知识库问答不是把整篇文档都丢进上下文而是先检索相关片段再把这些片段喂给模型。如果做了向量检索就不需要担心超长文档塞不进去。并发数本地模型跑批处理时并发太高容易把内存和显存占满。一开始先设 1 到 2等单条任务稳定了再慢慢加。我遇到过很多次“模型越跑越慢”的情况最后发现不是模型坏了而是同时开了太多请求CPU 和内存都打满了。5.3 遇到“request timed out”和空响应先排查这四个地方热词里有一条报错很典型llm request timed out. the model did not produce a response before the mod...翻译过来就是模型在限定时间内没有生成响应请求超时。拿到这个报错不要马上怀疑模型有问题。按顺序排查先看模型服务是否正常在模型客户端里手动发一条最短消息看有没有响应。再看资源占用CPU 是否满了、内存是否快满、磁盘读写是否异常。然后看输入长度是不是一次性塞了太多文档导致推理时间远超超时值。最后看超时配置客户端默认超时时间是不是太短本地慢模型需要更长的等待时间。常见的解决办法有四种把长文档拆成小片段处理、降低并发数、延长客户端超时时间、换一个更小更快的模型。不要反过来把超时无限调大那样问题会被掩盖下一次任务卡住时你反而更难定位。6. 回到科幻作家的反感可控使用才是和解方式6.1 LLM wiki 方法为什么能让反感的人接受一部分科幻作家的核心担忧是“不可控”。一个模型连资料来源都说不清你没法判断它哪句话可信哪句话是幻觉。这种状态当然不适合进入创作流程。LLM wiki 方法做得最扎实的一件事就是把“不可控”变成“可控”。它要求你预先定义角色、输入、输出、边界和验收标准要求模型输出时必须标注来源要求没有依据时明确说“不知道”。这些规则不是为了限制模型能力而是为了让使用者重新掌握判断权。当你能在每一条回答后面看到参考文件路径能通过日志检查模型读了哪些文档能通过 agent.md 让模型每次保持同一种行为模式时LLM 就不再是一个黑箱而是一台可以校对、可以审计的文本处理工具。对反感的人来说这种状态更有讨论基础。6.2 动手边界先从三个不重要的任务开始如果你看完这篇文章想亲自验证这套方法是不是靠谱我的建议是不要一上来就搭一个宏大知识库也不要直接用它写小说章节。先选三个不影响主任务的小事把你最近读过的几篇访谈整理成结构化摘要。把零散创作笔记按时间线重排成 Markdown 列表。准备一个只有五六个文档的小知识库在 AnythingLLM 里测试“只依据文档回答”的效果。跑通之后你可以对照 agent.md 的验收标准检查输出有没有编造内容每条结论能不能定位到来源格式是否稳定这三个问题通过之后再考虑把 LLM 接入更核心的工作流。如果连这三个小任务都经常跑偏那说明不是模型问题而是规则文档没写好或者输入文档太乱。这时候要先修复资料目录再调整提示词而不是继续加大并发或换更大模型。6.3 别把工具神话也别把所有使用都一概而论聊到最后我想说一个更现实的观点LLM 不是用来替代作者判断的至少在目前的形态下不是。它擅长的是对已有材料进行重组、摘要、检索和格式转换。它不知道你想表达什么也不理解一个故事为什么必须有那个“留白一句话”。所以真正成熟的用法是把 LLM 放在“执行者”和“助手”的位置上而不是放在“创作者”的位置上。文档驱动、知识库检索、输出检查都是为了让它在边界内发挥优势。这也许就是与科幻作家达成和解的路径。不要求所有人都接受 LLM也不要求所有文本都经历模型处理。只要每个人都能明确说出我在哪个环节用了工具、输入是什么、输出怎么验证那么工具就只是工具判断权始终在作者手里。
