企业官网建设流程全解析

1. 从校招入职到把 AI 塞进日常开发：我的完整工作流长什么样

刚进大厂那会儿，我最大的感受不是业务难，而是"信息密度"太高。一个需求从产品评审到上线，中间要经过需求拆解、技术方案、编码、自测、CR、联调、灰度、回归，每一步都有对应的平台和规范。作为校招生，我一开始的节奏是：白天开会、晚上补代码，周末补文档。真正让我把节奏拉回来的，不是加班，而是把 AI Coding 这套东西接进了我的完整开发流程里。

这里说的 AI Coding，不是"打开一个对话框问它怎么写快排"这种玩具级用法，而是把 Coding Agent 当成一个能读仓库、能改文件、能跑命令、能看报错的"结对同事"。核心工具我用的是 Codex 这类命令行 Coding Agent，配合 IDE 里的插件形态，覆盖从需求理解到提交 MR 的全链路。它解决的问题很具体：重复性的样板代码、跨文件的上下文查找、报错定位、单测补全、CR 前的自查，这些占了我一天里至少一半的时间。

这篇文章适合谁看？如果你是把 AI 当搜索引擎用的开发者，看完可以升级成"工作流级"用法；如果你是刚入职的校招生或者转行选手，这套流程能帮你把"能写代码"变成"能交付需求"；如果你已经在用 Coding Agent 但总觉得它"不太听话"，那大概率是接入方式的问题，后面我会重点讲。

我踩过的坑不少：一开始我以为 AI 就是补全，结果发现真正的价值在"流程编排"；我以为装个插件就完事，结果发现仓库上下文、权限、命令白名单才是决定体验的关键。下面我把整套东西拆开讲，从设计思路到实操细节，尽量让你能直接抄作业。

2. 整体设计思路：为什么是"接入流程"而不是"装个插件"

2.1 先想清楚 AI 在开发流程里的定位

很多人对 AI Coding 的期待是"我描述需求，它给我代码"。这个期待本身没错，但放在真实的大厂开发流程里会立刻碰壁。原因很简单：真实需求从来不是一句话，而是一堆上下文——产品文档、历史实现、团队规范、依赖版本、埋点要求、灰度策略。你把这些全塞进对话框，模型也消化不了。

所以我做的第一件事是给 AI 定位：它不是"需求到代码"的翻译器，而是"上下文到改动"的执行器。也就是说，需求理解、方案设计这些高价值判断我自己做，AI 负责的是把已经明确的改动落到具体文件、具体行、具体命令上。这个定位一变，整个工作流就顺了。

举个具体例子。产品说"这个列表页要支持按状态筛选"。我不会直接让 AI 写筛选逻辑，而是先自己确认：状态字段叫什么、枚举值有哪些、后端接口是否已支持、前端状态管理用哪个 store、筛选后是否要重置分页。这些确认完，我再让 AI 去改对应的组件、store、请求层和类型定义。它一次能改四五个文件，而且改得比我手敲快，因为它不会漏掉类型定义这种"顺手要改"的地方。

2.2 为什么选命令行 Coding Agent 而不是纯 IDE 补全

IDE 里的补全插件我用过不少，体验是"局部很强，全局很弱"。它能帮你补一行、补一个函数，但它看不到整个仓库的结构，也没法帮你跑测试、看报错、改配置。而 Coding Agent 的核心能力恰恰是跨文件操作 + 命令执行 + 结果反馈这个闭环。

我选 Codex 这类命令行 Agent 作为主力，理由有三个。第一，它能直接读仓库，不需要我手动复制粘贴上下文，这对大仓库尤其重要。第二，它能执行命令，比如跑 lint、跑单测、看 git diff，这意味着它能自己验证改动是否成立，而不是改完就甩给我。第三，命令行形态天然适合脚本化和流程编排，我可以把它嵌进 pre-commit、嵌进 CI 的某个环节，而不是只能手动触发。

IDE 插件我保留着，但用法变了：它负责"我在写代码时的即时补全和局部重构"，命令行 Agent 负责"我完成一个完整改动单元时的批量操作"。两者分工，不冲突。

2.3 工作流的分层设计

我把整个流程分成四层，从下到上依次是：

• 上下文层：仓库结构、依赖清单、团队规范文档、历史相似实现。这一层决定 AI 能不能"看懂"你的项目。
• 执行层：Coding Agent 本体，负责读文件、改文件、跑命令。
• 校验层：lint、类型检查、单测、构建。这一层决定改动能不能进 CR。
• 编排层：把上面三层串起来的触发点和规则，比如"改完自动跑 lint""提交前自动生成 commit message"。

