{
    "version": "https://jsonfeed.org/version/1",
    "title": "JohnWish就是约翰祈祷",
    "description": "",
    "home_page_url": "https://JohnWish1590.github.io",
    "feed_url": "https://JohnWish1590.github.io/feed.json",
    "user_comment": "",
    "author": {
        "name": "JohnWish1590"
    },
    "items": [
        {
            "id": "https://JohnWish1590.github.io/wei-liao-sheng-xia-05-miaowo-da-gai-hua-diao-liao-50-ge-xiao-shimouse4-kai-fa-fu-pan.html",
            "url": "https://JohnWish1590.github.io/wei-liao-sheng-xia-05-miaowo-da-gai-hua-diao-liao-50-ge-xiao-shimouse4-kai-fa-fu-pan.html",
            "title": "为了省下 0.5 秒，我大概花掉了 50 个小时：Mouse4 开发复盘",
            "summary": "0. 这种“过度工程”值得吗？ 如果用 ROI（投资回报率）来计算，Mouse4 绝对是一个失败的项目。 为了省去把鼠标移到左上角点“返回”的那 0.5 秒，或者为了省去登录微信才能截图的麻烦，我前后迭代了 55 个版本，重写了三次渲染核心，甚至为了修一个 Bug 去翻了 Windows 的底层 API 文档。 但这就是程序员（或者说极客）的宿命：我们无法忍受工具的“钝感”。 Mouse4 的诞生，不是为了做一个通用的软件，而是为了打造一个完全契合我个人生理习惯的“数字义肢”。 最早的 Mouse4 其实不叫 Mouse4，它只是一段几 KB 的 Python 脚本。 作为一个需要高频浏览财报和文件的基金经理/老师，Windows 资源管理器的交互逻辑让我抓狂：为什么“进入文件夹”是双击，而“返回上一级”却要大幅度移动鼠标去点那个该死的箭头？ 我的需求很原始： 我希望我的鼠标在哪里，哪里就是控制台。 于是，我利用 UIAutomation 做了一个简单的钩子：当且仅当鼠标停留在文件夹的空白处双击时，模拟按下 Backspace。 这个功能上线后，我几乎忘记了它的存在。这才是工具的最高境界——隐形。它变成了我肌肉记忆的一部分，以至于我在别人的电脑上操作时，总会下意识地双击空白处，然后看着毫无反应的屏幕发愣。 如果说“双击返回”是顺手，那“截图”功能的开发就是一场与 Windows 缩放机制的恶战。 作为一个多屏重度用户（左竖屏看盘，中横屏工作，右屏摸鱼），我的桌面环境简直是开发者的噩梦： 显示器 1：4K 分辨率，200% 缩放。 显示器…",
            "content_html": "<h3 data-path-to-node=\"6\">0. 这种“过度工程”值得吗？</h3>\n<p data-path-to-node=\"7\">如果用 ROI（投资回报率）来计算，Mouse4 绝对是一个失败的项目。</p>\n<p data-path-to-node=\"8\">为了省去把鼠标移到左上角点“返回”的那 0.5 秒，或者为了省去登录微信才能截图的麻烦，我前后迭代了 55 个版本，重写了三次渲染核心，甚至为了修一个 Bug 去翻了 Windows 的底层 API 文档。</p>\n<p data-path-to-node=\"9\">但这就是程序员（或者说极客）的宿命：<strong data-path-to-node=\"9\" data-index-in-node=\"18\">我们无法忍受工具的“钝感”。</strong></p>\n<p data-path-to-node=\"10\">Mouse4 的诞生，不是为了做一个通用的软件，而是为了打造一个<strong data-path-to-node=\"10\" data-index-in-node=\"32\">完全契合我个人生理习惯的“数字义肢”</strong>。</p>\n<h3 data-path-to-node=\"11\">1. 第一层：肌肉记忆的延伸</h3>\n<p data-path-to-node=\"12\">最早的 Mouse4 其实不叫 Mouse4，它只是一段几 KB 的 Python 脚本。</p>\n<p data-path-to-node=\"13\">作为一个需要高频浏览财报和文件的基金经理/老师，Windows 资源管理器的交互逻辑让我抓狂：为什么“进入文件夹”是双击，而“返回上一级”却要大幅度移动鼠标去点那个该死的箭头？</p>\n<p data-path-to-node=\"14\"><strong data-path-to-node=\"14\" data-index-in-node=\"0\">我的需求很原始：</strong> 我希望我的鼠标在哪里，哪里就是控制台。</p>\n<p data-path-to-node=\"15\">于是，我利用 <code data-path-to-node=\"15\" data-index-in-node=\"7\">UIAutomation</code> 做了一个简单的钩子：<strong data-path-to-node=\"15\" data-index-in-node=\"30\">当且仅当</strong>鼠标停留在文件夹的空白处双击时，模拟按下 <code data-path-to-node=\"15\" data-index-in-node=\"55\">Backspace</code>。</p>\n<p data-path-to-node=\"16\">这个功能上线后，我几乎忘记了它的存在。这才是工具的最高境界——<strong data-path-to-node=\"16\" data-index-in-node=\"31\">隐形</strong>。它变成了我肌肉记忆的一部分，以至于我在别人的电脑上操作时，总会下意识地双击空白处，然后看着毫无反应的屏幕发愣。</p>\n<h3 data-path-to-node=\"17\">2. 第二层：与“物理像素”的战争</h3>\n<p data-path-to-node=\"18\">如果说“双击返回”是顺手，那“截图”功能的开发就是一场<strong data-path-to-node=\"18\" data-index-in-node=\"27\">与 Windows 缩放机制的恶战</strong>。</p>\n<p data-path-to-node=\"19\">作为一个多屏重度用户（左竖屏看盘，中横屏工作，右屏摸鱼），我的桌面环境简直是开发者的噩梦：</p>\n<ul data-path-to-node=\"20\">\n<li>\n<p data-path-to-node=\"20,0,0\">显示器 1：4K 分辨率，200% 缩放。</p>\n</li>\n<li>\n<p data-path-to-node=\"20,1,0\">显示器 2：4K 分辨率，150% 缩放。</p>\n</li>\n<li>\n<p data-path-to-node=\"20,2,0\">显示器 3：1080P 分辨率，100% 缩放。</p>\n</li>\n</ul>\n<p data-path-to-node=\"21\">当我试图把截图功能加上去时，Python 的 GUI 库（PyQt）彻底晕了。 在 4K 屏上截图，画面要么被暴力拉伸成马赛克，要么截取的区域和鼠标选中的区域完全错位。最夸张的一次，我在中间屏幕画了一个圆，结果鼠标松开时，那个圆出现在了右边的屏幕上。</p>\n<p data-path-to-node=\"22\"><strong data-path-to-node=\"22\" data-index-in-node=\"0\">这背后的技术鸿沟在于：</strong> 操作系统为了照顾旧软件，会把 4K 屏“谎报”成 1080P（逻辑像素）。而截图软件需要的是“真·4K”（物理像素）。</p>\n<p data-path-to-node=\"23\"><strong data-path-to-node=\"23\" data-index-in-node=\"0\">这就导致了“坐标系打架”：</strong></p>\n<ul data-path-to-node=\"24\">\n<li>\n<p data-path-to-node=\"24,0,0\">鼠标说：“我在坐标 (500, 500)。”</p>\n</li>\n<li>\n<p data-path-to-node=\"24,1,0\">屏幕说：“好的，但在我这里，那是物理像素 (1000, 1000)。”</p>\n</li>\n<li>\n<p data-path-to-node=\"24,2,0\">截图引擎说：“啊？那我到底该切哪块图？”</p>\n</li>\n</ul>\n<p data-path-to-node=\"25\">在 V48 到 V54 的几十次崩溃中，我最终放弃了依赖框架的自动缩放。我写了一套<strong data-path-to-node=\"25\" data-index-in-node=\"41\">手动映射算法</strong>，强行接管了所有坐标计算。现在的 Mouse4，是在像素级别上“手动”把逻辑坐标对齐回了物理坐标。</p>\n<p data-path-to-node=\"26\">这种<strong data-path-to-node=\"26\" data-index-in-node=\"2\">严丝合缝</strong>的快感，只有在 200% 缩放的屏幕上拖出一个像素都不差的选区时，才能体会得到。</p>\n<h3 data-path-to-node=\"27\">3. 第三层：来自 Excel 的“幽灵”</h3>\n<p data-path-to-node=\"28\">就在我以为大功告成时，一个足以逼疯开发者的 Bug 出现了。</p>\n<p data-path-to-node=\"29\">有一天，我正在 Excel 里输入数据 <code data-path-to-node=\"29\" data-index-in-node=\"20\">712</code>，屏幕突然一黑，截图界面弹了出来。 我的快捷键是 <code data-path-to-node=\"29\" data-index-in-node=\"48\">Ctrl+1</code>。但我发誓，我当时绝对没有按 <code data-path-to-node=\"29\" data-index-in-node=\"69\">Ctrl</code>。</p>\n<p data-path-to-node=\"30\"><strong data-path-to-node=\"30\" data-index-in-node=\"0\">这简直是玄学。</strong> 难道我的键盘漏电了？</p>\n<p data-path-to-node=\"31\">经过排查，罪魁祸首竟然是**“手速太快”<strong data-path-to-node=\"31\" data-index-in-node=\"20\">。 我在输入数字前，习惯性地用了 <code data-path-to-node=\"31\" data-index-in-node=\"37\">Ctrl+C</code> 复制数据。当我快速切换窗口并敲击键盘时，Windows 的消息队列有时候会“跟不上”，导致 Python 的监听库</strong>没听到** <code data-path-to-node=\"31\" data-index-in-node=\"107\">Ctrl</code> 键弹起的那一声信号。</p>\n<p data-path-to-node=\"32\">于是，在程序的认知里，<code data-path-to-node=\"32\" data-index-in-node=\"11\">Ctrl</code> 键一直是被按住的（幽灵状态）。此时我只要按个 <code data-path-to-node=\"32\" data-index-in-node=\"39\">1</code>，程序就判定：<code data-path-to-node=\"32\" data-index-in-node=\"47\">Ctrl + 1</code> 触发！</p>\n<p data-path-to-node=\"33\"><strong data-path-to-node=\"33\" data-index-in-node=\"0\">为了杀掉这个幽灵，我被迫降维打击：</strong> 在 V55 版本中，我引入了 C++ 时代的古老兵器 —— <code data-path-to-node=\"33\" data-index-in-node=\"48\">GetAsyncKeyState</code>。 现在，每当你按下快捷键，Mouse4 不会轻易相信，而是会直接<strong data-path-to-node=\"33\" data-index-in-node=\"97\">质问操作系统底层</strong>：“现在的物理键盘上，Ctrl 键到底有没有通电？”</p>\n<p data-path-to-node=\"34\">只有物理层面的确认，才能打败逻辑层面的延迟。从此，那个幽灵消失了。</p>\n<h3 data-path-to-node=\"35\">4. 尾声：工具的温度</h3>\n<p data-path-to-node=\"36\">回顾这几十个小时的折腾，原本只是想把两个小功能缝合在一起，最后却变成了一场涉及<strong data-path-to-node=\"36\" data-index-in-node=\"39\">底层钩子、高分屏渲染算法、多线程并发</strong>的技术练兵。</p>\n<p data-path-to-node=\"37\">现在的 Mouse4，界面依然简陋，没有任何多余的动画。 但当我每天几百次地双击空白处返回，或者在 4K 屏上极其顺滑地截下一张图时，这种<strong data-path-to-node=\"37\" data-index-in-node=\"69\">完全受控、绝对精准</strong>的感觉，让我觉得这一切“无用功”都是值得的。</p>\n<p data-path-to-node=\"38\">这可能就是我们折腾工具的意义： <strong data-path-to-node=\"38\" data-index-in-node=\"16\">在这个充满不确定性的世界上，至少手中的鼠标和代码，永远忠诚于你。</strong></p>\n<hr data-path-to-node=\"39\">\n<p data-path-to-node=\"40\"><strong data-path-to-node=\"40\" data-index-in-node=\"0\">This article was updated on 一月 21, 2026</strong></p>\n<p data-path-to-node=\"41\"><strong data-path-to-node=\"41\" data-index-in-node=\"0\">Share It</strong> <strong data-path-to-node=\"41\" data-index-in-node=\"9\">JohnWish1590</strong> <strong data-path-to-node=\"41\" data-index-in-node=\"22\">Powered by Publii</strong></p>",
            "author": {
                "name": "JohnWish1590"
            },
            "tags": [
            ],
            "date_published": "2026-01-21T19:36:40+08:00",
            "date_modified": "2026-01-21T19:39:09+08:00"
        },
        {
            "id": "https://JohnWish1590.github.io/wo-ru-he-yong-ai-zai-48-xiao-shi-nei-ba-python-jiao-ben-bian-chengge-ren-peng-bo-zhong-duan.html",
            "url": "https://JohnWish1590.github.io/wo-ru-he-yong-ai-zai-48-xiao-shi-nei-ba-python-jiao-ben-bian-chengge-ren-peng-bo-zhong-duan.html",
            "title": "我如何用 AI 在 48 小时内把 Python 脚本变成“个人彭博终端”",
            "summary": "0. 背景：为什么我要折腾这个？ 作为一名同时关注港股和 A 股市场，我每天的信息焦虑很重。我需要盯着 36 氪、彭博社、英为财情等多个源头。 最开始，我只是想要一个简单的功能：有一个机器人帮我盯着这些网站，有新消息就发到我的飞书上。 我没有专业的编程背景，但我知道现在的 AI 能写代码。于是，我找了一位 AI 助手（Gemini），开始了这段为期两天的“结对编程”。 最早的版本很快就跑通了。AI 给了一段 Python 代码，放在 GitHub Actions 上跑。但是上线第一天我就受不了了——消息太碎了。 每一条新闻都会触发一次弹窗。如果彭博社一下子更新了 5 条新闻，我的手机就会震动 5 次。这完全没法用。 我向 AI 提出了第一个关键需求： “新闻还是一张卡片一张卡片的跳...能不能点一下折叠，或者聚合一下？” AI 告诉我不支持“点击交互”，但可以做“聚合发送”。它重写了代码，把 15 分钟内抓到的新闻打包塞进一张飞书卡片里。 这是优化后的效果，清爽多了： (图注：优化后的飞书卡片，同一个来源的新闻被聚合在一起，不再刷屏) 解决了推送问题，我又产生了新的想法：“能不能把它做成一个独立的 App？” 比如双击进入文件夹，或者有一个独立的界面查看历史消息。 AI 很诚实地劝退了我：开发 iOS App 需要每年交 99 美元开发者费用，还需要后端服务器。它给了一个“穷人版”的替代方案：利用&hellip;",
            "content_html": "<h3 data-path-to-node=\"6\">0. 背景：为什么我要折腾这个？</h3>\n<p data-path-to-node=\"7\">作为一名同时关注港股和 A 股市场，我每天的信息焦虑很重。我需要盯着 36 氪、彭博社、英为财情等多个源头。</p>\n<p data-path-to-node=\"8\">最开始，我只是想要一个简单的功能：<strong data-path-to-node=\"8\" data-index-in-node=\"17\">有一个机器人帮我盯着这些网站，有新消息就发到我的飞书上。</strong></p>\n<p data-path-to-node=\"9\">我没有专业的编程背景，但我知道现在的 AI 能写代码。于是，我找了一位 AI 助手（Gemini），开始了这段为期两天的“结对编程”。</p>\n<h3 data-path-to-node=\"10\">1. 第一阶段：从“消息轰炸”到“聚合卡片”</h3>\n<p data-path-to-node=\"11\">最早的版本很快就跑通了。AI 给了一段 Python 代码，放在 GitHub Actions 上跑。但是上线第一天我就受不了了——消息太碎了。</p>\n<p data-path-to-node=\"12\">每一条新闻都会触发一次弹窗。如果彭博社一下子更新了 5 条新闻，我的手机就会震动 5 次。这完全没法用。</p>\n<p data-path-to-node=\"13\"><strong data-path-to-node=\"13\" data-index-in-node=\"0\">我向 AI 提出了第一个关键需求：</strong></p>\n<blockquote data-path-to-node=\"14\">\n<p data-path-to-node=\"14,0\">“新闻还是一张卡片一张卡片的跳...能不能点一下折叠，或者聚合一下？”</p>\n</blockquote>\n<p data-path-to-node=\"15\">AI 告诉我不支持“点击交互”，但可以做“聚合发送”。它重写了代码，把 15 分钟内抓到的新闻打包塞进一张飞书卡片里。</p>\n<p data-path-to-node=\"16\"><strong data-path-to-node=\"16\" data-index-in-node=\"0\">这是优化后的效果，清爽多了：</strong></p>\n<figure class=\"post__image\"><img  src=\"https://JohnWish1590.github.io/media/posts/1/ScreenShot_2026-01-04_204330_211.png\" alt=\"\" width=\"800\" height=\"600\" sizes=\"(max-width: 1920px) 100vw, 1920px\" srcset=\"https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-xs.png 640w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-sm.png 768w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-md.png 1024w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-lg.png 1366w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-xl.png 1600w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204330_211-2xl.png 1920w\"></figure>\n<p data-path-to-node=\"17\"><i data-path-to-node=\"17\" data-index-in-node=\"0\">(图注：优化后的飞书卡片，同一个来源的新闻被聚合在一起，不再刷屏)</i></p>\n<h3 data-path-to-node=\"18\">2. 第二阶段：更大的野心与“网页时光机”</h3>\n<p data-path-to-node=\"19\">解决了推送问题，我又产生了新的想法：<strong data-path-to-node=\"19\" data-index-in-node=\"18\">“能不能把它做成一个独立的 App？”</strong> 比如双击进入文件夹，或者有一个独立的界面查看历史消息。</p>\n<p data-path-to-node=\"20\">AI 很诚实地劝退了我：开发 iOS App 需要每年交 99 美元开发者费用，还需要后端服务器。它给了一个“穷人版”的替代方案：<strong data-path-to-node=\"20\" data-index-in-node=\"65\">利用 GitHub Pages 生成一个静态网页。</strong></p>\n<p data-path-to-node=\"21\">于是，我们的架构变成了：</p>\n<ul data-path-to-node=\"22\">\n<li>\n<p data-path-to-node=\"22,0,0\"><strong data-path-to-node=\"22,0,0\" data-index-in-node=\"0\">即时消息</strong> -&gt; 飞书推送</p>\n</li>\n<li>\n<p class=\"align-left\" data-path-to-node=\"22,1,0\"><strong data-path-to-node=\"22,1,0\" data-index-in-node=\"0\">历史归档</strong> -&gt; <a href=\"https://johnwish1590.github.io/feishu-news-monitor/\">网页展示</a></p>\n</li>\n</ul>\n<figure class=\"post__image\"><img  src=\"https://JohnWish1590.github.io/media/posts/1/ScreenShot_2026-01-04_204706_232.png\" alt=\"\" width=\"800\" height=\"600\" sizes=\"(max-width: 1920px) 100vw, 1920px\" srcset=\"https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-xs.png 640w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-sm.png 768w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-md.png 1024w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-lg.png 1366w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-xl.png 1600w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_204706_232-2xl.png 1920w\"></figure>\n<h3 data-path-to-node=\"23\">3. 第三阶段：踩坑与填坑（最折磨的过程）</h3>\n<p data-path-to-node=\"24\">这个阶段是我们交互最密集的时刻，因为遇到了一系列技术问题：</p>\n<p data-path-to-node=\"25\"><strong data-path-to-node=\"25\" data-index-in-node=\"0\">问题一：网页“裸奔”与文件过大</strong> 一开始生成的 <code data-path-to-node=\"25\" data-index-in-node=\"23\">index.html</code> 非常简陋，甚至有一次因为没有任何样式（CSS），网页变成了纯文字。更严重的是，因为没有清理机制，HTML 文件很快膨胀到几千条新闻，导致 GitHub 编辑器直接打不开，报错 \"File too big\"。</p>\n<p data-path-to-node=\"26\"><strong data-path-to-node=\"26\" data-index-in-node=\"0\">解决过程：</strong> AI 引入了一个 <code data-path-to-node=\"26\" data-index-in-node=\"15\">MAX_ARCHIVE_ITEMS = 800</code> 的限制，只保留最近一周的数据。同时，为了防止样式丢失，它把 CSS 代码直接“焊死”在了 Python 脚本里，每次运行都强制重写网页头尾。</p>\n<p data-path-to-node=\"27\"><strong data-path-to-node=\"27\" data-index-in-node=\"0\">问题二：诡异的“7:50”停摆</strong> 就在我觉得一切正常时，我发现机器人突然不工作了。查看 GitHub 后台日志，发现所有的绿色对号在早上 7:50 之后就戛然而止。</p>\n<figure class=\"post__image\"><img  src=\"https://JohnWish1590.github.io/media/posts/1/ScreenShot_2026-01-04_205139_708.png\" alt=\"\" width=\"800\" height=\"600\" sizes=\"(max-width: 1920px) 100vw, 1920px\" srcset=\"https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-xs.png 640w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-sm.png 768w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-md.png 1024w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-lg.png 1366w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-xl.png 1600w ,https://JohnWish1590.github.io/media/posts/1/responsive/ScreenShot_2026-01-04_205139_708-2xl.png 1920w\"></figure>\n<p data-path-to-node=\"28\"><i data-path-to-node=\"28\" data-index-in-node=\"0\">(图注：日志显示，之前的运行间隔非常不规律，最终在 7:50 停止)</i></p>\n<p data-path-to-node=\"29\"><strong data-path-to-node=\"29\" data-index-in-node=\"0\">排查与解决：</strong> 我把日志发给 AI，经过分析发现是“免费额度”的问题。</p>\n<ul data-path-to-node=\"30\">\n<li>\n<p data-path-to-node=\"30,0,0\">我原本设置每 15 分钟运行一次。</p>\n</li>\n<li>\n<p data-path-to-node=\"30,1,0\">每次运行耗时约 2分30秒。</p>\n</li>\n<li>\n<p data-path-to-node=\"30,2,0\">一天运行 96 次 × 2.5 分钟 ≈ 240 分钟。</p>\n</li>\n<li>\n<p data-path-to-node=\"30,3,0\">GitHub 私有仓库每月免费额度只有 2000 分钟。按这个速度，<strong data-path-to-node=\"30,3,0\" data-index-in-node=\"34\">8 天就会用光一个月的额度</strong>。</p>\n</li>\n</ul>\n<p data-path-to-node=\"31\">为了解决这个问题，我们将策略调整为“省流模式”：只在早 8 点到晚 8 点运行，且频率降低为每 30 分钟一次。</p>\n<h3 data-path-to-node=\"32\">4. 第四阶段：发布 v1.0 与 Release 事故</h3>\n<p data-path-to-node=\"33\">当代码终于稳定后，我想把这个版本定格下来。AI 建议我使用 GitHub 的 Releases 功能。</p>\n<p data-path-to-node=\"34\">结果在发布时，我又卡住了。我填好了标题和内容，点击发布却一直报错：<code data-path-to-node=\"34\" data-index-in-node=\"33\">tag name can't be blank</code>。<i data-path-to-node=\"35\" data-index-in-node=\"0\"></i></p>\n<p data-path-to-node=\"36\">原来，GitHub 发版必须关联一个“标签”（Tag）。在 AI 的截图指引下，我学会了在输入框输入 <code data-path-to-node=\"36\" data-index-in-node=\"51\">v1.0.0</code> 后，必须点击那个弹出的 <strong data-path-to-node=\"36\" data-index-in-node=\"70\">\"Create new tag\"</strong> 按钮，而不是直接跳过。</p>\n<h3 data-path-to-node=\"37\">5. 最终成果</h3>\n<p data-path-to-node=\"38\">经过 48 小时的调试，这个“个人金融情报站”终于 v1.0 上线了。现在的它：</p>\n<ol start=\"1\" data-path-to-node=\"39\">\n<li>\n<p data-path-to-node=\"39,0,0\"><strong data-path-to-node=\"39,0,0\" data-index-in-node=\"0\">飞书端</strong>：每 30 分钟聚合推送，英文自动翻译成中文。</p>\n</li>\n<li>\n<p data-path-to-node=\"39,1,0\"><strong data-path-to-node=\"39,1,0\" data-index-in-node=\"0\">网页端</strong>：拥有了类似彭博终端的深色时间轴界面，手机访问也很漂亮。</p>\n</li>\n<li>\n<p data-path-to-node=\"39,2,0\"><strong data-path-to-node=\"39,2,0\" data-index-in-node=\"0\">零成本</strong>：托管在 GitHub，没有服务器开销。</p>\n</li>\n</ol>\n<p data-path-to-node=\"40\">回看整个过程，我并没有真正掌握 Python 的语法，但我学会了如何“精准地描述现象”<strong data-path-to-node=\"40\" data-index-in-node=\"45\">和</strong>“向 AI 提需求”。这或许就是 AI 时代，我们每个人都能拥有的能力。</p>",
            "author": {
                "name": "JohnWish1590"
            },
            "tags": [
            ],
            "date_published": "2026-01-04T15:14:18+08:00",
            "date_modified": "2026-01-04T21:04:10+08:00"
        }
    ]
}