2026年5月13日，同一周内两组重磅数字，勾勒出AI世界两条迥异的演进路径。

一、透视6万亿估值：资本飞轮如何高速运转

额度48小时内被抢光，投资者的狂热犹如一场一票难求的春运抢票。

Anthropic计划以超9000亿美元（约6.5万亿人民币）的投前估值，再度融资300亿美元——这并非愚人节玩笑，而是彭博社、财联社、金融时报在5月12日至13日连续确认的重磅消息。

更令人瞠目的是营收增速：今年2月年化营收为140亿美元，4月宣布突破300亿，5月初第三方机构的统计已来到440亿美元。短短不到5个月，增幅接近5倍。

支撑这条陡峭增长曲线的，是相当健康的收入结构：企业客户贡献超80%的营收，财富10强中8家已是付费用户，年支出超100万美元的大客户已逾1000家，且这一数字在两个月内翻了一番。

然而，6万亿估值的背后，是一张愈发密集的算力采购网络——谷歌承诺投入100亿美元并追加300亿美元，亚马逊投入50亿美元并追加200亿美元。每一轮融资的实质，都是为了采购更多英伟达GPU来训练更强劲的模型，再凭借模型优势揽获客户，然后用客户收入撬动新融资继续购买芯片。

这便是西方AI的核心逻辑：资本驱动型。

融资→购置算力→训练更强模型→更多客户→更多融资。

二、52%市场份额的背后：国产AI芯片的逆袭拐点

与此同时，就在Anthropic抢占市场份额的同一周，另一组数据虽低调出炉，却意义深远。2026年一季度，国产AI芯片在国内市场的份额首次突破50%，达到52.3%。

这不仅是数字上的变化，更是一个结构性的转折点。回看时间线，逆袭路径清晰可辨：

• 2024年底：国产AI芯片仍被视为“后备选项”，大部分AI企业首选英伟达，国产芯片仅作为补充。
• 2025年Q1：DeepSeek R1横空出世，证明了小团队配合国产算力同样能战，但市场仍持观望态度。
• 2025年下半年：昇腾910C启动规模化交付，多家大模型厂商开始适配。
• 2026年3月：昇腾950PR正式发布，单卡性能达到英伟达H20的2.87倍。
• 2026年5月：DeepSeek V4全面适配昇腾950PR，推理速度提升35倍，部署成本仅为英伟达方案的1/3。

从“能不能用”，到“好不好用”，再到“比进口方案更具性价比”，国产AI芯片仅用了不到两年便迈过了最关键的三步。

数据更加夺目：华为昇腾以37%的市场份额占据断层第一，占国产芯片总量近七成；英伟达在中国市场的份额由巅峰期的95%骤降至42.7%；在政务、金融、能源等战略行业，国产芯片的采购比例已超过70%。

更重要的是，这场转折还远未到达顶峰。华为2026年AI芯片营收目标约120亿美元，同比增幅超60%；昇腾950PR全年75万颗的产能，刚一公布便被国内头部互联网企业基本预定。

三、两条路径，两个平行宇宙的本质对比

当6.5万亿估值与52.3%市场份额交汇，体现的并非东西方AI的胜负，而是两种截然不同的发展逻辑正在并行演进。

西方路径：资本驱动型
• 核心资源：资本与顶尖人才
• 循环逻辑：融资→采购算力→训练更强模型→更多客户→更多融资
• 优势：迭代飞速、全球化布局、人才集聚效应显著
• 风险：估值泡沫、过度依赖单一算力供应商、成本持续高企

中国路径：基础设施驱动型
• 核心资源：自主算力与多样化场景
• 循环逻辑：政策引导→国产芯片规模量产→大模型适配→场景落地→正向生态循环
• 优势：完全自主可控、显著成本优势、丰富的落地场景、长期政策护航
• 风险：生态完备度不足、高端训练芯片仍待突破、国际化发展起步较晚

5月9日国常会释放的信号，将“基础设施驱动”逻辑推至新高度——算力网首次被列入国家“六张网”规划，与水网、新型电网、新一代通信网、城市地下管网、物流网处于同等地位。

这意味着什么？水网和电网是国民经济的命脉，算力网被纳入同一层级，象征算力正式从“行业资源”升格为“国家基础设施”。未来使用算力，如同用水用电一般，将成为国家基础设施的基本保障。

四、非零和博弈，而是双向奔赴的起点

