授人以鱼不如授人以渔：我对企业级 AI 研发提效的思考与实践

原创 吴佐衍 2026-11-12 18:01 浙江

关于企业内部 AI 研发提效的、为什么选择做这些事，以及在业务域中实际效果如何，本文或许能够提供一些经验和参考

我在此前的 《从 Spec 驱动转向环境与验证驱动》 中提到过一个自己的经历：顺手买的一个交互实验需求，终端改码加本地验证，1 个小时就能完成；但要让它在线上生效，还涉及 O2、ZCache、一休、BUY2、Trade-Hub、奥创等多个平台的关联发布，又恰好遇上大促封网，从编码完成到上线，实际用了 3 周。

这 3 周里除去封网等待外，大量时间实际上消耗在跨平台查改配置、对齐上下游依赖与环境验证上。它和开篇提到的“人肉给 AI 打工”共同揭示了一个问题： 当局部编码越来越快，决定交付速度的瓶颈，会逐渐暴露在编码之外——如果获取信息与验证结果的方式没有变，整体交付效率依然很难提上去。

从研发提效的角度看，开发人员的日常工作包含需求沟通、编码、排查问题以及其他各类日常事务，编码只是其中的一个环节。但作为程序员，大家很容易把注意力放在自己最擅长的领域，而忽略了那些相对短板的地方。从木桶理论来看，综合效率的提升往往取决于最短的那块短板——就像谷爱凌说的，大家往往只看到她很努力，但选择方向更重要。因此，我们要做的是一个覆盖研发日常各主要场景的工作台，而不仅仅解决“标准需求编码”的逻辑。

同理，现在很多人把 AI Coding 的重心放在死磕“如何教 AI 写出更完美的技术方案”上，却依然让人去干查配置、搬日志、手点验证的跑腿活。但在人本身具备架构判断力的情况下，这样做并没有发挥出人机各自的比较优势，而是陷入了同质化竞争。一个团队里有各种各样互补的人才才是最强的。就像一支球队如果场上 11 个人全是前锋是赢不了球的，又或者像一台外科手术，主刀医生的核心价值在于关键判断与决策，哪怕他跑腿拿化验单的速度比助手还快，也不应该去和助手比拼跑腿。

首先我们不做 Coding Agent，因为现在模型公司与应用公司已经把通用 Coding Agent（代码理解、任务规划、工具调用、上下文管理等）做得足够好，而且仍在快速进步，我们只需要站在巨人的肩膀上就行。那我们应该做什么？不妨考虑这样一个问题：如果没有 AI，一个新人入职公司时我们会给他提供什么？我们能提供给他的东西基本是一样的：一个账号，让他可以访问各个内部平台；一台办公设备（电脑 + 显示器），让他能动手做事并验证结果；以及一个靠谱的团队与业务，让他了解目标与业务约束，并融入团队的日常沟通协作。多年之后，每个人依靠自己的主观能动性，在各自的团队和业务里做出成绩。

所谓“授人以鱼不如授人以渔”，对于通用编码与推理能力已经很强的 AI，我们需要做的也是相同的事情：给它配齐相关的账号、设备、团队知识与协同机制。内部平台连接相当于账号背后的系统访问能力，执行与调试环境相当于办公设备，团队沉淀的业务知识与历史经验相当于师兄带教，在此基础上再让它逐步融入组织的日常协同。这样随着模型能力的持续增强，我们在内部系统打通、可验证环境与业务知识上的投入，创造的价值也会越来越大。

要让 AI 进入我们的工作上下文，首先需要看： 作为工程师在公司内部完成一项工作时，日常能够接触和操作的工作上下文有哪些？

• 办公与知识协同 ：办公通讯在钉钉，协作文档在钉钉文档，企业内网与技术社区在 Work 和 ATA；

• 需求、代码与部署 ：需求管理在 Aone，代码托管与评审在 Code，构建与部署则分别在 O2（前端）、MTL（客户端）和 Aone（服务端）；

• 业务平台与配置实验 ：具体业务的搭建与承接在一休、奥创、VOID 等业务平台，实验分流在 AB 平台，配置与开关在 Switch、Diamond、Orange；

• 监控、日志与基础保障 ：线上监控与问题排查依赖 JSTracker（前端监控）、Sunfire（服务端监控）、魔兔（客户端监控）以及 SLS 日志，底层还离不开账号、权限与审批等系统。

