前言¶

寫解決方案、投標技術方案或工程方案時，常見的問題是：章節看起來齊全，評審一追問就露怯。實施路徑缺少可驗收的節點，風險只有一句”將高度重視”，承諾無法驗證，過程也沒有留痕。對懂工程的甲方來說，這些問題比文筆不通更致命。

下面介紹一個專門處理這類問題的 Skill：@user_ca0a159e/design-engineered-solution（工程化方案設計）。

這是什麼¶

一句話定位：用工程化方法起草、深化或評審解決方案 / 投標技術方案 / 工程方案，產出含總起、概述、實施路徑等章節的文檔。

它解決的問題是把方案從”看起來像方案”改造成”經得起懂工程的甲方與評審追問”：每步可驗收、風險有應對、承諾可驗證、全程可留痕。

該 Skill 由社區作者 user_ca0a159e 發佈，來源爲 community，分類屬於 business-ops，版本 1.0.0，採用通用 SKILL.md 格式。SkillHub 頁面顯示評分 100000、下載 1303 次。

核心功能¶

根據官方簡介，它覆蓋的能力是：

1、方案起草與深化：生成方案的總起、概述、實施路徑等章節，並把已有方案往深裏寫。
2、方案評審：從”哪裏淺顯、哪裏不成體系”的角度審查方案，找出經不起追問的部分。
3、甲方視角改寫：按甲方的驗收邏輯修改方案，而不是隻在乙方語境裏潤色。
4、機制補齊：給方案補充驗收標準與風險應對機制，讓承諾可驗證、過程可留痕。

它不生成代碼，也不代替項目管理工具；輸入是方案文本與背景信息，輸出是結構化、可追問的方案文檔。

安裝與啓用¶

官方地址：

https://api.skillhub.cn/user_ca0a159e/design-engineered-solution

SkillHub 頁面：

https://www.skillhub.cn/skills/user_ca0a159e/design-engineered-solution

該 Skill 標記爲 requires_api_key=false，即使用過程不需要額外的 API Key。

資料中沒有給出具體的安裝命令與配置文件字段。它是社區來源、通用 SKILL.md 格式的 Skill，在 Cursor、Codex CLI、Claude Code 等支持 SKILL.md 的客戶端中，啓用方式以官方頁面說明爲準，此處不臆造命令。使用前建議先打開官方頁面確認安裝步驟與當前版本。

典型用法¶

官方簡介列出的適用場景，可以直接當作調用時的提示方向：

1、寫方案總起或概述：需要把項目背景、目標與總體思路快速搭出骨架時。
2、把方案寫深：已有方案篇幅夠但深度不夠，需要補充實施細節與論證時。
3、評審方案：作爲評審環節的輸入，回答”哪裏淺顯或不成體系”。
4、按甲方視角修改方案：交付前對照甲方關心的驗收、風險、可驗證性做一輪改寫。
5、給方案補驗收與風險機制：針對缺少驗收標準或風險清單的章節做專項補齊。

實際使用時，把待處理的方案文本、項目背景和本次目標（起草、深化、評審或改寫）一起作爲輸入給出，讓 Skill 按其工程化結構產出。

適用場景與注意¶

適合誰：需要撰寫或評審解決方案、投標技術方案、工程方案的人，尤其是面向懂工程的甲方交付、且方案要經過評審追問的場景。

限制與坑：

1、它是文檔結構化與論證強化的助手，不覈實方案中的業務數據與事實，數字、指標仍需使用者自己確認。
2、輸出質量取決於輸入的方案文本與背景信息，資料缺失時它會按通用結構補全，但補全內容需要人工複覈。
3、版本 1.0.0 且下載量不大，屬於社區作品，接入正式投標流程前建議先小範圍試用，確認輸出風格符合內部模板。

結尾¶

工程化方案設計的價值在於把方案的可驗收性、風險應對、承諾驗證和過程留痕做成顯式結構，而不是依賴評審時臨場發揮。如果你的方案經常在追問環節被問住，值得用它先起草或先評審一輪。

官方地址：https://api.skillhub.cn/user_ca0a159e/design-engineered-solution