AI Coding,正在重构整个IT管理体系

最近和一个创业的朋友聊天，他告诉我一件事：他们公司参加了一场黑客马拉松，主题是AI应用开发。他原本以为会像以前一样，产品经理找程序员组队——”我有想法，你来实现”。

结果到了现场，根本没人提这事。

大家聊的全是：怎么用AI Coding工具快速把想法跑起来？怎么找到目标用户？怎么赚到钱？

“就差一个程序员”这句话，在那场活动里彻底消失了。

说实话，我听完这个故事并不意外。因为我自己的工作方式，也在过去半年里发生了类似的变化——一个产品经理，借助AI Coding工具，能做的事情越来越多了，而且很多事以前根本轮不到我做。

这背后的变化，比大多数人想象的要深得多。

传统IT管理体系，正在失效

你一定很熟悉这套流程：

业务调研 → 需求整理 → 需求评审 → 开发排期 → 开发 → 测试 → 上线 → 迭代

一个中等规模的项目，涉及的岗位：产品经理、项目经理、业务方、技术负责人、后端开发、前端开发、测试工程师、运维工程师。中间还穿插着各种评审会、同步会、汇报会。

你可能觉得”本来就是这样啊”，但仔细想想，这套流程其实建立在一个前提上：技术能力是稀缺的，需要专人管理和传递。

产品经理负责”翻译”业务需求，传达给技术团队。技术总监负责协调各模块进度，向上汇报。项目经理负责确保大家在正确的时间做正确的事。

但这个前提正在被动摇。

先说信息衰减的问题。业务方说”我要一个方便的体验”，产品经理理解成”加个快捷按钮”，技术团队又理解成”写个接口”。每一层传递，都伴随理解偏差。这种偏差不是谁的问题，是这套链条的结构性缺陷。

再说时间。一个想法从提出到上线，往往要数周甚至数月。排期、评审、协调，每一步都在拉长周期。斯坦福大学做过一项研究，软件工程师只有不到40%的时间真正在写代码，其余都在沟通和等待。

Forbes今年初发了篇文章，标题就很直接：AI coding工具让开发者生产力提升2-3倍，项目时间线被大幅压缩，“making key parts of Agile irrelevant”。

讲真，看到这句话的时候我愣了一下。不只是瀑布流在失效——连敏捷都在失效。传统的项目管理方法，已经跟不上工具进化的速度了。

流程压缩：从”多人长链路”到”单人端到端”

AI Coding已经不是”代码补全”了

很多人对AI Coding的认知还停留在”AI帮你写几行代码，你检查一下，继续干活”的阶段。

但说实话，2025年底到2026年初，AI Coding工具已经进化到了一个完全不同的阶段。它不再是辅助工具，而是一套从规划到实现再到知识沉淀的完整工程体系。

这套体系的底层逻辑有个专业名称：上下文工程（Context Engineering）。Google DeepMind的研究者Phil Schmid给了一个定义：”在正确的时间、以正确的格式，为AI提供正确的信息。”Gartner直接把2026年定义为”Year of Context”，82%的IT领导者认为光靠prompt engineering已经不够用了。

说白了：AI Coding工作流的本质不是”让AI写代码”，而是”管理AI在什么时候看到什么信息”。

这不是纸上谈兵。开源社区已经冒出了成熟的框架。

Superpowers，GitHub上166k stars。它做的事情很直白——强制执行工程纪律。AI agent必须按 brainstorm → design → plan → TDD → implement → review 的顺序走，不可跳步。它的TDD机制会”删除没有测试的代码”，代码review技能在严重问题前直接阻断进度。说白了，流程管理从人盯变成了框架强制执行。规则比人更严格，也更稳定——至少它不会因为心情不好就对代码质量放水。

Trellis，跨14个AI coding平台的团队式工作流框架。它提供从spec规范制定、到task PRD拆解、到代码实现、再到journals会话日志沉淀的完整闭环。团队写一次规范，自动注入到每个成员的AI会话中。每次工作的上下文自动沉淀，下次会话自动恢复。一个人的经验，变成了全团队的知识。

