企业官网建设流程全解析

先给结论：AI 编程智能体这波，跟当年 GitHub Copilot 刚出来时的“IDE 自动补全”完全是两个物种。那时候大家都在猜 AI 会不会把程序员干掉，结果发现它只会替你写个 if 判断；这一轮你会看到它自己拆需求、改文件、跑测试，再根据报错自己修代码。我在中小型技术团队里做了很多年“救火队员”，从早期用各种 AI 编程工具到现在，最近这一年已经把自己的日常工作改成了“指挥智能体干活 + 评审它们的产出”的模式。这篇文我聊点实在的，不吹风口，也不贩卖焦虑，只讲一个普通程序员怎么把这套东西变成真正的个人杠杆。

先说清楚：我不是什么算法大佬，也没在头部大厂搞过基础模型，就是一个天天跟业务代码打交道、看系统烧 CPU、看测试动不动红一片的一线开发者。下面的经验全部来自真实项目，包括我自己从“把提示词写得很长”到“让智能体自己查资料改代码”的完整过程。你可以把它当成一条普通程序员的实操路线来看。

1. “风口”翻译成人话：AI 编程智能体到底改写了哪一层竞争

1.1 风口不在“会不会写代码”，而在“能不能把活干完”

大家常说程序员拼的是技术深度、架构能力、项目经验，这些当然都对。但这几年我感触最深的是另一件事：源源不断的琐碎代码才是最消耗人的。业务接口要写，CRUD 要写，数据迁移要写，测试用例要写，环境配置要写。这些东西难吗？真不难，可它们会非常稳定地吃掉你的时间，让你没空去看那些真正复杂的问题。

AI 编程智能体的第一个价值，就是把这些“不难但量大的活”接过去。你跟它说清楚这次要做什么，它能自己打开项目目录、找到对应文件、生成代码、跑测试，然后把结果反馈给你。它不是一个只会等你在聊天框里贴代码段的补全工具，而是一个能“接近完整执行任务”的工作体。

所以我说风口被改写了：以前一个普通程序员和一个经验丰富的资深工程师，差距不仅体现在方案设计上，更体现在同样时间里谁能产出更多可靠代码。现在智能体在一定程度上拉平了“执行层”的差距，你能分出更多精力去做设计、判断、取舍。

1.2 普通人才是这波工具的最大受益者

有一种误解，说 AI 编程智能体是高手才能用好的玩具。我反而觉得恰恰相反。已经在特定领域深耕多年的人，确实清楚每一步该怎么走，但他们不一定愿意让 AI 介入核心设计，因为出了错他们自己几分钟就能解决，让 AI 改反而还要解释上下文。普通程序员不同，我们手里大量任务本身就有标准答案：增删改查、接口对接、日志补全、配置整理。AI 编程智能体恰恰最擅长这类有明确目标和边界的工作。

这就像是给一个熟练工配了台能自动拧螺丝的机器，这台机器对工程师有用，但对刚入行、正被拧螺丝淹没的工人来说，意义更大。你可以把多出来的时间用来学业务、学架构、学怎么拆复杂问题，慢慢往上走，而不是三年后还在手动写同样的模板代码。

1.3 要认清：它不是“替你思考”，是“替你执行”

必须泼一盆冷水。AI 编程智能体的聪明，跟你理解的“聪明”不太一样。它能很好地理解你在一段上下文里表达的意图，也能在已有代码风格的基础上续写出看起来合理的代码，但它不会像资深工程师那样对技术方案做长期权衡。你可以让它“写个订单超时取消的定时任务”，它写得又快又好；你要是让它“设计一套金融级对账系统的整体方案”，它就很容易把表面的东西堆得很完整，真抠细节全是窟窿。

所以聪明的用法不是把决策权交给它，而是把它当成一个高配合度、低试错成本的执行层。你给方向，它填细节；你给约束，它给方案；你负责验收，它负责干活。后面我会详细说怎么搭这套协作关系。

2. 真实项目里测出的能力边界：能干的、不能干的、还有“假能干”

2.1 真正能顶上的工作

我在生产环境里实际让它干过蛮多事，按“省时间程度”排个队，最值的几类大概是：

我目前最常用的其实不只是写代码，而是“让它当我的第二双手”：我负责描述意图和验收，它负责把 Intent 变成 Commit。这项工作流一旦跑顺，人就不会那么容易被杂务拖垮。

2.2 它会栽跟头的场景

