我用两周时间，用 AI Agent 重构了公司的协作和沟通方式

开场：一个写了十几年代码的老兵，现在每天都在提交 PR

我是工程师出身，早些年写了不少代码，这几年管公司，反而越写越少。

但 AI Agent 出来之后，我现在每天合的 PR 比过去任何时候都多。

过去两个月，我尝试用 AI Agent 重新梳理公司里多个部门的协作和沟通方式。这篇文章，就是这段经历的一次复盘。观点未必完整，但应该能提供一个真实样本。

先看全貌

如果把这次变化说得再直接一点，它并不是 AI 替谁干活，而是开始重组公司内部的协作和沟通。

过去，信息要在多个部门之间层层传递，一件事往往要很多人接力完成；现在，需求、代码、工单、会议记录开始逐步汇到统一上下文里，一线拿到信息的人，可以在 AI 的协助下更快地端到端推进。

从结果上看，变化主要体现在三件事上。第一，中间翻译明显减少，响应速度更快了。第二，部门之间那道墙开始变薄，协作链路缩短了。第三，售后、研发、销售不再只是各自优化，而是开始被一条更完整的链路重新串起来。

一、真正需要重新思考的，不只是工程师

这两年，大家聊 AI，最常见的话题就是工程师会不会被替代。

我反而觉得，更需要尽快调整认知的，是企业经营者和组织管理者。

工程师正在经历一次非常明显的生产力提升。医疗、法律、制造这些行业，AI 也在进入，但还没有像软件行业这样，直接深入到核心生产流程里。软件行业离这波变化最近，也最先感受到它的力量。

真正需要重新审视的，是组织原本赖以成立的那套分工、协作和沟通方式。

一是那些长期依赖标准产品和按席位收费的软件公司。过去，这套模式支撑了很高的增长预期；但当越来越多“用户”变成 AI Agent，企业账号可能从几十个缩到两三个，按人头收费的逻辑就会面临新的挑战。

二是那些过去主要依赖技术壁垒和商业支持来建立优势的软件公司。过去用户面对几百万行代码，往往很难自己处理，只能购买商业支持。现在 AI 可以把代码、测试、文档都读一遍，再帮助用户补功能、做适配，原有壁垒会越来越难维持。

三是那些主要依赖信息传递、任务拆解和进度跟进来运转的组织角色。AI 把很多原来需要层层传递的工作打通之后，这类岗位的职责边界也需要重新定义。

二、为什么公司的沟通总要绕很多圈

AI 之前，一个客户需求的流转通常是这样的：

销售聊痛点 → 产品经理翻译 → 架构师拆方案 → 研发排期 → 测试验证 → 运维交付。

中间会经过很多层翻译。用户要的是 A，最后做出来的可能已经变成 B，而且往往要过很久才发现偏了。为什么一定要分这么多部门？

答案很简单：一个人的精力有限。擅长和客户沟通的人，未必擅长写代码；擅长写代码的人，未必擅长还原真实需求。所以组织把每个人放在一个更细的分工位置上，再靠流程、协作和沟通把它们串起来。这套逻辑在过去几十年一直成立。

但当 AI 让一个工程师同时具备“懂客户 + 能拆需求 + 会写代码 + 能写测试 + 能写文档”的能力时，这套逻辑就开始变化了。

部门之间那道厚墙，第一次有机会被真正削薄。谁拿到客户一手信息，谁就更有可能减少中间传递，端到端把事情做完。

软件行业最先发生这件事，是因为软件天然拥有大量开源资产，确定性也更强，结果可以被验证。给 AI 足够清晰的输入，它就更容易给出可复现的输出。其他行业暂时还没有这么好的基础。

三、第一步：从售后开始

我们动刀的第一个部门是售后。

原因很简单，售后是最值得优先优化的环节。客户压力大，公司压力大，售后团队自己的压力也最大。跨时区陪客户复现问题，一个问题定位两三天是常态，复杂一点的甚至会拖上两个月。遇到难题，还要频繁拉研发一起排查。

重构前

客户工单 → 告警 → 售后约会 → 拉日志 → 尝试复现 → 拉研发开会 → 再约客户 → ……