GSD（Get Shit Done），47k stars。它解决的是更底层的问题——上下文腐烂。你可能遇到过这种情况：AI聊着聊着就开始”胡说八道”了。这不是模型的问题，是会话太长了，上下文太多，AI的注意力分散了。GSD用阶段隔离的方式，确保AI每次只看到跟当前任务相关的上下文。

三个框架各有侧重：Superpowers管纪律，Trellis管团队协作，GSD管上下文质量。但它们指向同一个方向：AI Coding工作流已经从单工具进化到体系化分层。

而这套体系的使用方式，跟传统开发完全是两回事：

你描述需求 → AI追问细节 → 你做选择 → AI生成方案 → 你评审 → AI执行 → AI自动测试 → 你验收

说白了，你全程只做选择题。

产品经理的”技术黑盒”被打碎了

传统流程里，产品经理的核心能力是业务理解，技术认知可以没有。需求文档写给人看，技术细节交给技术团队去”翻译”。产品经理完全可以把技术当黑盒——”我要一个搜索功能，输入关键词，返回结果列表”，这就够了。

这个分工能成立，是因为中间有两层翻译垫着：

每一层翻译都有信息损耗，但好歹能跑通。

AI Coding工作流改变了这个格局。

不懂技术的产品经理，面对AI Coding工具，仍然只能给出模糊的自然语言需求。AI的输出质量低，反复修改，最后还是得找工程师兜底。翻译损耗只是从”人→人”变成了”人→AI→人”，问题压根没变。

但懂技术的产品经理，在AI Coding工作流下就完全是另一回事了：

火山引擎在关于企业IT组织重塑的文章里说了一句话，我觉得很精准：初级和资深之间的差距，不再主要体现在写代码速度上，而更多体现在对业务的理解、与AI的协作能力、技术方案的判断力。

这句话放在产品经理身上，一模一样。

Forbes也观察到这个趋势：AI Coding工具让开发者开始承担”部分原本属于产品经理的职责”。但反过来也成立——懂技术的产品经理正在承担部分原本属于开发者的职责。 两个角色在往中间靠。

“懂技术”不等于”会写代码”

不过要强调一点：”懂技术”不等于”会写代码”。

AI Coding时代，写代码反而成了最不重要的技术能力。真正重要的是：

传统产品经理可以把技术当黑盒，因为中间有人帮你拆解、翻译、兜底。

AI Coding工作流里，你就是那个和AI直接对话的人。没有人帮你翻译了。

“重”中层管理，正在消失

中层管理存在的根基是什么

先想一个问题：中层管理者为什么存在？

传统IT组织里，信息天然是不对称的。高管不知道项目细节和工程瓶颈；工程师不知道业务优先级和商业约束；不同团队之间不知道彼此的进度和依赖。

所以中层管理者的核心价值不是”管理”，而是弥合信息不对称——上传下达、左右协调、把信息从一个人的脑子传递到另一个人的脑子。

传统总监的两大职能，不只多余，而且有害

传统总监、技术负责人主要做两件事。

一是监工——盯进度、催交付、检查产出质量。

在AI Coding工作流里，Superpowers的TDD机制会”删除没有测试的代码”，代码review技能在严重问题前阻断进度。框架自动执行，不需要人盯。而且说实话，规则比人更严格、更稳定——至少它不会因为赶进度就对代码质量睁一只眼闭一只眼。

二是经验输出——”我做过类似项目，应该这样设计”、”这个方案之前踩过坑”。

这种经验分享当然有价值。但AI Coding agent能实时调用当前最佳实践、分析整个代码仓库的架构、对标数万个开源项目的模式。一个人的经验积累，再深厚，也无法和这种知识覆盖面竞争。

更要命的是，这两种职能在新工作流里不只是多余，而是有害的。

监工式管理让团队感觉不被信任。框架已经在强制执行质量标准了，人工盯梢只会增加焦虑、拖慢节奏、打击主动性。

经验输出式指导让团队被动等待。”等总监拍板”变成了瓶颈——而AI Coding工作流的核心优势恰恰是快速迭代、即时验证。等一个人想清楚的时间，AI已经跑完三个方案了。

