开源日记

京东又一开源神器，长视频更稳了。

Tue, 16 Jun 2026 15:08:27 +0800

Sora 关闭之后，AI 视频赛道就变得更火了。

国产这边，可灵、即梦、海艺都在发力，但长视频角色一致性仍是行业公认难题，目前能彻底解决的工具不多。

最近京东开源了JoyAI-Echo。

五分钟的视频中，人物的脸部、声音和服饰都可以保持不变，不会再出现越拍越不像自己的情况了。

JoyAI-Echo是京东JoyFutureAcademy团队所开发的一个长音频和视频生成框架。

目前在GitHub上已经获得了1600个Star，在短短两周的时间里增长速度非常快。

简单来说，它就是让 AI 视频里的角色更稳定。

几分钟的视频里，即使切换多个镜头，人物也不会突然变脸、变声，看起来更像是同一个人在演。

您的浏览器不支持 video 标签

怎么做到的？

它用 6大绝技解决角色一致性。

第一个叫「跨模态记忆库」，本质上是在治"角色老变脸"的毛病。

比如 AI 每次生成新的镜头的时候都得重新开始计算，并且没有任何的记忆，不知道上一个镜头里的主人公是什么样子，所以就容易出现偏差。

JoyAI-Echo 做法就是给 AI 配上一个“记忆库”。

当角色第一次出现的时候就把它的脸型、声音和穿着打扮等特征记录下来，并保存到记忆库里去。

在生成后面的镜头的时候，把之前的信息当作条件从记忆库中提取出来，并且强迫AI用同一个角色去绘制。

该记忆库有一个重要的设计就是把视觉与听觉结合起来。

不只是保存了人脸的照片，而且还保存了人的声音。因此在生成新的镜头的时候，不但脸是正确的，而且声音也是一样的人。

官方测评数据显示，语音内容正确率为0.8646，在用户的喜好测试中，音频质量为81.7%，优于其他产品。

第二个叫「DMD 分布匹配蒸馏」，针对的就是长视频生成太慢的毛病。

传统的多步扩散模型，在产生几秒钟到几十秒长的视频时会花费很长时间。

并且角色一致性的程度越高，所需要的计算量就越大，速度也就越慢。

JoyAI-Echo 使用了DMD分布匹配蒸馏技术来把多步扩散压缩为少步推理。

实现约7.5倍的速度提高，并且没有降低角色的一致性。

这个速度并不是以降低质量为代价来实现的，而是在不减少推理过程的前提下使整个流程更加简洁。

第三个叫「音视频联合生成」，本质上是在治"声音乱变"的毛病。

很多情况下声音会变得很杂乱，这是因为视频与音频是分别生成的。先制作好视频之后再用外部的声音工具进行配音，这样口型和台词就很难对上了。

JoyAI-Echo的做法是：一个管道同时输出视频和声音。

您的浏览器不支持 video 标签

对白、环境音和背景音乐都是一起产生的，在一个生成过程中就一起产生出来。

口型与台词是一起生成的，并不需后期人工修改。

在音频设置中，采样率为16000Hz、梅尔频谱bins为128、窗函数长度为96。

这些参数是为了保证音质和画面同步而设置的。

第四个叫「对话式编辑」，针对的是修改成本高的毛病。

比如你要把第三个镜头里的主人公换上红色的衣服，那么传统的工具就要从头到尾重新制作整个视频，成本就很大了。

JoyAI-Echo 有这样一个叫做Director Agent的功能，官方名称为“导演助理”。

你可以说“把第三个镜头里的主人公换上红色的衣服”，它只会修改这个镜头。

该功能还处于未发布的阶段，代码以及实际体验都没有对外公布。

但是从概念上来说，它所要解决的问题是另外一个问题：修改成本很高。

第五个叫「显存优化方案」，针对的是硬件门槛高的毛病。

是为了克服硬件要求高这个缺点而设计的。

JoyAI-Echo默认配置要46到50G显存，官方建议使用H100或A100，或者是至少48G以上的GPU，对于一般用户而言这个门槛还是有点高的。

不过官方也提供了一个降级方案。

将默认的241帧改为121帧之后，显存占用就会大大减少。

该项目还提供了一个ComfyUI集成方案，并且使用了官方节点包ComfyUI_JoyAI_Echo。