看见上面那张表，先别急着把全部代码都交给它。我在真实项目里踩过不少坑，现在总结下来，最危险的是下面几类：

• 老旧业务的多步状态流转。你给它一个“修改订单状态”的需求，它可能只是把状态字段改了，但漏掉了后面的库存回滚、日志记录、消息通知。因为上下文太深，它容易盯住眼前一段代码，忘了全局。
• 高度依赖公司内部约定。比如你们有自己的权限框架、统一返回结构、特殊异常码，智能体在一个新项目里很难猜到这些约定，除非你提前把约定喂给它。
• 并发和事务边界。这两个概念它理解得“很文字化”，能写出看起来对的锁、事务注解，但实际在高并发情况下很容易出问题。它缺少“线上被拖垮”的肌肉记忆。
• 现网问题的快速定位。你可以让它帮你分析日志摘要，但最终的因果判断还是得靠人。因为它只会基于你给它的信息做推测，而你给的信息可能本身就丢了关键链路。

2.3 怎么识别它在“假能干”

这是我最想分享的经验。AI 编程智能体输出的代码大概率能通过语法检查，但这不等于“对”。它经常犯一个毛病：自己“造”一个不存在的函数或配置项，然后一本正经地用上。典型表现是，你运行测试后报错ModuleNotFoundError或者AttributeError，它也改得很积极，可如果你不盯着它，它可能为了消除报错，去改掉一个不该动的底层方法，拆东墙补西墙。

我现在有个习惯：每次让它改代码，都会要求它附带“变更影响说明”，就像同事交 PR 时会写清楚“我改了什么、为什么这么改、还有哪些隐患”。如果它给不出像样的解释，那基本说明它不是真理解，只是在生成一段语法正确的字符串。你也可以在提示词里直接写明：“不要为了消除报错修改无关代码，如果发现有路径依赖，先停下来汇报。”

3. 一套直接抄作业的 AI 编程智能体工作流：从需求到提交

3.1 先定工作边界，再让它动手

我见过很多人用智能体翻车，原因不是工具不行，而是启动姿势不对。一上来就说“帮我做一个后台管理系统”，信息量巨大又模糊，它当然会给你一版“看起来很完整但根本没法接进现有项目”的代码。正确做法是先拆任务。

我的习惯是这样的：拿到一个需求，先自己把任务写成两三段话，明确四件事：背景目标、输入输出、约束条件、验收标准。背景目标是要让智能体知道这段代码在什么系统里运行；输入输出是边界；约束条件是让它别乱用依赖；验收标准是告诉它怎样才算做完了。

3.2 一个亲测好用的需求模板

下面这个模板我一直在用，基本覆盖了我和智能体协作需要的前提信息。你可以直接复制到对话开头：

任务背景： 当前项目是 XX 系统的订单服务，技术栈为 Python/FastAPI/PostgreSQL。 我要实现一个 CSV 账单批量导入接口。 输入输出： 输入是前端上传的 CSV 文件，字段包括：订单号、金额、导入人。 输出是 JSON 结构，包含成功导入条数和失败明细。 约束条件： - 只允许操作批次状态为“待导入”的记录 - 所有金额字段以分为单位，避免浮点误差 - 不要引入额外的大型框架，仅使用标准库 验收标准： - 数据格式错误时返回 400，并给出具体行数和字段 - 重复导入同一订单号时返回冲突提示，不能写入脏数据 - 处理完成后生成一条导入记录 请先给出实现方案，不要直接写完整代码，等我确认后再开始。

最后那句“先给方案，再写代码”非常重要。这能防止它朝着错误的方向狂奔。你花一分钟看方案，比让它写半小时错代码再去修要划算得多。

3.3 多文件改动的“分段驾驶法”

如果需求涉及多个文件，不建议让它在一次对话里把所有改动都做完。我现在的做法是：让它每完成一个步骤就停下来，我检查完这步的 diff 再继续下一步。

以一次典型重构为例：

1. 先给出目标：“把 XXService 中所有订单状态更新的逻辑收敛到 OrderStateMachine 类中。”这句话本身不复杂，但它会牵动一堆调用方。
2. 让它先列出它预计影响到的文件清单。这一步很重要，你可以在动手前发现它有没有漏掉某些调用方。
3. 确认清单后，让它先迁移核心逻辑，先不要改调用方。
4. 人工或测试驱动验证核心逻辑没问题，再让它逐个修改调用方。
5. 最后让它跑全量测试，并且列出每一个测试文件覆盖到的场景。

