AI时代程序员的出路：从写代码到定方向

代码正在变得廉价，但判断力从未如此昂贵

几个月前，我读到一组数据：一位工程师用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可以安全执行的spec：

text

【目标】清理不再使用的代码和资源，保证关键升级不受影响
【范围】
  - 删除已确认不再使用的业务功能代码
  - 删除已废弃平台的适配代码
  - 删除不再使用的资源文件
  - 保留当前产品仍在使用的所有代码路径
【停止条件】
  - 改动依赖度过大时暂停，降低风险后再继续
  - 任何影响关键升级的操作立即停止
【执行顺序】
  - 第一批：低风险删除（人工已确认无用的功能列表）
  - 第二批：中风险删除（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跑偏的情况？当时是事后才发现，还是中途拦截下来的？欢迎分享你的经验和应对方法。