1. "代码写得快，方向错得更快"：半年AI编程的真实体验

先说结论：这半年我用 AI 编程写出的代码量，比过去三年手动敲的还多。项目从内部工具到中台服务都有涉及，Cline、Cursor、Windsurf、VS Code Copilot、Trae 基本都深度用过，中间还接过 DeepSeek 的 API 自己搭过工作流。但最后卡住我的，不是模型上下文不够长，也不是代码生成质量不稳定，而是我自己根本写不出一份像样的需求描述。

最初我也有所有程序员的通病：拿到一个模糊想法，打开 Cursor，直接输入"帮我写一个XX系统"。AI 确实立刻开始生成代码，文件结构、数据库表、接口定义一应俱全。第一周我甚至有点飘，觉得"程序员这个职业完蛋了"只是时间问题。但等代码量到一定程度，问题开始暴露：AI 写出来的东西完全符合我的字面描述，却根本不符合我的真实意图。我反复改提示词，它反复重构，改到最后整个代码库变得七零八落，一堆死代码和没有人能说清的怪逻辑。

这个经历让我意识到一个反直觉的事实：AI编程真正考验的不是代码能力，而是需求表达能力。以前和产品经理对接，需求不清至少还有一个人能和你来回掰扯，双方用沉默和默契补全信息；现在对面变成了一个"极度听话、绝对不和你确认、直接把所有假设当事实执行"的机器，你脑子里的模糊地带，全部原样具象化成了代码里的错误。它能精确执行，但它不会读心。

这篇文章不是来吹某个工具多好用的。我想认真聊聊一个看起来特别"软"、实际上决定AI编程成败的问题：怎么把脑子里模糊的想法，变成 AI 能一次听懂、不必反复返工的输入。文章里会有我踩坑的实录、排查思路的复盘，以及一套我整理出来、现在团队里所有人都在用的需求描述模板。

如果你刚开始尝试 AI 编程，或者已经用了 AI 编程但总觉得"生成的东西不是我要的"，这篇文章大概率能帮你找到问题真正所在。它不在代码层，而在你张口说话之前的那层思维。

2. 需求不清的三种典型翻车现场：AI 把"大概意思"执行到了极致

2.1 翻车现场一：用了三个月才发现 AI 建错了核心表结构

这是我印象最深的失败案例。当时要做一个内部订单审核系统，我的原始需求描述是："帮我写一个订单管理系统，支持订单录入和审核。"

这听起来没问题对吧？AI 也确实执行了：建了订单表、用户表，写了录入页面、审核页面。我往里填测试数据，功能都能跑。但三个月后业务方要求加"订单改价"功能时，我发现 AI 用的是"审核通过后直接改写原记录"的逻辑，而不是新建一条"变更记录"。这意味着一旦订单改过价，原始价格就永久消失了，财务对账直接对不上。

根子在需求描述里。我当时说"支持订单录入和审核"，从来没说清楚"订单的价格字段在审核通过后是否锁定""改价应该覆盖原值还是保留历史版本""审核动作和修改动作之间是什么关系"。AI 只能根据最常见业务逻辑来猜——而最常见的猜法就是"把值改了拉倒"。回头看，这根本不是 AI 的错，是我把业务里最核心的一条规则——价格不可追溯、改价需留痕——漏得干干净净。

2.2 翻车现场二：提示词越写越长，代码越改越乱

第二个教训是另一个极端。我后来开始认真写提示词，把想到的所有细节全部堆进去，一段需求写了八百多个字。

"我要一个任务管理模块，任务有优先级、截止时间、负责人。任务状态有未开始、进行中、已完成、已取消。未开始的可以被取消，进行中的不能被取消除非是管理员。已完成的任务要记录完成时间。负责人发送邮件通知。任务可以添加评论。列表要分页..."

AI 确实全都照做了，但实现方式非常糟糕：六个状态散落在一个大表的枚举字段里，状态迁移逻辑全写在页面按钮的 onclick 回调中，没有一处统一的状态机。后来产品说"任务需要支持暂停状态"时，改动波及十几个文件，改完这周又冒出新 bug。

