AI编程浪潮下的工程实践
回想一年前的光景，AI还在按部就班地补全代码，你敲一个字它跟一个字，活脱脱一个听话的小跟班。今年画风突变，AI直接包揽整个项目了。作为干了十几年的老程序员，突然感觉自己的价值好像蒸发了一样。
既然打不过对手，那就选择加入。白天在公司搬砖，晚上回家继续折腾AI编程。订阅了Cursor会员，买了智谱的API接口，装了一堆AI开发插件。心里盘算着，万一哪天被裁员了，还能搞个"一人公司"自己单干，至少得提前摸摸底。
我的首个项目是个摄影分享站点。最近迷上了拍照，就想搞个自己的摄影小圈子，让Claude和Cursor轮番上阵捣鼓。
实际效果怎样呢？基础功能确实能跑起来了，速度确实快。
但用着用着就发现各种隐患：有的按钮点下去没动静，有的页面排版错位，偶尔还蹦出个莫名其妙的报错。让AI去修吧，修好这个功能，说不定另一个地方又出问题了。你根本不知道改完之后还藏着什么坑，只能自己一遍遍充当"人工测试仪"。别提多糟心了。
效率真的提升了吗？实话实说，并没有比自己动手快多少。表面上看着是省了时间，但后期修bug、擦屁股的时间，把前面省下的全搭进去了。看着外面那些AI做出来的亮眼产品，我陷入了沉思：到底是哪里出了问题？
如果你也有过类似的体验，那你肯定明白这种感觉：AI不是很厉害吗，怎么就是搞不出我真正想要的东西。
其实需求一点都不难：上传图片、按类别浏览、简单评论——多经典的增删改查系统。这要是搁以前，用老办法开发，也花不了多少时间。
交给AI之后呢？第一轮生成确实神速，框架搭好、页面生成、数据库对接……十分钟就能跑起来。但要明白，"能跑"和"好用"之间，隔着十万八千里。
你会发现一堆细节不对劲：图片上传后缩略图没生成；评论提交后页面居然不刷新；手机端布局在某些特定机型上直接乱套。这些全得你手动测试才能揪出来。
然后你让AI去修。它刚修好了缩略图，上传接口的参数校验又出问题了；修好了参数校验，分类筛选的排序逻辑又乱了。虽说算不上什么"改一处崩三处"的灾难，但这种折磨人的慢性消耗才要命——你不知道这次修完还有没有其他问题，每次都得把整个流程重新测一遍才能踏实。
这种感觉，做过系统重构的同行肯定不陌生。就像咱们之前聊过的：改动的影响范围是不可见的。你以为它只改了一个函数，但它在系统深处偷偷埋了一根线，牵连到了三个你压根没想到的地方。
AI改代码的时候，它理解的只是"当前这个文件的当前上下文"，它看不到全局。它在局部做的确实是"正确"的事，但放进整体系统里就未必了。
这和咱们之前聊过的"熵增"是一个道理：系统总是在自动变坏的。以前是一个团队花好几个月慢慢把系统搞乱，现在是AI加速了这个过程。以前一个月才能堆出来的"屎山"，现在几天就堆好了。
这算不算AI的功劳？（苦笑）
Martin Fowler在《重构》里说过一句很经典的话：
"任何傻瓜都能写出计算机能理解的代码，优秀的程序员写出人能理解的代码。"
我想在这里补充一句：AI能写出AI理解的代码，但能不能写出整个系统都理解的代码，得看你给不给它加约束。
我想了很久，问题到底出在哪？是AI不行吗？但X上的各种牛人否定了这一点。不是AI不行，那就是我不行！
其实真不是AI能力不够。它在单文件、单函数级别的编码能力，已经秒杀很多初中级工程师了。它缺的，是约束。
这就是第一性原理：没有约束的创造力就是混乱。你给程序员一份模棱两可的需求让他自由发挥，大概率也得不到你想要的结果。
AI也是一样的，甚至它比人更需要约束。因为它不像人类工程师那样，干着干着还能自己踩踩刹车，问一句"哎，我这样改会不会影响其他模块啊？"AI只管低头干活，你让改它就改，改完还特别自信。
AI是一台顶级的相机，但构图得你来。别指望更好的机身（更强的模型），也别指望更多的镜头（更多的Token），你得有自己的审美——得掌握用好它的方法。
带着这些困惑到处查资料时，我看到了今年特别火的一个词：Harness Engineering。
AI和人类协作的方式，其实经历了三代演进，每一代解决的核心痛点都不一样。咱们还是用摄影来打个比方：
第一代：Prompt Engineering（提示词工程，2022-2024）
这代大家都很熟了。核心就是研究：怎么写好一条指令，让AI一次性给出最好的答案。Few-shot、思维链（CoT）、角色扮演等技巧层出不穷。
打个比方：就像你对摄影师说"帮我拍一张日落海边的照片，暖色调，要有个人走在沙滩上"。描述越准，出片越好。但缺点是它是一次性的，下次摄影师又忘了你的偏好。
第二代：Context Engineering（上下文工程，2025）
到了2025年中，Andrej Karpathy说了一句很关键的话："Context engineering matters more than prompt engineering."模型需要的是动态构建的上下文窗口——相关文档、历史对话、工具定义、RAG检索结果。
打个比方：这不再是一句话了，而是你给摄影师递了一本拍摄手册，里面有风格偏好、历史作品集、实景照片和器材清单。你把所有参考资料都摆在他面前。
第三代：Harness Engineering（编排工程，2026）
这就是今年的前沿玩法了。核心观点是：不再关注单次交互，而是去设计AI工作的整个"环境"——工作流、约束规则、反馈循环、工具链、质量门禁、生命周期管理。
打个比方：这不再是描述或给参考资料的事了，这是你在设计一整间摄影工作室。你规定了选片流程、修图标准、出片质检机制。在这个环境里，每个人（和每个Agent）都知道自己该干什么，干完谁来检查。
用大白话说：Harness Engineering就是把多个AI Agent的会话，编排成一个可重复的工作流的工程实践。
它让AI在一个受控的环境里打工，而不是盲目追求让AI变得更聪明。工作环境搭好了，产出的质量一致性自然就有了。
OpenAI和Anthropic在实践中得出了一个高度一致的共识（这句话值得圈重点）：
"Agents aren't hard; the Harness is hard."
(Agent本身不难，难的是Harness。难的是你给AI搭建的那套"工作环境"。)
这里有个特别反直觉的现象。
Anthropic做过一个实验：完成同一个复杂任务，如果用简单的"提示词+直接运行"（prompt-and-run），花9美元，产出一个根本没法用的残次品。但如果用结构化、受约束的迭代方式，花200美元，能产出一个直接上线的完整产品。
成本差了20倍，但能力差距是本质的。还有一组数据更震撼：同一个模型、同一条提示词，仅仅因为"工作环境"不同，编程基准的成功率直接从42%飙升到78%。
这让我想起了咱们以前聊过的分治思想。把大问题切成小问题，本质也是一种约束。你让AI一口气搞定整个系统，它就像无头苍蝇到处撞；你把它限制在一个个边界清晰的模块里，它反而能大显身手。约束不是限制，是精确制导。
Harness公司2025年的报告里有一组特别能说明问题的数据：63%的团队用AI后写代码变快了，代码产出量暴涨59%，但整体的项目交付量反而下降了7%。
这中间的差值去哪了？全消耗在返工、调试、处理AI引入的隐性Bug、以及收不住的需求发散上了。这就是典型的Harness Gap。模型能力早就不是瓶颈了，怎么用好模型才是真本事。
彻底搞懂Harness Engineering之后，我尝试了两条实操路线。
第一条路线就是上篇文章聊过的TDD（测试驱动开发）。先写测试，再让AI写实现代码，至少能保证写出来的东西是对的。
效果很明显：代码质量确实稳了。以前那种改完不知道哪里会崩的恐惧感基本消失了。AI在TDD的框架里写代码，就像火车被死死按在铁轨上，再也不会乱跑。
当然，Tokens的消耗明显多了……
但新问题又来了：AI做的东西，跟我最开始想要的出现了偏差。
质量没问题，但方向歪了。AI规规矩矩地实现了每个功能点，但拼在一起一看，整体感觉不对。我要的是极简实用，它给我搞成了大而全。让它改吧，来回拉扯几轮，反而越来越偏离我的初衷。
结论：TDD解决了"代码对不对"的问题，但没解决"方向对不对"的问题。
于是我又查到了另一个方向——规格驱动开发（Spec-Driven Development，简称SDD）。就是在动工前，先写好规格说明书，把需求、约束、验收标准写得明明白白，再让AI照着写代码。
这就好比盖楼前先画蓝图：主题是什么？目标用户是谁？核心功能边界在哪？先想清楚"我要做成什么样"，再让AI搬砖。
市面上相关的框架也不少，比如Speckit、OpenSpec，都是把这套思想在AI Coding里落地的工具。用起来确实比"裸跑"强多了，至少方向不会跑偏。好像确实对味点，尤其是前端设计，先给我看下再动手。
当然，Tokens的消耗明显更多了……
不过我心里总觉得哪儿不太顺手，可能是跟之前公司的开发方式不一样吧。
用了别人的框架一阵子后，用多了就会有些想法：这些时髦的AI框架，本质到底是什么？
它们不就是咱们那些经典的"老旧"软件工程方法，在AI身上的固化吗？
打开一看：需求分解、架构设计、接口定义、任务拆分、代码评审、回归测试……这些不就是当年从《代码整洁之道》读到《Google软件工程》，在华为摸爬滚打了五年积累下来的那些老掉牙的工程实践吗？
这些"老古董"不仅没有过时，反而成了用好AI的绝世基本功。以前这些方法长在人的脑子里，靠着无休止的开会、写文档、Code Review才能艰难落地；现在，我们只需要把它固化成Agent能直接执行的流程。
《Google软件工程》里有个振聋发聩的公式：软件工程 = 编程 + 时间。编程是瞬间的动作，工程是长期的承诺。
放在今天，我觉得这个公式可以升级一下：
AI软件工程 = AI编程 + 软件工程方法。AI彻底解决了"编程"的效率问题，但"工程"的质量把控，还得靠那些经历过时间检验的"老古董"方法论。
想通了这件事，我的焦虑症好像减轻了点。AI虽然能替你疯狂输出代码，但好像缺个方法论来指导他，还得你跟他说：
这几样能力，恰恰是我过去这些年，通过一本本书、一个个项目、一次次背锅踩坑熬出来的。以前受限于执行力，你知道该怎么做，但项目催得紧、人手不够，最后只能向现实妥协。现在好了，AI把最苦最累的执行活儿全包了，你终于可以泡杯茶，专心做你真正该做的事：想清楚思路，做好设计，然后看着AI去干活。
想明白了"该用什么方法"，下一个问题是：用谁的现成工具？
Speckit、OpenSpec这些框架好不好？当然好，设计思路清晰，底子也很扎实。但我用起来就是觉得别扭。
因为那是别人脑子里长出来的工作流。别人的思维习惯、节奏和术语体系，就像你穿了一双别人的鞋，就算尺码刚好，走起路来总归磨脚。
我不是说开源的东西不好。相反，开源社区里有太多前人踩坑留下的宝贝了。问题在于，你得有一条自己的"主线"去把它们串起来。如果没有这根线，你今天借个外壳，明天抄个Prompt，后天再套个工作流，拼凑半天，这辆车终究不是你自己的，开起来也会散架。
所以，不是所有轮子都要自己重新造，但你得有自己的底盘。有了自己的底盘，别人的长处、约束和精华，才能真正消化成你工作流的一部分。
当AI把写代码的速度拉满之后，什么才是真正稀缺和有价值的？
不再是打字速度，不再是对语法的死记硬背，也不再是对某个框架的熟练度。真正的核心竞争力是：作品的风格、审美和判断力。
继续用摄影举例。现在人人都有智能手机，人人都能按快门。但为什么专业摄影师拍出来的就是不一样？
不是设备碾压（很多大片就是手机拍的），是审美的碾压。取景时的判断力（什么该入画，什么该裁掉，这是抽象）；构图的节奏感（哪里留白，哪里紧凑，这是设计）；后期的风格（冷暖色调、对比度，这是Trade-off）。
编程也是如此。当AI解决了"怎么写"的问题，"写什么"和"写成什么样"就成了拉开差距的关键。这背后，全靠你的经验和偏好撑着。你需要一套"懂你"的脚手架，才能让AI产出带有你强烈个人风格的作品。
你的Harness，就是你看待这个代码世界的方式。
于是，我开始动手做这件事：把我这些年内化的软件工程方法论，全部写成Agent能直接执行的Skills。
我没有发明任何新理论，纯粹是把脑子里的东西"具象化"搬出来：
不是在造新轮子，是在把老轮子安到我这辆新车上。有些轮子是我自己亲手打磨多年的，有些是找高人借来的，但现在，它们全都在这辆车上运转了。
最好的Agent，永远是那个被你亲手调教出来、最懂你的Agent。
来看看我最终折腾出来的这套流程。重点别看功能列表，看它的设计思路——那里面藏着的，才是原汁原味的软件工程思维。
在设计工作流时，我没有像大杂烩一样把所有方法全塞给AI。我按工作阶段做了切分，对症下药：
解决"做什么"的问题。引入Spec-Driven Development，把模糊的想法变成严谨的规格书。同时解决AI"健忘"的痛点：不依赖聊天记录，而是让AI直接去读仓库里的状态文件来决定下一步干嘛。
解决"做得对不对"的问题。引入Kent Beck的TDD，但加上硬约束：一次只能做一个任务。代码写完怎么查？引入70年代的Fagan同行审查法，核心纪律就一条：作者和审查者必须分离（AI自己写自己查绝对会放水）。
解决"真的做完了吗"的问题。光跑通不行，必须打包"证据"（测试结果、评审结论），满足完成定义（Definition of Done）才能算完。最后同步状态、写Release Notes，干净利落地收尾。
你看，这上面全都是咱们以前在书上看过、在项目里用过的老招式。现在，它们只是换了件衣服，变成了一套Agent的执行规范。
选好了方法，怎么把它装进Skill（技能库）里？这绝对是我踩坑最惨的地方。
起初，我犯了个致命错误：把方法论直接当成操作说明书喂给AI。比如TDD，我就告诉它："第一步写测试，第二步跑红灯，第三步写实现，第四步跑绿灯。"
结果AI跑起来简直像个智障，根本不对味。
改了好多轮后发现：方法论不是操作手册，它是决策框架。AI根本不需要你教它"怎么敲键盘"，它需要你告诉它"在什么节点，该做什么判断"。
举个例子，在处理测试驱动开发的Skill时，我写进去的核心是这些：
可以看到，我根本没教它TDD的步骤，我教它的是"纪律"和"红线"。
我理解这是封装方法论的正确姿势：你不要给AI复述方法本身（它模型里早就背得滚瓜烂熟了），你要告诉它，在当前这个特定环节，哪些纪律是不可妥协的，哪些危险信号说明它正在跑偏。
最大的教训就是：信息过载。一开始我恨不得把整本软件工程的经典书全塞进Prompt里，结果AI吃撑了，彻底懵圈，根本不知道该优先听哪句。
后来学会了"分层抽象"：把最核心的骨干约束留在Skill主文件里，把那些长篇大论的深度指导资料踢到references文件夹下。让AI需要的时候自己去翻，平时别去干扰它。这其实就是咱们说的：丢弃细节，抓住灵魂。
现在靠这套Harness Flow，我已经能非常稳定地搞出一些质量不错的小项目了。焦虑少了一点吧，终于找到了一个杠杆，把我自己多年的实战经验，跟AI可怕的生产力对接上了。当然，每天还是在被日新月异的AI模型和应用啪啪打脸。
现在感觉是AI能做出来想要的，但我想不清楚我要什么，缺少产品思维……
五篇文章，从"如何手写好代码"一路聊到"如何用好AI"，其实核心从来都没变过——做好每一件小事，把基本功练扎实。
回到年初那个让我焦虑的灵魂拷问："AI这么猛，我这个老兵的价值在哪？"
也许有答案了：AI从来不是来取代你的，它是来放大你的。但前提是，你的脑子里得有值得被"放大"的东西。
以前，你空有一身好方法论，却被繁重的体力劳动拖垮了执行力。现在，AI站出来接管了全部的脏活累活。你的方法论，也许迎来了全力施展的黄金时代。
打磨好你的手艺，把它们变成你专属的脚手架（Harness）。这，也许是我们在AI时代最好的反击策略。