企业官网建设流程全解析

1. 校招入职第一周，我发现隔壁工位的效率是我的三倍

刚入职那会儿，我还在用最原始的方式写代码：打开 IDE，新建文件，一行行敲，遇到不熟的 API 就切到浏览器搜文档，搜完再切回来，一天下来窗口切换几百次，脑子里的上下文碎了一地。直到有次我卡在一个 TypeScript 泛型推导的问题上折腾了快两小时，隔壁工位的同事看了一眼，说"你让 Agent 帮你跑一下不就行了"，然后他在终端里敲了几行命令，一个 Coding Agent 自动读了相关文件、定位到类型定义、给出了修改建议还附带了测试用例。整个过程不到三分钟。

那一刻我才意识到，AI Coding 不是"让 AI 帮你写一段代码"这么简单，而是把 AI 嵌入到整个开发流程的每一个环节里。从需求理解、代码编写、调试排错、测试补全到 Code Review，每个环节都有 AI 可以介入的切入点。这篇文章我想完整拆解我这几个月摸索出来的工作流，包括我用了哪些工具、怎么配置、踩过哪些坑、以及为什么这样设计。不管你是刚接触 AI Coding 的新人，还是已经在用 Copilot 但觉得"也就那样"的老手，应该都能从里面找到能直接抄作业的东西。

先说结论：我的工作流核心不是某一个工具，而是三层结构——IDE 内的实时补全层、终端里的 Agent 执行层、以及跨会话的 Context 管理层。三层各司其职，缺一不可。下面逐层拆。

2. 第一层：IDE 内的实时补全，别只把它当高级自动补全

2.1 为什么 IDE 层不能被 Agent 替代

很多人觉得有了终端里的 Coding Agent，IDE 里的补全就鸡肋了。我一开始也这么想，用了一段时间才发现完全不是一回事。IDE 内的 AI 补全解决的是毫秒级反馈的问题——你打字的时候它就在猜你下一步要写什么，这种即时性 Agent 做不到。Agent 是"你描述一个任务，它去执行"，适合有明确目标的场景；而补全适合"我知道要写什么，但不想敲那么多"的场景。

举个具体例子：写一个 React 组件的 props 类型定义，我心里清楚每个字段是什么，但手敲要十几行。这时候 IDE 补全直接 Tab 补全比开 Agent 快得多。反过来，如果我要"把这个组件的状态管理从 useState 重构为 useReducer，并补上对应的测试"，那就是 Agent 的活。

所以第一层的定位很明确：降低机械性输入的摩擦，而不是替代思考。

2.2 我的 IDE 配置：补全触发策略与模型选择

我用的是 VS Code 加上主流的 AI 补全插件。配置上有几个关键点值得说：

触发延迟。默认的触发延迟通常在 300ms 左右，意思是停笔 300ms 后才弹出建议。我把它调到了 150ms，因为写代码时思考停顿往往很短，300ms 会让我已经打出下一个字符了建议才出来，反而打断节奏。但也不能调太低，太低会导致频繁弹出无关建议，实测 150ms 是个平衡点。

模型选择。补全场景我倾向于用响应速度快的模型，而不是能力最强但延迟高的。原因很简单：补全的价值在于"不打断心流"，如果每次补全要等两秒，我宁可自己敲。所以我在补全场景用的是轻量模型，在 Agent 场景才切换到能力更强的模型。

多行补全的接受策略。这是很多人忽略的一点。多行补全弹出来后，不要无脑 Tab 全接受。我的习惯是：先看第一行，如果方向对，再看后续行，逐段接受。因为 AI 补全经常出现"前半段对、后半段跑偏"的情况，全接受反而要花更多时间改。

2.3 补全层最容易踩的坑：上下文污染

这里说一个我踩过的坑。有段时间我发现补全质量突然变差，给出的建议总是和当前文件不相关。排查了半天，发现是因为我打开了一个巨大的自动生成文件（几万行的类型定义文件），补全插件把这个文件的内容也纳入了上下文，导致真正相关的代码被淹没了。

解决办法有两个：一是把自动生成的文件加入忽略列表，不让补全插件读取；二是养成习惯，写完一个模块就关掉不相关的大文件标签页。这个经验后来我在用 Agent 的时候也复用了——上下文的质量比数量重要得多，塞一堆无关文件进去，模型反而会抓不住重点。

3. 第二层：终端里的 Coding Agent，从"对话"到"执行"的跨越