因此，从表面上看，打通内部研发平台是在给 AI 增加工具；但从完成任务的角度看， 它实际上是在拉齐 AI 与人的工作上下文，让它的可见范围与可操作范围逐渐接近工程师完成同一项工作所需的范围。

当这些平台打通之后，AI 就不再局限于本地的代码目录，而是可以串联起完整的研发动作：直接从 Aone 需求空间或钉钉文档里读取需求文档与历史方案，从 Code 平台拉取对应的多端代码仓库并创建变更；完成编码之后，可以通过 O2、MTL、Aone 触发各端构建与部署，到一休、奥创、VOID 等业务平台及 Switch、AB 平台上完成配置与实验变更，再去 SLS、JSTracker、Sunfire 中查询运行日志与监控结果，甚至通过钉钉同步进展并发起评审。前一步获得的信息可以直接用于下一步判断，大幅减少人在不同系统之间搬运材料、重新解释背景的成本。

做完之后，AI 就可以像人一样操作内部平台。在这里有两个关键点：

• 需要做好关键操作的门禁措施，由人来确认，避免 AI 误操作带来的问题。

• 建立完整的评测体系确保平台的操作准确与可靠，避免出现“看起来可用，但实际上一点不好用”的情况 ——例如经常操作错误，或者读取到的平台数据不准确等。

关于这些内部平台自身的演进方向，我还想补充一个判断：企业内部有非常多的研发系统与研发平台， 从长期来看，这些平台自身 GUI（图形界面）的重要度会越来越低，慢慢会演化为服务化底座，通过 SDK、Skill 或者 MCP 对外提供服务 ，由上层工作台按需连接和调度。

有了上下文和工具，AI 能做的事情多了，但要让它持续推进任务，还需要回答另一个问题：它如何知道自己做得对不对？

在上一篇文章里，我们讨论过编程 Agent 为什么能够较早成熟。一个重要原因是，软件工程天然具备编译、测试与版本回滚机制，模型可以反复经历“修改—执行—读取报错—修正”的循环。进入企业研发后，我们同样需要把这条反馈链路延伸到真实业务环境中。

对于终端开发而言，研发过程强依赖真实的终端环境（例如浏览器、APP 等环境）：代码编译通过，并不意味着页面渲染正确；接口返回成功，也不代表端上的交互状态就一定对。对于 Web 浏览器环境，目前已经有比较成熟的方案（例如基于 Chrome CDP 等协议），AI 可以直接获取页面 DOM 结构、网络请求与控制台状态。但移动端的缺口尤其明显：对于 APP，虽然可以通过类似 Computer-Use 的方式去识别截图、模拟操作界面，但作为研发调试手段是远远不够的，因为仅靠外部界面操作无法获取详细的页面结构与 APP 内部状态信息。过去，这些结果需要工程师打开手机、操作页面、截取画面、读取日志，再转述给 AI。每一轮修正都依赖人工反馈，AI 的自主执行范围也就停在了这里。

为此，我们把移动端 APP 的截图、控件结构、点击滑动、网络请求、运行日志与 Mock，以及切账号、切环境（如日常、预发、线上环境切换）等能力一并开放给 Agent，让它能够直接操作真实环境，并根据结果继续排查。工程侧提供可操作、可观察的环境，模型则结合需求预期和当前运行证据，判断下一步应该查看什么、修改什么、如何验证。

另外，推进这件事还有一个绕不开的实际问题： 调试环境必须足够好拿、随手可用。 如果每次让 AI 调试验证，都得先装特定的安装包，等我环境折腾好，估计都够自己手动测好几回了。只有把调试能力提前预置好，结合云真机或即开即用的模拟器，让 AI 随时能低成本连上终端环境，这套反馈闭环才能在日常研发中高频转起来。

当这些都准备好了之后，AI 就可以像人一样调试开发，人机分工因此开始发生变化：人更多地负责目标、业务前提与体验判断，AI 承担修改、部署、操作和证据收集；人不再需要一步步盯着推执行，而是把精力放到关键节点的校准与验收上。

前两项建设主要解决了 AI 如何获取工作上下文、如何在真实环境中执行和验证。但当越来越多同学开始使用 AI，我们会发现：一个人用得越来越好，并不意味着整个团队会自然跟着变好。

• 少数人摸索出来的有效方法，如何在团队内快速复用？ 团队的能力分布往往呈金字塔结构，在某方面特别强的人总是少数。如果少数人蹚出来的最佳实践只留在个人的 Agent 会话、配置或静态文档里，其他同学仍然需要重新摸索。

