2024年1月第170届芥川奖得主九段理江在获奖后公开承认她的获奖小说《东京都同情塔》约有5%的内容使用了ChatGPT辅助写作。这个新闻在当时迅速刷屏也把AI参与创作并获得文学奖从一个实验室话题变成了现实事件。而更早之前2016年日本公立函馆未来大学团队的AI小说《计算机写小说的一天》就曾通过星新一奖初审2024年国内AI辅助创作的科幻小说《机忆之地》也拿到了省级赛事奖项。这些案例分散在不同年份、不同国家、不同奖项里长期没有一个统一可检索的归档入口。List of literary award winning works created with AI这一类清单项目要解决的正是这个问题把AI参与创作并获奖或入围的文学作品统一收录、统一标注、统一核实。它不是简单地把新闻标题串起来而是一份带字段结构、参与度分级和原始信源的数据集。这篇文章会围绕三个问题展开这份清单收录什么、怎么核实、怎么持续追踪。你会看到一套可以直接落地的字段定义、一份可以当基线的真实案例表以及一个用Python配合大模型API做自动化监控和归档的示例流程。适合阅读这篇文章的读者有三类关注AIGC与版权边界的开发者、做AI创作方向研究的学生和从业者以及想在文学创作中使用AI但又担心赛事规则不明确的内容创作者。如果你只是想知道AI获奖作品有哪些前四节可以直接回答如果你想自己维护一份类似的清单后面的脚本、批处理和核实方法是重点。1. 核心能力速览先给一份整体判断方便你快速决定要不要继续往下看。能力项说明项目定位追踪并归档AI参与创作并获得文学奖项含入围的作品清单核心内容获奖作品、奖项名称、获奖时间、AI参与方式、原始信源、参与程度分级主要价值把分散在不同国家、不同年份的新闻转成可检索、可验证、可追踪的结构化数据关键能力案例核实、参与度分级、新闻源自动监控、批量归档、与赛事规则对照适用人群技术开发者、AIGC研究者、文学评论者、内容合规审核人员硬件要求不依赖显卡纯文本和数据类工作普通CPU即可运行API接入可配合大模型API做信息抽取也可用本地模型替代批量任务支持批量抓取新闻后统一清洗、去重、抽取、人工复核数据存储JSON / SQLite / CSV 均可推荐JSON或SQLite合规重点不虚构案例、保留原始信源、尊重作品版权、不提供规避赛事检测的方法这里要特别说明一点标题里的created with AI翻译成AI创作其实很模糊。现实案例里的AI参与程度差异极大有的是AI辅助润色有的是人与AI协同创作有的是全AI生成之后人工投稿。这份清单的核心价值正是把这类差异拆开记录而不是笼统地贴一个AI作品标签。2. 为什么需要这样一份清单信息分散、判定模糊、信源失真先看一组时间线。2016年日本公立函馆未来大学的团队用AI生成小说《计算机写小说的一天》投稿星新一奖并通过初审当时媒体普遍把它当作技术花边新闻。到了2024年九段理江获得芥川奖之后主动披露使用了ChatGPT讨论的层级已经变成严肃文学奖项是否应该接受AI辅助。同年《机忆之地》获得江苏省青年科普科幻作品大赛二等奖用一个小型赛事撬动了AI写作能不能算文学成就的公共讨论。这三个案例有一个共同特点它们都依赖新闻报道散播没有人做过系统归档。现在想回答目前到底有多少AI作品获奖只能靠搜索引擎一条条翻而且很容易翻到营销号加工的二手内容。维护一份清单本质上是在给这类信息建立可信的基础设施。从实际维护角度看主要有三个矛盾需要解决。第一是信息分散。获奖信息散落在文学奖官网、出版社公告、作者访谈、评委采访里。以芥川奖为例官方发布的是获奖名单但作者是否使用AI这种关键信息往往要等获奖后的记者会或后续采访才能确认。单一信源永远不够必须做多源交叉。第二是判定模糊。AI创作到底指什么是全文由AI生成还是AI参与了大纲、润色、翻译、标题拟定不同案例的AI参与方式完全不同。《东京都同情塔》属于人类作者主导、AI辅助部分文字和一篇完全由模型生成后投稿的作品在版权、伦理、赛事规则层面的性质是两回事。没有分类就没法讨论。第三是信源失真。AI获奖话题自带流量很多自媒体把通过初审写成获奖把AI辅助5%写成AI全盘创作。还有部分账号为了追热点会编造不存在的获奖案例。如果清单不做信源核实它自己会变成新的谣言源头。所以一份合格的清单必须做到有字段、有信源、有分级、有更新机制缺一不可。3. 清单的核心字段与数据模型设计清单的第一步是定字段。我的建议是用JSON存储主数据理由有三个字段可以灵活扩展天然支持嵌套结构后续导出成表格或接入数据库都很方便。下面是一份可以直接拿来用的字段设计。{ id: case-2016-hakodate, title: コンピュータが小説を書く日, title_cn: 计算机写小说的一天, award: 星新一奖, stage: 初审通过未获奖, year: 2016, country: 日本, ai_involvement: full_ai, human_role: 团队提供情节设定并筛选成稿, creator: 公立函馆未来大学研究团队, source: [NHK报道, 星新一奖官网], source_urls: [https://example.com/news1, https://example.com/news2], verified: true, notes: 早期AI小说通过严肃文学奖项初审的标志性案例 }这套字段里stage和ai_involvement是决定信息准确度最关键的两个字段。stage字段明确记录作品走到哪一步获奖、入围终审、通过初审还是被推荐但未获奖。这一条直接防止入围被误写成获奖。ai_involvement字段则记录AI参与程度我建议用枚举值控制后续会讲到五级分类。如果要用数据库存储SQLite比MySQL更适合个人维护场景。建表语句可以参考下面这份注意把source_urls拆成单独的表避免关系混乱。CREATE TABLE works ( id TEXT PRIMARY KEY, title TEXT NOT NULL, title_cn TEXT, award TEXT NOT NULL, stage TEXT NOT NULL, year INTEGER, country TEXT, ai_involvement TEXT CHECK (ai_involvement IN (none, polish, assist, co_creation, full_ai)), human_role TEXT, creator TEXT, verified INTEGER DEFAULT 0, notes TEXT ); CREATE TABLE sources ( id INTEGER PRIMARY KEY AUTOINCREMENT, work_id TEXT NOT NULL REFERENCES works(id), url TEXT NOT NULL, retrieved_at TEXT );一个实用原则是没有原始信源链接的案例不进入正式清单。如果只有自媒体截图宁可先放在待核实列表也不要直接收录。事实核查的成本远低于日后被指出收录了一个假案例的代价。4. 已收录案例与代表性作品下面给出的是可以当作基线数据的真实案例表。这些案例均来自公开报道具体细节以原始信源为准清单维护者应当逐一核实后再使用。作品奖项时间AI参与情况结果《计算机写小说的一天》星新一奖2016年全AI生成团队设置情节要素并筛选通过初审未获奖《东京都同情塔》芥川奖2024年ChatGPT辅助约5%内容作者主导创作获奖作者公开披露《机忆之地》江苏省青年科普科幻作品大赛2024年AI辅助创作二等奖三个案例的细节值得分别展开它们恰好代表了三种不同的AI参与形态。《计算机写小说的一天》是早期AI写作的典型代表。研究团队让模型根据预设的剧情走向、人物关系和对话模板生成小说文本再从中挑选可读性较高的成稿投稿星新一奖。这个案例中人类承担的是设定和筛选角色文本生成主体是AI。它通过初审本身在当时就引发了小说创作是否会被AI取代的讨论但作品最终没有获奖。《东京都同情塔》是当前讨论度最高的案例。九段理江在获奖后接受采访时表示小说中约5%的表述借助了ChatGPT进行辅助整体构思、叙事结构、人物塑造仍由她独立完成。这个披露引发了日本文学界的激烈讨论但需要强调的是作品是通过正常文学评审流程获奖的AI只参与了一小部分文字层面的辅助和AI生成了一整本小说是两种性质完全不同的事情。《机忆之地》是国内媒体报道相对较多的AI辅助获奖案例。据公开报道这是一次带有实验性质的AI辅助创作尝试作者在创作过程中使用AI辅助生成部分内容最终作品在赛事中获得二等奖。这个案例的特殊意义在于它让AI辅助创作参赛并获奖在国内有了一个具体样本也让赛事评审在AI辅助作品面前的实际态度浮出水面。再补充一条背景信息2022年Jason Allen使用Midjourney生成的图像《Théâtre Dopéra Spatial》在美国科罗拉多州博览会美术比赛中获得数字艺术类一等奖。这条不属于文学奖但它是AI生成内容通过艺术评审获奖引发全球讨论的最早案例之一很多对比文章都会把它和文学奖案例放在一起。如果后续把清单扩展成AI获奖艺术作品总表这一条建议收录。这里必须提醒网上流传的其他AI获奖作品比如某些声称获得海外奖项的AI诗歌、AI短篇小说请务必先查原始信源。相当一部分是自媒体为了流量编造的或者在二次传播中把入围夸大成获奖。清单记录的措辞必须精确到通过初审、进入终审还是最终获奖。5. 案例核实方法四个必查项收录一个案例之前至少查四项内容。第一奖项官网是否发布了获奖名单。获奖通知的最原始出处通常是奖项官网或主办方新闻稿。如果连官网都查不到几乎可以断定是假消息。查的时候注意很多文学奖项的官网只保留最近几年的获奖信息更早的获奖名单可能被移到存档页面搜索时要加年份和奖项全称。第二作者本人是否公开披露AI参与。九段理江的披露来自获奖后的记者会和采访这是最可靠的信息来源。如果作者本人从未说过使用AI即使外界再怎么猜测清单里也不应该标注使用AI。可能有人会问万一作者隐瞒了呢清单记录的是有公开证据的事实不是可能的真相这两条边界必须划清楚。第三AI的参与方式是否有原始访谈或报道佐证。要区分作者自己说的和记者推测的。作者原话能提供我用了AI做某件事这层信息记者推测则可能是过度解读。在notes字段里应该写清楚这条信息的来源类型比如作者在获奖记者会上披露或作者接受某媒体采访时说明。第四获奖和入围、初审通过是否被混淆。这是目前最常见的信息污染源。星新一奖在2016年那次AI小说通过初审的事件长期被部分媒体写成AI小说获奖直到现在仍有自媒体这样传播。清单维护者要在stage字段里写清楚实际进度并且对明显失真的表述做纠正。如果四个必查项全部通过案例可以标记为verifiedtrue。如果找不到原始信源就标记为waiting_verification并保留发现该案例的链接等后续补充。宁可让清单慢一点也不要让清单成为一个新的谣言来源。6. 自动化追踪用Python脚本监控奖项信息人工手动收集的效率和稳定性都太差建议写一个Python脚本做持续追踪。整体思路是把要监控的奖项官网、获奖新闻页、出版社公告页和RSS订阅地址放进一个配置列表定时抓取页面内容用关键词做初筛发现疑似命中后写入候选列表由人工复核后再进入正式清单。先看一个基础版本用requests抓取页面文本配合关键词列表做匹配。import requests from time import sleep MONITOR_URLS [ https://example-award.org/news, # 替换为实际奖项官网 https://example-publisher.com/rss, # 替换为出版社公告地址 ] KEYWORDS [AI, 人工智能, ChatGPT, 大模型, 生成式, AIGC] def fetch_text(url: str) - str: resp requests.get(url, timeout30, headers{ User-Agent: Mozilla/5.0 (compatible; award-list-tracker/1.0) }) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.text def scan(url: str) - list: text fetch_text(url) return [kw for kw in KEYWORDS if kw in text] for url in MONITOR_URLS: try: hits scan(url) print(f[{url}] 命中关键词: {hits}) except Exception as exc: print(f[{url}] 抓取失败: {exc}) sleep(2)这个脚本只是雏形。实际使用时还需要处理几个问题很多奖项官网是动态渲染页面requests拿不到完整DOM需要改用Selenium或Playwright某些站点有反爬限制要在合理频率内抓取不能给目标网站造成压力页面编码不统一的时候用apparent_encoding自动判断编码可以避免中文乱码。更实用的方案是直接解析RSS。RSS格式稳定、结构清晰、对站点压力小非常适合做奖项和出版社公告的订阅。import feedparser import json from pathlib import Path RSS_SOURCES [ https://example-award.org/feed.xml, # 替换为实际RSS地址 https://example-literary-magazine.com/rss, ] PENDING_FILE Path(pending_candidates.json) def update_pending(candidates: list) - None: existing [] if PENDING_FILE.exists(): existing json.loads(PENDING_FILE.read_text(encodingutf-8)) seen {item[link] for item in existing} new_items [c for c in candidates if c[link] not in seen] PENDING_FILE.write_text( json.dumps(existing new_items, ensure_asciiFalse, indent2), encodingutf-8 ) print(f新增 {len(new_items)} 条候选当前候选总数 {len(existing) len(new_items)}) for url in RSS_SOURCES: feed feedparser.parse(url) candidates [] for entry in feed.entries: text entry.get(title, ) entry.get(summary, ) if any(kw in text for kw in [AI, 人工智能, ChatGPT, 获奖]): candidates.append({ title: entry.get(title, ), link: entry.get(link, ), published: entry.get(published, ), source_rss: url, keyword_hit: True }) if candidates: update_pending(candidates)这个版本相比第一个脚本进步在两点去重逻辑放进了函数里避免同一个链接被重复收录候选结果统一写入JSON文件后续可以批量交给大模型抽取。定时执行可以用crontab也可以用系统的计划任务。以Linux为例每天上午9点跑一次0 9 * * * cd /path/to/award-list /usr/bin/python3 monitor.py monitor.log 21Windows用户可以在任务计划程序里添加一个每日任务触发命令指向python monitor.py。注意脚本路径和Python解释器路径都要写绝对路径否则定时任务经常跑不起来。7. 用大模型API做案例信息抽取与批量归档抓取到的新闻是长文本人工逐条阅读的成本很高可以交给大模型做结构化抽取。把一整篇新闻喂给模型让它输出固定的JSON字段然后把结果写入候选清单人工只需要看摘要做最终确认。下面是一个通用模板实际使用时要根据你所用的接口、模型名和认证方式进行替换。import json import openai client openai.OpenAI( api_keyYOUR_API_KEY, base_urlhttps://your-api-endpoint # 替换为实际服务地址本地部署则填本地地址 ) PROMPT 请从以下新闻中抽取与AI参与创作并获得文学奖项相关的信息。 只输出JSON不要输出任何多余文字。 字段要求 - title: 作品名 - award: 奖项名 - year: 年份 - country: 国家或地区 - ai_involvement: 枚举值polish/assist/co_creation/full_ai - result: award/placeholder/fail - quote: 原文中与AI使用相关的关键句最多100字 新闻正文 {news_text} def extract_candidate(news_text: str) - dict: resp client.chat.completions.create( modelgpt-4o-mini, # 按实际可用模型调整不限定具体版本 messages[ {role: user, content: PROMPT.format(news_textnews_text[:3000])} ], temperature0.1, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) if __name__ __main__: sample 某文学奖项公布获奖名单作者在采访中承认使用AI辅助改写部分段落。 print(extract_candidate(sample))这段代码有三个需要注意的地方。第一response_format参数并非所有接口都支持如果不支持就去掉改用提示词强制要求输出JSON。第二模型输出的JSON偶尔会有键名不一致的情况建议在解析之后做一层字段校验缺字段就补充默认值。第三temperature建议调低到0.1到0.2之间让抽取结果更稳定。批量归档时可以把上一节生成的pending_candidates.json逐条读取循环调用抽取函数把结果写入新的JSONL文件。每条数据保留原始链接方便后续人工回查。import json from pathlib import Path from time import sleep PENDING_FILE Path(pending_candidates.json) OUTPUT_FILE Path(extracted_candidates.jsonl) def process_pending(): if not PENDING_FILE.exists(): print(无待处理候选) return pending json.loads(PENDING_FILE.read_text(encodingutf-8)) with OUTPUT_FILE.open(a, encodingutf-8) as f: for item in pending: try: result extract_candidate(item.get(title, ) item.get(link, )) except Exception as exc: print(f抽取失败: {item.get(link)} - {exc}) continue record {**item, extraction: result} f.write(json.dumps(record, ensure_asciiFalse) \n) sleep(1) # 控制请求频率避免触发限流 PENDING_FILE.write_text([], encodingutf-8) if __name__ __main__: process_pending()批量任务设计上建议遵守三个原则每个请求独立失败重试将并发控制在较低水平处理完成之后清空待处理队列并把输出归档到以日期命名的文件中。这样即使某个请求出错也不会影响其他条目的处理。如果文本内容涉及未公开手稿或隐私信息不建议发到外部API可以通过本地部署模型的方式处理。本地部署的显存和内存占用需要根据实际模型版本测试不能说死但好消息是这类信息抽取任务对模型规模要求不高小模型基本够用。8. AI参与程度分级与判定边界这是清单里最核心、也最容易引发争议的部分。我建议把AI参与程度划分为五个等级。无AI参与作者明确声明未使用AI。这类作品一般不收录只在对照研究时使用。AI辅助润色AI参与语句修改、错别字修正、措辞调整不参与情节、人物和核心创意。可以理解为用AI做了编辑的工作。AI辅助创作AI参与大纲生成、角色设定、部分情节推演或素材整理作者主导整体创作并完成最终修改。九段理江的案例最接近这一档。人机协同创作AI和人类作者各自生成核心内容双方在情节、结构、表达层面都有实质贡献最终作品是共同决策的结果。全AI生成AI生成全部文本人类只做投稿、筛选或轻微编辑。《计算机写小说的一天》属于这一档但人类团队提供了情节设定和筛选机制。这个分级的意义在于不同级别的版权归属、伦理争议和赛事规则判断完全不同。全AI生成的作品获奖大家讨论的是机器能否成为作者人类作者用AI润色的作品获奖大家讨论的是工具辅助的边界在哪里。把这两件事混在一起所有讨论都会变成鸡同鸭讲。判定边界时要注意三点。第一作者未披露不等于没有使用AI清单只记录有公开证据的案例不做猜测。第二赛事规则本身也在变动很多奖项正在增加AI使用披露条款或者明确禁止AI生成内容参赛。清单可以在每个奖项下面增加一个规则状态字段记录该奖项目前对AI的立场。第三AI参与程度可能被作者在不同场合说辞不一遇到这种情况以最近一次、最权威的披露为准并在notes字段里记录上下文差异。需要特别强调这份清单是事实记录工具不是参赛指南。它不提供任何如何用AI写作出书参赛且不被发现的方法也不鼓励在要求披露AI使用情况的赛事中隐瞒。维护和阅读清单的人应该默认遵守一个原则作者有义务遵循赛事规则如果规则要求披露那就如实披露。9. 常见问题与排查方法维护和阅读这份清单时容易遇到的问题大致集中在下面几类。用表格快速定位再用后面的文字展开关键场景。问题现象可能原因排查方式解决方案搜到多个版本的AI获奖信息自媒体转载失真找到奖项官网或主办方公告以官网为准注明信源分不清获奖和入围标题党混淆阶段查原始获奖名单stage字段写清楚入围单独标注作者未披露却传言使用AI猜测被当作事实查作者采访和本人发言没有公开证据不收录同一件作品多篇报道细节矛盾报道口径不同对比多家媒体优先一手信源notes里记录分歧抓取脚本命中大量无关文章关键词太宽泛增加奖项名与获奖词组合规则用白名单和黑名单组合过滤大模型抽取字段为空新闻文本不含完整信息检查原文长度和信息完整度增加示例或者转人工标注外部API处理敏感文本有顾虑数据合规问题评估文本隐私风险改用本地模型或脱敏后再处理定时任务不执行脚本路径或Python路径错误查看定时任务日志改为绝对路径并重定向日志先展开第一个场景。很多AI获奖话题的文章标题写AI作品获奖正文却写着通过初审。第一眼看很容易忽略但这两个表述的差异是根本性的。通过初审意味着作品进入评审环节但没拿到奖项获奖意味着它击败了其他作品拿到正式名次。清单在stage字段上必须一刀切不允许模糊表述。第二个典型场景是大模型抽取结果不稳定。新闻文本本身信息不完整时模型会猜一旦猜错结构化输出的误导性比自由文本更大。我的建议是大模型只做初筛人工复核覆盖所有正式收录条目。重点检查ai_involvement这个字段因为模型很难从字面判断AI到底参与了多少这个判断最终要交给看过原始报道的人。第三个场景是采集脚本命中太多无关内容。比如AIGC这个关键词可能出现在任何行业新闻里和文学奖项毫无关系。解决办法是给关键词加上上下文限定比如只匹配AI获奖小说人工智能文学奖入围这样的组合规则而不是单关键词命中。也可以用排除词表把科技融资AI芯片这类明显不相关的内容过滤掉。10. 最佳实践与合规提醒最后这部分是工程层面和合规层面的建议每条都是维护这类清单时必须遵守的底线。第一字段设计要留出待核实状态。不是每条新闻都能立刻确认给候选案例一个缓冲区比直接收录更安全。把waiting_verification单独放进一个文件或一个状态值每周集中处理一次而不是随手收录随手标注。第二原始链接是底线。每条正式收录的案例必须带原始信源URL或对应的出版信息方便读者回查。如果发现某个链接已经失效在notes里记录失效日期不要直接删除案例。历史记录本身有参考价值删掉反而会让清单出现信息断层。第三关注赛事规则变化。文学奖项对AI的规则正处于快速变动期。有的奖项已经明确要求作者披露AI使用情况有的还在评估是否修改章程还有的默认按传统方式处理。清单可以增加一个奖项规则状态字段记录每个奖项最近一次关于AI的表态这样就能看出哪些赛事对AI开放、哪些还在观望。第四版权合规。清单本身只收录事实信息包括作品名、奖项、年份、作者公开披露的内容不转载作品原文。如果要引用作品片段控制在合理引用范围并注明出处。整理这些信息不等于获得作品版权两者必须分开。第五隐私和授权边界。涉及作者个人隐私、未公开手稿、非公开访谈的内容不要录入清单保护作者隐私是基本要求。如果清单要公开发布最好在发布前通知涉及的作品作者说明这份清单的目的和收录原则。这一点在涉及国内作者和机构时尤其重要。第六不要把清单做成AI参赛教程。既不要收录如何规避AI检测的内容也不要在任何章节暗示读者可以隐瞒AI使用情况去参赛。清单是事实记录工具它的价值在于让AI创作获奖这件事更加透明而不是帮助任何人钻规则空子。11. 总结与下一步这份清单最值得尝试的点是把AI获奖文学从一个新闻热点变成一套可验证的数据结构。只要字段设计得当、信源核实到位、参与度分级足够细它就能成为AI创作研究领域一个长期可用的参考基线。建议第一次动手时按三个步骤走。第一步先把前面给出的三个真实案例按JSON格式录入检查字段设计是否够用比如获奖和入围是否需要拆成不同字段AI参与程度的分级是否符合直觉。第二步把几个文学奖项的官网或RSS地址加入监控脚本跑一周看命中结果重点观察关键词匹配的准确率和误报率。第三步用大模型API走一遍抽取流程从待处理队列到JSONL输出确认批量任务能稳定跑通。三步全部跑通这份清单就算真正建立起来了。最容易踩的坑仍然是信源。很多AI获奖消息在传播过程中被层层加码从入围变成获奖从辅助变成全AI创作。处理这类信息时宁可少收一个案例也不要收录未经证实的消息。清单的长期价值恰恰建立在可回查之上一旦出现被证伪的条目整份清单的公信力都会打折扣。等这套流程稳定之后还可以把追踪范围从文学奖扩展到美术、音乐、影视、设计等更多AIGC获奖场景。AI参与创作并获奖这件事未来只会越来越多越早建立可信的数据基础对后续研究和判断就越有利。 AI创作获奖文学作品清单：字段设计、核实与自动化追踪
2024年1月第170届芥川奖得主九段理江在获奖后公开承认她的获奖小说《东京都同情塔》约有5%的内容使用了ChatGPT辅助写作。这个新闻在当时迅速刷屏也把AI参与创作并获得文学奖从一个实验室话题变成了现实事件。而更早之前2016年日本公立函馆未来大学团队的AI小说《计算机写小说的一天》就曾通过星新一奖初审2024年国内AI辅助创作的科幻小说《机忆之地》也拿到了省级赛事奖项。这些案例分散在不同年份、不同国家、不同奖项里长期没有一个统一可检索的归档入口。List of literary award winning works created with AI这一类清单项目要解决的正是这个问题把AI参与创作并获奖或入围的文学作品统一收录、统一标注、统一核实。它不是简单地把新闻标题串起来而是一份带字段结构、参与度分级和原始信源的数据集。这篇文章会围绕三个问题展开这份清单收录什么、怎么核实、怎么持续追踪。你会看到一套可以直接落地的字段定义、一份可以当基线的真实案例表以及一个用Python配合大模型API做自动化监控和归档的示例流程。适合阅读这篇文章的读者有三类关注AIGC与版权边界的开发者、做AI创作方向研究的学生和从业者以及想在文学创作中使用AI但又担心赛事规则不明确的内容创作者。如果你只是想知道AI获奖作品有哪些前四节可以直接回答如果你想自己维护一份类似的清单后面的脚本、批处理和核实方法是重点。1. 核心能力速览先给一份整体判断方便你快速决定要不要继续往下看。能力项说明项目定位追踪并归档AI参与创作并获得文学奖项含入围的作品清单核心内容获奖作品、奖项名称、获奖时间、AI参与方式、原始信源、参与程度分级主要价值把分散在不同国家、不同年份的新闻转成可检索、可验证、可追踪的结构化数据关键能力案例核实、参与度分级、新闻源自动监控、批量归档、与赛事规则对照适用人群技术开发者、AIGC研究者、文学评论者、内容合规审核人员硬件要求不依赖显卡纯文本和数据类工作普通CPU即可运行API接入可配合大模型API做信息抽取也可用本地模型替代批量任务支持批量抓取新闻后统一清洗、去重、抽取、人工复核数据存储JSON / SQLite / CSV 均可推荐JSON或SQLite合规重点不虚构案例、保留原始信源、尊重作品版权、不提供规避赛事检测的方法这里要特别说明一点标题里的created with AI翻译成AI创作其实很模糊。现实案例里的AI参与程度差异极大有的是AI辅助润色有的是人与AI协同创作有的是全AI生成之后人工投稿。这份清单的核心价值正是把这类差异拆开记录而不是笼统地贴一个AI作品标签。2. 为什么需要这样一份清单信息分散、判定模糊、信源失真先看一组时间线。2016年日本公立函馆未来大学的团队用AI生成小说《计算机写小说的一天》投稿星新一奖并通过初审当时媒体普遍把它当作技术花边新闻。到了2024年九段理江获得芥川奖之后主动披露使用了ChatGPT讨论的层级已经变成严肃文学奖项是否应该接受AI辅助。同年《机忆之地》获得江苏省青年科普科幻作品大赛二等奖用一个小型赛事撬动了AI写作能不能算文学成就的公共讨论。这三个案例有一个共同特点它们都依赖新闻报道散播没有人做过系统归档。现在想回答目前到底有多少AI作品获奖只能靠搜索引擎一条条翻而且很容易翻到营销号加工的二手内容。维护一份清单本质上是在给这类信息建立可信的基础设施。从实际维护角度看主要有三个矛盾需要解决。第一是信息分散。获奖信息散落在文学奖官网、出版社公告、作者访谈、评委采访里。以芥川奖为例官方发布的是获奖名单但作者是否使用AI这种关键信息往往要等获奖后的记者会或后续采访才能确认。单一信源永远不够必须做多源交叉。第二是判定模糊。AI创作到底指什么是全文由AI生成还是AI参与了大纲、润色、翻译、标题拟定不同案例的AI参与方式完全不同。《东京都同情塔》属于人类作者主导、AI辅助部分文字和一篇完全由模型生成后投稿的作品在版权、伦理、赛事规则层面的性质是两回事。没有分类就没法讨论。第三是信源失真。AI获奖话题自带流量很多自媒体把通过初审写成获奖把AI辅助5%写成AI全盘创作。还有部分账号为了追热点会编造不存在的获奖案例。如果清单不做信源核实它自己会变成新的谣言源头。所以一份合格的清单必须做到有字段、有信源、有分级、有更新机制缺一不可。3. 清单的核心字段与数据模型设计清单的第一步是定字段。我的建议是用JSON存储主数据理由有三个字段可以灵活扩展天然支持嵌套结构后续导出成表格或接入数据库都很方便。下面是一份可以直接拿来用的字段设计。{ id: case-2016-hakodate, title: コンピュータが小説を書く日, title_cn: 计算机写小说的一天, award: 星新一奖, stage: 初审通过未获奖, year: 2016, country: 日本, ai_involvement: full_ai, human_role: 团队提供情节设定并筛选成稿, creator: 公立函馆未来大学研究团队, source: [NHK报道, 星新一奖官网], source_urls: [https://example.com/news1, https://example.com/news2], verified: true, notes: 早期AI小说通过严肃文学奖项初审的标志性案例 }这套字段里stage和ai_involvement是决定信息准确度最关键的两个字段。stage字段明确记录作品走到哪一步获奖、入围终审、通过初审还是被推荐但未获奖。这一条直接防止入围被误写成获奖。ai_involvement字段则记录AI参与程度我建议用枚举值控制后续会讲到五级分类。如果要用数据库存储SQLite比MySQL更适合个人维护场景。建表语句可以参考下面这份注意把source_urls拆成单独的表避免关系混乱。CREATE TABLE works ( id TEXT PRIMARY KEY, title TEXT NOT NULL, title_cn TEXT, award TEXT NOT NULL, stage TEXT NOT NULL, year INTEGER, country TEXT, ai_involvement TEXT CHECK (ai_involvement IN (none, polish, assist, co_creation, full_ai)), human_role TEXT, creator TEXT, verified INTEGER DEFAULT 0, notes TEXT ); CREATE TABLE sources ( id INTEGER PRIMARY KEY AUTOINCREMENT, work_id TEXT NOT NULL REFERENCES works(id), url TEXT NOT NULL, retrieved_at TEXT );一个实用原则是没有原始信源链接的案例不进入正式清单。如果只有自媒体截图宁可先放在待核实列表也不要直接收录。事实核查的成本远低于日后被指出收录了一个假案例的代价。4. 已收录案例与代表性作品下面给出的是可以当作基线数据的真实案例表。这些案例均来自公开报道具体细节以原始信源为准清单维护者应当逐一核实后再使用。作品奖项时间AI参与情况结果《计算机写小说的一天》星新一奖2016年全AI生成团队设置情节要素并筛选通过初审未获奖《东京都同情塔》芥川奖2024年ChatGPT辅助约5%内容作者主导创作获奖作者公开披露《机忆之地》江苏省青年科普科幻作品大赛2024年AI辅助创作二等奖三个案例的细节值得分别展开它们恰好代表了三种不同的AI参与形态。《计算机写小说的一天》是早期AI写作的典型代表。研究团队让模型根据预设的剧情走向、人物关系和对话模板生成小说文本再从中挑选可读性较高的成稿投稿星新一奖。这个案例中人类承担的是设定和筛选角色文本生成主体是AI。它通过初审本身在当时就引发了小说创作是否会被AI取代的讨论但作品最终没有获奖。《东京都同情塔》是当前讨论度最高的案例。九段理江在获奖后接受采访时表示小说中约5%的表述借助了ChatGPT进行辅助整体构思、叙事结构、人物塑造仍由她独立完成。这个披露引发了日本文学界的激烈讨论但需要强调的是作品是通过正常文学评审流程获奖的AI只参与了一小部分文字层面的辅助和AI生成了一整本小说是两种性质完全不同的事情。《机忆之地》是国内媒体报道相对较多的AI辅助获奖案例。据公开报道这是一次带有实验性质的AI辅助创作尝试作者在创作过程中使用AI辅助生成部分内容最终作品在赛事中获得二等奖。这个案例的特殊意义在于它让AI辅助创作参赛并获奖在国内有了一个具体样本也让赛事评审在AI辅助作品面前的实际态度浮出水面。再补充一条背景信息2022年Jason Allen使用Midjourney生成的图像《Théâtre Dopéra Spatial》在美国科罗拉多州博览会美术比赛中获得数字艺术类一等奖。这条不属于文学奖但它是AI生成内容通过艺术评审获奖引发全球讨论的最早案例之一很多对比文章都会把它和文学奖案例放在一起。如果后续把清单扩展成AI获奖艺术作品总表这一条建议收录。这里必须提醒网上流传的其他AI获奖作品比如某些声称获得海外奖项的AI诗歌、AI短篇小说请务必先查原始信源。相当一部分是自媒体为了流量编造的或者在二次传播中把入围夸大成获奖。清单记录的措辞必须精确到通过初审、进入终审还是最终获奖。5. 案例核实方法四个必查项收录一个案例之前至少查四项内容。第一奖项官网是否发布了获奖名单。获奖通知的最原始出处通常是奖项官网或主办方新闻稿。如果连官网都查不到几乎可以断定是假消息。查的时候注意很多文学奖项的官网只保留最近几年的获奖信息更早的获奖名单可能被移到存档页面搜索时要加年份和奖项全称。第二作者本人是否公开披露AI参与。九段理江的披露来自获奖后的记者会和采访这是最可靠的信息来源。如果作者本人从未说过使用AI即使外界再怎么猜测清单里也不应该标注使用AI。可能有人会问万一作者隐瞒了呢清单记录的是有公开证据的事实不是可能的真相这两条边界必须划清楚。第三AI的参与方式是否有原始访谈或报道佐证。要区分作者自己说的和记者推测的。作者原话能提供我用了AI做某件事这层信息记者推测则可能是过度解读。在notes字段里应该写清楚这条信息的来源类型比如作者在获奖记者会上披露或作者接受某媒体采访时说明。第四获奖和入围、初审通过是否被混淆。这是目前最常见的信息污染源。星新一奖在2016年那次AI小说通过初审的事件长期被部分媒体写成AI小说获奖直到现在仍有自媒体这样传播。清单维护者要在stage字段里写清楚实际进度并且对明显失真的表述做纠正。如果四个必查项全部通过案例可以标记为verifiedtrue。如果找不到原始信源就标记为waiting_verification并保留发现该案例的链接等后续补充。宁可让清单慢一点也不要让清单成为一个新的谣言来源。6. 自动化追踪用Python脚本监控奖项信息人工手动收集的效率和稳定性都太差建议写一个Python脚本做持续追踪。整体思路是把要监控的奖项官网、获奖新闻页、出版社公告页和RSS订阅地址放进一个配置列表定时抓取页面内容用关键词做初筛发现疑似命中后写入候选列表由人工复核后再进入正式清单。先看一个基础版本用requests抓取页面文本配合关键词列表做匹配。import requests from time import sleep MONITOR_URLS [ https://example-award.org/news, # 替换为实际奖项官网 https://example-publisher.com/rss, # 替换为出版社公告地址 ] KEYWORDS [AI, 人工智能, ChatGPT, 大模型, 生成式, AIGC] def fetch_text(url: str) - str: resp requests.get(url, timeout30, headers{ User-Agent: Mozilla/5.0 (compatible; award-list-tracker/1.0) }) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.text def scan(url: str) - list: text fetch_text(url) return [kw for kw in KEYWORDS if kw in text] for url in MONITOR_URLS: try: hits scan(url) print(f[{url}] 命中关键词: {hits}) except Exception as exc: print(f[{url}] 抓取失败: {exc}) sleep(2)这个脚本只是雏形。实际使用时还需要处理几个问题很多奖项官网是动态渲染页面requests拿不到完整DOM需要改用Selenium或Playwright某些站点有反爬限制要在合理频率内抓取不能给目标网站造成压力页面编码不统一的时候用apparent_encoding自动判断编码可以避免中文乱码。更实用的方案是直接解析RSS。RSS格式稳定、结构清晰、对站点压力小非常适合做奖项和出版社公告的订阅。import feedparser import json from pathlib import Path RSS_SOURCES [ https://example-award.org/feed.xml, # 替换为实际RSS地址 https://example-literary-magazine.com/rss, ] PENDING_FILE Path(pending_candidates.json) def update_pending(candidates: list) - None: existing [] if PENDING_FILE.exists(): existing json.loads(PENDING_FILE.read_text(encodingutf-8)) seen {item[link] for item in existing} new_items [c for c in candidates if c[link] not in seen] PENDING_FILE.write_text( json.dumps(existing new_items, ensure_asciiFalse, indent2), encodingutf-8 ) print(f新增 {len(new_items)} 条候选当前候选总数 {len(existing) len(new_items)}) for url in RSS_SOURCES: feed feedparser.parse(url) candidates [] for entry in feed.entries: text entry.get(title, ) entry.get(summary, ) if any(kw in text for kw in [AI, 人工智能, ChatGPT, 获奖]): candidates.append({ title: entry.get(title, ), link: entry.get(link, ), published: entry.get(published, ), source_rss: url, keyword_hit: True }) if candidates: update_pending(candidates)这个版本相比第一个脚本进步在两点去重逻辑放进了函数里避免同一个链接被重复收录候选结果统一写入JSON文件后续可以批量交给大模型抽取。定时执行可以用crontab也可以用系统的计划任务。以Linux为例每天上午9点跑一次0 9 * * * cd /path/to/award-list /usr/bin/python3 monitor.py monitor.log 21Windows用户可以在任务计划程序里添加一个每日任务触发命令指向python monitor.py。注意脚本路径和Python解释器路径都要写绝对路径否则定时任务经常跑不起来。7. 用大模型API做案例信息抽取与批量归档抓取到的新闻是长文本人工逐条阅读的成本很高可以交给大模型做结构化抽取。把一整篇新闻喂给模型让它输出固定的JSON字段然后把结果写入候选清单人工只需要看摘要做最终确认。下面是一个通用模板实际使用时要根据你所用的接口、模型名和认证方式进行替换。import json import openai client openai.OpenAI( api_keyYOUR_API_KEY, base_urlhttps://your-api-endpoint # 替换为实际服务地址本地部署则填本地地址 ) PROMPT 请从以下新闻中抽取与AI参与创作并获得文学奖项相关的信息。 只输出JSON不要输出任何多余文字。 字段要求 - title: 作品名 - award: 奖项名 - year: 年份 - country: 国家或地区 - ai_involvement: 枚举值polish/assist/co_creation/full_ai - result: award/placeholder/fail - quote: 原文中与AI使用相关的关键句最多100字 新闻正文 {news_text} def extract_candidate(news_text: str) - dict: resp client.chat.completions.create( modelgpt-4o-mini, # 按实际可用模型调整不限定具体版本 messages[ {role: user, content: PROMPT.format(news_textnews_text[:3000])} ], temperature0.1, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) if __name__ __main__: sample 某文学奖项公布获奖名单作者在采访中承认使用AI辅助改写部分段落。 print(extract_candidate(sample))这段代码有三个需要注意的地方。第一response_format参数并非所有接口都支持如果不支持就去掉改用提示词强制要求输出JSON。第二模型输出的JSON偶尔会有键名不一致的情况建议在解析之后做一层字段校验缺字段就补充默认值。第三temperature建议调低到0.1到0.2之间让抽取结果更稳定。批量归档时可以把上一节生成的pending_candidates.json逐条读取循环调用抽取函数把结果写入新的JSONL文件。每条数据保留原始链接方便后续人工回查。import json from pathlib import Path from time import sleep PENDING_FILE Path(pending_candidates.json) OUTPUT_FILE Path(extracted_candidates.jsonl) def process_pending(): if not PENDING_FILE.exists(): print(无待处理候选) return pending json.loads(PENDING_FILE.read_text(encodingutf-8)) with OUTPUT_FILE.open(a, encodingutf-8) as f: for item in pending: try: result extract_candidate(item.get(title, ) item.get(link, )) except Exception as exc: print(f抽取失败: {item.get(link)} - {exc}) continue record {**item, extraction: result} f.write(json.dumps(record, ensure_asciiFalse) \n) sleep(1) # 控制请求频率避免触发限流 PENDING_FILE.write_text([], encodingutf-8) if __name__ __main__: process_pending()批量任务设计上建议遵守三个原则每个请求独立失败重试将并发控制在较低水平处理完成之后清空待处理队列并把输出归档到以日期命名的文件中。这样即使某个请求出错也不会影响其他条目的处理。如果文本内容涉及未公开手稿或隐私信息不建议发到外部API可以通过本地部署模型的方式处理。本地部署的显存和内存占用需要根据实际模型版本测试不能说死但好消息是这类信息抽取任务对模型规模要求不高小模型基本够用。8. AI参与程度分级与判定边界这是清单里最核心、也最容易引发争议的部分。我建议把AI参与程度划分为五个等级。无AI参与作者明确声明未使用AI。这类作品一般不收录只在对照研究时使用。AI辅助润色AI参与语句修改、错别字修正、措辞调整不参与情节、人物和核心创意。可以理解为用AI做了编辑的工作。AI辅助创作AI参与大纲生成、角色设定、部分情节推演或素材整理作者主导整体创作并完成最终修改。九段理江的案例最接近这一档。人机协同创作AI和人类作者各自生成核心内容双方在情节、结构、表达层面都有实质贡献最终作品是共同决策的结果。全AI生成AI生成全部文本人类只做投稿、筛选或轻微编辑。《计算机写小说的一天》属于这一档但人类团队提供了情节设定和筛选机制。这个分级的意义在于不同级别的版权归属、伦理争议和赛事规则判断完全不同。全AI生成的作品获奖大家讨论的是机器能否成为作者人类作者用AI润色的作品获奖大家讨论的是工具辅助的边界在哪里。把这两件事混在一起所有讨论都会变成鸡同鸭讲。判定边界时要注意三点。第一作者未披露不等于没有使用AI清单只记录有公开证据的案例不做猜测。第二赛事规则本身也在变动很多奖项正在增加AI使用披露条款或者明确禁止AI生成内容参赛。清单可以在每个奖项下面增加一个规则状态字段记录该奖项目前对AI的立场。第三AI参与程度可能被作者在不同场合说辞不一遇到这种情况以最近一次、最权威的披露为准并在notes字段里记录上下文差异。需要特别强调这份清单是事实记录工具不是参赛指南。它不提供任何如何用AI写作出书参赛且不被发现的方法也不鼓励在要求披露AI使用情况的赛事中隐瞒。维护和阅读清单的人应该默认遵守一个原则作者有义务遵循赛事规则如果规则要求披露那就如实披露。9. 常见问题与排查方法维护和阅读这份清单时容易遇到的问题大致集中在下面几类。用表格快速定位再用后面的文字展开关键场景。问题现象可能原因排查方式解决方案搜到多个版本的AI获奖信息自媒体转载失真找到奖项官网或主办方公告以官网为准注明信源分不清获奖和入围标题党混淆阶段查原始获奖名单stage字段写清楚入围单独标注作者未披露却传言使用AI猜测被当作事实查作者采访和本人发言没有公开证据不收录同一件作品多篇报道细节矛盾报道口径不同对比多家媒体优先一手信源notes里记录分歧抓取脚本命中大量无关文章关键词太宽泛增加奖项名与获奖词组合规则用白名单和黑名单组合过滤大模型抽取字段为空新闻文本不含完整信息检查原文长度和信息完整度增加示例或者转人工标注外部API处理敏感文本有顾虑数据合规问题评估文本隐私风险改用本地模型或脱敏后再处理定时任务不执行脚本路径或Python路径错误查看定时任务日志改为绝对路径并重定向日志先展开第一个场景。很多AI获奖话题的文章标题写AI作品获奖正文却写着通过初审。第一眼看很容易忽略但这两个表述的差异是根本性的。通过初审意味着作品进入评审环节但没拿到奖项获奖意味着它击败了其他作品拿到正式名次。清单在stage字段上必须一刀切不允许模糊表述。第二个典型场景是大模型抽取结果不稳定。新闻文本本身信息不完整时模型会猜一旦猜错结构化输出的误导性比自由文本更大。我的建议是大模型只做初筛人工复核覆盖所有正式收录条目。重点检查ai_involvement这个字段因为模型很难从字面判断AI到底参与了多少这个判断最终要交给看过原始报道的人。第三个场景是采集脚本命中太多无关内容。比如AIGC这个关键词可能出现在任何行业新闻里和文学奖项毫无关系。解决办法是给关键词加上上下文限定比如只匹配AI获奖小说人工智能文学奖入围这样的组合规则而不是单关键词命中。也可以用排除词表把科技融资AI芯片这类明显不相关的内容过滤掉。10. 最佳实践与合规提醒最后这部分是工程层面和合规层面的建议每条都是维护这类清单时必须遵守的底线。第一字段设计要留出待核实状态。不是每条新闻都能立刻确认给候选案例一个缓冲区比直接收录更安全。把waiting_verification单独放进一个文件或一个状态值每周集中处理一次而不是随手收录随手标注。第二原始链接是底线。每条正式收录的案例必须带原始信源URL或对应的出版信息方便读者回查。如果发现某个链接已经失效在notes里记录失效日期不要直接删除案例。历史记录本身有参考价值删掉反而会让清单出现信息断层。第三关注赛事规则变化。文学奖项对AI的规则正处于快速变动期。有的奖项已经明确要求作者披露AI使用情况有的还在评估是否修改章程还有的默认按传统方式处理。清单可以增加一个奖项规则状态字段记录每个奖项最近一次关于AI的表态这样就能看出哪些赛事对AI开放、哪些还在观望。第四版权合规。清单本身只收录事实信息包括作品名、奖项、年份、作者公开披露的内容不转载作品原文。如果要引用作品片段控制在合理引用范围并注明出处。整理这些信息不等于获得作品版权两者必须分开。第五隐私和授权边界。涉及作者个人隐私、未公开手稿、非公开访谈的内容不要录入清单保护作者隐私是基本要求。如果清单要公开发布最好在发布前通知涉及的作品作者说明这份清单的目的和收录原则。这一点在涉及国内作者和机构时尤其重要。第六不要把清单做成AI参赛教程。既不要收录如何规避AI检测的内容也不要在任何章节暗示读者可以隐瞒AI使用情况去参赛。清单是事实记录工具它的价值在于让AI创作获奖这件事更加透明而不是帮助任何人钻规则空子。11. 总结与下一步这份清单最值得尝试的点是把AI获奖文学从一个新闻热点变成一套可验证的数据结构。只要字段设计得当、信源核实到位、参与度分级足够细它就能成为AI创作研究领域一个长期可用的参考基线。建议第一次动手时按三个步骤走。第一步先把前面给出的三个真实案例按JSON格式录入检查字段设计是否够用比如获奖和入围是否需要拆成不同字段AI参与程度的分级是否符合直觉。第二步把几个文学奖项的官网或RSS地址加入监控脚本跑一周看命中结果重点观察关键词匹配的准确率和误报率。第三步用大模型API走一遍抽取流程从待处理队列到JSONL输出确认批量任务能稳定跑通。三步全部跑通这份清单就算真正建立起来了。最容易踩的坑仍然是信源。很多AI获奖消息在传播过程中被层层加码从入围变成获奖从辅助变成全AI创作。处理这类信息时宁可少收一个案例也不要收录未经证实的消息。清单的长期价值恰恰建立在可回查之上一旦出现被证伪的条目整份清单的公信力都会打折扣。等这套流程稳定之后还可以把追踪范围从文学奖扩展到美术、音乐、影视、设计等更多AIGC获奖场景。AI参与创作并获奖这件事未来只会越来越多越早建立可信的数据基础对后续研究和判断就越有利。