1.1 传统手写代码时代：从需求到程序，开发者要完成哪些工作

做一张书桌，木工要先确定尺寸，再选材料、画线、切割和组装。工具能帮助他锯得更快、更整齐，但桌子该多高、能不能承重，仍需要他判断。以人工编写代码为主的软件开发也是如此：开发者把人的需求拆成计算机能够执行的步骤，并负责检查结果。

这里的“传统”是一种工作方式，不是以某一年为界的历史断代。早在生成式 AI 普及之前，开发者就会使用代码补全、模板、框架、自动化测试和现成的开源库，并非每个字都从头手打。今天，这种以人主导设计和实现的方式仍然广泛存在。

写一个功能，为什么不只是敲几行代码

以“给读书笔记增加搜索功能”为例。需求听起来很短，真正开始做时却要回答一连串问题：搜索标题还是正文？大小写是否影响结果？没找到内容时显示什么？笔记很多时，搜索会不会变慢？

开发者通常会按下面的过程推进：

真正费时间的地方，往往在于理解已有系统、消除需求歧义和定位问题。键盘输入只是其中一环，所以评价开发效率时，不能只比较每分钟写了多少行。

学习编程时，最容易遇到的是语法错误。例如，英文引号写成了中文引号，或者缩进不一致，解释器就可能无法读懂代码。报错信息会指出它在哪里遇到了问题，未必代表整个网站都会崩溃。

更难发现的是逻辑错误：程序能正常运行，但算出的结果不符合需求。比如“满 100 元免运费”写成了“大于 100 元免运费”，恰好 100 元的订单就会多收钱。这类问题无法靠检查拼写发现，需要拿具体例子验证。

还有一种常见情况是环境不同。同一份代码在同事电脑上能运行，在你这里却找不到依赖包。此时应检查软件版本、配置文件和启动方式，而不是立刻修改业务逻辑。

用户注册、参数校验、数据库读写、错误提示等功能，常常有相似的结构。这些重复部分通常被称为“样板代码”。框架、模板和代码生成工具一直在减少这类劳动。

但“重复”不等于“无用”。对输入进行检查、处理失败情况、记录日志，看起来都不如核心功能显眼，却会影响程序在真实使用中的可靠性。把这些代码全部删掉，页面可能仍然能打开，遇到异常时却无法解释发生了什么。

AI 后来带来的帮助，主要是更容易根据当前需求生成这些实现。开发者仍需要判断：哪些约定应沿用，哪些代码可以复用，哪些地方必须单独处理。

理解人工开发的过程，能帮助你给 AI 安排合理的任务。如果只说“把搜索做好”，它必须自行猜测上述细节；如果提供搜索规则、相关文件和验收例子，它就有了明确的工作依据。

初学者不必先背下所有语法再接触 AI，但应逐渐掌握三件事：看懂数据从哪里来、知道程序在哪里作出判断、能够检查结果是否符合要求。后续工具再怎么变化，这三件事都用得上。

可以先练习描述一个熟悉的小功能。以“记录本月支出”为例，写清允许输入什么、金额如何累计、记录能否删除，以及关闭页面后数据是否还在。这份说明本身就是开发工作的起点。