企业官网建设流程全解析

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. 核心能力速览

先给一份整体判断，方便你快速决定要不要继续往下看。

这里要特别说明一点：标题里的"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参与形态。

《计算机写小说的一天》是早期AI写作的典型代表。研究团队让模型根据预设的剧情走向、人物关系和对话模板生成小说文本，再从中挑选可读性较高的成稿投稿星新一奖。这个案例中，人类承担的是设定和筛选角色，文本生成主体是AI。它通过初审本身在当时就引发了"小说创作是否会被AI取代"的讨论，但作品最终没有获奖。

《东京都同情塔》是当前讨论度最高的案例。九段理江在获奖后接受采访时表示，小说中约5%的表述借助了ChatGPT进行辅助，整体构思、叙事结构、人物塑造仍由她独立完成。这个披露引发了日本文学界的激烈讨论，但需要强调的是，作品是通过正常文学评审流程获奖的，AI只参与了一小部分文字层面的辅助，和"AI生成了一整本小说"是两种性质完全不同的事情。

《机忆之地》是国内媒体报道相对较多的AI辅助获奖案例。据公开报道，这是一次带有实验性质的AI辅助创作尝试，作者在创作过程中使用AI辅助生成部分内容，最终作品在赛事中获得二等奖。这个案例的特殊意义在于，它让"AI辅助创作参赛并获奖"在国内有了一个具体样本，也让赛事评审在AI辅助作品面前的实际态度浮出水面。

再补充一条背景信息：2022年，Jason Allen使用Midjourney生成的图像《Théâtre D'opéra Spatial》在美国科罗拉多州博览会美术比赛中获得数字艺术类一等奖。这条不属于文学奖，但它是"AI生成内容通过艺术评审获奖"引发全球讨论的最早案例之一，很多对比文章都会把它和文学奖案例放在一起。如果后续把清单扩展成"AI获奖艺术作品总表"，这一条建议收录。

这里必须提醒：网上流传的其他"AI获奖作品"，比如某些声称获得海外奖项的AI诗歌、AI短篇小说，请务必先查原始信源。相当一部分是自媒体为了流量编造的，或者在二次传播中把"入围"夸大成"获奖"。清单记录的措辞必须精确到通过初审、进入终审还是最终获奖。

5. 案例核实方法：四个必查项

收录一个案例之前，至少查四项内容。

第一，奖项官网是否发布了获奖名单。获奖通知的最原始出处通常是奖项官网或主办方新闻稿。如果连官网都查不到，几乎可以断定是假消息。查的时候注意，很多文学奖项的官网只保留最近几年的获奖信息，更早的获奖名单可能被移到存档页面，搜索时要加年份和奖项全称。

第二，作者本人是否公开披露AI参与。九段理江的披露来自获奖后的记者会和采访，这是最可靠的信息来源。如果作者本人从未说过使用AI，即使外界再怎么猜测，清单里也不应该标注"使用AI"。可能有人会问，万一作者隐瞒了呢？清单记录的是"有公开证据的事实"，不是"可能的真相"，这两条边界必须划清楚。

第三，AI的参与方式是否有原始访谈或报道佐证。要区分"作者自己说的"和"记者推测的"。作者原话能提供"我用了AI做某件事"这层信息，记者推测则可能是过度解读。在notes字段里，应该写清楚这条信息的来源类型，比如"作者在获奖记者会上披露"或"作者接受某媒体采访时说明"。

第四，"获奖"和"入围、初审通过"是否被混淆。这是目前最常见的信息污染源。星新一奖在2016年那次AI小说通过初审的事件，长期被部分媒体写成"AI小说获奖"，直到现在仍有自媒体这样传播。清单维护者要在stage字段里写清楚实际进度，并且对明显失真的表述做纠正。

