1. 一个月四个项目我踩的坑比写的代码还多先说结论零基础用 AI 编程一个月做出四个能跑的项目这件事本身不难。难的是第四个项目和第一个项目之间你能否不重复踩同一个坑。我一开始以为 AI 编程的瓶颈是不会写代码做完第一个项目才发现真正的瓶颈是项目纪律——需求怎么拆、上下文怎么给、代码怎么验收、改坏了怎么回退。这四个问题不解决AI 再强也只能帮你生产一堆看起来能跑、实际上不敢改的代码。这篇内容适合两类人看一类是完全没有编程基础、想用 AI 从零开始做点东西的人另一类是有一定基础、但用 AI 写代码时总觉得越写越乱、越改越崩的人。我会把这一个月里四个项目的真实推进过程、每个阶段踩到的具体坑、以及最后我怎么把这些坑固化成一个项目纪律系统的完整思路讲清楚。关键词里的 AI 编程、agent、项目纪律系统会贯穿全文但我不会堆概念只讲我实际怎么操作的。先交代一下背景。我此前没有任何系统的编程训练能看懂简单的 HTML 和 Python但让我从零写一个完整项目基本等于不会。我用的工具是当时主流的 AI 编程助手配合命令行和 Git。四个项目分别是一个本地用的数据处理小工具、一个带界面的信息管理应用、一个自动化脚本集合、一个多步骤的 agent 工作流。规模都不大但每一个都完整走完了从想法到能用的流程。之所以强调项目纪律是因为我第一个项目做完之后回头看发现代码里有大量重复逻辑、命名混乱、没有注释、改一个功能要动五个文件。这不是 AI 写得差是我给它的指令太随意。第二个项目我开始有意识地控制输入情况好转但还是会在改需求的时候翻车。到第三个、第四个我才慢慢摸出一套可复用的流程。这套流程后来被我整理成了一个 agent 项目纪律系统本质上是一组约束规则和检查清单用来保证 AI 产出的代码始终处于可控状态。下面我按四个项目分别踩了什么坑和纪律系统怎么长出来的两条线交叉讲你能看到问题是怎么一步步暴露、又怎么被解决的。2. 第一个项目需求没拆干净AI 就会替你瞎猜2.1 我最初给 AI 的指令有多离谱第一个项目是一个本地数据处理小工具需求很简单读一批 CSV 文件做清洗输出统计结果。我当时给 AI 的第一句话大概是帮我写一个处理 CSV 的 Python 程序要能清洗数据并输出统计。现在回头看这句话几乎把所有关键信息都省略了。CSV 有多少列列名是什么清洗规则是什么统计哪些指标输出成什么格式我一个都没说。AI 的反应很有意思它没有追问而是直接生成了一份通用代码。这份代码能跑但里面的清洗逻辑是它自己猜的——把空值填成 0、把重复行删掉、把字符串列做了 strip。这些操作有些是我要的有些不是。更麻烦的是它把列名硬编码成了column1、column2这种占位符我拿到手还得一个个改。这就是零基础用 AI 编程的第一个大坑你以为你在描述需求其实你只是在给 AI 一个猜谜的起点。AI 不会因为你没说就停下来它会用最常见的默认方案填满所有空白。而这些默认方案往往和你的真实场景差得很远。2.2 需求拆解的颗粒度到底要多细踩完这个坑之后我总结出一个判断标准如果一段需求描述里出现了处理优化统计这类动词而没有说明处理成什么样、优化到什么程度、统计哪些字段那这段描述就是不合格的。合格的描述应该细到输入是什么、输出是什么、中间经过哪几步、每步的判定条件是什么。拿那个 CSV 工具举例后来我重写的需求描述是这样的输入指定目录下的所有.csv文件每个文件第一行是表头清洗步骤一删除所有字段全为空的行清洗步骤二对amount列去掉货币符号后转为浮点数无法转换的记为 0清洗步骤三对date列统一转为YYYY-MM-DD格式输出一个汇总 CSV包含每个文件的文件名、有效行数、amount列总和、date列最早和最晚日期你看同样是清洗并统计拆到这个颗粒度之后AI 生成的代码几乎不需要改。因为它没有猜的空间了。这里的关键不是描述得长而是描述得没有歧义。我后来养成了一个习惯写需求的时候强迫自己把每个动词都翻译成输入-操作-输出的三元组翻译不出来的说明我自己也没想清楚。2.3 为什么 AI 不主动追问以及怎么逼它追问很多人会问AI 为什么不主动问我答案是大多数 AI 编程助手在默认模式下是执行型而不是澄清型。你给它一个模糊指令它倾向于直接产出结果因为这样体验更爽。但爽的代价就是你拿到一堆需要返工的代码。我的做法是主动制造追问环节。在正式让它写代码之前我会加一句在开始写之前先列出你需要我补充的信息以及你打算采用的默认假设。这一句话的效果非常明显。AI 会列出一串问题比如CSV 的编码是 UTF-8 还是 GBK日期格式有哪几种是否需要处理缺失的表头。这些问题里有些我能直接回答有些我原本没想过正好借这个机会想清楚。提示不要指望 AI 一次就懂你。把让它追问变成固定动作比事后返工省的时间多得多。这一步看起来只是多了一轮对话但它把AI 猜错的概率大幅降低了。我第一个项目如果一开始就这么做至少能省下两个晚上的返工时间。3. 第二个项目上下文给太多和给太少都会出事3.1 上下文窗口不是越大越好第二个项目是一个带界面的信息管理应用用了一个轻量级的 Web 框架。这个项目让我踩到了第二个大坑上下文管理。第一个项目代码量小我把整个文件贴给 AI 都没问题。第二个项目文件多了我开始纠结是每次只贴相关文件还是把所有文件都贴进去我一开始的做法是全贴觉得信息越全 AI 越不容易出错。结果适得其反。当我把十几个文件、上千行代码一次性丢给 AI 时它的回答开始变得飘——它会引用一些根本不存在的函数名或者把两个文件里的逻辑混在一起。后来我才明白上下文窗口大不等于 AI 能有效利用所有信息。信息过载时AI 的注意力会被稀释反而更容易抓错重点。3.2 我摸索出的最小必要上下文原则经过几次翻车我总结出一个原则每次让 AI 改代码只给它这次改动直接相关的文件 接口定义 数据结构定义。具体来说要改的那个文件完整给它这个文件依赖的其他模块只给函数签名和返回值说明不给完整实现涉及的数据结构比如数据库表结构、配置格式完整给它项目整体的目录结构用几行文字描述即可这样做的逻辑是AI 需要知道边界在哪里但不需要知道边界内部的所有细节。就像你让一个同事帮你改一个函数你会告诉他这个函数的输入输出、它被谁调用、它调用了谁但你不会把整个代码库打印出来给他看。我实测下来用最小必要上下文之后AI 生成的代码准确率明显提升而且它引用不存在函数的概率大幅下降。这个原则后来被我写进了纪律系统作为一条硬性规则。3.3 上下文里必须包含的隐形信息除了代码本身还有几类信息是我后来发现必须主动提供的否则 AI 一定会踩坑第一类是运行环境。Python 版本、依赖库版本、操作系统这些不说明AI 可能用了一个你环境里根本没有的语法或库。我就遇到过 AI 用了一个新版本才有的写法而我本地是旧版本直接报错。第二类是命名约定。项目里变量用驼峰还是下划线、文件名用什么风格、常量怎么命名这些如果不统一AI 每次生成的风格都不一样代码很快就乱了。我后来会在项目开始时先定一份命名约定每次对话都带上。第三类是错误处理风格。是抛异常还是返回错误码是记录日志还是直接打印这个不说明AI 会按它自己的习惯来导致项目里错误处理方式五花八门。这三类信息看起来琐碎但它们是项目一致性的基础。零基础的人最容易忽略这些因为它们不影响能不能跑只影响好不好维护。而 AI 编程恰恰最怕不好维护因为一旦代码乱了你后续给 AI 的上下文也会跟着乱形成恶性循环。4. 第三个项目改需求比写新代码危险十倍4.1 一个小改动是怎么把项目搞崩的第三个项目是一组自动化脚本。这个项目让我见识到了 AI 编程里最危险的操作在已有代码上改需求。当时我想给一个已经能跑的脚本加一个失败重试功能。我觉得这是个很小的改动就跟 AI 说给这个脚本加上失败重试重试三次。AI 确实加了重试但它顺手优化了其他东西——把原来的同步逻辑改成了异步、把日志格式换了、还改了一个函数的返回值类型。结果就是脚本本身能跑但依赖它输出的另一个脚本挂了。我花了半天才定位到问题因为改动分散在好几个地方我根本没意识到 AI 动了那么多。这件事让我明白一个道理AI 在改代码时默认是全局优化者而不是局部修改者。你让它改 A它可能顺手把 B、C、D 都改进了。这些改进单独看可能都是合理的但组合起来就是灾难。4.2 怎么把 AI 锁在只改这里的范围内我的应对方法是给每次改动加围栏。具体做法是在指令里明确三件事只允许修改哪些文件列出具体文件名其他文件一律不动只允许修改哪些函数列出函数名函数签名不能变不允许做的事比如不要改异步/同步模型不要改日志格式不要改返回值类型这三条写清楚之后AI 的改动范围就基本可控了。我还会加一句如果你认为需要修改范围之外的东西先停下来告诉我不要直接改。这一句很关键它把 AI 从自作主张切换成了先请示。4.3 改动前的快照和改动后的验收光有围栏还不够还得有验收。我后来养成了一个习惯每次让 AI 改代码之前先用 Git 提交一次相当于拍个快照。改完之后用git diff看看到底改了哪些行。这一步能救命——很多时候 AI 说我只改了一个函数但 diff 一看它改了三十行。验收的时候我会重点看三样东西检查项看什么常见问题改动范围diff 里的文件数和行数AI 改了围栏外的文件函数签名参数和返回值有没有变返回值类型被悄悄改了副作用有没有新增全局变量、改配置引入了隐藏依赖这个表格后来成了我纪律系统里的改动验收清单。每次改完代码照着过一遍基本能拦住大部分意外。注意不要相信 AI 说的我只改了这一处。以 diff 为准不以它的描述为准。5. 第四个项目多步骤 agent 工作流暴露的纪律问题5.1 从单次对话到多步骤流程的跨越第四个项目的性质不太一样它是一个多步骤的 agent 工作流先抓取数据再清洗再分析最后生成报告。每一步都是一个独立的 agent 任务前一步的输出是后一步的输入。这个项目让我意识到前面三个项目积累的纪律问题在单次对话里还能靠人盯着一旦变成多步骤自动流程就会集中爆发。最典型的问题是步骤之间的接口不稳定。第一步输出的数据格式第二步假设的是另一种格式第三步又假设了第三种。单次对话时我还能在中间手动调整多步骤流程里这种不一致会直接导致流程中断而且报错信息往往指向最后一步真正的问题在第一步。5.2 步骤之间必须契约先行解决这个问题的办法是契约先行。在写任何一步的实现之前先把步骤之间的数据契约定下来第一步输出什么字段、什么类型、什么格式第二步接收什么、输出什么以此类推。这个契约一旦定下来每一步的实现都必须严格遵守不允许顺手改一下格式。我把这个契约写成一个独立的文档每次让 AI 实现某一步时都把契约里相关的部分贴给它。这样做的效果是每一步的实现都变成了填空——AI 知道输入长什么样、输出要长什么样中间怎么实现是它的事但边界是锁死的。5.3 agent 工作流里的失败处理设计多步骤流程还有一个单次对话不会遇到的问题某一步失败了怎么办单次对话时失败了重新问一次就行。多步骤流程里你得设计失败处理逻辑是重试、是跳过、还是终止整个流程重试几次重试之间要不要等待我一开始没设计这些结果流程跑到一半失败整个状态就乱了只能从头再来。后来我加了三样东西每一步都有明确的成功/失败判定条件失败时记录当前步骤的输入和错误信息方便定位支持从任意一步重新开始而不是必须从头跑这三样东西看起来是工程细节但它们决定了这个 agent 工作流是玩具还是工具。零基础的人做 agent 项目最容易忽略的就是这些因为 demo 阶段一切顺利看不出问题。一旦数据量大了、步骤多了没有失败处理的流程基本不可用。6. 项目纪律系统把踩过的坑变成可执行的规则6.1 纪律系统到底是一套什么东西做完四个项目之后我把前面所有的经验教训整理成了一个项目纪律系统。它不是什么复杂的软件本质上就是一组规则、清单和模板用来约束我和 AI 的协作方式。它的核心目标只有一个让 AI 产出的代码始终处于可理解、可修改、可回退的状态。这套系统分成四个部分需求纪律、上下文纪律、改动纪律、验收纪律。每一部分都对应我前面踩过的一类坑。下面我逐个讲清楚每个部分具体包含什么以及怎么用。6.2 需求纪律把模糊动词翻译成三元组需求纪律的核心是一条规则任何需求描述里不允许出现没有具体判定的动词。处理优化完善这类词必须翻译成输入-操作-输出的三元组。翻译不出来的说明需求本身没想清楚先想清楚再动手。具体操作上我会在项目开始时写一份需求清单每条需求都按这个格式写输入什么数据什么格式操作具体做什么判定条件是什么输出什么数据什么格式这份清单不需要很正式写在文本文件里就行。但它的存在让每次和 AI 对话时我都能直接引用某一条需求而不是临时组织语言。这大大减少了AI 猜错的概率。6.3 上下文纪律最小必要 三类隐形信息上下文纪律包含两条规则。第一条是最小必要上下文每次只给 AI 直接相关的文件、接口定义和数据结构定义不给完整代码库。第二条是三类隐形信息必带运行环境、命名约定、错误处理风格每次对话都要带上。为了执行这两条规则我准备了一个上下文模板每次开新对话时先填这个模板运行环境Python 3.10 / Windows 11 / 依赖库版本见 requirements.txt 命名约定变量下划线、类名驼峰、常量全大写 错误处理统一抛出自定义异常不返回错误码 本次任务相关文件[列出文件名] 本次任务相关接口[列出函数签名] 本次任务相关数据结构[列出字段和类型]这个模板填起来不到一分钟但它能省下大量返工时间。我实测下来用了这个模板之后AI 生成的代码一次通过率从大概三成提升到了七成以上。6.4 改动纪律围栏 快照 验收清单改动纪律是我认为最重要的一部分因为改需求是风险最高的操作。它包含三个动作第一个动作是设围栏。每次让 AI 改代码明确列出允许修改的文件、函数以及不允许做的事。加一句超出范围先请示。第二个动作是拍快照。改之前先 Git 提交改之后用 diff 检查。这一步是硬性的不管改动多小都要做。第三个动作是过验收清单。就是我前面那个表格改动范围、函数签名、副作用。三项都过了才算这次改动完成。这三个动作加起来每次改动大概多花五分钟但它能拦住绝大部分改一个崩三个的情况。我第三个项目如果一开始就这么做那个加个重试把项目搞崩的事故根本不会发生。6.5 验收纪律能跑不等于能用验收纪律的核心观念是能跑不等于能用。AI 生成的代码跑通 demo 很容易但要在真实场景下稳定工作还需要额外检查。我的验收清单包括边界情况空输入、超大输入、格式错误的输入会不会崩失败处理出错时有没有清晰的错误信息能不能定位可回退改动能不能撤销状态能不能恢复一致性新代码的风格和项目其他部分是否一致这四项里前两项是功能性的后两项是维护性的。零基础的人最容易只看前两项忽略后两项。但恰恰是后两项决定了你的项目能不能持续迭代。7. 零基础用 AI 编程我最后留下的几条实操心得7.1 关于工具选择别在选工具上花太多时间我一开始也纠结过用哪个 AI 编程工具看了很多对比。后来发现对于零基础做小项目来说主流工具之间的差距远小于你会不会用的差距。与其花一周选工具不如随便挑一个主流的先用它做完一个项目。工具是在用的过程中熟悉的不是在对比中熟悉的。真正影响效率的不是工具本身而是你有没有一套稳定的协作流程。我前面讲的纪律系统换任何工具都适用。工具会更新流程不会。7.2 关于学习路径先做完整项目再补基础知识零基础的人容易陷入一个误区先把编程基础学完再用 AI 做项目。我的建议反过来先用一个完整的小项目跑通全流程遇到不懂的概念再回头补。因为 AI 编程里你需要的不是会写代码而是会描述需求、会验收结果、会定位问题。这些能力只有在做项目的过程中才能练出来。我第一个项目做完才真正理解了什么是函数、什么是模块、什么是依赖。这些概念如果先学我可能学两周还在看语法先做项目我两天就理解了它们的实际用途。7.3 关于心态把 AI 当同事不当许愿池最后一个心得是关于心态的。我见过很多人用 AI 编程的方式是许愿——说一句模糊的话期待 AI 给出完美结果。这种方式在 demo 阶段能爽到但项目稍微复杂一点就会崩。正确的姿势是把 AI 当一个执行力很强但需要明确指令的同事。你不会跟同事说帮我搞一下那个东西你会说清楚是什么东西、要什么结果、有什么限制。对 AI 也一样。你给的指令越清晰它的产出越可靠。这不是 AI 的能力问题是协作方式的问题。我一个月做四个项目最大的收获不是学会了编程而是学会了怎么把一个模糊的想法拆成 AI 能执行的清晰指令再把它验收成能用的东西。这套能力比任何具体的编程知识都更值钱。项目纪律系统就是这套能力的固化形式它不完美但足够让我在后续的项目里不再重复踩同样的坑。