从测试总监到 AI 产品架构师：我为什么选择这条路

不是励志故事

很多转型叙事都有一个"顿悟时刻"——某天突然想通了，然后勇敢转身，从此走上了正确的道路。

我的故事不是这样的。

如果非要说有一个触发点，大概是 2024 年初的一个下午。我在审查团队的测试方案时，发现 AI 工具生成的测试用例质量已经超过了团队中 70% 的人。作为一个管理着 80 多人测试团队的总监，这个发现让我感到的不是兴奋，而是焦虑。

如果 AI 能写出比大多数人更好的测试用例，那"管理一群写测试用例的人"这件事的价值在哪？

但这只是表面的触发点。更深层的原因，是过去几年积累的几个认知转变。

三个关键认知升级

认知升级一：管理经验是资产，也是陷阱

15 年的技术管理经验（10 年 QA + 5 年 PMO），让我对"怎么把事情做成"有深刻的理解。我知道怎么拆解复杂项目，怎么管理利益相关者的期望，怎么在资源有限时做取舍。

但这些经验也在限制我。

管理者的思维模式是"通过别人做事"——招人、分工、跟进、复盘。这在传统团队中是正确的，但在 AI 时代可能是错的。当 AI 可以替代大部分执行工作时，"通过 AI 做事"需要的不是管理技能，而是架构技能——你需要知道"做什么"和"怎么做"，因为执行已经被 AI 覆盖了。

从"管理者"到"架构师"的转变，本质上是从"组织人的工作"到"组织人与 AI 的协作"。

认知升级二：QA 思维是被严重低估的架构能力

这是我转型中最大的意外发现。

QA 出身的人有一种独特的思维方式：我们本能地会想"这个东西可能在哪里出问题？"这种"破坏性思维"在传统开发中被认为是"找茬"，但在 AI 时代变成了核心能力。

为什么？因为 AI 生成的代码有一个特点：它几乎总是"看起来对"的。 AI 不会写出语法错误或明显的逻辑 bug。它的问题在于更深层的地方——边界条件处理、并发安全、业务逻辑的隐含假设、架构层面的可维护性。

这些恰恰是 QA 思维最擅长发现的问题。

在做 LogiNexus 时，我发现自己的 QA 背景给了我一个巨大优势：我能在 AI 生成代码后准确地识别出潜在风险点。不是因为我写代码更厉害，而是因为我"找问题"更厉害。

具体来说，QA 思维在架构工作中的价值体现在：

风险感知能力。 看到一个架构方案时，我的第一反应不是"这个方案好不好"，而是"这个方案在什么条件下会失败"。这种思维在做 AI 产品时特别有用——AI 系统的失败模式比传统软件多得多（幻觉、置信度不稳定、边界输入等）。

端到端视角。 QA 天生关注完整的用户路径，而不是单个功能点。这让我在做架构设计时更容易发现"功能间缝隙"——那些单独看每个功能都没问题，但组合在一起就出问题的地方。

质量工程方法论。 不只是"发现问题"，还包括"设计质量保障体系"。在 LogiNexus 中，我设计了一套多源数据交叉验证的质量保障方案——GPS 数据来自 G7、GB32960、微信定位三个源，通过交叉验证确保准确性。这种思路直接来自 QA 的"测试金字塔"理念。

认知升级三：一人 + AI 可以做很多事

这个认知是在做 LogiNexus 的过程中逐步建立的。

LogiNexus 是一个完整的智能物流平台，覆盖了运单管理、智能调度、轨迹监控、运费结算等核心模块。在传统模式下，这样的项目至少需要 6 个人：前端、后端、数据工程师、产品经理、QA、DevOps。

但在 AI 辅助下，一个人覆盖了所有角色。不是因为我每个角色都很精通，而是因为 AI 补齐了我的技能短板：

• 前端： 我的前端基础不算强，但 Claude Code 可以生成高质量的 React/Next.js 代码，我负责审查和调整