这次的教训是："写得长"不等于"写得清楚"。我给的是一堆零散的"现象描述"，但完全没给"约束条件"和"规则边界"。当时我根本不知道有用户故事和验收标准这套软件工程方法论，更不知道 AI 编程时需要的不是散文，而是精确的行为约束。AI 没有能力从我八百字的小作文里提炼出"状态机"这种抽象设计，它只会逐字逐句地满足我的字面要求。

2.3 翻车现场三：需求随手改，测试全部白做

第三种情况最隐蔽，也最要命。项目中期，产品经理（没错，我们小团队还是有人工的 PM，虽然她只管提需求）在群里随口说了句"订单列表最好能导出 Excel"。我在 Cursor 里随手加了一句需求，AI 立刻给我加了个导出按钮，还贴心地引入了两个第三方库。

一切看起来很顺利，直到我发现：新引入的库和现有项目的 Excel 处理逻辑冲突，单元测试挂了 19 个。更麻烦的是，这个需求本身写得很含糊——"导出 Excel"，客户要的是全部字段还是列表里可见字段？要不要包含金额合计？数据量大的时候要不要异步导出？AI 全部按最简方案实现了。

最惨的不是 AI 实现错了。最惨的是，需求在最后两周改了四遍——导出字段、格式要求、是否加密——每次改动都要重新测。如果一开始吗就写好一份明确的需求说明和验收标准，这些返工周期至少能压缩一半。

2.4 三种翻车背后的共同点：问题全部出在"需求"这一层

把三种情况放一起看，你会看到一个清晰的模式：

我花了很多时间研究 Cursor 的配置、Copilot 的提示词技巧、Windsurf 的规则文件怎么写，最后发现：这些工具层面的优化全部是在"执行层"打转。如果我输入的根本不是一个清晰规则，任何工具、任何模型、再聪明的 agent，都只是在忠实地放大我的混乱。

AI 编程的本质是把"需求规格说明"变成"可执行代码"的快捷键。快捷键再快，按错了命令也不会走到正确的地方。

3. 为什么 AI 对需求的要求比人类更高：输入决定输出的底层逻辑

3.1 人类协作中的"隐性信息补全"机制，AI 完全没有

和人类合作时，需求沟通其实有大量"你不说我也知道"的隐性信息补全。比如你让小张"把订单状态改成已审核"，小张脑子里自动知道：要记录审核人、审核时间、状态变更要过日志、别人只在只读状态时不允许审核。这些不是需求里写的，是很多年软件工程规范沉淀出来的"行业常识"。

AI 确实也是基于海量代码训练出来的，它也有常识。但它的"常识"应该是全行业的平均分布，未必匹配你的特定业务。更关键的是：人类会主动确认，AI 只会被动猜测。同一个模糊需求交给五个不同程序员，五个人都会做出合理假设、问你两句、甚至帮你指出风险；交给 AI，它会安静地选择一个最常见假设，然后写出一坨看起来非常合理的代码。

这就像一个极其听话、但没有任何提问权限的实习生在干活。你让他"倒杯水"，他会真的只倒水，不加茶叶不调温度。他没有恶意，他只是真的不知道。写代码也一样——所有你没说的边界、所有你没有定义的异常、所有你没给出的约束，AI 不是帮你补全了，而是帮你"搁置"了，然后在代码里变成隐式的、随机的决定。更致命的是这个决定可能藏在某个深处，你短期内根本发现不了。

3.2 AI 编程的"需求接口"：自然语言提示词 + 多文件上下文 + 规则文件

需要明确的是，AI 编程的需求输入方式和传统软件工程有不少差别，但两者底层逻辑一致。传统的"需求接口"是需求规格说明书（SRS），有完整的信息架构：功能需求、非功能需求、接口定义、业务规则、验收标准。而 AI 编程的需求接口拆成了三块：

• 自然语言提示词：你要做什么、边界条件是什么、不能怎么做；
• 多文件上下文：AI agent 读取你项目里的现有代码、配置文件、README，作为隐式需求来源；
• 规则文件：Cursor 的.cursor/rules文件、Windsurf 的rules文件、Copilot 的.github/copilot-instructions.md，用来持久化团队的编码规范和业务约束。

