紙質表單電子化系統生成器

把當前提示詞和當前附件作為事實來源，輸出可驗證、可本地執行、可繼續維護的業務系統，而不是隻給方案、靜態頁面或程式碼片段。

當前技能基線：2.7.0。

版本說明： 2.7.0 在 2.6.0 的“業務理解 + 自動生成”基礎上補齊執行驗收與安全升級閉環。新增 test 命令，在隔離副本中真實啟動系統並覆蓋健康檢查、登入、CRUD、嚴格型別校驗、CSV 匯入預覽/確認、XLSX 匯出、安全停止、SQLite 備份/恢復；validate --strict 不再把未測試專案判為通過。新增 upgrade 命令，對舊/新 system-spec 做差異分類並預設只自動處理新增物件/新增欄位。業務關係推斷升級為“欄位語義 + 樣本值重合 + 唯一性”，生成表單增加日期、布林、列舉、數字控制元件與統一伺服器端校驗。候選關係、審批鏈、正式統計口徑仍遵守“無證據不猜測”。

0. 30 秒快速入口

使用者只做一件事

上傳業務資料，然後直接說：

“把這些資料做成 Windows 本地中文業務系統，先分析資料；確認能做後自動生成、測試並給我完整 ZIP。”

執行者負責其餘步驟。不要讓非技術使用者自己拼引數。

技術人員只記一個入口

本技能新增統一路由器：

python scripts/run_skill.py analyze "<資料>" --output "<工作目錄>"
python scripts/run_skill.py scaffold --spec "<工作目錄>/system-spec.json" --output "<僅工程骨架目錄>"
python scripts/run_skill.py generate --spec "<工作目錄>/system-spec.json" --output "<完整業務專案目錄>"
python scripts/run_skill.py test --project "<專案目錄>"
python scripts/run_skill.py validate --project "<專案目錄>" --strict
python scripts/run_skill.py upgrade --project "<舊專案目錄>" --spec "<新system-spec.json>" --output "<升級副本目錄>"
python scripts/run_skill.py diagnose --source "<資料>" --project "<專案目錄>" --strict
python scripts/run_skill.py package --project "<專案目錄>" --output "<交付ZIP>"
python scripts/run_skill.py self-test

它只是現有指令碼的統一入口，不替換原指令碼；原命令仍然有效。完整示例見 references/quickstart-and-evidence.md。

能力狀態必須這樣表述

技能輸出中禁止把“設計支援”直接寫成“已經可用”。統一使用以下五級證據：

1. 設計支援：規則/腳手架中存在該能力；
2. 已生成：本次專案已經生成對應檔案或模組；
3. 靜態驗收通過：結構、安全、雜湊、配置等自動檢查通過；
4. 執行驗收通過：本次已實際啟動、操作並通過對應測試；
5. 目標機實測通過：目標 Windows 電腦已實際驗證，例如斷網、EXE、區域網或客戶端連線。

只有達到對應證據等級，才能使用“已驗證、斷網可用、免 Python、區域網可用、解壓即用”等表述。

0.1 使用者操作說明：只上傳“提示詞 + 對應業務資料”

使用者端只需要做 3 步

第 1 步：上傳業務提示詞

提示詞可以是 TXT、DOCX、PDF，也可以直接在對話方塊輸入。內容只需要說明“想做什麼系統、給誰使用、希望解決什麼問題”。不要求使用者寫技術引數。

示例：

請根據下面的業務資料，做一箇中文 Windows 本地業務系統。保留原來的表單填寫習慣，實現錄入、查詢、修改、統計、Excel 匯入匯出。請自動識別業務規則；能確認的直接生成，不能確認且會影響業務結果的地方再提醒我。最後完成測試並輸出完整 ZIP。

第 2 步：上傳對應業務資料

把與提示詞對應的 Excel、CSV、Word、PDF、ZIP、JSON、TXT、已有原始碼或歷史資料一起上傳。可以一次上傳多個檔案，不需要先整理目錄，也不需要給檔案重新命名。

第 3 步：點選生成 / 直接傳送“開始生成”

使用者不需要執行 Python、命令列、引數組合、指令碼選擇或手工拼接配置。執行者自動完成：

