开发 on kenji.blog

LogicPad 开发秘辛

Wed, 30 Jul 2025 23:51:35 +0900

为“虽然不会写代码，但懂逻辑的人”打造工具。开发 LogicPad 的理由

大家好，我是 kenji，低代码工具「LogicPad」的作者。这次不是为了介绍产品功能，而是想从我个人的视角，和大家聊聊开发的幕后故事，以及我为什么想要做这款工具。

老实说，这不仅仅是一次单纯的工具开发。我个人的过往经历、在职场中的苦闷、自身的技能储备，以及内心深处一直按捺不住的“总有一天要做一款自己的产品”的渴望—— 这一切交织在一起，最终孕育出了 LogicPad。

也就是说，这对我而言，是一个“集人生大成的项目”。我想尽可能真诚、充满热情地写下这些背景故事。

坦白讲，我就是想要一款能理直气壮地说“这是我做的”的产品

说实话，这是我最初的动机。

一直以来，无论是在工作还是在业余爱好中，我都非常喜欢写代码。也参与过各种各样的开发项目。但是，有一天我突然意识到： “我还没有一款以自己的名字、由自己负责、推向世界的产品。”

当然，团队合作打造的产品很有价值，也有很多让我引以为傲的工作。但在内心深处，我也会感到一丝空虚：“难道我就要这样，在别人的名字下结束我的职业生涯吗？”

哪怕只有一次也好。 我想留下一样东西，能让我挺起胸膛说：“这是我做的。” 怀着这样的想法，我开始构思 LogicPad。大约是在 6 年前（2019年左右）。（而最初的灵感，其实可以追溯到更早的 2015 年左右，当时我了解到了虚幻引擎的视觉化编程语言 Blueprint。）

因为不会写代码就无法动手实现。这难道不可惜吗？

在我工作过的地方，有许多非常优秀的人。

他们懂得梳理逻辑。能熟练运用 Excel 的各种函数，也能一眼看穿问题的本质。但是——一到“写代码”这一步，他们就束手无策了。

“这个工作我每次都要看着操作手册做，能不能自动化呢？” “嗯，可以的。不过……那需要写代码才行……”

这样的对话上演过无数次。

每次我都忍不住想： “明明都懂逻辑，却被代码这堵墙挡住了去路，这真的太可惜了。”

低代码编辑器，一种新的选择

其实在上一份工作中，我参与了可以通过 GUI 操作的 2D CAD 软件开发。所谓的 CAD，不就是用鼠标把图形拼搭起来吗？也就是说，那是一个 “通过操作来构建逻辑” 的世界。

我当时就觉得：“这和低代码简直是绝配啊。”

如果再往前追溯，从学生时代起，我就一直在做图像处理、数值计算、Windows 工具、社交媒体自动发帖工具等等。一有灵感我就会马上写代码，量产了很多小程序。我觉得起码有 600 多个。现在它们还留在我的 GitHub 上。

当时我并没有考虑过这么做的意义。只是单纯地觉得“想做，所以就做”。仅此而已。

但是现在，在开发 LogicPad 的过程中……

我感觉，那些散落的点终于连成了一条线。

简单易用，但同时要功能强大。把握平衡的难题

在推进开发的过程中，我一直在思考的是： “如何打造一款既能直观使用，又真正强大的工具。”

如果一味增加功能，能做的事情自然会变多，但工具也会变得难用。如果为了追求极简，那谁都能上手，但这又满足不了部分进阶用户的需求。

为了不让人说“低代码工具不过是玩具吧？” 同时，也为了不让人抱怨“到头来还不是得自己写代码。”

我一直在“直观性”与“表现力”这两者的极限边缘挣扎。

我无数次推翻重做 UI，又无数次将其抛弃，直到终于做出了让我觉得“这个方向能行”的雏形时，我真的非常开心。

第一个“用户”的一句话拯救了我

我第一次把 LogicPad 交给别人试用，对象是我的一位前同事。她不擅长 IT，对代码也感到恐惧。但是，她的逻辑思维很强。

我稍微向她解释了一下，让她自己操作试试……几分钟后她说的那句话，我至今都无法忘记。

“如果用这个的话，感觉我也能做到了！”

那一刻，我真的快要哭出来了。原来我想带给大家的，就是这种感觉。

比起一款能运行的工具，那种“我自己做出来了！”的成就感。我深信，这才是 LogicPad 真正的价值所在。

当更多人能成为创造者，社会将会变得更加有趣

我坚信“技术的平民化”非常重要。

技术拥有改变世界的力量。但是，能够掌握技术的人却是有限的。