这三块组合在一起，构成了 AI 眼中的"需求规格"。但大多数人只用了第一块，而且用的方式是"聊天式"而非"规格式"。

聊天式需求是"帮我加一个导出 Excel 的功能"这种一句带过，AI 的自由度极大。规格式需求是"在订单列表页添加导出按钮，点击后生成包含订单号、金额、状态的 xlsx 文件，金额大于 10000 的订单导成 result_big.xlsx"这种精确行为描述。你会发现，前者像谈需求，后者像写需求规格书——虽然就是几行字，但颗粒度完全不同。

3.3 从"软件工程需求文档"里学到的三句话，比提示词技巧更值钱

我之前对"需求规格说明书"这种词很排斥，觉得是传统软件工程那套重文档、轻代码的东西，早过时了。但被 AI 坑了半年之后，我重新翻开了大学教材，发现三句话价值极高。

第一句：需求要描述"做什么"，而不是"怎么做"。这意味着你的提示词应该聚焦在业务规则、行为约束、输入输出关系，而不是告诉 AI"用 React 写一个函数组件"或者"用 Python 的 pandas 处理"——怎么做的决策应该留给 AI，前提是你在"做什么"层面把规则定死。

第二句：每个需求都要能追溯到验收标准。这条规则解决了我翻车现场三的问题。需求文档就是一个需求条目对应一个可测试的标准。我的需求描述里如果有"订单列表支持导出"，那后面必须跟一句"验收标准：点击导出按钮后下载一个包含所有列表列字段的 xlsx 文件，且文件能在 Excel 中正常打开"。如果写不出验收标准，说明这个需求本身还不够清晰。

第三句：需求变更要有流程。传统软件工程里需求变更要过变更控制委员会（CCB），听起来官僚。但在 AI 编程场景下，它变得非常实用：任何需求需要改动，先更新需求文档/提示词，再让 AI 改代码，而不是直接对着聊天框说"顺便改一下这个"。因为你随口改一句，AI 就会立刻动手，然后你还要花大量时间验证其他功能是否被破坏。没有变更记录，这个回滚和排查过程根本无法进行。

3.4 一个关键认知转折：AI 编程需要的不是提示词，是需求规格化能力

现在很多人还在研究"Magic Prompt"能不能一步生成高质量应用，研究 Cursor 和 Windsurf 谁更智能，研究各种 AI 智能体工具和平台。但站在半年的真实使用时间点上，我认为这些讨论方向都偏了。

AI 编程工具的差异，从绝对效果来说远没有想象中那么大。真正决定输出质量的上限，不是模型，不是工具，是你给它的需求的规格化程度。同一段需求描述，拿给 Cursor 和 Copilot 生成的结果，差距可能不到 15%；但一份规格化的需求和一份聊天式需求，拿给同一个工具生成的结果，差距可能是 10 倍。

这个认知转变把我从工具党变成了方法论党。我开始抛弃"再换一个工具看看"的思路，认认真真研究怎么把脑子里的想法变成 AI 能执行的规则集合。

4. 一套能落地跑的 AI 需求拆解法：从一句话想法到可验收的代码

4.1 第一步：先把"一句话需求"拆成五个维度

我现在的习惯是，拿到任何需求，不管多小，先拆成五个维度写下来。这五个维度是我的核心方法论，直接对标软件工程需求文档里的核心章节，又足够轻量，适合 AI 编程场景：

关键点是"功能边界"那一栏。大多数人写需求只写前两栏，完全不写"不做什么"，导致 AI 自由发挥。而我被坑的几次，几乎都踩在边界不清上——它自己发挥出了我根本不需要的"智能"。

举个实际案例。我曾经需要给内部知识库加一个全文搜索功能。第一版需求描述是"加个搜索，支持关键词匹配，能搜到文章标题和内容"。AI 写了通用的 SQL LIKE 查询，结果数据量一上来就慢。后来我发现这个知识库不到五千篇文章，500MB 的 SQLite 足够，根本不需要上 Elasticsearch。但 AI 不管这些，它只会按"通用最佳实践"来写。

