企业官网建设流程全解析

1. 先想清楚：这套 AI 科研写作工作台到底要解决什么

论文写作这件事，卡住人的从来不是"不会写"，而是流程太碎。我自己带过几届学生，也帮同行改过稿子，发现一个共同现象：真正坐在电脑前敲字的比重可能只占三成，剩下七成时间全耗在找文献、翻旧笔记、把同一段话反复改、核对参考文献编号、调格式、写回复信这些零碎活儿上。所以当我第一次听到"30 分钟搭建 AI 科研写作工作台"这个说法时，第一反应不是怀疑速度快不快，而是这套东西的结构对不对——它得能把论文全流程里那些散落的动作串成一条线，而不是又给你添一个新工具去学。

我把它叫做WorkBuddy 工作台，名字取自"work buddy"（干活搭子）的意思。它不是某一个现成软件，而是我用一套固定的目录结构、一份项目简报、一组提示词模板和两个小脚本拼出来的组合。做法听起来很朴素，但我实际测下来，从零搭好到跑通"选题—检索—提纲—初稿—润色—投稿"这条链路，多数人 30 分钟确实够用，前提是你按顺序来，别一上来就折腾工具。

这篇文章适合三类人看：正在写第一篇正式论文、被流程拖得焦头烂额的新手；手上同时压着两三篇稿子、想找统一工作流的在读研究生；以及虽然有经验、但一直靠"人工记忆 + 到处乱放文件"硬扛的资深研究者。文中所有步骤都可以照着复现，命令和模板我会直接贴出来。

1.1 三个真实痛点拆解

先说清楚痛点，才知道工作台该往哪儿使劲。我观察下来，科研写作里最耗神的三件事是：素材找不到、上下文丢失、重复劳动多。

素材找不到，根源是文献和笔记没有一个收口的地方。浏览器书签一层套一层，下载文件夹里躺着一堆文件名是乱码的 PDF，笔记软件里记了几条关键结论却没标出自哪篇。等到要写综述，你得凭印象一篇篇翻回去找原句，光这一步就能吃掉一整天。

上下文丢失，是很多人用了 AI 之后的新问题。每次开个新对话，都得把研究背景、目标期刊、写作风格、术语偏好重新交代一遍。更麻烦的是，上一轮谈好的结论没法带进下一轮，模型给的段落前后打架，你还得自己当编辑去缝合。这不叫效率工具，这叫把一个体力活换成了一个脑力活。

重复劳动多，最典型的是三样：同一段话要改成中文版、英文版、投稿信版；参考文献编号一动，全文交叉引用全乱；审稿意见回来，几条意见其实指向同一个改法，却要分开写回复。这些动作没有创造性，但每一步都不能省。

1.2 为什么是"工作台"而不是"某个更强的工具"

市面上不缺单点能力强的工具：文献管理有专门软件，写作有编辑器，翻译和润色有各种服务。问题是它们彼此不通气，你在 A 里做的整理，到 B 里还得重做一遍。我试过最极端的方案，一口气装了七八个工具，结果每天花二十分钟在窗口切换和文件搬来搬去上，纯属给自己上刑。

工作台的思路正好相反：工具可以普通，但数据必须留在同一个地方、同一种格式里。我把所有素材统一转成纯文本或 Markdown，放在固定目录下，任何环节需要调用，直接读文件就行。这样做的好处很实在——文件是持久的、可版本管理的、可以用文本工具批量处理的，也不依赖某个服务的存活周期。你在里面投入的每一分钟整理，后面都会被复用十几次。

提示：不要一上来就追求"全自动"。我踩过的坑是搞了一套复杂的自动化流水线，结果中间任何一环出问题都定位不到，反而比手动慢。先手动跑通一遍完整流程，把最烦的两个环节自动化，就够了。

1.3 30 分钟的时间预算怎么分配

很多人搭工作台失败，不是能力问题，是节奏问题——在第一步打磨目录结构打磨一小时，热情耗尽。我建议严格按下面这个时间块推进，每块到点就停，后面还能回头优化。

