AI 编程时代，为什么还要给自己留一块“手写代码”的自留地？

AI 可以显著提高编码速度，但速度并不等于能力已经内化。给自己保留一块“手写代码”的自留地，真正要保护的不是敲键盘的熟练度，而是从模糊需求出发，独立完成建模、取舍、实现、调试和验证的完整能力。生产项目当然可以继续使用 AI；自留地则像一套定期演练机制，让开发者确认自己仍能解释系统、识别坏方案，并在自动生成失效时接管现场。

AI 提效后，最容易被忽略的能力是什么

使用 AI 编程时，开发者经常从“构造方案的人”变成“选择方案的人”。输入需求后，工具会快速给出目录结构、依赖、接口、测试甚至提交说明。这样的协作没有问题，但选择一个看起来合理的答案，和亲自推导出答案，调用的是两套不同的认知过程。

当代码由自己逐步写出时，每个命名、数据结构、错误分支和模块边界都需要主动决定。开发者会更早遇到矛盾：一个对象到底负责状态还是行为，缓存失效由谁管理，异常应该在本层处理还是向上传递。生成式工具往往一次给出一整片实现，局部看都说得通，累积起来却可能形成不必要的抽象、重复状态或隐含耦合。只做快速审查，很容易错过这些缓慢形成的结构问题。

因此，能力退化通常不是突然“不会写语法”，而是三个更隐蔽的变化：遇到空白文件时难以起步，离开生成工具后无法把问题拆小，以及面对一段能运行但设计欠佳的代码时说不清哪里不对。这些问题会直接影响代码审查、故障处理和技术决策，尤其会削弱资深开发者应有的接管能力。

手写自留地训练的是完整反馈回路

所谓手写项目，并不要求拒绝所有智能工具，也不意味着回到低效率的工作方式。关键约束是：核心实现由自己输入，设计结论由自己推导，错误由自己定位，验收标准由自己制定。AI 可以充当讨论对象，帮助解释文档或质疑方案，但不直接交付可粘贴的主体代码。

这个约束会恢复一条重要的反馈回路：先形成假设，再写出最小实现，通过编译、测试或运行结果发现偏差，然后修改心智模型。只有亲历这个循环，开发者才会知道某个方案为何成立、在哪些边界会失败。单纯阅读生成结果也能获得知识，却很难替代“预测结果后被事实纠正”的训练。

手写还会迫使人控制复杂度。一个功能需要亲自实现时，额外的层、配置项和依赖都会产生切实成本，开发者自然会追问它们是否必要。让 AI 批量生成时，这些成本暂时被隐藏，直到需求变化或故障出现才集中暴露。自留地不是为了证明人比工具写得快，而是让复杂度重新变得可感知。

怎样选择一块合适的自留地

合适的项目应当小到能持续推进，又复杂到需要真实决策。一次性算法题只能训练局部技巧；照着教程复制应用，则缺少需求与设计取舍。更好的选题通常来自自己的日常需求，例如命令行日志整理器、本地笔记索引、小型任务调度器、浏览器扩展，或者现有业务之外的精简版服务。

项目最好同时包含输入、状态、失败处理和可验证输出。以本地文件索引器为例，它需要处理目录遍历、编码错误、增量更新、重复文件、查询接口和性能边界。规模不必大，却足以暴露数据模型、模块职责和测试策略上的问题。比起追求功能数量，更重要的是让每个功能都闭环。

选题时可以用四个条件过滤：一是两周内能做出最小可用版本；二是每周仍能提出一个真实改进；三是结果可以通过测试或实际使用验证；四是技术栈至少有一部分是自己熟悉的。若项目全部由陌生技术组成，时间会耗在查语法和搭环境上，反而削弱设计训练。

给手写项目设定清晰边界

自留地能否长期存在，取决于规则是否明确。可以把工具使用分成三层。第一层是允许的机械辅助，例如编辑器跳转、格式化、静态检查和单词补全；它们不会替你决定实现。第二层是允许讨论但禁止复制的辅助，例如让 AI 解释概念、列出风险、审视设计问题。第三层是项目中暂不使用的代码生成，包括整段函数、测试用例和自动重构。

边界不必成为道德判断。生产任务需要交付速度，完全可以采用另一套规则。自留地的价值恰恰来自它是受控训练环境，失败不会拖累业务，慢一些也可以接受。把训练项目与生产项目分开，能避免在截止日期压力下反复破例。

建议在仓库中写一份很短的约束说明，记录哪些工具可用、哪些不可用，以及什么情况可以临时求助。例如，连续定位同一问题超过九十分钟后，可以让 AI 提供排查方向，但仍由自己实施修复。规则越具体，越容易判断训练是否真的发生。

用一个可执行周期开始

先写问题和验收条件

第一天不要急着搭出庞大架构。先用几句话说明用户是谁、输入是什么、输出是什么，再列出三到五条验收条件。比如“给定一个目录，程序能建立文本文件索引；文件损坏时不中断整个任务；重复执行只处理发生变化的文件”。这些条件会约束后续设计，也能阻止项目无限扩张。