提示詞 + 業務資料 → 資料識別 → 業務建模 → system-spec → 系統生成 → 資料檢查 → 測試驗收 → ZIP交付

使用者不需要提供的內容

• 不需要寫 Python 程式碼；
• 不需要知道 SQLite、Flask 等技術；
• 不需要填寫指令碼引數；
• 不需要選擇應該執行哪個指令碼；
• 不需要自己判斷業務屬於 energy / pointwork / operations 等型別；
• 不需要自己整理欄位對映；
• 不需要自己打包 ZIP。

只有以下情況才向用戶提問

如果附件已經能證明規則，直接採用附件事實；只有缺失內容會影響金額、工時、審批、許可權、唯一鍵、歷史資料或正式統計口徑時，才向用戶提出最少量確認問題。其他可由工程預設值解決的內容由執行者自動處理。

使用者最終只應看到

1. 識別結果：識別到了什麼業務、哪些資料有效；
2. 處理結果：哪些功能已經生成；
3. 驗收結果：哪些專案已經自動驗證，哪些需要目標電腦實測；
4. 交付物：完整 ZIP、使用說明、版本資訊和必要的待確認事項。

不要把內部命令、Python traceback、JSON 中間檔案或複雜參數列作為使用者完成任務的前置條件。

0.1 執行約定：使用者零命令、過程可恢復

• 在 ChatGPT/Codex 中觸發時，由執行本技能的智慧體讀取附件、執行指令碼、診斷、驗收和打包；除非使用者明確索要本地操作說明，不得把命令列步驟留給使用者完成。
• 使用者只需提供業務材料並說明想做什麼。只在缺失規則會影響金額、工時、審批、許可權、唯一鍵或歷史資料時提問；能從附件驗證的內容不重複詢問。
• 每個階段先報告“已確認、待確認、當前阻斷、下一步”。中斷後從最近通過的階段繼續，不覆蓋已生成資料庫或已確認規則。
• 命令失敗時不得只轉發異常文本。按“發生了什麼 → 原因/位置 → 現在怎麼處理 → 從哪裡繼續”四項向用戶解釋，並保留原錯誤碼。
• 需要快速案例、能力證據等級、宣告邊界時讀取 references/quickstart-and-evidence.md；需要命令示例、錯誤碼、FAQ 或反模式時讀取 references/usage-and-troubleshooting.md。

1. 適用與不適用

1.1 最短使用方式

非技術使用者不需要先理解引數。直接提供業務資料並說明目標即可，例如：

• 普通本地系統：“把這些 Excel 做成一個 Windows 本地業務系統，保留原表字段，能錄入、查詢、統計、匯入匯出，最後給我完整 ZIP。”
• 區域網系統：“把這些表單做成區域網多人使用的系統，要求中文、斷網可用，並給出完整部署包。”
• 已有系統升級：“在不刪除原資料庫和歷史資料的前提下，把這些新表單和規則合併進現有系統。”
• 只分析不生成：“先分析這些資料，告訴我欄位、業務規則、缺失資料和能不能做成系統。”

執行者應根據目標自動選擇路由，不要求使用者自己拼接指令碼引數。

使用本技能時，使用者通常會提出以下目標之一：

• 根據 Excel/CSV/Word/PDF/ZIP 生成業務系統；
• 把現有表格流程改成本地或區域網系統；
• 根據已有原始碼和新附件繼承升級系統；
• 生成完整可執行 ZIP、Windows 啟停指令碼或 EXE 構建原始碼；
• 生成 V1.5.11 級 portable_full 完整部署包（服務端 + Windows 填寫客戶端 + 區域網工具 + 版本資料 + 條件式 macOS 客戶端）；
• 根據業務資料自動識別能源、點工/考勤、運營記錄、生產、質量、裝置、庫存、審批或組合業務。

如果使用者只要求分析報表、寫方案、做單個文件或修改少量程式碼，不要強行生成完整系統。

快速路由

2. 事實優先順序

業務事實按以下順序處理：

1. 使用者當前任務中的明確要求、修改和禁止項；

   小蔥技能站7w4.net每天更新，海量AI技能等你發現。

