最近大半年我在好几个团队里都看到同一种分裂一部分人借助AI写代码的速度已经快到让人怀疑人生一天能产出几百行甚至上千行改起需求来像换衣服一样随意另一部分人却越写越慢先画架构图、再定接口、再写设计文档一个接口可能就要磨上一周。两边经常互相看不懂前者觉得后者是效率的敌人后者觉得前者是在给生产环境埋地雷。我把这两种状态分别叫作“游击战”和“阵地战”。这不是贬义而是两种在AI时代都非常重要的编程范式。“游击战”强调小股力量、快速穿插、打了就跑适合用AI去试探未知、验证假设、完成一次性任务“阵地战”强调稳固防线、纵深配置、长期经营适合用AI去维护复杂系统、治理历史包袱、支撑多年迭代的产品。问题的关键从来不是哪种打法更高级而是什么时候用哪一种以及如何在不互相打架的前提下让两种打法共存。这也是我这篇文章想讲清楚的事。无论你是刚入行的新手还是带团队的技术负责人只要你的日常已经离不开AI辅助编程这篇文章都值得看完。1. 我观察到的两种AI编码流派一天能出几百行的人和一周只写一个接口的人1.1 高效但难以收场的“游击式”开发先说说第一种人。他们的典型画像是打开编辑器旁边挂着一个AI对话窗口需求到手先不建工程先让AI“给我一个能跑的Demo”。三十分钟后Demo已经能在本地跑起来了界面、接口、数据流全都有虽然粗糙但确实能点。这种打法在外部看来极度高效。它背后的逻辑是用AI的低边际成本对冲需求的高不确定性。传统开发里需求从“模糊”到“清晰”要经历漫长的沟通、设计、评审而这些环节恰恰是AI可以瞬间完成的——你只需要把模糊的描述变成提示词AI就能帮你生成一个可交互的“靶子”让业务方在这个靶子上继续校准需求。但这种打法有一个致命的软肋很难收场。Demo跑得越爽积累的技术债就越隐蔽。没有模块划分没有错误处理没有测试所有的逻辑全部堆在一个入口文件里AI生成的代码像拼图一样互相咬合改一处功能可能引发三处连锁崩溃。等到产品经理说“这个功能要上线”时游击队员傻眼了——他手里拿的是一块陶土捏出来的模型而不是一栋能住人的房子。1.2 稳定但启动缓慢的“阵地式”开发第二种人则完全相反。他们接手任何任务第一反应不是写代码而是问“这个功能属于哪个域”“上游依赖谁”“下游谁会消费我”“接口的兼容性怎么保证”。他们会花大量时间画时序图、定义数据模型、写接口文档然后在框架的约束下慢慢填充实现。这种打法的价值在长期维护中体现得淋漓尽致。代码库稳定职责清晰新人上手快线上问题容易定位。但其代价也很明显启动速度极慢。在业务方向还一片混沌的早期阵地式开发很容易陷入“过度设计”——你花两周设计出来的架构可能在下一次需求变更中就推倒重来。更有意思的是在AI辅助编程普及之后阵地式开发者的处境反而变得更微妙了。他们发现自己精心设计的架构边界在AI生成代码的“暴力美学”面前显得不堪一击——隔壁游击队员已经用AI把功能跑通了自己还在画第三版流程图。这种反差会让阵地派产生自我怀疑是不是我太守旧了1.3 为什么这个话题现在值得认真对待我之所以想把这两种范式拎出来认真聊是因为AI正在把编程活动的“两极分化”推向极端。以前一个开发者的能力长板决定了他是偏探索还是偏工程团队可以通过分工来互补。但现在AI让“探索”的边际成本降到了几乎为零任何一个普通开发者都可以在十分钟内完成过去需要一整天的探索性编码。这带来一个全新的问题当“试探成本”无限趋近于零时试探的边界在哪里如果所有团队都一股脑地选择游击战代码库会变成一片无法维护的战场废墟如果所有团队都死守阵地战又会错失AI时代最大的效率红利。我认为正确的心态不是二选一而是把这两种范式看作两套可随时切换的“战术包”根据任务的本质属性灵活调用。2. “游击战”的核心逻辑用AI当侦察兵而不是把AI当工程队2.1 游击战的三板斧原型验证、一次性脚本、探索性重构在我自己的实践中AI辅助的游击战主要落在三种场景里这三板斧用好了效率提升是立竿见影的。第一板斧是原型验证。比如团队想引入一个新的检索方案与其花三天搭完整环境不如把需求拆成提示词丢给AI让它基于示例数据生成一个最小可用的检索Demo。如果效果不达标整个投入也就是一个下午如果效果达标再决定要不要把Demo推倒重建。这种打法的核心是“先花小钱验证风险最大的技术点”而不是把技术选型押注在文档和PPT上。第二板斧是一次性脚本。数据迁移、日志清理、批量重命名、临时统计……这些任务的特点是“做完即弃”不需要架构设计不需要单元测试只要结果正确。这类工作我几乎全部甩给AI提示词写清楚输入输出和边界要求生成后人工肉眼审一遍跑完就删。第三板斧是探索性重构。遇到一个完全陌生的代码库时我会让AI先通读一遍目录结构帮我梳理模块依赖和核心数据流。这一步看似简单实际上能帮人节省大量通读源码的时间。你也可以直接提问“这个项目中异常处理是怎么组织的有没有统一的地方给我列出所有抛异常的位置。”AI能快速给出一个待办清单让你在全面重构前做到心里有数。2.2 一套好用的游击式AI提示词打法很多同学觉得AI生成代码“不可控”生成的东西要么跑不动要么不敢用。我自己的经验是问题和AI没关系是提问方式有问题。游击战场景下我有一套固定句式帮我写一个Python脚本读取某个目录下所有CSV文件按文件名里的日期排序合并输出成一个Parquet文件。脚本要能处理文件编码不一致的情况遇到坏行打日志跳过。不需要类封装直接函数式写法注释少一点关键步骤写清楚。这段提示词里有几个关键要素明确的目标、清晰的输入输出、边界条件坏行、风格约束函数式、注释少、细节约束编码。如果你只说“给我写个合并文件的脚本”AI给出的代码大概率覆盖不了真实世界的复杂度。迭代也很重要。AI生成第一版后我通常不会直接拿去用而是继续追问“如果某个文件只有一行你的代码会怎么处理”“这里如果内存爆了怎么办”这种追问式迭代是游击战的精髓——它不是让AI一次性交付一个完美方案而是让AI充当一个反应迅速的侦察兵用几轮对话把问题边界摸透。2.3 游击战红线哪些代码绝对不能只打游击游击战好用的前提是“懂边界”。我给自己定了几条红线踩线的代码无论AI生成得多么丝滑我都不会让它留在项目里不能进入主干分支。游击战产出的代码只能在独立分支、实验目录或者本地环境横跳绝不能直接合入主干。不能碰真实业务数据。所有的验证都要用样例数据或者沙盒环境一旦涉及生产环境的数据读写就必须切换打法。不能改变对外接口。API签名、消息结构、数据库表结构任何一行相关改动都不允许由游击战产出。生命周期不能超过一天。今天生成的探索性代码要么在当天内被清理要么转成交付级代码不允许拖到第二天还躺在工作区里。这四条红线听起来简单实际执行起来很容易破功。因为AI生成的代码“看起来太正常了”人会下意识地降低防备心一不留神就把它当成了生产代码。所以我现在的习惯是游击战代码统一在文件头加一个experimental注释并配套一个定时清理计划。3. “阵地战”的本质把AI改代码的成本变成可计算的确定性3.1 阵地战不是拒绝AI而是给AI划定作战半径很多阵地派在AI时代感到焦虑觉得“架构设计会被AI取代”。我的观点恰恰相反AI越强架构设计的价值越大。游击战的本质是用低成本的试探去换取高密度的信息而阵地战的本质是把这些试探获得的“战果”固化成一整套确定性系统。但阵地战绝不是“不用AI”。恰恰相反我认为阵地战更需要AI只是AI的角色从“侦察兵”变成了“工程队”——它不是去开路而是在你画好的图纸上施工。具体来说阵地战的AI使用方式是在明确的架构边界内生成符合规范的实现代码。举一个最简单的例子。假设我们在做一个支付系统核心的金额计算逻辑、状态机转换、幂等控制这三类代码无论AI怎么建议我都要求手写并经过严格评审。但是周边的DTO定义、数据库访问层的基础CRUD、单元测试模板、配置文件这些机械化程度高的代码完全可以交给AI批量生成。问题不在于“用不用AI”而在于“AI改的是哪一块”。我在某团队推行过一个“作战半径”制度用一个文件把项目里的模块分成三类红区核心业务逻辑AI只能提建议不能直接生成代码。黄区通用基础设施AI可以生成初稿但必须经过架构师评审。绿区样板式代码AI全权生成人工只做抽查。这个制度推行之前团队对AI的态度两极分化严重推行之后两边终于找到了共识AI不是洪水猛兽也不是万能许愿机它是一支需要被指定战场的工程队。3.2 阵地战必备的四个作战工事确定了AI的使用边界之后要想让阵地战真正稳固还需要几样“工事”来保证AI生成的代码不会悄悄越界。我自己最常用的有四个第一是架构约束测试。这类测试不是验证业务功能而是验证代码结构。比如“Controller层不得直接操作数据库”“Service层必须经过领域层接口”这些规则可以直接写成单元测试AI生成的代码无论如何飞舞只要测试跑不过就合不进主干。这比任何代码评审都硬核。第二是契约测试。对于任何对外暴露的接口都要求保留契约测试确保接口签名和数据结构的变更会被显式捕获。AI在“黄区”里折腾实现细节时契约测试像一条看不见的警戒线防止它无意中破坏了API兼容性。第三是全自动的规范检查。格式化、lint、类型检查、复杂度检查全部接入CI流水线不让任何“带病”的代码进入评审环节。AI擅长生成“看似规范”的代码但很多隐患隐藏在命名风格不一致、魔法数字散落、函数过长这些细节里自动化检查是兜底。第四是一套针对AI生成代码的人工检查清单。这个清单很朴素是否处理了异常是否记录了日志是否设置了超时是否有并发隐患是否硬编码了配置每次评审AI生成代码时评审人必须逐项打勾。别嫌它麻烦AI生成的代码在“平均分”上很高真正会咬人的往往是那些平均分掩盖下的极端角落。3.3 一张表看清两种打法的成本结构差异很多人纠结“该用哪种打法”本质上是因为没有把成本结构看清楚。我用一组对比来辅助判断对比维度游击战阵地战启动成本极低一个提示词即可较高需要设计边界与文档信息反馈速度高分钟级低可能要以天计变更灵活性高随时推翻重来低变更需要评估影响面长期维护成本高代码质量靠运气低结构清晰可控风险分布集中在上线前的收尾阶段分散在设计过程中的每个决策核心武器AI的即时生成能力人的架构判断与纪律适合的任务生命周期小时级到周级月级到年级这张表告诉我们两种打法的成本结构恰好互补游击战前便宜后贵阵地战前贵后便宜。聪明的做法不是死守一种而是在不同生命周期阶段主动把代码从一种打法“移交”给另一种打法。4. 选择打法的判据变更半径、存活周期与依赖深度4.1 四个核心判据那怎么判断眼前这个任务到底该用游击战还是阵地战我总结了四个判据每次动手前先过一遍能省下大量对应付错打法的后悔时间。判据一变更频率。这个功能未来三个月会被频繁改动吗如果答案是“会”请直接选择阵地战。因为高变更频率意味着每一次改动都要重新理解代码、重新评估影响面游击战产出的代码在这种场景下会迅速劣化为看不懂的泥潭。反之如果这个功能做完就定型了游击战完全够用。判据二存活周期。这段代码是要跑一次就丢还是要在生产环境里活很多年一次性脚本天然适合游击战核心业务模型天然需要阵地战。最危险的是一些“四不像”任务——看起来是一次性的做完之后却被反复复用这种时候要尽早主动转入阵地战。判据三副作用范围。改动会波及多少其他模块如果只触及一个函数内部游击战没问题如果涉及数据库结构、消息队列、对外接口、分布式事务这些全局副作用会让游击战的低质量成本无限放大必须阵地战。判据四可测试性。代码的正确性能否在短时间内被自动化验证如果可以用单测快速覆盖头铁一点打游击也没关系但如果逻辑要在复杂的分布式环境里才能验证没有完备的设计和测试直接上会极其危险。4.2 从判据到决策三个典型场景推演只看理论容易晕我拿三个真实场景做过拆解方便你直接套用。场景A是“给内部数据平台加一个CSV导出功能”。判据走一遍变更频率中低存活周期中内部工具能用挺久副作用范围小只涉及一个接口和查询逻辑可测试性中等。结论游击战为主但做一点轻量的参数校验和日志收敛好边界就可以交出去。场景B是“电商核心订单模块的支付超时处理”。变更频率高存活周期长副作用范围极大涉及订单状态、库存、支付流程、对账可测试性复杂。结论必须阵地战。这种模块连AI的单行建议都要经过严格讨论更不可能允许AI整段生成。场景C是“清历史遗留的技术债”。这类任务比较微妙探索阶段需要对存量代码做大量信息收集这明显是游击战的强项但重构阶段一旦形成方案就要立刻切换成阵地战。我看到的案例中凡是“一边探索一边顺手改”的基本都翻车了——因为探索期的战术动作和人说了算极容易越改越乱。4.3 团队规模如何影响打法选择除了任务本身的属性团队规模也会影响打法权重。一两百人的团队代码库庞大、人员流动率高阵地战的比例应该显著高于游击战——因为代码的“可交接性”重于“冲刺速度”。三人小团队做内部工具则可以大胆偏向游击战快速试错的价值远超架构优雅性。还要注意一个很多人会忽略的变量团队里AI使用能力的分布。如果大部分成员能熟练驾驭AI阵地战和游击战的切换就能更平滑如果只有少数人在用AI其他人还在传统模式那么过度偏向前者会制造巨大的认知落差。我发现最稳妥的做法是先让团队在小范围内跑通“游击转阵地”的完整流程再逐步扩大AI应用的范围。5. 实战组合拳游击开路、阵地收编的完整流程5.1 一个中型模块的完整作战记录光讲理论没有说服力我复盘一个自己做过的实际模块让大家看看两种打法怎么在同一个项目里无缝衔接。这个模块是某企业内部数据分析平台的“指标自定义计算”业务方提出了新需求我们希望支持用户通过一个表达式引擎在界面上自定义新的统计指标。这个需求方向明确但表达式的语法、优先级、性能特性全都不明朗直接上阵地战设计架构风险很大。第一步游击战原型验证。我先让AI基于一个简化版的表达式解析器生成原型目标是支持“加法、减法、乘法、除法、括号”五种能力并且跑通一组性能测试。AI大概花了二十分钟生成了初版我在本地跑了一遍发现解析器的性能在表达式层级嵌套过深时会指数级劣化。这个信息非常关键直接决定了后续架构选型必须限制表达式深度并引入预编译方案。第二步原型隔离。我把这版原型连同测试数据全部放到experiments/expression-engine目录下在README里写清楚“这是一个探索性原型2024年某月某日之前必须转正或被删除”。这个目录被明确排除在CI之外任何人都能拉下来跑但任何人都不能把它当库引用。第三步启动阵地战。基于原型验证的结论我画出了目标架构一个分层的表达式编译模块包括解析层、AST变换层、字节码生成层、运行时层。然后把接口契约写死词法器输入字符串、输出Token流解析器输入Token流、输出AST编译模块输入AST、输出可执行对象。边界定了之后AI的活就来了。第四步让AI在边界内干活。我让AI分别生成两个Token类型的定义、AST节点的lambda访问器、一个基础的常量折叠优化器。这些任务各自独立、边界清晰AI生成的代码经过单元测试和代码评审后并入主线。真正的核心部分——表达式求值器——我手写并且配了超过60个边界测试。第五步契约与架构测试收编。模块完成后我补上了契约测试和架构约束测试明确禁止后续任何人绕过Compiler接口直接调用Parser内部方法。这一步做完这个模块才算从“游击队的顺手杰作”正式变成了“阵地里的固定工事”。5.2 转换时机的信号与动作这次经历让我总结出了几个“该从游击转阵地”的明确信号。只要出现任意一条就不要再犹豫立刻启动转换流程。原型的某个函数开始被第二个功能复用。当一个代码片段从“验证假设”变成“被依赖的公共能力”时它就已经不是原型了它在事实上已经进入了生产系统的范畴。原型逻辑开始被复制粘贴到其他文件。复制粘贴是代码腐烂的起点如果这种情况发生说明原型的抽象边界已经撑不住了。修改一个功能需要同步改动三个以上文件。这意味着改动成本已经超过了重新设计的成本原地修补只会继续叠加复杂度。其他同事开始问“这段代码是干嘛的”。这标志着代码的可读性已经无法支撑团队协作。一旦决定转换我的固定动作是建新目录、写设计文档、定义接口、把原有代码切成碎片、在边界内重新组装。这个过程的纪律要求很高因为AI可以在十分钟内帮你“平滑迁移”但那样迁移之后代码仍然是一团浆糊。正确姿势是“先破坏再重建”虽然阵痛但转换完成后的稳定性是值得的。5.3 让AI同时服务两种打法的协作规范同一个项目里两种打法共存最怕的就是互相污染。我设计过一套很朴素的协作规范如今已经在团队里跑顺了。代码库的目录结构从顶层就按“作战区域”划分experiments/目录专门放游击战产物默认不合并、不参与部署core/目录是红区任何进入这里的AI生成代码都需要架构师显式批准infra/目录是黄区和绿区AI可以批量生成但提交时必须附带自测结果。其次所有涉及AI生成的PR标题都会有统一前缀[AI-gen]方便评审人第一时间知道这坨代码是“机器施工”的需要额外关注风格与逻辑一致性。《AI生成代码审查清单》挂在PR模板里评审人必须逐项勾选。这两个约定看起来不起眼但极大地降低了团队协作时的认知负担。游击队员知道自己的玩具不会被误当成生产代码阵地队员知道自己的核心模块不会漂移AI工具也能在清晰的战区内发挥最大价值。6. 我在切换打法中踩过的坑三种最容易翻车的打法错配6.1 把阵地战打成游击战架构重构随手交给AI第一次严重翻车事故发生在一次核心流程重构上。当时我负责梳理一个老系统的订单状态转换流程旧代码里嵌套了大量if-else逻辑分支多到人脑无法梳理。我当时的想法很天真“让AI帮我把它重构成状态机模式效率肯定高。”于是我把整个文件丢给AI要求生成新版状态机代码。AI很快就生成了看起来异常工整的状态机实现测试也跑通了我信心满满地提交。结果上线第二周就出了事故一个极老的订单在某种边缘时序下走入了错误的转换分支导致订单状态从“已完成”倒退回“待支付”。排查了一整天才发现AI在重构时“自作聪明”地合并了两个语义不同的状态因为它们在代码层面看起来过于相似。这次事故让我彻底明白了状态机、并发控制、金额计算这类“魔鬼在细节里”的领域不管AI如何自信都必须打阵地战。重构这类高危模块正确做法是先把状态转移矩阵手工画出来让AI只负责填充无关紧要的分支逻辑核心矩阵必须由人来敲定。6.2 把游击战打成阵地战原型代码被直接推进生产另一类翻车是反过来原型代码被“顺手”推上了生产。当时团队里有个A同学习惯让AI生成工具脚本。有一次他写了一个配置解析脚本本意是临时用一下结果这个脚本被集成到一个自动化部署流程里还因为“跑得没问题”而上了生产。三个月后这个脚本的缺陷集中爆发了没有处理配置文件编码的兼容性、没有打印日志、错误处理直接吞异常。最要命的是它硬编码了一个临时目录路径上线后一换环境就报错。A同学自己都忘了这段代码是怎么写的了因为AI生成后他就没细看。最后整整花了两天去回溯所有历史提交才把这段“僵尸代码”从部署流水线里挖出来。这个案例的教训是原型代码进入生产必须走一次“脱胎换骨”的过程而不是“包一层壳”。你可以在原型上快速验证假设但验证完之后必须重新按照阵地战标准重写一遍——哪怕AI告诉你“可以直接用”也要人为制造一次“推倒重来”的仪式感。这不是流程繁文缛节而是给那些草率的生成代码一个官方的“审查刑场”。6.3 两种打法互相污染团队里没有明确的边界共识最后一类翻车最隐蔽属于“慢性病”。团队一开始没有明确的区域划分AI生成代码满天飞一开始看没毛病代码量上去了之后问题开始呈现有的目录写着核心服务里面的代码却是AI现场生成的“野路子”有的实验脚本被其他模块当成依赖引入一删就牵连爆炸。我接手过一次这样的烂摊子花了两个迭代才把代码库结构重新理顺。后来推行了作战区域划分和PR标签约定情况才逐步好转。现在回看最根本的问题不在代码而在于团队没有就“什么代码可以被AI随意生成”达成共识。有人觉得AI写的能跑就行有人觉得“我的模块必须全手写”两边互相扯皮最终形成了一片灰色地带。如果你也发现自己所在的项目出现了“AI生成的代码密度过高且没有人说得清责任边界”那就是需要在团队层面定规矩的信号。这个规矩不是限制AI恰恰是为了让AI能在有边界的地方跑得更快——就像阵地战的价值不是拒绝敌军的冲锋而是让我军的防线能承受住更猛烈的攻击。我在实际切换打法的时候最深的体会是两种打法并不是非此即彼的阵营而是同一张作战地图上的不同战术状态。真正成熟的团队不是分成“游击队”和“阵地派”两拨人而是能够让同一个人、在同一个项目里上午用游击战验证一个接口的可行性下午用阵地战把它固化到可维护的架构里。AI时代给我们的不是一套更省事的编程方式而是一种更频繁地在两种范式之间切换的能力。这种能力本身才是这个时代稀缺的方法论资产。
最近大半年我在好几个团队里都看到同一种分裂一部分人借助AI写代码的速度已经快到让人怀疑人生一天能产出几百行甚至上千行改起需求来像换衣服一样随意另一部分人却越写越慢先画架构图、再定接口、再写设计文档一个接口可能就要磨上一周。两边经常互相看不懂前者觉得后者是效率的敌人后者觉得前者是在给生产环境埋地雷。我把这两种状态分别叫作“游击战”和“阵地战”。这不是贬义而是两种在AI时代都非常重要的编程范式。“游击战”强调小股力量、快速穿插、打了就跑适合用AI去试探未知、验证假设、完成一次性任务“阵地战”强调稳固防线、纵深配置、长期经营适合用AI去维护复杂系统、治理历史包袱、支撑多年迭代的产品。问题的关键从来不是哪种打法更高级而是什么时候用哪一种以及如何在不互相打架的前提下让两种打法共存。这也是我这篇文章想讲清楚的事。无论你是刚入行的新手还是带团队的技术负责人只要你的日常已经离不开AI辅助编程这篇文章都值得看完。1. 我观察到的两种AI编码流派一天能出几百行的人和一周只写一个接口的人1.1 高效但难以收场的“游击式”开发先说说第一种人。他们的典型画像是打开编辑器旁边挂着一个AI对话窗口需求到手先不建工程先让AI“给我一个能跑的Demo”。三十分钟后Demo已经能在本地跑起来了界面、接口、数据流全都有虽然粗糙但确实能点。这种打法在外部看来极度高效。它背后的逻辑是用AI的低边际成本对冲需求的高不确定性。传统开发里需求从“模糊”到“清晰”要经历漫长的沟通、设计、评审而这些环节恰恰是AI可以瞬间完成的——你只需要把模糊的描述变成提示词AI就能帮你生成一个可交互的“靶子”让业务方在这个靶子上继续校准需求。但这种打法有一个致命的软肋很难收场。Demo跑得越爽积累的技术债就越隐蔽。没有模块划分没有错误处理没有测试所有的逻辑全部堆在一个入口文件里AI生成的代码像拼图一样互相咬合改一处功能可能引发三处连锁崩溃。等到产品经理说“这个功能要上线”时游击队员傻眼了——他手里拿的是一块陶土捏出来的模型而不是一栋能住人的房子。1.2 稳定但启动缓慢的“阵地式”开发第二种人则完全相反。他们接手任何任务第一反应不是写代码而是问“这个功能属于哪个域”“上游依赖谁”“下游谁会消费我”“接口的兼容性怎么保证”。他们会花大量时间画时序图、定义数据模型、写接口文档然后在框架的约束下慢慢填充实现。这种打法的价值在长期维护中体现得淋漓尽致。代码库稳定职责清晰新人上手快线上问题容易定位。但其代价也很明显启动速度极慢。在业务方向还一片混沌的早期阵地式开发很容易陷入“过度设计”——你花两周设计出来的架构可能在下一次需求变更中就推倒重来。更有意思的是在AI辅助编程普及之后阵地式开发者的处境反而变得更微妙了。他们发现自己精心设计的架构边界在AI生成代码的“暴力美学”面前显得不堪一击——隔壁游击队员已经用AI把功能跑通了自己还在画第三版流程图。这种反差会让阵地派产生自我怀疑是不是我太守旧了1.3 为什么这个话题现在值得认真对待我之所以想把这两种范式拎出来认真聊是因为AI正在把编程活动的“两极分化”推向极端。以前一个开发者的能力长板决定了他是偏探索还是偏工程团队可以通过分工来互补。但现在AI让“探索”的边际成本降到了几乎为零任何一个普通开发者都可以在十分钟内完成过去需要一整天的探索性编码。这带来一个全新的问题当“试探成本”无限趋近于零时试探的边界在哪里如果所有团队都一股脑地选择游击战代码库会变成一片无法维护的战场废墟如果所有团队都死守阵地战又会错失AI时代最大的效率红利。我认为正确的心态不是二选一而是把这两种范式看作两套可随时切换的“战术包”根据任务的本质属性灵活调用。2. “游击战”的核心逻辑用AI当侦察兵而不是把AI当工程队2.1 游击战的三板斧原型验证、一次性脚本、探索性重构在我自己的实践中AI辅助的游击战主要落在三种场景里这三板斧用好了效率提升是立竿见影的。第一板斧是原型验证。比如团队想引入一个新的检索方案与其花三天搭完整环境不如把需求拆成提示词丢给AI让它基于示例数据生成一个最小可用的检索Demo。如果效果不达标整个投入也就是一个下午如果效果达标再决定要不要把Demo推倒重建。这种打法的核心是“先花小钱验证风险最大的技术点”而不是把技术选型押注在文档和PPT上。第二板斧是一次性脚本。数据迁移、日志清理、批量重命名、临时统计……这些任务的特点是“做完即弃”不需要架构设计不需要单元测试只要结果正确。这类工作我几乎全部甩给AI提示词写清楚输入输出和边界要求生成后人工肉眼审一遍跑完就删。第三板斧是探索性重构。遇到一个完全陌生的代码库时我会让AI先通读一遍目录结构帮我梳理模块依赖和核心数据流。这一步看似简单实际上能帮人节省大量通读源码的时间。你也可以直接提问“这个项目中异常处理是怎么组织的有没有统一的地方给我列出所有抛异常的位置。”AI能快速给出一个待办清单让你在全面重构前做到心里有数。2.2 一套好用的游击式AI提示词打法很多同学觉得AI生成代码“不可控”生成的东西要么跑不动要么不敢用。我自己的经验是问题和AI没关系是提问方式有问题。游击战场景下我有一套固定句式帮我写一个Python脚本读取某个目录下所有CSV文件按文件名里的日期排序合并输出成一个Parquet文件。脚本要能处理文件编码不一致的情况遇到坏行打日志跳过。不需要类封装直接函数式写法注释少一点关键步骤写清楚。这段提示词里有几个关键要素明确的目标、清晰的输入输出、边界条件坏行、风格约束函数式、注释少、细节约束编码。如果你只说“给我写个合并文件的脚本”AI给出的代码大概率覆盖不了真实世界的复杂度。迭代也很重要。AI生成第一版后我通常不会直接拿去用而是继续追问“如果某个文件只有一行你的代码会怎么处理”“这里如果内存爆了怎么办”这种追问式迭代是游击战的精髓——它不是让AI一次性交付一个完美方案而是让AI充当一个反应迅速的侦察兵用几轮对话把问题边界摸透。2.3 游击战红线哪些代码绝对不能只打游击游击战好用的前提是“懂边界”。我给自己定了几条红线踩线的代码无论AI生成得多么丝滑我都不会让它留在项目里不能进入主干分支。游击战产出的代码只能在独立分支、实验目录或者本地环境横跳绝不能直接合入主干。不能碰真实业务数据。所有的验证都要用样例数据或者沙盒环境一旦涉及生产环境的数据读写就必须切换打法。不能改变对外接口。API签名、消息结构、数据库表结构任何一行相关改动都不允许由游击战产出。生命周期不能超过一天。今天生成的探索性代码要么在当天内被清理要么转成交付级代码不允许拖到第二天还躺在工作区里。这四条红线听起来简单实际执行起来很容易破功。因为AI生成的代码“看起来太正常了”人会下意识地降低防备心一不留神就把它当成了生产代码。所以我现在的习惯是游击战代码统一在文件头加一个experimental注释并配套一个定时清理计划。3. “阵地战”的本质把AI改代码的成本变成可计算的确定性3.1 阵地战不是拒绝AI而是给AI划定作战半径很多阵地派在AI时代感到焦虑觉得“架构设计会被AI取代”。我的观点恰恰相反AI越强架构设计的价值越大。游击战的本质是用低成本的试探去换取高密度的信息而阵地战的本质是把这些试探获得的“战果”固化成一整套确定性系统。但阵地战绝不是“不用AI”。恰恰相反我认为阵地战更需要AI只是AI的角色从“侦察兵”变成了“工程队”——它不是去开路而是在你画好的图纸上施工。具体来说阵地战的AI使用方式是在明确的架构边界内生成符合规范的实现代码。举一个最简单的例子。假设我们在做一个支付系统核心的金额计算逻辑、状态机转换、幂等控制这三类代码无论AI怎么建议我都要求手写并经过严格评审。但是周边的DTO定义、数据库访问层的基础CRUD、单元测试模板、配置文件这些机械化程度高的代码完全可以交给AI批量生成。问题不在于“用不用AI”而在于“AI改的是哪一块”。我在某团队推行过一个“作战半径”制度用一个文件把项目里的模块分成三类红区核心业务逻辑AI只能提建议不能直接生成代码。黄区通用基础设施AI可以生成初稿但必须经过架构师评审。绿区样板式代码AI全权生成人工只做抽查。这个制度推行之前团队对AI的态度两极分化严重推行之后两边终于找到了共识AI不是洪水猛兽也不是万能许愿机它是一支需要被指定战场的工程队。3.2 阵地战必备的四个作战工事确定了AI的使用边界之后要想让阵地战真正稳固还需要几样“工事”来保证AI生成的代码不会悄悄越界。我自己最常用的有四个第一是架构约束测试。这类测试不是验证业务功能而是验证代码结构。比如“Controller层不得直接操作数据库”“Service层必须经过领域层接口”这些规则可以直接写成单元测试AI生成的代码无论如何飞舞只要测试跑不过就合不进主干。这比任何代码评审都硬核。第二是契约测试。对于任何对外暴露的接口都要求保留契约测试确保接口签名和数据结构的变更会被显式捕获。AI在“黄区”里折腾实现细节时契约测试像一条看不见的警戒线防止它无意中破坏了API兼容性。第三是全自动的规范检查。格式化、lint、类型检查、复杂度检查全部接入CI流水线不让任何“带病”的代码进入评审环节。AI擅长生成“看似规范”的代码但很多隐患隐藏在命名风格不一致、魔法数字散落、函数过长这些细节里自动化检查是兜底。第四是一套针对AI生成代码的人工检查清单。这个清单很朴素是否处理了异常是否记录了日志是否设置了超时是否有并发隐患是否硬编码了配置每次评审AI生成代码时评审人必须逐项打勾。别嫌它麻烦AI生成的代码在“平均分”上很高真正会咬人的往往是那些平均分掩盖下的极端角落。3.3 一张表看清两种打法的成本结构差异很多人纠结“该用哪种打法”本质上是因为没有把成本结构看清楚。我用一组对比来辅助判断对比维度游击战阵地战启动成本极低一个提示词即可较高需要设计边界与文档信息反馈速度高分钟级低可能要以天计变更灵活性高随时推翻重来低变更需要评估影响面长期维护成本高代码质量靠运气低结构清晰可控风险分布集中在上线前的收尾阶段分散在设计过程中的每个决策核心武器AI的即时生成能力人的架构判断与纪律适合的任务生命周期小时级到周级月级到年级这张表告诉我们两种打法的成本结构恰好互补游击战前便宜后贵阵地战前贵后便宜。聪明的做法不是死守一种而是在不同生命周期阶段主动把代码从一种打法“移交”给另一种打法。4. 选择打法的判据变更半径、存活周期与依赖深度4.1 四个核心判据那怎么判断眼前这个任务到底该用游击战还是阵地战我总结了四个判据每次动手前先过一遍能省下大量对应付错打法的后悔时间。判据一变更频率。这个功能未来三个月会被频繁改动吗如果答案是“会”请直接选择阵地战。因为高变更频率意味着每一次改动都要重新理解代码、重新评估影响面游击战产出的代码在这种场景下会迅速劣化为看不懂的泥潭。反之如果这个功能做完就定型了游击战完全够用。判据二存活周期。这段代码是要跑一次就丢还是要在生产环境里活很多年一次性脚本天然适合游击战核心业务模型天然需要阵地战。最危险的是一些“四不像”任务——看起来是一次性的做完之后却被反复复用这种时候要尽早主动转入阵地战。判据三副作用范围。改动会波及多少其他模块如果只触及一个函数内部游击战没问题如果涉及数据库结构、消息队列、对外接口、分布式事务这些全局副作用会让游击战的低质量成本无限放大必须阵地战。判据四可测试性。代码的正确性能否在短时间内被自动化验证如果可以用单测快速覆盖头铁一点打游击也没关系但如果逻辑要在复杂的分布式环境里才能验证没有完备的设计和测试直接上会极其危险。4.2 从判据到决策三个典型场景推演只看理论容易晕我拿三个真实场景做过拆解方便你直接套用。场景A是“给内部数据平台加一个CSV导出功能”。判据走一遍变更频率中低存活周期中内部工具能用挺久副作用范围小只涉及一个接口和查询逻辑可测试性中等。结论游击战为主但做一点轻量的参数校验和日志收敛好边界就可以交出去。场景B是“电商核心订单模块的支付超时处理”。变更频率高存活周期长副作用范围极大涉及订单状态、库存、支付流程、对账可测试性复杂。结论必须阵地战。这种模块连AI的单行建议都要经过严格讨论更不可能允许AI整段生成。场景C是“清历史遗留的技术债”。这类任务比较微妙探索阶段需要对存量代码做大量信息收集这明显是游击战的强项但重构阶段一旦形成方案就要立刻切换成阵地战。我看到的案例中凡是“一边探索一边顺手改”的基本都翻车了——因为探索期的战术动作和人说了算极容易越改越乱。4.3 团队规模如何影响打法选择除了任务本身的属性团队规模也会影响打法权重。一两百人的团队代码库庞大、人员流动率高阵地战的比例应该显著高于游击战——因为代码的“可交接性”重于“冲刺速度”。三人小团队做内部工具则可以大胆偏向游击战快速试错的价值远超架构优雅性。还要注意一个很多人会忽略的变量团队里AI使用能力的分布。如果大部分成员能熟练驾驭AI阵地战和游击战的切换就能更平滑如果只有少数人在用AI其他人还在传统模式那么过度偏向前者会制造巨大的认知落差。我发现最稳妥的做法是先让团队在小范围内跑通“游击转阵地”的完整流程再逐步扩大AI应用的范围。5. 实战组合拳游击开路、阵地收编的完整流程5.1 一个中型模块的完整作战记录光讲理论没有说服力我复盘一个自己做过的实际模块让大家看看两种打法怎么在同一个项目里无缝衔接。这个模块是某企业内部数据分析平台的“指标自定义计算”业务方提出了新需求我们希望支持用户通过一个表达式引擎在界面上自定义新的统计指标。这个需求方向明确但表达式的语法、优先级、性能特性全都不明朗直接上阵地战设计架构风险很大。第一步游击战原型验证。我先让AI基于一个简化版的表达式解析器生成原型目标是支持“加法、减法、乘法、除法、括号”五种能力并且跑通一组性能测试。AI大概花了二十分钟生成了初版我在本地跑了一遍发现解析器的性能在表达式层级嵌套过深时会指数级劣化。这个信息非常关键直接决定了后续架构选型必须限制表达式深度并引入预编译方案。第二步原型隔离。我把这版原型连同测试数据全部放到experiments/expression-engine目录下在README里写清楚“这是一个探索性原型2024年某月某日之前必须转正或被删除”。这个目录被明确排除在CI之外任何人都能拉下来跑但任何人都不能把它当库引用。第三步启动阵地战。基于原型验证的结论我画出了目标架构一个分层的表达式编译模块包括解析层、AST变换层、字节码生成层、运行时层。然后把接口契约写死词法器输入字符串、输出Token流解析器输入Token流、输出AST编译模块输入AST、输出可执行对象。边界定了之后AI的活就来了。第四步让AI在边界内干活。我让AI分别生成两个Token类型的定义、AST节点的lambda访问器、一个基础的常量折叠优化器。这些任务各自独立、边界清晰AI生成的代码经过单元测试和代码评审后并入主线。真正的核心部分——表达式求值器——我手写并且配了超过60个边界测试。第五步契约与架构测试收编。模块完成后我补上了契约测试和架构约束测试明确禁止后续任何人绕过Compiler接口直接调用Parser内部方法。这一步做完这个模块才算从“游击队的顺手杰作”正式变成了“阵地里的固定工事”。5.2 转换时机的信号与动作这次经历让我总结出了几个“该从游击转阵地”的明确信号。只要出现任意一条就不要再犹豫立刻启动转换流程。原型的某个函数开始被第二个功能复用。当一个代码片段从“验证假设”变成“被依赖的公共能力”时它就已经不是原型了它在事实上已经进入了生产系统的范畴。原型逻辑开始被复制粘贴到其他文件。复制粘贴是代码腐烂的起点如果这种情况发生说明原型的抽象边界已经撑不住了。修改一个功能需要同步改动三个以上文件。这意味着改动成本已经超过了重新设计的成本原地修补只会继续叠加复杂度。其他同事开始问“这段代码是干嘛的”。这标志着代码的可读性已经无法支撑团队协作。一旦决定转换我的固定动作是建新目录、写设计文档、定义接口、把原有代码切成碎片、在边界内重新组装。这个过程的纪律要求很高因为AI可以在十分钟内帮你“平滑迁移”但那样迁移之后代码仍然是一团浆糊。正确姿势是“先破坏再重建”虽然阵痛但转换完成后的稳定性是值得的。5.3 让AI同时服务两种打法的协作规范同一个项目里两种打法共存最怕的就是互相污染。我设计过一套很朴素的协作规范如今已经在团队里跑顺了。代码库的目录结构从顶层就按“作战区域”划分experiments/目录专门放游击战产物默认不合并、不参与部署core/目录是红区任何进入这里的AI生成代码都需要架构师显式批准infra/目录是黄区和绿区AI可以批量生成但提交时必须附带自测结果。其次所有涉及AI生成的PR标题都会有统一前缀[AI-gen]方便评审人第一时间知道这坨代码是“机器施工”的需要额外关注风格与逻辑一致性。《AI生成代码审查清单》挂在PR模板里评审人必须逐项勾选。这两个约定看起来不起眼但极大地降低了团队协作时的认知负担。游击队员知道自己的玩具不会被误当成生产代码阵地队员知道自己的核心模块不会漂移AI工具也能在清晰的战区内发挥最大价值。6. 我在切换打法中踩过的坑三种最容易翻车的打法错配6.1 把阵地战打成游击战架构重构随手交给AI第一次严重翻车事故发生在一次核心流程重构上。当时我负责梳理一个老系统的订单状态转换流程旧代码里嵌套了大量if-else逻辑分支多到人脑无法梳理。我当时的想法很天真“让AI帮我把它重构成状态机模式效率肯定高。”于是我把整个文件丢给AI要求生成新版状态机代码。AI很快就生成了看起来异常工整的状态机实现测试也跑通了我信心满满地提交。结果上线第二周就出了事故一个极老的订单在某种边缘时序下走入了错误的转换分支导致订单状态从“已完成”倒退回“待支付”。排查了一整天才发现AI在重构时“自作聪明”地合并了两个语义不同的状态因为它们在代码层面看起来过于相似。这次事故让我彻底明白了状态机、并发控制、金额计算这类“魔鬼在细节里”的领域不管AI如何自信都必须打阵地战。重构这类高危模块正确做法是先把状态转移矩阵手工画出来让AI只负责填充无关紧要的分支逻辑核心矩阵必须由人来敲定。6.2 把游击战打成阵地战原型代码被直接推进生产另一类翻车是反过来原型代码被“顺手”推上了生产。当时团队里有个A同学习惯让AI生成工具脚本。有一次他写了一个配置解析脚本本意是临时用一下结果这个脚本被集成到一个自动化部署流程里还因为“跑得没问题”而上了生产。三个月后这个脚本的缺陷集中爆发了没有处理配置文件编码的兼容性、没有打印日志、错误处理直接吞异常。最要命的是它硬编码了一个临时目录路径上线后一换环境就报错。A同学自己都忘了这段代码是怎么写的了因为AI生成后他就没细看。最后整整花了两天去回溯所有历史提交才把这段“僵尸代码”从部署流水线里挖出来。这个案例的教训是原型代码进入生产必须走一次“脱胎换骨”的过程而不是“包一层壳”。你可以在原型上快速验证假设但验证完之后必须重新按照阵地战标准重写一遍——哪怕AI告诉你“可以直接用”也要人为制造一次“推倒重来”的仪式感。这不是流程繁文缛节而是给那些草率的生成代码一个官方的“审查刑场”。6.3 两种打法互相污染团队里没有明确的边界共识最后一类翻车最隐蔽属于“慢性病”。团队一开始没有明确的区域划分AI生成代码满天飞一开始看没毛病代码量上去了之后问题开始呈现有的目录写着核心服务里面的代码却是AI现场生成的“野路子”有的实验脚本被其他模块当成依赖引入一删就牵连爆炸。我接手过一次这样的烂摊子花了两个迭代才把代码库结构重新理顺。后来推行了作战区域划分和PR标签约定情况才逐步好转。现在回看最根本的问题不在代码而在于团队没有就“什么代码可以被AI随意生成”达成共识。有人觉得AI写的能跑就行有人觉得“我的模块必须全手写”两边互相扯皮最终形成了一片灰色地带。如果你也发现自己所在的项目出现了“AI生成的代码密度过高且没有人说得清责任边界”那就是需要在团队层面定规矩的信号。这个规矩不是限制AI恰恰是为了让AI能在有边界的地方跑得更快——就像阵地战的价值不是拒绝敌军的冲锋而是让我军的防线能承受住更猛烈的攻击。我在实际切换打法的时候最深的体会是两种打法并不是非此即彼的阵营而是同一张作战地图上的不同战术状态。真正成熟的团队不是分成“游击队”和“阵地派”两拨人而是能够让同一个人、在同一个项目里上午用游击战验证一个接口的可行性下午用阵地战把它固化到可维护的架构里。AI时代给我们的不是一套更省事的编程方式而是一种更频繁地在两种范式之间切换的能力。这种能力本身才是这个时代稀缺的方法论资产。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