这张表的核心逻辑是：先让链路通，再让链路好。第一遍允许粗糙，粗糙的地方记在待办里，等真正写稿时自然知道哪里最疼，那时候再优化，投入产出比高得多。

2. 整体架构与工具选型：WorkBuddy 的四层结构

我把这套工作台分成四层，每一层只干一件事，层与层之间靠文件对接，不靠记忆对接。这个划分方式借鉴了软件工程里"关注点分离"的思路——听起来有点绕，其实道理很简单：如果一件事既管收集又管生成还管检查，出问题时你根本不知道怪哪一环。

四层分别是：输入层、上下文层、生成层、质检层。输入层负责把外部素材变成本地可读的文本；上下文层是整套系统的"记忆"，包括项目简报、术语表、写作规范、已定稿的段落；生成层负责产出提纲、初稿、改写版本；质检层做那些机器比人擅长的检查——编号是否连续、术语是否统一、字数是否达标、引用键是否都能在源文件里找到。

我特别想强调上下文层。很多人用 AI 写作效率不高，根本原因不是模型不行，而是它每次都从零开始理解你的研究。上下文层的意义就是把这部分"理解成本"前置一次，之后反复复用。一份写得好的项目简报，能顶掉后面几十次重复交代。

2.1 四层结构的职责边界

职责边界这件事必须写死，否则会互相污染。我的规矩是：输入层只读不改，上下文层只增不删，生成层按需覆盖，质检层只出报告不动正文。

输入层只读，意思是原始文献转成文本后就冻结，后续任何修改都另存新文件并标注版本。这条规矩救过我一次：某次我发现综述里引用的一个数据前后不一致，顺着查下去，发现是我早期"顺手改了一下"源文件里的表述，导致后面所有基于它的段落全错。自那以后，源文件一律不动。

上下文层只增不删，指的是简报和术语表这类文件允许不断追加条目，但不删旧记录。原因很现实：写论文是个长周期活儿，你可能两个月后才想起来某次为什么排除了一篇文献，记录还在，就能自证。

生成层按需覆盖，是因为草稿本身就是消耗品。我的30-draft目录里永远有v1、v2到v7这种版本，每轮大改前先复制一份，改坏了能退回去。质检层只出报告，是为了保持客观——检查工具一旦能自动改稿，人就会懒得看它改了什么。

2.2 选型逻辑与几个关键取舍

选工具时我给自己定了三条硬标准：数据能导出、格式是纯文本、离线可用。前两条保证不被锁死，第三条保证在没网的环境下也能干活——别笑，出差路上、会议室里、飞机上，没网的场景比想象中多。

下面这张表是我实际对比过的几类方案，以及我为什么最终选了现在这套：

结论很清楚：主干用最笨的文件夹加文本，聪明的部分只加在刀刃上。文献管理软件继续用，因为它管元数据确实方便；在线平台只在投稿前排版时碰一下；自动化脚本我只写了两个——引用检查和术语扫描，因为这两件事高频且规则明确。

还有一个取舍值得说：我没有把工作台做成"一键生成论文"。技术上做得到，实际上没用。论文的价值在于判断和论证，这两样东西现在还得人来出。工作台要加速的是判断之外的搬运工作，把这个边界想清楚，你就不会对工具有不切实际的期待，也不会因为它某次输出不好就全盘否定。

2.3 目录规范与文件命名

目录结构我改过四五版，最后稳定成下面这个样子。每一层的编号不是装饰，是给排序用的——在文件管理器里按名字排，天然就是工作流的顺序。

workbuddy-paper/ ├── 00-brief/ 项目简报、目标期刊要求、时间节点 ├── 10-sources/ 文献原文（转纯文本）、索引表 ├── 20-notes/ 阅读笔记、数据摘录、灵感碎片 ├── 30-draft/ 各版本草稿 ├── 40-assets/ 图表源数据、图片、补充材料 ├── 50-review/ 审稿意见、回复信、修改说明 └── 90-archive/ 过期版本、废弃方案（不删，只挪）

