1. 一个月从零到四我为什么选择用 AI 编程开局先说背景。我此前没有任何编程基础HTML 标签都认不全更别提什么变量作用域、异步回调。但就是在这样的起点上我用一个月时间借助 AI 编程工具做了四个能跑起来、能给别人用的项目。这四个项目分别是一个本地文件批量重命名工具、一个网页数据抓取小脚本、一个命令行记账程序以及一个把前面三个项目串起来的“项目纪律系统”——也就是我最后把它做成了一个 agent 项目纪律系统。你可能会问零基础凭什么一个月做四个答案不是“AI 万能”而是我找到了一套和 AI 协作的节奏。这套节奏的核心不是写代码而是把需求拆成 AI 能理解的颗粒度然后用 agent 的方式去管理整个项目流程。说白了AI 编程工具再强它也需要你告诉它“做什么、做到什么程度、按什么顺序做”。这就是我后来做“项目纪律系统”的原始动机。这篇文章适合谁看如果你是零基础但想用 AI 编程做出真实项目的人或者你已经会用 AI 写代码片段但项目一复杂就乱套的人再或者你对 agent 开发、agent 框架、agent 项目纪律这些概念感兴趣但不知道怎么落地的人那这篇内容就是写给你的。我会把一个月里踩过的坑、总结出的方法、以及最后那个纪律系统的设计思路全部摊开讲。先给一个核心结论AI 编程的上限不取决于 AI 有多强而取决于你给它的约束有多清晰。我做的那个 agent 项目纪律系统本质上就是一套约束机制——它不写代码它管的是“什么时候该写什么代码、写完怎么验证、验证不过怎么回滚”。这个思路贯穿了我四个项目的始终。2. 零基础用 AI 编程的第一个月四个项目是怎么跑起来的2.1 第一个项目本地文件批量重命名工具第一个项目选它原因很简单——我电脑里有一堆下载的图片和文档命名乱七八糟手动改要改到天荒地老。需求足够具体边界足够清晰适合拿来练手。我用的工具是 Cursor当时还不太懂什么 agent 模式就是开一个聊天窗口把需求用中文描述清楚“我要一个 Python 脚本读取指定文件夹下所有 .jpg 文件按修改时间排序重命名为 photo_001.jpg、photo_002.jpg 这种格式保留原始扩展名如果目标文件名已存在就跳过并打印警告。”AI 第一次给我的代码就能跑但有个问题它把排序逻辑写成了按文件名排序而不是按修改时间。我没看出来直接运行结果顺序全乱。这就是零基础用 AI 编程的第一个坑——你看不懂代码就无法判断 AI 给你的东西对不对。后来我学乖了每次让 AI 生成代码后我会追加一句“请逐行解释这段代码在做什么特别是排序和文件操作部分。”通过它的解释我才能对照需求检查逻辑。这个习惯后来变成了我纪律系统里的第一条规则AI 生成的每一段核心逻辑必须附带人类可读的解释。这个项目最终花了大概三个小时包括调试和测试。它教会我的东西需求描述要包含输入、输出、边界条件、异常处理。这四点缺一个AI 就会自由发挥而自由发挥的结果往往不是你想要的。2.2 第二个项目网页数据抓取小脚本第二个项目难度上了一个台阶。我想抓取某个公开数据网站上列出的条目信息整理成 CSV。这里涉及网络请求、HTML 解析、数据清洗、文件写入四个环节。我犯的最大错误是一次性把整个需求丢给 AI。我说“帮我写一个抓取某某网站表格数据的脚本”AI 给了一个用 requests BeautifulSoup 的方案但那个网站的数据是 JavaScript 动态加载的requests 拿到的 HTML 里根本没有表格内容。这个坑让我明白了一件事AI 编程工具不知道你的运行环境、不知道目标网站的技术栈、不知道你本地装了什么库。它只能基于你给的信息做最通用的假设。所以后来我调整了策略——先让 AI 帮我做技术选型分析再让它写代码。我重新提问“我要抓取一个网页上的表格数据但直接请求 HTML 拿不到内容可能是动态加载。请列出三种可能的抓取方案分别说明适用场景和需要的工具。”AI 给出了 Selenium、Playwright、以及分析 XHR 请求直接调 API 三种方案。我选了 Playwright因为它对新手更友好安装配置简单。这个项目花了大概两天其中一天半在解决环境配置和等待元素加载的问题。但收获很大我学会了用 agent 的思路去拆解问题——先侦察、再选型、后实现、最后验证。这个流程后来也被写进了纪律系统。2.3 第三个项目命令行记账程序第三个项目是我主动想练手的因为前两个都是“一次性脚本”没有状态管理没有持久化没有交互循环。我想做一个能持续用的东西。命令行记账程序的需求支持添加收入/支出、查看列表、按月份统计、数据存本地 JSON 文件。这个项目让我第一次接触到“项目结构”的概念——之前所有代码都写在一个文件里但这个项目如果全塞一个文件改起来会非常痛苦。我让 AI 帮我设计文件结构它给了这样的方案ledger/ ├── main.py # 入口处理命令行参数 ├── storage.py # 数据读写 ├── models.py # 数据模型定义 ├── reports.py # 统计报表 └── data/ └── records.json # 数据文件这个结构对科班出身的人来说很基础但对我这种零基础的人来说是全新的认知。我意识到AI 编程不只是让 AI 写代码还包括让 AI 帮你做架构决策。而架构决策的质量直接决定了项目后续好不好改、好不好扩展。这个项目踩的坑是数据格式的版本兼容。我一开始让 AI 用列表存记录后来想改成字典按 ID 索引结果旧数据读不出来。AI 没有主动提醒我数据迁移的问题因为我没有告诉它“已经有旧数据了”。这又是一个教训上下文要完整AI 不会读心术。2.4 第四个项目把踩过的坑做成 agent 项目纪律系统做完前三个项目我回头整理了一下发现所有坑可以归为几类需求描述不完整、技术选型没做调研、代码逻辑没验证、数据结构变更没考虑兼容、项目结构混乱导致改不动。于是我萌生了一个想法能不能做一个系统在每次开始新项目或新功能时自动提醒我检查这些点这就是“agent 项目纪律系统”的雏形。它的核心不是写代码而是定义一套检查规则和流程约束。我把它设计成一个 agent每次我启动一个新任务时它会按顺序问我几个问题需求边界清楚吗技术方案调研过吗数据结构会变吗验证方式是什么如果任何一个问题我没回答清楚它就不让我进入下一步。这个系统本身也是用 AI 编程做的大概花了四天。它让我第一次体会到 agent 开发的本质——agent 不是更聪明的代码生成器而是一个有状态、有规则、有执行流程的协作实体。3. agent 项目纪律系统的核心设计规则、状态与执行流3.1 为什么是“纪律系统”而不是“代码生成器”市面上大多数 AI 编程工具都在强调“生成代码有多快、多准”。但我实际用下来发现零基础的人最缺的不是代码生成速度而是项目推进的纪律。什么叫纪律就是该调研的时候不跳过、该验证的时候不偷懒、该回滚的时候不硬撑。我见过太多人包括我自己用 AI 编程时的典型翻车路径让 AI 写一个功能代码看起来没问题直接运行报错把报错丢给 AIAI 改一版再运行还报错来回几次之后代码已经面目全非自己也不知道改了什么。这就是没有纪律的后果。所以我把系统定位成“纪律系统”它的第一职责不是帮你写代码而是在你写代码之前、之中、之后强制你走完必要的检查点。这听起来很笨但实测下来它帮我节省的时间远超它消耗的时间。3.2 系统的三个核心模块规则引擎、状态记录、执行编排这个纪律系统我拆成了三个模块每个模块对应一类纪律约束。规则引擎负责定义“什么情况下必须做什么”。比如规则一任何新功能开始前必须用自然语言写出输入、输出、边界条件、异常处理四要素。规则二任何涉及数据格式变更的修改必须同时提供迁移方案。规则三任何 AI 生成的代码块必须附带逐行解释。这些规则不是硬编码在代码里的而是存在一个 YAML 文件里方便我随时增删改。状态记录负责跟踪当前项目进行到哪一步、哪些检查点已经通过、哪些还没。我用一个简单的 JSON 文件存状态每次启动 agent 时读取每次完成一个检查点后更新。这个设计很土但非常有效——它让我不会在项目复杂之后忘记自己有没有做某一步。执行编排负责按顺序调用检查点并在检查不通过时阻止进入下一步。比如我试图在“需求四要素”没写全的情况下进入“技术选型”agent 会直接拒绝并告诉我缺了哪一项。这个“拒绝执行”的能力是纪律系统和普通代码生成器最大的区别。3.3 agent 框架选型为什么我没有用重型方案在选型阶段我调研过几个 agent 框架包括 LangChain、AutoGen、以及一些轻量的 agent 编排库。但最后我选择了一个极简的方案用 Python 写一个主循环用 YAML 存规则用 JSON 存状态用命令行交互。原因有三个。第一我的项目规模很小引入重型框架只会增加调试成本。第二我需要完全理解系统的每一行逻辑因为我是零基础如果框架内部出问题我根本排查不了。第三也是最重要的一点——纪律系统的核心价值在于规则本身而不在于执行规则的引擎有多先进。一个简单的 while 循环加 if 判断足够实现我需要的所有约束。这个选择后来被证明是对的。我见过有人用复杂框架搭 agent结果光调试框架就花了一周规则本身反而没时间打磨。工具是拿来用的不是拿来供的。3.4 规则文件的设计让纪律可配置、可演进规则文件我用 YAML 写结构大概是这样rules: - id: req_001 name: 需求四要素检查 trigger: before_new_feature check: | 必须明确写出 1. 输入是什么 2. 输出是什么 3. 边界条件空值、极值、并发 4. 异常处理出错时怎么办 block_on_fail: true - id: tech_001 name: 技术选型调研 trigger: before_implementation check: | 必须列出至少两种可选方案 并说明选择当前方案的理由。 block_on_fail: true这个设计的好处是我可以在不碰代码的情况下调整纪律。比如我发现某个检查点太严了导致项目推不动我就把block_on_fail改成false让它变成警告而不是阻断。纪律是为人服务的不是人为纪律服务。4. 实操过程从零搭建纪律系统的完整步骤4.1 环境准备与工具选型我用的环境很简单Python 3.10、一个代码编辑器、以及 AI 编程工具 Cursor。没有用虚拟环境因为项目依赖极少只有 PyYAML 一个第三方库。这里有个小建议零基础阶段依赖越少越好。每多一个依赖就多一个可能出问题的地方而排查依赖问题对新手来说非常痛苦。AI 编程工具的选择上我试过几个最后固定在 Cursor。原因不是它生成代码最准而是它的 agent 模式支持多文件编辑和上下文引用这对做项目级开发很重要。如果你只是写单文件脚本任何 AI 编程工具都够用但一旦项目超过三个文件上下文管理能力就成了关键。4.2 第一步定义状态数据结构我先让 AI 帮我设计状态文件的结构。我告诉它“我要跟踪一个项目的多个检查点每个检查点有名称、状态未开始/进行中/已通过/已跳过、时间戳、备注。请给我一个 JSON 结构示例。”AI 给了这样的结构{ project_name: ledger, current_phase: implementation, checkpoints: [ { id: req_001, name: 需求四要素检查, status: passed, timestamp: 2025-01-15T10:30:00, notes: 输入输出已明确边界条件补充了空文件情况 } ] }这个结构我后来改了一处把checkpoints从列表改成了字典用 id 做 key。原因是列表查找要遍历字典直接取虽然性能差异可以忽略但代码写起来更清爽。这个改动很小但它体现了纪律系统的一个原则——数据结构要为查询和更新服务而不是为存储服务。4.3 第二步实现规则加载与检查逻辑规则加载的逻辑很直接读 YAML 文件解析成 Python 字典然后根据 trigger 字段决定什么时候调用哪个规则。检查逻辑我设计成两种模式自动检查和人工确认。自动检查用于可以程序化判断的规则比如“状态文件是否存在”“上一步是否已通过”。人工确认用于需要我判断的规则比如“需求四要素是否写全”。人工确认的实现方式是agent 把检查项打印出来我输入 yes 或 no它根据我的输入决定是否放行。这里有个细节值得说人工确认的规则agent 必须把检查项拆得足够细。一开始我把“需求四要素”作为一个整体让我确认我经常随手就 yes 了。后来我改成四个独立问题逐个问我的确认质量明显提高。人是有惰性的纪律系统要做的不是相信人的自觉而是通过设计减少人偷懒的空间。4.4 第三步编排执行流程与阻断机制执行流程我用了一个简单的状态机。每个阶段有明确的入口条件和出口条件只有出口条件满足才能进入下一阶段。比如“需求阶段”的出口条件是 req_001 通过“技术选型阶段”的出口条件是 tech_001 通过。阻断机制的实现方式是在阶段切换的函数里加一个检查如果前置检查点未通过就打印缺失项并返回当前阶段不执行切换。这个逻辑用伪代码表示就是def advance_phase(current, target): if not all_checkpoints_passed(current): print(以下检查点未通过) for cp in get_unpassed(current): print(f - {cp.name}) return current return target这段代码简单到不能再简单但它就是纪律系统的核心。复杂的事情简单做简单的事情重复做重复的事情认真做——这句话用在 agent 项目纪律上特别合适。4.5 第四步接入 AI 编程工具形成闭环最后一步是把纪律系统和 AI 编程工具串起来。我的做法是在 Cursor 里开两个窗口一个窗口跑纪律系统的命令行一个窗口写代码。每次开始新功能前先在纪律系统里走完检查点拿到“放行”信号后再切到代码窗口让 AI 生成代码。这个流程听起来很繁琐但实测下来它帮我避免的返工时间远超它消耗的时间。我统计过在做第三个项目时因为纪律系统的存在我少走了至少三次“写完发现方向错了”的弯路。每次弯路按两小时算就是六个小时。而纪律系统本身的操作时间每个功能平均不到十分钟。5. 踩坑实录零基础用 AI 编程最常见的六个问题5.1 问题一AI 生成的代码能跑但逻辑不对这是最高频的问题。AI 生成的代码语法正确、能运行、不报错但业务逻辑和你的需求有偏差。比如我让 AI 写一个“按修改时间排序”的功能它写成了按文件名排序。代码能跑结果全错。排查思路不要只看代码能不能跑要看代码的输出是否符合预期。具体做法是在让 AI 生成代码时同时要求它生成测试用例。测试用例要覆盖正常情况、边界情况、异常情况。如果 AI 生成的测试用例本身就不对那说明你对需求的理解和 AI 对需求的理解存在偏差需要重新对齐。避坑技巧让 AI 在生成代码后用一句话总结这段代码做了什么。如果它的总结和你的需求不一致立刻纠正。这个习惯我坚持了一个月帮我省下了大量调试时间。5.2 问题二上下文丢失导致 AI 反复犯同一个错AI 编程工具的记忆是有限的。当你和它对话轮次多了之后它可能会忘记前面已经确认过的约束。比如我已经告诉它“数据文件路径是 data/records.json”过了十轮对话后它又写成了 records.json。排查思路每次 AI 生成的代码涉及之前确认过的约束时主动检查是否符合。如果不符合不要直接让它改而是把约束重新贴一遍再让它改。避坑技巧把关键约束写在一个单独的文件里每次让 AI 生成代码前先把约束文件的内容贴给它。这个做法后来被我固化成了纪律系统的一条规则任何代码生成请求必须附带约束文件内容。5.3 问题三环境配置问题被误判为代码问题零基础的人最容易在这里卡住。AI 生成的代码没问题但你本地没装对应的库或者 Python 版本不对或者路径分隔符在 Windows 和 Mac 上不一样。报错信息看起来像代码错误实际上是环境问题。排查思路看到报错先别急着改代码先看报错类型。如果是ModuleNotFoundError那是缺库如果是SyntaxError那可能是 Python 版本问题如果是FileNotFoundError那可能是路径问题。避坑技巧在项目开始时让 AI 列出所有依赖和运行环境要求。然后逐项检查本地是否满足。这个步骤花不了五分钟但能省下大量排查时间。5.4 问题四项目结构混乱导致改不动前两个项目我都是单文件第三个项目文件多了之后我发现自己经常找不到某个函数在哪个文件里。AI 也不会主动提醒你“这个函数应该放在 models.py 而不是 main.py”。排查思路当你发现改一个功能需要同时打开三个以上文件时说明项目结构需要调整了。避坑技巧在项目开始时就让 AI 设计文件结构并且在后续每次新增功能时先问 AI“这个功能应该放在哪个文件里”。不要自己猜让 AI 基于当前项目结构给建议。5.5 问题五数据格式变更没有迁移方案这个问题我在记账程序里踩过。我把数据从列表改成字典旧数据读不出来程序直接崩溃。AI 没有主动提醒我因为我没有告诉它“已经有旧数据了”。排查思路任何涉及数据结构变更的修改都要问自己旧数据怎么办避坑技巧在纪律系统里加一条规则任何数据格式变更必须同时提供迁移脚本或兼容读取逻辑。这条规则后来帮我避免了好几次数据丢失。5.6 问题六过度依赖 AI 导致自己不理解代码这是最隐蔽的问题。代码能跑项目能推进但你越来越看不懂自己的项目。一旦 AI 生成的代码出问题你完全不知道从哪下手。排查思路定期做“代码自检”——随机挑一个函数尝试用自己的话解释它在做什么。如果解释不出来说明你对这块代码的理解已经脱节了。避坑技巧每完成一个功能让 AI 用最通俗的语言解释这个功能的核心逻辑然后你自己复述一遍。这个做法很笨但它是零基础的人保持对项目掌控感的唯一方式。6. 常见问题速查表与独家避坑心得6.1 问题速查表问题现象可能原因排查动作预防措施代码能跑但结果不对逻辑理解偏差检查输出是否符合预期要求 AI 生成测试用例AI 反复犯同一个错上下文丢失重新贴约束再让它改维护约束文件每次附带报错但代码看起来没问题环境配置问题看报错类型检查依赖和路径项目开始时列依赖清单改一个功能要开很多文件项目结构混乱重新审视文件划分让 AI 设计结构并持续维护旧数据读不出来数据格式变更无迁移检查数据结构变更历史变更必须附带迁移方案越来越看不懂自己的代码过度依赖 AI随机抽函数做自检每完成功能做通俗解释复述6.2 独家避坑心得纪律比聪明更重要我用一个月做四个项目的经历告诉我零基础用 AI 编程最大的敌人不是技术难度而是没有纪律。技术难度可以靠 AI 补但纪律只能靠自己建立。我见过太多人一开始热情满满让 AI 写了一大堆代码结果项目越做越乱最后弃坑。弃坑的原因往往不是某个技术问题解决不了而是整个项目失去了秩序。纪律系统的价值就在于此。它不帮你写代码它帮你维持秩序。它让你在每次想跳过检查点的时候多问自己一句我真的可以跳过吗大多数时候答案是不可以。6.3 独家避坑心得规则要少而精不要多而杂我一开始设计了十几条规则结果每次启动新功能都要走一遍烦不胜烦最后我自己开始绕过规则。这违背了纪律系统的初衷。后来我砍到五条核心规则需求四要素、技术选型调研、代码解释、数据迁移方案、功能自检。这五条覆盖了百分之九十的翻车场景而且执行起来不累。规则太多等于没有规则因为人会全部忽略。这个道理和写代码一样约束太多代码就失去了灵活性。6.4 独家避坑心得agent 的记忆需要主动维护agent 的记忆不是自动的。你不告诉它它就不知道。所以我在纪律系统里加了一个“上下文维护”的步骤每次开始新功能前先把当前项目的关键信息文件结构、数据格式、已确认的约束整理成一段文字贴给 agent。这个动作花两分钟但能让后续所有对话的质量提升一个档次。6.5 独家避坑心得验证要独立于生成AI 生成代码AI 验证代码这是不靠谱的。因为 AI 验证时用的逻辑和生成时是同一套它很难发现自己生成时的盲区。所以我的做法是生成用 AI验证用测试用例测试用例由我根据需求手动设计。虽然我设计的测试用例可能不全面但至少它是独立的能发现 AI 自己发现不了的问题。7. 从四个项目到一套方法我对 AI 编程的理解变化做完四个项目我对 AI 编程的理解发生了三次变化。第一次变化是刚开始的时候我以为 AI 编程就是“我说需求AI 写代码”。这个阶段我踩了很多坑因为我把 AI 当成了许愿机而许愿机是不存在的。第二次变化是在做第二个项目的时候我意识到 AI 编程是“我拆问题AI 填细节”。这个阶段我开始做技术选型调研、开始拆解需求、开始设计数据结构。项目成功率明显提高。第三次变化是在做纪律系统的时候我发现 AI 编程其实是“我定规则AI 在规则内执行”。这个阶段我不再依赖 AI 的自觉性而是用规则约束它的行为同时也约束我自己的行为。项目从“能跑”变成了“可控”。这个认知变化过程我觉得对零基础的人特别有参考价值。你不需要一开始就达到第三个阶段但你要知道第三个阶段存在。知道存在你就有方向。8. 后续可以怎么扩展这套纪律系统这套系统目前还很粗糙但它的扩展方向很清晰。我列几个我打算后续尝试的方向。第一个方向是规则模板化。不同类型的项目脚本类、Web 类、数据处理类需要不同的纪律规则。我可以做几套规则模板启动新项目时根据项目类型自动加载对应的模板。第二个方向是检查点自动化。目前很多检查点需要我手动确认后续可以尝试用 AI 自动检查。比如“需求四要素是否写全”可以让 AI 读我的需求描述自动判断四个要素是否都有。当然自动检查的结果需要我复核但至少能减少我的操作负担。第三个方向是与版本控制集成。每次检查点通过后自动打一个标签或提交一次。这样项目历史就和纪律执行历史对应起来了回溯的时候非常方便。第四个方向是多 agent 协作。目前纪律系统是一个 agent 在跑后续可以拆成多个 agent一个管需求、一个管技术、一个管验证。每个 agent 专注自己的领域通过消息传递协作。这个方向复杂度高但想象空间大。9. 给零基础想用 AI 编程的人的最后几句实话如果你看到这里说明你对 AI 编程是真的感兴趣。那我给你几句实话不绕弯子。第一AI 编程能让你做出东西但不能让你变成程序员。你做出四个项目不代表你掌握了编程。你掌握的是和 AI 协作的方法。这两件事不一样不要混淆。第二纪律系统不是万能的但没有纪律是万万不能的。我做的那个纪律系统本质上是我把自己踩过的坑固化成了规则。你也可以做而且你应该做。因为每个人踩的坑不一样只有你自己做的纪律系统才最适合你。第三不要追求一次做对要追求每次都有记录。我四个项目里没有一个是一次做对的。但每个项目我都记录了踩坑过程和解决方法这些记录后来变成了纪律系统的规则来源。记录比正确更重要。第四工具会变方法不会。今天你用 Cursor明天可能用别的。但“拆需求、做调研、定规则、勤验证”这套方法换什么工具都适用。把精力花在方法上不要花在追新工具上。第五也是最后一句开始做比什么都重要。我见过太多人一直在选工具、看教程、比较方案但就是不动手。你不需要准备好所有东西再开始你只需要开始然后在做的过程中补齐。我第一个项目开始的时候连 Python 都没装。装 Python 花了十分钟然后就开始写了。就这么简单。