方法论与洞察

公众号稿送专业方审阅翻车 · 弃读点与框架错误(2026-08-05)

入档:2026-08-05 事实结果

  • 稿件:《他们切开了那些书的书脊》约 3400 字,人机协作(作者 + Claude),未发布
  • 送审:飞书云文档给一位古典文献学专业的朋友,附三问(引用授权 / 专业校对 / 替他学科下的判断)
  • 反馈结论:原第五、六节整节删除;文体”太碎了""不像一篇文章”;对方在第六节弃读
  • 处置:稿件推翻重构(作者本人重写),压缩律档同日收窄适用范围(见 压缩保留簇丢弃孤例_v1
  • 无发布数据:本篇是生产过程复盘,不含任何效果判断 性质:人机协作写作的交付流程复盘

一句话

跨领域断言的错误分两种:事实错误可以自查(核对来源就行),框架错误自查不出来——因为它在框架内部完全自洽,只有领域内的人实读全文才会撞上;而他撞上的位置(弃读点)比他指出的错误更有信息量。


事实记录(不可修改区)

三处翻车,性质各不相同:

#错误谁发现的性质
1把作者本人在聊天里说的话,写成”我一个朋友的第一反应”作者素材归属错(多人聊天记录混淆说话人)
2断言”文献学地基在物质载体层、文本层会被 AI 替代”专业方框架错(外部强加的分层)
3宣称 tmp/ 已被 gitignore,实际未被忽略我自己复核时误读工具输出(详见下方)

其中 #2 的原话反馈:“这些东西并不能割裂地来看”、“地基不是那个”——校勘要判异文得知道版本源流,判版本又要靠文本内证,两者互为证据是循环不是层叠。


四条可复用 insight

1. 送审要问”你读到哪儿停的”,弃读点比错误点信息量大 ⚠️首次

专业方最有价值的一句不是任何一条具体批评,是这句:

“我看到文献学的地基那块就放弃了”

这一句独自暴露了一个所有正确性审查都查不出的结构缺陷:全文最弱的一节,摆在了最强的一节前面。 第七节(压缩丢掉孤本——全文唯一原创的论证)他根本没读到。

连带产生一个假警报:他说”坚船利炮那句后面还有一句,不能断章取义”,但那句其实写在文里了——他只是没读到那儿。弃读之后的所有反馈都不可信,但”在哪弃读”这个坐标本身极其可信。

操作:送审模板里固定加一问——「你读到哪一段停下来的?为什么停?」。

推论:长文的排序纪律是把最经得起推敲的放前面,不是把最完整的放前面。一节错误内容的代价不止是它自己错,是它后面的正确内容一起失去读者。

2. 事实错误能自查,框架错误只能外审 ⚠️首次

我在同一篇稿子里,事实部分扛住了、框架部分崩了:

结果为什么
事实(Project Panama、fair use 裁定、15 亿和解、Snopes 评级)✅ 无异议可核对来源,能自查
框架(把文献学切成”文本层/载体层”)❌ 地基级错误自查查不出来——它在框架内部完全自洽

框架错误的危险形态:它不长得像错误,它长得像洞见。分层清晰、对仗工整、能推出结论——所有”好想法”的外观它都有,唯独缺一样:领域内的人不这么切。

判据:一段论述如果满足「①对方领域 ②我给出了一个整洁的二分/分层 ③我没有在该领域的一手材料里见过这个切法」——三条齐了就是高危,必须外审,不要自己再想一遍。 自己再想一遍只会让它更自洽。

送审对象要选能证伪你的人,不是能鼓励你的人;且要给全文不给摘要——摘要看不出弃读点,也藏不住框架错误。

3. 加粗在替句子干活 ⚠️首次

专业方对文体的原话:“太碎了""不像一篇文章""一般人类不会写着写着给自己加一堆加粗”

机制不是”加粗太多”这个量的问题,是分工错位:本该由语序和节奏承担的强调,被排版接管了。 于是每段都是一个加粗结论 + 一段解释,读起来是结论的堆叠,不是论证的推进——“碎”的来源在这里,不在句子长短。

可操作自检把全文加粗全删掉,再读一遍。

这条对人机协作尤其要紧:结构化排版是 AI 输出的默认形态(便于扫读),而长文论证要的恰恰是不能扫读。同源判断见作者本人的 语言的Encoder-Decoder模型——文体这一道是”必须留给自己”的工序。

4. 公开仓库的工作区就是发布面,“没 commit”不是保护 ⚠️首次

knowledge-baseabove-the-web 都是公开仓库,且整库参与官网构建——commit 即发布。稿中含第三方尚未授权的私聊引用,因此归档动作必须先问落点。

但真正的坑在下一层:我把草稿放进 above-the-web/tmp/,并宣称”tmp/ 是 gitignored 的,安全”。这句是错的——.gitignore 里根本没有 tmp/ 这条规则,文件当时裸躺在公开仓库工作区,任何一次 git add -A 都会把它连同未授权引用一起推上 GitHub。

规则:含第三方未授权内容的草稿,落地前必须验证落点是否在 git 视野外;“我没打算 commit”不构成保护(保护要靠 .gitignore,且要验),更稳妥的是直接放到仓库目录树之外。

误判的成因单独记在下一条。


顺手教训


元层:批判某种思维错误,不使你免疫于它

同一篇稿子里,我在第七节用 伪机制解释识别_四层拆解法_v1 裁决凯文·凯利”把隐喻当机制”(数万亿参数 ≠ 数万亿方向),紧接着在第五、六节自己把隐喻当了机制(把工程师的分层直觉当成文献学的结构)。

而且顺序上,我是先犯错、后批判——写批判的时候完全没有回头看自己刚写的那两节。

规则:一篇文章里如果出现”某某犯了 X 错误”这样的裁决,收尾时必须拿同一把尺子回扫全文。指认某种错误的那一刻,正是你对它最没有警觉的时刻——因为你已经默认自己站在它的对面。


下次改进

  1. 送审模板固定三问:哪里错了 / 你读到哪儿停的 / 你觉得应该是什么。
  2. 跨领域断言过”三条高危判据”(对方领域 + 我给了整洁分层 + 一手材料里没见过这个切法),中了就外审,不自证。
  3. 长文定稿前做一次”删光加粗试读”。
  4. 草稿落地前验证落点是否在 git 视野外,用 git status 验、不用 check-ignore 验。
  5. 引用多人聊天记录,逐条核对说话人。
  6. 文中若有对他人错误的裁决,收尾拿同一把尺子回扫自己。

关联文档


版本

升级触发:

类型/协作工具链主题/写作交付主题/查证与核查