还有一个常被忽略的对比：斯坦福大学报告指出，2025年美国AI领域的私人投资是中国的23倍有余，但两国顶级模型的性能差距已缩小至仅2.7%。

这一结果，折射出中国依靠“芯片与模型协同”、全产业链配套和丰富应用场景所实现的超高研发效率。

资本驱动的西方路径，正在展现AI能创造多么巨大的商业价值；基础设施驱动的中国路径，则证明了AI能达到何等程度的自主可控。这绝非谁取代谁的零和博弈，而是人类AI文明在不同土壤中绽放的两朵奇葩。

数据来源：IDC、中国半导体行业协会、彭博社、财联社、金融时报、昇腾CANN开发者社区

funNLP 全面汇聚了从 ChatGPT、大语言模型数据集、中文语料库到知识图谱、文本生成、关键词提取、文本匹配及可视化等各领域的技术、项目与文献资源。截至目前，该开源项目已收获 79k 颗 GitHub Star，深受开发者青睐。无论是技术学习还是文献检索，都能在这里迅速定位所需内容，充分满足学习与实践需求。接下来为您详细解读。仓库的构建基于三大核心原则：

• 全面覆盖：从传统 NLP 任务到前沿大模型应用，无所不包
• 即拿即用：提供开箱即用的数据集、模型和工具，加速项目落地
• 社区共建：持续追踪最新科研进展与行业动态

主要资源类别

大语言模型与类 ChatGPT 资源

仓库全面覆盖大语言模型的最新进展，涵盖：

• 模型评测与对比：面向中文 LLM 的综合基准与评估体系
• 开源框架：可直接部署的 ChatGLM、MOSS、中文 LLaMA 衍生版本等实践方案
• 训练与优化：高效微调、低资源训练策略以及推理加速技术

传统 NLP 资源

构成中文 NLP 应用基础的核心资源：

专业领域应用

面向专业场景的行业定制 NLP 资源：

AG-UI：使每一次 AI Agent 与用户的接触，都自然、流畅且可控。

引言

在 AI Agent 爆发的当下，我们拥有了极其强大的智能后端——然而，怎样才能让这些 Agent 真正“融入”用户界面？传统的 REST API 和 GraphQL 在应对 Agent 的实时流式输出、不确定行为、多轮对话等特性时，显得力有不逮。

AG-UI（Agent-User Interaction Protocol） 由此诞生。它是一个开放、轻量、事件驱动的协议，将 AI Agent 与用户界面之间的连接方式进行标准化。

本文将从浅入深，详细介绍 AG-UI 协议的工作原理、核心概念及实际落地方式。

一、AG-UI 为何而生？

1.1 传统 API 遇到的瓶颈

在 AI Agent 亮相之前，前后端通信普遍采用请求-应答模式：

• 客户端发起请求
• 服务端返回数据
• 客户端渲染结果
• 一次交互结束

但 AI Agent 彻底打破了这种模式：

这些特性使得传统 API 捉襟见肘。开发人员不得不自行处理：

• 流式输出的解析与渲染
• 多种事件类型的统一管理
• 用户中途干预的衔接
• 前后端状态的一致性同步

1.2 三项 Agentic 协议的定位

AG-UI 并非孤立存在，它与其他两项协议共同构成了完整的 Agentic 生态：

2026 年 2 月，“Harness Engineering”这个术语突然在 AI 工程圈内引爆了话题。Mitchell Hashimoto 在个人博客里率先提出这一概念，紧接着 OpenAI 发布了涵盖百万行代码的实验报告，Martin Fowler 也紧随其后撰写了深度分析文章——仅仅几周时间，这一概念便成为讨论 AI Agent 开发时无法绕开的焦点。

一、核心隐喻：驾驭野马——马、马具与骑手

要理解什么是 Harness Engineering，目前业界最广为流传的隐喻是：

• 马（The Horse - AI 模型）：当下的 AI 模型（如 OpenAI Codex 等）犹如一匹力大无穷、疾驰如风的骏马。它的能力让人惊叹，但若不加引导，它常常彷徨不知方向，甚至横冲直撞（即产生幻觉、偏离架构规范）。
• 马具/缰绳（The Harness - 基础设施）：涵盖约束规则、护栏机制、上下文传递路径以及反馈循环。它们将 AI 模型的原始“智力”塑造为能够达成特定业务目标的系统。
• 骑手（The Rider - 人类工程师）：工程师不再需要“亲自奔跑”（手写底层代码），而是紧握缰绳，指明方向，注入意图并提供结构化反馈。