一句话：当框架管纪律、AI管知识，”管人”这件事本身就变成了干扰。

信息不对称本身，不存在了

AI Coding工作流带来的变化，不是”AI替代了中层做的事”——这太浅了。真正发生的是信息不对称本身被消除了：

Matt Hopkins在一篇叫《When AI becomes the manager》的文章里总结过，中层管理者存在的理由就三个：把高管战略翻译成具体任务、跨团队协调、为决策提供上下文。信息不对称消失后，这三个职能失去了存在的根基。

他举了个案例：多伦多AI公司Convictional搭了个平台，直接把高管战略翻译成员工每日任务。以前主管做的事——拆解战略、追踪进度、提供反馈——全部由平台自动完成。用他的话说：continuously, automatically, without anyone booking a meeting room。

不是孤例，是趋势

比裁员更有说服力的信号，是角色本身在合并。

Pragmatic Engineer 2026年的调查发现：工程师和工程经理的角色正在趋同。 AI让工程经理可以直接参与代码贡献，工程师也开始承担原本属于产品经理的需求判断。两个角色的边界在模糊。

火山引擎的判断更宏观：“组织结构不再只是人力协作的框架，而逐步演变为以AI增强型的业务单元来组织与编排。”

再看行业里发生的事：Zuckerberg推动Meta扁平化，取消”总监套总监”；亚马逊裁掉1.4万白领，理由是AI让更少的人做更多的事；Jack Dorsey的Block公司直接裁了40%，理由是”AI让更小、更扁平的团队成为可能”。2026年1月，美国裁员人数创下2009年以来的新高。

逻辑是一致的：当信息流转不再需要人做中介，层级就失去了存在的理由。

AI Coding下的新IT团队模型

三个变化，最终指向同一个结论——IT团队的管理模型正在发生根本性重构。

从多角色多节点，变成一人多面手的决策者。 传统流程里，产品经理管需求、技术负责人管方案、开发管实现、测试管质量、项目经理管进度。每个人只看自己那一环。AI Coding工作流把这条链路压缩了——一个人借助AI可以同时完成需求拆解、方案设计、代码实现、质量验证。角色边界消失了，但决策密度提高了。

从中层下达目标，变成个人主动式业务导向的判断决策。 以前，目标由中层分解下达，个人是执行节点。现在，业务理解直接转化为可执行的spec，个人从”等人派活”变成”主动判断做什么、怎么做、做到什么程度”。方向感和判断力取代执行力，成了核心能力。

从需要中层监工，变成AI Coding驱动的协作数据沉淀。 以前，项目进度靠人收集汇报，业务知识靠人传递沉淀，质量标准靠人监督执行。现在，项目状态、业务数据、决策记录自动沉淀在仓库中——Trellis的journals保存每次会话上下文，spec文件是团队共享的知识基线，git历史是最准确的进度记录。信息流转不再经过人的脑子，而是经过代码仓库。

这意味着团队需要的核心能力也在重新定义：

不过有一点要注意。火山引擎提醒过：个体提效不等于组织提效。 一个人变快了，不代表团队变快了。中间需要系统性的传导机制——spec规范、工作流框架、知识沉淀体系——才能把个体的能力放大为组织的竞争力。这不是换个工具就完事了，而是要重塑一整套工作方式。

IT团队的信息流转方式正在发生根本性变化：从”依赖人做信息枢纽”走向”依赖AI Coding工作流框架自动流转”。 中层管理的”上传下达、左右协调、监工催办”职能不再需要人来承担——框架做得更快、更准、更稳定。团队里每个人都是直接面对业务、直接是AI协作的决策者。

回到开头那个黑客马拉松。

“就差一个程序员”这句话消失后，下一个消失的会是什么？

可能是”请示一下总监”。可能是”排到下个迭代”。可能是”等产品经理出完PRD”。

AI Coding正在重构的不是某个岗位，而是整个IT生产关系的底层假设——技术能力稀缺、信息需要分层传递、协作需要专人协调。

当这些假设逐一失效，你的组织还在用什么逻辑运转？