Community研究與資料分析github.com

Rubix982/研究寫作

用於起草或修改研究寫作——論文、實驗筆記、設計文件、研究部落格文章、相關工作章節,或任何陳述發現的段落。執行主張稽核,讓每個斷言在寫出時即可證偽,將模糊修辭隔離至「限制」章節,並為數學內容強制執行「先文字後符號」的階梯原則。

研究寫作 是什麼?

此技能專為需要提升學術寫作嚴謹度的開發者與研究人員設計,提供一個結構化的三階段審查流程。第一階段是核心的「主張稽核」,要求使用者區分「修改」、「起草」和「設計」三種模式,並針對每個主張回答「什麼觀察會讓這句話為假?」。這能強制每個斷言都是可證偽的,並揭露哪些主張是承載結構的關鍵,進而根據文體(論文依賴性排序、實驗筆記依時間順序)重新組織內容。第二階段包含七個結構性問題,例如檢查標題是否具有真值、量化「差距」的代價、確保數學符號在定義前有英文名稱、以及將所有模糊修辭強制隔離到一個「限制」章節。第三階段提供一個基於詞彙的程式碼檢查工具(lint),但它被明確定義為一個「地板標準」而非品質門檻——它衡量的是是否符合特定風格,而非智慧財產權或原創性。此技能支援 Claude Code、Cursor、Codex 等 AI 代理平台,並可透過 Markdown 檔案參考實際案例。它明確不處理證據不足的問題,也不決定研究是否值得進行;它只改善草稿的認知結構。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Rubix982/research-craft/tree/HEAD/skill/research-writing

Installed? Explore more 研究與資料分析 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

研究寫作 是做什麼的?

大多數糟糕的研究寫作並非寫得不好,而是無法證偽——文筆流暢、用詞精準的文字,卻沒有提出任何可能被證明是錯誤的主張,因此讀者讀完後無事可做。這是經過測量而非推測的結果:一段 AI 生成的研究文字,在整個詞彙層級的程式碼檢查中得分每萬字 0.0 次命中,並在 472 個字中承載了一個可證偽的主張。它通過了所有表面檢查,卻什麼也沒說。

所以,第一階段是主張稽核。其他一切都是次要的。

第一階段——稽核(務必執行此步驟)

先選擇模式。 對文件問錯問題不會產生任何結果。

你是……單位問題
修改文字每個段落什麼觀察會讓這句話為假?
起草文字你打算提出的每個主張,在寫作之前同上,在文字存在之前回答
設計尚無結果的工作每個承載結構的假設如果這個假設是錯的,這項工作還能測量它所聲稱的東西嗎?

設計模式並非一種變體。設計中的斷言是關於將會被測量的事物,而「我們將掃描八層」這句話不可能為假,因此可證偽性無從著力。一個即使被證明為錯也能存活下來的假設沒問題;但一個無法存活的假設,就是在工作開始前需要加以控制的混淆變因。

修改與起草

段落主張,一句話概述自有或歸因?什麼會讓它為假?
  • 自有 vs. 歸因。 即使所有引文都準確報導,一個自有的主張仍可能為錯。「Qin et al. 報告 X」是歸因;「X 不能作為閘極」是自有。一份只有歸因主張的草稿不可能出錯——這就是缺陷。
  • 寫出即可證偽——讀者僅憑句子本身就能說出反駁的觀察。「高度相關」失敗,因為沒有可違反的閾值。「在三個模型上相關性 r > 0.5」則通過。
  • 未量化的最高級形容詞是最常見的失敗:最清晰的、主要的、大多數、少數之一。請給出標準,否則就放棄排名。
  • 分析性主張帶有標記 [A]。 一個衍生性主張——例如*「對任何 u 而言,係數恰好為 1」*——無法被任何觀察反駁,只能被推導錯誤或其前提失敗所反駁。將前提的反駁條件放在第四欄,而非主張本身,因為經驗內容存在於前提之中。舉例來說:我們自己的釘選主張是分析性的,其前提是前綴共享,而前提正是 [E-017] 和 [E-018] 所測量的。注意:分析性主張必須附上其推導過程,無論是在文件中或透過引用。若未顯示推導過程,則並非分析性,只是無法證偽。

修正每一個第四欄為空的列——使其更精確、降級為明確的歸因,或刪除。如果根本沒有自有主張,請停下來並說明;任何改寫都無法解決這個問題。

「我不知道該拿這個怎麼辦」在此解決,而非透過格式修飾。 一份草稿可能充滿無法執行的指示——*「將 GradSim 用作預編輯風險評分」*有動詞和受詞,卻無法執行,因為一個閘極需要一個閾值和錯誤率,而來源從未提供。一個空洞的指示建立在未量化的主張之上。 不要在未能通過此階段的草稿後面加上一個「後續行動」清單;那只會產生一份整潔但無人能執行的清單。

設計

編號承載結構的假設如果錯了,工作還能繼續嗎?控制措施

將可行性納入為一個假設:這在我實際擁有的計算、資料和依賴預算內運行。 一個有一半呼叫失敗的依賴項是一個會改變產物的設計參數——例如檢查點、可恢復性——而非稍後再吸收的意外事件。第三欄出現「否」即代表一個混淆變因;在開立任務單之前,先命名其控制措施。

第二項工作,也是真正重要的工作

一旦每一列都有第四欄,哪個主張是承載結構的就一目了然。

