02 | AI 时代，不破不立：程序员的旧能力，需要重新编译一次
AI 时代，不破不立：程序员的旧能力，需要重新编译一次
随着 AI 时代的来临，所有涉及到网络的技术类工种，都越来越焦虑。再加上各种自媒体的夸张和渲染，焦虑让人无法呼吸。让人感觉非常焦虑和浮躁。但是焦虑和浮躁的本质原因是什么呢? 怕被取代，这是一个表面现象。并不是问题的本质原因。我的结论是: 怕是对未知事情的不了解。
- 浮躁是想跳过过程直接拿到结果。
- 焦虑是因为对结果的不确定性。
所以才有了「程序员重生计划」这个系列。它首先不是一套教别人改变的方法，而是小编留给自己的一面镜子：用于重生，用于自省，更用于反省。把困惑写出来，把旧方法重新拆开，再和大家一起寻找新的答案。
我们都知道 AI 很强。过去需要半天完成的接口、页面和单元测试，现在可能十几分钟就能生成。这使我们很容易陷入焦虑：自己学了这么多年的 Java、数据库、前端和架构，是不是突然不值钱了？
小编认为，问题并不是我们的编程储备失效了，而是我们原来的使用方式正在失效。或者是正在被淘汰。
以前，我们把知识直接兑换成代码；现在，我们需要先把知识转换成规则、上下文、约束、验证标准和工作流，再由 AI 帮我们完成执行。
这不是简单地多学一个 AI 工具，而是一次方法论重构。
AI 没有让旧经验失效，它只是让旧经验的调用方式过期了。
一、所谓“不破不立”，我们要破的是什么
“不破不立”听起来很像一句口号。放到今天的开发工作里，我更愿意把它理解为：有些陪伴我们多年的工作惯性，到了重新审视的时候。
1. 破掉“代码必须由我亲手写”的执念
过去，代码是我们最直接的产出。一个人写得快、写得多、写得漂亮，通常就代表生产力高。
但 AI 出现以后，代码的生产成本正在快速下降。一个功能的 CRUD、DTO、单元测试甚至前端页面，都可以批量生成。如果依然坚持每一行都由自己敲出来，多少有点像拿着洗衣板和洗衣机较劲：认真当然没错，只是时间未必花在了最值得的地方。
这并不是说代码不重要，而是说我们的责任重心变了：
- 以前负责把需求翻译成代码；
- 现在负责把需求翻译成 AI 可以稳定执行的工程任务；
- 最后对交付结果负责。
手写代码是一种执行方式，不必成为我们证明专业性的唯一方式。
2. 破掉“学会 API 就等于掌握技术”的学习方式
过去学习一个框架，我们通常会从概念、注解、API 和 Demo 开始。把常用接口练熟，基本就能进项目干活。
但 AI 可以随时查询 API，也可以快速拼出示例代码。单纯记忆语法和调用方式，价值会越来越低。
相比记住更多 API，我现在更关心下面几个问题：
- 这个技术解决什么问题；
- 它的边界和失败模式是什么；
- 什么情况下不能用；
- 如何验证它生成的结果；
- 如何把它沉淀成团队可复用的能力。
说白了，过去我们更在意“怎么写”，现在“怎么判断”正在变得同样重要。
3. 破掉“需求进来，直接开写”的线性工作流
传统开发习惯往往是：理解需求、设计方案、开始编码、提交测试。很多信息都装在开发者脑子里，代码写到哪里，判断就做到哪里。
这种方式在人亲自执行时还能运转，因为人会自动补充上下文。但 AI 不会天然知道公司的业务规则、历史包袱、目录约定和风险边界。
如果输入只有一句“帮我实现退款功能”，AI 当然也能写。只不过它写出来的退款，可能退得很积极，账却没有对上。
这让我越来越确信，“想清楚”和“写代码”需要逐渐拆成两个环节：先把隐性经验显性化，再交给 AI 执行。
4. 破掉“代码能跑，就算完成”的交付标准
AI 最擅长生成“看起来没问题”的结果。
类型正确、结构完整、命名像模像样，甚至还附赠几句注释。但真正进入业务系统后，我们关心的是数据是否一致、并发是否安全、异常能否恢复、权限是否越界、日志是否可追踪。
如果没有明确的验收标准，人写代码会留下 Bug，AI 写代码只会更高效地批量留下 Bug。
因此，比“代码生成了”更可靠的完成标准，是“证据齐全了”。测试结果、构建结果、数据校验、风险说明和回滚方案，都可以成为交付的一部分。
二、不是清空旧知识，而是重新转换
拥抱 AI 很容易被理解成重新学习 Prompt，仿佛以前学的编程知识都要格式化。其实恰恰相反，AI 越强，越需要有人凭借真实的项目经验为它划清边界。
只是过去的知识不能继续只放在脑子里，它们需要转换成 AI 能够消费的工程资产。
| 我们已有的编程储备 | 过去的使用方式 | AI 时代的新载体 |
|---|---|---|
| 业务理解 | 开发者自己记住规则 | 任务说明、领域词典、业务约束 |
| 编码规范 | Code Review 时人工提醒 | 项目规则、模板、静态检查 |
| 架构经验 | 方案评审时口头判断 | 架构决策记录、边界清单、参考实现 |
| 排错经验 | 出问题后人工定位 | 诊断流程、日志规范、可观测性工具 |
| 测试经验 | 开发完成后补测试 | 验收用例、自动评测、回归测试 |
| 项目经验 | 依赖个人记忆和传帮带 | Skill、Workflow、可复用 Agent 流程 |
你会发现，我们不是要抛弃过去，而是要完成一次“重新编译”。
过去的经验主要运行在人的大脑里；未来的经验需要运行在团队的工程系统里。
三、重新建立 AI 时代的工程化方法论
重新审视旧惯性之后，更值得讨论的是：我们能建立什么。
就我目前的实践和理解来看，可以先从四层能力入手：任务契约、上下文工程、执行工作流和结果验证。
1. 把模糊需求变成任务契约
与其上来就让 AI 写代码，不如先花一点时间定义任务。
一个合格的任务契约，至少要回答：
- 要解决什么问题；
- 哪些内容属于本次范围；
- 哪些文件或模块可以修改；
- 哪些业务规则不能破坏；
- 用什么证据证明任务完成。
这和我们过去写接口契约很像。输入、输出、前置条件、异常和验收标准越清晰，执行结果越稳定。
Prompt 只是任务契约的一种表达形式。如果没有工程约束，再华丽的 Prompt 也只是一次临场发挥。
2. 把个人经验变成上下文工程
AI 不缺通用知识，缺的是“你这个项目为什么这么做”。
比如，同样是新增一个订单状态，AI 不知道状态值能不能修改，不知道下游报表是否依赖，不知道消息消费者是否支持，也不知道数据库里有没有历史脏数据。
这些内容以前常靠团队成员口口相传，如今可以逐步整理成可检索、可引用、可更新的上下文：
- 项目结构与模块职责；
- 领域模型与核心术语；
- 关键架构决策；
- 编码规范与禁止事项；
- 常见故障与处理流程；
- 已验证的参考实现。
上下文不是越多越好。真正有效的上下文，是与当前任务相关、没有冲突，并且能够直接约束决策的信息。
3. 把开发过程变成可重复工作流
如果今天提示一句、明天补充一句、后天发现跑偏再重来，AI 用起来确实很像一位记性不太稳定的新同事。这种方式适合试验，却很难支撑长期协作。
如果想让结果稳定下来，可以尝试把过程整理成一套闭环：
- 先读取任务和项目约束；
- 再检查现状与影响范围；
- 给出实施计划；
- 分步骤修改；
- 执行测试和静态检查；
- 根据失败结果继续修正；
- 最后输出变更说明和风险。
当这套流程可以重复执行时，它就不再是一段聊天记录，而可以继续沉淀为 Skill、Workflow，甚至多个 Agent 的协作流程。
这一步很关键。工程化的本质，不是期待 AI 偶尔做对一次，而是让正确的过程有机会重复发生。
4. 把“我看过了”变成自动验证
AI 提高了代码产量，也会同步放大审查压力。如果生成十倍代码，最后仍然全部依靠人工逐行检查，我们只是把瓶颈从编码搬到了 Review。
所以验证方式也要升级：
- 能由编译器判断的，不靠肉眼；
- 能由静态检查发现的，不留到评审；
- 能写成测试用例的，不只写在需求文档里；
- 能通过数据对账验证的，不凭一句“应该没问题”；
- 高风险变更则保留人工决策和回滚入口。
人的精力更适合放在业务正确性、架构边界和风险取舍上，而不是检查括号有没有闭合。
AI 负责提高执行速度，自动化验证负责守住质量下限，人负责最终判断。这才是一套能够进入生产环境的分工。
四、衡量工程价值，编码速度只是其中一部分
以前我们很容易用“写了多少代码”“完成了多少需求”评价一名开发者。但在 AI 时代，这些指标正在逐渐失真。
一个人生成了一万行代码，并不代表他创造了一万行价值，也可能只是给团队新增了一万行维护成本。
在我看来，下面这些能力会越来越重要：
- 能不能把复杂问题拆成清晰任务；
- 能不能为 AI 提供准确上下文；
- 能不能设计稳定、可重复的执行流程；
- 能不能用自动化手段验证结果；
- 能不能识别 AI 不应该替人决策的边界；
- 能不能把一次经验沉淀成团队资产。
这也是为什么，资深开发者的价值并没有因为 AI 而消失。真正的项目经验，本来就不只是会写代码，而是知道哪里容易出事、为什么会出事，以及怎样让系统长期稳定运行。
只是以前这些能力藏在代码背后，现在它们正在被慢慢搬到台前。
五、一次能力转译，可以从真实任务开始
方法论重构未必要等公司发通知，也未必要先搭一个宏大的 Agent 平台。下一项真实任务，就是不错的起点。
下次拿到需求时，可以先不急着让 AI 生成代码，试着多做四件事：
- 写清楚任务边界和验收标准；
- 把脑子里的业务规则整理成上下文；
- 让 AI 按固定步骤执行，而不是自由发挥；
- 用测试、构建和数据结果完成验证。
完成以后，再问自己一个问题：这次过程里，哪些内容可以沉淀成规则、模板、脚本或者 Skill，下一次不必重新解释？
当一次经验可以被复用，个人能力才真正变成了工程能力。
总结
AI 时代的“不破不立”，不是推翻过去，更不是否定我们多年积累的价值。
真正需要松动的，是把编程等同于手写代码、把学习等同于记忆 API、把开发等同于线性执行、把完成等同于代码能跑的旧方法。
在旧方法之外，我们可以慢慢建立另一套工程方法：以任务契约为起点，以上下文为燃料，以工作流为执行方式，以自动验证为质量保障。
过去，我们亲自把知识写成代码。
接下来，也许可以试着把知识写成一套能够持续生产正确结果的系统。
所谓“不破不立”，不是和过去告别，而是换一种方式，让过去的积累继续发挥作用。