真实项目:问题从哪里来
三人合作的私有 AI 小说项目暴露了权利追溯、语义验证、编辑瓶颈、重试恢复、版本管理和模型替换等真实问题。相关代码、小说、日志、提示词、合同和经营记录不进入公开仓库。
从“伪精确文学特征”到可审计 AI 数据管道
2025 年 6 月,我与一名算法工程师和一名内容编辑开始筹备私有 AI 小说创作工作台;后续我把项目中暴露的权利、标签真值、评测隔离和版本治理问题,独立重建为这套 100% 合成、可公开复核的数据管道。
项目在 2025 年 6 月筹备、7 月进入开发。我们希望把选题、素材、大纲、正文、润色和评价串成一套私有工作台:算法工程师负责模型调用与工作流,编辑负责内容规则与最终验收,我负责采集、清洗、数据库、向量检索,并在后期主导数据审计与治理重构。
三人合作的私有 AI 小说项目暴露了权利追溯、语义验证、编辑瓶颈、重试恢复、版本管理和模型替换等真实问题。相关代码、小说、日志、提示词、合同和经营记录不进入公开仓库。
我基于上述事故独立重建了训练前数据治理 Demo。所有公开数据 100% 合成;页面中的可复现指标只来自固定 Release,不代表私有项目规模或业务结果。
真实项目提供可解释的问题链,公开 Demo 提供可复核的实现链。二者在页面中并列说明,但资产边界始终分开。
我对照早期字段说明、数据库表和分析模块后发现,“12 维文学特征”存在三套不同定义。
钩子、反转和情绪递进主要依赖关键词、词典与模板。它们可以寻找表面信号,却难以判断反讽、冷幽默和字面含义与真实意图相反的表达。
同类模型服务同时参与生成和评价,缺少独立金标、盲评与校准。部分模型评价虽然被保存,却没有进入最终门禁,实际通过条件仍主要依赖表面格式规则。
数据格式全部通过,但文学语义完全没有区分度。
原报告里的“全部通过”只指抽样字段格式、范围和枚举检查,不是全量语义验证。
以上来自私有早期原型的 32 条合成 AI 试验记录,只展示内部审计聚合结果。来源材料属于私有证据,不在公开仓库复现;它们不是公开 Demo 的固定回归数据,也不代表真实业务规模。
我们三人开始搭建私有小说创作工作台。我负责采集、清洗、数据库和向量检索;算法工程师负责模型调用与工作流,编辑负责内容规则与验收。
Streamlit、LangGraph、通义千问、Chroma 和 SQLite 串起选题、素材、大纲、正文与评分;此时“能生成”仍被误当成“数据可用于训练”。
旧素材无法逐作品证明来源和使用范围。我把旧库隔离为只读实验数据,重新建立作者、来源、授权范围、撤回方式和版本台账。
编辑抽查发现样本高度同质;我继续对照材料、数据库和分析 Agent,确认字段口径漂移、特征分布塌缩,以及生成与评价没有真正解耦。
批量生成暴露了编辑瓶颈、限流重试、断点恢复和向量版本错位。同题盲测进一步说明:复杂 Agent 编排不应成为不可替换的核心,评测必须冻结且独立。
商业假设未通过止损线后,我们停止继续扩张。我整理权属、版本、密钥、索引、依赖与交付边界,把可保留价值收敛到工作流、治理规范和评测资产。
我把训练前治理部分独立重建为公开仓库,以 100% 合成数据、固定 Release、双版本 CI、可复现构建和治理文件完成发布。
我没有继续给规则增加更多文学名词,而是把客观硬门、候选检索、语义预筛和最终内容判断拆开。公开仓库重点实现其中的训练前数据工程层。
权利准入、Schema、格式、字数、哈希、版本和文件完整性。
相似人设、相似冲突、历史素材、旧大纲和编辑经验。
创意扩展、候选生成、风格改写、编辑建议和带证据的语义预筛。
黄金集、盲评、最终语义判断,以及修改 diff 的持续校准。
正文、作者、作品、权利字段与版本标识。
状态、用途、期限不满足即进入拒绝旁路。
Unicode、空白、标点与可重复哈希输入。
识别规范化正文的精确重复。
发现近重复候选,不把相似性等同于版权判断。
作者优先分组、作品不可拆,再派生数据集。
所有数据量都固定在 v0.1.0-demo,用于验证权利门、去重、切分、数据集派生和文件对账。它们不是业务规模指标。
我做这四个取舍,是为了不把无法证明的判断混进确定性硬门。
同一作者的风格、偏好与叙事习惯可能跨作品重复。如果只按章节或样本随机切分,验证集仍可能看到训练集作者的稳定模式。项目先冻结作者分组,并保持作品不可拆,再派生 SFT、偏好和评测任务。
SHA-256 对规范化后完全相同的正文确定、快速、可追踪;MinHash/LSH 用于发现轻微改写或局部变化的候选。前者不能识别语义近似,后者也不能证明版权安全,两者承担不同职责。
当同类模型同时生成和评审,它们容易共享盲区。模型评分适合预筛、解释和提供证据,不应替代独立金标、真实编辑盲评与校准后的发布门槛。
规则处理可确定的约束,检索召回历史证据,AI 提供候选与语义建议,编辑负责最终内容判断。分层后,每个组件的错误类型、验证方式和责任边界都更清楚。
PRIVATE PROJECT · REAL CONTEXT · NOT IN PUBLIC REPO 以下角色分工和工作流来自私有项目的实际协作与迭代。不同阶段的自动化程度不同,最终内容始终由编辑验收;公开仓库只实现其中的训练前数据治理部分。
以下治理证据固定到 Release 对应提交 b19b3b5…;CI 结果单独链接到当次 Actions 运行记录。
Synthetic Portfolio Build 与固定提交快照。
查看 Release → CI两个 job 的轻量公开发布安全门、确定性重建、测试、CLI、编译与 artifacts diff 均成功。
查看 Actions → GOVERNANCE数据来源、用途、切分策略、限制和真实性边界。
查看文档 → VERIFICATION固定合成构建的计数、测试、去重、隔离和校验结果。
查看报告 → MANIFEST数据版本、阶段产物、源码快照与 Release 血缘。
查看 Manifest → SPLIT CHECK固定合成切分的作者、作品与正文哈希重叠检查。
查看报告 → CHECKSUMS受管合成构建文件的固定校验和清单。
查看清单 → ARCHITECTURE公开数据工程范围、阶段边界与未实现范围。
查看架构 → LINEAGE公开实现的阶段、数据与评测版本,以及未执行训练 / 模型的占位关联;生产撤回路径属于目标设计。
查看血缘 → OWNERSHIP独立实现、AI 辅助开发与最终责任边界。
查看声明 → PROVENANCE合成数据生成方式与不包含第三方项目资产的公开边界。
查看声明 → PUBLIC SAFETY公开仓库禁止提交的敏感资产与人工复核边界。
查看策略 →python scripts/run_demo.py --output-dir artifacts
python -m unittest discover -s tests -v
python scripts/check_public_repo.py
下面只描述固定公开仓库的实现范围;它不否认私有项目的真实经历与工作流,也不把私有资产包装成公开可复现证据。