diff --git a/docs/技术方案建议书.md b/docs/技术方案建议书.md
index 4944866..0f4772e 100644
--- a/docs/技术方案建议书.md
+++ b/docs/技术方案建议书.md
@@ -152,6 +152,35 @@ Dify（意图分类 → 追问槽位 → 调 Ragflow → 方案生成 → 转人
 - 只求本单快验收、单租户可留 Logo → Dify 仍可行，但把判定树/评测集/原始知识**外置**，当保险。  
 - 不要假设「二开完还能廉价换家」——能换的是资产，不是画布。
 
+#### 若不纯赶工期，怎么选？
+
+时间让位之后，排序应变成：**许可干净 > 检索/幻觉可过验收 > 对话编排体验 > 上线速度**。
+
+**推荐默认改成：Ragflow 为主底座 + 自研薄「方案引擎」（判定树 / 追问槽位 / 转人工策略）。**
+
+| 理由 | 说明 |
+|------|------|
+| 许可 | 纯 Apache，乙方后续多客户复用、招标合规更省心 |
+| 验收 | 鲜境是资料驱动的「卖方案」，命中率/幻觉更吃检索，Ragflow 更对症 |
+| 锁定 | 首期就站在以后更可能留下的底座上，避免 Dify→Ragflow 重配画布 |
+| 编排缺口 | 用自研 API/状态机补「意图→追问→出方案」，业务逻辑落在你们代码与配置里，不绑死厂商画布 |
+
+**这时还要不要 Dify？**
+
+- **一般不必再引入 Dify**（双栈运维、两套权限/日志，长期总拥有成本更高）。  
+- 仅当方案引擎自研人力明显不足、又强依赖可视化编排时，可短期用 Dify 只做编排、检索仍走 Ragflow——但要接受多一套依赖。  
+- Flowise 同理：许可尚可，却更容易把逻辑锁在画布上；时间充裕时不如 **Ragflow + 自研编排** 干净。
+
+**时间充裕时的分期（示意，非合同附件二）：**
+
+1. 外置资产：资料仓、产品结构表、判定树、Eval 集  
+2. Ragflow 灌库 + 召回/幻觉打穿附件三阈值  
+3. 自研对话状态（槽位追问、低置信转人工、方案模板）  
+4. 单渠道接入 + 场景二 ASR  
+5. 再考虑是否要可视化编排器（多数情况不再需要）
+
+**一句话：不赶时间 → 选 Ragflow 路线更安全、更好；Dify 的优势主要是快，不是长期更优。**
+
 ---
 ### 为何首选 Dify（而不是 Flowise）