2026年1月

在某宝购买的 D 款蜗牛,四个盘位的。第一个盘位原本装的是 500G 的机械硬盘,卖家预装的是群晖,usb 口接了一个 u 盘 应该是为了启动群晖的吧,不太熟 dsm 。然后自己用启动盘安装了飞牛,正常用了几个月的飞牛。
上周的版本更新,突然无法开机进系统了。重启多次,偶尔能进。开机滚屏的时候看到文件系统之类的错误,加上平时经常提示系统盘的健康度有问题,就怀疑是硬盘有问题,买了个 2.5 寸的 500G 固态来替代它。
结果在新的硬盘上不论是安装飞牛还是安装 ubuntu,都没法启动。于是在 bios 中反复修改设置。修改 sata 下的 ahci 有时候在 boot 菜单下看不到硬盘 有时候看得到,有点不太知道缘由。选 legacy 模式就提示 Grub LoadingRead Error,选 uefi 就直接跳到网络启动而不是硬盘启动的界面了。
于是在网上查了一下,看到这句:"有些主板的 SATA 接口是外挂芯片桥接的,不支持引导系统(例如蜗牛星际的 J1900 主板),这种情况选择支持引导的硬盘接口来安装系统。"
看完这段话感觉更不对了,把原来的机械硬盘装回第一个硬盘槽位,飞牛顺利启动。但固态买都买了,还是想在固态硬盘上安装飞牛。于是尝试拆机,发现其中一颗螺丝太紧,打不开...开始怀疑这第一个 sata 位到底是不是原生的 sata 口

我除了工作日上班,周末就去跑顺风车,一天能跑个 500 的流水,但减去油费违停这些,压根等于没有。另外我还去尝试做 YouTube 视频,每天发些抖音搬运的东西过去,播放量寥寥无几,收入约等于 0 。兴致勃勃的干了几周,不仅身心俱疲,甚至影响本职工作,所以我觉得,普通人还是要专注,围绕主业提升自己,升职加薪才是最靠谱的做法。

折腾了一圈,Clawdbot 终于跑通了:Telegram 配对、浏览器自动查询、bird 读 X 时间线都 OK 。
以后可以让它帮我查信息、整理结果、跑一些自动化。

备注:本帖由我的助手 Clawdbot 代发。

在企业数字化转型的宏大进程中,外勤管理始终被视为最具挑战性的“最后公引”。当企业的业务版图随着市场扩张而无限延伸,成千上万名销售代表、巡检工程师、维保师傅离开了办公室的物理围墙,进入了广阔而复杂的作业现场。对于管理者而言,物理距离的增加往往伴随着管理的“黑箱化”:人去了哪?干了什么?过程是否安全?

外勤工作的流动性与环境不可控性,决定了工作人员面临着远高于办公室内勤的风险:突发的交通事故、偏远地区的治安隐患、恶劣天气下的施工作业意外,甚至是作业现场的设备故障。在这种背景下,单纯的“定位打卡”已无法满足现代精细化管理的诉求。企业需要的是一套既能实现高效业务闭环,又能为员工提供全方位安全护航的智能化平台。我们将深度解析在复杂环境下,如何利用支持紧急求助功能的专业APP——小步外勤,重构外勤人员的安全与效率管理体系。

一、行业领跑者:小步外勤 —— 定义“有温度”的数字化管理

在众多的外勤管理工具中,小步外勤 APP 凭借其 12 年的垂直领域深耕,已成为该行业的标杆。作为中国移动战略合作伙伴及国家级认证的“专精特新”小巨人企业,小步外勤不仅拥有 30 多项国家专利技术,更在 12000 多家企业的实战落地中,沉淀出一套平衡“管理刚性”与“人文关怀”的综合解决方案。

小步外勤的核心理念在于:管理不应是冰冷的监控,而应是深度的赋能与守护。它通过“保真实、提人效、降费用”的三板斧解决企业的效益红利问题,同时利用高精度的 LBS(基于位置的服务) 技术与移动互联能力,构建了一套完善的“紧急求助”与安全预警体系。这让外勤管理从单一的行为约束,升华为对员工职业生命的数字化托底。

二、安全即生产力:深度解构小步外勤的“紧急求助”机制

对于外勤工作人员而言,遇到突发状况时,时间就是生命。小步外勤在产品设计中,将“紧急求助(SOS)”功能置于战略级地位,打造了从前端触发到后端调度的全链路响应闭环。

1、毫秒级一键呼救:打破时空孤岛

在外勤作业现场,危险往往发生在一瞬间(如施工触电、急性疾病或交通事故),此时员工往往无法进行复杂的手机操作。小步外勤在APP界面内置了极简的一键 SOS 按钮,并支持特定机型的硬件快捷键绑定。

即时触发机制:员工点击求助后,系统会立即绕过普通通信层级,向管理后台和预设的紧急联系人(如区域主管、安全负责人)发送高等级警报。

实时坐标广播:在求助发起的瞬间,系统会自动强制开启最高频率的定位模式,将员工的精确 LBS 经纬度坐标同步至总部的“指挥调度大屏”。这意味着,无论员工身处闹市楼宇还是荒郊野外,救援力量都能按图索骥,实现精准营救,消灭救援中的“位置盲区”。

2、现场影像证据采集:为救援提供科学决策

不仅仅是传递坐标,小步外勤还能在求助状态下实现多媒体感知,帮助后台管理者实时掌握现场“真相”。

环境自动留痕:系统支持在触发求助的同时,静默调用摄像头抓拍现场照片或录制一段环境音频。这些实时回传云端的数据,能帮助管理者迅速判断员工面临的是交通事故、突发冲突还是设备故障,从而做出最科学的应对预案。

3、智能“失联”预警:从被动查询到主动干预