二、为何 Harness Engineering 不可或缺？

在过去两年中，行业共同发现了一个痛点：对 AI Agent 而言，“再努力一点（Try harder）”这条路根本走不通。 当 Agent 在庞大的代码库里迷失、陷入死循环、或者编写出违背公司架构规范的设计时，仅仅依靠调整 Prompt（提示词工程）来挽救局面极其脆弱。

Harness Engineering 应运而生，正是为了突破 AI 自主性的瓶颈。它的核心思想是：每当 AI 犯错，不要耗费精力去调整玄学般的提示词，而是改进 Harness 系统（例如添加一项 Linter 或测试拦截器），让它在机制层面再也不可能犯同样的错误。

模型能力并非瓶颈所在

这一论断已经得到了量化实验的支撑：

Can.ac 实验：仅仅改变 Harness 的工具格式（编辑接口），就在 16 个模型上显著提高了编码基准分数。效果最引人注目的是 Grok Code Fast 1，其成绩从 6.7% 飙升至 68.3%——完全没有任何模型权重的改动。

大语言模型最核心的能力依然是编程，其它的表现更像附加天赋。既然我们“聘请”了这位程序员，那就应该让它发挥擅长，而不是浅尝辄止。

曾经有一种论调称，如果没有任何编程基础，就无法有效驱动大模型写代码。但我偏不信这个邪，也坚持认为这项技能不仅自己要学会，更要分享给所有渴望掌握 AI 编程的人。

随着 AI 能力的渗透，软件开发的壁垒正在瓦解，独立搭建应用的门槛将下沉到每一家企业和每一个团队。未来当老板冒出数字化需求时，他会直接让你用 AI 捣鼓出一个工具，而不再是丢给外包。谁先驾轻就熟，谁就能率先在组织里构建起不可替代的竞争力。

AI 编程应该怎么学

其实最难的部分——写代码——大模型已经替你做了。剩下的核心，是建立起对整个软件开发生命周期的认知与掌控。

传统开发通常分成五个阶段：需求梳理、UI 设计、前后端开发、测试、上线。引入 AI 之后，流程可以精简为四步：需求梳理、软件开发、体验测试、部署上线。UI 设计这一步被融入开发过程里，而且每个环节都有 AI 协同，复杂度显著降低。

需求梳理

接到需求后，首先要厘清这个软件要解决什么问题、以什么形态呈现。脑中有了大致轮廓，就可以借助 AI 工具的 Plan 模式，生成一份完整的开发计划。这中间需要不断与模型沟通、迭代，把模糊的想法打磨成可执行的路径。

经验提示 推荐一套配合 Plan 模式使用的 skill 组，它能主动向你提出大量追问，最终自动生成需求调研报告和功能清单，帮助你从各个维度把需求细化到可落地的颗粒度。

Github：https://github.com/zhengyunhui123-dev/cursor-claude/tree/main/PM-skill

软件开发

接下来，将计划文档、需求调研报告和功能清单一起交给 Codex、Claude Code、Workbuddy 等 AI 编程工具，让它们执行开发。过程中前端开发可以调用 frontend-design 这个 skill，至少能保证产出的界面美观可用。

实践心得

1. 先构建最小可行产品（MVP），再逐步叠加功能。不要一开始就规划大而全的方案，因为初期对需求的理解往往不够完整，如果让模型一次性生成庞大代码，后续要调整时，连你自己都很难组织语言告诉它改哪里。
2. 根据软件类型，尽早决定使用本地数据库还是线上数据库。需要本地数据库时要搭配 Docker 辅助开发；线上数据库推荐 Supabase，上手快且生态完整。

（Docker、Supabase、Github、Vercel 等工具的具体使用教程会在后续分享。）

3. 不要执着于只用某一个 AI 工具。个人常用的策略是：让 Codex 负责写代码，同时在豆包、元宝等免费产品里为这个项目创建独立的对话。遇到不懂的问题就问它们，需要自己手动操作时，让它们一步步指导。这样既不会污染主工具的上下文，也不会浪费高级模型的宝贵 token，效率很高。

体验测试

在传统流程中，这部分通常是产品经理反复“走流程”来验证开发结果。AI 完成编程后，软件会先在本地运行起来。你要做的就是逐项体验、测试，把不符合需求的地方“圈”出来，再打回给模型修改，直到满意为止。