重构后

工单进来后，会自动同步成一个 GitHub Issue，带上客户版本、环境、日志等完整上下文。

AI 先做一轮静态代码分析。它可以同时读数据面、控制面、前端等四五个仓库，这是单个研发很难同时做到的。

十分钟内给出初步报告。售后判断能不能回复，能的话点一下就能发给客户。

如果问题复杂，AI 会自动按客户版本 checkout、起环境、按日志复现，半小时给出深度报告。

流程听起来很理想，刚推的时候团队其实半信半疑。

我们挑了一个一直搞不定的老问题。团队前前后后花了很长时间，CTO、架构师都拉进去过，始终没定位到原因。大家基本已经放弃了。

我们把所有上下文都交给 AI。很快，静态代码分析就指到了根因：错误日志体量很大，而真正触发崩溃的那条日志，出现在崩溃前很久的一个时间点。人工排查时，很容易忽略那个时间段。

按 AI 的分析一改，问题解决。

从那之后，售后团队就再也没怀疑过这个流程。

💡 心得：AI 重构最大的阻力往往不是技术，而是信任。最有效的办法，是用一个真实案例，让团队亲眼看到变化。

四、第二步：研发——从亲自写，到把关 AI 写

过完年第一天，我给所有研发开会，明确了几条新的工作方式：

第一，公司统一报销最好的 Claude Code / Codex 套餐，尽量让团队先用上最强的工具。

第二，命令行 Agent 优先，轻量补全类 IDE 工具只作为辅助。

第三，优先让 AI 生成代码初稿，人负责设计、审查和决策。

大家第一反应都是不适应，尤其是经验丰富的老工程师。如果没有亲眼看到效率提升，很难真正改变原有习惯。

今天的流程是：

售前写一份很详细的 PRD，包括竞品调研、需求背景、现有代码定位，把所有上下文先喂进去。

每日站会分任务。分给谁，不是因为谁来亲自写，而是谁最懂这块、最适合把关。

AI Agent 写代码、提 PR。

每个 PR 至少四轮 Review：GitHub Copilot 一次，一个外部 Code Review 服务一次，两个人各一次。

Review 留下的 comment，原 Session 的 AI 会自动读到，再一条一条尝试改。比如“方案不够合理，再调研一下”“测试覆盖不够，补上”。

凌晨两三点，AI 还在继续干活。很多时候，一个 Session 会一直持续到 PR 被合并为止。

团队后来半开玩笑地说，自己从“码农”变成了“码监”，负责监工 AI 写代码。

变化也很直接。一个版本以前带十来个功能，现在可以带更多；过去一周合五六个 PR，现在一天就能合五六个。发布速度的瓶颈，也从“写代码”慢慢变成了“人 Review”。

五、第三步：销售——让 AI 当销售教练

我们的销售有点特殊，大部分本身就是公司里技术很强的人。客户通常是架构师和 CTO，技术专业度本来就是建立信任的重要基础。

但这类“技术型销售”也有一个共性：一聊技术就容易越聊越深，结果整场会议技术细节很多，业务问题反而没有谈透。

ToB 销售里有一条很重要的经验：如果没有把客户的真实问题谈清楚，后续推进通常会变慢。

我们上了一套规则：

我们会尽量保留客户会议录音，工具不限。

会后，“销售教练 Skill”会自动拉取录音、做复盘打分，再同步到内部群。

如果复盘结果显示准备还不够充分，就先用 AI 多练几轮，把关键问题补齐，再推进下一次沟通。

AI 还会做对手推演：模拟目标公司 CTO、架构师、采购等不同视角，推演他们内部可能怎么讨论，再反推我们下一步怎么做更有效。

这件事以前很难做到。你很难准确判断一家陌生大公司的 CTO 会怎么想，但 AI 的知识面足够广，可以结合公司背景、个人履历、公开演讲等信息，做一个相对接近真实场景的模拟。

它扮演的不是助手，而是教练。用同一套标准，帮助整个销售团队持续提高。

六、GitHub 成了新的协作中枢

做这些事的过程中，我们形成了一个最重要的架构判断：

公司的一切都迁到 GitHub 上。

