AI自己写代码改代码发代码，效果还更好？Salesforce亲测有效
我们让AI当程序员，7个月的活13天干完，Bug还更少了
Salesforce工程团队全面转向以Claude Code为核心的AI智能体工作流，取消令牌限制后，工程师效率提升超50%，故障反降5%。一个迁移项目从231人天缩短至13天，效率提升18倍。工程师正用AI重构开发流程，但上下文管理和安全模型仍是挑战。
我们让AI自己写代码、改代码、发代码了，而且效果还不错
最开始，我们只是想让工程师都用上AI，花了大力气搞定了工具、权限、培训这些破事。好不容易，超过九成的工程师开始用AI了，我们觉得这已经是个巨大的胜利。结果没想到，这仅仅是个开头。
现在，我们Salesforce的工程团队已经全面切换到一种新模式：AI不再是那个坐在副驾给你指路的“副驾驶”，它直接坐到驾驶位自己开车了。从写代码、检查代码、生成测试、更新文档，到管理程序的发布上线，甚至开始协调那些以前必须得人跟人反复沟通才能搞定的工作，全都是AI在干。这个变化来得又快又猛，比我职业生涯里见过的任何一次技术变革都带劲。
我们铁了心要让Claude Code当主力，并且不限量
所有转变里，最关键的一步就是我们下定决心，把Claude Code作为全公司统一的AI主力工具。我们不光给所有工程师都装上了，还干了一件更能表明决心的事：我们取消了所有的令牌数量限制。我们当时的核心指导思想只有一个，就是扫清工程师和这些能让他们更快、更有效的工具之间的任何一点障碍。
结果数据自己会说话。跟去年4月比，今年4月每个工程师完成的工作任务数量涨了超过一半，合并的代码拉取请求数量涨了近八成。最重要的是，我们用一套基于机器学习的“有效产出”评分来算，发现工程师真正交付的有价值的代码量，一年之间翻了一倍半还多。
一个真实的例子：本来要干七个月，十几天搞定
光说数字你可能没感觉，我给你讲个我们产品团队的真实故事。
有个团队需要把33个API接口迁移到一个新的云原生架构上。按老办法，这种活有多痛苦呢？光是搞清楚每个接口的数据映射关系、手动测试、写文档，就能把整个团队拖住好几个月。我们估算过，按部就班干完，大概需要耗费231个人·天。
结果他们用了多久？13天。整整快了18倍。
怎么做到的？他们用Claude搭了一套基于规则的自动化迁移框架。说白了，就是写一堆Markdown文件，里面全是迁移的规则和参考示例，让AI照着干。每次AI干完活，工程师提的修改意见，他们都会反手再把新规则写进那些Markdown文件里。这样一来，AI干活越来越准，最后生成的代码几乎直接就能上线用。他们还让AI自主地跑起“写代码-修bug-验证”的死循环，不用人盯着，同时开了好几个隔离环境并行干活，一次性生成好几个代码拉取请求。33个接口，最后只提了5个代码拉取请求就全搞定了。其中最大的一个拉取请求，一次性交付了21个接口，测试覆盖率还是百分之百。
这，才叫写软件的新姿势。
活干得又多又快，质量反而更好了
这时候你可能会问，AI这么猛干，会不会把系统搞崩了？质量会不会掉链子？
我们的“工程360平台”给出了明确的答案：质量不但没掉，反而上升了。虽然代码拉取请求的数量猛增，但我们系统总的故障数量反而下降了。
这事儿特别重要，因为大家以前总觉得，要效率就没质量，要质量就得牺牲效率。我们没看到这种矛盾。信任是我们的第一价值观，工程师们拿着AI给的超能力，反而更有精力去追求最高的质量标准和那些非功能性的要求。比如，我们早就把安全护栏和质量标准硬生生嵌进了AI的工作流程里。只要AI工具用得对，速度不仅不会拖累质量，反而能让质量变得更好。
工程师们开始用AI，重新发明“写软件”这件事
四个月前我们学到的是，AI必须嵌进工程师现有的工作流程里，他们才愿意用。现在他们用上了，就开始用AI反过来彻底拆掉并重建那些旧的工作流程。
我们的工程师正在从根本上反思他们是怎么实践软件开发生命周期的。哪些流程完全可以砍掉？哪些人与人之间的交接是多余的？哪里还在用人干活，其实完全可以交给AI？能问出这些问题，才可能带来真正的效率飞跃，而不是小打小闹地修修补补。这肯定不是我们以前那种“在旧流程上硬糊一层AI”的样子。
写“提示词”变成了手艺，AI小分队开始干活
有个现象特别有意思。工程师们不再仅仅是AI工具的用户，他们开始变成自己AI工作流程的“建造者”。Claude Code的技能包，说白了就是一些封装好的、可重复用的能力，里面写清楚了团队的上下文、命名规则、工作套路，这些东西现在成了一种新型的“工程制品”。各个团队都在造自己的技能包，互相分享，互相抄作业。
我们还搞了一套内部的AI专家套件和基础插件库，都是专门针对我们Salesforce工程流程精挑细选、沉淀下来的AI技能。这就相当于给了每个工程师一个共享的“地基”，上面摆满了经过验证的好用的技能，大家不用每次都从零开始。我们内部测试表明，用这些精选技能包，AI在我们特定代码任务上的准确率和可靠性都明显提高了，同时还省下了不必要的成本。
另外，“子智能体”和“智能体团队”也开始改变复杂工作的拆解方式。所谓子智能体，就是一些有明确任务边界的AI，它们可以像一个团队一样，在一个大任务里并行处理不同的工作流。现在，一个工程师再也不用为了推进一个任务，在五个不同的系统之间来回切换上下文了。他只需要说清楚想要什么结果，一群互相配合的AI就会自己琢磨出具体该怎么做。
这是一种全新的工程手艺。现在最重要的技能，是知道怎么为一个AI系统去拆解和描述问题，知道什么时候该彻底放手让AI干、什么时候自己得盯着点，以及怎么能造出那种整个团队都能不断在上面叠buff、可重复用的模式。
有些坑我们还在填
当然，还有几个实实在在的难题没完全搞定。
在一个又长又复杂的AI自主会话里，怎么管理上下文？这还是个手艺活，工程师们正在现学。每个项目根目录下那个CLAUDE.md文件，里面写的持久化上下文配置（告诉AI你的代码库什么风格、有什么规矩、有什么限制），各团队写得水平参差不齐。这东西写得好不好，对AI输出质量的影响可是天差地别。
还有，在AI智能体能够自主行动的世界里，安全模型从根本上就不一样了。以前AI只提建议，现在它可以直接在你的系统上动手。一个工具配置错了，搞出来的乱子可能大得多。我们正在花大力气，从头到尾把整个AI自主软件开发生命周期的安全给加固起来。
角色的演变也是个真问题，值得我们认真对待。当AI把大部分执行层面的活儿都干了，那些入门级的脏活累活没了，初级工程师还怎么成长成高级工程师？在这个新世界里，设计师和产品经理又该扮演什么角色？我们以前的执行单元是“一个Scrum团队”，以后会怎么变？安全团队和产品团队的基础设施层，面对的答案会是一样的吗？我们正在尝试一个人就是一个单元，或者三个人一个单元，但这些都还是早期的实验。我们还没有清晰的答案。但可以肯定的是，那些现在就开始主动思考这些问题的团队，未来一定会走在前面。
大方向已经很清楚了
我写上一篇文章的时候说，目标是要打好一个地基。我们打好了。现在，我们正在这个地基上飞速地盖楼。未来的工程组织，绝不是在今天的样子上硬加一层AI。它的样子会完全不同。前面提到的那个产品团队，他们不仅仅是跑得更快了，他们改变了“在经济上什么是可行的”。我们现在正把这种能力，扩展到我们整个工程组织。
我们的目标，是打造全行业里自动化程度最高、AI智能体应用最彻底的软件开发生命周期。写这些文章，就是我们这一路上的进度报告。如果你也是同行的实践者，非常欢迎你分享你的故事。
极客辣评
1、他们原计划用 231 天完成的迁移工作，最终在 13 天内完成。一个 PR 就实现了 21 个端点，测试覆盖率达到 100%。
质量随着产量的提高而提升。即使提交的 PR 数量更多，Bug事件总数也下降了 5%。他们将安全防护措施和质量标准融入了代理工作流程本身。 生产效率与质量有时被视为一种权衡取舍。他们并没有意识到这一点。
那些从人工智能中获益最大的团队正在彻底改变他们的工作方式，而不是仅仅加快现有工作的速度。
2、认为对于企业来说，词元Token的使用并不那么重要，但对于普通用户来说，即使是最高 200 美元的套餐，成本也太高了。 这是因为推理过于冗长。您必须提供设置来控制这一点。推理必须简洁明了。 仅仅为了分析最近一项功能的实现方式就花费 400 万Token词元，这太多了。
3、我们必须将Token词元成本与组建一支人工团队的成本进行比较