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. 需要包含基本的异常处理和日志输出日志用项目里的loggerapp/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生成的分页函数不处理page0的情况读文件的代码不处理文件不存在的情形字符串处理不关心空值和编码问题。它倾向于覆盖快乐路径而把异常路径留给调用者。我的对策是在提示词里显式加一句请考虑所有正常的边界条件和异常分支。这句话能让错误率下降一大截。另外审查代码时我会刻意去测几个反直觉的边界值——空字符串、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带给我的最大惊喜也建议你亲自试一试。