開發 on kenji.blog

LogicPad 開發秘辛

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

為「不會寫程式碼，但有邏輯的人」提供工具。創建 LogicPad 的理由

你好，我是 kenji。我是低程式碼工具「 LogicPad 」的作者。這次不是介紹產品，而是想從有點個人的角度來寫寫「為什麼想做這個？」的開發幕後，以及我自己的想法。

說實話，這不僅僅是一個工具開發。我的過去、職場上的煩惱、技能組合，以及一直縈繞在心頭的「總有一天想做自己的產品」的想法—— 這些全部重疊在一起的結果，誕生了 LogicPad。

也就是說， 這對我來說也是「人生集大成的專案」 。我將盡可能坦率地、充滿熱情地寫下這樣的背景。

坦率地說，我想要一個可以挺起胸膛說「這是我做的」產品

說實話，這是最初的動機。

從以前開始，無論是工作還是興趣，我都喜歡寫程式碼。我也參與過各種開發。但是，有一天我突然意識到。 「沒有一個以自己的名字、自己的責任推向世界的產品」 。

當然，團隊製作的東西有價值，也有很多值得驕傲的工作。但是在某處，也有一種「就這樣，在別人的名字下結束職業生涯嗎」的虛無感。

一次就好。 我想留下一個可以挺起胸膛說「這是我做的」的東西。 帶著這樣的想法，我開始構思 LogicPad。那是大約 6 年前（ 2019 年左右）的事情。（最初的想法本身是在大約 2015 年前了解到 Unreal Engine 的視覺化程式語言 Blueprint 時產生的。）

因為不會寫程式碼所以無法著手。那不是很可惜嗎？

我的職場裡有很多優秀的人。

他們能建構邏輯。能自如地使用 Excel 函數，也能看穿問題的本質。但是——在「寫程式碼」這個階段，手就停住了。

「這個作業，每次都看著步驟書做，不能自動化嗎？」「嗯，可以喔。但是…那必須寫程式碼呢…」

這樣的對話發生過很多次。

每次我都這麼想。 「明明懂邏輯，卻因為程式碼這堵牆而停下來，真是太可惜了」 。

低程式碼編輯器，這個選項

其實在前一份工作中，我從事的是透過 GUI 操作運行的 2D CAD 開發。說到 CAD，就是用滑鼠來組裝圖形對吧。也就是說，這是一個 「透過操作來建構邏輯」 的世界觀。

我想：「這和低程式碼非常契合呢」。

再往前追溯，從學生時代開始，我一有想法就會馬上寫程式碼，大量製作影像處理、數值處理、Windows 工具、SNS 自動發文工具等小程式。我想有 600 多個。現在也還留在 GitHub 上。

當時並沒有考慮什麼意義。只是「想做所以做」。僅此而已。

但是現在，在製作 LogicPad 的時候…

我感覺那些點終於連成了一條線。

易於使用，但功能強大。平衡的困難

在推進開發的過程中，我一直考慮的是 「讓它成為一個直觀易用，同時又非常強大的工具」 。

如果增加功能，能做的事情就會變多。但是，會變得難以使用。如果簡化，任何人都能接觸。但是，那樣又會有人覺得不夠。

為了不被說「低程式碼工具只是玩具吧？」。但是，也不想被說「結果還是必須寫程式碼嘛」。

我一直在直覺和表現力那條極限的線上戰鬥。

無數次重做 UI，無數次丟棄，然後終於接近覺得「這樣可以」的形態時，我真的很高興。

第一次被「使用者」的一句話拯救了

第一次把 LogicPad 交給的是前同事。她不擅長 IT，也怕程式碼。但是，她擅長邏輯。

稍微說明並讓她試用後…幾分鐘後她說的一句話，我至今難忘。

「如果是這個，我也覺得我能做到！」

真的，我快哭了。我想給她的，就是這個。

不是會動的工具，而是 「我自己做出來了！」的感覺 。我確信，那才是 LogicPad 真正的價值。

能製作的人增加的話，社會會變得更有趣

我認為「技術的民主化」非常重要。

技術有改變世界的力量。但是，能駕馭它的人是有限的。

如果，只要「懂邏輯」就能製作應用程式的話？

更多的人，將能夠轉到「製作方」。 而且，從那裡誕生的東西，我認為會超越現在的想像。

如果 LogicPad 能成為那個入口。希望能成為一個把「想做」變成「能做」的工具。

