技術 Day 12：客觀錯誤直接修、判斷空間大的先討論——這條界線怎麼畫

前言 「查核結果出來了,不管是什麼問題,直接照查核結果改掉不就好了？」 如果每個查核結果都直接照改，會出現一個問題：有些查核結果是「這句話講的規則有例外情況沒提...

技術 Day 26：案例——長期未解決的 issue，AI 怎麼幫忙重新評估優先序

前言：不是每個 issue 都該立刻處理，但也不該被遺忘 「這個 issue 開了三、四個月都沒動，是不是不重要？還是只是排不進時間？」 維護一個有真實使用者的...

技術 Day 11：案例——用分批派工的方式查核多篇文章裡的技術主張

前言 「一篇文章裡的技術主張,自己重讀一遍不就查得完了嗎？」 單篇文章確實可以自己重讀查核,但當手上累積到十幾、二十篇文章、每篇都可能包含好幾個可查證的技術主張...

技術 Day 10：事實查核為什麼不能只憑內部踩坑經驗的記憶

前言 「這個技術細節我們踩過坑,親身經歷過,還需要另外查證嗎？」 親身經歷過的踩坑經驗,證明的是「在那個特定情境下,某個現象確實發生了」,不代表對這個現象的原因...

技術 Day 09：案例——一條去識別化規則怎麼從「漏抓一次」變成一支自動化掃描工具

前言 「人工複查已經很仔細了,為什麼還要另外寫一支掃描工具？」 因為「已經很仔細」跟「不會漏」是兩件事。這個系列的寫作規範裡明白寫著一句話:已經整理過的素材筆記...

技術 Day 08：去識別化不是「發文前掃一次」,是動筆當下就要做的決定

前言 「反正寫完會跑掃描工具檢查,動筆的時候先寫,寫完再一起改不就好了？」 這個順序聽起來省事,但實際上把風險留到了最不該留的地方。草稿一旦寫進磁碟,就已經是一...

技術 Day 07：一份好大綱長什麼樣子——貫穿主題句、分部結構、案例配置

前言 「講了六天怎麼規劃大綱,可以直接給我一份檢查清單嗎？」 可以。這篇是第一部的收尾,把前六天分散講過的元素收攏成一份大綱完成前可以逐項核對的框架。這份框架不...

技術 Day 06：跟 AI 一起規劃 30 天大綱時,人要保留哪些判斷

前言 「大綱都讓 AI 生成了,那還有什麼是需要人保留的？」 Day 02 講過大綱規劃的粗略分工:人定主題句跟邊界、AI 拆解結構。這篇要把「人保留的判斷」講...

技術 Day 05：案例——報名最後一天,加開一個新系列的完整判斷過程

前言 「都報名最後一天了,乾脆別加了吧,風險這麼高幹嘛還要多做一個系列？」 這確實是一個合理的保守選項,而且在很多情況下應該是正確答案。這篇不是要說服你「臨時加...

技術 Day 04：賽制規則本身要先讀懂——完賽條件、當日快照、字數門檻

前言 「規則不就是常識嗎？每天寫一篇、字數夠、內容切題,有什麼好特別讀的？」 規則的大方向確實是常識,但魔鬼藏在幾個容易被忽略的細節裡——例如「當天修改必須當天...

技術 Day 03：案例——多個系列同時進行,怎麼確認彼此的素材分工沒有撞題

前言 「不同系列講的技術主題不一樣,怎麼可能撞題？」 如果每個系列的素材來源都完全獨立,這個疑慮確實不成立。但當手上有好幾個系列的素材其實來自同一個真實經驗——...

技術 Day 02：為什麼要先跟 AI 一起規劃大綱,而不是想到標題就動筆

前言 「反正 AI 寫得快,想到什麼寫什麼,寫不下去再讓 AI 幫忙接下一篇不就好了？花時間規劃 30 天大綱,不是本末倒置嗎？」 這個想法在只寫一篇文章的時候...

技術 Day 01：把「參加鐵人賽」拆解成可以跟 AI 協作的任務

前言 「你不是已經在寫好幾個技術系列了嗎？幹嘛還要另外寫一個講『怎麼參賽』的系列，這不是套娃嗎？」 這個疑問很合理。如果鐵人賽只是「每天寫一篇技術文章」，那確實...

技術 7. 吃吃記帳 - 最小可行性產品 (Minimum Viable Product)

現在，我們已經有了吃吃記帳的產品發想、人物誌 Persona、使用者故事 User Story，和顧客旅程地圖 Customer Journey Map，還有流...

技術 1. 起始點 - 給自己的功課

為什麼要做 Side Project? 最近，我對自己的工作產生了迷惘：我是否朝著正確的方向成長、前進？雖然考過了 PMP ，並且接手了一個大型的 global...

徵才 【徵才】顧問類 - 助理顧問師 （專案管理）

公司簡介 PCCW Solutions 電訊盈科企業方案是 PCCW 電訊盈科集團 (香港上市公司 0008.HK) 旗下的 IT 服務公司，亦是於亞太地區各行...