16万行代码不是一次性“敲”出来的是“跑”出来的。这里的跑有两种含义一是项目不断迭代、持续演进代码总量像雪球一样滚起来二是AI Coding工具在背后不停生成、修改、再生成把写代码这件事变成了流水线作业。很多人问我AI写代码到底靠不靠谱16万行里有多少是AI写的真正把AI Coding用到一个中型项目里你才会发现它根本不是“打字机”而是需要一套叫AI Engineering的方法论去约束、审查、修复和沉淀。下面我把自己踩过的坑和跑通的方法拆开讲清楚适合正在用或准备用AI辅助开发的技术团队也适合想理解AI Coding边界的前后端工程师。1. 别把AI Coding当成“打字机”16万行代码背后的工程分层16万行代码看起来是一个让人咋舌的数字但真正拉开差距的不是代码行数而是行数背后的管理方式。如果把AI Coding单纯理解为“用AI快速打字”那它只能帮你完成一些零碎片段如果把它放进AI Engineering的框架里它才能支撑起一个可以长期演进的项目。我经历过一个真实项目从零开始到16万行最终能稳定交付依靠的是一套分层思路。1.1 为什么需要16万行代码业务复杂度先于代码规模先说结论16万行不是我们追求的目标是业务复杂度逼出来的。以我参与过的“客户运营中台”为例它包含十几个子系统权限体系、客户档案、标签管理、工单流程、数据分析看板、定时任务、消息通知、导入导出中心。每个子系统还要支持Web端和移动端两套形态。哪怕每个模块都克制到极致只要涉及多种角色、多种工作流、多种报表口径代码量就会自然突破十万行。这不是堆代码而是业务本身需要这么多实现细节。我见过有些团队为了让“AI效益”看起来明显故意让AI生成大量同类代码比如把几十个相似的DTO、工具方法、配置文件批量复制出来。这种代码行数再高也毫无价值反而增加维护负担。所以在动手前必须先分清代码量是“业务投影”还是“技术债”。只有前者才值得我们用AI去加速后者只会让AI成为垃圾制造器。1.2 AI Coding与AI Engineering的分工AI Coding和AI Engineering不是同一个东西这一点如果不讲清楚很容易迷失。AI Coding解决的是“能不能把一段程序写出来”AI Engineering解决的是“这段程序能不能安全地存在于一个系统里”。生活类比一下AI Coding像请了个能说会道的写手几分钟就能出一篇稿子AI Engineering是编辑部流程要管选题、审稿、排版、校对最后保证稿子印出来不出事故。没有编辑部写手再快也只是在制造文字垃圾。维度AI CodingAI Engineering关注点生成一段可用代码让代码在系统中长期存活产出物函数、类、组件架构、规范、测试、可维护性常见失败代码能跑但没人敢改体系太僵化没人愿意用时间尺度秒级月级、年级核心动作生成、修复、补全约束、评审、演化AI Coding擅长从零到一AI Engineering擅长从一到一百。很多人用AI写码翻车不是因为AI不行而是只用了AI Coding没上AI Engineering。比如让AI生成批量函数却完全没有贴项目规范结果造出一堆不符合团队风格的代码后面接手的同事直接骂娘。这种“生成一时爽维护火葬场”的体验几乎每个用过AI写代码的人都遇到过。1.3 一个核心判断代码里“能生成”和“能演化”是两码事“能生成”是指AI形成代码文本听起来很轻松但代码进入仓库后需要经受依赖升级、需求变更、故障修复。AI生成的代码如果没有配套“演化能力”过两周就会变成技术债。我越来越倾向用三个条件判断AI生成的代码是否合格一是否符合团队现有命名和分层习惯二是否被至少一个测试用例保护三在诊断插件下是否没有高频警告。三条同时满足才算“能演化”的代码。如果只是“能生成”今天AI生成一百行明天就可能成为别人修改时想删又不敢删的障碍物。16万行代码之所以能“跑”起来正是因为每一批AI产出都要过这三关。凡是通不过的一律退回重写绝不让它流入主干。这是AI Engineering里最朴素、也最有效的规则。2. 让AI代码“不乱”AI Coding代码生成规范怎么定如果AI Coding是野马规范就是缰绳。没有规范100个人用AI会产出100种风格的代码项目会迅速变成一座无法进入的丛林。我们团队很早就意识到这件事所以把AI Coding的规范写成了团队内部文档并且持续更新。下面这套规则不是想象出来的是经历了大量返工后总结出来的。2.1 团队级的AI生成代码规范可直接抄作业我们团队定了六条铁律每一条背后都有实际教训。AI只能生成“函数级/组件级”代码禁止让AI生成跨模块的大文件。函数级出错影响面小定位快大文件出错你连问题源头都找不到。生成的代码必须包含标识注释例如在文件头加# AI-GENERATED方便后续统计和溯源。生成结果必须通过本地编译、Lint、单元测试后才能进入MR。AI写的代码充其量是“提案”不是“定稿”。涉及权限、支付、数据删除的高风险模块AI只能生成草案最终代码必须由人重写。这条我们称之为“红线模块”。提示词中必须携带项目本地规范片段包括命名、分层、异常处理方式禁止只丢一句“帮我写个接口”。AI不允许“默认依赖”所有第三方库必须先确认版本再让AI生成。否则它可能凭空引用一个不存在的API编译直接挂。这六条写清楚后AI生成的代码质量稳定了很多。尤其是第一条很多团队没有限制AI生成文件大小最后得到几千行的“怪物文件”别说AI人类自己看了都想删库跑路。2.2 别让你跟AI的“对话”变成一笔糊涂账AI Coding写代码本质上是“上下文工程”你给的上下文越具体产出越好。不要只说“帮我写个接口”要说清楚数据模型、已有字段、路由风格、返回结构。我常用一个任务卡格式把需求结构化地丢给AI字段说明目标要做什么输入输出是什么上下文相关文件路径、现有接口、数据表结构约束命名、分层、异常处理、禁用技术验收测试命令、诊断插件要求把这个格式贴在提示词开头AI的产出质量会有明显提升。另外AI Coding最怕“文字背景丢失”对话拉长后AI会忘记前面约定甚至自相矛盾。所以生成一个函数就开一个新对话旧对话只用来修Bug。这是我的实操习惯刚开始时我没注意经常在一个对话里又生成又修改越到后面AI越“糊涂”改A坏B。2.3 代码诊断插件和AI是“最佳拍档”热词里“代码诊断插件”出现频率很高说明很多人已经意识到AI生成代码之后需要一道自动检查防线。我们在IDE里长期开着SonarLint、ESLint、pylintAI生成完代码之后第一件事不是看逻辑而是看诊断面板的红色警告数。红色警告超过三个直接丢回去重写这个策略省掉了大量Review时间。诊断插件能自动发现未使用变量、重复代码、超长函数、深层嵌套这些恰好都是AI最常见的风格病。后来我们更进一步把诊断规则文件直接喂给AI让它按照规则生成效果比生成后再修更好。比如前端项目把ESLint的no-console、max-lines-per-function等规则贴进提示词AI生成的代码一次通过率立刻提高。2.4 顺着“AI Coding笔试”聊聊怎么判断一个人会不会用AI现在招聘里“AI Coding笔试”越来越热但很多公司还在用传统算法题这其实没有区分度。我面试时不会让候选人手写快速排序而是给一段模糊需求让他用AI辅助产出。重点看三个点一会不会把需求拆成AI可执行的任务二给AI的提示词是否包含约束三产出后是否主动跑测试和诊断插件。这三步能区分“只会复制粘贴”和“具备AI Engineering意识”的人。只会复制粘贴的人通常直接把任务丢给AI然后AI说什么他信什么有工程意识的人会先在脑海中拆解需求再补上项目的约束条件最后把AI的输出当“候选方案”来验证。如果你自己也想把AI Coding作为加分项建议刻意练习“拆需求、提约束、验结果”这三个动作这是AI Engineering的基本功。3. 16万行代码实操全过程从一个空仓库到交付很多人好奇16万行代码到底是怎么一点一点“跑”出来的接下来我按实操顺序拆解分为四个阶段。整个过程最关键的不是“让AI写得多”而是“怎么控制AI写的每一段代码都落在系统的正确位置上”。3.1 阶段一把需求“翻译”成AI能理解的任务我们从业务侧拿到需求不是直接写代码而是先做模块拆分。比如“客户运营中台”拆分出30个模块每个模块再拆成若干任务卡最终产出几百张任务卡。每张任务卡就是一个AI Coding单元。关键原则是一张卡片只解决一件事卡片之间尽量无状态、无隐式依赖。这样才能让AI在短上下文内完成高质量输出。演示一张任务卡实例模块订单查询需求根据用户ID查询近30天订单汇总输入user_id: int输出List[OrderSummary]含total_amount, order_count约束使用SQLAlchemy Core不使用ORM遵守项目异常规范验收pytest test_order_query.py 通过pylint score 8把任务卡喂给AI它就能直接输出可用的片段。整个过程像“把大象放进冰箱”先拆解再翻译最后执行。没有这一步AI很容易生成出看似完整、实则不知道为谁服务的代码。这大概就是我们常说的“AI Coding好不好用关键在提问者”。3.2 阶段二让AI生成代码的实操流程附示例实操步骤基本固定初始化项目骨架。我们用FastAPI模板先人工搭好目录结构固定Python版本和依赖版本。让AI生成核心实体/模型。把表结构DDL喂给AI让它生成SQLAlchemy模型。让AI生成Repository层。约定方法命名例如find_by_user_id_and_date_range。让AI生成API路由。约束返回JSON结构。人工合并代码跑一遍pytest。这里举一个实际生成示例。假设要做一个订单汇总接口提示词可以这样写项目customer-ops 技术栈Python 3.11, FastAPI, SQLAlchemy 2.0, PostgreSQL 数据表 orders: id BIGINT PK user_id BIGINT status VARCHAR(20) amount NUMERIC(10,2) created_at TIMESTAMP 请编写用户订单汇总服务函数 get_order_summary(session: AsyncSession, user_id: int) - dict。 要求 - 统计用户近30天内有效订单statuspaid的总金额和订单数 - 使用SQLAlchemy 2.0 style select禁止使用ORM对象 - 返回 {total_amount: 123.45, order_count: 2} - 若用户不存在返回空结果但不要抛异常 - 用logging记录查询耗时 - 在文件头部加 # AI-GENERATEDAI生成的代码可能类似# AI-GENERATED import logging from datetime import datetime, timedelta from sqlalchemy import Select, func, select from sqlalchemy.ext.asyncio import AsyncSession from app.db import models logger logging.getLogger(__name__) async def get_order_summary(session: AsyncSession, user_id: int) - dict: Return order summary for the last 30 days. since datetime.now() - timedelta(days30) stmt: Select ( select( func.coalesce(func.sum(models.Order.amount), 0).label(total_amount), func.count(models.Order.id).label(order_count), ) .where( models.Order.user_id user_id, models.Order.status paid, models.Order.created_at since, ) ) result (await session.execute(stmt)).one() return { total_amount: {:.2f}.format(result.total_amount), order_count: result.order_count, }这段代码看起来能跑但离交付还有距离。它没处理result为空的极端情况也没考虑 Decimal 格式化的精度问题。这些细节依靠AI自己发现很难必须靠人来看。所谓“AI生成80分人工补20分”那20分往往才是决定系统稳定的关键。如果pytest失败我会把报错信息直接复制粘贴给AI让它修复。注意修改时最好新开一个对话把原始代码和报错一起贴进去不要用原来的长对话否则历史信息会让它越改越乱。3.3 阶段三用诊断插件和自动化测试把16万行代码“焊死”代码积攒多了必须上工程化门禁。我们在CI里固定跑以下检查Flake8和ESLint负责Lintmypy和TypeScript strict负责类型检查pytest和vitest负责单测SonarQube负责代码诊断重点看重复率和复杂度最后用bandit和npm audit做安全扫描。所有检查通过之后才允许合并到主干。门禁的价值在于它不信任任何单次生成的代码而是用统一标准去卡所有人。我们统计过最初AI生成代码的一次通过率只有三成上了门禁和规范之后慢慢到了七成。所谓“16万行代码跑出来”其实是被门禁逼着迭代出来的。AI每生成一版就扔到这些检查里跑一遍不过就回去修直到通过为止。这个过程很枯燥但恰恰是它保证了代码库不失控。3.4 阶段四从“生成”到“演进”——AI Coding真实维护姿势代码上线只是开始绝大部分工程工作在后续三个月需求变化、接口调整、依赖升级。AI Coding在维护阶段的正确用法是“小步修改”。比如新增一个字段不要重新生成整个文件而是把现有文件内容、新增需求、测试结果贴给AI让它只改对应函数。我踩过一个大坑有次让AI“重写整个模块”结果它把别处的逻辑悄悄改坏了测试跑了两轮才发现。后来我养成一个习惯每次给AI的修改范围必须限定在单个函数或组件并且用diff review逐行查看。这也是从AI Coding升级到AI Engineering的分水岭你会开始管理“修改的边界”。一个不会控制修改边界的团队用AI重构主干代码往往就是灾难的开始。4. AI Coding会不会拉低代码质量实测下来关键在于“门禁”“AI Coding的到来会不会让代码质量下降”这是很多团队关心的问题。我的答案很直接如果你不上工程化门禁AI Coding绝对会让代码质量断崖式下跌如果你像我们一样把规范、测试、诊断插件全部接进去AI Coding反而能帮你把中型项目稳稳落地。问题从来不在工具而在使用工具时是否设置了防错机制。4.1 质量问题从哪来先泼盆冷水AI生成代码的坏味道很集中大量重复代码、上下文不落地的伪抽象、隐藏的冗余查询、对第三方API的幻觉使用。比如有一次AI生成文件上传代码引用了一个并不存在的SDK方法本地编译直接失败。这些问题的根源不是AI笨而是它没有系统全局观只能在token范围内做局部预测。它不知道项目里已经有公共上传组件也不知道某个接口的真实返回结构。所以“生成”和“可靠”之间必须架设门禁。门禁既包括自动化的诊断插件、测试、Lint规则也包括人工的code review。很多团队只做了自动化却没有让有经验的人去review diff结果AI生成的“合理但错误”的代码悄悄潜入主干。这种错误往往要等到生产告警才暴露修复成本成倍上升。4.2 常见问题速查表建议收藏我们在16万行代码的实操过程中遇到的高频问题基本都在这张表里问题现象可能原因排查与处理AI代码报找不到模块依赖未安装或版本错固定requirements版本再重新生成功能看似正确但性能差自动生成了N1查询用慢SQL日志定位提示词里禁止循环内查询界面样式混乱组件库规则没进提示词把组件库规范文件注入提示词同一个功能每轮生成不同上下文不足或对话过长拆小卡片新对话重试诊断插件报警一堆AI未遵循代码规范把lint规则文件贴在提示词里改一个字段引发大量故障AI修改范围失控限定只改单个函数diff review每一条背后都有真实教训。特别是N1查询AI不会主动做批量查询它天然倾向于在循环里一条条查。你在提示词里写一句“禁止在循环内查询数据库”能直接避免大量性能事故。4.3 多智能体AI Agent协作开发的尝试我们试过用多智能体AI Agent协作开发这也是热词里频繁出现的玩法。具体分工是Agent A负责写代码Agent B负责审代码Agent C负责补测试。A根据任务卡生成接口B针对A的输出做静态分析和逻辑审查C再基于A和B的最终结果生成测试用例。这个模式不是概念炒作实测能拦下不少低级错误。但多智能体不是万能药Agent之间互相“脑补”时会创造上下文里的假事实。比如审查Agent可能根据“经验”判断某个API不存在导致误报测试Agent生成的测试用例可能完全不匹配实际业务规则。所以必须保留人类终审。角色分工可以参考Agent角色输入输出编码Agent实现需求任务卡代码片段审查Agent识别坏味道代码片段规范审查意见清单测试Agent编写测试代码片段接口定义pytest测试文件使用多智能体后我认为最有价值的不是“让AI互相把关”而是让每个Agent只专注一个狭窄目标从而减少单模型在长链任务中的遗忘。和人工一样单一职责能显著提高稳定性。4.4 让AI帮你做代码整理和重构的正确姿势热词“代码整理”其实也是一项适合AI的能力。AI不仅能生成代码还能整理代码把大函数拆小、重命名变量、抽取公共组件。做法是先在Git上开分支跑一遍全量测试然后给AI指定待重构的函数要求它“只重构不改变对外行为”。重构完再跑全量测试。我踩过坑AI重构时会“顺手”优化一些逻辑导致行为变化看起来是改进实际上是隐患。比如把if x is not None改成if x遇到空字符串和0时结果就完全变了。所以每次重构后必须检查diff重点关注“不该改的有没有被改”。实操中我会在提示词里明确写一句“不允许修改任何测试文件和接口定义”这句话能挡掉不少自作聪明。5. 落到工程上AI Coding到AI Engineering的沉淀清单16万行代码的项目做完后我们沉淀出一套自己的AI Engineering实践这里分享四个支撑点。这些不是理论而是每个季度都会复盘更新的操作清单。5.1 四个支撑点上下文、门禁、可追溯、演进上下文工程是第一支撑点。AI的产出质量高度依赖输入上下文我们把项目结构、代码规范、现有调用方式打包成文档每次生成前从中摘取相关片段。门禁是第二支撑点严格做到静态检查、单测、人工评审三件套。AI输出只是提案门禁才是裁决。做到了这两点代码质量的下限就锁住了。可追溯是第三支撑点。所有AI生成的代码都要打# AI-GENERATED标签我们用它做统计和追责。哪些模块AI写得好哪些模块AI总出问题一段时间后一目了然。这个数据反过来指导我们调整提示词规范。演进是第四支撑点。AI工程化的落脚点不是“今天生成得多好”而是“半年后还改得动”。我们会定期用AI做小步重构保持模块拆分合理防止代码腐化。5.2 现在团队的一天从把“红色警告”丢给AI开始我们的日常开发流程已经和AI深度绑定。早上到岗先同步代码本地跑诊断插件把红色警告的文件列表导出来AI负责批量修复低风险问题然后人工review。高风险的逻辑改动还是人先写草案AI做代码补全和测试生成。这种工作方式下16万行代码不是一堆静态文件而是每天都在变化的活系统。有人问AI会不会取代程序员我的看法是AI Coding取代的是“打字时间”不是“思考时间”。思考时间仍然是工程核心。团队里的资深工程师现在把更多精力放在架构决策、边界控制、疑难Bug排查上而不是纠结某个函数怎么写。这也解释了为什么AI Coding会导致“初级重复劳动减少综合判断能力增值”。5.3 给团队和个人的几条实在建议如果你正准备把AI Coding引入项目有几点建议可以直接拿走。先拿一个中小型模块试跑AI Coding不要一上来就把核心系统交给AI。把“AI生成代码”和“AI辅助修改”两条路线分开练后者更难更需要工程基础。代码行数不是KPI有效代码才是。AI生成1000行没人维护的代码不如100行经过评审的代码。规范文档要及时更新因为AI会根据你给的规范“有样学样”规范烂代码就烂。多观察诊断插件的同类告警把高频告警变成提示词约束能明显减少AI返工。这些建议不是我拍脑袋想出来的每一条都对应踩过的坑。比如不把诊断告警变成提示词约束时AI每轮都会重复同样的错误直到你把规则写进提示词。带完这个16万行的项目我最深的感受是AI Coding让“写代码”变得便宜但让“决定代码怎么活”变得昂贵。那些只看重生成速度、不看工程约束的团队很快会被自己制造的混乱反噬。反过来如果你愿意在规范和门禁上花时间AI能帮你把过去不敢想的中型项目稳稳落地。我现在每次让AI动手前都会先问自己这行代码进来接下来三个月谁来维护想清楚这个问题AI Coding才真正长成了AI Engineering。最后再分享一个小技巧给你的AI配一个“入职培训”文档里面写清楚项目结构、编码规范、常见陷阱这个文档的价值比任何模型都值钱。 AI写代码能信吗？16万行代码背后的AI Engineering实践
16万行代码不是一次性“敲”出来的是“跑”出来的。这里的跑有两种含义一是项目不断迭代、持续演进代码总量像雪球一样滚起来二是AI Coding工具在背后不停生成、修改、再生成把写代码这件事变成了流水线作业。很多人问我AI写代码到底靠不靠谱16万行里有多少是AI写的真正把AI Coding用到一个中型项目里你才会发现它根本不是“打字机”而是需要一套叫AI Engineering的方法论去约束、审查、修复和沉淀。下面我把自己踩过的坑和跑通的方法拆开讲清楚适合正在用或准备用AI辅助开发的技术团队也适合想理解AI Coding边界的前后端工程师。1. 别把AI Coding当成“打字机”16万行代码背后的工程分层16万行代码看起来是一个让人咋舌的数字但真正拉开差距的不是代码行数而是行数背后的管理方式。如果把AI Coding单纯理解为“用AI快速打字”那它只能帮你完成一些零碎片段如果把它放进AI Engineering的框架里它才能支撑起一个可以长期演进的项目。我经历过一个真实项目从零开始到16万行最终能稳定交付依靠的是一套分层思路。1.1 为什么需要16万行代码业务复杂度先于代码规模先说结论16万行不是我们追求的目标是业务复杂度逼出来的。以我参与过的“客户运营中台”为例它包含十几个子系统权限体系、客户档案、标签管理、工单流程、数据分析看板、定时任务、消息通知、导入导出中心。每个子系统还要支持Web端和移动端两套形态。哪怕每个模块都克制到极致只要涉及多种角色、多种工作流、多种报表口径代码量就会自然突破十万行。这不是堆代码而是业务本身需要这么多实现细节。我见过有些团队为了让“AI效益”看起来明显故意让AI生成大量同类代码比如把几十个相似的DTO、工具方法、配置文件批量复制出来。这种代码行数再高也毫无价值反而增加维护负担。所以在动手前必须先分清代码量是“业务投影”还是“技术债”。只有前者才值得我们用AI去加速后者只会让AI成为垃圾制造器。1.2 AI Coding与AI Engineering的分工AI Coding和AI Engineering不是同一个东西这一点如果不讲清楚很容易迷失。AI Coding解决的是“能不能把一段程序写出来”AI Engineering解决的是“这段程序能不能安全地存在于一个系统里”。生活类比一下AI Coding像请了个能说会道的写手几分钟就能出一篇稿子AI Engineering是编辑部流程要管选题、审稿、排版、校对最后保证稿子印出来不出事故。没有编辑部写手再快也只是在制造文字垃圾。维度AI CodingAI Engineering关注点生成一段可用代码让代码在系统中长期存活产出物函数、类、组件架构、规范、测试、可维护性常见失败代码能跑但没人敢改体系太僵化没人愿意用时间尺度秒级月级、年级核心动作生成、修复、补全约束、评审、演化AI Coding擅长从零到一AI Engineering擅长从一到一百。很多人用AI写码翻车不是因为AI不行而是只用了AI Coding没上AI Engineering。比如让AI生成批量函数却完全没有贴项目规范结果造出一堆不符合团队风格的代码后面接手的同事直接骂娘。这种“生成一时爽维护火葬场”的体验几乎每个用过AI写代码的人都遇到过。1.3 一个核心判断代码里“能生成”和“能演化”是两码事“能生成”是指AI形成代码文本听起来很轻松但代码进入仓库后需要经受依赖升级、需求变更、故障修复。AI生成的代码如果没有配套“演化能力”过两周就会变成技术债。我越来越倾向用三个条件判断AI生成的代码是否合格一是否符合团队现有命名和分层习惯二是否被至少一个测试用例保护三在诊断插件下是否没有高频警告。三条同时满足才算“能演化”的代码。如果只是“能生成”今天AI生成一百行明天就可能成为别人修改时想删又不敢删的障碍物。16万行代码之所以能“跑”起来正是因为每一批AI产出都要过这三关。凡是通不过的一律退回重写绝不让它流入主干。这是AI Engineering里最朴素、也最有效的规则。2. 让AI代码“不乱”AI Coding代码生成规范怎么定如果AI Coding是野马规范就是缰绳。没有规范100个人用AI会产出100种风格的代码项目会迅速变成一座无法进入的丛林。我们团队很早就意识到这件事所以把AI Coding的规范写成了团队内部文档并且持续更新。下面这套规则不是想象出来的是经历了大量返工后总结出来的。2.1 团队级的AI生成代码规范可直接抄作业我们团队定了六条铁律每一条背后都有实际教训。AI只能生成“函数级/组件级”代码禁止让AI生成跨模块的大文件。函数级出错影响面小定位快大文件出错你连问题源头都找不到。生成的代码必须包含标识注释例如在文件头加# AI-GENERATED方便后续统计和溯源。生成结果必须通过本地编译、Lint、单元测试后才能进入MR。AI写的代码充其量是“提案”不是“定稿”。涉及权限、支付、数据删除的高风险模块AI只能生成草案最终代码必须由人重写。这条我们称之为“红线模块”。提示词中必须携带项目本地规范片段包括命名、分层、异常处理方式禁止只丢一句“帮我写个接口”。AI不允许“默认依赖”所有第三方库必须先确认版本再让AI生成。否则它可能凭空引用一个不存在的API编译直接挂。这六条写清楚后AI生成的代码质量稳定了很多。尤其是第一条很多团队没有限制AI生成文件大小最后得到几千行的“怪物文件”别说AI人类自己看了都想删库跑路。2.2 别让你跟AI的“对话”变成一笔糊涂账AI Coding写代码本质上是“上下文工程”你给的上下文越具体产出越好。不要只说“帮我写个接口”要说清楚数据模型、已有字段、路由风格、返回结构。我常用一个任务卡格式把需求结构化地丢给AI字段说明目标要做什么输入输出是什么上下文相关文件路径、现有接口、数据表结构约束命名、分层、异常处理、禁用技术验收测试命令、诊断插件要求把这个格式贴在提示词开头AI的产出质量会有明显提升。另外AI Coding最怕“文字背景丢失”对话拉长后AI会忘记前面约定甚至自相矛盾。所以生成一个函数就开一个新对话旧对话只用来修Bug。这是我的实操习惯刚开始时我没注意经常在一个对话里又生成又修改越到后面AI越“糊涂”改A坏B。2.3 代码诊断插件和AI是“最佳拍档”热词里“代码诊断插件”出现频率很高说明很多人已经意识到AI生成代码之后需要一道自动检查防线。我们在IDE里长期开着SonarLint、ESLint、pylintAI生成完代码之后第一件事不是看逻辑而是看诊断面板的红色警告数。红色警告超过三个直接丢回去重写这个策略省掉了大量Review时间。诊断插件能自动发现未使用变量、重复代码、超长函数、深层嵌套这些恰好都是AI最常见的风格病。后来我们更进一步把诊断规则文件直接喂给AI让它按照规则生成效果比生成后再修更好。比如前端项目把ESLint的no-console、max-lines-per-function等规则贴进提示词AI生成的代码一次通过率立刻提高。2.4 顺着“AI Coding笔试”聊聊怎么判断一个人会不会用AI现在招聘里“AI Coding笔试”越来越热但很多公司还在用传统算法题这其实没有区分度。我面试时不会让候选人手写快速排序而是给一段模糊需求让他用AI辅助产出。重点看三个点一会不会把需求拆成AI可执行的任务二给AI的提示词是否包含约束三产出后是否主动跑测试和诊断插件。这三步能区分“只会复制粘贴”和“具备AI Engineering意识”的人。只会复制粘贴的人通常直接把任务丢给AI然后AI说什么他信什么有工程意识的人会先在脑海中拆解需求再补上项目的约束条件最后把AI的输出当“候选方案”来验证。如果你自己也想把AI Coding作为加分项建议刻意练习“拆需求、提约束、验结果”这三个动作这是AI Engineering的基本功。3. 16万行代码实操全过程从一个空仓库到交付很多人好奇16万行代码到底是怎么一点一点“跑”出来的接下来我按实操顺序拆解分为四个阶段。整个过程最关键的不是“让AI写得多”而是“怎么控制AI写的每一段代码都落在系统的正确位置上”。3.1 阶段一把需求“翻译”成AI能理解的任务我们从业务侧拿到需求不是直接写代码而是先做模块拆分。比如“客户运营中台”拆分出30个模块每个模块再拆成若干任务卡最终产出几百张任务卡。每张任务卡就是一个AI Coding单元。关键原则是一张卡片只解决一件事卡片之间尽量无状态、无隐式依赖。这样才能让AI在短上下文内完成高质量输出。演示一张任务卡实例模块订单查询需求根据用户ID查询近30天订单汇总输入user_id: int输出List[OrderSummary]含total_amount, order_count约束使用SQLAlchemy Core不使用ORM遵守项目异常规范验收pytest test_order_query.py 通过pylint score 8把任务卡喂给AI它就能直接输出可用的片段。整个过程像“把大象放进冰箱”先拆解再翻译最后执行。没有这一步AI很容易生成出看似完整、实则不知道为谁服务的代码。这大概就是我们常说的“AI Coding好不好用关键在提问者”。3.2 阶段二让AI生成代码的实操流程附示例实操步骤基本固定初始化项目骨架。我们用FastAPI模板先人工搭好目录结构固定Python版本和依赖版本。让AI生成核心实体/模型。把表结构DDL喂给AI让它生成SQLAlchemy模型。让AI生成Repository层。约定方法命名例如find_by_user_id_and_date_range。让AI生成API路由。约束返回JSON结构。人工合并代码跑一遍pytest。这里举一个实际生成示例。假设要做一个订单汇总接口提示词可以这样写项目customer-ops 技术栈Python 3.11, FastAPI, SQLAlchemy 2.0, PostgreSQL 数据表 orders: id BIGINT PK user_id BIGINT status VARCHAR(20) amount NUMERIC(10,2) created_at TIMESTAMP 请编写用户订单汇总服务函数 get_order_summary(session: AsyncSession, user_id: int) - dict。 要求 - 统计用户近30天内有效订单statuspaid的总金额和订单数 - 使用SQLAlchemy 2.0 style select禁止使用ORM对象 - 返回 {total_amount: 123.45, order_count: 2} - 若用户不存在返回空结果但不要抛异常 - 用logging记录查询耗时 - 在文件头部加 # AI-GENERATEDAI生成的代码可能类似# AI-GENERATED import logging from datetime import datetime, timedelta from sqlalchemy import Select, func, select from sqlalchemy.ext.asyncio import AsyncSession from app.db import models logger logging.getLogger(__name__) async def get_order_summary(session: AsyncSession, user_id: int) - dict: Return order summary for the last 30 days. since datetime.now() - timedelta(days30) stmt: Select ( select( func.coalesce(func.sum(models.Order.amount), 0).label(total_amount), func.count(models.Order.id).label(order_count), ) .where( models.Order.user_id user_id, models.Order.status paid, models.Order.created_at since, ) ) result (await session.execute(stmt)).one() return { total_amount: {:.2f}.format(result.total_amount), order_count: result.order_count, }这段代码看起来能跑但离交付还有距离。它没处理result为空的极端情况也没考虑 Decimal 格式化的精度问题。这些细节依靠AI自己发现很难必须靠人来看。所谓“AI生成80分人工补20分”那20分往往才是决定系统稳定的关键。如果pytest失败我会把报错信息直接复制粘贴给AI让它修复。注意修改时最好新开一个对话把原始代码和报错一起贴进去不要用原来的长对话否则历史信息会让它越改越乱。3.3 阶段三用诊断插件和自动化测试把16万行代码“焊死”代码积攒多了必须上工程化门禁。我们在CI里固定跑以下检查Flake8和ESLint负责Lintmypy和TypeScript strict负责类型检查pytest和vitest负责单测SonarQube负责代码诊断重点看重复率和复杂度最后用bandit和npm audit做安全扫描。所有检查通过之后才允许合并到主干。门禁的价值在于它不信任任何单次生成的代码而是用统一标准去卡所有人。我们统计过最初AI生成代码的一次通过率只有三成上了门禁和规范之后慢慢到了七成。所谓“16万行代码跑出来”其实是被门禁逼着迭代出来的。AI每生成一版就扔到这些检查里跑一遍不过就回去修直到通过为止。这个过程很枯燥但恰恰是它保证了代码库不失控。3.4 阶段四从“生成”到“演进”——AI Coding真实维护姿势代码上线只是开始绝大部分工程工作在后续三个月需求变化、接口调整、依赖升级。AI Coding在维护阶段的正确用法是“小步修改”。比如新增一个字段不要重新生成整个文件而是把现有文件内容、新增需求、测试结果贴给AI让它只改对应函数。我踩过一个大坑有次让AI“重写整个模块”结果它把别处的逻辑悄悄改坏了测试跑了两轮才发现。后来我养成一个习惯每次给AI的修改范围必须限定在单个函数或组件并且用diff review逐行查看。这也是从AI Coding升级到AI Engineering的分水岭你会开始管理“修改的边界”。一个不会控制修改边界的团队用AI重构主干代码往往就是灾难的开始。4. AI Coding会不会拉低代码质量实测下来关键在于“门禁”“AI Coding的到来会不会让代码质量下降”这是很多团队关心的问题。我的答案很直接如果你不上工程化门禁AI Coding绝对会让代码质量断崖式下跌如果你像我们一样把规范、测试、诊断插件全部接进去AI Coding反而能帮你把中型项目稳稳落地。问题从来不在工具而在使用工具时是否设置了防错机制。4.1 质量问题从哪来先泼盆冷水AI生成代码的坏味道很集中大量重复代码、上下文不落地的伪抽象、隐藏的冗余查询、对第三方API的幻觉使用。比如有一次AI生成文件上传代码引用了一个并不存在的SDK方法本地编译直接失败。这些问题的根源不是AI笨而是它没有系统全局观只能在token范围内做局部预测。它不知道项目里已经有公共上传组件也不知道某个接口的真实返回结构。所以“生成”和“可靠”之间必须架设门禁。门禁既包括自动化的诊断插件、测试、Lint规则也包括人工的code review。很多团队只做了自动化却没有让有经验的人去review diff结果AI生成的“合理但错误”的代码悄悄潜入主干。这种错误往往要等到生产告警才暴露修复成本成倍上升。4.2 常见问题速查表建议收藏我们在16万行代码的实操过程中遇到的高频问题基本都在这张表里问题现象可能原因排查与处理AI代码报找不到模块依赖未安装或版本错固定requirements版本再重新生成功能看似正确但性能差自动生成了N1查询用慢SQL日志定位提示词里禁止循环内查询界面样式混乱组件库规则没进提示词把组件库规范文件注入提示词同一个功能每轮生成不同上下文不足或对话过长拆小卡片新对话重试诊断插件报警一堆AI未遵循代码规范把lint规则文件贴在提示词里改一个字段引发大量故障AI修改范围失控限定只改单个函数diff review每一条背后都有真实教训。特别是N1查询AI不会主动做批量查询它天然倾向于在循环里一条条查。你在提示词里写一句“禁止在循环内查询数据库”能直接避免大量性能事故。4.3 多智能体AI Agent协作开发的尝试我们试过用多智能体AI Agent协作开发这也是热词里频繁出现的玩法。具体分工是Agent A负责写代码Agent B负责审代码Agent C负责补测试。A根据任务卡生成接口B针对A的输出做静态分析和逻辑审查C再基于A和B的最终结果生成测试用例。这个模式不是概念炒作实测能拦下不少低级错误。但多智能体不是万能药Agent之间互相“脑补”时会创造上下文里的假事实。比如审查Agent可能根据“经验”判断某个API不存在导致误报测试Agent生成的测试用例可能完全不匹配实际业务规则。所以必须保留人类终审。角色分工可以参考Agent角色输入输出编码Agent实现需求任务卡代码片段审查Agent识别坏味道代码片段规范审查意见清单测试Agent编写测试代码片段接口定义pytest测试文件使用多智能体后我认为最有价值的不是“让AI互相把关”而是让每个Agent只专注一个狭窄目标从而减少单模型在长链任务中的遗忘。和人工一样单一职责能显著提高稳定性。4.4 让AI帮你做代码整理和重构的正确姿势热词“代码整理”其实也是一项适合AI的能力。AI不仅能生成代码还能整理代码把大函数拆小、重命名变量、抽取公共组件。做法是先在Git上开分支跑一遍全量测试然后给AI指定待重构的函数要求它“只重构不改变对外行为”。重构完再跑全量测试。我踩过坑AI重构时会“顺手”优化一些逻辑导致行为变化看起来是改进实际上是隐患。比如把if x is not None改成if x遇到空字符串和0时结果就完全变了。所以每次重构后必须检查diff重点关注“不该改的有没有被改”。实操中我会在提示词里明确写一句“不允许修改任何测试文件和接口定义”这句话能挡掉不少自作聪明。5. 落到工程上AI Coding到AI Engineering的沉淀清单16万行代码的项目做完后我们沉淀出一套自己的AI Engineering实践这里分享四个支撑点。这些不是理论而是每个季度都会复盘更新的操作清单。5.1 四个支撑点上下文、门禁、可追溯、演进上下文工程是第一支撑点。AI的产出质量高度依赖输入上下文我们把项目结构、代码规范、现有调用方式打包成文档每次生成前从中摘取相关片段。门禁是第二支撑点严格做到静态检查、单测、人工评审三件套。AI输出只是提案门禁才是裁决。做到了这两点代码质量的下限就锁住了。可追溯是第三支撑点。所有AI生成的代码都要打# AI-GENERATED标签我们用它做统计和追责。哪些模块AI写得好哪些模块AI总出问题一段时间后一目了然。这个数据反过来指导我们调整提示词规范。演进是第四支撑点。AI工程化的落脚点不是“今天生成得多好”而是“半年后还改得动”。我们会定期用AI做小步重构保持模块拆分合理防止代码腐化。5.2 现在团队的一天从把“红色警告”丢给AI开始我们的日常开发流程已经和AI深度绑定。早上到岗先同步代码本地跑诊断插件把红色警告的文件列表导出来AI负责批量修复低风险问题然后人工review。高风险的逻辑改动还是人先写草案AI做代码补全和测试生成。这种工作方式下16万行代码不是一堆静态文件而是每天都在变化的活系统。有人问AI会不会取代程序员我的看法是AI Coding取代的是“打字时间”不是“思考时间”。思考时间仍然是工程核心。团队里的资深工程师现在把更多精力放在架构决策、边界控制、疑难Bug排查上而不是纠结某个函数怎么写。这也解释了为什么AI Coding会导致“初级重复劳动减少综合判断能力增值”。5.3 给团队和个人的几条实在建议如果你正准备把AI Coding引入项目有几点建议可以直接拿走。先拿一个中小型模块试跑AI Coding不要一上来就把核心系统交给AI。把“AI生成代码”和“AI辅助修改”两条路线分开练后者更难更需要工程基础。代码行数不是KPI有效代码才是。AI生成1000行没人维护的代码不如100行经过评审的代码。规范文档要及时更新因为AI会根据你给的规范“有样学样”规范烂代码就烂。多观察诊断插件的同类告警把高频告警变成提示词约束能明显减少AI返工。这些建议不是我拍脑袋想出来的每一条都对应踩过的坑。比如不把诊断告警变成提示词约束时AI每轮都会重复同样的错误直到你把规则写进提示词。带完这个16万行的项目我最深的感受是AI Coding让“写代码”变得便宜但让“决定代码怎么活”变得昂贵。那些只看重生成速度、不看工程约束的团队很快会被自己制造的混乱反噬。反过来如果你愿意在规范和门禁上花时间AI能帮你把过去不敢想的中型项目稳稳落地。我现在每次让AI动手前都会先问自己这行代码进来接下来三个月谁来维护想清楚这个问题AI Coding才真正长成了AI Engineering。最后再分享一个小技巧给你的AI配一个“入职培训”文档里面写清楚项目结构、编码规范、常见陷阱这个文档的价值比任何模型都值钱。