Spaces:
Running
Running
檢視角度改以 CIA 三要素為框架，並校準完整性的定義
Browse files原本四個角度只是列舉，沒有說明依據。改為明確採用資訊安全的 CIA 三
要素（機密性／完整性／可用性，ISO/IEC 27000 系列對資訊安全的定義
基礎），並說明選它的理由：任何資訊系統的風險最終都會落在「不該看到
的人看到了」「產出被破壞或殘缺」「該用時用不了」三類之一，涵蓋面完整。
第四項「可維護性」明確標示不屬於 CIA，出處為 ISO/IEC 25010 軟體品質
模型，並說明納入理由（前三項的改善都落在同一份程式碼上）。
同時校準「完整性」的定義。原本寫的是「錯誤情境有沒有處理完」，那是
錯誤處理健全度，不是 Integrity 的標準意思；若直接掛上 CIA 而定義對
不上，反而降低可信度。改為標準定義「資訊與產出保持正確、完整，未遭
意外或未授權的變更」。
第三節補上歸類理由，讓內文支撐表格的分類：LLM 呼叫失敗時系統不會停
下來，而是標記該階段失敗後繼續，使用者仍拿到一份看起來完成、實際缺
了報告本文的產出。缺乏重試機制的後果因此不只是慢或要重跑，而是可能
交付殘缺成果，這才是 Integrity 問題。
表格改為四欄：角度、標準定義、在本系統的具體提問、帶出的項目。
- docs/開發優化建議.md +16 -8
docs/開發優化建議.md
CHANGED
|
@@ -20,14 +20,20 @@
|
|
| 20 |
|
| 21 |
## 檢視角度
|
| 22 |
|
| 23 |
-
本文件
|
| 24 |
|
| 25 |
-
|
| 26 |
-
|
| 27 |
-
|
| 28 |
-
|
| 29 |
-
|
|
| 30 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 31 |
|
| 32 |
---
|
| 33 |
|
|
@@ -172,7 +178,9 @@
|
|
| 172 |
|
| 173 |
## 三、LLM API 呼叫可靠性強化
|
| 174 |
|
| 175 |
-
2026-08-05 實測過程中，以測試用的 OpenRouter API Key 直接呼叫 `_call_openrouter()`（app_agent.py:377-401），發現兩個目前程式碼裡沒有處理
|
|
|
|
|
|
|
| 176 |
|
| 177 |
```python
|
| 178 |
def _call_openrouter(api_key, model, system_prompt, user_prompt, max_tokens=16000, temperature=0.5):
|
|
|
|
| 20 |
|
| 21 |
## 檢視角度
|
| 22 |
|
| 23 |
+
本文件的檢視框架採用**資訊安全的 CIA 三要素**，再補上一項軟體品質特性。
|
| 24 |
|
| 25 |
+
CIA 指機密性（**C**onfidentiality）、完整性（**I**ntegrity）、可用性（**A**vailability），是 ISO/IEC 27000 系列標準對「資訊安全」的定義基礎，也是資安領域公認的核心原則。用它當檢視框架的好處是涵蓋面完整：任何一個資訊系統的風險，最終都會落在「不該看到的人看到了」「資料或產出被破壞、殘缺」「該用的時候用不了」這三類的其中之一。
|
| 26 |
+
|
| 27 |
+
第四項「可維護性」不屬於 CIA，取自 ISO/IEC 25010 軟體品質模型的八大特性之一。納入的理由是：前三項的改善全部要落在同一份程式碼上，維護性差會直接放大其他每一項的施工成本與風險。
|
| 28 |
+
|
| 29 |
+
| 角度 | 標準定義 | 在本系統的具體提問 | 帶出的項目 |
|
| 30 |
+
|---|---|---|---|
|
| 31 |
+
| **機密性**<br>Confidentiality | 資訊只開放給有權限者存取 | 使用者上傳的研究語料，會流到哪裡、留在哪裡、誰看得到？ | 一、四、六 |
|
| 32 |
+
| **完整性**<br>Integrity | 資訊與產出保持正確、完整，未遭意外或未授權的變更 | 系統交付的結果是否完整？失敗時會不會交出殘缺的東西？ | 三 |
|
| 33 |
+
| **可用性**<br>Availability | 有權限者在需要時可正常取用 | 使用者實際操作時，會不會卡住、拿不到已經產出的結果？ | 二 |
|
| 34 |
+
| **可維護性**<br>Maintainability<br><sub>（非 CIA，ISO/IEC 25010）</sub> | 系統可被有效率地修改而不引入缺陷 | 下一個接手的人，能不能安全地改這份程式碼？ | 五 |
|
| 35 |
+
|
| 36 |
+
同一個項目可能同時命中多個角度，歸類以最主要者為準。第七、第八節屬產品決策，不涉及上述風險，未納入本表。
|
| 37 |
|
| 38 |
---
|
| 39 |
|
|
|
|
| 178 |
|
| 179 |
## 三、LLM API 呼叫可靠性強化
|
| 180 |
|
| 181 |
+
2026-08-05 實測過程中，以測試用的 OpenRouter API Key 直接呼叫 `_call_openrouter()`（app_agent.py:377-401），發現兩個目前程式碼裡沒有處理的問題（3.1、3.2）。這兩點集中在同一個函式，建議一次評估、一次修改。
|
| 182 |
+
|
| 183 |
+
**歸類為完整性問題的理由**：LLM 呼叫失敗時，系統不會整個停下來，而是讓該階段標記失敗後繼續往下走。結果是使用者仍然拿到一份分析產出，只是裡面缺了報告本文。也就是說，缺乏重試機制的實際後果不只是「慢」或「要重跑」，而是**系統可能交付一份殘缺卻看起來完成的成果**。研究者若沒注意到缺漏，可能誤以為那就是完整結果。
|
| 184 |
|
| 185 |
```python
|
| 186 |
def _call_openrouter(api_key, model, system_prompt, user_prompt, max_tokens=16000, temperature=0.5):
|