为什么顶级程序员都用「决策减法」写代码：从 CEO 同款黑T 到你的 daily.dev 配置

作者提米哥

你有没有过这种感觉：
– 下午 4 点改一个 bug，反复看同一行代码 10 分钟，就是看不出少了个分号；
– Code Review 时前 3 个 PR 都认真写了建议，第 4 个直接点了 “Approve”；
– 明明知道该重构那段重复逻辑，却告诉自己“先 merge，明天再搞”——然后永远没有明天。

这不是你“不够努力”，也不是“状态不好”。
这是你大脑在真实报警：决策疲劳（Decision Fatigue）正在悄悄吃掉你的技术判断力。

别被名字吓到——它不是玄学，而是像肌肉酸痛一样可测量、可预防的生理现象：
✅ 每次你决定用 const 还是 let、选 axios 还是 fetch、要不要加 TypeScript 类型、是否要拆这个 Hook……都在消耗同一种认知能量；
✅ 这种能量有限，用完就“短路”：你会更依赖默认选项（比如无脑 any）、回避复杂权衡（跳过单元测试）、或突然冲动（“我重写整个模块吧！”）；
✅ 研究发现：开发者上午 10 点提交的 PR，被要求修改的概率比下午 3 点低 37%——不是代码变差了，是你的大脑累了。

那程序员能学 CEO 穿同一件 T 恤吗？

当然可以——而且早就在做了，只是没叫这个名字：

  • VS Code 主题/字体/快捷键固定一套 → 省下每天 2 分钟“今天用哪个主题”的决策；
  • Git 提交信息强制用 Conventional Commits → 不再纠结 “fix: xxx” 还是 “chore: xxx”；
  • CI 流水线模板化（如 .github/workflows/test.yml 复用） → 拒绝每次新建项目都重写 YAML；
  • 团队约定：函数超过 8 行必须拆、组件 props 超过 5 个必须封装 → 把“要不要重构”变成“是/否”判断题。

这些不是教条，是给大脑装上的「决策节流阀」。

开发者专属「决策减法」实战清单（今天就能用）

  • 删掉「小决策」，不是删功能：把 ESLint + Prettier 自动化到保存即格式化，让“要不要加空格”彻底消失；
  • 把重要决策「预约」在上午：把架构讨论、技术选型、Code Review 集中在 9:30–11:30，就像医生约手术时间；
  • 用框架代替临场发挥：
    “`ts
    // ✅ 好：用预设模板降低判断成本（比如 API 错误处理统一结构）
    interface ApiResponse {
    code: number; // 200=成功，4xx=客户端错，5xx=服务端错
    data: T; // 业务数据（成功时存在）
    message?: string; // 错误提示（失败时存在）
    }

// ❌ 累：每次调接口都要想“这次怎么处理错误？弹窗？Toast？静默？”
“`

  • 批量处理同类决策：
  • 不要边写新功能边修历史 tech debt；
  • 每周三下午 2–4 点，只做「技术债清理」：统一升级依赖、补缺失的类型、删废弃的分支；
  • 建「决策红绿灯」：
  • 🔴 红灯（必须停、拉会、查文档）：引入新基础设施（如换数据库）、影响 3+ 服务的 API 变更；
  • 🟡 黄灯（按模板走）：新增页面路由、加监控埋点、写单元测试；
  • 🟢 绿灯（自动执行）：代码格式化、Lint 检查、CI 构建。

最后送你一句硬核真相：

写出好代码的能力，不取决于你多能“卷”，而取决于你多会「不决策」。
把力气留给真正需要深度思考的地方——比如：这个需求，到底该不该做？

直达网址：https://keeprule.com/en/scenarios

作加

类似文章