可以支持在48G显存下进行热切换，并且每个镜头都可以添加注释并且实时预览。

看完这些功能，相信各位已经迫不及待了。

如果要尝试的话，最简单的方法就是先克隆这个仓库。

git clone https://github.com/jd-opensource/JoyAI-Echo.git
conda env create -f environment.yml
conda activate echo-long

下载权重是最大的门槛，需要从 HuggingFace 下载约 46GB 的模型文件。

还有 gemma-3-12b 文本编码器，大约 24GB。

在prompts目录下创建一个json格式的提示文件，并且使用python inference.py来产生视频。

项目提供了一个叫做Prompt Enhancer的东西，可以将一个简短的故事想法变成有组织的镜头描写。

包含角色、动作、风格、镜头、背景、音效等各个方面，使生成的结果更加可控。

到这里缺点也给大家提提。

现在还不支持I2V（图像到视频），只可以由文字来产生，并且不可以使用图片作为起始帧。

LTX-2 Community License 只能用于学术研究以及非商业目的，在商业用途中需要与 Lightricks 联系。

目前只开放了推理代码以及权重，没有开放训练代码。

Director Agent 和 Echo-SR 超分模块标注为待发布，实际体验还没开放。

写在最后

JoyAI-Echo 支持本地部署。

视频素材不用上传云端，所有数据都在本地处理，隐私性更高。

如果你经常制作长视频，尤其在意人物一致性，它会比较有优势。

视频、配音和口型同步生成，不需要再额外找配音工具，也不用后期慢慢对口型。

环境配置完成后就能直接使用，也不用长期支付订阅费用。

当然，它对硬件要求不低，官方推荐约 46～50GB 显存。

这个门槛确实不算低，但对于有相关硬件配置、又经常制作 AI 视频的用户来说，还是很值得尝试的。

项目基于 LTX-2 Community License 协议开放，感兴趣的同学可以去 GitHub 仓库看看源码和文档。

开源地址：https://github.com/jd-opensource/JoyAI-Echo

既然看到这了，欢迎随手点赞、在看、转发，也可以给我个星标⭐，接收最新的文章，我们下期见！

3 天暴涨 9500 Star , 又一个 AI 神器火了。

Mon, 15 Jun 2026 15:08:49 +0800

3 天 9500 Star，又一个 AI 神器火了。

你有没有遇到过这种情况：

本来只是让 AI 把按钮的颜色改成别的颜色，结果它却创建了三个新文件，抽取了两层接口，并且顺便给你做了一个将来可能会用到的结构。

本来用 10 行代码就可以解决的问题，最后却变成了 100 多行。

今天我刷到一个爆火的项目 Ponytail，就是用来解决这个问题的。

简单来说就是：

让 AI 不要急于去写代码了，要先想一想是否真的要写那么多代码。首先不写代码，使用现有的方案，只写最少的代码。

假设你跟 AI 说："帮我加个邮箱验证功能。"

不用 Ponytail ，AI 一般会这样做：

先安装一个验证库，写一个自定义hook，封装成组件，导出类型定义，加个错误提示样式……一口气把所有的活都干完了之后。

多了 50 行代码和 2 个依赖。

就想验证个邮箱，至于要 50 行吗？

有了 Ponytail之后，AI 会这样做：

浏览器不是自带邮箱验证的功能么？

用 <input type="email"> 即可，只需要一行HTML代码，并且不需要JavaScript，不需要任何第三方库。

在同样的需求之下，从原来的 50 行变成了现在的一行。

Ponytail 的主要价值就是在开始写代码之前进行一次“是否需要”的审查。*

那么这套检测又是怎样进行的呢？

Ponytail把“不写代码”分成了六项标准来考核。

第一项叫作“YAGNI 检查”，其实就是对 AI 进行“过度设计”的一种方法。

首先问一下这件事是否存在呢？不需要的话就直接跳过，不要写出任何代码来过渡设计。

第二条就是“标准库优先”，主要是为了解决“装依赖成瘾”的问题。

现有条件能解决这个问题吗？在可以使用标准库的时候就不应该再增加新的依赖。比如日期格式化，AI 想要安装 moment.js，但是标准库中已经有 Date 对象了。

第三种就是“平台原生功能”，也就是先用平台自身提供的功能。

优先用平台自带的功能，不要自己去实现。像邮箱验证这种事情，在 HTML5 的 <input type="email"> 中就可以解决了，并不需要任何 JavaScript。

