给自己留一块不用 AI 的编程自留地

AI 编程工具适合提高交付速度，但程序员仍应长期保留一个由自己主导、关键代码亲手完成的项目。这样做不是排斥 AI，也不是把低效率当作美德，而是给代码阅读、问题分解、调试和设计判断留出稳定的训练场。当工具生成的代码无法工作、生产环境限制模型接入，或者系统进入复杂故障状态时，开发者仍能理解现场并接管问题，这才是“编程自留地”的实际价值。

为什么需要一块不用 AI 生成代码的空间

依赖大语言模型生成代码的软件开发方式，能够快速完成原型、样板代码和常见功能。它的优势是真实的：开发者可以用自然语言描述目标，让工具在较短时间内给出可运行的初稿，再通过测试和提示迭代。但速度会改变人的工作方式。开发者容易从“构造系统的人”变成“判断结果看起来是否可用的人”，而阅读一个现成方案与从约束出发亲自形成方案，锻炼的能力并不相同。

手写代码最重要的训练，不是记忆语法，而是连续做出细小且相互影响的决策。例如，一个模块应该暴露哪些接口，状态由谁拥有，失败是否重试，数据何时持久化，测试应在哪一层拦截回归。生成式工具往往一次给出完整结构，许多决定被隐藏在结果里。即使开发者逐行审查，也可能只是在确认代码“说得通”，没有经历备选方案之间的取舍。

当这种取舍长期缺席，最先退化的通常不是敲代码的速度，而是建立心智模型的能力。开发者可能会使用版本控制、容器或框架，却说不清工作区、暂存区与提交之间的关系，也无法判断容器网络、挂载和进程生命周期如何共同造成故障。工具正常时问题不明显；一旦错误跨越多个层次，缺乏模型的人只能继续转述报错并等待下一次生成。

自留地不是生产环境里的禁用令

自留地应与业务交付分开管理。生产项目通常关注成本、期限、质量和协作，没有必要为了练习而拒绝一切自动化。个人训练项目关注的是能力保持，可以主动限制代码生成，让自己承担分析与实现过程。两种模式服务于不同目标，不应互相冒充。

“不用 AI”也需要清楚定义。一个可操作的边界是：不让模型直接生成要提交的代码、测试、配置和修复补丁；允许查阅语言与框架文档，也允许向 AI 询问概念或讨论多个设计方向，但最终方案必须由自己验证和实现。编辑器的符号补全、格式化、静态检查和单行机械补全可以保留，因为它们主要减少输入负担，不替代核心设计。

边界不必追求纯粹。真正要避免的是把尚未理解的成片代码直接纳入项目。如果一次讨论已经给出了近乎完整的实现，可以先关闭对话，根据自己的笔记重新设计，并在提交说明中记录关键决定。训练目标是让思考链条属于开发者，而不是证明自己能够忍受低效工具。

怎样选择合适的手写项目

项目太小，只会反复练习语法；项目太大，又容易在基础设施上耗尽耐心。合适的项目应当能够持续数月，有真实输入和失败场景，并包含至少两到三个技术边界。命令行笔记工具、小型任务调度器、日志分析服务、局域网文件同步器或迷你运行时都可以成为候选。关键不是题材新颖，而是需求会逐步演化。

可以先写一页约束清单：项目解决什么问题，明确不做什么，数据存在哪里，允许哪些依赖，怎样确认功能正确。第一阶段只实现最小闭环。例如任务调度器只需读取任务、按时执行、记录结果和处理退出，不要一开始加入分布式选主、插件市场或复杂控制台。主动压缩范围，才能把注意力放在设计决定上。

依赖也应克制，但不必重复发明所有基础设施。使用成熟的数据库驱动、测试框架和序列化库是合理的；自行实现加密算法、网络协议或数据库通常既危险又偏离训练目标。判断标准是：这个组件是否属于你想训练的核心。如果目标是理解调度，就亲手设计任务状态机；如果目标是掌握存储，就应亲手处理迁移、事务和恢复，而不是把它们全部交给框架默认值。

建立一套可持续的训练规则

先写约束，再写代码

每个功能开始前，用短文记录输入、输出、不变量和失败方式。以“保存任务”为例，不要只写一个创建接口，还要明确重复标识如何处理、写入中断后是否留下半成品、时间字段采用什么基准。随后再设计数据结构和函数签名。这个过程会迫使开发者在实现之前暴露模糊之处。

