Claude Code团队如何用AI开发AI：信任、放手与抽象层上移

团队现在怎么跟AI一起干活？

一年前，Claude Code的工程师还在干一件特别累的事：盯着AI的每一步操作。每一次工具调用、每个参数选择、每段推理逻辑，都要人工过一遍。这工作量，想想都头疼。

现在不一样了。团队把70%到80%的日常任务交给了Slack里内置的AI智能体——Claude Tag。他们的工作方式变了：不再盯着模型怎么想，而是直接告诉它“我要什么结果”，然后让它自己去搞定。

这种转变背后有个关键设计：用户看到的只是Claude发出来的消息，而它内部的思考过程、中间步骤、试错记录，全都被藏起来了。你不会在聊天窗口里看到它反复纠结“该不该用这个API”或者“这个参数设多少”。这种界面和思考的解耦，让AI更像一个真实的Slack同事——你只关心它交付了什么，而不是它脑子里转了多少圈。

团队管这叫“有点吓人的强制性放手”。但更狠的是，他们正在用Claude Tag开发Claude Tag自己。

举个例子：有人想做个新工具，第一步不是写文档，而是问Claude Tag：“我有这么个点子，该找谁聊？谁会感兴趣？”AI立刻列出一串相关干系人名单。聊完一圈后，第二步直接让Claude Tag画原型图、写实现方案。第三步，给工具加上一堆埋点，扔进内部环境跑起来，观察大家怎么用、有没有反馈。

之后就彻底放养了。Claude Tag自己盯着使用数据，一旦有人吐槽或点击率掉下来，它会主动提醒负责人，甚至自己动手优化转化漏斗。整个过程几乎不需要人插手。团队说，到了这个阶段，“信任比监督更重要”——你得相信模型能自己兜住底。

为什么不能对代码太“恋战”？

所有这些做法，其实都源于一个残酷现实：底层模型的能力每两个月就会发生一次根本性跃迁。

今天你辛辛苦苦写的补丁，可能下个月就完全没用了。技术的地基一直在动，你必须站在前沿，甚至越过前沿，才能摸到真正的边界。但同时，你还得为今天正在用产品的人提供稳定价值。这平衡不好拿捏，一半靠艺术，一半靠科学。

所以团队定下一条铁律：对自己造的东西保持极度不执着。

比如早期有个“待办清单”（to-do list）功能。那时候Sonnet 3.5还搞不定多步复杂任务，必须靠外部清单一步步引导。结果一年后模型自己长出了更强的记忆和规划能力，这个功能瞬间成了累赘，立马拆掉。

再比如“AskUserQuestion”工具，最初是为了让AI能在任务中途主动提问而专门设计的。后来模型生成HTML和可视化内容的能力突飞猛进，大家干脆让它直接输出带图表的交互式页面来问问题——老工具自然就被淘汰了。

面对这种“地基随时塌陷”的局面，团队放弃了打造“完整解决方案”的念头，转而搭建一套可自由组合的“原语”（primitives）。比如权限控制（Permissions）、可视化（Visualizations）、验证（Verification）、代码审查（Code Review）、反馈收集（Feedback）等等。

这些原语就像乐高积木。某个模块过时了？换一块就行，不用推倒重来。更妙的是，当它们层层叠加时，常常会意外涌现出新能力——比如把反馈收集和可视化组合起来，自动生成用户行为热力图。

工程师的角色到底变了吗？

如果非要说这一年最大的变化，那就是人和AI打交道的颗粒度不断上移。

最早是盯着一个个token、一次次工具调用；后来变成关注一整轮对话（session）；再后来是设定一个完整目标（goal）；现在，他们已经在构建能跨多次对话、持续运行的工作系统。

这种抽象层级的提升，体现在两条并行的演进线上。

第一条是基础设施。从本地跑脚本，到远程开发机，再到托管容器，最后变成网页版云端服务。任务可以一直在后台挂着，自动执行例行工作，比如每天凌晨清理日志、每周一生成周报。

第二条是代码审查流程。人不再手动扫每一行代码。现在是让Claude先大范围扫描，找出所有可疑点；然后对每个疑点做对抗性测试——从三个不同角度交叉验证，过滤掉误报；最后只把真正值得看的问题推给人。这套机制后来直接演化成了自动化workflows：Claude自己写编排代码，调度多个子智能体协作，把确定性逻辑和自主判断结合起来。

有意思的是，团队里那些曾经最讲究“手写匠心”的工程师，现在已经放下“被取代”的焦虑，开始享受效率飙升的快感。毕竟软件工程从来就是个关于“变化”的行当。二十年前大家还在手写原生JavaScript，连jQuery都没有。现在变化只是更快了点，但底层逻辑没变——

工程师的核心，永远是如何解决问题（Problem Solving）。

工具在变，抽象层在升，但你要解决的那个真实问题，才是锚点。