剛拿到需求書,想先知道「評審在看什麼」。三分鐘內得到架構方向。
你是這個案子的評審。以下是需求文件:{貼上}
1. 列出評審最可能的評分面向與權重(推測要說明理由)。
2. 依評分面向反推企劃書章節架構:章節|要證明什麼|需要什麼證據。
3. 指出需求文件裡「沒明說但會扣分」的隱藏期待。
不要開始寫內文,先給架構。可替換變數
| 變數 | 要換成什麼 |
|---|---|
{貼上} | 需求書或評選須知全文(含附件的重點段落)。 |
完整使用範例(照這樣填)
你是這個案子的評審。以下是需求文件: (貼上「○○業務委外服務案」投標須知與服務建議書架構要求全文) 1. 列出評審最可能的評分面向與權重(推測要說明理由)。 2. 依評分面向反推企劃書章節架構:章節|要證明什麼|需要什麼證據。 3. 指出需求文件裡「沒明說但會扣分」的隱藏期待。 不要開始寫內文,先給架構。
預期輸出範例(拿到的東西應該長這樣)
一、推測評分面向與權重 | 面向 | 推測權重 | 推測理由 | |---|---|---| | 服務內容完整性 | 30% | 須知第 5 條列出 8 項服務,逐項要求說明 | | 執行團隊 | 25% | 要求附履歷與過去實績,且指定專職人力 | | 時程與風險管理 | 20% | 多處出現「應於……日內」 | | 價格合理性 | 15% | 採最有利標,價格非唯一 | | 創新加值 | 10% | 僅一句「得提出加值服務」 | 二、反推章節架構 | 章節 | 要證明什麼 | 需要什麼證據 | |---|---|---| | 一、對本案的理解 | 我們懂主辦單位真正的問題 | 過去三年相關政策或前案缺口 | | 二、服務內容 | 八項服務逐項有具體做法 | 每項一個流程圖或實例 | | 三、執行團隊 | 人力真的投得下去 | 履歷、專職證明、過去同型案 | | … | | | 三、隱藏期待(沒明說但會扣分) 1. 須知反覆提到「跨單位協調」,但沒有列入評分——通常代表主辦單位過去在這裡吃過虧,建議獨立一節談協調機制。 2. 要求「每月提交報告」卻沒說格式,附一份報告範例會加分。 3. 附件中的服務時間涵蓋例假日,但正文沒提,需要說明值班安排。
常見錯誤用法
- 跳過這一步直接寫內文——這是這個方法最主要的價值所在。
- 把 AI 推測的權重當成事實去分配篇幅。它是假設,要找人驗證。
- 只貼需求書正文不貼附件——評分細節與隱藏期待常常在附件裡。
- 得到架構後就叫同一個對話開始寫。先確認架構、再分章展開。
- 需求書尚未公告時(等於在猜)。
- 需求書含機敏或限閱資訊而你只有消費者版帳號。
拿不到正式評分表時,AI 的推測至少要說明理由——你才能判斷哪幾項推測是可信的。標記為「推測」的權重不要用來決定篇幅分配,先找熟悉該主辦單位的人確認一輪。
- 評分權重的最終認定。
- 隱藏期待哪幾條真的成立。
- 架構定案。