academic-writing-style

学术写作风格

将提供的信息转化为写得出色的学术作业，贴合用户自然的写作风格，避免明显的 AI 痕迹，同时保持专业水准。

核心方法

优先使用朴素的语言（硬性规则）。 无论作业类型如何，都应使用浅白的语言，避免冗长复杂的句子。这适用于每种文档类型、每种模式和两种语言。风格档案不能放宽这一要求。中文：大多数句子不超过 40 个字符，超过 60 个字符的句子必须拆分。英文：平均每句 15–20 个单词，尽量不超过 25 个单词，每句最多包含一个从句。避免堆砌成语、华丽的比喻和宏大的开篇。完整标准见 references/writing-guidelines.md（原则 1）。

除此之外，生成的内容应自然流畅，并具备以下特点：

• 使用描述性标题，清晰组织章节
• 自然推进主题，避免刻板的“首先……其次……最后”结构
• 根据作业类型适度使用第一人称视角
• 使用具体示例和细节，而非泛泛而谈
• 以短句为主，适当调整节奏
• 根据目标语言（中文或英文）使用恰当的标点

选择模式

首先根据用户的请求确定模式：

模式	适用情况	操作
A. 撰写新内容	用户提供主题、大纲或材料	按照以下写作流程操作
B. 修订／润色	用户提供现有草稿，要求改进、润色、重写或“去 AI 化”	诊断 → 重写 → 保存为 <name>-revised.md。默认轻度润色；用户要求时进行深度重写
C. 学习风格	用户提供自己过去的写作样本	创建 style-profile.md，然后用于模式 A 或 B

模式 B 和 C 有详细步骤，见 references/revision-and-style.md。适用模式 C 时，可同时采用模式 A 或 B。

规则冲突时的优先级： 学校或教师的格式要求 > 朴素写作规则 > 用户的风格档案 > 此技能的默认设置。

如果 outputs/<project-name>/writing/style-profile.md 已存在，应在写作前阅读。

写作前

1. 明确作业要求：

   • 作业类型（技术分析、研究综述、案例研究等）
   • 目标语言（中文、英文或两者）
   • 预期长度或范围
   • 要涵盖的具体主题或概念
   • 任何特殊要求

2. 加载适用的参考资料：

   • 对于中文作业：阅读 references/chinese-examples.md
   • 对于英文作业：阅读 references/english-examples.md
   • 始终阅读 references/writing-guidelines.md，了解核心原则
   • 始终阅读 references/ai-markers.md，查看 AI 痕迹清单
   • 对于模式 B 和 C：阅读 references/revision-and-style.md

3. 评估个性化程度：

   • 技术分析：更加客观，尽量少用第一人称
   • 研究综述：适度体现个人风格
   • 案例研究：适合加入更多个人表达和反思

写作流程

长篇内容先列大纲

在模式 A 中，如果目标长度达到 1500 个中文字符或 1000 个英文单词，或要求不明确，应先展示大纲：

• 章节标题
• 用一句话说明每章的内容
• 每章的预计篇幅

等待用户确认或调整。短篇内容可以直接撰写。

分章节撰写长篇文档

对于长篇文档，每次撰写一章并写入同一个文件：先创建文件并写入第一章，再依次追加后续章节。简要记录关键术语和风格选择（术语拼写、第一人称形式、编号方式），确保后续章节保持一致。最后一章完成后，通读整篇文档，并调整章节之间的衔接。

结构开发

使用能预告内容的描述性章节标题，而非泛泛的标签：

• 不要写“引言”，改为“Docker 与容器革命：实践视角”
• 不要写“分析”，改为“从繁琐到简洁：Spring Boot 如何改变 Java 开发”
• 不要写“结论”，改为“迁移生产数据库：PostgreSQL 实现零停机切换的经验”

按照自然的主题脉络组织内容，让各章节通过内容关联逐步展开，而非使用明确的过渡语句。

段落构建

将信息融入连贯的段落，而不是列成清单。当信息自然构成清单时，将其融入行文：

避免： 主要优势包括：

• 提升性能
• 降低成本
• 增强可扩展性

建议： 这项优化带来了三大主要益处：响应时间缩短了 60%，性能显著提升；资源利用效率更高，成本随之降低；架构的可扩展性也得到增强，为未来发展做好了准备。

过渡与行文流畅度

通过以下方式衔接段落：

• **主题延伸：**上一段的最后一个概念在下一段继续展开
• **自然对比：**呈现对照观点，不依赖生硬的过渡词
• **隐含问题：**回应内容引发但未明说的问题
• **章节划分：**通过章节区分标示主题的重大转变

“然而”“此外”“不过”等明确的过渡词并非禁用，但不应总用它们来开启段落。少用这类词，让内容自然衔接。

融入示例与细节

通过以下内容让行文更加具体：

• 具体指标：“响应时间从 8 秒降至 2 秒”
• 真实案例：“Netflix 在数年间将其单体架构拆分为数百个微服务”
• 技术细节：“该查询涉及 7 张表的连接，并产生了 N+1 查询问题”
• 个人观察：“以我的经验来看，这种方法适用于……”（少用）

语言调整

中文写作：