这一环节往往最耗时间，因为 AI 交付给你的更像一个“简装房”，需要你进行细致的“精修”。

精修管理

“精修”主要包含需求变更和 Bug 修复两类。建议把这两类问题都记录成台账，方便后期追踪。这个项目管理的方法也写进了 AGENTS.md 文件中，里面还融入了社区大牛总结的编程规范以及补充要求。放在项目文件夹里，AI 编程时会自动读取并遵循。

这篇文章是一个从未接触过编程的我，在一步步查阅资料、询问AI之后，耗费两天时间，终于将自己用AI编程打造的一款记账软件成功部署上线的真实记录。

整个过程踩坑无数，走了不少弯路，也浪费了许多时间。

因为部署流程的步骤较为繁琐，我把整个过程详细记录下来，既是为了与大家共同进步，也是为了日后自己需要时能够快速回顾。

前提

最近我用 Codex 编写了一个小巧的软件，取名为 jotbook。

它本质上是一个记账工具，用来记录我每天的支出，所有内容都保存在本地。无需登录，没有数据库，也不依赖后端。

网上建议使用 PWA 架构，说是体验贴近原生应用，部署起来也方便简洁，我便让 Codex 也照此实现。

在本地调试一切正常后，剩下的工作就是将它部署上线，这样我就能在手机上随时随地使用了。

我之前考虑过直接使用本地调试的版本来记账，但实际操作起来并不方便，需要电脑一直开机，并且保持服务持续运行。

所以，最终还是决定将它部署上线。

部署上线

部署上线过程可以总结为以下三步：

1. 将项目上传到 GitHub
2. 通过 Vercel 进行部署上线
3. 配置域名解析

虽然看上去只有三步，但每一步都埋着大大小小的坑。我也是尝试了多种方案后，最终选择在 Vercel 上部署，目前看来这是最方便的一种方式。

如果你手头没有现成的项目，可以直接复制我的这个项目（https://github.com/zhengyunhui123-dev/jot），按照教程走一遍完整的部署流程。

上传 GitHub

编程离不开 Git，这是毋庸置疑的。

Git 的核心作用是版本管理，假如你从来不进行版本管理，一旦代码改崩了，就会让你体验到什么叫做痛苦。

GitHub 则是将你的代码存储在云端的地方，把代码上传到 GitHub，主要是为了方便下一步 Vercel 的部署。

Git 使用

Git 基本大家都安装过，使用 Claude Code 本身就要求必须安装 Git。如果你懒得记那些命令，可以下载一个图形化工具——“小乌龟”（TortoiseGit）。

毕竟每次让大模型帮你操作 Git，消耗的都是白花花的 token，还容易污染上下文，不如自己手动搞定。

这也是我建议手动提交的原因之一。

Git 分为提交（commit）和推送（push），提交是提交到本地仓库，推送才是同步到 GitHub 上。只有推送成功，代码才能同步给 Vercel。

在执行 Git 提交时，尤其要注意下面两点：

1. 敏感信息不要提交，比如你的密钥、账号密码等，不要稀里糊涂地全选提交，务必先筛选剔除敏感内容后再提交。
2. 本地依赖不要提交，也就是那个叫 “node_modules” 的文件夹，如果提交了，在 Vercel 部署时就会报错。把它从提交中剔除出去。

这也是我建议手动提交的原因之二。

Git 的其他详细使用方法，可以去询问元宝或豆包。

身处互联网行业的从业者，想必都感受到了，今年整体的业务推进相当困难。

尤其在ToB赛道，各大企业的需求都在收缩，新项目基本不会启动。即便偶尔出现一两个机会，报价也被压得极低，而且就算价格再低，也很难轮到你的公司来接单。

这就引发了一系列连锁反应——像你所在的公司这类做ToB业务的互联网企业，纷纷开始“勒紧腰带过苦日子”。

有的公司状况稍好一些，选择节衣缩食，砍掉福利，下调薪资，冻结招聘，号召员工一起陪公司熬过低谷。

而有些公司实在顶不住，只能裁员断臂求生，打算先活下来再谈其他。

但相当多的企业并不愿意承认是自己业务本身出了问题，反而把一切归咎于AI带来的冲击。

经过老板们反复的宣传与灌输，我们这些打工人便慢慢信了这一套说法。

矛盾被转移了，问题依旧没有解决。

