一个人做项目：先减少切换，再放大产出

《工程化决策树》第 7 篇

主题：独立开发者的工程化------把有限精力留给判断

一个人可以覆盖多个工作环节，但不等于完整替代产品、设计、开发、测试、运维和安全等专业角色。独立开发者更需要知道：哪些工作适合交给系统，哪些风险需要停下来判断，哪些能力应该向外求助。

一、消耗精力的常常是切换，不是编码

起初我以为困难只是"一个人做所有事"，后来发现更持续的消耗来自角色切换。

下面是我经历过的一类工作日。时间不是效率统计，只是为了还原切换过程：

text 复制代码

上午：写后端 API
  → 客户消息进来，切到需求澄清
  → 回到代码，重新寻找上下文
中午前：前端联调报错，切到排障
下午：检查页面细节，再处理测试失败
傍晚：响应运维告警
  → 想继续上午的工作，却要重新建立思路

每件事单独看都能处理，组合在一天里却会不断打断深度工作。加班不能修复这种结构问题，只会让后面的判断更疲惫。

我后来采用的原则是：先判断失败代价和可逆性，再谈自动化。高风险或难以恢复的工作先建立隔离、审批、观测和恢复路径；跨过这道安全边界后，再把高频、可验证的步骤交给系统。涉及方向和取舍的工作仍由人负责。

二、自动化不是一张越长越好的清单

我现在用两层判断处理每一项工作：

先看失败代价与可逆性。影响真实用户、数据、安全、权限或费用，或者无法可靠恢复的动作，先进入安全边界：隔离环境、显式审批、持续观测和经过验证的恢复路径。
再看频率与可验证性。跨过安全边界后，高频且结果可由规则判断的步骤优先自动化；低频或难以验证的步骤保持简单，并保留人工判断。

这个顺序很重要。高频不代表可以直接自动执行，高风险也不因为频率低才需要保护。自动化优先级只能在风险边界明确之后讨论。

三、高风险或难以恢复：先隔离，再自动化

数据库迁移、权限变更、备份恢复、生产发布和自动回滚，都可能影响真实数据和用户。无论它们每天发生还是一年只发生一次，都不适合在缺少保护时追求"无人值守"。

我会为这类工作增加四层保护：

1. 变更前有边界

明确影响范围、前置检查、负责人和停止条件。高风险验证先放在隔离或受保护环境；数据库迁移要区分可逆与不可逆步骤，发布要知道哪些指标代表异常。

2. 系统负责准备

流水线执行备份校验、迁移预检、构建、部署和健康检查，把日志与差异集中给人审阅。可重复的步骤仍由机器完成。

3. 高风险动作显式批准

涉及生产数据、权限扩大、删除和外部费用时，我保留人工确认。自动化降低操作差错，但不会替我决定风险是否值得承担。

4. 失败后立即可见

自动回滚只有在异常检测、告警通知、回滚证据和人工跟进都有效时才有意义。第二天才从日志里发现昨晚发生过回滚，不是理想状态；它说明告警或值守链路还缺一环。

我会定期验证恢复路径，而不是只确认"配置文件里写了回滚"。备份能否恢复、旧版本能否在当前数据结构上运行，都需要演练或受控验证。

四、跨过安全边界后：让高频、可验证的步骤稳定重复

这类工作有明确输入、明确规则和可观察结果，适合作为第一批自动化对象。

工作	触发方式	可验证证据
格式与 lint	保存、提交或 CI	规则检查结果
类型检查	提交或 CI	编译器诊断
单元与集成测试	变更或合并请求	测试报告
构建	合并前	可复现构建产物
低风险、可逆的常规部署	受保护环境或审批后的发布	发布记录、健康检查与恢复结果
基础观测	持续运行	日志、指标和告警

我的代码流程逐步变成：

text 复制代码

提交变更
  → lint
  → type-check
  → test
  → build
  → 生成可审阅结果