命名规则我用的是一句话能读懂的形式：日期_主题_版本，比如0312_综述段落_数据一致性_v3.md。别小看命名，三个月后你打开文件夹，能靠文件名判读内容，比点开十个文件快得多。另外几个细节：文件名不带空格（脚本处理时省事）、不用中文标点（避免编码问题）、版本号用两位数（v01而不是v1，排序才对）。

注意：90-archive这个"垃圾站"目录一定要有。人的心理是"删了怕后悔"，结果就是不敢删、目录越来越乱。给它一个去处，清理就变成移动，心理负担立刻小很多。

3. 30 分钟实操：从零到跑通全流程

这一节是纯操作，我会把每一步具体敲什么、写什么都放出来。假设你现在手上有一篇要写的稿子，先别管它写到哪一步，跟着走一遍。

3.1 前 10 分钟：骨架与项目简报

第一步，建目录。Windows 用资源管理器手动建也行，习惯命令行的直接复制下面这段（macOS / Linux）：

mkdir -p workbuddy-paper/{00-brief,10-sources,20-notes,30-draft,40-assets,50-review,90-archive} cd workbuddy-paper && ls

第二步，写项目简报。这是整套系统里性价比最高的一个文件，值得多花五分钟。我在00-brief/brief.md里固定写六块内容：

# 项目简报 ## 研究对象 （一句话说清研究的是什么，不超过 30 字） ## 核心问题 （这篇论文要回答的那一个问题，只能有一个） ## 主张与证据 - 主张： - 关键证据 1： - 关键证据 2： ## 目标期刊 - 期刊类型与定位： - 篇幅要求： - 结构要求（是否有固定小节）： - 引用格式： ## 写作约定 - 人称：第三人称 / 第一人称复数 - 时态：方法与结果用过去时 - 术语表见 terms.md，全文必须一致 ## 边界 （明确不做什么，防止越写越散）

为什么这六块？因为它们是模型每次都要问、而你每次都懒得答的东西。把它写下来，后面每个提示词开头贴一遍，等于给模型装了个随身记忆。我实测过，加不加这份简报，同一段初稿的质量差距很明显——加了之后基本不需要再解释背景，直接就能出可用的句子。

第三步，建术语表00-brief/terms.md。格式很简单，一行一个：中文术语 | 英文对应 | 禁用写法。这个东西看着枯燥，但它解决的是论文里最容易被审稿人挑刺的问题——同一个概念前后叫法不一致。有了这张表，后面质检脚本能直接扫。

3.2 中 10 分钟：把文献变成可检索的文本

文献这一步我用"够用就好"的策略：不追求把所有收藏都导进来，只导和当前这篇稿子直接相关的 10 到 20 篇。原因很实在，导得越多，噪音越大，检索时反而找不到东西。

具体做法分三步。第一步，把 PDF 放进10-sources/raw/，用文献管理软件统一命名成第一作者_年份_关键词.pdf。第二步，转成纯文本，放在10-sources/txt/。第三步，建一张索引表10-sources/index.md：

引用键这一列是关键，格式用"作者+年份"全小写，全文引用只认这个键，最后排版时再用脚本统一替换成目标格式的编号。这样做的好处是：投稿被拒改投另一本期刊，引用格式从数字改成作者年份，你只需要跑一次脚本，不用手工改几百处。

提示：转文本时保留页码标记，比如每页前后加[p.12]。写综述时想回头核对原句，靠页码能十秒定位，这个习惯省下的时间远超你加标记的时间。

3.3 后 10 分钟：四个提示词模板与两个检查脚本

模板不要多，四个够用。我把它们放在00-brief/prompts/下，每个文件一个模板，用的时候复制粘贴加参数。

模板一：提纲生成

