我所在的公司不是没有在谈 AI，而是一直停留在“口头上全面接入”，却没有真正进入团队级工作流。
从 ChatGPT 到 Cursor、Claude Code，再到各种 Agent、自动化平台，这两年公司内部也一直在谈“接入 AI”“全面使用 AI”“把 AI 用到需求、开发和部署里”。但如果把视角拉回我所在的研发现场，就会发现一个很直接的问题：
- 有人自己偷偷用 AI 写代码
- 有人用 AI 查问题、补测试、写说明
- 有些部门已经主动把账号、报销和工具都配起来了
- 但我们研发部门整体的交付方式，并没有因为 AI 发生本质变化
换句话说，AI 工具有人在用，但 AI 工作流并没有在我们部门真正推行起来。
这两者差别很大。
前者是个人能力增强，后者是部门生产方式变化。真正难的，恰恰不是“把 AI 打开”，而是让 AI 进入正式流程，并稳定地产生价值。
一、我所在的公司，为什么推不动 AI 工作流？
1. 把 AI 当工具采购，而不是流程改造
至少从我所在公司的情况来看，对 AI 的理解还停留在：
- 买几个账号
- 给员工装上插件
- 开一次内部分享会
- 然后宣布“以后大家多用 AI”
这种方式本质上和“给大家发一把新锤子”没区别。
问题在于，工作流不是靠口号形成的，而是靠约束、输入、产出和责任边界形成的。
如果没有明确这些问题：
- 什么环节可以引入 AI
- 谁来提供上下文
- AI 生成结果由谁审核
- 哪些产出可以直接进入下一环节
- 出了问题谁负责回溯
那 AI 最终就只会变成“个别人偷偷提效”的工具，而不是部门能力。
2. 流程本身就是乱的
这一点其实最关键。
而我所在的研发部门，在没有 AI 的时候，流程本身就已经不清晰了：
- 需求文档不完整
- 原型和说明对不上
- 接口文档长期失真
- 测试反馈没有复现路径
- 发布流程靠口口相传
- 项目背景、目录、环境变量没人说得清
在这种前提下，让 AI 接手工作，其实就像让一个新同事在没有交接文档的情况下，直接接盘线上项目。
人都很难干明白，AI 更不可能稳定干明白。
很多人总觉得是 AI 不够聪明，但很多时候，问题并不是智能不够，而是输入太烂。
3. 管理层想要结果，但不愿补基础设施
AI 工作流要真正落地，背后需要很多“看起来不性感”的基础工作：
- 统一代码仓库规范
- 建立文档沉淀机制
- 明确环境和发布链路
- 给需求、测试、开发建立标准输入格式
- 定义评审和回滚机制
这些东西做起来不炫，也不能立刻拿去汇报“AI 提效 300%”。但如果不做，所谓 AI 推行通常就会停留在表层。
这背后最典型的管理心态是：
想直接享受 AI 带来的效率红利，却不愿补上让 AI 发挥作用的工程底座。
这当然推不起来。
4. 领导层把“接入 AI”当成一句行政口号
在我所在的公司里，更常见、也更让人无力的一种情况是，领导在内部会议上已经明确提出要“全面接入 AI”，但真正往下拆时，却只剩下传话。
按理说，这种级别的决策一旦被提出来，后面至少应该跟着这些动作：
- 明确接入目标
- 评估现有流程的卡点
- 给出试点范围
- 选择工具和预算方案
- 安排技术支持和培训计划
但现实里，经常变成了另一种样子：
- 技术总监、项目总监只是转述“公司要求用 AI”
- 不输出实施方案，也不定义优先级
- 不分析哪个环节适合先接、哪个环节风险高
- 不建立规范，只把压力继续往下传
这时候所谓“全面接入 AI”，本质上不是决策落地，而只是一次管理口号下发。
更讽刺的是，公司里别的部门已经主动行动起来了。
比如产品部门已经在为成员开通 Claude Code 账号，先让团队用起来，再走公司报销；而研发这边，领导还停留在“你们要多用 AI”“要跟上趋势”这种口头指示上，没有预算动作，没有工具清单，也没有统一支持。
看起来是在推动，实际上只是把“要用 AI”四个字当成了表态。
5. 把调研和试错成本，直接甩给一线开发
在我们这边，还有一种很典型的做法，是领导不提供方案，只让个别开发自己去找 AI 路线。
表面上看，这像是在“鼓励探索”；实际上往往意味着：
- 没有人负责正式调研
- 没有人评估工具差异和适用边界
- 没有人沉淀部门共识
- 最终所有试错成本都压在一线开发身上
于是你会看到一些很空洞的动作：
- 找几个人自己试
Kiro - 再试
Trae - 再试
Cursor - 甚至连
VS Code的各种 AI 插件也一起摸一遍
最后开一个简单培训会，大家签到，演示一下怎么注册账号、怎么领额度、怎么通过聊天生成一个前端页面，好像这就叫“部门已经在推进 AI”了。
但这种培训几乎没有技术含量，也没有实际使用价值，因为它回避了最关键的问题：
- 现有项目怎么接
- 哪类需求适合 AI 参与
- 代码 review 怎么做
- 权限边界怎么设
- 部署链路怎么衔接
- 出问题后谁来兜底
如果这些问题都不回答，只演示“聊天生成页面”，那充其量只是工具试玩，不是工作流建设。
6. 张口就要全流程接入，却不分析现实阻力
有些领导最典型的问题，不是不会用工具，而是完全没有决策者应有的分析能力。
他们会直接提出：
- 需求分析要用 AI
- 写代码要用 AI
- 测试要用 AI
- 部署也要用 AI
听起来非常完整，像是有战略、有方向，但只要往下追问一步就会发现，根本没有做过任何落地分析。
比如最基本的这些问题：
- 当前项目文档是否足够支持 AI 理解上下文
- 代码仓库、权限体系、部署流程是否适合接入 Agent
- 需求和测试输入是否已经结构化
- 哪些业务高风险，不能直接让 AI 深度参与
- 团队成员之间的 AI 使用水平是否存在明显差异
这些都不分析，就要求“项目里必须用上 AI”，本质上和随口说一句“以后大家都提高效率”没有区别。
决策者真正该做的，不是喊出一个正确的方向，而是把这个方向拆成能执行的方案。只负责喊口号，不负责识别难点、拆解路径、配置资源，那就不是推行，只是甩锅。
二、在我这里，AI 工作流具体卡在什么地方？
1. 输入不标准
这点在我现在的工作里特别明显。
比如一个需求，如果只是：
这个页面改一下，参考之前那个活动页，再把支付那块顺一下。
那无论给人还是给 AI，都属于“靠猜”。区别只是，人还能靠经验、靠追问、靠上下文关系勉强补齐；而 AI 更容易出现“看起来写了很多，其实没打中重点”的情况。
如果我所在的部门真想让 AI 进入需求分析、开发、测试、发布这些环节，就必须逐步把输入标准化，比如：
- 需求目标是什么
- 改动范围是什么
- 不改什么
- 依赖哪些接口/模块
- 验收标准是什么
- 风险点在哪里
没有这些，AI 就只能在模糊空间里自由发挥。
而我现在遇到的问题是，很多需求本身就没有被整理成这种输入。图是旧的，说明是散的，变更是口头加的，最后开发只能靠自己猜，AI 也只能跟着一起猜。
2. 上下文不集中
我越来越觉得，AI 最怕的不是任务复杂，而是信息散落。
而我这边的很多项目，刚好就是这种状态：
- 产品在 Figma 里说一半
- 需求在聊天记录里说一半
- 技术约束在会议里说一半
- 历史坑点藏在某个人脑子里
最后执行的人，得自己把碎片拼起来。
这时候让 AI 参与，常常不是提升效率，而是额外增加“喂上下文”的成本。
所以 AI 工作流的本质要求之一，是把上下文沉淀成可被检索、可被引用、可被复用的资产，而不是继续依赖“问人”。
但我现在的实际感受是，很多时候连人都得四处去问，才能把一个事情拼完整。在这种环境里，AI 不是不能用，而是很难稳定用。
3. 没有审核闭环
AI 可以生成内容，但生成不等于可交付。
无论是代码、测试用例、文档，还是运营文案，真正让 AI 进入正式流程，必须有一层审核闭环：
- 谁审核
- 审核什么
- 审核不通过如何回退
- 哪些问题可以自动修正
- 哪些问题必须人工拍板
如果没有这层闭环，就会出现两种极端：
- 要么大家不敢用，因为怕出事
- 要么大家乱用，因为觉得“反正 AI 写的”
这两种都不是工作流。
tip：我这边客户端相关的内容就经常出问题，而有个同事给出的回复也很直接：“这是 AI 写的。”
这句话听起来像解释，实际上什么都没解释。因为真正的问题不在于“是不是 AI 写的”，而在于写出来之后有没有人检查、出了问题谁来负责、后面怎么修正。
4. 权限和责任没设计好
这也是我所在部门现在明显缺失的一点。
但放到我现在的工作环境里，这个问题甚至不是“边界画得不清”，而是很多基础前提都不存在。
比如我们现在用的是 SVN，没有像 Git 那样清晰的分支隔离，也没有稳定的暂存、提交、回滚这一套工作方式。这样一来，AI 一旦给出不合理的方案，或者改坏了一部分代码，撤回就会变得非常麻烦。
正常一点的研发流程里，至少还能做到：
- 先在隔离环境里试
- 不合适就回退到上一个提交
- 确认没问题再进入后续流程
但在我们这里，很多时候根本没有这种缓冲区。
- 改动就在当前副本里堆着
- 功能之间没有良好的隔离
- AI 改坏了，想撤回也不干净
- 一旦夹杂了别的需求，更难判断该撤哪一段
这时候“让 AI 帮忙写代码”听起来很轻松，实际上一旦出问题，收拾残局的成本非常高。
部署链路也一样，并不是那种清晰、自动化、可回滚的流程。
- 测试环境要走堡垒机
- 灰度环境很多时候还是手动打包
- 打完包后，还要把文件分别扔到不同的
SVN目录里 - 静态资源、页面文件、不同项目目录之间的关系又乱又杂
在这种情况下，所谓“让 AI 参与部署”或者“让 AI 直接接入工作流”，根本不是一句话的事。因为问题不是 AI 会不会写命令，而是我们连一条清晰、可追踪、可回退的部署链路都没有。
所以在我看来，这里的“权限和责任没设计好”，本质上就是：
- AI 可以改，但谁来兜底不清楚
- AI 可以生成，但出了问题怎么撤不清楚
- AI 可以参与部署，但部署链路本身就是混乱的
如果这些基础条件不先理顺，AI 进来以后不会让流程更顺，只会让混乱更快扩散。
三、真正能落地的 AI 工作流，通常长什么样？
基于我现在看到的情况，我越来越倾向于认为，适合我们这种部门的不是“全自动 AI 团队”，而是半自动、强约束、可追溯的工作流。
大致会更像这样：
1. 需求阶段：AI 做整理，不做拍板
- 产品提供结构化需求输入
- AI 负责整理背景、补充风险清单、输出初版任务拆分
- 负责人审核任务边界和优先级
AI 在这里更适合做“整理器”和“放大镜”，而不是代替业务负责人做决策。
2. 开发阶段：在我现在的环境里，AI 更适合做局部辅助
如果按我现在接触到的项目现状来说，AI 在开发阶段并不适合一上来就大段改代码、接管复杂需求，更适合做一些局部辅助性的事情，比如：
- 帮我解释一段老代码
- 先产出一个小功能的初版
- 补一个工具函数或简单页面
- 帮我梳理某个报错的大致排查方向
原因很现实，不是我不想让它多做，而是项目本身不具备让它稳定发挥的条件：
- 项目背景和目录经常不清楚
- 需求上下文分散
- 很多约束藏在口头沟通里
- 代码管理又缺少良好的隔离和回退能力
所以在我们这种环境里，AI 如果直接大面积介入开发，很容易出现一种情况：它写得很快，但你收尾更慢。
3. 测试阶段：AI 可以帮补东西，但替代不了真实验收
测试这块也是一样。
理论上，AI 确实可以补一些东西：
- 根据需求整理测试点
- 帮忙生成回归清单
- 协助梳理 bug 复现路径
但问题在于，我现在遇到的测试反馈，本身就经常不规范。如果输入是模糊的，比如只说“这里不对”“按钮点不动”“页面没数据”，那 AI 能帮上的也很有限。
它可以把一个清晰的问题整理得更完整，但没法凭空替代测试去确认业务预期，也没法替代人去把一个说不清的问题变成标准输入。
所以在我们这里，测试阶段真正缺的，可能还不是 AI，而是最基本的复现、记录和反馈规范。
4. 发布阶段：先别谈让 AI 接管，先把链路理顺
在发布这件事上，我觉得最不现实的说法，就是一上来就谈“让 AI 参与部署”。
因为对我现在的工作环境来说，问题根本不是 AI 会不会部署，而是部署流程本身就不干净：
- 测试环境要走堡垒机
- 灰度环境依赖手动打包
- 打包完还要分别扔到不同的
SVN目录 - 不同项目、不同页面、不同静态资源目录之间关系复杂
在这种前提下，让 AI 参与发布，很容易从“提高效率”变成“加速出错”。
所以如果真要说一个现实路线，那我反而觉得，发布阶段最先该让 AI 做的，不是直接执行部署，而是：
- 帮忙整理变更说明
- 帮忙梳理部署步骤
- 帮忙检查有没有遗漏的文件或路径
先做辅助，别急着接管。
这是我现在更认同的路线。
不是完全不让 AI 动手，而是先承认我们当前的基础条件有限，再决定它到底能动到哪一步。
四、如果我所在的部门现在真想推行 AI 工作流，应该先做什么？
我觉得顺序不能反。
不是先问“我们要接哪个模型”，而是先问“我们现在的流程，哪里已经标准化到可以接 AI 了”。
如果非要给一个现实一点的推进路径，我会更建议按下面的顺序来：
1. 先统一输入格式
优先统一三类东西：
- 需求模板
- Bug 反馈模板
- 发布说明模板
当输入稳定了，AI 的可用性才会明显提升。
2. 再沉淀项目上下文
至少要做到：
- 项目说明可查
- 目录和启动方式可查
- 环境变量和部署流程可查
- 常见问题和历史坑点可查
这一步不是为了“知识管理”好看，而是为了降低 AI 和新同事的理解成本。
3. 选择一个低风险环节试点
不要一上来就喊“AI 全流程接管”。
更合适的是从低风险、可验证的环节开始，比如：
- 自动整理需求摘要
- 自动生成测试点
- 自动生成发布说明
- 自动做代码解释和重构建议
这些地方一旦跑顺了，再逐步往核心链路推进。
4. 最后再谈组织级推广
当试点环节已经能稳定产出后，再去制定：
- 团队统一规则
- 工具权限边界
- review 要求
- 数据安全要求
- 效率评估方式
这时候推行才是“成体系”的，而不是一阵风。
五、结语
很多人一提到 AI 工作流，就容易想象成一种非常激进的画面：
- AI 自动读需求
- AI 自动写代码
- AI 自动测试
- AI 自动上线
但真实世界不是 demo。
就我所在公司的情况来说，真正难的地方，不是让 AI 做出一个看起来厉害的样品，而是让它在真实部门、真实项目、真实约束里，持续、稳定、可控地工作。
所以我现在越来越觉得，AI 工作流的推行，先是我所在公司内部的管理问题，往外看，才是组织协作升级的问题。
如果文档是散的，流程是乱的，职责是虚的，权限是不清的，那 AI 只会把这些问题更快地放大出来。
我这篇文章是从自己公司的现场写起的，但说到底，这也不只是我一个公司的问题。很多行业、很多公司，只要管理层把 AI 当口号，把试错成本甩给执行层，把流程问题假装成工具问题，最后都会走到同一个结果上：AI 一直在被谈论，却始终没有真正进入生产流程。
反过来说，不管是互联网、传统行业，还是正在追热点接入 AI 的团队，只要本来就有清晰的输入、明确的边界、稳定的流程和可追溯的机制，AI 才会真正从“玩具”变成“生产力”。