这样做看着慢，实际比一次性大改更稳。因为智能体的上下文窗口是有限的，一旦文件太多、调用链太深，它的错误率会指数级上升。你把它控制在“一次只动一个层次”，它的表现会稳定很多。

3.4 让智能体“自己修测试”，但要给它配个监理

现在不少 AI 编程工具已经能直接执行测试命令，看到失败后自己继续改代码。这套循环跑通之后非常省心，但也有坑。它跑测试、看报错、改代码，如果报错来自测试代码本身，它可能会为了让测试通过而把测试断言改弱，甚至直接注释掉。

我的处理方案是，在项目里约定一条规则：测试代码不允许被智能体修改。如果它发现测试有问题，只能在反馈里说明原因，等待人来决定。你可以在规则文件里写明“不得修改 tests/ 目录下的文件，只能新增测试文件”。这是成本最低、收益最大的护栏。

4. 比提示词更值钱的东西：给你的智能体建立“项目职业记忆”

4.1 单次对话的提示词，无法替代长期上下文

很多人把 AI 编程智能体当成一个每次都要从零开始解释的实习生。你今天告诉它项目用的是 TypeScript，明天它可能又默认生成 JavaScript；你今天提醒它单元测试要写在tests/，明天它可能又把测试塞到源码目录里。这就是缺了长期记忆。

好在现在主流编码智能体普遍支持项目级配置文件，相当于给智能体建了一份“入职手册”。里面可以写清楚项目语言、框架、目录结构、代码风格、常见约定、哪些目录不能乱动、测试命令是什么。这个文件不是给人看的摆设，它会成为智能体在每次对话前自动加载的上下文。

4.2 一份通用规则文件示例

不同工具对这个文件的命名略有差异，但我建议你用通用的AGENTS.md，现在主流工具基本都接受这个命名。它的结构不需要复杂，只要把过去你反复提醒智能体的话沉淀下来：

# 项目约定 ## 技术栈 - Web 框架：FastAPI - 数据库访问：SQLAlchemy 2.x + Alembic 迁移 - 前端不需要此项目处理 ## 目录说明 - app/routers/ 只放路由入口，禁止写业务逻辑 - app/services/ 放业务逻辑 - app/models/ 放 ORM 模型 - tests/ 下的文件只能新增，不能修改 ## 代码风格 - 类型标注必须完整 - 所有错误先统一映射到 app/errors.py 中的异常类 - 日志使用结构化日志，字段名统一为 uuid、event、message ## 常用命令 - 安装依赖：pip install -r requirements-dev.txt - 跑测试：pytest tests/ -x - 本地启动：uvicorn app.main:app --reload

你会发现，写这个文件的过程，其实就是逼自己梳理项目规范的过程。我以前很多规范只在脑子里，或者散落在团队文档里，现在统一丢给智能体一份，它写出来的代码至少不会跑偏太多。这个文件本身，才是你真正该花时间维护的东西。

4.3 规则要具体，别写“要写高质量代码”这种废话

很多人建了规则文件却觉得没效果，十有八九是因为规则写得太抽象。智能体对“高质量”“可维护”“性能好”这种词只有模糊反应，真正有用的是可被检查的约束。

举个例子，“性能好”没用，“禁止在循环里查询数据库，应该先批量取出再在内存里组装”有用； “注意安全”没用，“所有用户输入必须通过 validator 校验，不能直接拼进 SQL”有用。每一个约束都要尽量落到“能被执行或检查”的层面，这样智能体才不会自由发挥。

4.4 把“踩坑记录”也喂给它

现在我还会在项目里放一个KNOWN_ISSUES.md，专门记录那些我们反复踩过、普通人很难看出来的坑。比如某个第三方库在某个版本下有并发 bug、某个接口调用必须带超时时间、某个数据库字段不能直接更新。智能体在修改相关代码时不一定能自动翻到这份文件，所以我通常在任务提示里加一句：

开始前先阅读 KNOWN_ISSUES.md，如果本次改动涉及相关模块，必须按其中的约束处理。

这个文件的价值会随着时间叠加，你踩过的坑越多，智能体就越像“熟悉这个项目的老手”。这不是什么高深技术，纯粹是知识管理。

5. 普通程序员怎么练出“智能体驾驶力”

5.1 别把工具当玩具，要把它当正规军