【角色】你是我的写作搭档，熟悉本领域常见论文结构。 【上下文】以下是我的项目简报： {{brief.md 全文}} 【任务】基于上述简报，给出三个不同侧重的提纲方案。 【要求】 1. 每个方案标注适用场景（偏理论/偏应用/偏方法） 2. 每个小节写清"这一节要证明什么"，而不是"这一节写什么" 3. 指出每个方案最薄弱的环节 【输出】纯 Markdown，不要开场白

模板二：段落扩写

【上下文】{{brief.md}} 【已有内容】{{当前小节已有文字}} 【任务】把下面这条要点扩写成 200 字左右的学术段落： {{要点}} 【要求】 1. 只使用我提供的信息，不得引入新的数据或文献 2. 需要引用处用 {{引用键}} 占位，不要自己编 3. 不用"众所周知""显而易见"这类词

第三条要求特别重要。我吃过亏——早期没限制，模型给我补了一段"据研究显示"，我一时没查就用了，后来核对发现那篇文献根本没这个结论。从那以后，所有引用位置一律用占位符，人工填，这条规矩我到现在没破过。

模板三：润色分级

【任务】对下面文字做第 {{N}} 级润色。 第 1 级：只改语法和标点，不动句序。 第 2 级：合并冗余句，调整逻辑连接，保持信息量不变。 第 3 级：按目标期刊风格重写段落结构，允许调整句序。 【约束】三级都不许新增事实、不许改变数据、不许替换专业术语。 【输出】修改后文本 + 一段不超过 50 字的改动说明。

分级的意义在于可控。第 3 级改动力度大，适合初稿；投稿前只用第 1 级，避免把已经打磨好的表述又改乱。

模板四：审稿意见归类

【任务】把下面的审稿意见拆成独立条目，并按"必须改/建议改/可解释"三类归档。 【要求】每条标注涉及正文哪一节，指出哪些意见其实是同一个问题的不同说法。 【输出】表格：意见原文 | 归类 | 涉及章节 | 建议处理方式

两个脚本都不复杂。第一个查引用键是否都存在：

#!/usr/bin/env bash # check-cites.sh —— 检查正文里的引用键是否都能在索引表中找到 set -euo pipefail DRAFT="${1:-30-draft/current.md}" INDEX="10-sources/index.md" grep -o '{{[a-zA-Z]*[0-9]\{4\}}}' "$DRAFT" | tr -d '{}' | sort -u > /tmp/used.txt grep -o '^| *[a-zA-Z]*[0-9]\{4\}' "$INDEX" | tr -d '| ' | sort -u > /tmp/known.txt echo "== 正文引用了但索引表里没有 ==" comm -23 /tmp/used.txt /tmp/known.txt echo "== 索引表里有但正文没引用 ==" comm -13 /tmp/used.txt /tmp/known.txt

第二个查术语一致性，用 Python 写更省事：

# check-terms.py —— 扫描草稿中是否出现术语表里的禁用写法 import re, pathlib terms = pathlib.Path("00-brief/terms.md").read_text(encoding="utf-8") banned = [] for line in terms.splitlines(): parts = [p.strip() for p in line.split("|")] if len(parts) >= 3 and parts[2] and not parts[2].startswith("-"): banned.append(parts[2]) draft = pathlib.Path("30-draft/current.md").read_text(encoding="utf-8") hits = [(b, draft.count(b)) for b in banned if b in draft] for word, n in sorted(hits, key=lambda x: -x[1]): print(f"{word}\t出现 {n} 次") print("检查完成，共", len(hits), "处待处理")

两个脚本加起来不到四十行，但每次改稿前跑一遍，能省掉投稿后被审稿人指出"术语不统一"的尴尬。这就是我说的"聪明加在刀刃上"。

4. 论文全流程加速：六个环节的具体打法

工作台搭好只是地基，真正省时间的是把它用进每个环节。下面按写作顺序讲，每个环节我都会说清楚"机器干什么、人干什么"，这条分工线画不清，效率提升会很有限。

4.1 选题与文献缺口定位

