两周的实验,既不是彻底的否定,也不是盲目的拥抱。在互联网公司里,技术决策往往来自于试错:把新工具推到实际任务中,观察它在真实产品开发流程里的表现。Antropia 团队的 adbrew 实验,是一次典型的"把生成式人工智能(LLM)放到端到端开发里"尝试。这个实验既暴露了当前大模型带来的生产力红利,也揭示了严重的摩擦点和治理难题。通过对这段经历的报道与分析,开发者和管理者可以更清晰地判断:在怎样的场景下应该用AI,怎么用,或者不该把它放到关键路径中去。 实验背景与目标很简单。
团队想为小型电商主构建一个更为简洁的Facebook广告管理界面,目标是只做"我们需要"的功能,通过Facebook官方API直接交互,避开繁杂臃肿的官方控制面板。技术栈选用了当下流行的组合,包含 Remix(作者同时提到React Router v7)、前端样式方案以及相关工具链。最关键的变量是:开发过程将由Claude Code等大模型深度参与,从需求拆分到实现,乃至提交、部署,几乎把AI放到了整个开发闭环中。 实验开展得很快也很有典型性。每天的节奏是定义任务、让AI实现、反复讨论与修正、人工审查生成代码、提交与部署。为了提升"机器可理解性",团队不断完善项目的Guidelines,加入自动化检查(MCPs)并微调提示(prompt)。
初期的成果往往令人兴奋:AI可以很快生成可运行的页面、简化的API交互逻辑,甚至一些单元测试和样式代码都能在短时间内产出。然而随着时间推移,问题逐渐显现,挫败感逐日累积,最终团队在两周后选择回归传统工作流,用人工方式清理代码并继续开发。 在这次实验中暴露的问题可以概括为几类互相交织的痛点。首先是上下文不足问题。尽管团队倾尽全力向模型提供项目上下文,AI仍然在不明确的情况下大量假设,导致实现与预期偏离。模型缺乏主动提问的机制:当它感知到信息不足以完成任务时,并不会像一个资深工程师那样回头问关键问题,而是选择"自信地"填补空白,结果经常成为后续修复的根源。
第二是可维护性问题。AI生成的代码在局部实现上可能是可用的,但往往难以被抽象、复用或整合进已有的组件体系里。团队发现同样的功能会以不同风格和命名重复出现,多次出现"各自为政"的卡片组件与文本组件,这既增加了代码基的复杂性,也使得代码审查变得沉重而低效。即便将现有组件信息写入Guidelines,模型依旧倾向于产生新的实现,而不是重用现有库或遵循团队约定的样式。 第三是工作流节奏被打散。AI带来的即时反馈诱发了碎片化任务处理习惯,团队很难为单个任务争取到连续的30分钟左右的专注时间。
人工在审核生成结果时需要频繁"接力"阻止错误的传播,这严重削弱了开发者的心理流(flow),降低整体效率。最佳实践往往依赖开发者的连续思考,而非多次中断后的斑驳拼接。 第四是幻觉问题。Facebook广告API本身就是复杂且部分不完善的生态,文档不足、SDK类型松散,是常态。AI在面对这类边缘或未被良好文档化的接口时,会"自信地"捏造参数、端点和协议,导致代码在集成测试时频繁失败。把不同的库与框架(Tailwind、React Router、dayjs、日志库等)混合起来,幻觉频率更高,修复成本也更大。
第五是"帕累托问题"的放大。用团队自己的比喻,任务就像树:从粗到细的拆分会揭示出跨功能的边角事务、日志、追踪、权限等横切关注点。AI倾向于快速完成表面80%的功能,但很少自动触及那些会影响长期稳定性和一致性的20%。结果是项目看上去"差不多能用",但实际上有大量隐患与不一致,需要人工花费大量时间去修补。 这些痛点之下,团队对AI的态度并非全盘否定,而是更趋于"有限度采纳"。他们总结出AI在若干领域确有显著价值。
语义搜索与快速检索工具是明显的生产力提升点:当AI对问题有准确理解时,能比传统搜索更快速地定位解决方案并适配到当前上下文。AI作为"橡皮鸭式思考"伙伴也很有用:当你需要在设计方案或框架之间权衡时,让模型列举替代方案或给出关键词,往往能触发新的研究方向或联想。在重复性代码片段、常见工具函数(如chunkify、clamp、mapValues)生成上,AI能节省重复劳动。测试生成方面,AI也能帮助发现未考虑的场景,自动写出部分单元测试,这对提升代码覆盖率和发现边缘条件很有帮助。文本类工作如提交信息、文案、Issue或PR说明也是AI的天然用武之地,团队甚至把审稿流程反过来:让AI帮忙润色和优化人类写好的内容。 这些经验给出了一个折衷方案:将AI作为"增强工具"而不是"全权代理"。
值得推广的实践包括严格限定AI的角色与边界,明确哪些任务可以完全交给模型辅助,哪些必须保留给人工决策。对AI友好的工程实践需要明确的代码约束与自动化门槛:一套可执行的Guidelines、持续集成的风格检查器、静态类型强制、以及生成代码的审查流程。比方说,生成的代码必须通过类型检查与集成测试才能合并;在PR中应自动标注由AI生成的文件并要求人工复审;团队内部应有组件库与范式示例,并把它们以可机读的方式提供给模型以减少重复实现。 此外,有效的提示工程不应仅仅停留在单次请求上。提示配置需要版本化、可复现,并结合上下文快照(如当前package.json、组件列表、样式变量)作为模型输入。关键的是训练模型"提问而不是假设"的策略:在任务不明时,强制AI输出需要额外信息的候选问题清单,要求在获取确认前不进行实质性实现。
配合自动化脚本,这些候选问题可以被转成任务并指派给人类,形成闭环。这样可以把信息缺口转化为明确的沟通步骤,而不是让AI自行填充而产生潜在错误。 针对幻觉问题,工程化的解决之道是多层验证。静态类型检查、契约测试、契约文档和模拟(mock)都能在不同层级捕获错误假设。对外部API调用应建立模拟层与记录回放机制,任何生成的请求都应首先在沙箱环境中对齐目前真实API的实际行为。日志与监控的自动注入在AI驱动的开发中变得更为重要:当模型生成代码与外部系统交互时,详细可追溯的日志可以加速问题定位与回滚决策。
关于数据隐私与模型位置的选择,团队明显更偏向本地化模型与受控环境。虽然云端大模型在能力上可能更强,但对敏感数据的外发和长期的可控性是公司决策中不可忽视的因素。将模型放在受管的私有环境里,可以降低数据泄露风险并便于审计,同时有利于把模型定制化为适配自己的组件库与规则。 组织层面的调整同样关键。AI并不能替代设计与架构讨论,反而会把更多审查责任向团队转移,因此需要在团队流程中为审查、讨论和回顾留出明确时间窗。建议把AI生成的工作限定在"原型与实验"阶段,当任务进入发布路径时,必须经过人工重构与一致性校验。
对于长期项目,建立模型生成代码的度量体系非常必要:监测由AI生成代码的缺陷率、审查时间、重构成本与上线后错误密度,作为是否扩大AI应用的量化依据。 从更广的视角看,生成式AI的发展并不会停步,但当前阶段的边界很清晰:当任务具有高度可定义性、强重复性、且依赖良好文档化的API时,AI能显著提升效率。当任务需要跨系统架构判断、需要长期可维护性或在高度安全受控的环境下运行时,人工仍然不可或缺。对那些需要发现隐含需求、权衡产品逻辑和处理跨领域耦合的场景,人类工程师与产品经理的经验依然无可替代。 adbrew 的实践结论可作为许多中小团队决策的参考。短期内,更现实的路径是把AI当作生产力工具而非替代者。
把AI用在语义搜索、重复性代码生成、测试case提示、文本润色和头脑风暴上。严格控制模型在代码库中的写入权限,通过类型与测试门控输出,并在组织内部建立关于AI产出审查的文化与流程。长期来看,若模型在主动交互、长期记忆、上下文保存与可控性方面发生根本改进,它们才可能承担更多设计与实现的责任。 技术以外,团队体验也决定了工具的采纳。实验中最让人沮丧的往往不是技术缺陷本身,而是工作流的质量下降与创造乐趣的消失。开发是一种深度工作,良好的节奏、明确的反馈与协作能带来成就感。
任何工具如果破坏了这些基础要素,都会在心理层面产生重大抵抗。AI的设计目标不应该是替代这种体验,而是增强它,让人类工程师把更多精力放在创造性、架构性和高价值的决策上。 最后,对管理者的建议是采取渐进与数据驱动的策略。小规模试点、明确度量、保守的回滚机制以及对敏感工作流的隔离,能帮助组织在不牺牲质量的前提下探索AI的潜力。对工程团队而言,采用AI并不是技能的替代,而是需要补充新的能力:提示工程、AI产出审查、契约测试与模型治理成为新的必备素养。 两周的实验结束,adbrew 的代码并没有被全盘AI化,但团队获得了宝贵的经验:生成式AI有其不可否认的价值,但现阶段尚不足以完全代替工程师的判断与架构能力。
与其用它去完成所有任务,不如把它放在正确的岗位上,让它成为一个强力的助手,而不是独裁者。未来的路在于工具与流程的共同进化,只有当模型学会主动提问、长期记忆并与团队规范深度融合时,才有可能改变软件开发的全貌。现在的最佳策略是谨慎试探、持续优化,并始终把代码质量与团队体验放在首位。 。
