AI 產品經理學習營 期末專案：完整產品提案與 Demo 準備

本篇記錄「AI 產品經理學習營」期末專案的作業要求，以及產品提案簡報與 Prototype Demo 的準備過程。

• 繳交期限：11/9(一) 23:59
• 內容：產品提案簡報(pptx)、可操作的 Prototype Demo
• 繳交方式：上傳至作業區雲端資料夾，並提供 Prototype 的 GitHub 連結
• 提案簡報重點在於說明產品機會、目標使用者、產品策略、MVP 取捨、驗證依據、開發可行性與預期商業價值，簡報樣式美觀與否不是評比重點。

要交付的東西

• 產品提案簡報(pptx)
• Prototype Demo

準備：產品提案簡報

把「第一階段 課後作業：EcoSpeak 產品提案」和「產品構想一 PRD v1.1」丟給AI根據內容轉成10-12頁的簡報檔即可。

請AI推薦轉簡報檔的AI工具，ChatGPT和Gemini皆推薦 Gamma.app，但要錢，直接用ChatGPT產就好。

準備：Prototype Demo

之前已經寫了第一版，但老師應該要看的是AI Agent、SDD與OpenSpec的協作開發，所以必須在原本的專案導入OpenSpec，做些規格變更、提交、AI自動化測試與Archieve等動作，以及加入SubAgent，CustomAgent，HOOK機制，MCP調用等。

初始化 OpenSpec

前往專案根目錄，輸入openspec init 初始化 OpenSpec 專案。

設定Context和Rule

將原始的產品提案product_proposal.md放在專案根目錄下的docs目錄。

在 OpenSpec 的設定檔 openspec/config.yaml加入既有的產品提案文件作為 context，並設定 rules。

openspec/config.yaml

schema: spec-driven

context: |
  Project: EcoSpeak

  Product proposal:
  - docs/product_proposal.md

  This is an existing, implemented application.

  When creating or updating specifications:
  - Read docs/product_proposal.md for product intent and MVP scope.
  - Inspect the existing source code for actual implemented behavior.
  - Treat source code as the source of truth for current behavior.
  - Do not invent unimplemented features.
  - Identify differences between the proposal and implementation.

rules:
  specs:
    - Describe existing behavior using requirements and scenarios.
    - Do not include unimplemented features in baseline specs.

回補 Baseline Spec

利用 AI 協助回寫 OpenSpec的 spec.md

進入Codex CLI，輸入以下提示詞。

Read docs/product_proposal.md and openspec/config.yaml.

Analyze the existing EcoSpeak implementation.

Generate baseline specifications under openspec/specs/
based on actual implemented behavior.

Compare the implementation with the original product proposal.

Do not modify application source code.
Do not create change proposals for already implemented features.

結果 Codex 在專案根目錄下產生以下檔案：

• openspec/specs/dialogue-generation/spec.md - 對話生成規格
• openspec/specs/dialogue-practice-page/spec.md - 頁面規格
• docs/implementation-comparison.md - 既有程式碼與產品提案差異比較

新增功能 proposal

使用下面提示詞詢問 Codex 目前程式和產品提案中還有哪些未實現的功能。

Read docs/implementation-comparison.md and
docs/product_proposal.md.

Identify unimplemented MVP features.

Recommend the smallest feature suitable for
the next OpenSpec change.

Do not modify any files.

Codex 回覆：

Recommend add-scenario-input as the next OpenSpec change. It is the smallest complete feature that closes a clear gap in the proposed MVP.

Based on the comparison (docs/implementation-comparison.md) and the proposal (docs/product_proposal.md), the remaining gaps are:

| MVP behavior | Current gap |
|---|---|
| Enter a scenario or need — FR-01, US-01 | No input field, request parameter, or blank-input validation. |
| Generate from that scenario — FR-03, US-02 | Generation uses a fixed prompt with an AI-selected topic. |
| Meet dialogue constraints — FR-05, US-02 | A/B speakers, length, and target-phrase inclusion are requested through the prompt but not checked afterward. |
| Avoid displaying incomplete results — US-04 | Rendering failures can leave partially updated content. |

Naturalness and grammatical quality also need evaluation, but the absence of automated quality checks does not itself mean those requirements are unimplemented. The planned user study has no documented results; manual collection is explicitly allowed.

The recommended change should cover one complete flow:

1. Enter a scenario, such as “Ordering coffee.”
2. Reject empty or whitespace-only input in both the page and backend.
3. Send the scenario to the backend and include it in the generation request.
4. Display the resulting dialogue through the existing interface.
5. Allow editing the scenario and generating again.

This completes US-01 and the missing input-dependent portion of FR-03. It requires no storage or new external service and has clear acceptance criteria. Target-phrase selection can remain AI-driven.

No files were modified.

在Codex CLI，使用 $openspec-propose 並帶入以下提示詞，

$openspec-propose Create a change named `add-scenario-input`
1. Enter a scenario, such as “Ordering coffee.”
2. Reject empty or whitespace-only input in both the page and backend.
3. Send the scenario to the backend and include it in the generation request.
4. Display the resulting dialogue through the existing interface.
5. Allow editing the scenario and generating again.

This completes US-01 and the missing input-dependent portion of FR-03. It requires no storage or new external service and has clear acceptance criteria.

Codex 回覆：

Created add-scenario-input under openspec/changes/add-scenario-input/:

- Proposal (openspec/changes/add-scenario-input/proposal.md): scope and rationale
- Design (openspec/changes/add-scenario-input/design.md): API, validation, and AI integration
- Two delta specs covering backend generation and the practice page
- Tasks (openspec/changes/add-scenario-input/tasks.md): implementation and verification checklist

Strict OpenSpec validation passed. Application code remains unchanged.

All artifacts needed for implementation are ready. Review them, then run $openspec-apply-change add-scenario-input or ask me to apply the change.

Codex 產生add-scenario-input功能的 OpenSpec 文件：

• openspec/changes/add-scenario-input/proposal.md - Proposal
• openspec/changes/add-scenario-input/design.md - Design
• openspec/changes/add-scenario-input/tasks.md - Tasks
• openspec/changes/add-scenario-input/specs/dialogue-generation/spec.md - Delta Specs
• openspec/changes/add-scenario-input/specs/dialogue-practice-page/spec.md - Delta Specs

審查 proposal

Codex CLI 輸入以下提示詞，讓 AI 審查剛產生的 Proposal 檔案，當然也可以人工審。

Review OpenSpec Change Artifacts for `add-scenario-input`

Codex 回覆：

No blocking findings in add-scenario-input.

The proposal, design, delta specs, and tasks consistently cover required scenario input, validation, normalized forwarding, AI request construction, and repeat generation. They also preserve the existing response and display behavior.

One minor improvement: the structured-output requirement (openspec/changes/add-scenario-input/specs/dialogue-generation/spec.md:24) says “existing … model” instead of explicitly naming gpt-5-mini and the Responses API. Keeping those details explicit would make the synchronized spec self-contained.

openspec.cmd validate add-scenario-input --strict passed. No files changed; implementation tests were outside this artifact review