什么是技术刺探
技术刺探（Spike）是对不确定性高的技术点做限时探索：目标单一、时间盒固定、产出是可丢弃的原型与明确结论。它回答的问题是「能不能做」，而不是「在生产条件下是否达标」——后者属于 PoC。刺探的价值是用几天时间换取决策依据，避免把不确定性直接带进正式排期。
基本信息
| 适用条件 | 关键依赖未知、方案存在分歧、性能假设未验证 |
|---|---|
| 形态 | 时间盒（如 2 到 3 天）加明确的问题清单 |
| 产出 | 结论、证据与建议，代码原则上丢弃 |
| 与 PoC 区别 | 刺探回答可行性，PoC 回答生产条件下是否达标 |
常见刺探类型
| 类型 | 目标 | 示例 |
|---|---|---|
| 技术刺探 | 验证技术可行性 | 第三方 SDK 的延迟能否满足目标 |
| 架构刺探 | 验证结构与集成路径 | 消息模型端到端能否走通 |
| 业务刺探 | 验证规则与流程 | 计费规则原型走查是否可实现 |
典型使用场景
- 关键依赖评估：接入第三方能力前先验证调用方式、配额与延迟
- 方案分歧：两种技术路线争执不下时，用刺探拿出对照数据
- 性能假设：验证「缓存能降低多少延迟」这类未证实的前提
- 数据可行性：确认目标数据源能否取出所需字段与粒度
- 集成验证：确认两个系统的认证与数据格式能否对接
- 排期前置：在正式立项前清掉最大的不确定性，避免后期返工
刺探的输入与输出模板
刺探的输入与输出模板
# 输入（开动前写下）
要回答的问题：例如「该组件在 2000 QPS 下的 P99 是否能控制在 100ms 内」
判定标准：P99 ≤ 100ms 即为可行，否则记录实际数值与瓶颈
时间盒：2 天，到期即停
# 输出（结束后一页交付）
结论：可行 / 不可行 / 需要更多信息
证据：压测数据、日志片段、关键代码路径说明
建议：推荐路径与置信度、遗留风险
代码处置：丢弃 / 转重构排期（注明原因）刺探要有时间盒与问题清单：没有边界时「探索」会无限延伸，占用正式排期却不产出决策依据。
原型代码直接上线是常见陷阱：刺探代码通常忽略错误处理、并发与安全，按生产标准重写或重构是必要步骤。