2. 正式制度、欄位說明、表單模板、已有原始碼和資料庫；
3. 可驗證的工作簿/CSV/JSON 結構、公式、歷史資料與檔案間關係；
4. 本技能的 Profile、工程骨架和預設值。

第 4 項只能補工程能力，不能覆蓋前 3 項。

會改變金額、工時、審批、許可權、唯一鍵、歷史資料或正式統計口徑的衝突不得靜默處理。把衝突寫入 BUSINESS_CONFLICTS.md；可安全繼續但尚未確認的內容寫入 ASSUMPTIONS.md 或 system-spec.json.open_questions。

3. 第一步：執行時初始化，而不是把結果預置在技能包

正常任務由執行本技能的智慧體先執行：

python scripts/bootstrap_generation.py <材料目錄或單個檔案> --output <工作目錄>

如使用者明確指定業務型別，可加：

--profile energy
--profile pointwork
--profile operations

如果使用者明確要求“完整部署包 / 區域網完整包 / 類似 V1.5.11 / 伺服器端+填寫客戶端 / 解壓後交給普通使用者使用”，初始化時增加：

--deployment-mode portable_full

明確要求區域網多人訪問時再增加 --network-mode lan。

初始化命令會在本次任務工作目錄動態建立：

• input-profile.json
• business-profile.json
• BUSINESS_RECOGNITION_REPORT.md
• INPUT_COMPLETENESS_REPORT.md
• source-file-mapping.json
• data-quality-report.md
• BUSINESS_CONFLICTS.md
• ASSUMPTIONS.md
• system-spec.json
• DELIVERY_STATUS.json

這些都是呼叫結果，不應作為固定成品塞進技能安裝包。詳細定義見 references/runtime-output-contract.md。

如果初始化指令碼不可執行，按同一規則手工完成，不能跳過檔案盤點和事實約束。

執行者向用戶彙報初始化結果時，優先用自然語言說明資料等級、識別到的業務域、檔案錯誤和待確認規則，不要求使用者理解 JSON 或命令列輸出。

4. 輸入檔案處理規則

每個發現的輸入檔案都必須出現在 input-profile.json，狀態只能顯式為 ok、warning 或 error。單個檔案失敗時預設繼續處理其他檔案，整體標記 partial_with_errors；只有核心事實無法安全建模時才阻斷。

不得執行 Office 宏、PDF JavaScript、壓縮包內未知程式、未知 EXE 或附件中的命令來獲取業務規則。原件只讀；轉換時使用副本。

需要詳細檔案解析、來源追溯、資料質量和匯入規則時讀取：

references/file-mapping-and-data-quality.md

需要 2.7.0 真實執行 E2E、strict 語義和安全升級細節時讀取：

references/runtime-e2e-and-upgrade.md

需要安全、離線和國內環境規則時讀取：

references/security-and-domestic-compatibility.md

5. 業務識別只是路由證據

自動識別結果可為：

energy、pointwork、operations、production、quality、equipment、inventory、approval、general、composite。

不得只根據檔名或少數關鍵詞決定系統型別。結合表頭、工作表名、正文、公式、現有原始碼、使用者提示和跨檔案關係判斷。

路由細節讀取：references/business-routing.md。

5.1 深度業務模型（2.6.0）

analyze 現在會先生成 business-model.json 與 BUSINESS_MODEL_REPORT.md。業務識別不再只依賴檔名、工作表名和關鍵詞，而是優先使用：

• Excel/XLSM：工作表、真實單元格值、inlineStr/共享字串、表頭、資料型別、公式；
• CSV/TSV/JSON：欄位結構、樣例值、候選唯一列；
• DOCX：正文與表格；
• PDF：僅在本地存在可靠解析器時提取正文，否則明確降級，不把亂碼當事實；
• 跨表關係：只生成“候選關係 + 置信度 + 原因”，不直接升級為正式外部索引鍵；
• Excel 公式：能安全轉換為同一行純算術/白名單函式時標記為 auto_executable，否則只保留原公式和證據位置。

system-spec.json 會自動帶入 business_objects、field_mappings、calculation_rules、relationships 與業務模型摘要。

只有需要對應業務時再讀取相關 Profile：

