1. 为什么我不再把 AI 当“代码生成器”而是当“结对搭档”我平时写代码AI 已经深度嵌进了日常工作流。不是那种“帮我写个贪吃蛇”的玩具用法而是真正在业务代码、线上排查、重构评审这些场景里当主力辅助。踩过的坑不少也总结出了一套相对稳定的用法。这篇文章就把我日常最常用的 5 个场景拆开讲每个场景配可直接复制的 Prompt顺便把背后的思路和注意事项说清楚。先说一个核心认知AI 写代码的质量八成取决于你怎么问两成取决于模型本身。很多人抱怨“AI 写的代码不能用”大概率是 Prompt 太模糊。比如“帮我写个登录接口”AI 只能给你一个最通用的模板跟你的项目结构、鉴权方式、错误码规范完全不搭。但如果你把上下文、约束、输出格式都交代清楚它能给出的东西直接就能进代码库。这篇文章适合几类人刚接触 AI 编程辅助想系统了解的、已经在用但觉得效果不稳定的、以及想把这套方法带到团队里做规范的。下面每个场景我都会给出完整的 Prompt 模板你可以直接复制改参数就用。2. 场景一从零写一个新模块——把需求拆到 AI 能“接得住”2.1 为什么直接说“帮我写个 XX”大概率会翻车新手最容易犯的错就是把 AI 当成一个“需求翻译器”扔一句话就等结果。我早期也这样后来发现问题的根源在于AI 没有你项目的上下文。它不知道你用的是哪套框架、数据库字段怎么命名、异常怎么抛、日志怎么打。你给的信息越少它就越倾向于输出“教科书式”的通用代码而这种代码往往跟你的项目格格不入。我的做法是在让 AI 写代码之前先花两分钟把“约束条件”列清楚。这就像你给一个新同事派活你得告诉他项目用什么技术栈、代码规范是什么、这个模块跟哪些已有模块交互。信息给到位产出质量立刻上一个台阶。2.2 我常用的“新模块生成”Prompt 模板下面这个模板是我反复打磨过的适用于后端接口、工具类、数据处理脚本等场景。核心思路是角色 技术栈 功能描述 约束条件 输出格式。你是一名资深后端工程师熟悉 Python 3.11 和 FastAPI 框架。 【任务】 帮我实现一个用户积分查询接口。 【技术栈】 - 框架FastAPI - 数据库PostgreSQL使用 SQLAlchemy 2.0 ORM - 缓存Redis用于热点数据缓存 - 鉴权JWT用户 ID 从 token 中解析 【功能要求】 1. 接口路径GET /api/v1/user/points 2. 入参无用户 ID 从 JWT 中获取 3. 出参{ user_id: int, points: int, level: str, updated_at: str } 4. 积分等级规则0-99 为 bronze100-499 为 silver500 以上为 gold 5. 缓存策略先查 Redis命中则返回未命中查数据库写入 RedisTTL 300 秒 【约束条件】 - 所有数据库操作使用异步 session - 异常统一抛出 HTTPException错误码遵循项目规范 - 日志使用 structlog记录关键路径 - 不要写测试代码只写业务逻辑 【输出格式】 - 先给出完整的路由函数代码 - 再给出对应的 Pydantic 响应模型 - 最后用注释说明每个关键步骤的意图这个模板的关键在于“约束条件”那一段。很多人会忽略它但恰恰是这段决定了代码能不能直接用。比如“异步 session”这一条如果你不说AI 很可能给你同步的写法你还得手动改。2.3 拿到代码后我必做的三件事AI 给出代码只是第一步直接复制粘贴进项目是危险的。我通常会做三件事第一通读一遍逻辑重点看边界条件。AI 经常在“积分等级规则”这种地方写错边界比如 100 到底算 bronze 还是 silver它可能理解反了。第二检查依赖导入AI 有时会引入你项目里根本没装的库。第三跑一遍类型检查Python 项目我会跑 mypyTypeScript 项目跑 tsc能提前发现不少问题。注意AI 生成的代码里异常处理往往是最薄弱的一环。它倾向于用最通用的except Exception这在生产环境是大忌。拿到代码后务必把异常处理改成项目统一的错误码体系。3. 场景二排查线上 Bug——把日志和堆栈喂给 AI 的正确姿势3.1 排查 Bug 时 AI 最怕你只给一句“报错了”线上出问题的时候人容易急直接把一句“接口 500 了帮我看看”扔给 AI。这种问法基本没用因为 AI 没有任何线索。排查类问题的核心是你给的信息越具体AI 的推理链越短定位越准。我一般会准备三样东西完整的错误堆栈、相关的代码片段、以及触发条件什么操作、什么参数、什么时间点。这三样凑齐AI 的排查效率比我翻日志还快。3.2 我的“Bug 排查”Prompt 结构你是一名擅长排查线上问题的资深工程师。 【现象】 调用 /api/v1/order/create 接口时约 5% 的请求返回 500。 错误信息KeyError: user_level 【完整堆栈】 粘贴完整 traceback 【相关代码】 粘贴出错的函数以及上下游调用链大约 50-100 行 【触发条件】 - 只在用户等级为 None 时出现 - 新注册用户首次下单必现 - 老用户复现概率低 【已排查项】 - 数据库 user_level 字段确实存在但部分老数据为 NULL - 代码里没有对 None 做兜底 【请帮我】 1. 定位根因 2. 给出修复方案优先考虑兼容历史数据 3. 指出这类问题在代码里还有哪些潜在位置这个模板里“已排查项”是我后来加上的效果非常好。它能避免 AI 重复你已经做过的工作把精力集中在真正的盲区上。3.3 排查类 Prompt 的三个实战技巧第一个技巧堆栈要完整不要截断。很多人只贴最后几行但真正的根因往往在中间某层调用里。第二个技巧代码片段要给上下文不要只贴出错那一行上下游的调用关系很重要。第三个技巧明确告诉 AI 你要什么是要根因分析、修复方案还是预防建议说清楚它才不会跑偏。我实测下来用这套结构问排查问题AI 给出的根因判断准确率能到七八成剩下两三成需要我自己结合业务判断。但即便它判断错了它列出的排查方向也常常能给我启发。提示涉及敏感数据的日志粘贴给 AI 之前记得脱敏。用户 ID、手机号、订单号这些用占位符替换掉。这不是不信任工具而是基本的职业习惯。4. 场景三代码重构与评审——让 AI 当那个“挑刺的同事”4.1 重构场景下 AI 的真正价值在哪很多人用 AI 重构就是让它“把这段代码优化一下”。但“优化”是个很模糊的词AI 不知道你关心的是性能、可读性还是可维护性。我的经验是重构类任务一定要明确优化目标。比如一段查询代码你可以让 AI 从“减少数据库查询次数”的角度优化也可以从“提升可读性”的角度优化两个方向的产出完全不同。目标越具体产出越有价值。4.2 代码评审 Prompt让 AI 扮演严格的 Reviewer你是一名严格的代码评审员有 10 年 Python 后端经验。 【待评审代码】 粘贴代码建议控制在 200 行以内 【项目背景】 - 这是一个订单状态流转的核心模块 - 日均调用量约 50 万次 - 对性能敏感要求 P99 延迟低于 50ms 【评审重点】 1. 性能问题有没有不必要的循环、重复查询、内存拷贝 2. 并发安全多线程/协程环境下有没有竞态条件 3. 边界处理空值、超长输入、异常路径是否覆盖 4. 可维护性命名、职责划分、注释是否到位 【输出要求】 - 按严重程度分级致命 / 严重 / 建议 - 每条问题给出具体行号和修改建议 - 不要泛泛而谈要指出具体代码位置这个 Prompt 的精髓在“评审重点”和“输出要求”。分级输出能帮你快速抓住关键问题具体行号则让你改起来有的放矢。4.3 重构时我踩过的坑有一次我让 AI 重构一个数据处理函数它把原本 30 行的代码压缩到了 12 行用了各种列表推导和内置函数。看起来很美但可读性直线下降团队里其他人 review 的时候一脸懵。后来我学乖了重构 Prompt 里会加一句“优先保证可读性不要为了简洁牺牲清晰度”。还有一次AI 重构时悄悄改了一个边界条件把改成了导致一个边缘 case 出错。这提醒我AI 重构后的代码diff 一定要逐行看尤其是条件判断和循环边界。5. 场景四写测试用例——AI 最擅长但也最容易偷懒的地方5.1 为什么测试用例特别适合交给 AI写测试是个重复性很高、但又必须覆盖全面的活。AI 在这件事上有天然优势它能快速枚举各种边界条件而且不会像人一样因为“觉得这个 case 不可能发生”而漏掉。我现在的习惯是业务代码自己写测试用例让 AI 先出一版我再补充。但 AI 写测试有个通病它倾向于只写 happy path。正常流程的用例写得很全异常路径、边界值、并发场景经常一笔带过。所以 Prompt 里必须明确要求覆盖这些。5.2 测试用例生成 Prompt 模板你是一名测试工程师擅长用 pytest 编写高质量单元测试。 【被测函数】 粘贴函数代码 【函数说明】 - 输入用户 IDint、时间范围start_date, end_date - 输出该时间段内的订单列表 - 依赖数据库查询、Redis 缓存 【测试要求】 1. 覆盖正常路径有订单、无订单 2. 覆盖边界值时间范围为空、起止时间相同、跨年 3. 覆盖异常路径数据库超时、缓存穿透、非法用户 ID 4. 使用 pytest unittest.mockmock 掉数据库和 Redis 5. 每个用例要有清晰的 docstring 说明测试意图 【输出格式】 - 按测试类组织每个类对应一类场景 - 使用 parametrize 处理多组输入5.3 测试用例的验收标准AI 给出的测试代码我会重点检查三件事断言是否有效有些测试只断言“不报错”等于没测、mock 是否合理mock 太宽会导致测试失去意义、用例是否独立用例之间有依赖是测试的大忌。我个人的经验是AI 生成的测试用例大概能覆盖 60%-70% 的场景剩下的 30% 需要我根据业务理解补充。但即便这样也省了我大量时间。尤其是 parametrize 那部分AI 写得比我规范。注意AI 有时会写出“永远通过”的测试比如断言一个必然为真的条件。拿到测试代码后建议故意改坏被测函数看测试能不能挂掉。挂不掉说明测试是假的。6. 场景五技术方案调研——让 AI 帮你快速摸清一个陌生领域6.1 调研场景下 AI 的定位是“加速器”不是“决策者”遇到不熟悉的技术选型比如“消息队列该选哪个”“这个场景用哪种缓存策略”我现在的第一反应是让 AI 先给我梳理一遍。但要注意AI 给的调研结论不能直接当决策依据它可能信息滞后也可能一本正经地胡说。它的价值在于帮你快速建立认知框架知道该关注哪些维度然后你再去查官方文档验证。6.2 技术调研 Prompt 模板你是一名架构师帮我做一次技术选型调研。 【场景】 - 日均消息量约 200 万条 - 要求消息不丢、支持顺序消费 - 团队现有技术栈Java Spring Boot - 运维能力中等没有专职中间件团队 【候选方案】 - Kafka - RocketMQ - RabbitMQ 【请从以下维度对比】 1. 吞吐量与延迟 2. 消息可靠性保证机制 3. 顺序消费的实现难度 4. 运维复杂度与社区活跃度 5. 与 Spring Boot 的集成成本 【输出要求】 - 用表格对比 - 每个维度给出明确结论和理由 - 最后给出推荐方案并说明在什么情况下推荐会改变这个模板里“在什么情况下推荐会改变”这一句很关键。它能逼着 AI 给出条件化的结论而不是一个武断的答案。技术选型本来就没有银弹条件化结论才有参考价值。6.3 调研结论的验证方法AI 给的调研结果我会做两件事验证查官方文档确认关键数据比如吞吐量、延迟搜社区讨论看实际使用者的反馈。AI 说的“Kafka 单机吞吐百万级”这种数字往往是最理想情况下的理论值实际部署要打不少折扣。另外AI 对新兴技术的了解可能滞后。比如某个框架最近出了重大更新AI 可能还在按老版本回答。所以调研类问题时效性强的部分一定要自己核实。7. 让 AI 真正好用的几个底层习惯7.1 Prompt 要“可复用”不要每次现编我见过很多人每次用 AI 都是临时想怎么说效率很低。我的做法是把高频场景的 Prompt 存成模板用的时候改参数就行。比如新模块生成、Bug 排查、代码评审这三个模板我存在笔记里随时调用。这样不仅快而且质量稳定。模板化的另一个好处是你可以持续迭代。每次发现 AI 输出不理想就回头改模板加约束条件。用久了你的模板会越来越精准。7.2 上下文要给够但不要给太多这是个平衡问题。给太少AI 瞎猜给太多它抓不住重点。我的经验是代码片段控制在 100-200 行日志控制在关键部分需求描述控制在 5 条以内。超过这个量AI 的注意力会被稀释反而容易漏掉关键信息。如果确实需要给大量上下文我会分步来先让 AI 理解整体结构再针对具体问题深入。不要一次性把所有东西塞进去。7.3 永远保持“验证者”心态这是最重要的一条。AI 是个能力很强但会犯错的搭档它给的每一行代码、每一个结论你都要有验证的意识。我见过太多人因为“AI 说的”就放松了警惕结果引入 bug 或者做出错误决策。具体到操作上代码要跑测试结论要查文档方案要结合业务判断。AI 负责提速你负责把关。这个分工不能乱。7.4 常见问题速查表问题现象可能原因解决思路AI 生成的代码跑不起来依赖缺失或版本不匹配检查 import确认项目依赖版本代码逻辑跟项目规范不符Prompt 里没交代规范补充技术栈、命名规范、错误码体系排查 Bug 时 AI 答非所问信息给得太少或太杂按“现象堆栈代码触发条件”结构重问重构后引入新 BugAI 改了边界条件逐行 review diff重点看条件判断测试用例覆盖不全Prompt 没要求异常路径明确要求覆盖边界值和异常场景调研结论不准确AI 信息滞后查官方文档和社区讨论交叉验证这张表是我从实际踩坑中总结的基本覆盖了日常用 AI 写代码时八成以上的问题。遇到卡壳的时候对照着看能省不少时间。8. 我个人的一点使用体会用 AI 辅助写代码这两年最大的感受是它改变的不是“写代码”这件事本身而是“思考代码”的方式。以前遇到问题我得自己从头捋逻辑现在我会先让 AI 给几个方向然后我判断哪个方向对。这个过程里我的角色从“执行者”更多转向了“决策者”。但有个前提你得有判断力。AI 给的东西对不对你得看得出来。所以基础功不能丢该学的原理还得学该踩的坑还得踩。AI 是放大器它放大你的能力也放大你的短板。最后分享一个小习惯我会定期把 AI 给出的好代码和好方案整理到一个笔记里标注当时用的 Prompt。时间长了这就成了一个私人知识库。下次遇到类似问题直接翻笔记比重新问 AI 还快。这个习惯坚持了半年我的 Prompt 模板库已经有三十多个了覆盖了日常工作的绝大部分场景。 AI编程实战：5个高效Prompt模板与结对编程技巧
1. 为什么我不再把 AI 当“代码生成器”而是当“结对搭档”我平时写代码AI 已经深度嵌进了日常工作流。不是那种“帮我写个贪吃蛇”的玩具用法而是真正在业务代码、线上排查、重构评审这些场景里当主力辅助。踩过的坑不少也总结出了一套相对稳定的用法。这篇文章就把我日常最常用的 5 个场景拆开讲每个场景配可直接复制的 Prompt顺便把背后的思路和注意事项说清楚。先说一个核心认知AI 写代码的质量八成取决于你怎么问两成取决于模型本身。很多人抱怨“AI 写的代码不能用”大概率是 Prompt 太模糊。比如“帮我写个登录接口”AI 只能给你一个最通用的模板跟你的项目结构、鉴权方式、错误码规范完全不搭。但如果你把上下文、约束、输出格式都交代清楚它能给出的东西直接就能进代码库。这篇文章适合几类人刚接触 AI 编程辅助想系统了解的、已经在用但觉得效果不稳定的、以及想把这套方法带到团队里做规范的。下面每个场景我都会给出完整的 Prompt 模板你可以直接复制改参数就用。2. 场景一从零写一个新模块——把需求拆到 AI 能“接得住”2.1 为什么直接说“帮我写个 XX”大概率会翻车新手最容易犯的错就是把 AI 当成一个“需求翻译器”扔一句话就等结果。我早期也这样后来发现问题的根源在于AI 没有你项目的上下文。它不知道你用的是哪套框架、数据库字段怎么命名、异常怎么抛、日志怎么打。你给的信息越少它就越倾向于输出“教科书式”的通用代码而这种代码往往跟你的项目格格不入。我的做法是在让 AI 写代码之前先花两分钟把“约束条件”列清楚。这就像你给一个新同事派活你得告诉他项目用什么技术栈、代码规范是什么、这个模块跟哪些已有模块交互。信息给到位产出质量立刻上一个台阶。2.2 我常用的“新模块生成”Prompt 模板下面这个模板是我反复打磨过的适用于后端接口、工具类、数据处理脚本等场景。核心思路是角色 技术栈 功能描述 约束条件 输出格式。你是一名资深后端工程师熟悉 Python 3.11 和 FastAPI 框架。 【任务】 帮我实现一个用户积分查询接口。 【技术栈】 - 框架FastAPI - 数据库PostgreSQL使用 SQLAlchemy 2.0 ORM - 缓存Redis用于热点数据缓存 - 鉴权JWT用户 ID 从 token 中解析 【功能要求】 1. 接口路径GET /api/v1/user/points 2. 入参无用户 ID 从 JWT 中获取 3. 出参{ user_id: int, points: int, level: str, updated_at: str } 4. 积分等级规则0-99 为 bronze100-499 为 silver500 以上为 gold 5. 缓存策略先查 Redis命中则返回未命中查数据库写入 RedisTTL 300 秒 【约束条件】 - 所有数据库操作使用异步 session - 异常统一抛出 HTTPException错误码遵循项目规范 - 日志使用 structlog记录关键路径 - 不要写测试代码只写业务逻辑 【输出格式】 - 先给出完整的路由函数代码 - 再给出对应的 Pydantic 响应模型 - 最后用注释说明每个关键步骤的意图这个模板的关键在于“约束条件”那一段。很多人会忽略它但恰恰是这段决定了代码能不能直接用。比如“异步 session”这一条如果你不说AI 很可能给你同步的写法你还得手动改。2.3 拿到代码后我必做的三件事AI 给出代码只是第一步直接复制粘贴进项目是危险的。我通常会做三件事第一通读一遍逻辑重点看边界条件。AI 经常在“积分等级规则”这种地方写错边界比如 100 到底算 bronze 还是 silver它可能理解反了。第二检查依赖导入AI 有时会引入你项目里根本没装的库。第三跑一遍类型检查Python 项目我会跑 mypyTypeScript 项目跑 tsc能提前发现不少问题。注意AI 生成的代码里异常处理往往是最薄弱的一环。它倾向于用最通用的except Exception这在生产环境是大忌。拿到代码后务必把异常处理改成项目统一的错误码体系。3. 场景二排查线上 Bug——把日志和堆栈喂给 AI 的正确姿势3.1 排查 Bug 时 AI 最怕你只给一句“报错了”线上出问题的时候人容易急直接把一句“接口 500 了帮我看看”扔给 AI。这种问法基本没用因为 AI 没有任何线索。排查类问题的核心是你给的信息越具体AI 的推理链越短定位越准。我一般会准备三样东西完整的错误堆栈、相关的代码片段、以及触发条件什么操作、什么参数、什么时间点。这三样凑齐AI 的排查效率比我翻日志还快。3.2 我的“Bug 排查”Prompt 结构你是一名擅长排查线上问题的资深工程师。 【现象】 调用 /api/v1/order/create 接口时约 5% 的请求返回 500。 错误信息KeyError: user_level 【完整堆栈】 粘贴完整 traceback 【相关代码】 粘贴出错的函数以及上下游调用链大约 50-100 行 【触发条件】 - 只在用户等级为 None 时出现 - 新注册用户首次下单必现 - 老用户复现概率低 【已排查项】 - 数据库 user_level 字段确实存在但部分老数据为 NULL - 代码里没有对 None 做兜底 【请帮我】 1. 定位根因 2. 给出修复方案优先考虑兼容历史数据 3. 指出这类问题在代码里还有哪些潜在位置这个模板里“已排查项”是我后来加上的效果非常好。它能避免 AI 重复你已经做过的工作把精力集中在真正的盲区上。3.3 排查类 Prompt 的三个实战技巧第一个技巧堆栈要完整不要截断。很多人只贴最后几行但真正的根因往往在中间某层调用里。第二个技巧代码片段要给上下文不要只贴出错那一行上下游的调用关系很重要。第三个技巧明确告诉 AI 你要什么是要根因分析、修复方案还是预防建议说清楚它才不会跑偏。我实测下来用这套结构问排查问题AI 给出的根因判断准确率能到七八成剩下两三成需要我自己结合业务判断。但即便它判断错了它列出的排查方向也常常能给我启发。提示涉及敏感数据的日志粘贴给 AI 之前记得脱敏。用户 ID、手机号、订单号这些用占位符替换掉。这不是不信任工具而是基本的职业习惯。4. 场景三代码重构与评审——让 AI 当那个“挑刺的同事”4.1 重构场景下 AI 的真正价值在哪很多人用 AI 重构就是让它“把这段代码优化一下”。但“优化”是个很模糊的词AI 不知道你关心的是性能、可读性还是可维护性。我的经验是重构类任务一定要明确优化目标。比如一段查询代码你可以让 AI 从“减少数据库查询次数”的角度优化也可以从“提升可读性”的角度优化两个方向的产出完全不同。目标越具体产出越有价值。4.2 代码评审 Prompt让 AI 扮演严格的 Reviewer你是一名严格的代码评审员有 10 年 Python 后端经验。 【待评审代码】 粘贴代码建议控制在 200 行以内 【项目背景】 - 这是一个订单状态流转的核心模块 - 日均调用量约 50 万次 - 对性能敏感要求 P99 延迟低于 50ms 【评审重点】 1. 性能问题有没有不必要的循环、重复查询、内存拷贝 2. 并发安全多线程/协程环境下有没有竞态条件 3. 边界处理空值、超长输入、异常路径是否覆盖 4. 可维护性命名、职责划分、注释是否到位 【输出要求】 - 按严重程度分级致命 / 严重 / 建议 - 每条问题给出具体行号和修改建议 - 不要泛泛而谈要指出具体代码位置这个 Prompt 的精髓在“评审重点”和“输出要求”。分级输出能帮你快速抓住关键问题具体行号则让你改起来有的放矢。4.3 重构时我踩过的坑有一次我让 AI 重构一个数据处理函数它把原本 30 行的代码压缩到了 12 行用了各种列表推导和内置函数。看起来很美但可读性直线下降团队里其他人 review 的时候一脸懵。后来我学乖了重构 Prompt 里会加一句“优先保证可读性不要为了简洁牺牲清晰度”。还有一次AI 重构时悄悄改了一个边界条件把改成了导致一个边缘 case 出错。这提醒我AI 重构后的代码diff 一定要逐行看尤其是条件判断和循环边界。5. 场景四写测试用例——AI 最擅长但也最容易偷懒的地方5.1 为什么测试用例特别适合交给 AI写测试是个重复性很高、但又必须覆盖全面的活。AI 在这件事上有天然优势它能快速枚举各种边界条件而且不会像人一样因为“觉得这个 case 不可能发生”而漏掉。我现在的习惯是业务代码自己写测试用例让 AI 先出一版我再补充。但 AI 写测试有个通病它倾向于只写 happy path。正常流程的用例写得很全异常路径、边界值、并发场景经常一笔带过。所以 Prompt 里必须明确要求覆盖这些。5.2 测试用例生成 Prompt 模板你是一名测试工程师擅长用 pytest 编写高质量单元测试。 【被测函数】 粘贴函数代码 【函数说明】 - 输入用户 IDint、时间范围start_date, end_date - 输出该时间段内的订单列表 - 依赖数据库查询、Redis 缓存 【测试要求】 1. 覆盖正常路径有订单、无订单 2. 覆盖边界值时间范围为空、起止时间相同、跨年 3. 覆盖异常路径数据库超时、缓存穿透、非法用户 ID 4. 使用 pytest unittest.mockmock 掉数据库和 Redis 5. 每个用例要有清晰的 docstring 说明测试意图 【输出格式】 - 按测试类组织每个类对应一类场景 - 使用 parametrize 处理多组输入5.3 测试用例的验收标准AI 给出的测试代码我会重点检查三件事断言是否有效有些测试只断言“不报错”等于没测、mock 是否合理mock 太宽会导致测试失去意义、用例是否独立用例之间有依赖是测试的大忌。我个人的经验是AI 生成的测试用例大概能覆盖 60%-70% 的场景剩下的 30% 需要我根据业务理解补充。但即便这样也省了我大量时间。尤其是 parametrize 那部分AI 写得比我规范。注意AI 有时会写出“永远通过”的测试比如断言一个必然为真的条件。拿到测试代码后建议故意改坏被测函数看测试能不能挂掉。挂不掉说明测试是假的。6. 场景五技术方案调研——让 AI 帮你快速摸清一个陌生领域6.1 调研场景下 AI 的定位是“加速器”不是“决策者”遇到不熟悉的技术选型比如“消息队列该选哪个”“这个场景用哪种缓存策略”我现在的第一反应是让 AI 先给我梳理一遍。但要注意AI 给的调研结论不能直接当决策依据它可能信息滞后也可能一本正经地胡说。它的价值在于帮你快速建立认知框架知道该关注哪些维度然后你再去查官方文档验证。6.2 技术调研 Prompt 模板你是一名架构师帮我做一次技术选型调研。 【场景】 - 日均消息量约 200 万条 - 要求消息不丢、支持顺序消费 - 团队现有技术栈Java Spring Boot - 运维能力中等没有专职中间件团队 【候选方案】 - Kafka - RocketMQ - RabbitMQ 【请从以下维度对比】 1. 吞吐量与延迟 2. 消息可靠性保证机制 3. 顺序消费的实现难度 4. 运维复杂度与社区活跃度 5. 与 Spring Boot 的集成成本 【输出要求】 - 用表格对比 - 每个维度给出明确结论和理由 - 最后给出推荐方案并说明在什么情况下推荐会改变这个模板里“在什么情况下推荐会改变”这一句很关键。它能逼着 AI 给出条件化的结论而不是一个武断的答案。技术选型本来就没有银弹条件化结论才有参考价值。6.3 调研结论的验证方法AI 给的调研结果我会做两件事验证查官方文档确认关键数据比如吞吐量、延迟搜社区讨论看实际使用者的反馈。AI 说的“Kafka 单机吞吐百万级”这种数字往往是最理想情况下的理论值实际部署要打不少折扣。另外AI 对新兴技术的了解可能滞后。比如某个框架最近出了重大更新AI 可能还在按老版本回答。所以调研类问题时效性强的部分一定要自己核实。7. 让 AI 真正好用的几个底层习惯7.1 Prompt 要“可复用”不要每次现编我见过很多人每次用 AI 都是临时想怎么说效率很低。我的做法是把高频场景的 Prompt 存成模板用的时候改参数就行。比如新模块生成、Bug 排查、代码评审这三个模板我存在笔记里随时调用。这样不仅快而且质量稳定。模板化的另一个好处是你可以持续迭代。每次发现 AI 输出不理想就回头改模板加约束条件。用久了你的模板会越来越精准。7.2 上下文要给够但不要给太多这是个平衡问题。给太少AI 瞎猜给太多它抓不住重点。我的经验是代码片段控制在 100-200 行日志控制在关键部分需求描述控制在 5 条以内。超过这个量AI 的注意力会被稀释反而容易漏掉关键信息。如果确实需要给大量上下文我会分步来先让 AI 理解整体结构再针对具体问题深入。不要一次性把所有东西塞进去。7.3 永远保持“验证者”心态这是最重要的一条。AI 是个能力很强但会犯错的搭档它给的每一行代码、每一个结论你都要有验证的意识。我见过太多人因为“AI 说的”就放松了警惕结果引入 bug 或者做出错误决策。具体到操作上代码要跑测试结论要查文档方案要结合业务判断。AI 负责提速你负责把关。这个分工不能乱。7.4 常见问题速查表问题现象可能原因解决思路AI 生成的代码跑不起来依赖缺失或版本不匹配检查 import确认项目依赖版本代码逻辑跟项目规范不符Prompt 里没交代规范补充技术栈、命名规范、错误码体系排查 Bug 时 AI 答非所问信息给得太少或太杂按“现象堆栈代码触发条件”结构重问重构后引入新 BugAI 改了边界条件逐行 review diff重点看条件判断测试用例覆盖不全Prompt 没要求异常路径明确要求覆盖边界值和异常场景调研结论不准确AI 信息滞后查官方文档和社区讨论交叉验证这张表是我从实际踩坑中总结的基本覆盖了日常用 AI 写代码时八成以上的问题。遇到卡壳的时候对照着看能省不少时间。8. 我个人的一点使用体会用 AI 辅助写代码这两年最大的感受是它改变的不是“写代码”这件事本身而是“思考代码”的方式。以前遇到问题我得自己从头捋逻辑现在我会先让 AI 给几个方向然后我判断哪个方向对。这个过程里我的角色从“执行者”更多转向了“决策者”。但有个前提你得有判断力。AI 给的东西对不对你得看得出来。所以基础功不能丢该学的原理还得学该踩的坑还得踩。AI 是放大器它放大你的能力也放大你的短板。最后分享一个小习惯我会定期把 AI 给出的好代码和好方案整理到一个笔记里标注当时用的 Prompt。时间长了这就成了一个私人知识库。下次遇到类似问题直接翻笔记比重新问 AI 还快。这个习惯坚持了半年我的 Prompt 模板库已经有三十多个了覆盖了日常工作的绝大部分场景。