• 分散在不同岗位手里的知识，如何汇集起来共用？ 一个业务域通常由产品、运营、服务端、前端、测试、设计等多个岗位共同参与：产品熟悉业务规则与人群口径，服务端了解供给链路，前端熟悉用户动线与体验，测试掌握异常场景与验收要求。大家围绕同一个业务目标工作，各自掌握的知识相互关联，却往往分散在不同的人、文档和工具（如各自的 Codex、Qoder、Cursor）中，无法形成合力。

怎么把分散在个人手里的知识与经验沉淀下来，变成全团队推进下一个事情时都能直接复用的公共上下文？ 为了解决这个问题，我们建设了 Team 的团队上下文管理：

第一步，构建业务域 Team，把全局上下文与实践经验组织起来。 一个 Team 既可以对应顺手买这样的具体业务小组，也可以对应性能优化、架构治理等横向专项小组。具体该往 Team 里放什么？不妨再次回到“新人入职”的视角：一位靠谱的师兄，实际上发挥着路由导航的作用——他会先帮新人摸清团队与业务，谁负责什么、需求在哪里、涉及哪些系统、代码分布在哪些仓库、遇到问题去哪里查；随着工作深入，还会告诉新人哪些规则必须遵守、哪些地方容易踩坑。

Team 承担的也是这样的职责。我们围绕具体业务域梳理出一张“全景导航图”，把开展工作所需的规则与经验以文档、Skill 等形式组织在里面，主要包括：

• 团队与研发入口 ：成员分工、Aone 需求空间、A/B 实验空间、数据口径与 A+ 空间、关联代码库、常用研发平台等，让 AI 知道一项工作涉及哪些人、系统与资料；

• 业务与架构全景 ：核心业务概念与规则、从供给到推荐再到消费的数据流转、C 端与 B 端用户动线、仓库组织方式、业务架构与技术架构等，让 AI 看清局部修改所在的完整链路；

• 工程规范与实践经验 ：实验配置要求、终端适配规范、常见踩坑点、历史决策及其适用条件等，让团队验证过的方法能直接复用到后续任务中。

知识建设的重点是梳理全景图与业务约束，易粗不易细，而不是把代码逻辑翻译成文档，因为 AI 自己就能直接读代码 。具体实现细节让它顺着导航去查代码即可，Team 重点维护单看局部代码看不出来的全局脉络与核心红线，避免把大量容易过期的代码细节堆成误导 AI 的负资产。

第二步，产研共用同一个工作台，在日常工作中直接使用 Team。 Team 建好之后，我们让同一业务域的产品、服务端、前端、测试等各岗位同学在同一个工作台里切入对应的 Team 开展工作。产研共用一个工作台，好处是不同岗位的上下文在日常干活时自然就打通了：产品补充的业务规则与统计口径，研发写代码时可以直接调取；研发梳理出的系统约束与实验规范，也能成为产品和测试后续评估与验收的依据。同时，工作台把前面打通的内部平台与验证环境也整合在一起， 底层执行 Agent 随时可以更换，而团队沉淀在 Team 里的业务知识、规则与经验则可以跨工具持续复用。

第三步，在日常迭代中持续更新 Team，把个人经验沉淀为团队资产。 业务和系统一直在变，Team 里的内容如果只靠集中整理，很快就会过时。因此我们把更新融进日常工作，形成两条回流路径：

• 由人在使用中发现问题并顺手提交更新 ：比如产品发现少了某个人群分层的定义、服务端发现供给链路说明已过时、前端发现终端适配漏了前提条件，直接在当前工作中提交修正，CR 合入后全团队马上就能用上；

• 由 AI 在需求结束后总结经验并发起 CR ：一个需求上线后，可以让 AI 回顾这次任务补充了哪些新知识、踩了哪些坑、形成了什么可复用的做法，整理后提交人工评审把关。这里尤其需要人来判断适用范围，避免把单次需求里的临时处理误当成全团队长期遵循的规则。

当通过前面三件事帮 AI 配齐了账号（内部系统打通）、设备（可验证环境）与团队知识（Team）之后，我们进一步在思考与探索的第四个方向是： 如何让这位“新人”融入组织的日常协同？

