高友谊

本手册是针对当前 Hexo + Butterfly 主题博客的完整操作指南，涵盖从写文章到上线的全流程。 一、博客项目概览1.1 技术栈 组件 说明 博客框架 Hexo 5.4.2 主题 Butterfly 5.5.4 部署方式 hexo-deployer-git → GitHub Pages 站点地址 https://gao-youyi.github.io/ 本地项目路径 D:\blog\root 源码仓库 本地 Git 管理 1.2 目录结构12345678910111213141516D:\blog\root\├── _config.yml # Hexo 主配置（站点信息、部署、插件）├── _config.butterfly.yml # Butterfly 主题配置（外观、功能）├── package.json # 依赖管理├── scripts/│ └── blogbot.js # 自定义脚本（新建、格式化、发布、提醒）├── source/│ ├─...

1. 这是我的一个自动更新博客测试 结论：可以提醒 要点：11 行动：111 2. 细节11111111 3. 参考1111

1.test

前段时间把一个一直想做的小产品落了地，名字叫 Mini Court 小法庭。 它不是一个特别宏大的项目，说白了就是围绕“生活纠纷裁决”这个场景，做一个能让用户发帖陈述、评论讨论，再由大模型给出初审和复审结果的 MVP。 这篇不准备写成宣传文，而是把当时做这个东西时比较关键的技术和产品决策整理下来，留作后面复盘，也方便以后做类似产品时少走弯路。 1. 先定义产品边界：MVP 到底要解决什么我做这个产品时，给自己定的边界很明确： 要做的 用户发帖陈述纠纷 其他用户评论讨论 基于用户原帖做一次初审 融合评论区观点做一次复审 支持结果分享 留出后台治理能力 暂时不做的 复杂社交关系 长链路 IM 多模型路由编排 复杂推荐系统 付费系统 原因很简单：MVP 阶段最怕什么都想做，最后什么都做不完。 所以我一开始就把核心链路定成： 发帖陈述 → 评论讨论 → Bot1 初审 → Bot2 复审 → 分享传播 只要这条链路是通的，这个产品就算站住了。 2. 为什么这个场景适合 LLM不是所有产品都应该硬套大模型。 我觉得这个场景适合的原因主要有三点： 1. 用户输入天然是开放文本生活...

最近在重新整理实习简历，也顺手把自己的 LaTeX 模板又改了一版。 说实话，我一直挺喜欢用 LaTeX 写简历，不是因为它多高级，而是因为它对版式控制更稳定，尤其对我这种会反复改字段顺序、字间距、项目 bullet 的人来说，比 Word 舒服很多。 但简历这东西，模板永远只是第二位。真正重要的还是内容取舍。 所以这篇我不只放模板思路，也会一起讲讲我现在怎么理解“研究生实习简历”这件事。 1. 研究生实习简历最重要的，不是写全，而是写准很多同学一到研究生，就容易把简历越写越满： 本科经历舍不得删； 研究生科研细节写很长； 课程、技能、奖项全部堆满； 一页放不下就想做两页。 但如果你投的是实习，尤其是算法岗、开发岗、研究型实习，我现在还是建议： 一页纸优先。 因为面试官筛简历时，最想先看到的是： 你是谁； 你做过什么最有代表性的事； 你和岗位匹不匹配。 不是来看你的成长史。 2. 我现在更推荐的一页结构我自己的简历大概会按下面顺序排： 基本信息 教育背景 科研经历 / 项目经历 实习经历（如果有） 竞赛与荣誉 技能补充 如果你偏研究，就把科研放前面。 如果你偏...

我最近又把 LeetCode Hot100 过了一遍。 不是因为它有多神，而是因为到研究生阶段你会发现：算法题这东西，一段时间不碰，手感掉得非常快。尤其是平时做科研、写工程代码比较多的时候，脑子会更习惯“大系统逻辑”，反而不够敏感于题目里的局部结构。 所以这篇不写“我刷了多少题”，只写我觉得真正有用的经验。 1. Hot100 不是题单，是模板训练集很多人刷 Hot100 的方式是： 做一道 过一道 收藏一道 然后下一道 最后刷完了，问他双指针模板是什么、二叉树 DFS 怎么快速写、动态规划怎么定义状态，还是卡住。 这就说明，你刷的是题，不是方法。 我现在更认可的一种说法是： Hot100 的价值，不在于 100 这个数字，而在于它能帮你把高频题型压缩成有限的思维模板。 2. 我会把 Hot100 分成这几类来刷第一类：哈希 / 数组 / 双指针这一类是最适合恢复手感的。 因为它们通常： 代码量不大； 反馈快； 容易建立“看题识型”的感觉。 像这些思路一定要练熟： 两数之和：哈希 三数之和：排序 + 双指针 盛最多水的容器：对撞双指针 移动零：快慢指针 如果这...

这篇文章记录一个我实际接手过的医学数据分析项目。 项目来自一位医学生的毕业设计，主题并不是简单的“跑一个 Cox 回归”或者“画一张 KM 曲线”，而是要把肿瘤患者在医疗路径不同阶段的延迟真正拆开来分析，并且把整套分析流程做成可复现、可扩展、可继续交付的工程化项目。 我最后选择的做法，不是只交一个结果表，而是把它做成了一套完整的 R 分析框架： 上游有数据导入与清洗 中间有阈值搜索、KM、log-rank、Cox 下游有随机生存森林（RSF） 最终还能一键导出论文图件和结果表 对我来说，这类项目真正有价值的地方，不在于“模型多高级”，而在于：你能不能把一个医学问题翻译成一套稳定、清晰、别人接手后也能继续跑的分析流程。 一、这个项目在解决什么问题项目的核心问题其实很明确： 肿瘤患者在不同医疗阶段发生的延迟，是否会影响生存结局？ 这里面被重点分析的延迟有两类： 就医延迟：从症状出现或首次不适，到真正去医院就诊； 治疗延迟：从确诊，到第一次开始治疗。 另外还有一个诊断延迟变量，但在当前版本里，它主要作为协变量进入模型，用来控制混杂，而不是主分析对象。 这个项目最后不是...

前段时间，帮亲戚工厂做了一个很接地气的小项目：流水线零件残缺/异常自动检测报警程序。 说白了，需求并不复杂，但很典型： 产线上零件需要持续过站； 以前主要靠人工盯着看； 一旦出现混料、划伤、锈斑、残缺或异常件，就希望系统能及时报警； 最好还能顺手把结果统计下来，方便后面追溯。 一开始我并没有把它当成“多高大上”的 AI 项目去做，而是把它当成一个真正能在工厂现场跑起来的自动化工具：识别要稳、接线要简单、故障别轻易中断、出现 NG 之后要能直接给 PLC 发信号。 最后做出来的是一套轻量但完整的方案：模板分类防混料 + 缺陷检测 + PLC 报警输出 + 实时控制台面板 + 日志统计。 一、这个项目到底要解决什么问题工厂现场最怕的不是“识别率论文指标不够漂亮”，而是下面这些很现实的问题： 人工目检容易漏检工人长时间盯流水线，注意力会下降，轻微划伤、局部锈斑、错料件都可能漏过去。 不同型号零件容易混料只要上料或周转过程中出一点问题，就可能把 A 型和 B 型零件混在一起，后续装配会出更大问题。 现场节拍固定，系统必须跟得上不是离线跑图片，而是真正跟着产线节拍走，到了时间...