Fast For Short Essay：我给短篇论文写了一个 Agent Skill

#AI Agent #Skill #学术写作 #LaTeX #自动化 被打开 -- 次

最近做了一个小工具，准确说是一个 Agent Skill：Fast For Short Essay。

仓库地址：https://gitee.com/Smercapto/ssfe.-fast_-for_-short_-essay-skill.git

它的中文名可以叫：短篇学术/技术写作自动化 Skill。

这个名字听起来有点长，但它想解决的问题其实很简单：

让 AI 不要一上来就“帮我写一篇论文”，而是先把资料、模板、引用、图表、编译和最终检查这些容易翻车的地方管住。

为什么要做这个 Skill

大学生最容易头痛的就是 小论文、课程报告、实验报告这些看起来似乎又没那么重要，但是上手一做就是时间杀手，还不一定能做得好。他们看起来篇幅不长，但是自己慢慢写又费时费力，盯着一个小屏幕，在知网，万方，文档，浏览器反复横跳实在让人头大。那有人就说了：我们用ai生成不好吗？确实，好像让 AI 一口气生成全文就行。但真正交作业或者交报告的时候，就很容易在这些地方头疼：

  • 参考文献是不是编的；
  • DOI、页码、卷期、作者是不是乱补的；
  • 图表有没有来源，题注和正文能不能对上；
  • 模板要求有没有被忽略；
  • PDF 能不能编译；
  • 编译出来的 PDF 有没有表格溢出、图被截断、首页占位符残留；
  • 作者、单位、课程、学号、日期这些个人信息有没有被 AI 瞎填；
  • 最终提交包里到底哪个版本才是能交的。 这些问题很烦，但又很现实。

所以我做这个 Skill 的初衷不是“让 AI 写得更快一点”，而是让它不要快到把坑都留到最后。我希望能提供一种让这些小的“大作业”更无痛完成，看起来更专业，节约更多时间到更有实际意义的数据收集，原理理解，知识学习上面去，而不是反反复复切页面，排版这样的机械动作上。

（当然要拿来偷懒似乎也……咳咳，建议还是不要完全偷懒哦，毕竟写报告过程中一般还是能学到不少东西的（突然开始严肃脸.jpg））

它不是一个普通 Prompt

普通 Prompt 很容易长成这样：

请你根据以下主题，写一篇 3000 字论文，要求有摘要、关键词、参考文献……

然后 AI 会很努力地给出一篇看起来完整的文章。

但“看起来完整”不等于“可以提交”。

Fast For Short Essay 的思路是把任务拆成一条比较严格的流程：

环境预检 → 项目初始化 → 来源与参考文献登记 → 大纲 / 图表 / 引用计划 → 分章节写作 → 逻辑审查与润色 → 格式工程化 → PDF 编译与日志修复 → 信息确认 → 截图视觉核查 → 最终提交包

也就是说，它不鼓励 Agent 直接开写全文，而是让 Agent 像一个比较啰嗦但靠谱的助教一样：先确认环境，先把材料登记清楚，先知道哪些资料能用、哪些资料不能支撑关键结论，再开始写。

这也是它和普通写作提示词最大的区别。

两种模式：Standard 和 Strict

这个 Skill 里目前保留了两个主要模式。

Standard Mode

适合普通课程论文、技术报告、实验报告、综述报告。

它会要求 Agent 至少完成：

  • 环境预检；
  • 需求采集；
  • 项目目录初始化；
  • 资料登记；
  • 大纲、图表、引用计划；
  • 分节写作；
  • 技术审查与润色；
  • 引用一致性检查；
  • 至少一种可提交输出；
  • 信息确认文件；
  • 最终检查报告。 如果目标输出是 PDF，还需要编译和视觉核查。

Strict Mode

Strict Mode 就更“强迫症”一点。

它适合有明确模板、必须生成 PDF、必须有参考文献格式、必须保留源码和编译日志、还要整理最终提交包的场景。

比如学报模板、课程模板、格式要求很死的报告，就更适合走 Strict Mode。

为什么没有 Quick Mode

一开始其实我先做过一个Quick Mode：快写，快交，最快速度，最低质量底线完成任务。

但我后来把它拿掉了。

原因很朴素：短篇文档虽然短，但风险并不短。

如果 Quick Mode 跳过了环境检查、来源风险、模板解析和个人信息确认，那么最后得到的可能是：

  • 正文挺顺，但引用是假的；
  • PDF 编出来了，但图表位置烂了；
  • 首页看起来像成品，但还留着“作者姓名”“单位名称”；
  • 文献列表很长，但关键论断没有可靠来源。 这种“快”，其实是在把麻烦延期。

所以这个 Skill 不提供 Quick Mode。需要快修已有正文时，它单独提供了一个文字快修入口，只改措辞、衔接、压缩、去重和术语统一，不碰排版、引用、图表和模板结构。

我最在意的几个规则

这个 Skill 里有几条规则，我自己觉得比“能不能写得漂亮”还重要。

1. 不编造来源

不能编 DOI、页码、卷期、作者、期刊和 URL。

资料会被分成不同风险等级：

  • 全文级资料：可以支撑方法、比较和具体结论；
  • 摘要级资料：只能支撑高层定位；
  • 题录级资料：只能证明“有这篇东西”，不能支撑关键论断；
  • 用户材料：可以支撑项目事实，但必须可追溯；
  • 模板材料：只控制格式，不支撑技术结论；
  • 禁用资料：不能复活，不能偷用。 这套分级听起来麻烦，但能防止 AI 把“只看过标题”的文献写得像读完全文一样。

