1
提案數
0
諮詢數
0
成交數
0%
回覆率
- 軟體程式設計
- 網站架設
- 網路應用程式設計
- AI 聊天機器人
- AI 智能客服
- +5
我把每天要重複做的工作,變成不用人做的程式。 專長是自動化與系統串接:Excel 與資料庫批次處理、網頁公開資料擷取與定期報表、LINE 官方帳號機器人、第三方 API 整合、影音批次處理。 所有作品都在真實環境長期運行、有真實使用者,不是練習專案——包含一套 24 小時常駐的 API 監控系統(約 31,000 行程式碼)、一條每日自動執行的影片剪輯流水線,以及多個長期運作的社群機器人。 另有數位鑑識與資安分析背景,交付時會一併檢查資料保護與權限問題。 配合方式:需求先講清楚再報價,過程中有進度回報,交付含說明文件並附免費修改 2 次。不確定自己需要什麼也可以先聊,我會直接說做不做得到。
作品(5)
多份 Excel 合併月報(含對帳)
【需求】 三家門市各自匯出銷售明細,格式全都不一樣。每個月要有人手動貼在一起、對一遍、再做成月報。 【核心主張:合併 Excel 最危險的不是合不起來】 合不起來會噴錯,你馬上就知道。真正危險的是合起來了,但數字是錯的——少併了一家、或重複算了幾筆,報表照樣產出、格式照樣漂亮,你可能一整季都不會發現。 所以這支程式的重點不在合併,在於它會證明自己沒算錯:每個來源檔的「原始筆數/原始金額」與「併入後筆數/金額」都攤在對帳頁上,差額必須完全等於被移除的重複列。對不起來就不算成功,而且結果直接寫在總覽頁第一眼看得到的地方。 【第一件事:三家的日期是三種不同的東西】 一家是真正的日期型別、一家存成文字、一家是 Excel 序列數字。三種都要轉得動,而轉不動的不能猜——直接列進異常清單,附上原始值,讓人自己看。 【第二件事:我寫的去重刪掉了 80 列,而我只放了 5 列重複】 第一版用最直覺的做法:整列一模一樣就當重複刪掉。結果它刪了 80 列。 原因很簡單——同一天賣出兩杯一樣的拿鐵,在沒有交易編號的明細裡長得完全一樣,那是兩筆真實營收,不是重複。刪錯的後果是營收變少、報表照樣漂亮,沒有人會發現。 改成只認「連續三列以上完全相同」——那才是系統重跑一次匯出的特徵。落單的重複則只標記、不刪除,並在異常清單寫明「沒有交易編號無法區分,請自行確認」。 抓到這件事的不是我看程式碼,是自我檢查裡那條「應該剛好抓到 5 筆」。如果我只驗「程式有沒有跑完」,這個錯會一路跟到客戶那裡。 【第三件事:不認得的欄位不可以當作沒看到】 其中一家多了一欄「備註」。欄位對映做成白名單,對映不到的欄位會列進異常清單告訴你「這欄沒有併進報表」,而不是靜靜丟掉。你可能覺得它不重要,但那要你決定,不是程式替你決定。 【交付長什麼樣】 一個 Excel 檔五個分頁:月報總覽(KPI、營收圖表、對帳狀態)、明細(凍結窗格、篩選、退貨紅字)、品項排行、異常清單(每筆寫明類型與原因)、對帳。 實測:3 個來源共 571 列,併入 566 列,異常清單 7 筆,對帳全部通過。自我檢查 19 項全通過,其中 8 項是反向對照組。 【可交付】 合併程式、欄位對映設定、異常規則、月報範本、排程設定、原始碼與說明文件。新增門市或改欄位名只要改對映表,不用改程式。
- 軟體程式設計
讓程式自己發現自己死了
【為什麼需要這個】 自動化程式的價值不在「跑得動」,在「壞掉的時候有人知道」。沒有人盯著的程式一旦安靜失效,你會照常收到空報表、照常以為一切正常——直到幾週後才發現。 以下是我在自己所有長期運行的系統上實作的同一套機制,以及我親自踩過的坑。 【第一件事:監控最常見的失敗,是它自己騙自己】 一、它把自己當成偵測目標。檢查「某某程式還在不在」時,那道查詢指令本身的文字裡就含有目標名稱,於是它永遠找得到——包含目標其實已經死掉的時候。 二、排程回報「成功」不等於工作完成。排程啟動的往往只是一個啟動器,它把工作丟出去就回報成功,後面真正的工作成不成功它不知道。 三、正常關機被誤判成當機。我手動要求服務停止,看門狗判定它意外死亡,立刻又把它拉起來——想關的東西關不掉。 【第二件事:判斷失敗不能靠文字比對】 有一套失敗偵測整整一個月都沒作用:程式比對輸出裡有沒有 ERROR 這個字,但那台機器在實際執行的環境下輸出的是中文的「錯誤」,永遠對不上。改成比對錯誤代碼(語言無關)之後才真的抓得到。 同一次還學到一件更重要的事:有一類檔案永遠會被占用,導致每次都回報失敗。當紅燈永遠亮著,紅燈就沒有意義了——那個月的四十幾次警報全是噪音。把已知情況排除之後,警報才重新有價值。 【第三件事:我怎麼驗收監控本身】 只有一條標準:如果被監控的東西真的壞了,這個監控會不會叫?答不出來就等於沒有監控。 所以每一套我都會做「故意弄壞」的對照測試——不是看它在正常狀況下說 OK(那太容易了,一個永遠回 OK 的程式也會通過),是看它在壞掉時會不會說不 OK。 【可交付】 存活檢查、心跳機制、自動重啟、失敗告警(可送 LINE/Discord/Email),以及一份白紙黑字的清單:哪些情況它會叫、哪些情況它不會叫。第二項通常比第一項重要。
- 軟體程式設計
每日情報自動彙整與推播
【需求】 每天早上固定時間,自動去看八個來源有沒有新東西,有的話整理成一份 PDF 直接送到手機上。不用自己開八個網頁一個一個看。 【第一件事:「今天沒有新的」和「我抓壞了」長得一模一樣】 最直覺的做法是比對日期——抓到的東西是今天的就算新的。 問題是各家的日期格式都不一樣,有的根本沒有日期。只要日期解析失敗,程式就會很有精神地回報「今天沒有新消息」,然後你永遠不會發現它壞了。這是最貴的一種故障:安靜地壞掉。 所以這支程式不比對日期,改成比對「看過的識別碼」:每筆記下唯一 id,下次只跳過確定看過的。日期解析失敗最多讓同一則重複出現一次,不會讓整批消失。寧可吵一點,不要安靜地漏掉。 【第二件事:一個來源掛掉不能拖垮整份報告】 八個來源各自獨立抓取。其中一個超時或改版,其他七個照常產出——而且失敗的來源會列在報告最後面,不是靜靜跳過。你要看得到「今天有一個沒抓到」,才有機會決定要不要理它。 【第三件事:測試模式不可以留下痕跡】 開發時抓到兩個自己寫的坑:試跑用的 dry-run 竟然會把「已讀」狀態寫進紀錄檔,結果正式跑的時候那些消息全被當成看過的,一則都不會出現;另一個只產檔不呼叫 AI 的模式,會直接覆蓋掉當天已經產好的正式檔。 兩個都改掉了。判準是:任何會改到狀態的動作,都要先問「這在測試模式下該不該發生」。 【第四件事:刻意控制成本】 摘要用的是較便宜的模型,一天成本約 0.01~0.03 美元。這是想清楚才選的——這份報告的價值在「每天都準時有」,不在「每個字都完美」。花十倍的錢換一點文筆,對這個用途不划算,這種取捨我會先跟業主講。 【實測】 每天 09:00 自動執行,PDF 直接送達通訊軟體。約 1,095 行。 【可交付】 抓取程式、去重機制、內容摘要、PDF 排版、自動推播、排程設定、失敗回報、原始碼與說明文件。
- 爬蟲程式
LINE 官方帳號機器人(長期運行)
【需求】 把原本只能坐在電腦前才查得到的東西搬到 LINE 上,用手機就能問,而且要 24 小時在線。 【第一件事:不是每一句話都該丟給 AI】 最省事的做法是把使用者說的每一句都送進大型語言模型讓它自由發揮。但這樣有三個問題:查固定資料(訂單、餘額、進度)本來就有標準答案,交給 AI 反而可能講錯;每一句都在算錢;而且慢。 所以這支機器人分兩條路走:認得出來的關鍵字直接查資料回覆,完全不經過 AI——快、不花錢、而且永遠不會編。認不出來的才交給 AI。 對業主的意義是:常見問題的邊際成本是零,而且答案來自你自己的資料,不是模型想像出來的。 【第二件事:誰可以問什麼】 同一個官方帳號會有很多人加,但不是每個人都該看到所有東西。這支程式用 LINE 的使用者 ID 分權:一般人只能用公開功能,指定的人才查得到內部資料。權限判斷發生在查資料之前,不是先把資料撈出來再決定要不要顯示——後者只要有一次疏漏就是外洩。 【第三件事:訊息太長的下場是「已讀不回」】 回覆超過長度上限 LINE 會直接拒收,使用者看到的不是被截斷的訊息,是機器人「沒有回應」。所以長回覆會自動分段送出,而且切在換行處、不切在句子中間。 【第四件事:它必須自己活著】 長期運行的東西一定會掛:網路斷、對方 API 限速、碰到沒想過的輸入。這支用三層擋:每則訊息各自獨立容錯(一則出錯不會讓整個服務停擺)、程序層有看門狗定時確認還在不在、另外有心跳紀錄可以分辨「程序還在」跟「真的還在做事」——這兩件事不一樣,只看前者會讓你以為一切正常。 【規模】 約 1,066 行,實際長期運行中,每天有真實使用者在用,不是練習專案。 【可交付】 官方帳號設定、Webhook 伺服器、關鍵字與 AI 分流、權限規則、對話紀錄保存、監控與自動重啟、原始碼與說明文件。
- AI 聊天機器人
船期資料自動擷取與健檢
【需求】 定時抓取某國際海運公司的長程船期表,一天兩次,把資料原樣送到指定 API。不需要解讀資料,只要抓到並送達。 【第一件事:先確認這到底是不是爬蟲案】 對方網站是 Next.js 前端,畫面上的資料其實來自三支公開 REST API。實測用純 HTTP 呼叫、不開瀏覽器、不帶登入,三支全部正常回應。 這對業主的意義是:不必解析 HTML、不必養無頭瀏覽器,對方改版時也比較不會壞。同樣的需求,維護成本差很多。 【第二件事:「不用解析」不等於「不用檢查」】 業主說不需要判斷、不需要解析——這是對的,資料的詮釋權應該留在業主手上,我不該替他解讀任何一班船。 但如果完全不檢查,來源網站哪天改了欄位或臨時回空資料,程式仍然會「執行成功」,把一包空資料準時送到業主的 API,而業主可能好幾天後才發現。這是最貴的一種故障:安靜地壞掉。 所以這支程式不解析內容,但檢查形狀——「這批東西還像不像船期表」。有沒有停靠港、有沒有船、時間欄位長不長得像時間。任何一項不對就標記出來跟資料一起送出,讓業主自己判斷要不要用。 【第三件事:我會查證自己的警報】 第一次實跑時,程式對 19 條航線中的 13 條報了「時間格式錯誤」,共 308 筆。 我沒有直接當成資料有問題,去看那 308 筆的實際內容——全部是同一個字串 SKIP,那是航運業的正常狀態(該船當次跳過此港),不是錯誤,是我的檢查太嚴。 修正後改成:SKIP 視為正常,但出現任何沒見過的新狀態字串仍然報警,因為那才是「來源真的改了東西」的訊號。 如果我沒去查那 308 筆,交出去的會是一支每天發假警報的程式。而假警報比沒有警報更糟——第二週就沒有人會再看它了。 【實測結果】 19 條航線全數抓到,0 失敗,0 形狀警告,輸出 1.17 MB JSON。 自檢 11 項全通過,其中包含反向對照組(正常資料必須通過、SKIP 必須放行、沒見過的新字串必須擋下),確保檢查真的有區辨力,而不是永遠說 OK。 【我主動告知業主的一件事】 來源網站的 robots.txt 明確標示不希望自動程式存取 API 路徑。這不是法律規定,但那是網站方明確的意思表示。可以改走前端頁面(合乎其規範但較慢、較脆弱),也可以走 API(快而穩定)。這個取捨我認為應該由業主決定,不該由承接方默默替他選。 【可交付】 擷取程式、排程設定、資料送達、健康狀況回報、原始碼與說明文件。
- 爬蟲程式
作品(5)
多份 Excel 合併月報(含對帳)
【需求】 三家門市各自匯出銷售明細,格式全都不一樣。每個月要有人手動貼在一起、對一遍、再做成月報。 【核心主張:合併 Excel 最危險的不是合不起來】 合不起來會噴錯,你馬上就知道。真正危險的是合起來了,但數字是錯的——少併了一家、或重複算了幾筆,報表照樣產出、格式照樣漂亮,你可能一整季都不會發現。 所以這支程式的重點不在合併,在於它會證明自己沒算錯:每個來源檔的「原始筆數/原始金額」與「併入後筆數/金額」都攤在對帳頁上,差額必須完全等於被移除的重複列。對不起來就不算成功,而且結果直接寫在總覽頁第一眼看得到的地方。 【第一件事:三家的日期是三種不同的東西】 一家是真正的日期型別、一家存成文字、一家是 Excel 序列數字。三種都要轉得動,而轉不動的不能猜——直接列進異常清單,附上原始值,讓人自己看。 【第二件事:我寫的去重刪掉了 80 列,而我只放了 5 列重複】 第一版用最直覺的做法:整列一模一樣就當重複刪掉。結果它刪了 80 列。 原因很簡單——同一天賣出兩杯一樣的拿鐵,在沒有交易編號的明細裡長得完全一樣,那是兩筆真實營收,不是重複。刪錯的後果是營收變少、報表照樣漂亮,沒有人會發現。 改成只認「連續三列以上完全相同」——那才是系統重跑一次匯出的特徵。落單的重複則只標記、不刪除,並在異常清單寫明「沒有交易編號無法區分,請自行確認」。 抓到這件事的不是我看程式碼,是自我檢查裡那條「應該剛好抓到 5 筆」。如果我只驗「程式有沒有跑完」,這個錯會一路跟到客戶那裡。 【第三件事:不認得的欄位不可以當作沒看到】 其中一家多了一欄「備註」。欄位對映做成白名單,對映不到的欄位會列進異常清單告訴你「這欄沒有併進報表」,而不是靜靜丟掉。你可能覺得它不重要,但那要你決定,不是程式替你決定。 【交付長什麼樣】 一個 Excel 檔五個分頁:月報總覽(KPI、營收圖表、對帳狀態)、明細(凍結窗格、篩選、退貨紅字)、品項排行、異常清單(每筆寫明類型與原因)、對帳。 實測:3 個來源共 571 列,併入 566 列,異常清單 7 筆,對帳全部通過。自我檢查 19 項全通過,其中 8 項是反向對照組。 【可交付】 合併程式、欄位對映設定、異常規則、月報範本、排程設定、原始碼與說明文件。新增門市或改欄位名只要改對映表,不用改程式。
- 軟體程式設計
讓程式自己發現自己死了
【為什麼需要這個】 自動化程式的價值不在「跑得動」,在「壞掉的時候有人知道」。沒有人盯著的程式一旦安靜失效,你會照常收到空報表、照常以為一切正常——直到幾週後才發現。 以下是我在自己所有長期運行的系統上實作的同一套機制,以及我親自踩過的坑。 【第一件事:監控最常見的失敗,是它自己騙自己】 一、它把自己當成偵測目標。檢查「某某程式還在不在」時,那道查詢指令本身的文字裡就含有目標名稱,於是它永遠找得到——包含目標其實已經死掉的時候。 二、排程回報「成功」不等於工作完成。排程啟動的往往只是一個啟動器,它把工作丟出去就回報成功,後面真正的工作成不成功它不知道。 三、正常關機被誤判成當機。我手動要求服務停止,看門狗判定它意外死亡,立刻又把它拉起來——想關的東西關不掉。 【第二件事:判斷失敗不能靠文字比對】 有一套失敗偵測整整一個月都沒作用:程式比對輸出裡有沒有 ERROR 這個字,但那台機器在實際執行的環境下輸出的是中文的「錯誤」,永遠對不上。改成比對錯誤代碼(語言無關)之後才真的抓得到。 同一次還學到一件更重要的事:有一類檔案永遠會被占用,導致每次都回報失敗。當紅燈永遠亮著,紅燈就沒有意義了——那個月的四十幾次警報全是噪音。把已知情況排除之後,警報才重新有價值。 【第三件事:我怎麼驗收監控本身】 只有一條標準:如果被監控的東西真的壞了,這個監控會不會叫?答不出來就等於沒有監控。 所以每一套我都會做「故意弄壞」的對照測試——不是看它在正常狀況下說 OK(那太容易了,一個永遠回 OK 的程式也會通過),是看它在壞掉時會不會說不 OK。 【可交付】 存活檢查、心跳機制、自動重啟、失敗告警(可送 LINE/Discord/Email),以及一份白紙黑字的清單:哪些情況它會叫、哪些情況它不會叫。第二項通常比第一項重要。
- 軟體程式設計
每日情報自動彙整與推播
【需求】 每天早上固定時間,自動去看八個來源有沒有新東西,有的話整理成一份 PDF 直接送到手機上。不用自己開八個網頁一個一個看。 【第一件事:「今天沒有新的」和「我抓壞了」長得一模一樣】 最直覺的做法是比對日期——抓到的東西是今天的就算新的。 問題是各家的日期格式都不一樣,有的根本沒有日期。只要日期解析失敗,程式就會很有精神地回報「今天沒有新消息」,然後你永遠不會發現它壞了。這是最貴的一種故障:安靜地壞掉。 所以這支程式不比對日期,改成比對「看過的識別碼」:每筆記下唯一 id,下次只跳過確定看過的。日期解析失敗最多讓同一則重複出現一次,不會讓整批消失。寧可吵一點,不要安靜地漏掉。 【第二件事:一個來源掛掉不能拖垮整份報告】 八個來源各自獨立抓取。其中一個超時或改版,其他七個照常產出——而且失敗的來源會列在報告最後面,不是靜靜跳過。你要看得到「今天有一個沒抓到」,才有機會決定要不要理它。 【第三件事:測試模式不可以留下痕跡】 開發時抓到兩個自己寫的坑:試跑用的 dry-run 竟然會把「已讀」狀態寫進紀錄檔,結果正式跑的時候那些消息全被當成看過的,一則都不會出現;另一個只產檔不呼叫 AI 的模式,會直接覆蓋掉當天已經產好的正式檔。 兩個都改掉了。判準是:任何會改到狀態的動作,都要先問「這在測試模式下該不該發生」。 【第四件事:刻意控制成本】 摘要用的是較便宜的模型,一天成本約 0.01~0.03 美元。這是想清楚才選的——這份報告的價值在「每天都準時有」,不在「每個字都完美」。花十倍的錢換一點文筆,對這個用途不划算,這種取捨我會先跟業主講。 【實測】 每天 09:00 自動執行,PDF 直接送達通訊軟體。約 1,095 行。 【可交付】 抓取程式、去重機制、內容摘要、PDF 排版、自動推播、排程設定、失敗回報、原始碼與說明文件。
- 爬蟲程式
LINE 官方帳號機器人(長期運行)
【需求】 把原本只能坐在電腦前才查得到的東西搬到 LINE 上,用手機就能問,而且要 24 小時在線。 【第一件事:不是每一句話都該丟給 AI】 最省事的做法是把使用者說的每一句都送進大型語言模型讓它自由發揮。但這樣有三個問題:查固定資料(訂單、餘額、進度)本來就有標準答案,交給 AI 反而可能講錯;每一句都在算錢;而且慢。 所以這支機器人分兩條路走:認得出來的關鍵字直接查資料回覆,完全不經過 AI——快、不花錢、而且永遠不會編。認不出來的才交給 AI。 對業主的意義是:常見問題的邊際成本是零,而且答案來自你自己的資料,不是模型想像出來的。 【第二件事:誰可以問什麼】 同一個官方帳號會有很多人加,但不是每個人都該看到所有東西。這支程式用 LINE 的使用者 ID 分權:一般人只能用公開功能,指定的人才查得到內部資料。權限判斷發生在查資料之前,不是先把資料撈出來再決定要不要顯示——後者只要有一次疏漏就是外洩。 【第三件事:訊息太長的下場是「已讀不回」】 回覆超過長度上限 LINE 會直接拒收,使用者看到的不是被截斷的訊息,是機器人「沒有回應」。所以長回覆會自動分段送出,而且切在換行處、不切在句子中間。 【第四件事:它必須自己活著】 長期運行的東西一定會掛:網路斷、對方 API 限速、碰到沒想過的輸入。這支用三層擋:每則訊息各自獨立容錯(一則出錯不會讓整個服務停擺)、程序層有看門狗定時確認還在不在、另外有心跳紀錄可以分辨「程序還在」跟「真的還在做事」——這兩件事不一樣,只看前者會讓你以為一切正常。 【規模】 約 1,066 行,實際長期運行中,每天有真實使用者在用,不是練習專案。 【可交付】 官方帳號設定、Webhook 伺服器、關鍵字與 AI 分流、權限規則、對話紀錄保存、監控與自動重啟、原始碼與說明文件。
- AI 聊天機器人
船期資料自動擷取與健檢
【需求】 定時抓取某國際海運公司的長程船期表,一天兩次,把資料原樣送到指定 API。不需要解讀資料,只要抓到並送達。 【第一件事:先確認這到底是不是爬蟲案】 對方網站是 Next.js 前端,畫面上的資料其實來自三支公開 REST API。實測用純 HTTP 呼叫、不開瀏覽器、不帶登入,三支全部正常回應。 這對業主的意義是:不必解析 HTML、不必養無頭瀏覽器,對方改版時也比較不會壞。同樣的需求,維護成本差很多。 【第二件事:「不用解析」不等於「不用檢查」】 業主說不需要判斷、不需要解析——這是對的,資料的詮釋權應該留在業主手上,我不該替他解讀任何一班船。 但如果完全不檢查,來源網站哪天改了欄位或臨時回空資料,程式仍然會「執行成功」,把一包空資料準時送到業主的 API,而業主可能好幾天後才發現。這是最貴的一種故障:安靜地壞掉。 所以這支程式不解析內容,但檢查形狀——「這批東西還像不像船期表」。有沒有停靠港、有沒有船、時間欄位長不長得像時間。任何一項不對就標記出來跟資料一起送出,讓業主自己判斷要不要用。 【第三件事:我會查證自己的警報】 第一次實跑時,程式對 19 條航線中的 13 條報了「時間格式錯誤」,共 308 筆。 我沒有直接當成資料有問題,去看那 308 筆的實際內容——全部是同一個字串 SKIP,那是航運業的正常狀態(該船當次跳過此港),不是錯誤,是我的檢查太嚴。 修正後改成:SKIP 視為正常,但出現任何沒見過的新狀態字串仍然報警,因為那才是「來源真的改了東西」的訊號。 如果我沒去查那 308 筆,交出去的會是一支每天發假警報的程式。而假警報比沒有警報更糟——第二週就沒有人會再看它了。 【實測結果】 19 條航線全數抓到,0 失敗,0 形狀警告,輸出 1.17 MB JSON。 自檢 11 項全通過,其中包含反向對照組(正常資料必須通過、SKIP 必須放行、沒見過的新字串必須擋下),確保檢查真的有區辨力,而不是永遠說 OK。 【我主動告知業主的一件事】 來源網站的 robots.txt 明確標示不希望自動程式存取 API 路徑。這不是法律規定,但那是網站方明確的意思表示。可以改走前端頁面(合乎其規範但較慢、較脆弱),也可以走 API(快而穩定)。這個取捨我認為應該由業主決定,不該由承接方默默替他選。 【可交付】 擷取程式、排程設定、資料送達、健康狀況回報、原始碼與說明文件。
- 爬蟲程式
服務(3)
評價(0)
--
尚無資料
--%
專案完成率
尚無資料
諮詢印象
尚無資料,期待您聯絡後的真實感受
- ??
- ??
- ??
- ??
- ??
- ??
- ??
- ??
專案執行
尚無資料,給新星專家一個展現的機會!
整體推薦
溝通契合
專業能力
準時交付
回覆速度

