---
title: "plan 和 sdd 的場景"
date: "2026-03"
category: "ai運用"
tags: ["ai運用"]
description: "plan 和 sdd 適合的場景是： 你知道該做什麼 或者你相信 AI 會做什麼 用akr的話來說的話，就是這種提前決定好情況和流程的ai使用，最適合情況已知而且非常成熟的情況下來做..."
source: "https://enriquemark.com/zh-hant/posts/plan%20%E5%92%8C%20sdd%20%E7%9A%84%E5%9C%BA%E6%99%AF"
---

plan 和 sdd 適合的場景是：

1. 你知道該做什麼
2. 或者你相信 AI 會做什麼

用akr的話來說的話，就是這種提前決定好情況和流程的ai使用，最適合情況已知而且非常成熟的情況下來做。但如果遇到的問題未知，或者是專案中期，各種問題出現的時候，我不知道，ai也沒辦法搞好。更不用說專案變大後，流程可能就不可預期了。
雖然我想過用agent團隊的形式去實現，但這仍然會面臨一個上下文汙染、中斷的問題，因此找個ai當專案經理盯著恐怕不是好辦法。因此，從這個角度來看，定義明確的測試導向型開發就是比較好的解決方案——當然，是目前的暫定方案。
這裡的核心關鍵點是定義清晰的邊界和形式化的驗證——測試程式本質上就是一個形式化的系統，因此他的輸入和輸出都是絕對明確的，因此邊界就在這裡被定義下來了。
akr的說法確實沒錯，反饋迴圈很重要，重點是這樣的反饋從哪裡來？測試當然就是一個。
但測試導向並非完美的，ai有可能會出線先射箭再畫靶子的問題。他會繞著程式去寫測試，最終導致測試結果就是量身定做的——這顯然不是我們想要的良好測試樣例。
恐怕如何寫測試需要人類來指定一個原則，我倒是想到A家的憲法ai了，人類多少還是要給個邊界限制——卻並非完全的僵死的限制。他就像法官解釋法律一樣，ai可以按照自己的理解來靈活的解釋，但邊界範圍卻是明確的。

sdd：規範驅動開發（Specification-Driven Development, SDD）