腾讯云架构师同盟·上海 AI工具箱的真实使用图鉴

沙龙回顾

腾讯云架构师同盟·上海 AI工具箱的真实使用图鉴

活动：「走进自然，交换AI工具箱」腾讯云架构师城市沙龙·上海 日期：2026年5月30日

5月30日早上8点，一群架构师从腾讯滨江大厦出发，乘坐大巴车去了共青公园。徒步沿途花正盛，有人在拍照，有人在聊昨天刚踩的AI坑。中午集体烧烤，下午分组讨论——一天的节奏是先放空，再碰撞。

这是腾讯云架构师同盟上海沙龙的日常：不谈概念，只谈实战。下午的分组讨论聚焦一个话题——AI工具在开发与办公场景中，真正用起来是什么状态？哪些地方提了效，哪些地方还在踩坑？

两组讨论下来，最让人意外的不是AI能做什么，而是AI太听话这件事本身成了最大的问题。

🔧 工具箱里有什么

先说工具。两组讨论都从"你日常在用什么"开始，很快拼出了一张当前AI工具的使用全景。

💻 开发场景

主流工具集中在几个方向：代码编写用 Codex、Cloud Code、Code Gravity、CodeArts；团队内部也有定制化工具，比如 Nature IM。架构设计方面，开发人员会通过与AI对话输出结构化语言描述，再转换为架构图，大幅减少手工绘图的工作量。

📝 办公场景

豆包、Kimi、元宝是高频选择。其中元宝的录音转写功能和千问的语音输入法被特别提到——不是最酷的功能，但确实最实用。

🤖 自研工具

有团队内部开发了名为"贾维斯"的AI分析工具，专门用于分析生产环境的告警和错误日志。其他自研产品还包括智能对账、智能测速、智能接入——都是针对重复性高、规则明确的任务开发专用工具。

⚠️ 值得注意的边界感 非技术岗位也在用AI——项目管理、运维、行政主要将AI用于文字类工作。但航空等强监管行业明确表示，AI仅用于边缘场景，核心生产系统因安全与合规要求，严禁使用AI。

工具在快速丰富，但两组讨论都不约而同地转向了同一个问题：工具多了，怎么用才不出事？

🛑 Plan模式：给AI加一道刹车

两组讨论中，"Plan模式"被反复提及，几乎成了避坑的第一条共识。

核心思路：两步走

先让AI进入Plan模式——只能读取代码库、分析现有结构、规划修改步骤，不做任何改动；确认方案后，再切换到执行模式，AI按计划修改代码。先想再做，而不是先做再改。

讨论中有人提到，部分团队尝试将代码审核也交由AI自动确认——一键"yes"执行。这种做法确实快，但风险同样明显：AI可能因理解指令不完整或误改历史遗留逻辑而做出错误修改，而一键确认让这些错误畅通无阻地进入代码库。

🧭 三种模式，对应不同场景

关键在于选对模式：在安全边际内大胆跑，在核心系统上谨慎走

Google工程师的实践指南也验证了类似原则：规格先行 + 分块迭代。先写清规格文档，再把任务拆成小于50行的代码块逐步推进。据其团队日常开发的实践数据，这种方法可将代码一次通过率从40%提升到75%，bug率降低70%。

讨论中还提到一个更深层的观察：采用"Agent + Skill"模式构建系统的团队，每个成员独立负责从需求到实现的全流程，高度依赖AI，但缺乏顶层架构设计，存在模块割裂风险。Plan模式解决的是单次交互的可靠性，但整个系统的架构协调，仍然需要人的判断。

Plan模式的本质，是给AI加一道"刹车"。 不是不让AI跑，而是在该停的时候能停得住。

🧠 上下文管理：200万token为什么只敢用70%

讨论中有一个细节让不少人意外：即使使用支持200万token的模型（如元宝4.7），实际推荐只使用70%的上下文——大约140万token。超过这个阈值，推理质量会明显下降，用现场的话说，"智商降低"。

