ARTICLE · 1259477
软著被要求 AIGC 补正,源码里这几处值得先检查
最近看了三份收到 AIGC 补正要求的软著源码材料，想从具体代码中找找，有哪些问题值得在提交前检查。
由于aigc的检测系统是个黑匣子，没人看过用过。所以我们做的更多的是，从被检测的材料中找到一些比较明显的AI特征，并把可以改正的问题拿出来讨论。样本有限，只能管中窥豹。
说明一下，AIGC的检测规则庞杂，我们没法全面覆盖，本文会重点分析那些能定位、有改进空间的问题。
先说结论：被判 AI 生成的代码，不只是"写得太像 AI"，更关键的是它太不像一个真跑过的项目。
一、项目太像一键直出的材料了
在315之前，我买过那种只给一个题目，就能生成整套软著材料的服务，手边还留着当时的代码和说明书。这次看几份补正材料时，我发现它们的叙述方式，和那时的材料有不少相似之处。
比如，说明书里放了大量按钮截图，几乎每写一句操作说明，就配一张局部小图。乍看很细致，但这些截图究竟帮用户解决了什么问题？如果一张完整页面图就能讲清楚，为什么还要拆成十几张按钮图，反复解释点击和输入？
这样的写法增加了制作和维护的工作，阅读起来也零碎。当然，截图多不能证明是AI生成，也不能据此认定它触发了补正。但既然这种写法本身就费力、难读，又与批量生成材料的套路相似，就没必要继续沿用。围绕实际操作流程组织说明，在关键步骤配图，通常更清楚。
代码上也是同样的问题。好项目即使由 AI 参与完成，逻辑也是闭合的，不会到处留着未完成的逻辑。有些材料翻下来，不少页面里能看到伪数据、假逻辑、没验证过的分支。这类程序即便能跑，放到真实项目里恐怕撑不住实际的交互。
二、"示例"两个字，是自己把自己卖了
文件里有这么几行：
# 简化的短信验证码校验：仅示意字段存在，不做真实短信逻辑
flash('请输入短信验证码（示例系统不做真实验证） 。', 'warning')
# 2) XXX实时追踪（示例静态地图 + 伪数据）
# 8) 批量订单导入（Excel 简化为 CSV/文本示例）
<h6>联系方式（示例）</h6>
全文一共13处，随手翻翻就是这样的逻辑。
示例、示意、模拟、简化、伪数据、不做真实、占位、仅供参考。这些词你是审核员看到，是什么感觉？
一个真实项目不是不会出现这些，比如模拟数据和待办功能，但是一定要控制比例，而且要看它们出现在哪里。如果核心校验只是示意，主要数据全靠模拟，关键流程还在占位，就很难说明软件已经实现了所描述的功能。不然全写完，到处都不可用，回头再写，和重开一个项目毫无区别。再简单的本地项目或是校园项目都不是这样写代码的。出现这样的代码，我只能说这完全是在糊弄版权局。
这类词人类更是不会大量写，写了就全是把柄。
功能简单没关系，但你不能自己到处声明它是假的。
若是拿放大镜扒开代码仔细看看，可笑的事情更多
同一份文件里还有这么一段配送时长计算：
s = int(''.join(filter(str.isdigit, sender_building or '0')))
r = int(''.join(filter(str.isdigit, receiver_building or '0')))
distance = abs(s - r)
minutes = max(5, distance * 3)
拿两个楼栋号相减再乘 3，就是"预计配送时长"。没有任何业务依据。太粗暴了。
还有一处更彻底：
orders = Order.query.filter_by(status=' 已完成↩︎
').order_by(Order.created_at.desc()).all()
' 已完成↩︎' 后面被换行截断了，字符串里带着一个回车。这段代码但凡跑过一次，这里就会查不到任何订单。
所以，我有时会和群友强调，你的真实项目AI写的也是可以申请的。但要是项目业务都是假的，手搓的也无用。因为版权局真正想消灭的是AI造假。
三、注释里写"对应说明书"，等于自首
A 文件的注释里，有 22 处长这样：
// 对应说明书"4.常见问题与处理—模块名称/模块功能"：定义功能基因与待测序列的统一记录结构。
// 对应说明书"3.软件的使用—结果字段"：保存最佳待测序列、相似度、覆盖度、位置、方向与判定状态。
真实开发者不会在源码注释里指回说明书的章节。写这种注释只有一个动机——让审查材料互相印证。等于直接告诉系统：这份代码是照着说明书倒推出来的。
更要命的是，这种引用给了系统一个特别省力的算法：拿代码注释和说明书正文做文本相似度比对。 章节号、原句照搬、措辞一致——相似度一算就出来，比统计任何措辞特征都稳。这是所有特征里最不该留的一条。
同一份文件的开头还有 23 行模块清单，每条句式一模一样：
// 系统架构模块：浏览器端页面负责数据录入、状态管理、序列计算与结果呈现。
// 数据模型模块：统一描述功能基因、待测序列、功能标注与筛查结果。
// 功能基因库模块：支持功能基因记录的文件导入、粘贴、新增、编辑、删除和搜索。
23条，一个字都没变过节奏。人写不出这么整齐的东西。
改法：删掉"对应说明书"字样，注释砍掉一半，剩下的长短不一。有的地方只写半句，有的干脆不写。程序员做事规整，就事论事，说话言简意赅，平铺直叙。虽然不是所有人都这样，但是我们要走大概率能成功的路线。
四、中文句号前那个空格，是最难藏的马脚
文件里还有 3 处这样的：
'请输入短信验证码（示例系统不做真实验证） 。'
'请上传 Excel/CSV 文件 （示例系统使用 CSV 文本模拟） 。'
注意句号前面那个空格。中文标点前面不会有人手动敲空格，这是文本生成模型的排版习惯。
系统抓它只需要一条正则：[，。；：？！] 前面有没有空白字符。误伤率几乎为零，因为模型几乎每句都会这样做。
这类"一条正则搞定"的信号，是系统最好实现的检查——便宜、确定、可解释。
同类的还有这些：
“” | ||
— | 70%—100%） | |
· | ||
… | ||
× |
代码注释和报错提示里，符号只保留这些就够了：
， 。 ： ； 、 （ ） - / % .
中文引号、破折号、间隔号、省略号、箭头、乘号、感叹号、问号——全部清掉。
顺带说一句，不要写emoji，虽然我看到emoji也很开心，但是大多数人写代码都不会这么活泼，AI却很喜欢。所以避开AI痕迹，还是要选择人类选择更多的路线。
五、太整齐，也是一种破绽
C 文件 3116 行代码，只有 26 行注释，密度 0.8%。
整份代码几乎裸奔，但中间孤零零挂着这么一条：
// add by XXX：旧批次即使已经结束，未拆换的位置仍可能保留占用索引，重装前必须逐项关闭。
全程零注释，突然冒出一条带人名的 add by。 这是典型的反检测手法，问题是它反而更扎眼——真实项目的注释是零散分布的，不会只有一条。
同一份文件的格式化也整齐得过分，而整齐的例子是这样的：
record RepairMountCmd(
UUID repairId,
long repairVersion,
int roundNo,
UUID sourceBatchId,
List<MountSlotCmd> slots,
RequestMeta meta
) {
}
record 后面跟一对空花括号，六个参数每个独占一行，连 UUID repairId 这种短的也不合并。而且全文的类和方法一个 public 都没有。
正常写法：空 {} 去掉，短参数合并成一行，该加 public 的加上，允许个别地方不统一。
六、一份没有"历史"的代码
三份代码里，TODO、FIXME这类标记一处都没有。
真实项目多少会留几条没处理完的标记：某个功能之后再去实现，某个分支先这么写着、某个参数待确认、某次线上故障后临时加的判断。这些是工程演进留下的痕迹，也是代码被真实使用过的证据。
AI生成的代码从来不写这些。
改法：留一两条真实的待办标记，但也别太多，作为降AI的小心机。
下面这段代码，也许校园项目和不上线的代码是会用的。但是你要是申请软著，可能会遇到小麻烦：
app.config['SECRET_KEY'] = 'sudi-drone-factory-secret' # 硬编码密钥
image_path = os.path.join(upload_dir, image.filename) # 直接用原文件名，路径穿越
return send_from_directory('.', filename) # 根目录任意文件读
七、还有些个语法完全不通的毛病
文件全文等号出现次数：0。
看这一段：
const DNA_ALPHABET new Set([...]);
.filter((letter) > DNA_ALPHABET.has(letter))
if (reference.kind ! "DNA")
let matches 0; matches + 1
=> 变成 >，!== 变成 !，赋值号直接消失。这是一份编译不过的代码。
还有一份文件：pom.xml 里五处 <version>$</version>，原文应该是 ${postgresql.version}。
不能编译的代码，截图是咋出来的呢？不抓你抓谁呢？
最后说一句
AI 辅助写代码这件事本身没什么问题，现在谁不用。
与其费力让AI降AI，不如用一样的力气让AI把业务逻辑实现出来。反正3000行也不用多久就完成了。真实逻辑基本能过受理这一关，至于后面还会触发别的补正，那么我们只能开篇另说了。