• 后端： 架构设计是我来做，具体实现 AI 辅助完成

• 数据： 数据管道的设计我来做，Drizzle ORM 的 schema 和查询 AI 辅助生成

• 产品： 需求来自我对物流行业的理解，AI 帮我快速验证方案

• QA： 这是我的老本行，测试策略我来定，测试代码 AI 辅助生成

• DevOps： Vercel + Neon 的 serverless 架构大大简化了运维

6 个月下来，累计交付了 72 万行代码。这个数字本身不重要（AI 生成代码很快），重要的是：一个人可以端到端地交付一个中等复杂度的商业产品。 这在三年前是不可想象的。

转型的代价

说了这么多"认知升级"，也必须说说代价。

收入下降。 从总监到独立创业者，收入落差是显著的。前 6 个月没有任何产品收入，完全靠积蓄支撑。

身份焦虑。 过去 15 年，我的身份是"管理者"——管理团队、管理项目、管理流程。转型后，我的身份变成了"独立开发者"——一个人写代码、一个人做决策、一个人面对不确定性。这种身份转换比我预想的要困难得多。

技术焦虑。 从管理岗回到技术岗，最大的挑战是"代码能力的落差"。管理者看代码的视角是"这个能不能按时交付"，架构师看代码的视角是"这个设计是否优雅"。这两种视角的差距，需要时间和实践来弥补。

社交缩减。 管理者的日常充满了会议和社交。独立创业者的日常是一个人对着屏幕。这种社交强度的落差，对心理健康有不小的影响。

当前面对的挑战

转型半年多了，最大的挑战不是技术，而是这几个：

挑战一：从"会做"到"能说清楚"

做了 72 万行代码的项目，积累了大量的实战经验。但如果不能把这些经验写清楚、说清楚，它们就只存在于我的脑子里。

技术写作是我当前最大的短板。过去 15 年几乎没有公开的技术写作记录。从零开始建立写作习惯，比我想象的要难。不是因为没东西写，而是因为"写得不够好"的焦虑会阻碍你动笔。

我的应对策略：每周至少一篇文章，800-1500 字。不追求完美，追求持续。先完成再完美。

挑战二：LogiNexus 的商业验证

产品做出来了，但商业验证还在路上。冷链物流是极度传统的行业，客户决策链长、信任建立慢。一个没有销售团队的独立开发者，要如何获取第一批付费客户？

这是我接下来 6 个月最核心的挑战。如果到 2026 年 8 月还没有试用客户，就需要重新评估产品方向。

挑战三：可持续节奏

每天 8-10 小时的高强度工作，已经持续了半年多。虽然目前状态还行，但长期来看必须建立更可持续的节奏。42 天冲刺机制是一个尝试——通过短周期迭代来保持节奏感，避免无止境的冲刺。

给考虑转型的人的话

如果你也在考虑从管理岗转型到技术/产品岗，我的经验是：

第一，确认你的动机。 是"逃离管理"还是"奔向创造"？前者可能只需要换个管理岗位，后者才需要转型。

第二，利用而非放弃你的管理经验。 管理经验中的项目拆解能力、风险感知能力、利益相关者管理能力，在架构工作中都是直接可用的。

第三，准备好财务缓冲。 转型期没有收入是正常的。确保你有至少 12 个月的生活费储备。

第四，找到你的"做中学"项目。 不要先学习再实践，要在实践中学习。我的"做中学"项目就是 LogiNexus——在做一个真实产品的过程中，提升所有需要的能力。

第五，接受不完美。 你不会一夜之间从"管理者"变成"技术专家"。但你可以利用 AI 工具快速弥补技能短板，同时发挥你的独特优势。

转型不是一个事件，是一个过程。我还在这个过程中，每天都在学习，每天都在犯错，每天都在进步。这条路没有标准答案，但至少，它是我自己选择的。

这就够了。