代码正在变得廉价但判断力从未如此昂贵几个月前我读到一组数据一位工程师用20天时间让AI提交了70万行代码10个项目同时并行。不是IDE补全那种协作模式而是把整个任务整包交出去——让模型自己读地形、定方案、写实现、跑验证、修bug全套跑完。他只做一件事在关键节点拽方向。这让我开始重新思考一个问题当代码本身变得如此廉价程序员的价值到底在哪里不是会不会用AI而是会不会管AI现在行业里有一个明显的分水岭。不是“用AI的程序员”和“不用AI的程序员”之间的分水岭而是会用AI执行任务和会让AI稳定产出之间的分水岭。很多人把AI当作一个更快的打字员。告诉它“帮我写个函数”它写了看一眼没问题提交。这其实只是把Stack Overflow换成了大模型工作方式没有本质变化。但另一群人开始意识到真正稀缺的能力不是让AI写代码而是设计一套约束系统让AI在不失控的前提下整包接住一个复杂任务。这套约束系统包含三层边界条件明确告诉AI哪些不能碰。就像在一个遗留系统里做代码清理你得先标出承重墙的位置——哪些产品宏下的代码必须保留哪些平台的适配代码不能删。不画这个圈AI会一扫而空连正在用的功能都干掉。目标优先级告诉AI先做什么后做什么。AI不知道什么是业务优先级它不知道“保证核心升级顺利”比“清理更多无用代码”重要一百倍。这个判断必须由人来注入。验证标准定义“什么样的证据能证明你做对了”。编译通过、测试全绿、改动依赖度低于阈值、删除项附带理由说明——这些不是事后检查而是事前就写进契约的条件。这三层合在一起就是Harness方法论的核心人定方向模型推进。一个真实的工程案例前段时间我参与了一个大型桌面软件的代码清理项目。这个产品经历过多次产品线调整仓库里沉淀了大量历史遗留代码——早期产品的业务逻辑、已废弃平台的适配代码、不再使用的资源文件全都混在一起。任务听起来很简单清理不再使用的代码和资源。但如果直接丢给AI“帮我删掉没用的代码”结果将是灾难性的。我们在AI动手之前先建立了一套完整的约束系统。第一层确认边界。团队逐个确认了几个关键问题哪些产品宏下的代码需要保留是否需要保留其他操作系统平台的代码是否只保留64位版本是否只保留Win10及以上系统的兼容代码这些问题本质上是在划定AI的活动范围。就像拆墙之前先用粉笔标出承重墙——粉笔线之内随你拆粉笔线之外一砖不动。第二层确认优先级。我们把清理工作分了三个批次。第一批人工确认过的低风险代码直接删除。第二批AI辅助生成的“疑似无用代码”清单需要人工确认后才能执行。第三批资源、脚本等非核心代码的清理。这背后有一条核心原则不影响关键升级的优先放低。AI不知道当前的首要目标是保证升级顺利人必须给它注入这个判断。第三层确认验证标准。每次删除后必须评估改动依赖度依赖度过大时暂停所有改动必须通过回归测试分批提交每批附带删除理由说明。最终这个模糊的“清理代码”需求被转化成了AI可以安全执行的spectext【目标】清理不再使用的代码和资源保证关键升级不受影响 【范围】 - 删除已确认不再使用的业务功能代码 - 删除已废弃平台的适配代码 - 删除不再使用的资源文件 - 保留当前产品仍在使用的所有代码路径 【停止条件】 - 改动依赖度过大时暂停降低风险后再继续 - 任何影响关键升级的操作立即停止 【执行顺序】 - 第一批低风险删除人工已确认无用的功能列表 - 第二批中风险删除AI出的疑似无用代码清单人工确认后执行 - 第三批非核心代码及资源清理 【证据要求】 - 每次删除后提供改动依赖度评估 - 回归测试通过 - 分批提交每批附带删除理由说明这个案例让我意识到AI时代的工程管理本质上是在设计约束系统。人不再亲自搬每一块砖而是设计建造规则、标出承重墙位置、制定验收标准。怎么判断该给AI多大的自由度这是实践中最常遇到的问题。每次派活之前都面临一个抉择是设限还是放手我后来总结了一个简单的决策框架只需要评估任务的两个属性可逆性和可验证性。可逆性问的是搞砸了能多容易恢复能通过git revert一键回滚的可逆性高会导致数据丢失或业务中断的可逆性低。可验证性问的是对错好不好判断能写成一条机器可自动执行的校验规则的如“编译通过”“测试全绿”可验证性高需要靠人的业务经验或审美判断的如“架构是否优雅”可验证性低。把这两个维度交叉就得到四种策略高可逆性低可逆性高可验证性放手去做只定目标和验证规则设置验证点每步等确认低可验证性设置边界只准列清单不准动手人做判断AI在圈内执行回到代码清理的案例不同任务恰好落在不同象限删除已知无用的资源文件图片、皮肤→高可逆、高可验→ 放手让AI自己找、自己删、自己验证删除已确认不用的业务代码 →高可逆、中可验→ 分批删除每批等回归测试通过删除“疑似无用”的代码 →中可逆、低可验→ AI先出清单人工确认后再执行决定是否保留某个产品宏下的业务逻辑 →极低可逆、极低可验→ 人做判断AI只在限定范围内执行删除这个框架的本质是把你每次“这个任务该用哪一级自主性”的模糊感觉变成一个可重复的理性决策。你不是凭直觉给AI设限而是基于任务的风险属性主动设计它的自主级别。如何把这种能力系统化有了初步的实践经验后下一步是把隐性的判断力变成显性的方法论。我总结了三个层次的刻意练习。第一层深化——把直觉外化成框架。每次完成一个AI协作任务后做一个结构化复盘而不是简单总结“这次顺利”或“这次翻车”。复盘的模板大致是这样这次任务是什么类型我用了哪一级自主性spec的设计边界条件、优先级、停止条件、验证标准分别是什么实际执行AI在哪一步表现超出预期在哪一步跑偏了为什么我在哪个节点介入拽回方向的这次经验可以提炼成什么可迁移的规则spec模板应该怎么改坚持做20次这样的复盘你就能从“感觉这个任务该这样管”进化到“我知道这类任务的约束模式是什么”。第二层系统化——把经验沉淀为可复用的资产。基于复盘积累开始构建自己的工具箱spec模板库为不同的任务类型代码清理、功能开发、重构、Bug修复提炼可复用的spec模板每次只做微调checkpoint设计原则提炼验证节点的设计规则——粒度要“小到可检查大到可自治”每个checkpoint要求AI提交的不是“我做好了”而是“这是证明我做好的证据”分层验证体系建立自己的safety net从语法层能否编译到行为层测试是否全过到依赖层影响范围评估到契约层是否满足spec边界到业务层是否真正解决问题第三层产品化——让能力脱离你的双手独立产生价值。当你的方法论积累到一定程度可以把它打包成别人也能用的东西。最小启动方式是整理一个开源仓库把spec模板、checkpoint清单、验证检查表分享出去。这本身就是建立行业影响力的方式。如果想更进一步可以做成付费课程或工具。但核心不是变现而是通过输出倒逼输入——当你要把一个方法论讲给别人听时才会发现哪些地方自己其实没想清楚。程序员的出路不在技术在姿态过去程序员的竞争力体现在三个层面代码产量、技术深度、实现速度。AI正在让这三个维度快速贬值。但有三样东西AI短期内无法替代业务判断力——知道什么该做、什么不该做。代码清理案例中“确认哪些产品宏需保留”的判断AI做不了因为它不理解产品历史和业务优先级。约束设计能力——能在模糊需求中识别关键边界设计出可校验、可恢复的系统。这不是写代码的能力而是设计“如何让AI安全执行”的能力。验证定义能力——知道什么样的证据链能证明一件事做对了。AI可以生成代码但它不知道什么算“对”。这三种能力合在一起就是“人定方向”的真正内涵。AI时代的程序员正在从执行者转变为Harness工程师——不再亲自写每一行代码而是设计让AI稳定产出的约束系统。spec怎么写、checkpoint设在哪、验证体系如何分层、什么任务该用哪一级自主性——这些才是新的核心技能。这不是职业危机而是职业进化。就像建筑行业从手工搬砖进化到设计建造系统工程师依然是建筑的灵魂只是工具变了。我现在每天在做的就是训练自己问出更好的问题这个任务的安全边界在哪里什么样的验证配得上这一级自主性如果AI跑偏我能在哪一步发现并拽回来当你能系统性地回答这些问题时你就从一个“会用AI的程序员”变成了一个“驾驭AI的工程师”。而驾驭比操作更有价值。思考题你在工作中遇到过哪些AI跑偏的情况当时是事后才发现还是中途拦截下来的欢迎分享你的经验和应对方法。