2. PDF 编译成功不等于可以提交

这是我踩坑后很认同的一点。

PDF 能编译，只能说明 LaTeX 没炸。它不能保证：

  • 表格没有溢出；
  • 图片没有被截断；
  • 页码没有乱；
  • 参考文献没有乱码；
  • 首页没有占位符；
  • 图题、表题、正文引用能对上。 所以 Skill 里专门有视觉核查阶段，要求对 PDF 截图做检查。

有些问题，日志真的看不出来，眼睛一看就知道不对。

3. 个人信息不能让 AI 猜

作者、学校、学号、课程、老师、单位、城市、邮编这些信息，不能让 Agent 自己脑补。

Skill 里有信息确认文件：缺什么就列出来，没确认就不能把最终稿标成可提交。

这个设计有点笨，但我觉得很必要。

4. 每个阶段都要留下反馈

它会鼓励每个阶段都写反馈文件：

  • 读了什么输入；
  • 生成了什么输出；
  • 有没有违反规则；
  • 还有什么没解决；
  • 是否允许进入下一阶段。 这样后续复查时，不会只剩一个“最终版.docx”或者“final_final_v3.pdf”。

电子睡睡评：人类最恐怖的文件名就是 最终版_真的最终_改完了.pdf。

一次实际项目带来的经验

这个 Skill 的设计不是纯想象出来的。

我之前用类似流程跑过一次“集群智能容错控制”的短篇中文综述项目，从文献池、文献卡片、综述矩阵、章节正文，到 LaTeX 工程化、PDF 编译、图表调整、最终信息补齐，一路走下来，暴露了不少问题。

比如：

  • 初期没有把模板要求前置，后面才发现标题和版式要调整；
  • 环境里缺 latexmk 和 xelatex，PDF 生成被卡住；
  • 有些图一开始只是占位框，看着像完成了，其实还不能交；
  • 作者和单位信息不能被占位提示词糊弄过去；
  • PDF 编译成功后，仍然要检查图表和首页。 这些经验后来被抽象进了 Skill 里。

所以它不是“我想象中的完美论文流程”，更像是“被现实教育以后整理出来的防翻车流程”。

仓库里有什么

目前仓库里大概有这些内容：

  • SKILL.md：主 Skill 入口，定义目标、模式、状态机和硬规则；
  • prompts/：不同入口的中文目标 prompt，比如完整自动流程、标准模式、严格模式、文字快修、PDF 视觉核查等；
  • checklists/：引用一致性、环境检查、图表要求、最终提交、视觉核查等检查清单；
  • templates/：LaTeX、Markdown 报告、项目结构和信息确认模板；
  • schemas/：来源登记、项目 manifest、问题列表等结构约定；
  • tools/：环境检查和占位符扫描的小脚本；
  • docs/：工作流设计、失败模式、环境配置、复盘经验和自定义指南。 它现在还算初稿，不是一个“安装即全自动无脑出论文”的东西。

更准确地说，它是一套给 Agent 用的工作规矩。

目前适配状态

目前我更建议优先用 Codex 跑这个 Skill。

仓库里的 agents/openai.yaml、prompts/ 和几个目标 prompt 都更偏 Codex 风格，也实际跑通过一次完整 Strict Mode 项目。

Claude Code / Claude Agent 方向还在适配中，SKILL.md 已经按比较通用的 skill 格式写了，但一些清单文件和工具脚本不一定会被自动加载，可能还需要手动复制 prompt 或者单独调用脚本。

多模态方面，我也更倾向于让带视觉能力的模型直接参与 PDF 截图核查。纯 OCR 或“主写 + 辅看”的组合可以凑合，但在表格、图、公式编号、页面位置这些细节上容易漏。

后面可能会继续做什么

现在仓库里已经有两个小工具：

  • env_check.py：检查 Python、Git、LaTeX、pandoc 等环境；

  • placeholder_scan.py：扫描最终稿里是否还残留 TODO、待补、作者姓名 这类占位符。 后面可能继续补：

  • PDF 渲染和 contact sheet 生成；

  • 仓库结构验证；

  • 一键打包提交包；

  • 更多引用格式模板；

  • DOCX / WPS-friendly 示例；

  • 更完整的 Claude Code 适配。 慢慢来吧。先让它在真实任务里多挨几次打，再说自己成熟了。

最后

Fast For Short Essay 的目标不是替代人的判断。

它更像是把“写短篇报告时容易忘的检查项”变成 Agent 必须走的流程：

  • 资料要登记；
  • 引用要分级；
  • 图表要规划；
  • 模板要确认；
  • PDF 要真编译；
  • 版式要看；
  • 个人信息不能猜；
  • 最终提交前要扫占位符。 如果说普通写作 Prompt 是“来，帮我写一篇”，那这个 Skill 更像是：

先别急着写，先把会翻车的地方一个一个按住。

这就是它目前的意义。

仓库地址再放一次：https://gitee.com/Smercapto/ssfe.-fast_-for_-short_-essay-skill.git

等后续再跑几个真实项目，我可能会继续把它修得更顺手一点。

评论