大部分人的问题出在只做了执行层，上下文层没准备、校验层没接上，结果就是 AI 改出来的东西"看着对但跑不通"，用几次就放弃了。我后面会重点讲上下文层和校验层怎么搭。

提示：不要一上来就追求全自动。先把"AI 改一个文件 + 我手动验证"跑通，再逐步加自动化。流程是长出来的，不是设计出来的。

3. 核心细节解析：上下文、权限、命令白名单三件套

3.1 仓库上下文怎么喂才有效

AI 改代码改得准不准，八成取决于它有没有拿到对的上下文。我总结了一个"三层上下文"的做法。

第一层是项目级上下文，也就是那些"每个改动都该知道"的东西：技术栈、目录约定、命名规范、常用工具函数位置。这些我会整理成一个简短的说明文件放在仓库根目录，Agent 启动时会读。注意，这个文件要短，控制在几百字，写清楚"什么代码放哪里""命名用什么风格""哪些工具函数优先复用"就够了。写太长模型反而抓不住重点。

第二层是任务级上下文，也就是这次改动相关的文件。我不会手动一个个指定，而是让 Agent 自己去找。做法是给它一个明确的入口，比如"从src/pages/OrderList/index.tsx开始，找出所有和订单状态相关的文件"。它会顺着 import 关系把相关文件捞出来，比我手动列全得多。

第三层是规范级上下文，也就是团队特有的约束。比如我们要求所有接口请求必须走统一的 request 封装、所有异步操作必须有错误处理、所有新增字段必须同步更新类型定义。这些约束我会写成检查清单，在让 Agent 改代码时一并给它，让它改的时候就遵守，而不是等 CR 被打回来。

这三层搭好之后，AI 的改动准确率会有肉眼可见的提升。我实测下来，同一个需求，没喂上下文时改完要返工两三次，喂了之后基本一次过。

3.2 权限边界：哪些操作必须人工确认

把 AI 接进开发流程，最容易被忽略的是权限。它能改文件、能跑命令，如果不管，它可能删掉你不该删的东西，或者跑一些有副作用的命令。我的做法是设三道边界。

第一道是文件写权限。我会明确告诉 Agent 哪些目录可以改、哪些只能读。比如node_modules、dist、.git这些绝对不碰，配置文件改动要单独确认。这个通过 Agent 的配置项就能限制，不用靠自觉。

第二道是命令白名单。跑测试、跑 lint、跑类型检查这些只读或幂等的命令，允许自动执行；涉及网络请求、数据库写入、部署相关的命令，一律人工确认。我踩过一次坑：让 Agent 自己跑一个"清理缓存"的脚本，结果它把本地开发环境的 mock 数据也清了，重新造数据花了半小时。从那以后，凡是带"清理""重置""删除"字样的命令，我都设成必须确认。

第三道是提交权限。Agent 可以帮我生成 commit message、可以帮我整理 diff，但最终git commit和git push我一定自己来。原因很简单：提交记录是要进代码历史的，出了问题要能追溯到人，这个责任不能交给 AI。

3.3 命令白名单的具体配置思路

命令白名单不是简单列几个命令就完事，要按"风险等级"分类。我一般分三档：

这个分类的好处是，日常高频操作（读文件、跑校验）不打断我，危险操作一定会停下来问我。用久了你会发现，真正需要确认的操作其实很少，大部分时间 AI 都在做低风险的事。

注意：白名单要定期回顾。我每个月会看一眼 Agent 实际执行过的命令，把不再需要的加进去，把有隐患的挪到高风险管理。这个习惯帮我避免了好几次"AI 悄悄做了我不想要的事"。

4. 实操过程：从需求到 MR 的完整落地

4.1 需求理解阶段：让 AI 帮我做"信息压缩"

需求评审完，我手里通常是一堆散落的信息：产品文档、会议纪要、设计稿、历史相关需求。这个阶段我不让 AI 写代码，而是让它帮我做信息压缩。

具体做法是把这些材料丢给它，让它输出三样东西：改动范围清单（涉及哪些页面、哪些接口、哪些数据）、待确认问题清单（哪些地方文档没写清楚）、风险点清单（哪些改动可能影响现有功能）。这三样东西帮我快速判断这个需求的工作量和难点，也帮我在跟产品对齐时更有底气。

这一步的价值在于，它把"读文档"这个耗时但低产出的环节压缩了。以前我要花一两个小时翻文档理清楚，现在十几分钟就能拿到结构化结论，剩下的时间用来确认关键问题。

