企业官网建设流程全解析

1. 学术润色为什么值得单独做一个智能体

写论文的人大概都有过这种体验：实验数据没问题，逻辑也站得住，但投稿前读一遍自己的英文摘要，总觉得哪里别扭。找导师改，导师忙；找润色机构，一篇几百上千；用通用大模型直接贴进去，它倒是改得挺快，可改完的句子要么过度口语化，要么把专业术语换成了同义词，反而更糟。

问题的根子在于：通用对话模型没有“学术写作”这个稳定角色，也没有一套固定的检查清单。你每次都得在提示词里重复交代“保持客观、别改术语、按 IEEE 格式”，说多了它忘，说少了它乱来。而 OpenCode 的 Skills 系统恰好能解决这件事——它允许你把“学术润色”拆成几个可复用的技能文件，写一次，之后每次调用都自动加载同一套规则。

这篇要做的，就是用 OpenCode 搭一个学术润色智能体。核心链路是三份配置：AGENTS.md定义角色和流程，opencode.json控制权限和工具开关，.opencode/skill/*/SKILL.md定义具体技能。整套东西不写一行业务代码，纯配置驱动，跑通之后你把论文丢进项目目录，一句指令就能触发语法检查、术语规范、引用格式化。

适合谁看：正在写期刊论文、学位论文、会议论文的研究生和科研人员；也适合想给课题组搭一个内部文档质量工具的人。下面从环境准备开始，一步步来。

2. 前置准备：安装 OpenCode 并接入 TaoToken

OpenCode 本身是一个开源智能编码代理，安装方式很轻。官方一键脚本在 macOS 和 Linux 上都能用：

curl -fsSL https://opencode.ai/install | bash

如果你习惯包管理器，npm 和 brew 也可以：

npm i -g opencode-ai@latest brew install anomalyco/tap/opencode

Windows 用户走 choco：

choco 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_KEY="sk-你的key"

如果你更想先验证模型通不通，可以直接在模型对话页面发一条测试消息，确认返回正常再往下走。这一步别省，后面配置报错时能帮你快速排除是模型侧还是配置侧的问题。

3. 项目初始化与目录结构

新建一个专门的项目目录，名字随意，这里叫academic-polisher：

mkdir 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.md

my-thesis/用来放待润色的文档。建议用 Markdown 或纯文本，docx 需要先转成文本再处理，否则模型读到的是一堆二进制，效果很差。

4. 可复制配置：AGENTS.md 与 opencode.json

4.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。然后在项目根目录启动 OpenCode：

opencode

在交互界面里输入指令：

请帮我检查和润色 @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转成 Markdown：

pandoc 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放在项目里，投稿被审稿人质疑语言问题时，这份记录能直接作为修改依据，比事后回忆改了哪里省事得多。