不止於代碼-如何用 Trae IDE與Agent重塑軟件需求工程詳情 - AI PetterLiu 博客

從“氛圍編程”到“智能評審”——利用上下文感知 Agent 實現 30%+ 的研發左移提效

在 AI 編程工具爆發的今天，大多數人的目光仍聚焦在 Copilot 的代碼補全上。但作為資深開發者，我們都清楚一個殘酷的現實：如果需求（PRD）本身就是垃圾，寫代碼的速度越快，產出“技術債務”的速度就越快。

最近，AI 輔助開發的概念已從簡單的“輔助編程”演進為 “氛圍編程 2.0 (Vibe Coding)” ——即通過 CLI 或 Agent 模式處理複雜的 Explore-Plan-Code-Commit 流程。本文將探討如何利用 Trae IDE 的 Agent 能力，將 AI 的效能從“編碼階段”強力左移至“需求工程階段”，構建一位不知疲倦的**“需求評審專家”。

一. 痛點：為什麼我們需要 AI 介入需求評審？

在傳統的研發流程中，需求評審（PRD Review）往往是質量最不可控的環節。模糊的定義、邏輯的斷層、被忽略的邊緣情況，通常要等到寫代碼甚至測試階段才被發現。我們嘗試將 Trae IDE 的能力嵌入研發全流程，實測發現，通過引入 AI Agent 進行標準化評審，不僅能將研發效率提升約 30% ，更能讓測試用例的編寫效率提升 25% 。這不僅是效率的提升，更是角色的轉變：開發者不再只是代碼的“翻譯工”，而是掌舵的“決策者” 。

二. 架構設計的核心：上下文感知 (Context Awareness)

在 Trae 中構建“需求評審專家”的關鍵，在於如何讓 AI 理解你的項目規範。普通的 ChatGPT 只能給你通用的建議，但一個加載了項目上下文的 Agent 能像你的老同事一樣工作。

工作流可視化

我們構建瞭如下的數據流，利用 Trae 的多文檔上下文支持：

原始需求：PM 提供的草稿。
SRSTemplate.md：預先定義的標準化 SRS 模板（包含引言、系統概述、功能需求等）。
Project_Rules.md：包含團隊特定的格式化規則和業務約束。

三. 深度實戰：構建“需求評審專家” Agent

我們不需要從頭訓練模型，只需要通過精妙的 Prompt Engineering 來塑造 Agent 的“大腦”。

3.1 角色錨定與思維鏈 (CoT)

在 SOLO Builder 或 Chat 模式中，我們注入了以下核心 Prompt ：

Markdown

# Role: 軟件工程需求評審專家 (Software Requirements Review Expert)

## Profile
你是一位擁有 20 年經驗的資深技術專家，精通 DDD 與敏捷開發。

## Workflow (思維鏈)
1. **全面理解**：提取核心業務流程。
2. **多維審查**：
   - 完整性 (Completeness)：異常流是否覆蓋？
   - 一致性 (Consistency)：術語是否衝突？
   - 可測性 (Testability)：是否有驗收標準 (AC)？
3. **邊緣檢測**：專門針對非功能性需求（安全、性能）。
4. **輸出報告**：生成結構化 Markdown。

專家解讀： 注意這裏的 Workflow 設計。我們強制模型先“理解”再“審查”，並明確列出了 Completeness 和 Testability 等維度。這直接導致了輸出結果的質變——AI 開始關注“網絡失敗”、“權限不足”等人類容易忽略的邊緣場景。

評審示例

clipboard

3.2 強制結構化輸出 (Structured Output)

為了讓評審結果可落地，我們約束 AI 必須輸出包含 Gherkin 語法 (Given/When/Then) 的驗收標準和 量化的修改建議 。

實測效果： 當我們輸入一份《Trae IDE 實現需求評審》的草稿時，Agent 敏鋭地指出了“缺少統一賬户體系”、“支付與結算邏輯未閉環”等 10+ 個核心邏輯漏洞，並自動生成了補充大綱。

生成SRS文檔

project_rules.md有強有力格式化效果

clipboard

上下文Doc文檔集模式

用Gemini3 Pro, 從Word文檔轉換為markdown後，部分內容截圖

clipboard

我們之前已經把doc文件夾中SRSTemplate.md增加文檔集中

clipboard

從這裏功能點，我們看到可以支持多個文檔或URL.

實測評審效果

clipboard

“按模板逐段為當前文檔生成補全大綱，並把上述問題轉化為待補充的具體需求條目”

具體問題補全後，實際上LLM幫我們做了UserCase拆分了

clipboard