选题这一步，机器能帮的是穷举，人负责取舍。我的做法是拿核心问题去检索，把近三年的相关文献摘要批量拉下来，然后让模型做一件事：按"研究了什么 / 用了什么方法 / 得出什么结论 / 遗留什么问题"四列，生成一张矩阵表。

这张表的价值在于，你把所有行的第四列竖着看一遍，缺口自然浮现。我常用的一个判断标准是"三圈交集"：方法圈（你手上的技术能力）、数据圈（你能拿到的数据）、问题圈（领域里公认还没解决的问题）。三个圈的交集才是能落地的选题。只有问题圈没有数据圈，选题再漂亮也做不出来。

这一步要防的坑是"看起来新、其实早有人做过"。我的做法是让模型明确列出它认为最接近的三篇工作，然后我逐篇核对原文。凡是模型提到的文献，一律当"待核实线索"处理，不当事实。这个习惯养成之后，返工率会明显下降。

4.2 文献综述：用矩阵表代替大段摘抄

综述写不好，多数是因为写成了"甲说了什么，乙说了什么"的流水账。我改用矩阵驱动：先建表，再写文。

表的列固定为：文献、样本/数据、方法、主要结论、局限、与我的研究关系。每读一篇填一行，读够十五篇左右，你会发现某些列开始出现重复模式——重复出现的局限，就是你这篇论文可以切入的地方。写的时候不再按文献顺序，而是按"主题句 + 多篇证据 + 我的评述"这个结构展开，一段只讲一个论点，证据用引用键挂上去。

这样写出来的综述有个明显好处：审稿人问"你为什么漏了某类工作"，你能立刻在表里查到当时是判定为不相关还是没检索到。表格就是你的检索记录。

注意：矩阵表里"与我的研究关系"这一列千万别空着。这一列空着的行，八成是白读的——读了但说不清它和你有什么关系，说明它本来就不该进这篇稿子。

4.3 提纲到初稿：分段生成加事实锚点

初稿阶段最忌讳的是"让模型一口气写三千字"。那样出来的东西看着完整，实则每段都浮在表面。我的做法是把提纲拆到三级标题，一次只生成一节，而且每节必须先给"事实锚点"。

所谓事实锚点，就是这一节要用的具体材料：哪几个数据、哪几条引用、哪张图。我一般这样写提示：

【本节任务】写"3.2 实验结果"这一节，约 600 字。 【事实锚点】 - 数据：表 2 中的三组对比，样本量分别为 120 / 118 / 125 - 引用：{{smith2021}} 报告过类似趋势，{{lee2023}} 结论相反 - 图：图 3 显示随温度升高指标下降 【约束】只能使用上述锚点，缺材料的地方写 [待补]，不要自行补全。 【输出】正文段落 + 一段"本节待补清单"

"[待补]"这个标记是我的核心技巧。它把模型的"编造冲动"转化成了"待办清单"，我每次写完一节，立刻能知道缺什么材料，是去补数据还是去补引用，一目了然。整篇初稿写完，把所有 [待补] 搜一遍，通常二三十处，一天内能清完，比事后逐句核对可信度高得多。

4.4 图表与数据描述的一致性

图表这块，机器帮不上太多，但有个环节特别值得用：图注和正文描述的一致性。我见过太多稿子，图注写"显著上升"，正文写"略有上升"，审稿人一眼就看出来。

我的流程是：先在40-assets/放源数据表，然后让模型只做一件事——根据数据表生成三样东西：图注（不超过 40 字）、正文描述句（一到两句）、以及一个"数值核对清单"（列出描述里提到的每个数字，标注它来自表格哪一格）。最后这个清单是重点，我会拿它逐项对一遍原始表格。数字对不上，说明描述是模型自己"感觉"出来的，必须改。

另外一个小经验：图表命名统一用fig01_主题.png、tab01_主题.md这种形式，正文里提到图 1 就写图 1，不要一会儿"下图"一会儿"图 1"。质检脚本里可以加一条规则，扫"下图""上图""如下表所示"这类指代，改成明确编号。投稿前做一遍，能减少很多格式上的挑刺。

