需求工程 + Boundary
今天只回答一个问题：我们到底在设计什么，边界画在哪里？核心产物是一份 Boundary Pack（边界三件套）。
需求三分类
功能需求
系统“做什么”。
下单、撤单、查持仓、拉 K 线。
质量属性
系统“做得多好”。
下单多快、行情断了怎么办、半夜挂了谁知道。
约束
系统“必须在什么框里做”。
单人运维、30 美元/月、必须用 Alpaca API。
生活类比：点外卖
- 功能需求：“我要吃黄焖鸡”——吃什么。
- 质量属性：“30 分钟内送到、送到时还是热的”——做得多好。
- 约束：“预算 25 元、只能用手机下单”——框。
拆解一句话
“系统要在 1 分钟 K 线上跑 SPY 策略”——功能：拉 K 线、算信号、下单；质量：行情断了 5 分钟怎么办？下单超时了怎么办？约束：跑在 30 美元的服务器上，一个人运维，必须用 Alpaca API。
同一句话里藏着三类需求。新手只看到第一行，架构师三行都要看到。从今天起，每读到一条需求，先问：它是功能、质量，还是约束？
质量属性场景：三问版
判断一个质量目标是否合格，只问三个问题：发生什么？系统怎么响应？怎么判断响应合格？
Worked example：下单超时
发生什么：Alpaca Trading API 下单 5 秒无响应。
系统怎么响应：不能直接认定失败，进入 Unknown 状态，发起查询对账，不盲目重发。
怎么算合格：在预定查询窗口内完成确认；若无法确认，则保持 Unknown 状态并持续对账，且不产生重复下单。
Boundary（边界）
生活类比：餐厅
- 厨房管做菜，不管种菜。
- 和外部交接的三个口：进货口（供应商）、点餐口（顾客）、外卖口（骑手）。
- 每个口都要说清“交什么、什么标准”：菜几点送、坏了包不包退换；外卖超时谁负责。
Worked Example（讲透）：奶茶店的边界
管什么：做奶茶、收钱。
不管什么：不种茶叶（找供应商）、不自己送外卖（用外卖平台）。
外部依赖：茶叶供应商、糖浆供应商、外卖平台、支付通道。
交接契约：茶叶“每周二送达，坏包退换”；外卖“接单后 40 分钟送达，超时平台赔付”。
讲透三层
第一层：边界不是“墙”
边界是“交接清单”——在每个交接点说清谁负责什么、交什么、什么标准。
第二层：边界定义责任与风险暴露
边界决定责任主要归属在哪里，也定义哪些风险由外部承担、哪些仍需系统检测和缓解。记住：Boundary ≠ 风险消失。
第三层：边界带来可预期性红利
厨房可以按“供应商应在周二送货”安排流程，但仍要考虑延迟交付怎么办。Contract creates expectations, not certainty——契约创造的是可预期性，不是确定性。
Boundary Pack：边界三件套
为统一小样场景画边界，要交出三样东西：
- 管什么 / 不管什么清单：各至少 4 条，“不管”每条加一句“为什么不管”。
例（管）：拉行情、算信号、风控检查、下单撤单、订单状态跟踪、对账与告警。
例（不管）：不自己撮合（交易所/券商撮合）、不管资金托管（钱在券商账上）、不做高频做市、不管税务申报。 - 外部依赖清单：每个写一句“它坏了会怎样”。
例：Alpaca Trading 坏了 → 下不了单，需触发交易安全开关；告警通道坏了 → 出事没人知道。 - 一句话 Boundary Contract：每个交接点一句话写清谁负责 / 交什么 / 失败怎么办。
例：券商负责返回订单执行结果；超时无响应时系统进入 Unknown 并发起查询对账，不盲目重发。
与后续的衔接
Day 3 Contract = 一句话 contract 的展开 + 超时语义；Day 4 Structure 的划分必须落在 Day 2 的边界内——边界是 Structure 的外框，Day 4 不许画出界；Day 6 把三问版升级为完整六要素；Day 7 检查点复用这份 Boundary Pack。