这类自动化带来的价值不只是少点几次命令。更重要的是，它把"我是否记得检查"变成"系统每次都会检查"，减少了我在编码、测试和发布角色之间来回切换。

五、需要人工判断：不要把责任藏进工具

独立开发者最稀缺的不是敲键盘的时间，而是把不完整信息变成可承担的选择。这些工作很难被一个通用门禁判定：

客户当前最需要解决什么，而不是什么都做；
架构复杂度与未来变化之间如何取舍；
某个体验问题是否值得延迟发布；
安全、合规、成本和进度之间如何权衡；
事故发生后，表面故障背后的组织原因是什么；
自己缺少专业能力时，何时请设计师、安全专家、法务或运维协助。

工具可以整理访谈、列候选方案、检查一致性和准备证据。Agent 也可以在边界清楚的任务里起草代码、测试或文档，但它只是辅助者。

一个人交付项目不等于一个人拥有所有专业角色的判断。尤其在支付、隐私、医疗、财务和高可用系统中，自动化不能代替专业审查，Agent 也不能承担责任。

六、Agent 对独立开发者的边界

我使用 Agent 是为了减少资料整理、常规实现和上下文恢复的切换，不是搭建一个看起来齐全的虚拟团队。它可以根据已确认接口起草常规代码、整理测试候选、核对文档差异或汇总部署日志；我仍要审阅产物，并对发布决定负责。

同一套风险闸门也适用于 Agent：可能触达生产、真实数据或不可逆结果的任务，不能因为由 Agent 执行就绕过隔离与审批。目标尚未定义，或安全、合规、设计等判断超出我的能力时，我会暂停委派并找相应专业人士，而不是让工具补齐我并不具备的经验。

七、从哪里开始自动化

先过风险闸门，再决定自动化优先级：

text 复制代码

失败代价高，或结果难以恢复？
│
├── 是
│   ├── 先隔离或进入受保护环境
│   ├── 设置审批、观测和恢复路径
│   └── 只自动化边界内可验证的步骤
│
└── 否
    └── 是否高频且可由规则验证？
        ├── 是 → 优先自动化
        └── 否 → 保持简单或由人判断

如果从一个空白项目重新开始，我通常按这个顺序建立基础：

统一启动和检查入口，让自己不必记零散命令。
接入 lint、类型、测试和构建，先获得快速反馈。
为核心用户路径补可重复测试。
在受保护环境建立部署流程、健康检查、日志和告警。
在明确异常信号和恢复路径后，再引入自动回滚。
任务复杂到上下文相互干扰时，再使用 Agent 隔离。

顺序不是按年份固定，也不要求每个小项目都做全套。预期寿命短、失败代价低且容易恢复的工具，可以保持轻量；承载用户数据、结果不可逆或持续运营的产品，需要把隔离、审批、观测、备份和恢复提前。

八、我的实践发生了什么变化

我仍然会在一天里处理需求、架构、代码和发布，但切换方式变了。

以前，我在每个角色里手工确认"下一步做什么"；现在，规范记录已确认决策，流水线执行常规检查，测试说明核心行为，观测告诉我发布后发生了什么。Agent 帮我准备材料和处理边界清楚的任务，我把时间放在审核、取舍和核心逻辑上。

这套系统没有把我变成一支完整的专业团队，也不会消除返工。它做的是降低遗漏和重复操作，让有限精力集中在当下最需要人的地方。

衡量自动化是否有效，我不再使用"替代了几个人"或"快了几倍"，而是看三个信号：

常规检查是否每次都执行；
高风险变化是否更早暴露；
我是否能在中断后通过清晰产物恢复上下文。

对独立开发者来说，这已经是很实在的杠杆。

下一篇是终章：为什么"不需要英雄"不是否定专家，而是让专家的判断进入系统。

上一篇：同一模型，为什么交付结果差这么远

下一篇：工程化的终点是"不需要英雄"

《工程化决策树》第 7 篇 · lytao123