现在的人用AI来写代码, 效率有高有低, 差得很多。光靠改提示词是没法解决代码仓库质量差的根本问题的。真正能提高效率的关键原因, 还是软件工程的基本功。当你打开技术社区的时候, 你会发现到处都是那种“AI抹平开发门槛”以及“代码已经变得廉价”这样的说法, 大家仿佛是只要学会了如何去描述自己的需求, 那么普通人也就能够来完成软件的开发工作这一点, 这就使得传统软件工程的一套方法论, 看起来就已经变成了一种过时的旧时代的产物了。但是实际项目的场景是完全反过来的, 有很多团队接入人工智能辅助开发以后, 短时间内看产量好像是大大的增加了, 不过过了一段时间之后情况却变得越来越难以控制了, 代码文件变得碎片的程度越来越严重, 各种依赖关系复杂得一塌糊涂, 错误和问题不断地冒出来, 修改一个小地方的代码就会波及到整个工程的很大部分, 工程师们的大部分时间没有花在开发新的功能上, 反而是花在了清理由人工智能生成代码所带来的混乱上面。领域知名研究者 Matt , 在将近一年的时间里, 一直都在持续观察很多开发者使用 AI 智能体来完成那些真实的业务项目, 他看到了很多组可以进行对比的案例, 在这些案例里, 硬件环境都是一样的, 使用的模型版本也都是一致的, 具体的业务需求完全是相同的状态, 但有的开发者只需要四十分钟就能把那个需求给完成了, 还顺便把测试用例也给补上了, 而有的开发者呢, 从上班一直到下班都在里面折腾来折腾去, 搞出来的代码是越来越臃肿了, 到了最后这个局面之下, 最后只能做一个回退的操作, 回到了几天前的时候那个还没有接入 AI 的版本上面去了。巨大的效率鸿沟, 它的根源并不在于是不是谁的提示词写得更加华丽, 也并非体现在去选择那些价格更为昂贵的大模型之上。Matt得出了一个非常具有反向直觉特点的结论, 这个结论表明人工智能不具备平衡的作用, 它仅仅是一个放大的工具, 它并不会抹去代码库原本所存在的那些缺陷情况, 却只能够将代码库原先所展现出的面貌给成倍地放大开来, 至于软件工程中最为基本的那些功夫技能, 其价值非但没有发生贬值的现象, 相反地却被赋予了此前从未有过的一种杠杆式的影响力效应。人工智能可以用来搞定像敲代码这样的战术层面的具体工作, 但是代码的所有权这件事情, 必须得让开发者牢牢地把它掌握在自己手里。我们倒是不需要一行接着一行地去手动敲打每一段代码, 可是呢, 我们必须得做到能够随时看得懂、可以随意修改、并且有能力去接管整套代码系统这回事儿。万一要是把代码的控制权给彻彻底底地交给了AI的话, 那么就算那个模型再强大, 也没办法阻止技术债务这种东西以疯狂的速度不断累积起来这个事情。别陷入误区“写规格自动生成代码”是伪装成新范式的旧陷阱眼下存在一种特别受青睐的开发做法, 就是先整理出一份详细得要命的规格说明文件, 然后把这份文件交给人工智能, 让它直接把完整的代码给生产出来, 要是发现出现了程序错误或者是有了新的需求变更, 也绝对不去动那些已经产生出来的代码, 只管去修改那份文档, 然后再次让模型把程序内容重新输出一个遍, 拥护这个方法的人群会把这一整套操作过程跟当初汇编语言升级到高级语言的过程做对比, 他们觉得在这个环节里人类仅仅需要专注于把文档写好这件事情就行, 至于编码工作那就完全可以全部放手丢给机器去完成。乍一听, 这个情形确实显得挺美好的, 就好像说软件开发就要进到一种由文档来驱动的那种全自动的一个时代里面去了。不过, Matt自己亲自去跑完了三轮那个完整的迭代流程之后, 他就非常坚定地放弃掉了这一套流程安排。在第一个阶段生成的那些代码, 还是说能够在某种程度上正常的运行起来的可是到了第二轮的那个迭代工作里面的话, 质量就会出现一个特别明显的往下降了的情况了而如果要一直延续到第三轮结束的时候, 那时候所生产出来的那些代码里面的风险就已经变得过高了, 高到已经完全没有办法再去把他们投入到实际的营业环境里面去使用了。从本质上进行分析, 这样一种由文档用来驱动代码生成的工作模式, 它与行业内备受争议的感觉式编码在内部逻辑上属于同一类事物的不同表现形态, 仅仅是在外在形式上进行了一些变换。其存在的主要问题在于, 这种做法选择放弃人类对源代码所拥有的全部控制权, 进而将系统功能的实际构建过程完全地、毫无保留地交由大型语言模型凭借自身能力去随意展开并实现最终结果。许多人存在一种误解, 认为既然人工智能技术能够直接生成相关的代码程序, 那么代码文件本身的商业价值就会大幅度降低, 以至于一旦编写出现错误或者逻辑漏洞, 操作人员就只需要重新调用工具生成一份新的版本即可, 从而无需承担额外的修正成本。可是当前的客观实际情况完全背离了这一假设。普通类型的应用代码虽然在初始阶段的生成效率很高且总体投入成本极低, 但是由混乱不堪的结构和糟糕的逻辑所组成的劣质软件资产, 实际上构成了整个计算机软件开发与工程行业当中耗费资源最多、导致损失最大的核心负担。在那些整理得整整齐齐、安排得井井有条的代码仓库这里头, 人工智能啊那是如同插上了翅膀的猛虎一样, 能够把迭代的步伐给迅速加快, 而对于那些原本架构就变得混乱不堪、名称取得随意至极、界限模糊不清的那些项目而言, 人工智能则仅仅是在放大所有历史遗留下来的那些问题的同时, 去制造更多耦合关系以及碎片化逻辑的状况, 进而一步步抬高后续维护所需付出的成本, 因为对于大模型那种存在来讲, 它们是无法凭空创造出方法来修复代码库底层结构上存在的各种缺陷的这一点是明确的, 不管是提示词被优化的过程也罢, 还是更换更加强大模型的行为也算罢, 全都无法填补工程底子之上所存在的那些短板的。过去, 有一个项目爆火过, 那个项目的全文只有字, 没有一行能运行的代码, 上线短短的时间里就收到了三万多颗星星, 这个由Matt维护的文档之所以这么火, 并不是因为它提供了神奇的咒语, 而是它戳破了行业的幻想, 在AI这个时代, 真正值钱的其实不是生成代码的那个技巧, 而是几十年的沉淀所积累下来的软件工程思维。在项目进行开发的整个过程当中存在着六个比较常见的错误陷阱。AI协作路上的隐形绊脚石在和人工智能智能体一起搞协同开发的那个完整过程里面, 那些让人头疼的坑点, 是分布在需求去对齐、代码去实现、还有规模去扩张这三个不一样的阶段上面的。好多团队在踩过坑之后, 第一个蹦出来的反应, 是去把模型的参数给调一下, 或者是把提示词给优化优化, 可是实际上绝大部分的问题, 它们的根源都来自于人和人工智能之间, 协作机制这一块东西的缺失。下面这个部分, 要结合项目实践的情况, 把在那个开发全流程里面, 频繁遇到且又很典型的那六个大问题的具体情况拆解给大家看, 再把针对这些问题的一套一套解决办法的想法也拆给大家看。阶段一编码尚未启动风险已经埋下还没写下第一行代码, 误解和偏差就已经悄悄埋下了。陷阱 1脑海中的构想和AI输出结果完全错位在软件开发工作当中, 最为令人感到烦恼的一个场景就是这样的情况: 你在心里的预想里设计好了全部的业务规则, 随后把这些需求内容交代给了人工智能工具, 最后拿到了一分看起来整体结构非常完整、并且在语法层面也没有出现任何错误提示的代码程序, 但是在实际执行运行的时候才会发现, 所真正实现出来的功能逻辑, 和你原本设想的那个逻辑是完全不一样的另一套内容。在《设计的设计》这本书里, 是提出了一个叫做“设计概念”的概念的。当团队在做协作开发的时候, 每一个成员的心里头, 是存在着一种没有写在纸上的共识构想的。人与人之间, 想要去对齐这一套隐形的共识, 都还是需要经过反复的沟通确认的。大模型是完全无法天生就感知到开发者脑袋里面的隐性想法的, 出现理解层面的偏差, 这几乎就是必然会发生的事件。这个痛点摆在眼前, Matt提出了grill-me的协作思路。他不急着马上搞出开发计划。是让AI变成那个揪着细节不放的人。一次只放出一个问题。还顺手给个带倾向性的参考答案。顺着业务设计的各种分支往下钻。一层又一层地把那些藏在大脑里没有写出来的设计构想全挖出来。这中间要反复问问答答几十次。上一轮说的什么, 直接就是下一轮提问时用的素材。这在很多编辑器内置的plan模式里面, 有着不一样的地方。这个plan模式的目标, 是要快速输出一份计划文档。目的就是为了能尽快进入编码环节。不过, grill-me这边就不一样了。它更愿意牺牲掉速度方面的东西。它的优先事项, 是把那些模糊的想法, 转化成明确的、可落地的共识。慢这件事, 在这里并不是什么缺陷。这其实是一种前置的成本, 专门用来规避在后期出现大规模返工的问题。陷阱 2语法逻辑没问题但整体风格、术语和团队语境格格不入还有更难以被察觉的一类问题, 这个问题的具体情况是, 由人工智能生成出来的代码, 其中的逻辑部分是满足要求的, 其中的功能部分也是完全符合预期的, 但是, 关于变量的命名方式, 关于业务所使用的那些专业术语, 以及关于技术实现过程中所养成的那些习惯, 它们与开发团队长期以来所保持一致的习惯之间, 是完全脱离关系的。领域驱动的这块设计, 里面有个什么通用语言的理论, 这个理论是这么告诉咱们的, 就是业务那边沟通的时候、代码里头起名字的时候、还有和那个甲方的业务人员一块儿交流的那会儿, 这三个方面得用同一套统一的术语词来表述, 要是这三套语境各自干各自的, 那沟通的成本就会像指数那样上涨的非常厉害, 这一套逻辑嘛, 同样也适用于人和那个人工智能一起干活的情况, 要是那个模型不熟悉你们项目内部用的那些业务的专有名词, 哪怕是那个需求的描述已经很清楚了, 最后写出来的那些代码, 依然是会出现语义上割裂的那种情况。对应的解决方案就是去维护一份针对仓库层面的业务术语清单, 具体做法是先用工具把现有的代码库通读一遍, 从中抽取那些项目里高频出现的业务名词, 然后统一整理成一张表格, 接着在每一次规划开发任务的时候, 都把这份写好的术语表当作资料一同喂给大模型, 经过实践观测这个效果确实不错, 导入术语表以后, 最终写出来的代码输出肯定会用统一的措辞, 甚至连模型自己在做内部推理和思考的整个过程中, 都会主动地去沿用这个项目既定的领域词汇, 这就能从源头上减少命名混乱的情况。阶段二编码进行中代码结构悄然发生变质需求方面已经做到了对齐现在正式进入到开发的环节当中去, 新的风险就一个接着一个地出现了, 代码库会在迭代的过程之中发生悄悄的腐化。陷阱 3功能看似全部完成程序却无法正常运行需求沟通的情况已经全部都到位了, AI输出的功能模块也是完整的, 但是在把各个部分组装起来之后, 程序就不能正常运行了。大部分开发者在第一反应上来时会想到要去补充测试用例, 不过实际的问题往往不是由于测试的数量不够所造成的, 而是由于测试执行的时机完全属于滞后的这一种状态。这个大模型它存在着一种天生的惯性, 那就是非得一口气把整套业务功能里头的代码全部写完不可, 非要到所有的逻辑都已经落地实现了以后, 它才会慢悠悠地回头去补充那些测试脚本。《程序员修炼之道》这本书里, 就用这样一个形象的说法来比喻这种状态, 叫做“行驶在前灯照射范围之外”。这就好比说一辆车正在面前猛冲过去, 可是它前头的灯光根本照不远, 前方的道路一片漆黑, 开发者完全不可能预先察觉到那些可能会冒出来的风险和隐患, 心里头是完全没底的。这里, 咱们得把那个叫作测试驱动开发的经典方法去重复利用一下, 这个方法的英文缩写通常是TDD, 然后, 必须得严格执行一个叫红的, 绿的, 然后再重构的这一套流程安排, 具体怎么个执行法儿, 就是第一步先写好那些测试用例, 这些测试用例写好了是注定要失败的, 第二步呢再去实现一个最少的业务代码出来, 要让这个代码跑起来能够通过这些测试用例才行, 做完这两步之后, 第三步才开始搞重构这个事儿来做优化, 总的原则就是得强制让那些代码测试跑到前头去, 跑到那个业务代码的实现前面去, 这么一来就颠倒掉了人工智能默认的那个开发顺序。反馈速度直接决定了我们迭代推进能够达到多高的上限, 那些像类型校验还有静态扫描这样的操作, 再加上能够在几秒钟之内就跑完的单元测试, 它们的真正价值并不在于去追求那个测试覆盖率的数字有多高, 而是核心地体现在压缩反馈周期上面, 这样能够尽早地把问题暴露出来千万不要等到写完了大量的代码之后才集中去发现错误。陷阱 4持续迭代之后代码库越改越混乱在很多的状况下面, 项目的维护工作做得越多产生的文件数量也就随之变得越多, 同时模块的划分又是非常之细碎, 各个部分彼此之间纠缠、耦合在一起乱作一团大家俗称这种现象为“意大利面条代码”或者“意大利面式代码”, 在这个现象背后的原因, 我们可以借用在《软件设计哲学》这部著作当中提到的, 关于“深模块”与“浅模块”这样的相关概念来进行解释。所谓浅模块, 指的就是那种对外暴露出来非常多接口, 而在每个模块的内部却只安装了非常少的业务逻辑的书写方式。这种写法导致文件被切割得又细碎又零散, 同时各个模块之间互相产生依赖关系, 结果就是牵一发而动全身。打个比方来说, 它好比是把一件完整的事情拆分到十几个小的窗口里面去办理, 在这种情况下, 人们不得不挨个窗口跑上一遍, 因此没有人能够记住全貌。我们对这类代码库进行维护, 这件事本身就让人感到十分的煎熬而对于AI智能体而言, 它必须要在上下文受到严格限制的情况下, 去还原整张依赖关系图, 如果它在理解的过程中出现了断开的状况, 它就会去继续新增更多细碎的文件, 从而使得项目开发变得越来越混乱。深模块的情况正好和前面提到的情况相反, 对于外部来说, 它仅仅展现出非常少的、并且都很简洁的接口, 然后它把那些复杂的业务逻辑全部都封装到了自己的内部去, 这样调用的一方就只需要明白“应该给它什么东西”以及“能够拿回什么东西”, 而完全不需要去关心模块内部的实现流程是怎样的样子, 这就好比是一个只开设了一个窗口的办事大厅一样, 用户进去之后只需要提交相关的材料, 接着就可以拿走处理好的结果, 剩下的那些工作步骤都在厅里面自动地完成。深这个模块, 它也属于是比较容易来进行验证的类型, 因为大家只需要放在外部去针对这个接口契约来编写那些测试内容就可以了, 完全不用非要去钻到内部实现的那个过程当中去。Matt还用过一个叫代码库架构优化这是一个工具, 在开头有两个减号和一个右括号。它的作用说起来非常简单, 就是把整个项目从头到尾扫描一遍。它会找出那些被拆散了, 并且互相纠缠在一起的代码部分。然后, 它会给出一些重构建议, 告诉你是哪几块应该收拢到一起。这样做的目的是为了引导项目长出更多的具有深度的模块。他举了一个例子, 用的是一种浏览器里的视频剪辑工具。把从界面一直到服务端的一整条链路都收拢成一个深模块之后, AI在这个仓库里面的表现有了非常明显的提升, 达到了一个质的飞跃水平。阶段三项目规模扩张上下文触达天花板因为交付的功能越来越多, 系统的规模一直在增加, 所以就会碰到由规模扩大所带来的两个方面的难题。陷阱 5交付成果越来越多但是开发者对系统全局感知持续弱化人工智能持续不断地生成新的代码, 导致系统内部所蕴含的相关信息急剧膨胀, 处于爆炸式增长的状态, 这使得人类的大脑难以完整地将所有的实现细节全部牢记于心, 因此开发者对于整体系的掌控能力以及那种对全局的把握感也就随之不断减弱和下降。深模块的设计思想恰好能够应对当下的局面, 人们可以先把深模块看成是灰盒, 把模块的接口契约交给人类去定义, 用人工验收校验的方式来确认模块的对外行为, 具体的内部实现工作交给人工智能来处理, 这样就真的不需要逐行地阅读里面的每一条代码, 这一点和极限编程之父肯特贝克曾经提出来的理念是比较接近的, 这个理念强调每天都需要为系统的设计付出精力, 在这样一个框架之下, 人类主要负责划定系统的边界, 并且把具体实现的这一类工作委派出去。之所以文档驱动直生成代码这个模式没有办法长久地维持下去, 这背后存在非常深的逻辑道理。完全依靠去修改那些规格说明来产出代码, 这种行为从本质上来说, 就是在持续性消耗在早期系统设计阶段所积累下来的资产。一个比较健康的项目状态, 应该是能够在系统设计方面进行持续性的投入, 而不是说要去不断透支前面积累的这些资源。陷阱 6上下文超限模型进入“愚蠢区”输出持续走样大模型实际上存在一个客观的边界, Matt把对话上下文分成了“智慧区”还有“愚蠢区”。当token的数量快要靠近十万这个界限的时候, 模型的注意力负担会以平方的程度大幅往上增长, 导致输出的水准出现非常明显的下降, 推理过程中开始频繁地发生错误。哪怕厂商那边声称是支持超大上下文的窗口, 这种性能逐渐衰减的现象依然是确确实实在那里存在的。大型开发任务它没办法一次性塞进单次对话的上下文里面去。如果采用线性任务计划, 让所有步骤都交由同一个智能体去按照顺序执行, 那很容易就直接掉进愚蠢区里头。解决方案是把大型任务拆解成DAG有向无环图看板, 要明确标记出那些任务之间的依赖约束, 如果卡片不存在那种依赖阻塞的话, 就允许多个智能体并行接手去执行, Sand库它就是这套思路的落地实现, 规划模块能够识别任务的依赖, 为可以并行的任务分配独立的沙箱, 多个实现的智能体会同步开展开发的工作, 在完成之后专门的合并组件来处理冲突。与此同时, 还需要把各个角色之间的分工给做好。具体到普通编码这块任务, 要选用那种既有性价比又更划算的模型来处理到了评审这个环节呢, 则应该去调用那些能力更强、水平更高的模型。最重要的一点在于, 在进行评审操作的时候, 必须要把之前所有的历史上下文信息全部清掉, 这样做的目的就是为了确保整个评审工作能够一直运行在智慧区里面, 从而避免因为存在大量旧的对话内容而对当前的判断结果产生干扰。完整协作流水线厘清人与AI各自的权责边界上面讲到的那些工具还有方法论, 它们根本不是零零碎碎、各管各的零散小技巧, 而是可以把一条长长的链条给扣起来, 最终能够拼凑成一套完整的闭环工作流, 这个工作能把从最开始那种模模糊糊的需求, 一直串联到最后的交付以及后续的迭代更新整个过程全部覆盖掉。从头先拿出一个还不太清楚的业务想法, 第一步是借由那种提问和回答的对话方式, 把需求的意思和大家的看法整理统一, 留下标准的文字文档接下来把这些需求一点点拆开, 做成一张张独立的任务单放进任务看板上交给人工智能助手助手会根据测试驱动开发的要求同时写代码做测试然后让人类来做质量检测还有检查代码如果在检查过程中又有新的需求或者发现了错误就把这些重新放回顾板去, 再开始下一轮的重复工作。在这套操作流程里, 有三种细节是大家都特别喜欢跳过不要的, 但其实呢它们又是特别特别重要的。第一点事情是这样的, 任务采用的方式是垂直切片, 坚决不采用水平分层这种开发方式。大模型这种东西, 它天生就习惯按层级分开着做这件事。它具体怎么做呢? 先把所有数据库的表设计完, 然后去开发接口, 最后再做前端页面。这种方式有一个非常明显的特点, 要等到最后一层的事情全都做完, 那个东西才能跑得起来, 问题也就全堆在开发末期才暴露出来。所谓一次完成一个完整的功能, 这也就是在借鉴曳光弹的开发思路, 意思是首先要打通一条完整的数据链路。在一个单独的任务之中, 要同时涵盖对存储数据的修改、后端处理逻辑的实现以及极其简单的界面搭建这一全过程。通过这种方式, 可以把从底层数据库到应用层接口以及前台页面显示的所有层级全部串联起来。这样一来, 每完成一个小任务之后, 立刻就能得到一个可以运行并且能够进行验证的最终结果, 如果开发的方向出现了偏差, 也能够比较早的时候察觉到。以拿合同台账这个功能举例这种方式来看, 按层级分开来做的意思就是先进行第一步的设计合同数据表的工作, 接着再进行第二步的开发接口的任务, 最后才是去做第三步的台账页面这一环节而所谓的垂直切片做法, 则是在第一步当中就把录入一份新合同以及能够在台账列表里面查到它这一整件事情给完结掉, 这其中包含了涉及到的数据表部分、接口部分、极简界面部分还有测试部分在内的全部内容, 尽管做出来的功能比较简陋一些, 但是完整链路是可以直接跑通的。第二, 对话的上下文快要被填满, 直接把它清空然后重新开启一个会话, 不要去做什么历史压缩处理。等到对话的上下文空间即将被彻底占满的时候, 其实只有两条路子可以选: 一条路是把所有的历史记录都进行压缩和摘要, 然后在新的摘要基础上继续运行还有另外一条路, 就是把一切归零, 让会话重启。Matt这个人更偏向于推荐第二种做法。你要知道, 如果在模型本身质量已经发生严重下滑的状况下, 还要强行去压缩内容, 那么错误就会像滚雪球一样, 一层一层地叠加起来, 不断地进行累积放大。但是如果选择把上下文全部清空, 然后从头开始新的一场对话, 这样就能保证每一轮的工作任务都是建立在一个相对稳定的起点之上的, 对。第三点, 就是把权力和责任的边界划分清楚, 需求盘问、编写产品需求文档PRD、还有拆解任务, 这些属于要把事情先想清楚的顶层设计环节, 必须由我们自己来主导, 具体编码实现的部分可以放手交给AI智能体去做, 在验收评审这个环节, 则需要重新回到我们手中来进行把关。评审这个动作, 是让工程判断进入项目的关键节点。比如说代码风格到底应该怎么取舍, 异常情况到底该怎么兜底, 还有可读性是不是应该优先于那些炫技的写法, 这类价值判断的事情, 在大模型现阶段的水平之下, 它还代替不了我们去做。AI这个东西, 它可以非常高效地完成执行层面的任务, 但是关于系统架构、业务语义以及质量上的取舍这些决定权力的事儿, 必须紧紧地掌握在开发者自己的手里才行。落地实践路线分短期、中期、长期逐步改造项目要想把人工智能的代码编写效率真正释放出来, 其实不需要一开始就去做大规模的结构调整工作, 可以按照时间短、时间中、时间长这样的三个阶段来进行逐渐的更新改造, 这样就能把过去多年积累的软件工程基本能力, 转换成机器和人一起协作的工具。短期沉淀统一业务术语低成本消除理解鸿沟大家应当把业务术语表视为项目的关键核心资源, 并将其摆放在代码仓库的起始位置也就是根目录下, 让它伴随着业务的逐步迭代同步进行更新, 在每一次发起代码提交请求以便合并的操作也就是通常所说的PR的时候, 顺手去维护和完善这份文档资料。做这样一件事情付出的成本是非常低的, 但是它却能够直接从最源头的那个地方减少因为命名不一致所带来的混乱情况, 同时又能降低人工智能系统对于公司业务理解的偏离程度, 最终使得生成的代码模型可以更加贴合我们团队各自所拥有的特有的业务知识环境和上下文语境。很多团队对于这一件小事情采取了忽略的态度, 他们在提示词当中不停地进行了重复性的描述, 这种行为涉及到的业务名词, 然而却并没有形成一份可以用于复用的统一术语资产, 也没有让这份资产随着项目的演进而进行更新。中期打造高速反馈闭环快速拿到报错信息等短期内的任务处理完毕之后, 人工智能最少起码就学会讲我们所使用的那些话语了接着来的更加关键的环节在于, 它进行书写操作的速度非常快, 但是所说的内容是否准确无误, 需要等待比较长的一段时间才能知道答案呢?这一步骤的作用就是把持续集成这一条流水线调整为一种能够快速产生反馈的消息通道, 只要代码被提交上去, 机器就会立即自动完成编译工作, 检查错误情况, 并且重新运行一下以前的那些功能, 在几分钟之内给出最终的结论。举一个具体的例子吧, 在员工报销系统当中, 人工智能修改了差旅补贴的计算规则, 但在提交的时候并没有查出任何问题, 直到两周之后才发现金额计算错了, 然而在这么长的一段时间里面, 已经有几百份报销单早就已经被批准完了, 也早就已经把款项打出去了, 并且已经合并到了当月的费用报表里面, 这时候财务部门就必须要把每一张单据都退回重算, 并且还要向员工去解释钱为什么又被扣回去了, 如果当时有几条单元测试能够在第一时间跑出出差额的情况来, 那么它只需要用几秒钟的时间就能进行修改, 后面发生的这一系列麻烦事情就一定不会发生了。人工智能技术, 这个东西其实就像一个放大器一样, 反馈的周期如果被压缩得越短的话, 它来改正错误的速度就能够变得越快, 但如果时间被拖延上了几天的话, 那么它就会带着既有的错误一路往前冲下去。所以说, 在处理这一步操作的时候, 我们不去看测试写得有多么全面, 只去看检查的过程运行得到底有没有快——把类型检查、还有静态扫描以及秒级完成的单元测试全都串联到同一条流水线上去, 从而将花费的时间从原来的十几分钟直接压缩减少到几十秒钟的时间段里面去。长期持续推进架构重构优先打造深模块重构的目标, 并不是单纯地去删减文件, 或者是去整理一下代码格式, 核心的目标其实是要把外部调用方在认知方面所承受的负担降下来。我们要优先地把零散分布在各个地方的业务逻辑收拢到一起, 然后持续地把接口很干净的深层次模块打造出来, 要把那些复杂性全部封装在模块的内部之中。对外面暴露出来的概念越少, 系统的边界就会越清晰, 这就意味着, 不管是我们在自己进行维护, 还是让AI去生成或者修改代码的时候, 出现错误或者跑偏的概率都会大幅度地下降。你应当坚持, 每天要投入一部分精力去做系统设计工作, 不要一直等到项目彻底失控了以后, 才被迫着去进行大规模的重构。结语人工智能工具给软件研发过程带来了那种过去从来没有过的生产力方面的巨大好处和收益, 可是它并不会自然而然地就去保证工程质量的水平和情况怎么样。不管那个模型强大到什么程度, 也不管使用的提示词设计的有多精巧巧妙, 所有这些方法全部都无法解决、挽救一个内部结构混乱不堪的代码仓库所存在的那一堆根本性问题。很多开发者担心在AI时代多年积累的软件工程基本功会不会变得完全没用。事实恰恰就是和你想的不一样: 敲代码这种重复性的执行工作完全可以交给AI去做, 但是需求共识的对齐、系统边界的定义、业务语义的统一、质量权衡的取舍, 这些核心工作, 依旧只能依靠开发者自己来完成。把机械编码执行这个事交给人工智能去做, 然后把工程决策权牢牢地握在自己手里面, 这样做的话, 才是能够真正去享受到因为人工智能带来的产能的提升。如果不这样做的话, 就只会被用人工智能所制造出来那些技术债务给无休止地消耗掉自己的精力而已。工具这个东西永远它只是一个放大器罢了。真正决定事情上限高低的还是开发者自己沉淀了多年之后所形成的那一些在软件工程方面的底层能力附文中人物与名词解释一览出场人物Matt 是领域研究者, 也是教育者, 他是核心团队成员之一, 曾经在相关职位上负责开发者教育工作, 他还创办了名为 Total课程的培训项目, 被很多工程师当作这门语言的标准教材来进行学习, 文章当中所说的关于人工智能编程方面的观察结果, 基本上都是来自于他自己在过去的一年半时间里的真实实践经历。他是图灵奖的获得者, 也是IBM 360以及操作系统OS/360的主要主持人和发展者, 他还写有《人月神话》《设计原本》等作品。这位叫kent beck的人, 他是把极限编程给提出来那个, 他也是特别推崇测试驱动开发, 他还是那个敏捷宣言上面签了字的人之一。关键名词按文中出现顺序所谓的AI 智能体, 又被称作AI Agent, 它是一种AI 助手, 这种助手能够自己规划步骤, 同时还能调用工具, 并且能够连续完成一整串的任务。把那些要交给人工智能来进行处理的指令性的文字, 也就是所谓提示词这些东西。这是属于一种纯文本的写作模式, 这种模式能够通过简单的符号来实现标记标题以及创建表格的操作。所谓的“感觉式编码”这种行为方式, 具体是指在面对由人工智能所生成出来的代码时, 选择既不去查看、也不去弄懂其中具体的含义, 而是完全依靠自己的直觉和主观感受, 不断地要求这个人工智能工具进行反复的重写操作。所谓技术债务, 其实就是因为急着赶工作进度, 所以就留下了以后会出问题的隐患, 等到了后面需要还钱的时候, 那就得花费加倍的时间来把这些账给补上。这种像是盘问一样的对话方式, 也就是 Matt 提倡的那种协作办法, 它是先让那个工作智能工具反过来一句接着一句地问你, 一直把你的那些想法都问得明明白白之后, 然后再去动手做事。计划模式, 也就是很多人说的那个 plan mode , 是许多编辑器中都自己带有的一个功能, 它会让你的那个 AI 先去把一份方案给出, 然后才开始去写代码。把通用语言这件事做到位, 具体来说, 就是在业务沟通、代码命名以及和业务方进行交流这些个不同的环节里面, 大家都要去使用同一套术语来进行表达和互动。所谓的浅模块, 是一种什么样的写法呢, 这种写法的接口是又多又杂的, 这种写法的每个模块只装了一点点逻辑, 而且这种写法的文件被切得非常细、非常碎。这是一种所谓的深模块的设计做法, 在这种做法里, 它对外仅仅是暴露出一小部分的接口, 而把那些复杂的逻辑内容全部都隐藏并包裹在了模块内部的这个机制里面的一种写法。所谓灰盒测试意思就是不考虑内部的实际运行细节和具体实现过程, 只是根据事先约定好的接口规范来进行验收, 并且只查看最终输出的结果。代码库架构优化当被问及 Matt 曾经使用过的工具时, 这里提到的是这样一款工具: 它能够把整个项目仔细地检查一遍, 然后给出一些关于重构的建议, 意思是让用户知道应该把哪些部分的代码整合到一起。测试驱动开发, 也就是我们常说的TDD strongTest-, 它的主要做法是这样的: 先进行编写测试这个步骤, 随后再编写代码来让所写的测试获得成功通过, 最后再进行代码重构的工作。TDD的三步是红、绿、重构。先写一个必然失败的测试, 这叫做红阶段。接着使用最少量的代码让测试通过, 这就是绿阶段。最后一步是进行重构工作。所谓的垂直切片, 就是说在一个任务里头, 要把一个完整的功能给一次性全部做完, 让数据库、接口还有界面全都贯穿起来。水平分层, 意思是按层级来把任务分开来做, 具体的做法是先完成全部数据库的编写工作, 然后再进行接口的开发工作。在曳光弹这种项目的开发层面, 首要任务是先构建出一条完整的操作链路, 以便让最终的成果能够尽早地被看见和被证明, 这一过程所具有的意义与效果, 就类似于当我们发射曳光弹之后, 能够清楚地看到它在空中划出的那条轨迹。那个token, 它是模型在处理文字的时候, 所使用的最小的那种计量的单位, 并且它也常被拿来衡量, 在一轮对话里究竟能够装下多少的内容。Matt 的说法是, 当上下文的长度接近十万 token 之后, 模型的输出质量会出现明显的下滑, 这也就是说进入到了所谓的“愚蠢区”之中。有向无环图, 这指的是DAG, 也就是Graph的一个实例, 它代表了一张任务流程图, 在这张图里面, 各个任务之间存在着先后的依赖关系, 而且不会出现回头绕圈的现象。这个由 Matt 所使用的 Sand沙堡工具库, 主要的作用是依据任务的依赖关系情况, 把那些能够同时处理的任务分配给相互独立的运行环境去操作, 等到这些操作都完成以后, 再把结果统一合并到一起。容器沙箱, 指的是这样一个东西, 那就是每个任务的运行环境都会被进行单独隔开处理的容器。所谓的持续集成流水线, 简称为CI, 就是在一整套流程里进行自动编译、自动检查、还有自动跑测试的一系列事情。在这类约束里头, 每一个数据项都被事先规定了明确无误的类型, 要是使用了不符合要求的数据类型, 马上就会弹出一个错误提示。这套自动校验机制会把类型检查、静态扫描还有单元测试这些都包括进去, 让错误出现的时候能够马上就被发现并暴露出来。合并请求, 也叫做Pull , 就是把代码所做的更改提交上去, 并且发起一个向自己的同事进行评审的一次请求。产品需求文档PRD: 就是一份要求把需求讲清楚的书面材料。质量验收, 这里用QA来表示, 就是要通过人工的方式, 对最终交付出来的结果进行仔细的检查动作, 并且还要完成确认的环节。