3.1 Coding Agent 和聊天式 AI 的本质区别

聊天式 AI 是你贴代码给它，它给你建议，然后你自己去改。Coding Agent 是你给它一个任务描述，它自己去读文件、改代码、跑命令、看结果、再调整。这个区别看起来只是"自动化程度"的差异，但实际用起来是质变。

我举个真实场景。有一次我需要给一个 API 接口加上请求频率限制。如果用聊天式 AI，我得先把相关文件内容贴给它，它给我一段限流中间件代码，我再自己找到合适的位置插入，再手动改路由配置，再自己写测试。整个过程我要在 AI 和 IDE 之间来回切换至少五六次。

用 Coding Agent 的话，我只需要说："给/api/upload这个路由加上每分钟 10 次的频率限制，用现有的 Redis 连接，参考项目里已有的限流实现风格，并补上测试。"然后它自己去搜索项目里的 Redis 配置、找到已有的限流代码作为参考、修改路由文件、写测试、跑测试、如果测试失败还会自己修。我只需要在最后 review 一下改动。

3.2 任务描述的颗粒度：太粗和太细都不行

用 Agent 最关键的技能是任务描述的颗粒度控制。我摸索出来的原则是：描述"做什么"和"约束条件"，不描述"怎么做"。

太粗的描述："优化一下这个接口的性能。"——Agent 不知道优化哪个维度，可能给你加缓存，也可能给你改索引，方向完全不可控。

太细的描述："在第 42 行加一个 if 判断，如果 count 大于 100 就返回 429。"——这就退化成聊天式 AI 了，Agent 的自主性完全没用上。

合适的描述："/api/search这个接口在数据量大时响应超过 2 秒，需要在保持结果正确的前提下降低响应时间。项目里已经用了 Redis，可以参考cache.ts里的缓存模式。注意搜索结果需要支持分页，缓存 key 要包含分页参数。"

这个描述给了目标（降低响应时间）、约束（保持结果正确、支持分页）、参考（已有的缓存模式），但没规定具体怎么实现。Agent 可以自己决定是加缓存、优化查询、还是两者都做。

3.3 Agent 执行过程中的"信任边界"设置

用 Agent 有一个绕不开的问题：你信任它到什么程度。完全信任，它可能改坏你的代码；完全不信任，每一步都要确认，效率又上不去。

我的做法是分阶段设置信任边界：

这个分阶段策略的好处是：在风险最高的探索阶段保持控制，在风险较低的收尾阶段放手让它跑。实测下来，比"全程确认"快很多，又比"全程放手"安全很多。

提示：不管信任级别设多高，有一条底线不能破——永远不要让 Agent 直接操作生产环境。所有 Agent 的操作都应该在本地或隔离的开发环境里进行，确认无误后再手动部署。

4. 第三层：Context Engineering，决定 AI Coding 上限的隐形战场

4.1 为什么同样的 Agent，不同人用出来效果差十倍

这是我最想聊的一部分。我观察过身边同事用同样的 Agent 工具，效果差异巨大。有人觉得"AI 也就那样，写的代码还得大改"，有人觉得"效率提升了好几倍"。差距不在工具，在Context Engineering——你怎么组织给 AI 的上下文。

打个比方：Agent 就像一个刚入职的新人，能力很强但对你项目一无所知。你给它的上下文就是它的"入职培训材料"。培训材料给得好，它上手就快；给得差，它就只能瞎猜。

4.2 项目级上下文：让 Agent 快速"入职"

我做的第一件事是在项目根目录维护一个 Agent 能读到的上下文文件。这个文件不是给人看的文档，而是专门给 AI 看的"项目说明书"。内容包括：

• 项目架构概览：用了什么框架、目录结构怎么组织、核心模块之间的关系
• 编码约定：命名规范、错误处理模式、日志规范、测试写法
• 常用命令：怎么启动开发环境、怎么跑测试、怎么跑 lint
• 已知的坑：哪些模块有历史遗留问题、哪些依赖版本有兼容性注意事项

这个文件我大概花了两个小时写，但后面每次开新会话都省了大量"解释项目背景"的时间。Agent 一上来就知道"这个项目的 API 层统一用 zod 做参数校验"，不用我每次都说。

4.3 任务级上下文：精准投喂比大量投喂有效

项目级上下文解决"通用背景"问题，任务级上下文解决"这次具体做什么"的问题。我的经验是：给 Agent 的文件不在多，在准。

