惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
C
Check Point Blog
博客园 - Franky
V
Visual Studio Blog
云风的 BLOG
云风的 BLOG
aimingoo的专栏
aimingoo的专栏
Microsoft Security Blog
Microsoft Security Blog
V2EX - 技术
V2EX - 技术
AI
AI
Hacker News - Newest:
Hacker News - Newest: "LLM"
Jina AI
Jina AI
S
Security @ Cisco Blogs
Security Archives - TechRepublic
Security Archives - TechRepublic
H
Hacker News: Front Page
H
Hackread – Cybersecurity News, Data Breaches, AI and More
O
OpenAI News
Attack and Defense Labs
Attack and Defense Labs
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
爱范儿
爱范儿
H
Heimdal Security Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
G
Google Developers Blog
G
GRAHAM CLULEY
V
V2EX
The Register - Security
The Register - Security
人人都是产品经理
人人都是产品经理
B
Blog RSS Feed
Schneier on Security
Schneier on Security
M
MIT News - Artificial intelligence
Stack Overflow Blog
Stack Overflow Blog
Help Net Security
Help Net Security
大猫的无限游戏
大猫的无限游戏
C
CERT Recently Published Vulnerability Notes
The GitHub Blog
The GitHub Blog
V
Vulnerabilities – Threatpost
The Last Watchdog
The Last Watchdog
J
Java Code Geeks
S
Secure Thoughts
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
量子位
NISL@THU
NISL@THU
K
Kaspersky official blog
Engineering at Meta
Engineering at Meta
T
Threatpost
Recent Commits to openclaw:main
Recent Commits to openclaw:main
宝玉的分享
宝玉的分享
Security Latest
Security Latest
T
The Exploit Database - CXSecurity.com
博客园_首页
A
Arctic Wolf

秋实-Allenyou 的小窝

【笔记】人工智能与模式识别 复习笔记 - 秋实-Allenyou 的小窝 【教程】使用 Keyd 将 Copilot 键映射为可用的组合键并修复触摸板防误触失效问题 机械革命无界 15X 的 Arch Linux 开荒指南 我在用什么?(2026 版) - 秋实-Allenyou 的小窝 关于 Next.js SSG 生成 RSS Feed 文件的另一思路 从零开始的 NixOS 体验 - 秋实-Allenyou 的小窝 2025:迷茫中转向 - 秋实-Allenyou 的小窝 我在用什么?(2025 版) - 秋实-Allenyou 的小窝 【记录】一种在主机通过 Docker 容器名解析容器 IP 的方法 【记录】如何在 Next.js 中优雅的调用 Matomo 统计 从信号与系统角度看 OI/XCPC 中的傅里叶变换运用 - 秋实-Allenyou 的小窝 【杂谈】答《博客作者呀,我想采访你这 9 个问题!》 - 秋实-Allenyou 的小窝 使用 Golang 重写 gh-proxy - 秋实-Allenyou 的小窝 FurryCTF 2024 寒假赛 调试窗口 题解 2024:“我”的大学生活 - 秋实-Allenyou 的小窝 【游记】CCPC 2024 重庆站尾杀记 - 秋实-Allenyou 的小窝 【游记】ICPC 2024 亚洲区域赛南京站打铁记 - 秋实-Allenyou 的小窝 【杂谈】这次 Furrygooo 结束后我的一些体验 - 秋实-Allenyou 的小窝 【教程】使用阿里云 OSS + CDN 加速 Gravatar 【记录】 一次罗技鼠标驱动冲突问题的排查经历 - 秋实-Allenyou 的小窝 【记录】我是如何用 Next.js 重构我的博客的 - 秋实-Allenyou 的小窝 【教程】如何用 Git 快速搭建简单的 CI - 秋实-Allenyou 的小窝 我的DN42 Peering信息 - 秋实-Allenyou 的小窝 【进度】博客重构计划 - 秋实-Allenyou 的小窝 这是一个正经的2023总结 - 秋实-Allenyou 的小窝 【题解】Luogu P9769 [HUSTFC 2023] 简单的加法乘法计算题 2023新年谜题总结 - 秋实-Allenyou 的小窝 【教程】浅谈Linux服务器的一些基础安全技巧 - 秋实-Allenyou 的小窝 Goodbye, 2022~ - 秋实-Allenyou 的小窝 【教程】使用 Docker 开服,优雅地隔离不同版本JDK - 秋实-Allenyou 的小窝 【旧文补档】2020年终总结 & 2021新年计划 - 秋实-Allenyou 的小窝 【旧文补档】写个脚本监控你的VPS SolusVM面板适用 - 秋实-Allenyou 的小窝 【旧文补档】建立自己的私人网盘!在CentOS VPS上安装NextCloud - 秋实-Allenyou 的小窝 【旧文补档】2019,再见!2020,你好! - 秋实-Allenyou 的小窝 【旧文补档】新一代USB来袭,一起捋一捋USB的“前世今生” - 秋实-Allenyou 的小窝 【旧文补档】矩阵学习笔记 - 秋实-Allenyou 的小窝
【杂谈】关于 AIGC 的一些思考 - 秋实-Allenyou 的小窝
2025-11-12 · via 秋实-Allenyou 的小窝

