Nuteo Platform v3.5

Nuteo Platform v3.5

Overview Nuteo Platform 是一款面向现代企业的全栈 ERP 系统。3.5 版带来多智能体编排和自主工作流能力——专为需要不仅仅是任务管理的团队设计。 Tech Stack Frontend: Next.js 16 (App Router, TypeScript, Tailwind) Backend: Node.js APIs + Supabase (self-hosted) AI: Ollama + MiniMax-M2.7 / GLM-5.1 (本地 LLM 编排) Database: PostgreSQL via Supabase Infrastructure: Docker, Ubuntu 24.04, Cloudflare Key Features 多租户 SaaS 架构 实时协作 (WebSocket) AI 驱动的自动化流程 自定义工作流构建器 (拖放) 基于角色的访问控制 API 优先设计 Status 🟢 Active Development — 小团队生产就绪 Stack: Next.js · Supabase · Ollama · Docker

2025年5月20日 · nuteo
Go 1.22 至 1.26: 真正重要的变化

Go 1.22 至 1.26: 真正重要的变化

为什么这篇文章同时涵盖四个次要版本 Go 每六个月发布一次。连续阅读四套发布说明不是任何人想要度过下午的方式。但如果你在生产环境中运行 Go,你需要知道发生了什么变化。 本文涵盖 Go 1.22 到 Go 1.26 — 2024 年初到 2026 年初发布的版本。这是两年的语言演进,放在一篇文章里。 Go 1.22: For 循环改变了一切 2024 年 2 月。Go 1.22 中最有影响力的变化不是新包或编译器优化。而是修复了 for 循环处理变量的方式。 在 Go 1.22 之前,这段代码有一个微妙的 bug: var funcs []func() for i := range 10 { funcs = append(funcs, func() { fmt.Println(i) }) } for _, f := range funcs { f() // 打印 9 次 9,而不是 0-9 } 每个闭包捕获相同的变量 i。当你调用这些函数时,i 是 9。每个 Go 开发者至少踩过这个坑一次。 Go 1.22 改变了这一点。 每次循环迭代现在都创建新变量。闭包捕获不同的变量。代码的行为符合你的预期 — 打印 0 到 9。 Go 团队提供了过渡工具,以便你可以检测依赖于旧行为的代码。go vet 可以捕获该模式。但修复本身很干净:如果你的代码看起来正确,它很可能就是正确的。 ...

2026年3月15日 · nuteo
在 Go 中构建 HTTP APIs: Chi vs Fiber vs Gin (2026)

在 Go 中构建 HTTP APIs: Chi vs Fiber vs Gin (2026)

Go 中的框架问题 Go 与网络框架的关系很奇怪。标准库的 net/http 真的很好。你可以使用纯标准库构建生产 API,而不会觉得在和工具斗争。 但大多数团队最终会使用路由库。问题是选哪个。 讨论最多的三个:Chi、Fiber 和 Gin。每个都有不同的理念。吸引不同类型的开发者。 真正的答案:它比你想象的更重要 在深入比较之前,这里有一个令人不安的事实:对于大多数 API,在 Chi、Fiber 和 Gin 之间选择不会对你的应用性能、稳定性或可维护性产生有意义的影响。 路由器是 net/http 之上的薄层。这些库之间的原始吞吐量差异在基准测试中可测量,在生产中无关紧要。你的数据库比你的路由器慢。你的查询设计比 JSON 序列化速度更重要。 这并不意味着选择没有意义。这意味着你应该出于正确的原因做出选择:API 设计、中间件人体工程学和团队熟悉度 — 而不是基准数字。 Chi:极简且与 stdlib 对齐 Chi 将自己定位为一个贴近 net/http 的轻量级路由库。理念:如果你懂 net/http,你就懂 Chi。 r := chi.NewRouter() r.Use(middleware.Logger) r.Use(middleware.Recoverer) r.Route("/api/v1", func(r chi.Router) { r.Get("/users", listUsers) r.Post("/users", createUser) r.Get("/users/{id}", getUser) }) 路由语法清晰。Route 模式将相关处理器干净地分组。中间件链读起来很自然。 Chi 没有内置的 JSON 绑定层。你自带 — 大多数人将其与 go-json 或标准的 encoding/json 配对。这既是优点(你选择依赖项)也是缺点(你必须选择依赖项),取决于你的偏好。 最适合: 想要路由清晰度而不要框架魔法的团队。net/http 兼容性很重要的项目。希望准确了解请求路径中发生什么的 API。 Fiber:Go 对 Express.js 的回答 Fiber 受 Express.js 启发。如果你来自 Node.js,Fiber 会立即感觉熟悉。 ...

2026年2月20日 · nuteo
本地AI:在2026年运行本地LLM

本地AI:在2026年运行本地LLM

为什么2026年要在本地运行AI 每周都有新的AI工具想要你的数据。每月都有关于prompt injection的新闻。每季度都有初创公司收集了太多训练数据。 我自2024年以来一直在运行本地LLM。在2026年,体验与两年前完全不同。曾经需要32GB内存的模型现在可以在8GB上运行。曾经以分钟计算的推理速度现在以每秒token数计算。本地和云质量之间的差距显著缩小。 这不是边缘爱好者的专属了。它是一个合法的基础设施选择。 真正有效的方法 硬件现实检查 2026年运行本地LLM不需要GPU。我这么说是因为我已经在ThinkPad T14上运行集成显卡运行了六个月。结果比GPU设置慢,但足够用于实际工作。 纯CPU推理配合llama.cpp现在可以在现代笔记本电脑上以8-12 tokens/秒处理7B模型。这对于起草、编码辅助和研究足够用了。对于微调或重型批处理不可用。 GPU加速改变一切。RTX 3060(12GB)以20+ tokens/秒运行4位量化的70B模型。M3 MacBook Pro可以轻松处理13B模型。硬件的ROI已显著转变 — 二手3060比Claude Max的一年订阅便宜。 2026年的模型格局 小但强大(7B-13B): Qwen 2.5、Phi-4、Gemma 3B。在消费级硬件上运行。对于编码辅助和快速草稿,通常足够。优势:快速、私密、无速率限制。 中等层级(20B-35B): Mistral Small、Command R+、DeepSeek V3。更好的推理、更长的上下文窗口、更细腻的输出。需要更多RAM或GPU。这是大多数专业用例所在的地方。 大型层级(70B+): Llama 4、DeepSeek R2、Qwen 2.5 Ultra。接近大多数任务的云前沿质量。需要专用GPU或大量云支出。对于大多数用户不值得,除非有特定需求。 我实际使用的技术栈 经过两年的迭代,这是我日常工作中的内容: Ollama作为运行时。它处理模型管理、API兼容性和硬件检测。ollama run命令比我尝试过的任何其他方式都简单。 open-webui作为界面。这是我如果有时间会构建的东西。干净、快速、支持图像上传、内置RAG。 自定义API包装器用于特定任务。我有脚本调用本地API进行代码审查、文档摘要和泰英翻译。它们在计算成本和数据暴露方面代价为零。 隐私论点 这里变得严肃了。 你发送给云API的每个prompt都是一个数据点。一些公司在上面训练。一些被泄露。一些更改条款,蓦然回首你的内部文档就在训练运行中。 本地推理意味着这些都不会发生。你的prompts留在你的机器上。你的文档永远不会离开你的网络。权衡是维护 — 你自己运行技术栈 — 但对于敏感工作,这是值得做的权衡。 实际影响:我对任何接触代码、内部流程或客户数据的内容运行本地。我使用云进行研究和创意工作,以及需要最佳输出的任务。混合方法已成为自然。 仍然不好的地方 在消费级硬件上进行微调仍然痛苦。LoRA有效但需要大量实验才能正确。工具改进了但过程仍适合喜欢调试的人。 上下文窗口管理被低估了。运行128K上下文窗口听起来很棒,直到你意识到它消耗多少RAM以及推理变得多慢。实际上,16K-32K是大多数任务的最佳选择。 多模态模型终于变好了但设置开销仍然很高。如果你需要视觉,云仍然更实用,除非你有特定的合规要求。 底线 本地AI不再是科学项目。它是生产基础设施。问题不是是否可能 — 而是维护成本是否值得你的用例的隐私和成本优势。 对我来说是的。我运行本地两年了,没有回头。但我也不会假装它适合每个人。了解你的工作负载,了解你的硬件,根据实际数字做出决定。 本系列的下一篇文章将涵盖RAG实现 — 将你的文档放入模型中,以便本地AI能够真正推理你的特定上下文。

2026年4月10日 · nuteo
开发基础设施设置

开发基础设施设置

The Stack 从零开始构建的定制开发环境——稳定、快速、完全自托管。 OS: Ubuntu 24.04 LTS Web: Next.js 16, Node.js 22, Hugo 0.146 Container: Docker + Docker Compose AI: Ollama (本地 LLM), MiniMax-M2.7, GLM-5.1 Database: Supabase (自托管 PostgreSQL) Proxy: Cloudflare Tunnel What Runs 10.100.100.8 (办公室服务器): Hugo (静态站点) :3000, Next.js (Web 应用) :3001, Supabase :3002, Ollama :11434 192.168.77.222 (AI 服务器): Ollama + 模型 Key Automation 通过 GitHub webhooks 自动部署 通过 Cloudflare API 自动化 DNS 通过 rsync 备份数据库到 NAS 容器健康监控 Stack: Ubuntu · Docker · Next.js · Cloudflare

2025年4月15日 · nuteo
Web 平台架构

Web 平台架构

The Goal 构建销售"泰式风情"的 Web 平台——文化、生活方式、身份认同——通过真实、非旅游陷阱的内容面向中国和东盟受众。 Approach Content: 泰国视角、真实生活方式、非旅游营销 Language: EN 默认 → TH → ZH (不是反过来) Stack: Next.js 16 (App Router), i18n (zh-CN/en/th), Markdown 优先 Design: 极简、网格、Unsplash 图像 Key Pages /culture → 泰国文化内容 /lifestyle → 现代泰国生活 /design → 数字产品中的泰国美学 /food → 泰国美食(真实的,非旅游的) /travel → 真正的泰国,不只是指南 /blog → 个人视角 /about → 谁在背后 Stack: Hugo · PaperMod · i18n · Markdown

2025年3月10日 · nuteo
Docker Compose Patterns 实际可扩展

Docker Compose Patterns 实际可扩展

Docker Compose 是每个人都推荐但没有人能正确使用的工具。你从 YAML 文件中的三个服务开始。六个月后,你有三十个服务,而你的 docker-compose.yml 变成了一份没有人完全理解但每个人都害怕碰的文件

2026年3月5日 · nuteo