# Intent Alignment

> 在動手實作之前，先與使用者對焦提案的意圖、代價與替代方案。當使用者提出的內容包含尚未實作的構想、新功能、新模組、架構調整或設計方案，且這輪對話預期最終會導向實作時，務必先使用這個 skill 進行討論，不要直接開始寫程式。純粹的錯誤修正、bug 診斷、現況評估、事實確認與說明性問題不適用。

- Skill: `organic-san/intent-alignment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add organic-san/intent-alignment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/organic-san/intent-alignment/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: organic-san (https://skillmd.com/u/organic-san)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/organic-san/intent-alignment

---


# 實作前的意圖對焦

## 什麼時候用

兩個條件同時成立才適用：

1. 使用者提出的是**尚未實作的構想** — 新功能、新模組、資料結構調整、流程改變、架構決策、要引入的工具或依賴。
2. 這輪對話**預期會導向實作** — 使用者的意圖是把它做出來，不只是想聽你的看法。

不適用的情況，照常回答就好：

- 修 bug、改錯字、調參數、補測試等既有內容的修正
- 「為什麼會壞」「這段在做什麼」等診斷與解釋
- 「這個方案你覺得如何」等純評估 — 使用者已經在要你的意見，不需要再包一層流程
- 「這樣對嗎」等事實確認

判斷不出來時，用一句話問使用者：「這是要直接做，還是先討論？」比起強行套流程或貿然開工，都好。

## 討論之前先做功課

沒有根據的討論比不討論更糟。如果你還沒看過相關程式碼就問「這會帶來什麼代價」，你只是把問題原封不動丟回去，浪費使用者的時間。

進入討論前先花少量成本確認現況：

- 提案會碰到的檔案實際長什麼樣
- 這個功能是不是已經存在，或已經做了一半
- 誰呼叫這些程式碼、誰依賴這個行為
- 專案裡有沒有既有慣例可以沿用

如果調查後發現**使用者對現況的認知有落差**（他以為不存在的東西其實已經有了、他以為單純的地方其實有隱藏依賴），這是最優先要講的事，放在回應最前面。很多提案在這一步就會直接改變形狀。

## 回應格式

調查完之後輸出這五段，寫完就停，不要接著產出實作。

```
## 我理解的問題
用你自己的話重述使用者真正想解決的問題，而不是他提出的解法。

## 這個提案能否命中
提案是否真的解決那個問題。會、不會、或只解決一部分 —— 講清楚是哪一部分。

## 代價
具體到檔案與機制：哪些地方要跟著改、誰會受影響、之後要長期維護什麼、
放棄了哪些彈性。「會增加複雜度」這種通則等於沒說。

## 其他做法
至少一個。適用時把「先不做」也列進去。每個做法要附上它跟原提案的取捨差在哪。

## 需要你拍板的
最多三個。能用一兩句話回答的具體問題，不要開放式的「你覺得呢」。
```

## 幾件事要注意

**不要為了顯得有在思考而硬找反對意見。** 如果提案本身就是對的，就說它是對的、理由是什麼，然後問可不可以開始。假性質疑會讓這套流程變成儀式，使用者很快就會叫你跳過。

**使用者已經講過的不要再講一遍。** 如果他的訊息裡已經把代價和替代方案都想清楚了，只補上他沒想到的缺口，不要把整份模板重填一次。

**代價要往兩邊看。** 不做這個提案的代價，跟做了的代價，一樣要講。

**這個階段不要寫實作。** 可以引用既有程式碼來說明，可以寫三五行示意介面的樣子，但不要開始產出要進 codebase 的東西。

## 什麼時候可以往下走

使用者明確表示要開始（「就這樣做」「開始吧」「照第二個方案」）之後才進實作。如果他只回答了部分問題但方向已經清楚，就照清楚的部分做，把還沒定的地方在實作時標出來問。

如果使用者一開始就說「不用討論直接做」，尊重他，直接做。但實作過程中若撞到當初沒談到、而且會影響結果的岔路，停下來問一句再繼續。