画出最小数据流

把系统压缩成输入、转换、存储和输出四部分，明确数据在每一步的形态。此时只选择当前需求需要的抽象，不提前为未知场景设计插件系统。若两个模块的边界说不清，先把它们放在一起；当变化方向真正分离时再拆分，比预先制造接口更容易保持系统可理解。

纵向完成一个闭环

不要先写完所有模型，再写所有存储，最后才尝试运行。选择最小场景，从入口一直做到可观察结果。例如只索引一个文件并完成一次查询。纵向切片能尽早验证关键假设，也让每次工作结束时都有可运行状态。

记录决策而非流水账

每次编码后只记录三个问题：今天做了哪个重要决定，放弃了什么替代方案，什么证据会让我改主意。这样的记录会积累成设计判断的样本。几周后回看，能够发现自己是经常过度抽象、忽略异常，还是低估了数据一致性。

如何判断能力是否真的在提升

代码行数和提交次数不是合适指标。手写训练应该观察可迁移能力。首先看预测准确度：修改之前，能否说出会影响哪些模块、可能出现什么失败；运行测试后，实际结果与预测差距多大。预测越来越准确，说明对系统的心智模型正在变清晰。

其次看解释能力。随机选择一个核心函数，尝试不看实现说明它的输入、输出、不变量和失败方式。如果只能描述代码表面动作，却说不出为什么这样设计，说明理解仍不牢固。还可以隔一周再处理一个小需求，观察重新进入上下文需要多久。

第三看排错过程。遇到错误时先写下三个最可能原因，再根据日志、断点或最小复现逐个排除。不要立即大范围改代码。有效的调试不是碰巧修好，而是每一步都能缩小问题空间。保留简短的排错记录，比保留大量成功截图更有训练价值。

最后看简化能力。每完成一个阶段，检查能否删除一个抽象、合并一层转发、减少一种状态，或者让错误处理更一致。成熟度往往体现在知道什么不必存在，而不只是能继续添加功能。

把手写能力带回 AI 协作

手写训练的最终目的不是建立两个互不相干的世界，而是提高与 AI 协作时的判断质量。经历过完整实现后，开发者能给出更明确的约束：数据所有权在哪里，哪些不变量不能破坏，什么行为必须测试，哪些模块不得扩大职责。提示会更具体，生成结果也更容易验收。

代码审查方式也会变化。不要只问“这段代码能不能跑”，而应依次检查需求是否被准确表达、状态是否只有一个可信来源、失败是否可观察、抽象是否早于实际变化、测试是否覆盖了风险。AI 生成的代码可以很流畅，但流畅并不能证明边界正确。

对于关键修改，可以建立接管测试：关闭生成能力，从问题描述开始，独立解释相关模块并手工完成一个小修复。若无法做到，就说明当前系统的理解债务已经过高，需要降低生成速度，补读代码、补测试或重写局部设计说明。

常见误区与调整方式

第一个误区是把手写等同于背诵 API。记不住命令或函数名并不代表能力不足，查阅文档仍然是正常工作。真正应独立完成的是问题分解、方案选择和证据验证。可以查语法，但不要把整个问题直接交出去。

第二个误区是选一个过大的项目，然后因进度缓慢而放弃。自留地不需要成为完整产品。宁可做一个边界明确、长期维护的小工具，也不要在脚手架、账号系统和部署平台上耗尽兴趣。若四次编码仍没有可运行结果，应立即缩小目标。

第三个误区是完全不用 AI，却继续机械照抄搜索结果。训练关键不在信息来自哪里，而在是否经过自己的推理和验证。阅读资料后应合上示例，按自己的数据结构重新实现，并用测试说明理解是否正确。

第四个误区是只写新功能，不维护旧代码。真实工程能力包含重构、迁移和故障处理。可以定期故意改变一条约束，例如把内存存储换成文件存储、让任务支持取消、处理一次数据格式升级。变化会检验原有边界是否可靠，也会暴露先前被快乐路径掩盖的问题。

形成可持续的双轨节奏

较现实的安排是把大部分生产编码继续交给高效的人机协作，同时每周预留两到四小时维护自留地。每次只完成一个纵向小目标，并在结束前保证项目可运行、测试通过、下一步清晰。稳定频率比集中投入一个周末更能抵抗能力退化。

每四周可以做一次复盘：挑选一个设计决定重新评估，手工修复一个真实缺陷，删除一处不必要的复杂度，再把学到的审查规则应用到 AI 生成的生产代码中。这样，手写项目就不是怀旧活动，而是一套持续校准工程判断的机制。

AI 编程时代真正稀缺的并非产出代码的速度，而是对代码后果负责的能力。保留一块手写自留地，能让开发者持续拥有从零构建、识别风险、验证假设和接管系统的底气。工具可以承担越来越多施工工作，但目标、边界与质量判断仍需要一个理解全局的人；手写训练正是在维护这种理解。