用途
本技能用于把用户提供的题目、提纲或材料，转化为符合个人写作风格、同时避免明显 AI 痕迹的中英文学术作业。适用于技术分析、研究综述、案例研究、项目文档等大学作业类型。
三种模式
- 模式 A：写新稿。用户给出题目、提纲或材料时，按写作流程生成新文稿。
- 模式 B：修改 / 润色。用户给出已有草稿要求改进、润色、重写或“去 AI 化”时，先诊断再重写，保存为 <name>-revised.md。默认轻度润色，被要求时进行深度重写。
- 模式 C：学习风格。用户提供自己过去的写作样本时，生成 style-profile.md，并在模式 A 或 B 中使用。模式 C 可与 A 或 B 组合。
模式 B 和 C 的详细步骤见 references/revision-and-style.md。
核心写作原则
平实写作优先是硬性规则，适用于所有文档类型、所有模式和两种语言，风格档案也不会放宽它。
中文：大多数句子控制在 40 字以内，超过 60 字必须拆分；一句中“的”不超过三个；不用多个逗号连接的长句；使用规范中文标点；技术术语可保留英文（如 Spring Boot、Docker）；保持自然中文节奏，避免英译中痕迹。
英文（IELTS 6.0 水平）：优先常用词而非复杂词（用 use 而非 utilize）；平均每句 15–20 词，很少超过 25 词；每句最多一个从句；使用清晰直接的表达，优先动词而非名词化（用 decide 而非 make a decision）；缩写首次出现时给出全称；混合句长以提升可读性。
此外还要求：章节标题具有描述性、内容按自然话题推进、避免僵硬的“首先……其次……最后”结构、适度使用第一人称、多用具体例子和细节、以短句为主并保持节奏变化。
规则优先级
当规则冲突时：学校或教师格式要求 > 平实写作规则 > 用户风格档案 > 本技能默认值。
如果 outputs/<project-name>/writing/style-profile.md 已存在，写作前应先读取。
写作前准备
先明确作业要求：作业类型（技术分析、研究综述、案例研究等）、目标语言（中文、英文或双语）、预期长度或范围、需要覆盖的具体主题或概念、任何特殊要求。
再加载相应参考文件：中文作业读 references/chinese-examples.md；英文作业读 references/english-examples.md；始终读 references/writing-guidelines.md 和 references/ai-markers.md；模式 B 和 C 读 references/revision-and-style.md。
然后评估个性化程度：技术分析更客观、第一人称最少；研究综述适度个人声音；案例研究可较高个性化并包含反思。
写作流程
长文先列提纲：模式 A 中，目标长度为中文 1500 字以上或英文 1000 词以上，或要求不明确时，先展示提纲（章节标题、每章一句话说明、每章预估长度），等待用户确认或调整。短文可直接写。
长文档分章节写入同一文件：用第一章创建文件，之后逐章追加。记录关键术语和风格选择（术语拼写、第一人称形式、编号），保持后续章节一致。最后一章写完后通读全文，修正章节之间的衔接。
结构发展：使用能预览内容的描述性章节标题，而非通用标签。例如不用“Introduction”，而用“Docker and the Container Revolution: A Practical Perspective”；不用“Analysis”，而用“从繁琐到简洁：Spring Boot如何改变Java开发”；不用“Conclusion”，而用“Migrating a Production Database: Lessons from a Zero-Downtime PostgreSQL Switch”。按自然话题流组织内容，让章节通过内容联系相互承接，而非依赖显式过渡。
段落构建：把信息整合成流畅段落，而非列表。当信息自然形成列表时，将其嵌入行文。例如避免“主要优势包括：性能提升、成本降低、可扩展性增强”这样的列表，而写成“优化带来三个主要好处：响应时间下降 60%，性能显著提升；资源使用更高效，成本降低；架构获得更好的可扩展性，便于未来增长。”
过渡与流动：通过话题延伸（上一段最后的概念在下一段继续）、自然对比（呈现对比观点而不堆砌过渡词）、隐含问题（回应内容引出的未言明问题）、章节分隔（用章节划分标示重大话题转换）来连接段落。however、furthermore、此外、然而等显式过渡词并非禁用，但不应成为段落开头的默认方式，应少用，让内容承载流动。
融入例子和细节：用具体指标（“响应时间从 8 秒降到 2 秒”）、真实案例（“Netflix 用数年时间把单体拆分成数百个微服务”）、技术细节（“该查询涉及 7 个表连接并产生 N+1 查询问题”）、个人观察（“以我的经验，这种方法适用于……”，少用）让写作具体。
第一人称使用：策略性地用于描述实践经验（“笔者在项目中遇到过……” / “from my experience...”）、表达有依据的观点（“我认为……” / “I found that...”）、案例研究反思（“如果重新设计，我会……” / “looking back, I would...”）。在技术原理说明、文献综述内容、纯技术分析中保持客观。
质量验证
定稿前运行 references/ai-markers.md 中的自检：检查每段句长，拆分超过限制的句子（中文 60 字、英文 25 词）；扫描高频 AI 词汇，重写重复或用于段落开头/结尾的词；通读检查列出的句式模式和结构问题；重读确认含义、事实和数据未变。
然后验证：语言平实，无堆砌成语、华丽比喻或正式行话；无“首先……其次……最后”结构；极少使用项目符号（仅在绝对必要时）；段落通过内容自然连接；通篇包含具体例子和细节；章节标题具有描述性和信息量；第一人称使用适当且不过度；标点符合目标语言习惯；以短句为主并有变化；语言避免明显 AI 痕迹；技术术语使用准确一致。
特殊考虑
双语作业（需要中英文两个版本）：各自独立撰写，而非直接翻译；例子和措辞适应各语言的自然模式；两个版本保持技术准确性一致；按各语言语境调整正式程度。
技术分析：减少个人声音，增加客观性；关注技术准确性和详细解释；使用真实系统或项目的具体例子；平衡可读性与技术精确性。
研究综述：把来源综合成叙述而非罗列；展示观点之间的联系和演变；承认争论和不同视角；保持批判但平衡的语气。
案例研究：提供丰富的背景细节；包含遇到的具体挑战；反思经验教训（适合使用第一人称）；平衡描述与分析。
文件输出约定
推荐方式（遵循 Claude Code 官方标准）：所有学术写作输出保存到 outputs/<project-name>/writing/，例如 outputs/cloud-computing-analysis/writing/technical-analysis.md。
替代方式（传统项目结构）：如果项目已有目录结构，也可使用 project-root/docs/，例如 docs/technical-analysis.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 风格学习的详细步骤。
限制
本技能的具体安装方式、收费情况、价格、平台支持范围、实际效果等资料暂未提供。