如果我在"功能边界"里明确写上"仅支持 SQLite FTS5 全文检索，不引入独立搜索服务，数据量在万级以内"，AI 的方案会完全不一样。这就是边界信息的价值：它约束了 AI 的自由度，让它在你的约束范围内搜索最优解，而不是全行业最优解。

4.2 第二步：把"业务规则"翻译成 AI 能执行的逻辑约束

业务规则是需求文档里最有技术含量的一部分。不能写"订单要有充分的审核机制"这种虚话，要写"订单状态字段只能为 pending → approved → shipped → delivered，不可跳转，也不可逆；从 approved 到 shipped 必须由仓库角色执行"这种精确逻辑。

翻译成 AI 编程需求时要记住：AI 对自然语言的理解是统计性的，不是逻辑性的。它擅长理解"如果-那么"这种清晰的演绎结构，不擅长理解"尽量""合理""正常"这些模糊副词。所以业务规则的表达，要尽量接近伪代码的逻辑结构。

我总结了一个简单的改写范式：

• 原文："订单被审核后就不能再改了"
• 改写："订单状态字段一旦变为 approved，订单的所有可编辑字段（金额、数量、收货地址）均变为只读；任何写操作返回错误提示；只有状态为 pending 的订单允许编辑"

第一句话 AI 也大概能懂，但"不能改"到底是不能改状态还是不能改字段？"审核后"具体指什么时刻？最后出现了什么错误提示？这些全部跑到 AI 自由发挥区间去了。第二句话则把状态、条件、行为、异常四个要素全部定死，AI 没有自由发挥的空间，生成的代码自然精准。

4.3 第三步：给 AI 一个"输入输出规格说明"而非散文

这一步对应软件工程里的"接口定义"章节。AI 编程场景下最常见的"接口"不是 API 接口，而是三种：函数级输入输出、页面级交互流、数据模型关系。

函数级输入输出的写法很简单。我之前写提示词总是"开发一个函数，计算订单价格"，AI 生成了什么参数、返回什么结构、处理什么异常全靠猜。现在的写法是：

"编写函数 calculateOrderTotal(order)：

• 输入：订单对象，含 items 数组（每项含 quantity, unitPrice, discountRate）、shippingFee 字段
• 输出：一个数字，为商品总价 sum(quantity × unitPrice × (1 - discountRate)) + shippingFee
• 异常：订单为空时返回 0；任何商品缺少 discountRate 时按 0 处理；shippingFee 为负数时抛类型错误"

这种写法的好处不是 AI 第一次就完全写对（虽然确实大概率写对），而是出错时你可以精准定位是哪条规格没有满足。没有规格说明，AI 写错了你也说不清它错在哪，只能模糊地说"不对，重写"。

页面级交互流同样要精确。不要写"用户登录后进入首页看到订单列表"，要写：

"未登录用户访问 /orders 时重定向到 /login；登录成功后返回原先要访问的 /orders 页面；订单列表默认按创建时间倒序，每页 20 条，分页后 URL 带上 ?page=2；页面顶部显示总数和筛选条件。"

这些看着繁琐，但每条都在消除 AI 的猜测空间。写需求的人多用十分钟，AI 执行时就能少重构十次。

4.4 第四步：在 Cursor / Copilot / Windsurf / Trae 里如何组织输入

不同工具有不同的需求输入机制，我也把四家主流产品都摸了一遍，简单对比供参考：

关键的输入组织方式是把"需求描述模板"固化成项目根目录下的一个REQUIREMENTS.md文件。这样每次对话前，我可以让 AI 先读这个文件，"请按照 REQUIREMENTS.md 中的规范实现 X"，它就能利用这个持久化的上下文，而不是每次重新解释一遍项目背景。

4.5 第五步：写完需求后，自己先做一轮"需求走查"

这一步对应软件工程里的"需求评审"。AI 编程场景下，我们不太可能组一个正式评审会，但最少要做三件事：

第一，自己重读一遍需求描述，找到所有的模糊词。"几分钟内""比较快""合适的"这种词统统杀掉，替换成具体数字或者"默认值 X，可配置"。

