1. 被误解的“基本功”为什么 Prompt 不是护城河过去一年多我身边不少做开发的朋友都陷入了一种集体焦虑看着各种 AI 编程工具层出不穷感觉自己多年积累的编码能力正在被快速稀释。于是大家纷纷开始研究怎么写更精妙的提示词收藏夹里塞满了各种“万能模板”“咒语大全”仿佛只要掌握了某几句神奇的话术就能让 AI 乖乖写出生产级代码。但实际用下来情况往往很骨感。同一个需求你照着模板把提示词写得花团锦簇AI 生成的结果可能依然漏洞百出而隔壁工位那位看起来“不太会写提示词”的老哥只是简单描述了几句AI 却像开了窍一样输出得又快又准。这个反差背后藏着一个被大多数人忽略的事实AI 编程的真正门槛从来不在提示词本身而在于你如何定义问题、拆解任务、验证结果。我打个比方。Prompt 就像是你跟一位能力极强但完全不了解你项目背景的新同事沟通。你可以把话说得很漂亮但如果这位新同事不知道你的代码规范、不清楚你的架构约束、不明白你的业务边界再华丽的措辞也换不来可用的产出。真正决定协作效率的是你能否把“做什么”“为什么做”“做到什么程度”讲清楚以及你能否判断他交回来的东西到底对不对。所以这篇文章想聊的不是又一个“提示词速成指南”而是那些被热搜和短视频掩盖掉的、真正决定 AI 编程成败的基本功。这些能力不会因为模型迭代而贬值反而会随着工具越来越强而愈发重要。无论你是刚接触 AI 编程的新手还是已经用了一段时间但总觉得“差点意思”的开发者下面这些内容都值得你花时间重新审视一遍。2. 基本功之一把模糊需求翻译成可执行规格2.1 为什么“帮我写个登录功能”注定失败我见过太多人对着 AI 输入类似“帮我写一个用户登录功能”这样的指令然后抱怨 AI 写出来的代码不能用。问题出在哪出在这句话本身就不是一个工程需求而是一个愿望。“登录功能”这四个字背后至少隐藏着几十个决策点用什么认证方式会话怎么管理密码怎么存储要不要验证码失败几次锁定支不支持多端和现有用户表怎么关联这些决策你不做AI 就只能靠猜。而 AI 猜中的概率跟你闭着眼睛投飞镖差不多。真正的基本功是把愿望翻译成规格。这其实和传统软件工程里写需求文档是一回事只不过现在你的“开发人员”变成了 AI它对模糊信息的容忍度更低因为它不会主动来找你确认。2.2 一个可复用的需求拆解框架我自己的习惯是用一个固定的四层框架来拆解任何要交给 AI 的任务这里分享出来供你参考第一层目标与边界。这个功能要解决什么问题明确不做什么比如“实现基于邮箱和密码的登录不包含第三方登录不包含注册流程”。第二层输入与输出。接口的入参是什么格式出参是什么结构异常情况返回什么把这些用表格或 JSON 示例写清楚。第三层约束与规范。用什么语言和框架遵循什么代码风格有没有性能要求依赖哪些现有模块第四层验收标准。怎么判断做完了需要覆盖哪些测试用例边界条件有哪些这四层写下来通常也就一两百字但信息密度远超那些花哨的提示词模板。更重要的是这个拆解过程本身就是在帮你理清思路——很多时候写着写着你会发现自己原本的想法就有漏洞。2.3 用“验收标准前置”倒逼需求清晰这里有个我屡试不爽的技巧先写测试用例再让 AI 写实现。这其实是测试驱动开发思路在 AI 编程场景下的自然延伸。比如你要让 AI 写一个日期格式化函数不要直接说“写个格式化日期的函数”而是先列出输入2024-01-15格式 YYYY年MM月DD日 期望输出2024年01月15日 输入无效日期字符串 abc 期望输出抛出 InvalidDateError 输入null 期望输出返回空字符串把这些验收标准给到 AI它生成的代码质量会有质的飞跃。因为你不是在让它“猜你想要什么”而是在给它一个明确的靶子。这个习惯一旦养成你会发现不仅 AI 编程效率提升了你自己对需求的理解也深刻了一个层次。提示验收标准不需要写得像正式测试报告那么严谨用自然语言列出关键场景即可。重点是让 AI 知道“什么算对什么算错”。3. 基本功之二上下文工程比提示词工程重要十倍3.1 模型不知道你的项目长什么样这是新手最容易踩的坑把 AI 当成一个无所不知的专家默认它了解你的项目结构、命名习惯、历史包袱。实际上每次对话开始时模型对你的代码库一无所知。你给它的上下文就是它全部的信息来源。我见过有人让 AI 修改一个函数结果 AI 把整个文件重写了一遍引入了三个新依赖还改了公共接口。原因很简单AI 不知道这个函数被哪些地方调用不知道项目里已经有一个现成的工具类可以复用也不知道团队规范禁止随意新增依赖。上下文工程的核心就是在正确的时机把正确的信息以正确的形式喂给模型。这比研究怎么措辞重要得多。3.2 分层投喂给 AI 建立“项目认知”我的做法是把上下文分成三个层次按需投喂层次内容投喂时机全局层技术栈、目录结构、代码规范、核心抽象会话开始时一次性说明模块层当前模块的职责、依赖关系、关键接口处理具体模块时提供任务层当前任务的具体文件、相关函数、数据结构每次具体请求时附带全局层的信息可以整理成一个简短的“项目说明书”每次开新会话时贴给 AI。别嫌麻烦这几百字能省下后面无数次返工。模块层和任务层则根据实际情况灵活调整原则是“相关但不过量”——给太多无关代码反而会干扰模型判断。3.3 用“反向提问”检验上下文质量有个简单的方法可以检验你给的上下文够不够让 AI 复述它理解的任务。在正式让它写代码之前先问一句“你理解我要做什么吗请用你的话复述一遍并列出你不确定的地方”。如果 AI 复述得准确说明上下文到位了如果它复述得离谱或者列出一堆你根本没意识到的歧义点那恭喜你你在写代码之前就发现了需求漏洞。这个“反向提问”的习惯帮我省下的调试时间难以计数。注意不要指望一次就把上下文给全。实际协作中上下文是逐步补全的。关键是每次补充都要有明确目的而不是一股脑把整个代码库塞进去。4. 基本功之三代码审查能力决定 AI 产出上限4.1 AI 写的代码你敢直接上线吗这个问题听起来像废话但现实中真有不少人把 AI 生成的代码复制粘贴就提交了。我理解那种“看起来能跑就行”的心态尤其是在赶进度的时候。但 AI 生成的代码有几个典型特征如果不加审查直接使用迟早会出问题。第一AI 倾向于过度设计。你让它写个简单的工具函数它可能给你整出一个带策略模式、工厂模式和配置系统的“框架”。第二AI 会编造不存在的 API。尤其是涉及较新或较小的库时它可能一本正经地调用一个根本不存在的方法。第三AI 对边界条件处理往往不够。空值、超长输入、并发场景这些它经常考虑不全。所以代码审查不是可选项而是 AI 编程流程中不可省略的一环。而且这个审查能力恰恰是 AI 替代不了的——它需要你对业务、对系统、对潜在风险有真实的理解。4.2 审查 AI 代码的四个重点维度我审查 AI 代码时会按优先级过一遍这四个维度正确性逻辑是否真的实现了需求边界条件覆盖了吗异常处理合理吗这个维度最花时间但也最重要。安全性有没有注入风险敏感数据会不会泄露权限校验是否到位AI 对安全问题的敏感度参差不齐必须人工把关。可维护性命名是否清晰结构是否合理有没有重复代码AI 有时会为了“优雅”而牺牲可读性需要拉回来。一致性是否符合项目现有风格有没有引入不必要的依赖和现有模块的交互方式是否统一这四个维度里正确性和安全性是底线可维护性和一致性是加分项。时间紧的时候至少要把前两个维度过一遍。4.3 把审查意见转化为下一轮输入审查出问题之后怎么反馈给 AI 也有讲究。直接说“这里不对”效果很差因为它不知道“对”的标准是什么。有效的反馈应该包含三要素问题描述、期望结果、判断依据。比如不要说“这个函数有问题”而要说“这个函数在输入为空数组时会抛异常期望是返回空列表因为调用方没有做空值判断”。这样 AI 才能准确修正而不是瞎猜。更进一步你可以把审查中发现的共性问题沉淀成“项目规范”下次开新会话时直接放进全局层上下文。这样 AI 从一开始就知道你的底线在哪里返工率会明显下降。5. 基本功之四调试与验证的闭环思维5.1 AI 说“修好了”不等于真的修好了这是另一个高频陷阱你发现一个 bug告诉 AIAI 改了一版说“已经修复”。你一看代码确实变了就信了。结果跑起来发现原来的问题还在甚至引入了新问题。AI 没有运行环境它无法真正验证自己的修改是否有效。它只是根据你的描述和代码上下文做出了一个“看起来合理”的修改。所以验证这件事必须由你来完成。而且验证不能只看代码 diff要实际运行、实际测试。我的习惯是每次 AI 修改完代码我都会问自己三个问题这个修改真的针对根因了吗有没有可能影响其他功能我该怎么验证它确实修好了这三个问题逼着我建立完整的验证闭环而不是盲目信任。5.2 构建最小复现用例调试 AI 生成的代码时一个非常有效的技巧是构建最小复现用例。把出问题的场景从复杂系统中剥离出来用最少的代码复现它。这样做有两个好处一是帮你确认自己真的理解了问题二是给 AI 提供干净的调试上下文。比如你发现某个数据处理流程在特定输入下出错不要直接把整个流程丢给 AI而是抽取出出错的那一步构造一个独立的输入输出示例。这样 AI 能聚焦在真正的问题上而不是被无关代码干扰。5.3 让 AI 参与调试但由你主导方向AI 在调试中其实很有用但用法要对。不要指望它“自动找到 bug”而是把它当成一个思路扩展器。你可以这样用让它列出可能导致这个现象的原因你来判断哪个最可疑让它解释某段代码的执行流程你来对照实际行为找差异让它生成针对某个假设的测试用例你来运行验证这个过程中AI 负责发散和辅助你负责收敛和决策。方向始终由你掌控AI 只是加速了你的思考过程。实操心得调试时把错误信息、相关代码、你已经尝试过的方案一起给 AI比只丢一句“报错了”效率高得多。信息越完整AI 的建议越靠谱。6. 基本功之五架构判断力是最后的护城河6.1 AI 能写模块但写不好系统把视角拉高一层。AI 现在写单个函数、单个类、甚至单个模块表现都相当不错。但一旦涉及系统级设计——模块怎么划分、服务怎么拆分、数据怎么流转、技术选型怎么权衡——AI 的表现就明显力不从心了。原因不难理解。系统设计需要考虑的因素太多团队规模、运维能力、成本预算、演进路径、历史包袱这些信息 AI 很难完整获取也很难做出真正贴合实际的权衡。它给出的方案往往是“教科书式”的看起来合理但放到具体场景里可能完全不适用。所以架构判断力成了 AI 时代开发者最值钱的能力之一。你能不能让 AI 帮你写某个模块取决于你对整体架构的清晰认知你能不能判断 AI 给的方案是否合适取决于你对各种权衡的理解深度。6.2 用 AI 做方案对比而不是方案决策AI 在架构层面最有价值的用法是快速生成多个备选方案并列出各自的优劣。比如你要选一个消息队列可以让 AI 对比几种常见方案的适用场景、运维复杂度、社区活跃度。这些信息它整理得又快又全能帮你节省大量调研时间。但最终决策必须你自己做。因为只有你知道团队里没人用过某个技术、只有你知道运维资源有限、只有你知道这个系统明年可能要重构。这些“只有你知道”的信息才是决策的关键依据。6.3 保持对技术本质的理解最后想说的是无论 AI 工具多强大对技术本质的理解不能丢。你可以不手写每一行代码但你要知道 HTTP 请求是怎么走的、数据库索引是怎么工作的、并发问题是怎么产生的。这些底层认知决定了你能否判断 AI 的输出是否合理能否在出问题时快速定位。我见过一些开发者用 AI 用得很溜但一旦遇到 AI 解决不了的问题就束手无策。根源就在于他们跳过了对原理的理解直接进入了“调 API”的层面。这种能力结构是脆弱的因为 AI 越强纯“调 API”的价值就越低。反过来那些对原理理解透彻的人用 AI 如虎添翼。他们能精准地描述问题、能快速判断方案优劣、能在 AI 卡壳时自己顶上。这种“人机协作”的状态才是 AI 编程的理想形态。7. 常见问题与排查技巧实录7.1 AI 编程高频问题速查表问题现象可能原因排查方向生成的代码跑不起来上下文缺失或 API 幻觉检查依赖版本核对 API 是否存在改了一个地方坏了另一个地方未提供调用关系上下文补充相关模块的依赖信息代码风格和项目不一致未说明代码规范在全局上下文中加入规范说明反复修改都修不好问题描述不准确构建最小复现用例重新描述输出越来越离谱会话上下文过长或混乱开新会话重新整理上下文性能不达标未提出性能约束明确数据规模和性能要求7.2 几个我踩过的坑第一个坑是过度依赖单次长对话。早期我喜欢在一个会话里连续处理很多任务结果发现随着对话变长AI 的表现会下降有时候还会“忘记”前面说过的约束。后来我改成每个独立任务开新会话把必要的上下文重新整理一遍效果稳定多了。第二个坑是让 AI 做它不擅长的事。比如让 AI 猜某个业务逻辑的意图、让 AI 决定技术选型、让 AI 处理需要外部系统交互的调试。这些事它要么做不好要么会给你一个看似合理实则错误的答案。识别 AI 的能力边界比挖掘它的能力上限更重要。第三个坑是忽视版本差异。同一个库的不同版本 API 可能完全不同而 AI 的训练数据可能覆盖多个版本。如果不明确指定版本它可能给你一个“混合版”的代码。现在我给上下文时一定会带上关键依赖的版本号。7.3 建立自己的“协作手册”用 AI 编程用久了你会慢慢形成一套自己的习惯。我的建议是把这些习惯显式地写下来形成一份个人或团队的“AI 协作手册”。内容包括什么任务适合交给 AI、上下文怎么组织、审查重点是什么、常见坑有哪些。这份手册不需要多正式几页纸就够。但它的价值在于把零散的经验固化成可复用的流程。下次遇到类似任务你不用重新摸索照着手册走就行。团队协作时这份手册还能统一大家的用法减少沟通成本。8. 回到本质AI 时代开发者该练什么聊了这么多其实核心观点就一个AI 编程的真正基本功是那些 AI 替代不了的工程能力。需求拆解、上下文组织、代码审查、调试验证、架构判断这些能力在 AI 出现之前就存在只是现在它们的重要性被放大了。Prompt 技巧当然有用但它更像是“锦上添花”而非“雪中送炭”。你把基本功练扎实了哪怕提示词写得朴素AI 也能产出高质量结果基本功不扎实提示词再花哨也是空中楼阁。我自己在实际操作中的体会是与其花时间收集各种提示词模板不如花时间做三件事把需求想清楚、把上下文整理好、把验证做到位。这三件事做到位AI 编程的效率和质量都会有肉眼可见的提升。至于提示词用着用着自然就顺手了它是在实践中长出来的不是背出来的。最后再分享一个小技巧每次用 AI 完成一个任务后花两分钟复盘一下——这次哪里顺畅、哪里卡壳、下次可以怎么改进。这个复盘习惯坚持下来你会发现自己对 AI 编程的理解越来越深用起来也越来越得心应手。工具在变但工程思维的价值不会变。