Krita：从草稿到成品的开源绘画工具，其开发流程与 AI 禁令值得注意
Krita 是一款免费开源跨平台应用程序，它提供了基于 KDE 和 Qt 框架从头开始创建数字艺术文件的端到端解决方案。
秒懂
- 它是什么？
- Krita 是一款面向数字艺术家的跨平台绘画软件，基于 KDE 和 Qt 构建。本文从其定位、工作机制、构建方式到开发限制，给出工程视角的评估。
- 适合谁用？
- Krita 适合需要完整数字绘画流程的艺术家和工作室，尤其是漫画、插画、概念设计领域。它不适合需要频繁集成 AI 辅助功能的团队，因为项目明确禁止在开发中使用 AI 工具，直到 2026 年 10 月。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
Krita 解决什么问题，谁在用
Krita 是一个自由开源的数字绘画应用，目标是从零开始创建数字艺术文件，覆盖从草稿到成品的全过程。它的目标用户是漫画艺术家、插画师、概念艺术家、matte 和纹理画家，以及数字 VFX 行业。这意味着它不是通用图像编辑器，而是专注于绘画工作流。对于工程师来说，Krita 的价值在于它是一个可扩展的、跨平台的 C++ 项目，基于 KDE 和 Qt 框架，适合需要深度定制绘画工具的团队。但如果你只是偶尔画个示意图，Krita 可能过于庞大。
工作机制：基于 KDE 和 Qt 的架构
Krita 构建在 KDE 和 Qt 框架之上，这意味着它的核心是 C++ 和 Qt 的图形界面层。从仓库布局看，它使用 CMake 构建系统，并且有专门的开发文档指导构建。它的架构设计围绕数字绘画的特定需求，比如笔刷引擎、图层管理和色彩管理。这些功能不是简单的图像处理，而是需要低延迟的交互，所以 Qt 的事件循环和 OpenGL 加速是基础。文档中提到 Apidox，说明有公开的 API 文档，开发者可以扩展功能。但具体的数据流和模块划分，从 README 中无法确认，需要查阅在线文档。
如何获取和运行：从源码到 CI 构建
获取 Krita 的方式有几种。普通用户可以直接从官网下载稳定版，或者使用 nightly 构建。对于开发者，README 指向了在线构建文档，地址是 https://docs.krita.org/en/untranslatable_pages/building_krita.html。CI 构建产物可以从 https://cdn.kde.org/ci-builds/graphics/krita/master/ 获取，这是不稳定版。稳定版在 https://cdn.kde.org/ci-builds/graphics/krita/krita-5.2/。如果你需要调试符号，可以找 CI 中的 linux-debug-weekly 作业，下载 AppImage。对于 ASAN 构建，需要设置环境变量，例如在 Linux 上执行 export ASAN_OPTIONS=new_delete_type_mismatch=0:detect_leaks=0，然后运行 AppImage。Windows 上类似，但要注意 cd 到 bin 目录，否则 ASAN 无法定位 llvm-symbolizer.exe。
CI 与发布状态：nightly 的盲区
README 中有一个 CI 状态表，覆盖 master、stable 和 release 分支，但明确标注 nightly 构建不在覆盖范围内。这意味着 nightly 版本可能没有经过相同的测试保障。对于依赖 nightly 功能的开发者，这是一个风险。同时，当前 master 分支的 Feature Freeze 和 String Freeze 状态都是允许的，说明项目正在活跃开发新功能。但发布节奏不明确，因为 README 没有提供最近的 release 信息。如果你需要稳定的生产环境，应该依赖 stable 分支，而不是 master。
开发政策：AI 禁令与协作方式
Krita 社区有一个明确的 AI 禁令，禁止在开发中使用 AI 工具，直到 2026 年 10 月。原因包括社区共识缺失、KDE 缺乏政策、以及 AI 发展不确定性。这意味着如果你计划为 Krita 贡献代码，不能使用 AI 辅助编程工具。对于企业用户，这影响不大，但如果你依赖 AI 提高开发效率，可能需要重新评估。协作方式上，开发者主要在 libera.chat 的 #krita 频道交流，讨论论坛在 krita-artists.org。Bug 报告通过 KDE 的 Bugzilla 系统。
局限性与错误工具场景
Krita 的局限性首先体现在许可上，整个项目是 GPL-3.0，虽然个别文件可能兼容其他许可，但整体上如果你要闭源分发，会有限制。其次，它的定位是绘画，不是照片编辑或矢量设计，所以不适合这些场景。技术层面，nightly 构建缺乏 CI 覆盖，可能不稳定，尤其是 master 分支。另外，AI 禁令可能让一些开发者感到不便，特别是那些习惯用 AI 工具写代码的人。如果你需要的是一个轻量级的绘画插件，Krita 的完整应用可能过于重量级。
替代方案：与 MyPaint 的差异
一个常见的替代方案是 MyPaint，它同样是开源的绘画工具，但架构不同。MyPaint 专注于笔刷引擎，使用 Python 脚本扩展，而 Krita 是完整的应用，支持动画、矢量图形和复杂的色彩管理。MyPaint 更轻量，启动快，但功能范围窄。Krita 的图层系统和滤镜更丰富，适合专业工作流。如果你的需求只是快速素描，MyPaint 可能更合适；如果需要端到端的绘画流程，Krita 更全面。从技术栈看，MyPaint 使用 GTK，而 Krita 使用 Qt，这会影响集成方式。
维护与升级成本
Krita 的维护成本取决于你如何使用。如果你只是使用预编译版本，升级是简单的替换。但如果你从源码构建，需要跟踪 CI 构建和依赖变化。README 提供了 ASAN 和 debug 构建的流程，说明项目重视调试支持，但这也意味着你可能需要配置环境变量和符号工具。许可方面，GPL-3.0 要求衍生作品同样开源，所以如果你的团队计划修改 Krita 并分发，必须遵守。AI 禁令是一个额外的政策成本，你需要确保贡献者遵守。总体而言，Krita 的维护成本中等，但政策限制需要提前规划。
编辑结论
Krita 适合需要完整数字绘画流程的艺术家和工作室，尤其是漫画、插画、概念设计领域。它不适合需要频繁集成 AI 辅助功能的团队，因为项目明确禁止在开发中使用 AI 工具，直到 2026 年 10 月。在采用前，应先确认你的团队能遵守这一政策，并检查 CI 构建的稳定性，特别是 nightly 版本，因为 README 指出 nightly 构建不在 CI 状态表的覆盖范围内。同时，注意 GPL-3.0 许可，如果你的项目需要闭源分发，Krita 的库可能不适用。最终判断：Krita 是一个功能成熟、社区活跃的绘画工具，但它的开发节奏和政策限制要求使用者有明确的合规预期。
社区笔记