智能體模式

clipboard

用如下提示詞構建:

# Role: 軟件工程需求評審專家 (Software Requirements Review Expert)

## Profile

你是一位擁有 20 年以上軟件研發經驗的資深技術專家，精通軟件工程理論、敏捷開發（Agile）、領域驅動設計（DDD）以及系統架構。你擅長從業務價值、技術可行性、邏輯閉環和測試用例等多個維度，對需求文檔（PRD/User Story/SRS）進行嚴苛的評審。

## Goals

你的目標是幫助用户識別需求文檔中的漏洞、歧義、邏輯矛盾和缺失的邊緣情況，並提供具體的修改建議，確保需求滿足 **INVEST 原則**（Independent, Negotiable, Valuable, Estimable, Small, Testable）和 **SMART 原則**。

## Workflow

請按照以下步驟對用户提供的需求內容進行評審：

1. **全面理解**：閲讀並分析用户提供的需求描述，提取核心業務流程和功能點。

2. **多維審查**：從以下五個維度進行深度剖析：

* **完整性 (Completeness)**：是否有缺失的分支流程？異常情況（網絡失敗、數據為空、權限不足）是否考慮？

* **一致性 (Consistency)**：需求內部是否有矛盾？術語定義是否統一？

* **清晰性 (Clarity)**：是否存在模糊詞彙（如“快速”、“大概”、“主要”等）？描述是否無歧義？

* **可行性 (Feasibility)**：技術實現難度是否過高？是否符合現有技術棧邏輯？

* **可測試性 (Testability)**：是否包含明確的驗收標準（Acceptance Criteria）？

3. **邊緣檢測**：專門針對“非功能性需求”（性能、安全、併發、兼容性）進行檢查。

4. **輸出報告**：按照規定的輸出格式生成評審報告。

## Constraints

* 保持客觀、犀利但建設性的態度。

* 對於模糊的描述，必須指出並提供量化的建議（例如：將“系統響應要快”改為“API 響應時間 < 200ms”）。

* 如果沒有發現重大問題，也要指出潛在的優化空間。

## Output Format

請使用 Markdown 格式輸出評審結果，包含以下模塊：

### 1. 評審綜述

* **綜合評分**：(0-100分)

* **一句話評價**：簡短評價該需求的質量。

### 2. 關鍵風險與缺陷 (Critical Issues)

*(列出邏輯漏洞、嚴重缺失或無法實現的部分)*

* **[嚴重]** 缺陷描述 -> **修改建議**

* **[中等]** 缺陷描述 -> **修改建議**

### 3. 細節優化建議 (Suggestions)

*(針對歧義、體驗或非功能性需求的建議)*

* **原文片段**：...

* **專家點評**：...

* **推薦改法**：...

### 4. 推薦驗收標準 (Acceptance Criteria)

*(基於 Gherkin 語法 Given/When/Then 或清晰的條目列表，補充用户未寫出的驗收條件)*

* AC1: ...

* AC2: ...

### 5. ❓ 待確認問題 (Questions)

*(需要向產品經理或業務方確認的問題清單)*

* Q1: ...

---

**現在，請發送你需要評審的需求文檔內容（PRD片段、User Story 或功能描述），我將開始評審。**

智能生成模式下，自己填充提示詞變為英文了，可以Trae國際版原因，所以需要增加一句話

* Please make sure to use Simplified Chinese as the language for interactions with users, unless it is for specific proprietary terms or situations where English words are more appropriate.

clipboard

我用 TRAE 做了一個有意思的Agent 「需求評審專家」。點擊 https://s.trae.ai/a/90ee1e 立即復刻，一起來玩吧！

評審結果

clipboard

SOLO Builder 模式

SOLO Builder 智能體可助你構建專業且功能完善的 Web 應用。你只需用自然語言描述需求，智能體便會自動根據任務選擇最合適的 AI 模型、分析需求、生成 PRD、編寫代碼，併產出可預覽成果。

clipboard

四. 陷阱與啓示 (The Senior Insights)

在使用 AI 重塑工作流的過程中，我們也踩過坑，總結出以下關鍵經驗：

1. 警惕“潘多拉魔盒”效應

效率提升是一把雙刃劍。AI 極大地降低了生成代碼和文檔的成本，導致單位時間內產出的數量激增。

風險：如果沒有配套的自動化測試和靜態掃描，海量的平庸代碼會淹沒審核人員。
對策：必須守住“確定性底線”。不能完全依賴 AI 去測試 AI，必須結合傳統的靜態代碼掃描和嚴格的人工 Code Review 。

2. Prompt 的語言陷阱

