本文目的：沒有甚麼目的，就是這 30 天心態上的紀錄。想到甚麼就寫甚麼，有點亂請見諒

(我希望這篇是鐵人賽的最後一篇，因此先上傳。施工中，預計10/18完成)

本專欄編寫的環境

我這 31 篇文章皆是在 heptabase 中編寫，特點是一個 section 都可以化成一張卡片，並且很容易建立卡片間的關聯。它的優缺點如下：

缺點

• Notion 能使用的 markdown 格式更多一些

• Notion 支援超多種表格與顯示方式，在資料/時間管理方面的能力更強

• 好貴，最便宜的年付方案平均一個月也要 $ 270 (台幣)，若使用 AI 功能需要更高階方案或是自己申請 api 連接並買額度 (貴應該是我的問題不是軟體定價問題)

優點

• 結合卡片盒筆記與視覺化展示的白板，可以清楚展示資料間的關係。例如下面是我在看深度學習原理時寫下的筆記，可以看到不同的卡片以視覺化方式清楚呈現彼此關聯 (這裡看更多範例)

  

• 容易看出資料之間的聯繫，例如可以看到下面這張卡片中有其他那些卡片跟它連線或引用它，並且可以直接連結到那些卡片

  

• 寫文章時可以同時顯示編輯中卡片、相關資料(先前寫過的卡片、相關網頁等)以及 AI 對話框。我在寫文時要使用 AI 時可以不用切換視窗非常方便

• 提供日誌功能，可以先在日誌中寫下草稿並在有空時整理

• 有在聽 podcast 的的話有內建的將 podcast 轉成逐字稿功能

我是看了這篇文之後開始使用 Heptabase。我使用 Heptabase 的原因是因為 Heptabase 比起 Notion 更適合用於學習。一次寫完整的筆記很困難，但若是寫像上面"卷積層“那樣的筆記就很簡單。我的習慣是在看書時簡單寫下像上面各式各樣的小卡片，在時間較多時將這些筆記放到白板上並尋找卡片間的功能並畫線

將卡片攤開、放置於白板上並畫姻緣線，這個過程中一定會思考關連並對建立自己對這個領域的架構。Heptabase 的白板非常適合這樣子視覺化的整理筆記方式，也因此在整理時對於整體架構就會有清楚的認知。

(雖然我常拿來寫日記、運動紀錄、毛線織圖等有的沒的，因為 好貴 )

本專欄編寫的動機

這篇鐵人賽的誕生與 AI 有強烈關聯，雖然我的內容上偏向自己設計程式。

我原本的工作內容是產品製程規劃、管理樣品交期、製程開發等項目(就是產品工程師啦)，但是因為我學生時接觸過數值分析、也參與了新產品專案，因此開始使用 Python 腳本處理大量的數據。

在編寫腳本的時候我實際遇到幾個問題：

• 我不知道要怎麼把 UI 元件接上 method，我不知道公開介面要怎麼設計

• 每做一個新的分析，連"讀取檔案並清洗"這種重複的事都要一直重寫

• 腳本又臭又長，看得我頭昏眼花

• 換個輸出格式(例如6行變成7行)就要確認許多地方，像新開一個專案

• 找 bug 找好久才發現是 dict 的 key 打錯

• 族繁不及備載 ……

因為犯過的錯誤罄竹難書，因此我在今年 3 月某天下班時隨手點開 GPT 寫了個人背景與工作內容，並在最後問了一句”軟體工程師是怎麼設計程式的”。這個對話如果用 A4 紙印出可以印出 215 頁，於是 AI 就成了我模組化開發的家教。

我跟 AI 這樣對話之後並照做與討論之後，我寫程式的思考方式和年初有很大的不同。我現在編寫程式時會花蠻大心力在「如何讓程式碼更容易重複使用與修改」，而不是會動就好。

我認為 AI 在我們這種跨領域的學習者來說，最大的好處 AI 會提點我們認知以外的「其他領域的知識」，而這些東西很可能我們根本不知道要去學習。

我之前想自己寫 GUI 程式時便有買相關書籍並在裡面看到「UI 與 main」要分開這種描述，但沒有清楚的寫到職責分離與 MVC （也可能是我當時根本看不懂）。我是在與 AI 討論「如何像一個軟體工程師？」的過程中才知道有 MVC 架構這種寫法。

若我是沿著工作內容演變、與自己的認知設計學習地圖，很可能不知道要去了解模組化程式設計。我會一路資料分析工作下來、可能知道更多數據或圖像分析的方法，但還是被各種長又複雜的腳本困擾著。

TL;DR

本專欄的寫作手法

我買了不少程式教學的書籍（很當然大部分都沒看完）。我不知道是不是我不會挑書，大部分的