如果只要“懂逻辑”就能开发应用呢？

就会有更多的人能够加入到“创造者”的行列中。 我相信，由此诞生出的事物，将会远远超出我们现在的想象。

如果 LogicPad 能够成为进入那个世界的入口。我希望它是一款能将“想做”转变为“能做”的工具。

这就是我的愿望。

结语

目前 LogicPad 还是测试版，并未完全成熟。还有许多需要改进的地方，也有许多我想加入的功能。

但是，我已经在这个工具上 倾注了我人生的全部“点滴”。 现在，我可以挺起胸膛说了。

“这，是我自己开发的产品。”

👇彩蛋：LogicPad 能做什么

通过拖拽构建处理流程
可以通过 GUI 处理条件分支、变量等
提供了多种 AI 协作节点
支持插入脚本，满足进阶用户的扩展需求
高精度的数学函数与数据处理（如无限精度的数值运算等）
为进阶用户提供了丰富的快捷键
支持 90 多个国家的语言

未来想做的事

与 AI 结合，通过自然语言生成逻辑
建立让用户可以自定义节点的机制
搭建一个可以分享自制节点和逻辑的平台

✍️后记

非常感谢您能阅读到这里。这不仅是一次工具开发，更是我将自己的经验、热情以及人生的片段倾注其中的一次挑战。

“虽然不会写代码，但我懂逻辑” 我希望通过 LogicPad，能让这些人凭借自己的力量，迎来一个 “能够去创造”的未来。

如果您哪怕只有一丝“想试试看”的想法，我都会感到无比欣慰。如果您感兴趣，请务必去尝试一下 LogicPad。

无论在使用后有什么感想，或是发现了什么问题，哪怕是再小的事情也没关系。您的声音，将成为推动这款产品迈出下一步的巨大力量。

今后也请多多关照。

AI开发的壁垒

Sun, 20 Jul 2025 21:52:42 +0900

AI开发的壁垒

〜虽然到了八合目，但接下来的路才是地狱〜

大家好，我是kenji。

最近，经常听到有人说“拜托AI，结果连应用都做出来了！”这样的话。我们已经越过了无代码(No-code)和低代码(Low-code)的时代，进入了“Vibe coding（凭感觉写代码）”之类的阶段。

例如，如果你说“做一个可以编辑图片并发布到社交网络的应用”，AI就会为你输出代码甚至UI。 很厉害吧，是不是觉得已经不需要人类了呢？

但是呢，那 就像穿着凉鞋降落在富士山的八合目一样 啊。

登到八合目之前看起来“轻而易举”

用AI进行开发，一开始真的非常轻松。文件IO？反正能跑就行。网络？嗯，能连上。数据库？用JSON就够了吧。 UI？ChatGPT给我吐出了React代码。支付？复制粘贴一下Stripe的API就行了。

到了这里，你就会产生一种错觉：“我该不会已经是工程师了吧？” 但是，真正的地狱才刚刚开始。

为什么会陷入僵局？

理由很简单，因为“AI做得有模有样，但最终的调整全都抛给了人类”。

文件IO会导致数据丢失
数据库缺乏规范化，搜索很慢
UI不够直观
没有做过压力测试，流量一集中就崩溃
被Apple/Google的审核拒绝
违反法律法规引发（差点引发）公关危机

也就是说，AI很擅长制作“看起来像是完成了的原型”， 但要把其打磨成“真正在世上行得通的产品”，至今依然是人类的工作。

但是，存在一个悖论

在这里我们会发现一个悖论。

如果将来AI真的什么都能做到了呢？也就是说，如果“安全性、支付、架构设计，全都能由AI完美处理”了呢？

到那时，人类制作应用的需求本身可能就不存在了。

因为，如果用户直接对AI说“我想做这种事”，任务就会无需通过应用而被立刻执行。

🌀举个例子

以前我们“为了计算而启动计算器应用”，现在只要说“Hey Siri，12×32是多少？”就搞定了。

同样地，只要说一句“用AI把照片处理一下并分享出去”，可能不用经过应用的UI和API，处理就已经完成了。

也就是说， 当“用AI制作应用”的目标实现之时，可能就会迎来一个应用本身已不再需要的世界。

到底，现在的我们能做些什么

那么，该怎么办呢。

既然现在“八合目以上”依然是人类的领域，那就去磨练那部分技能
专注于本质上的用户理解和服务设计
思考“有价值的事情”，而不是“能做出来的事情”
倒不如说，去探索“不局限于应用这种形式”的提供价值的方式