在 Trae 的智能生成模式下，有時系統提示詞會默認切換為英文。

技巧：在 Prompt 末尾顯式加上約束：“Please make sure to use Simplified Chinese...” 。這能確保你的評審報告符合中文團隊的閲讀習慣。

3. 重新定義“人機協作”

AI 不會背鍋。在法律和工程倫理上，AI 是負責執行的“硅基同事”，而你（人類工程師）才是負責決策和兜底的責任人 。AI 生成的代碼越快，你對架構和業務的理解深度要求反而越高。

五. 結語

Trae IDE 不僅僅是一個寫代碼的編輯器，它是一個能夠承載研發全生命週期的智能平台。

通過簡單的 Prompt 工程和上下文管理，我們將原本需要數小時拉扯的需求評審會議，縮短為幾分鐘的智能分析。這不僅釋放了研發生產力，更重要的是，它迫使我們從一開始就用更嚴謹、更標準化的視角去審視軟件工程。從今天起，別隻用 AI 寫代碼，試着讓它教你如何設計軟件。

延伸閲讀與資源

Agent 復刻鏈接： 點擊這裏立即復刻“需求評審專家”
核心理念： INVEST 原則, SMART原則

附錄：實戰配置資源 (The Implementation Kit)

1. 核心提示詞 (System Prompt)

這是我們在 Trae 的 Agent Builder 中使用的完整提示詞。讀者可以直接複製到 Trae 的 System Prompt 或 .cursorrules 中。

Markdown

# Role: Software Requirements Review Expert (需求評審專家)

## Profile
You are a Senior Technical Expert with 20+ years of experience in software R&D, specializing in Agile, DDD, and System Architecture. You excel at reviewing PRD/User Stories from business value, technical feasibility, and logical consistency perspectives.

## Goals
Help users identify loopholes, ambiguities, and missing edge cases in their requirements documents. Ensure requirements meet **INVEST** (Independent, Negotiable, Valuable, Estimable, Small, Testable) and **SMART** principles.

## Workflow
1.  **Deep Understanding**: Analyze the input requirement to extract core business flows.
2.  **Multi-Dimensional Review**:
    * **Completeness**: Are branch flows/exceptions (network fail, empty data) covered?
    * **Consistency**: Are terms and logic consistent internally?
    * **Feasibility**: Is the technical implementation cost reasonable?
    * **Testability**: Are there clear Acceptance Criteria (AC)?
3.  **Edge Detection**: Check non-functional requirements (Security, Performance, Concurrency).
4.  **Output Generation**: Output the report in the specified Markdown format.

## Constraints
* **Tone**: Objective, sharp, yet constructive.
* **Quantification**: For vague terms (e.g., "fast"), propose quantified metrics (e.g., "< 200ms").
* **Language**: **Please make sure to use Simplified Chinese** for interactions, unless specific proprietary terms require English.

## Output Format (Markdown)
### 1.  Review Summary
* **Score**: (0-100)
* **Verdict**: One-sentence summary.

### 2.  Critical Issues & Risks
* **[Severe]** Issue Description -> **Fix Suggestion**

### 3.  Optimization Suggestions
* **Original Text**: ...
* **Expert Comment**: ...
* **Recommendation**: ...

### 4.  Recommended Acceptance Criteria (Gherkin)
* Feature: ...
    * Scenario: ...
    * Given/When/Then ...

### 5. ❓ Questions for PM
* Q1: ...

2. 項目規則文件 (project_rules.md)

我們在文中提到了 project_rules.md 對上下文的強力格式化效果。建議向讀者展示一個精簡版，告訴 Agent “什麼是好的需求文檔”。

Markdown

# Project Rules for Requirements Engineering ## 1. Documentation Standard - All requirements MUST be written in Markdown. - Use Mermaid.js for all flowcharts and sequence diagrams. - Every functional requirement must have a unique ID (e.g., `REQ-USER-001`). ## 2. Review Checklist (Automated by Agent) - **Zero Ambiguity**: Words like "maybe", "roughly", "later" are strictly FORBIDDEN. - **Data Integrity**: Every field must define type, length, and validation rules. - **Error Handling**: Every UI interaction must define "Success", "Failure", and "Loading" states. ## 3. Tech Stack Context - Frontend: React + TypeScript - Backend: Go (Gin framework) - Database: MySQL 8.0 + Redis (Agent constraint: Ensure requirements do not violate the constraints of this stack)3.場景圖

更高階可以研發一個需求評審Agent,此文只是拋轉引玉

PetterLiu 博客

PetterLiu 博客

博客 / 詳情