1. 为什么我觉得“跟风AI副业”是一条弯路
最近这半年，我身边冒出来好多搞AI副业的工程师。有人在卖ChatGPT写文案的课，有人做数字人带货的视频，还有人天天研究怎么用AI批量生成小红书笔记。不能说这些人赚不到钱，但如果你是个有几年底子的开发工程师，我看着总觉得哪里不对——你在拿自己最值钱的能力去干最不值钱的事。
副业变现这件事，本质上是在出售时间。卖课需要录制、答疑、运营，做号需要选题、剪辑、维护，就算你有AI工具加持，这些环节里的沟通成本、流量焦虑、交付压力一点都省不掉。你一天就24小时，单位时间的产出天花板摆在那里。更麻烦的是，这些副业和你积累了多年的工程能力完全是两套体系，等于把程序员的核心竞争力丢在一边，去跟一大堆非技术背景的人拼执行力和运营手感。
那工程师该干的到底是什么？我的答案很直接：AI Coding。
我说的AI Coding不是指"会往对话框里丢提示词让它生成几个函数"那种玩票水平，而是把AI当作一个真正的结对编程搭档，融入需求分析、架构设计、编码实现、测试验证、重构维护的完整链路里。说得再直白一点：那些做AI副业的人，是在跟AI抢饭碗；而学会AI Coding的工程师，是在给自己加杠杆。同样的需求规模，别人要写三天的代码，你带着AI一个下午就能跑通；别人读项目源码要啃一周，你让AI帮你梳理出关键路径，半天就能定位到需要改的地方。这种效率差，才是工程师在AI时代安身立命的东西。
所以这篇文章不是劝你放弃搞钱，而是想跟你认真聊聊：为什么AI Coding值得我们投入精力去学，以及真正把它落地到日常开发里到底需要掌握哪些东西。
2. AI Coding和普通编程，差距不在工具在思维
我见过不少同事拿到AI编程工具的第一反应是：让它写一个登录页面，让它写个冒泡排序，然后丢一句"不对，改用Vue"，全程像在跟一个能力很强但极不稳定的实习生对话。这种用法不能说错，但效率极低，而且产出质量完全靠运气。
2.1 从"掌控每一行"到"掌控意图与边界"
传统编程里，我们对代码的控制力是绝对的——每一条分支、每一个变量、每一处异常处理都是我们亲手写的，脑子里有完整的执行路径。到了AI协作阶段，这个模型必须改变。你不再需要写出每一行代码，但你必须比任何时候都清楚"代码应该做什么"和"代码绝对不能做什么"。
我举一个很简单的例子。一个普通程序员让AI写一个文件上传接口，提示词可能就是"写一个上传文件的接口"。AI确实能快速生成一段可以跑的代码，但如果你没有明确说文件大小限制、类型白名单、存储路径策略、文件名冲突处理、鉴权方式、日志规范，它给你的东西大概率是"看起来能用但没办法上生产"的玩具代码。
这里的核心转变是：提问者必须变成需求定义者。你的价值不在于手写那些CRUD逻辑，而在于把模糊的"我要上传功能"拆解成精确的、无歧义的、可验证的工程约束。AI越强，这个能力越值钱，因为它是AI替代不了的那一层。
2.2 提示词的本质是一份需求文档
我后来慢慢意识到，写提示词跟写需求文档是同一件事，只是载体从中文变成了自然语言+代码片段。很多程序员写不好提示词，不是不懂工具，而是从来没有训练过"把事情讲清楚"的能力。
一个好的开发提示词至少应该包含四层信息：目标（要实现什么功能）、约束（技术栈、性能指标、安全要求）、上下文（现有的代码长什么样、放在哪个模块）、验收标准（怎样算做完）。比如让AI生成一个接口，最低限度的提示词是这样的：
请帮我写一个Python FastAPI的上传接口，要求： 1. 仅允许jpg/png/webp格式，大小不超过5MB； 2. 文件保存到 /data/uploads/ 目录，文件名用UUID重命名； 3. 使用项目现有的数据库会话依赖（在app/db.py里的get_db）； 4. 上传成功后返回JSON格式：{ "url": "..." }，失败返回400和错误码； 5. 需要包含基本的异常处理和日志输出，日志用项目里的logger（app/utils/logger.py）。同样的需求，你丢一句"写个上传接口"和丢上面这段，拿回来的代码质量天差地别。原因很简单：AI没有读心术，它的输出上限取决于你输入的信息密度。
2.3 上下文管理才是AI编程的核心能力
如果说提示词是需求文档，那么上下文管理就是架构设计。AI模型有上下文窗口限制，你不可能把一个大型项目整个塞进去让它理解。真正会AI Coding的人，懂得分层递喂：先给整体架构摘要，再给目标模块的核心代码，最后给具体的报错信息和测试用例。
我的习惯是三层喂法。第一层告诉AI这个项目的整体结构和技术栈，让它知道自己在什么环境里工作；第二层把要改动的文件相关的接口定义、数据模型贴进去，给它画出"施工区域"；第三层才是具体的任务描述。做完之后，再根据报错或测试结果，把最新的信息反馈给它。
这本质上是在帮AI做注意力管理。上下文窗口是稀缺资源，谁喂得精准，谁得到的产出就准。很多AI写出来的代码不对劲，回头看提示词，八成是因为用户自己都没搞清楚该让它关注什么。
3. 把环境和工作流搭对，AI Coding才谈得上效率
工具选不对、流程没理顺，AI Coding很容易变成"AI写代码、人改代码"，最后算下来还不如自己写。我从最开始的地狱模式折腾到今天，踩了不少坑，下面说说我现在的固定搭配。
3.1 工具选型：编辑器、模型与成本权衡
先亮我的配置：IDE用的是VS Code加官方AI插件，模型按任务分：日常补全和代码生成用响应快的中型模型，架构梳理和复杂重构用推理能力更强的模型。
选型逻辑很简单：
- 实时补全类工具要的是低延迟、低打断感。你写代码的时候它能接上下文给出下一段，质量过得去就行，不需要每次都惊艳。
- 对话生成类工具要的是上下文理解能力，尤其是处理多文件、跨模块任务时，模型能不能准确理解代码关系是最重要的。
- 独立处理任务的Agent型工具要的是执行可靠性。它要能自己读文件、跑测试、改代码，这时候出错率比速度重要得多。
如果你预算有限，至少保证有一个好用的IDE补全插件和一个支持项目级上下文导入的对话工具，这两者搭配起来的收益已经超过绝大部分"买最贵模型但乱哄哄让它写东西"的用法。
3.2 项目级上下文的准备细节
很多人说AI不理解自己的项目，其实不是模型不行，是你没给它准备"项目地图"。我现在会在每个项目根目录维护一份AI_CONTEXT.md，大概300行左右，内容包括：
- 项目整体架构图（文字版）和技术栈说明；
- 各模块职责说明和关键目录索引；
- 常用数据模型和接口约定；
- 本地开发、测试、构建的具体命令；
- 编码规范和常见约定（比如错误处理方式、日志格式）。
每次让AI动手之前，先把这份文件丢给它，再让它读对应模块的代码。这一步花十分钟，但能让后面省几个小时。它最大的价值是减少AI的"瞎猜"——大部分"AI改坏代码"的事故，都源于它在不了解项目背景的情况下自作主张。
3.3 把开发流程改成"需求-拆解-微任务"三段式
学会AI Coding之后，我个人的开发节奏发生了很大变化。以前是打开IDE直接写，现在是先把任务文本化，再逐层拆解，最后把微任务喂给AI。
具体来说，拿到一个需求后我会先写一段简洁的"任务描述"，包含背景、目标、范围和限制条件。然后把它拆成若干个可以独立验证的微任务，每个微任务控制在50-100行代码规模。拆好了之后，按依赖顺序逐个让AI完成，每完成一个我就跑一次测试或人工审查。
这样做的好处是：每一个步骤都处于可控状态。AI一旦写偏了，我可以立刻发现并纠正，不会出现"写了一大坨才发现方向错了"的情况。拆任务的过程本身也是在逼自己把需求想清楚，这一步无论有没有AI都不能省。
4. 一次完整实操：让AI帮我写完一个CLI工具的配置模块
光说不练没意思，我拿最近一个实际项目里的例子，完整走走一遍流程。项目是一个内部日志分析CLI工具，需要新加一个配置模块，支持从YAML文件读取配置、支持环境变量覆盖、输出标准化后的配置对象。
4.1 需求定义与AI可执行边界
第一步，我没有直接让AI写代码，而是先把需求写清楚。在项目的AI_CONTEXT.md里记录了这个CLI工具的入口、现有的日志Logger、参数解析用的是哪个库、测试框架是pytest等。然后我定义了这个任务的边界：
- 只做配置模块，不碰现有命令执行逻辑；
- 配置优先级：命令行参数 > 环境变量 > YAML文件默认值；
- YAML解析用项目里已有的PyYAML，不要引入新依赖；
- 输出配置对象需要做数据校验，非法类型要报错并指明字段名；
- 兼容Python 3.9及以上版本。
这些约束不写清楚，AI大概率会自作主张引入pydantic、给你整一套dataclass魔法，最后风格和项目完全不搭。
4.2 提示词设计的第一版和第二版
第一版提示词我大概这么写的：
在项目根目录下新建 config.py，实现配置加载功能。 配置来源优先级：CLI参数 > 环境变量 > YAML文件。 YAML文件路径通过 --config 参数传入，环境变量以 LOG_ANALYZER_ 为前缀。 默认配置写在 config.example.yaml 里。 配置项包括：log_dir、log_pattern、output_format、workers、batch_size。 完成后写对应单元测试。这个版本能跑，但AI生成的代码有个问题：它对"环境变量命名规则"理解得比较机械，直接用了环境变量的原始名称，没做前缀剥离和命名映射。而且关于"非法类型处理"只用了简单的try-except，信息丢失严重。
于是我给了第二轮反馈，把第一版代码里我指出的问题写明确：
环境变量 LOG_ANALYZER_LOG_DIR 应该映射到配置项 log_dir，注意剥离前缀并转小写下划线。 类型校验失败时要输出完整字段路径，例如 "config.log_pattern 必须是字符串，当前得到 int"。 不要打印堆栈，直接抛自定义的 ConfigError 异常，由上层统一处理。4.3 生成、审查、修复的完整循环
在提示词迭代中我总结出的经验是：第一版求"覆盖"，第二版求"对齐"，第三版才求"完美"。先让AI把所有功能点粗略覆盖一遍，看清整体结构，然后再针对结构、命名、异常处理等细节逐轮修正。这个流程很像带一个聪明但缺乏经验的初级工程师，你没法指望一次交代就完事，但每一轮反馈之后，它的产出质量都会显著提升。
这次实操里，我和AI总共往返了四轮。第一轮拿到基本可运行的代码和测试；第二轮修正环境变量映射和异常处理；第三轮我手动审查时发现配置项的默认值定义分散，不符合项目"默认值集中管理"的约定，让它把默认值抽成一个DEFAULT_CONFIG字典；第四轮补了测试覆盖率，把遗漏的"环境变量为空字符串需要当作未设置"这个边界条件补齐。
最终这个模块大概250行代码，测试50行，我实际手动写的部分不到30行，主要是审查、修正和补充边界测试。整体耗时大概一个半小时，而如果是从零手写，同样的质量水平我至少要三到四个小时。关键不是代码量省了多少，而是全程的节奏感和可控性都很好，每一步都知道自己在哪里。
5. AI写代码最容易翻车的四个场景，我踩过以后这么处理
AI Coding用多了，你会发现它翻车的模式其实很固定。把这些场景摸清楚，你就能在它犯错之前拦下来，或者在犯错之后快速定位修复。
5.1 边界条件缺失：代码"看起来对"但经不起推敲
这是最常见的一类问题。AI生成的分页函数不处理page=0的情况，读文件的代码不处理文件不存在的情形，字符串处理不关心空值和编码问题。它倾向于覆盖"快乐路径"，而把异常路径留给调用者。
我的对策是在提示词里显式加一句"请考虑所有正常的边界条件和异常分支"。这句话能让错误率下降一大截。另外审查代码时我会刻意去测几个反直觉的边界值——空字符串、None、超大数值、编码混杂的文本，这些地方是AI最薄弱的。
5.2 API幻觉：一本正经地编造不存在的接口
这个坑尤其隐蔽。AI在训练数据里见过大量开源库的用法，但它记不住确切版本，经常把不同版本的接口混在一起生成出来。最典型的例子是让我用某个库写代码，它自信地调用了三个不存在的参数，然后代码跑起来直接AttributeError。你检查它的代码，语法正确、逻辑通顺，就是跑不通。
我的处理方式是：涉及第三方库的关键API调用，不让AI凭记忆写，而是先把官方文档或库的签名贴给它，让它基于真实签名写代码。另外，任何AI生成的新依赖用法，我都要求它给出对应的版本和来源。如果回答含糊，就直接让它读取本地已安装库的__init__.py和类型定义文件，宁可多花一分钟，也不让它基于幻觉硬编。
5.3 测试覆盖的空洞：测试通过不等于程序正确
AI写的测试有个通病：它测试的是"自己代码的行为"，而不是"需求要求的正确行为"。换句话说，如果实现逻辑本身就是错的，那么测试很可能跟着错——你让它写一个排序函数和对应的测试，它可能会写出一个"用自己实现的排序逻辑断言输出"的测试二重身，最后所有断言都过，但排序结果确实是错的。
针对这个问题，我现在的原则是测试的桩函数和关键断言必须由人来定义：输入什么数据、期望得到什么输出、出现什么错误，这些必须人工指定。AI可以负责生成测试框架和辅助代码，但核心断言不允许它自己写。
5.4 过度设计与技术栈不统一
AI受过海量最佳实践的投喂，特别喜欢引入新依赖、新设计模式，哪怕你的项目里根本没有那套东西。你让它加个配置功能，它给你塞一个依赖注入框架；你让它修个Bug，它顺手重构了你半个文件。这种"顺手改善"在生产项目里是大忌。
我的对策是在项目说明文件里写死技术约定，同时在每次任务描述里加一行"遵循项目现有代码风格，不引入新依赖，不修改与本次任务无关的代码"。每次生成后人工diff也必须重点关注修改范围的扩散情况，一旦发现无关改动，马上让它撤销。
6. 学会AI Coding以后，工程师真正的路怎么走
最后聊聊更远一点的事。当我真正把AI Coding嵌入日常工作流程以后，我对"工程师价值"的理解发生了一些变化。
6.1 从"写代码的人"到"定义问题的人"
以前我们评价一个工程师的水平，常看他手写代码的速度和熟练度。但在AI时代，写代码本身正在变得越来越廉价，真正稀缺的是两件事：一是准确理解业务需求并把它转化成精确工程约束的能力，二是在AI产出大量代码后快速定位问题、判断质量、做出取舍的能力。
换句话说，工程师的角色在从"生产者"变成"架构师+审查者"。这个转变不是坏事，它意味着我们终于可以把时间从重复劳动里解放出来，放到更有创造性的部分——系统设计、用户研究、性能优化、代码质量文化建设。
6.2 保持审查力和审慎心
当然，我还是要泼一盆冷水。AI Coding带来的效率提升是真实的，但它也要求我们付出对等的责任心。AI生成的每一行代码，最终都要有一个人为它兜底。出线上事故的时候，背锅的是工程师，不会是模型。所以我建议无论工具多好用，都保留几条底线：
- 不理解的代码不合并，为了效率抛弃理解力，迟早会还债；
- 关键路径（支付、鉴权、数据一致性）必须人工逐行审查，不让AI独立交付；
- 保持手写代码的手感，哪怕AI写得更快，定期手写一些核心逻辑有助于保持对代码的真正掌控力；
- 把AI当作一个能力超强但需要管理的搭档，而不是神。
我自己在实操中的体会是，AI Coding最迷人之处在于它让你重新定义了"效率"这个词。以前一个功能从想法到落地要经历漫长的编码调试循环，现在这个循环被大幅压缩，你反而有更多时间想清楚做什么、为什么做。每天下班前看一眼当天合并的代码量，再想想那些时间节省下来能做什么，你会觉得这条路走对了。
最后分享一个小技巧：不要只把AI当写代码的，试试让它帮你做技术方案评审和代码走查。把它当一面镜子，你会发现很多自己已经"看麻木"的问题，它反而能一眼挑出来。这是AI Coding带给我的最大惊喜，也建议你亲自试一试。
