当前位置：首页 > news >正文

我用 AI Agent 掀翻公司协作旧模式，从售后到研发，效率直接翻倍｜技术老兵复盘

news 2026/7/5 5:15:03

作为一个写了十几年代码的工程师老兵，这几年转型管公司后，我亲手写代码的次数越来越少。本以为会逐渐远离一线开发，没想到AI Agent的出现，让我每天合并的PR比过去任何时候都多。过去两周，我牵头用AI Agent重新梳理了公司多个部门的协作和沟通方式，从售后到研发再到销售，每一个环节都发生了肉眼可见的变化。这段经历没有标准答案，却能给同样在探索AI落地的企业提供一个真实的实践样本，今天就把这段复盘完整分享出来，也聊聊我在这个过程中的思考和感悟。

很多人聊AI，第一反应就是“谁会被替代”，但在我看来，AI Agent带来的不是替代，而是重构。它没有让某个人失业，而是重新定义了公司内部的协作逻辑和沟通方式。过去，信息在部门之间层层传递，一件简单的事往往需要多个人接力完成，中间环节越多，信息损耗就越大，响应速度也越慢。现在，需求、代码、工单、会议记录开始逐步汇总到统一的上下文里，一线拿到信息的人，在AI的协助下，就能更快地端到端推进事情，不用再反复跨部门沟通、确认。

这段时间的实践下来，变化主要集中在三个方面。一是中间“翻译”环节明显减少，过去销售对接客户的需求要翻译成产品语言，产品再翻译成研发能懂的技术需求，现在AI能直接打通这些环节，让需求传递更精准，响应速度也提升了不少。二是部门之间的“墙”开始变薄，协作链路大幅缩短，售后不用再频繁拉研发开会，研发也能直接获取客户的一手需求，不用再靠他人转述。三是售后、研发、销售不再是各自为战、单独优化，而是被一条更完整的业务链路重新串联起来，形成了闭环，整体效率提升的同时，客户体验也好了很多。

不止是工程师，更需要调整认知的是管理者

这两年，AI替代工程师的话题炒得很热，很多人都在担心工程师的岗位会被AI抢走。但我反而觉得，相比工程师，企业经营者和组织管理者更需要尽快调整认知，因为AI带来的不是某个岗位的变化，而是整个组织架构、协作模式的重构。

工程师其实正在经历一次非常明显的生产力提升，尤其是在软件行业。医疗、法律、制造等行业，AI虽然也在逐步渗透，但还没有像软件行业这样，直接深入到核心生产流程中。软件行业离这波AI变革最近，也最先感受到它的力量，工程师借助AI工具，能快速生成代码、排查问题、撰写文档，生产力翻倍增长。

真正需要重新审视的，是组织原本赖以成立的那套分工、协作和沟通方式，尤其是三类主体，需要重点关注。

第一类是长期依赖标准产品和按席位收费的软件公司。过去，按人头收费的模式支撑了很多软件公司的高增长预期，企业需要为每个员工购买账号，这是一笔稳定的收入。但当越来越多“用户”变成AI Agent，企业账号可能从几十个缩减到两三个，原本按人头收费的逻辑就会面临新的挑战，如何调整商业模式，适应AI时代的变化，成为这类公司的当务之急。

第二类是主要依赖技术壁垒和商业支持建立优势的软件公司。过去，用户面对几百万行代码，往往很难自己处理问题，只能依赖软件公司的商业支持，这也是很多软件公司的核心盈利点。但现在，AI可以快速读取代码、测试用例、文档，帮助用户补充功能、做适配，甚至排查复杂问题，原本的技术壁垒会越来越难维持，单纯靠商业支持盈利的模式也需要重新思考。

第三类是那些主要依赖信息传递、任务拆解和进度跟进来运转的组织角色。比如一些中层管理者，日常工作就是传递上级指令、拆解任务、跟进进度，协调各个部门之间的沟通。但AI把很多原本需要层层传递的工作打通之后，这类岗位的职责边界就需要重新定义，不能再停留在简单的信息传递和进度跟进上，而是要转向更具判断力、决策力的工作。

为什么公司沟通总要绕很多圈？

在AI普及之前，一个客户需求的流转通常要经过多个环节：销售和客户沟通，了解客户痛点；产品经理把客户痛点翻译成产品需求；架构师根据产品需求拆解技术方案；研发根据技术方案排期开发；测试对开发成果进行验证；最后由运维完成交付。

这个过程中，会经过很多层“翻译”，每一层翻译都可能出现信息偏差，导致用户想要的是A，最后做出来的却是B，而且往往要过很久才能发现偏差。很多人会疑惑，为什么一定要分这么多部门，让一个人从头到尾负责不好吗？

