越来越勤劳了,做了一个交易的小产品,即将上线……
20x Max 就是爽……
产品功能:
可以玩模拟盘(crypto/美股);可以自动化跟单;可以手写策略+ai 生成策略+上传 py 文件策略;支持 api 接入;支持 tradingview webhook 。

xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
20x Max 就是爽……
产品功能:
可以玩模拟盘(crypto/美股);可以自动化跟单;可以手写策略+ai 生成策略+上传 py 文件策略;支持 api 接入;支持 tradingview webhook 。

Web 3D 可视化开发中,模型动画、材质质感、渲染扩展性是提升产品体验的关键,但其底层逻辑复杂,如骨骼蒙皮、光照计算,导致开发门槛高、效率低。图扑软件自研 HT for Web(简称 HT)高性能 Web 3D 渲染框架,为 FBX/glTF 模型的骨骼动画、材质切换及自定义 Shader 开发提供完善支持,可大幅降低开发门槛,提升 3D 应用的开发效率与视觉呈现质量。 骨骼动画是复杂 3D 模型动态交互的核心能力。HT 框架通过底层渲染逻辑封装,大幅简化骨骼蒙皮、帧插值、动画调度等复杂流程,开发者可通过标准化流程快速实现模型动画。 设计师可在 3ds Max、Maya、Blender 等主流工具中完成模型构建、骨骼绑定与权重绘制,并编辑关键帧动画(如机械运动、角色行走、设备动作等)。 模型导出需遵循以下规范(确保动画数据完整、加载高效): 动画加载与播放 开发者无需关注底层渲染(如骨骼蒙皮计算、动画帧插值),通过简洁代码即可实现动画,具体步骤如下: 1 创建 3D 视图 初始化视图并挂载到 DOM,为模型加载提供渲染容器。 2 加载模型节点 FBX 与 glTF 仅 modelType 差异,glTF 支持 .gltf/.glb 格式。 3 动画控制 支持播放、暂停、多片段切换,适配所有模型格式。 HT 框架封装了底层骨骼蒙皮、帧插值等复杂计算逻辑,开发者无需编写专业蒙皮算法,即可快速实现专业级 3D 动画,且支持与内置动画系统无缝融合,轻松构建复杂动态场景。 材质是决定模型物理质感与场景氛围的核心要素。HT 提供三层材质体系,并在 FBX/glTF 模型上保持配置逻辑完全统一,具备超强的工程化复用能力。 1 PBR 物理渲染材质(Physicallly-Based Rendering) 2 Blinn-Phong 材质 3 litePhong 材质(HT 自研) 关键参数: 1 材质注册·全局复用 2 普通节点材质设置 普通 3D 节点(如立方体、球体)可直接通过 shape3d.material 绑定材质: 3 FBX/glTF 模型材质设置 FBX/glTF 模型需依赖设计师在建模软件中预留的材质通道(如通道名 body、arm),通过 matDef 为指定通道绑定材质,实现“局部材质修改”: 若多个节点复用同一材质,直接修改材质会导致所有节点同步变化,需通过“复制材质”实现单独修改(以调整透明度为例): Shader(着色器)可突破固定渲染管线限制,HT 支持自定义顶点着色器(Vertex Shader)与片段着色器(Fragment Shader),实现卡通渲染、溶解、辉光等个性化效果,且 FBX/glTF 模型的适配逻辑统一。 格式规范 示例(红色纯色 Shader): 内置变量(无需手动传递) HT 为 Shader 提供丰富内置变量,直接声明即可使用,避免手动传参繁琐,常用变量及作用如下: 通过 ht.Default.setShader 注册 Shader,支持文件路径或代码字符串,同时提供错误调试工具,便于排查问题: Shader 使用-结合材质 自定义 Shader 需与材质绑定,通过 type 指定 Shader 名称 / 路径,同时传递自定义参数(uniform),适配所有模型格式: 通过 uTime(时间)控制纹理采样,实现模型溶解: 1 Shader 代码-溶解核心逻辑 2 材质配置 图扑软件 HT 框架通过封装底层 3D 渲染逻辑,为 Web 3D 开发提供高效、灵活、高性能的解决方案,降低开发门槛,推动 3D 可视化技术在各行业落地。无论是数字孪生、3D 产品展示,还是虚拟仿真等场景,开发者均可基于 HT 框架快速实现专业级三维可视化效果,同时兼顾 Web 端的兼容性与流畅性。随着 WebGL 技术的发展,HT 框架还将持续优化对 glTF 2.0 新特性(如动画片段、顶点颜色)的支持,进一步降低 Web 3D 开发门槛。
系统分析
01 FBX/glTF 模型骨骼动画实现
建模与导出规范

var g3d = new ht.graph3d.Graph3dView();
g3d.addToDOM();
var walkMan = new ht.Node();
// FBX配置(glTF设为modelType: "gltf",url对应.gltf/.glb文件)
var modelJson = {
modelType: "fbx",
url: 'assets/graph3dView/fbx/walk.fbx',
cube: true,
center: true,
playAutomatically: true
};
walkMan.s('shape3d', modelJson);
g3d.dm().add(walkMan); 
var animNames = walkMan.getAnimationNames(); // 获取所有动画名(如["walk", "run"])
// 播放指定动画:参数依次为动画名、速度(1=原速)、起始时间(0=从头播)、循环模式walkMan.playAnimation(animNames[0], 1, 0, 'repeat');
// 暂停动画(按需调用)
// walkMan.pauseAnimation();
// 切换动画(如从行走切到跑步)
// walkMan.playAnimation(animNames[1], 1.2, 0, 'repeat');


02 HT 框架材质系统解析
核心材质类型


材质设置方式
通过 ht.Default.setMaterial 注册材质,支持直接传入配置或 JSON 文件路径,后续可通过名称复用,避免重复编码。// 1. 直接传配置(PBR材质示例)
ht.Default.setMaterial('metalMat', {
type: 'pbr',
metalness: 0.9, // 高金属度
roughness: 0.1, // 低粗糙度(镜面效果)
environmentMap: 'assets/textures/env.jpg'// 环境贴图(增强真实感)
});
// 2. 传JSON文件路径(复杂材质配置,如多贴图)
ht.Default.setMaterial('plasticMat', 'materials/plasticMat.json');
var cube = new ht.Node();
cube.s('shape3d', 'cube'); // 设节点为立方体
// 方式1:用已注册的材质名
cube.s('shape3d.material', 'metalMat');
// 方式2:直接传临时材质配置(不复用)
cube.s('shape3d.material', {
type: 'litePhong',
diffuse: '#409EFF',
emissive: '#1E90FF'
});
g3d.dm().add(cube);var robot = new ht.Node();
robot.s('shape3d', { modelType: 'gltf', url: 'assets/robot.glb' });
// 为通道"body"设metalMat,"arm"设plasticMat
robot.s('matDef', {
"body": "metalMat",
"arm": "plasticMat"
});
// 也可直接传材质配置
// robot.s('matDef', { "body": { type: 'pbr', metalness: 0.8 } });
g3d.dm().add(robot);
4 单独节点材质修改·避免复用冲突// 单独修改节点透明度(FBX/glTF通用)
functionsetNodeOpacity(node, targetOpacity) {
// 1. 获取节点当前材质定义(matDef)
var matDef = node.s('matDef');
// 若节点未自定义matDef,从模型默认配置中获取
if (!matDef || Object.keys(matDef).length === 0) {
matDef = ht.Default.getShape3dModelMap()[node.s('shape3d')].matDef;
}
// 2. 深拷贝材质配置(避免修改原材质)
var matDefCopy = {};
for (var key in matDef) {
// 克隆已注册的材质(ht.Default.clone确保深拷贝)
matDefCopy[key] = ht.Default.clone(ht.Default.getMaterialMap()[matDef[key]]);
// 3. 修改材质参数(设透明)
matDefCopy[key].transparent = true;
matDefCopy[key].opacity = targetOpacity;
}
// 4. 重新绑定材质到节点
node.s('matDef', matDefCopy);
}
// 调用:将机器人模型透明度设为0.6(半透明)
setNodeOpacity(robot, 0.6);
03 HT 框架自定义 Shader 开发
Shader 职责划分

自定义 Shader 实现流程
// Hints: glsl3, bloomSelective
// 顶点着色器(处理顶点坐标)
attribute vec3 aPosition; // HT内置:顶点位置
uniform mat4 uModelViewMatrix; // HT内置:模型视图矩阵
uniform mat4 uProjectMatrix; // HT内置:投影矩阵
voidmain() {
// 计算顶点最终屏幕坐标
gl_Position = uProjectMatrix * uModelViewMatrix * vec4(aPosition, 1.0);
}
// FS(分隔标记)
// 片段着色器(处理像素颜色)
uniform vec4 uColor; // 自定义:颜色参数
voidmain() {
gl_FragColor = uColor; // 设像素颜色
}