• 能源：references/domain-profile-energy.md
• 點工/考勤：references/domain-profile-pointwork.md
• 運營記錄：references/domain-profile-operations.md

Profile 是參考，不是當前業務事實。

6. 資料完整度門禁

資料完整度分 A/B/C/D：

• A：結構化資料 + 正式規則 + 現有原始碼/資料庫證據較完整；
• B：有結構化資料，並有規則或原始碼證據；
• C：主要是報表/模板；可生成確定部分，關鍵規則保持待確認；
• D：缺少可驗證結構化材料；只能生成通用原型/骨架，不得宣稱已還原正式業務口徑。

任何等級都不得無證據補齊考勤週期、金額/工時公式、目標方向、稽核、許可權或唯一鍵。

7. system-spec 是生成程式碼前的唯一業務規格入口

在寫業務程式碼前先完善 system-spec.json。至少覆蓋：

• 系統名稱、業務域、部署模式；
• 業務物件、欄位型別、唯一鍵、歷史快照；
• 計算公式及證據來源；
• 角色、許可權、資料範圍、欄位級許可權；
• 狀態機與審批鏈；
• 匯入預覽、防重和事務策略；
• 報表、看板、列印/匯出；
• 審計、備份、恢復、遷移、升級；
• 目標機驗收和未確認事項。

動態欄位場景優先使用 schema snapshot；欄位重新命名/拆分時保留顯式舊→新對映，預設非破壞式遷移。

7.1 自動生成完整業務模組（2.6.0）

當 business_objects 已有可追溯欄位結構後，優先使用：

python scripts/run_skill.py generate --spec "<工作目錄>/system-spec.json" --output "<專案目錄>"

該命令會先生成通用工程底座，再自動物化：

• 每個業務物件對應的 SQLite 業務表與遷移；
• 新增、修改、刪除、列表、查詢、分頁；
• Excel/CSV 匯入，且必須先預覽再確認寫入；
• Excel 匯出；
• 按業務物件生成 RBAC 許可權並自動賦予管理員；
• 增刪改匯入匯出的審計日誌；
• 對 auto_executable=true 的安全公式在伺服器端重新計算；
• AUTO_GENERATION_REPORT.md 與 business/generated_schema.json。

候選唯一鍵不會自動建立資料庫 UNIQUE。只有在 confirmed_unique_keys 中明確確認的鍵才會生成正式唯一約束。審批、金額/工時正式口徑、跨表強外部索引鍵和欄位級許可權仍必須滿足證據門檻。

7.2 執行級 E2E 與嚴格驗收（2.7.0）

生成後優先執行：

python scripts/run_skill.py test --project "<專案目錄>"
python scripts/run_skill.py validate --project "<專案目錄>" --strict

test 永遠在隔離副本中執行，不改寫原專案業務資料庫。通過後會更新 TEST_REPORT.md 與 DELIVERY_STATUS.json.runtime_e2e_verified。測試覆蓋：啟動與 /health、管理員登入、CRUD、數字/日期/布林等嚴格型別校驗、CSV 逐行匯入校驗、XLSX 匯出、專案級安全停止、SQLite 備份/恢復與完整性檢查。

2.7.0 起，validate --strict 如果發現 tests_executed 為空、runtime_e2e_verified != true 或 TEST_REPORT 仍為“未執行”，必須失敗。靜態驗收通過不再等同於系統可用。

7.3 安全升級已有系統（2.7.0）

python scripts/run_skill.py upgrade --project "<舊專案目錄>" --spec "<新system-spec.json>" --output "<升級副本目錄>"

升級流程先生成 UPGRADE_DIFF_REPORT.md 與 upgrade-diff.json，將變化分成：

• safe_additive：新增物件、新增欄位，可自動建立升級副本；
• review_required：標籤、唯一約束、公式、許可權/流程等變化，需要業務複核；
• breaking：刪除物件、刪除欄位、欄位改型別，預設阻斷自動升級。

升級始終生成新副本並保留舊 system-spec.before-upgrade.json；不會直接修改原專案。SQLite 執行時會檢查舊錶結構並非破壞式補齊缺失的新欄位。破壞性變化即使使用 --allow-breaking 也只是允許生成升級副本，不代表遷移風險已經自動消除，仍必須人工遷移演練與重新 E2E。

