用14天决策循环替代“转行自信心”

别再迷信什么“相信自己”这种鸡汤了，在公司内部推行AI工具或者尝试技术转型时，这种虚无的自信根本解决不了实际问题。最核心的矛盾在于：你面对的是一个需要结果的决策，但手里的证据不足。与其死等自信心爆棚，不如追求“决策就绪”——也就是拿到足够证据，决定下一步怎么走。

我把这套逻辑实操成了一个为期14天的快速验证循环，核心是通过一个GitHub仓库记录实验，而不是写日记。

一、搭建个人实验仓库

先建一个私有Repo，用来存放所有可量化的证据。结构建议如下：

transition-lab/
├── README.md
├── decisions/
│ └── 001-test-backend-work.md
├── evidence/
│ ├── job-sample.md
│ └── feedback.md
├── artifact/
└── .github/
 ├── ISSUE_TEMPLATE/
 └── workflows/

记住，这里面不要记录“今天学了什么”，而要记录“什么观察能改变我的决定”。

二、编写可证伪的假设

不要问“我适不适合做后端”，这种问题没法测。你需要在 decisions/ 目录下写一个具体的假设。

---
id: D-001
status: active
started: 2026-07-27
deadline: 2026-08-10
reversible: true
---

# 验证后端开发是否为可行方向

## 假设
在两周约束下，我能独立构建并解释一个小型HTTP服务，且在经历调试和部署的枯燥过程后，依然对该方向感兴趣。

## 交付物
一个包含持久化、验证、测试且有README的已部署API。

## 证据收集项
- 能否在不完全依赖教程的情况下完成纵向切片
- 独立调试能力边界（能解决什么，卡在什么地方）
- 外部评审关于代码可维护性的反馈
- 匹配该技能栈的3个实际岗位描述
- 对日志、报错、文档等琐碎工作的真实反应

## 决策规则
- 继续：工作依然有趣，且能力差距在可训练范围内
- 调整：喜欢工作内容，但目标岗位或学习路径有误
- 暂停：时间或财务压力导致无法进行下一个冲刺
- 停止：日常琐碎工作完全不匹配，即使能完成也极其痛苦

三、闭环输出

14天结束时，你拿到的应该是：一个具体的假设、一个在压力下完成的交付物、一份外部客观评价，以及一个明确的结论（继续、调整、暂停或停止）。

这种工作流最强的地方在于，它把“转行”这个巨大的压力，拆解成了像软件开发一样的 Sprint。你不需要在第一天就确定这是你的终身事业，你只需要决定接下来的四周是去投三个初级岗位，还是换个方向试水。