【应用分享】News In Simple：我用 Gemini 重构了英语新闻阅读- Community

[App Sharing] 【应用分享】News In Simple：我用 Gemini 重构了英语新闻阅读

Apps Section 508 views · 6 replies ·

Nico

deepin

18 hours ago

Author

写在前面：英语阅读的“死锁”与“重构”

作为一名开发者，我相信很多人跟我有一样的困惑：我们可以熟练地阅读 Stack Overflow、GitHub Issues 甚至是晦涩的 API 文档（Technical English），但一旦试图阅读 The Verge、Bloomberg 或者 New York Times（Real World English）时，却往往坚持不过三分钟。

为什么？因为技术文档的语法结构是线性的、逻辑是收敛的，且词汇高度重通过复。而真实世界的新闻充满了长难句、文化隐喻、俚语和低频词。

直接啃原版新闻，难度相当于刚学完 Python 基础语法，就让你去读 Linux 内核源码——这是认知过载（Cognitive Overload）。

所以，作为一名写了多年代码的开发者，我认为我们这个群体在英语学习上存在一个有趣的“死锁（Deadlock）”现象：

输入端：我们可以毫无压力地阅读 Stack Overflow、RFC 文档甚至 Linux 内核注释。这是因为技术文档的语法结构是线性的，逻辑是收敛****的，词汇是高度复用的。
阻塞点：一旦切换到 The Economist、New York Times 或 YouTube 的真实新闻语料（Real World English），我们的解析器（大脑）立刻抛出异常。长难句嵌套、文化隐喻、低频词汇，让阅读体验变成了痛苦的“Debug”过程。
结果：收藏夹里躺满了“待读外刊”，但永远停留在 TODO 状态。

我意识到，这本质上不是我们“算法（智商）”的问题，而是数据源****（语料）的难度与我们的处理能力不匹配。

根据克拉申的“i+1 可理解性输入”理论，最有效的学习不是去硬啃“屎山代码”（i+10），而是阅读那些经过重构的、逻辑清晰的源码（i+1）。

既然 LLM（大模型）具备了极强的 NLP 能力，我决定自己开发一个工具，对真实世界的英语新闻进行 Refactoring（重构）。这就是 News In Simple 的诞生逻辑。

产品链接：https://newsinsimple.com/

(独立开发，目前全免费，纯粹为了解决我和身边朋友的痛点)

一、产品哲学：把新闻当成“Legacy Code”来处理

News In Simple 的核心理念不是“翻译”，而是“降维”。

如果把一篇高难度的英文新闻比作一段复杂的“屎山代码”，我的工作就是利用 LLM（大模型）对它进行 Refactoring（重构）：保持核心逻辑（新闻事实）不变，但是简化语法结构，降低耦合度（长难句拆分），替换复杂的依赖库（生僻词）。

1. 分级重构（Graded Refactoring）

对于一篇复杂的原版新闻，我将其视为一段充满了 goto 语句和复杂依赖的 Legacy Code。我的系统通过 Gemini 模型，将其重构为三个版本：

Level 1 (Beginner) - 伪代码层：
- 设计哲学：Decoupling（解耦）。
- 实现细节：强制打断所有超过 15 个单词的长句；去除被动语态；将隐喻转化为直白陈述。这就像是把复杂的嵌套函数拆解成了平铺直叙的脚本，让初学者只关注“核心逻辑”（新闻事实）。
Level 2 (Intermediate) - 标准库层：
- 设计哲学：Best Practice（最佳实践）。
- 实现细节：引入定语从句和常用搭配（Collocations）。这是大部分开发者应该停留的舒适区，既能获取信息，又能积累语感。
Level 3 (Advanced) - 源码层：
- 设计哲学：Production Ready。
- 实现细节：保留原汁原味的高级表达和修辞，供高阶用户挑战。

2. 语境感知（Context Awareness） vs 静态查词

传统的划词翻译 API，就像是查阅静态的 man 手册。

但在新闻中，单词的含义是动态绑定（Dynamic Binding）的。

