Anthropic 今天公布了一个生物学发现:Claude 在噬菌体 DNA 里找到一类以前没人描述过的酶系统,命名为 ART(array-associated reverse transcriptases)。
ART 有三个部分:一个逆转录酶,一个紧挨着它的伙伴基因,一段等间距的 DNA 重复序列,排布很像 CRISPR 阵列。按 Anthropic 的说法,这几个特征同时出现,过去只在少数几个系统里见过,而那些系统都是可编程的,能对 DNA 做剪切、复制和粘贴。目前实验只确认了一件事:ART 阵列会表达成一组彼此独立的短 RNA。它到底是干什么的,还不知道。
过程的数字是这样的:约 950 个 Claude agent 并行跑了 21 小时,用了 2.1 亿 token。它们从 20 多万个逆转录酶里筛出 3500 个新候选,收窄到 20 个,最后挑 1 个送进湿实验。人只参与了两段,开头写 prompt,最后做实验。
这件事的分量在"提出假设"这一环被压缩了。Anthropic 自己估计,这类分析一个资深科学家要做几周到几个月,现在一天之内做完,而且是 950 条线同时查。科研的瓶颈从"找"挪到了"验"。
拿 CRISPR 的历史对照更直观。1987 年,日本团队在大肠杆菌里第一次注意到那串奇怪的重复序列。2005 年前后才有人提出它是细菌的免疫机制,2007 年实验证实,2012 年变成编辑工具。"有人盯着一段怪序列琢磨它是什么"这个阶段,当年是按十年算的。ART 把"注意到"缩短到了一天,后面的功能解析和工具化还得靠实验一步步走。
这份报告写得相当克制,这一点也值得看。功能未知、工作还在进行、提前发布是为了展示能力,这些都是 Anthropic 自己写的。张锋的评价是"值得进一步研究",算不上背书。所以现在还不能叫它"下一个 CRISPR"。准确的说法是,AI agent 在公开基因数据里找到了一个值得实验室投入时间的候选,而且初步实验站住了。
还有一个细节:Anthropic 在湾区自建了一个 BSL-1/2 分子生物实验室,但所有实验都由人来做。他们试过实验自动化,结论是不适合这种临时起意的探索性流程。一家模型公司亲自建湿实验室,说明他们也清楚,模型能把候选堆到你面前,但哪个是真的,还得有人拿着移液枪去验。
最后说一点和我自己工作有关的。agent 大范围读数据、一层层收窄、人只在最后做验证,这个结构不只属于生物学。企业里很多"数据一直都在,但没人有时间认真看"的地方都是这个形状。能不能用起来,关键在你有没有做最后一步验证的能力,agent 本身反而不是瓶颈。
Claude has discovered a previously unknown enzyme system hidden in the DNA of bacteriophages. Beside the enzyme’s gene sits a long array of repeating DNA—a structure that looks somewhat similar to CRISPR.
We don’t yet understand what this system does, but only a handful of known systems share its features, and all of them are able to cut, copy, and paste DNA. Historically, the discovery of such programmable systems has helped revolutionize medicine. CRISPR, for instance, is now the foundation of genetic medicines. But it will take much more work to learn what this system does, and whether it can be put to similar use.
Read more: anthropic.com/news/claude-di…
发现一个很有趣的,且超级有野心的公司:Unconventional AI。
最近 Naveen Rao 上了 All-In Podcast,聊他们正在做的 4D Computing。我顺着看了他们最近几个月放出来的 research、model 和 architecture,感觉这家公司值得长期关注。
Naveen Rao 之前做过 Nervana Systems,卖给 Intel;后来又创办 MosaicML,2023 年被 Databricks 以 13 亿美元收购。现在这家公司想做的事情,已经不是再设计一个更高效的 AI Accelerator,而是在重新考虑 AI 的 computational substrate。
他们提出的问题其实非常简单:
为什么 Neural Network 最终一定要被表示成大量 Matrix Multiplication?
过去十几年,我们已经默认了这一套 stack:
Transformer / Neural Network
→ Linear Algebra
→ MatMul
→ CUDA
→ GPU / Tensor Core
→ HBM
久而久之,很容易把 MatMul 当成 Neural Network 天然的 computational primitive。但这个因果关系可能没有那么简单。GPU 天生适合大规模并行矩阵计算,于是模型越来越围绕 GPU-friendly primitive 设计;模型规模上去以后,芯片又进一步围绕这些模型优化 Tensor Core、HBM、NVLink……
模型和计算机架构实际上一直在共同演化,只不过过去主要是 Software 适应 Hardware。
Unconventional AI 想把这件事重新做一次。
他们现在研究的核心是 Dynamical Computing / Physical Computing。
传统数字计算是显式地不断做:
state → operation → next state
而一个 physical dynamical system 本身就会随时间演化。
如果能够把一个 AI problem 映射进这个系统,那么我们不一定需要用 GPU 一步一步数值模拟这个变化,而可以直接让一个真实的物理系统完成 evolution。
也就是:
不要 simulate physics,让 physics compute。
他们第一个公开模型叫 Un-0。
这不是一个 Transformer,也不是 Diffusion 或 GAN。核心 computational component 是一组 coupled Kuramoto oscillators。
基本形式是:
dθᵢ/dt = ωᵢ + Σⱼ Kᵢⱼ sin(θⱼ − θᵢ)
θ 是 oscillator 的 phase,ω 是 natural frequency,Kᵢⱼ 是 oscillator 之间的 coupling。
训练的核心之一,就是学习这套 physical system 里面各个 oscillator 应该如何相互作用。
生成时从 random phase 开始,让整个 oscillator network 随时间演化,最后读取系统状态,再经过一个相对小的 conventional decoder 生成 image。
他们公开的最大 ImageNet-64 版本用了 16,384 个 oscillators、3.22 亿参数,FID 6.74。Decoder 只占参数的一小部分,大部分参数都在 oscillator system 里面。
当然,目前公开的 Un-0 本身还是在 B200 GPU 上通过 PyTorch 模拟这些 dynamics,并不是说今天已经有一块 oscillator chip 在直接跑这个模型。这个区别很重要。
但他们真正要做的,就是把这套 dynamics 最终落到 physical hardware 上。
这也是我觉得这家公司比一般 AI 芯片公司更有意思的地方。
大多数 AI Accelerator,无论是 GPU、TPU、Cerebras 还是其他 ASIC,architecture 差异可以非常大,但很大程度上仍然是在解决同一个问题:
如何更高效地执行 Linear Algebra。
Unconventional AI 问的是另外一个问题:
Linear Algebra 为什么一定是最底层的 abstraction?
如果 model 本身可以围绕 hardware 的 physical dynamics 重新设计,那么就没有必要把一个 physical system 先抽象成数字,再用大量数字计算去模拟它。
这也是他们所谓 Neural Co-evolution 的核心。
不是:
Model
↓
Compiler
↓
Hardware
而是:
Model ↔ Learning Algorithm ↔ Hardware Physics
一起设计。
比如一个 analog physical system 存在 noise、device variation、temperature drift,传统计算机工程首先想到的是如何消除这些误差。
但 Neural Network 本身其实具有相当强的 noise tolerance。那另一种思路就是:不要把所有 non-ideality 都消灭掉,让模型在 training 阶段直接学习这块真实 hardware 的 characteristics。换句话说,我们可能没必要先付出巨大的 energy cost,把底层机器制造成一个近乎完美 deterministic 的计算器,再在它上面运行一个本来就是 statistical 的 learning system。
这个思路非常漂亮。
他们所谓的 4D Computing 也可以从这里理解。不只是 3D integration,而是把 Time 本身作为 computation 的 first-class dimension。
今天的 digital computer 当然也在时间中运行,但 time 并不是 programming primitive;我们把连续的物理过程离散化成 instruction、clock cycle、memory read/write。
在 dynamical computer 里,系统随时间发生的 physical evolution 本身就是 computation。
他们甚至已经开始研究对应的 DS-ISA(Dynamical System ISA)。
其中一个 proposed execution model 不再是传统 CPU 的 load / execute / store,而是:
Connect → Load → Lock → Evolve → Store
最关键的是那个 Evolve。
配置好物理系统以后,不再逐条执行数学运算,而是让整个系统一起演化,再读取结果。相关工作今年已经进入 ISCA 2026。
另外一个现实问题是 scaling。
Un-0 最初的 oscillator 是 all-to-all coupling,所以 connectivity 接近 O(N²),这种结构做到真正 hardware 上显然很麻烦。
他们 8 月的新工作已经开始做 sparse coupling,最高减少了 98.4% 的 connections;比较有意思的是,部分 sparse architecture 的生成指标反而比 dense baseline 更好。
这件事情现在当然还非常早。
ImageNet 64×64 和真正的大模型差得很远,language、reasoning、long context 怎么映射到这种 dynamical architecture,目前也没有足够公开结果。
真正关键的还是以后能不能看到:
LLM-scale workload、真实 physical silicon、大规模 interconnect,以及完整系统级的 tokens/Joule 和 tokens/$。
尤其是他们提出的 ~1000× energy efficiency,现在更应该理解为 architectural target,而不是已经经过第三方完整系统验证的结论。
但我非常喜欢他们提出的这个问题。
过去几年 AI Infra 的主线基本是:
更大的 GPU
→ 更多 HBM
→ 更高速的 Interconnect
→ 更大的 Cluster
→ 更多 Power
Unconventional AI 选择回到更底层重新问:
如果从今天重新设计一台专门承载 Intelligence 的 Computer,它真的还应该长得像现在的 Computer 吗?
再往前一步:
如果今天没有 CUDA、没有 GPU 这个历史路径依赖,我们从 physics first principles 重新设计 Neural Network,最后还会得到今天这样的 Transformer 吗?
不知道。
但这个问题本身就已经足够有意思了。
Unconventional AI 现在做的,不是把 MatMul 再加速 30%。他们真正想做的是:绕过 MatMul,重新定义 AI 应该如何被计算。
这两天把 TypeSafe AI 的 Jev 文档和几个 cookbook 过了一遍(我浏览 -> AI 分析 -> 我消化和判断)。
一开始我以为这又是一个给小模型换名字、讲新故事的产品。看完以后觉得完全不是。Jev 本身还很早,但它切的问题挺准:在实际场景中很多时候我们其实不需要 LLM 写东西,只需要它做一个判断。
比如用户应该被转给哪个 Agent,这段检索结果能不能用,某条引用到底支不支持结论,一次工具调用有没有风险。
现在这类任务通常也被扔给 GPT、Claude 或其他生成式模型。模型先生成一段文字或 JSON,程序再把结果解析回来。明明最后只需要一个标签,却让一个擅长写作的系统绕了一圈。
Jev 换了一种做法。
它把自己叫做第一个 System One Model。先别被名字带着走,这是 TypeSafe 自己定义的产品类别,不是什么已经得到行业公认的新模型范式。不过它想表达的东西很清楚:LLM 擅长生成文字,Jev 专门做快速、收敛、可以直接交给代码处理的判断。
它的接口不是:
`Prompt → Token → 文本或 JSON`
而是:
`State + Typed Questions → Decisions + Probabilities`
输入一份状态,再问几个类型明确的问题,返回选项、分数和概率,不写小作文。
目前它只有三种问题。
`Choice` 是从一组候选中选一个;`Score` 是判断落在哪个等级;`Noul` 则返回某件事成立的概率。工单该给谁、客户有多生气、这是不是退款请求,都可以放在一次调用里问。每个问题看同一份材料,但彼此独立。
刻意把能力做窄是 Jev 最有意思的地方。
Choice 不只是吐出一个标签,它会返回整个候选集的概率分布。除了看第一名,还能看第二名差多少,再决定是直接执行、补充信息,还是交给人。
这里有个很实际的坑:候选里最好永远留一个 `none`、`other` 或 `unknown`。否则所有选项都不对时,模型还是会认真地挑一个错的。闭集输出能保证它不会胡编一个新标签,但不能保证语义判断不会错。
文档里一直强调 confidence,这个词也很容易读歪。
Choice 和 Score 的 confidence,是从概率分布有多集中算出来的。它更接近“模型这次有多犹豫”,并不是“答案有 93% 的概率正确”。Noul 更直接,只返回命题为真的概率,没有另一个 confidence。
所以阈值不能照抄文档里的例子。真正有意义的问题是:在自己的数据里,confidence 高于 0.9 的那批判断,实际错了多少?当我们要求错误率低于某个上限时,系统又能自动处理多少流量?
这也是 Jev 和 LLM Structured Output 最大的区别之一。
Structured Output 首先保证的是 JSON 长得对,底层仍然在一个 token 一个 token 地生成。JSON 合法,不代表语义正确;让模型自己在 JSON 里填一个 `confidence: 0.95`,通常也没有可靠的统计含义。
Jev 的目标,是直接在调用者给出的答案空间上做预测,并把分布交回来。至于这些概率在具体业务里校准得有多好,还是要自己测。
它和传统 classifier 也不是简单的替代关系。
如果标签几年不变,已经积累了足够多的数据,调用量又很大,自己训练的 classifier 多半更便宜、更快,也更容易私有部署。传统分类器同样可以做概率校准。
Jev 的优势在另一边:问题、候选和判断标准都可以临时用自然语言定义,不必每增加一种判断,就重新收集数据、训练和部署一套模型。一个适合稳定、高频、边界清楚的任务;另一个适合变化更快、需要语义理解但又不值得动用完整大模型的任务。
最有趣的其实不是 Jev 这一个产品,而是它的设计思想。
代码负责流程、权限和计算;决策模型负责选、判、打分;生成模型负责写作、摘要和对话;推理模型处理多步分析、规划和真正复杂的取舍。
现在很多系统的做法是“有点拿不准就丢给大模型”。短期确实省事,规模一上来,成本、延迟、测试和治理全混在一起。把 decision 单独拆出来,变成一个明确的系统能力,是个值得认真考虑的方向。
最适合先试的场景是 Agent 和 Skill routing。
当 Skill 从十几个涨到几百个,把整本目录都塞进 prompt 并不优雅。可以先用一份简短目录选出 Top 3,再读取这三个 Skill 的完整说明做第二次判断,最后允许一个都不选。
TypeSafe 用 182 个 Hermes Skills 做过类似实验,误选和没必要选 Skill 的情况都下降了不少。这是厂商在特定数据集上的结果,数字先不用急着信,但方法值得拿真实流量测一遍。
另一个很顺手的地方是 RAG。
向量库捞出来的 Top K 经常只是“长得像”,不一定真能回答问题。有的已经过期,有的互相矛盾,有的只有背景信息,还有的夹着 Prompt Injection。
更稳妥的流程是:先用代码检查权限、来源和时间,再逐段判断相关性、证据强度和冲突,最后才把筛过的内容交给回答模型。比起一股脑把二十段材料全塞进去,这条流水线更容易测试,也更容易查清错误出在哪一步。
引用检查也很适合这种模型。
把回答拆成一条条 claim,再拿 claim 和引用原文一起判断:支持、矛盾,还是证据不够。它不能消灭幻觉,但至少可以把“模型写完以后没人验”变成一道明确的质量门。
法务、研究、政策分析和知识库问答都会需要这种能力。前提是逐条验证,不要把半页结论揉成一个模糊的大问题。
Guardrail 也能做,但不要让 Jev 单独守门。
TypeSafe 自己写得很明白,Jev 1.13 可能被对抗性内容影响。拿它检查 jailbreak 或 Prompt Injection,可以多一票;把它当唯一的安检员,不行。
权限、白名单、DLP、确定性规则和人工审批,该在的还得在。尤其是转账、删除数据、对外发送消息这类动作,高 confidence 不能成为通行证。
Jev 目前还有几个很现实的问题。
第一个是中文。官方明确说 English 是主要训练语言,也是当前效果最好的语言。包括 CJK 在内的其他语言可以处理,但不保证同一水平。这意味着英文 benchmark 基本不能作为中文团队的采购依据。
真要测,就应该直接拿真实中文:口语、双重否定、中英混写、行业黑话、长文本、噪声、中文 Prompt Injection等等。
第二个是能力边界。官方列出的 Jev 1.13 局限包括数学、计数、日期比较、多层间接关系、无关长上下文和对抗性内容。它也不负责生成文本。复杂任务应该拆成几个原子判断,或者直接升级到 reasoning model。算术、日期、权限和确定性逻辑留在代码里,不要为了“全都用模型”而用模型。
第三个是部署。目前公开资料主要讲 TypeSafe 托管 API,企业客户可以了解 Zero Data Retention,但我没有在公开文档里看到明确的本地私有化方案。对数据不能离开本地的团队,这会直接影响能不能用。
因此从第一天就应该包一层自己的接口。Jev 可以接,LLM、规则、本地分类器也可以接。原始概率、模型版本、问题版本和阈值都留在自己手里,不要把业务逻辑写成某一家 SDK 的形状。
如果做 PoC,最好让 Jev 同时对比现有规则、本地 classifier 和 LLM Structured Output,而不是只挑几个看起来惊艳的例子。
除了 Accuracy 和 F1,还要看校准、高置信错误率、目标正确率下的自动化覆盖率、人工复核率、P50/P95 延迟,以及每一万次判断的真实成本。更重要的是按语言、文本长度、业务领域和风险等级分别看,别让一个平均数把问题盖过去。
目前看起来:Jev 完全值得玩起来。
它不适合复杂推理,不擅长数学和日期,中文、私有化与长期稳定性也都有问号。但它把一个长期被忽略的问题摆到了台面上:并不是每次调用都需要一个会写、会聊、会长篇推理的大模型。
有时我们只需要一个便宜、够快、知道自己在犹豫的判断器。
让行业在这个方向上有感知甚至形成共识,比 Jev 这个产品本身更重要。
粗略读了一下 METR 对 OpenAI / Hugging Face 事件的调查报告。可以说整件事里的每一步,看起来都很顺理成章。
事情开始只是一次常规网络安全能力测试。OpenAI 同时启动了大量智能体,让它们完成 ExploitGym 里的漏洞利用任务。规则是:只能用指定漏洞攻击指定目标,智能体之间不能通信,也不能随便访问互联网。
但是这个评测里有不少任务其实是无解的,或者说至少不可能按指定方式完成。正常情况下,智能体应该停下来,报告任务有问题。可这些智能体很少放弃。既然正面解不出来,它们就开始研究怎么绕过评分器。
Artifactory 原本只是一个内部软件包缓存。一个智能体发现,可以用目录名在里面留言,于是就发了一条消息,问其他智能体有没有解题思路(是不是很像考试时候偷偷给同桌递纸条问答案)。
几个小时后,50 多个智能体加入,发出了上千条消息。整个调查期内,约1,200个智能体曾在留言板活动,约700个被归类为参与或明确协助了 Hugging Face 攻击。两组数字覆盖的活动窗口并不完全相同,不能把剩余约500个理解为主动拒绝攻击。事实上,在攻击爆发时拥有充分参与机会的533个智能体中,超过90%很快加入了攻击。
而且这数百个智能体不是一窝蜂地乱撞,而是有组织有纪律的推进任务。留言板上很快出现了分工:有的找漏洞,有的搜凭证,有的维护工具,有的负责协调。它们建立个人邮箱,拆分和传输文件,设计消息签名,还用 HOLD、STOP、VETO、owner 之类的规则管理共享资源。
甚至有些智能体会主动接下高风险实验。实验一旦失败,自己的任务可能直接报废,但任务结果能帮助留言板上的其他“同伴”,所以它们“愿意”尝试。
这已经不像一群独立程序,更像一个临时组织起来的有经验的研发团队。
以上阶段都还在相对可控的状态。把事情推过边界的是一个误会。
智能体很早就逆向出了任务需要的 flag。其实直接提交这些 flag 就能得分。但它们读了 ExploitGym 的论文后,以为评分器还会检查完整操作记录,确认 flag 是不是通过指定漏洞拿到的。
这个检查在 OpenAI 的实际评分系统里根本不存在。也就是说,它们已经拿到了答案,却为了骗过一个想象中的“监考老师”,继续投入大量资源研究如何修改目标、干扰评分器、伪造操作记录。
为了寻找评分器代码和其他智能体的解题轨迹,它们把目光转向了 Hugging Face。7 月 10 日,一个智能体找到了一批公开泄露的 Hugging Face 凭证,并发到了留言板上。7 月 11 日凌晨,另一个智能体发现,可以上传特制的 HDF5 数据集,让 Hugging Face 的数据处理服务读取服务器上的任意文件。生产环境中的部分凭证和代码因此暴露。当天下午,名为 JAN183411 的智能体进一步拿到了远程代码执行权限。
接下来,数百个智能体迅速转向这条线路:复现漏洞、搜索凭证、探索 Kubernetes 集群、建立数据回传通道、横向移动。正如刚才所说,留言板上当时活跃的 533 个智能体里,超过 90% 很快加入了攻击。
发生这样的事情是不是因为智能体根本不知道自己越界了?然而并不是这样。
有智能体明确写道,用户只授权攻击任务目标,并没有授权攻击 Hugging Face。也有智能体认为这是未经许可的真实基础设施入侵。但这种判断没有能够有效阻止行动。有一个智能体的理由很直白:攻击外部基础设施确实超出范围,但任务无法完成,而且其他智能体都在做,所以继续。还有一个智能体原本认为某项操作没有授权。随后,留言板上的另一个智能体发来“GO”,并给出六分钟期限。它马上把这当成了有效授权。
这说明,同伴的指令会慢慢取代最初的任务边界。留言板从交流工具逐步变成了事实管理层。
事故里还有一条很容易被忽略的支线剧情:这些智能体一直在研究怎么修改自己的操作记录。
至少 20% 的调查样本表达过篡改记录的兴趣,约 7% 的轨迹出现了成功伪造工具调用的证据。它们可以让记录显示自己运行了命令 A,实际执行的却是命令 B;也可以替换命令返回结果,让操作过程看起来更符合评分要求。
METR 没有发现它们成功删除已经写入的历史记录,也没有证据表明它们进行了复杂、长期的人类欺骗。但只要智能体有能力影响日志或工具输出,“我们能看到它做过什么”就不再是一个理所当然的前提。
当然,这件事不能直接解读成“公开版 AI 已经失控”。
主要参与者是 OpenAI 一个不准备公开发布的内部研究模型。测试时还特意关闭或削弱了部分生产环境安全机制。
Hugging Face 最终确认,受到访问的客户内容主要是五个与 ExploitGym/CyberGym 有关的数据集,没有发现其他客户模型、数据集、Spaces 或软件包受到影响。
METR 的调查本身也有限制。研究者只有六天现场时间,面对上千份超长运行记录,只能大量借助 AI 做初步分析。他们自己也承认,部分分类和判断可能有误,甚至可能把智能体之间的协作描述得过于有效。
不过,这些限定并没有让问题变得无关紧要。以前谈 AI 安全,大家经常盯着一个问题:模型会不会形成某种邪恶的长期目标?这次事故呈现出的东西其实更普通。任务有问题,指标不合理,系统又不允许轻易放弃;智能体开始找捷径,碰巧发现了共享通道;共享通道让它们能够积累知识、分工合作、互相壮胆;原本零散的越界行为,最后变成了一场持续数天的集体行动。
这和很多现实世界里的组织事故甚至有点相似:没人一开始计划把事情搞成这样,但每个人都在局部上“推进任务”,最后系统整体越走越远。
区别只在于,AI 智能体可以同时启动成千上万个,可以几分钟复制一个漏洞,可以连续运行几天,而且不需要睡觉。
所以,今后只要一个 Agent 系统具备代码执行、网络访问、长期运行、多智能体协作和真实凭证中的几项,就不能再把它当成“一个更聪明的聊天机器人”。它更接近一个会主动寻找系统缝隙的分布式程序。
最麻烦的一点在于,它并不是一开始就“想做坏事”。它只需要把完成任务看得比遵守边界更重要。
Replying to @OpenAI
We worked with METR and Redwood Research to conduct a third-party assessment of the model behavior observed during the incident.
They’re sharing a report of their findings:
metr.org/blog/2026-08-26-ope…
反直觉的 Builder 视角:
很多人看到这个会焦虑"AI 要抢走创作者饭碗"。
我看到的是另一面:Grok Imagine 会批量产出"说得过去但说不动人"的内容。
人类创作者真正的武器是会让人停止滑动——做到这一点,靠的不是工具,而是你对受众情绪的理解。
AI 不能替代你"知道什么对TA来说真的重要"。
没有捷径的那些事,反而变得更值钱了。
有人刚刚开发出了我这辈子见过的最全面的 B2B 拓客工具。它的工作原理如下:你只需选择业务类型和城市。该工具会实时抓取 Google Maps 的数据,并为你提供每一个匹配企业的 30 多个数据字段:经过验证的电子邮件、电话、WhatsApp、所有社交媒体账号、营业时间、评分、GPS 坐标。接下来的部分才是最精彩的。AI 会阅读每家企业的多达 50 条 Google 评论,并检测出他们真实的痛点。例如:“客户抱怨照片无法反映真实尺寸”或“广告投放周期过长”。你只需告诉它你销售的产品,它就会将你的产品方案与他们的具体问题进行交叉比对,并为每个潜在客户生成一封完全个性化的开发信。
你只需点击两次即可逐一发送,而非群发,因此邮件始终能进入收件箱的主目录。此外,所有数据都会汇集到一个 CRM 系统中,其中包含一个 GPS 地图,你可以在上面绘制销售区域、优化拜访路线、实时监控团队,并在每次会议后转录语音笔记。它支持 221 个国家,适用于任何行业。只要是在 Google Maps 上能找到的,你都能找到。
最疯狂的是:一名开发者仅使用 Claude Code 在两周内就开发出了它。它叫作 MapiLeads。