作为打工者，薪资福利缩水了，活儿却一点没少，还得承受来自公司和领导的额外压力，于是开始犹豫要不要换个环境。

对于那些有些蠢蠢欲动的职场人，我想真心劝一句：先别急，不妨再观望一阵。

因为眼下所有公司都处在转型过程中，市场的运作方式远未定型，如果贸然跳出去，很可能会变得更加难以适应。

举例来说，你是一个程序员，目前在岗的公司，工作内容与职责范围已经相对确定，工作量与薪资的匹配也已大致量化，所以你能够心态平和地上下班。

而在AI冲击之下，你若是跳去一家新公司，极可能遇到待遇不涨、但工作任务翻倍甚至更多的情况。这种巨大的反差，不是谁都能消化得了的。

看看如今的招聘网站，已经明晃晃地要求一个程序员前后端都要兼顾，关键是薪资没变，甚至比之前还低。问起来，理由就是——现在有了AI，效率提高了，这些活儿一个人就能干完。

AI成了所有公司推行降本增效的统一借口，看似无懈可击。

那实际情况是怎样的？至少就我了解到的真实场景，AI并没有真正提升效率，相反，我常常因为折腾AI耗费了大量时间，加了很多班。

起初我以为这是“磨刀不误砍柴工”，可后来发现，每换一个新的工作场景，这把“刀”就得重新磨一次，仿佛永远都没有磨完的时刻。

更关键的是，制定这些规则的领导和老板，很多人压根就没亲自用过AI。他们只是看了新闻报道，听几个相熟的老板说了类似的话，就断定实际情况就是如此。

“给一个人配上AI，他就能干三个甚至更多人的活。”

“好，那就这么定了，把AI融入我们工作流。”

“什么？很多人反对？既然老员工不愿改变，那就裁员，招新人来接受这种变化。”

这，便是当下真实的工作生态。如果我们轻易换工作，很可能只是从一个坑跳进另一个更大的坑，你将不得不面对成倍增加的任务量，却无从反对，只能欲哭无泪。

最稳妥的策略，还是“苟住”，等待局势明朗。

我预估，接下来会有一轮岗位重塑与洗牌，工作岗位也会被重新划分。可能产品经理岗位要纳入编程技能，程序员将不再区分前后端，测试工程师也得懂用户体验。

这些变化之后，关键点是工作量与薪资会逐渐稳定到一个大家都能接受的区间，而不会像现在这样，严重失衡。

我相信，作为互联网行业的从业者，大家并不排斥工作量的增加，核心是要能拿到同等的报酬。

所以，在这个阶段，为了不让自己累垮，不妨先接纳现公司施加的“压力”和“压榨”吧。毕竟在现有的公司里，你多少还有讨价还价的余地，身边也有同事跟你站在同一条战线上。

等到尘埃落定，再做下一步决定，也为时不晚。

在生成式AI突飞猛进的当下，大模型的基础推理能力已经实现了跨越式的提升。然而，行业的焦点已悄然转变——从最初惊叹于“模型有多聪明”，转而思考“怎样让大模型的能力稳定、可控、合规地嵌入真实而复杂的生产环境”。

• Prompt 决定你如何发出任务指令
• Context 决定模型在决策时刻能看到什么信息
• Harness 决定模型在怎样的运行机制中完成任务

这三层的外延其实是逐步扩大的。

当我们的目标从“做对一道题”进化为“稳定完成一整段工作流”，系统的发力点便会自然地外移。我们会先发现优化prompt已经不够，接着意识到只补足上下文仍不足，最后不得不去直面那些更工程化的问题——运行环境、反馈回路、权限边界以及记录系统。

范式一：提示词工程（Prompt Engineering）—— 寻找与AI的“共同交流语言”

在第一阶段，探索几乎都围绕着同一个主题：如何与大模型进行“有效沟通”。人们逐渐意识到，大模型内部虽蕴含着海量知识和强大的推理能力，但这些能力并不会自动释放，必须有特定的指令结构去触发。于是，开发者开始通过精心设计的输入、引导思维链（CoT）等方式，尽可能地激发模型的原生潜力。

多数人第一次接触LLM，也正是从Prompt开始的：打开ChatGPT、DeepSeek或豆包，在对话框里敲下一句话，模型随即返回一段回答。例如输入“中国的首都是哪里”，得到“北京”。这种简单直白的交互方式催生了大量的ChatBot，其实质是将模型能力封装成一个更高效的知识库、数据库或搜索引擎。在这一阶段，AI的核心仍是“问答”——如何更准确地输出用户想要的答案。

