大多数人写论文，不是输在不会写。是输在把一个系统级任务，当成了一份文档。
我写论文的第一天，没有写一个字正文。
我先写了一份文件。
320行。
名字叫 CLAUDE.md。
那是整个论文系统的宪法。
一篇MBA论文看起来像一份文档。
实际上，它更像一个系统。
7章正文。61条参考文献。十几张图表。三情景经济学模型。1262行自动总装脚本。导师7条反馈，100%闭环追踪。
如果没有系统，它最后往往会变成一个文件名叫
论文v3-修改版-final-最终版-真的最终版.docx
的灾难。
所以我没有先写论文。
我先写规则。
那份320行的CLAUDE.md里，只有几件事：
五条红线。
虚假归因、数据口径不一致、跳过审核直接定稿、格式不对标、数据造假。
任何一条触发，系统必须停止。
然后是 唯一真相源（SSOT, Single Source of Truth）。
论文里的关键数据，只能存在一个地方。修改必须先改源头，再改引用。禁止反向。
然后是 Phase Gate。
每次修改一章，都必须过四道门：口径一致性、引用完整性、格式规范、全文巡检。通过之前，不允许进入下一阶段。
很多人第一天先写绪论。
我第一天先写规则。
因为真正会让论文翻车的，从来不是正文。
是系统。
说实话，这套东西也不是我一开始就设计好的。它基本都是在某次翻车之后补上去的。
你把论文当什么东西，决定了你第一天做什么。
把它当文档，你会打开Word。
把它当系统交付，你会先写宪法。
两种选择，两种后果。
开工之前——那些反人性但救命的准备工作
写论文的第一件事，不是打开Word，不是列提纲，是把学校发的全部文件读一遍。
北大光华MBA论文的要求材料，是六份附件、中英双语，一共12个PDF和Word文档。包括论文模板、答辩安排、原创性声明、提交承诺书。大多数人的做法是扫一眼，"知道了，知道了"，然后直接开写。我的做法是把每一份都读了一遍。包括英文版。连目录都看了。
读完之后，我做了一件比较极端的事。
我把从这些文件里提炼出来的格式要求，整理成了一份118项格式审计门禁清单。逐条写下来，每条可以打勾。A4纸、上边距3.0cm下边距2.5cm左右2.6cm、宋体加TNR小四字体、20磅行距、章标题黑体三号居中、一级节黑体四号居左、图编号在图下居中宋体11pt、表编号在表上居中宋体11pt、页眉奇数页章标题偶数页"北京大学硕士学位论文"……这些东西写下来密密麻麻，但每一条都是一个可能被打回来的坑。
118项。不是因为我强迫症。是因为格式这件事，不是你自己觉得对就行。格式要求的标准是：跟学校模板像素级对齐。 你写得再好，格式扣分，答辩委员第一眼就觉得你不专业。
光有规范不够，我还需要知道"真实的论文长什么样"。
这时候往届范文的价值就出来了。我找到了已毕业同学的论文定稿，拿来和模板逐条对照：哪些是模板没写清楚、但定稿里必须有的；哪些是范文自己加的，不是硬性要求。更关键的是，我还找到了一份答辩会议转写，里面讲的是评委到底会怎么问。
参考不是抄袭。参考是省掉重复踩坑。
在真正动笔之前，我先把终局长什么样校准清楚。
再往下，才是那些真正反人性的操作。
12张图，分两条流水线生成：数据图用Python的matplotlib，概念图用HTML/SVG模板加Playwright截图。为什么要这么干？因为图是要改的。导师说"这个图横轴的标签改一下"，或者"这个颜色方案换掉"，如果你的图是在PS里一笔笔画的，改起来痛苦到怀疑人生。但如果图是代码生成的，你改一个参数，重新跑一遍，三十秒新图出来了。案件规模趋势、竞争格局散点、用户行为漏斗——这些数据图走matplotlib；商业画布九要素、产品架构、三层收入架构、用户旅程匹配——这些概念图走HTML渲染再截图。两条线，但共享一套写死在代码里的视觉规范：蓝灰学术色系五级色阶，从#2B579A到#D0E2F0，强调色橙、成功色绿各一个，中文宋体英文Times New Roman——连配色都不靠人眼判断，是常量定义的。每一张都是代码，每一张都可以一键重生。
15张表（含附录），全部写成Markdown三线表格式。总装脚本自动转成Word里的三线表。所有表格上有表名、下有脚注、格式统一——不是人工调，是脚本保证。
最"离谱"的是那1262行JavaScript总装脚本。它做一件事：把10个Markdown格式的论文章节文件，合并成一个符合学校格式要求的Word文档。带目录、带三线表、带页眉页脚、带脚注、带正确的页码系统。一行命令，十秒钟，0.97MB的Word出来了。
你可能觉得这些操作听起来很酷，但未免太折腾。说实话，这些操作每一步都反人性。没有人写论文的时候觉得"我需要先写一个JS脚本来生成Word"。但每一步都在为你省十倍的返工时间。
我在第四次改格式的时候崩溃了，然后写了这个脚本。脚本写完之后，格式问题就永远不再是格式问题了——它变成了参数问题，改参数就行。
准备工作不是准备"万一要用到的东西"。是准备"你一定会用到的东西，在你用到之前就做好"。
为什么传统写法一定会翻车
传统写法翻车的根本原因只有一个：用单线程人脑，处理一个需要数据库的任务。
先说一个真实故事。
我的论文里有一个关键数字：全国劳动人事争议仲裁受理的案件数量。这个数字在正文里出现了六次。六次引用，三种口径。有的写"超过385万件"，有的写"350万件"，有的写"近400万件"。其中一处甚至用了这个数字支撑了一个关键论点，但口径跟其他地方完全对不上。
我花了将近一小时，才把这个数字的来源找清楚：人社部2024年度人力资源和社会保障事业发展统计公报，原文是385.0万件。
一小时。就为了确认一个数字。而且这个数字在论文里出现了六次，如果不是系统性地检查，你根本不会意识到三种口径同时存在。你只会记得"我写了这个数，差不多是这么多"。
用记忆管理数据，等于用大脑当Excel。
大脑会衰减，会变形，会以最自信的方式给你最错误的答案。
这个问题只是冰山一角。
传统论文的写法几乎人人一样：打开Word，开始写，存一个文件，然后改，然后再改，然后文件叫论文v3-修改版-final-最终版-真的最终版.docx。我见过同学发给我看的文件名，就是这样的，一点不夸张。
5万字塞在一个文件里的后果是什么？你在改第五章的某个段落，不知道第三章有没有类似的表述。你用搜索替换把一个词改了，不知道另外三处使用这个词的地方逻辑上适不适合改。改到版本3，你已经不记得版本1里哪些判断是深思熟虑过的，哪些是临时写的。
更致命的是：5万字的Word文件没有任何结构可言。所有问题藏在里面，你看不见，也找不到。
导师反馈是第三个坑。
导师说了什么？微信语音，三条，每条一分钟。你记下来了大概意思，改了两处。下次见面，导师说"我说的不是这个"。于是你再改。再改完，再确认。这个循环可以无限重复。
反馈没有闭环，就像客户工单没有状态追踪。你知道有问题，但不知道改没改。你知道改过，但不知道改对没改对。导师知道有问题，但不知道你改了哪里。每次对话都是从零开始重建上下文。
不是能力问题，是架构问题。你在用单线程人脑处理一个需要数据库、版本控制和质量门禁的系统级任务。
传统写法的三个致命伤：数据靠记忆（会错）、内容在单文件（改不动）、反馈靠对话（没闭环）。这三个问题不是独立存在的，它们叠在一起，会在你论文进行到60%、70%的时候集中爆发。你之前积累的每一个小问题，都在那时候变成大麻烦。
系统性的问题，需要系统性的解法。工具解决"写"的问题，系统解决"不翻车"的问题。
文献综述——论文最大的坑，以及我们怎么没掉进去
文献综述是整篇论文最容易出事的地方。
不是因为文献难找，而是因为文献管理是一个被严重低估的工程问题。大多数人把文献当成"参考资料"在管，有个大概印象，知道自己"存过"，引用的时候把名字和年份填进去。这套做法，在答辩桌上会出事。
出事的方式有四种。
引用了一篇论文但没认真读过原文，答辩评委随口问一句"你引用了Teece2010，这篇文章的核心贡献是什么"，你说了一个大概，评委追问"原文里怎么说的"，你答不上来，场面会非常被动。引用格式不统一，有的写"Teece, D.J."有的写"TEECE D J"，格式审查打回来，叫你重排。参考文献列表跟正文对不上，正文引了某个作者，列表里没有这条文献，叫幽灵引用；或者列表里有，正文一次都没引，叫僵尸文献——GATE-2和AUDIT-5专门查这两类问题。最后，61条参考文献，先中后英、各按姓名字母排序，手动排一遍的体验，只有一个词可以描述：折磨。
文献综述不是"读了几篇论文写个总结"。它是一个数据完整性问题。而数据完整性问题，用工程方法解决。
所以我建了一份文献下载台账。
这份台账现在是v13版，61条全覆盖。每条记录包含：文献编号、下载状态、文件名、文件大小、存放位置。该落地的都落地：43条学术论文和报告有本地PDF，15本书单独标注购买状态，3条法规保留官方原文。
中文文献里，学术论文和行业报告分开管理；英文学术论文覆盖参考文献列表里的全部期刊论文；网页类文献统一打印成PDF归档。McKinsey生成式AI经济潜力报告落地了，Stanford法律设计实验室的报告落地了，NBER工作论文落地了，arXiv预印本也落地了。
系统真正开始显出威力，是导师反馈之后新增的那7条文献。导师在反馈里，提到需要补充几篇关于商业模式创新、法律科技和LLM经济学的文献。这7条文献，当天下载完毕，当天入台账。这种速度，不是因为我特别勤快，是因为台账的结构已经在那里了，新增一条只需要填格式。
文献管理不是"我好像在Zotero里存过"。是61条文献全覆盖——43条学术论文和报告落地PDF，15本书标注购买状态，3条法规文件归档原文。每一条都有迹可循。
有了PDF还不够。PDF在手，不代表里面写的是你引用的那个意思。
这就是引用核实清单的价值所在。
61条文献，每条核实四个维度：作者和年份是否与PDF原文一致、论文里引用的关键数字和结论是否与PDF原文一致、理论归因是否正确（就是"X提出了Y"这种说法，X是不是真的提出了Y）、卷期页码是否与PDF封面一致。
目前已完成核实43条（原有36条加新增7条），发现并修正了若干问题。举几个真实的例子。人社部2024年统计公报那条，论文原来写的是"350万件"，打开PDF一查，原文是"385.0万件"，已修正。McKinsey2023报告那条，原来写"推理成本下降80%"，打开PDF发现原文说的是"推理成本持续大幅下降"，措辞过强，已软化。Anderson2009的Freemium那条，引用了一个"约5%转化率"的说法，PDF里这是行业经验估计而非实证数据，现已在脚注里注明。Korinek和Vipra2024那条，原来写AI推理成本"超线性增长"，PDF里根本没有这个表述，属于过度解读，已删除。
书籍类文献，比如Yin2018的单案例研究设计、Porter1985的竞争优势，暂时标注"购买未逐页核实"——这是合理取舍，核实成本太高，但这类经典文献的归因是学术界共识，风险可控。
这份清单的实际价值是什么？答辩的时候，评委翻到任何一条引用，你三秒钟找到PDF原文对应页码。你不是在"我记得大概是这样"，你是在"翻到第三页第二段，原文这么写"。这两种状态，答辩桌上的气场完全不同。
最后是文献排序的自动化。
GB/T 7714著者-出版年制，参考文献先列中文，再列英文，各按姓名字母排序。61条文献混在一起，谁在谁后面，手动排一遍没有人会不出错。
所以我写了一个排序验证脚本，把参考文献列表跑一遍，确认中文部分按拼音顺序正确，英文部分按姓氏字母顺序正确。AUDIT-4专门管这件事。
孤立检查（AUDIT-5）也是脚本完成的：正文每一处引用，格式是(作者, 年份)或作者(年份)，脚本扫全文把这些引用全部提取出来，跟参考文献列表做双向比对。正文有、列表没有的是幽灵引用；列表有、正文没引用过的是僵尸文献。这两类问题，用肉眼在5万字的正文里逐条检查，估计要花一天。脚本跑一遍，三分钟，结果列出来，逐条修复。
文献这件事，值得这么认真对待。因为参考文献不只是论文的附录，它是你的学术信用背书。61条文献，每一条都是你声称自己读过、理解过、正确引用过的东西。一条幽灵引用或者一个错误归因，在答辩台上可以直接把你的可信度砸掉。用工程方法管文献，不是在做过分复杂的事。是在做这件事应有的认真程度。
唯一真相源——SSOT如何根治数据混乱
写论文最让人抓狂的不是写作本身。是你改完第五章，发现第三章那个数字跟它对不上。你回头改第三章，又发现第七章的结论引的是第五章改之前的版本。你不知道哪个是对的。你开始怀疑自己的记忆。
这不是粗心。这是一个架构问题。
说白了，如果每个人都在自己的笔记本里记一个版本的数字，这个项目迟早会出事。SSOT的意思很简单：系统里只能有一个地方是对的。
我的解法是一张表。一张只有12个条目的表，叫数据口径速查表。
每一个在论文里出现超过一次的关键数字，都只有一个权威来源。385万件/年，来自人社部2024统计公报，原文写"劳动人事争议仲裁受理385.0万件"，一字不差。约75%无律师代理，来自多地劳动仲裁委员会公开代理率数据的保守反推，注意那个"约"字——不是随手写上去的，是强制要求的，因为这不是全国统一口径的官方统计。毛利率96%-97%，来自附录A的计算模型，扣除LLM成本和支付手续费之后的实际数字。
这12个条目覆盖了论文里几乎所有会被追问来源的数字。
修改规则只有一条：先改源头，再改下游。你要把385万改成386万？先改速查表，再grep全文找到所有引用这个数字的地方，逐一同步。禁止反向——你不能先改章节里的数字，再去速查表里"更新"它。因为一旦反向，速查表就失去了权威性。它不再是真相源，只是一个滞后的备忘录。
"约"字这件事值得单独说一下。有意思的是，这一个字是整个SSOT体系里最容易被删掉、也最不能被删掉的东西。仲裁代理率没有全国统一口径的官方现成结论，你把保守反推结果写成一个绝对精确的数字，就等于在给自己挖坑。评委一追问地区差异和推算方法，你就会很被动。"约75%"留的是方法边界，不是偷懒。这是数据诚实，不是数据不严谨。
但SSOT不只是那一张速查表。
SSOT本质上是一种思维方式：对于每一类信息，系统里只能有一个地方是权威的。其他地方都是引用，引用必须和权威保持一致。
在这个论文系统里，参考文献列表是SSOT。61条文献，每条的格式、作者、年份、期刊信息，只在08-参考文献.md这一个文件里是权威版本。正文里出现(Teece, 2010)，你去参考文献列表找对应条目，不是去脑子里回忆。
格式规范是SSOT。小四宋体、20磅行距、上边距3.0cm、图名在图下方居中——这些不是靠记忆的，是靠00-排版规范手册.md。Word排版时遇到任何格式疑问，回到这个文件，不要靠感觉。
待办清单是SSOT。哪个问题修了，哪个问题还挂着，哪条导师反馈处理了，全在00-待办清单.md里。不在脑子里，脑子会骗你。
引用核查报告是SSOT。已经对照PDF核实过的43条文献，发现并修正过的若干处表述错误，全部留档。你不需要记得"那条文献我上周核实过了"，你只需要打开报告，看状态。
Word总装脚本路径是SSOT。04-论文章节/scripts/assemble-docx.mjs，这是唯一的总装脚本，不存在v2、v2-backup、v3-真的最终版这种情况。
这12个SSOT条目之间，有一张隐形的依赖关系图。
数据口径速查表依赖Supabase数据库和附录A计算模型。格式审计门禁依赖排版规范手册。引用核查报告依赖引用核实清单。待办清单是所有其他文件的汇总视图。总装脚本依赖全部10个章节文件。
把这些依赖关系画出来，你得到的不是一张备忘录，而是一张架构图。跟你设计一个软件系统的架构图，结构上一模一样——模块、依赖、数据流向、单一真相源。论文是一个知识系统，知识系统和软件系统面临同样的工程问题。
你不需要记住所有数字。你只需要知道它们住在哪里。
知道数字住在哪里，比记住数字本身更有价值。因为记忆会衰减，系统不会。你三个月后回来修改论文，速查表还在那里，精确到小数点，完整到来源文件。你不需要重新考证，你只需要打开那个文件。
这就是SSOT的本质：不是让你更聪明，是让你不需要那么聪明。
Phase Gate——论文的CI/CD
代码工程有一个成熟的概念叫CI/CD（持续集成/持续交付）。每次你提交代码，自动化测试就跑一遍。测试通不过，代码进不了主分支。没有人工检查的疏漏，没有"我觉得没问题就上了"的侥幸。质量门禁是系统层面的，不是个人自律层面的。
论文没有现成的CI/CD。你得自己造。
我造了四道门，叫Phase Gate。
GATE-1是口径一致性。只要你修改的内容涉及数字，就必须检查速查表是否同步。不是"我改的时候顺手改了"，是"改完之后主动验证"。两件事看起来类似，实际上第一件依赖记忆，第二件依赖流程。
GATE-2是引用完整性。每次你在正文里新增或修改一个引用，必须检查08-参考文献.md里有没有对应条目。正文有引用但参考文献列表里没有条目，叫幽灵引用。参考文献列表有条目但正文里从没引用过，叫僵尸文献。两种情况都是硬伤，答辩时都会被发现。
GATE-3是格式规范。图表编号连续吗？引用格式统一吗？脚注完整吗？这些不是审美问题，是合规问题。学校模板要求图名在图下方，你写在上方，打印出来就是格式错误。
GATE-4是交叉验证。同一个数字如果在多个章节里出现，必须全文grep确认它们完全一致。不是大概一致，是字面上一模一样——包括单位、精度和那个"约"字。
四道门，每修改一章就过一遍。听起来麻烦，实际上每次不超过五分钟。但这五分钟能帮你省掉在定稿前发现"第三章和第六章数字对不上"的那几个小时。
说到grep巡检，这是整个Phase Gate体系里最低成本、收益最高的操作。
一行命令：grep -rn "385万\|290万\|75%" 04-论文章节/
这一行命令告诉你：在论文章节目录下，所有引用了385万、290万、75%这三个数字的地方，精确到文件名和行号。你不需要翻开每个章节文件逐段阅读，一秒钟就看到全局。
有没有用错口径？有没有漏改的地方？有没有新增了一处引用但忘了检查格式？grep会告诉你，它不会漏。
人会漏。凌晨两点改论文，你已经看了同一段文字十遍，你的大脑已经开始自动补全——它看到"385"就以为是对的，因为它期待是对的。grep不会。它只是机械地匹配字符串，没有预期，没有疲劳。
人在凌晨两点会犯错。系统不会。
类似的巡检命令，我为毛利率、LLM成本口径、律师费区间各写了一条。每次改完相关内容，跑一遍，三十秒确认全文一致性。这不是强迫症，这是用工具替代人脑做不擅长的事。
定稿前还有五级终审，比日常的Phase Gate更重。
AUDIT-1是格式对标，对照118项格式清单逐项勾选。118项不是随便凑的数字——那是把学校模板和往届论文里的每一条格式要求拆解之后得到的清单，每一项都有来源，每一项都可勾选。勾完之后，你知道自己过了，不是"我觉得格式应该没问题"。
AUDIT-2是Supabase真实数据核对。论文第六章引用的运营数据——216个会话、881个事件、行为漏斗转化率——都有直接的数据库查询来源。对标核对，确认论文里的数字和数据库里的数字是同一批数据。
AUDIT-3是61条PDF引用核实。61条参考文献，每条核实四个维度：作者/年份一致、关键数据一致、理论归因正确、卷期页码正确。已核实43条，发现并修正了若干处表述与原文不符。答辩时评委可以随机翻到任何一条引用，我能在三秒内找到PDF原文对应页码。
AUDIT-4是排序验证。GB/T 7714规定先中后英、各按姓名字母顺序排列。61条手动排是人间地狱，写个排序验证脚本，五秒钟确认。
AUDIT-5是孤立检查：没有幽灵引用，没有僵尸文献。正文每个(作者, 年份)在参考文献列表里有对应条目，反过来列表每条至少在正文被引用一次。
五级审计，每一级有明确的完成标准和输出记录。不是"大概过了"，是"AUDIT-3已核实43条，剩余18条待核实，待核实条目列表在引用核实清单第3节"。
Phase Gate不是官僚主义。它是你凌晨两点改论文时不会改错地方的保险。
你在深夜改一个细节，改完的那一刻你确信自己改对了。但你忘了第三章有同样的表述，你忘了那个数字还出现在摘要里，你忘了图5.2的注释也引用了那个参数。Phase Gate不需要你记住这些，它的存在就是为了替你在忘记的时候把门关上。
系统的反面：我差点翻车的三次
很多人问我，这套系统是不是一开始就设计好的。
不是。
几乎每一个组件，都是在某次翻车之后才出现的。
第一次翻车：数字开始分裂
前面提到过那个385万的故事。六次引用，三种口径，一小时才找到源头。
那一刻我意识到一件事：我正在用大脑当Excel。
于是SSOT数据口径速查表诞生了。12个关键数字，每个只有一个权威来源，修改只能从源头开始。
第二次翻车：Word是黑洞
导师说"把那个图横轴的标签改一下"。
听起来是一分钟的事。实际上：打开Word，找到图，删掉旧图，插入新图，调整大小，发现排版错位了，花二十分钟重排，检查其他图有没有受影响。
一个标签，改了四十分钟。
Word是一个黑洞。内容和格式全部缠在一起。 你动了内容，格式可能崩；你调了格式，内容可能移位。你永远无法确定你只改了你想改的那件事。
于是模块化和总装脚本诞生了。10个Markdown文件管内容，1262行JavaScript管格式。两件事物理隔离，再也不会互相伤害。
第三次翻车：AI的自信
有一次系统出了问题，我让AI诊断。它非常自信地给出了一个方案，逻辑完整，表述专业，看起来很对。
我照做了。没修好。
它又给了第二个方案。还是很自信。还是没修好。
最后我自己回到原点，从最简单的可能性开始排查，发现问题出在一个很基础的地方——它一开始就排除了这个可能性，因为"太简单了"。
AI会非常自信地犯错。
于是诊断协议诞生了。所有诊断必须先列出三个可能的原因，从最简单的开始验证，验证通过才能进入下一个。不允许跳过简单假设直奔复杂方案。
回头看，这套系统其实不是设计出来的。
是补丁叠出来的。
每一次翻车，补一个组件。补丁多了，就变成了架构。
所以当别人问我这套系统是不是很复杂。
我通常会说：
其实一点也不复杂。
只是我翻过的车比较多。
模块化——10个文件比1个Word强一百倍
前面讲过Word的黑洞效应。内容和格式缠在一起，动一个就可能崩掉另一个。
搜索替换误伤别的章节，调图片位置整页排版崩掉，改一个表格要祈祷不影响其他地方——这是每一个"用Word写论文"的人都经历过的噩梦。
我做了一个违反常识的决定：把论文拆成10个Markdown文件。
每个文件对应一个章节，平均3000到5000字。绪论是一个文件，文献综述是一个文件，商业模式分析是一个文件。它们住在同一个目录下，但它们彼此独立。
改第五章，只打开第五章那个文件。改完保存，关闭。第三章的文件不受任何影响。不可能误伤，因为根本没有打开过。这不是需要注意力和自律才能做到的——这是文件系统层面的物理隔离。
Git记录每个文件的每一行变更。你改了第五章的第47行，commit history里精确到行。三周后你想知道"那个表格是什么时候改的"，一条git log -p 05-定价策略设计.md，变更历史全部呈现，精确到秒。这是Word的修订模式做不到的——Word的"历史版本"是快照，不是行级别的变更追踪。
但10个Markdown文件本身，还不是这个系统最有价值的部分。
真正值钱的是三层文档体系——L1、L2、L3，从项目宪法到模块宪法到文件元数据。
L1是项目宪法，就是那份CLAUDE.md。铁律五条，SSOT十二项，Phase Gate四道门，格式规范，Agent调度规则。这是整个论文项目的最高法。它不常改，但它定义了所有其他文件的行为边界。
L2是模块宪法，是04-论文章节/CLAUDE.md。它管的是这10个章节文件的协作关系：成员清单（每个文件是什么、多少字、什么状态）、依赖关系图（第六章依赖第四章的假设、第五章依赖第九章的附录A）、接口契约（数据如何在章节间共享，引用如何双向检查）。改了一个章节，L2能告诉你这个改动会影响哪些下游文件。
L3是文件元数据，藏在每个章节文件顶部的HTML注释块里。每个章节有自己的INPUT（输入依赖）、OUTPUT（对下游的输出）、DEPENDS（依赖的文件和数据源）、CITATIONS（主要引用）、GATE（本章特有的质量门禁）、STATUS（初稿/修改中/待审/定稿）。这个注释块对Word导出没有影响，但AI协作时，它是关键上下文。
这个三层结构，跟一个中等规模软件项目的分形文档架构是同构的。项目层面的架构决策文件、模块层面的设计规范、文件层面的元数据注释——换个领域，同一套逻辑。论文不是软件，但论文的复杂度和软件项目是一样的量级。用同样的工程方法处理，效果是一样的。
说到底，这个系统最有趣的部分是总装脚本。
1262行JavaScript。一个命令，十秒钟，10个Markdown文件变成1个Word文件。带自动生成的目录，带三线表格式，带奇偶页眉（奇数页章标题，偶数页"北京大学硕士学位论文"），带脚注，带页码系统（摘要和目录是罗马数字，正文是阿拉伯数字）。0.97MB，格式合规，可以直接打印。
这个脚本做的事情，本质上是把内容和格式彻底分离。
Markdown文件只管内容。章节标题、正文段落、引用格式、表格数据、图片引用——所有关于"写了什么"的东西，在Markdown里。格式怎么呈现——字体、行距、边距、表格样式、页眉页脚——在脚本里。
两件事完全解耦。导师说"第四章那个表格加一列"，你打开第四章的Markdown文件，改表格，保存，重新跑脚本，十秒钟新的Word出来了，格式完全一致，一行排版代码都没碰。导师说"行距改成22磅"，你在脚本里改一个参数，重新跑，所有章节的行距全部更新，一个Markdown文件都没碰。
这是"关注点分离"在论文场景里的直接应用。不是一个抽象原则，是一个每次修改都能感受到价值的工程决策。
有一个比较值得展开。传统写法是什么？你在Word里改内容，同时用样式工具改格式，两件事在同一个文件里交缠在一起。改了内容可能影响格式，改了格式可能影响内容的呈现。你永远无法确定你只改了你想改的那件事。
Markdown + 脚本的写法，两件事物理隔离。内容文件里没有任何格式代码，脚本里没有任何实质内容。当你打开某个文件的时候，你就知道你在干什么，你也知道你只会影响那件事。
这就是为什么10个Markdown文件比1个Word文件强一百倍——不是因为Markdown本身有多高明，而是因为它强制你把该分离的东西分离开来。分离开来之后，每一个部分都更容易修改、更容易验证、更容易追踪。
你不是论文作者兼Word排版员。你是论文的产品经理。
产品经理不写代码，也不做设计，但产品经理定义系统如何运作。内容在哪里写，格式在哪里定义，两者如何集成，质量由谁保证——这些是产品级别的决策。
你把这些决策想清楚，写对，跑通，剩下的是系统帮你收尾。内容交给十个Markdown文件，格式交给1262行脚本，质量交给Phase Gate，数据口径交给SSOT。你不是在论文的丛林里靠记忆和自律杀出一条路，你是在一个设计好的系统里，按照规定的路线走到终点。
导师反馈工单化——审稿的闭环
导师发来第一轮反馈的那天，我做了一件大多数人不会做的事。
我没有立刻打开论文改。我打开了一个新的Markdown文件，把导师七条反馈逐字贴进去，然后给每一条加上字段：涉及章节、影响范围、修改方案、状态、优先级。状态只有三个值：待处理、处理中、已完成。优先级只有两级：P0是必须改的，P1是建议改的。
这件事花了我二十分钟。但这二十分钟，是整个审稿周期里最值钱的二十分钟。
导师反馈不是一次对话。它是一个工单。
工单和对话的区别在于：对话结束了就结束了，工单有状态，有追踪，有闭环确认。微信语音里导师讲了七条，你大概记住了五条，改了其中三条，两条改的方向不对，剩下两条你以为不重要略过了。等导师下次看到稿子时，她也很难快速确认你到底改到了哪里。这不是谁的错，这是对话的结构性缺陷——它天然不留痕迹。
工单不一样。七条反馈在文件里，每条都有状态，每条都有修改记录，每条都能追溯到你改了文件的哪一行。导师问"这个地方改了没"，你不需要搜记忆，你打开清单，三秒钟找到对应条目：已完成，修改于2026年3月6日，涉及第三章第3.2节第四段，改动见git commit 73a9e64。
这不是为了应付导师。是为了让自己清醒。
第一轮审稿结束后，我做了总结。导师的七条反馈里，有三类：表述过强、结构问题、数据细节。表述过强是最系统性的问题——论文里有十几处用了"证明"、"确认"、"验证"这样的词，但这是一篇探索性研究，样本量不足以支撑这种确定性。这不是改几个词的事，是全文降调。
于是第一轮改稿，只做一件事：全局降调。找出所有过强表述，换成探索性语言。"证明"改成"初步表明"，"确认"改成"初步验证"，"显示"改成"显示出一定趋势"。这种改法听起来像自我削弱，但它更诚实。一篇样本量只有28个测试案例、216个灰度测试会话的研究，不该说"证明"。不是谦虚，是科学态度。
第二轮改稿处理结构问题：删重复段落、修逻辑矛盾、补情景分析。这比降调难。删重复需要判断哪段保留、哪段删除，不能机械合并。修逻辑矛盾需要找到两章之间表述不一致的地方，决定以哪个版本为准。补情景分析需要新写内容，不是修改，是生成。
第三轮是残留清零。前两轮改的是人能发现的问题。第三轮用grep把所有目标词语扫一遍，看还有没有漏掉的。grep -rn "证实\|确认\|验证" 04-论文章节/ 一行命令，哪个文件第几行出现了这些词，全部列出来。人会漏，机器不会漏。
三轮结束，工单里七条全部变成"已完成"。但我没有就此关掉文件。我在清单底部加了一行备注：哪些是结构性修改，哪些是表述修改，各占多少比例，导师下次看时可能还会提哪类问题。
这个备注只有我自己看。但写出来这件事本身，帮我把一次审稿经历沉淀成了可复用的经验。下一轮导师反馈来了，我不需要从零开始思考如何处理，我有上一轮的模板。
传统方式处理导师反馈，每一次都是重新开始。工单化之后，每一次都是在上一次的基础上迭代。
迭代和重启，长期来看是两种完全不同的命运。
AI在这个系统里扮演什么角色
有人看到我写了"1262行JavaScript总装脚本"、"grep巡检"、"三轮迭代审稿"，就问：这些都是AI写的吗？
答案不复杂：是，也不是。
答案很简单：技术执行，很多是。作者身份，不是。
AI在这个系统里的角色不是作者，是工程团队。
脚本它写。巡检它跑。引用它初筛。格式它先过第一遍。凡是确定性、重复性、可校验的劳动，我都尽量交给它。因为这类工作最该被自动化，不该继续拿人脑去磨。
但论点成不成立，结论该不该降调，哪些话不能为了好看而写满，最后都得我拍板。初稿重写就行，错误归因不能带着进答辩。这也是为什么我后来越来越少让AI代写，越来越多让它代检。
论文项目有自己的CLAUDE.md。跟Obsidian操作系统的宪法一样，它不是说明书，是边界条件。
里面最重要的也不是功能，而是红线：虚假归因不行，数据拔高不行，测试案例冒充真实用户也不行。灰度测试期的216个会话，就是216个会话；初步验证，就是初步验证。AI最大的问题不是偷懒，是太勤快。它会本能地替你把话说满。所以边界必须提前写死。
边界一旦写清楚，它反而很好用。边界之内，执行力很强；边界之外，直接拦住。
但这套系统也有一个副作用。
当你把AI当成工程团队，你就必须接受一件事：
它会犯错。
在这一个多月的使用里，系统记录了108个session、1946条消息、33次错误方案、16次理解偏差。有些问题甚至是我自己最后找到答案的。
这不是AI的问题。这是系统设计的问题。
后来我给系统加了一条规则：所有诊断必须先验证，再修复。
流程只有三步：先列出三个可能的原因，写一个最小测试验证每个原因，再决定怎么修。
AI很擅长执行，但不擅长判断。所以真正的工作不是"让AI更聪明"，而是 让系统更安全。
还有一个教训。
当你开始用多agent并行系统时，节奏会变得很快。但节奏越快，你越需要控制。
因为AI很擅长 快速执行错误的事情。
所以系统里必须有门禁。不是为了复杂，是为了避免高速翻车。
后来我发现一个很明显的区别。
很多人在讨论怎么用AI。
但真正改变效率的不是这个问题。
真正的问题是：怎么为AI设计系统。
工具很重要。但工具只是入口。
结构才是护城河。
人机边界说白了就三句话：AI核查，人判断；AI搭框架，人定表达；AI自动化，人负责任。
它可以把问题全找出来，但不能替我决定哪些结论该保守，哪些句子该降调，哪些地方为了学术诚实必须承认边界。总装脚本可以自动生成Word，但最后那份稿子是不是能交，是我签字，不是AI签字。
AI是过客。但一个训练有素的过客，比一支没有流程的团队更稳定。
它不理解这篇论文为什么存在，也不在乎它最后能不能过答辩。它只处理这一次session里的任务。任务做完，它就走了。也正因为如此，系统必须把输入写得足够清楚：红线是什么，数据从哪来，做完要交付什么。
这条线不能模糊。模糊了，你不知道最后那篇论文是谁的作品。清晰了，你知道：论点是我想的，数据是我核的，责任也是我的。AI只是放大器。
方法不稀缺，代价才稀缺
SSOT、Phase Gate、模块化、总装脚本、文献台账、审稿闭环——这篇文章里出现的所有方法，没有一个是秘密。
但这些方法有一个共同点：每一个都是在某次翻车之后才搭起来的。
知道和做到之间，隔着的不是信息差，是经历差。
这些方法都不难。难的是，在你还没翻过车的时候，你不会觉得自己需要它们。更难的是，就算你知道了，你也未必愿意真的按这个强度把系统搭完。
写论文只是一个例子。
其实很多知识工作，都是同一个问题。写书、写报告、做研究、做产品——如果任务复杂度足够高，它就不再是写作问题。
它是系统工程。
AI时代真正的竞争力，可能不是谁写得更快。
而是谁能 设计更好的系统。
这大概就是我最近一直在想的一件事：Agentic Engineering。
论文还没答辩。5月才答辩。我也不知道最终结果怎么样。
但到今天为止，导师的每一条反馈都有闭环记录。每一个数据口径都可追溯到原始文件。每一条引用都能在PDF里找到对应页码。
系统在跑，没有翻过车。
如果最后还是翻了车，那至少是在一个 可审计的系统里翻的。
而不是在一个叫做
论文v3-修改版-final-最终版-真的最终版.docx
的Word文件里。
把论文当文档写，你会不断返工。
把论文当系统交付，你才有办法收口。
如果你只是想看一篇文章，到这里就够了。
如果你想把这套系统真的搭起来——之后再说。
我是J叔。答辩之后再告诉你系统有没有翻车。