现在的 AI Agent 大多还是单向的“人指挥 AI”，当 AI 进入团队后，人与 AI、AI 与团队其他成员之间同样需要建立顺畅的协作关系。目前在这方面很明显的一个卡点： 异步交互链路往往是断的 。例如，我们可以让 AI 去咨询问题，但钉钉的消息回馈是断的；可以让 AI 发起一个 CR，但还需要我们去提醒它看看 CR 进展；AI 去申请权限，但申请是否通过又要我们去提醒它。当 AI 遇到困难时，能否直接找到对应的同学寻求帮助？大家能否直接在钉钉群里 @AI 让它去解决问题，或者在协同文档里 @AI 让它去做分析？它又能否作为 PM 协助进行项目推进管理？

这背后其实对应着人机协作模式的一次转变。一个人每天在线时间是有限的，而 AI 却可以 7x24 小时随时在线。一方面，让任务在人离开办公电脑后仍能继续推进，为此我们支持了云端与 Mac mini 多设备模式，白天在工位开启的任务，离开后可无缝移交到 Mac mini 或云端后台执行，人在手机端随时可查看或接续；另一方面，协作模式慢慢从“人盯着 AI”转向“ AI 在关键节点找人 ”。前面提到的等 CR、等权限审批、等消息回馈，很多通过定时器或事件回调就能自动接续，等到真正需要人做判断时再带着上下文通知人；而再往后的主动找人求助、群与文档内协同、项目推进，则更偏向于“个人管家”或“个人助理”的角色。

一旦进入这个阶段，最需要关注的核心问题就是： AI 要清楚知道哪些事情可以做，哪些事情不能做 。当 AI 代表个人或团队在组织里发消息、找人、响应群内呼唤时，必须有明确的身份标识、上下文路由与权限边界。比如别人呼叫它时，它可以回答事实问题、帮忙排查分析，但涉及代码变更、发布部署或排期承诺等有副作用的操作，必须回来找号主本人确认；同时在主动找人或跟进项目时也要克制打扰频率，避免给团队制造额外噪音。这部分边界与机制，我们目前也还在持续探索中。

把前面这些能力整合在一起，我们希望带来的使用体验就是“开箱即用”。举个不一定恰当的比喻：对于企业内部的研发场景，原生的 Cursor、Codex、Claude Code 就像配置很高的组装 Windows 电脑，基础能力很强，但每个人拿到手后，还需要自己装驱动、配软件、接内部系统，才能进入具体业务干活；而我们希望自己建设的研发工作台“三眼仔”像 MacBook 一样，把内部平台连接、终端验证环境与团队上下文预先整合好，减少每位同学开始工作前重复准备的成本。 落到每位同学身上，就是不用再重复折腾平台接入、环境配置和背景解释，打开工作台就能直接进入业务干活。

当团队成员开始一项工作时，只需要 选择对应的业务 Team （比如顺手买 Team），AI 就能利用已经配置好的平台入口、业务知识与验证环境，围绕需求沟通、编码实现、问题排查等场景推进工作：

• 查实验、排查问题与口径对齐 ：无论是日常查一个 A/B 实验、排查线上报警与数据异动，还是在需求沟通阶段核对业务现状，因为 Team 里已经配置好了空间映射与业务规则，AI 可以自动关联到对应的研发与监控平台，直接去读取一休上的实验配置、拉取线上数据或日志并分析原因；如果在这个过程中，PD（产品同学）发现某个统计口径、人群分层或对账规则需要调整，直接在工作台里提交对应上下文或 Skill 的更新，经 CR 确认合入后，后续研发和数科同学沟通与分析时就对齐到了最新口径。

• 从读需求、跨仓编码到真机自验证 ：当推进一个具体需求实现时，AI 可以自动关联钉钉文档或 Aone 读取需求内容，顺着 Team 里的架构与仓库地图找到对应的前后端代码仓库完成编码；写完代码后，AI 会根据 Team 里记录的 用户动线 ，自动打开真机并导航到目标业务场景，将页面资源 替换为本地开发地址 进行实时真机验证，还能根据测试需要 自主切换测试账号、自主部署预发环境 。

• 代码 CR 与团队经验持续回流 ：在功能验证通过、准备上线前，AI 可以发起代码 CR，并在收到评审意见后协助修复问题；而在整个过程中，如果发现某处上下文缺失或踩了新的坑，既可以 由人在过程中随时提交更新 ，也可以 在需求上线后由 AI 总结经验提交更新，统一经人工 CR 确认合入 Team ，让每一次需求迭代都沉淀为团队的公共经验。

从顺手买团队 2026 年 5 月至 9 月的交付记录看（对比首尾的 5 月与 9 月），需求从进入研发到上线的平均交付耗时由 16 天下降到 10 天。这些是团队同期的整体变化，也包含架构依赖治理与测试优化等工作的贡献，不能全部归因于 AI；但它们让我们开始从完整交付周期与工作范围的变化，观察 AI 在组织中的实际作用。