第二，模拟 AI 的执行路径。假设你是 AI，读完这段需求，你会怎么写表结构？遇到金额计算的边界条件（例如数量为 0）会做什么？有没有可能 AI 实现的方案和你设想完全不同？如果有可能，说明需求里还缺少约束。

第三，做一次"极端场景反问"。我问自己的问题通常是：数据为空时怎么办？并发操作时怎么办？权限不足时报什么错？时间超过 deadline 时怎么处理。这些问题不是为了每个都写进需求，而是为了倒逼自己确认——到底哪些是 AI 可以自己决定的，哪些必须定死。绝不能出现"漏掉了一个关键规则，代码上线两个月后才发现"这种命运由 AI 决定的局面。

5. 复杂项目场景下的需求管理：当需求不再是一页纸能说清的事

5.1 需求规格说明书简化版：一页纸项目管理法

很多人一听到"需求规格说明书"就头大，觉得那是大厂流程里厚达几十页的文档。我做个人项目和小团队项目时，用的是一页纸模板，效果出奇地好。核心就五段：

对于超小型需求，我会把这个模板压缩成三行。比如"F1 导出订单：运营点按钮获得 xlsx 文件，字段含订单号/金额/状态，打开文件内容正确"——这已经足够 AI 执行了。真正要避免的是"做一个导出功能"这种只有一个名词的需求。

5.2 需求追踪与变更管理：AI 编程场景下的轻量方案

我在翻车现场三中说的"需求随手改，测试全白做"，本质上就是缺少变更管理。传统软件工程的 CCB 流程太重，落地到个人开发者，我用的是一套三个文件的轻量方案：

第一个文件是REQUIREMENTS.md（当前完整需求描述）。每个功能条目带编号，AI 实现完后在文件里标记[x] F1 已完成。

第二个文件是CHANGELOG.md（需求变更记录）。任何需求的变化都记录：改了哪条需求、为什么改、影响哪些功能、验收标准如何变化。哪怕只有一句话。AI 编程的特性是每一次代码改动都可以追溯到一句需求描述，所以需求变更记录本质上就是代码变更的索引。

第三个文件是"当前激活需求列表"，用 ChatGPT 或 DeepSeek 的 API 可以做一次自动化梳理：把现有功能和需求描述交给大语言模型，让它找出"代码里有但需求里没有写的功能"（AI 自由发挥的部分）和"需求里有但代码里尚未实现的功能"。这个自动化检查每两周跑一次，能发现大量隐患。

5.3 测试用例与需求的绑定：让验收从口头变成可执行

软件工程里"软件需求规格说明中的用例建模"用 Use Case 把需求和测试连接起来。在 AI 编程里，我用的方法是"需求条目直接映射到测试文件"，一个编号对应一组测试。

具体做法：需求里的每条验收标准，直接作为测试用例的输入。比如 F1 的验收标准是"导出文件包含订单号和金额字段"，那测试里就是断言exportedFile.columns包含这两个字段。AI 生成代码时，我会在提示词里写明"同时生成满足以下验收标准的测试文件"。

这样最直接的好处是：AI 每次改完需求，我可以一键跑测试，通过与否直接告诉我"需求是否真正实现"，而不是我肉眼扫一遍页面觉得"好像可以"。AI 编程最大的风险是"看起来实现了，实际上有一堆边界条件没处理"——测试文件是这个风险的最佳防火墙。

5.4 多需求并存时的优先级管理：给 AI 明确"分层执行"指令

真实项目里不可能一次只做一个需求。我之前经常一次给 AI 列十几个需求，它全部实现，但每个都实现得半吊子——因为我没说优先级和依赖顺序。AI 会从左往右一条一条执行，如果中间某个需求本身有歧义，后面的所有需求都会被这个歧义污染。

现在的做法：把需求列表按 P0/P1/P2 分层，并告诉 AI 必须按编号顺序执行，一个需求验收通过后再开始下一个。同时在需求描述里加上依赖关系说明："F2 依赖 F1 的数据结构，在 F1 完成前不需要实现 F2 的存储逻辑，只需要定义接口和页面原型。"