Shader 注册与调试
// 1. 按文件路径注册(复杂Shader,如卡通渲染)
ht.Default.setShader('toonShader', 'assets/shaders/toon.glsl');
// 2. 按代码字符串注册(简单Shader,如红色纯色)
ht.Default.setShader('redShader', `
// Hints: glsl3
attribute vec3 aPosition;
uniform mat4 uModelViewMatrix, uProjectMatrix;
void main() {
gl_Position = uProjectMatrix * uModelViewMatrix * vec4(aPosition, 1.0);
}
// FS
uniform vec4 uColor;
void main() {
gl_FragColor = uColor;
}
`);
// 3. 调试:获取Shader编译错误(若报错)
console.log(ht.Default.getShaderErrorLog());
// 4. 监听Shader加载完成(异步加载时用)
ht.Default.handleShaderLoaded = function(name, resource) {
console.log(`Shader "${name}" 加载完成,可使用`);
};
let redMat = {
type: 'redShader', // 指定已注册的Shader名称
renderMode: 'triangles', // 绘制模式(默认triangles,支持lines/points等)
transparent: false, // 是否透明
cullFace: false, // 是否背面裁切(默认false,复杂模型可设为true优化)
// 自定义uniform参数(传递给Shader的uColor)
uColor: [1, 0, 0, 1] // RGBA:红色不透明
};
// 绑定到节点(FBX/glTF通用)
robot.s('matDef', { "body": redMat });
实战案例-溶解效果
// Hints: glsl3
attribute vec3 aPosition;
attribute vec2 aUv; // UV坐标
uniform mat4 uModelViewMatrix, uProjectMatrix;
uniform float uTime; // 时间参数
uniform sampler2D uNoiseTex; // 噪声纹理
varying vec2 vUv; // 传递UV到片段着色器
voidmain() {
vUv = aUv;
gl_Position = uProjectMatrix * uModelViewMatrix * vec4(aPosition, 1.0);
}
// FS
uniform float uTime;
uniform sampler2D uNoiseTex;
uniform vec4 uDissolveColor; // 溶解边缘颜色
varying vec2 vUv;
voidmain() {
// 采样噪声纹理
float noise = texture2D(uNoiseTex, vUv).r;
// 计算溶解阈值(随时间增加,模型逐渐消失)
float threshold = 0.5 + sin(uTime) * 0.3;
// 溶解逻辑:噪声值小于阈值则丢弃像素
if (noise < threshold) discard;
// 溶解边缘:接近阈值的像素设为边缘色
float edge = smoothstep(threshold, threshold + 0.1, noise);
gl_FragColor = mix(uDissolveColor, vec4(1), edge);
} var dissolveMat = {
type: 'dissolveShader',
uNoiseTex: 'assets/textures/noise.png', // 噪声纹理
uDissolveColor: 'rgb(255,85,0)'// 溶解边缘橙红色
};
robot.s('matDef', { "body": dissolveMat });
04 HT 框架技术优势总结
开发效率与工程化能力突出

视觉表现力与场景覆盖全面

模型格式兼容性与一致性强
Web 端性能优化到位
总结

最近天气一下从 25 多度降低到 9 度了
周六万里无云,天气晴朗已经有夏天的感觉了
周末开始沙尘暴,满天都是土,气温 25 度
周一开始下雨,越下越大
整整下了一天一夜,晚上刚才回来的时候还在丢星
回来看下新闻,周围都下雪了
下面用大白话一步步说,跟着做就能装上。 下载安装包 用管理员身份运行(推荐) 选择安装模式: All Users(所有用户,需要管理员权限) → 选好后点 Next。 选择安装位置: 附加选项: 打开 Postman,第一次会让你登录: 发第一个请求: 改请求方式: 保存接口: Postman-win64-7.3.5-Setup.exe是 Postman 接口测试工具 的安装包,专门用来调试 API、发 HTTP 请求、测后端接口,做开发、测试、前后端联调都少不了它。一、准备工作
Postman-win64-7.3.5-Setup.exe→ 选“以管理员身份运行”。二、安装步骤
Postman-win64-7.3.5-Setup.exe运行。C:\Users\你的用户名\AppData\Local\Postman三、首次使用与基本操作
https://jsonplaceholder.typicode.com/posts。
解压工具: 安装包下载:https://pan.xunlei.com/s/VOqjjTLTPRGI3eaAMpxdY6Z_A1?pwd=5s6x#,右键下载的【PE工具箱】压缩包 → 选择【解压到PE工具箱】。 运行制作程序: 打开解压文件夹,右键【PE工具箱】→【以管理员身份运行】。 写入U盘: 验证制作结果: 打开【此电脑】,可见原U盘变为空盘,且新增一个名为【EFI】的隐藏分区(部分系统可能不显示)。 一、U盘预处理(NTFS格式化)
二、制作PE启动盘
很长一段时间,我以为成为“更优秀的开发者”就是学更多工具。 更多框架、更多库、更多教程。如果我不持续升级技术栈,我就会感觉自己在落后。 所以我不停地切换,尝试新东西…… 结果呢?我并没有真正进步。 我花了很长时间才明白这个简单的道理: 成长并非来自做更多的事情…… 而是来自对正确的事情理解得更透彻。 你不能跳过 HTML、CSS 和 JavaScript,指望框架能带你一路顺风顺水。 如果你的基础薄弱: 扎实的基础可以消除你之后的大部分困惑。 很多开发者在了解开发环境之前就开始使用框架。 但所有功能仍然在浏览器中运行。 请求、渲染、缓存、DOM 更新……这一切都在你的代码底层进行。 如果你不理解这一层,框架就会感觉像魔法而不是工具。 即使你不是每天刷 LeetCode,你仍然需要结构化思维。 你不需要记住所有东西,但应该理解这些模式: 这种思维方式无处不在,不仅仅出现在面试中。 这就像编写可运行的代码和编写可扩展的代码之间的区别。 框架不是魔法。 了解它们实际的工作内容: 一旦你理解了“为什么”,“怎么做”就变得简单了。 网上很多开发建议都是正确的……但只在正确的上下文中。 在个人项目中有效的,在生产环境可能失败。在创业公司有效的,在企业系统中可能崩溃。 不要问“这个好吗?” 要问:“这个什么时候好?” 不要只是实现需求。 要理解: 这就是开发者和工程师的区别。 大多数人认为 TypeScript 只是添加类型。 其实不是。 它讲述的是: 一旦你习惯了,纯 JavaScript 就会让你觉得有风险。 如果你使用 Next.js,要深入了解,不只是看懂文件夹结构。 理解: 否则,你的应用能跑……但在生产环境中可能会出现不可预测的行为。 工具使用不当会浪费大量时间。 掌握: 这些工具每天都在使用。 这里的小改进累积起来的速度比你想象的要快得多。 大型任务让人感到压力巨大。 但它们中的大多数只是许多小问题的组合。 将它们分成: 这项任务变得容易多了。 你也会更快地看到进步。 一次解决一个问题,事情就会开始好转。 只要理解代码的功能,复制代码是没问题的。 问题出在盲目复制上。 后来,当出现 bug 时: 这就是为什么小 bug 会演变成漫长的调试过程。 写出巧妙的代码会让人感觉很好。 但之后,它就变得难以阅读、调试和修改。 大多数代码被阅读的次数比编写的次数多,因此从长远来看,可读性总是更重要的。 巧妙的代码能让人眼前一亮,而易读的代码则能让人受益终生。 一个常见错误是在完全理解问题之前就尝试优化。 先让它工作。 然后让它清晰。 然后只在真正重要时才优化。 过早优化增加了复杂性却没有价值。 几天后回来看你的代码。 如果它让你困惑……那就是反馈。 清晰的代码应该无需费力就能理解。 你不需要记住所有东西。 这项技能不是记忆,而是导航。 你需要知道: 这才是经验的真实面貌。 大多数 bug 并不复杂。 那只是你不知不觉中对自己撒的谎。 调试的过程就是不断证明自己是错的,直到最终回归现实。 看教程很容易感觉高效,因为看的时候一切都说得通。 但真正的理解只发生在你独自面对空白屏幕尝试构建东西时。 如果你从不离开教程,你永远学不会思考。 所以关掉视频,自己动手试试,你肯定会遇到问题卡住,那就是成长的地方。 强行解决问题会让人感觉很有成就感。 但暂时离开往往能更快地解决问题。 不用担心,即使你停止盯着它看,你的大脑仍然会继续运转。 如果你已经卡住几个小时,不要再想了。 经验证明,再往下也很少带来突破,通常只会带来挫败感。 大多数开发者都乐意帮忙的,前提是你已经尝试自己解决问题了。 谁也帮不了你解决“它怎么不起作用”这种模糊的问题。 但他们可以帮忙做这件事: 好的问题不仅能更快地得到答案,还能迫使你更深入地理解问题。 写代码只是开发者工作的一部分。 另一部分是: 在实际工作中,沟通问题比技术问题更容易引发问题。 写代码只是工作的一半,解释它是另一半。 你需要能够描述你在做什么、为什么这样做、存在什么权衡取舍。 这体现在: 清晰的沟通能够防止误解,否则会变成 bug 或浪费时间。 如果你能把复杂的概念用简单易懂的方式表达出来,你在任何团队中都会立刻变得更有价值。 在发布前试图让事情完美通常会拖慢整个流程。 比起本地一个完美的版本,从生产环境中运行的版本中你能学到更多东西。 即使你不是设计师,你仍然可以塑造用户体验。 这些细节比大多数开发者想象的更重要。 因为用户看不到你的代码。 但他们会感觉到。 如果你与你所创造的东西缺乏联系,那么光有技术是不够的。 人们会注意到你真正关心的是产品,而不仅仅是代码。 你不需要表现得过于兴奋,但你需要表现出解决问题的兴趣,而不仅仅是完成任务。 这种态度会让你更可靠、更值得信赖,也更有可能获得更好的机会。 大多数时候,热情会悄然转化为职业发展。 你不需要独自解决所有问题。 一位好的导师可以指出真正重要的事情,帮你节省数月的试错时间。 他们不会给你所有问题的答案,但他们可以帮助你避免一些愚蠢的弯路。 有时是公司里的高级开发人员,有时是网上你很欣赏的人。 向那些已经达到你想达到的高度的人学习。 开源软件能教会你教程永远无法教会你的东西。 你将面对真实的代码库、真实的限制条件,以及真实的人员对你的工作进行审查。 一开始可能会觉得有点吓人,但这正是关键所在。 从小处着手: 随着时间的推移,你会逐渐了解大型系统的实际结构,以及在你自身圈子之外,协作是如何真正运作的。 当你觉得自己“弄明白了”的那一刻,你的速度就开始放慢了。 工具会改变,模式会演变,去年行之有效的方法今天可能就不够用了。 你不需要追逐每一个潮流,但你应该保持灵活。 要勇于质疑自己的习惯,并在出现更好的方法时尝试这些方法。 教学是提升自身理解力最快的方法之一。 当你向别人解释概念时,你会立刻发现自己知识上的不足。 你不需要成为专家才能提供帮助;只要稍微了解一些就足够了。 它迫使你更清晰地思考,同时也让整个生态系统变得更好。 许多优秀的工作之所以不为人知,仅仅是因为没有人谈论它们。 发布你的项目、经验教训或小成就,有助于你随着时间的推移建立声誉。 你不需要“爆红”,你只需要坚持不懈。 人们开始记住你的名字,而机会往往就来自于这种悄然的曝光。 大多数增长并非来自重大突破。 它源于持续不断的小改进。 你不需要了解所有事情, 只需要再每次建造时都多花一点心思。 这就是普通代码如何变得优秀的过程。 也是优秀开发者成长为卓越开发者的过程。 我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。 欢迎围观我的“网页版朋友圈“,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。
1. 掌握基础知识
2. 理解浏览器做了什么
3. 提升数据结构和算法思维
4. 理解框架而不是死记硬背它们

