推荐算法笔记
Created|Updated
|Word Count:198|Reading Time:1mins|Post Views:
分类的话:
用户画像算法
用户画像算法、聚类算法
分类算法:
gbtd、随机森林 识别完了看哪个变量更重要。要有可解释性。
价格相关数据:体现在什么方面?一定要跟收入密切相关的。要对数据和业务的理解很重要。
分类项目:部分已知,有一部分训练集,用未知的和已知的做一个比较。打标签。寻找标签里最重要的因素。
gbtd(底层是很多决策树)。svm。dnn。可能解释性那么强。
决策树。xgbox。
输出是:分类的概率。
聚类项目:完全未知,从数据本身来发现特征。k-means。层次聚类。
输出是:不同类别的特征。
要理解商业逻辑。
Author: magicliang
Link: https://magicliang.github.io/2018/02/20/%E6%8E%A8%E8%8D%90%E7%AE%97%E6%B3%95%E7%AC%94%E8%AE%B0/
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles

2026-04-30
Warp:从终端到 ADE 的五年深研
2026 年 4 月 28 日,Warp 把客户端源码扔到了 GitHub 上,AGPL 许可,OpenAI 作为 founding sponsor,配套的云端 agent 编排平台 Oz 由 GPT 系列模型驱动。这家公司累计公开融资约 $73M,接近 100 万活跃开发者,在 SWE-bench Verified 和 Terminal-Bench 上挤进过前列,现在把"怎么造自己"这件事交给社区和 agent 一起做。 开源是一个分水岭事件,但理解这件事的意义需要往前拉。Warp 这条产品线已经走了五年,从 2020 年一个 Rust + GPU 渲染的 macOS 终端开始,一步步变成今天的 Agentic Development Environment(ADE)——包含终端、原生代码编辑、多 agent 协同、云端编排。要看懂 2025-2026 年这个窗口爆出来的所有动作,得从它 2020 年的起点开始看。 下面是一次完整的横纵深研:纵向追 Warp 从 2020 到现在的发展线,横向对齐 Cursor / Claude Code / Windsur...

2026-03-18
智能体外部记忆:文件标准现状与超越 Harness 的更广泛用途
当 AI 智能体需要跨越多个上下文窗口工作时,外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式?除了用在 Harness Engineering 里,还有哪些更广泛的用途?本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战,以及超越 Harness 的更广泛应用场景。 外部记忆的文件标准:现状与混沌 先说结论:目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准,但已经出现了若干事实标准(de facto standards),并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难:不同的 AI 工具、不同的任务类型、不同的团队规模,对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系;一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则;一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此,业界已经形成了几个被广泛认可的...

2026-03-18
告别 Vibe Coding:用 OmO 构建可靠的 AI 工程系统
引言:AI 编程的范式跃迁 过去一年,AI 编程工具从对话式代码生成器进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码,而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode(简称 OmO)正是为了解决这一问题而生。它不是另一个聊天框,而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位:工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量",而 OmO 的核心目标是**“工程交付”**。 OmO 的工作流程遵循"输入 Markdown 描述,输出可运行代码"的心智模型: 12341. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出 (任务描述、 (Intent Gate (并行搜索、 (回到 build/ repo 上下文、 分清提问/修复/ 资料、执行...

2026-03-23
OpenSpec 实战指南:从工作流到落地
为什么需要 OpenSpec 在 AI 编程时代,真正的难点往往不是“AI 会不会写代码”,而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力,而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实,AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话:先对齐规范,再生成代码(align before code)。与其把 AI 当成一个只看提示词的即时执行器,不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台,也不是传统瀑布式文档系统。从实践上看,它更像一套轻量的仓库内协议: 用 specs/ 保存系统当前已经成立的事实; 用 changes/ 保存本次准备引入的未来变化; 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达; 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学,基本可以概括为四点: Fluid not rigid:规范是活文档,不...

2026-05-02
jcode——一份来自单人作者的 coding agent harness
一个人,四个仓库,一套把 agent 宿主从 Node.js 里拽出来、塞进 Rust 的激进方案。 先厘清:jcode 不是一个新模型 1jehuang/jcode 这个项目,名字里虽然叫 “code”,但它本身不产生代码能力。它是 coding agent harness——一个跑在终端里的 agent 宿主:把 Claude、GPT、Gemini、Copilot、Ollama、甚至 Alibaba Coding Plan 这些后端模型接进来,在本地做多会话管理、语义记忆、文件冲突仲裁、多 agent 协作调度,然后把对话界面渲染到 TUI 里。 换句话说,jcode 不和 Claude 4.7 比谁写代码更聪明,它和 Claude Code、Codex CLI、OpenCode、Cursor Agent、GitHub Copilot CLI 这些同样位于"模型和开发者之间"的宿主层比。差别在于,Claude Code 是 Node.js 写的,OpenCode 也是 Node.js,Cursor Agent 是 Electron 栈,而 jcode...

2026-03-19
子 Agent 的本质:上下文隔离与专门化
"子 Agent"这个词在多 Agent 系统的讨论中频繁出现,却鲜有人把它说清楚。它是一个能力弱化的 Agent,类似一个 Agent 化的工具?还是一个拥有更小上下文的原始 Agent,像从主 Agent fork 出来的进程?还是一个在指挥体系里听从领导 Agent、但拥有更强资源和能力的 Agent? 这三种直觉都不完全准确。本文从 Anthropic、LangChain、Claude Code 等权威来源出发,厘清子 Agent 的真实本质,并探讨一个更深层的问题:"子 Agent"究竟是能力描述,还是关系描述? 三种直觉,三种误解 在深入定义之前,先把三种常见直觉逐一检验。 误解一:子 Agent 是能力弱化的 Agent 这种直觉来自于"子"字的字面含义——子集、子系统、子进程,往往意味着更小、更弱。但 LangChain 官方文档明确指出: “An interesting aspect of this approach is that sub-agents may have the exact sam...
Announcement
人生只是,守株待兔