近年来,随着以 ChatGPT、Kimi、DeepSeek、Qwen 为代表的 LLM,Sora 为代表的音视频生成模型,Stable Diffusion 为代表的图像生成模型等一系列生成式 AI 技术成熟,AI 生成内容(AIGC)在互联网上比重逐渐增大。相对应的,也产生了一些问题。

背景

作为开往 Travellings 维护组成员之一,我偶尔会参与开往加入申请的审核工作。这一年来,我审核过的站点数量也有几百个了,其中不乏站点排版精良,内容有深度有参考价值的优质站点,但也有一些比较“粗制滥造”的站点。其中,抛开以无授权转载/抄袭为主的“传统”内容农场站点,最令我感到头疼的就是以低质量 AIGC 为主,文章全都是一眼 DeepSeek/Kimi 生成,甚至没有一点润色的站点。

DeepSeek/Kimi 生成大段文字时,不知道为什么非常喜欢用“比喻:内容”的小标题,同时几乎可以说是在滥用 Markdown 无序列表格式,一方面这使得整段文字的 “AI 味”非常明显,几乎可以说是一眼认出,另一方面也使得文章看起来并不像是一段连贯的文字,而更接近于未完成的大纲(还是辞藻浮夸、比喻经常不知其所以然的那种),很难称得上符合“文从字顺”的要求。

类似的情况并非偶然。当我在国内某蓝色文字问答平台上搜索一些涉及一定背景知识要求的问题时(例如对某项技术的分析、对某个 Bug 的解决时),也会有这种“一眼 AI”的回答,实在是污染了搜索结果。

因此,我个人对于 AIGC 的态度,其实是更偏向负面一些的。

当然,作为一个还没达到 35 岁分界点的二旬老人,我也不希望自己盲目抵触新的技术。因此,我希望借写作这篇文章的机会,梳理一下我自己关于 AIGC 的一些看法,并与大家讨论。

本文内容仅为作者自身不成熟的一些想法,如有片面之处欢迎在评论区指出。

本文讨论的 AIGC 仅限于 DeepSeek/Kimi/ChatGPT 等以文本生成为主要功能的生成式 AI 模型服务,也即大语言模型 LLM,其他如 Sora/Suno/Claude Code 等音视频、代码生成模型不在本文讨论范围内。

当我们在互联网讨论 AIGC 时,我们在讨论什么

目前,互联网上的 AIGC 使用显然是非常广泛的。例如不少博主为博客添加的博文 AI 总结就是一个典型利用。但是 AIGC 亦有高下之分,有的 AIGC 质量不输人类,而有的则毫无营养。因此,在讨论之前,对其进行分类显然是十分有必要的。

以我目前在开往加入申请审核中的经验来看,能看出来使用了生成式 AI 的内容可以分为两类:

  1. 一眼 AI,主体几乎全部由生成式 AI 生成。
  2. 大体还是比较像人写的,只是局部使用了 AI 进行润色等,或者人工对 AI 生成的内容进行了二次加工。