AI是工具、是上升的阶梯、有时也是竞争对手。但是，“要做什么”和“为什么要做”，依然是我们人类去提出的问题。

总结：

AI开发的壁垒，不是技术，而是结构的悖论

这是一个谁都能登到富士山八合目的时代。但从那往后的路才是动真格的。

而且，等到终于登顶的时候，也许等待着我们的将是重新发问：“这山，我们有必要登吗？”的未来。

市场导向与产品导向

Tue, 15 Jul 2025 20:18:22 +0900

市场导向与产品导向

大家好，我是 kenji。

偶尔在商业书籍或策划书里，

“我们采用的是市场导向（Market-in）战略” “这是产品导向（Product-out）型呢”

会看到类似这样的话……。

但是，市场导向？产品导向？到底哪个更厉害？？？

大家会不会有这样的疑问呢？

所以这次，关于“市场导向”和“产品导向”这两个概念，我想尽量用通俗易懂的方式，带点辛辣地来聊一聊。

简单来说就是…

市场导向（Market-in）：倾听市场（Market）的声音，然后配合需求去制造商品
产品导向（Product-out）：把自己认为好的东西（Product）造出来，推向世界

就这么简单。非常纯粹。

比如用拉面店来打比方…

市场导向的拉面店，感觉就像是：“最近家系拉面很流行啊。好，我们就多放点油脂和大蒜吧！”

产品导向的拉面店，感觉就像是：“我做的这个豆乳罗勒盐味拉面，简直最棒了，你们快来吃吧。”

要说哪个才是正确答案的话…其实都对

市场导向因为迎合了顾客的需求，所以“畅销的概率很高”，但很难诞生出突破性的想法或创新。

产品导向则是“将自己坚信的正义具象化”，所以非常尖锐且充满魅力，但一旦没对上电波，就不会引起任何人的共鸣。

iPhone 就像是产品导向

在大家都说“智能手机根本不需要”的时代，Apple 推出了 iPhone。

这已经 完全是产品导向 的成功案例了。

如果听取用户的声音，肯定会被说“没有键盘的手机？不可能不可能”，然后就此结束。

但是产品导向很容易变成“自我满足”

偶尔会有企业或个人说“我们是产品导向型的”，

哎，那不就是单纯的无视用户吗？

有时候我也会这么想。

“因为想做就做了。但是没卖出去”，这不叫产品导向，而是“孤芳自赏”了。

市场导向也有陷阱

另一方面，市场导向也不是万能的。

如果说“只要用户有需求我们就全做！”，那么产品的核心就会动摇，最终谁也打动不了。

不断地添加功能，回过神来发现已经变成了一个混沌的工具，就是这种情况。

真正厉害的是，“两者兼顾的人”

优秀的产品，能够精准地把“用户真正想要，却无法用语言表达出来的东西” 呈现出来。

也就是说，“用产品导向的思维，去获得市场导向的共鸣”。

这话说起来简单，做起来却极其困难。但如果能做到这一点，就能一跃成为“神级产品”。

结论：比起词汇，用户的反应才是一切

是市场导向，还是产品导向。到底哪个才是正确的，这种问题其实没多大意义。

我认为，“有没有真正触达用户的心？”这才是全部。

至于“我们走的是偏向哪种的战略”，这种话只要事后能写在营销资料上就可以了。

这就是关于市场导向和产品导向的话题啦！

不要被奇怪的外来语迷惑，思考“到底怎么做才能让人高兴？” 我觉得这才是最健康的心态。

那么，下次见啦～。

如何在 Windows 环境下安装 Gemini CLI

Sun, 13 Jul 2025 23:49:56 +0900

【适合初学者】在 Windows 上安装 Gemini CLI 的方法

让您能够在命令行中使用 Google 的生成式 AI“Gemini”的工具“Gemini CLI”。在本文中，我们将尽可能以通俗易懂的方式，为您讲解在 Windows 环境下安装 Gemini CLI 的步骤。

1. 准备工作：安装 Node.js 和 npm

首先，由于 Gemini CLI 是在“Node.js”环境下运行的，因此您需要事先安装以下组件。

Node.js
npm（Node.js 附带的包管理工具）
npx（包含在 npm 中的命令执行工具）

请从以下官方网站下载 Windows 版的 Node.js（推荐使用 LTS 版本）：

👉 Node.js 官方网站

安装完成后，请使用以下命令确认是否已正确安装。

1
2


node -v
npm -v

2. 启动 PowerShell

在 Windows 上使用 Gemini CLI 时，通常会使用 PowerShell 进行操作。请从开始菜单中输入“PowerShell”并启动它。

