1. 被误解的“基本功”为什么 Prompt 不是终点这两年跟不少同行聊 AI 编程发现一个特别普遍的现象很多人把“会写 Prompt”当成了核心竞争力甚至觉得只要提示词写得够花哨AI 就能自动把活干完。我一开始也走过这个弯路花了不少时间研究各种提示词模板、角色设定、思维链格式结果在实际项目里该翻车还是翻车。后来才慢慢想明白一件事Prompt 只是你和模型之间的接口真正决定输出质量的是你对问题的拆解能力、对上下文的组织能力以及对结果的验证能力。打个比方Prompt 就像你跟装修师傅沟通时说的话。话说得清楚当然重要但如果你自己都不知道想要什么风格、水电怎么走、预算怎么分配那话说得再漂亮最后装出来的房子大概率也不是你想要的。AI 编程也是这个道理——模型再强它也只是执行者真正的“设计图纸”得你自己出。那什么才是 AI 编程的真正基本功我总结下来是四样东西问题拆解、上下文管理、结果验证、以及工程化思维。这四样东西跟你会不会写 Prompt 关系不大但跟你是不是一个合格的工程师关系极大。下面我逐个拆开讲结合我自己的实操经验把每个环节的细节和坑都摊开来说。1.1 一个真实的翻车案例先说个我自己的教训。之前接了一个需求要给一个内部工具加一个“数据导出”功能支持导出成 CSV 和 Excel 两种格式。我当时觉得这活儿简单直接给 AI 甩了一句“帮我写一个数据导出功能支持 CSV 和 Excel。”结果 AI 给出来的代码CSV 部分还行Excel 部分用了一个我没听说过的库而且导出逻辑里把整个数据集一次性加载到内存完全没有分页处理。问题出在哪不是 Prompt 写得不好是我自己没想清楚几个关键点数据量有多大需不需要流式导出Excel 格式有没有特殊要求比如单元格样式、多 sheet这些我都没定义AI 只能猜猜出来的结果自然不能用。后来我重新梳理了需求把问题拆成几个子问题数据源是什么、导出触发方式是什么、目标格式的具体要求、性能约束是什么。然后针对每个子问题分别跟 AI 沟通最后再让它把各部分组装起来。这次出来的代码质量明显不一样基本一次通过。这个经历让我意识到AI 编程的核心不是“怎么问”而是“问什么”。你得先有能力把一个大问题拆成若干个小问题每个小问题都有明确的输入、输出和约束条件然后才能指望 AI 帮你高效解决。2. 基本功之一问题拆解能力问题拆解听起来像句废话谁不会拆问题但实际操作中我发现很多人拆问题的粒度太粗或者拆完之后子问题之间还有隐含依赖没理清楚。AI 编程场景下拆解的质量直接决定了你后续跟 AI 交互的效率。2.1 拆解的粒度怎么把握我的经验是每个子问题应该是一个“可独立验证”的单元。什么意思就是你把这个子问题交给 AI 之后它给出的结果你能单独跑起来、单独测试、单独判断对错。如果一个子问题还需要依赖另一个子问题的输出才能验证那说明拆得还不够细。举个例子你要做一个“用户登录”功能。粗拆可能是前端页面、后端接口、数据库查询。但这个粒度太粗了AI 给你的代码你没法直接验证。细拆应该是数据库表结构设计字段、类型、索引密码加密与校验逻辑用什么算法、盐值怎么处理登录接口的请求/响应格式定义前端表单的字段校验规则登录态的管理方式token 还是 session每个子问题都可以单独拿出来让 AI 生成代码而且生成之后你能立刻写个测试用例验证。这样一步步推进最后组装起来的时候出问题的概率会小很多。2.2 拆解时容易忽略的“隐性依赖”拆解的时候有个坑特别容易踩子问题之间的隐性依赖。比如你让 AI 先生成数据库查询代码再生成接口代码但接口代码里用到的字段名跟数据库查询返回的字段名对不上。这种问题在粗粒度拆解时经常出现因为 AI 不知道你前面生成了什么。解决办法是在拆解阶段就把接口契约定下来。比如你先定义一个数据模型# 用户登录相关的数据模型定义 class LoginRequest: username: str password: str class LoginResponse: token: str expires_at: int user_id: str然后把这个模型定义作为上下文分别让 AI 生成数据库查询、接口逻辑、前端调用代码。这样各个部分之间的字段名、类型都能对齐组装的时候基本不会出现“对不上”的问题。注意拆解阶段花的时间会在后续组装和调试阶段成倍省回来。我自己的经验是拆解时间占总时间的 20% 左右比较合理低于这个比例后面大概率要返工。2.3 拆解后的优先级排序拆完之后还有个步骤排优先级。不是所有子问题都一样重要有些是核心路径有些是边缘情况。我的做法是先搞定核心路径让整个流程能跑通然后再逐个补充边缘情况。比如做数据导出功能核心路径是“查询数据 → 格式化 → 写入文件 → 下载”。边缘情况包括数据量为零怎么处理、导出过程中用户取消怎么办、文件名冲突怎么解决。先把核心路径跑通你就能看到一个可用的版本然后再让 AI 帮你补充边缘情况的处理逻辑。这样每一步都有正反馈不至于一开始就陷在细节里出不来。3. 基本功之二上下文管理能力跟 AI 协作编程上下文管理是另一个容易被低估的能力。很多人觉得上下文就是“把代码贴给 AI”但实际上上下文的组织方式、裁剪策略、更新时机都会直接影响 AI 的输出质量。3.1 上下文不是越多越好我见过有人把整个项目的代码都贴给 AI觉得这样 AI 就能“理解全局”。但实际上上下文太长会导致两个问题一是模型注意力被分散关键信息反而被淹没二是 token 消耗大成本高不说还可能触发长度限制。我的做法是只给当前子问题相关的上下文。比如我在写一个 API 接口我只需要给 AI 看这个接口的路由定义、相关的数据模型、以及它依赖的服务层方法签名。不需要把整个项目的代码都塞进去。具体操作上我会维护一个“上下文清单”每次跟 AI 交互前先想清楚这次需要哪些信息上下文类型是否必需说明当前子问题的需求描述必需明确输入输出和约束相关的数据模型定义必需保证字段名和类型对齐依赖的方法签名必需知道能调用哪些方法相邻模块的代码可选需要风格对齐时才给整个项目的代码不需要信息过载反而干扰3.2 上下文的更新时机上下文不是一次给完就完事了随着子问题的推进上下文需要动态更新。比如你刚让 AI 生成了一个工具函数接下来要写调用这个函数的代码那你就需要把刚才生成的函数签名加到上下文里。我习惯用一个小技巧每次跟 AI 交互后把关键产出函数签名、数据模型、接口定义摘出来存到一个单独的文档里。下次交互时直接把这个文档作为上下文的一部分。这样既能保证信息不丢失又不会把无关的代码带进来。3.3 用“契约”代替“代码”作为上下文还有一个进阶技巧尽量用接口契约而不是具体实现作为上下文。比如你要让 AI 写一个调用数据库的方法你不需要把数据库连接的具体代码给它看只需要告诉它“有一个方法叫query_users接收一个user_id参数返回一个User对象”。这样 AI 生成的代码会更干净不会跟具体的实现细节耦合。这个思路其实跟微服务架构里的“面向接口编程”是一个道理。AI 不需要知道底层怎么实现的它只需要知道能调用什么、返回什么。这样生成的代码可测试性也更好因为你可以很方便地 mock 掉依赖。4. 基本功之三结果验证能力AI 生成的代码永远不要直接信。这不是说 AI 能力不行而是因为 AI 没有你的业务上下文它不知道哪些边界情况需要处理也不知道你的代码规范是什么。所以验证环节是必须的而且验证能力本身就是一个核心基本功。4.1 验证的三个层次我把验证分成三个层次语法验证、逻辑验证、边界验证。语法验证最简单代码能不能跑起来、有没有明显的语法错误。这个大部分 IDE 都能帮你做AI 生成的代码一般语法问题不大。逻辑验证是看代码的逻辑是否符合你的预期。比如你让 AI 写一个“计算订单总价”的函数你得检查它有没有把折扣、税费、运费都算进去计算顺序对不对。这个层次需要你自己对业务逻辑非常清楚否则你根本不知道 AI 写得对不对。边界验证是最容易被忽略的。比如输入为空、输入超长、数值溢出、并发冲突这些情况AI 默认生成的代码往往不会处理。你需要主动构造这些边界条件去测试发现问 题再让 AI 补充处理逻辑。4.2 用测试用例驱动验证我的习惯是在让 AI 生成代码之前先想好测试用例。比如我要一个“判断字符串是否为合法邮箱”的函数我会先列出几个测试用例# 测试用例设计 test_cases [ (userexample.com, True), # 正常邮箱 (user.com, False), # 域名不完整 (example.com, False), # 缺少用户名 (userexample, False), # 缺少顶级域名 (user nameexample.com, False), # 包含空格 (, False), # 空字符串 ]然后把这些测试用例一起给 AI让它生成能通过这些用例的代码。这样 AI 的输出就有了明确的验证标准你也能快速判断它写得对不对。4.3 验证过程中的常见陷阱验证的时候有几个坑我踩过这里列出来供参考只验证正常路径只测了输入合法的情况没测异常输入。结果上线后遇到脏数据直接崩了。验证环境跟生产环境不一致本地测试用的是小数据集生产环境数据量大性能问题没暴露出来。过度依赖 AI 的自我验证让 AI 自己检查代码有没有问题它往往会说“没问题”但实际上问题还在。验证必须由你自己来做。提示验证环节的时间投入不要省。我自己的比例是生成代码占 30%验证和调试占 70%。这个比例看起来夸张但实际做下来前期验证充分的话后期返工的时间会大幅减少。5. 基本功之四工程化思维最后一个基本功是工程化思维。AI 编程很容易让人陷入“能跑就行”的状态因为生成代码太快了快到你来不及思考架构和可维护性。但代码是要给人看的也是要长期维护的所以工程化思维不能丢。5.1 代码风格的一致性AI 生成的代码风格可能跟你项目现有的风格不一致。比如你项目里用的是 4 空格缩进AI 给你生成的是 2 空格你项目里用驼峰命名AI 给你生成的是下划线命名。这些细节看起来小但积累多了会让代码库变得混乱。解决办法是在上下文里明确告诉 AI 你的代码规范。比如请遵循以下代码规范 - 缩进使用 4 个空格 - 变量和函数名使用驼峰命名法 - 类名使用大驼峰命名法 - 常量使用全大写下划线分隔 - 每个函数不超过 50 行 - 公共方法必须写文档注释把这些规范作为系统提示的一部分每次交互都带上AI 生成的代码风格就会一致很多。5.2 模块划分与职责单一AI 生成代码时倾向于把所有逻辑写在一个函数里。比如你让它写一个“处理用户注册”的功能它可能把参数校验、密码加密、数据库写入、发送邮件全塞在一个函数里。这种代码能跑但不好维护。你需要主动引导 AI 做模块划分。比如你可以这样拆validate_registration_params(params)只负责参数校验hash_password(password)只负责密码加密create_user_in_db(user_data)只负责数据库写入send_welcome_email(user_email)只负责发送邮件每个函数只做一件事然后在一个主流程里把它们串起来。这样代码的可读性和可测试性都会好很多。5.3 错误处理与日志AI 生成的代码往往对错误处理比较敷衍要么直接抛异常要么吞掉异常什么都不做。但在生产环境里错误处理和日志是必不可少的。我的做法是在让 AI 生成代码时明确要求它加上错误处理和日志。比如import logging logger logging.getLogger(__name__) def create_user_in_db(user_data): try: # 数据库写入逻辑 result db.users.insert_one(user_data) logger.info(f用户创建成功: {user_data[username]}) return result except DuplicateKeyError: logger.warning(f用户名已存在: {user_data[username]}) raise ValueError(用户名已被占用) except Exception as e: logger.error(f用户创建失败: {str(e)}) raise这样生成的代码出问题的时候你能快速定位而不是两眼一抹黑。6. 实操流程从需求到上线的完整链路前面讲了四个基本功这一节我把它们串起来展示一个完整的实操流程。假设我们要做一个“文件上传与解析”的功能支持上传 CSV 文件并解析成结构化数据。6.1 第一步需求拆解先把需求拆成子问题文件上传接口接收文件、校验格式、保存到临时目录CSV 解析逻辑读取文件、解析表头、逐行解析数据数据校验检查必填字段、数据类型、数值范围数据入库将解析后的数据写入数据库错误处理解析失败时返回明确的错误信息每个子问题都可以独立开发和验证。6.2 第二步定义接口契约在写代码之前先把数据模型和接口定义好# 数据模型 class UploadedFile: filename: str content_type: str size: int temp_path: str class ParsedRow: row_number: int data: dict errors: list class ParseResult: total_rows: int success_rows: int failed_rows: list这些契约定义好之后后续每个子问题的开发都围绕这些契约来保证各部分能对接上。6.3 第三步逐个实现子问题以 CSV 解析逻辑为例我会这样跟 AI 沟通请实现一个 CSV 解析函数要求 - 输入文件路径字符串 - 输出ParseResult 对象 - 使用 Python 标准库 csv 模块 - 第一行作为表头 - 每行数据解析后检查必填字段是否为空 - 如果某行解析失败记录行号和错误信息继续解析下一行 - 不要因为单行失败而中断整个解析过程AI 生成代码后我会用几个测试文件验证正常文件、空文件、只有表头的文件、包含脏数据的文件。验证通过后再进入下一个子问题。6.4 第四步集成与联调所有子问题都实现完之后把它们组装起来。这时候重点检查各模块之间的数据传递是否正确错误处理是否覆盖了所有失败路径日志是否足够定位问题性能是否满足要求比如大文件上传时内存占用集成阶段最容易出现的问题是“接口对不上”但因为前面已经定义了契约这类问题会少很多。6.5 第五步上线前的检查清单上线前我会过一遍这个清单检查项检查内容功能完整性所有需求点是否都已实现边界处理空文件、超大文件、格式错误文件是否都有处理错误提示用户能否看懂错误信息日志记录关键操作是否有日志性能表现大文件上传和解析是否在可接受范围内安全性文件类型校验、大小限制、路径穿越防护这个清单看起来简单但每次过一遍都能发现几个遗漏的点。7. 常见问题与排查技巧实录在实际操作中我遇到过不少典型问题这里整理成速查表方便大家参考。7.1 AI 生成的代码跑不起来怎么办这是最常见的问题。排查思路是看报错信息Python 的报错信息通常很明确直接看最后一行。检查依赖AI 可能用了你没安装的库或者用了不同版本的 API。检查上下文AI 可能假设了一些不存在的变量或方法检查它引用的东西是否真的存在。简化问题把代码拆成更小的片段逐个运行定位到具体哪一段出问题。提示如果 AI 生成的代码反复跑不起来不要一直让它“修复”而是把报错信息完整贴给它并告诉它你的运行环境Python 版本、已安装的库。信息越完整它修复的成功率越高。7.2 AI 生成的代码逻辑不对怎么办逻辑不对通常是因为需求描述不够清晰。我的做法是把需求拆成更细的步骤逐步跟 AI 确认提供具体的输入输出示例让 AI 照着示例写如果还是不对自己先写伪代码让 AI 把伪代码翻译成具体语言的代码7.3 代码风格不一致怎么办前面提过在上下文里明确代码规范。如果已经生成了不一致的代码可以让 AI 帮你统一格式化或者用项目的 lint 工具自动修复。7.4 性能不达标怎么办AI 生成的代码往往不是性能最优的。如果性能不达标先定位瓶颈在哪是数据库查询慢、还是循环太多、还是内存占用高。定位到具体问题后再针对性地让 AI 优化。比如数据库查询慢可能是没有加索引或者查询了不必要的字段。你可以让 AI 帮你分析查询语句给出优化建议。7.5 常见问题速查表问题现象可能原因解决思路代码跑不起来依赖缺失、API 版本不对检查报错信息确认环境逻辑不符合预期需求描述不清晰补充输入输出示例拆细需求风格不一致未指定代码规范在上下文中加入规范说明性能差算法效率低、缺少索引定位瓶颈针对性优化边界情况崩溃未处理异常输入补充边界测试用例集成时对不上接口契约未定义提前定义数据模型和接口8. 我个人的一些实操心得最后分享几个我在实际项目中总结的小技巧都是踩过坑之后才明白的。第一不要一次性让 AI 生成太多代码。我试过让 AI 一次性生成一个完整模块结果代码量太大它自己都顾此失彼前面定义的变量后面忘了用。后来改成每次只生成一个函数或一个类质量明显提升。第二把 AI 当成一个“很聪明但很健忘的同事”。它能力很强但记不住你之前说过什么。所以每次交互都要把必要的上下文带上不要指望它记得你上一轮说了什么。第三验证环节不要偷懒。我见过有人直接复制 AI 生成的代码到生产环境结果出了事故。AI 生成的代码一定要经过测试尤其是边界情况和异常路径。第四保持自己的判断力。AI 有时候会给出看起来合理但实际上有问题的方案。比如它可能推荐一个已经不维护的库或者用一个有安全隐患的写法。你需要有能力判断这些方案是否靠谱。第五持续积累自己的“代码片段库”。跟 AI 协作久了你会发现某些场景反复出现比如参数校验、错误处理、日志记录。把这些常用逻辑整理成自己的代码片段库下次直接复用不用每次都让 AI 重新生成。这些心得听起来简单但真正做到需要刻意练习。AI 编程的效率提升是实实在在的但前提是你得把基本功练扎实。Prompt 只是表面功夫真正决定你上限的还是那些传统的工程能力拆解问题、管理上下文、验证结果、保持工程化思维。这些东西AI 替代不了也帮你省不了。