Run a company (管理)
Run for president (竞选)
Run a test (执行)

在 News In Simple 中，我利用 LLM 的 Context Window，提取的 Key Vocabulary 不仅仅是单词本身，而是包含了该单词在当前新闻上下文中的具体实例化对象。这就像 IDE 里的“跳转到定义”，直接把你带到了具体的实现逻辑中，而不是泛泛的文档。

二、技术深潜：Prompt Engineering 的那些坑

作为一个基于 Next.js + Vercel + Gemini 的 AI Wrapper 产品，核心壁垒其实在于 Prompt 的调试。

在开发过程中，我遇到了几个典型的技术挑战：

1. 如何让 AI 稳定输出“分级内容”？

最开始，我简单地告诉 AI：“请把这篇文章改成简单版本”。结果非常不稳定：有时改得太短，有时改得像儿歌，有时甚至幻觉出了新闻里没有的细节。

为了解决这个问题，我经过了数十次迭代，总结了一些经验：

Role Play（角色设定）：不仅要设定为“英语老师”，更要设定为“资深的新闻编辑”。
Constraints（约束条件）：不能只说“简单”，要量化。
- 例如针对 Level 1，我在 Prompt 中明确限制了：Sentence length must be under 15 words, Avoid passive voice, Use vocabulary from the CEFR A2 list.
Fact Consistency（事实一致性）：为了防止 LLM “胡编乱造”，我在 Prompt 中加入了强约束：Strictly adhere to the factual information provided in the source text. Do not hallucinate or add personal opinions.

2. 难度梯度的量化 (Quantifying Difficulty)

什么是“简单”？AI 不理解“简单”。

解决方案：将语言学标准转化为 Prompt 指令。

Level 1 对应 CEFR A2 标准（基础词汇表）。
Level 2 对应 CEFR B2 标准。
通过限制 sentence_length 和 vocabulary_complexity 来物理控制输出难度。

3. 结构化输出 (JSON Mode)

为了让前端能优雅地渲染单词卡片和 Quiz，我强制模型输出严格的 JSON 格式。这里踩了很多坑，最终通过 Few-Shot Learning（给模型几个完美的 JSON 示例）解决了格式不稳定的问题。

4.词汇提取的“语境感知”

传统的查词 API 只是机械地返回字典释义。但在新闻中，同一个词 Run 在 "Run a company" 和 "Run for president" 中意思完全不同。

在 News In Simple 中，我利用 LLM 的 Context Window（上下文窗口），要求它“In-Context Learning”。生成的 Key Vocabulary 列表，不仅仅是单词，还包含了该单词在当前新闻语境下的具体含义。这就像是 IDE 里的 Go to Definition，直接跳到了具体的实现，而不是泛泛的文档。

三、未来规划：重构“查字典”的体验 (Roadmap)

目前的 News In Simple 只是完成了“阅读流”的闭环（MVP）。接下来，我真正想做的是颠覆“背单词”这个枯燥的流程。

我正在开发的 Word Insight 模块，基于我对记忆原理的理解，试图解决一个问题：为什么我们背了单词书记不住，但看美剧学的词忘不掉？

答案是：情绪价值（Emotion） 和 情境记忆（Episodic Memory）。

未来的 Word Insight 将包含：

AI 梗图生成器：
不再展示枯燥的例图。查 "Procrastination"（拖延症），AI 会生成一个骷髅坐在电脑前写 "To Do List" 的梗图。幽默感是记忆的最强粘合剂。
Story Generator (微小说生成)：
这是一种“生成式 UI”。当你查了 5 个生词，AI 会为你动态生成一个包含这 5 个词的微型悬疑故事或科幻小品。你不再是死记硬背，而是在阅读故事的过程中，观察这些单词如何作为“角色”在剧本中互动。
Core Lexicon AI：
基于 Longman 3000 和 GSL 词频表，对新闻进行数据可视化标注。让大家把有限的精力（CPU Time），优先分配给那些出现频率最高的“高权重单词”。