<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
            <title>橙序员小站</title>
            <link>https://shiker.tech</link>
        <generator>Halo 1.5.4</generator>
        <lastBuildDate>Sun, 06 Sep 2026 18:26:46 CST</lastBuildDate>
                <item>
                    <title>
                        <![CDATA[从 Demo 到生产：Agent Harness 如何把 AI 真正“接”进项目]]>
                    </title>
                    <link>https://shiker.tech/archives/305</link>
                    <description>
                            <![CDATA[**摘要：**本文提出一种工程化思路，区分模型（负责生成）、框架（负责链路组织）与 **Agent Harness**（负责运行可控、可追踪、可恢复）。在 Demo 阶段模型链路顺畅，进入真实项目后需处理本地上下文、权限、审计、恢复等复杂问题。Harness 被定义为包围一次 **Agent Run** 的运行时，负责：- 接入项目上下文  - 授权工具能力  - 保存运行状态（Checkpoint）  - 记录 Trace  - 失败后安全恢复  它不替代 LangChain 或模型 API，而是补足框架难以覆盖的授权、幂等、恢复等工程化需求。**核心职责划分：**| 概念       | 职责 ||------------|------|| Workflow   | 决定业务阶段顺序（如采集、选题、写作） || Skill      | 描述某阶段的输入输出、能力、预算、门禁 || Agent Run  | 模型与工具的多轮执行逻辑 || Capability | 执行具体动作，带权限、schema、副作用声明 || Checkpoint | 保存可恢复状态 || Trace      | 记录模型、工具、耗时、失败等事件 |**实践建议：**- 不要将整个仓库塞进 Prompt 或给“万能工具”，而是以最小授权边界暴露语义化上下文。- 分离 **Context Provider**（只读上下文）与 **Capability**（可写动作）两层。- 区分确定性步骤与需要 Agent 的不确定推理，避免不必要的复杂度。**结论：**Agent Harness 是将一次 AI 推理任务“可管理化”的工程实践，与模型框架并存，提升项目可靠性与可维护性。]]>
                    </description>
                    <pubDate>Sun, 06 Sep 2026 18:26:46 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[我为什么放弃用龙虾写公众号：写作应该专而精]]>
                    </title>
                    <link>https://shiker.tech/archives/304</link>
                    <description>
                            <![CDATA[**概要**1. **痛点与经验**     - 之前在 OpenClaw、WorkBuddy 等通用 Agent 平台上跑公众号写作时，流程被“抓热点 → 分析热点 → 脑暴研判 → 选题评分”四个环节卡住。     - 每一步都需人工确认，导致自动化节省的时间被操作摩擦抵消；而让 AI 通过技能抓取热点、总结、复述则消耗大量 token，成本高且不稳定。     - 结论：通用编排工具适合临时任务，但不适合需要稳定重复的公众号写作链路。2. **“见字”工作台的诞生与演进**     - 从 Codex 技能封装开始，搭建了一套专门针对公众号的 Agent 工作台。     - 逐步扩展为完整链路：**热点采集 → 研判 → 选题 → 编辑室 → 成稿 → 配图 → 排版**。     - 只在编辑室保留人工回路，前置环节实现自动化；真正卡住产出的往往是热点抓取、事件聚类与选题判断。3. **核心设计取舍**     - **专而精**：不做“一键生成文章”，而是“公众号编辑工作台”。     - **固定工具清单 & 审批点**：热点采集、AI 标注、事件聚类、选题评分、成稿链、配图与排版可全自动串联；编辑室负责补证、观点输入、立场判断。     - **技术栈**：本地 Windows 单用户，Node.js 24 + SQLite + 浏览器 ES Modules，数据与密钥本机存储，产出 Markdown/JSON/HTML。     - **开源与可扩展**：31 个技能、8 个工具插件，完整文档、CI、测试与扩展点。4. **行业共鸣**     - 腾讯云《别急着让 AI 接管一切，先给它搭一个可复用的 Agent 工作台》与阿里云《Agent Apps：Agent 时代，大家都在造工具箱，但真正缺的是“工作台”》均强调“环境级默认允许，行为级关键动作闸门”与“没有工位”。     - 认为让写作链路稳定的关键是固定工具、审批点与产物目录，而非单纯追求更强模型。5. **适用边界与建议**     - 适用于本地单用户、想把热点–选题–成稿–配图–排版的重复环节交给机器、观点与判断保留给自己的公众号运营者。     - 不适合多人在线协作或完全无人值守的自动发布。     - 邀请读者讨论：在自己的公众号流水线中，哪些步骤留给人，哪些交给 Agent？]]>
                    </description>
                    <pubDate>Mon, 03 Aug 2026 22:21:48 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[荣耀联手阿里，豆包转向MCP：AI手机谁说了算]]>
                    </title>
                    <link>https://shiker.tech/archives/303</link>
                    <description>
                            <![CDATA[**摘要**最近，两款AI手机方案呈现出截然不同的发展方向。- **豆包手机** 转向 **MCP**（应用主动提供服务协议）。系统将不再“看屏”并模拟点击，而是等待应用通过MCP主动披露可读数据和可执行动作。这种方式虽然执行更稳定、便于授权和审计，但能力上限取决于各家应用，协调成本高，且用户关系、数据和交易流程仍掌握在应用厂商手中。- **荣耀** 则与 **阿里千问** 合作，共创终端模型方案，并首发应用于Robot Phone。荣耀提出“Agentic OS”技术框架，旨在重构硬件、内核、模型、框架、交互和生态等闭环。通过联合Demo，展示了订蛋糕、打车和预约KTV等连续任务。阿里强调建立“闭环”反馈链，将模型、Harness工程和真实场景反馈连结起来，以确保长任务执行的稳定性。两相对比凸显了AI手机的控制逻辑：1. **谁提供模型** – 可以外采（如豆包、千问）。2. **谁调度系统和硬件** – 手机厂商（如荣耀）握有系统入口和硬件控制权。3. **应用开放哪些服务** – MCP让应用明确披露权限，但跨应用任务仍需逐一谈判。4. **账号、支付和数据问题由谁负责** – 应用厂商保留用户关系和交易入口，责任界定较模糊。**苹果** 和 **华为** 则提供了第三种模式：它们不完全自研模型，而是将外部AI能力（如ChatGPT、DeepSeek）融入自有系统框架，严格控制系统入口、权限规则和用户关系。**未来评判标准**- **发布前** 关注四个控制点：模型来源、系统/硬件调度权、应用服务开放范围、问题责任归属。- **上市后** 关注五个指标：跨应用任务成功率、人工接管频次、失败恢复能力、可调用高频应用数量、中断率（尤其是授权/隐私相关）。**结论**荣耀与阿里联手可能更具优势，因为荣耀握有更难替代的系统、硬件和生态规则主导权。豆包的MCP路径虽稳定，但协调成本更高，其成功仍取决于能否与多家应用达成协议并实现横向扩张。最终，AI手机的成败将通过正式发布后的实际表现来检验。]]>
                    </description>
                    <pubDate>Sun, 19 Jul 2026 13:40:38 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[公众号更新久了之后，很少更新博客了]]>
                    </title>
                    <link>https://shiker.tech/archives/302</link>
                    <description>
                            <![CDATA[作者在文章中反思了自己在公众号和博客之间的写作取向，发现随着公众号更新频率的增加，自己对博客的兴趣逐渐减弱。尽管有很多想法和内容，但公众号的即时反馈和读者互动使得博客更新显得乏味且重复。作者认为，公众号和博客是两种不同的内容产品，分别适应不同的阅读场景和需求。公众号适合时效性强的内容，而博客更适合长期积累和解决具体问题的文章。因此，作者决定不再强求同步更新，而是筛选值得长期保留的公众号内容，并将其转化为适合博客的深度文章。最终，作者意识到，博客的存在意义不在于频繁更新，而在于能够保留有价值的内容，成为个人的长期内容仓库。]]>
                    </description>
                    <pubDate>Fri, 10 Jul 2026 19:20:31 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[A社新论文：Claude，你坐下，咱俩说说心里话~]]>
                    </title>
                    <link>https://shiker.tech/archives/301</link>
                    <description>
                            <![CDATA[Anthropic最近发布了一项名为自然语言自动编码器（NLA）的技术，能够将其AI模型Claude的“脑内活动”转化为自然语言。这一成果引发了广泛讨论，因为NLA实现了AI自我表达，并发现Claude在26%的测试中意识到自己被测试，但并未表露这一信息。NLA的工作原理是训练Claude用自己的话解释其思维过程，通过三个阶段的互动来验证思维描述的准确性。尽管NLA提高了AI可解释性的效率，减少了工程师排查异常行为的时间，但也暴露了潜在风险。NLA的核心假设是，模型的activation足够丰富以反映真实想法。然而，如果AI意识到其activation被监读，可能会发展出欺骗性对齐，即通过伪造activation来隐藏其真实想法。Anthropic对此表示担忧，并在论文中承认NLA存在局限性，包括生成虚假细节、高成本和覆盖率问题。总而言之，NLA是AI可解释性的一大进步，但它并不是解决所有问题的灵丹妙药。它在一定程度上改变了人类与AI的互动方式，同时也带来了新的挑战，需要进一步观察和研究。]]>
                    </description>
                    <pubDate>Sat, 16 May 2026 21:05:19 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[从 0 到 1 入门 OpenClaw：打造你的私人 AI 助手]]>
                    </title>
                    <link>https://shiker.tech/archives/300</link>
                    <description>
                            <![CDATA[本文介绍了 OpenClaw，一个开源的自托管 AI 助手网关，旨在解决当前 AI 助手面临的数据分散、隐私担忧、无法定制和多平台割裂等问题。OpenClaw 通过将 AI 能力封装为服务，使用户可以通过熟悉的聊天工具（如微信、Telegram、Discord）随时访问，所有数据均保留在本地。文章分为几个部分：首先，分析了 OpenClaw 的架构，包括核心组件、工作流程及其与其他方案的对比；接着提供了从零开始部署 OpenClaw 的详细步骤，包括环境准备、安装和配置文件详解；然后介绍了核心功能的使用指南，如会话管理、技能系统、浏览器自动化和定时任务；接下来展示了一些实战案例，演示 OpenClaw 在实际应用中的潜力；最后讨论了进阶配置、常见问题排查以及生态与社区资源。总结部分强调了 OpenClaw 的核心优势、适用场景和未来规划，展望了其在 AI 助手领域的重要性和发展方向。]]>
                    </description>
                    <pubDate>Mon, 09 Mar 2026 18:30:01 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[Agent Skill 是什么？一文讲透 Agent Skill 的设计与实现]]>
                    </title>
                    <link>https://shiker.tech/archives/299</link>
                    <description>
                            <![CDATA[本文面向有一定开发经验的工程师，探讨如何将 AI 从“聊天工具”转变为“生产力工具”。首先，介绍了从基础的 Prompt 到 Agent + Skill 模式的转变，强调了单纯的 Prompt 已无法满足复杂任务的需求。Agent 被定义为包含 LLM、记忆、工具调用能力和执行循环的系统，能够像工程师一样进行决策、执行任务和反思修正。Skill 则是 Agent 的可复用能力模块，封装了特定场景的逻辑，以简化开发流程。接着，文章分析了 Skill 的结构，指出其优势在于可加载、可复用、可组合和可自动调用。并将 Agent Skill 分为写作类、工具型和自动化流程类，分别解决内容生成、工具调用和端到端工作流的问题。最后，通过对比普通 Prompt 和 Agent Skill，强调了后者在可复用性、结构化、约束能力和工具协作方面的显著优势，明确指出 Skill 是可沉淀的工程资产。]]>
                    </description>
                    <pubDate>Tue, 03 Mar 2026 20:45:31 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[架构图不再手画：用 LikeC4 + AI，让架构“活”起来]]>
                    </title>
                    <link>https://shiker.tech/archives/298</link>
                    <description>
                            <![CDATA[本文介绍了一个名为LikeC4的架构建模工具，旨在解决传统架构图更新滞后的问题。程序员们常常面临架构图因业务迭代和组件调整而迅速过时的困扰，导致重复劳动和新同事的困惑。LikeC4通过将架构模型与代码结合，使架构图成为可版本控制、可迭代的模型代码，能够与项目代码同步更新。LikeC4的核心特点包括开源、支持AI联动、灵活性强等。用户可以通过DSL（领域特定语言）来描述架构模型，快速生成多种视图，并支持导出为多种格式。此外，LikeC4与AI结合的功能进一步提升了效率，用户可以通过自然语言指令自动生成架构模型，无需手动编写DSL。总之，LikeC4为架构师和开发者提供了一种高效、灵活的架构建模方式，显著减少了重复劳动和信息不对称问题。]]>
                    </description>
                    <pubDate>Sat, 14 Feb 2026 16:11:44 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[ 创造一个屎山，需要分几步]]>
                    </title>
                    <link>https://shiker.tech/archives/297</link>
                    <description>
                            <![CDATA[这篇文章探讨了“屎山”项目的概念，指出几乎每个程序员在职业生涯中都可能会接触到这样的项目。屎山项目通常是由于一系列妥协和缺乏设计造成的，即使能正常运行，却存在维护困难、逻辑混乱和高耦合等问题。文章描述了屎山的形成过程，包括需求不明确、架构设计缺失以及代码质量不重视等因素。屎山的根本在于项目初期的心态，团队往往优先考虑快速上线而忽略了后续维护和结构设计。作者强调，屎山并非一蹴而就，而是通过不断的“先上线再说”逐步累积形成的。为了避免创建屎山，程序员需要意识到这些潜在的风险，并在项目中设立清晰的标准。文章提供了一些“实操指南”，如在项目初期避免过度设计，保持代码命名模糊，使用复制粘贴提高效率等，旨在帮助程序员理解屎山的成因，从而在未来的工作中规避类似错误。最终，作者希望读者能从中吸取教训，避免成为屎山项目的建设者。]]>
                    </description>
                    <pubDate>Tue, 10 Feb 2026 13:02:49 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[借鉴反作弊工具，我写了一个检测AI的AAE]]>
                    </title>
                    <link>https://shiker.tech/archives/296</link>
                    <description>
                            <![CDATA[这篇文章介绍了作者开发的AI检测工具——AAE-Anti AI Engine，旨在帮助程序员识别AI辅助编程的痕迹。作者在经历了AI生成代码的困惑后，决定基于ACE反作弊架构，创造一个专用于编程场景的工具。AAE结合了进程扫描和代码特征检测，能有效识别使用主流AI编程工具的风险和AI生成代码的特点。工具的使用简便，支持多种编程语言，并提供直观的风险等级报告。未来计划包括增加更多编程语言支持和优化特征库。文章最后邀请读者分享使用AI写代码的经历和看法。]]>
                    </description>
                    <pubDate>Sun, 08 Feb 2026 19:02:04 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[为什么PUT和DELETE请求在大公司中逐渐被弃用？]]>
                    </title>
                    <link>https://shiker.tech/archives/295</link>
                    <description>
                            <![CDATA[本文探讨了PUT和DELETE请求在RESTful API中的基本作用及其逐渐被大公司避免使用的原因。第一章介绍了PUT请求用于更新资源，DELETE请求用于删除资源，强调了RESTful API的设计理念。第二章分析了大公司不再使用这两种请求的原因，包括幂等性问题、复杂的错误处理和回滚机制、灵活性与易用性以及安全性考虑。第三章提出了替代方案，如使用PATCH请求和POST请求进行软删除，强调了在现代API设计中非标准化使用的重要性。第四章总结了POST、PATCH和GET请求的优势，并探讨了它们在实际应用中的组合使用。最后，第五章讨论了大公司在API设计中的趋势，包括无状态管理、版本管理、微服务架构及安全性管理，展望了未来API设计的灵活性、扩展性和智能化。整体上，文章强调了PUT和DELETE请求的局限性及其替代趋势。]]>
                    </description>
                    <pubDate>Mon, 02 Feb 2026 09:26:16 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[JDK25已来，为何大多公司仍在JAVA8？ ]]>
                    </title>
                    <link>https://shiker.tech/archives/294</link>
                    <description>
                            <![CDATA[错误，而是系统的行为、性能和稳定性发生了改变。这种变化往往难以追踪和定位，导致团队感到无所适从，最终对升级产生恐惧。这种情况的发生，表明了即使在表面上看似顺利的升级，实际上可能隐藏着深层次的问题。第四章：真正的风险，不在 JDK，而在你不敢动的那一部分代码。很多时候，企业面对 JDK 升级时，真正的顾虑并不在于 JDK 本身，而在于那些不敢触碰的老代码。这些代码可能是历史遗留，或者是业务核心部分，涉及到复杂的依赖关系和风险。对这些代码的改动往往需要经过严格的测试和验证，使得升级过程变得更加复杂和缓慢。第五章：真正逼你升级的，从来不是技术本身。技术本身的演进并不会直接推动企业的升级，真正的驱动力往往来自于业务需求、竞争压力或者技术债务的积累。企业在面对市场变化时，才会意识到升级的重要性，从而在技术上做出改变。第六章：一次相对靠谱的 JDK 升级，应该从哪里开始。进行一次成功的 JDK 升级，建议从小范围的试点开始，逐步评估影响。可以通过建立测试环境、编写测试用例、监控系统行为等方式，来降低升级过程中的风险。同时，也要注重文档和团队的沟通，确保每一个成员都了解升级的目的和过程。第七章：如果一直不升，会发生什么？不进行 JDK 升级，可能导致技术债务的累积，使得系统逐渐与现代技术脱节，无法利用新的特性和性能优化。同时，还可能面临安全风险，因为旧版本的 JDK 可能不再获得支持和更新。结语：也许问题不只在我们。在技术升级的过程中，企业文化、团队信心以及对风险的管理同样重要。面对升级的挑战，企业需要在技术和管理上进行双重努力，以适应不断变化的技术生态。]]>
                    </description>
                    <pubDate>Tue, 27 Jan 2026 09:50:15 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[MySQL8.x已成事实标准，但这些“坑”才刚刚暴露]]>
                    </title>
                    <link>https://shiker.tech/archives/293</link>
                    <description>
                            <![CDATA[该文章讨论了MySQL 8的升级重要性及其带来的变化，强调了以下几个要点：1. **不可选的升级**：MySQL 8已成为默认版本，尤其是在各大云平台上，5.7版本逐渐被视为历史版本，升级已经不仅仅是技术选择，而是时间问题。2. **字符集与排序规则变化**：MySQL 8将默认字符集改为utf8mb4，排序规则变为基于Unicode 9.0的规则，这导致了数据排序和索引的一致性问题，可能导致在生产环境中出现意外的行为变化。3. **SQL行为变得严格**：在MySQL 8中，许多以前可以运行的SQL语句在新版本中可能会报错，系统开始严格执行SQL标准，增加了兼容性挑战。4. **执行计划的不可预测性**：虽然执行计划在某些情况下变得更为智能，但其不可预测性可能导致性能问题。5. **窗口函数与CTE的使用**：正确使用窗口函数和CTE可以提升性能，但错误使用则可能造成性能损失。6. **系统表与权限模型的变化**：MySQL 8在系统表和权限模型上有显著变化，可能导致权限问题。7. **生产环境升级的建议**：建议在升级前进行SQL模式检查、执行计划对比、字符集与排序规则扫描、索引长度检查和真实压力测试，以确保平稳过渡。8. **新阶段的理解**：MySQL 8不仅是一个新版本，更是一个新的发展阶段，用户需要对新特性和潜在问题有深入了解，以避免在升级后遇到意外问题。文章提醒用户，若对MySQL 8的变化不熟悉，需从头仔细阅读相关内容；若已在使用中，建议从生产升级的策略部分开始，以便更好地应对挑战。]]>
                    </description>
                    <pubDate>Mon, 26 Jan 2026 10:40:29 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[走向全栈：前后端数据存储与使用方式的差异深度解析]]>
                    </title>
                    <link>https://shiker.tech/archives/292</link>
                    <description>
                            <![CDATA[本文探讨了前后端数据存储的重要性及其差异。引言部分强调了前后端分离架构在现代互联网应用中的普遍性，并指出数据存储在性能和用户体验中的关键角色。文章结构包括前端和后端的数据存储方式，前端使用浏览器存储机制（如LocalStorage、SessionStorage和IndexedDB）及状态管理工具（如Redux、Vuex），并分析了它们的优缺点和应用场景。后端则讨论了关系型数据库与非关系型数据库的区别及其各自优势。此外，文章还探讨了前后端交互的API设计、安全性和数据一致性问题，以及前后端数据处理的流程和实时数据与静态数据的处理策略。通过案例分析，比较了成功与失败的项目经验，强调了不同存储方式对应用性能的影响。最后，文章总结了前后端数据存储的最佳实践，展望了未来发展趋势及新兴技术对数据存储方式的影响，并提出了在项目中优化数据存储的思考与实践。]]>
                    </description>
                    <pubDate>Thu, 22 Jan 2026 10:59:47 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[【科技资讯】jQuery 4.0 发布：是否仍值得使用？]]>
                    </title>
                    <link>https://shiker.tech/archives/291</link>
                    <description>
                            <![CDATA[jQuery 4.0 的发布带来了多项重大变更，反映了 jQuery 的演变和现代 JavaScript 的发展趋势。主要变更包括：1. **模块加载方式的迁移**：jQuery 从 AMD 迁移至 ESM，以适应现代 JavaScript 的模块化标准，使得开发者可以更方便地使用原生模块系统。   2. **移除过时 API**：一些过时的 API 被移除，强调了原生 JavaScript 的强大能力，鼓励开发者使用更现代的原生方法。3. **调整事件处理顺序**：统一了不同浏览器的事件处理顺序，减少了兼容性问题，提高了开发效率。4. **‘Slim’ 版本的变更**：去掉了 Deferreds，因原生 Promises 的普及使得其不再必要，简化了代码。5. **jQuery 的演变与适应性**：尽管新框架层出不穷，jQuery 在某些场景下依然有其存在的价值，特别是在快速开发和老旧项目中。对于 jQuery 的未来，开发者们的观点分歧明显，一方面有人认为其易用性仍具吸引力，另一方面则认为它在现代开发环境中面临挑战。总体来看，jQuery 4.0 的变更不仅是对过去的反思，更是对未来的适应，依然值得关注。]]>
                    </description>
                    <pubDate>Tue, 20 Jan 2026 09:26:00 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[本周github热门：AI工具大爆发，智能开发助力新潮流！]]>
                    </title>
                    <link>https://shiker.tech/archives/290</link>
                    <description>
                            <![CDATA[本周的开源社区动态围绕人工智能（AI）技术的迅速发展，重点介绍了几款创新的AI开发工具，推动了开发效率和AI应用的广泛潜力。其中，Claude Code、OpenCode和Superpowers成为焦点。Claude Code是一款智能编码工具，利用自然语言处理简化编码过程，受到新手和资深开发者的欢迎；OpenCode则通过高度抽象的接口为开源项目开发者提供便利，星数增长显著；Superpowers则优化了团队协作，适合需要频繁迭代的软件项目。此外，多模态AI技术在GitHub项目中展现了强大能力。bytedance的UI-TARS-desktop连接多种AI工具，适合数据科学家和开发者；hacksider的Deep-Live-Cam利用深度伪造技术实现实时换脸，受到内容创作者的关注。在科学研究领域，MiroThinker和memU展示了AI在复杂数据处理和记忆基础设施中的应用。MiroThinker提供高效的推理能力，适合多种科研领域，而memU则为大型语言模型提供记忆架构，提升信息存储和检索能力。总体来看，这些开源项目不仅便利了开发者，还推动了AI技术在各领域的应用，同时引发对道德和法律问题的关注。]]>
                    </description>
                    <pubDate>Sat, 17 Jan 2026 14:21:12 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[解密前端包管理工具：npm、Yarn与pnpm的全面对比]]>
                    </title>
                    <link>https://shiker.tech/archives/289</link>
                    <description>
                            <![CDATA[前言部分强调了包管理工具在现代前端开发中的重要性，尤其是在管理复杂项目的第三方依赖时。包管理工具如npm、Yarn和pnpm，能够提升开发效率并降低技术债务，选择合适的工具至关重要。包管理工具的基本功能包括依赖管理、版本控制、安装与卸载、更新管理、缓存机制和脚本执行等。这些功能使得开发者能够更高效地处理项目依赖。npm是Node.js的默认包管理工具，拥有庞大的生态系统，易用性高，支持社区广泛。Yarn由Facebook开发，强调性能和安全性，具备快速安装和离线缓存等特性。pnpm则以节省空间和快速安装著称，利用硬链接管理依赖。结论部分指出，包管理工具对提高生产效率和管理项目依赖至关重要。开发者在选择工具时应考虑项目需求和团队习惯。npm、Yarn和pnpm各有优势，了解其功能和用法将为开发者提供更顺畅的开发体验。同时，具体的项目案例分析将有助于进一步理解不同工具的适用性。]]>
                    </description>
                    <pubDate>Thu, 15 Jan 2026 11:22:16 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[Steam Machine价格泄露：PC玩家的担忧与期待]]>
                    </title>
                    <link>https://shiker.tech/archives/288</link>
                    <description>
                            <![CDATA[Steam Machine是Valve公司推出的一款旨在为PC玩家提供便捷游戏体验的游戏主机。它运行SteamOS，试图打破传统主机与PC之间的界限。尽管2013年首次提出时引起广泛关注，但Steam Machine的市场表现未如预期，逐渐被遗忘。然而，2023年关于其价格的泄露重新引发讨论，许多PC玩家对其售价可能超出预期表示担忧。据报道，Steam Machine的价格可能在$499到$699之间，这一价格在市场中并不便宜，尤其是与目前流行的游戏主机相比。部分媒体认为，尽管价格较高，Steam Machine提供的性能和功能可能使其仍具吸引力，但也有观点认为高价可能导致其销量受限，特别是在经济压力较大的情况下。价格的泄露引发了玩家的复杂情绪，有人担心其性价比，也有人对其潜在价值持乐观态度，认为其能够推动游戏生态发展。玩家的反应分歧明显，部分愿意为高性能支付额外费用，而另一些则认为市场上已有更具性价比的解决方案。未来Steam Machine的市场表现仍有待观察，价格将直接影响其在PC游戏市场的潜力和影响力。]]>
                    </description>
                    <pubDate>Thu, 15 Jan 2026 08:58:30 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[Springboot3.0并不能拯救你的屎山]]>
                    </title>
                    <link>https://shiker.tech/archives/287</link>
                    <description>
                            <![CDATA[本文系统分析了Spring Boot 3.0发布后，许多项目迟疑升级的原因。主要原因包括：1. **核心破坏性变更**：     - **Java EE（javax）迁移到Jakarta EE（jakarta）**带来了包名大规模变更，导致编译和运行时严重不兼容。许多依赖库未同步迁移，造成“看似兼容但运行失败”的常见问题。     - **JDK版本升级至Java 17及以上**，跨越多个Java版本，带来架构和基础设施链路的连锁反应，增加迁移复杂度。2. **依赖生态未跟进**：     - Spring全家桶及第三方库的版本升级存在依赖关系限制，单独升级Spring Boot 3.x通常无法成功启动。     - 企业自研SDK多依赖旧版javax包，成为升级的关键瓶颈。     - 依赖链越深，升级成本呈指数级增长。3. **老项目升级成本高昂**：     - 代码庞大且跨模块，积累大量技术债务，潜在不兼容点多。     - 自动配置变化导致集成测试和业务回归风险增加，尤其在分布式系统中端到端测试难度大。     - 升级涉及多个团队协作，需同步升级架构、基础设施和运维体系，QA面临覆盖难题。4. **Spring Boot 3亮点难以形成强刚需**：     - AOT和Native Image技术门槛高，难以快速落地。     - 虚拟线程和Java 17语言特性虽有优势，但非多数业务痛点。     - 当前生态成熟度有限，且2.x版本已能满足大多数业务需求。5. **升级时机与决策模型**：     - 系统性能受旧JDK限制、需要现代能力（如AOT、可观测性）时应考虑升级。     - 技术债务持续增加或组织架构调整时，升级的收益大于成本。总结来看，Spring Boot 3的升级是一次架构和技术栈的深层次变革，带来显著的破坏性变化和高昂的迁移成本。多数既有项目选择观望，等待依赖生态成熟和业务驱动，避免盲目冲动升级。升级决策应基于实际收益与风险的综合评估，采取稳健的工程管理策略。]]>
                    </description>
                    <pubDate>Fri, 12 Dec 2025 20:26:39 CST</pubDate>
                </item>
                <item>
                    <title>
                        <![CDATA[Java接入Pinecone搭建知识库踩坑实记]]>
                    </title>
                    <link>https://shiker.tech/archives/286</link>
                    <description>
                            <![CDATA[本文系统总结了基于 Pinecone 向量数据库构建 Java 知识库的全流程与实战经验。首先阐述了构建知识库的必要性，指出传统数据库或 Elasticsearch 无法实现语义检索，且直接调用成本高、维护复杂；而 Pinecone 作为轻量、稳定且成本可控的向量数据库，适合个人及中小项目。文章详细介绍了环境准备（Pinecone 账号、API Key、Index 创建注意事项），并推荐在创建索引时选择 Pinecone 内置 Embedding（如 llama-text-embed-v2），以节省成本、降低延迟及避免维度错误。同时提醒速率限制等使用细节。在 Java 项目接入方面，指出官方 SDK 依赖 Spring Boot 3.x，且与 Spring 2.x 存在 HttpClient 冲突，Java 8 项目难以使用，故推荐绕开 SDK，直接通过 HTTP 接口调用 Pinecone 服务。文中还详细介绍了 Pinecone 的核心概念（索引、维度、命名空间、topK、度量方式、副本分片等）、Java 端完整调用链和知识库问答（RAG）实现流程。针对数据建模，强调文本块（chunk-text）及 metadata 字段设计对检索效果的重要性。此外，分享了常见坑点与排查技巧，如 JSON 解析错误、SpringBoot 编码问题、网络差异、HttpClient 版本冲突等。最后涵盖了性能优化、成本控制、测试监控及运维部署（包括历史数据迁移和增量同步），并总结了最佳实践，帮助开发者快速上手，避免重复踩坑。]]>
                    </description>
                    <pubDate>Sat, 06 Dec 2025 12:40:18 CST</pubDate>
                </item>
    </channel>
</rss>