要是能把 AIGC 给加工到完全看不出是 AIGC,那工作量绝对比自己写大多了,不得不服

其中,第一种很显然几乎不能体现人类作者的贡献。而第二种内容的生产过程中,人类作者的贡献所占的比重是不小的。

如果以论文作者排序来比喻的话,第一种内容发布时,发布这篇文章的人类作者顶多能排到二作三作,甚至很多时候只是“通讯作者”;而第二种内容的一作仍然是人类作者自己。

在互联网上,就我自己观察到的情况而言,大部分人并不会将第二种内容明确划分到 AIGC 中——甚至如果作者不太道德地抹去了 AI 生成的标识,大部分人都不会认为这是一篇 AIGC。

本文中,还是以对第一种“一眼 AI”的内容的讨论为主。

不同类型的内容应当有不同的对待标准

是的。对于 AIGC,我其实是赞同一定程度的“双标”的。

参考开往早期对成员博客的分类,我们可以将内容——或者说,在当前语境下,文章——分为两类:

  • 知识类:通常以分享某些知识为主,如我憋了一下午憋出来的从信号与系统角度看 OI-XCPC 中的傅里叶变换运用一文。这类文章中通常不会过多夹杂作者自己的某些情感、某些观点,而读者阅读时期望获取到的也是“如何做某事”等知识。
  • 生活类:通常以记叙自己的经历、分享自己的情感或观点为主,如【游记】CCPC 2024 重庆站尾杀记一文。这类文章通常包含大量从作者自己的主观视角叙述的内容,读者阅读时也往往期望获取新观点、了解一段新的经历等。

对这两类文章,使用 AI 生成技术的结果显然不一样,也应当有不同的对待标准。

知识类:用就用吧

正如上文所说,知识类文章中,通常不会过多夹杂作者自己的情感与观点,而读者阅读时期望获取到的也是知识。这种情况下,合理地使用 AI 辅助,甚至通过 AI 创作 + 人工润色在一定程度上都是可以接受的。

例如,ryan4yin 大佬发布的 Linux 桌面系统故障排查指南系列文章就在开头明确标注了“本系列文章由笔者借助 ChatGPT, Kimi K2, 豆包和 Cursor 等 AI 工具创作,有很大篇幅的内容完全由 AI 在我的指导下生成”。按照前文的划分,甚至也达到了“一眼 AI”的标准。但这种 AIGC 在我看来,还是属于“可以接受”的范围。虽然我并不喜欢这样的文章(毕竟 AI 文风看着属实生理不适),但是这个系列的文章的确提供了我需要的关于 Linux 桌面故障排查的“知识”,并且有人工把关,我也不太需要担心生成式 AI 的“幻觉”会给我提供虚假信息。

由此也能看出,关于知识类内容,我并不十分抵触 AIGC(更多是不喜欢 AI 的这种行文风格)。

然而,在开往进行审核工作时,也仍然有不少知识类 AIGC 被我们以“内容农场”等原因打回。原因很简单,这些内容有以下问题中的至少一条:

  • 版权不明。生成的内容过于平凡以至于在网上可以轻松找到相似度极高的 AIGC,这时非常难以评判到底是否属于原创。更不用说从 ChatGPT 3 模型问世持续到现在的争端——通过互联网公开语料训练的 AI,生成的内容版权应该归属于用户、模型提供商、模型开发者、语料提供者、语料生产者的哪一方?
  • 内容真假参半。众所周知,现在的 LLM 都存在不可避免的“幻觉”问题,也就是会一本正经的胡说八道。没有合格的人类作者把关,很难相信其中提供的“知识”是正确可信的。
  • AI 味重到根本没法看,**能不能麻烦作者至少在写提示词时候加一句,让 LLM 不要全篇都是用 Markdown 无序/有序列表列一些观点?**这样看起来,起码这还像是一篇文章,而非某个人写到一半的大纲。

只要没有以上问题,AIGC 其实还是可以接受的。

不是,你生活类还用 AI?

相反,在生活类文章中,我完全无法容忍 AIGC 的出现。

作为作者,我写生活类文章(比如这篇)时,一定是有我想要表达的观点,或者想要分享的经历的。而在这上面使用 AIGC,显然有些违背初心了。