4.5 三档润色与中英转换

润色我坚持分级，前面模板已经给了。这里补几个实操细节。

第 1 级只改语法，适合已经定稿的段落。第 2 级合并冗余句，适合初稿刚出来那几天。第 3 级重写结构，我只在写摘要和引言时用，因为这两部分对节奏要求最高。方法和结果部分我基本不用第 3 级——数据描述的句子结构一旦被重排，很容易把因果说反。

中英转换的坑更多。我的做法是中文写、英文译，而不是两边同时写。同时写的后果是两边都半生不熟。翻译时给模型的约束要写死：术语按terms.md走、被动语态优先、句子长度控制、不要用修辞性表达。译完我只看三样：术语是否一致、数字单位是否对、逻辑连接词是否保留了中文的论证方向。这三样查完，剩下的语法问题交给第 1 级润色。

4.6 投稿材料与审稿回复

审稿意见回来那天，是最容易情绪化的时候。我现在的固定流程是：先把意见原文贴进50-review/，用模板四做归类，然后只处理"必须改"这一类，处理完再回头看"建议改"。

回复信我用的结构是四段式：感谢 + 复述意见 + 具体改了什么（附位置）+ 补充说明。"具体改了什么"这一栏我一定要写清页码和段落，因为审稿人复查时最烦的就是满篇找改动。另外，如果某条意见我不打算改，会写清理由并给出替代方案，而不是简单说"我们认为无需修改"——后者是激化矛盾最快的一句话。

5. 常见问题与排查速查表

这套东西用了大半年，出问题的地方其实高度集中。我把它们整理成表，方便你遇到时直接对照。

5.1 典型故障与处理

5.2 防幻觉的四条硬规矩

这一小节我认为是全篇最该抄走的部分。工具会变，这四条不变。

第一条：所有具体数字必须能追溯到源文件。模型给的任何数值、比例、样本量，我都要在源表里找到对应格子。找不到的，一律删掉或标 [待补]。这条没有任何例外。

第二条：引用只认键名，不认作者年份文字。提示词里明确禁止模型输出"某某等人（2021）指出"，只允许{{键名}}。因为一旦它开始写作者名，就有一半概率写错年份或拼错名字。

第三条：模型提的文献一律先核实再入库。我有个固定动作，每篇新文献进10-sources之前，必须亲眼看到原文的方法或结论部分，并把一句话结论填进索引表。没看过原文的，不进表。

第四条：结论句必须由人来下。每一节的最后一句，也就是那句"因此可以认为……"，我从来不让模型写。原因很简单，论证的方向和强度是作者的责任，这句话写歪了，整节的意思就变了。

提示：如果某天你发现自己开始"懒得核对"，那就是该停下来休息的信号。这套工作台放大的是判断力，不是替代判断力。

6. 我实际用下来的一点体会

踩过几次坑之后，我对这类工作台的态度变得比较务实：它不会让你从不会写变成会写，但它能把"会写的人"从流程泥潭里捞出来。我自己的体感是，同样一篇稿子，从提纲到可投稿状态的周期大概缩短了三成到四成，省下来的时间基本都花在了核对和论证上——这恰恰是应该多花时间的地方。

如果后面还想继续扩展，我会往两个方向走。一个是把20-notes里的阅读笔记做成可检索的小片段库，写综述时按关键词直接捞，不用再翻原文；另一个是把回复信也模板化，按"数据问题 / 方法问题 / 表述问题"三类各准备一套骨架，下次审稿意见回来，先套骨架再填内容。这两件事都不难，但都得等手头这篇稿子投出去再说——工具是用来干活的，别让搭工具本身变成新的活。

最后分享一个很小的习惯：每次关电脑前，在00-brief/todo.md里写三行——今天做到哪、卡在哪、明天第一件事干什么。第二天打开电脑不用重新进入状态，直接开工。这个习惯跟 AI 一点关系没有，但它是我这套工作台里最省钱的一环。