围绕这一目标，主流方法本质上都在解决同一个问题：让模型更好地理解用户意图。因此，Prompt Engineering成为研究重点，主要包括：

• 通过角色设定、背景补充与行为约束，构建结构化的提示
• 使用 one-shot / few-shot 样例对模型进行引导
• 引入思维链（Chain-of-Thought）以增强推理过程的可控性
• 借助 ReAct 框架，让模型拥有“推理—行动—观察”的基本能力（这其实也标志着向Agent形态的初步演进）

更严格地说，Prompt Engineering不仅仅是“写一句更有效的话”，而是一个包含设计、测试、评估与迭代的系统工程，其本质在于持续优化“输入表达”。

从方法论上看，这一阶段可以视为一种“输入调优”：我们把大模型视作一位极具潜力但欠缺业务上下文的高智商员工——指令越清晰、边界越明确，输出就越接近期望结果。

然而，这种高度依赖模型原生能力的交互范式也存在天然上限：

• 受上下文长度限制，难以承载复杂任务；
• 无法接入外部知识与实时信息；
• 更无法从根本上消除“幻觉”带来的不确定性与业务风险。

因此，单靠Prompt，并不足以支撑更复杂、更可靠的应用形态。

范式二：上下文工程（Context Engineering）—— 为大模型外接“专属知识中枢”

模型是基于上下文窗口来工作的，prompt只是其中的一部分。当任务从“问答”走向“执行”，问题的重心便从“如何提问”迁移为“如何组织上下文”。

这里的上下文，并不只是system prompt。凡是进入模型视野、影响其下一步决策的信息，都可以算作上下文，例如：

• 提示词
• 用户输入
• 工具定义
• 工具返回的结果
• 历史对话记录
• 检索出的知识片段
• 长短期记忆
• 当前任务状态

那么怎样才能有效地组织这些信息呢？显然不是简单地机械填充进来。

2.1 RAG：破解“模型不掌握的私有知识”

私域知识（如产品文档、内部规范、历史记录）通常远超上下文窗口，无法一次性输入模型，因此需要“先检索，再生成”。

RAG的核心价值在于：让检索结果贴合任务语义，而不仅仅是字面匹配。
比如搜索“苹果”，既可能命中“5元一斤的水果”，也可能命中“8000元的手机”，但真正有用的信息取决于当前任务的语境。

一个经典笑话是：女朋友说“我要买苹果，给我转点钱”，你转了100块，心想买20斤水果绰绰有余——然而她其实想买的是手机。

RAG的发展也经历了明显的观念起伏：

• 曾一度流行：“RAG解决一切”
• 随着上下文窗口扩大、微调能力增强，又出现了“RAG已死”的声音

但在实际应用中：

• 企业知识问答 / 内部文档检索 / 规范辅助 → RAG仍是关键
• 代码仓库导航 / 精确定位问题 → Grep、Glob、日志、Git等方式更加直接有效

这背后的本质并非RAG失效，而是：
不同任务需要不同的信息获取机制

三维建模，从我开始关注数码科技的那一天起，就一直是横亘在普通人面前的一道高墙。专业门槛之高，让许多人望而却步。

但就在周末，当我像往常一样浏览各种新涌现的AI工具时，一个令人瞠目结舌的东西闯入了我的视野。

它的强大程度，甚至让我产生了一种预感：未来手办厂商和初级建模师，或许真的要面临大规模的冲击。

我说的就是这款名为 Hi3D（全称 Hitem3D）的工具。

不知道大家过去是怎么制作 3D 模型的。以我自己的经历来看，想要得到一个真正能用的模型，往往需要在各类三维软件里花费大量时间反复打磨。如果要从零开始学习，还得啃下一部又一部晦涩难懂的教程。并不是教程本身不好，而是这些专业内容天然存在着不低的壁垒。

然而，Hi3D 的出现，彻底瓦解了我对 3D 建模的畏惧之心。

它的核心逻辑简洁到近乎粗暴。

你只需要给出一张平面的 2D 静态图片，它就可以原地将其转化为一个可以 360 度旋转、全方位把玩的 3D 模型。

为了验证它是否言过其实，我立即上手做了一番测试。

先从一个简单的案例开始，给大家一个直观的印象。