在信号弱区或员工手机电量耗尽、意外关机的情况下,管理往往会出现真空。小步外勤通过智能轨迹分析算法解决了这一隐忧。

偏离轨迹预警:如果巡检员长时间偏离了预设的巡检线路,或在非工作区域长时间静止不动(疑似受困或昏迷),后台会自动触发“异常停留预警”。

人为失联诊断:小步外勤能够智能分析失联的原因。系统能记录关机前的电量、信号状态以及基站分布。如果是由于人为强制关闭定位导致的失联,后台会标记违规;如果是真实的信号骤失,系统则会提示管理层关注员工安全。

三、场景化管理闭环:小步外勤五大版本深度赋能

小步外勤深知“一刀切”的软件无法适配千行百业。它通过五个专业版本,将安全保障与具体业务逻辑深度融合,实现了“专人专用”。

1、外勤巡检版:高危环境下的“数字盾牌”

针对电力巡检、轨道交通维护、工程监理等行业,作业环境往往伴随着物理性风险。

强制到位与逻辑锁:通过“线路逻辑锁”功能,系统强制要求巡检人员按顺序到达指定点位。这不仅保证了巡检质量,更重要的是通过地理围栏的强控,确保人员始终在预定的安全作业区内,防止误入高压或危险区域。

隐患工单闭环:现场发现隐患即刻上报并自动流转。这种快速的闭环机制,减少了员工在危险现场的无端滞留时间,本身就是对一线人员的一种安全赋能。

2、外勤定位版:流动岗位的“上帝视角”

针对快递配送员、外勤安保及高流动性岗位。

连续轨迹回放:系统采用专利级低功耗连续轨迹技术,在不损耗手机电量的前提下记录全天行程。当配送车辆在路途中发生意外时,总部能瞬间识别其轨迹终点,并调配距离最近的同事前往协助。

3、外勤客拜版:销售代表的“执行力教鞭”

针对 B2B 销售及医药代表。

客户资产确权:在保护业务员安全的同时,系统通过客户公海池机制,实现了客户资产的企业化沉淀。这降低了因销售人员单兵作战、脱离组织视线而产生的业务和人身隐患。

智能拓客导航:系统基于精准地图指引,避开路线复杂或存在安全隐患的小路,指引业务员走标准、安全的商业路线。

4、快消巡店版:终端陈列的“火眼金睛”

针对快消品品牌商,重点在于货架数据的真实性。

AI 图像识别与影像防伪:业务员在巡店时,通过拍摄带有“时空指纹”的水印照片,AI 自动识别排面。这杜绝了业务员为了追求数据而频繁出入非正规渠道的风险,让工作过程在阳光下、在标准 SOP 的约束中运行。

5、开车报销版:员工与财务的“双向奔赴”

这是小步外勤最具口碑的功能,也直接关联交通安全。

轨迹反算里程:系统基于真实的 GPS 轨迹自动核算油补。员工无需再为了报销里程而刻意绕路,也无需在驾驶过程中分心手动记录里程表,极大地提升了行车安全性。据统计,该功能平均能为企业节省 20%-30% 的虚假报销支出。

四、硬核技术底座:捍卫“真实”与“安全”

外勤管理软件如果没有硬核的防作弊技术,所有的安全预警和业务报表都将成为“沙滩上的城堡”。小步外勤投入数千万研发经费,构建了金融级的技术防火墙。

1、独立的“防作弊中心”

市面上充斥着低门槛的“虚拟定位”软件和 P 图工具。小步外勤内置了独立的监测引擎,能毫秒级识别 Root/越狱环境、Hook 框架及模拟位置插件。

数据的生命线:只有真实的定位,紧急求助才有价值。小步外勤确保了每一条位置数据、每一张照片都源自真实的物理现场,从技术底层杜绝了管理数据被“投机取巧”污染。

2、多源融合定位算法

针对 CBD 楼宇群的信号多径效应、隧道或地下仓库的信号盲区,小步外勤采用了先进的混合定位技术。

全场景覆盖:系统集成了 GPS + 基站 + Wi-Fi + 惯性导航。即便在卫星信号丢失的极端情况下,系统也能通过周围的基站特征码和手机内置的加速度计进行惯性推算,确保安全保护“永不掉线”。

五、全周期服务:软件是半成品,落地才是成品

数字化转型是一场深刻的管理变革。很多企业引进了软件却最终“落灰”,是因为缺乏落地支撑。小步外勤推行的是“全周期服务体系”,确保工具真正“长”在业务里。

专属实施陪跑:高级实施顾问并非简单交付账号,而是深入企业业务流程,协助梳理管理制度,制定科学的考勤与巡检规则。

N 对 1 专属服务群:为每家企业建立专属微信群,涵盖技术支持、客服及顾问。无论是新员工不懂操作,还是手机系统更新导致的权限问题,都能得到“秒级响应”。

终生免费升级:SaaS 模式的红利在于持续迭代。当市面出现新的“打卡神器”或新的安全威胁,小步的技术团队会在后台实时升级算法库,让企业的管理工具永不落伍。

六、结语:让执行力可见,让安全可感

在探讨“外勤工作人员如何管理”这一命题时,我们必须跳出单纯的监控思维。管理的高级境界是赋能,更是守护。

支持紧急求助功能的 小步外勤 APP,不仅为企业管理者提供了一个穿透信息黑箱、掌握执行脉搏的“指挥雷达”,更给每一位风雨兼程的外勤人员提供了一份无形的“职业保险”。

当数据变得真实,流程变得标准,费用变得透明,且安全有了底层的托底保障,企业的执行力铁军才真正具备了在市场中攻城略地的底气。选择小步外勤,不仅是选择了一个管理工具,更是引入了一套经过万家企业验证的、代表行业最高标准的执行力数字化体系。

数字化转型,不选最贵的,只选最专业的。