我见过不少人一开始兴致勃勃，让智能体写了个贪吃蛇就觉得自己掌握了；也见过很多人因为一次改崩了项目就再也不敢用。这两种极端都没必要。你要做的，是把“指挥智能体”当成一门正经技能来练。

最低成本的练法，是找一个你自己维护、但短期不会上生产的旧项目。先给它的根目录写一份AGENTS.md，然后翻旧需求单，挑几个典型的模块改造任务，比如“把原来的同步接口改成异步”“给这个服务加统一的异常处理”。每个任务都走一遍“拆解需求、让它出方案、确认方案、分段执行、人工验收”的流程。

5.2 学会看 diff 是基本盘

你也许觉得，有了智能体，自己就不用那么懂代码了。恰恰相反，以后人与人之间的差距，可能从“谁能写出代码”变成“谁能看出 AI 写的代码哪里不对”。看懂 diff、看懂调用链、看懂异常上下文，这些能力会更值钱。

我的做法是，无论它改了多小的东西，我不会直接点“接受”，一定会逐个文件看 diff。刚开始会慢，但坚持一个月，你会对项目结构产生比原来更清晰的理解，因为你不再沉浸在自己敲代码的“心流”里，而是站在更高维度审视代码变更。这个转变本身就是成长。

5.3 给自己的提示重用库

我现在维护着一个个人提示库，不是网上那种花哨的“咒语大全”，而是结合自己技术栈写的模板。里面有“写一个 FastAPI 接口时提示模板”“排查线上报错的提示模板”“重构多文件功能的提示模板”等等。

这些模板的维护逻辑很简单：每次我发现某个提示能让智能体的输出显著变好，就把它固化下来；每次发现它因为某种表达方式出了错，就在模板里加一句限制。过几个月你会发现，你其实是在用工作经验训练一个自己的“专属驾驶舱”，这比收藏一万条别人的提示词有用得多。

5.4 试着把一个小系统完整交给它

当你对 workflow 足够熟练后，可以做个进阶训练：找一个非常小的内部工具，从数据库表设计开始，到接口、前端页面、部署脚本，全部让智能体配合你完成。你自己只负责拆模块、定接口、验收。这个过程会逼你把需求讲清楚，也会让你看到它在完整项目链条里哪些环节容易掉链子。

我在自己练这个的时候最惊讶的是，很多以前要花一整天的“体力活”，压缩到了半天甚至两三个小时。剩下来的时间，我开始补以前没时间看的领域知识。这种状态持续一段时间，你对工作的掌控感会明显不一样。

6. “逆天改命”我信八成，但改的不是你想的那个命

6.1 它能放大的，是你原有的执行力

回到标题里那个词，逆天改命。我的真实看法是：AI 编程智能体确实可能改变普通程序员的职业轨迹，但前提是你本身愿意做事、也有把事情做成的能力。它更像杠杆，而不是无中生有的印钞机。

你有没有发现，过去几年“风口”这个词被用烂了，很多人追区块链、追元宇宙，结果啥也没捞着。AI 编程智能体跟那些概念不同，它不需要你投入资金，不需要你有资源人脉，只需要你愿意改变工作习惯，就能立刻提高产出。对普通程序员来说，这就是最朴素的价值：同样能力，你能交付更多；同样时间，你能学到更多。日积月累，差距自然出来。

6.2 风险清单：别等出事了再后悔

使用 AI 编程智能体绝不是没有代价的。我排了几个最常见也最容易踩的坑，你能提前避开就提前避开：

只要把这条清单放在手边，大部分翻车现场是可以避免的。

6.3 给想上车的普通程序员一句掏心窝的话

我知道看到这里，你可能最关心的是：那我到底该不该把大量时间花在学这些工具上？我的建议是，先别想那么远，这个月就做一件小事：挑一个你最近要开发的简单功能，不用 AI 写，你先自己拆好需求和接口，然后让智能体按你的方案写出来，你再仔细看它每行代码。这个流程重复三到五次，你自然会知道自己能省多少时间。

不要指望看一篇文章就能成为高手，也别觉得这波机会已经晚了。工具还在一轮一轮迭代，真正缺的不是工具，而是能把工具用在真实项目里的人。我自己还在不断调整工作流，下一期我准备拆一个具体的例子，讲怎么让自己的智能体真正理解老项目的业务模型并参与重构。这系列既然开了头，我就会一直写下去，把踩过的坑、验证过的好用姿势都慢慢放出来。