答案其实很简单，一个人的精力是有限的。擅长和客户沟通的人，未必擅长写代码；擅长写代码的人，未必擅长还原客户的真实需求；擅长做产品设计的人，未必擅长技术架构。所以，组织把每个人放在更细分的分工位置上，再靠流程、协作和沟通把这些环节串起来，这套逻辑在过去几十年里一直是成立的，也是提高效率的最优解。

但AI的出现，打破了这套逻辑。当AI能让一个工程师同时具备“懂客户、能拆需求、会写代码、能写测试、能写文档”的能力时，部门之间的分工就不再是必须的，那些厚厚的部门墙，第一次有机会被真正削薄。谁能拿到客户的一手信息，谁就更有可能减少中间传递环节，端到端把事情做完。

为什么软件行业最先发生这种变化？因为软件天然拥有大量的开源资产，确定性更强，结果也可以被验证。只要给AI足够清晰的输入，比如代码、文档、日志等，它就能给出可复现的输出，帮助工程师快速完成工作。而其他行业，要么缺乏足够的数字化资产，要么不确定性太强，AI很难快速发挥作用，所以暂时还没有这么明显的变化。

重构第一步：从售后切入，用案例打破信任壁垒

我们重构公司协作方式的第一步，选择从售后部门切入。原因很简单，售后是公司里最值得优先优化的环节，客户压力大，公司压力大，售后团队自身的压力也最大。跨时区陪客户复现问题是常态，一个简单的问题定位两三天很常见，复杂一点的甚至会拖上两个月。遇到难题，售后还要频繁拉研发一起排查，既占用售后的时间，也影响研发的正常开发进度。

先说说重构前的售后流程：客户提交工单后，售后会先收到告警，然后和客户预约沟通时间，沟通后拉取客户的系统日志，尝试复现问题，如果复现不了，就需要拉研发开会讨论，讨论完再约客户沟通，反复循环，效率极低。

重构后的流程就简洁多了：工单进来后，会自动同步成一个GitHub Issue，同时带上客户的产品版本、运行环境、系统日志等完整上下文，不用售后手动整理。接着，AI会先做一轮静态代码分析，它可以同时读取数据面、控制面、前端等四五个仓库的代码，这是单个研发很难同时做到的。

通常情况下，AI会在十分钟内给出初步报告，售后团队判断可以直接回复客户的话，点一下就能把报告发给客户，不用再手动组织语言。如果问题比较复杂，AI会自动按照客户的产品版本 checkout 代码、搭建运行环境，根据日志复现问题，半小时内就能给出深度报告，明确问题的可能根因和解决方案。

这个流程听起来很理想，但刚推的时候，售后团队其实半信半疑，毕竟大家习惯了过去的工作方式，对AI的能力还有所顾虑。为了打破这种信任壁垒，我们挑了一个团队前前后后花了很长时间都没搞定的老问题，CTO、架构师都参与过排查，始终没定位到原因，大家基本已经放弃了。

我们把这个问题的所有上下文，包括日志、代码、客户反馈等，都交给了AI。没想到，AI很快就通过静态代码分析，指出了问题的根因：错误日志的体量很大，而真正触发系统崩溃的那条日志，出现在崩溃前很久的一个时间点，人工排查时，很容易忽略那个时间段的日志，所以一直找不到问题所在。

我们按照AI给出的分析，对代码做了简单修改，问题竟然直接解决了。从那之后，售后团队就再也没怀疑过这个新流程，主动配合推进AI Agent的落地，售后效率也得到了质的提升，过去需要两三天才能定位的问题，现在基本能在一小时内给出解决方案，跨部门沟通的次数也减少了80%以上。

这里有一个很深的心得，AI重构最大的阻力往往不是技术，而是人的信任。很多时候，不是AI做不到，而是大家不愿意相信AI能做到。最有效的办法，不是反复宣讲AI的优势，而是找一个真实的、大家都解决不了的案例，让团队亲眼看到AI带来的变化，信任自然就建立起来了。

重构第二步：研发转型，从亲自写代码到把关AI写代码

售后部门的成功，给了我们很大的信心，紧接着，我们就把重构的重点放在了研发部门。过完年第一天，我就给所有研发开会，明确了三条新的工作方式，强行推动研发团队适应AI时代的工作节奏。

第一条，公司统一报销最好的Claude Code / Codex套餐，尽量让团队先用上最强的AI工具，不用大家自己承担费用，消除工具使用的门槛。第二条，命令行Agent优先，轻量补全类的IDE工具只作为辅助，因为命令行Agent能更全面地整合上下文，效率更高。第三条，优先让AI生成代码初稿，人负责设计、审查和决策，把工程师从重复的编码工作中解放出来，专注于更有价值的设计和判断。