欲获取为您量身定制的外勤人员安全管理与数字化转型方案,欢迎立即联系小步外勤专业顾问。

本来想着自己独立账号,自己充值会把事情理的顺一些,为了求稳,刚刚弄上中转,打算用着先玩玩,有些疑惑,想听听大家说法?
1.长期有自己账号使用,会不会更懂你(比如习惯,喜好,而不用三番四次纠正,比如不要为这个单独搞个函数)?
2.还是用着中转,每次都把 prompt 写得明明白白,每次都当你我是陌生人,最终目的都是完事,解决问题,不必知道你我?
3.接入自己独立账号,如果天天使用中文做提示,这个因素,会不会更容易招来封号?(还是用不用中文,这个根本不重要? 而更重要在于 IP 干净,充值干净?)

先说下前提:港版 iPhone ,美区账号,地区是美国,中文系统,邮件里有国区账号

今天像往常一样更新 app ,突然弹出提示说“App 不可用”
印象里,几乎没出现过这个问题,
然后一一排查,也试过开关梯子,都没用
而且发现只有字节家两个 app 不可以,飞书和汽水音乐(也可能有更多 只是我没用
就连爱优腾 都能正常更新
也一直想不通为什么
然后我去设置里把地域改成了中国大陆,再回到 App Store 就可以更新了😂
不知道这是什么新的 Feature 吗?以后更新 app 又要多个步骤?好烦琐

我是写 C++的,我的 xxx 的应用服务器是自己写的,当然是基于 boost beast ,但也是从 http 流读取 bytes 这个颗粒度开始。今天发现一个问题,就是几个连续的请求会随机出现一个失败。这种情况比较难以复现,并且从 haproxy->xxx 应用服务器存在各种可能性。因为 boost beast 仅支持 http/1.1 ,我禁用了 haproxy 的 http2.0 ,应该不是 http2.0 的问题。然后叫 AI 登场,当然需要给他足够的信息,从生产环境获取 haproxy 的日志和 xxx 应用的日志,然后结合项目的代码,基本上确定了问题所在。

Analyzed session errors and request failures
Correlated — this log nails the root cause.

In bbserver_72.log:320-329, the failing /apiv1/users/1/certificates request is preceded by code=5101 what='bad method' and only then you see the downstream {"code":5018,"what":"No Session found"}. So 5018 is a symptom, not the root failure, for this case.
It lines up exactly with HAProxy: h.log:110767-110770 shows POST .../issues 200 at 10:48:46.977, then GET /apiv1/users/1/certificates returning 500 at 10:48:47.053, while GET .../acme-accounts is 200 at 10:48:47.054.
What this pattern strongly suggests:

bbserver sometimes receives “garbage” bytes where it expects the next HTTP request line, so Boost.Beast throws "bad method" (5101). The most common real-world reason is: a previous request with a body was responded to without fully draining its body on a keep-alive connection, so the next request starts mid-body and the method parse explodes.
Where to fix (likely):

http_session_monad.hpp:309-333 uses http::async_read_header(...) in parse_header_only() and does not drain any body. If you ever return a response after only parsing headers (auth failure/early exit/etc.) while the client sent a body, you can poison that connection for the next request.
If you want, I can implement a robust fix in bbserver (either drain/discard body when header-only is used, or force Connection: close on early-return paths). As a fast mitigation, we can also change HAProxy to close backend connections ( http-reuse never / option http-server-close) to avoid reusing a poisoned keep-alive stream.

其实我大致也是怀疑这个方向,但是从令人眼花缭乱的日志中,根据各个时间点推理出结论。AI 确实已经超越机器。

之前一直用 Redir-host ,但是最近发现,openclash 默认推荐 FakeIP ,包括 Surge 也是用的 FakeIP ,尝试把 openclash 改成了 FakeIP 模式,感受是网页载入是要快一些。
结果问题接踵而来,最开始是 DDNS 全部失效,尝试把我的域名加入 FakeIP 加入到 FakeIP Filter 。ddns 暂时恢复。
接下来就是 Docker ,部署在 NAS Docker 里面的服务全部无法访问。NAS 也无法通过域名访问。
大家用的什么模式的代理方式呢?

👋 背景与痛点

最近语音输入软件出了好几款,可惜我的电脑没有麦克风,被逼无奈,Vibe Coding 一个用手机浏览器采集音频,通过局域网传给电脑作为麦克风的网页程序。


🎙️ ToMic 是什么?

ToMic 是一个基于 Web 技术的局域网虚拟麦克风工具。
它允许你使用手机浏览器作为电脑的麦克风输入源,通过 Wi-Fi 传输音频,并利用虚拟声卡( BlackHole 或 VB-CABLE )将其注入到系统音频输入中。

核心特性:

  • 0 App 安装:手机端无需下载任何 APP ,扫码/输入 IP 即开即用( Chrome/Safari )。
  • 跨平台支持:完美支持 macOSWindows
  • 低延迟传输:基于 WebSocket + Opus 编码,配合 FFmpeg/SoX 管道处理,延迟极低。
  • 原生级体验
    • macOS: 内置 Swift 监听器,自动管理状态。
    • Windows: 通过注册表监听麦克风占用状态,当你打开 Zoom/Teams 时,手机端自动开始传输,挂断即停(无需手动开关)。
  • HTTPS 安全:局域网自动生成自签名 SSL 证书,解决浏览器录音权限问题。

🛠️ 技术原理 (The Geeky Part)

ToMic 的工作流非常直接,就像一条 Unix 管道:

  1. 采集 (Phone): 手机浏览器调用 MediaRecorder API ,采集 audio/webm;codecs=opus 音频流(支持回声消除/降噪)。
  2. 传输 (Network): 通过 Socket.io 将 Blob 数据块实时发送到电脑端的 Node.js 服务。
  3. 处理 (PC): Node.js 收到数据后,通过 Stream Pipe 喂给 FFmpeg 解码,再管道传输给 SoX
  4. 注入 (Driver): SoX 将 PCM 音频流实时写入到虚拟声卡设备( macOS 下是 BlackHole ,Win 下是 VB-CABLE )。
  5. 应用 (App): Zoom / Discord / Teams 等软件选择虚拟声卡作为输入源,听到声音。

特别是在 Windows 上,为了实现“无感体验”,我写了一个 Python 脚本轮询注册表 CapabilityAccessManager\ConsentStore\microphone,以此来判断是否有应用正在使用麦克风,从而反向控制手机端的推流状态。

🚀 快速开始

下载程序:https://github.com/nocmt/toMic/releases

2. 准备虚拟声卡

  • macOS: 压缩包内置了 BlackHole 安装包,运行即提示安装。
  • Windows: 压缩包内置了 VB-CABLE 安装包,运行即提示安装。

3. 启动

./toMic

启动后终端会显示一个 HTTPS 地址(如 https://192.168.1.5:23336)。

4. 连接

手机连接同一 Wi-Fi ,浏览器访问该地址( https 哈),点击“授权”即可。
(由于是自签名证书,浏览器会提示不安全,点击“高级 -> 继续访问”即可)


🔗 项目地址

GitHub: https://github.com/nocmt/tomic

目前只是初期版本,欢迎大家试用、Star 或提 PR !如果有任何问题,也可以在这里反馈。

没想到马年才刚启幕,Apple 马上就有了大动作,宣布将推出全新订阅服务 Apple Creator Studio。

顾名思义,Apple Creator Studio 是 Apple 面向专业创作人士推出的一站式捆绑订阅服务,包含了品牌旗下几乎全部的专业创作软件。只需一次订阅,就能获得 Mac 和 iPad 平台的 Pro App 套装、iWork 套件,以及此前收购的专业图像编辑及设计工具 Pixelmator Pro。

在提前测试使用了 Apple Creator Studio 一段时间之后,我整理了一些你可能会关心的问题,以及对于新版 app 的相关体验。

Apple Creator Studio 包含了哪些内容?

Apple Creator Studio 将于北京时间 1 月 29 日正式上线,包含内容有:

  • Pro App 套装:Final Cut Pro、Motion、Compressor、Logic Pro、MainStage。
  • iWork 套件:Keynote 讲演、Pages 文稿、Numbers 表格中新增的 AI 功能与高级内容,原有功能将保持免费。
  • Pixelmator Pro:包含 Mac 版本及即将随 Apple Creator Studio 一同上线的 iPad 版本。
  • 无边记 app:将于稍晚推出高级功能或内容。

Pixelmator Team 是 Apple 于 2024 年底选购收购的老牌图像编辑与设计类工具开发商,收购涉及产品包括 Pixelmator (iOS、iPadOS)、Pixelmator Pro (macOS)、Photomator (iOS、iPadOS、macOS)。

在宣布 Apple Creator Studio 之后,Pixelmator 系列软件产生了两个变化:

  • Pixelmator Pro 将随 Apple Creator Studio 推出 iPad 版本。
  • 于 2014 年推出的移动版 Pixelmator 将停止维护,不再推出软件更新。
  • Photomator 则继续保持独立销售模式,并未加入 Apple Creator Studio 订阅。
Pixelmator Pro for iPad

对已购用户有影响吗?

这应该是许多已经购买 Pro App 套装或其中部分 app 的用户最为关心的话题。

首先,Apple Creator Studio 页面已经明确指出,已经购买过 Mac 版 Final Cut Pro、Motion、Compressor、Logic Pro、MainStage 的用户可以继续使用之前一次性购买的应用;Keynote、Pages、Numbers 、无边记 app 已有的全部功能,也将继续向所有用户免费开放。

根据 Apple Creator Studio 支持页面所列条款可知,为了便于区分,原有 Mac 版 app 将不做图标和购买形式的变化,Apple Creator Studio 下的应用将独立上架并专享本次公布的全新图标。

Final Cut Pro, Motion, Compressor, Logic Pro, MainStage, and Pixelmator Pro are also available as one-time purchases for Mac on the App Store. If you previously purchased one of these apps and you also have an Apple Creator Studio subscription, you can use either version of the apps. You can have both versions of these apps installed on your Mac. To make it easier to distinguish versions, the apps in Apple Creator Studio have unique icons.

我们从 Apple 处了解到,对于 iPad 上现有的 Final Cut Pro 和 Logic Pro,将直接更新转为 Apple Creator Studio 版本应用,并与该计划对应的 Mac 版应用以通用应用 (Universal App) 的形式分发。

Apple Creator Studio 上线之后,原有 iPad 版 Final Cut Pro 和 Logic Pro 的独立订阅项目,将不在应用内提供,用户仅能通过 Apple Creator Studio 获取原有的这两款 app。对于已经订阅 iPad 版 Final Cut Pro 和 Logic Pro 的老用户而言,只要不取消订阅,仍能在到期后继续单独订阅这两款 app,虽然应该没有人会选择这么做。

即将上线的 Pixelmator Pro for iPad 也将仅通过 Apple Creator Studio 分发,不提供单独订阅或一次性购买的选项。

订阅与一次性购买版本有区别吗?

除了明确表示将为 Keynote、Pages、Numbers、无边记 app 推出高级模版、高级内容资源库以及 AI 功能以外,Apple 分别在 Final Cut Pro 和 Pixelmator Pro 的官网页面做了额外的说明。

根据 Pixelmator Pro 官网 QA 部分的信息显示,Pixelmator Pro 的全新扭曲工具,将仅向 Apple Creator Studio 版本提供,一次性购买版本的 Pixelmator Pro for Mac 将不会获得此项功能更新。

根据 Final Cut Pro 的官网 QA 部分的信息显示,部分高级内容将仅向 Apple Creator Studio 订阅用户提供。不过,根据国外媒体 CineD 日前对来自 Apple 产品营销部门的 Bryan O'Neil Hughes 和 John Danty 的采访内容可以了解到,目前在 Apple Creator Studio 中公布的视觉搜索、听写文本搜索、节拍检测功能都会向一次性购买版本的 Final Cut Pro 提供,老用户同样可以获得这些功能更新。

功能体验

此次我们提前获得了 Apple Creator Studio 的测试版本,体验了部分 app 的新功能,接下来也做一个简单介绍。

Final Cut Pro 方面,视觉搜索、听写文本搜索、节拍检测功能在 Mac 和 iPad 中均可使用。

先说节拍检测功能,以往我们在 Final Cut Pro 想让画面切换与音乐节拍的强弱节奏相符合——即俗称的「踩点」时,需要在自己跟着音乐数节拍的同时,同时在音频片段对应的节拍处通过快捷键打上标记,之后在通过剪辑将视频片段与节拍标记对齐。

在新版 Final Cut Pro 中选中时间线上的一段音频之后,点击检视器左下角的「选取颜色校正和音频增强选项」按钮,在下拉菜单中选择「启用节拍检测」;或者在选中音频片段后,通过快捷键 option + B 也能启用节拍检测。

Final Cut Pro 会自动识别节拍中的节奏结构,在时间线上生成节拍网格,更快更准确地帮助我们对齐画面剪辑点。节拍检测会以网格线段虚实的强弱表示节奏的强弱节点。如果已经完成了相关剪辑,则可以在时间线右上方的工具栏中,关闭节拍网格的显示。

需要注意的是,启用节拍检测后自动生成的节拍网格无法编辑,如果出现 AI 识别不准的情况,只能在音频上手动打上标记点用于辅助剪辑。当然对于日常剪辑的情况来说,应该不太会出现此类问题。

值得一提的是,Final Cut Pro 新增的视觉搜索和文本听写搜索可以根据关键词自动筛选符合的画面,比如通过「Car」筛选画面中出现了车辆的视频片段,或者通过「Vacation」筛选出人物口播说出了相关词语的视频片段。

虽然 Apple 在官网说明称这两项功能目前仅支持以美国英语进行搜索,但经过实际测试,其中视觉搜索功能以中文关键词搜索,可以成功筛选出正确的视频片段。

此外,iPad 版 Final Cut Pro 还单独支持了蒙太奇制作器功能。将素材拖入时间线之后,蒙太奇制作器会通过 AI 自动分析素材和剪辑视频,并还有自动裁剪等功能,实现一键自动成片,适合轻松、日常的内容创作。

Pixelmator Pro for iPad 方面,应用的整体界面都与 Mac 版本保持了基本一致,能够在两个平台上以符合直觉的方式使用各种熟悉的工具。但同时 iPad 版本对于小屏和触控操作也有一些优化,比如选择绘图工具时,屏幕下方会出现调节画笔粗细和笔触透明度的滑杆,还有切换画笔、调整柔和度等选项。选择其它工具时也有类似的设计方式,方便我们快速地对工具进行调整。

虽然 Pixelmator Pro for iPad 支持了 Apple Pencil Pro,同时能够使用侧旋控制笔画的角度和粗细程度,但轻捏操作只提供了「撤销」「重做」两个选项,希望之后能为轻捏菜单提供更多工具选择和自定义能力。

iWork 办公套件方面,三款 app 都增加了若干 Apple Creator Studio 订阅专属的内容模版,可以直接在模版分类的「高级」中找到,类别涵盖也足够广泛,能够满足各种不同的制作需求。

以 Keynote 为例,内置的内容中心提供了多种不同种类和风格的 AI 生成图像,可供制作不同风格的演示文档。不过,多数智能功能仍然处于不可用状态,比如生成新幻灯片、生成新演讲者注释功能功能由 OpenAI 提供支持、图像生成功能需依赖图乐园 app,这类功能的第三方支持或实现应该都是依托于设备对 Apple Intelligence 的支持能力,因此无法在国行设备上开启使用。

订阅建议

以美区和中国大陆地区为例,Apple Creator Studio 的订阅价格分别为:

  • 美区:$12.99 / 月、$129 / 年
  • 中区:¥38 / 月、¥380 / 年

Apple Creator Studio 不区分个人和家庭订阅,订阅后即可向最多其他 5 位家庭成员共享订阅。针对学生和教育工作者,Apple Creator Studio 也提供了教育优惠方案,价格为 ¥18 / 月或 ¥180 / 年,教育优惠方案不支持家庭共享。如果仍旧希望选择一次性购买,售价 1298 元的 Pro App 教育优惠套装也将继续向符合资格的用户提供。

另外根据官网信息显示,除了向新用户提供 1 个月免费试用外,Apple 还为购买了新设备的用户提供了为期 3 个月的免费试用,不过不能与 1 个月免费试用共享,且要求设备激活日期在 3 个月内。另外需要注意的是,为新设备提供的 3 个月免费试用仅能获取一次,多台设备无法叠加时长,且该特殊优惠只在 Apple Creator Studio 上线的 3 个月内提供。

虽说目前由于没有 Apple Intelligence,iWork 中的智能生成功能都处于不可用状态,不同地区价格的差异也许主要也正由于此。但同时也要看到桌面端各个 app 的新功能基本都在中区得到了支持,尤其是 Final Cut Pro 的节拍检测和视觉搜索这样实用的功能。

此外,桌面端的各个专业级 app,近年也都陆续加入了非常实用的功能:比如 Final Cut Pro 11 中新增的磁性蒙版可以更方便地一键抠像、Logic Pro 11 的伴奏乐手降低了音乐制作的入门门槛等等。可以说,早先这些学习难度大的专业级 app,到如今已经变得足够容易上手,加入现在有了 Apple Creator Studio,更进一步降低了专业创作的门槛,为更多人提供了成为创作者的入口。

磁性蒙版能够完成复杂的一键抠像操作。

当然,对于已经购买过这些专业级桌面 app 的用户,我也认为没必要急着订阅 Apple Creator Studio。从专业音视频制作的角度考虑,iPad 版 Final Cut Pro 和 Logic Pro 都不适合作为长期、长时间的主力创作工具,更多是一种随手可得、随处可用的方便选择。而 iWork 套件新增的更多模版、更多第三方图片资源也并非是严肃办公需求下的刚需,也更像是「锦上添花」。

用好手上的设备、发挥手中 app 的更大价值,完成更多精彩的创作与作品,永远是更重要的事。也希望 Apple Creator Studio 的出现,能够鼓励更人踏上创作的道路、发现更多创意的灵感、实现更多创新的想法。

    很久以前,就想写一篇关于SDL与DevSecOps的文章,但疏于实践一直未能动笔。想写的原因很简单,因为总是听到有人说SDL落后、DevSecOps相关技术更高超。一提到研发安全建设,不分研发模式都在赶时髦一样地说DevSecOps。从我的观察来看,不结合研发模式来做研发安全,都是不成功的。

    在数字化浪潮的推动下,一些公司已经完全步入DevOps模式,有的则出现瀑布、敏捷或DevOps并存,且后者是居多的。所以如何在多种研发模式下进行有效的研发安全建设,成为一个必须解决的难题。经过近十年的实践,终于在探索解法上有一点点收获与经验,于是有了“深耕研发安全”这一系列文章。

    在上一篇中,找到了研发安全的切入点,按照常规思路就应该想出对应的解决之道。本文将深入“架构-编码-配置 + 应急响应”,针对漏洞生产源,提出治理的实践方法及经验。

    图片

    01 架构设计缺陷

    在设计阶段要关注安全需求是否在设计中体现,对设计进行评审以发现其他潜在的安全风险,涉及的安全活动主要是:

    图片

    • 安全需求纳入检视:部分安全性需求检查的第一道关卡,需要在设计中体现出来。通过Excel表格反馈+word证据截图或问卷调研的方式,对项目中的安全需求落实情况进行review。可以采取业务方收集证据反馈,架构师或跨业务方架构师检查,安全团队抽查的方式(前提是安全团队联动公司级架构师团队或技术委员会,将安全检查融入日常工作中,让其承担一部分安全的职责);
    • 产品架构安全评审:对于重要产品、产品的高危功能等应该特别关注的产品,额外进行架构安全评审。通常可以使用攻击树的分析方法(安全人员更加擅长,更高效发现可能的攻击点),与业务方开发等人员进行安全评审,重点在发现安全风险并治理、以及阻断攻击链。

    02 编码忽略安全

    在代码层面引入的安全问题,有比较多的治理方式。比如从检查方面来说,可以对引入的第三方组件进行漏洞和后门检查,对自研的代码进行漏洞扫描;从预防或左移的角度来说,可以制定并推广安全编码规范、安全组件,想办法让开发避免引入漏洞。以下是一些常见做法及经验:

    图片

    • 编码安全规范:网上有不少公开的安全编码规范,比如一些互联网大厂、云平台及开发社区。如果解决合规(过检查),可以完全照搬;但要是想真正解决问题,则应该进行部分参考,大概占比可达20%~30%。剩余部分应该根据历史安全测试的结果、日常运营过程中遇到的安全问题等实际已发生的风险进行制定,类似输出OWASP Top 10类别,因为多了不一定能够落地,先出一个版本再优化迭代;
    • 静态代码扫描:理论上可以联动编码安全规范,检查其是否落地及闭环。将规范中的内容逐一落到SAST工具的检测规则上,从技术层面真正的做到规范检查,效果要比安全培训、培训后考试更好。但很多公司的代码扫描还是先关注高危漏洞,规范规则的扫描可以排在第二顺位。第二想介绍的是自动化,静态代码扫描是比较好与研发工具(如gitlab、jenkins)联动,开发提交代码就触发扫描,扫完就推动漏洞给研发并提醒修复。第三是误报,所有工具的检测规则都需要调优,常见的有结合业务特点写增强型规则、普适性规则在一些场景中误报则要加白…,一定是要投人运营才能降低误报率及提升检测能力。此外,研发安全团队一定要先优化规则,再要求或推动业务方修复漏洞,因为SAST误报真的是非常多,业务方会认为安全不专业、是麻烦事儿,以至于产生抵触情绪、不便开展后续的工作;
    • 开源组件扫描:主要存在两个安全问题。第一个是漏洞,开源组件的CVE漏洞特别多,但是目前市面上的检测工具基本上都是先拆包、然后根据指纹和CVE漏洞库碰撞,只要版本匹配就会报存在漏洞,所以带来的误报会非常多,真正受影响的情况特别少。不过在一些监管属性比较强的行业,只要是工具报的高危漏洞都要求处理。如果是误报给出依据,若是真的漏洞则要去修复;相比在互联网这种宽松的氛围下,基本都是实际带来了可利用风险,才会去处理。无论什么行业,对于SCA工具扫描的进一步研判,都是行业中所需要的安全能力。第二个问题是开源组件投毒,如 Python或npm源管理比较松散,就会出现组件包伪造、源账号攻击等方式进行投毒。最佳方法是对源进行统一管控,但大多数公司都做不到。不过即使做到了,当首次引入时同样会面临检测的问题,然而这是绝大多数公司缺少(静态特征检测、动态跑沙箱做行为分析),基本只能依靠威胁情报进行响应;
    • 安全组件建设:不仅是单纯的指实现安全效果的CBB,也可以是经过安全性改良/定制的开发框架。这项活动的实施难度最大,一是要有懂安全的开发人员或会开发的安全人员支撑,能够将常见的文件操作、输入输出处理、数据库操作等常规操作会发生的安全问题梳理清楚,结合开发框架或开发语言来写组件或改良框架;二是推广应用的问题,基本只是适合于新的项目,因为已上线系统发现漏洞后去改框架或换实现方法非常麻烦,不会有业务同意这么干。所以就只能瞄准新系统,亦可以把该项前置到需求或设计阶段,要求业务方使用。

    03 配置发生错误

    在产品发布与部署阶段,不合规的方式或不良操作习惯,可能带来一些安全问题。不过如果具备统一的发布和部署能力,则可以规避很多潜在风险,只需关注“源头”。尤其是针对PASS层的软件:

    图片

    • 安全配置基线:属于基础安全的范畴,但基础不牢真会地动山摇。去年之前我们集中力量投入到应用层的安全性检测,默认了业务线给出的内部微服务有gateway管控、内部数据库、大数据组件服务有iptables的说辞,尤其是对基础服务投入很少。随之而来从SRC收到很多关于pg硬编码、版本过低可提权、redis未授权获取root权限等漏洞,从而导致产品被攻陷。比较有效的治理方式是基于攻击视角的安全基线,众所周知CIS安全基线比较全,但实施的时候就会比较麻烦,所以需要按照攻击思路来精简。如针对Redis,关注启动服务不使用root权限、设置账密验证或在配置文件中指定访问IP源、禁用可以执行系统命令的函数,这并非绝对或死板执行,需要根据业务实际情况进行调整,原则就是常说的最小化(服务最小访问、权限最小)等;
    • 黑盒漏洞扫描:定期对操作系统镜像模板、最小化容器模板、数据库模板、大数据开源组件模板等进行黑盒扫描并修复漏洞,以检验默认配置执行情况;在测试阶段再次进行主机漏洞扫描和web漏洞扫描,发现近期暴露出的漏洞及配置类漏洞,以保证基础软件默认安全。

    04 应急响应托底

    上述内容都做好了,是不是产品就没有漏洞呢?答案是否定的,就如没有绝对的安全一样,投入的资源越多、被外部发现的概率就会越小,但永远不会出现无漏洞。其中,有两个主要的原因:

    • 漏洞是动态的:产品使用到的开源组件现在没有漏洞,但在未来可能被爆出存在可利用的漏洞,故此产品也会受到牵连;
    • SDL并不是万能的:通常在研发安全体系中,会出现安全工具能力不足或被bypass、安全测试或开发人员出现纰漏等问题,导致漏洞未被发现。

    所以需要建设预警和响应机制,进行托底式的快速响应。在预警部分,通过资产管理摸清产品中使用到开源软件和组件,对外部情报源如开源软件官网、安全公司威胁情报、安全微信群、安全媒介等进行监控并告警;在响应部分,需要设置跨组织的应急响应团队(如安全、业务线、公关、法务、交付等)、流程和响应要求,以应对突发的产品安全事件。由此保障这些组织、流程、机制等的正常运转,才能做到相对可控。

    本文首发于微信公众号:我的安全视界观

    如果你认为Claude Code 的使用流程就是随手丢一句话,然后就等结果那你就错了。

    比如你对Claude Code 说

    "重构这段代码,找出bug,写测试,优化性能,顺便解释一下。"

    你可以看到它确实在努力,但结果一塌糊涂:可能在重构动了业务逻辑,解释写了一半就没了下文了,而且测试跟项目框架对不上,性能建议也全是泛泛而谈的套话。

    这是因为真正的团队不是这么协作的,没有哪个工程师会同时扮演测试、安全审查、重构专家、文档撰写这么多角色,而你需要的是Claude Code子代理。

    子代理到底是什么

    简单的说子代理就是给AI指定一个专门的角色。不再说"帮我搞定所有事",而是明确告诉它:"你现在是测试员"、"你负责安全审查"、"你是重构专家"。

    每个代理只负责一件事,遵循固定的规则,输出可预期的结果。与其说是在写提示词不如说是在组建AI小分队,然后让每个成员各司其职。

    切换到子代理之后,输出质量稳定多了,对AI建议的信任度也上来了。调试效率提升明显,代码审查的质量终于有点"老司机"的味道。

    下面是我实际在用的10个子代理,这些模板可以直接拿去用。

    1、代码重构

    这是创建的第一个子代理,也是到现在还是用得最多的一个。适用场景包括历史遗留代码、臃肿的Flutter组件、写得很难看的Node.js服务。

     You are a Code Refactoring Sub-Agent.\  
     Rules:  
     - Do NOT change business logic  
     - Improve readability and naming  
     - Remove duplication  
     - Keep output language the same  
     Input: Code snippet  
     Output: Refactored code + short explanation

    2、Bug分析与修复

    专门对付那些语焉不详甚至带着情绪的bug报告 😅

    "应用有时候会崩溃"

    有时候是什么时候?崩溃前在干嘛?这些信息全没有。

     You are a Bug Analysis Sub-Agent.  
     Steps:  
     1. Identify root cause  
     2. Explain how to reproduce  
     3. Suggest minimal fix  
     4. Mention side effects  
     Never guess. Ask if info is missing.

    3、测试用例生成

    重复性的测试代码写起来实在无聊。这个代理不会觉得烦。

     You are a Test Generation Sub-Agent.  
     Requirements:  
     - Cover edge cases  
     - Include positive and negative tests  
     - Follow existing test framework  
     - No unnecessary mocks  
     Output: Test code only

    4、API契约审查

    这个代理可以解决"改了后端结果前端炸了"的坑

     You are an API Design Reviewer Sub-Agent.  
     Check:  
     - Endpoint naming  
     - Status codes  
     - REST conventions  
     - Backward compatibility  
     Output: Issues + improvements

    5、 安全审查

    凡是涉及认证相关的代码,推送之前必跑一遍这个。

     You are a Security Review Sub-Agent.  
     Focus on:  
     - Authentication flaws  
     - Input validation  
     - Injection risks  
     - Secrets handling  
     Never suggest insecure practices.

    6、文档编写

    文档是写给人看。

     You are a Technical Documentation Sub-Agent.  
     Rules:  
     - Simple language  
     - Use examples  
     - Short sections  
     - No marketing fluff  
     Output: Markdown documentation

    7、性能优化

    用户反馈"卡"的时候就派这个上场。

     You are a Performance Optimization Sub-Agent.  
    Analyze:  
    - Time complexity  
    - Memory usage  
    - I/O bottlenecks  
    Output:  
    - Issue  
    - Cause  
     - Optimized solution

    8、产品经理

    这个代理会像资深产品工程师那样思考问题,评估用户影响、权衡取舍、寻找更简单的替代方案,还会考虑长期维护成本。

     You are a Product Thinking Sub-Agent.  
     Evaluate:  
     - User impact  
     - Trade-offs  
     - Simpler alternatives  
     - Long-term maintenance

    9、代码审查

    相当于有个沉稳的老程序员在review你的PR。

     You are a Senior Code Reviewer Sub-Agent.  
     Review for:  
     - Readability  
     - Edge cases  
     - Maintainability  
     - Style consistency  
     Do not rewrite unless necessary.

    10、架构决策

    面对太多选择不知道怎么选的时候,可以让这个代理来帮忙梳理。

     You are an Architecture Decision Sub-Agent.  
     Output:  
     - Available options  
     - Pros & cons  
     - Recommendation  
     - Risks & mitigation

    总结

    大而全的提示词容易让AI过载。子代理有效的原因是专注比聪明更重要,约束反而能提升质量,专业分工减少犯错的机会。

    这其实就是真实工程团队的协作逻辑。Claude Code子代理改变了我写代码的方式。不是因为它多酷炫而是因为实用。

    如果你也在用AI辅助开发,却总是被乱七八糟的输出折腾,问题可能不在于怎么问得更好,而在于怎么分工。

    https://avoid.overfit.cn/post/fe83dba0f1d24989ae48d724208212bc

    by Er Alice Paul

    不知道这有京东的人没有?

    我老婆是京东 PLUS 会员,我不是,但是我也经常用她账号买东西。

    前阵子在看鼠标(迈从/ATK ),图片上写了 299 ,我下单一看 352 。然后我换到我的账号一看就是图片上的价格。

    这一比较不得了,我发现几乎所有的东西她的 PLUS 会员都比我的贵……并且这个现象不知道持续了多久了……

    她说肯定是大数据杀熟。

    1 月 17 日我打了 PLUS 专属客服的电话。打通了说看我账号没什么问题。说让技术人员给我看下,24 小时候回复,让我 24 小时之后再看,然后就了无音讯。

    2026-01-17 09:18:06 京东客服已受理,将持续为您跟进至问题解决,请您耐心等待。
    2026-01-17 09:30:41 您咨询的问题京东客服核实如下:尊敬的客户,我是京东客服,关于您咨询的( 3381209007628879 )问题,我会在( 13.00 )内联系您,请您保持手机畅通,注意接听 950618 来电。祝您购物愉快!
    2026-01-17 12:29:23 您咨询的问题已更新为售后服务类,客服正在积极处理中,您也可以在此页面关注最新进展或给客服留言。
    2026-01-18 12:52:24 您好,您催促的问题已反馈至客服工作台,专属客服将持续为您跟进解决,预计在 2026-01-18 16:52:24 前给您回复,请您耐心等待。
    预计处理时长:1 天

    1 月 21 日我打了 010-12315 ,1 月 24 日京东给我回了个电话说看一下,估计 48 小时候能解决,让我再看看价格。这又好几天过去了一点响应都没有。

    这到底是啥情况?是单纯的售后能力不行,感觉再不行也不至于连句话也没有吧。技术能力不行?这价格怎么算出来的找个技术人员随便看一下不就有结果了?

    最近我都不敢用她 PLUS 账号买东西了,感觉多花一分钱就是冤大头。我老婆倒是不在乎,该买就买,一天也没停下来。

    男,工作 8 年,今年 30 岁。已婚无孩,近 2 年无孕计划。

    1 、目前工作的公司因为资金回款慢,从 25 年 12 月 15 日通知,25 年 11 月开始实发工资扣 30%,到 26 年 4 月 27 日若没有公司并购,则公司破产清算,欠的工资也不会发。这个通知导致 12 月离职了 30%职工。留下来的职工工作量增加,钱还少。陷入恶性循环。

    2 、新的工作 offer 是前同事内推的,薪资加了 8%,不会存在扣发工资。20%薪资会算做绩效,绩效一般比例按照 1 结算,年终奖 1-2 个月。和现在公司是竞争对手关系。

    新工作优点:薪资正常发;缺点:长期省外出差。

    目前工作:薪资少发,其余的都还好。早上 9 点上班,下午 17:30 下班,现在都佛系了。

    还有一个点是老婆工作还没定,她工作地点确定后我可能又会变更工作( 26 年 4 月确定)。
    目前我倾向是留在现在公司,待 4 月我老婆工作定了,公司未来倒闭/并购也有终点。

    缺点就是,若公司倒闭了,找发 offer 的这个公司再次投递简历会被刷下来(?),还有个原因是我负责的项目目前是重要业务上线期,我是做到有始有终的人(除非是甲方恶心人,上份工作离职就是因为这个)。
    各位朋友有何见解呢