最近一个月我至少刷到几十篇“普通人AI副业月入过万”的帖子什么AI漫剧、AI建站、AI一键生成PPT、AI写作变现一个比一个热闹。作为一个写了十几年代码、最近又把大量开发工作迁移到AI辅助流程上的工程师我的建议非常直接别去追那些副业把时间押在AI Coding上。原因不复杂。AI副业卖的是“AI能干的体力活”本质上是在用你的时间去换平台流量和零钱而AI Coding是把你十几年积累的专业判断力变成杠杆用AI放大你写代码、读代码、维护代码的底层能力。前者是消耗后者是复利。这篇文章我打算把自己最近的AI Coding实践完整拆开讲包含我为什么不用AI做副业、AI Coding到底学的什么、一个真实项目如何用AI Coding跑通、以及我踩过的坑和正在用的提示词模板适合所有正在观望AI编程的工程师参考。1. 为什么别跟风AI副业工程师该把时间押在AI Coding上1.1 AI副业的本质是计件劳动不是资产积累先做一个冷静的拆解。市面上那些AI副业项目不管是AI漫剧、AI建站、AI做PPT还是AI写带货文案它们的共同特征是生产过程高度标准化产出物高度同质化进入门槛极低。这意味着什么意味着你赚到的每一分钱本质上都是平台算法的“分发费”而不是你劳动创造的独特价值。我用一个类比说明。AI副业就像工地上的挖掘机操作员AI是挖掘机你是那个坐在驾驶室里的人。刚开始你会觉得“我会开挖掘机了比搬砖强”确实如此第一批操作员确实吃到了红利。但很快你就会发现能开挖掘机的人越来越多而挖掘机本身也越来越智能操作员从“技术工种”退化成了“看仪表的人”计件工资自然越来越低。对工程师来说这个逻辑更残酷。一个擅长写Python脚本的人去做AI漫剧本质上是放弃了自己最稀缺的“复杂系统理解能力”去和所有会用AI工具的人拼“谁的视频剪得多”。这不是能力升级这是能力套现而且套现的还是最不值钱的那部分。1.2 AI Coding的本质是把专业判断力杠杆化AI Coding完全不同。它发生在你自己的专业领域内部服务的对象是那些你需要真正负责质量的代码库、架构设计和业务逻辑。在这个领域里AI不是在替代你做事而是在放大你的判断力。举个例子。我一个朋友在传统金融公司做内部系统最近让他评估一个老旧模块的重构方案。他用ChatGPT问“这段代码怎么优化”得到的答案非常通用——建议拆分函数、增加单元测试、使用设计模式听着都对但放到他的业务上下文里完全不可用因为那个模块有特定的事务边界和历史兼容性约束通用建议只会把事情搞得更糟。但同样是这个人把整个模块的背景、约束、调用链贴进上下文用一条经过设计的提示词让AI给出方案AI给出的答案就精准得多——它甚至指出了“这里可以去掉一个历史遗留的兼容层因为调用方已经在今年全部升级了”。这个判断力不是AI自己得出的是我朋友在提示词里把“兼容层存在的原因和废弃条件”写清楚了AI只是帮他快速梳理了调用链。这就是AI Coding的本质你的领域知识越深AI能帮你的就越多。副业是把你的能力拉低到AI的平均水平上去竞争而AI Coding是把你的能力以AI的生成速度放大。两者的方向完全相反。1.3 一组真实对比谁在“用AI”谁在“被AI用”我用最近观察到的两组工程师状态做对比可能比抽象论述更直观。A工程师三年经验执行力很强。他发现AI能做PPT和文案后每天下班做AI副业一个月大概赚两三千。但他白天的开发工作完全没变甚至因为晚上熬夜做副业白天写代码的精力明显下降。半年后他的副业收入没有增长因为平台流量偏好变了他的账号数据反而开始下滑。B工程师也是三年经验没有做任何副业。他把精力全部放在研究AI编程上先熟练使用Cursor再学会把项目需求拆解成任务清单交给AI最后搭建了一套自己的“需求文档任务拆解AI生成自动化测试”工作流。半年后他一个人完成了一个原本需要三个人做的内部工具代码质量还有提升因为测试覆盖率反而上去了。他开始在公司内部分享这套方法影响力逐渐积累。A在“用AI”但他用AI做的事情不具备不可替代性B也在“用AI”但他用AI做的事情全部围绕自己的专业积累展开越做越深。六年后的差距不用我多说了。2. AI Coding的能力拆解提示词、上下文、Agent与多模型协作2.1 提示词工程你写的是“意图”不是“代码”很多人一上来就问“哪个AI编程工具最厉害”实际上更基础的问题是你有没有把需求表达清楚。传统编程是“告诉计算机怎么做”AI Coding是“告诉AI你要什么”两者思维模式完全不同。你写的是意图需要让AI能基于意图生成代码。我自己在用的一套提示词结构大致有这么几层角色设定、任务描述、输入输出定义、硬性约束、参考示例。举个例子我让AI重构一个Python模块时的提示词是这样写的你是一名Python后端工程师请对 services/order.py 中的 OrderService 类做性能重构。 任务描述 该类当前在批量查询订单时存在N1查询问题请改为使用SQLAlchemy的joinedload一次性加载关联商品信息。 输入输出 - 输入order_ids列表可能为空 - 输出保持原有方法签名和返回值结构不变 硬性约束 - 不允许修改数据库表结构 - 不允许引入新的第三方依赖 - 所有改动的代码必须通过项目现有的pytest测试 参考示例 参考本仓库中 services/cart.py 里 CartService.query_with_items 方法的写法保持风格一致。注意这段话的结构。角色设定让AI进入正确的专业状态任务描述足够具体直接指出了N1问题和想要的解决方案“输入输出”和“硬性约束”规范了生成结果的边界“参考示例”则是锁定代码风格的关键——大模型是概率生成器你给它的示例越接近你想要的风格它输出的内容就越一致。这里顺便解释一个常见的困惑“为什么我给AI的提示词已经很长了生成代码还是不符合要求”答案往往是——你只写了“要做什么”没写“不能做什么”。约束条件才是提示词里最能体现你专业判断力的部分。一个新人看不出这个模块为什么不能用新依赖但你作为工程师知道这个项目要兼容某套老环境新增依赖会有连锁风险。这就是专业经验变成提示词价值的地方。2.2 上下文管理AI代码质量的上限由这里决定可以说单轮提示词只是AI Coding的起点真正的分水岭是上下文管理。大模型有上下文窗口限制你不可能把整个代码库都塞进一次对话里。实际使用中我一般把项目按“代码库索引 会话分段 关键决策文档”三层来管理。代码库索引指的是用Cursor或者Claude Code这类工具时先让AI扫描整个仓库生成一个索引之后提问时它会自动搜索相关文件。这比你自己贴代码文件进对话要精准得多而且不会撑爆上下文窗口。会话分段是更重要的习惯。不要在一个会话里同时问“帮我重构下单模块”和“帮我排查登录接口的Bug”这是两类完全不同的任务混在一起会让AI的判断产生干扰。我的习惯是一个会话只做一类事做完就开新会话。如果你发现AI开始忘记你早期的指令比如你明明在第一轮说过“不要使用requests库”它到第五轮还是用了那就不用怀疑上下文已经失控了应该立刻开新会话把关键约束重新写一遍。关键决策文档是我最近才真正执行到位的做法。我会在项目根目录放一个AI_CONTEXT.md文件里面写清楚这个项目的核心约束技术栈版本、禁止使用的依赖、目录结构约定、常见的业务边界条件。每次开新会话时提示词第一句让AI读这个文件然后再开始任务。效果极其明显AI出错的概率降低了大概一半因为很多约定不需要你在每次对话里反复重复了。2.3 Agent模式从“问答式编程”转向“授权式编程”刚开始用AI编程工具时大家的交互模式是“问答式”你问一句AI回一段你审查、复制、粘贴、改改。这种模式对简单任务够用但对复杂任务效率提升有限。更进阶的模式是“授权式”也就是让AI以Agent形态自主执行多步骤任务。比如我经常用Claude的Agent模式做这类任务请梳理 services/payment/ 目录下的依赖关系列出所有模块之间的调用链找出循环依赖或者明显违反分层架构的地方输出一份Markdown格式的重构建议报告。注意只输出分析和建议不要修改任何代码。这种任务如果人工做需要打开IDE逐个文件点开看整理依赖图最后写报告可能要用一个下午。Agent模式大概几分钟就可以完成而且它给出的调用链分析相当完整会顺带指出我没有注意到的隐藏依赖。但我要强调的是Agent不是自动驾驶它更像一个执行力强但需要你把控方向的下属。工程师的职责并没有消失而是从“写代码”变成了“定义任务、审查结果、纠正偏差”。这本质上和带新人是类似的——你需要把任务拆解到颗粒度足够细它才能执行到位。如果你自己都没想清楚要做什么Agent只会更快地做出一个漂亮但错误的东西。2.4 多AI协作让不同模型在流水线里各司其职实际使用中我还有一个心得不同模型擅长的事情差异极大不要一棵树上吊死。我现在的工作流是多模型协作的。日常开发和代码生成主用Claude它的长上下文和代码理解能力最强适合处理涉及多个文件的复杂重构。快速问答、API用法查询、正则表达式调整这类小任务我用ChatGPT类的通用大模型顺手就能处理不用去挤占主线上下文。代码解释、注释生成、把一段陈旧代码翻译成现代写法这些小活我用轻量的小模型就足够——写注释这件事不需要最强推理能力小模型速度快、成本低。这个过程很像带一个团队。团队里有人擅长架构设计有人擅长快速响应有人擅长琐碎的文档活重点不是每个人都很强而是你清楚每个人适合干什么然后合理派活。多AI协作也一样你要建立自己的“AI分工表”而不是试图一个模型搞定所有事情。这背后也牵扯到一点AI大模型基础原理的理解不同模型在训练数据、参数量、上下文窗口设计上差异巨大导致它们在代码生成、长文本理解、指令跟随上的表现各不相同。理解这一点你就能在选型时做出有针对性的判断而不是盲目跟风换工具。3. 实操用AI Coding跑通一个内部工具项目3.1 项目选型选择能体现你专业判断力的场景实践AI Coding的第一步不是学工具而是选对场景。我的建议是选一个你自己专业领域内的小型项目最好是那种“你完全懂业务但嫌写起来麻烦”的工具。我用自己最近的一个项目举例。当时我需要一个内部数据导出工具从几个不同的数据库读取数据做字段映射清洗数据最后生成Excel报表。这类工具本身不复杂但涉及的数据源、业务口径、导出格式要求全是只有内部人才知道的信息。完美的AI Coding练手场景。选择这个项目有两个理由。第一因为它足够真实需求维度丰富能让你完整跑一遍AI Coding流程。第二因为它足够小一个下午就能完成就算AI生成了一堆错误代码你也有足够的业务判断力去发现并修正——这比选一个你完全不懂的领域要安全得多。3.2 工具选型主流AI编程工具横向对比在正式开始实战前先解决工具选型问题。我用了将近两个月的AI编程工具覆盖了市面主流的几个做一个横向对比工具核心能力多文件编辑Agent/自动化能力终端集成适用场景GitHub CopilotIDE内自动补全代码生成质量高局限主要处理当前文件较弱有日常编码加速Cursor多文件上下文理解强支持代码库问答强支持需配置规则有需要理解整个代码库的重构任务Claude Code / Codex终端内运行Agent式多步任务执行极强强可自主执行任务序列原生自动重构、跨文件分析和复杂任务JetBrains AI Assistant与IDE深度集成一般中有已有JetBrains工作流的团队通义灵码Fitten等国产插件国内网络友好中文理解好一般较弱有日常补全和解释中文需求表达我的实际使用组合是日常开发用JetBrains AI Assistant和Copilot做代码补全复杂重构和跨文件任务交给Cursor需要完整Agent式执行时用Claude Code在终端里跑。这个组合覆盖了我开发中的三层需求每一层用最顺手的工具而不是指望一个工具解决所有问题。需要提醒的是工具迭代太快几个月后对比表可能就变了。关键是理解每个工具的能力边界选型时要基于自己的项目规模和上下文需求来判断而不是只看“哪个热门”。3.3 五步实战流程从需求文档到测试通过选好工具和项目后我用的AI Coding实战流程分为五步每一步都有明确的产出物和验收标准。第一步写需求文档。这是最重要的一步也是最容易偷懒的一步。即使你准备让AI帮你写代码需求也必须你自己写因为只有你完全理解业务。写清楚数据源类型、表结构、抽取逻辑、清洗规则、导出格式、异常处理方式。我这份需求文档大约2000字内容非常具体比如“订单金额字段统一转为分为单位不需要四舍五入直接截断”这种细节都写进去了。第二步拆解任务清单。把大项目拆成AI能分步执行的小任务。这个项目我拆成四个任务读取各数据库并适配表结构、字段映射与清洗逻辑、Excel导出模块、主流程串联与命令行参数解析。每个任务控制在AI能一次性生成完整可运行代码的规模。第三步逐模块生成代码。一个任务一个会话每个会话的提示词都按照前面介绍的“角色任务约束示例”结构来写。每个模块生成后立刻让人工审查一遍核心逻辑再进入下一个模块。这一步人为控制了风险范围问题最多出现在单模块内定位起来非常快。第四步自动化测试兜底。模块全部生成后编写基础测试覆盖主要数据流。比如给一个“金额字段断尾截断”的测试给一个“空数据源导出”的测试给一个“字段映射失败时报警”的测试。跑通测试不是目的目的是验证AI生成逻辑在边界条件下是否正确。这一步绝对不能省。第五步代码Review和重构。AI生成的代码即使能跑风格和组织方式也需要人工审查。我做了一轮主要调整把AI分散在各模块里的重复代码抽成一个公共函数把几个命名混乱的变量改清楚去掉一个AI生成的但实际上毫无用途的配置项。这一步让代码从“能跑”变成“好维护”也确保代码是你能理解和负责的。整个流程下来这个工具从开始到上线用了大概一个工作日其中AI生成代码大约占一半时间剩下的一半时间全是我在做需求梳理和代码审查。这和传统的开发方式相比效率提升我认为在两倍以上。3.4 可直接复用的提示词模板我把自己在实战中验证过、效果稳定的一组提示词模板整理在这里你可以直接参考使用。新建功能模块模板请为 [项目名称] 新增一个 [功能描述] 模块。 背景 [写清楚业务场景和调用方] 功能点 1. [功能点1给出具体输入输出] 2. [功能点2] 技术约束 - 使用 [技术栈/框架] 符合项目现有风格 - 文件放在 [指定目录] 下 - 不允许修改 [指定的已有文件/依赖] 完成后请输出 - 新增文件的完整代码 - 调用方式的简单说明 - 需要补充的测试用例清单代码重构模板请重构 [文件/函数名] 中的 [具体问题如重复代码/长函数/命名混乱]。 重构目标 [描述你期望达到的结构比如“拆分为多个小函数每个函数只做一件事”] 约束 - 保持对外的函数签名不变 - 不要改变现有的业务逻辑 - 重构后请进行自检给出你认为可能受影响的位置 参考风格 [可以是项目内其他文件的写法示例也可以说“保持与现有代码最接近的风格”]排查Bug模板以下代码 [贴代码] 在执行 [操作] 时出现 [错误日志/异常现象]。 请按以下顺序帮我排查 1. 指出最可能的三个原因并标注概率 2. 对每个原因给出对应的检查方法 3. 确认原因后给出修复建议不要直接改代码 约束 - 只分析已贴出的代码不要假设不存在的函数或变量 - 如果你觉得缺少关键信息直接告诉我需要补充什么这套模板最大的价值不是“照抄就行”而是让我每次和AI沟通时都保持了结构化的表达能力。模板用多了之后你会逐渐内化这种表达方式即使离开模板也能自然地把约束条件和业务边界说清楚。4. 常见问题与避坑技巧实录4.1 “代码能编译≠逻辑正确”的翻车现场AI生成代码最迷惑人的地方在于它看起来非常专业类型注解齐全函数拆分合理命名也很规范但一跑起来逻辑完全不对。这种问题我刚开始用AI Coding时几乎每天都会遇到。有一次让AI写一个日期区间处理函数它写得很漂亮逻辑也通顺直到我把数据一跑才发现它在处理边界时用的是“闭区间”而业务需求是“左闭右开”——差一个端点导致统计数字全错。这就是典型的现象AI生成的是“看起来合理的代码”而不是“验证过正确的代码”。它不懂你的业务口径它只是基于训练数据预测了一段大概率合适的文本。我现在的处理办法是凡是AI生成的代码一律默认它不可靠。跑测试只是第一关还要针对边界条件和业务特殊逻辑做定向验证。我在提示词里会专门加上“必须在注释中明确说明对边界条件的处理假设”这样至少能暴露AI自己也没想清楚的地方让我有机会在审查时发现。4.2 上下文漂移AI为什么会“忘记”你最初的约束上下文漂移是AI Coding里非常折磨人的一个问题。你第一轮说“不要修改数据库表结构”AI严格遵守了但聊到第五轮、第六轮时它开始给你推荐“加一个字段来存储冗余数据”——完全忘记了最初约束。这不是AI笨而是上下文窗口被大量信息挤占后早期指令的“注意力权重”被稀释了。大模型处理长对话时后面的内容天然会影响它对全局约束的关注度这是一个机制性问题。我总结了一套非常实用的应对措施。首先把硬性约束写进项目根目录的AI_CONTEXT.md每次开新会话时让AI先读取它把约束前置到对话的最前面。其次一个会话只做一个任务不给它“自由发挥”的空间。第三如果发现AI开始跑偏不要试图提醒它“我之前说过了”直接开新会话并把约束重新完整贴一遍这比重启对话更快也更能保证不再跑偏。4.3 安全红线密钥、生产数据与许可证问题使用AI编程工具时安全是一个必须正式对待的问题。尤其是现在很多Agent模式需要读取你的整个代码库数据会发送到AI服务商的服务器上做推理如果代码库里有生产环境的密钥、客户数据或者敏感业务逻辑就会产生实际风险。我的原则是绝不让AI代处理任何包含生产凭据的文件。涉及密钥的代码我手工处理或者用环境变量引用方式让AI生成代码但密钥本身不出现在代码里。同时我会定期检查项目里有没有不小心提交的.env文件被AI意外读取这类事故虽然不常见但一旦发生后果严重。还有一个常被忽略的问题是许可证风险。AI训练数据里包含大量开源代码它生成的代码片段有时会非常接近某个开源项目的实现而这一段代码可能带有GPL等传染性许可证。如果直接进入商业项目可能会引发法律问题。我的处理方法是对AI生成的代码做安全审查时不只看功能还会留意那些“特别眼熟”的代码段。如果你生成的是常用算法的典型实现一般没问题但如果是某个特定库的内部实现细节就要提高警惕了。4.4 给AI Coding装一道保险测试先行最后一个避坑技巧可能是最有效的。我现在的习惯是凡是让AI写一个有一定逻辑复杂度的方法或模块会要求它“先写测试再写实现”或者至少“并行产出测试用例清单”。这么做有很直接的好处。一方面测试是AI代码质量的客观仲裁者。AI很擅长为它自己的代码编写对应的测试——反过来说让AI先写测试就是先用文字把你的需求硬约束固化下来之后生成实现代码时它会更谨慎地保持行为一致。另一方面测试先行的过程会逼迫你把需求想得更清楚“这个函数对空输入应该返回什么”“这个场景下要不要抛异常”这些问题如果不在写代码前定义好实现阶段一定会乱。我最近让AI写一个“金额转换”函数时它在实现代码里写了四舍五入但我先让它写的测试用例里明确写了3.14159保留两位小数的期望值是3.14还是3.15——测试用例一写AI就发现自己的实现和测试期望不一致主动纠正成了截断处理。这比我后期人工发现问题再回炉重造高效得多。5. 工程师的AI Coding学习路径从工具使用者到工作流设计者5.1 第一个月让AI成为你的结对编程搭子学习AI Coding不需要一开始就追求大而全的Agent工作流。第一个月的目标就一个让AI成为你日常开发的“结对编程搭子”。具体做什么写代码时让AI提供实现方案遇到Bug让AI帮忙分析看不懂的旧代码让AI解释日常重复性工作让AI做一遍然后你审查。这阶段最关键的习惯是“凡是动手之前先想一下这件事能不能让AI做”。不要刻意追求AI生成多少行代码而是训练自己识别“什么任务适合交给AI”的直觉。一个月下来你的日常开发效率应该有至少20%~30%的提升同时你已经积累了自己的提示词风格和使用心得。5.2 第二至三个月引入Agent和自动化流程有了第一阶段的基础第二到三个月可以尝试把AI Coding推向更复杂的场景。重点是把上一节说的“五步实战流程”完整跑通选一个自己领域内的小项目从需求文档开始到任务拆解、模块生成、测试验证、代码Review完整地走一遍。这套流程走完你就完成了从“工具使用者”到“工作流设计者”的转变。你不再是一句一句地和AI对话而是设计一个完整的任务体系让AI在其中工作。到这个阶段你已经可以开始思考如何让AI Coding帮助身边的同事或者把一些标准化的开发流程做成团队内部的操作指南。这本质上也是一个AI模型的工程化落地过程——你已经在设计一个完整的“AI辅助软件开发流水线”了。5.3 持续演进把AI Coding固化到团队工作流再往深走可以考虑把这套工作流推广到团队层面。我建议别一上来就要求所有人用同一个工具那样大概率会失败。更靠谱的做法是先在自己负责的项目里跑通一个完整的AI Coding模板包括需求文档模板、任务拆解规范、测试用例标准然后分享给一个愿意尝试的同事做出一个标杆案例后其他人自然会被吸引。团队推广时最有可能遇到的阻力是“AI生成的代码质量不稳定”的质疑。这个问题通常不是工具造成的而是流程没设计好。如果有人把需求描述得模棱两可AI生成代码跑不通那是提示词的问题不是AI的问题。所以把好的提示词模板和工作流沉淀成文档和引入工具本身同等重要。5.4 记住一件事AI是放大器不是替代品写了这么多最后想收敛到一个可能有点反常识的结论AI Coding学的不是“怎么用AI”而是“怎么把你脑子里的领域知识表达成AI能理解的约束”。这句话的意思是AI生成的代码永远需要你审查AI的架构建议永远需要你判断取舍Agent的执行结果永远需要你负责。你不理解的东西让AI写出来只会得到一堆运行正常但业务上不负责任的代码。反过来你越懂自己的业务就越能把AI的能力用到位。这也回应了标题那句话不要跟风AI副业。副业教不会你“表达约束的能力”它只会让你更快地消耗时间而AI Coding的练习每一次都在强化你的需求拆解能力、技术判断力和工程质量意识。工具会换代工作流会更换但“把复杂业务变成可执行任务”的能力永远是最值钱的。我个人在实际操作中最深的一个体会是AI Coding真正改变我的不是写代码的速度而是我思考任务的粒度。以前我会直接敲键盘现在我会先想清楚“这个任务可以被拆成几步、每步的验收标准是什么”然后才开始干活。就冲这一点我觉得 AI Coding值得每一个工程师认真投入时间去学。