原因很简单：AI Agent 要能无障碍地读到所有代码、测试、文档、工单、客户历史、会议录音。

上下文越完整，协作成本越低，产出也越好。这件事没有捷径。

七、开源：我看到的新挑战

我们自己就是做开源的，所以这层变化也值得摊开来讲。

开源会面临新的压力。

单靠 License 的约束，会变得越来越弱。过去大公司即便想尽量少付出额外成本，多少还会顾忌 License。现在 AI 能把代码读懂，再改写成“API 一样、实现不一样”的版本，这里面的边界会越来越模糊。

一部分商业支持会被替代。过去客户搞不定，会直接购买你的支持服务；现在 AI 会让客户觉得，很多问题自己也能先处理一部分。这会直接影响商业支持的价值感知。

贡献回上游的动力，也可能下降。既然自己能先改，很多团队未必还会第一时间选择回馈上游。

安全问题会更早暴露，也更考验社区的响应能力。我们最近一个版本里，有相当一部分 feature 都在修安全问题，AI 帮我们发现了大量之前没注意到的风险点。问题是，开源维护者本身不一定是安全专家，也不一定总有足够精力快速处理；而原本只有少数资深研究员才能挖到的问题，现在会被更多人更快发现。

我不是在否定开源。只是说，过去那种主要依赖 License 建护城河的开源商业模式，确实需要被重新审视了。

八、人和人的差距，可能会被进一步放大

AI 之前，顶尖工程师和刚入门工程师之间的生产力差距当然存在，但总体还比较有限。人要睡觉吃饭，精力也有上限。

AI 之后，这种差距可能会被进一步拉大，甚至扩大到过去很难想象的程度。

对初级工程师来说，最大的挑战不是会不会被替代，而是在 AI 提供答案的同时，如何继续建立自己的判断力。很多坑如果都被 AI 先填平了，人反而更容易缺少第一手经验。

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

判断力会成为这个时代最稀缺的资产。

相比单纯的编码能力，我现在会更看重那些有经验、能做关键判断的人。

九、小公司的机会，在于敢不敢推翻自己

小公司在这一波里有天然优势。

组织的竞争力，无非两样：品牌，或者效率。效率上，如果你能提 10 倍、100 倍，而对手提不了，差距就会非常明显。

但这件事往往需要公司最高层亲自推动，才更容易形成统一动作。

研发配合了，测试、运维、产品不配合，还是没用。

一线团队面对新的工作方式，通常都会更谨慎。很多人感受到的效率提升只有 20% 到 30%，往往是因为 AI 还只停留在局部补全层面。

真正的变革，不是把现有流程优化 30%，而是重新设计流程本身，重新组织人与人、人与 AI 之间的协作和沟通。如果只是局部提效，很难形成真正的组织优势。

所以这件事如果没有 CEO 亲自推动，往往很难在组织层面真正落下去。

十、主动蒸馏自己

AI Agent 时代真正的含义是：每个人都在成为 Builder。

那我们做工程师、做管理者的该做什么？

主动蒸馏自己。

我现在做的，就是把自己 Review 代码的视角、打分销售会议的标准、拆需求的路径，一个一个写成 Skill，让它们在我不在场的时候继续工作。

如果你只是把自己定义为某个技术点上的执行者，这部分能力很快就会被 AI 商品化。

如果你的工作主要停留在信息传递和流程转发，这部分价值也会被重新定义。

如果你是有判断力的架构师，把判断力做成可复用的 Skill，你就会成为组织里更关键、也更稀缺的那批人。

真正拉开差距的，不是会不会用 AI，而是能不能把自己的判断沉淀成可复用的方法。

最后的建议

这些观点未必都对，很多也还需要时间验证。重要的不是直接接受结论，而是带着你自己的业务上下文，再认真走一遍。

今晚就装一个 Claude Code 或者 Codex，拿你们业务里一个最大、最复杂的功能去试。只要描述足够清楚，在很多明确场景下，它给出的代码、测试和文档，已经足以让你重新认识现在公司的协作和沟通方式。

体感一次，胜过看十篇文章。

欢迎转发、讨论。也欢迎你把自己踩出来的经验告诉我。