技术边界定义：范围界定、假设条件、约束条件
技术可行性边界的定义是AI产品架构选型的起点。在启动任何技术选型前，必须明确“做什么、不做什么、在什么前提下做、受什么限制”。缺少清晰边界，将导致选型目标发散、论证失效、决策反复。本章从范围、假设、约束三个核心维度，给出可操作的边界定义方法。
1.1 为什么需要技术边界
技术边界不是限制，而是决策锚点。它帮助团队在不确定性中锁定可验证的可行性范围，避免无休止的技术论证。在AI项目中，边界尤重要——模型能力、数据可用性、算力成本、业务容忍度等因素相互耦合，没有边界就无法量化“可行”或“不可行”。
直觉提示：边界定义越模糊，后期选型翻车的概率越高。一个典型反例是“我们要做一个智能客服”，未明确离线/在线、单轮/多轮、开放域/限定域，导致技术方案来回切换。
1.2 三个核心维度
| 维度 | 定义 | 常见输出物 | 典型错误 |
|---|---|---|---|
| 范围界定 | 项目要解决的核心问题、交付物、不包含的边界 | 功能列表、排除清单、里程碑范围 | 遗漏关键非功能需求（如延迟、并发） |
| 假设条件 | 为简化分析而预先承认的技术/环境/资源事实 | 假设清单、依赖项、前置条件 | 假设过于乐观（如“数据都可用且干净”） |
| 约束条件 | 不可协商的硬性限制（时间、预算、合规、技术栈） | 约束矩阵、强制要求、红线列表 | 忽略合规约束导致方案被否决 |
1.3 边界定义过程
- 收集输入：业务目标、用户故事、利益相关者期望、已有系统分析。
- 识别边界要素：通过头脑风暴或检查清单，列出可能需要界定的事项。
- 分类并文档化：将每个要素归入范围、假设或约束，并给出明确描述。
- 验证与批准：与关键干系人（业务方、数据owner、安全合规）确认边界是否合理。
- 版本化与维护：边界定义应随项目深入调整，每次变更记录版本。
1.4 常见风险与权衡
- 范围蠕变：未严格控制“不做什么”，导致选型方案被不断追加需求压垮。
- 假设失效：所有假设都是风险点，必须在选型前做压力测试。
- 约束误判：将软性限制（如“希望用最新模型”）误判为硬约束，压缩方案空间。
- 决策悖论：过度精确的边界反而阻碍创新，需留一定弹性。
红线警示：任何边界定义都不能替代实际验证。假设和约束必须作为可行性评估的输入条件，在后续章节中逐一验证。
1.5 验收标准
本章定义的边界是否合格？可对照以下标准自检：
- 范围界定覆盖了“做”与“不做”的所有关键维度（功能、性能、部署方式、接口协议）。
- 假设条件被显式列出，每条假设都有明确的可验证方式（如“假设第三方API可用，需在T+2周内完成可用性测试”）。
- 约束条件被量化（如“延迟<200ms，预算<¥50万”）且来源可追溯。
- 边界文档经过至少一次跨角色评审（产品、架构、开发、QA）。
- 存在边界变更流程和版本控制机制。
以上框架可作为团队头脑风暴和文档模板的起点。在实际项目中，建议将范围、假设、约束分别整理成独立表格，并在选型报告中显式引用。