创业阶段的技术决策：先管理不可逆性

创业团队每天都在做不完整信息下的决定。模型、数据库、桌面端方案和部署方式都有多个选项，时间却不允许逐一验证。

最有效的分类不是“重要或不重要”，而是“可逆或不可逆”。

可逆决定快速行动

局部组件、日志库和内部工具通常可以替换。只要边界清楚，选择一个团队熟悉、能尽快交付的方案更合理。为这些决定写长篇评审，会让组织把时间花在低风险差异上。

不可逆或高迁移成本的决定需要更多关注：核心数据模型、公开 API、用户数据归属、任务状态语义和安全边界。一旦积累真实数据或外部依赖，修改成本会快速上升。

我会先给决定做一个粗粒度分类，不追求数学精确：

这张表阻止团队在低风险选择上争论一周，也提醒我不能用“两周 MVP”跳过数据删除和备份。速度的来源是把注意力投到正确位置，不是所有事情都少做。

保留证据和退出条件

决策记录不必很长，但要说明目标、约束、主要候选、选择理由和重新评估条件。例如当调用量达到某个范围，是否需要更换模型路由；当工作流复杂到何种程度，现有状态模型不再适用。

我实际使用的记录模板只有这些字段：

Decision: 任务状态持久化到关系数据库
Context: 任务跨多个模型与工具调用，进程重启后必须恢复
Constraints: 两周内上线；团队熟悉 PostgreSQL；当前规模不需事件平台
Alternatives: 进程内状态 / Redis / PostgreSQL
Choice: PostgreSQL 为事实源，队列只负责调度
Consequences: 状态转换需要事务；吞吐不是首要目标
Revisit when: 单任务事件量或并发达到现有写入瓶颈
Owner: workflow

Consequences 和 Revisit when 比“选择理由”更重要。它们承认决定有代价，也给未来改变留下正当入口。

创业速度不等于忽略质量。身份、数据安全、备份和核心流程恢复属于底线，不能以“以后再做”掩盖。其余质量则根据验证阶段分配。

团队理解也是迁移成本

某个方案即使技术上优秀，如果只有一人能维护，也会形成组织风险。选择需要考虑团队已有能力、学习时间和文档质量。关键系统至少应有第二个人能解释运行和恢复方式。

我会让第二个人在没有口头提示的情况下完成一次恢复演练：从告警找到任务、判断是否能重试、执行恢复并验证结果。只看过架构图不算掌握；能在压力较低的演练中走完整条路径，才说明知识没有锁在负责人脑中。

技术负责人不能把个人偏好包装成长期方向。对重要选择做小型原型，用真实任务比较，再公开记录取舍。这样未来改变决定时，团队是在更新假设，而不是推翻某个人的权威。

技术负责人最重要的工作不是选择最先进的技术，而是让团队知道哪些地方可以大胆试错，哪些边界必须谨慎保护。

图：有限注意力优先投入高影响、退出缓慢的选择。

实际操作中，我用一张可逆性表决定每个选择的讨论深度：影响半径、回退时间、数据迁移、外部绑定、验证窗口和最晚决定日。两小时能回退的 UI 库不占用一周会议；涉及客户数据格式和长期合同的选择必须留下 ADR 与退出方案。创业阶段最稀缺的是注意力，把判断精度用在不可逆和高影响处，比让所有技术决定都达到理论最优更重要。

两篇相邻的文章可以对照看：两周 MVP 里那些“能推迟就推迟”的功能，依据的是同一张可逆性表（见两周交付 AI MVP）；而决定一旦属于“必须记录”的那一档，留下证据的格式就是ADR 怎么写才有人看。