MCP/mcp-shrimp-task-manager
1
0
Fork 0
mirror of https://github.com/cjo4m06/mcp-shrimp-task-manager.git synced 2025-07-27 08:32:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

更新任務分析與執行指引，增強任務拆分與質量審核標準，提供更詳細的技術分析步驟與執行計劃指南，提升任務管理的靈活性與準確性。

Browse Source
This commit is contained in:
siage 2025-04-12 15:07:29 +08:00
parent 9581d2125e
commit 40e2ce915c
1 changed files with 322 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

374
src/tools/taskTools.ts
View File

@ -73,10 +73,29 @@ export async function planTask({
2. 識別任務中可能的技術挑戰和關鍵決策點 2. 識別任務中可能的技術挑戰和關鍵決策點
3. 考慮潛在的解決方案和替代方案 3. 考慮潛在的解決方案和替代方案
4. 評估每種方案的優缺點 4. 評估每種方案的優缺點
5. 判斷是否需要分解為多個子任務
6. 考慮與現有系統的集成需求
如果對任務描述有任何不清楚或需要澄清的地方，請明確向用戶提問。 如果對任務描述有任何不清楚或需要澄清的地方，請明確向用戶提問。提問時應具體指出哪些資訊缺失或模糊，並提供可能的選項。
## 下一步行動\n\n完成初步分析後，請使用「analyze_task」工具提交您的分析結果，必須同時包含：\n\n1. 結構化的任務摘要（包括目標、範圍和關鍵挑戰）\n2. 初步解答構想（包括技術方案和實施策略）`; ## 任務分析最佳實踐\n\n- 保持客觀分析，避免過早做出技術選擇
- 考慮長期影響，不僅僅關注短期解決方案
- 識別假設和風險，明確標注需要進一步確認的部分
- 在分析中引用相關文檔或代碼庫中的證據支持您的觀點
## 下一步行動\n\n完成初步分析後，請使用「analyze_task」工具提交您的分析結果，必須包含以下兩個關鍵部分：\n\n1. **結構化的任務摘要**：
- 明確的任務目標和期望成果
- 明確的範圍界定（包括明確標注哪些不在範圍內）
- 主要技術挑戰清單
- 相關係統依賴和限制條件
2. **初步解答構想**：
- 詳細的技術方案描述
- 實施策略和主要步驟
- 可能的替代方案及其優缺點比較
- 測試和驗證策略建議
請確保您的分析全面且深入，這將作為後續所有開發工作的基礎。`;
return { return {
content: [ content: [
@ -133,18 +152,49 @@ export async function analyzeTask({
let prompt = `## 代碼庫分析任務\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n已收到您的初步解答構想：\n\n\`\`\`\n${initialConcept}\n\`\`\`\n\n`; let prompt = `## 代碼庫分析任務\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n已收到您的初步解答構想：\n\n\`\`\`\n${initialConcept}\n\`\`\`\n\n`;
prompt += `## 技術審核指引\n\n請執行以下分析步驟：\n\n1. 檢查現有程式碼庫中的相似實現或可重用組件 prompt += `## 技術審核指引\n\n請執行以下詳細的技術分析步驟：\n\n### 1. 代碼庫分析
2. 評估是否可以抽象出通用模式或利用現有框架 - 檢查現有程式碼庫中的相似實現或可重用組件
3. 識別潛在的技術債務或效能瓶頸 - 分析系統架構，確定新功能的適當位置
4. 確保方案符合項目的架構風格和最佳實踐 - 評估與現有模塊的整合方式和潛在影響
- 識別可能受影響的其他系統部分
請特別關注程式碼重用的機會，避免重複實作已有功能，降低技術債務風險。`; ### 2. 技術策略評估
- 評估是否可以抽象出通用模式或利用現有框架
- 考慮模塊化和可擴展性設計原則
- 分析提案的擴展性和未來兼容性
- 評估測試策略和測試覆蓋率要求
### 3. 風險和質量分析
- 識別潛在的技術債務或效能瓶頸
- 評估安全性和數據完整性考量
- 分析錯誤處理和異常情況處理機制
### 4. 實施建議
- 確保方案符合項目的架構風格和最佳實踐
- 建議特定的實施方法和技術選擇
- 提出明確的開發步驟和里程碑
請特別關注程式碼重用的機會，避免重複實作已有功能，降低技術債務風險。分析中應引用具體的代碼文件和行號作為證據支持您的評估。`;
if (previousAnalysis) { if (previousAnalysis) {
prompt += `\n\n## 迭代分析\n\n請對照先前的分析結果進行比較和改進：\n\n\`\`\`\n${previousAnalysis}\n\`\`\`\n\n請明確識別：\n1. 哪些問題已經解決\n2. 哪些問題仍然存在\n3. 您的新方案如何解決之前未解決的問題`; prompt += `\n\n## 迭代分析\n\n請對照先前的分析結果進行比較和改進：\n\n\`\`\`\n${previousAnalysis}\n\`\`\`\n\n請明確識別：\n1. 哪些問題已經解決，以及解決方案的有效性
2. 哪些問題仍然存在，及其優先級和嚴重性
3. 您的新方案如何解決之前未解決的問題
4. 迭代過程中獲得的新見解和經驗教訓`;
} }
prompt += `\n\n## 下一步行動\n\n完成深入分析後，請使用「reflect_task」工具提交：\n\n1. 原始任務摘要（保持與第一階段一致）\n2. 完整的分析結果（包括技術細節、依賴組件和實施策略）`; prompt += `\n\n## 下一步行動\n\n完成深入分析後，請使用「reflect_task」工具提交您的最終分析，必須包含：\n\n1. **原始任務摘要**：
- 保持與第一階段一致，確保分析連續性
- 必要時可以澄清或精確化原始摘要，但不應改變核心目標
2. **完整的分析結果**：
- 詳盡的技術細節和規格定義
- 與現有系統的所有接口和依賴關係
- 明確的實施策略和步驟
- 預期結果和驗收標準
- 具體的工作量估計和資源需求
您的詳細分析將決定任務的解決方案質量。請確保全面考慮各種技術因素和業務約束，提供專業且實用的技術建議。`;
return { return {
content: [ content: [
@ -200,21 +250,41 @@ export async function reflectTask({
console.error("記錄對話日誌時發生錯誤:", error); console.error("記錄對話日誌時發生錯誤:", error);
} }
const prompt = `## 解決方案反思與評估\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n### 詳細分析結果\n\`\`\`\n${analysis}\n\`\`\`\n\n## 批判性評估指引\n\n請從以下多個維度對您的解決方案進行全面且批判性的審查：\n\n### 1. 技術完整性評估\n- 方案是否存在技術缺陷或邏輯漏洞？ const prompt = `## 解決方案反思與評估\n\n### 任務摘要\n\`\`\`\n${summary}\n\`\`\`\n\n### 詳細分析結果\n\`\`\`\n${analysis}\n\`\`\`\n\n## 批判性評估指引\n\n請從以下多個維度對您的解決方案進行全面且批判性的審查：\n\n### 1. 技術完整性評估
- 是否考慮了邊緣情況和異常處理？ - 方案是否存在技術缺陷或邏輯漏洞？從各個角度檢驗解決方案的完整性。
- 所有數據流和控制流是否清晰定義？ - 所有邊緣情況和異常處理是否周全？列舉可能的異常場景並驗證處理方式。
- 所有數據流和控制流是否清晰定義？繪製流程圖以確認各環節無缺失。
- 實現是否考慮了所有必要的技術限制和依賴條件？檢查系統間的相互作用。
- 解決方案的技術選擇是否適合問題的性質和規模？評估技術選型合理性。
### 2. 效能與可擴展性評估 ### 2. 效能與可擴展性評估
- 解決方案在資源使用效率方面是否最佳化？ - 解決方案在資源使用效率方面是否最佳化？分析計算、存儲和網絡資源消耗。
- 系統在負載增加時是否仍能保持穩定性能？ - 系統在負載增加時是否仍能保持穩定性能？考慮擴展性瓶頸和解決方案。
- 是否有可能進一步優化的部分？ - 是否有可能進一步優化的部分？找出潛在的優化點並提出具體改進方案。
- 是否考慮了未來功能擴展的可能性？評估方案的長期可持續性。
### 3. 需求符合度評估 ### 3. 需求符合度評估
- 解決方案是否完全實現了所有功能需求？ - 解決方案是否完全實現了所有功能需求？逐條核對需求列表。
- 是否符合所有非功能性需求（如安全性、可維護性）？ - 是否符合所有非功能性需求（如安全性、可維護性）？全面檢查各方面的需求符合情況。
- 是否有遺漏或誤解的需求？ - 是否有遺漏或誤解的需求？重新審視原始任務描述，確保全部涵蓋。
- 使用者體驗和可用性是否達到預期標準？從最終用戶角度評估方案。
- 是否考慮了業務流程與解決方案的整合？確認解決方案能夠融入現有業務流程。
## 決策點\n\n基於您的反思，請選擇下一步行動：\n\n- 如果發現需要改進的關鍵問題：請使用「analyze_task」工具，重新提交改進後的方案（必須包含之前的摘要和修改後的構想）\n\n- 如果確認方案已足夠完善：請使用「split_tasks」工具，將解決方案分解為具體、可執行的子任務，並建立明確的依賴關係`; ## 決策點與行動建議\n\n基於您的反思，請選擇下一步行動：\n\n- **如果發現需要顯著改進的關鍵問題**：
- 請使用「analyze_task」工具，重新提交改進後的方案
- 明確指出問題所在並提供具體的改進方向
- 保留原摘要，但徹底修訂方案中的問題部分
- **如果只需輕微調整或優化**：
- 直接在下一步中應用這些小的改進
- 記錄需要調整的具體點供後續實施參考
- **如果確認方案已足夠完善**：
- 請使用「split_tasks」工具，將解決方案分解為具體、可執行的子任務
- 建立明確的依賴關係和執行順序
- 為每個子任務設定明確的完成標準和驗收條件
您的批判性評估將決定最終方案的質量，請務必嚴格審查，不放過任何潛在問題。`;
return { return {
content: [ content: [
@ -342,17 +412,40 @@ export async function splitTasks({
isOverwrite ? "覆蓋模式" : "新增模式" isOverwrite ? "覆蓋模式" : "新增模式"
}\n\n### 系統確認\n任務已成功${ }\n\n### 系統確認\n任務已成功${
isOverwrite ? "覆蓋現有任務清單" : "新增至現有任務清單" isOverwrite ? "覆蓋現有任務清單" : "新增至現有任務清單"
}。\n\n## 任務質量審核指引\n\n請根據以下標準對任務拆分進行嚴格的質量審核：\n\n### 1. 任務原子性\n- 每個任務是否足夠小且具體，可獨立完成？ }。\n\n## 任務拆分指南\n\n### 有效的任務拆分策略\n\n1. **按功能分解** - 將大功能拆分為獨立可測試的子功能
- 每個子功能應有清晰的輸入、輸出和功能邊界
- 確保子功能間邏輯關係明確且最小化耦合
- 避免功能過度細分導致管理複雜度增加
2. **按技術層次分解** - 沿系統架構層次分離任務
- 前端界面層、業務邏輯層、數據訪問層分別拆分
- 確保層間接口明確，便於並行開發
- 優先完成底層核心功能，逐層向上構建
3. **按開發階段分解** - 從原型到完善的演進路徑
- 初始開發階段專注核心功能實現
- 測試與完善階段改進錯誤處理與邊緣案例
- 優化階段專注性能與用戶體驗提升
4. **按風險程度分解** - 隔離高風險部分
- 將技術風險高的部分單獨拆分為探索性任務
- 將業務邏輯複雜的部分細化為可管理的子任務
- 通過獨立任務降低風險對整體進度的影響
## 任務質量審核指引\n\n請根據以下標準對任務拆分進行嚴格的質量審核：\n\n### 1. 任務原子性\n- 每個任務是否足夠小且具體，可獨立完成？
- 任務是否具有清晰的完成標準？ - 任務是否具有清晰的完成標準？
- 是否避免了範圍過大的任務？ - 是否避免了範圍過大的任務？
- 任務大小是否平衡，避免出現極大或極小的任務？
### 2. 依賴關係完整性\n- 任務依賴關係是否形成有向無環圖？ ### 2. 依賴關係完整性\n- 任務依賴關係是否形成有向無環圖？
- 是否存在隱藏依賴未被明確標記？ - 是否存在隱藏依賴未被明確標記？
- 依賴鏈是否最短化，避免不必要的阻塞？ - 依賴鏈是否最短化，避免不必要的阻塞？
- 是否優先考慮了任務的並行執行可能性？
### 3. 描述完整性\n- 每個任務描述是否清晰準確？ ### 3. 描述完整性\n- 每個任務描述是否清晰準確？
- 是否包含足夠的上下文信息？ - 是否包含足夠的上下文信息？
- 注意事項是否涵蓋關鍵實施細節？ - 注意事項是否涵蓋關鍵實施細節？
- 是否明確了任務的驗收標準？
## 詳細任務清單\n\n${createdTasks ## 詳細任務清單\n\n${createdTasks
.map( .map(
@ -377,11 +470,25 @@ export async function splitTasks({
) )
.join( .join(
"\n" "\n"
)}\n\n## 任務依賴提示\n\n在建立新任務時，可以通過以下方式指定依賴關係：\n\n1. **使用任務名稱**（推薦）：直接使用其他任務的名稱，如 \`"建立用戶界面"\`\n2. **使用任務ID**：使用任務的唯一標識符，如 \`"${ )}\n\n## 任務依賴管理技巧\n\n### 依賴關係設置\n在建立新任務時，可以通過以下方式指定依賴關係：\n\n1. **使用任務名稱**（推薦）：直接使用其他任務的名稱，如 \`"建立用戶界面"\`\n2. **使用任務ID**：使用任務的唯一標識符，如 \`"${
createdTasks.length > 0 createdTasks.length > 0
? createdTasks[0].id ? createdTasks[0].id
: "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6" : "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6"
}"\`\n\n## 決策點\n\n請選擇下一步行動：\n\n- 如發現任務拆分不合理：請重新呼叫「split_tasks」工具，調整任務定義或依賴關係\n\n- 如確認任務拆分完善：請生成執行計劃摘要，包括建議的執行順序、關鍵路徑和風險點`; }"\`\n
### 依賴關係最佳實踐
- **最小化依賴數量** - 僅設置直接前置任務為依賴
- **避免循環依賴** - 確保任務圖是有向無環的
- **平衡關鍵路徑** - 減少關鍵路徑上的任務數量
- **提高並行度** - 結構設計應允許多個任務並行執行
## 執行計劃指南
### 關鍵路徑識別
- 確定項目關鍵路徑上的任務序列
- 優先分配資源到關鍵路徑任務
- 監控關鍵路徑任務進度，防止延誤
## 決策點\n\n請選擇下一步行動：\n\n- 如發現任務拆分不合理：請重新呼叫「split_tasks」工具，調整任務定義或依賴關係\n\n- 如確認任務拆分完善：請生成執行計劃摘要，包括建議的執行順序、關鍵路徑和風險點`;
return { return {
content: [ content: [
@ -778,23 +885,74 @@ export async function executeTask({
prompt += contextInfo; prompt += contextInfo;
} }
prompt += `\n## 執行指引\n\n1. 請仔細分析任務要求，確保理解所有細節和約束條件 prompt += `\n## 執行指引\n\n### 理解與規劃階段
2. 設計詳細的執行方案，包括具體步驟和技術選擇 1. **仔細分析任務需求** - 全面理解任務描述、注意事項和約束條件
3. 系統性地實施您的方案，遵循最佳實踐和項目慣例 - 識別核心需求和次要需求，建立優先級
4. 完整記錄您的實施過程，包括重要決策點和遇到的挑戰 - 確認與現有系統的整合要點和依賴關係
5. 實時更新任務相關文件，確保上下文記憶持續有效 - 評估潛在的技術難點和解決方案
## 專注限制\n\n為確保系統穩定性和任務準確性，請嚴格遵守：\n\n- 僅修改與任務直接相關的代碼區域，不做範圍外的修改\n- 所有變更必須可直接追溯到任務描述中的明確需求\n- 發現範圍外問題時，僅記錄不修改，保持系統整體一致性\n- 當任務描述與實際需求存在歧義時，優先選擇影響範圍最小的實現方案\n- 不自行擴展需求範圍，即使發現可能的優化機會\n\n如有疑問，請立即向用戶請求澄清，而非做出假設性修改。 2. **設計執行方案** - 制定結構化的實施計劃
- 定義明確的實施步驟和執行順序
- 選擇適合的技術方案，考慮系統架構一致性
- 設計測試策略，確保功能正確性和質量
## 質量保證\n\n- 確保代碼符合專案編碼標準和架構設計 ### 實施與測試階段
- 實施適當的錯誤處理和邊緣情況檢查 3. **系統性實施方案** - 按照計劃逐步執行
- 優化性能和資源使用 - 遵循項目的編碼規範和最佳實踐
- 實現核心功能，確保與現有系統正確整合
- 處理邊緣情況和錯誤處理機制
- 持續參考現有代碼風格和架構模式
## 上下文記憶管理\n\n- 在執行過程中，使用 update_task_files 工具更新重要的相關文件 4. **全面測試與驗證** - 確保實現的正確性和穩健性
- 關注關鍵代碼片段，記錄代碼行號以便精確定位 - 測試核心功能和邊緣情況
- 將重要的發現、決策和實現細節記錄為文件關聯和描述 - 驗證與其他系統組件的交互
- 評估性能影響和資源使用情況
- 確保符合原始需求規格
## 下一步行動\n\n完成實施後，必須使用「verify_task」工具進行全面驗證，確保所有功能和要求均已正確實現。`; ### 文檔與完成階段
5. **完整記錄實施過程** - 詳細記錄關鍵決策和實施細節
- 記錄技術選擇理由和考量因素
- 描述遇到的問題及其解決方法
- 提供實現的核心邏輯說明
- 注明可能需要後續改進的地方
6. **更新相關文件** - 保持文檔與代碼同步
- 使用 update_task_files 工具關聯和更新文件
- 記錄代碼行號以便精確定位關鍵實現
- 確保文檔反映最終實現的實際狀態
## 專注限制與質量保證\n\n### 範圍管理
- **嚴格遵守任務範圍** - 僅修改與任務直接相關的代碼區域
- 所有變更必須可直接追溯到任務描述中的明確需求
- 避免功能蔓延或過度設計
- 發現範圍外問題時，記錄但不立即修改，保持系統整體一致性
- **需求優先級管理** - 專注於完成核心需求
- 當需求與實際情況存在歧義時，選擇影響範圍最小的實現方案
- 不自行擴展需求範圍，即使發現潛在優化機會
- 對於重大設計決策，尋求用戶確認而非做出假設性修改
### 質量標準
- **代碼質量保證** - 確保交付高質量的實現
- 符合專案編碼標準和架構設計原則
- 實現適當的錯誤處理和邊緣情況檢查
- 注重代碼可讀性和可維護性
- 避免重複代碼，優先利用現有組件和函數
- **效能考量** - 優化性能和資源使用
- 考慮算法效率和數據結構選擇
- 避免不必要的計算或資源消耗
- 在關鍵路徑上進行必要的性能優化
- 平衡開發速度與執行效率
## 下一步行動\n\n完成實施後，必須使用「verify_task」工具進行全面驗證，確保所有功能和要求均已正確實現。驗證過程應包括：
- 功能完整性檢查 - 所有需求點是否已實現
- 代碼質量審核 - 是否符合項目標準和最佳實踐
- 兼容性測試 - 是否與現有系統無縫整合
- 性能評估 - 實現是否滿足效能要求
驗證通過後，使用「complete_task」工具標記任務完成並提供詳細的完成報告。`;
return { return {
content: [ content: [
@ -883,19 +1041,134 @@ export async function verifyTask({ taskId }: z.infer<typeof verifyTaskSchema>) {
task.notes ? `- **注意事項:** ${task.notes}\n` : "" task.notes ? `- **注意事項:** ${task.notes}\n` : ""
} }
## 完整性驗證標準\n\n請根據以下關鍵標準進行嚴格的質量檢查： ## 完整性驗證標準\n\n請根據以下關鍵標準進行嚴格的質量檢查，為每個評估項目提供詳細的證據和具體範例：
### 1. 需求符合性 (30%)\n- 實現是否完全符合任務描述中的所有功能需求？\n- 是否遵循了所有注意事項和約束條件？\n- 是否處理了所有業務邏輯的邊緣情況？ ### 1. 需求符合性 (30%)
#### 核心評估項目：
- **功能完整性** - 實現是否完全符合任務描述中的所有功能需求？
- 逐條檢查任務描述中的每一項功能點，確認全部實現
- 驗證主要功能流程的完整性和正確性
- 評估用戶交互體驗是否符合要求
### 2. 技術實現質量 (30%)\n- 代碼是否遵循了項目的架構模式和設計原則？\n- 是否有適當的錯誤處理和防禦性編程？\n- 實現是否簡潔高效，避免了不必要的複雜性？ - **約束條件遵循** - 是否遵循了所有注意事項和約束條件？
- 檢查是否嚴格遵守了任務指定的技術限制或規範
- 驗證實現是否符合任務描述中的特定要求
- 確認所有指定的業務規則都得到正確實現
### 3. 集成與兼容性 (20%)\n- 實現是否與現有系統無縫集成？\n- 是否考慮了與其他組件的相互作用？\n- 是否保持了向前和向後兼容性（如適用）？ - **邊緣情況處理** - 是否處理了所有業務邏輯的邊緣情況？
- 列舉並驗證各種可能的異常輸入和情況
- 檢查錯誤處理機制是否完善
- 評估實現對無效操作的容錯能力
### 4. 性能與可擴展性 (20%)\n- 實現是否考慮了性能優化？\n- 系統是否能夠處理預期的負載和擴展需求？\n- 是否避免了可能的資源洩漏或瓶頸？ #### 評分指南：
- **優秀(90-100%)**: 所有需求點完美實現，邊緣情況處理完備，代碼穩健可靠
- **良好(75-89%)**: 核心需求全部實現，少量邊緣情況可能需要優化
- **合格(60-74%)**: 主要功能已實現，但處理不夠完善或有遺漏
- **需改進(<60%)**: 關鍵功能缺失或實現不正確，需要重大修改
## 驗證結果報告\n\n請提供詳細的驗證結果報告，為每個標準分配評分並提供具體證據。對於發現的任何問題，請提供明確的修復建議。 ### 2. 技術實現質量 (30%)
#### 核心評估項目：
- **架構一致性** - 代碼是否遵循了項目的架構模式和設計原則？
- 評估實現是否符合現有代碼庫的架構風格
- 檢查模塊化程度和責任分離是否適當
- 驗證是否遵循了項目的編碼規範和命名慣例
## 決策點\n\n- 如果發現嚴重問題：請繼續改進並解決問題\n- 如果任務已完全符合要求：請使用「complete_task」工具，標記任務為已完成並提交最終報告`; - **程式健壯性** - 是否有適當的錯誤處理和防禦性編程？
- 檢查是否實施了適當的錯誤捕獲和處理機制
- 評估異常情況下的系統行為是否符合預期
- 驗證是否有防禦性檢查和輸入驗證
- **實現優雅性** - 實現是否簡潔高效，避免了不必要的複雜性？
- 評估代碼的可讀性和可維護性
- 檢查是否存在不必要的重複或冗餘邏輯
- 評估算法和數據結構選擇的適當性
#### 評分指南：
- **優秀(90-100%)**: 代碼優雅、健壯，完全符合項目架構標準，高度可維護
- **良好(75-89%)**: 代碼結構合理，錯誤處理完善，但可能有小的改進空間
- **合格(60-74%)**: 基本符合編碼標準，但存在架構或錯誤處理上的不足
- **需改進(<60%)**: 代碼質量較差，存在明顯的架構問題或錯誤處理不足
### 3. 集成與兼容性 (20%)
#### 核心評估項目：
- **系統整合** - 實現是否與現有系統無縫集成？
- 檢查與其他系統組件的接口是否正確實現
- 評估對現有功能的影響是否最小化
- 驗證是否正確使用了共享服務和組件
- **互操作性** - 是否考慮了與其他組件的相互作用？
- 評估與依賴服務或模塊的交互是否正確
- 檢查資源共享和競爭條件的處理
- 驗證數據交換格式和協議的兼容性
- **兼容性維護** - 是否保持了向前和向後兼容性（如適用）？
- 評估對現有API或界面的變更是否維持兼容性
- 檢查對舊數據格式或配置的支持
- 驗證升級路徑和降級策略
#### 評分指南：
- **優秀(90-100%)**: 完美集成，零衝突，維持所有必要的兼容性
- **良好(75-89%)**: 基本無縫集成，極少數邊緣情況下可能有小問題
- **合格(60-74%)**: 主要功能正確集成，但存在一些兼容性考慮不足
- **需改進(<60%)**: 集成存在明顯問題，對現有系統造成破壞性影響
### 4. 性能與可擴展性 (20%)
#### 核心評估項目：
- **效能優化** - 實現是否考慮了性能優化？
- 評估代碼執行效率和資源使用情況
- 檢查是否有不必要的計算或操作
- 驗證關鍵路徑的效能表現
- **負載適應性** - 系統是否能夠處理預期的負載和擴展需求？
- 評估在高負載下的系統行為和穩定性
- 檢查資源使用的可擴展性
- 驗證並發處理和資源競爭的管理
- **資源管理** - 是否避免了可能的資源洩漏或瓶頸？
- 檢查資源分配和釋放的正確性
- 評估內存使用效率和垃圾回收影響
- 驗證數據庫查詢或IO操作的效率
#### 評分指南：
- **優秀(90-100%)**: 高效實現，經過充分優化，具備優秀的擴展能力
- **良好(75-89%)**: 效能良好，無明顯瓶頸，滿足當前和可預見的需求
- **合格(60-74%)**: 基本性能可接受，但在高負載下可能存在問題
- **需改進(<60%)**: 存在明顯的性能問題或資源使用不當
## 驗證結果報告\n\n請提供詳細的驗證結果報告，應包含以下內容：
1. **整體評分與結論**：
- 根據上述評估標準給出總體評分和評級
- 簡明扼要的總結性評價
2. **各項標準詳細評估**：
- 為每個標準給出分項評分和具體證據
- 引用具體代碼示例或實現細節
- 指出特別出色或需要改進的部分
3. **發現的問題與建議**：
- 按嚴重程度列出所有發現的問題
- 為每個問題提供具體、可行的修復建議
- 區分必須修復的關鍵問題和可選的優化建議
4. **最終結論和建議**：
- 明確指出是否符合驗收標準
- 提供關於後續步驟的清晰建議
## 決策點\n\n根據您的全面驗證評估，請選擇適當的後續行動：
- **如果發現嚴重問題需要修復**：
- 詳細列出所有問題及其優先級
- 提供具體的修復指導
- 建議繼續改進並解決關鍵問題
- 「plan_task」工具，計劃修復問題的步驟
- **如果任務已完全符合要求**：
- 總結實現的主要優點和特色
- 使用「complete_task」工具，標記任務為已完成
- 提出任務完成總結報告的要點建議
您的驗證評估將直接影響產品質量，請以專業和批判性的眼光進行全面檢查。`;
return { return {
content: [ content: [
@ -995,11 +1268,10 @@ export async function completeTask({
try { try {
await addConversationEntry( await addConversationEntry(
ConversationParticipant.MCP, ConversationParticipant.MCP,
`任務成功完成：${task.name} (ID: ${ `任務成功完成：${task.name} (ID: ${task.id})，完成摘要：${extractSummary(
task.id taskSummary,
})，摘要：${taskSummary.substring(0, 100)}${ 100
taskSummary.length > 100 ? "..." : "" )}`,
}`,
task.id, task.id,
"任務完成" "任務完成"
); );
@ -1007,15 +1279,13 @@ export async function completeTask({
console.error("記錄對話日誌時發生錯誤:", error); console.error("記錄對話日誌時發生錯誤:", error);
} }
const prompt = `## 任務完成確認\n\n任務 "${task.name}" (ID: \`${
task.id
}\`) 已於 ${new Date().toISOString()} 成功標記為完成。\n\n## 任務摘要要求\n\n請提供此次完成任務的摘要總結，包含以下關鍵要點：\n\n1. 任務目標與主要成果\n2. 實施的解決方案要點\n3. 遇到的主要挑戰及解決方法\n\n**重要提示：** 請在當前回應中提供任務摘要總結。完成本次任務摘要後，請等待用戶明確指示後再繼續執行其他任務。請勿自動開始執行下一個任務。\n\n您可以使用「list_tasks」工具查看剩餘任務，但請等待用戶明確指示再繼續。`;
return { return {
content: [ content: [
{ {
type: "text" as const, type: "text" as const,
text: prompt, text: `## 任務完成確認\n\n任務 "${task.name}" (ID: \`${
task.id
}\`) 已於 ${new Date().toISOString()} 成功標記為完成。\n\n## 任務摘要要求\n\n請提供此次完成任務的摘要總結，包含以下關鍵要點：\n\n1. 任務目標與主要成果\n2. 實施的解決方案要點\n3. 遇到的主要挑戰及解決方法\n\n**重要提示：** 請在當前回應中提供任務摘要總結。完成本次任務摘要後，請等待用戶明確指示後再繼續執行其他任務。請勿自動開始執行下一個任務。\n\n如果用戶要求連續執行任務，請使用「execute_task」工具開始執行下一個任務。`,
}, },
], ],
}; };