平台与业务场景 · 知识点
低代码平台、AI 编程和 ChatBI 都是「把模型嵌进工作流」。真正要选的是：数据出不出域、规则能不能写成代码、数谁来算。
切片、混合检索、权限看 RAG 知识点；Prompt / 窗口看 上下文工程；循环和工具看 Agent 知识点。本页只讲平台与业务怎么拆。
0. 总图
常见四条路，不要混成一个词：
text
要交付的是什么？
│
├─ 对话 Bot / 内容工作流 → 低代码平台（Coze / Dify）
├─ 工具循环、要自己控权限 → 自建 Agent（框架见 04）
├─ 人写代码、AI 加速 → 编程工具（Cursor / CLI / 插件）
└─ 业务人员问数 → Text-to-SQL / ChatBI| 路 | 适合 | 先问什么 |
|---|---|---|
| Coze 一类 SaaS | 快速 demo、内容、要接国内社交渠道 | 数据能不能上云 |
| Dify 一类可私有化 | 内网、要自己接模型、要改工作流版本 | 数据出不出域 |
| 自建 Agent | 权限、评测、工具策略必须自己执行 | 决策树能不能写死 |
| AI 编程 | 改仓库、补测试、出 Spec | 有没有验收 |
| ChatBI | 不懂 SQL 的人问业务 | 指标口径谁定义、数谁算 |
口条：先问数据出不出域，再问要不要自己接模型，最后才比 UI。
重点 1. 平台选型：Coze vs Dify
Coze（国内扣子）是低代码 Agent 平台。核心别把三个词混成一个：
- Bot：给人用的产品（人设、模型、插件、知识库、工作流）。
- 工作流：可视化编排（LLM / 代码 / 检索 / 条件 / 循环）。
- 插件：官方或自定义 HTTP，是工具，不是 Bot。
Dify 是开源 LLM 应用平台，API 优先，可 Docker Compose 私有化。
| 维度 | Coze | Dify |
|---|---|---|
| 开源 | 闭源 SaaS | 开源，可私有化 |
| 数据 | 上云 | 数据自有 |
| 模型 | 偏国内云端模型 | 可接 OpenAI / Ollama / vLLM 等 |
| 适合 | 快速 demo、内容 | 合规、内网、要改工作流版本 |
数据敏感 / 要私有化 → Dify；个人小工具快速上线 → Coze。不要说「我们用了 Dify」就当工程能力；要能讲清工作流怎么拆、向量库怎么换、回滚怎么做。
Dify 里 Workflow 一次跑完、无会话，适合批处理和定时；Chatflow 有多轮历史，适合客服和问答。同一套节点能力，差在有没有会话状态。
能规则化的别上 Agent。Batch Agent（简历打分、发票审核）是非结构化 + 模糊规则；传统 ETL 是 SQL / 脚本写死。上了 Agent 就要有超时、重试和单条 token 预算。
重点 2. 工作流怎么拆节点
不要让一个 LLM 一步出完整结果。拆开才能换模型、加硬规则、单独调试。
典型内容工作流（例如「商品卖点 → 几条风格文案」）：
- 搜同类样本 / 知识库捞模板
- LLM 出多种风格（创意）
- 代码节点做硬规则（字数、CTA、违禁词）
- 再一个便宜模型或规则打分排序
硬约束放代码节点，LLM 只做不确定的部分。一步到位容易漏 CTA、超字数、无法单点复现。
选型：
- 决策树能画清 → 工作流，不要自主循环。
- 下一步必须由模型看观察再选 → Agent，见 03。
- 规则清晰、结构化数据 → 脚本 / ETL，不要包一层 Bot。
重点 3. Text-to-SQL 与 ChatBI
Text-to-SQL：自然语言 → 可执行 SQL。
LLM 之前：Schema 理解差、复杂 JOIN 不稳、换库就挂、没有执行报错回流。现在语义更好，Schema 和示例可以进 prompt，报错可以重写。仍然要防的坑：
| 坑 | 做法 |
|---|---|
| 表太多塞不下 | Schema Linking：只召回相关表 |
| 业务词 ≠ 字段名 | 指标词典，不要让模型猜口径 |
| 「最近一周」有歧义 | 先澄清时间窗 |
| 多表嵌套易错 | few-shot + CTE + 执行重试 |
| 跑通 ≠ 语义对 | 合理性检查 / 抽检；JOIN 错会重复计数 |
现成 create_sql_agent 不够生产：中文口径弱、整库 schema 塞窗口、没有指标语义层、可能生成写操作。生产至少：只 SELECT、参数化、白名单、动态 few-shot（历史「问题 + SQL」本身也是一层 RAG）。
ChatBI：用不懂 SQL 的人问业务，返回数据 + 图 + 解读。和传统 BI 的差别是对话、更即时；看板团队转向指标治理。
高频约束：数用 SQL / Polars 算完，LLM 只负责解释。不要让模型自己算涨幅或收益率。展示数据要带时间戳；「茅台」可能是股票也可能是基金，要澄清。
4. 了解：AI 编程提效
细节题留在技术问答。这里只记选型：
- 工具按「编辑器一体 / CLI 自治 / 插件补全」三类讲，不要背型号。
- 不确定就 Ask / Plan，确认了再 Agent，避免一上来改崩。
- Rules 是项目共识，进 Git；写短，靠
globs，alwaysApply只留 1–2 条。个人口味进 Memory。 - SDD：先写 Spec 再让模型实现。没有 Spec 的 AI 编程 = 没有验收的外包。
- TDD：红绿重构。AI 可以写测试和实现，人要看测试是否测对了行为。
- 重构遗留：先理解 → 锁定当前输入输出 → 再渐进替换。不要一次推倒重写。
- CI 里 AI 是助手（审查、定位、Release Notes），不是自动合码的闸门。
5. 建议复习顺序
- 数据出不出域 → Coze / Dify
- 工作流拆节点：创意 vs 硬规则
- Workflow vs Chatflow、什么时候不上 Agent
- Text-to-SQL 坑：Schema Linking、词典、只读、跑通≠对
- ChatBI：数用引擎算，模型只解释
- 编程提效：Rules、SDD、TDD（问答里练口述）