而作为读者,我阅读这篇文章时,想要读到的是作者的经历、观点,而不是 AI 的。

某位不愿透露姓名的群友

写日记还用 AI,简直像是 🦌 的时候 🦌 幻龙。

秋实-Allenyou

秋实-Allenyou

话糙理不糙,但你这也太糙了……

也因此,除了简单的语句、标点润色之外,我完全不认为在生活类文章中使用 AI 是可接受的。

关于 AIGC 检测

既然聊到了 AIGC,就不得不提相对的 AIGC 检测技术。

目前,国内外均有商用的 AIGC 检测技术(国内知网/维普,国外 GPTZero 等)。其中国内的几项我也有试用过(学校图书馆提供每人每年几次的免费使用)。

很遗憾,就我的使用体验来看,这些技术还远远未能达到“可用”的水平,至多能给人工审查提供一些参考。一方面,对于 AI 润色等简单使用,这些技术的查出率存在一定不足。另一方面,这些技术有极高的误报率。

先前,我必修的某门课程要求每人提交一份课程报告作为大作业。通过参考 Kimi 生成的大纲后,我几乎独自写作完成了整篇文章。然而,在图书馆提供的 AIGC 检测系统中,我的文章以 90% 的置信度被认为是 AI 生成。作为对照,我提交了一份由指定了避免使用 Markdown 格式的提示词 DeepSeek-V3 生成的文章进行 AIGC 检测,其置信度只有 70% 不到。这显然是十分荒谬的。

根据 AIGC 检测的原理,目前的检测技术大多是以分析选词和排布句子的习惯来区分 AIGC 和人工写作。其中,以长难句、陈述句、非口语化表达为主的文本会被更高概率地认为是 AIGC。在我修改我的文章,将一些书面表述替换为更口语化的表述后,AIGC 置信度有显著下降。然而,在学术文本中,这种检测显然是不具有区分度的——学术文本的一大特征正是以非口语化、陈述性的语句为主,且常用较多限定词进行修饰,保证表述的严谨性。这种表述与 AI 的用词相似度较高,目前的技术很难区分这一点。

综上,目前的 AIGC 检测技术尚未达到独立判断的水平,仅能作为一项参考。

一点总结

首先可以明确的一点是,生成式 AI 不应当被抵触。尽管我个人对 AIGC 的态度偏负面,我仍然支持在工作流中引入 AI。例如,公文写作等应用文体写作场合中,使用生成式 AI 生成一个模板,在此基础上进行润色修改以符合自己的需求,这显然是十分行之有效的,对于缺乏此类文本写作经验的用户来说,AI 提供的参照也能快速提高这种“模板化”写作的能力水平。

然而,AIGC 也不应当被滥用。在生活类文章中,使用生成式 AI 显然会严重抹消这篇文章的意义。而在知识类文章中,不合理的使用也会降低文章的质量。同时,AIGC 的版权和“幻觉”问题也不应该被忽视。

基于此,我个人认为合理的使用应当满足以下几点:

  • 在应用类文体写作中,可以使用 AIGC 作为参考,帮助提高写作技能,但不应当不加审阅地直接将 AIGC 作为最终版使用。
  • 在生活类文章中,尽量减少生成式 AI 的使用,且仅限于进行一些审阅、文字润色方面的工作,不能用于直接生成大段文字
  • 在知识类文章中,可以适当使用生成式 AI 进行辅助创作,但是最后呈现的内容必须是相对完整的内容,且其中所涉“知识”应当得到人工审核确认是相对可信的。
  • 完全或大部分由 AI 生成的内容,必须标注为 AIGC,不能作为作者自己的原创文章看待。
  • 使用 AI 润色等辅助写作生产的内容,建议添加“使用 AI 辅助写作”等标注。

后记

基于这篇文章中的思考,与开往维护组内成员、开往社群成员进行讨论并参考意见后,我和林林 @Xiaozonglin 一同提出了《关于在开往加入规则中增加 AIGC 相关条款的提案》,并在开往官网、社群进行公示投票,待投票通过后将在开往加入标准中引入 AIGC 相关要求。