第四条为“已经安装的依赖复用”，防止对功能相同的包进行多次安装。

项目里包含的内容有哪些？如果能用到的话就用上它，不要重复安装。

第五条叫作“一行代码优先”，简单功能不需要有抽象层。

可以一行解决吗？可以的话就写一行，不可以的话就不搞抽象层了。简单功能不需要interface，wrapper，type export。

最后一条，也是六条里最实用的一条，叫「最小化兜底」。

如果以上方法都无效的话，才需要去写代码——但是要写出“最基本够用”的代码。

每一步都是一个难关。

项目作者还做了一组相当严谨的 benchmark 测试。

五项日常工作、三个模型、三种方式，在每个窗口进行十次运行后取中位数。

使人感到意外的是：

Claude 3.5 Haiku 裸跑 342 行，Ponytail 21 行，减少了 93.9%，成本降低了 77%。

Claude 3.5 Sonnet 裸跑 287 行，Ponytail 34 行，减少了 88.2%，成本降低了 62%。

Claude 3.5 Opus 裸跑 256 行，Ponytail 51 行，减少了 80.1%，成本降低了 47%。

从整体上看，代码量减少到了原来的80%-94%，成本下降了47%-77%，速度提升了3-6倍。

节省token就是节约成本，用 Claude Code 的话，16%的token节省就意味着你可以每个月少花几十刀。

benchmark数据比较

看完这些数据，相信各位已经迫不及待了。

Ponytail 支持的 AI 编程助手包括了主要的工具：

以Cursor为例来安装Ponytail：