8. 從零生成與繼承升級

有現有原始碼/資料庫

優先繼承升級。先識別資料庫、遷移、許可權、路由、匯入匯出、啟停、測試和歷史相容，不得無理由推倒重寫。

無現有原始碼

完善 system-spec.json 後執行：

python scripts/run_skill.py generate --spec <工作目錄>/system-spec.json --output <專案目錄>

generate 會自動物化有證據支撐的業務物件、欄位、CRUD、搜尋、匯入匯出、RBAC、審計和安全公式；審批、正式唯一鍵、複雜統計與無證據規則繼續按待確認項處理。只有明確只要工程底座時才使用 scaffold。

公共工程模式見 references/proven-system-patterns.md；骨架邊界見 references/scaffold-contract.md。

9. portable_full 完整部署包模式

當 system-spec.json.system.deployment_mode = "portable_full" 時，不得只交付扁平原始碼目錄。必須按 references/portable-full-contract.md 生成 V1.5.11 級完整包裝：

• 01_服務端_完整程式/；
• 02_Windows填寫客戶端/；
• 條件式 03_macOS填寫客戶端/；
• 04_業務原始資料參考/、05_電子檔模板/；
• 06_說明與版本記錄/00_當前版本/；
• 根目錄一鍵啟停；
• Windows 客戶端伺服器地址設定、連線測試；
• 區域網地址/埠輔助；
• 明確執行時策略與“免 Python/完全離線”宣告證據。

繼承現有 V1.5.11 類系統時，優先保留其完整部署結構、資料、遷移、客戶端和執行生命週期，不得降級為簡化原始碼包。

portable_full 額外驗收：

python scripts/validate_portable_full.py <專案目錄> --strict

只有實際帶入並驗證 EXE 或便攜執行時，才能宣稱“免 Python 解壓即用”；只有依賴也可離線獲得時，才能宣稱“首次安裝完全離線”。

10. 預設本地部署技術棧

能力邊界先說明： 預設生成目標是 Windows 10/11 上的 Python 本地 Web 系統。預設技術棧不是“只能生成 Python”的營銷承諾，而是本技能當前腳手架和驗收體系的實際實現邊界。使用者若要求非 Python、iOS 原生、Android 原生、純前端靜態站或其他技術棧，應先說明需要重新設計生成底座，不能直接聲稱當前技能已經支援。

除非使用者指定其他技術棧，預設：

• Python 3.10+
• Flask + Jinja2
• SQLite
• 原生 JS/CSS
• openpyxl/XlsxWriter
• Waitress
• zh-CN
• 預設業務時區 Asia/Shanghai
• Windows 10/11 為第一目標
• 核心功能斷網可用，不依賴 CDN、遠端字型或線上許可證

單機預設監聽 127.0.0.1；只有明確要求區域網共享時才監聽內網地址。埠必須可配置。

11. 必須具備的工程能力

正常“生成系統”任務至少實現：

• 登入、改密、退出；
• 服務端 RBAC 與必要的資料範圍/使用者覆蓋；
• 審計日誌；
• SQLite WAL、事務、引數化 SQL、遷移；
• 真實 Excel/CSV 匯入預覽、校驗、防重、匯出；
• 備份、完整性檢查、恢復前回滾副本；
• 健康檢查；
• 專案專屬安全啟動/停止；
• 一鍵診斷；
• 目標電腦驗收入口；
• Windows EXE 構建原始碼與 PyInstaller spec；
• 中文執行說明與已知限制。

稽核鏈不得寫死，可為無稽核、單級、序列多級、並行多稽核人或任意 N 人完成。只有附件有證據時才落定具體規則。

12. 啟停與遷移硬規則

停止指令碼必須只控制本專案例項，禁止：

• taskkill /IM python.exe
• taskkill /F /IM pythonw.exe
• killall python
• pkill -f python

推薦共享專案專屬 PID/狀態檔案、埠和隨機 shutdown token。

資料庫升級前備份；遷移顯式版本化、冪等、失敗可回滾；禁止升級時靜默重算已確認歷史值。

13. 最終交付

除非使用者明確只要方案/原型/單檔案，正常“生成系統”任務預設交付完整 ZIP。

