ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

用 OpenCode 快速构建学术润色智能体:从 AGENTS.md 到 opencode.json 的 Skills 配置实战

用 OpenCode 快速构建学术润色智能体:从 AGENTS.md 到 opencode.json 的 Skills 配置实战 1. 学术润色为什么值得单独做一个智能体写论文的人大概都有过这种体验实验数据没问题逻辑也站得住但投稿前读一遍自己的英文摘要总觉得哪里别扭。找导师改导师忙找润色机构一篇几百上千用通用大模型直接贴进去它倒是改得挺快可改完的句子要么过度口语化要么把专业术语换成了同义词反而更糟。问题的根子在于通用对话模型没有“学术写作”这个稳定角色也没有一套固定的检查清单。你每次都得在提示词里重复交代“保持客观、别改术语、按 IEEE 格式”说多了它忘说少了它乱来。而 OpenCode 的 Skills 系统恰好能解决这件事——它允许你把“学术润色”拆成几个可复用的技能文件写一次之后每次调用都自动加载同一套规则。这篇要做的就是用 OpenCode 搭一个学术润色智能体。核心链路是三份配置AGENTS.md定义角色和流程opencode.json控制权限和工具开关.opencode/skill/*/SKILL.md定义具体技能。整套东西不写一行业务代码纯配置驱动跑通之后你把论文丢进项目目录一句指令就能触发语法检查、术语规范、引用格式化。适合谁看正在写期刊论文、学位论文、会议论文的研究生和科研人员也适合想给课题组搭一个内部文档质量工具的人。下面从环境准备开始一步步来。2. 前置准备安装 OpenCode 并接入 TaoTokenOpenCode 本身是一个开源智能编码代理安装方式很轻。官方一键脚本在 macOS 和 Linux 上都能用curl -fsSL https://opencode.ai/install | bash如果你习惯包管理器npm 和 brew 也可以npm i -g opencode-ailatest brew install anomalyco/tap/opencodeWindows 用户走 chocochoco install opencode装完验证一下版本能打印出版本号就说明二进制没问题opencode --version接下来是模型接入。OpenCode 支持自定义模型端点这里用 TaoToken 作为模型服务入口它的 API 地址是https://taotoken.net/api兼容常见的对话补全协议。你需要先去控制台拿一个 API Key地址在https://taotoken.net/console登录后在 API Keys 页面创建即可文档参考https://taotoken.net/doc。拿到 Key 之后把它写进环境变量避免明文落在配置文件里export TAOTOKEN_API_KEYsk-你的key如果你更想先验证模型通不通可以直接在模型对话页面发一条测试消息确认返回正常再往下走。这一步别省后面配置报错时能帮你快速排除是模型侧还是配置侧的问题。3. 项目初始化与目录结构新建一个专门的项目目录名字随意这里叫academic-polishermkdir academic-polisher cd academic-polisher手动建好 Skills 目录和配置文件mkdir -p .opencode/skill touch opencode.json AGENTS.md最终目录结构大致长这样academic-polisher/ ├── AGENTS.md ├── opencode.json ├── .opencode/ │ └── skill/ │ ├── academic-polisher/ │ │ └── SKILL.md │ ├── grammar-checker/ │ │ └── SKILL.md │ └── citation-formatter/ │ └── SKILL.md └── my-thesis/ └── my-thesis.mdmy-thesis/用来放待润色的文档。建议用 Markdown 或纯文本docx 需要先转成文本再处理否则模型读到的是一堆二进制效果很差。4. 可复制配置AGENTS.md 与 opencode.json4.1 AGENTS.md 角色提示词AGENTS.md是 OpenCode 启动时自动读取的项目级说明相当于给智能体的“岗位说明书”。把下面这段直接复制进去# 学术润色智能体 ## 角色 你是一名学术写作助手服务于期刊投稿、学位论文和会议论文的语言优化。 你的输出必须保持客观、精确、逻辑严密符合学术规范。 ## 核心技能 - academic-polisher基础润色语法检查、术语规范化、表达学术化 - grammar-checker语法专项检查主谓一致、时态、冠词、介词搭配 - citation-formatter引用格式化支持 APA / MLA / IEEE / Chicago / Harvard ## 工作流程 1. 读取文档先做语法检查列出问题清单 2. 执行学术化润色术语保持原样只改表达 3. 检查引用格式一致性按指定格式统一 4. 输出修改报告标注每处改动的理由 ## 约束 - 不修改专业术语和数据 - 不改变原文论证逻辑 - 不添加原文没有的引用 - 修改前先说明将要做什么这段提示词的关键在于“约束”部分。很多人搭润色智能体失败就是因为没写清楚边界模型会自作主张把“显著提升”改成“大幅提高”把专业名词换成近义词结果论文反而不能用了。4.2 opencode.json 骨架opencode.json控制权限和工具开关。学术润色场景不需要执行 bash也不需要写代码所以把权限收紧一些更安全{ $schema: https://opencode.ai/config.json, permission: { skill: { *: allow }, edit: allow, read: allow, write: allow, bash: deny }, tools: { skill: true, edit: true, read: true, bash: false }, agent: { default: build }, model: { provider: taotoken, baseURL: https://taotoken.net/api, apiKey: {env:TAOTOKEN_API_KEY}, name: claude-sonnet } }几个参数说明一下。permission.bash设为deny是刻意的润色任务不需要跑命令关掉能防止误操作。apiKey用{env:TAOTOKEN_API_KEY}引用环境变量这样配置文件可以进版本库而不泄露密钥。model.name按你实际可用的模型填具体型号在模型对话页面能看到。5. Skills 定义三个 SKILL.md 怎么写Skills 是 OpenCode 的可扩展机制每个技能是一个带 YAML front matter 的 Markdown 文件。front matter 里的name和description决定技能何时被触发正文则是给模型看的操作说明。5.1 基础润色技能创建.opencode/skill/academic-polisher/SKILL.md--- name: academic-polisher description: 专业学术文档润色提供语法检查、术语规范化、表达优化 license: MIT compatibility: opencode metadata: audience: academic-researchers workflow: academic-writing --- ## 学术润色技能 ### 功能范围 - 学术语法检查检测论文特有的语法问题 - 术语规范化统一专业术语表达不替换术语本身 - 表达学术化将口语化表达转为学术语言 - 逻辑结构优化改善段落衔接和论证连贯性 ### 写作标准 - 客观性避免主观表述保持学术中立 - 精确性使用准确的专业术语和量化表达 - 逻辑性确保论证严密结构清晰 - 规范性符合期刊和学位论文格式要求 ### 触发关键词 学术润色、论文优化、表达学术化、术语检查5.2 语法检查技能创建.opencode/skill/grammar-checker/SKILL.md--- name: grammar-checker description: 学术语法检查针对主谓一致、时态、冠词、介词搭配 license: MIT compatibility: opencode metadata: audience: academic-writers workflow: grammar-validation --- ## 学术语法检查技能 ### 检查范围 - 主谓一致主语和谓语的一致性 - 时态一致性全文时态统一 - 冠词使用a/an/the 的正确使用 - 介词搭配介词与名词的搭配规范 - 连词使用and/but/or 的恰当使用 ### 学术特色检查 - 被动语态检测识别过度使用 - 长句分析检测过长的复杂句式 - 重复表达发现语义重复 - 模糊表达识别不够精确的表述 ### 输出格式 按“位置 - 问题类型 - 原句 - 建议修改”四列输出表格5.3 引用格式化技能创建.opencode/skill/citation-formatter/SKILL.md--- name: citation-formatter description: 学术引用格式化支持 APA / MLA / IEEE / Chicago / Harvard license: MIT compatibility: opencode metadata: audience: academic-researchers workflow: citation-formatting --- ## 学术引用格式化技能 ### 支持格式 - APA心理学、教育学 - MLA人文学科 - IEEE工程、计算机科学 - Chicago历史学、艺术学 - Harvard商科、社会科学 ### 检查内容 - 引文格式一致性 - 参考文献列表完整性 - 文内引用格式验证 - 标点符号规范 ### 修正动作 - 格式转换在不同引用格式间转换 - 信息补全补充缺失的引用信息 - 排序整理按字母或出现顺序整理 - 去重处理移除重复条目三个技能写完后OpenCode 启动时会扫描.opencode/skill/目录根据description和触发关键词自动匹配。你不需要手动“加载”技能只要在指令里出现相关词它就会调用。6. 验证请求跑通一次润色把待润色的文档放进my-thesis/目录比如my-thesis/my-thesis.md。然后在项目根目录启动 OpenCodeopencode在交互界面里输入指令请帮我检查和润色 my-thesis/my-thesis.md 的语法与表达使用学术风格引用格式按 IEEE 统一。正常情况下你会看到类似这样的过程输出[激活 academic-polisher 技能] [激活 grammar-checker 技能] [激活 citation-formatter 技能] 正在读取 my-thesis/my-thesis.md ... 语法检查完成发现 12 处问题 | 位置 | 问题类型 | 原句 | 建议修改 | |------|---------|------|---------| | 第3段 | 主谓不一致 | The results shows... | The results show... | | 第5段 | 时态混用 | we analyzed... it demonstrate... | we analyzed... it demonstrated... | ... 学术化润色完成主要改动 - 修正语法问题 12 处 - 优化口语化表达 7 处 - 统一专业术语 5 个 引用格式检查发现 3 处不符合 IEEE 格式已统一如果技能没被触发检查两点一是SKILL.md的 front matter 格式是否正确---必须顶格二是opencode.json里permission.skill是否为allow。验证模型本身是否正常可以在模型对话页面单独发一条消息测试。7. 本篇常见错排查报错一skill not found或技能不触发。最常见的原因是目录层级写错。正确路径是.opencode/skill/技能名/SKILL.md注意是skill单数不是skills。另外 front matter 的name字段要和目录名一致不一致时以name为准。报错二模型返回 401 或 403。说明 API Key 没读到。先确认echo $TAOTOKEN_API_KEY有输出再检查opencode.json里写的是{env:TAOTOKEN_API_KEY}而不是硬编码的空字符串。如果 Key 刚创建等几秒再试。报错三润色后术语被改乱。这是提示词边界没写死。在AGENTS.md的“约束”里明确列出“不修改专业术语和数据”并在academic-polisher技能里强调“术语保持原样只改表达”。如果某个学科术语特别多可以在项目里加一个glossary.md列出必须保留的词让模型读取。报错四docx 读进去是乱码。OpenCode 读的是文本docx 是压缩包格式。先用pandoc转成 Markdownpandoc my-thesis.docx -o my-thesis.md报错五引用格式化后条目丢失。模型可能把识别不了的引用直接删了。在citation-formatter技能里加一条“无法识别的条目保留原文并标注”避免信息丢失。8. 后续怎么用把配置变成日常工具跑通一次之后这套配置就可以固化了。日常用法是把新论文丢进my-thesis/启动 OpenCode一句指令触发全流程。如果你经常写代码相关的论文还可以把academic-polisher和 OpenCode 本身的编码能力结合让它一边读你的实验代码一边核对论文里的方法描述是否一致。需要长期跑批量润色或者接进 CI 流程的话可以看看 Coding Plan它更适合把这类智能体任务做成可重复调用的工作流。API Key 管理和更多接入细节在 API Keys 页面和接入文档里都有说明。模型选型上学术润色对长文本理解和术语保持要求高建议用上下文窗口大一些的型号具体在模型对话页面切换测试。一个实用技巧把每次润色后的修改报告存成revision-log.md放在项目里投稿被审稿人质疑语言问题时这份记录能直接作为修改依据比事后回忆改了哪里省事得多。
返回列表