4.2 方案设计阶段：AI 做方案对比，我做决策

方案设计我不会让 AI 拍板，但会让它做对比。比如一个列表页要加筛选，我会问它："有哪几种实现方式？各自的改动范围、性能影响、可维护性如何？"它会给出两三种方案，我根据团队现状选一个。

这个用法有个前提：你得能判断它给的方案靠不靠谱。我的经验是，AI 给的方案通常"技术上可行"，但"团队适配性"要自己判断。比如它可能推荐用一个很新的状态管理库，但我们团队统一用的是另一套，这时候就要按团队规范来。

选定方案后，我会让 AI 把方案拆成具体的改动步骤，形成一个 checklist。这个 checklist 就是后面编码阶段的执行清单，每完成一项打个勾，避免漏改。

4.3 编码阶段：小步快跑，每步都验证

编码阶段是整个流程的核心，我的原则是"小步快跑，每步验证"。具体来说，一个需求我会拆成若干个"改动单元"，每个单元对应一个可独立验证的改动。

每个改动单元的执行流程是这样的：

1. 告诉 Agent 这个单元要改什么，给出入口文件和约束条件。
2. Agent 读相关文件，输出改动计划（改哪些文件、每个文件改什么）。
3. 我确认计划没问题，让它执行。
4. 执行完，让它跑 lint 和类型检查。
5. 我看 diff，确认改动符合预期。
6. 进入下一个单元。

这个流程看起来步骤多，但实际很快，因为大部分步骤是自动的。关键是第 2 步和第 5 步——计划要确认，diff 要审。这两步是防止 AI"跑偏"的关键。我见过太多人直接让 AI 改完就提交，结果 CR 时被打回来一堆问题，返工成本比一开始审 diff 高得多。

4.4 自测阶段：让 AI 补单测和边界用例

自测是我觉得 AI 价值最高的环节之一。人写单测容易偷懒，只测 happy path，边界情况经常漏。AI 不一样，你让它补边界用例，它能列出一堆你没想到的。

我的做法是：先自己写核心逻辑的单测，然后让 AI 补充边界用例。补充的时候给它明确的约束，比如"覆盖空值、超长输入、并发场景、异常分支"。它补完我再筛一遍，把不合理的删掉。这样下来，单测覆盖率能稳定在团队要求之上，而且边界覆盖比我自己写全。

还有一个用法是让 AI 帮我构造测试数据。真实业务数据往往很复杂，手动造很费劲。我会把数据结构给它，让它生成一批符合约束的测试数据，包括正常数据和异常数据。这个在联调阶段特别有用。

4.5 CR 前自查：把 AI 当"第一道 reviewer"

提交 MR 之前，我会让 AI 做一轮自查。自查的内容包括：改动是否完整（有没有漏改的地方）、是否符合团队规范、有没有明显的性能问题、有没有安全隐患、commit message 是否清晰。

这一步帮我挡掉了不少低级问题。比如有一次我改了一个接口的返回结构，忘了同步更新调用方的类型定义，AI 自查时发现了。如果等 CR 时被同事发现，虽然也不是大事，但会显得不够专业。

自查完，我会让 AI 生成一份改动说明，附在 MR 描述里。这份说明包括改动背景、改动内容、测试情况、影响范围。写 MR 描述这件事，以前我要花十几分钟，现在几分钟就能搞定，而且写得更全。

5. 常见问题与排查技巧实录

5.1 AI 改代码"看着对但跑不通"怎么办

这是最常见的问题，原因通常是上下文不全或者约束没给清楚。排查思路是这样的：

先看报错信息，判断是类型问题、依赖问题还是逻辑问题。类型问题通常是漏改了类型定义，让 AI 重新扫一遍相关文件。依赖问题通常是它用了仓库里没有的库，或者版本不对，这时候要明确告诉它"只能用现有依赖"。逻辑问题最麻烦，通常是它没理解业务约束，这时候要把业务规则重新讲清楚，最好给个具体例子。

我的经验是，报错信息越具体，AI 修得越快。所以不要只说"跑不通"，要把完整报错贴给它，包括堆栈。它读堆栈的能力比人强，经常一眼就定位到问题。

5.2 AI 改动范围失控怎么处理

有时候你让它改一个小功能，它顺手把周边代码也重构了。这种情况要提前预防：在给任务时明确说"只改和 X 相关的代码，不要动其他文件"。如果它还是改了，看 diff 时把无关改动回滚掉。