窗口越大不应该越聪明吗？实际情况是，上下文窗口的扩大带来了新的问题，可以归纳为四种陷阱：

☠️ 上下文中毒

AI产生错误后反复引用该错误。错误信息被写入上下文，形成"毒源"，后续推理持续被污染。

😵 上下文分心

AI过度关注上下文中的信息，反而忽略了自己训练时已掌握的知识。信息过载导致注意力稀释，就像一个人面前摊了太多资料，反而找不到重点。

🌀 上下文混乱

AI分不清有用与无用的信息，胡乱调用。工具和文档缺乏筛选，什么都往上下文里塞，AI就在噪音中迷失。

⚡ 上下文冲突

前后信息矛盾，AI"精神分裂"。早期错误答案残留在上下文中，与后续正确信息冲突，导致输出前后不一致。

讨论中也有人提到，用户需要手动压缩对话内容并存入文档，避免自动压缩丢失关键信息。这本身就是上下文管理困难的体现——连"该保留什么"都需要人来判断。

💡 针对这些陷阱，实践中形成了三种管理策略：

按需筛选：只提供当前任务所需的关键信息，避免一次性塞入所有资料。不是知道得越多越好，而是知道得越精准越好。

阶段压缩：每完成一个阶段做小结，将有效结论压缩为摘要，剔除试错过程。把"怎么走到这一步的"删掉，只保留"结论是什么"。

流程隔离：将长流程任务（查API文档、分析报错）与主推理流程隔离，防止副产品干扰主线。查资料是查资料，写代码是写代码，不要混在一个上下文里。

Anthropic为Claude Managed Agent推出的"Dreaming（做梦）"功能，正是为了解决上下文的"记忆退化"问题——让Agent在任务间隙沉淀经验，而不是每次会话都从零开始。这从另一个角度说明，上下文管理不仅是"控制输入"，还包括"沉淀输出"。

200万token的窗口是能力， 但怎么用这200万，是方法。

📚 知识沉淀：企业AI落地的真正瓶颈

讨论中有一个共识：个人知识库版本混乱，团队级知识库更新机制缺失。这个问题看似是工具层面的，实则指向企业AI落地更深层的困境。

🔴 核心矛盾：上下文悖论

AI很擅长写代码、解数学题、生成创意内容，但很难理解企业特定的业务上下文和行业专业知识的细微差别。比如航空通信场景——通用大模型缺乏该领域的训练数据，无法理解排班规则背后的安全约束，给出的方案看似合理实则暗藏风险。而人类最擅长的恰恰是把事情放在正确的上下文中理解。

AI能力在通用领域突飞猛进，但在企业场景中，它最缺的不是算力，而是上下文。

这解释了一个尴尬的现实：企业AI投资巨大，但ROI难以兑现。Forbes的研究显示，只有25%的企业真正从AI中获得了价值。

问题往往不在模型，而在知识不可用。

大量企业积累了海量数据，但内容长期分散在OA、ERP、CRM等系统中，形成"知识孤岛"。更关键的是，大量隐性知识——"2025年后北美交易查A系统"这类业务规则——存在于老员工的经验中，从未被数字化。AI拿不到这些知识，就无法做出正确判断。

🏗️ 正在形成的解法：构建"上下文层"（Context OS）

业务规则标准化

明确指标计算逻辑与时间范围 → 统一口径，消除理解歧义

数据源映射

标注各系统权威性与数据归属 → 确保AI查到准确、最新数据

隐性知识显性化

将散落的配置规则、经验逻辑录入系统 → 补全AI决策所需上下文

知识质量 > 模型能力—— 这一判断正在获得越来越多从业者的认同。 模型可以换，但知识沉淀是长期工程。

⚖️ 责任归属与黑箱风险

"只要出问题就是你的问题。"

