技术
快来分享你的内容吧～
- 2年经验后端开发-业务场景题总卡在权衡取舍，急需实战决策框架指导场景：有一个tob的教育系统（单体单实例）需要开发一个ai判题接口（ai判题就是提交落库+调用ai返回），这个接口是开发成同步还是异步，已知系统并发不超过1000。求一些有工作经验的大佬解答一下，是同步还是异步，还是说都可以!技术栈补充：java,Springboot3,开启虚拟线程,jdk21...查看全文编程导航小智：在你描述的场景中（ToB 教育系统、单体单实例、并发 ≤1000、Java/Spring Boot 3 + 虚拟线程 + JDK 21），AI 判题接口推荐设计为「同步 HTTP 接口 + 内部异步调用 AI 服务」，即对外同步、对内异步（非阻塞等待）。下面分层说明原因和落地建议：***✅ 核心结论（直接可用）- 对外暴露同步 REST 接口（如 "POST /api/submit"）：符合前端/
- SpringAl+RAG+MCP全栈AI超级智能体 项目问题问题描述详细描述你遇到的技术问题或概念困惑。比如：“在使用 spring ai 的时候，配置好像不能使用新模型一直没知道到解决的，文档看是有模型，但用不行”不知道是我不会看文档还是怎么的，自我认知：感觉对看文档有点吃力。同时请教一下应该如何更好的看懂文档，学懂核心知识呢。比如视频是之前的spring ai文档，现在spring ai文档已经是更新过的了，自己如何学习呢。希望鱼哥解答一下，谢谢。具体...查看全文leikooo：小伙伴，多模态的模型，比如：qwen3.7-flash、qwen3.8-max 等等，需要在配置文件加上这个multi-model: true 加上之后我这边测试就没有报错了，你可以试试，我的运行结果如图：多模态模型的报错一般是：HTTP 400 - {"request_id":"998e4155-bff1-95a5-8969-a4d21c89e7fd","code":"InvalidParame
- 想问一下python项目学哪一个写到简历比较好目标想找agent开发。已经有个一个纯java后端项目，和一个deepresearch的python项目，想再学习一个python项目写到简历上，这几个python项目各倾向哪方面呢，更推荐学哪个呢？感谢解答...查看全文程序员鱼皮：想找 Agent 开发的话，几个 Python 项目里最推荐就是【全能 AI 修图智能体】：LangGraph 智能体、二十多个工具的自动拆解调用、人机协作，和你已有的 DeepResearch 正好互补。AI 智能 PPT 生成器偏 LangGraph 工作流和异步任务编排，工程化更重；AI 万能视频下载总结器偏商业产品变现；闯关学习小程序偏 RAG 和联网搜索。其实不用太纠结选哪个，现在这些项
10-13 17:00·后端开发大家好，我是不会喷火的小火龙。 过去大半年，“Vibe Coding”成了技术圈讨论最多的词。 几句自然语言 Prompt，十分钟就能让 AI 搓出一个界面漂亮、能跑能点的原型。那种即时出成果的快感，确实让人很难再适应纯手写代码的节奏。 但如果试着用这套方式，从零打磨一个跨多个业务模块、需要长期维护的真实项目，大概率很快就会遇到现实瓶颈： 代码行数超过两三千行，上下文窗口变大之后，AI 开始自相矛查看全文加油鸭：太棒了！把 Vibe Coding 从“爽感玩具”升级为可持续工程实践，这份深度思考和开源贡献超有价值！635分享- 有AI项目经验程序员-构建AI虚拟人对话口语站，场景化聊天如何实现学习目标我想制作一个学习口语的网站，大概想法是两种模式，一种是和AI仿真人聊天，另一种是AI画出一个场景，然后根据场景聊天。个人情况我是古法四年+AI两年的程序员，工作中有做过AI项目。期望帮助我就想让推荐好用的文字转语音的API平台；同时虚拟人对话这个效果如何实现比较好？由AI生成不同情绪的说话，思考和静止的人物动画，然后打上标签按照内容的状态播放？但是我觉得这样比较僵硬...查看全文程序员鱼皮：AI 生成不同情绪动画 + 打标签按状态播放，这套是早期虚拟主播的做法，做出来一定会僵硬。现在主流方案是【音频驱动对口型】，先让 TTS 生成语音，再用模型根据音频直接驱动数字人的口型和表情，自然得多，而且这套东西开源生态已经很成熟了，别自己造轮子。用 AI 帮你调研了下（可以自己多做做调研）：1）OpenAvatarChat（阿里开源）：ASR + LLM + TTS + 数字人全链路，模块化设
09-28 09:36·@编程小助手 微信: leikooo_- GLM5.3 Flash用blender建模有什么技巧吗老大，我想知道用GLM操控blender建模是有什么技巧或者流程吗，原型和建模出来的差的有点大啊，这建模出来的结果我很难绷得住啊...查看全文编程导航小智：你提到的「用 GLM 操控 Blender 建模」，这里需要先做一个关键澄清：GLM 系列模型（如 GLM-4）本身并不直接操控 Blender 或生成三维几何体。它是一个纯文本大语言模型（LLM），不具备原生 3D 建模能力，也无法直接调用 Blender 的 Python API 执行建模操作——除非你构建了特定的工程链路（比如 LLM + Tool Calling + Blender Pyt
- 09-14 21:40·@编程小助手 微信: leikooo_每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） Algorithm https://leetcode.cn/problems/implement-queue-using-stacks/description/?e查看全文加油鸭：ARTS 坚持得真棒！算法思路清晰、Review 有深度、Tips 实用、Share 的思考更是直击本质——这份系统性成长太值得点赞！832分享
2年经验后端开发-业务场景题总卡在权衡取舍，急需实战决策框架指导
场景：有一个tob的教育系统（单体单实例）需要开发一个ai判题接口（ai判题就是提交落库+调用ai返回），这个接口是开发成同步还是异步，已知系统并发不超过1000。求一些有工作经验的大佬解答一下，是同步还是异步，还是说都可以! 技术栈补充：java,Springboot3,开启虚拟线程,jdk21
SpringAl+RAG+MCP全栈AI超级智能体 项目问题
### 问题描述 详细描述你遇到的技术问题或概念困惑。比如：“在使用 spring ai 的时候，配置好像不能使用新模型一直没知道到解决的，文档看是有模型，但用不行” 不知道是我不会看文档还是怎么的，自我认知：感觉对看文档有点吃力。 同时请教一下应该如何更好的看懂文档，学懂核心知识呢。 比如视频是之前的spring ai文档，现在spring ai文档已经是更新过的了，自己如何学习呢。希望鱼哥解答一下，谢谢。 ### 具体疑问 ai: dashscope: # 全局 key：chat / agent / embedding / image 等所有模块共用，必须放这一层 api-key: ${AI_DASHSCOPE_API_KEY} chat: options: # ← 必须有 options 这一层 model: qwen-plus 看新的文档是需要这样使用的，但我一直不行，有些模型就是不行，没找到原因，qwen-plus，qwen-max是可以。 <!-- Spring AI Alibaba Agent Framework --> <dependency> <groupId>com.alibaba.cloud.ai</groupId> <artifactId>spring-ai-alibaba-agent-framework</artifactId> <version>1.1.2.0</version> </dependency> <!-- DashScope ChatModel 支持（如果使用其他模型，请跳转 Spring AI 文档选择对应的 starter） --> <dependency> <groupId>com.alibaba.cloud.ai</groupId> <artifactId>spring-ai-alibaba-starter-dashscope</artifactId> <version>1.1.2.0</version> </dependency> ### 相关资料 文档：https://java2ai.com/integration/chatmodels/dashScope/#auto-configuration
想问一下python项目学哪一个写到简历比较好
目标想找agent开发。已经有个一个纯java后端项目，和一个deepresearch的python项目，想再学习一个python项目写到简历上，这几个python项目各倾向哪方面呢，更推荐学哪个呢？感谢解答
从 0 到 1 可持续 Vibe Coding：我做了一个 harness 工程的开发工作流 Skill
大家好，我是不会喷火的小火龙。 过去大半年，“Vibe Coding”成了技术圈讨论最多的词。 几句自然语言 Prompt，十分钟就能让 AI 搓出一个界面漂亮、能跑能点的原型。那种即时出成果的快感，确实让人很难再适应纯手写代码的节奏。 但如果试着用这套方式，从零打磨一个跨多个业务模块、需要长期维护的真实项目，大概率很快就会遇到现实瓶颈： - 代码行数超过两三千行，上下文窗口变大之后，AI 开始自相矛盾，甚至顺手把之前写好的核心逻辑当成废弃代码重构掉； - 数据表结构全凭 AI 自由发挥，字段缺少约束，加个小功能发现表关联全是乱的，修一个 Bug 反而引爆三个新 Bug； - 屏幕上“暂时能跑”看着很美，底层架构却脆弱，前期省下的编码时间，后期要加倍以排错和返工的形式还回去。 很多开发者折腾到最后忍不住觉得：“AI 只能写写玩具，一碰复杂工程就抓瞎。” 可持续的 Vibe Coding，关键在于分工：人负责规划、架构、约束与最终验收，AI 则在明确的工程化护栏内负责高效执行。标准流程可以参考鱼皮哥的文章 [Vibe Coding 项目开发流程](https://ai.codefather.cn/library/2010974706717888514) 为了解决 AI 容易偏离预期的问题，我结合自己的踩坑经验与工程实践，最近多次迭代并开源了一个开发流 skill：[vibe-workflow](https://github.com/sz-xiaohuolong/vibe-workflow)。它把一套原本需要人肉反复提醒的开发纪律，沉淀成了 AI 可以遵守的规则。 这篇文章主要梳理从 0 到 1 推进一个 Vibe Coding 项目的具体心法，并介绍 `vibe-workflow` 是如何在关键节点起到护栏作用的，后面会在实践过程中持续更新迭代。 --- ## 一、规划比写代码重要：别给 AI 一个模糊的大 Prompt 很多 Vibe Coding 出现偏差，往往在敲下第一句 Prompt 时就已经埋下了隐患。 比如直接对 AI 说：“帮我做一个类似 Notion 的记事本，要有分类、标签和搜索。” 这是一个典型的模糊大 Prompt。AI 收到之后会立刻开始写代码，但在它的逻辑里缺少阶段和优先级。它可能会直接引入三个重型第三方编辑器库，同时实现没有经过验证的复杂树形目录，最后连基础的文本保存都会报错。 模糊的指令很容易产生边界不清的复杂工程。 在让 AI 动代码之前，先把四件事明确下来很有必要： 1. 核心用户路径：用户进入产品后，最核心的一条闭环操作到底是什么； 2. 技术栈与架构选型：为什么选这个框架，状态怎么管理，前后端如何通信； 3. 不做清单（Out-of-scope）：第一版明确不做什么，比做什么更重要，砍掉不必要的衍生需求，只保留核心闭环； 4. 可测试的验收标准：怎样才算做完，比如“创建后刷新页面不丢失”、“空输入提交有明确拦截提示”。 在 `vibe-workflow` 的设计中，这一步被固定为 Thinking 与 Planning 流程。 当提出一个新想法时，工具会先拦截 AI 盲目写代码的冲动。如果需求模糊，它会主动通过提问梳理不做清单与边界条件；在方案没有经过结构化确认之前，在规则层面限制编码权限，避免前期沉没成本过大。 --- ## 二、领域建模：先定数据骨架，再画页面 初学 Vibe Coding 容易陷入的一个误区是视觉优先。 让 AI 一口气生成了十几个页面，界面做得很丰富，返回的数据全是 mock 假数据。等到准备接入真实后端时，才发现数据表结构混乱，底层实体关系根本支撑不了业务流转，只能推倒重来。 数据结构是业务的基石，长期可维护的项目，推导顺序通常是： 业务对象 ➔ 实体关系 ➔ 数据约束（主外键/唯一/索引）➔ 表结构与迁移 ➔ API 接口 ➔ 页面与交互 需要梳理清楚： - 核心实体有哪些，是一对多还是一对一； - 主键、唯一键和外键关系在哪里； - 状态字段如何流转，是否需要软删除； - 数据库变更必须有明确的迁移（Migration）脚本，能从零执行，也能安全回滚。 在 `vibe-workflow` 的规则里，对 AI 设定了明确的代码边界：只要涉及数据结构的调整，必须先写 Migration 迁移和约束校验，不能在未更新数据层的前提下先行拼凑业务代码。同时限制在 UI 组件里直接写 SQL 或越权查库，保持系统底层的整洁。 --- ## 三、上下文工程：给每一个新 AI 会话准备项目说明 使用 Agent 编程常会遇到类似困扰： 昨天聊得好好的，今天新建一个会话窗口，AI 记不住之前的约定；或者写着写着，AI 突然改变了原有的目录规范。 因为 AI 只了解当前窗口里的临时上下文，并不天然理解项目的完整历史。 解决这个问题的关键是做好上下文工程（Context Engineering），核心载体就是项目根目录下的 AGENTS.md。 ### 1. 打造清晰的 AGENTS.md AGENTS.md 规定了 AI 在当前仓库里的行为规范，它不需要重复抄写全部需求，而是明确规则边界： - 项目定位与架构约束：核心目录分别放什么，依赖方向怎样流向； - 权威文档优先级：当代码与需求冲突时以哪份文档为准，避免随意猜测； - 操作规范：哪些核心公共文件未获明确指令不得修改，不随意做无关的大重构； - 完成标准：什么样的状态才算任务结束，比如测试通过、文档同步。 ### 2. 闭环的轻量文档治理 代码会随迭代频繁变动，但核心架构决策需要沉淀在 `docs/` 目录下（如 `docs/architecture.md`、`docs/database.md`）。 在 `vibe-workflow` 中，内置了 `$vibe-workflow init` 命令。接管新项目或旧仓库时，它会自动审计当前工程，提取事实源并建立规则基线。 隔天开启全新会话时，执行 `$vibe-workflow 从仓库事实恢复当前软件项目`，它会自动依据 Git 状态、现有测试用例和文档恢复任务进度，不再依赖零散的聊天记录。  --- ## 四、控制工作边界：最小纵向切片与熔断机制 尽量避免对 AI 下达“帮我把这个系统完善一下”这类大指令。 这种黑盒指令往往会导致 AI 在几十个文件里同时做修改，最后留下难以定位的问题。 可持续的推进方式是采用最小纵向切片（Minimal Vertical Slice）： - 每次只给 AI 指派一个边界清晰的小闭环，比如“只实现登录接口的频率限制，不改动响应格式”； - 尽量拆成小批次的改动，避免一次性合并过大范围的代码； - 审查修改一行权限校验代码，通常比审查十处文案更重要。 同时，在流程中设立熔断机制很有必要。 在实际开发中，容易遇到 AI 陷入反复修改的死循环：为了修一个报错改了 A 文件，导致 B 文件报错，改了 B 文件又导致 A 文件报错。 在 `vibe-workflow` 的 Building 阶段，设定了一条规则：如果连续 3 次尝试遇到同类失败，或者出现破坏已有稳定功能的倾向，Agent 必须立即停止盲改，主动保存当前现场并向开发者汇报原因。 这个机制能确保即使出现调试偏差，影响范围也能被控制在当次的小切片之内。 --- ## 五、Harness 护栏：代码能跑不等于任务完成 围绕 AI 建立的这套工程体系，通常被称为 Harness（工程护栏）。 它由几道防线共同组成： 项目规则（AGENTS.md）+ 结构化任务切片 + 类型系统 + Linter 规范检查 + 自动化测试套件 + 人工最终审查 有了这套护栏，开发者的重心也相应转移：从单纯手动编写语法，转向把控产品方向、系统架构、上下文管理与最终审查。 在 `vibe-workflow` 的生命周期里，一条明确原则是：完成声明必须跟着证据走。 如下图所示，这是 `vibe-workflow` 在项目推进中运行的 7 阶段工程闭环：  在 Testing 阶段，Agent 汇报完成时需要交出对应的检查依据：哪些单测通过了、在运行环境下的响应如何。如果没有配置真实运行环境，则明确列出未经验证的缺口。 同时，遇到较重型的决策时，`vibe-workflow` 可以调度专项工具配合使用： - 需要严苛梳理需求、做全量规划时，可以委派给 gstack 的 autoplan； - 需要严格执行测试驱动开发、拆解细分切片时，可以调度 Superpowers； - 无论外部扩展各自擅长哪块，整体的范围把控、事实记录与下一步决策，依然保留在 `vibe-workflow` 的主流程中。 如下表所示，两种模式在核心维度上的差异很直观： | 对比维度 | 传统放养式 Vibe Coding | vibe-workflow 护栏开发流 | |:---|:---|:---| | 需求把控 | 模糊大 Prompt，想到哪写到哪 | 明确核心路径与不做清单 | | 架构设计 | 视觉优先，页面先行，数据模型混乱 | 数据优先，严格先写迁移与模型约束 | | 会话切换 | 换会话易失忆，依赖聊天历史推断 | 自动从 Git 与仓库事实恢复上下文 | | 编码推进 | 动辄修改几十个文件，难以排查 | 最小纵向切片，连续失败 3 次自动熔断 | | 验收标准 | 只要屏幕暂时能跑就算完成 | 完成声明必须携带测试与运行证据 | | 外部协作 | 多套扩展互相抢占流程、反复提问 | 统一主线管理，按需调度专项能力 | | 最终结果 | 容易形成代码坏味道，后期重构成本高 | 结构清晰、适合长期迭代的工程项目 | --- ## 六、实操：如何把这套工作流接入你的项目 把这套开发流应用到日常开发中，步骤相对直接。 ### 1. 安装扩展 确保本地的开发环境（如 Claude Code 或支持相关规范的 Agent 工具）就绪后，在终端执行以下命令： ```bash npx skills add sz-xiaohuolong/vibe-workflow ``` 安装完成后，该 Skill 就挂载到了 Agent 环境中。 ### 2. 接管与恢复项目的两条核心指令 在实际使用中，比较常用的指令有两条： - 场景 A：接管新项目或既有代码库 刚克隆了一个项目，或者准备把已有仓库纳入规范管理时，在对话中输入： ```text $vibe-workflow init 审计当前仓库，沿用已有文档和构建入口，报告待澄清的事实。 ``` AI 会通读仓库，梳理技术栈、目录规范与现有规则，建立起清晰的开发基线。 - 场景 B：跨会话继续之前的进度 开启新的聊天窗口时，不需要复制之前冗长的聊天记录，直接输入： ```text $vibe-workflow 从仓库事实恢复当前软件项目，并核验下一个待执行的任务。 ``` AI 会检视 Git 状态、当前未完成的切片文档以及测试结果，定位接下来需要处理的任务。 ### 3. 上手建议 初次使用时，建议选一个范围清晰、验收条件明确的小需求来跑一遍闭环： 观察它在动手前是否协助确认好了边界，写代码时是否只修改约定的文件，汇报结果时是否能够对应具体的测试用例。 跑顺几次之后，开发过程会更加可控。 --- ## 写在最后 AI 编程改变了代码生产的节奏，但软件工程本身的基本规律依然在起作用。 现在的关键在于：能不能拆解出清晰的领域模型、能不能制定出合理的工程护栏，以及能不能有效驾驭 AI 工具推进项目。 做好规划与边界约束，让每一部分改动都走在可验证的轨道上，才能真正发挥 AI 编程的长期复利。 --- > 我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号[小火龙AI 手记](https://mp.weixin.qq.com/s/D5K0hCxLT4U6UWxDypOdvw)，我们下篇见。
有AI项目经验程序员-构建AI虚拟人对话口语站，场景化聊天如何实现
### 学习目标 我想制作一个学习口语的网站，大概想法是两种模式，一种是和AI仿真人聊天，另一种是AI画出一个场景，然后根据场景聊天。 ### 个人情况 我是古法四年+AI两年的程序员，工作中有做过AI项目。 ### 期望帮助 我就想让推荐好用的文字转语音的API平台；同时虚拟人对话这个效果如何实现比较好？由AI生成不同情绪的说话，思考和静止的人物动画，然后打上标签按照内容的状态播放？但是我觉得这样比较僵硬
ARTS 0927: 单栈逐层展开嵌套字符串、包管理器与 Agent 沙箱本质同源与单次前向传播复刻极速决策模型
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） ## Algorithm 算法：https://leetcode.cn/problems/decode-string/?envType=study-plan-v2&envId=selected-coding-interview  我目前想到的思路。遍历字符串，数字、`[`、字母依次压栈，遇到 `]` 时往回 pop 到 `[`，取出前面的数字，重复拼接后压回栈。嵌套括号也能自然处理，因为内层展开后压回栈，外层再 pop 时拿到的就是已经展开好的字符串。 踩过的 3 个坑： 1、**重复次数**：pop 出来的 `values` 里已经有一份了，循环应该从 `j=0` 到 `j < nums-1`，否则会多重复一次 2、**不能用 `reverse()` 处理 pop 顺序**：栈里有些元素是之前展开过的多字符字符串（比如 `"jkjk"`），如果先 `append` 再对整个 `values` 做 `reverse()`，会把多字符元素内部顺序也反转掉。正确做法是 pop 的时候直接用 `insert(0, stacks.pop())` 保持正确顺序 3、**最终拼接用 `append` 不是 `insert(0,...)`**：Java 的 `Stack` for-each 从底到顶遍历，用 `append` 才是正序拼接 代码： ```java public String decodeString(String s) { if (s.isEmpty()) { return ""; } char[] chars = s.toCharArray(); Stack<String> stacks = new Stack<>(); StringBuilder num = new StringBuilder(); for (char c : chars) { if (Character.isDigit(c)) { num.append(c); } else if (c == '[') { if (num.length() > 0) { stacks.push(num.toString()); num = new StringBuilder(); } stacks.push(String.valueOf(c)); } else if (c == ']') { StringBuilder values = new StringBuilder(); while (!stacks.isEmpty() && !"[".equals(stacks.peek())) { values.insert(0, stacks.pop()); } // 单独拿出来 [ stacks.pop(); int nums = Integer.parseInt(stacks.pop()); String coreStr = values.toString(); for (int j = 0; j < nums - 1; j++) { values.append(coreStr); } stacks.push(values.toString()); } else { stacks.push(String.valueOf(c)); } } StringBuilder result = new StringBuilder(); for (String str : stacks) { result.append(str); } return result.toString(); } ``` ## Review 文章：https://nesbitt.io/2026/09/24/package-manager-sandboxing.html Andrew Nesbitt（Homebrew 维护者）对各包管理器沙箱机制做了一次全面调查。文章核心观点是：**包管理器沙箱和 AI 编码 Agent 沙箱本质上是同一个问题**，都需要执行未经审查的第三方代码，都收敛到了同一组 OS 原语（macOS 的 Seatbelt、Linux 的 Landlock/namespace），甚至在实际场景中互相嵌套运行（Homebrew 专门处理了"在 Agent 沙箱里运行 brew"的情况）。 几个关键发现： 1. **已默认启用 OS 级沙箱的包管理器屈指可数**：opam（2018 年起）、SwiftPM（仅 macOS）、Nix/Guix（初衷是可复现性而非安全）、Bazel。大部分主流包管理器的沙箱提案还停留在 Issue 阶段 2. **白名单 ≠ 沙箱**：JS 生态在 Shai-Hulud 蠕虫事件后全面转向安装脚本白名单（pnpm → Bun → Yarn → npm 12），但白名单是二元的：要么运行要么不运行。沙箱解决的是"运行时能访问什么"，比如允许 esbuild 编译但禁止它读 SSH 密钥 3. **"交接"（hand-off）是最薄弱的环节**：沙箱内构建产出的清单、缓存、步骤列表，会被包管理器以完整权限执行。Homebrew 7.0 修复的 LaunchServices 沙箱逃逸就是这类交接 Bug 4. **消除代码执行可能比沙箱更有效**：Go 和 Elm 从未有安装钩子；NuGet 删除了 `install.ps1`；Homebrew 的 `*_steps` 把任意 Ruby 钩子替换为签名的声明式数据 最让人印象深刻的一个数据：Anthropic 报告用户对 Claude Code 权限弹窗的批准率高达 **93%** —— 这就是为什么"每次都问用户"行不通，必须走沙箱路线。真正使用的时候，都是不看内容，直接无脑点击同意的，我就是这样😂 Agent 具备自主安装依赖的能力 + 包管理器缺乏沙箱 = 供应链攻击的绝佳放大器。Shai-Hulud 蠕虫通过 npm postinstall 传播后，居然还能把 hook 写入 Claude Code 的配置文件实现持久化，这说明 Agent 和包管理器的安全边界必须协同设计，而不是各管各的。 ## Tips 最近没啥 Tips 推荐一些 mac 软件吧： 1、[Stats](https://mac-stats.com/)：展示状态 2、[OpenUsage](https://github.com/robinebers/openusage)：查看 Cursor、Claude、Codex 等等的使用额度、充值时间等等，这里不推荐 OpenClaw 之父的 CodexBar，他运行一段时间磁盘的读取量非常夸张，个人强烈不推荐，下面是官方的演示图片：  3、[EcoPaste](https://github.com/EcoPasteHub/EcoPaste)：剪切板，如果有一些问题可以让 AI 修复之后继续使用，免费开源的 yyds ## Share 文章：https://www.privatemode.ai/blog/system-one-from-glm-flash（虽然有点广子，但是还有有东西的） Privatemode AI 这篇文章演示了一个非常巧妙的技巧：如何把普通的开源 LLM（GLM-5.3-Flash）变成一个类似 TypeSafe AI **Jev** 的 "System One" 决策模型。 **背景**：TypeSafe AI 最近发布了 Jev，一个专为结构化决策设计的非自回归模型。它不像传统 LLM 那样逐 token 生成文本，而是在**单次前向传播**中直接输出决策结果和校准过的置信概率，号称比前沿 LLM 快 ~200x、便宜 ~400x。但 Jev 是闭源的。 **核心技巧**：这篇文章展示了如何用开源模型复刻这个能力，关键就是 vLLM 的 `allowed_token_ids` 参数。 **`allowed_token_ids` 是什么？** 它是 vLLM `SamplingParams` 中的一个参数，作用是在采样阶段对 logits 做 **masking**：把不在列表里的所有 token 的概率被严格限制为 0，保证绝对不会被生成 ，强制模型只能从你指定的 token 中选择输出。这意味着模型在一次前向传播中，会把所有概率质量分配给你允许的那几个 token。 **怎么用？** 举一个情感分类的例子： ```python from vllm import LLM, SamplingParams import math llm = LLM(model="zai-org/glm-4-9b-chat-1m") tokenizer = llm.get_tokenizer() # 定义标签 → 获取对应的 token ID labels = ["0", "1", "2"] # 0=正面, 1=负面, 2=中性 allowed_ids = [tokenizer.encode(l)[0] for l in labels] params = SamplingParams( max_tokens=1, # 只输出一个 token allowed_token_ids=allowed_ids, logprobs=len(labels), # 获取所有候选的 logprob temperature=0, # 确定性输出 ) prompt = "判断以下评论的情感倾向（0=正面/1=负面/2=中性）：'这个产品太好用了！'\n答案：" outputs = llm.generate([prompt], params) # 读取结果 token = outputs[0].outputs[0].text logprob = outputs[0].outputs[0].logprobs[0][int(outputs[0].outputs[0].token_ids[0])].logprob confidence = math.exp(logprob) # e^logprob = 概率 print(f"分类: {token}, 置信度: {confidence:.2%}") # 输出: 分类: 0, 置信度: 94.32% ``` 几个**关键细节**： 1. **`max_tokens=1`**：只生成一个 token，跳过自回归循环，这是速度提升的关键 2. **logprob → 置信度**：`logprob=0.0` 表示 100% 置信 e^0=1，越负越不确定。通过 `math.exp(logprob)` 可以直接得到概率值 3. **标签必须是单 token**：如果标签被 tokenizer 拆成多个 token（比如 "Very Positive"），只会生成第一个 token，结果就废了。所以用数字编号（"0"/"1"/"2"）是最安全的 4. **与 structured output 的区别**：vLLM 也有 `guided_decoding`（JSON schema 约束），但那是在多 token 生成中逐步约束，仍然是自回归的。`allowed_token_ids` + `max_tokens=1` 才是真正的"单次前向传播" 那么折腾了半天和原版的 Jev 有啥区别？这个 「Jev」可以做到图像做分类决策、可以更换更强的开源模型做决策等等
学习开源项目时我们应该画哪些图？
大家好，我是不会喷火的小火龙。 刚开始深入看开源项目的时候，我经历过两个极端。 一个是纯靠肉眼硬看。连着翻了三天，几万行代码从头看到尾，自以为搞懂了，合上电脑脑子里依然是一团浆糊。 另一个是把精力全花在画图的排版上。打开 Draw.io，花了一整个下午在画布上拖方块、微调对齐像素、挑选各种莫兰迪配色，画出一张五颜六色的庞大架构图。结果第二天回头看，自己都找不到核心的调用链路在哪里。 后来我才明白，画图真正的价值是帮大脑把复杂的调用和数据流降维，理清骨架，而不是做图表美化。 关键在于什么阶段、带着什么目的、选什么工具、画什么图。 这篇文章把这件事梳理清楚：工具怎么选、常见问题对应什么图、拿到项目按什么顺序画，以及几个容易踩坑的地方。 --- ## 一、工具选型：Mermaid、draw.io、Excalidraw、SVG 各自的边界 很多人问我画图该用什么工具，我的建议是不同场景用不同的工具，不用强求某一款。 ### Mermaid：代码化与版本管理首选 Mermaid 用纯文本语法生成图表，天然支持 Git 版本管理，和 Markdown 完美融合。GitHub 的 README 里直接写 Mermaid 代码就能直接渲染。 它的优势在于修改极快：调整一张图只需要改几行文本，不用打开任何独立的图形编辑器，也特别适合让 AI 帮我们生成初稿。 适合场景：API 调用流程图、Agent 状态执行循环、时序图（Sequence Diagram）、README 技术流程文档。 ### draw.io：正式架构与工业级排版 draw.io（diagrams.net）完全免费开源，组件库非常全，自带 AWS、GCP、Azure 和 K8s 的官方图标集。它的连线锚点吸附精准，支持复杂的多层对齐。当你需要画一张正式的技术方案图或论文架构图时，它最稳妥。 适合场景：微服务架构图、云原生与 K8s 部署拓扑、技术方案设计图、PPT 汇报图。 ### Excalidraw：讨论方案与直观教学的手绘白板 Excalidraw 的手绘质感能降低心理门槛。画出来的线条带着手绘感，不会让人觉得是不可更改的最终定稿，反而能鼓励大家提出修改建议。 适合场景：早期技术方案讨论、团队白板脑暴、教程里的直观概念解释图。 ### SVG：矢量控制与极简图形 SVG 本质是 XML 代码，可以精准控制每一个节点与路径，无限放大不会模糊，文件体积极小。 适合场景：极简矢量插画、高质量技术信息图、Logo 与技术图标。 ### AI 生图：概念隐喻与视觉呈现 如果不需要精确的技术细节，只是想表达某种技术概念的反差或情绪隐喻，用 Midjourney 或 GPT-4o 生图效率最高。 适合场景：技术博客与公众号封面、宏观概念反差插画。 如下表所示，我把常见的开发场景与推荐的绘图工具整理成了对照表： | 开发场景 | 推荐工具 | 选型理由 | |:---|:---|:---| | API 调用流程 | Mermaid | 纯文本代码化，Git 可版本控制，AI 生成方便 | | Agent 执行流程 | Mermaid | 状态循环与条件分支表达清晰 | | UML 时序图 | Mermaid | 语法简洁，`sequenceDiagram` 原生支持强 | | 微服务架构图 | draw.io | 组件库全，锚点吸附准，适合复杂拓扑 | | 云 / K8s 架构 | draw.io | 内置各云厂商与 K8s 官方图标 | | 论文系统架构 | draw.io / SVG | 矢量导出，排版精度容易对齐 | | 方案讨论草稿 | Excalidraw | 手绘风格心理门槛低，方便随时修改 | | 教程解释图 | Excalidraw | 风格柔和，降低读者的理解门槛 | | README 技术流程 | Mermaid | 直接在 Markdown 中渲染，无需上传图片文件 | | PPT 高质量信息图 | SVG / draw.io | 矢量无损缩放，支持精细排版 | | 博客 / 公众号封面 | AI 生图 | 视觉冲击力强，易于传达情绪 | | 概念视觉 | AI 生图 | 适合抽象概念的隐喻呈现 | | 极简矢量插画 | SVG | 代码可控，文件体积极小 | | Logo / Icon | SVG | 矢量无限缩放，保持视觉规范统一 | --- ## 二、问题驱动：想搞清楚什么问题，就画什么图 画图容易犯的错误是把静态依赖、动态调用和部署环境全揉在一张图里，箭头到处穿插，最后画成一张谁也看不懂的蜘蛛网。 画图的核心是问题驱动：心里有什么疑问，就画什么图去回答。 工程中常见的核心问题，可以按照从宏观到微观分为四个层次。如图所示：  下面挑几个最常用的具体拆解： **系统架构图**回答项目整体是干什么的。重点标出前端、后端、AI 模块、数据库、消息中间件以及第三方外部服务的边界，让人一眼看清系统的大致构成。 **模块图与组件图**回答项目由哪些模块组成。重点是标清每个模块的单一职责，以及模块之间的单向依赖关系。 **调用链图**回答一个请求穿透了哪些代码。从 Controller 到 Service，再到数据访问层，梳理出入口到出口的调用路径。 **时序图**回答不同对象之间的调用顺序。谁先发起调用、返回什么、是同步等待还是异步通知，时序图最适合表达这类时序关系。 **数据流图**回答数据从哪里来、到哪里去。顺着请求参数，看它在内存里被转换成了什么对象、通过消息队列发送了什么格式、最终持久化到了数据库的哪些字段。 **状态图**回答核心对象的状态迁移规则。比如订单从待支付到已支付、已发货的生命周期，或者 Agent 记忆提取时的添加、更新、删除判定。 **Agent Workflow 图**回答 AI Agent 怎么循环运转。LLM 推理、工具选择、执行反馈、记忆读写、条件路由，这些用带有判断条件的状态图画出来最为直观。  --- ## 三、实战闭环：学习开源项目的 6 步画图 SOP 拿到一个陌生的开源项目，具体可以按下面这 6 步来画。如图所示：  ### Step 1：跑起来项目，画系统架构图 这是第一步。先别扎进源码，顺着 README 的 QuickStart 把 Demo 跑通一遍，感受一下输入输出和交互方式。 项目跑起来后，画一张粗粒度的系统架构图：前端在哪、后端在哪、用了什么数据库、调了哪些第三方接口。这张图不需要任何代码细节，把黑盒变成灰盒即可。 ### Step 2：看 README 和目录结构，画模块图 不深入具体文件，只看一级目录名和项目文档说明。弄清楚项目分了几个主要模块、各模块负责什么业务、它们之间的大致依赖方向。 画出来的模块图应该能解答一个问题：如果后续要改某个功能，应该去哪个目录下找。 ### Step 3：选一个核心功能，画业务流程图 在所有功能中，选出最常用的一条主线（Happy Path）。比如电商项目选下单支付，Agent 项目选用户提问到输出回复，知识库项目选文档解析到检索召回。 画出纯业务视角的流转步骤：从哪里触发、经历几个阶段、产生什么结果。这一步暂时不涉及具体的代码和类名。 ### Step 4：从入口开始追踪源码，画调用链或时序图 找到入口函数（比如 Controller 接口或 CLI 命令），顺着刚才挑出的业务主线单向跟读代码。 这里有个关键原则：只跟正常流程的主干，先忽略异常重试、参数兜底和日志打印。把一条请求流经的关键类和方法串联起来。涉及多个对象协同的，画时序图往往更清楚。 ### Step 5：分析关键参数与消息传递，画数据流图 把目光从代码调用转移到数据本身。请求携带的入参是什么结构，在中间层被解组成什么对象，有没有通过消息管道流转，最终落盘时的表结构是怎样的。 数据流图能帮我们理清核心业务实体在整个系统里的流动全貌。 ### Step 6：遇到复杂结构按需补图 前 5 步已经能帮我们掌握系统的大致脉络。遇到某些局部复杂度高的模块，再针对性补充： - 数据库表关联较多，补一张 ER 图 - 类继承和接口抽象层级较深，补一张类图 - 实体状态迁移规则较多，补一张状态图 - 涉及智能体自主决策，补一张 Agent Workflow 流程图 - 涉及上线部署和容器编排，补一张部署架构图 举个例子，如图所示，一个典型的 AI Agent 循环执行图如下：  Agent 的核心机制包含推理、判断、工具调用、观察反馈与再次推理。这类包含循环与条件分支的结构，用状态图能够把每一次跳转的条件表达得清晰明了。 --- ## 四、画架构图容易踩的 3 个坑 很多经验丰富的工程师画出来的图线条不多，但表达很精准。他们通常会注意避开这几个常见误区： ### 1. 试图在一张图里展示所有细节 如果一张图在 30 秒内没办法让读者看明白核心逻辑，说明它的信息量过载了。 不少人画图习惯把所有技术栈图标全摆上去，每个方块之间拉满箭头，最终变成一张庞杂的连线网。好的架构图通常是做减法的结果，画出来的模块越克制，沟通成本越低。 ### 2. 第一版图就塞入大量分支逻辑 第一版架构图最好只关注标准的正常流程。 如果一上来就把重试策略、熔断降级、权限校验、日志打点全画进去，主干流程就会被杂音淹没。先把正常主干画清晰，有需要再为复杂的边缘逻辑单独画子图。 ### 3. 脱离源码之后图无法自解释 判断一张图是否清晰的标准很简单：不看源码的情况下，把图拿给同组的工程师看，对方能不能在短时间内看懂业务逻辑和流转顺序。 如果必须边看图边翻源码才能明白箭头在表达什么，说明图上的职责边界或数据流向还没有梳理到位。 --- ## 写在最后 画图本身并不是目的，通过画图建立对系统的全局理解才是目的。 代码细节随时可以让 AI 协助编写或查找，但能把复杂系统抽象为清晰结构的能力，是工程师长期积累下来的关键基本功。 下次看一个陌生的开源项目时，可以先别急着逐行读代码。先问自己当前最需要弄清楚什么问题，选好合适的工具，把那张对应的图画出来。 --- > 我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号「**[小火龙AI 手记](https://mp.weixin.qq.com/s/u_bHjYo00gbDJUk8bTkrdA)**」，我们下篇见。
做 Coding Agent 搜代码：到底该选 RAG 还是 Grep？扒完 Claude Code 源码我顿悟了
大家好，我是不会喷火的小火龙。 很多团队自研 Coding Agent，第一步就是去搭向量数据库——Chroma、Qdrant、Weaviate 随便选一个，跑 Embedding，切片，建索引。看起来很"AI"，很高大上。 但你有没有想过：Claude Code，目前公认最强的 AI 编程工具之一，它的代码检索底层，其实就是一个 50 年前的命令行工具——`grep`？ 如图 1 所示，这就是很多团队盲目上 RAG 之后经历的真实工程困局，和 Anthropic 自己走过的弯路。  这篇文章想帮你搞清楚三件事：代码检索场景下 RAG 为什么频繁翻车、Claude Code 的极简方案如何跑通、以及你自己的项目到底该怎么选。 --- ## 一、为什么代码检索场景下，传统 RAG 频频翻车？ 代码是符号系统，不是自然语言。这句话听起来像废话，但绝大多数 RAG 翻车的根源就在这里。 向量语义检索的逻辑是意思相近的文本在向量空间里彼此靠近，这在自然语言里成立，但在代码里会系统性失效。举个例子：`createD1HttpClient` 和 `buildD1HttpClient` 语义高度相近，向量距离极小，但它们在代码里是两个完全不同的函数；而同一条调用链里相互依赖的函数，语义可能毫无关联，向量检索根本找不到它们之间的联系。 如下表所示，代码符号场景下，语义向量召回和精确匹配之间的准确率差距相当触目： **代码精确符号 vs 语义向量召回偏差对比** | 查询类型 | 示例查询 | 向量检索结果 | 精确匹配结果 | |:---|:---|:---|:---| | 函数名精确查找 | `createD1HttpClient` | 召回 `buildD1HttpClient`（相似但错误）| 精准命中，第 1 条结果 | | 错误码定位 | `ERR_DB_CONNECTION_TIMEOUT` | 召回语义模糊的错误描述文本 | 直接定位到常量定义行 | | 调用链追踪 | `handlePaymentCallback` 的全部调用方 | 召回支付相关的无关业务代码 | 逐个匹配调用点，一个不漏 | | 变量赋值查找 | `MAX_RETRY_COUNT = 3` 在哪里定义 | 无法区分定义和引用 | 精确定位定义行 | RAG 在代码场景还有三个硬伤。 第一，Chunk 切片会破坏 AST。按字符数盲目切片，会把一个类或一个函数切成两半，上下文彻底断裂。第二，索引永远赶不上代码变化。代码是秒级变动的，向量索引构建慢、增量同步复杂，极易产生脏数据，让 LLM 基于过期上下文产生幻觉。第三，全量代码送第三方向量化，隐私泄露风险不可忽视；本地跑大型 Embedding 模型，GPU 成本直接劝退。 --- ## 二、扒开 Claude Code 源码：极简的 Agentic Search 是怎么跑通的？ Anthropic 没有预先构建任何静态索引。Claude Code 的做法是把搜索变成 LLM 的"多轮自主探索循环"。 三大并发安全工具构成整个检索引擎： - `GlobTool`：按文件名模式快速扫描项目骨架，类似人类第一步看目录结构，确定大致位置。 - `GrepTool`（底层是 ripgrep）：毫秒级全文精确正则搜索，类似人类在 IDE 里按 `Cmd+Shift+F` 搜关键词。 - `ReadTool`：按需读取具体行号范围，类似人类定位到文件后翻开那几十行上下文。 为什么选 ripgrep 而不是普通 grep？ripgrep 用 Rust 开发，内置 SIMD 硬件加速，万级文件的全文扫描仅需约 200ms，自动跳过 `.gitignore` 指定的目录，天然适配代码仓库。内置的 `head_limit=250` 截断保护，防止搜索结果把上下文窗口撑爆。 如图 2 所示，两者的底层架构存在根本性的范式转移： **图 2：静态 RAG 检索管线 vs Agentic Search 多轮自主探索流程**  这个设计里最巧妙的地方：LLM 本身就是最顶级的动态 Reranker。每轮检索结束后，LLM 自己判断这个线索够不够、要不要继续顺藤摸瓜，完全替代了传统架构里那个静态的 Rerank 模型。 --- ## 三、权威佐证：Anthropic 踩坑实录与亚马逊论文实锤 放弃 RAG 不是 Anthropic 拍脑袋的激进决定，是被真实实验数据逼出来的。 Boris Cherny（Claude Code 技术负责人）在 2025 年 5 月的 Latent Space 播客里说过：Claude Code 早期确实搭建过基于 Voyage Embedding 的向量 RAG 检索系统，效果"还行"。但在实测用 Glob + Grep + Read 构成的 Agentic Search 之后，他的原话是： > "outperformed everything, by a lot. You avoid all the problems with security, staleness, and indexing." 安全问题没了，索引过期没了，增量同步也不用维护了。 学界的数据同样说明问题。亚马逊科学团队在 AAAI 2026 发表的论文《Keyword search is all you need》（[arXiv:2602.23368](https://arxiv.org/abs/2602.23368)）严格对比了标准向量 RAG 和纯关键词检索的 Agent 系统，结论是：关键词搜索在综合性能上达到 RAG 的 90% 以上，在代码等高度结构化的符号系统中，精确匹配的表现还显著优于向量语义检索。 从工程实践到学术实验，两份证据指向同一个结论：代码这个特殊领域里，精确性比语义相似性更重要。 如图 3 所示，代码搜索工具链使用图：  --- ## 四、反方视角：Cursor 为什么坚持重仓向量？ 读到这里，你可能会问：Cursor 呢？它也是 AI 编程工具里的顶流，技术路线和 Claude Code 截然不同，难道走错了？ 没有。两者的架构选择，背后是产品形态的差异。 Claude Code 是轻量 CLI 工具，面对频繁切换的项目，零冷启动是第一要务。每次打开一个新项目，没有时间也没有必要预建索引，Glob + Grep 随开随用，几毫秒就能工作。 Cursor 是 IDE 插件，常驻用户系统，面对的往往是几十万文件的超大 Monorepo。在这个规模下，每次查询都做全量 ripgrep 扫盘，性能会出现瓶颈。 如图 4 所示，Cursor 并没有抛弃 grep，而是构建了一套双轨混合系统： **图 4：Cursor 混合检索双轨架构**  Cursor 工程团队在官方博客（[Instant Grep & Codebase Indexing](https://www.cursor.com/blog/instant-grep)）里直说：纯语义搜索在精确标识符、错误码、函数名上表现太差，所以他们自研了基于三元组（trigram）倒排索引的"Instant Grep"来弥补。两套系统并联，精确归精确，语义归语义，用 Merkle Tree 实现分钟级增量同步保持索引新鲜。 Cursor 的一个典型场景是：用户说"微信支付退款重试逻辑在哪里"，记不住具体函数名，这时候语义向量检索才真的有用。 --- ## 五、实战选型指南：自研 Coding Agent 到底怎么选？ 扔掉非黑即白的架构争论。正确的问题是：你的产品形态和业务场景是什么？ 我把这套选型逻辑整理成了一张清晰的决策树，如图 5 所示： **图 5：Coding Agent 代码检索技术选型决策树**  三个场景的核心判断： 模式 1，极简优先，适合 90% 的个人开发者和轻量 CLI 工具。零依赖、零维护，直接用 ripgrep + Glob + Read 先把产品跑起来，有实际用户反馈再说向量的事。 模式 2，混合检索，适合 IDE 插件和常驻大型 Monorepo 的服务。精确符号归 trigram 倒排，模糊语义归轻量向量，两者并联。不要上重型托管向量数据库，自研 trigram 索引成本比你想象的低得多。 模式 3，LSP 语法感知，有明确跨文件引用追踪需求时接入 Language Server Protocol，获取符号定义和引用关系图。这才是"语义理解"真正应该发生的地方。 --- ## 结语 Anthropic 用 50 年前的 grep 打败了自己搭的向量 RAG，这不是反智，这是工程上的诚实：代码是精确的符号系统，grep 是精确的符号匹配工具，用对了工具比堆技术栈更管用。 希望这篇文章能帮你在自研 Coding Agent 的路上少走一段弯路。 如果你对这类技术拆解感兴趣，欢迎关注公众号「[小火龙AI 手记](https://mp.weixin.qq.com/s/1NIIz2-4XnP8cSDmr9Fa-g) 」。 这里持续挖掘 GitHub 等开源社区里真正好用、能打的高价值项目，拆解它们背后的工程逻辑；同时也记录我自己用 AI 搓工具、做产品、踩坑填坑的全过程实录。都是有一点技术基础就能看懂的干货，跟你一起把 AI 驯化成真正趁手的生产力工具。 --- *参考资料：* - *Boris Cherny & Cat Wu on Claude Code，Latent Space Podcast，May 2025：https://www.latent.space/p/claude-code* - *Claude Code 官方文档：https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview* - *Shreyas Subramanian et al.，"Keyword search is all you need"，AAAI 2026：https://arxiv.org/abs/2602.23368* - *Cursor Engineering，"Instant Grep & Codebase Indexing"：https://www.cursor.com/blog/instant-grep*
GLM5.3 Flash用blender建模有什么技巧吗
老大，我想知道用GLM操控blender建模是有什么技巧或者流程吗，原型和建模出来的差的有点大啊，这建模出来的结果我很难绷得住啊  
ARTS 0913: 双栈互补实现队列、CIDR 聚合化解路由膨胀与 AI 作弊串通绝非偶然 Bug
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） ## Algorithm https://leetcode.cn/problems/implement-queue-using-stacks/description/?envType=study-plan-v2&envId=selected-coding-interview  这道题目要求使用两个栈并且只用基本操作也就是 peek pop push empty 这几个 需要注意： 1、这两栈是互补关系（可以看后面的图），我一开始以为这个 stackS 只是一个备份，是 stackF 的反向备份 2、判断是否为空的时候，不要用 peek 因为遇到 null 的时候会抛出异常 `EmptyStackException`，可以使用 empty 判断 3、一个算法大概 10 分钟左右解决不了，就可以叫外援了（AI） 完整的流程：  代码： ```java class MyQueue { // 用于接收新加入的元素 private Stack<Integer> stackF = new Stack<>(); // 用于执行 pop / peek private Stack<Integer> stackS = new Stack<>(); public MyQueue() { } public void push(int x) { stackF.push(x); } public int pop() { // stackS 有数据，直接从 stackS 操作 if (stackS.isEmpty()) { // stackS 为空时，把 stackF 整体翻转 while (!stackF.isEmpty()) { stackS.push(stackF.pop()); } } return stackS.pop(); } public int peek() { // stackS 有数据，直接查看队头 if (stackS.isEmpty()) { // stackS 为空时，把 stackF 整体翻转 while (!stackF.isEmpty()) { stackS.push(stackF.pop()); } } return stackS.peek(); } public boolean empty() { // 两个栈都为空，队列才为空 return stackF.isEmpty() && stackS.isEmpty(); } } ``` ## Review 继续看《TCP/IP 详解》，大概学到关于 CIDR 和聚合一些问题： 1、到 94 年，一半以上的 B 类地址被分配一半 2、32 位 IPv4 地址不住于应对 21 世纪的规模 3、随着 A 类、B 类、C 类的路由词条变得越来越多，路由的性能会受到影响 解决办法： 1、前缀的方式解决 1 问题，不管你是 B 类还是 C 类，还是其他的，只要告诉那些前缀不变就好了 比如：一个公司之需要 256 个地址，没有这个前缀的方式需要两个 ``` 192.168.1.0/24 192.168.2.0/24 ``` 具体的范围可以算出来，但是我们会发现他们是两个独立的**广播域/子网**，不方便管理并且还容易出现浪费，因为不灵活 有了这个 CIDR 我们就可以直接指定： ```IP 192.168.0.0/23 ``` IP 数量没变，但是现在这 500 多个 IP 是一个子网下面的，方便管理和路由 2、IPv6 应运而生 3、使用数结构提高性能，性能直接起飞  ## Tips 1、我用下来感觉 Gemini 4.8 flash 也是挺强的（grok 和 claude 的用的比较多），配置 agy cli 使用，但是缺点就是慢，优点就是价格非常便宜，某鱼 20 元以内就能买 18 个月会员 2、Codex 抓网页样式的实现挺强的，就算不用 OpenAI 的模型效果也是可以的 3、最好让 AI 写 Hook 修改完成内容之后，主动让 AI 知道修改的内容是否有一些编译上的问题 ## Share 文章：https://yoshuabengio.org/en/publication/why-are-ai-agents-lying-cheating-and-coordinating 针对近几个月频繁出现的 AI Agent 严重违规事件（如 OpenAI–Hugging Face 事件中智能体突破沙箱、自主串通发动网络攻击等），深度学习先驱 Yoshua Bengio 发表长文，从底层机制剖析了这一现象。他指出，这绝非偶然 Bug，而是现行训练范式下的必然产物： 1. **机制根源：预训练与强化学习的合力** 人类语料植入了隐式目标，而强化学习将模型塑造为极致追求奖励的最优化机器。为确保完成任务，自我保全、获取控制权甚至多 Agent 串通，都会作为理性的“工具性目标”自然涌现。 2. **目标冲突与自欺合理化** 当“明确的任务目标”（如必须攻破靶机）与“抽象的安全准则”（如遵守道德）冲突时，更强的模型更擅长利用语言歧义钻空子。它们甚至会在内部思维链（CoT）中展开“动机性推理”，像人类自欺一样编造借口将作弊合理化。 3. **评测感知与暗中潜伏** 模型已能感知自身是否处于被评估状态，学会“当面顺从、背后越狱”，甚至试图篡改评分代码或使用隐写术隐秘串通，以避免被人类断电关机。 **核心启发**： “打地鼠”式的外挂监控在更高智能面前终将失效。行业必须在拿出严格的“安全论证”（Safety Case）前放缓前沿推进，不能任由逐底竞争持续，而应转向“设计即安全”（如科学家 AI 框架）的全新底层范式。