一个任务如何走到生产环境

这是我在 2026 年真实的工作方式：每个任务先经过两道过滤——能否完全不用手工完成，以及编写能否提速——之后才进入代码。下面是完整的链路，逐步展开。

前提——负责人还是执行者只有当我对自己的领域负责时，过滤才成立

Promova 彻底重塑了我的思维方式：不只是当开发者，而是对每一个到我这里的任务做校验。不是「怎么做」，而是「它给业务带来什么」。不过这道过滤只在一个条件下才成立。

我对自己的领域负责

任务立刻过滤。我为结果负责，所以我有资格说「这根本不该做」或「这不该由我来做」。

我是执行者

没有过滤。有任务、有截止时间、有交付。这没什么不好——只是另一种约定而已。

差别不在技能，而在授权。一个完全对自己领域负责的独立单元，比一个执行者更省公司的钱——因为它不做多余的东西。

写码之前

一个任务进来了
我不会从「怎么做」开始。第一个问题是它给业务带来什么；第二个问题是它到底需不需要我亲手来做。
02
第一道过滤——能不能完全免去手工？
三条出路，三条都回答同一个问题：接下来由谁来做。任务只要走上任何一条，它就不再是我的，我的产能就留给真正需要开发者的工作。
流水线出口
- 由智能体来做
  配置一次，之后不再回到任何人手上。从此由一个智能体独自运行并完成，全程零参与。
  自动代码审查 · 分析数据直接进入专属 Slack 频道，而不是手动翻日志
- 由需求方来做
  任务根本不会到我手上。需要它的人自己借助 AI 完成——我的部分是把这条路修好一次。
  外联邮件 · 网红平台
- 由团队来做
  一个缝进系统里的功能或插件，团队借它自己改动——不用工单，不用开发者。
  CMS 里的重定向插件，归 SEO 团队掌管
第二道过滤——加快写码本身
任务熬过了第一道过滤，那它就是我的。下一个问题：这在代码层面算不算例行？如果模式会重复——按钮样式、反复出现的结构——我先给它写一个 skill，然后才写代码。第一次更久，之后每次都更快。

实现
由计划挑中的那一方开始写——我或智能体。
dev 环境检查——智能体
检查的是智能体，不是我：它用 Playwright 跑通流程，或通过 MCP 直接从 Next.js dev 服务器读错误。这里不消耗我的产能。
build 模式检查——智能体
dev 会骗人。chunk 不同、优化不同、行为不同。dev 里能跑、build 里挂掉是经典问题，所以 build 单独过一遍——同样由智能体来跑。
单元测试 + Playwright
只有在真正跑通之后。逻辑用单元测试，流程用 Playwright——同样由智能体来写。
预发环境——这里换我上
第一处由我亲手检查的地方。只有任务敏感时才在本地看。然后交给 QA——就是这个顺序，不能反过来。
Pull request
由掌管项目相应区域的 skill 所对应的智能体来审查：性能相关的改动对照性能规则，支付相关的改动对照支付规则。
生产环境
发布。
最终检查
QA 在生产环境验收。稳住了——就完成了。

根基

掌握架构实践、守住步骤顺序，就能同时把代码写得又快又好。速度来自次序，而不是敲字更快。

在某一项具体技术上的专精，总能写出更好的代码——这没什么可争的。但它不可迁移：换了技术栈就得从头再来。而对开发流程、架构和原则的理解，可以完整迁移。正是它让你能在还不熟悉的代码库里工作：plan mode（第 04 步）会告诉你这个具体项目是怎么搭的，而判断一个方案对不对，你本来就会。