1. 从vibe coding到harnessAI全栈开发的两条路线这两年挂着AI全栈开发标签的项目我见过不下百个真正跑起来、能维护、敢上生产的反而都是那些一开始就承认AI会犯错的团队。最近圈子里天天在聊vibe coding和harness模式的区别我想结合自己用AI做全栈开发的体会把这条路上的核心经验系统捋一遍。先说个基本判断AI全栈开发的本质不是让AI帮你写代码而是你作为开发者把设计决策、验收标准和上下文管理这三件事牢牢握在手里。工具再强它也只是执行者不是架构师。我见过太多人把需求往Claude或GPT里一贴拿到代码往仓库一推最后连自己项目跑起来依赖了哪些环境都不知道这种vibe coding方式做原型可以做产品就是给自己埋雷。所谓vibe coding就是纯粹靠感觉让AI写代码你只负责描述我想要什么剩下的全交给模型随机发挥。这种方式胜在快几十行代码能瞬间生成但你失去了对代码行为的预测能力。举个我踩过的例子让它实现一个用户登录功能它自作主张加了token刷新逻辑还在前端存了明文用户信息。表面看功能正常实际上安全模型完全是错的。这就是vibe coding的典型风险——它会在你注意不到的地方做你并没要求的事。另一条路线是harness意思是给AI套上缰绳。说白了就是把AI当作一个能力很强但经验不足的初级工程师来管理——给它清晰的工单、给它可验证的验收标准、给它跑测试的反馈回路而不是让它自由发挥。harness模式下的AI全栈开发核心动作是约束不是放纵。这两种模式不是零和关系。我的经验是探索期可以用vibe coding快速试方向验证想法可行性一旦方向确定进入开发期立刻切换到harness模式给AI设定纪律全栈项目越大harness比例必须越高否则技术债会把你拖死这里就得引出另一个正在热门的概念——SDD也就是规范驱动开发。它跟harness是一对黄金搭档harness解决怎么约束AI的问题SDD解决拿什么约束AI的问题。没有规范驱动的约束只是空话你告诉AI注意代码规范它根本不知道你的团队规范是指缩进风格还是目录结构还是接口命名。但你把规范写成定义好的规则文件(SDD的spec)AI在执行每个任务前先看规范产出的代码就稳定得多。我在实际项目里的分工是这样的我自己写产品需求文档和架构设计把技术规范拆成一份详细说明然后才把任务交个AI编码工具。本来这一步只需要1小时但能节省后面10小时的调试时间。这不是保守是效率最大化。2. 规范驱动开发(SDD)背后的脑科学逻辑为什么给AI立规矩比给AI喂需求更高效前面提到SDD这里我想深挖一下它为什么有效。你可能觉得规范驱动听起来就是写文档没什么了不起。但我接触过上万个AI编码场景后越来越确定一件事模型生成代码的质量直接取决于输入的约束密度。一个含糊的需求比如做一个待办事项应用给了十个不同AI工具会出来十种截然不同的架构。但如果你说用ReactTypeScript状态管理用zustand数据持久化用localStorage列表渲染用虚拟滚动十个AI产出的代码结构会高度相似且大概率都是可用的。这就是规范的价值——它把模型的发散空间压缩到你可控的范围内。站在人脑处理的角度也好理解。你指挥一个人类工程师时会告诉他按团队规范走用我们的组件库遵循已有的目录结构而不是从头描述每一个细节。AI也一样先建立规范和上下文再给具体任务比把细节全塞进一条提示词里可靠得多。因为模型的注意力是有限的提示词越长它越容易在关键约束上注意力稀释。而把规范放到单独的文件里作为先导上下文等于告诉模型这些是稳定的、长期的约束你随时可以参考比堆在任务描述里有效得多。在具体落地时我用的规范结构长这样技术栈规范框架版本、语言特性、允许和禁止使用的依赖库架构约束目录结构、模块边界、数据流方向、状态管理方案代码风格命名规则、组件拆分粒度、注释要求这部分可以直接引用团队的lint配置完成定义什么样的代码算做完包括必须通过的测试、必须处理的边界情况这套规范写完后每次交给AI的任务描述就会变得非常短。因为长周期约束都沉淀在规范文件里了任务描述只需要包含做什么、为什么做、涉及的文件范围、验收标准。这种规范任务的两层结构就是我跑了这么多AI项目之后觉得最稳定的一种组合。有朋友问过我规范写这么细是不是等于我在替AI把活都干了说实话一开始我也有这个疑虑。但后来我想明白了开发的核心竞争力从来不是打字速度而是决策质量。技术栈选什么、模块怎么切、数据怎么流这些决策才是值钱的。AI帮你把决策变成代码节省的是执行时间而决策本身必须由人来做。SDD也不是让你把每个函数都设计好而是把约束定好让AI在约束内自行发挥。它做的部分依然很多但你不再需要担心它跑偏了。3. 从辅助编程到AI Agent全栈项目中智能体的分工设计与上下文管理聊到AI全栈开发就不能不提AI Agent。现在很多人把Agent理解成一个能自动干活的机器人这种理解没错但放在全栈项目里远远不够。我自己的定义是Agent是能自主完成一个完整任务闭环的程序它需要感知、决策、执行、验证四个环节缺一不可。在一个全栈项目里可以把不同类型的工作分给不同的AI Agent去处理但分工必须清晰。以我最近做的一个数据中台项目为例我同时用了三类Agent需求分析Agent把产品PRD拆成技术任务列表标注优先级和依赖关系代码生成Agent根据技术任务生成实现代码这个环节我用的是AI编码工具配合规范文件测试与审查Agent写单元测试、做代码走查、检查安全漏洞三个Agent各司其职中间通过统一的上下文交换。具体做法是需求分析Agent的输出是一个结构化任务文件包含任务编号、目标描述、涉及模块、验收条件代码生成Agent读取这个任务文件结合规范和代码库上下文生成实现审查Agent再读取实现和任务文件做差异对比和测试执行把结果反馈出来。这套流程跑通之后最大的感受是上下文管理成了比写代码更重要的事情。AI Agent的能力上限取决于它能访问到多少高质量上下文。几个我常用的上下文管理技巧把长期稳定的信息架构决策、规范、接口约定放到独立的文档中按需加载把短期任务相关的信息这次要改什么、涉及哪些文件放到任务描述中把已经做过的事记录下来让后续Agent不需要重复探索很多人在用AI编码工具时遇到的一个典型卡点是——AI生成的代码跟你项目的现有风格不一致。这通常不是模型能力问题而是它没有看到足够的项目上下文。解决方式是给AI补上相关模块的现有代码作为参考哪怕只贴一部分产出的风格匹配度都会大幅提升。说到AI编码工具最近很火的几个我都实测过。Cursor的Autopilot模式上下文管理做得不错能自动索引整库代码并检索相关片段GitHub Copilot workspace在对大型代码库的理解上更强对已有的工程结构把握更准确。不过工具终归是工具关键在于你怎么用它而不是它本身多强。一个我对所有想尝试AI Agent全栈开发的团队的建议不要一开始就搞全自动多Agent流水线那只会让你在调试Agent互相传递的垃圾信息上浪费大量时间。先用单Agent把手动流程跑顺再逐步自动化。我见过太多失败案例不是因为AI能力不行而是因为没搞清楚整个流程之前就急着把所有环节交给Agent导致错误被一级级放大。4. AI全栈开发的项目结构从AI生成代码到AI友好的代码库设计大多数全栈项目都有一个共同特征项目越写越大代码越来越乱。用AI开发的项目还有一个额外的麻烦——AI生成的代码往往是正确但不易维护的因为它不会像老手一样考虑未来三个月的演进方向。这就要求我们在设计项目结构时额外考虑AI友好这一维度。什么是AI友好的代码库我用几个标准来衡量职责清晰每一个模块、组件、函数都有一个明确的、可描述的职责AI通过命名和目录结构就能理解项目组织方式上下文可达相关的代码放在相近的位置AI在分析时不需要跨十几个目录去追踪逻辑状态显式数据流写清楚状态全局管理避免隐式传值让AI能准确推断数据来源和流向这套标准不是玄学是有实际依据的。大模型生成代码是输入上下文→推理→输出代码的过程它能看到的上下文越清晰推理就越准确。如果你把状态藏在各种隐式的地方AI很容易在修改逻辑时漏掉关联点。但如果数据流是单向、显式的AI生成代码时就能顺着数据流推演改起来也稳。我在一个电商项目里做过一次对比测试同一项功能改造在重构前的代码库上AI生成的代码只有40%能直接用重构后这个数字提升到了75%。重构本身没有改变任何功能只是把代码库整理得更AI友好。这个提升非常直观地说明了问题——AI不是万能的但它足够聪明聪明到值得你为它优化环境。具体来说我在项目结构设计上会着重做这几件事用领域模型做目录分层而不是按技术类型分层。比如电商项目我不建controllers、services、models这种目录而是按订单、支付、商品分模块每个模块内部再分层次。AI在处理业务逻辑时相关代码天然在一起读起来方便把类型定义集中管理。给AI一个明确的类型地图它能少走很多弯路用规范文件锁死目录结构。告诉AI哪些代码应该放哪里、什么逻辑应该归哪个模块而不是让它自由想象这样设计还有一个好处当AI Agent要修改某个功能时它能快速锁定影响范围不会碰伤周边无关代码。这也正是全栈项目里最怕出现的问题——AI改一个模块结果把无关模块的功能改坏了。清晰的模块边界是避免这类事故的第一道防线。5. AI编程提示词从写提示词到设计提示系统现在很多讨论把AI编程提示词说得玄乎其玄好像掌握了什么咒语就能让AI写出完美代码。以我用过的实际经验看真正有价值的不是单条提示词写得多漂亮而是你能不能围绕一个项目设计出一套稳定的提示系统。什么是提示系统它不是一句话而是一套结构化的输入组合。我每次让AI开发一个新功能时输入的材料包含项目背景一两段话让AI理解它在做什么项目、为什么做这个项目技术规范标明允许使用的依赖和禁止使用的方案任务描述本次要完成的具体功能参考实现如果项目里有类似的已实现功能贴上一段验收标准什么样的产出算合格这五类材料各有用处缺一个都可能导致质量下降。项目背景让AI理解全局技术规范约束它的选择空间任务描述指明目标参考实现提供风格模板验收标准让它可以自检。关于提示词本身我有几条经过验证的经验第一用任务式陈述不要用命令式。你说给我写一个用户注册接口AI会给你一个孤立接口。但你说实现用户注册功能包含接口、数据库操作、前端表单、错误提示它就会给你一个完整闭环。任务式提示词能激发模型的全局规划能力命令式提示词只会让它机械执行。第二把边界条件说得越具体越好。告诉AI这个表单需要处理用户名为空、密码太短、邮箱格式错误三种情况比做好表单校验好一百倍。AI在处理边界条件的可靠性完全取决于你对边界条件描述得有多详细。第三让AI先复述任务再执行。让AI在第0步先用自己的话描述它对这个任务的理解、准备怎么实现然后再开始写代码。这一步能提前暴露AI理解偏差的问题避免它写了一大堆发现方向错了。第四涉及改代码时贴上前后对比的预期。直接告诉AI改动前接口返回的是A改动后要变成B需要同步更新前端调用处的逻辑它就能意识到这个改动可能有连锁反应。提示系统还有一个很实际的用途就是让团队里的所有人都能用相同的方式指挥AI。我们团队内部会把提示模板沉淀成文档新人来了先看文档然后照着模板提示AI产出的代码质量跟老手差距就小得多。把个人经验变成团队规范这是任何一个AI开发团队走向成熟的必经之路。6. AI基础设施从单机调用API到AI Infra的工程化思维做AI全栈开发光会调API、写提示词是不够的。项目稍微上点规模就得考虑AI基础设施的问题。这个听起来高大上其实核心就是三件事怎么稳定地调用模型、怎么管理好提示词和上下文的版本、怎么做好成本和质量的可观测。先说说模型调用的稳定性。我自己原来写AI功能都是直接调OpenAI的API代码里硬编码API Key。后来项目上线、多人协作之后发现这种方式问题很大——Key泄露风险、模型切换成本高、没法统一做限流重试。后来我换成了LiteLLM Proxy现在圈子里已经很流行把它当作模型API的统一代理层。前端代码只对接LiteLLM Proxy的接口Proxy再去路由到具体的大模型后端。这样换模型供应商改一个配置文件就行不用改业务代码重试、限流、负载均衡这些也可以在Proxy层面统一处理。这里有一句值得记住的话让业务代码依赖模型供应商的SDK是最糟糕的架构决策之一。因为业务逻辑怎么写提示词、怎么处理回复跟基础设施调用哪个模型、怎么计费高度耦合后任何一个调整都牵一发动全身。用Proxy层做隔离等于把做什么和怎么调分开这是AI Infra工程化的第一步。再谈提示词和上下文的版本管理。这可能是最被忽视但坑最多的地方。传统软件里代码有版本控制但在AI应用里提示词和上下文的改动同样会影响行为甚至影响更大。我见过很多团队某天突然发现线上AI功能表现不对排查半天才发现是有人改了提示词没经过验证直接推上线了。我的做法是把提示词模板纳入git管理和代码一起走版本控制。改动提示词必须经过和改代码一样的评审流程。如果将来有条件还可以给提示词做版本对比测试——同一批测试样本分别用旧版提示词和新版提示词跑一遍对比输出质量确保提示词改动是可量化评估的。最后是成本和质量的观测。做AI全栈开发每一笔API调用都是真金白银而且模型质量在变化、token消耗在不同场景下差别很大。我的经验是在上线AI功能的第一个月就建立基础的可观测体系记录每一次调用的模型、输入token数、输出token数、延迟、成本、用户反馈。这些数据是后续优化的依据没有数据所谓的优化只能是拍脑袋。做这类观测最省力的方式是日志打点不用搞得太复杂也不需要接入专门的平台。把自己的日志服务里加几个字段记录模型名称、token用量、耗时、缓存命中情况就够用了后面需要的时候再逐步升级。7. 全栈AI应用的代码走查当AI写完代码你该重点审查哪些环节不能否认一个现实AI写代码已经不是行不行的问题了而是哪里不行的问题。我让AI写的大量代码中逻辑bug其实不多真正的风险集中在几个固定区域。做AI全栈开发的代码审查重点盯这几个地方就够了。第一个要盯的是权限与安全逻辑。AI对这个接口需要鉴权吗这类问题经常理解不到位。我在审查AI代码时会把所有涉及数据访问的入口列出来逐一确认是否做了权限校验。最容易漏的是内部管理接口AI会默认只有管理员能访问所以不用校验这个假设在真实系统里往往不成立。第二个要盯的是输入校验的完整性。AI生成的表单处理逻辑通常只能覆盖正常情况和显而易见的反例对边界条件覆盖很差。审查时要特别留意如果用户传入超大字符串怎么办如果提交的速度特别快导致并发写怎么办如果字段缺失怎么办AI的默认实现往往在这些场景下会直接抛异常或写入脏数据。第三个要盯的是状态管理和副作用。AI对全局状态的处理相对薄弱经常在函数体内部隐式修改全局状态导致排查困难。审查时我会特别关注每个函数是否有明确的输入和输出是否只修改了自己所属模块的状态是否产生了预期的外部副作用第四个要盯的是错误处理策略。AI倾向于遇错抛异常但这在生产环境并不实用。合理的设计是能恢复的错误就恢复不能恢复的错误要带足够上下文的报错信息。AI生成的错误处理代码要么吞掉异常不留痕迹要么把敏感信息直接写在日志里都需要人工做一遍修正。关于审查方式我试过一个比较高效的办法让AI审查AI的代码。让负责代码生成的Agent写完代码后交由另一个负责审查的Agent去检查上述几个风险点输出审查报告。人工再对审查报告做二次判断重点看报告的覆盖面和误报率。两轮下来多数低层问题能提前暴露人工只需要关注架构和业务层面的事。当然最终的责任人永远是你自己。AI生成的代码出了问题不会有人帮你背锅。再高效的审查流程也只能降低风险不能消除风险。这个认知决定了一个团队能不能长期受益于AI开发——那些把AI当甩手掌柜的团队最后都会被隐藏的技术债反噬。8. 可观测性设计AI全栈应用上线后你要看的数据比传统应用多一倍传统全栈应用上线后运维关注的核心指标就那么几个响应时间、错误率、吞吐量、资源占用。但AI全栈应用多了一个维度——模型行为的可观测性。因为你的应用行为一部分由代码决定一部分由模型决定而模型行为是概率性的、会变化的。我在一个客服系统项目里吃过一次大亏。上线时测试效果不错结果运行两周后用户投诉量暴增。排查了半天最后发现是模型供应商更新了版本导致输出风格突变。传统监控一点告警都没报因为系统本身没有报错只是输出内容偏离了预期。从那之后我再也没做过裸奔的AI应用。对于AI全栈应用我要求自己上线前务必建立这些观测点每一次模型调用的入参出参至少要存hash值方便事后回溯问题样本模型输出的质量指标比如用户是否在接收到AI回复后继续追问通常说明第一次回复没解决ta的问题模型响应延迟的分位数分布大模型接口的延迟波动比普通API大得多需要建立独立的SLO成本指标的按功能维度拆分不同功能模块的token消耗差异巨大集中记账很难发现问题这些观测数据不光用于出问题时排查更重要的用途是驱动持续优化。我每月会拉一次AI调用的成本和质量报表找出成本高但转化差的功能模块然后针对性地优化提示词或调整模型选型。AI应用的调优本质上是一个数据驱动的循环每一次调整都要有数据支撑。另外一个很多文章没提过的点要把AI能力的降级方案纳入可观测设计。模型供应商可能随时出问题这跟你的代码质量无关。我的做法是给核心AI功能做降级开关——模型调用失败时自动走一段预设的规则逻辑保证用户至少能得到一个兜底回复而不是一个错误页面。这个降级是否发生过、触发频率多高都要纳入观测。这是做AI全栈应用最实用的保命设计之一。9. 多人协作的AI开发流从个人效率工具到团队协作基础设施当AI编码工具成为团队基础设施而不是个人玩具时很多新问题就浮现了。最典型的问题就是AI改的代码其他成员看不懂怎么办AI产生的变更量太大code review如何进行我在团队里推行了一套名为AI改动可视化的制度核心思想是让AI的每一次改动人类都能快速理解它改了什么、为什么改。具体操作上有三条规则要求AI在提交代码时必须附带说明内容包含需求理解、实现方案、改动的文件清单、已知限制和潜在风险。这些说明直接写入PR描述reviewer看PR时先看说明再看代码限制单次改动范围。不要一次性让AI改十个文件而是拆成一个一个的小任务逐次完成每次改动产生一个独立PR。虽然流程慢一点但review质量和事故率都大幅改善重大架构改动坚持人工先行设计AI后行实施。AI可以参与方案讨论也可以做细节设计但最终架构决策由人来拍板。我这里有一条铁律AI不能在没有明确书面架构决策的情况下重构核心模块还有一个小技巧是对AI产生的代码打上标识比如在文件头部注释里加上generated by AI标记。这样review时对AI生成的代码采取更严格的审查标准对人工改写的代码相对宽松。这个标记不是为了鄙视AI代码而是因为AI代码的风险模式跟人写代码不同需要不同的关注点。多人协作还有一个容易被忽视的问题不同成员对AI的使用水平差异带来的“生产力落差”。熟练的成员让AI代写80%的代码不熟练的成员可能只用了20%的能力代码风格和行为差异会越来越大。解决方式也很简单就是前面提到的提示词模板和规范文件的标准化。让所有成员用同一套规范和提示框架去指挥AI产出质量不会完全一致但至少差距可以控制在一个合理范围内。10. AI全栈开发的项目管理任务拆解粒度与验收标准的工程化设计最后想聊一个听起来不酷但非常关键的话题AI全栈开发下的项目管理方式。传统项目管理拆任务拆到人可以执行的程度就够了。但在AI参与的团队里任务拆解的粒度直接决定了AI编码工具的表现质量。根据我的实测经验AI编码工具最适合的任务粒度是一个一个小时内可实现的完整功能单元。拆得太粗AI容易遗漏实现细节拆得太细上下文切换成本反而大于收益。比如实现用户注册是一个合适的任务但实现用户注册、登录、忘记密码、第三方登录就太大了AI容易做到后半段时把前面的设计决策忘掉。配合任务粒度验收标准的写法也要改变。传统的验收标准是能用就行但AI任务的验收标准要具体到可以自动验证的程度。比如不要写登录功能是好的要写用户输入正确凭据后应返回200和token输入错误密码时应返回401和错误码AUTH_001不要写界面样式合理要写注册页面在375px和1440px宽度下均无横向滚动条按钮最小点击区域44x44px不要写性能达标要写列表接口在1000条数据下P95响应时间小于200ms且首屏渲染无白屏这套方式的好处是AI编码工具生成的代码能不能过关可以用自动化手段直接判定不需要人工主观判断。这才能真正释放AI开发的价值——人类负责定义什么是好AI负责实现好。我还建议在项目管理里为AI任务设置一个专门的上下文预热阶段也就是把任务相关的背景信息、类似实现参考、规范摘录等提前准备好。这个准备工作看起来拖慢了进度但它能有效压缩AI的返工率。我实测过一个数据有预热和没预热的AI任务相比首轮代码可用率从40%提升到70%左右总消耗时间反而下降了。用AI全栈开发项目还有一点跟传统项目不同每次AI调用都在消耗成本所以任务安排的顺序要更讲究。先做风险最高的部分用AI快速验证可行性后做大量重复性的部分用AI规模化生产。把AI用在刀刃上比让AI做所有事更高效也更省钱。11. Agentic CI/CD让AI不只是写代码而是参与构建、测试和发布全流程AI全栈开发做到后面必然要面临一个问题AI写代码只是开始能不能让AI也参与构建、测试和发布我在项目中尝试了逐渐把CI/CD流程的一些环节交给Agent这里分享一些心得。传统的CI/CD流程完全由人工配置和维护依赖关系复杂、脚本又多又长。AI Agent介入后可以承担不少流程工作自动化测试用例的生成AI根据代码变更自动生成针对性测试用例纳入测试套件构建失败的根本原因分析构建报错时AI自动分析日志定位问题比人肉翻日志快得多发布说明的自动生成根据git历史自动生成变更日志和发布说明特别是API变更要标注出来回滚决策辅助新版本出问题时AI可以快速对比新旧版本行为差异辅助确定是否需要回滚这里有个边界问题需要考虑哪些环节适合完全自动化哪些必须留给人来兜底。我目前的规则是构建和测试环节可以全自动发布环节保留人工审批。理由很简单——发布的成本和风险远高于前两个环节一旦出错直接影响生产环境所以发布前保留一道人类审批的环节是必要的。AI可以提供建议和预检结果但按下那个发布按钮的人必须是一个能承担后果的人类。另一个比较实用的场景是AI辅助Code Review。在代码提交后、人工review之前先让AI Agent做一轮自动审查检查风格规范、潜在bug、安全漏洞输出审查意见。人工review时带着AI的审查意见去看效率高很多。实测下来这种方式能让review时间减少大约30%更重要的是能先过滤掉那些低级的送了都觉得不好意思的问题让人类专家把精力集中在真正值得讨论的架构和设计决策上。往更远看一点Agentic CI/CD的终极形态或者说理想形态应该是一个AI开发团队——需求分析Agent、编码Agent、测试Agent、审阅Agent、运维Agent各司其职在人类设定的流水线上协同工作。这种形态现在还有些远多数团队其实用不到这么复杂的建制。但往这个方向逐步演进每一步都能带来实实在在的效率提升。我也是从最基础的自动化测试生成做起一步步把Agent引入到流程的更多环节中的。目标不是让AI取代整个CI/CD而是让AI把流程里那些重复的、可枚举的部分吃掉把人解放出来做更智慧和重要的判断。12. 成本控制与模型选型每个AI全栈项目都必须回答的四个问题做AI全栈项目早晚绕不开一个话题钱。很多AI项目的成本失控不是用量太大而是从一开始的模型选型和调用架构就没规划好。我归纳了每个AI全栈项目都必须回答的四个问题第一这个功能真的需要最强模型吗大部分智能功能用中小模型就足够了。比如做关键词提取、信息摘要、格式转换这些任务用轻量模型性价比极高。只有像复杂推理、长文本理解、代码生成这类高难度任务才需要上旗舰模型。我见过不少项目所有功能一律调用旗舰模型成本是优化后方案的十几倍效果却没差多少。第二能不能用缓存降低成本在很多AI应用里大量用户问的问题是相似甚至完全一样的。在模型调用层加一层语义缓存让相同或高度相似的问题直接走缓存返回结果可以把成本降一个数量级。实现也不复杂把用户输入做embedding后存入向量数据库检索到相似度超过阈值就直接复用历史答案。第三提示词里的上下文能不能精简很多AI应用成本高的原因是提示词里塞了太多不必要的内容。token数直接跟钱挂钩每次多传1000个token一个月下来就是一笔不小的开销。审视上下文是成本优化的最直接手段同时也是效果优化的手段——上下文越精简模型越容易聚焦真正重要的信息。第四是否需要对不同用户做分级免费用户走性价比路线优先使用便宜模型对响应质量要求放低付费用户走旗舰模型提供最好的回答质量。这种分级策略在商业上行得通技术实现也简单。一个Proxy层加上用户维度的路由规则就搞定了。回答完这四个问题大多数AI项目的成本能自然落入一个健康区间。剩下的优化空间就来自每次调用的微观层面比如设置max_tokens上限防止模型胡言乱语浪费token、对长上下文做优雅截断而不是强行塞入……关于模型选型还有一个容易踩的坑不要太早绑定某一家模型供应商。AI模型更新迭代真的太频繁了今天最强的模型三个月后可能就掉队了。如果在架构上做了解耦——业务代码不直接依赖模型SDK而是通过中间层接入——那么切换模型就是一个配置文件的修改。我在前面提到的LiteLLM Proxy这类工具就是做这件事。架构上付出一点点抽象成本换来的是长期的选型自由。这个投入我认为是AI全栈项目里回报率最高的基础设施投资之一。13. 从代码生成到产品交付AI全栈开发者的认知升级路径走到这一步AI全栈开发的工程层面基本聊透了。但最后我还想专门说说人这个层面。因为工具会持续迭代模型能力会不断提升但一个开发者对AI的认知深度决定了他能不能持续从中受益。我的个人经验是AI全栈开发的认知升级大概经过三个阶段第一阶段是工具视角。把AI当成一个超级补全工具写代码时让它补全、debug时让它分析。这个阶段收获的是局部效率提升但没有改变开发的底层方式。第二阶段是协作视角。把AI当成一个协作者学会给它清晰的指令、建立规范约束、设计验证反馈机制。这个阶段收获的是整体效率提升但依然是以人主导、AI辅助的模式工作。第三阶段是生态视角。把AI当成整个开发流程的基础设施从任务拆解、代码生成、测试验证、CI/CD到运维监控全程融入AI能力。这个阶段收获的是质变——项目的上限不再取决于团队里最强的那个人而是取决于整个流程的设计质量。我见过很多团队停留在第一阶段整天研究各种提示词技巧确实也提升了效率但始终无法突破瓶颈。跳出来的关键动作有两个第一个是从让AI做任务转变为为AI设计任务。前者是一次性的、随机性的后者是系统性的、可积累的第二个是从追求生成代码的质量转变为追求开发流程的质量。一个流程如果设计得好AI生成的代码质量自然就高反之再强的模型也救不了混乱的流程现在回头看AI全栈开发给我最大的改变不是写代码更快了而是我思考问题的方式变了。以前我拿到需求的第一反应是这个功能怎么做现在我的第一反应是这个任务的边界是什么、验收标准是什么、需要哪些上下文才能让AI一次做对。这种思维方式的转变让我从执行者变成了设计者。对正在考虑引入AI全栈开发的朋友我的建议是千万别从让AI把现有工作全包了开始一定要从挑一个高频且边界清晰的小任务设计一套让AI能稳定完成的流程开始。等这个流程跑顺了、你摸清了AI的能力边界和失效模式再逐步扩大AI的职责范围。这个过程没有捷径但每一步的积累都会在后面的项目中成倍地还给你。 AI全栈开发实战：从vibe coding到规范驱动与Agent工程化
1. 从vibe coding到harnessAI全栈开发的两条路线这两年挂着AI全栈开发标签的项目我见过不下百个真正跑起来、能维护、敢上生产的反而都是那些一开始就承认AI会犯错的团队。最近圈子里天天在聊vibe coding和harness模式的区别我想结合自己用AI做全栈开发的体会把这条路上的核心经验系统捋一遍。先说个基本判断AI全栈开发的本质不是让AI帮你写代码而是你作为开发者把设计决策、验收标准和上下文管理这三件事牢牢握在手里。工具再强它也只是执行者不是架构师。我见过太多人把需求往Claude或GPT里一贴拿到代码往仓库一推最后连自己项目跑起来依赖了哪些环境都不知道这种vibe coding方式做原型可以做产品就是给自己埋雷。所谓vibe coding就是纯粹靠感觉让AI写代码你只负责描述我想要什么剩下的全交给模型随机发挥。这种方式胜在快几十行代码能瞬间生成但你失去了对代码行为的预测能力。举个我踩过的例子让它实现一个用户登录功能它自作主张加了token刷新逻辑还在前端存了明文用户信息。表面看功能正常实际上安全模型完全是错的。这就是vibe coding的典型风险——它会在你注意不到的地方做你并没要求的事。另一条路线是harness意思是给AI套上缰绳。说白了就是把AI当作一个能力很强但经验不足的初级工程师来管理——给它清晰的工单、给它可验证的验收标准、给它跑测试的反馈回路而不是让它自由发挥。harness模式下的AI全栈开发核心动作是约束不是放纵。这两种模式不是零和关系。我的经验是探索期可以用vibe coding快速试方向验证想法可行性一旦方向确定进入开发期立刻切换到harness模式给AI设定纪律全栈项目越大harness比例必须越高否则技术债会把你拖死这里就得引出另一个正在热门的概念——SDD也就是规范驱动开发。它跟harness是一对黄金搭档harness解决怎么约束AI的问题SDD解决拿什么约束AI的问题。没有规范驱动的约束只是空话你告诉AI注意代码规范它根本不知道你的团队规范是指缩进风格还是目录结构还是接口命名。但你把规范写成定义好的规则文件(SDD的spec)AI在执行每个任务前先看规范产出的代码就稳定得多。我在实际项目里的分工是这样的我自己写产品需求文档和架构设计把技术规范拆成一份详细说明然后才把任务交个AI编码工具。本来这一步只需要1小时但能节省后面10小时的调试时间。这不是保守是效率最大化。2. 规范驱动开发(SDD)背后的脑科学逻辑为什么给AI立规矩比给AI喂需求更高效前面提到SDD这里我想深挖一下它为什么有效。你可能觉得规范驱动听起来就是写文档没什么了不起。但我接触过上万个AI编码场景后越来越确定一件事模型生成代码的质量直接取决于输入的约束密度。一个含糊的需求比如做一个待办事项应用给了十个不同AI工具会出来十种截然不同的架构。但如果你说用ReactTypeScript状态管理用zustand数据持久化用localStorage列表渲染用虚拟滚动十个AI产出的代码结构会高度相似且大概率都是可用的。这就是规范的价值——它把模型的发散空间压缩到你可控的范围内。站在人脑处理的角度也好理解。你指挥一个人类工程师时会告诉他按团队规范走用我们的组件库遵循已有的目录结构而不是从头描述每一个细节。AI也一样先建立规范和上下文再给具体任务比把细节全塞进一条提示词里可靠得多。因为模型的注意力是有限的提示词越长它越容易在关键约束上注意力稀释。而把规范放到单独的文件里作为先导上下文等于告诉模型这些是稳定的、长期的约束你随时可以参考比堆在任务描述里有效得多。在具体落地时我用的规范结构长这样技术栈规范框架版本、语言特性、允许和禁止使用的依赖库架构约束目录结构、模块边界、数据流方向、状态管理方案代码风格命名规则、组件拆分粒度、注释要求这部分可以直接引用团队的lint配置完成定义什么样的代码算做完包括必须通过的测试、必须处理的边界情况这套规范写完后每次交给AI的任务描述就会变得非常短。因为长周期约束都沉淀在规范文件里了任务描述只需要包含做什么、为什么做、涉及的文件范围、验收标准。这种规范任务的两层结构就是我跑了这么多AI项目之后觉得最稳定的一种组合。有朋友问过我规范写这么细是不是等于我在替AI把活都干了说实话一开始我也有这个疑虑。但后来我想明白了开发的核心竞争力从来不是打字速度而是决策质量。技术栈选什么、模块怎么切、数据怎么流这些决策才是值钱的。AI帮你把决策变成代码节省的是执行时间而决策本身必须由人来做。SDD也不是让你把每个函数都设计好而是把约束定好让AI在约束内自行发挥。它做的部分依然很多但你不再需要担心它跑偏了。3. 从辅助编程到AI Agent全栈项目中智能体的分工设计与上下文管理聊到AI全栈开发就不能不提AI Agent。现在很多人把Agent理解成一个能自动干活的机器人这种理解没错但放在全栈项目里远远不够。我自己的定义是Agent是能自主完成一个完整任务闭环的程序它需要感知、决策、执行、验证四个环节缺一不可。在一个全栈项目里可以把不同类型的工作分给不同的AI Agent去处理但分工必须清晰。以我最近做的一个数据中台项目为例我同时用了三类Agent需求分析Agent把产品PRD拆成技术任务列表标注优先级和依赖关系代码生成Agent根据技术任务生成实现代码这个环节我用的是AI编码工具配合规范文件测试与审查Agent写单元测试、做代码走查、检查安全漏洞三个Agent各司其职中间通过统一的上下文交换。具体做法是需求分析Agent的输出是一个结构化任务文件包含任务编号、目标描述、涉及模块、验收条件代码生成Agent读取这个任务文件结合规范和代码库上下文生成实现审查Agent再读取实现和任务文件做差异对比和测试执行把结果反馈出来。这套流程跑通之后最大的感受是上下文管理成了比写代码更重要的事情。AI Agent的能力上限取决于它能访问到多少高质量上下文。几个我常用的上下文管理技巧把长期稳定的信息架构决策、规范、接口约定放到独立的文档中按需加载把短期任务相关的信息这次要改什么、涉及哪些文件放到任务描述中把已经做过的事记录下来让后续Agent不需要重复探索很多人在用AI编码工具时遇到的一个典型卡点是——AI生成的代码跟你项目的现有风格不一致。这通常不是模型能力问题而是它没有看到足够的项目上下文。解决方式是给AI补上相关模块的现有代码作为参考哪怕只贴一部分产出的风格匹配度都会大幅提升。说到AI编码工具最近很火的几个我都实测过。Cursor的Autopilot模式上下文管理做得不错能自动索引整库代码并检索相关片段GitHub Copilot workspace在对大型代码库的理解上更强对已有的工程结构把握更准确。不过工具终归是工具关键在于你怎么用它而不是它本身多强。一个我对所有想尝试AI Agent全栈开发的团队的建议不要一开始就搞全自动多Agent流水线那只会让你在调试Agent互相传递的垃圾信息上浪费大量时间。先用单Agent把手动流程跑顺再逐步自动化。我见过太多失败案例不是因为AI能力不行而是因为没搞清楚整个流程之前就急着把所有环节交给Agent导致错误被一级级放大。4. AI全栈开发的项目结构从AI生成代码到AI友好的代码库设计大多数全栈项目都有一个共同特征项目越写越大代码越来越乱。用AI开发的项目还有一个额外的麻烦——AI生成的代码往往是正确但不易维护的因为它不会像老手一样考虑未来三个月的演进方向。这就要求我们在设计项目结构时额外考虑AI友好这一维度。什么是AI友好的代码库我用几个标准来衡量职责清晰每一个模块、组件、函数都有一个明确的、可描述的职责AI通过命名和目录结构就能理解项目组织方式上下文可达相关的代码放在相近的位置AI在分析时不需要跨十几个目录去追踪逻辑状态显式数据流写清楚状态全局管理避免隐式传值让AI能准确推断数据来源和流向这套标准不是玄学是有实际依据的。大模型生成代码是输入上下文→推理→输出代码的过程它能看到的上下文越清晰推理就越准确。如果你把状态藏在各种隐式的地方AI很容易在修改逻辑时漏掉关联点。但如果数据流是单向、显式的AI生成代码时就能顺着数据流推演改起来也稳。我在一个电商项目里做过一次对比测试同一项功能改造在重构前的代码库上AI生成的代码只有40%能直接用重构后这个数字提升到了75%。重构本身没有改变任何功能只是把代码库整理得更AI友好。这个提升非常直观地说明了问题——AI不是万能的但它足够聪明聪明到值得你为它优化环境。具体来说我在项目结构设计上会着重做这几件事用领域模型做目录分层而不是按技术类型分层。比如电商项目我不建controllers、services、models这种目录而是按订单、支付、商品分模块每个模块内部再分层次。AI在处理业务逻辑时相关代码天然在一起读起来方便把类型定义集中管理。给AI一个明确的类型地图它能少走很多弯路用规范文件锁死目录结构。告诉AI哪些代码应该放哪里、什么逻辑应该归哪个模块而不是让它自由想象这样设计还有一个好处当AI Agent要修改某个功能时它能快速锁定影响范围不会碰伤周边无关代码。这也正是全栈项目里最怕出现的问题——AI改一个模块结果把无关模块的功能改坏了。清晰的模块边界是避免这类事故的第一道防线。5. AI编程提示词从写提示词到设计提示系统现在很多讨论把AI编程提示词说得玄乎其玄好像掌握了什么咒语就能让AI写出完美代码。以我用过的实际经验看真正有价值的不是单条提示词写得多漂亮而是你能不能围绕一个项目设计出一套稳定的提示系统。什么是提示系统它不是一句话而是一套结构化的输入组合。我每次让AI开发一个新功能时输入的材料包含项目背景一两段话让AI理解它在做什么项目、为什么做这个项目技术规范标明允许使用的依赖和禁止使用的方案任务描述本次要完成的具体功能参考实现如果项目里有类似的已实现功能贴上一段验收标准什么样的产出算合格这五类材料各有用处缺一个都可能导致质量下降。项目背景让AI理解全局技术规范约束它的选择空间任务描述指明目标参考实现提供风格模板验收标准让它可以自检。关于提示词本身我有几条经过验证的经验第一用任务式陈述不要用命令式。你说给我写一个用户注册接口AI会给你一个孤立接口。但你说实现用户注册功能包含接口、数据库操作、前端表单、错误提示它就会给你一个完整闭环。任务式提示词能激发模型的全局规划能力命令式提示词只会让它机械执行。第二把边界条件说得越具体越好。告诉AI这个表单需要处理用户名为空、密码太短、邮箱格式错误三种情况比做好表单校验好一百倍。AI在处理边界条件的可靠性完全取决于你对边界条件描述得有多详细。第三让AI先复述任务再执行。让AI在第0步先用自己的话描述它对这个任务的理解、准备怎么实现然后再开始写代码。这一步能提前暴露AI理解偏差的问题避免它写了一大堆发现方向错了。第四涉及改代码时贴上前后对比的预期。直接告诉AI改动前接口返回的是A改动后要变成B需要同步更新前端调用处的逻辑它就能意识到这个改动可能有连锁反应。提示系统还有一个很实际的用途就是让团队里的所有人都能用相同的方式指挥AI。我们团队内部会把提示模板沉淀成文档新人来了先看文档然后照着模板提示AI产出的代码质量跟老手差距就小得多。把个人经验变成团队规范这是任何一个AI开发团队走向成熟的必经之路。6. AI基础设施从单机调用API到AI Infra的工程化思维做AI全栈开发光会调API、写提示词是不够的。项目稍微上点规模就得考虑AI基础设施的问题。这个听起来高大上其实核心就是三件事怎么稳定地调用模型、怎么管理好提示词和上下文的版本、怎么做好成本和质量的可观测。先说说模型调用的稳定性。我自己原来写AI功能都是直接调OpenAI的API代码里硬编码API Key。后来项目上线、多人协作之后发现这种方式问题很大——Key泄露风险、模型切换成本高、没法统一做限流重试。后来我换成了LiteLLM Proxy现在圈子里已经很流行把它当作模型API的统一代理层。前端代码只对接LiteLLM Proxy的接口Proxy再去路由到具体的大模型后端。这样换模型供应商改一个配置文件就行不用改业务代码重试、限流、负载均衡这些也可以在Proxy层面统一处理。这里有一句值得记住的话让业务代码依赖模型供应商的SDK是最糟糕的架构决策之一。因为业务逻辑怎么写提示词、怎么处理回复跟基础设施调用哪个模型、怎么计费高度耦合后任何一个调整都牵一发动全身。用Proxy层做隔离等于把做什么和怎么调分开这是AI Infra工程化的第一步。再谈提示词和上下文的版本管理。这可能是最被忽视但坑最多的地方。传统软件里代码有版本控制但在AI应用里提示词和上下文的改动同样会影响行为甚至影响更大。我见过很多团队某天突然发现线上AI功能表现不对排查半天才发现是有人改了提示词没经过验证直接推上线了。我的做法是把提示词模板纳入git管理和代码一起走版本控制。改动提示词必须经过和改代码一样的评审流程。如果将来有条件还可以给提示词做版本对比测试——同一批测试样本分别用旧版提示词和新版提示词跑一遍对比输出质量确保提示词改动是可量化评估的。最后是成本和质量的观测。做AI全栈开发每一笔API调用都是真金白银而且模型质量在变化、token消耗在不同场景下差别很大。我的经验是在上线AI功能的第一个月就建立基础的可观测体系记录每一次调用的模型、输入token数、输出token数、延迟、成本、用户反馈。这些数据是后续优化的依据没有数据所谓的优化只能是拍脑袋。做这类观测最省力的方式是日志打点不用搞得太复杂也不需要接入专门的平台。把自己的日志服务里加几个字段记录模型名称、token用量、耗时、缓存命中情况就够用了后面需要的时候再逐步升级。7. 全栈AI应用的代码走查当AI写完代码你该重点审查哪些环节不能否认一个现实AI写代码已经不是行不行的问题了而是哪里不行的问题。我让AI写的大量代码中逻辑bug其实不多真正的风险集中在几个固定区域。做AI全栈开发的代码审查重点盯这几个地方就够了。第一个要盯的是权限与安全逻辑。AI对这个接口需要鉴权吗这类问题经常理解不到位。我在审查AI代码时会把所有涉及数据访问的入口列出来逐一确认是否做了权限校验。最容易漏的是内部管理接口AI会默认只有管理员能访问所以不用校验这个假设在真实系统里往往不成立。第二个要盯的是输入校验的完整性。AI生成的表单处理逻辑通常只能覆盖正常情况和显而易见的反例对边界条件覆盖很差。审查时要特别留意如果用户传入超大字符串怎么办如果提交的速度特别快导致并发写怎么办如果字段缺失怎么办AI的默认实现往往在这些场景下会直接抛异常或写入脏数据。第三个要盯的是状态管理和副作用。AI对全局状态的处理相对薄弱经常在函数体内部隐式修改全局状态导致排查困难。审查时我会特别关注每个函数是否有明确的输入和输出是否只修改了自己所属模块的状态是否产生了预期的外部副作用第四个要盯的是错误处理策略。AI倾向于遇错抛异常但这在生产环境并不实用。合理的设计是能恢复的错误就恢复不能恢复的错误要带足够上下文的报错信息。AI生成的错误处理代码要么吞掉异常不留痕迹要么把敏感信息直接写在日志里都需要人工做一遍修正。关于审查方式我试过一个比较高效的办法让AI审查AI的代码。让负责代码生成的Agent写完代码后交由另一个负责审查的Agent去检查上述几个风险点输出审查报告。人工再对审查报告做二次判断重点看报告的覆盖面和误报率。两轮下来多数低层问题能提前暴露人工只需要关注架构和业务层面的事。当然最终的责任人永远是你自己。AI生成的代码出了问题不会有人帮你背锅。再高效的审查流程也只能降低风险不能消除风险。这个认知决定了一个团队能不能长期受益于AI开发——那些把AI当甩手掌柜的团队最后都会被隐藏的技术债反噬。8. 可观测性设计AI全栈应用上线后你要看的数据比传统应用多一倍传统全栈应用上线后运维关注的核心指标就那么几个响应时间、错误率、吞吐量、资源占用。但AI全栈应用多了一个维度——模型行为的可观测性。因为你的应用行为一部分由代码决定一部分由模型决定而模型行为是概率性的、会变化的。我在一个客服系统项目里吃过一次大亏。上线时测试效果不错结果运行两周后用户投诉量暴增。排查了半天最后发现是模型供应商更新了版本导致输出风格突变。传统监控一点告警都没报因为系统本身没有报错只是输出内容偏离了预期。从那之后我再也没做过裸奔的AI应用。对于AI全栈应用我要求自己上线前务必建立这些观测点每一次模型调用的入参出参至少要存hash值方便事后回溯问题样本模型输出的质量指标比如用户是否在接收到AI回复后继续追问通常说明第一次回复没解决ta的问题模型响应延迟的分位数分布大模型接口的延迟波动比普通API大得多需要建立独立的SLO成本指标的按功能维度拆分不同功能模块的token消耗差异巨大集中记账很难发现问题这些观测数据不光用于出问题时排查更重要的用途是驱动持续优化。我每月会拉一次AI调用的成本和质量报表找出成本高但转化差的功能模块然后针对性地优化提示词或调整模型选型。AI应用的调优本质上是一个数据驱动的循环每一次调整都要有数据支撑。另外一个很多文章没提过的点要把AI能力的降级方案纳入可观测设计。模型供应商可能随时出问题这跟你的代码质量无关。我的做法是给核心AI功能做降级开关——模型调用失败时自动走一段预设的规则逻辑保证用户至少能得到一个兜底回复而不是一个错误页面。这个降级是否发生过、触发频率多高都要纳入观测。这是做AI全栈应用最实用的保命设计之一。9. 多人协作的AI开发流从个人效率工具到团队协作基础设施当AI编码工具成为团队基础设施而不是个人玩具时很多新问题就浮现了。最典型的问题就是AI改的代码其他成员看不懂怎么办AI产生的变更量太大code review如何进行我在团队里推行了一套名为AI改动可视化的制度核心思想是让AI的每一次改动人类都能快速理解它改了什么、为什么改。具体操作上有三条规则要求AI在提交代码时必须附带说明内容包含需求理解、实现方案、改动的文件清单、已知限制和潜在风险。这些说明直接写入PR描述reviewer看PR时先看说明再看代码限制单次改动范围。不要一次性让AI改十个文件而是拆成一个一个的小任务逐次完成每次改动产生一个独立PR。虽然流程慢一点但review质量和事故率都大幅改善重大架构改动坚持人工先行设计AI后行实施。AI可以参与方案讨论也可以做细节设计但最终架构决策由人来拍板。我这里有一条铁律AI不能在没有明确书面架构决策的情况下重构核心模块还有一个小技巧是对AI产生的代码打上标识比如在文件头部注释里加上generated by AI标记。这样review时对AI生成的代码采取更严格的审查标准对人工改写的代码相对宽松。这个标记不是为了鄙视AI代码而是因为AI代码的风险模式跟人写代码不同需要不同的关注点。多人协作还有一个容易被忽视的问题不同成员对AI的使用水平差异带来的“生产力落差”。熟练的成员让AI代写80%的代码不熟练的成员可能只用了20%的能力代码风格和行为差异会越来越大。解决方式也很简单就是前面提到的提示词模板和规范文件的标准化。让所有成员用同一套规范和提示框架去指挥AI产出质量不会完全一致但至少差距可以控制在一个合理范围内。10. AI全栈开发的项目管理任务拆解粒度与验收标准的工程化设计最后想聊一个听起来不酷但非常关键的话题AI全栈开发下的项目管理方式。传统项目管理拆任务拆到人可以执行的程度就够了。但在AI参与的团队里任务拆解的粒度直接决定了AI编码工具的表现质量。根据我的实测经验AI编码工具最适合的任务粒度是一个一个小时内可实现的完整功能单元。拆得太粗AI容易遗漏实现细节拆得太细上下文切换成本反而大于收益。比如实现用户注册是一个合适的任务但实现用户注册、登录、忘记密码、第三方登录就太大了AI容易做到后半段时把前面的设计决策忘掉。配合任务粒度验收标准的写法也要改变。传统的验收标准是能用就行但AI任务的验收标准要具体到可以自动验证的程度。比如不要写登录功能是好的要写用户输入正确凭据后应返回200和token输入错误密码时应返回401和错误码AUTH_001不要写界面样式合理要写注册页面在375px和1440px宽度下均无横向滚动条按钮最小点击区域44x44px不要写性能达标要写列表接口在1000条数据下P95响应时间小于200ms且首屏渲染无白屏这套方式的好处是AI编码工具生成的代码能不能过关可以用自动化手段直接判定不需要人工主观判断。这才能真正释放AI开发的价值——人类负责定义什么是好AI负责实现好。我还建议在项目管理里为AI任务设置一个专门的上下文预热阶段也就是把任务相关的背景信息、类似实现参考、规范摘录等提前准备好。这个准备工作看起来拖慢了进度但它能有效压缩AI的返工率。我实测过一个数据有预热和没预热的AI任务相比首轮代码可用率从40%提升到70%左右总消耗时间反而下降了。用AI全栈开发项目还有一点跟传统项目不同每次AI调用都在消耗成本所以任务安排的顺序要更讲究。先做风险最高的部分用AI快速验证可行性后做大量重复性的部分用AI规模化生产。把AI用在刀刃上比让AI做所有事更高效也更省钱。11. Agentic CI/CD让AI不只是写代码而是参与构建、测试和发布全流程AI全栈开发做到后面必然要面临一个问题AI写代码只是开始能不能让AI也参与构建、测试和发布我在项目中尝试了逐渐把CI/CD流程的一些环节交给Agent这里分享一些心得。传统的CI/CD流程完全由人工配置和维护依赖关系复杂、脚本又多又长。AI Agent介入后可以承担不少流程工作自动化测试用例的生成AI根据代码变更自动生成针对性测试用例纳入测试套件构建失败的根本原因分析构建报错时AI自动分析日志定位问题比人肉翻日志快得多发布说明的自动生成根据git历史自动生成变更日志和发布说明特别是API变更要标注出来回滚决策辅助新版本出问题时AI可以快速对比新旧版本行为差异辅助确定是否需要回滚这里有个边界问题需要考虑哪些环节适合完全自动化哪些必须留给人来兜底。我目前的规则是构建和测试环节可以全自动发布环节保留人工审批。理由很简单——发布的成本和风险远高于前两个环节一旦出错直接影响生产环境所以发布前保留一道人类审批的环节是必要的。AI可以提供建议和预检结果但按下那个发布按钮的人必须是一个能承担后果的人类。另一个比较实用的场景是AI辅助Code Review。在代码提交后、人工review之前先让AI Agent做一轮自动审查检查风格规范、潜在bug、安全漏洞输出审查意见。人工review时带着AI的审查意见去看效率高很多。实测下来这种方式能让review时间减少大约30%更重要的是能先过滤掉那些低级的送了都觉得不好意思的问题让人类专家把精力集中在真正值得讨论的架构和设计决策上。往更远看一点Agentic CI/CD的终极形态或者说理想形态应该是一个AI开发团队——需求分析Agent、编码Agent、测试Agent、审阅Agent、运维Agent各司其职在人类设定的流水线上协同工作。这种形态现在还有些远多数团队其实用不到这么复杂的建制。但往这个方向逐步演进每一步都能带来实实在在的效率提升。我也是从最基础的自动化测试生成做起一步步把Agent引入到流程的更多环节中的。目标不是让AI取代整个CI/CD而是让AI把流程里那些重复的、可枚举的部分吃掉把人解放出来做更智慧和重要的判断。12. 成本控制与模型选型每个AI全栈项目都必须回答的四个问题做AI全栈项目早晚绕不开一个话题钱。很多AI项目的成本失控不是用量太大而是从一开始的模型选型和调用架构就没规划好。我归纳了每个AI全栈项目都必须回答的四个问题第一这个功能真的需要最强模型吗大部分智能功能用中小模型就足够了。比如做关键词提取、信息摘要、格式转换这些任务用轻量模型性价比极高。只有像复杂推理、长文本理解、代码生成这类高难度任务才需要上旗舰模型。我见过不少项目所有功能一律调用旗舰模型成本是优化后方案的十几倍效果却没差多少。第二能不能用缓存降低成本在很多AI应用里大量用户问的问题是相似甚至完全一样的。在模型调用层加一层语义缓存让相同或高度相似的问题直接走缓存返回结果可以把成本降一个数量级。实现也不复杂把用户输入做embedding后存入向量数据库检索到相似度超过阈值就直接复用历史答案。第三提示词里的上下文能不能精简很多AI应用成本高的原因是提示词里塞了太多不必要的内容。token数直接跟钱挂钩每次多传1000个token一个月下来就是一笔不小的开销。审视上下文是成本优化的最直接手段同时也是效果优化的手段——上下文越精简模型越容易聚焦真正重要的信息。第四是否需要对不同用户做分级免费用户走性价比路线优先使用便宜模型对响应质量要求放低付费用户走旗舰模型提供最好的回答质量。这种分级策略在商业上行得通技术实现也简单。一个Proxy层加上用户维度的路由规则就搞定了。回答完这四个问题大多数AI项目的成本能自然落入一个健康区间。剩下的优化空间就来自每次调用的微观层面比如设置max_tokens上限防止模型胡言乱语浪费token、对长上下文做优雅截断而不是强行塞入……关于模型选型还有一个容易踩的坑不要太早绑定某一家模型供应商。AI模型更新迭代真的太频繁了今天最强的模型三个月后可能就掉队了。如果在架构上做了解耦——业务代码不直接依赖模型SDK而是通过中间层接入——那么切换模型就是一个配置文件的修改。我在前面提到的LiteLLM Proxy这类工具就是做这件事。架构上付出一点点抽象成本换来的是长期的选型自由。这个投入我认为是AI全栈项目里回报率最高的基础设施投资之一。13. 从代码生成到产品交付AI全栈开发者的认知升级路径走到这一步AI全栈开发的工程层面基本聊透了。但最后我还想专门说说人这个层面。因为工具会持续迭代模型能力会不断提升但一个开发者对AI的认知深度决定了他能不能持续从中受益。我的个人经验是AI全栈开发的认知升级大概经过三个阶段第一阶段是工具视角。把AI当成一个超级补全工具写代码时让它补全、debug时让它分析。这个阶段收获的是局部效率提升但没有改变开发的底层方式。第二阶段是协作视角。把AI当成一个协作者学会给它清晰的指令、建立规范约束、设计验证反馈机制。这个阶段收获的是整体效率提升但依然是以人主导、AI辅助的模式工作。第三阶段是生态视角。把AI当成整个开发流程的基础设施从任务拆解、代码生成、测试验证、CI/CD到运维监控全程融入AI能力。这个阶段收获的是质变——项目的上限不再取决于团队里最强的那个人而是取决于整个流程的设计质量。我见过很多团队停留在第一阶段整天研究各种提示词技巧确实也提升了效率但始终无法突破瓶颈。跳出来的关键动作有两个第一个是从让AI做任务转变为为AI设计任务。前者是一次性的、随机性的后者是系统性的、可积累的第二个是从追求生成代码的质量转变为追求开发流程的质量。一个流程如果设计得好AI生成的代码质量自然就高反之再强的模型也救不了混乱的流程现在回头看AI全栈开发给我最大的改变不是写代码更快了而是我思考问题的方式变了。以前我拿到需求的第一反应是这个功能怎么做现在我的第一反应是这个任务的边界是什么、验收标准是什么、需要哪些上下文才能让AI一次做对。这种思维方式的转变让我从执行者变成了设计者。对正在考虑引入AI全栈开发的朋友我的建议是千万别从让AI把现有工作全包了开始一定要从挑一个高频且边界清晰的小任务设计一套让AI能稳定完成的流程开始。等这个流程跑顺了、你摸清了AI的能力边界和失效模式再逐步扩大AI的职责范围。这个过程没有捷径但每一步的积累都会在后面的项目中成倍地还给你。