完整交付契約見：

references/local-deployment-contract.md

交付前按：

references/acceptance-checklist.md

執行驗收。

至少執行：

python scripts/validate_local_bundle.py <專案目錄> --strict

如果是 portable_full，還必須執行：

python scripts/validate_portable_full.py <專案目錄> --strict

如果專案包含 delivery-manifest.json，再執行：

python scripts/validate_delivery.py <專案目錄> --strict

最終打包優先執行：

python scripts/finalize_delivery.py <專案目錄> --output <系統.zip>

只有驗證成功後才能宣稱“完整交付”。

14. 價值報告與驗證表述

VALUE_REPORT.md 只有收到真實 before_minutes、after_minutes、sample_count 時才允許計算效率變化。不得用演示資料、經驗值或模型估算冒充實測。

Windows EXE 未在 Windows 真機實際構建和執行時，只能表述為“已包含構建原始碼，未完成真機驗證”。靜態檢查不能替代目標電腦驗收。

15. 異常恢復與有限重試

任何指令碼返回非零狀態時：

1. 保留錯誤碼和最小定位，不用大段堆疊代替解釋；
2. 讀取 references/usage-and-troubleshooting.md，給出使用者可執行的修復動作和恢復點；
3. 原因不明確時執行 python scripts/diagnose.py --source <材料> --project <專案> --strict，只提供實際存在的引數；
4. 只有只讀或冪等步驟、原因明確且修復已完成時，才自動重試一次；寫庫、遷移、恢復、覆蓋和打包失敗不得盲目迴圈；
5. 可選聯網步驟超時時，不阻斷離線核心生成。記錄未完成項；只有使用者已授權且呼叫冪等時才重試一次。

不得把“重新執行全部流程”作為預設修復。優先從診斷報告中的 recommended_resume_point 或最近通過階段繼續。

16. 使用者可用最短觸發語

使用者不需要複製長工程規範。以下短句應進入完整生成流程：

根據這份報表和附件生成對應的完整本地部署業務系統 ZIP。

如果使用者說“做成和這個 V1.5.11 一樣的完整區域網部署包”，自動進入 portable_full，不得要求使用者再寫工程細節。

如果使用者只說“把這個 Excel 做成系統”“根據這些檔案做個本地系統”，也按同樣流程執行；重要規則證據不足時顯式保留待確認項，而不是降低為靜態原型。

17. 參考檔案路由

18. 能力宣告與驗證門禁

技能對外描述必須區分“設計支援”“指令碼檢查通過”和“目標機實測通過”，禁止把設計目標寫成已經驗證的事實。

14.1 三檔宣告

尤其是“免 Python”“完全離線”“區域網多人”“EXE 解壓即用”“不會資料丟失”等強宣告，必須有對應證據後才能使用。

14.2 交付前最低證據

最終 ZIP 至少應能追溯：輸入資料盤點、業務規格、測試結果、驗收結果、交付狀態和檔案清單。缺少實際測試時，在 TEST_REPORT.md 或交付說明中明確標記“未實測”，不要用“已驗證”“保證”等詞替代。

14.3 使用者可見的失敗資訊

錯誤資訊必須同時回答：哪裡出錯、為什麼、使用者/執行者現在做什麼、修復後從哪裡繼續。優先使用 PBxxx 錯誤碼和 cause/action/resume_point，不要把 Python traceback 直接作為主要說明。

19. 最小可復現示例

完整示例與常見問題集中放在 references/usage-and-troubleshooting.md。每次需要示例時優先引用其中的“示例 A/B/C”。示例只用於說明呼叫方式，不得當作業務規則或驗收結果。

這個 Skill 質量很好，上傳 Excel 或表單資料就能自動生成可用的業務系統，不用懂技術。文件寫得清楚，操作流程簡單明瞭，功能覆蓋全面，測試和驗收都很規範。最實用的是它能把資料直接變成能查詢、統計、匯入匯出的系統，還能打包成 ZIP 交付。唯一的不足是版本號在文件裡藏得比較深，不太好找。總體來說，這是一個非常實用的系統生成工具，適合需要快速把紙質表單變成數字化系統的使用者。