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