git clone https://github.com/DietrichGebert/ponytail.git
cp ponytail/.cursor/rules/* .cursor/rules/

使用ClaudeCode的话，可以用 plugin 安装：

/plugin marketplace 添加DietrichGebert/ponytail
/plugin install ponytail@ponytail

安装完成之后就可以直接使用了，不需要进行其他的设置。

装完之后，多出几个实用命令，大家自己看。

什么时候该用 Ponytail？

看到这里，可能很多朋友会纠结，到底要不要装 Ponytail？

作为一个过来人，我的建议是，分场景。

场景A：日常开发和个人项目中使用Ponytail行吗？

如果需求是快速实现功能而不希望受到太多的工程化限制的话，那么Ponytail就是最好的选择了。

很低的代码膨胀率可以大大减轻维护的工作量。节省下来的时间用来写更多的其它功能。

场景B：写库，写SDK，团队大项目的时候，慎用Ponytail。

如果需求是为别人写SDK或开源库的话，就必须要包含完整的错误处理，类型导出以及边界条件覆盖。

此时Ponytail的“一劳永逸”就变成了一个坑。

写在最后

过去一年，整个行业一直在卷模型能力，比拼谁家的 Claude，GPT，Gemini 更聪明。

AI 写大一大堆代码后，维护的问题有谁真正想过吗？

就算模型很强，但每次都会给你塞一整堆冗余的代码，到最后你会发现买单的人还是你自己。

如果你每天在用 AI 写代码，又受够了那些"勤快过头"的输出，Ponytail 值得装一下。

项目基于 MIT 协议开放，感兴趣的同学可以去 GitHub 仓库看看源码和文档。

开源地址：https://github.com/DietrichGebert/ponytail

既然看到这了，欢迎随手点赞，在看，转发，也可以给我个星标⭐，接收最新的文章，我们下期见！

Agent 终端管理，终于有人做了。

Sun, 14 Jun 2026 15:08:00 +0800

一个终端项目，五个月斩获 22000 Star。

连 Ghostty 作者 Mitchell Hashimoto 都转发了,说这又是个基于 libghostty 做出来的东西。

它不是新语言新框架,就是个给 Agent 用的终端。

用一句话概括一下就是：

cmux 本质上就是帮你同时管理多个 agent 会话，让你一眼看出谁在等你输入，谁在跑什么任务 。

cmux 主界面

它把每一个AI Agent会话的状态都展示得一清二楚。

以前使用传统终端同时运行多个Claude Code会话的时候，最让人头疼的就是通知了。

当 macOS 的通知弹出来的时候，只会出现“Claude 正在等你回复”的字样，并不能知道是哪个agent，在哪个项目里被卡住了，又是哪一步被卡住的。

回到终端之后，十几张标签页挤在一起，标题被截断了，要想找到要输入的地方，只能一个个地点过去看。

cmux 的做法是把标签页改成垂直侧边栏，在每个工作区中都显示完整的状态信息。

垂直标签页侧边栏

01 垂直标签页侧边栏，解决的是标签页信息过载的问题。

传统的终端水平标签页，标题只能显示几个字符，打开很多的时候就会挤在一起，分不清楚哪个是哪个。

cmux 把标签页从横向变成了纵向，并且把它们放在了左边，在每一个工作区里都显示出了 git branch，PR 编号，当前目录，监听端口以及最新的一条通知信息。

一目了然地看到每一个agent在做哪个项目，卡在哪个环节上。

02 蓝色通知环，解决的是通知定位的问题。

传统上终端通知系统是没有上下文的，弹出来的时候看不出是哪个agent要你。

cmux的方式是在一个agent需要输入的时候，这个agent对应的面板四周会有一圈蓝光。

不需要一直盯着通知面板看，只要看到蓝色的灯亮起来，就说明那个窗口已经准备好要等你了。

用快捷键Cmd+Shift+U可以快速定位到最新的未读消息所在的agent上，并且不需要一个一个地去查找。

03 OSC 序列检测，解决的是通知兼容性的问题。

这套通知系统不只是给 Claude Code 用的，它通过 OSC 序列检测，能自动捕获终端发出的通知信号。

只要你的 agent 工具支持 OSC 9/99/777 这类序列，cmux 就能识别，一条 cmux hooks setup 就能把通知集成进去。

如果使用的是Claude Code，Codex，OpenCode，Gemini CLI等主流工具的话，cmux还提供hook自动安装的功能，即插即用。

内置浏览器面板

除了通知系统之外，cmux 还有浏览器面板。

这个设计有点特别，你可以在终端旁边分屏打开一个 WebKit 浏览器。

用以查看agent生成的网页，调试前端界面，让agent自己操作浏览器等。

更进一步的话，它提供了浏览器自动化API，来源于Vercel的agent-browser项目。

它解决的是agent和Web界面之间的交互问题。

可以使用CLI命令来获取agent snapshot页面的accessibility tree，点击元素，输入文本，执行JS等。

例如 cmux browser snapshot --interactive 可以得到页面结构， cmux browser click --surface surface:3 'e14' 可以点击到指定的元素。

让Agent不再局限于终端上运行，可以直接对浏览器界面进行操作，打通了终端和 Web 之间的隔阂。

如果在远程服务器上运行agent的话，浏览器面板的路由就会自动穿透到远程网络中去。

localhost 地址直接就能用，不用手动配端口转发，省掉了一堆折腾。

SSH 远程连接

cmux 还提供了一个 MCP Server，让 agent 控制 agent。

cmux-agent-mcp 有 81 个工具，它的设计理念就是用一个orchestrator agent来管理cmux，从而去管理其他的agent。

这套工具解决的是多 agent 协调的问题。

可以用来spawn新的agent会话，给正在运行中的agent注入提示，读取任意面板的输出。

也可以一次调用给多个agent分配不同的任务，例如让三个子agent分别负责前端，后端和测试，并且要对它们的输出情况进行监控。

这样就使cmux不只成为“终端”，而成为一个agent orchestration平台。

Claude Code Teams 模式

看到这，有些人可能想试试。

如果使用的是macOS的话，最简单的方法就是Homebrew：

brew tap manaflow-ai/cmux
brew install --cask cmux

安装好之后打开应用程序，如果之前你使用过Ghostty的话，cmux就会自动读取配置文件，并且继承你的主题，字体和颜色设置。

CLI 工具放在了应用包里面，如果要在外面直接使用的话，可以在 /usr/local/bin/cmux 上创建一个软链接。

然后运行 cmux hooks setup ，将Claude Code或者Codex的通知整合进来之后就可以使用了。

到这里缺点也给大家提提。

目前只支持 macOS 14.0 以上，Linux 版本还在计划中，Windows 没有官方提及。

SSH 功能还在不断更新中，tmux 的 detach/attach 机制已经比较完善了，目前 cmux 还不能实现 tmux 那样的功能，比如持久化会话，远程 detach 等。

该项目使用的是GPL-3.0协议，企业想要使用但是又不希望受到GPL合规限制的话，就需要购买商业授权。

写在最后

整体来看，cmux 不是要替代 tmux 或 iTerm2，而是定义了一个新类别：AI Terminal Multiplexer。

它主要的价值就是把“agent 并行管理”这件事情由人工去操作变成终端本身具备的能力。

经常同时跑 Claude Code 和 Codex CLI 的朋友，推荐试试。

项目基于 GPL-3.0 协议开放，感兴趣的同学可以去 GitHub 仓库看看源码和文档。

开源地址：https://github.com/manaflow-ai/cmux

既然看到这了，欢迎随手点赞，在看，转发，也可以给我个星标⭐，接收最新的文章，我们下期见！

一个产品经理必备 skill ，上热搜了。

Sat, 13 Jun 2026 15:10:35 +0800

产品经理用 AI 写文档，早就不是新鲜事了。

我试过用好几个 AI 来写 PRD。我发现真正让人头痛的是，AI 给你的是很多的文字，并不是可以执行的方法论。

AI 写了一个 PRD，它就给你生成几个页面的模板；让你做竞品分析，它就给你列出一串表格。

看起来很完整了，但是用的时候总感觉少了一点东西。

最近我在 GitHub 上刷到了一个叫 PM Skills 的项目。

三个月内拿到了 16000 多颗星星。

PM Skills Marketplace 做的事情很简单，就是把产品管理的方法论编码成可以被AI直接执行的工作流。

举个例子，你就明白了

遇到一个未知的需求，一般会这样。

打开 ChatGPT 或 DeepSeek。
输入 “帮我写一个用户访谈脚本”。
AI 给你一个通用模板。
自己先改一点，还是不清晰的。
再问 “对电商用户怎么改”，AI 又会给出一些建议。
你还要不断地修改，反反复复地进行好几轮。

而我装完 PM Skills ，直接在 OpenCode 里输入：

/interview-script

马上它就问我：

本次采访的目的是什么？

我给一个企业级的OA工作流系统的调研需求。

一分钟后。

创建了一个叫 customer-interview-oa-workflow.md 的文件。

里面记录了一些关于这个需求调研的内容。

我用Vs Code 打开并补充一些内容。

接着它根据我的回答来生成一个结构化的访谈脚本，里面包含了JTBD问题、满意度等内容。

从这个过程来看。很明显。

已经不需要自己去搭建框架了，AI 会带你完成整个过程。

这就是“给你文字”与“给你结构化的执行路径”的区别。

整个项目包含 9 个插件、 68 个技能以及 42 个命令，覆盖了产品的全生命周期。

从产品发现、战略规划、执行落地，到市场研究、数据分析、市场进入、营销增长，再到工具包和最新的AI交付，基本覆盖了产品经理工作中会遇到的所有场景。

它把所有产品的管理方法论都编入了AI 中。

01 发现产品的方法

每个“技能”都有一个对应的方法论或分析框架。

我用了 /opportunity-solution-tree ，本来是想让我画出一棵树状图，但它却一步步地引导我来构建Teresa Torres的OST——从结果出发，逆向推导出机会点、分解方案，最后通过实验来验证。

不是给你一个模板让你去填，而是问完一个问题之后再问下一个。

identify-assumptions-existing 也试了，按照价值、可用性、可行性、生存性这四个维度把我的产品中“默认没问题”的假设都揪出来了。

强的一逼。

02 命令与技能之间也有关系

那么命令与技能的区别是什么呢？

技能是独立的方法论，命令就是把多个技能组合起来完成一个过程。

比如 /discover ，它会让你看到整个产品发现的过程：创意产生、假设对应、排序优先、实验设计。不需要你自己来拼接流程了，AI会一步步地向你提问，并且一步步地带你前进。

03 产品的战略能力

战略相关的内容包括了产品的愿景、价值主张、商业模式和价格策略等。

/product-strategy 会帮你创建出包含九个部分的产品战略画布，并且从愿景一直写到可以防御的部分。而 lean-canvas 就是把整个Lean Canvas走一遍——我曾经填了很多次Lean Canvas，每次都会想，“这里应该填什么？”这样让它带上就快了。

04 定价策略能力

pricing-strategy 会帮你做定价模型、竞争分析、支付意愿评估和价格弹性考虑。

用前面提到的企业的OA系统需求来试试看，它会自动找出所有的竞争对手名单——这一点是没想到到的。

原来需要花上几天时间来整理的东西，现在分分钟就出结果了。

05 产品的执行能力

执行层面上最多的有16项，包括PRD、OKR、路线图、Sprint规划、发布说明等。

create-prd 会为你生成一个包含八部分的PRD模板，而 outcome-roadmap 则把功能列表转化为以成果为导向的路线图。

pre-mortem 最实用的就是在项目刚开始的时候就做一次风险分析，并且把Tigers、Paper Tigers和Elephants分开来。

以前需要开上半天会议才能想到的想法，现在也是很快就拿到结果了。

它不是随便给你一个模板让你去填，而是问完一个问题之后再问下一个。

它会向你提问、引导你的思考、帮助你做优先级排序——你才是做决定的人，它只是帮你把方法论走一遍。

看到这里的人可能会想试一试

我用 OpenCode 手动复制 Skills 来安装。

1. 将项目克隆到本地
git clone https://github.com/phuryn/pm-skills.git

2. 把所有的技能都复制到OpenCode文件夹里
mkdir -p ~/.opencode/skills
cp -r pm-skills/pm-product-discovery/skills/* ~/.opencode/skills/
cp -r pm-skills/pm-product-strategy/skills/* ~/.opencode/skills/
cp -r pm-skills/pm-execution/skills/* ~/.opencode/skills/
其他插件也是如此

3. 在 OpenCode 里直接用
比如说在产品发现上遇到问题的时候
为了提升用户留存率所设计出的一种机会方案树

到这里就缺点也给大家提一提了

Commands 只能在 Claude Code 和 Claude Cowork 中使用，在其他工具里只能用到 Skills。Windows 用户还会遇到不稳的情况。

另外，该项目比较适合有产品管理方法论基础的人。

如果对 Opportunity Solution Tree、Lean Canvas 等概念一无所知的话，在 AI 向你提问时可能会答不上来。

写在最后

关于方法论的问题，知道的人很多，能够实施的人却很少。

PM Skills Marketplace 把框架变成了一种流程，把知识变成了能力。

下次写 PRD 或者做战略规划的时候，可以让他带你转一圈。

有兴趣的朋友可以安装一下试试看。

开源地址：https://github.com/phuryn/pm-skills

既然看到这了，欢迎随手点赞、在看、转发，也可以给我个星标⭐，接收最新的文章，我们下期见！

画图这件事，我终于不用拖拽了。

Fri, 12 Jun 2026 15:10:07 +0800

画图这件事，我终于不用拖拽了。

原创开源日记开源日记

画架构图这件事，我折腾了好多年。

从 Visio 到 draw.io，从 ProcessOn 到 Excalidraw，工具换了好多次，但是核心问题一直没有解决：改图太麻烦。

改一个节点的位置，整个图的连线都要重新调整，半个小时就没有了。

团队合作的时候更加头疼，图表文件传来传去，版本控制很难做到，谁改了什么都不知道。

直到发现了D2这个项目之后，才发现原来画图也可以像写代码一样。

只需要用文本来描述“有什么”以及“谁连谁”，布局、对齐、样式等全部由引擎自动完成。

这个项目在 GitHub 上已经有 24300 Star，核心定位就是把文本转换成图表。

用声明式的语法来描述结构，它会帮你自动生成SVG或者PNG，不需要你手动去定位。

布局引擎会自动处理元素的位置，修改代码就是修改图片。

D2 的语法设计得非常克制，不需要学习很多复杂的命令。

基本 15 分钟就可以学会。

我打开 https://play.d2lang.com 体验了一把。

准备让他画出一个简单的服务架构图。

D2 会自动生成一个结构化的架构图，节点为矩形，箭头为连线。

我又找了一个例子，最前面加一行 direction: up 整个图形的箭头方向都反过来了。

体验下来的感受：

你不需要管组件放在哪里，只管它们之间有什么关系，修改结构的时候就修改代码。

布局会自动调整，不会出现“改一处地方整张图片都乱了”的情况。

你只管描述图长什么样，至于节点怎么摆、线怎么连，则交给底层布局引擎来处理。

这样的布局引擎，D2 内置了三种。

01 dagre 分层布局，这是默认的布局方式，适用于大部分情况。

这是默认引擎，适用于大部分情况，使用的是Graphviz DOT算法，效果稳定可靠。

02 ELK 节点链接布局，适用于有方向的复杂网络拓扑图。

更适合有方向的节点链接图，端口连接优化做的很好，可以适用于复杂的网络拓扑。

03 TALA付费引擎，针对软件架构图进行优化，效果最好。

专门针对软件架构图进行优化，多种算法组合在一起使用，效果最好但是要单独购买。

如果你对默认的效果不满意的话，可以换一个引擎试一试，不同的引擎得到的结果差别很大。

布局决定着图的结构骨架，而视觉表现力则依靠形状、样式来实现。

形状库也是专门为现代架构设计的，这点我很喜欢。

基础形状齐全，矩形圆形菱形圆柱体云形状都有，覆盖常见场景。

数据库用圆柱体，云服务用云形状，微服务用六边形——一行代码声明类型就可以，不需要手工绘制。

专业的形状很多，可以支持SQL表格时序图、LaTeX公式嵌入、图表展示等，非常实用。

甚至可以直接把SQL表格、时序图、LaTeX公式嵌入到图表中，在文档中需要配数据结构的地方就更加方便了。

这些形状不需要你手动绘制出来，只用设置好类型就可以了。

样式系统配置的方式也很简单。

填充色、边框、虚线、阴影都用属性声明的方式，官方还提供了一套专业的设计师制作的主题，直接使用即可。

还有手绘风格的 Sketch 模式，出来的图有随手画的感觉，很适合做演示用。

看到这里，应该有不少朋友会想试一试。

我给大家介绍两种打开方式。

最简单的。

直接打开官方 https://play.d2lang.com，在浏览器中就可以玩了。

还有喜欢命令行也可以。

用下面的一行命令就能搞定，无需复杂配置：

curl -fsSL https://d2lang.com/install.sh | sh -s

装完之后创建一个 hello.d2 文件，并写上几行代码，之后使用 d2 --watch 可以实现实时预览。

支持实时预览。

代码改了，浏览器里的图会自动刷新，调试很方便。

到这里缺点也给大家提出来。

自动布局是D2最大的优点之一，但是也意味着放弃了像素级别的位置控制。

对于需要精细排版的地方，它并不是最好的工具。

另外，在大图中，随着节点、层级的增多，编译的时间也会相应增加。

但是如果你只想要画软件架构图或者系统流程图的话，D2 的体验已经很好了，可以试一试。

写在最后

我觉得，D2 最大的价值不只是"画图更快"。

而把架构图也纳入到了版本管理的闭环当中。

改了代码就知道改了什么，团队协作不再靠"图-v2-最终版-final.png"来沟通。

如果你也经常在改图和传图之间消耗耐心，不妨花 15 分钟试试声明式绘图，也许会打开一个新思路。

开源地址：https://github.com/terrastruct/d2

既然看到这了，欢迎随手点赞、在看、转发，也可以给我个星标⭐，接收最新的文章，我们下期见！

继续滑动看下一个

开源日记

向上滑动看下一个

开源日记

京东又一开源神器，长视频更稳了。

它用 6大绝技解决角色一致性。

看完这些功能，相信各位已经迫不及待了。

到这里缺点也给大家提提。

写在最后

3 天暴涨 9500 Star , 又一个 AI 神器火了 。

Ponytail把“不写代码”分成了六项标准来考核。

项目作者还做了一组相当严谨的 benchmark 测试。

看完这些数据，相信各位已经迫不及待了。

什么时候该用 Ponytail？

写在最后

Agent 终端管理，终于有人做了。

除了通知系统之外，cmux 还有浏览器面板。

cmux 还提供了一个 MCP Server，让 agent 控制 agent。

看到这，有些人可能想试试。

到这里缺点也给大家提提。

写在最后

一个产品经理必备 skill ，上热搜了。

举个例子，你就明白了

它把所有产品的管理方法论都编入了AI 中。

看到这里的人可能会想试一试

到这里就缺点也给大家提一提了

写在最后

画图这件事，我终于不用拖拽了。

画图这件事，我终于不用拖拽了。

这样的布局引擎，D2 内置了三种。

形状库也是专门为现代架构设计的，这点我很喜欢。

看到这里，应该有不少朋友会想试一试。

到这里缺点也给大家提出来。

写在最后

3 天暴涨 9500 Star , 又一个 AI 神器火了。