如果四个必查项全部通过，案例可以标记为verified=true。如果找不到原始信源，就标记为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, timeout=30, 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(encoding="utf-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_ascii=False, indent=2), encoding="utf-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 2>&1

Windows用户可以在任务计划程序里添加一个每日任务，触发命令指向python monitor.py。注意脚本路径和Python解释器路径都要写绝对路径，否则定时任务经常跑不起来。

7. 用大模型API做案例信息抽取与批量归档

抓取到的新闻是长文本，人工逐条阅读的成本很高，可以交给大模型做结构化抽取。把一整篇新闻喂给模型，让它输出固定的JSON字段，然后把结果写入候选清单，人工只需要看摘要做最终确认。

下面是一个通用模板，实际使用时要根据你所用的接口、模型名和认证方式进行替换。

import json import openai client = openai.OpenAI( api_key="YOUR_API_KEY", base_url="https://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( model="gpt-4o-mini", # 按实际可用模型调整，不限定具体版本 messages=[ {"role": "user", "content": PROMPT.format(news_text=news_text[:3000])} ], temperature=0.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(encoding="utf-8")) with OUTPUT_FILE.open("a", encoding="utf-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_ascii=False) + "\n") sleep(1) # 控制请求频率，避免触发限流 PENDING_FILE.write_text("[]", encoding="utf-8") if __name__ == "__main__": process_pending()

批量任务设计上建议遵守三个原则：每个请求独立失败重试；将并发控制在较低水平；处理完成之后清空待处理队列并把输出归档到以日期命名的文件中。这样即使某个请求出错，也不会影响其他条目的处理。

如果文本内容涉及未公开手稿或隐私信息，不建议发到外部API，可以通过本地部署模型的方式处理。本地部署的显存和内存占用需要根据实际模型版本测试，不能说死，但好消息是这类信息抽取任务对模型规模要求不高，小模型基本够用。

8. AI参与程度分级与判定边界

这是清单里最核心、也最容易引发争议的部分。我建议把AI参与程度划分为五个等级。

1. 无AI参与：作者明确声明未使用AI。这类作品一般不收录，只在对照研究时使用。
2. AI辅助润色：AI参与语句修改、错别字修正、措辞调整，不参与情节、人物和核心创意。可以理解为"用AI做了编辑的工作"。
3. AI辅助创作：AI参与大纲生成、角色设定、部分情节推演或素材整理，作者主导整体创作并完成最终修改。九段理江的案例最接近这一档。
4. 人机协同创作：AI和人类作者各自生成核心内容，双方在情节、结构、表达层面都有实质贡献，最终作品是共同决策的结果。
5. 全AI生成：AI生成全部文本，人类只做投稿、筛选或轻微编辑。《计算机写小说的一天》属于这一档，但人类团队提供了情节设定和筛选机制。

这个分级的意义在于，不同级别的版权归属、伦理争议和赛事规则判断完全不同。全AI生成的作品获奖，大家讨论的是"机器能否成为作者"；人类作者用AI润色的作品获奖，大家讨论的是"工具辅助的边界在哪里"。把这两件事混在一起，所有讨论都会变成鸡同鸭讲。

判定边界时要注意三点。第一，作者未披露不等于没有使用AI，清单只记录有公开证据的案例，不做猜测。第二，赛事规则本身也在变动，很多奖项正在增加AI使用披露条款，或者明确禁止AI生成内容参赛。清单可以在每个奖项下面增加一个"规则状态"字段，记录该奖项目前对AI的立场。第三，AI参与程度可能被作者在不同场合说辞不一，遇到这种情况，以最近一次、最权威的披露为准，并在notes字段里记录上下文差异。

需要特别强调：这份清单是事实记录工具，不是参赛指南。它不提供任何"如何用AI写作出书参赛且不被发现"的方法，也不鼓励在要求披露AI使用情况的赛事中隐瞒。维护和阅读清单的人应该默认遵守一个原则：作者有义务遵循赛事规则，如果规则要求披露，那就如实披露。

9. 常见问题与排查方法

维护和阅读这份清单时，容易遇到的问题大致集中在下面几类。用表格快速定位，再用后面的文字展开关键场景。

先展开第一个场景。很多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参与创作并获奖这件事，未来只会越来越多，越早建立可信的数据基础，对后续研究和判断就越有利。