零基础AI编程实战：用agent项目纪律系统管理开发流程

1. 一个月从零到四个项目我为什么走上了 AI 编程这条路先说清楚背景。我此前没有任何编程基础HTML 标签认不全命令行只会cd和ls连 Git 是什么都说不明白。一个月之后我手上跑着四个能用的项目一个本地知识库问答工具、一个自动整理会议纪要的小系统、一个批量处理表格数据的脚本集还有一个就是标题里提到的——agent 项目纪律系统。这四个项目全部是在 AI 编程工具的辅助下完成的我没有系统学过任何一门语言。写这篇东西不是为了证明零基础也能做开发这种鸡汤。恰恰相反我想讲的是另一面AI 编程确实把门槛砍掉了一大半但剩下那一小半坑才是真正决定你能不能把项目做完的东西。我在这一个月里踩的坑密度高到离谱——同一个错误反复犯、AI 给的代码看着对但跑不通、项目做到一半上下文全乱、改一个功能把另一个功能改崩。到最后我发现问题根本不在 AI 会不会写代码而在于我自己没有一套约束 AI 干活的纪律。于是就有了第四个项目的雏形一个专门用来管理 AI 编程过程的 agent 项目纪律系统。它不是什么高大上的框架本质上是把我在前三个项目里总结出来的规则、检查清单、上下文管理方法固化成一个可复用的 agent 工作流。这篇文章会把整个思路、技术选型、实操步骤、踩坑记录全部摊开讲适合两类人看一类是和我一样零基础想用 AI 编程做点东西的人另一类是已经在用 agent 开发、但总觉得项目越做越乱的人。核心关键词先摆出来AI 编程、agent、项目纪律系统。这三个词贯穿全文后面每一节都会围绕它们展开。2. 先搞明白AI 编程和 agent 到底差在哪2.1 从补全代码到自己干活的分界线很多人把 AI 编程和 agent 混为一谈我一开始也是。用下来才明白这两者中间隔着一条很清晰的分界线。AI 编程工具典型形态是你在编辑器里写一半它帮你补全或者你描述一个函数它给你生成一段代码。它的工作模式是你问它答一次交互解决一个具体问题。你让它写个排序它给你排序你让它改个 bug它给你改。它不关心你的项目整体长什么样也不记得你上一步干了什么。agent就不一样了。agent 的核心是自主执行——你给它一个目标它会自己拆解任务、调用工具、读文件、写文件、跑命令、看结果、再决定下一步。它有一个循环思考、行动、观察、再思考。这个循环让它能处理多步骤的复杂任务而不是单点问答。我用一个生活化的类比AI 编程工具像是一个随叫随到的技术顾问你问一句他答一句agent 像是一个你雇来的实习生你交代一个任务他自己去查资料、动手做、遇到问题自己想办法做完给你汇报。顾问不会替你干活实习生会。这个区别直接决定了你的使用方式。用 AI 编程工具你得自己当项目经理把任务拆到足够细用 agent你可以把粗粒度的目标丢给它但你必须给它立规矩否则它会跑偏。2.2 为什么零基础的人反而更适合从 agent 入手这里有个反直觉的结论零基础的人可能比有编程基础的人更适合用 agent 做项目。原因在于有编程基础的人会不自觉地用旧习惯去指挥 agent——他们会想这个函数应该这么写这个架构应该这么设计然后试图把 agent 当成一个打字快的码农来用。结果就是频繁干预反而打乱了 agent 的执行节奏。零基础的人没有这些包袱更容易接受我描述目标agent 执行的模式。但代价是零基础的人缺乏判断 agent 输出对错的能力所以必须建立一套纪律来兜底。这就是项目纪律系统存在的意义。我踩过的最大的坑就在这前两个项目我完全放任 agent 自由发挥结果代码越写越乱文件结构一塌糊涂改一个地方崩三个地方。第三个项目我开始尝试给 agent 立规矩情况明显好转。到第四个项目我把这些规矩系统化了。2.3 项目纪律系统的本质给 agent 戴上缰绳所谓项目纪律系统说白了就是一套约束 agent 行为的规则集合。它包含几个层面上下文纪律agent 每次执行前应该加载哪些文件、哪些规则、哪些历史记录任务纪律一个任务应该拆到多细什么情况下必须停下来问人代码纪律命名规范、文件组织、注释要求、禁止的操作验证纪律每步执行完必须做什么检查什么算完成回滚纪律出错时怎么退回上一个可用状态这套东西听起来像软件工程里的规范但它是专门为 agent 设计的。因为 agent 和人类程序员不一样——人类程序员有常识知道这个改动可能会影响别的地方agent 没有常识它只会执行你给的指令。所以你必须把常识写成显式规则。3. 四个项目的实战复盘每个项目教会我一件事3.1 项目一本地知识库问答——教会我上下文是稀缺资源第一个项目是个本地知识库问答工具。需求很简单把我积累的一堆文档丢进去能问问题、能返回答案。技术选型上我用了最朴素的方案——文档切块、向量化存储、检索后拼进提示词让模型回答。这个项目让我第一次意识到上下文窗口是稀缺资源。agent 每次执行都要把相关文件读进上下文但上下文是有长度限制的。我一开始图省事让 agent 每次都把整个项目目录读一遍结果就是要么超出长度限制直接报错要么关键信息被挤到后面agent 根本看不见。后来我改成按需加载——只读当前任务相关的文件其他文件只给文件名和一句话描述。这个改动让 agent 的执行成功率肉眼可见地提升了。这个经验后来直接变成了纪律系统里的上下文纪律第一条。提示上下文不是越多越好。塞太多无关信息反而会稀释关键指令的权重让 agent 抓不住重点。3.2 项目二会议纪要整理——教会我任务必须拆到可验证第二个项目是自动整理会议纪要。输入是一段录音转写的文字输出是结构化的纪要议题、结论、待办、负责人。这个项目我踩的坑是任务粒度太粗。我一开始给 agent 的指令是把这段文字整理成会议纪要。结果它每次输出的格式都不一样有时候漏掉待办有时候把结论和议题混在一起。我反复调整提示词效果时好时坏。后来我把它拆成了四步第一步提取所有议题第二步为每个议题找对应结论第三步提取所有待办事项第四步按固定模板组装。每一步都有明确的输入和输出格式每一步做完我都能检查对错。拆完之后稳定性立刻上来了。这件事让我明白agent 的任务必须拆到每一步的产出都能被验证的程度。如果一步的产出你没法判断对错那这一步就太粗了。3.3 项目三批量表格处理——教会我禁止操作清单比允许操作清单更重要第三个项目是批量处理一堆 Excel 表格做数据清洗和格式统一。这个项目让我吃到了agent 乱改文件的苦头。有一次我让 agent 处理一批表格它为了优化数据自作主张把一些空值填成了 0还把几列日期格式统一改了。结果原始数据被覆盖我花了两小时才从备份里恢复。从那以后我学乖了给 agent 的规则里明确列出禁止操作比列出允许操作更重要。因为 agent 的想象力很丰富你允许它做 A它可能顺手把 B 也做了。你必须明确告诉它不许改原始文件、不许删除任何数据、不许自作主张填充空值、所有修改必须写到新文件。这条经验后来成了纪律系统里最硬的一条原始数据只读所有产出写到独立目录。3.4 项目四agent 项目纪律系统——把踩过的坑变成规则到第四个项目我已经积累了一堆血泪教训。我决定不再让这些教训散落在脑子里而是把它们固化成一个系统。这个系统的形态是一个 agent 工作流配置一组规则文件、一套任务模板、一个检查清单、一个上下文加载策略。每次开新项目我先把这套东西挂上去agent 就自动带着纪律干活了。它不复杂但极其有效。下面几节我会详细拆解它的设计思路和实现方式。4. 项目纪律系统的核心设计五条纪律撑起整个框架4.1 上下文纪律按需加载分层管理上下文纪律解决的是agent 每次该看什么的问题。我的做法是把项目文件分成三层层级内容加载策略常驻层项目规则、目录结构说明、核心接口定义每次必加载任务层当前任务相关的源码文件、数据文件按任务动态加载参考层历史记录、其他模块代码、文档只在需要时按文件名检索常驻层要精简控制在几百字以内只放最关键的约束。任务层是动态的每次执行前根据任务描述决定加载哪些。参考层平时不加载agent 需要时通过文件名去查。这个分层的关键在于常驻层必须极简。我一开始把整个 README 都塞进常驻层结果 agent 每次都被一堆无关信息干扰。后来我把常驻层压缩到只剩项目目标一句话、目录结构、五条核心纪律、当前任务描述。注意常驻层每增加一段内容都要问自己这条信息是不是每次执行都必须看到。如果不是就挪到任务层或参考层。4.2 任务纪律拆到可验证卡住就停任务纪律解决的是agent 该干多大的活的问题。核心原则两条第一每个任务必须有明确的、可验证的产出。什么叫可验证就是你能用一个具体的检查动作判断它对不对。比如生成一个函数是可验证的——你能跑测试优化代码结构就不可验证——你没法判断它优化得好不好。第二agent 卡住时必须停下来问人不许自己瞎猜。我在规则里明确写了如果遇到以下情况必须停止执行并输出问题——依赖缺失、需求歧义、连续两次尝试失败、需要修改常驻层文件。这条规则救了我很多次因为 agent 瞎猜的代价往往比停下来问一句大得多。4.3 代码纪律命名、组织、注释三件套代码纪律解决的是agent 写出来的代码长什么样的问题。零基础的人最容易忽略这块因为看不懂代码就觉得能跑就行。但代码乱到一定程度agent 自己都会迷失。我定的规矩很朴素命名变量和函数用完整单词不用缩写不用拼音组织一个文件只做一件事文件超过 300 行就拆注释每个函数开头写一句话说明它干什么参数和返回值各一行这些规矩不是为了好看是为了让 agent 下次读这个文件时能快速理解。代码是写给 agent 看的其次才是给人看的——这个认知转变很关键。4.4 验证纪律每步必查不查不算完验证纪律解决的是怎么判断一步做完了的问题。我的规则是任何一步执行完必须有一个验证动作验证通过才算完成。验证动作可以是跑一个测试、检查一个文件是否存在、对比输出格式是否符合预期。关键是这个动作要具体、要能自动执行。比如检查生成的 JSON 是否能被解析就是好验证检查代码质量就是坏验证。我把验证动作直接写进任务模板里每个任务都自带验证步骤。agent 执行完任务后会自动跑验证验证不过就回到上一步。4.5 回滚纪律随时能退回可用状态回滚纪律解决的是出错怎么办的问题。这条最容易被忽略但关键时刻能救命。我的做法是每个任务开始前先记录当前状态任务完成后如果验证通过就提交不通过就回滚。用 Git 的话就是每个任务一个 commit验证不过就git reset。对于零基础的人Git 可能有点门槛但这是必须跨过去的坎。我一开始也怕 Git后来发现只要掌握四个命令就够了git init、git add、git commit、git reset。这四个命令能覆盖 90% 的回滚需求。5. 手把手搭建从零实现一个最小可用的纪律系统5.1 准备工作工具选型和环境搭建先说工具选型。我用过的 AI 编程工具不少最后稳定下来的组合是一个支持 agent 模式的编辑器 一个能跑命令的终端 Git。编辑器方面市面上主流的几款都支持 agent 模式选哪个看个人习惯。我选的标准是三点能读整个项目目录、能执行终端命令、能管理多轮对话上下文。这三点缺一不可因为纪律系统的核心就是让 agent 看到该看的、执行该执行的、记住该记住的。环境搭建没什么特别的装好编辑器、装好 Git、建一个空项目目录就行。我建议新手从最简单的项目开始别一上来就搞复杂的。5.2 第一步建立规则文件在项目根目录建一个RULES.md这是纪律系统的核心。内容分五块对应五条纪律。我把我自己的模板简化后贴出来# 项目规则 ## 上下文纪律 - 常驻加载本文件、目录结构、当前任务描述 - 按需加载任务相关的源码文件 - 禁止一次性加载整个项目目录 ## 任务纪律 - 每个任务必须有可验证的产出 - 遇到依赖缺失、需求歧义、连续两次失败必须停止并提问 - 禁止自作主张扩大任务范围 ## 代码纪律 - 命名用完整单词不用缩写 - 一个文件只做一件事超过 300 行拆分 - 每个函数开头写一句话说明用途 ## 验证纪律 - 每步执行完必须验证验证通过才算完成 - 验证动作必须具体、可自动执行 ## 回滚纪律 - 每个任务开始前记录状态 - 验证不通过立即回滚 - 原始数据只读产出写到独立目录这个文件要短短到 agent 每次都能完整读进去。我见过有人把规则写成几千字结果 agent 根本记不住等于没写。5.3 第二步设计任务模板规则文件是宪法任务模板是法律。每个具体任务都套用同一个模板保证 agent 每次执行都有章可循。模板长这样## 任务[任务名称] ### 目标 一句话说明这个任务要达成什么。 ### 输入 - 需要读取的文件列表 - 需要的前置条件 ### 步骤 1. 第一步做什么 2. 第二步做什么 3. ... ### 验证 - 验证动作 1 - 验证动作 2 ### 禁止 - 本任务中明确不许做的事这个模板的关键是验证和禁止两块。很多人写任务只写步骤不写验证和禁止结果 agent 干完活你也不知道对不对还容易顺手干些你不想要的事。5.4 第三步配置上下文加载策略上下文加载策略决定了 agent 每次执行时视野里有什么。我的配置逻辑是这样的# 伪代码说明加载逻辑 def load_context(task): context [] # 常驻层永远加载 context.append(read(RULES.md)) context.append(read(STRUCTURE.md)) # 目录结构说明 context.append(task.description) # 任务层按任务加载 for f in task.related_files: context.append(read(f)) # 参考层不主动加载agent 需要时自己查 return context这个逻辑的核心是常驻层极简、任务层精准、参考层按需。我实测下来常驻层控制在 500 字以内、任务层控制在 5 个文件以内agent 的执行成功率最高。5.5 第四步跑通第一个受纪律约束的任务配置好之后跑一个最简单的任务验证整套系统。我建议第一个任务选创建一个 hello world 文件这种级别的目的是验证流程通不通不是验证 agent 聪不聪明。执行流程是这样的你把任务模板填好交给 agentagent 按规则加载上下文、执行步骤、跑验证、报告结果。如果验证通过你提交不通过回滚重来。第一次跑大概率会出问题比如 agent 没按模板来、验证动作没执行、上下文加载错了。这些都是正常的根据报错调整规则文件和模板就行。我调了大概五六次才跑顺。6. 踩坑实录那些让我熬夜的典型问题和排查方法6.1 agent 反复犯同一个错怎么办这是最常见的问题。agent 改了一个 bug下次执行又犯同样的错。原因通常是这个错误的教训没有被写进规则文件。我的解决办法是每次 agent 犯错我都问自己一句这个错能不能变成一条规则如果能就写进RULES.md。比如 agent 老是忘记写注释我就在代码纪律里加一条每个函数必须有注释验证时检查。加了之后它就不忘了。规则文件是会长大的这很正常。但要注意定期清理把已经不会犯的错的规则删掉保持文件精简。6.2 上下文超限导致 agent 失忆agent 执行到一半突然忘了前面干了什么或者开始重复已经做过的事。这通常是上下文超限了。排查方法看 agent 每次加载了多少内容。如果常驻层太大或者任务层加载了太多无关文件就会挤占上下文空间。解决办法就是严格执行分层加载常驻层能删就删任务层只加载必需的。我踩过最惨的一次是让 agent 处理一个 5000 行的数据文件它把整个文件读进上下文结果后面的指令全被挤没了。后来我改成先让 agent 读文件的前 100 行了解结构再用脚本分批处理问题就解决了。6.3 agent 自作主张改了不该改的东西这个坑我在项目三踩过前面提过。根本原因是禁止清单不够明确。排查方法回顾 agent 的操作日志看它改了哪些你没让它改的东西然后把这些操作明确写进禁止清单。禁止清单要写得具体不能写不许乱改要写不许修改 data/ 目录下的任何文件。6.4 验证动作形同虚设有时候你写了验证动作但 agent 跑完说验证通过你一看结果根本不对。这通常是验证动作写得太模糊。好的验证动作必须是机器可判断的。比如检查输出文件是否存在是好的检查输出内容是否正确是坏的因为正确没有标准。我现在的习惯是验证动作尽量用命令表达比如test -f output.json或者python -c import json; json.load(open(output.json))。6.5 常见问题速查表问题现象可能原因排查方向解决办法agent 反复犯同一错教训没写进规则检查 RULES.md把错误变成规则agent 执行中失忆上下文超限看加载内容量精简常驻层分层加载agent 乱改文件禁止清单不明确看操作日志写具体禁止项验证形同虚设验证动作模糊看验证步骤改成机器可判断的动作任务做一半卡住任务粒度太粗看任务模板拆到可验证回滚失败没记录状态看 Git 记录每任务一 commit7. 关于 AI 编程工具和 agent 框架的一些个人看法7.1 工具是次要的纪律是主要的我用过好几款 AI 编程工具说实话它们的能力差距没有想象中那么大。真正拉开差距的是你有没有一套纪律来约束它们。我见过有人用着最贵的工具项目做得一团糟也见过有人用着最朴素的工具项目做得井井有条。区别就在纪律。工具会更新换代纪律是通用的。所以我的建议是别在选工具上纠结太久选一个顺手的就开始把精力花在建立纪律上。7.2 agent 框架的选择从简单开始agent 框架这块市面上的选择很多有轻量的、有重型的、有偏编排的、有偏自主的。我的建议是从最简单的开始。零基础的人一上来就搞复杂框架很容易被各种概念绕晕。我一开始就是从规则文件 任务模板这种最土的办法开始的跑通了再考虑要不要上框架。事实证明对于个人项目这套土办法完全够用。框架解决的是规模问题——当你有很多 agent 要协作、很多任务要编排时框架才有价值。个人做几个项目用不上那么重的东西。7.3 关于agent 记忆的一点实践agent 记忆是个热门话题但我实践下来发现对个人项目来说最简单的记忆就是文件。我把所有需要 agent 记住的东西都写成文件规则写RULES.md目录结构写STRUCTURE.md历史决策写DECISIONS.md。agent 每次执行时按需读取。这比搞什么向量数据库、记忆模块简单多了而且可控。复杂的记忆方案适合复杂场景个人项目用文件就够了。别为了用新技术而用新技术。8. 给零基础想用 AI 编程做项目的人几句实在话第一别指望 AI 帮你把项目做完它只能帮你把活干了。项目能不能做完取决于你有没有把任务拆清楚、有没有验证每一步、有没有在出错时回滚。这些事 AI 替不了你。第二规则文件是你最重要的资产。你踩的每一个坑都应该变成一条规则。规则积累得越多你后面做项目越顺。我现在的RULES.md有三十多条每一条都是血泪。第三从最小的项目开始。别一上来就想做个大系统先做个能跑起来的小工具把纪律系统跑通再逐步加复杂度。我第一个项目就几百行代码但它让我把整套流程走了一遍。第四Git 一定要学。哪怕只学四个命令也比不学好。回滚能力是零基础的人的安全网没有它你改崩一次可能就前功尽弃。第五别怕犯错但要记录错误。我一个月里犯的错比我过去一年都多但每一个错我都记下来了变成了规则。错误本身不可怕重复犯同一个错才可怕。最后分享一个我最近在用的技巧每次开新项目前我会先花十分钟把上个项目的RULES.md过一遍把适用的规则复制过来不适用的删掉。这样新项目一开始就带着上个项目的经验起步就比上次稳。这个习惯让我第四个项目的启动时间比第一个短了一半还多。