3. 安装 Gemini CLI

将以下命令复制并粘贴到 PowerShell 中执行：

1

npx @google/gemini-cli

此命令旨在临时运行 Google 发布的 Gemini CLI 包。有时可能会要求您进行初始设置或登录。

※ 首次运行可能需要几分钟。如果出现错误，请仔细检查您的 Node.js 和网络环境。

4. 安装完成！下一步要做什么

至此，Windows 上的 Gemini CLI 就安装完成了。今后，您就可以通过命令行使用 Gemini 来进行文本生成、代码补全等各种操作了。

如果您想查看官方文档或帮助，也可以使用以下命令：

1

npx @google/gemini-cli --help

总结

让我们复习一下在 Windows 上安装 Gemini CLI 的步骤：

安装 Node.js 和 npm
启动 PowerShell
执行 npx @google/gemini-cli

这样准备工作就完成了！想要在本地使用生成式 AI 的朋友，请务必参考本文中的步骤进行尝试。

使用 Win32API + C++ 编写程序的优缺点

Sat, 12 Jul 2025 12:30:35 +0900

使用 Win32API + C++ 开发的魅力与挑战

对于想要深入 Windows 应用开发的人来说，Win32API + C++ 至今依然是一个强大的选择。这种组合能够以最近的距离与操作系统交互，兼具高速性与灵活性。

另一方面，由于其与现代的开发风格大相径庭，因此在学习上需要做好心理准备。

本文将从 现役 Windows 应用开发者的视角，浅显易懂地解说其优点与缺点。

优点

超高速的原生执行

C++ 和 Win32API 在最靠近操作系统的层级上运行，因此几乎没有多余的开销。其 CPU 和内存的使用效率极高，拥有 压倒性的执行速度。

极高的灵活性和自由度

无论是窗口控制、异步处理、COM 协作还是进程管理等，应用的任何行为都可以 自行进行精细控制。你也可以构建专用于特定目的的工具，或自制独有的框架等。

无需运行时，便于分发

无需像 .NET 或 Java 那样的外部运行时，只需一个可执行文件即可分发。在再分发时不易出现问题，无需安装程序也能轻松运行，这是其魅力所在。

能够制作轻量级应用

由于只需最小限度的配置即可，其特征是 内存占用非常小。即使在低配置的 PC 或虚拟机环境中也能流畅运行。

支持操作系统级别的高级控制

鼠标与键盘的全局钩子、窗口样式的微调、系统菜单操作等，也能实现 在普通语言或库中难以完成的控制。

缺点

开发效率低

GUI 的构建也完全需要通过代码来实现，有时 仅制作一个按钮就需要几十行代码。更改设计时的修改也很繁琐，与使用 UI 框架的开发相比，生产力较低。

维护性容易下降

消息循环和窗口过程等 结构特殊的代码 很多，在可读性和可重用性上存在困难。也有不适合团队开发或长期维护的一面。

适配现代 UI 很麻烦

高 DPI 适配、触摸界面、无障碍功能、深色模式等，很难应对近年来对 UX（用户体验）的要求。必须逐一手动进行适配，非常费力。

不支持跨平台

因为完全是 Windows 专用的 API，无法移植到 macOS 或 Linux。如果考虑到多平台部署，则需要选择其他技术。

学习成本极高

必须理解句柄、GDI、COM、OLE 等 在现代已经不太使用的概念和机制。文档也有很多是旧的，学习需要时间和毅力。

适合的用途

文件启动器或快捷键辅助等 轻量级工具
剪贴板操作或 IME 控制等 系统实用程序
全局钩子或窗口捕获等 原生控制系应用
与硬件紧密协作的 驱动辅助工具

不适合的用途

重视现代 UI/UX 的 面向普通消费者的应用
速度优先的 原型制作或 MVP 开发
以长期运营或团队开发为前提的 大规模项目
需要支持多个操作系统的 跨平台产品

评价总结

维度	评价
执行速度	◎ 非常快
内存效率	◎ 优秀
开发速度	× 慢
维护性	× 低
跨平台支持	× 不支持
现代 UI 支持	× 弱
OS 控制自由度	◎ 压倒性地高

结论

Win32API + C++ 是适合“想要自己处理操作系统的一切”的开发者的工具。 虽然它的力量非常强大，但在学习和运用上也需要相应的心理准备。

是否有“特意去选择”的价值，取决于你目标应用的性质。

不依赖 GUI 框架或现代语言，跃入 #include <windows.h> 的世界—— 这种选择，至今依然是有意义的。