企业官网建设流程全解析

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 聪不聪明。

执行流程是这样的：你把任务模板填好，交给 agent，agent 按规则加载上下文、执行步骤、跑验证、报告结果。如果验证通过，你提交；不通过，回滚重来。

第一次跑大概率会出问题，比如 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 常见问题速查表

7. 关于 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过一遍，把适用的规则复制过来，不适用的删掉。这样新项目一开始就带着上个项目的经验，起步就比上次稳。这个习惯让我第四个项目的启动时间比第一个短了一半还多。