也许你已经在新闻里看到过这样的标题一篇由 AI 写的小说通过了日本星新一奖的初审一篇 AI 辅助完成的科幻短篇在国内省级赛事中获奖还有一部用传感器数据和语言模型生成的“公路小说”被正式出版。这些消息每次出现都会引发同一个问题AI 创作真的能拿文学奖吗作为一个长期关注大模型工程化应用的技术作者我想说这个问题的答案并不只是“能”或“不能”而是“AI 如今已经进入文学奖的评审视线但真正拿到最终大奖的作品仍然很少”。比起单纯讨论文学价值更值得开发者关注的是背后那套可复现的生成流程怎么用大模型 API 写出一段有风格的文本怎么通过参数控制文风怎么做人机协作迭代。这不只是文学实验其实是自然语言生成技术在真实创作场景里的一次完整落地。这篇文章会先盘点几个进入文学奖项视野的公开案例再把重点放到技术实现上。我会给出可直接运行的 Python 示例演示如何调用大模型 API 生成小说开头、如何调节 temperature 控制风格、如何做多轮改写。如果你正打算尝试“AI 写作”或“AI 辅助创作”这篇文章可以帮你少踩不少坑。1. 为什么 AI 作品会和“文学奖”联系到一起先明确一个概念我们说的“AI 创作”通常不是 AI 完全脱离人类独立写完一部小说。更准确的说法是“AI 生成文本人类参与选题、约束、筛选和改写”。这个过程中AI 担任的是“无限量草稿生成器”和“风格模仿助手”人类负责提供方向、判断质量、控制边界。这种分工方式天然适合文学创作。写作者最头疼的往往是开头、转折和对话节奏而这些正是大语言模型的强项。只要给出一个足够具体的提示词模型就能在几秒钟内生成数千字。对写作者来说这等于拥有了一个“不会累的灵感搭档”。对技术人来说这也是最容易演示大模型价值的场景之一。所以“AI 获奖”新闻的本质不是机器人突然具备了文学天赋而是“生成式 AI 已经能稳定产出达到基础发表水平的文本”。一旦文本质量过了门槛进入奖项初审就是顺理成章的事。至于能不能拿最终大奖就要看评审更看重“人的体验”还是“文本完成度”了。2. 盘点进入文学奖项视野的 AI 作品在展开技术细节之前先用一个表格把公开报道中比较典型的案例整理出来。要注意的是下面这些案例的信息来源是公开媒体和项目资料具体奖项信息请以官方发布为准。年份作品/事件AI 参与方式奖项相关情况事实说明2016《The Day a Computer Writes a Novel》AI 生成小说文本人类参与筛选和编辑通过日本星新一奖初审未获最终奖多家媒体报道公开可查2018《1 the Road》传感器数据驱动 AI 实时生成叙事文本作为实验小说出版未参评传统文学奖作者 Ross Goodwin 公开了项目思路2023《机忆之地》AI 辅助生成初稿人类作者修改和投稿据国内媒体报道获得省级科幻赛事奖项具体以赛事公布为准网络讨论热度高需以官方信息为准从表格可以看出一个事实真正被媒体称为“AI 获奖”的案例很多其实是“入围”“初审通过”或“获得一个非核心奖项”。这不是坏事而是新技术进入传统评价体系时必然经历的阶段。评审们需要时间验证 AI 作品的稳定性和原创性读者也需要时间接受“作者”的身份可以是一个协作体。对于开发者来说更有价值的不是争论“AI 配不配获奖”而是理解这些作品是怎么被生产出来的。下面我会从原理到代码完整走一遍 AI 辅助文学创作的技术路径。3. 从技术视角看AI 是怎么“写”小说的当前主流的大语言模型本质上是一个基于 Transformer 架构的“下一个 Token 预测器”。它并不会像人类一样先去构思情节、设计人物而是根据你输入的提示词逐字预测最可能出现在当前位置的文本片段。这个机制决定了三件事第一AI 生成的质量高度依赖提示词。你问“写一个故事”它只能给出一个平庸的开头你明确“写一个发生在废弃空间站的科幻短篇主角是一名修复机器人语气缓慢而克制”它就能调动训练数据里相近的叙事风格。第二生成结果有随机性。同一个提示词在不同 temperature 参数下会得到不同文本。temperature 接近 0 时输出更稳定、更接近“概率最高”的文本temperature 高于 0.9 时输出更跳跃、更有想象力但也更容易出现逻辑断裂。第三AI 没有长期规划能力。它可以写好一个段落但一口气生成整本小说时很容易出现前后矛盾、伏笔丢失、人物性格漂移。这就是为什么真正的 AI 辅助写作流程几乎都是“分段生成 人工整合”。所以如果你想用 AI 创作文学作品不能把它当成一个“自动写书机”而要把它的定位理解为“一个需要你持续给出的编辑指令的高强度写手”。下面四节的内容就是围绕这个定位展开的实操。4. 环境准备与前置条件本节提供一个最小可运行的实验环境。你可以用 OpenAI 兼容接口的任意大模型服务也可以使用国内支持相同协议的模型服务。重点是演示通用思路模型名称和地址请以你的实际服务商为准。你需要准备Python 3.10 或更高版本一个可用的 LLM API 密钥一个 OpenAI 兼容的 Base URL默认可以是https://api.openai.com/v1安装requests库用pip install requests完成为了不把密钥硬编码到代码里建议通过环境变量传入。在 Windows PowerShell 下可以用$env:LLM_API_KEY你的密钥在 macOS/Linux 下可以用export LLM_API_KEY你的密钥。下面的代码会复用同一个环境变量这样示例之间可以相互调用改动量也更小。如果你使用的是国内模型服务商不同厂商的 Base URL 和模型名差别很大请务必先阅读服务商文档不要强行套用。5. 用大模型 API 生成一段小说开头第一个示例会调用 OpenAI 兼容的/chat/completions接口让模型写一段 500 字左右的科幻小说开头。# 文件路径generate_story.py import os import requests # 从环境变量读取密钥不要在代码里硬编码 API_KEY os.environ.get(LLM_API_KEY) BASE_URL os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) def generate_story(topic, temperature0.8, max_tokens500): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: gpt-4o-mini, # 请按你的服务商调整 messages: [ {role: system, content: 你是一名文学编辑擅长构思短篇科幻小说。}, {role: user, content: f请围绕“{topic}”写一段500字左右的开头要求有画面感。} ], temperature: temperature, max_tokens: max_tokens, } resp requests.post(f{BASE_URL}/chat/completions, headersheaders, jsonpayload) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: print(generate_story(AI 考古学家发现了一本会自我修改的日记))这段代码的关键逻辑有三处一是messages结构。第一行system告诉模型“你是一名文学编辑”这能显著影响输出语气第二行user是实际创作指令。这种结构比单纯传一个字符串更能稳定输出质量。二是temperature参数。这里设为 0.8属于“兼顾稳定性与想象力”的区间。如果你希望输出更接近“标准”文本可以降到 0.3如果你想要更跳跃的表达可以提高到 1.0 以上。三是max_tokens。它限制生成长度是 500 token大约相当于几百个汉字。如果输出被截断可以调大这个值。运行命令python generate_story.py预期输出是一段符合提示词要求的科幻小说开头。如果运行失败优先检查LLM_API_KEY是否配置正确、Base URL 是否可访问、模型名称是否真实存在。6. 用参数控制文风Temperature 与 Top_p 的实际差异很多第一次接触大模型生成的人会忽略一个事实同样的提示词不同的采样参数会产生完全不同的文本。对文学创作来说这个差异尤其明显。下面这段脚本会循环测试三个 temperature 值并输出每个参数下的生成结果。# 文件路径compare_temperature.py from generate_story import generate_story prompt 在一个永远下雨的城市图书馆里最后一盏灯突然熄灭。 for temp in [0.2, 0.8, 1.2]: print(f----- temperature {temp} -----) print(generate_story(prompt, temperaturetemp)) print()运行命令python compare_temperature.py从实际输出可以看到几个规律temperature 为 0.2 时模型给出的描述往往比较克制情节推进稳定但可能缺少惊喜感temperature 为 0.8 时文本更有张力会出现一些“意料之外但合理”的细节temperature 为 1.2 时灵感变多但逻辑断裂的概率也随之上升有时会连续生成几个彼此不连贯的句子。除了 temperature还有一个top_p参数也会影响随机性。它的原理是只在累计概率达到某个阈值的候选词里采样。实际项目中通常只调节其中一个参数不要同时大幅调整两个参数否则输出会很难控制。从工程角度我的建议是初稿阶段用偏高的 temperature 追求灵感润色阶段用偏低的 temperature 保证语法正确和逻辑连贯。这个思路和人类写作流程高度一致因此很适合落到 AI 辅助写作工具中。7. 人机协作写作从初稿到可参赛文本直接让 AI 一口气生成整篇文章通常质量不够。真正能在文学创作流程里发挥价值的是“多轮迭代”先生成初稿再让模型根据指令改写。下面这个示例演示了如何把人工修改后的段落作为上下文让模型继续润色。# 文件路径rewrite_with_llm.py import os import requests API_KEY os.environ.get(LLM_API_KEY) BASE_URL os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) def rewrite(text, instruction): messages [ {role: system, content: 你是一位严肃的文学编辑能够在保留原意的基础上提升文本质感。}, {role: user, content: f原稿\n{text}\n\n请按以下要求修改\n{instruction}} ] resp requests.post( f{BASE_URL}/chat/completions, headers{Authorization: fBearer {API_KEY}, Content-Type: application/json}, json{ model: gpt-4o-mini, messages: messages, temperature: 0.5, max_tokens: 700, } ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: draft 他走进房间。桌子上有一封信。他打开信上面写着不要打开这封信。 print(rewrite(draft, 把第一人称改成第三人称增加环境描写和心理活动字数在200字左右。))运行命令python rewrite_with_llm.py这段脚本的意义在于模拟真实协作流程初稿可以是模型生成的也可以是人类写的但每一轮修改都需要携带明确的指令。指令越具体模型输出越接近你想要的风格。比如“把第一人称改成第三人称”是明确的结构要求“增加环境描写和心理活动”是内容要求“字数在 200 字左右”是篇幅约束。在参赛场景下这种“AI 写初稿 人类重写”的模式最容易产生高质量结果也最能保证作品的“人类作者主体性”。你可以把 AI 看成一支随时响应指令的编辑部而不是真正的署名作者。8. AI 作品参评文学奖的现实问题把代码跑通之后我们再回到“获奖”这个话题。很多读者会问既然 AI 能写出合格文本为什么拿最终大奖的案例很少原因是文学奖评审并不只看“文本完成度”。评审通常还会看作品的思想深度、情感真实性、作者意图、社会背景与个人经验。这些维度对 AI 来说非常困难因为大模型没有真实的生命体验它只是在统计层面模仿“人类如何表达痛苦与喜悦”。它可以写出“他望着雨窗想起母亲去世那天的天色”这类句子但它并不知道失去亲人是什么感觉。此外各大赛事对“AI 是否参与创作”的规定也在快速收紧。有的赛事要求作者在投稿时声明是否使用 AI有的赛事则完全禁止。你的提示词、生成过程、改写比例都可能成为决定作品是否合规的因素。如果你真的想用 AI 辅助创作去参赛第一步不是写代码而是阅读赛事规则。还有一个容易被忽视的问题AI 幻觉。模型在生成过程中可能编造人物、书目、历史事件甚至自己的训练数据来源。在纯虚构文学里这种幻觉有时是灵感但一旦作品涉及真实历史、真实人物或科普知识评审很可能会抓到你文中的事实错误。因此用 AI 辅助写作时凡是涉及“事实性信息”的段落都必须人工核对。9. 常见问题与排查思路下面整理了几个在实践中最容易遇到的问题以及对应的排查方式。问题现象可能原因排查方式解决方案调用接口返回 401API Key 错误或未设置环境变量检查LLM_API_KEY是否已导出且正确重新设置环境变量确认密钥没有被空格或引号污染请求返回 404Base URL 或模型名错误查看服务商文档确认请求路径和模型标识修改BASE_URL或model参数输出内容截断max_tokens太小查看响应里的finish_reason是否为length调大max_tokens或改为分段生成生成结果重复temperature 过低或 prompt 限制不足检查采样参数和提示词调高 temperature 到 0.7~0.9增加负面约束文本前后矛盾一次生成过长把长文拆成多段逐段生成并保持上下文使用多轮对话把已生成的段落放入messages作品被认定 AI 痕迹过重提示词与参数没调整好请求模型重写或人工修改过度套路的句子减少固定句式加入自定义细节和真实生活经验从排查思路能看到AI 辅助写作的真正难点不在“能不能调用”而在“如何控制生成质量”。这也是为什么前几节的参数对比和迭代脚本比单纯的 API 调用示例更有工程价值。10. 最佳实践与工程建议如果你打算把 AI 辅助写作做成一个稳定可用的工具而不是临时跑一段代码下面这些建议值得留意。第一把 API Key 放在环境变量或密钥管理服务中不要让密钥出现在代码仓库里。团队协作时尤其要注意不要把 key 提交到 Git。否则一次误操作就可能造成资源浪费或安全事故。第二建立“生成记录”。每次生成时保存 prompt、temperature、max_tokens、模型名称和输出结果。这样你可以在后续调优时回溯哪些参数组合产生了最佳文本。对于文学创作项目记录这些日志也能帮助你表明“人类在哪些环节做了选择和修改”。第三设计明确的“人工把关”节点。AI 可以一次性生成很多段落但“哪些段落能进入正文”必须由人类决定。最有效的方式是三段式流程AI 生成候选文本人工筛选并修改再用模型润色。这个流程的每一步都应留痕。第四注意版权边界。不同平台和服务商对 AI 生成内容的版权归属有不同政策。使用前请阅读相关条款。如果作品要参赛或出版最好在投稿前确认赛事方和出版社对 AI 辅助创作的态度。第五控制成本。文学创作经常需要反复调用模型很容易积累 API 费用。建议为单次任务设置max_tokens上限并避免使用超大模型做简单改写。对初稿生成和风格模仿这类任务中等规模的模型往往已经足够。这些建议的核心是同一个原则把 AI 当作“生成引擎”而不是“决策主体”。人类负责判断、修改和承担责任AI 负责扩展写作可能性的边界。这既是对作品的保护也是对读者的尊重。11. 总结与后续学习方向从 2016 年的星新一奖初审到 2023 年国内科幻赛事中的 AI 辅助作品AI 与文学奖之间的距离正在逐渐缩短。但这种缩短不是因为某个模型突然有了“文学灵魂”而是因为生成式 AI 已经能够稳定输出达到基础发表水平的文本从而让更多人愿意把它纳入创作流程。如果你对这块感兴趣下一步可以从一个更简单的目标开始打开一个 OpenAI 兼容的接口跑通前几节的代码生成一段 500 字的小说开头。然后尝试调整 temperature、修改提示词、加入人工改写。跑通之后再思考一个问题在你自己的写作流程里AI 应该承担“灵感生成”“句式润色”还是“结构建议”的角色这个领域真正的难度从来不是接口调用而是“如何定义人和 AI 的分工”。希望这篇文章能帮你找到自己的答案。也建议把文中三个脚本保存下来作为你 AI 写作工具链的第一批基础组件。