比如我要改一个用户认证相关的功能，我不会把整个src目录都给它，而是给这几个文件：认证中间件、用户模型定义、相关的路由文件、以及一个已有的类似功能的实现作为参考。这四个文件加起来可能就几百行，但覆盖了 Agent 完成任务所需的全部信息。

怎么判断"给够了"？我的标准是：如果我把这些文件给一个刚入职的同事，他能不能独立完成这个任务。如果还需要额外解释，说明上下文不够；如果给了一堆他根本用不到的文件，说明上下文冗余。

4.4 跨会话的上下文延续：别每次都从零开始

AI Coding 一个很大的痛点是：每次开新会话，之前的上下文就丢了。你昨天跟 Agent 讨论了半天才理清的方案，今天开新会话它完全不记得。

我的解决办法是维护一个工作日志文件。每次和 Agent 完成一个阶段性任务后，我会让它把"做了什么、为什么这么做、还有什么没做"写进这个文件。下次开新会话时，第一件事就是让 Agent 读这个文件。这样虽然不能完全恢复上下文，但至少能接上之前的进度。

这个习惯看起来麻烦，但实际用下来，它帮我避免了很多"重复解释同一个问题"的时间浪费。而且这个日志本身也是很好的工作记录，写周报的时候直接翻就行。

5. 把三层串起来：一个完整功能的开发实录

5.1 需求理解阶段：让 Agent 先当"产品经理"

假设我接到一个需求："给现有的评论功能加上@提及用户的能力，被提及的用户会收到通知。"

我的第一步不是直接写代码，而是让 Agent 先分析这个需求。我会说："读一下comment模块的代码，分析要实现@提及功能需要改动哪些地方，列出改动清单和潜在风险，先不要改代码。"

Agent 会去读评论相关的模型、路由、服务层代码，然后给我一个改动清单：需要改评论内容解析逻辑、需要加一个提及关系表、需要加通知触发逻辑、需要改前端渲染。同时它会指出风险：比如提及的用户名如果包含特殊字符怎么处理、被提及用户如果不存在怎么办。

这一步的价值在于：它帮我把"我以为我懂了"变成"我真的懂了"。很多时候需求看起来简单，实际一分析才发现有一堆边界情况。

5.2 方案设计阶段：让 Agent 给多个选项

理解需求后，我会让 Agent 给出至少两个实现方案，并说明各自的取舍。比如@提及功能，方案 A 是在评论内容里存纯文本，解析时用正则提取提及；方案 B 是存结构化的提及数据，渲染时再拼装。

Agent 会分析：方案 A 实现简单但解析容易出错，方案 B 更健壮但需要改数据结构。然后我根据项目实际情况选一个。这个"让 AI 给选项而不是给答案"的习惯，是我觉得最有价值的用法之一——它把决策权留在我手里，但帮我省去了调研的时间。

5.3 编码执行阶段：小步快跑，每步验证

选定方案后，进入编码阶段。我的原则是把大任务拆成小步骤，每步都让 Agent 跑测试验证。

比如@提及功能，我会拆成：先加数据模型和迁移、再改评论创建逻辑、再加通知触发、最后改前端渲染。每一步完成后都让 Agent 跑相关测试，通过了再进行下一步。

这样做的好处是：如果某一步出了问题，问题范围很小，容易定位。如果一次性让 Agent 把所有改动都做了，出了问题要在一大堆改动里找，非常痛苦。

5.4 测试与 Review 阶段：让 Agent 当"挑刺的人"

代码写完后，我会让 Agent 做两件事：一是补全测试用例，特别是边界情况的测试；二是以"Code Reviewer"的身份审查自己的代码，找出潜在问题。

第二件事特别有意思。我会说："现在你是一个严格的 Code Reviewer，审查刚才的改动，重点看：错误处理是否完整、是否有并发问题、是否有性能隐患、命名是否清晰。不要客气，该挑刺就挑刺。"

实测下来，Agent 在这种"角色扮演"模式下确实能找出一些我自己忽略的问题。比如它会指出"提及通知的发送没有做去重，同一个用户被提及多次会收到多条通知"——这种问题我自己 review 时经常漏掉。

6. 那些没人告诉你但很重要的实操细节

6.1 模型不是越强越好，匹配场景才对

我用下来最大的体会是：不要所有场景都用最强的模型。补全场景用轻量模型，响应快；Agent 执行场景用强模型，因为它要理解复杂任务；代码 Review 场景用强模型，因为它要发现细微问题；格式化、改命名这种机械任务用轻量模型就够了。