那就是我的願望。

結語

LogicPad 還是 Beta 版，並未完成。需要改善的地方，想做的事情，還有堆積如山。

但是，我把 自己人生的「點」全部傾注到了這個工具中。 現在我可以挺起胸膛說。

「這是，我自己製作的產品」 。

👇附錄：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開發真的非常輕鬆。檔案I/O？總之能運作。網路？嘛，能連上。資料庫？用JSON就可以了吧。 UI？ChatGPT已經幫我寫出React程式碼了。支付？Stripe的API大概複製貼上就行了。

在這裡，你會產生一種錯覺：「我，是不是已經是個工程師了？」但是，真正的地獄從這裡才開始。

為什麼會卡關？

理由很簡單，因為「AI雖然能做出看起來像樣的東西，但最終調整還是全丟給人類」。

因為檔案I/O導致資料消失
資料庫正規化不夠嚴謹導致搜尋緩慢
UI不夠直覺
沒有進行壓力測試，流量一集中就崩潰
被Apple/Google的審查退回
觸及法律規範要求而差點引發公關危機

也就是說， AI擅長製作「外表看起來已完成的原型」 ，但 將其打磨成「真正在世上行得通的產品」，至今依然是人類的工作 。

但是，這裡存在一個悖論

在這裡，我們會發現一個悖論。

如果未來AI真的變得什麼都能做到了呢？也就是說，當「安全性、計費、設計全都能由AI完美處理」的時候呢？

到那時候， 人類可能根本不再需要製作應用程式了 。

因為只要使用者直接對AI說「我想做這件事」，即使沒有應用程式，任務也會被立即執行完畢。

🌀 舉例來說

以前我們會「為了計算而開啟計算機應用程式」，但現在只要說「Hey Siri，12乘32是多少？」就結束了。

同樣地，如果說「請AI幫我編輯照片並分享」，可能根本不需要經過應用程式的UI或API，處理就已經完成了。

換句話說， 當「用AI製作應用程式」這個目標實現時，或許就會迎來一個根本不需要應用程式的世界 。

說到底，我們現在能做什麼

那麼，我們該怎麼辦呢？

現在「第八合目以上」仍然是人類的領域，所以要精進這部分
專注於本質上的使用者理解與服務設計
思考「有價值的東西」而不是「能被做出來的東西」
甚至，探索「不侷限於應用程式形式」的價值提供方式

AI是工具、是升降機，有時也是競爭對手。但是， 「要做什麼」以及「為什麼要做」，依然是我們人類面臨的課題 。

總結：

AI開發的壁壘，並非技術問題，而是結構上的悖論

這是一個任何人都能到達富士山第八合目的時代。但從那之後才是真正的考驗。

而且，當我們終於登頂時，或許會迎來一個讓我們重新思考：「我們真的有必要爬這座山嗎？」的未來。

Market-in 與 Product-out

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

Market-in 與 Product-out

大家好，我是 kenji。

有時候在商業書或是企劃書上，

「我們是 Market-in 策略」「這個是 Product-out 型呢」

會看到類似這樣的說法，但是……

等等，Market-in？ Product-out？哪個比較厲害？？？

大家不會這樣覺得嗎？

所以這次，我想把這個「Market-in」和「Product-out」盡量講得白話一點，稍微帶點辛辣的觀點來看看。

簡單來說…

Market-in ：傾聽市場（Market）的聲音，並配合它來製造商品
Product-out ：把我們自己覺得好的東西（Product）做出來並推向世界

就這樣。很簡單。

舉個拉麵店的例子…

Market-in 的拉麵店會說，「最近家系拉麵很流行呢。好，那就來點滿滿的油脂和大蒜吧！」

Product-out 的拉麵店則是，「我做的這碗豆乳羅勒鹽味拉麵真的是最棒的，快吃吃看吧。」

哪個才是正確答案呢…其實都對

Market-in 因為貼近顧客需求，所以「賣得好的機率很高」，但很難產生突破性的想法。

Product-out 則是「把我們相信的正義具象化」，所以很有個性且吸引人，但一旦搞錯了，就無法引起任何人的共鳴。

iPhone 感覺像是 Product-out

在大家說著「才不需要智慧型手機呢」的時代，Apple 推出了 iPhone。

這已經是 完全 Product-out 的成功案例了。

如果當初聽了用戶的聲音，只會得到「沒有鍵盤的手機？不可能啦」然後就結束了。

