今天我們來看一個和“能不能按時把事做完”直接相關(guān)的方法論Getting things done (in small increments)2022。這個主題說的不是讓你用更復(fù)雜的時間管理軟件也不是堆一堆待辦清單而是先把“完成一件事”的方式改掉讓每一步都足夠小、可以驗證、可以快速拿到反饋。對于經(jīng)常寫代碼、做批量任務(wù)、維護倉庫、寫文檔的人來說這套思路最直接的價值在于你不再需要一口氣憋出幾十個文件、一個大改動、一次長周期交付而是把最終目標拆成若干個小塊每一塊都能獨立推進、獨立驗證、甚至獨立發(fā)布。這正好對應(yīng)技術(shù)團隊里常見的小步提交、持續(xù)集成、灰度發(fā)布也和任務(wù)批量處理中的“小批驗證”邏輯一致。這篇文章會把“小增量”拆開講清楚為什么大任務(wù)常常做不完小增量到底小到什么程度怎么拆怎么用工具輔助怎么驗證自己確實在推進。如果你正在被長周期任務(wù)、無限拖延、倉庫里長期不合并的分支、批量任務(wù)一次跑完才報錯這些問題困擾這篇值得讀完。1. 核心思路速覽先把這套方法論的規(guī)格擺出來方便快速判斷適不適合你。維度說明方法論類型任務(wù)執(zhí)行、工程效率、項目管理實踐核心原則小步拆解、可驗證成果、短反饋循環(huán)適用對象開發(fā)者、運維、研究測試人員、內(nèi)容生產(chǎn)者、技術(shù)管理者主要工具Git、終端、任務(wù)追蹤工具、輕量腳本學(xué)習(xí)成本低核心概念當天可以上手硬件需求無普通開發(fā)機即可見效周期通常數(shù)天到數(shù)周取決于執(zhí)行頻率主要風險任務(wù)拆得不夠小、驗證標準缺失、反饋周期太長這里的“工具”不需要指定某個特定產(chǎn)品。你用 Obsidian、Notion、Todoist、GitHub Projects、Excel、甚至一張 Markdown 清單都可以關(guān)鍵是執(zhí)行節(jié)奏要符合“小增量”三個特征每個任務(wù)單元在 1 到 4 小時內(nèi)可以完成一個可驗證成果。每完成一個單元不需要等待其他單元也能確認“這個部分確實有效”。每個單元之間有清晰的先后依賴關(guān)系不會越做越亂。2. 為什么“一次性做大任務(wù)”往往做不成技術(shù)工作里最常見的失敗模式不是能力不夠而是任務(wù)粒度太大。大任務(wù)會帶來四個問題。第一是認知負荷。一個任務(wù)包含太多步驟時大腦很難在開始前把狀態(tài)完整加載出來。你會有“不知道從哪里動手”的感覺于是一直反復(fù)讀資料、一直準備環(huán)境、一直拖延。這是開發(fā)者在長周期需求上最常見的卡點。第二是心理阻力。一個需要兩周才能完成的功能每次打開編輯器都像面對一座山。而小步推進只需要你面對一個明確的、短期的、可交付的小塊心理負擔會明顯降低。第三是反饋延遲。大任務(wù)往往要等全部做完才能看到效果。如果某個底層假設(shè)錯了你要到最后一個星期才發(fā)現(xiàn)返工成本極高。小增量則會在最早時間暴露問題因為每個單元都會經(jīng)過驗證。第四是上下文切換成本。做長周期任務(wù)時你可能同時維護多個未完成線每次切回來都要重新回憶。小步提交配合清晰記錄能大幅減少這種“重新加載狀態(tài)”的開銷。技術(shù)領(lǐng)域里的具體表現(xiàn)很典型一個倉庫里長期不合并的大分支、一次生成幾百個文件后才發(fā)現(xiàn)批量任務(wù)的某個參數(shù)全錯、一篇技術(shù)文章攢到全部寫完才給同學(xué)看結(jié)果結(jié)果方向偏了。這些都是“不必要地放大任務(wù)粒度”的代價。3. 小增量方法論的核心概念小增量不是說把任務(wù)“碎片化”。碎片化是沒有邏輯地切分而小增量是按照“可驗證成果”來切分。一個任務(wù)單元由幾個部分組成組成部分作用示例目標描述說明這個單元完成后能得到什么完成批量圖片壓縮腳本輸入條件明確依賴什么才能開始已有待處理圖片目錄、壓縮工具已安裝執(zhí)行步驟具體的操作路徑讀取目錄、逐張壓縮、輸出到新目錄驗收標準證明這個單元成功的證據(jù)壓縮后圖片體積平均下降 60%清晰度可用反饋方式誰、用什么方式確認完成本地運行腳本查看輸出日志關(guān)鍵區(qū)別在于驗收標準必須是可執(zhí)行、可觀察的而不是“感覺差不多”。下面是一個適用性很廣的任務(wù)拆解模板# 任務(wù)XXX ## 小增量 1準備和驗證環(huán)境 - 目標確認本機能跑通最小示例 - 輸入開發(fā)環(huán)境已安裝、示例數(shù)據(jù)已下載 - 步驟 1. 按官方文檔安裝依賴 2. 運行官方示例 - 驗收示例輸出結(jié)果與文檔一致 - 負責人 ## 小增量 2實現(xiàn)最小處理邏輯 - 目標對單個輸入執(zhí)行核心處理邏輯 - 輸入一份測試素材 - 步驟 1. 編寫核心函數(shù) 2. 用單條輸入跑通 - 驗收單條輸入輸出符合預(yù)期 ## 小增量 3擴展到批量處理 - 目標對目錄內(nèi)全部輸入執(zhí)行批量處理 - 輸入小批量測試數(shù)據(jù)10 個文件以內(nèi) - 步驟 1. 循環(huán)調(diào)用核心函數(shù) 2. 記錄失敗項 - 驗收批量運行成功失敗項有日志代碼版本管理里小步提交的核心則是“一次提交只做一件事”。一個典型的提交信息模板# 模板type(scope): description git commit -m feat(compress): add batch image compression如果你發(fā)現(xiàn)一次提交里既有“修復(fù)壓縮算法”又有“調(diào)整界面布局”又有“修改配置文件”這就是典型的提交粒度問題。4. 把方法論落到日常技術(shù)工作和內(nèi)容生產(chǎn)中不同的工作類型小增量的拆法不同。但是底層邏輯都一樣從結(jié)果反推最近一個可驗證的節(jié)點然后只做這個節(jié)點。4.1 軟件開發(fā)場景把需求拆成以下順序確認輸入輸出這個功能吃什么數(shù)據(jù)、出什么結(jié)果。寫最小用例先定義一個測試數(shù)據(jù)。實現(xiàn)最小路徑只要能跑通不看邊界。補充邊界與異常錯誤處理、空目錄、斷網(wǎng)情況。接入真實數(shù)據(jù)小批驗證。提交并交給評審。每一步都是小增量。你不需要一步到位寫出完整系統(tǒng)而是像搭積木一樣逐塊推進。4.2 批量任務(wù)場景批量處理最容易踩的坑就是“一次性全量跑”。正確做法是先用 1 條數(shù)據(jù)驗證算法正確。再用 10 到 50 條數(shù)據(jù)驗證穩(wěn)定性。再跑一小批真實數(shù)據(jù)觀察耗時和顯存、內(nèi)存占用。最后再做全量并保留失敗的日志。這里有一個通用的小批處理腳本思路您可以根據(jù)實際任務(wù)調(diào)整參數(shù)和邏輯import os import logging from pathlib import Path logging.basicConfig( filenamebatch.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) input_dir Path(./inputs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) # 第一批先跑 10 個驗證流程 files sorted(input_dir.iterdir())[:10] for file_path in files: try: # 這里的寫法只是示例實際請?zhí)鎿Q為你的核心處理函數(shù) result process_one(file_path) output_path output_dir / file_path.name output_path.write_bytes(result) logging.info(fSUCCESS: {file_path.name}) except Exception as exc: logging.error(fFAILED: {file_path.name} error{exc})跑完第一批先看日志。成功率、單條耗時、資源占用符合預(yù)期再擴展到全量。4.3 技術(shù)寫作場景寫技術(shù)文章也可以用同樣思路寫出核心結(jié)論這篇文章要讓讀者學(xué)會什么。列出結(jié)構(gòu)大綱只寫標題不寫正文。先寫最容易驗證的“動手步驟”代碼塊和命令先補完。再補背景說明與原理部分。最后統(tǒng)一檢查格式和引用。這里最容易犯的錯誤是“等靈感齊了再寫正文”。實際上先把可驗證的代碼跑通文章骨架就穩(wěn)了。5. 如何驗證小增量方法有沒有效果推薦用一組簡單的指標來觀察自己或團隊的變化。指標計算公式/來源變化趨勢任務(wù)完成率完成的小增量數(shù) / 計劃的小增量數(shù)應(yīng)逐步提升平均完成時長單個小增量從開始到驗收的耗時應(yīng)保持穩(wěn)定或降低提交粒度每次提交涉及的文件數(shù)和行數(shù)應(yīng)更小、更聚焦分支存活時間從分支創(chuàng)建到合并的天數(shù)應(yīng)顯著縮短返工率因驗收不通過而返工的次數(shù)應(yīng)下降批量任務(wù)交付成功率全量任務(wù)一次交付成功的比例應(yīng)上升如果發(fā)現(xiàn)指標沒有變好不要急著否定方法。大概率是任務(wù)拆得還不夠小或者根本沒有設(shè)驗收標準。另外還可以用 Git 提交歷史來觀察自己的提交粒度。下面的命令可以查看最近提交涉及的文件數(shù)git log --oneline -20 --stat如果你想在項目目錄里自動統(tǒng)計每個提交的文件變更數(shù)可以用這個思路git log --prettyformat:%h %s -20 | while read commit msg; do count$(git show --stat --oneline $commit | tail -n 1 | awk {print $1}) echo $commit 文件數(shù): $count 提交信息: $msg done這里的$commit是從前一個命令讀取的提交哈希實際終端環(huán)境里可以作為一個快速檢查腳本使用。如果你的任務(wù)推進長期沒有可量化反饋可以先從這類小工具開始把反饋閉環(huán)建起來。6. 常見問題與排查方法小增量的方法論本身不復(fù)雜但實踐時容易踩坑。下面整理了一張排查表。問題現(xiàn)象可能原因排查方式解決思路任務(wù)拆完之后還是不想動手任務(wù)仍然太大或者入口不清晰看第一個子任務(wù)是否 30 分鐘內(nèi)可完繼續(xù)拆直到第一個任務(wù)可以立刻執(zhí)行拆得太碎列表一堆但沒推進把“行動”拆成了“想法”檢查是否每個子任務(wù)都有可驗證成果刪除只表達狀態(tài)、不表達交付的條目小步提交但代碼頻繁沖突分支存活時間太長觀察從創(chuàng)建到合并的時長加快合并節(jié)奏頻繁同步主干批量任務(wù)小批成功、全量失敗全量時存在邊界數(shù)據(jù)或資源超限查看失敗日志分析失敗樣本的共性分批加日志先覆蓋邊界再提升并發(fā)增量推進很多但成果感不強缺少對外展示和反饋節(jié)點確認每個小增量完成后是否有記錄/評審為每個小增量添加展示或演示環(huán)節(jié)任務(wù)推進中有新的待辦反復(fù)插入沒有設(shè)置收集箱將臨時想法記錄到單獨列表先記錄統(tǒng)一處理不打斷當前小增量寫了驗收標準但沒法判斷驗收標準描述模糊檢查標準是否包含可觀察或可測條件改成“輸出文件存在且日志無 ERROR”類的硬指標最典型的問題是第一行拆完之后還是不想動手。這種情況不用懷疑自己的自律性而是任務(wù)粒度還不夠細。一個真正的小增量應(yīng)該做到“打開工具就知道第一行代碼寫在哪里或者第一個操作按鈕點哪里”。7. 工程化落地與自動化輔助小增量如果只是停留在個人清單層面執(zhí)行一段后會逐漸走形。比較穩(wěn)妥的方式是把它變成工程化流程。有幾個方向可以做。第一個方向為每個小增量建立持久化記錄。不要用隨手刪掉的便利貼而是把每一輪任務(wù)記錄成文檔包含日期、目標、驗收結(jié)果、發(fā)現(xiàn)問題。這樣兩周后可以復(fù)盤找到自己卡住的真實原因。第二個方向把“驗收”自動化。如果你做的是代碼任務(wù)可以在每個小增量完成后運行一次測試命令或靜態(tài)檢查讓機器告訴你是否通過。常見的通用檢查方式# 示例運行項目已有測試 pytest tests/ # 示例檢查代碼格式 ruff check src/ # 示例檢查腳本語法 python -m py_compile main.py需要注意不同項目的檢查命令不同以上只是通用示例。你的項目如果沒有 pytest 或 ruff需要按實際工具替換。第三個方向用腳本輔助生成任務(wù)模板。下面是一個簡單的 Python 腳本可以根據(jù)你輸入的總?cè)蝿?wù)名稱生成一個包含多個小增量占位結(jié)構(gòu)的文件方便快速開始。from pathlib import Path task_name input(請輸入總?cè)蝿?wù)名稱: ).strip() filename f{task_name}_task.md content f# 任務(wù){(diào)task_name} ## 小增量 1 - 目標 - 輸入條件 - 執(zhí)行步驟 - 驗收標準 - 預(yù)計耗時 ## 小增量 2 - 目標 - 輸入條件 - 執(zhí)行步驟 - 驗收標準 - 預(yù)計耗時 ## 小增量 3 - 目標 - 輸入條件 - 執(zhí)行步驟 - 驗收標準 - 預(yù)計耗時 filepath Path(filename) filepath.write_text(content, encodingutf-8) print(f已生成任務(wù)拆解模板: {filepath.resolve()})這個腳本的優(yōu)勢是讓你把精力花在“填寫驗收標準”而不是“組織格式”。第一次使用后你會發(fā)現(xiàn)自己原來對很多任務(wù)的預(yù)期其實并不清晰寫不出驗收標準就是證據(jù)。第四個方向批量任務(wù)加重試和日志。無論你是在處理圖片、視頻、文檔還是調(diào)用 API只要涉及批量就必須假定會有一部分失敗。更穩(wěn)的批量流程是小批運行、記錄日志、失敗進入隊列、重試有限次數(shù)、最后人工查看剩余失敗項。8. 使用邊界與合規(guī)提醒小增量方法和技術(shù)實踐結(jié)合時有兩條邊界必須說清楚。第一不是所有事情都適合“先小步再擴大”。比如線上服務(wù)出現(xiàn)了緊急故障你首先要做的是止血而不是拆成五個小增量慢慢觀察。這時候的正確做法是快速恢復(fù)、再事后復(fù)盤把修正項拆成小增量補進開發(fā)流程。小增量解決的是“從零到一、從一到穩(wěn)定交付”的執(zhí)行問題不是應(yīng)急響應(yīng)的替代品。第二凡是涉及生產(chǎn)環(huán)境、用戶數(shù)據(jù)、版權(quán)素材、人臉信息、聲音信息批量處理和個人發(fā)布前都要確認授權(quán)和合規(guī)邊界。小步發(fā)布不代表可以繞過備份、回滾和灰度驗證。即使你只處理了很小一批數(shù)據(jù)只要數(shù)據(jù)來源或結(jié)果使用沒有授權(quán)最小增量也不能覆蓋合規(guī)風險。技術(shù)文章里分享處理腳本時也建議明確提示“僅用于合法授權(quán)的內(nèi)容和自己擁有的測試數(shù)據(jù)”。第三團隊協(xié)作場景下小步提交是一項紀律不要為了追求“每天提交很多次”就制造大量無意義提交也不要一個人在長期分支上偷偷攢大量改動而不同步。小增量的收益必須在“及時合并、及時評審、及時同步”的前提下才能體現(xiàn)。9. 最佳實踐與使用建議基于前面的分析這套方法要真正見效建議從下面幾件事做起。寫任務(wù)清單時不要以“做什么”為主體而是以“完成什么”為主體。舉例“研究視頻生成參數(shù)”是一個動詞更合適的小增量是“使用測試視頻跑通默認參數(shù)生成記錄顯存占用和輸出時長”。前者沒有終點后者有明確終點。每個任務(wù)單元限制反饋周期。個人開發(fā)時一個小增量的反饋周期最好不超過一個工作日團隊協(xié)作時從完成到評審合并最好不要超過兩到三天。反饋周期越短糾偏成本越低。定期回顧自己的提交記錄和任務(wù)記錄?？梢悦恐艹槭昼娍匆幌卤局芡瓿闪硕嗌賯€小增量、有多少個是一次通過、有多少出現(xiàn)了返工。如果返工率高說明拆解時對輸入條件和驗收標準的分析還不夠。給批量任務(wù)預(yù)留重跑機制。批量處理中的失敗項一定要記錄到日志并支持“只處理失敗項”的重跑模式。最怕的是全量跑完發(fā)現(xiàn)三分之一失敗后沒有任何日志不知道哪些失敗、為什么失敗。不要追求“拆得很漂亮”再動手。任務(wù)拆解是執(zhí)行的一部分不是前置儀式。實際上很多驗收標準只有在完成第一個小增量后才會變清晰。先拆一個可以立刻執(zhí)行的單元跑通之后再調(diào)整后面單元的粒度。如果是在團隊里落地建議從一個小項目開始試點而不是立刻全員鋪開。否則很容易變成“表單填寫大賽”團隊把精力花在寫任務(wù)模板上而不是交付結(jié)果上。小增量的檢驗標準永遠只有一個是否更快地交付了可驗證成果。10. 總結(jié)與下一步“Getting things done (in small increments)”最值得嘗試的點不是它引入了什么新概念而是它把一個很樸素的常識變成了可操作的執(zhí)行標準一次只做一小塊做完立刻驗證驗證通過再推進下一塊。我建議你從下一個手頭任務(wù)開始驗證不管它是寫代碼、做批量實驗、整理文檔還是處理數(shù)據(jù)先拆成三個小增量每個都寫清楚驗收標準然后只做第一個。結(jié)束后記錄一下啟動耗時和完成耗時和以前“一次性做完”的節(jié)奏對比往往立刻能感覺到差別。最容易踩的坑是拆解時沒有設(shè)置驗收標準。這不是模板問題而是你還沒真正想清楚“什么算完成”。如果一個任務(wù)寫不出驗收標準大概率還需要重新分析輸入條件或結(jié)果形態(tài)。接下來可以繼續(xù)擴展的方向有三個一是把任務(wù)拆解和 Git 提交粒度關(guān)聯(lián)起來每個小增量對應(yīng)一次提交二是給批量任務(wù)加自動日志和失敗重試讓交付更穩(wěn)定三是每周復(fù)用第 5 節(jié)的指標做復(fù)盤連續(xù)四周觀察完成率、返工率和分支存活時間的變化。落到日常行動上就是從明天開始把第一個任務(wù)拆小一點。