小步提交并解释决定

每次提交只包含一个可说明的变化，并在提交信息里写清目的。遇到两种方案时，可在决策日志中记录选择、代价和重新评估条件。几周后回看这些记录，比回看一批生成结果更容易理解系统为何演变成现在的样子，也能发现自己经常忽略的风险。

让测试验证行为，而不是装饰覆盖率

先为核心规则写少量测试，再补充失败路径。状态机应测试非法转换，持久化应测试回滚和重复执行，解析器应测试空输入、边界值与畸形数据。不要为了数字给简单访问器堆测试，也不要声称没有运行过的测试已经通过。测试的价值在于让设计意图可以重复检查。

功能完成条件：
1. 正常路径可由自动化测试重复验证
2. 至少一个预期失败路径有明确结果
3. 日志能够定位失败发生在哪个阶段
4. 重新启动后，持久状态仍符合不变量
5. 开发者能脱离代码解释数据流与控制流

定期进行无辅助排错

每隔一段时间主动制造一个可恢复故障，例如破坏配置、让依赖超时、模拟磁盘写入失败或制造竞态条件。先观察日志和状态，再提出假设、设计验证步骤，最后修复。排错时记录“现象、假设、证据、结论”，能够有效阻止随机修改。真实工程能力往往体现在缩小问题范围，而不是一次猜中答案。

如何判断训练是否有效

行数、提交次数和开发时长都不是可靠指标。更有意义的检查是：能否画出主要模块和依赖方向；能否说明一次请求或任务从进入到完成经过哪些状态；能否在没有生成式工具的情况下定位一个回归；能否指出当前设计最脆弱的三个位置；能否删掉不再必要的抽象。回答越具体，说明对系统的掌控越真实。

还可以设置季度复盘。选择一个早期模块，重新阅读需求、测试和提交记录，判断当初的抽象是否经受住变化。若需要重构，先描述旧设计为什么阻碍新需求，再实施最小修改。不要为了展示技术而整体重写，因为维护已有约束、兼容数据和控制风险，才更接近真实工程。

新手可让有经验的开发者只审查设计和代码，不直接给出完整实现。评审意见应落到可验证的问题上，例如资源是否释放、错误是否被吞掉、接口是否泄露内部状态。老手则可以选择不熟悉但范围可控的领域，避免只在舒适区重复已经自动化的动作。

常见误区与调整方法

第一个误区是把手写等同于拒绝文档和现成库。自留地训练的是判断与实现，不是闭门猜测。权威文档、规范、源码和调试器都应正常使用。第二个误区是项目只新增功能，从不维护旧代码。没有兼容、迁移、故障和删除，自留地很快会退化为一次性练习。

第三个误区是规则过严导致项目停摆。如果下班后精力有限，可以固定每周两次、每次四十五分钟，只推进一个小目标。遇到两小时仍无法突破的问题，可先查资料或与 AI 讨论概念，但不要直接接收补丁。把获得的线索转化为自己的实验，仍能保留训练价值。

第四个误区是把不用 AI 当作职业优越感。AI 生成代码可以显著提高原型和交付效率，合理使用它本身也是工程能力。自留地的意义在于补上效率工具不负责的那部分：对细节的触感、对失败的耐心、对系统全貌的记忆，以及在自动化失效时独立行动的能力。

把手写能力带回 AI 协作流程

自留地最终不应与日常工作割裂。亲手积累的经验会改善提示、审查和验收：开发者更容易给出准确约束，识别不必要的复杂度，要求工具补齐失败路径，并拒绝表面合理但破坏系统不变量的实现。此时 AI 是放大已有判断力的工具，而不是替代判断力的黑箱。

可以把工作分成三层：目标和约束由人负责，候选实现可以由工具加速，最终证据由测试、观测和人工审查提供。对安全、数据迁移、权限和不可逆操作，提高人工介入程度；对样板代码和低风险转换，允许更多自动化。自留地持续训练的，正是决定何时放手、何时接管的能力。

给自己保留一个手写项目，不要求回到没有工具的年代。它更像固定的基础训练：规模可以小，节奏可以慢，但必须真实、持续并接受失败。只要开发者仍能解释系统、验证假设、修复故障并为设计取舍负责，AI 带来的速度就会成为能力的乘数，而不会悄悄替代能力本身。