但是 Product-out 很容易變成「自我滿足」

有時候會有些企業或人說，「因為我們是 Product-out 型」，但是，

欸，這不就只是無視用戶嗎？

有時也會讓人這麼想。

「因為想做就做了。但是賣不出去」這不是 Product-out，而是「自以為是-out」呢。

Market-in 也有陷阱

另一方面，Market-in 也不是萬能的。

如果說著「只要是用戶要求的我們全做！」，產品的核心就會動搖，結果誰也吸引不了。

不斷地增加功能，回過神來才發現變成了一個混亂的工具，大概就是這種感覺。

真正厲害的，是「兩者兼具的人」

厲害的產品，能精準地提出「用戶真正需要，卻無法用言語表達的東西」。

也就是說，「用 Product-out 的發想，取得 Market-in 式的共鳴」。

這說起來簡單，但其實超級困難的。不過，如果能做到這點，就會一口氣變成「神級產品」。

結論：比起言語，用戶的反應才是一切

Market-in 還是 Product-out。哪一個才是對的，這其實是沒什麼意義的問題。

「是否有確實傳達到用戶心裡？」這才是一切 ，我是這麼認為的。

「我們是偏向哪種策略」之類的，等之後能寫進簡報裡就好了吧，我大概是這樣想的。

以上，就是關於 Market-in 與 Product-out 的話題！

不要被奇怪的外來語迷惑，「結果到底該怎麼做才能讓人開心？」去思考這一點，才是最健全的。

那麼下次見囉～。

如何在 Windows 環境中安裝 Gemini CLI

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

【初學者指南】如何在 Windows 上安裝 Gemini CLI

「Gemini CLI」讓您可以從命令列使用 Google 的生成式 AI「Gemini」。本文將盡可能以淺顯易懂的方式，為您解說在 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. 安裝完成！接下來要做的事

至此，Gemini CLI 已經安裝在您的 Windows 上了。今後，您可以從命令列使用 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 或虛擬機器環境中也能舒適地運作。

能夠實現作業系統級別的進階控制

您還可以實現 使用一般語言和函式庫難以達成的控制 ，例如全域滑鼠和鍵盤鉤子（Hook）、視窗樣式的微調以及系統選單操作。

缺點

開發效率低

即使是 GUI 的建構也必須完全在程式碼中完成，有時 僅僅為了建立一個按鈕就需要幾十行程式碼 。修改設計也很繁瑣，且與使用 UI 框架的開發相比，生產力較低。

易於降低可維護性

有許多 具有特殊結構的程式碼 ，例如訊息迴圈和視窗程序，這阻礙了可讀性和可重複使用性。它還有不適合團隊開發和長期維護的方面。

難以支援現代 UI

很 難支援近年來要求的 UX ，例如高 DPI 支援、觸控介面、無障礙功能和深色模式。您必須手動處理每一項，這需要花費大量的精力。

不支援跨平台

由於它是一個完全 Windows 專用的 API，因此 無法移植到 macOS 或 Linux 。如果您計劃跨平台部署，則需要選擇其他技術。

學習成本極高

您必須了解 如今已很少使用的概念和機制 ，例如 Handles (控制代碼)、GDI、COM 和 OLE。許多文件都很舊，需要時間和耐心來學習。

適合的用途

輕量級工具 ，如檔案啟動器和快捷鍵輔助工具
系統實用程式 ，如剪貼簿操作和 IME 控制
基於原生控制的應用程式 ，如全域鉤子和視窗擷取
與硬體緊密連結的 驅動程式支援工具

不適合的用途

現代 UI / UX 重要的 一般消費者應用程式
考慮到速度而建立的 原型設計和 MVP 開發
基於長期運作和團隊開發的 大型專案
需要支援多個作業系統的 跨平台產品

評估總結

觀點	評估
執行速度	◎ 非常快
記憶體效率	◎ 優秀
開發速度	× 慢
可維護性	× 低
跨平台支援	× 不支援
現代 UI 支援	× 弱
作業系統控制自由度	◎ 壓倒性地高

結論

Win32API + C++ 是為那些「想要親自處理作業系統中所有事情」的開發人員準備的工具。 雖然其力量巨大，但學習和操作需要相應的決心。

是否值得「大膽選擇」取決於您目標應用程式的性質。

潛入 #include <windows.h> 的世界而不依賴 GUI 框架或現代語言 ―― 這個選擇在今天仍然有意義。