大家的第一反应都是不适应，尤其是经验丰富的老工程师，他们习惯了自己亲手写代码，觉得AI生成的代码不够严谨、不够高效，甚至有人觉得“让AI写代码，就是否定自己的能力”。其实这很正常，长期形成的工作习惯很难快速改变，除非大家亲眼看到效率的提升，否则很难真正接受。

经过两个多月的磨合，现在研发团队的工作流程已经完全适应了新的模式，具体可以分为四个步骤。第一步，售前团队写一份详细的PRD，包括竞品调研、需求背景、现有代码定位等内容，把所有上下文都喂给AI，让AI充分了解需求。第二步，每日站会分配任务，分配任务的标准不再是“谁来亲自写代码”，而是“谁最懂这块业务、最适合把关”，毕竟代码由AI生成，把关才是关键。第三步，AI Agent根据PRD生成代码、提交PR，整个过程不用工程师干预，AI会自动处理代码格式、注释等细节。第四步，每个PR至少要经过四轮Review，分别是GitHub Copilot一次、一个外部Code Review服务一次、两个工程师各一次，确保代码的质量和安全性。

更高效的是，Review过程中留下的comment，原Session的AI会自动读取，然后一条一条尝试修改。比如工程师评论“方案不够合理，再调研一下”“测试覆盖不够，补上相关测试用例”，AI会自动根据这些评论优化代码，不用工程师再手动指导。很多时候，凌晨两三点，AI还在持续优化代码，一个Session会一直持续到PR被合并为止。

团队后来半开玩笑地说，自己从“码农”变成了“码监”，主要工作就是监工AI写代码，审查AI生成的代码，做出关键决策。这种转型带来的变化也很直接，过去一个版本只能带十来个功能，现在可以带更多功能；过去一周只能合并五六个PR，现在一天就能合并五六个PR。发布速度的瓶颈，也从“写代码”慢慢变成了“人Review”，这也意味着，工程师的核心价值，已经从“编码能力”转向了“判断能力”。

重构第三步：销售升级，让AI当专属销售教练

解决了售后和研发的问题后，我们把目光投向了销售部门。我们公司的销售有点特殊，大部分本身就是技术很强的人，毕竟我们的客户主要是架构师和CTO，技术专业度是建立信任的重要基础。但这类“技术型销售”也有一个共性问题，一聊技术就容易越聊越深，整场会议下来，聊了很多技术细节，却没有把客户的真实业务问题谈透。

做ToB销售的人都知道一条重要经验，如果没有把客户的真实问题谈清楚，后续的推进通常会很慢，甚至会出现客户需求理解偏差，导致后续工作白费。所以，我们决定用AI Agent，给销售团队配备一个专属的“销售教练”，帮助他们提升沟通效率，精准把握客户需求。

我们制定了一套简单的规则，首先，尽量保留所有客户会议的录音，工具不限，只要能清晰记录会议内容即可。其次，会议结束后，“销售教练Skill”会自动拉取录音，对会议内容进行复盘打分，分析销售在沟通中存在的问题，比如“技术细节过多，业务问题未深入”“未挖掘客户潜在需求”等，然后把复盘结果同步到内部群，让整个销售团队都能学习借鉴。

如果复盘结果显示，销售对客户的了解还不够充分，准备还不够到位，就先用AI多练几轮，模拟和客户的沟通场景，把关键问题补齐，再推进下一次沟通。除此之外，AI还会做对手推演，模拟目标公司CTO、架构师、采购等不同角色的视角，推演他们内部可能怎么讨论我们的产品，分析他们的顾虑和需求，再反推我们下一步怎么做更有效。

这件事在过去是很难做到的，你很难准确判断一家陌生大公司的CTO会怎么想，他们关注的重点是什么，顾虑是什么。但AI的知识面足够广，它可以结合目标公司的背景、CTO的个人履历、公开演讲等信息，做一个相对接近真实场景的模拟，帮助销售提前做好准备，精准应对客户的疑问。

这里要强调的是，AI扮演的不是销售的助手，而是教练。它用同一套标准，帮助整个销售团队持续提高沟通能力，避免出现“有的销售能力强，有的销售能力弱”的不均衡情况，让整个销售团队的专业度都能得到提升。经过一段时间的实践，销售团队的沟通效率提升了不少，客户需求的理解准确率也大幅提高，后续推进的速度也明显加快。

核心架构：GitHub成了新的协作中枢

