最近总有朋友问我你真的在项目里用 AI 写代码吗还是只拿它生成一点玩具代码发朋友圈我的回答是真在用而且已经用进日常的生产项目了。但我要先把丑话说在前面——我身边翻车最多的用法就是把需求往聊天窗口一丢等它吐出一段看起来完整的代码然后原样粘进仓库。用这种方式做 AI 编程基本都会经历“第一版惊艳、第二版勉强、第三版想骂人”的过程。真正能让 AI 在真实编程里稳定发挥的不是某个神奇提示词而是三件配套的事把任务拆到足够小、把项目上下文喂到位、把代码验收的闸门攥在自己手里。这篇文章就沿着这三条线把我正在用的整套做法摊开讲。1. AI 编程第一步不是写提示词而是拆任务1.1 为什么一句话需求必然翻车先说一个底层逻辑大语言模型本质上是一个概率预测器它在给定上下文之后生成的是“最像样的默认答案”。你给的需求越模糊它可发挥的自由度就越大最后交出来的往往是通用但平庸的实现。举个例子你说“帮我写个用户登录接口”模型大概率会给你一个username password token的标准骨架。这个骨架单看没问题可一旦放进真实系统接踵而来的全是你没交代的细节密码要不要做复杂度校验账号连续输错几次要锁定允许多端同时在线吗token 过期了是静默刷新还是强制重登重复提交怎么防用户状态禁用怎么处理这些细节你没有写进去它自然不会主动帮你做。等上线测试的时候问题一个个爆出来你只会得出一个结论AI 生成的代码不敢用。其实不是 AI 不行是你给它的任务边界太宽了。1.2 “登录功能”我是怎么拆的那正确做法是什么我的习惯是接到需求之后先不急着让 AI 干活而是把整个功能拆成一堆可以独立验证的子任务。以登录功能为例用户看到的只是一个表单和一次点击但我会在脑子里先把后端要面对的所有约束过一遍接口层URL 路径、HTTP 方法、请求参数结构、成功和失败的响应格式。入参校验用户名格式、密码长度和复杂度、参数缺失对应的返回码。账号规则账号是否锁定、是否首次登录需要改密、是否允许多端在线。会话层token 有效期、刷新策略、退出后的清理逻辑、鉴权中间件。安全异常连续输错密码的锁定策略、是否需要验证码、登录接口是否要限流。数据层用户表核心字段、密码哈希算法、会话存储位置、用户状态字段。这个清单一旦列出来再让 AI 去写“登录”就不是撞大运了。我通常会按模块逐个推进每个模块的提示词里都明确给出输入输出。例如让 AI 写登录接口时我会这样说入参只有用户名和密码成功时返回 token 和过期时间失败时返回统一的错误体{ code, message }密码用 bcrypt 校验日志里不允许打印密码项目基于 FastAPI认证工具类已经放在app/utils/auth.py。当提示词里塞满了这类具体约束AI 输出的代码就从“随便写个能跑的”变成了“按我的项目规则写出来”。我不需要什么咒语只需要把原来留白的地方填清楚。1.3 拆完的下一步把验收标准一并交给 AI拆完子任务后我还习惯顺手写一版验收标准。这个东西看着不起眼实际上对稳定性的提升最明显。同样拿登录接口来说我会在提示词后面补一段正常路径用户名密码正确返回 200 和 token。异常路径密码错误返回 401错误码是AUTH_FAILED。边界情况参数缺失返回 422账号被锁定返回 423。安全要求日志不打印密码每个 token 可以被单独吊销。把这些验收标准交给 AI它输出的代码风格会立刻不一样因为它自己也能拿这些标准来检查产出。更进一步验收标准还是后面写测试、做 code review 的统一参照物。拆任务不是表面的仪式感它的本质是把模型预测的不确定性一点一点消除掉。2. 决定代码质量的恰恰是你喂给 AI 的上下文2.1 直接丢整个代码库给 AI为什么不灵很多开发者拿到 AI 编程工具后的第一个想法是AI 不是能处理很长的上下文吗我把整个仓库丢给它它不就什么都懂了这个想法听上去合理但在实际工程里会撞上两个问题。第一上下文越长注意力越容易被稀释。仓库里有大量配置文件、历史遗留代码、第三方依赖样板这些噪声会把真正的需求淹没掉。模型不是人类它不会自动分清哪些是核心、哪些是无关紧要的。第二你的改动往往只涉及仓库的小小一块它如果真把整个项目看了一遍反而可能被角落里的旧写法带偏给你生成一份“一半新规范、一半老毛病”的非主流代码。我试过几次直接粘贴整个仓库的路径让模型自动去读结果生成的东西要么不敢合并要么改起来比重写还痛苦。所以在我的工作流里喂给 AI 的不是“整个仓库”而是精心整理的“精简上下文包”。2.2 我常维护的一份“精简上下文包”我现在每个项目里都维护着一个私有文档通常会命名为context.md。这个文件长期跟着项目更新每次开新对话我都会把相关部分作为背景信息贴给 AI。里面主要包括四块内容。第一块是技术栈和版本号例如 Python 3.11、FastAPI、SQLAlchemy 2、PostgreSQL 14。不同版本之间差异很大AI 如果只知道框架名很容易用旧写法生成一段无法运行的代码。第二块是目录结构不是把一个几百行的tree全扔过去而是只写到模块层级并标注每一层大致负责什么。第三块是编码约束这是我最看重的一层比如时间统一存 UTC金额统一用 Decimal不准在服务层用 float新接口的错误必须走统一错误码controller 里不拼业务逻辑数据库查询必须走 repository 层。第四块才是本次任务相关的接口签名只贴当前改动涉及的数据结构和函数定义。这个文件不是一次性说明书而是和源码一起维护的。项目结构变了、规范改了我都会顺手更新它。有了它AI 就像拿到了一份入职手册不会总说外行话。2.3 开写之前先让 AI 复述一遍需求喂完上下文我还有一个看起来有点“笨”的步骤让 AI 先用一百字以内复述它对需求的理解让它列三个需要我确认的点等确认完再开始写代码。这个操作会让很多人觉得耽误时间。但我可以很肯定地说它省下的时间比花掉的多得多。因为大部分回滚和返工都来自同一个原因你觉得自己描述得很清楚了模型理解的却是另一个样子。如果它能用自己的话把需求说一遍你就能立刻发现理解偏差在哪里甚至发现自己的原始需求描述还有含糊之处。我常碰到的情形是AI 复述出来的重点和我心里想的不一样。这个时候我就知道要么是我拆任务拆得还不够细要么是边界条件没有交代清楚。趁它还没写代码我把信息补全等于把 bug 的发现时间提前到了编码开始之前。这一步看着小却是我整个工作流里性价比最高的动作。3. 过去两年沉淀下来真正好用的三套提示模板3.1 功能开发模板一次只生成一个可验收的单元很多人把提示词工程讲得很玄什么角色扮演、思维链、few-shot 一套一套的。落到真实编程里我自己用的其实只有三个模板而且都可以套进固定的结构。第一个是功能开发模板。它的框架是“背景 任务 输入 约束 输出 验收样例”。我拿一个具体场景举个例子比如让 AI 写一个解析日期范围参数的函数背景项目技术栈是 Python 3.11 FastAPI参数使用 Pydantic v2 校验。 任务实现一个解析日期范围参数的函数。 输入start_date 和 end_date格式 YYYY-MM-DD可能来自用户输入。 约束不引入新的第三方库参数非法时抛出 ValueError类型注解必须完整。 输出只输出函数本身不要输出测试代码。 验收样例 - 输入 2025-01-01 和 2025-01-31应返回两个 datetime 对象 - 输入 end_date 小于 start_date应抛出 ValueError - 输入非法日期字符串应抛出 ValueError。这个模板的本质是把 AI 的输出空间从一个庞大的系统缩小到一个能一眼看穿的小函数。我给它的边界越明确它就越不容易自由发挥。这里要提醒一句模板也不是越长越好。提示词如果堆砌太多无关细节模型反而会在不重要的条款上过度用力把真正核心的任务冲淡。3.2 测试用例模板先交用例清单再补测试代码第二个模板是拿来生成测试的。我会把目标函数的定义和上下文贴给 AI然后提出这样的要求先别写测试代码先把测试用例清单列出来按照基础功能、边界异常、外部依赖异常三类分开。每一行都要写清楚输入、预期输出或者预期异常以及这个用例到底在验证什么规则。等我确认清单没问题再让它用 Pytest 补全实现。这个动作有两个好处。第一测试用例清单本身就是一份可读的验收文档谁拿过来都能看明白功能覆盖到哪一层。第二我可以根据自己的业务经验往里补充 AI 想不到的边界。比如某个接口在时区切换时会不会出错金额计算会不会出现精度问题并发请求下会不会有锁冲突。这些经验不可能靠模型自己生成但可以通过先列清单的方式让人有机会在写代码之前就把坑补上。顺序一旦反过来让 AI 直接生成几百行测试代码这些缺口反而会被淹没在大量断言里。3.3 代码审查模板让 AI 用风险清单说话第三个模板是代码审查。我经常看到有人拿 AI 做 review最后得到一堆命名建议和格式建议跟真正关心的东西完全不搭边。所以我给的审查提示一般是这样的请忽略代码风格和命名把注意力放在功能正确性、资源泄漏、并发安全、异常路径、安全性、事务一致性这六个方面。逐条输出发现的问题标注风险等级高风险问题给出具体行号和可执行的修改建议。如果确实没有高风险问题直接说没有不要凑数。用了这个模板以后AI 输出的审查质量会立刻不一样它不再像一个批改作业的老师而是像一个把“这段代码在什么场景下会炸”摆到你面前的同事。我在实际使用中还会加一条要求针对高风险的修改建议先不要直接改代码把问题报给我由我决定怎么处理。因为高风险往往意味着设计层面的取舍AI 直接修改很可能修了东墙漏了西墙。4. 实战复盘一个报表导出与合并工具是怎么和 AI 配合落地的4.1 需求背景和为什么选这个项目当试验田我一直觉得讲 AI 编程不能只讲方法不如拿一个真实项目完整复盘一遍。我选了一个报表导出与合并工具它是这样产生的数据团队每天都要从报表系统导出一批 CSV按日期合并后交给业务方做后续统计。人肉操作的问题很明显耗时、容易漏、来回重复。这个项目的目标是用 Python 写一个命令行工具自动拉取某个时间段的报表文件统一字段后合并生成汇总结果支持断点重试。我挑它当试验田是因为流程边界清楚失败后果可控非常适合拿来验证 AI 协作的工作流也能顺便看清模型在哪些环节会翻车。4.2 第一轮先不写代码让 AI 梳数据结构我开这个项目之后第一句话不是“给我写个下载脚本”而是“先不要写代码帮我梳理这个工具的数据流和模块边界”。AI 很快给出一个模块划分网络请求层、任务调度层、文件解析层、合并层、归档与日志层。方案大体符合我的预期于是我在这个基础上补充了项目里实际会出现的几个变数报表系统偶尔会超时CSV 来自不同编码环境不同报表的字段顺序并不完全一致。我请它把异常处理路径补进模块设计里。这一步的产出不是任何可运行代码而是一份大家都认可的讨论框架。我发现很多人急着想要代码会跳过这个环节但后面往往因此反复返工。先花一个来回把数据流和模块边界对齐后面每一轮生成都有了一个清晰的坐标。4.3 第二轮生成核心模块逐个人工审查框架对齐后我让 AI 生成下载模块相关的函数。提示词里带了接口签名还特别要求它“只输出receive_report函数不要改动其它文件”。AI 给出的初始版本功能上是通的但我在审查时发现两个问题。第一个问题是它默认把整个 CSV 文件全部载入内存面对上万行的报表时内存占用会明显偏高。我让它改成流式逐行读取文件多大都不怕。第二个问题是它把重试逻辑直接写进了下载函数里把“请求超时”和“文件校验失败”混成了一条处理路径后期会非常难维护。我要求它把重试策略拆成独立模块。这个过程很像在带一个写代码很快的实习生初稿可以很快但审查必须由我来做发现不对的地方打回去让它改。而且我每次都明确要求它只输出修改后的那个函数这样我能逐段 merge不至于被大文件里夹带的改动砸晕。4.4 联调翻车CSV 编码与逗号问题的一次排查链路这个项目最值得分享的其实是后面这段联调“翻车”经历。脚本跑起来以后第一天的数据能正常合并第二天的数据里出现了一行中文乱码。我按下面的顺序做排查。第一步把原始文件和程序输出各抓几行做二进制比较很快发现程序读取时没有做编码探测默认按 UTF-8 解析但线上部分 CSV 其实是 GBK 编码。第二步我没有直接让 AI 改代码而是把出错的原始文件样本和报错行贴给它先问它从已知信息判断可能是什么原因并让它列出排查步骤。这一步的本质是拿 AI 做知识检索和可能原因组合分析而不是盲改。第三步锁定原因后我再让它加入编码探测逻辑同时用csv.reader处理带引号字段里的特殊字符。第四步我在验收标准里加了一条回归用例要求以后必须能正确处理含中文字段和半角逗号的 CSV。这个问题的核心在于AI 没有见过真实数据分布的时候会天然假设世界是干净的。真实生产里编码不一致、字段里有逗号、有空行、有前后空格这些脏数据才是杀手。人工经验和现场数据是模型无法自动越过的一道坎。4.5 沉淀下来的协作节奏这个项目跑通后我总结出一条固定协作流水线拆任务给上下文生成单个函数人工审查补测试小步合并。不管任务大小我都按这个顺序走。有人可能会嫌慢但实际体验是它比纯手写快的地方不在敲键盘而在于 AI 能把重复性的查询方案、异常处理、模板写法一次性铺好省下来的是大量查资料和搭框架的时间。人负责判断方向和质量AI 负责把方向变成初稿。这套协作方式经过这个项目的验证之后我基本沿用到了后续所有涉及 AI 的开发任务里。5. AI 代码要上线先过我这三道验收线5.1 我的三道防线人工审查、自动化检查、小步提交我给自己定过一条规矩AI 生成的代码如果不经过三道防线不允许合入主分支。第一道是人工审查。每次拿到 AI 输出我不会立刻合并而是先找几个重点业务规则对不对有没有不合理的资源占用有没有可能导致数据丢失的路径。我基本不看命名风格这类表层问题那些交给机器就好。第二道是自动化检查包括类型检查、lint、单元测试以及 CI 里的回归验证。AI 工具现在能生成大量基础测试但自动化检查必须真正跑过跑不通就一律不算完成。第三道是保持小的提交。一次改动只涉及一个模块如果 AI 给出的改动范围过大我宁可退回重拆也不会让它一次“重构半个项目”。小步提交回滚成本低出了问题也更容易定位。这三道防线听起来都很朴素但正是它们决定了 AI 代码到底是“能用”还是“不敢用”。5.2 让 AI 先写测试用例而不是直接写测试代码的好处在第三部分我讲过测试用例模板放到真实落地里它还有一个隐藏价值让 AI 在写实现代码之前先和我把验收标准对齐。因为测试用例清单是唯一能把“我理解的”和“它理解的”之间差异摊开看的硬文本。有一次我让 AI 做一个订单状态流转函数它的第一版测试用例里几乎没考虑到“金额只能减少不能为负”这类业务规则。如果一上来就让它直接写测试代码这些缺口会被埋在几百行断言里我未必能一眼看出来。但它先列清单的时候缺口就摆在桌面上非常扎眼。我先补上了几条真正重要的业务边界再让它按新清单去补测试代码。顺序这一调整质量差得不是一星半点。5.3 合并姿势规定 AI 只输出改动部分最后讲一个不高大上但极其实用的技巧。每次让模型改代码的时候我都会在提示词末尾加一句只输出修改后的函数不要输出整个文件不要改动无关代码。原因是模型生成大文件的时候很容易顺手改掉你没让它碰的地方。可能它把某个变量名重命名了也可能把另一个函数重新格式化了一遍这些改动混在 diff 里会非常干扰 review。限定输出范围后git diff变得干净清晰我能很快判断这次改动的影响面发现异常也能直接在一两行里找到问题。这个约束不是万能的模型不可能百分之百遵守但它已经能把乱改的概率压低很多。6. 哪些代码我敢直接交给 AI数据、依赖、业务规则的三条边界6.1 敏感数据脱敏优先必要时候用本地部署模型真实项目里最容易被忽视的是数据安全边界。我现在的习惯是任何可能包含用户敏感信息的代码都不会把真实字段名和真实数据直接交给云端 AI。比如处理用户中心相关需求时我会把手机号、身份证号、企业名称这类字段替换成xxx_phone、xxx_user_id这种占位符。字段类型和数据长度保持一致但语义被抽象掉了。这样做确实会让提示词损失一点语义丰富度但换来的是敏感结构不外流。如果项目所处环境对外部服务有严格隔离要求我会选择本地部署开源的中小参数模型来离线处理这类问题代价是生成效果弱一些但在这个安全边界面前效果让路是值得的。6.2 依赖推荐不是照单全收先做技术选型审计AI 非常喜欢在代码末尾顺手推荐一个第三方库。要么是pip install xxx要么是npm install yyy这其实是 AI 编程里的一个隐藏雷点。那些比较冷门的库可能已经很久没人维护有些库的依赖链层层嵌套一次性能带进来几十个间接包安全隐患成倍放大。所以我给自己定了一个流程AI 给完依赖方案之后人必须再做一次核验。核验三件事仓库的活跃度是否正常最近有没有版本更新许可证是否适合商用场景会不会把项目拖进合规风险近期有没有已知的安全问题或者兼容性硬伤。这三项确认没问题之后项目才会把新依赖写进配置文件并安装。不要因为方案来自 AI 就跳过这一步供应链风险不会因为推荐人是模型就自动降低。6.3 业务规则和钱有关的逻辑人类必须把关AI 能写出标准化的代码但业务规则不是标准化的。最典型的是金额计算模型生成的常规版本很可能直接用 float 相加这在报表、收银这类场景里就会踩精度坑。1.1 加 2.2 在浮点数里并不是 3.3。如果只是展示还好一旦进入计费或者对账逻辑这就算事故了。这种业务规则必须由懂业务的人写进约束里比如金额统一用“分”存整型或者使用 Decimal 并明确规定舍入方式。另一个高频例子是时区数据库统一存时间戳展示层再按用户时区转换。这些规则 AI 不知道你不说它就按默认世界的规律去写而默认往往是错的。所以我的原则是凡是有硬性业务约束的地方判断权不交给模型。AI 适合回答“用什么技术方案实现”但“这个规则这样定到底对不对”必须由人来拍板。在提示词里把业务规则显式写出来AI 才能真正按你的预期工作而不是按平均预期工作。7. 从问答式写码到 AI 智能体我还在适应的新阶段7.1 适合交给智能体的任务和不适合的任务最近 AI 智能体这个概念很火很多人问我要不要干脆把任务直接交给 Agent 去自动执行。我的结论是应用场景需要分开看。上表是我根据自己的实际体验总结出来的判断标准适合交给智能体不适合交给智能体批量修复 lint 警告重构公共模块自动补充测试用例修改数据库结构生成 API 文档调整核心交易逻辑批量重命名变量跨系统协调的功能开发低风险、可自动验证高风险、目标模糊适合的任务有一个共同点每个动作是否完成都有明确标准失败成本低可以在小范围内重试。不适合的任务则相反一旦出错定位和回滚成本都很高。我现在不会让一个多步智能体直接去动核心代码库。智能体解决的是“确定性环境里跑可验证指令链”的问题而真实开发大多数时候是模糊判断这个边界比很多人以为的要硬。7.2 我现在一天的真实工作流长什么样也有不少朋友好奇把 AI 用进工作流之后我一天到底怎么干活。实际状态大概是这样的。写代码之前我会先做需求拆解和方案设计确定这次改动要碰哪些模块哪些地方必须保持稳定。写的过程中IDE 里的 AI 补全负责把重复片段填掉遇到不熟的技术栈我会另外开一个独立对话把精炼后的上下文贴进去用功能开发模板生成底稿。写完一轮之后我会用代码审查模板对核心代码跑一遍风险扫描然后针对中高风险的结论逐个人工核验。再往后测试用例清单和自动化 CI 负责做回归验证通过了才允许提交。整个链路下来人没有变成一个只按回车的人反而是决策点变得更集中了。7.3 一点个人体会AI 时代更值钱的能力没有变坦白讲刚开始大规模用 AI 写代码的那段时间我也会有一种“AI 这么强我还要不要学底层原理”的错觉。但踩过足够多的坑之后我反而更确定一件事越是依赖 AI需求拆解、代码审查、业务规则判断这些能力就越值钱。模型输出的质量上限本质上就是你喂给它的信息质量上限。你能把任务拆得多清楚它就能把代码写得多准。那些看起来被 AI“干掉的岗位”真正被干掉的只是重复劳动的环节而不是掌握方向的判断力。我现在的状态是把 AI 当成团队里一个效率极高、有点幻觉倾向的实习生我会给它清晰的上下文、明确的验收标准、充分的测试保护但最后的掌舵人是我。这也是我目前认为最稳妥、最能真正落地的一套 AI 编程协作形态。