5. 上下文比建议更重要
6. 理解业务
7. TypeScript 不只是关于类型
8. Next.js 不只是“更简单的 React”
9. 正确使用工具
10. 把问题拆成小块

11. 不要复制你解释不了的代码
12. 优先选择可读性高的代码,而不是设计巧妙的代码
13. 不要过早优化
14. 像陌生人一样阅读自己的代码
15. 搜索是一项真正的技能
16. 调试 = 消除错误假设

17. 创造要大于消费
18. 卡住时休息一下
19. 卡住太久就寻求帮助
20. 提出更好的问题
21. 沟通是工作的一部分

22. 学会清晰地解释你的想法
23. 完成比完美更重要
24. 始终考虑用户体验
25. 对工作表现出热情
26. 寻找导师
27. 为开源做贡献
28. 保持开放的心态去学习新事物
29. 指导年轻开发者
30. 在社交媒体上分享你的作品
最后
AI时代快速构建Wiki知识库 你是否也常陷入这种数字焦虑? ● 知识碎片孤岛化: 公众号、知乎、小红书等各平台的好文章随手收藏保存,却带出一堆乱码插件“小尾巴”,甚至复制都阻止。存了几千条笔记,想写专题时却要在几百个文件夹里反复横跳,知识点互不关联,你的库只是“仓库”而非“大脑”。 ● AI 灵感难寻: 在 ChatGPT、DeepSeek 里的深度对话,对答 2 小时喂出的精华,想找时却得翻烂历史记录,不知在哪个AI,那个对话中,最后莫名丢失。 ● 资料“石沉大海”: 明知电脑里有份重要研报,却怎么也搜不到,知识被永久埋没。知识库越大越难搜,里面塞满了过时的废话和重复的草稿,这种“知识熵增”让你连自己存的资料都不敢全信。 ● 公式架构“解析乱码”: 下了一堆 Markdown 工具,没一个能全面保留数据格式的,比如全数学公式和架构图等。 KNOTA(诺达)来了。 它不只是笔记工具,更是 AI 时代开箱即用的LLM WIKI知识库。 为什么 Markdown 是 AI 工具时代的“黄金门票”? 数据越纯净,AI 越聪明 相比杂乱的 HTML 或封闭的 PDF,Markdown 是纯粹的结构化纯文本。它剔除了冗余干扰,让 AI 不再为解析格式浪费算力,从而将全部性能投射在内容理解上,大幅提升问答准确度。 天然的“结构化基因” 大模型(LLM)在训练时深度学习了海量 Markdown 格式的代码和文档。它通过简单的符号(如 #、-、[])定义了严密的层级。在 AI 眼中,Markdown 不是文字的堆叠,而是清晰的逻辑图谱。 零损耗的“母语”沟通 Markdown 语法高度规范且无歧义,让 AI 能以“直觉”识别重点与权重。使用 Markdown 存储知识,等同于为 AI 提供了一份零损耗的思维导图,实现了与数字生命灵魂层面的无缝对接。 人类要的是漂亮的排版,AI 要的是高效。掌握了 Markdown,就掌握了 AI 时代的知识主动权。 KNOTA 是人和 AI 共同的“终端大脑” 现在的 AI 体验非常割裂:虽然单次交互变快了,实则你长期被迫在不同模型间反复‘喂养’同一份数据,沦为 AI 的搬运工。KNOTA 重新定义了数据流向: 从碎片记录到工业级知识生产的终局方案 1. 全向数据采集:打造纯净的“数字矿产” KNOTA 解决了网页资料“存了就乱”的痛点,确保您的知识库不再是乱码堆叠。 完美格式保留: 系统会完整保留原始文章的富文本格式、代码块、图片及数学公式,并将其转化为最适合 AI 理解的 纯净 Markdown 格式 存入本地。 2. 强大的 Markdown 创作中心 将记录提升为一种结构化的思考过程,实现知识的神经网络化。让你的私有知识库看起来不再像零散的草稿纸,而像是一本专业出版的电子书。 3. 专题 Wiki:AI 驱动的知识自愈系统 KNOTA 独特的专题化组织能力,能将零散文档进一步沉淀为“可问答、编译、AI 实时监控巡检”的结构化知识库。 智能建库模式: 手动创建:用户可自主选择文件夹、根目录笔记或额外本地目录,精确定义知识库范围。 自动发现:只需输入主题关键词,系统即可自动检索全库相关资料,穿透分类和文件夹,自动提取关联知识生成专题 wiki 库。 4. AI 问答:绝幻觉,每一句都有据可查 KNOTA 的 AI 不再泛泛而谈,而是严谨的私有的“领域专家”,它最大的特点是:不胡说。 证据溯源:AI 的每一句回答都带有“数字足迹”。点击证据编号,系统能瞬间穿透文档,精准跳转至原始笔记的具体行号和段落。即便笔记后期经过多次增删,溯源依然精准锚定。 5. 本地数据分析舱 KNOTA 填补了传统笔记工具无法处理结构化数据的空白。 核心底层保障:100% 知识主权 KNOTA 诺达致力于让您的知识不再只是散落的笔记,而是可以持续生长、随时调用的智慧资产。 限量福利领取: 我们现已放出最后1000个永久免费使用名额! 行动指令:扫描上方二维码,添加官方小助理,发送暗号 “Knota”,抢占您的数字资产守护官!名额有限,手慢无。
4 月 20 日,苹果宣布 Tim Cook 将于 8 月 31 日卸任 CEO,并自 9 月 1 日起担任董事会执行董事长(Executive Chair)。现任硬件工程高级副总裁 John Ternus 将接替 Cook 担任 CEO 并加入董事会;自 2011 年 11 月起担任苹果董事长的 Arthur Levinson 将出任首席独立董事(Lead Independent Director)。
Cook 卸任苹果 CEO 本身不算新鲜消息;媒体从去年底起就已做过广泛报道。但作为从 Jobs 手中接棒、带领苹果度过多个关键节点的 CEO,Cook 在苹果未来的角色很难不引起关注。值得注意的是,Cook 即将转任的「执行董事长」一职,是苹果历史上没有出现过的,而相比普通的「董事长」,这个头衔似乎多出了几分「亲力亲为」的意味。
(苹果上一次出现 CEO 转任董事长的情况是在 2011 年:Steve Jobs 于 8 月 24 日辞去 CEO 职务,并于当日当选为董事长,直至六周后去世。)
那么,执行董事长到底是一个怎样的职位,又预示 Cook 怎样的未来职能呢?
首先需要指出,「执行董事长」一职无论在美国联邦法规、美国证券交易委员会(SEC)规则,还是加州(苹果注册地)公司法中都没有明确规定,因此其具体职责范围和设立方式由公司自治。
与此同时,苹果的公司章程(最近一次修订于 2024 年)也没有提到「执行董事长」,只笼统规定:「公司可依董事会酌情决定,设立董事长及/或一或多名首席董事。如设有董事长或首席董事,则其有权主持所有董事会会议,并具有董事会不时订明或本章程订明的其他权利及职责。」可见,苹果章程只是为此次职位变动预留了空间,并未作出具体规定。
不过,执行董事长一职在美国上市公司中并不罕见。根据一项针对标普 1500 指数公司的研究,2003 至 2017 年间设有非 CEO 董事长的公司中,约有四分之一选择了「执行董事长」这一安排;在该研究识别出的执行董事长中,40% 由退任 CEO 转任,相关任命新闻稿中 70% 表示该职位会继续参与战略决策和规划。
但是,这些执行董事长的地位并不「平等」,其职能按照强弱大致可以分为以下几类。
第一类是执行董事长的地位高于 CEO。福特汽车公司的章程规定,公司官员包括执行董事长(且名列最前),而 CEO 在行使职权时须服从执行董事长的指示。该职位目前由福特家族成员、前任 CEO Bill Ford 担任。Bill Ford 自 1999 年起担任董事长,2001 年至 2006 年兼任 CEO,其后主导了三次 CEO 交接,也亲自推动了底特律新园区建设、工会谈判等重要事宜,并继续获发高管层次的薪酬,可谓地位显要。
第二类是执行董事长与 CEO 的地位平行而各有分工。例如 2017 年,陶氏化学与杜邦公司以对等合并方式组成陶氏杜邦公司,原陶氏 CEO 兼董事长 Andrew Liveris 出任执行董事长,原杜邦 CEO 兼董事长 Edward Breen 出任 CEO。按合并公告,两人共同向董事会汇报,Liveris 直接负责材料科学业务,Breen 则直接负责农业和特种产品两项业务。
第三类是执行董事长并不真正参与公司运营管理。例如,半导体封装和测试服务商安靠科技(Amkor Technology)的章程规定,执行董事长是一个可选职位,除主持董事会及股东大会外,具有辅助、咨询、建议公司高管的职能,但其本身并不视为公司高管。事实上,该职位自 2024 年 10 月创始人 James Kim 退休以来一直处于空缺状态。
那么,苹果为 Cook 设置的执行董事长一职,会是哪种模式呢?从先例和现有信息看,采用第二类模式(并行分工)的可能性比较大。
执行董事长经常是美国科技公司 CEO 卸任后的下一站。2011 年,谷歌联合创始人 Larry Page 重新出任 CEO 后,Eric Schmidt 由 CEO 转任执行董事长;2015 年公司架构重组、成立 Alphabet 后,Schmidt 继续担任 Alphabet 的执行董事长,直至 2018 年初卸任,2019 年离开董事会。在执行董事长任上,Schmidt 负责所有业务线的对外事务,并就业务和政策问题向 CEO 和管理层提供建议。
类似地,2014 年甲骨文创始人 Larry Ellison 卸任 CEO 后转任执行董事长,保留了全部软件和硬件工程职能的运营控制权,仅将销售、财务和法律职能委托给两名联席 CEO。此外,2000 年 Bill Gates 将微软 CEO 一职交棒给 Steve Ballmer 后,转任董事长兼首席软件架构师;虽然头衔中没有「执行」字样,Gates 实际上也持续参与微软的高层管理、技术架构和产品战略决策,并在微软与反垄断机构的沟通中发挥核心作用,直至 2014 年卸任。
事实上,苹果已经在公告中指明了 Cook 作为执行董事长的一项重要职能——「与全球政策制定者沟通」。
在担任首席执行官的 15 年间,Cook 与政策制定者建立了极其广泛的联系。在美国,Cook 自上任以来与历届政府都保持直接沟通,议题从奥巴马时代联邦执法与隐私保护的冲突,延伸到特朗普时代在美国本土设厂与持续投资的承诺以及芯片关税等。虽然近来外界对其向特朗普「俯首」的姿态不无批评,但其斡旋在动荡的美国政治环境下,对苹果的稳定运营无疑起到了很大的保护作用。
在中国,Cook 近年一直维持高频访问,面见部长、副总理级别官员,议题涵盖消费者权益保护、在华生产线的维持承诺、《网络安全法》下的数据本地化要求,以及 Apple Intelligence 的监管审批等。
此外,在欧盟,Cook 曾就税务纠纷、反垄断和《数字市场法案》合规问题多次与官员当面沟通。在苹果试图逐步减少对中国依赖的背景下,他也访问过印度和东南亚,探讨当地制造等事宜。
这种与政府高层的持续联系需要多年积累,无法快速转移给新任 CEO。相比之下,John Ternus 是一位资深硬件工程师,此前一直从事产品开发工作,与政策制定者并无重要互动。而在目前复杂的全球监管与贸易摩擦下,政府关系的重要性又格外突出。因此,让 Cook 以执行董事长的名义保留对外职责、而 Ternus 专注于内部运营,可能是目前最务实的选择。
值得指出的是,对于 CEO 转任董事长,历来存在谨慎看法。传统上,公司法理论认为,董事会的职能是缓解公司所有者(股东)和管理者之间因利益和信息不一致产生的优先级冲突(即所谓委托—代理问题),因此应当扮演监督与制衡的角色,与日常经营保持必要的距离。CEO 转任董事长,尤其是以「执行」身份继续保留对公司事务的实际介入,将会打破这种分工。
因此,英国《公司治理准则》自 2003 年起就建议 CEO 不要转任本公司董事长,理由是前 CEO 担任董事长会削弱董事会对其决策的独立监督;ISS、Glass Lewis 等机构投资者顾问也对前 CEO 担任董事长持保留态度,理由是容易稀释董事会的监督独立性,并拖累新 CEO 权威的建立。
现实中,现任 CEO 与转任董事长角色的前任 CEO 发生冲突的案例并不罕见:2022 年,迪士尼董事会解除 Bob Chapek 的 CEO 职务,由前任 CEO、此前转任执行董事长的 Bob Iger 重返 CEO 岗位;同年,星巴克 CEO Kevin Johnson 在劳资压力下宣布退休,前任 CEO、曾任执行董事长的 Howard Schultz 以临时 CEO 身份回归。
诚然,就 Cook 的新角色而言,苹果的表述将其职责限定在政策沟通,看似与日常运营切割得相当清晰。但现实中,尤其是像苹果这样的跨国科技巨头,对外事务与产品及运营决策之间并不存在明确的界限。例如,反垄断合规必然涉及修改 App Store 规则、开放功能接口等决策,AI 与隐私监管的表态会约束服务业务的形态,而关税与供应链政策也会直接影响未来产品规划。
综合起来,与其将「执行董事长」视为董事会框架下的一个固定职务,不如将它看作应对特定过渡需求而设计的一个有用头衔、一种介于董事与高管之间的混合角色,目的是让 Cook 这样具有特殊地位和职能的前任 CEO,能够继续以正式身份参与公司事务。而 Cook 与 Ternus 之间的职权边界与优先级安排,仍将持续是一个开放问题,需要靠苹果接下来的 8-K 申报文件和实际运作情况来回答。
福建户籍,五一想去金门玩玩,dy 刷到自行车可以直接上船一起过去,就想过去环岛
有没有去过的讲讲体验怎么样
明天去办大通证,应该来得及吧
数据库变更流程怎么做更安全?很多团队一开始都是用 Navicat 管数据库,但到了生产环境,很快就会遇到同一个问题:Navicat 适合连接数据库和执行 SQL,却不适合承载生产变更所需的审批、预检、备份、执行控制和回滚追踪。NineData 作为数据库 DevOps 平台,解决的正是这一类生产数据库变更安全问题。本文就结合真实生产场景,聊聊为什么数据库变更不能只停留在客户端操作,而要升级成一条可审计、可回滚、可治理的流程。 很多团队的数据库变更,起点都是 Navicat。 这并不奇怪。对开发、测试、DBA 来说,Navicat 这类数据库客户端足够顺手:连库快、查表方便、执行 SQL 直接、对象管理也直观。问题往往不是工具本身,而是当团队把生产环境的数据库变更也长期建立在“客户端直连 + 人工约束 + 口头流程”之上时,风险会迅速放大。 生产库变更真正可怕的,不是某一次 SQL 写错,而是整条链路没有边界。谁能连生产库,谁能直接执行 UPDATE、DELETE、ALTER,变更前有没有预检,执行前有没有备份,执行中出了问题能不能及时中断,变更后能不能快速定位和回滚,这些问题如果没有平台化承载,迟早会在某个晚上集中爆发。 很多时候,事故并不是从一条危险 SQL 开始的,而是从“这条 SQL 为什么能直接跑到线上”开始的。 先说清楚一点,Navicat 没有问题。 它是一个成熟的数据库客户端,适合做连接、查询、日常开发、轻量管理,很多团队也早就离不开它。真正的问题在于,数据库客户端天然更偏“操作入口”,而不是“流程治理平台”。 如果一个团队的生产变更流程长期是这样的: 那么随着人员变多、系统变复杂、数据库实例变多,这套方式几乎一定会碰到边界。 因为它太依赖人了: 这套模式在团队小、变更少的时候还勉强可用,但一旦进入正式生产环境,数据库变更就不能只是“用什么客户端执行 SQL”的问题,而必须升级成“如何设计一条安全的数据库变更流程”的问题。 数据库事故复盘里最常见的几种情况,其实都很像: 这些问题表面上看是 SQL 问题,实际上是流程问题。 如果数据库变更仍然建立在“谁能连上库谁就能改”的模式上,那么不管换多少更熟练的 DBA、写多少规范文档,都很难从根本上消除风险。真正有效的办法,是把生产数据库的变更权限、执行方式、审核规则、审批链路和回滚能力全部收拢到统一平台里。 这也是 NineData 这类数据库 DevOps 平台的价值所在。 如果把数据库操作分成“日常使用”和“生产变更”两类,那么 Navicat 和 NineData 解决的其实不是同一个问题。 前者更像数据库客户端,解决的是连库和操作效率。 后者更像数据库变更治理平台,解决的是生产环境里谁能改、怎么改、改之前怎么检查、改的时候怎么控制、改完以后怎么追踪。 NineData 的一套比较完整的做法,可以概括成五步。 NineData 在数据库变更实践文档里强调的第一步,就是先把数据源接入统一平台。 这一步的意义,不只是“多了一个页面”,而是把原本分散在各种客户端、跳板机、本地连接配置里的数据库访问入口收拢到一个组织级平台里。这样做之后,至少能带来几个直接变化: 很多团队的问题不是没有规范,而是规范无处落地。数据库一旦仍然依赖个人客户端直连,规范就很容易停留在文档里。只有先把入口收回来,后面的流程控制才真正有机会生效。 NineData 给出的数据库变更流程实践里,有一个非常关键的动作:对生产数据库,直接关闭 SQL Console 的 DDL 和 DML 变更能力。 这一步看起来很严格,但恰恰是很多团队真正需要补上的安全边界。 原因很简单。只要生产环境仍然允许普通用户在控制台或客户端里直接执行 DELETE、UPDATE、ALTER,那么所有的审批、预检、留痕和备份机制都可能被绕开。数据库变更流程再漂亮,只要还有一个直通生产库的口子,风险就始终存在。 在 NineData 的设计里,普通用户即使能够查询生产库,也不等于能够直接修改生产库。当用户尝试进行变更时,平台会引导其改为提交 SQL Task,把“直接执行”改成“工单化发布”。 这件事的本质不是增加流程,而是把变更从个人动作变成组织动作。 生产环境里的数据库变更,最怕的不是流程多,而是流程散。 很多团队口头上也有审批,但实际上 SQL 可能是这样流转的: NineData 的 SQL Task 正是为了解决这类问题。根据官方文档,SQL Task 覆盖了提交、审批、执行、回滚等完整过程,本质上就是把数据库变更变成一张可追踪、可审计、可回看的工单。 在这个流程里,最重要的变化不是“SQL 换了个地方提交”,而是: 这意味着数据库变更不再散落在客户端、本地文件和聊天工具里,而是开始沉淀为可治理的流程资产。 真正成熟的数据库变更流程,不应该把所有希望都寄托在“出问题后怎么恢复”,而应该先问一句:能不能在执行前就尽量把风险挡下来? NineData 的 SQL 开发规范里,已经把不少常见高危场景做成了可配置规则。NineData典型规则包括: 这类规则的价值非常直接。 比如一条在 Navicat 里看上去“只是想顺手执行一下”的 SQL,如果放到生产环境里,其实可能是高风险操作。客户端很难替你做组织级约束,但平台可以在 SQL 进入执行阶段前先做一轮预检。 也就是说,NineData 解决的不是“怎么让 SQL 执行得更快”,而是“怎么让危险 SQL 尽量没有机会直接落到线上”。 很多公司也有审批流程,但常见问题是审批链路复杂、配置成本高、不同数据库实例很难统一维护,最后流程往往形同虚设。 NineData 在数据库变更流程的实践里,给了一个很实用的设计,就是把 Data Source Owner 作为审批角色纳入流程。这样每个数据源可以绑定对应 owner,发起 SQL Task 时,系统能够自动带出对应的数据源负责人作为审批人之一。 这个设计的好处很明显: 在生产环境里,真正有效的审批不是“多一个点击动作”,而是确保“该负责的人一定会进到流程里”。 很多文章讲数据库流程安全,喜欢写事前预检和事后回滚,但对执行过程本身一笔带过。实际上,真正危险的往往就是执行中的几分钟。 NineData 的 SQL Task 在执行阶段提供了几个很关键的控制点。 首先,任务在执行前默认会备份即将变更的当前数据状态。NineData产品对MySQL、SQL Server、Oracle、PostgreSQL 等类型的数据源都支持自动备份能力。对 MySQL 来说,自动备份覆盖的语法包括: 这意味着平台不是等执行完再想办法,而是在真正写入之前先把可恢复的数据状态保存下来。 其次,执行阶段支持明确的错误处理策略。比如: 再进一步,任务在执行过程中还支持 Pause 和 Terminate。这让执行期不再是完全不可控的黑盒,一旦发现异常,平台可以提供明确的止损动作。 从工程视角看,这一点非常重要。因为生产事故不只是“有没有恢复能力”的问题,很多时候更是“能不能在损失扩大之前停下来”的问题。 一个很常见的场景是,业务团队需要在生产库里修正一批订单状态。 如果沿用传统方式,往往是开发先在 Navicat 里连上生产库,把 SQL 写好,找 DBA 或负责人看一眼,然后直接执行: UPDATE orders\ 问题在于,这条 SQL 即使最初看起来没有问题,依然会存在几个隐患: 在客户端模式下,这些问题主要靠人判断。 在 NineData 模式下,这条 SQL 会走另一条路径。 先提交为 SQL Task。 平台先做规范预检,检查是否命中规则,例如是否必须使用索引、是否超过影响行数限制、是否属于高风险变更。 预检通过后,再进入审批流程,由业务负责人和数据源 owner 或 DBA 审批。 真正执行前,平台先备份受影响数据。 执行时再根据预设策略决定:一旦报错是终止、继续,还是在 MySQL DML 场景下自动回滚。 如果执行后仍有问题,再通过 Track & Rollback 按时间范围、数据库、表名和变更类型定位具体记录,下载回滚 SQL 做进一步恢复。 同样是一条 SQL,在 Navicat 模式里,它更像一次个人操作;在 NineData 模式里,它变成了一次受控发布。 这就是两者最大的区别。 很多团队在数据库变更中最焦虑的,并不是“会不会写 SQL”,而是“出问题后能不能迅速搞清楚到底发生了什么”。 NineData 的 Track & Rollback 提供的价值,恰恰在这里。 NineData支持按数据源、数据库、表、时间范围和变更类型追踪执行过的语句,支持的变更类型包括: 平台会在预检查阶段自动检查账号权限、Binlog 配置、指定时间范围内 Binlog 文件状态和大小。对 DML,平台可以生成并下载回滚 SQL;对 DDL,平台可以帮助快速定位是谁、在什么时间、对什么对象做了操作,但回滚 SQL 生成目前只支持 DML,不支持 DDL。 这点很关键,因为它意味着 NineData 没有把“回滚”宣传成一个无边界能力,而是把能力边界划得很清楚: 这反而更符合生产环境里的真实需求。真正需要的不是一句“都能回滚”,而是一套清楚、可执行、边界明确的恢复方案。 1. 数据库变更流程为什么不能只靠 Navicat? 因为 Navicat 本质上是数据库客户端,不是生产变更治理平台。它适合连接数据库和执行 SQL,但很难单独承载审批、预检、执行控制、备份、审计和回滚这类组织级能力。生产变更如果只靠客户端,流程很容易依赖人工,风险也更难统一收口。 2. NineData 和 Navicat 的核心区别是什么? Navicat 更偏“连接和操作数据库”,NineData 更偏“治理生产数据库变更流程”。前者解决执行入口问题,后者解决谁能改、怎么改、改前怎么检查、改中怎么止损、改后怎么追踪的问题。 3. 为什么生产环境要关闭 SQL Console 的直接 DDL/DML 变更能力? 因为只要还允许普通用户直接修改生产库,就意味着审批、预检、备份和留痕都可能被绕开。关闭直接变更能力的目的,不是增加操作门槛,而是防止高风险 SQL 绕过流程直接落到线上。 4. NineData 的 SQL Task 解决了什么问题? NineData的SQL Task 把数据库变更从聊天记录和本地客户端里抽出来,变成一张可提交、可审批、可执行、可追踪的工单。这样谁提交、谁审批、谁执行、任务状态如何、执行结果如何,都能留在统一平台里。 6. NineData 如何降低 UPDATE 和 DELETE 误操作风险? NineData 的 SQL 开发规范可以对高风险 DML 做规则约束,例如要求 UPDATE/DELETE 必须带 WHERE、必须命中索引、限制影响行数,并对大规模数据变更做风险检测。这些规则的目的,是尽量在执行前就把风险拦下来。 7. NineData 在执行阶段有哪些止损能力? NineData 支持执行前自动备份当前数据状态,支持执行出错后终止任务、备份失败后停止任务,对仅包含 MySQL DML 的任务还支持执行报错自动回滚,同时执行中支持 Pause 和 Terminate。这些能力能帮助团队在执行过程中及时止损。 8. NineData 能不能做数据库误删后的恢复? 可以分场景看。对 DML 变更,NineData 的 Track & Rollback 支持追踪记录并生成回滚 SQL。对 DDL 变更,例如 TRUNCATE,平台可以帮助定位是谁、何时、对哪个对象执行了操作,但恢复仍需结合事前备份和恢复流程。 9. NineData 适合什么样的团队? NineData产品提供三种灵活交付形态,覆盖从个人开发到企业核心的全场景需求! 数据库变更流程安不安全,从来不是“工具会不会用”的问题,而是“流程有没有边界”的问题。 很多团队早就有 Navicat,也早就有规范文档,但只要生产库还允许通过客户端直接改,只要审批仍然停留在聊天工具里,只要执行前没有预检、备份和止损机制,那么数据库事故就始终只是时间问题。 NineData 的价值,不在于取代所有数据库工具,而在于把生产变更这件事从“直接连库执行”升级成“统一入口、规则预检、审批放行、执行控制、事后追踪”的完整闭环。 对企业来说,真正可靠的数据库变更流程,不应该只回答“怎么改”,还应该同时回答: 这才是数据库变更流程真正变得更安全的起点。 NineData 是玖章算术(浙江)科技有限公司旗下智能数据管理平台,专注于云计算与数据管理基础技术创新,依托云原生架构与 AI 能力,打造覆盖数据库 DevOps、数据复制、数据对比、智能运维等核心场景的一体化数据管理平台,帮助企业在多云、混合云及复杂异构环境下实现更高效、更安全、更智能的数据管理。 NineData 面向企业数据库开发、迁移、同步、治理与运维全流程,提供从研发协同到生产保障的完整能力支撑,助力企业提升数据流转效率、强化数据安全与合规治理,加快数字化升级与全球化业务落地。产品已广泛应用于金融、制造、能源、电力、互联网、医疗健康、跨境出海等多个行业场景。Navicat 适合连接数据库,但不适合独自承担生产变更流程
真正危险的,不是误删本身,而是误删发生前没人拦它
NineData 的思路,不是替代客户端,而是把生产变更从“直接执行”改成“受控发布”
第一步:把数据源纳入统一平台,先收口生产环境入口
第二步:在生产环境关闭 SQL Console 的直接变更能力
第三步:NineData用 SQL Task 承载变更,而不是继续让 SQL 在聊天记录里流转
第四步:把风险前移到执行前,用 SQL 开发规范拦住高危操作
第五步:审批不是装饰,而是要和数据源责任人绑定起来
执行阶段也不能失控,NineData 的价值还体现在“事中控制”
一个更贴近生产环境的场景:从 Navicat 直连,到 NineData 受控发布
SET status = 'closed'\
WHERE updated\_at < '2026-01-01';事后追踪和回滚,NineData 补上的不是一个按钮,而是一条链路
FAQ
SaaS 版 社区版 企业版 核心定位 云上即用,快速上线 本地部署,低成本起步 专属集群,私有化部署 交付形态 官方云托管 Docker 单机/内网部署 客户自有服务器集群部署 环境要求 无安装,需访问云服务 需安装,支持离线运行 需自建,支持内网/隔离网络 数据驻留 云上托管环境 本地或内网环境 企业自有专属集群 能力重点 数据库DevOps、数据复制、数据对比、AI 数据管理 数据库DevOps、数据复制、数据对比 数据库DevOps / 数据复制 / 数据对比 / AI 数据管理 安全与可用性 标准云服务保障 数据本地驻留,轻量部署 数据不出域,多节点高可用 适用客户 个人开发者、小团队、中型企业 开发者、初创团队、教育机构、内网用户 中大型企业及高合规组织 适合场景 快速验证、快速落地 本地测试、离线部署、低成本起步 私有化生产、高安全、长期稳定运行 成本模式 免费使用 / 付费 免费使用 按需授权,商务报价 写在最后
关于 NineData
移动αρρ -底部中间 ai
给灵犀发送:四月的青团真香
領到后去移动αρρ -我的-我的咔劵-去使用。
例如領到 7 亓加赠劵,沖 20 实到 27 。
当前情况:
问题描述:
打开手机网络 4G,必须开关飞行模式才显示 5G,才有网。
导致我现在买早饭,坐地铁,拿快递,付停车费(从锁屏状态打开)都得切一下很烦,等他自己反应过来很慢
比如要部署 deepseek 满血版,总不能用一台跑对吧,那比如有三台 SXM 版的 8 卡 A100 的 GPU 服务器
好奇问一下,想学习学习
我是一个独立 iOS 开发者。 没有团队。 但最近,我连续做了多个 App,而且速度比过去快很多。 原因只有一个: AI 改变了整个开发方式。 以前开发一个 App: 现在变成: 整个过程被极大压缩。 我日常的组合是: AI 在我这里,不是“辅助工具”,而是: 很多以前要查半天的东西,现在直接问 AI。 我不再纠结“这个功能要不要做”。 而是问: 👉 AI 帮我把想法“压缩”。 以前要开 Figma,现在基本不需要了。 流程变成: 效率非常高。 AI 帮我搞定: 原来要花半天,现在 10 分钟搞定。 这一步很多人忽略,但其实最关键。 我用 AI 来做: 开发 + 增长,合成一个闭环。 现在基本固定为: 用 AI 快速搞清楚: 目标是: 只要“能用”,就上线。 不是完美,而是: 上线之后再: 全部继续用 AI 辅助。 我最近做了两个产品: 它们的共同点是: 如果没有 AI,这个速度几乎不可能。 AI 很强,但也有边界: 这些,仍然是开发者的核心价值。 AI 并没有让我变成更强的程序员。 它让我变成了: 而在今天: 如果你是独立开发者: 你不再需要: 你真正需要的是: AI 给的是: 你怎么用,是关键。 我们正在进入一个新的时代: 不是因为工具变了。 而是: 效率被彻底放大了。 我正在持续做: 如果你也在做类似的事情,可以一起交流。 语音记录 App(SpeechNote) 订阅管理工具(DueSight) 2026.04.21 17:56从想法到上线,我几乎不再需要团队
一、我现在是怎么做开发的
没有设计师。
没有产品经理。二、过去 vs 现在
想法 → 开发 → 上线 → 迭代
三、我实际在用的 AI 工具
一整个虚拟团队
四、AI 在开发中的真实作用
1. 写代码(核心)
2. 产品思考
3. UI / UX
描述 UI → AI 给方案 → 直接转 SwiftUI → 调整
4. App Store 上架
5. 内容与增长
五、我的真实开发流程
Step 1:想法压缩
Step 2:快速做 v1
几天内上线
Step 3:尽早上线
可验证
Step 4:持续迭代
六、真实案例
快速做 v1 → 快速上线 → 持续优化
七、AI 做不到的事情
八、最重要的一点
一个更快的执行者
速度,比完美更重要
九、这对普通开发者意味着什么?
杠杆
十、最后
一个人,可以完成过去一个团队的工作
👇 我正在做的事情
📱 我的产品
美区:
https://apps.apple.com/us/app/jingnote/id6759850635
美区:
https://apps.apple.com/us/app/duesight-subscription-tracker/i...
沪·嘉松中路
一张 visa 一张 万事达,都被拒,万事达还被暂时冻结了。。。



今天,OpenAtom openKylin(以下简称“openKylin”)社区正式推送openKylin 2.0 SP2第三次更新升级。本次更新重点针对近期用户反馈较多的软件商店部分软件安装报错、磐石架构-用户模式下装包体验等问题进行优化,涉及系统更新、开明软件包格式、KARE兼容环境、软件商店、不可变系统等多个系统关键模块。另外,在保障系统整体安全和稳定的前提下,为尽量满足用户便捷装包的诉求,磐石架构本次新增了在用户模式下通过dpkg直接安装软件包的功能,将有效提升装包速度。 系统安装与升级方式 主要功能优化及缺陷修复 主要缺陷修复
方式一:从openKylin官网下载最新镜像进行安装(适用于新用户或想重新安装系统的用户);
方式二:前往系统设置—“更新”界面,按提示完成系统更新(适用于已安装旧版本的用户);
方式三:打开维护模式(设置-关于-点击5次UKUI Logo-侧边栏找到维护模式并打开),通过终端运行以下命令进行更新,升级后退出维护模式(适用于开发者):
sudo apt update
sudo apt upgrade
功能优化
【磐石架构】针对dpkg进行改造,在保障安全和稳定的前提下,支持在用户模式通过dpkg命令直接安装或卸载软件包等操作。
【开明软件包格式】新增对固定浏览器插件目录的处理,确保插件能被正确加载;新增对离线包导出功能的支持;优化了Kazam、Gnote、SMPlayer等多个开明版应用在安装后无法启动或运行异常的问题;通过设置GTK_THEME环境变量优化了在不同系统和环境下的界面显示。
【KARE运行环境】新增跨环境文件映射机制、kare试安装(try-install)支持、旧目录迁移等特性;优化终端交互体验、应用覆盖安装后文件拷贝逻辑、软件更新失败处理机制、宿主机驱动挂载时序、应用自更新流程、tini更新机制等。
【系统更新】优化数据迁移功能,提升磐石架构-系统更新的稳定性和用户数据安全性。
【软件商店】修复用户模式下安装分区编辑器失败,报错0003,日志提示依赖解析失败的问题【软件商店】修复用户模式下安装字体管理器提示依赖解析失败0002的问题【软件商店】修复用户模式下安装gimp,报错 0003的问题【软件商店】修复部分用户反馈的在商店更新wps办公软件失败的问题【软件商店】修复用户模式下安装迅雷失败的问题【软件商店】修复用户模式下安装奇安信浏览器报错失败的问题【软件商店】修复用户模式下安装 battle软件失败的问题【软件源】修复无法安装texlive-full论文排版软件的问题【软件源】修复安装tauri font-manager等软件时提示缺少依赖libwebkit2gtk4.1.0的问题【外设支持】修复已安装扫描仪驱动后扫描应用无法识别扫描仪的问题
除了首页时间流和侧栏的精选展位,少数派 Matrix 社区还有很多优秀内容因条件所限无法得到有效曝光,因此我们决定重启 Matrix 周报,并在此基础上添加更多社区内容、作者投稿新玩意呈现给大家。
上周社区速递:派友挑战不沉迷手机的周末、未来视野显示器与 MT6000 路由器
在第 271 期一派讨论《别让它吃灰:你为家里的「淘汰设备」找到了哪些新用途?》中,共有 467 名派友热情参与,十分感谢!

Alsosent(+31) 旧手机改了供电,做了电车导航车机;旧平板改了供电,做了电子相册,配合旧的音响做音乐播放器🥹根本舍不得扔掉。


Keyluces(+30) 变成电子日历。

啊權權權兒(+13) 把 iPhone 6 塞在了相框裡顯示時間,就是一直插著電,電池很容易鼓包,不過換電池倒也便宜和方便。



云中的小白(+13) 文石小白马被我捏爆了,找来了十年前的 KPW3,刷了安卓,装了微信读书。只要下载离线内容,翻页很快,也不怎么卡顿,目前已经作为文石替代品了。比用网页微信读书效果好太多了。

棉花老闆(+10) 用 iPod 听播客。好处有两个方面:一是可以不去碰手机,二是可以玩手机的同时播客声音不被其他软件打断。

碱水结(+7) 现在感觉一开始就得少买,出售和处置(像移动电源就是)也是成本……特别老旧的带屏设备的话有点难强行找用途,眼睛就两只。新的场景也跑不太动或者不太稳定。
噼哩啪啦砰(+4) 初中攒饭钱买的 GBA,最近决定买点套件改个锂电 + 高亮屏。昨天拿出来在太阳底下玩了会儿,决定只改锂电了。
原装的那个 TFT 反射屏才最有味道,哈哈。
记得喝岩浆(+4) 去年家里收拾东西把老豆 20 多年前配的电脑翻了出来,把机箱翻新改造成了 NAS,还有一套不知名的音箱,搭配同样是被翻出来的一台 vivo X9 实现了 AirPlay。
瑞士伯尔尼(+2)
HarryQin(+1) 两部 iPhone 4 拆掉做了装裱。
别的电子产品最后几乎都去了闲鱼,很少有能再重新利用的说法。
📢:下一期的一派讨论是数码圈日经话题《周末挑战赛:来一场春季赛博大扫除》,欢迎来聊。
来自文章 《派早报:低空司回应无人机「起飞难」》:
↳ 💬 关于「7 家电商平台因幽灵外卖被罚没 35.97 亿元」的热议:
宽松回不去(+0) 现在点外卖就找在线下吃过的店/大品牌连锁了,每单价格提升到 17-25 之间 ,都能保证干净,省下的医药费就约等于收入了,毕竟有些外卖那个条件,实在是……
噼哩啪啦砰(+0) 买了摩托以后,看到没环境照片但是想吃的外卖店我都会过去瞅一眼(用练车作为理由驱动自己出门)。很遗憾,大部分店都不太干净……
↳ 💬 关于「Claude Opus 4.7 token 消耗量显著提高」的热议:
Alei(+0) 文言文该复活了。
↳ 💬 关于「谷歌 IPv6 流量占比首次过半」的热议:
HarryQin(+0) 感觉用户端几乎没 IPv6 的说法,倒是商业和运营商方面已经铺开了。
来自文章 《AI 输出中的 ** 是怎么来的:谈中文 Markdown 强调标记的渲染问题》:
haper(+5) 个人感觉加粗、斜体这些文本格式影响还好,代码块、引用等等更是重灾区,经常出现给的回答一半正文一半引用,阅读和复制都是灾难。
话说回来有没有好办法能约束一下🤔,尝试过在 GPT、Gemini 等模型里加自定义 Rule,效果也一般。
来自文章 《你好,我是一名「火腿」》;
dawncold(+2) 核准码不在有效期不要紧,生产设备时那个码是有效的就行。
斯迪(+2) 看到妈妈以为在偷听敌台忍不住笑出了声
来自文章 《「新人报到」手冲咖啡入门指北:如何建立兴趣、建立信心》:
写小黑文的Alex(+6) 1、「当然我也见过拼配罗豆的,美其名曰复古怀旧」,这话有误,其实意式拼配豆配罗豆是基操,增加意式风味,罗豆和阿拉比卡并不是非黑即白的关系,风味不同罢了,不是说有罗豆就是不好。
2、不知道喜欢什么风味的咖啡豆可以从两个极端出发,一个埃塞,就是常见的酸味咖啡,一个曼特宁,就是偏苦的风味,可以试了之后往中间靠。
3、磨豆机比较重要,别贪便宜买砍豆机或者是陶瓷研磨芯的。
4、C40 作为标杆不是因为单一产品有多好,当然也是最早的优秀磨豆机,后来的都是摸着 C40 过河,C40 有先发优势。C40 最大的优势是品控好,就像一把尺子,不同的 C40 磨出来的豆子粒径分布非常接近,这样你买了豆子之后可以按照豆子商家给的推荐刻度和水温得到最佳风味。
5、细粉决定了咖啡风味的感觉是对的。
6、厨房秤最大的问题是没有计时功能,或者有计时的时间不够,一分多钟自己关机了,就很尴尬。
7、xBloom 在火起来之前国内最低的时候两千出头,确实非常出色,甚至可以取代一般咖啡师。
短叶丝兰(+2) 新豆先做冷萃,然后就知道自己手冲冲得有多歪了🥹。
来自文章 《派早报:Canva AI 2.0 发布、Anthropic 发布 Claude Opus 4.7 模型等》:
↳ 💬 关于「OpenAI 升级 Codex,新增多项实用功能」的热议:
xuchunyang(+0) 第一次用 computer use,很惊艳。估计不能有太多交互步骤,不然太费 Token 了,因为每次都需要截图。
keleus(+0) 新版的 Codex 支持纯聊天,不指定项目和工作台的模式了,相当于是 GPT 客户端但工具调用版。
↳ 💬 关于「大疆发布 Osmo Pocket 4 云台相机」的热议:
keleus(+0) 这一代的续航和过热表现提升了,然后智能追踪能力提升了。其他的和 Pocket 3 变化不大,有 Pocket 3 的可以不用升级(虽然其实画面效果也有提升,直出的程度感觉高了)。
星海之心(+0) 等 4 Pro 吧,感觉 Pocket 4 和 Pocket 3 没啥太大区别。
↳ 💬 关于「Apple 钱包支持用支付宝开通 NFC 交通卡」的热议:
HarryQin(+0) 地府通依旧坚挺。
至尊宝宝(+0) 难道兄弟们没有点开看,你添加有几个城市的全国交通卡都是支付宝的选项么……其实只是把原来的充值付费模式更改为支付宝授权委托代扣,先乘车再付款……本质还是 NFC 的交通卡,只是改变了付款方式而已……
来自文章 《城市漫步指南:在沿海宜居小城,过一段不赶时间的日子》:
kitlorovers(+6) 北海强行吃波士顿龙虾也是抽象行为,想起被华强捅的摊主:你瞧瞧这现在哪有瓜呀?这都是大棚里的瓜。
Morris_Xxx(+2) 看到吃波龙有点蚌埠住,堪比在厦门吃海南大金芒。
来自文章 《众测 | 让通勤路上的你「重装简行」:邀你一同体验 tomtoc T77 双肩包》:
诺维好茨基(+7) 我算是一个包包收集爱好者,我现在用书包有以下几个场景:
1. 如果只是上班带饭为了应付安检,我会用一个透明 PVC 包,里面也可以装一点其他东西。
2. 上下班需要背电脑,我会用那种束口的简易双肩包背一个电脑,包里面有多个分隔用于装不同的东西,这个束口袋周末爬山徒步也能用,2-3 天的短途出行也够用了。
3. 3 天以上的出行,2 中的束口包不够用,我会再加一个折叠圆筒包,基本够装 1 个星期的东西。
4. 出门超过 2 天,我会在包里放一个折叠胸包,这样主要行李放在酒店的时候,我可以把随身用品放在这个胸包里。
5. 如果需要带行李箱,我会同时把 2 中的简易双肩包和行李箱一起随身使用,同时把 3、4 中的包放在行李箱里作为拓展和不同场景使用。
6. 同时我还有一个双肩+圆筒两用的包,这个包是众筹的某台湾品牌,但是我基本没怎么使用过。
目前 1、2、3、4 基本覆盖了我 100% 的场景,所以我基本不怎么用行李箱,还是以 2 中的简易束口包为主。我感觉你们可以出一个包含 1、2、3、4 甚至加上 5、6 的一整个箱包解决方案。
anchorrose(+2) 我做过 11 年外勤,每天背双肩包超五小时。最后我留下的是小鹰光线,背板非常舒服,特别是夏天。当然一天就 1-2 小时场景,什么都行。
Taki(+2) 自费购买用户来了。之前用过 T64,对于短途室内通勤场景没什么问题,但是工作性质导致全年超过三分之二的时间都在出差,T77 这包真的极大地缓解了我的容量焦虑。后仓笔记本电脑+iPad+掌机,前仓小件衣物+NuPhy 键盘,tomtoc 自家的配件包+随行小包全部塞进去还绰绰有余,其余零散的配件放在前袋,移动电源和需要快取使用的物件放在左侧口袋。背感也很舒适,塞满东西之后拎着十分重,但是背上后扣上胸部锁扣,长时间背负也不会累。最后就是面料了,这个不用多说了,防水性能一流,也很耐脏。
来自文章 《译文|Tahoe 的图标令人难评》:
鼓手高(+36) 没想到设计教材中所有的禁忌都能完美地在苹果公司推出的最新系统中找到典型。
苹果去年推出的 3 类主要操作系统(iOS 26、iPadOS 26 以及 macOS Tahoe)在我看来,都是用一块液态玻璃,遮住了系统级的交互和设计地狱。
iOS 26,我最明显的感受就是最开始的版本极其粗糙。虽然曾经 iOS 7 和 iOS 11 由于大面积改版也有许多不成熟,但实际体验下来我觉得 iOS 26 的粗糙程度前所未有(我手上有一台 iOS 7.0.4 的 iPod 和一台 iOS 11 的 iPhone X),因为除了 Bug 层出不穷,系统的 UI 和圆角是非常混乱随意的。当然迭代到 26.2 之后稳定性还是值得肯定的。
2013 年,Jony Ive 大刀阔斧推进的扁平化贯穿了 iOS 7-9 时代,极细的字体营造了轻盈的视觉美感。但可读性差成了讨论的焦点,之后苹果不断加大字重,虽然一定程度上影响了美感,却真正解决了易读性问题。iOS 26 呢?超粗的 SF 字体叠加液态玻璃,弱化甚至取消选项栏间的分隔线,成功让易读性重新成为摇摆不定的难题。
iPadOS 26,解放了生产力,窗口自由调整,明面上是这样的。如今 iPad 给了你三个选择:要么用前台调度和多窗口模式激发生产力,要么简单模式别想分屏。可当你拿走键盘鼠标,为触控而量身定制的分屏和 Slide Over 操作设计却忽然不翼而飞了。之前一步到位的拖拽和切换,如今由于「自由」的窗口尺寸,你还得二次调整(Slide Over 虽然回来了但是比以前麻烦多了)。分屏时,由于窗口间 R 角增大,牺牲了很多全屏显示的面积。
此外,把 Mac 的红绿灯和菜单栏加入看起来确实不错,但比小拇指还小的操作界面似乎告诉你:iPad 触屏体验不重要,键鼠才是重点。那要生产力+便携性,我买 MacBook Air 不就好了?作为普通用户,在日常使用场景下,最影响我们的不是窗口大小,而是操作的易懂和便利性。我到现在都搞不懂,为什么那个朴素而优美的旧分屏逻辑没被苹果作为一个选项保留?
macOS Tahoe 在这篇文章中更是把「要打磨的东西不细节,要细节的东西不打磨」体现得淋漓尽致。Mac 作为生产力的代名词,系统居然做成如此混乱不堪,各自搭建 UI 擂台,更别说依旧不统一的窗口 R 角了……
乔布斯在 1983 年的设计大会(IDCA)上曾提到:「我们的设计目标是让产品变得 Intuitively obvious(仅靠直觉也易用)」
苹果多年来也的确开创了一个个先例,深刻影响着设计界语言。
但这一次的「苹果风」,我不敢苟同,我不会希望未来充斥这种视觉大于一切的设计语言。我更倾向于觉得,这一次苹果的尝试,只是走上了自己的独木桥。
来自文章 《开局收获上万差评的游戏:《红色沙漠》为何能这么快翻身?》:
天天忽悠(+7) 虽没玩过红沙,但慢节奏的大世界游戏很难上手这种情况我是深有体会……大表哥 2、巫师 3 这俩游戏买来好几年了,第一章都没打过去。但我也不会轻易给这俩游戏差评。因为很多游戏就是有这么一个先苦后甜的过程,曾经玩死亡搁浅,我背着快递翻山越岭,耐心几乎达到极限,此时终于看到节点城,同时响起 BGM,心态立刻就变了,这种心灵上的冲击无以言表。现在我知道……并不是有些游戏本身有问题,有问题的是我自己,长期快节奏的生活,让我非常难静下心慢慢细品这些慢节奏的游戏。
vevan(+7) 坏消息:付费测试
好消息:测完了他们真改
克莱德(+4) 这应该是今年第一款我想给好评但觉得自己词穷无法完整概括游戏体验的作品。
前面 20 个小时:这什么垃圾剧情主角这句「嗯」真的太搞笑了。
目前 120 个小时了:什么是剧情?我一刀五附伤一拳烈劲法开天辟地……诶等等你看这里有个密室!
来自文章 《一日一技|Liquid Glass 液态变磨砂》:
EVA丫(+8) 打开减弱动态,然后在桌面单独关闭。
真是天才想法。
既减少了动态,又保留了程序切换,返回桌面的效果。
来自文章 《从一夜无眠到夜夜香甜:睡个好觉并不难》:
aaa果女士(+2) 读过类似的书籍《睡眠革命》,对我大有帮助的同时也会定期爆发一些「帮助」失效的时刻。看了作者的睡前 Routine 倒排法我才意识到,我没有把睡前 Routine 这个流程适己化,一味空想「睡前冥想、做流体瑜伽、拉伸运动一会」会彻底改变我的生活。而实际是这些事我睡前根本不会做,导致我真实睡前做的事情和规划完全天上地下两样。难以实施计划导致破罐子破摔熬夜刷手机,从而恶性循环下去。
为了让作者的投稿尽快与广大读者见面,我们调整了《新玩意》栏目中作者投稿部分的呈现方式和周期,作者投稿的「新玩意」后续会迁移至本栏目。投稿渠道与奖励方式仍与以往完全一致,详情参见文末。我们相信新鲜火热出炉的分享更能赢得大家的喜爱,也欢迎广大读者朋友们踊跃投稿。
我平时拍视频主要用到三台设备:iPhone 15 Pro、DJI Osmo Action 4 和 Sony ZV-1 II。我发现 iPhone 和 Action 4 的内置收音表现其实蛮不错的,声音清晰,而且能捕捉到较远处的声源。但 ZV-1 II 的收音就有些差强人意了:声音听起来非常单薄,一旦人离远一点,音量就会变得非常小,几乎听不清(不确定是不是我自己的设置问题,我尝试过把麦克风增益调高一点,但这样杂音也会有很多)。因为我要拍那种 Top-down 视角的桌面内容,这种场景下 ZV-1 II 最合适,所以我就想着买一个外接麦克风。
虽然考虑过专业的机顶麦,但我平时只是随便拍拍,没必要大材小用。看到 DJI Mic Mini 一套只要 500 元,果断入手。
我一般只有一个人录制,其实买一发一收也够了,但考虑到收纳整齐和续航,还是买了两发一收的套装。毕竟丢进充电盒就能随时补电,比起单发版本要放到小底座上才能充电要省事不少。
拿到手后,还没开始用呢,没想到最惊喜的竟然是随附的收纳袋 —— 做工精致厚实,有缓冲的夹层,大小竟然刚好能装下 Action 4 和它自带的电池盒。其实这个麦克风我买来也不会经常带出门去用,但 Action 4 是随身携带的,这下相当于「白赚」了一个运动相机收纳袋。🤣


套装里面还包含一个充电盒、两个发射器(TX)、一个接收器(RX),还有一个 USB-C 转接头和连接相机用的 3.5mm 音频线。这个转接头主要是给那些支持 USB-C 麦克风输入的设备用的,比如现在大多数的手机和电脑。

充电盒方方正正的,比想象中大一些,因为是磨砂质感,握起来很舒服。收纳设计也很用心:接收器即使装上转接头,也能直接放进盒子里,不需要每次拆上拆下。3.5mm 音频线倒是还没找到完美的收纳方式,要么只能堆在收纳袋里,但我的袋子里已经给 Action 4 用了。至于防风毛套,直接安装在发射器上也能收进盒子里,不会挤压变形。毛套附赠了灰色和黑色各一对,如果单独购买白色的发射器,应该会是白色的毛套。



配对的时候我发现,虽然发射器能够通过蓝牙直接连接支持 Osmo Audio 的设备和手机,但蓝牙连接模式存在一定的功能限制。而且,如果发射器已经在蓝牙模式下,想要切回与接收器配对,就需要断开重新配对,放回充电盒并不会自动触发重连。所以其实买「两发一收」还挺好的:可以让其中一个发射器通过蓝牙连接,另一个则专门跟接收器配对。这样切换使用场景时,就不用在那儿反复重连了。
由于 Mic Mini 为了追求轻便去掉了屏幕,所有的详细设置都需要通过手机上的 DJI Mimo App 来调整。如果接收器配对了两个发射器,那么 App 里可以同时调整三个设备的状态。不过什么都要在 App 上面改,有时候就没那么方便。比如虽然发射器上有灯光显示降噪状态,但降噪等级(标准或强降噪)必须在 App 里修改,无法在机身上快速切换。而且如果我想把它当作电脑麦克风使用,必须先插到手机上调好设定,再拔下来连电脑。
音质方面,我不懂太深厚的技术参数,但实际听感明显比设备自带的要出色,尤其是比我那台 ZV-1 II 自带的麦克风好太多,声音很干净,也不用怕我动来动去离相机太远了。
也试过把它接在 PS5 上作为 USB 麦克风使用,表现也完全没有问题。虽然连着转接头插到 PS5 的 USB 接口上时,因为 PS5 的外壳是凸起来的,看起来似乎没有完全插到底,但实际上是能正常收音的。不过有个小提醒:如果你玩游戏时声音是外放的,录制之前要检查一下是不是开启了降噪模式,否则麦克风过滤背景音的算法会让说话声变得很奇怪。

总之,以 500 元的价格来说还是非常满意的😆
MUJI 有什么值得入的平价小物?香味蜡烛应该是其中之一,28 元一大罐,属于 MUJI 最低价的区间,主要是还有一些比较特别的香型,比如我这次入手的「桧木」,由于太冷门了,市面上的蜡烛品牌几乎都没人做这个味道。
桧木是一种扁柏植物,盛产于日本。别说蜡烛了,连香水都很少人做,桧木味道的香水最出名的还是只有川久保玲的「Hinoki」。MUJI 这个蜡烛就当是 28 元买个川久保玲的超平替,这么一想之后 CP 值直接拔地而起。
香味蜡烛的外观就是典型的 MUJI 风格,一个很有重量的咖色玻璃罐子,简洁又不失质感,里面的膏体由大豆蜡、棕榈蜡和香精制成,净含量 85 克。打开玻璃盖子就能闻到明显香味了,再看这款蜡烛的香味描述:
这是 MUJI 官方写的香调,不过现实中很难闻到那么多层次,虽然我个人对香水略有研究,但老实说这罐蜡烛我也只能闻出混合的木质调和柑橘调,整体是沉静的木质香味,其中青柚的味道像一种初夏未熟的青橘,夹杂了清凉的绿意和草本的辛香,莫名让人想起柠檬叶或香茅的味道,喜欢热带风情又不想要太浓郁的朋友有福了,闻起来像到了热带小树林。

使用方法:
静置: 我夜晚放在床头柜上,只是把盖子打开,就可以闻到香味了。
加热: 之前在小红书看到一个说法是香味蜡烛不能点燃,要用融蜡灯,如果没有融蜡灯,可以尝试别的方法达到加热效果:
我感觉前两个方法有点麻烦,就试了第三个方法,放在加热杯垫上加热。说说使用效果,由于加热杯垫是从底部开始加热,可以看到底部的蜡融化时,上部的蜡还没有反应,不确定这是否影响了发挥,我感觉香味扩散并没有小红书上说的那么神奇。
点燃: 回归传统方法,直接点,既然它叫蜡烛,那我们就点它。点蜡烛的香味扩散我感觉比放在加热杯垫上还要好一些,而且省电,只是有一些小小的注意事项:
其实,所有香味蜡烛我都觉得自然状态比点燃状态好闻,所以总的来说香味蜡烛更适合比较有仪式感的人,如果是像我这样的懒人,同价位还是更推荐芳香喷雾。顺便提名这款蜡烛另外几个我觉得好闻的味道吧:
如果你也想分享「新玩意」🔉:
成功入选本栏目还可以得到 108 元的「剁手红包」🧧。如果你有兴趣参与,就赶紧来稿吧!
> 下载少数派 客户端、关注 少数派公众号,了解更多的新玩意 🆒
> 特惠、好用的硬件产品,尽在 少数派 sspai 官方店铺🛒
最近,我们的全新文生图开源模型——ERNIE-Image正式与大家见面了。它基于 8B 参数的 DiT 架构,在复杂指令跟随、文字渲染和结构化图像生成方面表现突出,覆盖了从写实摄影、设计感图像到风格化表达在内的多种视觉风格,因此尤其适合海报、漫画、多面板布局等需要较强控制能力的内容生产场景。 今天,我们带来一篇超友好的ComfyUI实战教程,手把手带你完成 ERNIE-Image 的部署与使用。即使是新手,也能轻松上手! ComfyUI 相关仓库: 魔搭: Huggingface: Comfy Cloud : 工作流下载: https://github.com/Comfy-Org/workflow\_templates/blob/main/templates/image\_ernie\_image.json 安装 ComfyUI 与权重下载 1.1 网页版安装 1.2 客户端安装 下载 ComfyUI 最新版本 v0.19.1 (https://www.comfy.org/zh-cn/download) 1.3 模型权重下载 让 ERNIE-Image-Turbo 在服务器端/本地顺利运行,你需要在 ComfyUI 中正确配置四个核心组件:扩散模型、文本编码器、PromptEnhancer和变分自编码器(VAE)。从 HuggingFace 下载 ERNIE-Image 核心模型权重文件,模型地址: https://huggingface.co/Comfy-Org/ERNIE-Image。 模型权重放置在 ComfyUI 的相应目录下: 将上述四个文件分别放入 ComfyUI 的对应目录后,即可开启 ComfyUI 工作流实践。 标准流工作 当前 ComfyUI 新版本已经支持了 ERNIE-Image 的标准工作流,用户可以直接使用官方推荐工作流来获得最佳画质和速度。 2.1 加载模型节点 在 ComfyUI 中,从左侧模板库选择“Ernie Image Turbo:文生图”或者“Ernie Image:文生图”,系统会自动加载已放入对应目录的核心组件。 如果前述文件已经放入正确位置后,相关模型会自动加载,无需手动配置,直接输入 Prompt,即可启动生图。 需要特别关注的是:当前 PE 节点作为 ERNIE-Image 的默认选项,其使用的加载器和 Text Encoder 加载器都是使用的 CLIPLoader 来加载模型权重。 2.2 PE 设置 ERNIE Image 最适合长、详细、结构良好的提示——更丰富的描述往往会产生更好的生成质量、更精确的教学保真度,以及更忠实地呈现复杂的布局或叙事内容。在实践中,非常建议用户开启 PE,官方节点默认是开启 PE。 PE 节点的参数设置可以通过点击节点图右上角打开子图进一步设置,关键参数配置如下: 2.3 采样器设置 打开子图后,同样可以看到采样器的相关配置项,具体配置推荐如下: 2.4 分辨率设置 ERNIE-Image/ERNIE-Image-Turbo 模型在下列分辨率优化效果比较好,当前避免直接生成 2k+ 分辨率。 GGUF量化版工作流 如果你使用是低显存设备,则需要采样Unsloth给出的 GGUF 量化方案,Unsloth 的 GGUF 量化权重可以从 Huggingface 中下载。 GGUF(Unsloth)相关仓库: https://huggingface.co/unsloth/ERNIE-Image-GGUF https://huggingface.co/unsloth/ERNIE-Image-Turbo-GGUF https://huggingface.co/unsloth/Ministral-3-3B-Instruct-2512-GGUF 首先,你需要在 ComfyUI 中通过 ComfyUI Manager安装 ComfyUI-GGUF 插件。 安装后需要重启服务并刷新页面,从前面的网页中下载需要的的量化模型,放入到 ComfyUI/models/unet/文件夹下。然后双击空白处-> 搜索 GGUF-> 点击 Unet Loader(GGUF),即可使用本地的量化模型;使用 CLIP Loader(GGUF)节点加载文本编码器。 说明:Prompt Enhancer 的 GGUF 版本当前暂未提供。致谢:感谢 ComfyUI 官方对 ERNIE-Image 适配的大力支持。
### 拉取最新的ComfyUI仓库:
git clone https://github.com/Comfy-Org/ComfyUI.git
### 配置ComfyUI运行的环境并安装最新的包含有ERNIE-Image的template:
cd ComfyUI && pip install -r requirements.txt && pip install comfyui-workflow-templates==0.9.56





