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

这是2026年的第 80 篇文章

（ 本文阅读时间：约 20 分钟 ）

导读

随着 Cursor、Claude Code、Codex 等 AI 工具深入团队日常研发，许多工程师陷入了“人肉给 AI 打工”的困境：AI 无法读取内网文档、不能自动验证代码、需人工粘贴日志。此外，个人使用 AI 的效率提升难以转化为团队整体效能，且缺乏对 AI 产出质量的可靠判断机制。

本文基于《跨越临界点》与《从 Spec 驱动转向环境与验证驱动》的演进逻辑，探讨如何通过构建企业级 AI 研发工作台，将个人经验转化为团队资产，实现从局部编码提速到整体交付提效的跨越。

在实际研发场景中，局部编码往往只需数小时，但涉及多平台关联发布、跨系统查改配置及环境验证时，交付周期可能长达数周。这揭示了一个核心问题：当局部编码效率提升后，决定整体交付速度的瓶颈已转移至编码之外的信息获取与结果验证环节。

根据木桶理论，综合效率取决于最短的短板。若仅聚焦于优化编码环节，而让工程师继续承担查配置、搬日志、手动验证等“跑腿”工作，并未充分发挥人机各自的比较优势。理想的分工应是：AI 承担执行与数据搬运，人类工程师专注于关键判断与决策，如同外科医生不应与助手比拼跑腿速度。

鉴于通用 Coding Agent 在代码理解、任务规划等方面已趋于成熟，企业内部无需重复造轮子，而应借鉴“新人入职”的培养模式，为 AI 配齐必要的“账号、设备与团队知识”：

• 内部平台连接（账号）：赋予 AI 访问内部系统的权限；
• 执行与调试环境（设备）：提供可动手做事并验证结果的环境；
• 团队沉淀知识（师兄带教）：注入业务知识、历史经验与协同机制。

通过夯实这些基础底座，随着模型能力的增强，企业在系统打通、可验证环境与业务知识上的投入将产生复利效应。

工程师的工作上下文涵盖办公协同、需求代码部署、业务平台配置及监控日志等多个维度。打通内部研发平台不仅是增加工具，更是拉齐 AI 与人的工作上下文，使其可见与可操作范围接近人类工程师。

平台打通后，AI 可串联完整研发动作：从 Aone 或钉钉文档读取需求，从 Code 拉取代码，通过 O2/MTL/Aone 触发构建部署，在一休/奥创等平台完成配置，并在 SLS/JSTracker 中查询日志，最后通过钉钉同步进展。这一过程大幅减少了人在系统间搬运材料和解释背景的成本。

在此过程中需注意两点：

• 设立操作门禁：关键操作需由人确认，防止 AI 误操作；
• 建立评测体系：确保平台操作准确可靠，避免数据读取错误或执行偏差。

长期来看，企业内部研发平台的 GUI 重要性将降低，逐渐演化为通过 SDK、Skill 或 MCP 对外提供服务的服务化底座，由上层工作台按需调度。

要让 AI 持续推进任务，必须解决“如何知道做得对不对”的问题。对于终端开发，仅靠代码编译通过不足以验证页面渲染与交互状态。目前 Web 端已有较成熟方案，但移动端存在明显缺口。

为此，需将移动端 APP 的截图、控件结构、操作模拟、网络请求、日志及环境切换等能力开放给 Agent，使其能直接操作真实环境并获取反馈。同时，调试环境必须足够易用且随手可得，如结合云真机或即开即用的模拟器，降低 AI 调试验证的门槛，形成高频反馈闭环。

此时的人机分工转变为：人负责目标设定、业务前提与体验判断，AI 承担修改、部署、操作和证据收集。人从逐步盯着执行转变为在关键节点进行校准与验收。

为解决个人最佳实践难以复用、跨岗位知识分散的问题，需建设 Team 团队上下文管理，将个人经验转化为团队公共资产。

第一步：构建业务域 Team，组织全局上下文

Team 类似“靠谱师兄”，为 AI 提供全景导航图，主要包含：

• 团队与研发入口：成员分工、需求空间、代码库及常用平台；
• 业务与架构全景：核心规则、数据流转、用户动线及架构关系；
• 工程规范与实践经验：配置要求、适配规范及历史踩坑点。

重点在于梳理宏观脉络与核心红线，而非翻译代码细节，避免积累误导性负资产。

第二步：产研共用工作台，打通岗位上下文

让产品、研发、测试等在同一个工作台切入对应 Team 工作。不同岗位的上下文自然打通，底层执行 Agent 可更换，但沉淀在 Team 中的知识与规则可跨工具持续复用。

第三步：日常迭代中持续更新 Team

建立两条知识回流路径：

• 人工提交更新：在使用过程中发现缺失或过时内容，直接提交修正；
• AI 总结发起 CR：需求结束后，AI 回顾任务总结新知识或踩坑点，经人工评审把关后合入。

当前 AI 协作的主要卡点是异步交互链路断裂。未来协作模式将从“人盯着 AI”转向“AI 在关键节点找人”。支持云端与多设备无缝移交，利用定时器或事件回调自动接续任务，仅在需要人做判断时通知。AI 将扮演“个人助理”角色，参与群聊协同与项目推进。

此阶段的核心在于明确AI 的行为边界：涉及代码变更、发布部署等有副作用的操作需本人确认；主动找人时需克制频率，避免制造噪音。需建立明确的身份标识、上下文路由与权限边界。

企业级 AI 工作台“三眼仔”旨在提供“开箱即用”的体验，预整合内部平台、验证环境与团队上下文。以顺手买团队为例，AI 依托 Team 配置可实现：

• 查实验、排查问题与口径对齐：自动关联研发与监控平台，读取实验配置与日志，同步最新业务口径；
• 从读需求到真机自验证：自动读取需求，定位代码仓库，依据用户动线进行真机验证，自主切换账号与环境；
• 代码 CR 与经验回流：发起 CR 并修复问题，将新产生的上下文或踩坑经验经人工确认后合入 Team。

数据显示，该团队需求平均交付耗时从 16 天下降至 10 天。虽然包含其他因素贡献，但这反映了 AI 在完整交付周期中的积极作用。

AI 提升了执行速度，但也放大了错误方向的风险。Taste（品味与取舍）变得至关重要。为让人具备跨领域的判断力，需在三个层面补齐：

• 梳理宏观应用架构：无需了解所有代码细节，但需清晰认知系统架构、调用边界与最佳实践，以便评估生产风险；
• 提供客观验证证据：AI 需提供修改原因、操作路径、日志变化及真机截图，降低跨领域验收门槛；
• 显性化专家判断过程：沉淀风险评估与取舍依据，并在关键节点保留领域专家校准。

只有人的判断力跟上 AI 的执行提速，才能确保最终的交付质量与效率。

面对 AI 重塑软件研发的浪潮，关键在于避免“不知道自己不知道”的盲区。检验标准是：当下一代更强模型发布时，我们今天做的事是被淘汰，还是能发挥更大威力？

业务团队应专注于建好承接模型能力的底座——打通内部平台、提供可验证环境、沉淀 Team 全景图，并提升团队的宏观架构认知与判断力。这样，底层模型的每一次进步，都能通过这套工作环境与团队能力被放大，从而真正站在风口之上。

欢迎留言一起参与讨论~