开头
想象一下，你手上有几十篇学术论文要改写成公众号科普文章。每篇论文动辄三五十页，充斥着晦涩术语。靠人工写作，一篇至少要花两三小时。能不能交给AI自动化处理？我在亚马逊工作时深度参与过六页纸写作流程的标准化，知道结构化文档的威力。既然学术论文改写也有固定套路，那能否用"文档即代码"的方式，让AI按预设流程自动生产？如何才能让AI既不编造虚假信息，又能保持科普文章的易读性？答案是：用三份文档驱动Claude Code，构建一个5阶段的智能改写流水线。从10月4日中午12点启动项目到下午5点完成测试，仅用5小时就实现了从零到可用的自动化系统。
一份需求文档，换来80%可用代码
整个项目叫wepaper，我先花半小时手写了需求文档need.md，明确定义了输入（CSV文件里score==9的论文）、输出（2500字的中文科普文章）、处理流程（初稿生成→QA反馈→基于反馈改写→最终润色→自动分类）。需求文档里最关键的是写作规范：面向9年级以下语言水平的读者，句长不超过30字，每句话独立成行便于修改。这些看似琐碎的规定，实际上是为了约束LLM的输出质量。
拿到需求文档后，Claude Code自动生成了设计文档design.md。它自己推导出了单线程处理保证编号一致性、使用状态文件做断点续写、设计原子性文件写入等细节。它还主动提出了文本抽取的优先级策略——先读本地txt镜像，失败后依次尝试pdfminer、pdfplumber、MinerU。这种"AI推导设计"的能力让我看到了它的架构思维。设计文档完成后，Claude又自动生成了计划文档plan.md，把开发拆解成11个任务。虽然预估需要2-2.5天，但因为文档指引清晰，Claude Code实际5小时就完成了全部功能——9个Python文件，实现了CSV解析、状态管理、文本提取、双API客户端、5阶段处理逻辑、分类器。
踩坑实录：当AI开始编造假作者名
开发过程最惊险的一刻出现在测试初稿生成时。我用Teece等人1997年的经典论文《动态能力与战略管理》做测试，这篇论文在Google Scholar有3.8万次引用。系统跑完第一阶段后，我打开生成的初稿文件，参考文献部分赫然写着："作者：张三、李四……"。原论文作者明明是David J. Teece、Gary Pisano、Amy Shuen，怎么变成了张三李四？LLM在编造虚假信息。
问题的根源在于：初稿生成的Prompt里只传入了论文正文内容，LLM的训练数据里没有这篇具体论文的元数据，它只能根据上下文"猜"一个看起来合理的作者名。中文环境下，它就猜成了"张三李四"。
怎么办？我想起在亚马逊写六页纸时的一个原则：重要信息必须有可追溯的来源。于是我增加了一个Stage 0（元数据提取阶段）：让系统先从论文原文的前3000字符里抽取真实的作者、机构、年份、期刊信息，保存成结构化数据，再作为变量传给后续所有阶段的Prompt。比如初稿Prompt里改成了："这项研究由{authors}完成，于{year}年在{journal}发表……"。这样一来，参考文献100%准确，再也没有出现编造的情况。这个小插曲让我意识到：AI不是万能的，它需要被"喂"正确的输入。Prompt设计不仅要告诉AI做什么，还要告诉它"依据什么"做。
Prompt设计的关键：约束越多，质量越高
整个系统的核心是5个处理阶段，每个阶段都是一次LLM调用，前后衔接形成流水线：Stage 0提取元数据→Stage 1生成2500字初稿→Stage 2模拟三类读者提出6个反馈→Stage 3基于反馈改写→Stage 4去结构化标记润色→Stage 5自动分类归档。
Prompt设计遵循三个原则。第一是结构化模板。比如初稿生成的Prompt，我详细定义了每个部分的字数（SCQA开头150字、论文说明500字、研究结果600字……）、格式（每句独立成行、段落间空一行）、语言风格（9年级以下语言水平、句长不超过30字），让LLM没有发挥空间。第二是变量传递。Stage 0提取的元数据以变量形式传入所有后续阶段，确保信息准确。第三是纠偏机制。每个阶段的输出都会经过规则校验，不合规就追加一次"纠偏Prompt"要求重新生成。
我在写《六页纸+AI：亚马逊式领导力的中国实践》这本书时，深度研究过亚马逊的文档文化。亚马逊要求每个项目启动前先写六页纸，把问题、解决方案、用户痛点都说清楚。这个wepaper项目就是"六页纸思维"的实践：需求文档相当于定义问题，设计文档相当于提出方案，计划文档相当于分解执行路径。有了这三份文档，AI就像有了GPS导航，不会跑偏。
5小时时间线与分工
从日志里可以清晰看到整个开发过程。10月4日12:07第一次运行，遇到"No score==9 rows found"错误，12:09修正后成功处理了第一篇测试论文，全流程耗时约1分半钟。12:52切换到真实论文。16:36时Kimi API调用失败，系统自动降级到DeepSeek API。16:41系统成功提取了元数据，16:45完成分类，文章被复制到blog目录。
整个项目中，我和Claude Code的分工非常清晰。我负责"定义目标和约束"：手写需求文档，明确输入输出、5阶段流程、写作规范；发现元数据提取问题后，提出增加Stage 0的需求；定义分类规则；审查生成的文章质量。Claude Code负责"设计和实现"：根据需求文档自动生成设计文档和计划文档；编写9个Python文件，实现全部功能；自己修正bug。更有意思的是，Claude在实现过程中展现出了"自我纠偏"能力，比如双API策略的优先级参数，是它自己推导出需要增加的，这种"理解意图并主动补全细节"的能力，让我感觉像是在跟一个有经验的工程师协作。
最终生成的文章质量如何？我抽查了001-动态能力与战略管理.md，标题是"26年过去，为什么企业还在用这个理论打天下？"，副标题"六页AI文献综述之动态能力与战略管理"，开头用SCQA结构引入，全文2500字左右，每句话独立成行，完全符合预设的写作规范。更重要的是，参考文献信息完全准确，没有出现编造的作者名。
新范式：人定义目标，AI实现路径
这个项目给了我三个意外收获。第一是"文档即代码"的威力被放大了。在AI辅助开发中，文档变成了"可执行的需求说明书"，只要需求文档写得足够清晰，AI就能生成80%可用的代码。第二是AI的"架构能力"超出预期。状态文件的设计、原子性写入的实现、双API容错机制，这些都不是我明确要求的，而是Claude根据"批量处理3000篇论文"的场景自己推导出来的。第三是"约束越多，质量越高"。很多人用AI时倾向于给宽泛指令，但我的经验恰恰相反：Prompt设计得越详细、约束越明确，输出质量越稳定。
这个wepaper系统让我看到了"AI+文档"的新范式。过去写代码是程序员的专利，现在只要你能把需求写清楚，AI就能帮你实现80%。剩下的20%人工打磨，反而成了真正有价值的创造性工作——定义什么是"好"，而不是重复性地实现"好"。如果你也想尝试用AI构建自动化系统，我的建议是：先花时间写一份详尽的需求文档，把输入、输出、流程、约束、异常处理都想清楚。然后让AI生成设计和计划文档，跟它讨论细节、提出改进。最后让AI写代码，你负责测试和迭代。这种"人定义目标、AI实现路径"的协作模式，可能就是未来知识工作的标准形态。