这是我在港澳旅行时随手拍摄的一张照片。

将照片上传之后，大约两分钟的时间，当结果呈现出来的那一刻，我确实被惊艳到了——它直接生成了一个细节精准、纹理极为真实的 3D 模型。

紧接着，我便将模型文件导入家里的 3D 打印机。数小时后，一座承载着旅途记忆的建筑，就变成了一件实实在在的、可以摆在桌面上的专属手办。

这种从视觉图像到物理实体的跨越实在令人兴奋。建筑上那极为复杂的轮廓、石砖的纹理，甚至是锋利的边缘，全部被清晰地保留了下来。

我查阅了一下相关资料，发现这背后是一项名为 Sparc3D 的算法。

传统的 3D 重建算法，往往需要先将三维数据压缩到二维空间，再从这些二维信息重建回三维。这个过程不可避免地会丢失大量细节。

但是 Sparc3D 并没有走这条捷径。

它基于稀疏卷积网络与 3D 变分自编码器（VAE）技术，直接从源头消除了这种转换误差，实现了输入与输出的几乎无损映射。

更令人咋舌的是，在建模效率猛增 90% 的同时，生成时间反而加快了 6.7 倍。使用最新的 V2.1 版本，两分钟就能完成一个 3D 模型。

整个过程如丝般顺滑。

再来看另一个例子。我曾经在参观三星堆时，隔着展柜玻璃拍下一张青铜人像的照片。

在 3D 重建领域，人像和复杂结构可谓是最具挑战性的硬骨头。因为我们人类的眼睛对人脸的差错极度敏锐。

我决定用这张照片继续考验它的能力。

为了让最终效果达到完美，我先借助一款 AI 生图工具，把这张照片处理成白底的等轴测视图。

指令是这样写的：

“为图片中央的物体生成一张真实的等轴测照片，物体居中，白色背景，无阴影。”

然后，我把这张白底图上传，选择他们最新的 2.1 模型，点击生成。

在互联网行业，无论是程序员还是产品经理，工作中几乎离不开画图。

• 需求评审时需要画图。
• 技术方案设计也离不开图。

画图最耗时的往往不是梳理逻辑，而是拖拽图形、连线、调整位置、修改字体和箭头样式，这些机械操作浪费了大量时间。

以实际工作为例，最常用的图无非三种：

• 流程图：用于梳理业务流程

  

• 时序图：展示各系统间的交互顺序

  

• 架构图：体现系统功能模块与分层关系

  

过去纯手工绘图，很难绕开 ProcessOn、draw.io、Excalidraw 这类平台。

我最常用的是 ProcessOn，它上手快，内置大量模板，画图体验很流畅。但它是收费的，我连续付费5年！（真心疼）

现在有了 AI，会员到期后我没有再续费，因为 AI 画图已经足够方便了。

个人看法：不只是我，在 AI 时代，传统的 SaaS 工具公司会面临更大挑战。一个程序员借助 AI 能在很短时间内开发出具备70%以上功能的替代平台。

draw.io 虽然免费，但成品的美观程度一般，界面也没有 ProcessOn 顺手，我几乎不用，不过很多同事（尤其产品经理）喜欢用，大概是看中它完全免费——还要什么自行车呢！

Excalidraw（网址：https://excalidraw.com）可能有些朋友还不太了解。

这个网站能做出非常好看的手绘风格图示，颜值很高，内置了丰富的手绘素材。比如下面这张用户注册流程图，就是典型的手绘效果：

然而，无论是上面哪一个平台，本质上仍需要手动绘制。（尽管 ProcessOn 现在也提供了 AI 绘图功能，但需要会员才能使用。）

进入 AI 时代，画图这件事已经彻底变了。

如今，像流程图、时序图这类图表，完全可以用自然语言“Vibe”出来。架构图虽然复杂一些，也同样可行（文章末尾会讲到）。

还在手工一点一点拖拽绘图吗？时代真的不同了！

AI 生成图像的两种方式

借助 AI 生成图表，主要有两种方法。其一是利用 Mermaid 和 PlantUML 这类基于文本的绘图语法。

两者都能用，但如果让我推荐，我更偏向 Mermaid。原因很简单，它对 AI 更加友好。

而且主流的 AI 对话工具，如 DeepSeek、元宝、豆包、ChatGPT 等，内部集成的就是 Mermaid 语法。

快速生成流程图

例如，你可以直接对豆包说出需求：