在推进这一系列重构工作的过程中，我们形成了一个最重要的架构判断，那就是把公司的一切都迁到GitHub上。过去，我们的协作平台、迭代管理、客户工单、CRM等，分散在不同的工具上，信息不互通，AI Agent很难快速获取完整的上下文，协作成本很高。

现在，我们对所有工具进行了整合，具体的调整如下：过去用协作平台文档，现在换成GitHub Wiki / Issue；过去用专门的迭代管理工具，现在用GitHub Projects；过去用专门的客户工单系统，现在用GitHub Issues；过去的CRM系统，现在用GitHub Issues，通过定时任务同步客户动态；过去的定时服务，现在用GitHub Actions；AI Skill / Prompt则存放在GitHub Repo中，方便团队共享和优化。

这么做的原因很简单，AI Agent要能无障碍地读到所有代码、测试用例、文档、工单、客户历史、会议录音等信息，上下文越完整，AI的输出就越精准，协作成本也就越低，产出也越好。这件事没有捷径，只有把所有信息整合到一个统一的平台上，才能让AI Agent发挥最大的作用，也才能真正打通各个部门之间的信息壁垒，实现高效协作。

事实也证明，这个决策是正确的。自从把所有信息迁到GitHub上后，AI Agent的响应速度和输出质量都有了明显提升，各个部门之间的沟通成本也大幅降低，大家不用再在不同的工具之间切换，就能获取自己需要的所有信息，工作效率提升了不少。

开源视角：AI带来的新挑战与新思考

我们公司本身就是做开源的，所以在推进AI Agent重构的过程中，也深刻感受到了AI给开源行业带来的新挑战。这些挑战不是否定开源的价值，而是提醒我们，过去那种主要依赖License建护城河的开源商业模式，确实需要被重新审视了。

第一个挑战是License的约束力越来越弱。过去，大公司即便想尽量少付出额外成本，多少还会顾忌License的约束，不敢随意修改开源代码、规避开源协议。但现在，AI能把开源代码读懂，然后改写成“API一样、实现不一样”的版本，这里面的边界会越来越模糊，License的约束力也会随之减弱，开源项目的知识产权保护面临新的考验。

第二个挑战是商业支持的价值被削弱。过去，客户遇到问题搞不定的时候，会直接购买开源项目的商业支持服务，这也是很多开源公司的核心盈利点。但现在，AI能帮助客户自己处理很多问题，比如排查代码bug、补充功能适配等，客户会觉得很多问题自己也能先处理一部分，对商业支持的需求会减少，这会直接影响商业支持的价值感知，开源公司的盈利模式需要重新调整。

第三个挑战是贡献回上游的动力下降。过去，很多团队使用开源项目时，遇到问题会自己修改，然后把修改后的代码贡献回上游，帮助开源项目优化完善。但现在，AI能帮助团队快速修改代码，满足自己的需求，很多团队未必还会第一时间选择回馈上游，这会影响开源项目的迭代速度和质量，也会破坏开源社区的生态。

第四个挑战是安全问题更早暴露，对社区的响应能力提出更高要求。我们最近一个版本中，有相当一部分功能都在修复安全问题，这些安全问题很多都是AI帮我们发现的，都是之前人工排查没有注意到的风险点。但问题在于，开源维护者本身不一定是安全专家，也不一定总有足够的精力快速处理这些安全问题；而原本只有少数资深研究员才能挖到的安全漏洞，现在会被更多人更快发现，这对开源社区的响应速度和处理能力提出了更高的要求。

我不是在否定开源的价值，开源依然是软件行业发展的重要动力。但AI的出现，确实让开源行业面临了新的挑战，我们需要重新思考开源的商业模式，重新构建开源社区的生态，才能在AI时代持续发展。

人与人的差距：判断力成为最稀缺的资产

AI Agent出现后，还有一个很明显的变化，那就是人和人的差距可能会被进一步放大，甚至扩大到过去很难想象的程度。

在AI出现之前，顶尖工程师和刚入门工程师之间的生产力差距当然存在，但总体还比较有限。因为人要睡觉、要吃饭，精力有上限，即便顶尖工程师再厉害，一天能写的代码、能解决的问题也是有限的，而刚入门工程师只要努力，也能慢慢追赶。

但AI出现之后，这种差距就被彻底拉开了。AI可以24小时不间断工作，不用休息，不用吃饭，只要有足够的上下文，就能快速生成代码、排查问题。对顶尖工程师来说，AI是强大的助手，能帮他们解决大量重复的工作，让他们有更多时间专注于设计、判断等更有价值的工作，生产力会得到指数级提升；而对刚入门的工程师来说，AI虽然能帮他们快速生成代码，但也让他们失去了很多实践的机会，很多坑如果都被AI先填平了，人反而更容易缺少第一手经验，很难建立自己的判断力。