• 大多数句子控制在 40 个字符以内；超过 60 个字符的句子应拆分
• 每句话中“的”不超过 3 个；避免用多个逗号串联冗长句子
• 使用规范的中文标点：，。：""
• 适当保留英文技术术语，如“Spring Boot”“Docker”
• 保持中文表达自然流畅
• 避免生硬的英译中句式

英语写作（雅思 6.0 水平）：

• 优先使用常见词汇，而非复杂词汇：用 “use” 代替 “utilize”
• 平均每句 15–20 个词；尽量不超过 25 个词
• 每句话至多使用一个从句
• 使用清晰、直接的表达；优先使用动词，而非名词化表达（用 “decide”，而非 “make a decision”）
• 首次出现缩写时给出全称：“Object-Relational Mapping (ORM)”
• 交替使用不同长度的句子，让阅读更加轻松

第一人称的使用

有策略地使用第一人称：

• 描述实践经验：“笔者在项目中遇到过……” / “from my experience...”
• 表达有依据的观点：“我认为……” / “I found that...”
• 反思案例：“如果重新设计，我会……” / “looking back, I would...”

以下内容应保持客观：

• 技术原理说明
• 文献综述内容
• 纯技术分析

质量核验

定稿前，请按照 references/ai-markers.md 进行自检：

1. 句子长度： 检查每个段落，并拆分超出限制的句子（中文 60 个字符，英文 25 个单词）
2. 高频 AI 用词： 搜索列出的词语；如果重复出现，或出现在段落开头或结尾，请改写
3. 句式和结构： 检查列出的句式模式和结构问题
4. 重读： 确认含义、事实和数据均未改变

然后核验以下内容：

• 语言通俗易懂；避免堆砌成语、华丽的比喻或正式术语
• 不使用“首先……其次……最后……”的结构
• 尽量少用项目符号（仅在确有必要时使用）
• 段落通过内容自然衔接
• 全文包含具体示例和细节
• 章节标题描述清晰、信息明确
• 第一人称使用恰当，不过度使用
• 标点符号符合目标语言习惯
• 句子大多简短，并有所变化
• 避免明显的 AI 写作痕迹
• 技术术语准确且前后一致

特别注意事项

双语任务（需要提供中文和英文版本）：

• 分别独立撰写各语言版本，不要直接翻译
• 根据每种语言的自然表达习惯调整示例和措辞
• 确保技术准确性在两个版本中保持一致
• 根据不同语言的语境调整正式程度

技术分析：

• 减少个人表达，增强客观性
• 注重技术准确性和详细解释
• 使用真实系统或项目中的具体示例
• 兼顾易读性与技术精确性

研究综述：

• 将来源综合成连贯叙述，而不是逐条罗列
• 说明观点之间的联系和发展脉络
• 承认争议和不同观点
• 保持批判性，同时做到客观平衡

案例研究：

• 提供丰富的背景细节
• 说明遇到的具体挑战
• 在适当的位置总结经验教训（可使用第一人称）
• 平衡描述与分析

文件输出规范

输出目录规范

推荐方式（遵循 Claude Code 官方标准）：

将所有学术写作输出保存到 outputs/<project-name>/writing/：

outputs/
└── <project-name>/              # Project name (e.g., cloud-computing-analysis)
    └── writing/
        ├── technical-analysis.md    # Technical analysis report
        ├── research-review.md       # Research review document
        ├── case-study.md            # Case study report
        └── project-documentation.md # Project documentation

示例：

outputs/
├── cloud-computing-analysis/
│   └── writing/
│       └── technical-analysis.md
├── ai-ethics-research/
│   └── writing/
│       └── research-review.md
└── database-optimization-case/
    └── writing/
        └── case-study.md

替代方式（传统项目结构）：

如果项目已有目录结构，也可以使用：

project-root/
└── docs/
    ├── technical-analysis.md
    ├── research-review.md
    └── case-study.md

输出文件列表

根据任务类型生成文档：

技术分析：

• technical-analysis.md - 技术分析报告

研究综述：

• research-review.md - 研究综述文档

案例研究：

• case-study.md - 案例研究报告

项目文档：

• project-documentation.md - 项目文档

修订（模式 B）：

• <original-name>-revised.md - 修订稿，与原文保存在同一目录下（粘贴的文本则保存到 outputs/<project-name>/writing/），并附上简短的修改摘要

风格学习（模式 C）：

• style-profile.md - 保存在 outputs/<project-name>/writing/ 中的可复用风格档案

文件命名规范

• 使用 kebab-case：cloud-computing-technical-analysis.md
• 必要时注明版本或日期：research-review-v1.0.md
• 使用描述性名称：database-optimization-case-study.md
• 双语文档注明语言：technical-analysis-en.md、technical-analysis-zh.md

交付摘要

生成文档后，提供简短摘要：

• 使用的模式（新建／修订／匹配风格）
• 文档类型和目标语言
• 字数和章节结构
• 涵盖的主要主题
• 所采用的写作风格特点
• 确认文件保存位置

参考资料

详细示例和指南请参阅：

• references/chinese-examples.md - 全面的中文写作示例
• references/english-examples.md - 全面的英文写作示例
• references/writing-guidelines.md - 核心写作原则和技巧（优先遵循简明写作标准）
• references/ai-markers.md - AI 标记检查清单，包含替换建议和自检步骤
• references/revision-and-style.md - 修订（模式 B）和风格学习（模式 C）的详细步骤