《AI Coding 工程化：从个人提效到组织升级》· AI 时代全栈专题第 1 期
这个专题主要聊 AI Coding 降低实现门槛以后，前端、后端、测试的岗位边界会怎么变化，团队又该怎样守住专业能力与交付质量。
我们最近做了一件过去不太容易推的事：试点“全员全栈”。
以前一个需求进来，会分别拆给前端、后端和测试。每个人只处理自己那一段，中间靠需求文档、设计评审、联调和沟通把几段工作接起来。
现在，我们不再按岗位拆需求，而是大致按人数分配。前端、后端、测试都会拿到完整需求，谁拿到，谁就借助 AI Coding 按照全栈方式完成。当然前期我们是以一些普通需求做试点，复杂需求还没纳入。
这里不是重新招一批全栈工程师，也不是挑几个人成立一个全栈小组，而是让现有团队一起转。
跑了一段时间以后，收益确实有。一个人从头做到尾，少了很多信息传递和重复理解，需求会快一些。但提升没有想象中那么夸张，主要提效仍然来自 AI Coding。
更值得讨论的是另一面：AI 可以帮一个人把前端、后端代码写出来，却不会自动把另一个岗位多年积累的专业判断一起装进来。
我们很快就在一次上线里碰到了这个问题。
本地功能没问题，上线后 App 端却不能用
那是一个前端同学完成的功能。
他在本地把功能调通，自己验证也没有问题，于是按流程上线。结果上线以后才发现，这个功能在 App 端不能使用。
问题本身并不复杂，就是没有覆盖多端测试。
过去由测试同学负责时，类似功能会覆盖 H5、Android、iOS、鸿蒙和小程序。测试并不是看到一个页面能正常操作就结束，而是知道这个功能涉及哪些端，每一端要验证什么。
这次换成开发同学自己测试，他熟悉自己写的功能，也确认本地运行正常，很自然地觉得已经没问题了。但他只验证了一个端。
开发和测试看待同一个功能，关注点本来就不一样。
| 原来的专业方向 | 跨到其他环节时容易缺少什么 |
|---|---|
| 测试做开发 | 能判断功能是否正确，但不一定能判断代码实现是否合适，遇到开发环境问题也容易卡住 |
| 前端、后端互相跨端 | 对另一端的代码、运行机制、环境和常见实现方式不熟悉 |
| 开发自己做测试 | 容易围绕自己的实现验证，漏掉完整业务场景、多端覆盖和回归范围 |
这些问题并不代表全栈试点失败。代码不熟、环境不会配、实现方式拿不准，都可以通过 AI 和团队互相帮助逐步解决。
真正危险的是：一个人做完了全部工作，也顺手用自己的理解完成了全部验收。
如果中间没有专业流程约束，他不知道自己漏掉了什么。
全栈不是把三套流程压缩成一套
发现多端漏测以后，我们没有退回原来的任务分法，也没有另外设计一套更轻的“全栈流程”。
我们的处理很直接：原来开发和测试怎么做，现在仍然怎么做。
测试用例要经过评审，评审完成以后再定稿；真正执行时，每一条用例都要逐项验证，并且标记状态。哪些端需要覆盖、哪些场景需要回归，也不能因为执行者换成了开发就省略，或者使用了AI就省略。
开发流程同样如此。代码规范、设计要求、必要评审和验证标准，不会因为测试同学开始写代码就自动降低。
所以，全栈真正改变的是执行者，不是交付标准。
以前三个人分别执行三段流程，现在可能由一个人把三段都走完。但如果所谓全栈只是让一个人写完前端、后端，再凭感觉点几下页面，那不是全栈。
随着 Harness 工程逐步完善，其中一些固定步骤可以由流程自动提醒、检查和留痕，但关键设计和测试用例是否合理，目前仍需要有专业经验的人判断。
所有人转全栈，不等于所有人变得一模一样
老A的判断是，随着 AI Coding 和 Harness 越来越强，研发团队逐步全栈化是一个很明确的方向。
但这不代表前端、后端和测试的专业能力会消失。
我们不是保留一批只做专业工作的专家，再换一批人做全栈，而是让现有团队成员都逐步具备端到端交付能力。前端同学可以完成后端和测试，后端、测试同学也一样。
与此同时，每个人原来最擅长的方向仍然有价值。
遇到普通需求，大家按人数分配，各自端到端完成；遇到跨端执行者解决不了的环境、实现或质量问题，对应专业更强的同学就介入帮助。设计评审、测试用例评审这些关键节点，也仍然需要专业人员守住质量。
复杂需求更没有必要为了“全栈”两个字强行交给一个人。我们原本就把需求分为普通需求和复杂需求：普通需求按迭代周期执行，复杂需求单独评估、排期。现在只是把普通需求改成全栈交付，复杂需求仍然按照前端、后端、测试等职能拆分。
我更愿意把未来的专业方向理解成一种能力强项，而不是一道任务围墙。
你可以端到端完成一项普通需求，同时在前端体验、后端架构或者测试质量上，比其他人看得更深。当团队碰到复杂问题时，这些深度仍然决定了项目能不能做好。
不过，这只是基于当前模型能力和团队实践得出的答案。
全栈到底是能力升级，还是一个人干三份活
这也是全栈最容易引发争议的地方。
站在团队管理者角度，一个人端到端完成需求，减少沟通和交接，资源安排也更灵活，当然有吸引力。
站在开发者角度，原来只需要做好一个方向，现在既要写前端和后端，又要设计测试用例、处理环境问题，还要对最终结果负责，很容易产生另一种感受：是不是三份工作压到了一个人身上？
我觉得，两者的差别不在“全栈”这个称呼，而在团队到底怎么做。
如果只是增加职责、减少人手，再把原来的评审和质量流程一起删掉，全栈当然会变成负担，项目质量也迟早出问题。
如果 AI 接走了大量重复实现，个人因此能够真正负责一个完整需求；团队又保留专业规范、评审机制和互相支持的能力，那么全栈才是能力边界的扩大。
我们现在的试点更接近后者，但也远没有到可以宣布专业分工已经结束的时候。普通需求能一个人做，不代表复杂项目也应该一个人扛；代码生成变容易，也不代表专业判断变得不重要。
如果所有需求都能端到端交付呢
再往后看一步，问题可能会变得更尖锐。
如果模型能力继续增强，Harness 把需求澄清、设计、编码、测试和发布真正串起来，企业的知识库、工具、权限、质量卡点也逐步补齐，今天只用于普通需求的全栈模式，未来有没有可能覆盖复杂需求？
到那时，一个人端到端交付，未必是一个人亲手写完前端、后端和测试代码，而是一个人借助整套企业 AI Coding 基建，带着多个 Agent 跑完整条研发链路。
那么，前端、后端和测试这些专业能力还需不需要？程序员还需不需要？
老A现在的判断是，岗位还会继续融合，纯执行型工作也会越来越少，但专业判断不会突然消失。需求有没有价值、架构该怎么取舍、风险能不能接受、结果是否真的达到交付标准，这些事情仍然要有人判断和负责。
其中一部分经验会逐步沉淀进知识库、Spec、质量规则和 Harness，让 AI 下次直接执行；剩下的复杂决策和例外问题，仍需要真正懂业务、懂技术的人处理。
也许未来企业不再需要那么多按技术栈分工的程序员，而是需要少数能够定义目标、建立约束、判断结果并承担责任的人。到了那一天，这些人还叫不叫程序员，反而不是最重要的。
写在最后
AI Coding 正在改变研发团队的分工方式。至少在我们的试点里，普通需求已经可以不再按前端、后端和测试拆开，而是交给一个人端到端完成。
岗位边界确实会越来越淡，现有团队成员也会逐步转向全栈。
至少在今天，真正决定交付质量的那些东西还没有消失：完整的开发流程、测试覆盖、设计与用例评审，以及遇到棘手问题时的专业判断。
全栈化改变的是谁来完成工作，不是把专业标准一并取消。
但未来的答案未必和今天一样。
如果模型、Harness 和企业 AI Coding 基建继续增强，最终所有需求都可以由 AI 端到端交付，那时还需不需要这些专业能力，还需不需要程序员？面对这样的未来，你最担心的是什么？
欢迎在评论区聊聊你的判断，也欢迎说说你所在的团队正在发生什么。