用错模型的代价：用强模型做补全，延迟高，打断心流；用轻量模型做复杂重构，它理解不了任务，来回改反而更慢。

6.2 会话管理：什么时候该开新会话

一个常见的困惑是：什么时候该继续当前会话，什么时候该开新的。我的经验是：

• 同一任务的连续迭代：继续当前会话，因为上下文还在
• 切换到不相关的任务：开新会话，避免上下文污染
• 当前会话已经很长（比如超过几十轮对话）：考虑开新会话，因为长会话里早期的上下文可能已经被稀释了

判断标准很简单：如果你觉得 Agent"变笨了"，大概率是上下文太杂了，开个新会话重新喂干净的上下文。

6.3 不要完全信任 AI 生成的代码

这条听起来像废话，但我要说的是更具体的：AI 生成的代码在"看起来对"和"实际对"之间有巨大鸿沟。它可能写出语法完全正确、逻辑看似合理、但实际有微妙 bug 的代码。

我的习惯是：AI 生成的每一段涉及业务逻辑的代码，我都要自己读一遍。不是逐字读，而是带着"这段代码在边界情况下会怎样"的问题去读。涉及安全、金额计算、权限判断的代码，更是要逐行确认。

6.4 保持自己的编码能力

最后一个可能有点反直觉的建议：不要因为有了 AI 就停止提升自己的编码能力。原因很简单：你越懂代码，越能判断 AI 给的代码好不好；你越不懂，越容易被 AI 的错误答案带偏。

我见过一些新人，完全依赖 AI 写代码，结果遇到 AI 也搞不定的问题时完全束手无策。AI 是放大器，它放大你的能力，但也放大你的无知。保持基本功的训练，才能让 AI 真正为你所用。

7. 我踩过的三个真实坑，以及怎么爬出来的

7.1 坑一：让 Agent 一次性重构太多东西

刚用 Agent 的时候我很兴奋，有一次让它"把整个项目的状态管理从 Redux 迁移到 Zustand"。结果它改了三十多个文件，跑测试挂了一大半，我花了整整一个下午才把烂摊子收拾干净。

教训：Agent 的重构能力有边界，超过一定规模就会失控。后来我改成按模块迁移，一次只迁一个模块，迁完测试通过再迁下一个。虽然看起来慢，但总体反而快得多，因为没有返工。

7.2 坑二：上下文里塞了过期的文档

有次我让 Agent 参考项目里的 API 文档来实现一个接口，结果它按文档实现完后跑不通。排查发现那份文档是半年前的，接口早就改了，但文档没更新。Agent 忠实地按照过期文档实现，自然对不上。

教训：给 Agent 的上下文必须是"活的"。过期的文档比没有文档更危险，因为它会误导 Agent。后来我养成了习惯：给 Agent 参考文档前，先确认这份文档是不是最新的。

7.3 坑三：忽略了 Agent 的"幻觉式自信"

Agent 有时候会用非常肯定的语气给出错误答案。比如它会说"这个函数在utils/helper.ts的第 15 行"，但实际上那个文件里根本没有这个函数。它不是在撒谎，而是"幻觉"——它根据模式生成了一个看起来合理的答案。

教训：Agent 说的具体事实（文件路径、行号、函数名、API 签名）都要验证。我现在养成了一个习惯：Agent 提到某个具体位置时，我会让它把那段代码贴出来，而不是直接相信它的描述。

8. 写在最后：AI Coding 的本质是"人机协作的接口设计"

用了这几个月，我最大的感悟是：AI Coding 的核心竞争力不在于你会不会用某个工具，而在于你会不会设计"人机协作的接口"。这个接口包括：你怎么描述任务、怎么组织上下文、怎么设置信任边界、怎么验证结果。工具会不断更新换代，但这套接口设计的能力是通用的。

我现在的日常是：IDE 补全帮我处理机械输入，终端 Agent 帮我执行有明确目标的任务，Context Engineering 帮我管理跨会话的知识延续。三层配合下来，我的编码效率大概提升了两到三倍——不是因为我写代码更快了，而是因为我花在"找信息、切窗口、重复劳动"上的时间大幅减少了。

如果你刚开始接触 AI Coding，我的建议是从最小的地方开始：先在一个小功能上试试 Agent，感受一下它的能力和边界，再逐步扩大使用范围。不要一上来就想着"全流程 AI 化"，那大概率会翻车。慢慢来，找到适合自己项目的节奏，比什么都重要。