这本质上就是传统软件工程里的"迭代计划"，只不过执行者是一个 AI agent。给 AI 分层，既避免了并发任务导致的上下文污染，也让每次验收变得干净可控。

6. 从"需求文档"到"AI Agent 协作"：把我现在的工作流完整拆给你看

6.1 一个典型需求的完整流转链路（从想法到代码落地）

最后分享一套我自己现在每天在用的工作流。以最近做的"库存告警通知功能"为例，完整走一遍：

第一步，把原始想法拆成需求五维度，写进REQUIREMENTS.md：

F3 库存告警通知功能

• 业务背景：仓库库存低于安全阈值时需要通知采购员，当前依靠人工盯盘效率低
• 角色流程：库存变动时触发检测 → 低于阈值 → 发送企业微信通知 → 采购员确认后标记"已处理"
• 功能边界：只做库存低于阈值的检测和通知，不做补货单生成、不做采购流程管理
• 业务规则：同一 SKU 在 24 小时内不重复通知；通知接收人为该 SKU 对应的采购员；标记"已处理"后 48 小时内不再触发该 SKU 的通知
• 验收标准：输入一个库存低于阈值的 SKU，能收到通知；收到通知后点击"已处理"，再次触发时不重复通知；24 小时内重复触发时跳过。

第二步，处理与 AI 协作的上下文输入。我打开 Cursor，先让 AI 读取REQUIREMENTS.md，然后把库存变动的相关代码文件用@引用到对话中，补充一句："请基于现有项目的框架，为 F3 编写完整实现，包括数据库迁移、服务层逻辑、企业微信通知接口对接和对应的测试文件。"

第三步，等待 AI 生成后，跑一遍我提前写好的测试脚本。没有测试脚本的需求，视为未完成。测试通过后，我才会做人工 code review。

这个流程跑通了三个月，返工率下降非常明显。尤其是"业务规则"那一栏，只要规则写清楚，AI 生成的一次通过率非常高。凡是返工的，十次里有八次是因为我在"业务规则"里漏了条件。

6.2 AI Agent 在做"需求操作"时经常需要提升的四个地方

前面提到热词里有一个"需求操作需要提升"，我的理解是：AI Agent 做需求实现时，经常在以下几个环节表现不稳定，需要使用者主动"喂"更多信息：

第一，数据模型的建模选择。AI 经常在"新增一张表"和"复用已有表加字段"之间做出错误判断。我现在的对策：在需求描述里明确"数据模型请复用现有 users 表，不要新建用户表"。如果需求本身对数据模型没把握，就先让 AI 生成方案，而不是直接让它写代码。

第二，异常处理策略。AI 写异常处理的常见问题是"吞掉异常"（catch 了不处理）或"过度处理"（每个函数都套 try-catch）。如果需求里没有明确异常策略，AI 的表现完全随机。我通常在需求里加一句"失败时的行为：记录错误日志并返回友好错误信息，业务数据不落库"。

第三，日志和可观测性。AI 默认不写日志，或者只在关键入口写简单的console.log。如果项目依赖日志排查问题，需要在需求里明确"日志级别：INFO 记录入参和出参，ERROR 记录堆栈，敏感字段脱敏"。

第四，性能和容量的预判。AI 喜欢按"通用最佳实践"生成代码，但这种最佳实践往往是为大规模系统准备的（比如引入缓存、消息队列），用到小项目上就是过度设计。我一般在项目根目录的REQUIREMENTS.md里写一段全局性能声明："本项目为内部工具，日活不超过 100 人，数据量在 10 万行以内，优先考虑实现简单性而非扩展性。"这一句话能让 AI 少写大量无用代码。

6.3 大语言模型 API 做"需求梳理"的斜杠用法

除了直接用 AI 编程工具，我发现把"需求梳理"本身交给大模型 API（比如 DeepSeek 的 api）也是一个很高效的做法。这不是让 AI 替我写需求，而是让它帮你发现需求的漏洞。