随着 AI 干活越来越快，一个想法很快就能变成原型，一份方案很快就能落到代码。过去受限于执行成本而无法尝试的事情，现在可以在短时间内反复探索。在这个过程中，Taste（品味与取舍）会变得越来越重要：选择解决什么问题、采用哪种方案、什么样的体验才算好，都需要人来拍板判断。

但对于组织来说，仅仅强调个人的 Taste 还不够， 如何让人具备判断力是更重要的事。因为一旦跨入自己陌生的领域，人其实很难判断 AI 做得对不对。

举个全栈的例子：一个前端同学借助 AI 去做后端需求，如果他完全不了解后端的业务架构与工程最佳实践， 即使 AI 给出的技术方案本身是对的，在实际的生产环节中，单靠他自己，这个需求也是无法上线的 。AI 拓宽了人活动的边界，却不会自动帮他补齐陌生领域的判断力。因此，组织提效需要同时推进两件事：让 AI 更有能力执行，也让人更有依据判断。具体来说，需要在三个层面上补齐人的判断力：

• 在实际业务场景里依然缺少不了“下苦功夫”，持续梳理整体的应用架构 。在 AI 时代，我们可以不了解所有的局部代码细节，但需要对整个系统的业务架构、技术架构、调用边界与工程最佳实践有清晰的宏观认知。只有脑子里有这张宏观地图，跨领域干活时才知道该看哪些关键点、如何评估生产风险。 换句话说，AI 时代对人的要求不是降低了，而是更高了。

• 把验证过程变成人能核对的客观证据 。人在陌生领域很难单靠看代码判断对错，但看真实环境的运行结果就直观得多。如果 AI 只回一句“已经修好了”，人根本没法放心；但如果它能同时附上修改原因、操作路径、日志与请求变化，以及真机跑出来的页面截图，核对起来就有了明确抓手。借助前面打通的研发平台与真机验证环境，把这些运行证据直接摆到台面上，能大幅降低跨领域验收的门槛。

• 把专家的判断过程显性化，并在跨领域关键节点保留组织校准 。值得沉淀进 Team 的内容，除了最终结论，还包括资深同学当时评估过哪些风险、依据什么做出的取舍，以及上线前必须核对哪些红线。同时，对于跨出熟悉领域的任务，在方案评审、核心 CR 与上线验收等关键节点保留领域专家的校准，让工作范围的扩展与个人判断能力的成长相互配合。

AI 越快，错误方向被放大的速度也越快 。Taste 帮我们选对要做的事，全局架构认知与客观验证证据帮我们把准结果对不对；而团队要做的，就是把这些判断标准沉淀下来、传承下去。只有人的判断力跟上了，AI 带来的执行提速，才能稳稳转化为团队最终的交付质量与交付效率。

回看这段实践，AI 重塑软件研发已经是大势所趋。雷军曾说“风口来了，猪都能飞起来”，面对这场技术浪潮，我就期望自己和团队能成为风口中的那只猪。但这里恰恰有一个最关键的判断： 如何让自己真正站在风口上？ 因为很多时候，最怕的是“不知道自己不知道”——明明做的事情还在旧流程、旧入口里打转，或者还在替模型补那些很快会被下一代模型内化淘汰的短板，却以为自己已经站在风口上了。

要跳出这种盲区，其实只需要问自己一个问题： 当下一代更强的模型发布时，我们今天做的事情，是会被它淘汰，还是会让它发挥出更大的威力？ 对于业务团队来说，我们无法决定下一代模型会在什么时候跨过新的临界点，但可以把承接这些能力的底座先建好——这也是我们不做通用 Coding Agent，而是选择做企业级 AI 工作台“三眼仔”的原因。

所谓“授人以鱼不如授人以渔”：像对待一位新同事一样，为 AI 打通内部研发平台（账号）、提供可验证的终端调试环境（设备）、沉淀业务域的 Team 全景图（团队），并让它逐步融入组织的双向协同网络；与此同时，也倒逼团队里的每一位同学下苦功夫梳理宏观应用架构、提升跨领域的判断力。我们还在这个探索过程中，但至少目前的实践让我更加相信：当底层模型每进步一分，这套工作环境与团队的判断力就能把红利放大一分——这或许就是让自己真正站在风口上的方式。

跳转微信打开