讨论中这句话被反复提及，道出了当前AI在企业落地中最尴尬的处境。AI能提效，但最终的责任永远落在人身上。这不是技术问题，而是组织问题：AI没有法律主体地位，不能签字、不能担责、不能在事故报告上署名。

深层矛盾

越依赖AI，人的审查负担越重。一键"yes"执行看似高效，但如果没有充分的代码审查能力，AI的错误修改会畅通无阻地溜进生产环境。"黑箱风险"正是这个问题的体现——AI生成的方案可能隐藏未知"坑点"，初级工程师因未经历踩坑过程，难以识别潜在问题。

换句话说，AI降低了写代码的门槛，但没有降低审查代码的门槛。甚至可以说，AI让审查变得更难了——因为审查者不仅要理解代码逻辑，还要判断哪些部分是AI生成的、其中可能隐藏什么问题。

🛡️ 实践层面的几条建议：

核心系统必须人工审核，AI辅助但不替代决策。该人看的不能省。

对初级工程师，建议使用Agent模式（每步确认）而非YOLO模式。经验不足时，慢就是快。

建立项目级Prompt配置（如.cursorrules），确保AI输出风格一致、约束明确。把团队规范写进AI的"行为手册"。

AI提效但不能担责，这不是一个会随技术进步而消失的矛盾。 它需要的是组织层面的回答： 谁来审、怎么审、审什么。

🔄 协同范式的未竟之问

讨论中有一个观察值得深想：多数团队仍沿用传统的"Spec → 开发"模式，AI仅作为提效工具嵌入旧流程，未催生新的协作范式。

AI在提效，但协作方式没变—— 速度是快了，流程还是那个流程。

📅 腾讯云架构师同盟的持续探讨：

2025年12月

讨论AI Coding标准提案，试图为AI编程建立规范框架

2026年1月

聚焦SDD（Spec-Driven Development，以可执行的规范说明为中心的开发范式），试图把"意图和规则"结构化，让AI在明确的边界内完成实现

2026年3月

探讨"LLM下的编程范式"，提出"软件将死，智件已来"——传统软件生态将在AI时代演化为新形态"智件"

SDD的核心思路是：不是让AI自由发挥，而是通过结构化规约把"意图和规则"说清楚，让AI完成"具体实现"。这与Plan模式的理念一脉相承——可控而非自动，才是AI编程的真正价值。

今天的讨论中，"Grill"类技能工具也被提及：通过AI对文档或设计进行多轮细节拷问，提前暴露模糊点和潜在风险。这同样是"先想再做"的思路——在写代码之前，先把需求拷问清楚。

从Plan模式到SDD，从"刹车"到"新范式"， 讨论的脉络是一致的： AI的能力边界在扩展，但人的判断力不可替代。 问题不是AI能不能做， 而是人能不能说清楚要做什么。

🌅 尾声

一天的活动，从共青公园的花到分组讨论的火，信息量很大。

从Plan模式的刹车，到上下文管理的分寸，到知识沉淀的瓶颈，到责任归属的困境，再到协同范式的未竟之问——一条线串下来，今天的讨论其实只回答了一个问题：AI工具箱越来越满，但真正的问题从来不是工具够不够多，而是怎么用、谁来审、出了事谁负责。

📌 几个方向值得后续跟进：

测试团队的AI工具使用情况——开发侧的讨论充分，测试侧还缺一块

岗位知识库的构建路径——如何将员工经验有效"蒸馏"为AI可用的知识资产

AI编程的团队协作规范——多人使用AI时如何避免代码冲突和风格不一致

强监管行业的AI边界——安全合规要求下，AI的合理使用范围如何界定

从"提效工具"到"新协作范式"——AI嵌入旧流程只是过渡，新的开发协作模式正在形成

今天的讨论没有给出最终答案， 但把问题问清楚了—— 这本身就是一个好的开始。

本文基于2026年5月30日腾讯云架构师同盟上海沙龙现场讨论整理，并补充了行业实践和同盟历次活动的相关内容。