具体做法：把你写好的需求五维度发给 DeepSeek（或其他模型），加上一句提示词："请扮演资深产品经理，审查这份需求描述，找出所有可能产生歧义的地方。输出格式：每个歧义点对应一个具体问题，我需要针对这个问题修改需求。"

几秒钟后，它会返回十几个问题："F3 的'同一 SKU 在 24 小时内不重复通知'，如果 SKU 从低于阈值恢复后又再次低于阈值，也算同一 24 小时吗？""企业微信通知接口有频控限制吗？超过频控时的降级策略是什么？"这些我根本没有想到的边界问题，一次就被挖了出来。我把这些问题逐条补进需求文档，再给 Cursor 执行。我经常把这称之为"我打草稿、AI 做验收审查、我修订、AI 再实现"的循环，返工率确实降得非常明显。

6.4 给 Cursor / Copilot 场景下的"规则文件"书写样板

最后放一个我常用的.cursor/rules文件精简版，适合中小型项目。你可以根据自己的情况改：

# 项目全局规则 ## 通用 - 本项目为内部工具，优先考虑实现简单性，不做过度设计 - 所有新增字段需要同时在数据库迁移文件和对应 TypeScript 类型中更新 - 所有外部 API 调用必须包含超时和错误日志 ## 数据模型 - 新表必须包含 id（自增主键）、created_at、updated_at 字段 - 不要轻易新增表，优先在现有表上扩展字段 ## 接口实现 - 所有服务层函数必须包含输入校验 - 金额统一使用 decimal 类型，禁止使用 float - 各类枚举值必须定义为常量，禁止散落在代码里 ## 测试 - 每个需求功能必须附带对应测试文件 - 测试使用项目现有的测试框架，不要引入新框架

把这份规则文件丢给项目之后，AI 生成的代码整体质量稳定了一大截。但请注意，规则文件是"全局兜底"的需求约束，具体每个功能的具体规则还是要靠你在每次提示词中写清楚。规则文件解决那些你"不想每次重复说"的常规约束，功能提示词解决那些"这个功能特有"的行为规则，两者缺一不可。

7. 写在最后：把我踩过的坑总结成几句不太中听的大实话

回头看这半年，我的最大收获不是学会了 Cursor 的某个快捷键，也不是掌握了多复杂的提示词技巧，而是老老实实把大学软件工程课里的"需求分析"重新捡了回来。这件事听起来一点都不酷，但它真的解决了我 80% 的返工痛苦。

如果你也在用 AI 编程，我建议你别急着研究下一个新工具，也别在"哪个 AI 编程智能体工具更强"这种问题上多花时间。先试着把你下一个需求写到能够回答下面五个问题：

1. 这个功能给谁用，解决他的什么问题？（业务背景）
2. 操作流程的每一步是什么？（角色流程）
3. 哪些事是这个功能绝对不做的？（功能边界）
4. 数据的变换规则有哪些硬性条件？（业务规则）
5. 我凭什么认为它做完了？（验收标准）

五个问题回答完，你花十分钟写的文字，比之前花一小时写的长篇提示词更值钱。我实测下来，这类需求描述 AI 的一次生成通过率至少翻了一倍。

另一个大的体会是：逐步养成"需求先于代码"的肌肉记忆。这半年我最大的改变是，打开 Cursor 的第一件事不再是在对话框里描述功能，而是打开REQUIREMENTS.md，把需求改清楚。代码只有在上面的需求理清楚之后才算开始。这个习惯刚开始会觉得很麻烦，觉得"多此一举"，但坚持一个月之后你会和我一样发现：写需求的时间，只是换一种方式花在了代码上。它不会增加你的总工作量，它只是把隐性的返工成本显性化了，变成了写文档的时间——而显性化的成本，总是更容易被控制。

最后分享一个我非常私人的判断标准：如果你的需求描述写完之后，你自己读一遍觉得"这个活好像也不是很难嘛"，那大概率说明需求写得够好了。真正清晰的需求会让你觉得实现它很简单——因为复杂度已经被你消化在描述里了。这恰恰说明，AI编程时代，最先卡住你的永远不会是代码，而是你把复杂世界翻译成精确规则的能力。