稽核告訴你什麼是承載結構的。它沒有告訴你要施加什麼順序——那是文體決定的。

  • 論文按依賴關係排序:其他主張所依賴的先行,僅確認它的往後放。
  • 實驗筆記、記錄或敘事按時間順序排序。一則旨在展示八個主張按其被撤回順序撤回的貼文,若按依賴關係排序就會被破壞。
  • 兩者可以組合。一個按時間順序的文件仍有進行論證的章節,而在一個論證性章節內,依賴關係主導一切,無論文件頂層做什麼。

搞錯這一點是這個稽核唯一會造成損害的方式,所以在移動任何東西之前,先決定文體。

在三次實際使用中,過濾器捕捉到了零個無法證偽的主張——所有來源都已按該標準撰寫——而排序每次都會改變結構。預期排序,而非過濾。 一個什麼都沒捕捉到的稽核並非失敗;閱讀表格,看看什麼優先於什麼。

第二階段——七個結構性問題

按順序。實際案例請參考 references/structure.md。問題 2 和 3 是在三次實際使用中真正觸發過的——問題 2 兩次,問題 3 一次——所以先在那裡投入注意力。三次使用並非排名;它是讓你查看的重點。

  1. 標題——能否將每個標題改寫成一個帶有真值的句子? (導航標籤——如參考文獻、附錄、方法,以及任何扮演限制章節角色的部分——得以豁免。)
  2. 差距——什麼差距?填補它要付出什麼代價?什麼會因此改變?一個未標價的差距只是一個願望。
  3. 符號——每個物件在獲得符號之前,是否先用英文按其功能命名? 參考 references/mathematics.md。
  4. 省略——每個被省略的項是否在其被省略的地方得到承認? 「……為求符號簡潔,省略 x。」
  5. 命名——現有的詞彙是否能精確指稱此物? 如果是,借用;在不確定時則創造新詞,因為一個新詞會大聲失敗,而一個錯誤的借用會安靜地失敗。
  6. 模糊修辭——將其隔離,而非減少。 所有限定詞都放入一個名為「限制」的章節,正文則以無修飾的方式運作。相同的認知內容,但集中呈現,且更誠實:一個特定的限制被命名,而非一個模糊的副詞。
  7. 批評——範圍是否在造成損害之前就已固定? 「X 是為了做 A 而建造的,它做到了。B 是一個不同的問題。問題在下游。」

每份草稿都有一個限制章節,無論它叫什麼名字

隔離是要求,名稱不是。 「攻擊目標」在對抗性語境中也能完成同樣的工作。無論哪個章節執行此功能,都豁免於真值標題的規則。

但請檢查第三類條目在重新命名後是否仍然存在。 對抗性框架收集的是審查者可能會攻擊的點,而沒有人會攻擊對使用方式的限制——因此當該章節被命名為其他東西時,這類條目往往會消失。

三種條目,而第三種永遠不會單獨出現:

  1. 結果沒有顯示的內容——「測量知識是否存在,而非模型是否會產生它。」
  2. 沒有做的事情——「我尚未在 GPT-2-XL 上執行約束測量。」
  3. 結果可能不被使用的方式——「這是研究發現的後果,而非我提供的方法。」沒有第二階段的問題會產生它;請特意添加。

第三階段——程式碼檢查(一個地板標準,而非門檻)

python scripts/lint.py --rate DRAFT.md

參考數值:內部風格文字為每萬字 0.0(共 27,700 字),已發表的機械解釋論文為 5.1,未編輯的調查報告文字為 6.4。1.25 倍的差距——這無法區分一篇好論文和一份壞報告。

它也不是作者身份測試。 這個數值追蹤的是作者是否遵循內部風格,而非誰打的字:在實際使用中,兩份 AI 撰寫的文件得分為 0.0(分別為 3,200 字和 13,100 字)。切勿將乾淨的程式碼檢查結果作為品質或來源的證據。

定位主張

一個新穎性判定——「這是未聲明的」、「我們被搶先了」——本身是一個主張,因此第一階段照常適用。一個陳述的判定是意見;一個指出最近論文沒有做什麼的判定則可以被檢查。有兩條稽核不會產生的規則:

擱置需要比繼續進行更強的證據。 一個錯誤的*「這條路是開的」會在後來那篇論文出現時浮出水面。一個錯誤的「我們被搶先了」*則會悄然終結工作,且不會產生任何證據表明它是錯誤的。一個未經證實的被搶先判定是應予核實的理由,而非擱置的理由。

當判定取決於一篇論文做了什麼時,請閱讀其方法或附錄,而非其文字。 緒論說的是作者希望這個建構會產生什麼;附錄說的是實際執行了什麼。再多的搜尋也無法捕捉到這一點。

此技能無法做到的事情

這些階段改善的是草稿的認知結構,而非其證據基礎。 經過測量:應用它們增加了七個可證偽的主張,卻沒有增加任何新的數字,因為來源本來就沒有。在薄弱的證據上,它們會產生一個明確的陳述,說明證據薄弱——這比自信地薄弱要好,但與證據充分不同。

如果草稿需要它沒有的數字,請如此說明並停止。

它也無法決定這項工作是否值得做、執行文獻搜尋,或選擇下一步要建構什麼。這些屬於專案層級的設計協議。

參考資料

  • references/structure.md——七個問題,附有修改前/後的範例
  • references/mathematics.md——先文字後符號;名稱的自由推論測試
  • references/exemplars.md——標記的段落,以及一個完整的反例範本
  • references/voice.md——僅在從零開始起草時使用。 正在擴充一份文件?請從該文件採用其語域。

相關技能