所以，对初级工程师来说，最大的挑战不是会不会被AI替代，而是在AI提供答案的同时，如何继续建立自己的判断力。不能只依赖AI给出的答案，还要多思考“为什么AI会这么做”“有没有更好的方案”，多动手实践，积累经验，才能在AI时代立足。

相反，有经验的架构师会迎来更大的发挥空间。架构师的核心价值，不是写代码的能力，而是判断力——知道这件事该不该做、优先级在哪、几个方案里哪个trade-off更合理、什么样的东西适合上生产，这些判断能力不会因为AI的出现而贬值，反而会变得更加重要。

现在，我招聘和培养员工时，相比单纯的编码能力，我会更看重那些有经验、能做关键判断的人。因为编码能力可以被AI替代，但判断力不行，它需要长期的经验积累和深度思考，是AI很难复制的，也是这个时代最稀缺的资产。

小公司的机会：敢推翻自己，才能抓住AI红利

在这波AI变革中，小公司其实有天然的优势。大公司组织庞大，流程固化，想要推进整体的协作重构，难度很大，需要协调各个部门、各个层级，推进速度会很慢。而小公司组织灵活，没有那么多固化的流程和利益纠葛，只要最高层下定决心，就能快速推进变革，抢占先机。

组织的竞争力，无非两样东西，品牌或者效率。对小公司来说，品牌影响力通常不如大公司，所以效率就是我们的核心竞争力。如果我们能借助AI Agent，把效率提升10倍、100倍，而竞争对手还停留在传统的协作模式上，那么两者之间的差距就会非常明显，小公司也能在激烈的竞争中脱颖而出。

但这里有一个关键前提，这件事必须由公司最高层亲自推动，才能更容易形成统一动作。AI重构不是某个部门的事，而是整个公司的事，需要售后、研发、销售、产品等所有部门协同配合。如果只有研发配合，测试、运维、产品不配合，那么重构工作也很难推进，很难达到预期的效果。

另外，一线团队面对新的工作方式，通常都会比较谨慎，很多人感受到的效率提升只有20%到30%，这往往是因为AI还只停留在局部补全层面，没有真正融入到整个工作流程中，没有对流程进行重构。

真正的变革，不是把现有流程优化30%，而是重新设计流程本身，重新组织人与人、人与AI之间的协作和沟通。如果只是局部提效，很难形成真正的组织优势，也很难抓住AI带来的红利。所以，这件事如果没有CEO亲自推动，没有下定决心推翻过去的传统模式，往往很难在组织层面真正落下去，也很难实现真正的效率提升。

AI时代，我们该如何自处？主动蒸馏自己

AI Agent时代，真正的含义是每个人都在成为Builder，每个人都能借助AI工具，快速实现自己的想法，创造价值。那么，我们作为工程师、作为管理者，该做些什么，才能在这个时代立足，不被淘汰呢？

我的答案是，主动蒸馏自己。所谓蒸馏自己，就是把自己的经验、判断、方法，提炼成可复用的Skill，让它们在自己不在场的时候，依然能发挥作用。

我现在做的，就是把自己Review代码的视角、打分销售会议的标准、拆解需求的路径，一个一个写成Skill，交给AI Agent，让AI能按照我的判断和方法去工作。比如，我Review代码时，会重点关注代码的安全性、可扩展性、可读性，我就把这些判断标准写成Skill，AI Agent在Review代码时，就会按照这个标准去审查，和我的判断保持一致。

如果你只是把自己定义为某个技术点上的执行者，每天重复写代码、做重复的工作，那么这部分能力很快就会被AI商品化，很容易被替代。如果你你的工作主要停留在信息传递和流程转发，没有自己的判断和思考，那么这部分价值也会被AI重新定义，岗位也会面临风险。

但如果你是有判断力的架构师，是有丰富经验的管理者，能把自己的判断力、经验沉淀成可复用的Skill，那么你就会成为组织里更关键、也更稀缺的那批人。因为这些沉淀下来的东西，是你长期经验的积累，是AI很难复制的，也是组织真正需要的。

真正拉开人与人差距的，不是会不会用AI，而是能不能把自己的判断、经验沉淀成可复用的方法。AI只是一个工具，它能帮我们提高效率，但不能替代我们的判断和思考。只有主动蒸馏自己，把自己的核心能力沉淀下来，才能在AI时代持续创造价值，不被淘汰。