如果它频繁越界，说明你的约束不够明确。我会在项目级上下文里写清楚"改动最小化原则"，让它默认遵守。另外，把任务拆得足够小也能减少越界，因为小任务本身就没有"顺手重构"的空间。

5.3 AI 生成的代码风格和团队不一致

这个问题的根源是上下文里没有风格约束。解决办法是在项目级上下文里写清楚命名规范、注释规范、错误处理规范，最好给一两个"标准示例"让它参考。风格这种东西，说一百句不如给一个例子。

如果团队有 lint 规则，一定要让 AI 在改完后跑一遍 lint，让它自己修掉风格问题。这比人工挑刺高效得多。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是过度信任 AI 的"自信"。它有时候会用很肯定的语气给出错误答案，尤其是涉及具体版本号、具体 API 的时候。所以凡是涉及外部依赖的，我都会自己核实一遍。

第二个坑是上下文给太多。一开始我以为给得越多越好，结果发现给太多无关文件反而干扰它。后来我改成"精准给"，只给相关的，效果更好。

第三个坑是不做版本控制就让它改。有一次我没提交当前改动就让 AI 动手，结果它改乱了我想回滚都回不去。从那以后，让 AI 改代码前我一定先 commit 一次，保证有干净的还原点。

提示：把 AI 当成一个"能力很强但需要明确指令"的新同事。你不会指望新同事自己猜出所有规范，也不会让他随便动生产环境。同样的边界感，用在 AI 上就对了。

6. 工具选型与流程编排的取舍

6.1 命令行 Agent 和 IDE 插件怎么分工

前面提过，我两个都用，但分工明确。命令行 Agent 负责批量、跨文件、带命令执行的任务；IDE 插件负责即时补全、局部重构、快速问答。这个分工的核心逻辑是：需要"看全局"的交给命令行，需要"看当前光标"的交给插件。

举个具体场景。我在写一个组件时，插件帮我补全 props 类型、补全样式、快速提取一个子组件。等我写完这个组件，需要把它接入路由、接入状态管理、补上单测，这些跨文件操作我就切到命令行 Agent。两者切换很自然，不会互相干扰。

6.2 什么时候不该用 AI

这一点很重要，但很少有人讲。我的原则是：涉及核心业务逻辑判断、涉及数据安全、涉及线上配置的改动，不用 AI 直接改。这些地方出错成本太高，而且往往需要人对业务有深入理解，AI 给的建议只能当参考。

另外，学习新技术的时候我也不用 AI 直接写。比如我最近在学一个新的框架，我会自己写，遇到不懂的问 AI。因为学习阶段最重要的是建立自己的理解，让 AI 代劳反而学不到东西。

6.3 流程编排：把重复动作自动化

用了一段时间后，我发现有些动作是重复的，比如"改完跑 lint""提交前生成 commit message""MR 前生成改动说明"。这些就可以编排成固定流程。

我的做法是写几个简单的脚本，把 Agent 调用和校验命令串起来。比如一个"改完自检"脚本，依次跑 lint、类型检查、相关单测，全过了才提示我可以提交。这个脚本帮我省掉了每次手动跑命令的时间，也避免了"忘了跑某个检查"的情况。

编排的原则是只自动化确定性的步骤。判断性的步骤（比如"这个改动合不合理"）永远留给人。自动化是为了省时间，不是为了省思考。

7. 我个人的一些实际体会

用这套工作流大半年，最大的变化不是写代码变快了，而是我能把精力放在更值钱的地方。以前一天里有一半时间在查上下文、写样板、跑校验，现在这些被压缩了，我可以用更多时间想方案、想边界、想怎么把需求做得更稳。

另一个体会是，AI 用得好不好，差距不在工具，在你怎么组织上下文和约束。同一个工具，有人用起来像神器，有人用起来像玩具，区别就在于有没有把项目规范、任务边界、校验流程这些东西搭起来。工具是死的，流程是活的。

最后分享一个小技巧：我会定期回顾 AI 帮我改过的代码，看哪些地方它改得好、哪些地方它总出错。改得好的地方，我把经验固化到上下文里；总出错的地方，我调整约束或者干脆自己来。这个过程让整套工作流一直在进化，而不是用一段时间就停滞了。

这套东西没有标准答案，每个人的项目、团队、习惯都不一样。我的建议是先从一个小环节开始试，比如先让它帮你补单测，跑顺了再扩展到编码、自查、CR。一步一步来，比一次性搭个大而全的流程靠谱得多。