<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="/feeds/rss-style.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Code4Focus</title>
        <link>https://code4focus.github.io/</link>
        <description>Code4Focus 是一个使用 Astro 与 Retypeset 构建的个人博客，记录软件工程、AI、产品思考与长期主义相关的内容。</description>
        <lastBuildDate>Thu, 09 Apr 2026 17:03:27 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>Astro-Theme-Retypeset with Feed for Node.js</generator>
        <language>zh</language>
        <copyright>Copyright © 2026 Code4Focus</copyright>
        <atom:link href="https://code4focus.github.io/rss.xml" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[小型站点先用元数据构建阅读路径，而不是急着上搜索]]></title>
            <link>https://code4focus.github.io/posts/metadata-reading-paths/</link>
            <guid isPermaLink="false">https://code4focus.github.io/posts/metadata-reading-paths/</guid>
            <pubDate>Fri, 10 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[说明为什么对一个双语小站来说，在上更重的搜索层之前，应该先把基于元数据的确定性阅读路径补起来。]]></description>
            <content:encoded><![CDATA[<p>对一个内容量还不大的站点来说，可发现性不一定要先靠搜索框解决。</p>
<p>更优先的事情，通常是把页面之间的本地连接做强。目标不是模仿推荐流，而是让已经落到文章页上的读者，更容易继续读下去。</p>
<h2>先用站点已经拥有的信号</h2>
<p>最便宜、也最容易解释的信号，通常本来就已经在内容模型里：</p>
<ul>
<li>发布时间</li>
<li>语言</li>
<li>共享标签</li>
<li>明确的系列归属</li>
</ul>
<p>这些信号构建成本低，可以在构建期完成，而且读者也更容易理解“为什么这里出现了这几个链接”。</p>
<h2>确定性阅读路径解决什么问题</h2>
<p>当内容集合还比较小、而且整体是人工整理过的时候，确定性路径其实很好用。</p>
<p>它至少能给读者三种明确的下一步：</p>
<ol>
<li>按时间继续读。</li>
<li>留在同一个系列里读。</li>
<li>打开另一篇共享局部主题信号的文章。</li>
</ol>
<p>很多时候，这已经足够提升继续阅读的概率，而不需要先引入更重的客户端搜索或索引方案。</p>
<h2>搜索什么时候再上</h2>
<p>当站点已经大到读者经常是为了“找回一篇具体旧文章”而来时，搜索的优先级才会明显上升。</p>
<p>在那之前，放置得当的元数据驱动链接，往往已经能承担大部分发现任务，而且更透明、更轻，也更容易长期维护。</p>
]]></content:encoded>
            <author>Code4Focus</author>
        </item>
        <item>
            <title><![CDATA[评论审核规则]]></title>
            <link>https://code4focus.github.io/posts/comment-moderation-policy/</link>
            <guid isPermaLink="false">https://code4focus.github.io/posts/comment-moderation-policy/</guid>
            <pubDate>Thu, 09 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Code4Focus 评论区的公开审核基线，说明什么内容欢迎、什么内容可能被自动最小化，以及误判后的处理方式。]]></description>
            <content:encoded><![CDATA[<p>目前站点评论托管在 <code>Giscus + GitHub Discussions</code> 上。</p>
<p>这样做的原因很直接：第一版先把评论落到维护成本最低、审计路径最清楚的平台侧能力上，后续如果确实需要更细的私有规则、账号体系或更强的自动过滤，再考虑迁到自建后端。</p>
<h2>欢迎的内容</h2>
<ul>
<li>针对文章内容的补充、纠错与追问</li>
<li>与主题直接相关的经验、案例与反例</li>
<li>基于事实和理由的不同意见</li>
<li>对排版、链接、引用或可读性问题的反馈</li>
</ul>
<h2>可能被处理的内容</h2>
<p>以下内容不适合保留在评论区：</p>
<ul>
<li>明显广告、导流、SEO 外链投放或批量灌水</li>
<li>钓鱼、骗取凭据、恶意下载、钱包助记词或私钥相关诱导</li>
<li>威胁、骚扰、人身攻击或故意刷屏</li>
<li>泄露他人隐私、身份信息或其他不应公开的数据</li>
<li>与文章主题无关、且只以引流或破坏讨论为目的的内容</li>
</ul>
<h2>自动处理的边界</h2>
<p>自动化只处理非常窄的一类情况：</p>
<ul>
<li>带有明显广告或诈骗特征的评论</li>
<li>带有明显恶意链接、凭据诱导或恶意软件分发特征的评论</li>
</ul>
<p>命中这类规则后，评论可能会在 GitHub 侧被自动最小化，并保留平台可见的原因，例如 <code>spam</code> 或 <code>abuse</code>。</p>
<p>除此之外，自动化不会尝试替代人工判断。边界模糊、需要上下文解释、或者只是观点尖锐但仍在讨论范围内的评论，不会因为自动规则直接被处理。</p>
<h2>如果发生误判</h2>
<p>如果你的评论被最小化，但你认为这是误判，可以：</p>
<ul>
<li>直接新开一个 GitHub issue，并附上对应 discussion 链接</li>
<li>简要说明评论原意，以及你认为被误判的原因</li>
</ul>
<p>我会优先按公开规则复核，而不是让隐藏规则替代说明。</p>
]]></content:encoded>
            <author>Code4Focus</author>
        </item>
        <item>
            <title><![CDATA[把归档做成可按时间扫描的入口]]></title>
            <link>https://code4focus.github.io/posts/archive-structure-notes/</link>
            <guid isPermaLink="false">https://code4focus.github.io/posts/archive-structure-notes/</guid>
            <pubDate>Mon, 06 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[记录为什么首页归档应该更像时间线而不是平铺列表，同时继续保持静态优先和低认知负担。]]></description>
            <content:encoded><![CDATA[<p>归档页不应该只是“证明这里有文章”。</p>
<p>对一个内容规模还不大的站点来说，读者往往会在归档页上快速判断三件事：这里是不是还在持续更新、内容有没有阶段感、以及值不值得继续点开更多文章。如果页面只是一串平铺标题，这些判断都会变得更费力。</p>
<h2>为什么时间结构要更明确</h2>
<p>博客天然拥有的强信号里，时间几乎是最稳定的一个。</p>
<p>按年份分组、再把节点做得更可扫描之后，归档页能更快回答这些问题：</p>
<ul>
<li>站点是持续更新，还是已经停掉了？</li>
<li>内容是在某些阶段集中出现，还是零散发布？</li>
<li>哪个时间段最值得先点进去？</li>
</ul>
<p>这比“单纯倒序列表”更像一个真正的发现入口。</p>
<h2>归档页应该帮助读者完成什么</h2>
<p>时间线式归档，至少应该让三件事变得便宜：</p>
<ol>
<li>快速看最近在写什么。</li>
<li>按时间段回到某个阶段。</li>
<li>看出几篇文章是否属于同一轮建设或思考过程。</li>
</ol>
<p>对双语站点来说，这一点更重要，因为读者会自然判断不同语言下的归档是不是同样完整、是否能形成连续阅读路径。</p>
<h2>暂时不需要做什么</h2>
<p>这一阶段的归档页不需要直接变成搜索引擎。</p>
<p>只要它能把时间结构讲清楚，保持静态优先，并为后续文章页的上一篇、下一篇和相关文章提供更强的上下文，目标就已经成立。</p>
]]></content:encoded>
            <author>Code4Focus</author>
        </item>
        <item>
            <title><![CDATA[用 Astro 与 Retypeset 搭起新的写作起点]]></title>
            <link>https://code4focus.github.io/posts/hello-world/</link>
            <guid isPermaLink="false">https://code4focus.github.io/posts/hello-world/</guid>
            <pubDate>Sat, 04 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[这是博客的第一篇文章，用来确认新的站点结构、排版风格与内容方向。]]></description>
            <content:encoded><![CDATA[<p>新的博客已经搭起来了。</p>
<p>我选择 <code>Astro + Retypeset</code> 作为第一版基础设施，原因很直接。</p>
<p>作为对照，普通静态引用会尽量保持安静 <sup><a href="#cite-astro-docs">[1]</a></sup>。启用预览的引用则可以在桌面端就地补足上下文 <sup><a href="#cite-retypeset-demo">[2]</a></sup>。</p>
<h2>为什么是这套组合</h2>
<ol>
<li>它天然适合静态部署，放到 <code>GitHub Pages</code> 成本低、维护轻。</li>
<li>SEO 基础能力完整，包含 <code>sitemap</code>、<code>Open Graph</code>、<code>RSS</code> 和结构化元信息能力。</li>
<li>它对中文内容的阅读体验更认真，不只是“能显示中文”，而是更接近“认真排版过”的感觉。</li>
</ol>
<h2>这个站会写什么</h2>
<ul>
<li>软件工程与前端开发</li>
<li>AI 工具链与工作流</li>
<li>产品思考与长期项目</li>
<li>阅读、写作与知识整理</li>
</ul>
<h2>下一步</h2>
<p>接下来我会继续补齐这些内容：</p>
<ul>
<li>GitHub Pages 正式部署</li>
<li>Search Console / Bing Webmaster 验证</li>
<li>评论系统与统计方案</li>
<li>更细致的中文字体与排版优化</li>
</ul>
<p>如果你正在读这篇文章，说明这个博客已经从想法进入了运行状态。</p>

<hr />
<ol>
<li><a name="cite-astro-docs"></a><p><a href="https://astro.build">Astro 官方文档</a> 明确把 Astro 定位为适合内容型、静态优先网站的框架，这和这个博客当前的部署方式与维护目标是一致的。</p></li><li><a name="cite-retypeset-demo"></a><p><a href="https://retypeset.radishzz.cc/">Retypeset 演示站</a> 所呈现的字距、留白和长文阅读体验，是我判断这套主题适合写作场景的重要依据。</p></li>
</ol>
]]></content:encoded>
            <author>Code4Focus</author>
        </item>
    </channel>
</rss>