企业官网建设流程全解析

最近好几个朋友都在聊“AI工程交付行动营”这个词，好奇这到底是学什么的。其实用一句话就能讲明白：就是教你把一个大模型demo变成真正能上线、能被业务方每天使用的系统。这件事说起来简单，做起来全是坑。我自己前后带过好几轮AI项目交付，最深的感受是：工具和能力是两码事。现在大家手上基本都有Codex这类代码生成工具，写代码的速度确实快了很多，但如果脑子里没有一套从需求到上线的完整交付框架，速度快反而容易翻车——生成得越快，错得越远。

这篇文章就把我在交付实战里反复验证过的方法论、提示词写法、踩坑记录和排查思路一次讲透。不管你是刚接触Codex的开发者，还是正在带AI项目的技术负责人，只要能照着把其中几条落下去，交付质量都会有肉眼可见的提升。

1. 先看清：AI工程交付到底在交付什么

1.1 模型跑通不等于项目交付

很多团队容易陷入一个误区：模型准确率刷到90%以上，就认为项目快成了。但真实情况是，模型跑通只是整个交付链路里的一小步。交付的本质是让业务价值稳定地运行在生产环境里，它要求系统可重复、可观测、可回滚，出了问题能定位、能恢复。

我给你打个比方：模型跑通相当于你手里有一份很好的菜谱，但开餐厅是另一回事。你要考虑食材供应链稳不稳定、厨师能不能按标准出餐、高峰期出餐速度跟不跟得上、客人吃坏了肚子怎么溯源。放到AI工程交付里，对应的就是数据管道、接口契约、权限控制、日志追踪、监控告警、异常降级、回滚机制。这些环节任何一个掉链子，哪怕模型本身再强，业务方也不会认账。

我见过一个真实的场景：某团队做了一个图像识别服务，离线测试效果惊艳，结果一上线就崩。原因很简单——没有做并发限制，没有设置超时，也没有接口鉴权，结果生产流量一进来，服务直接雪崩。模型没有任何问题，问题全在工程交付。所以做AI项目，第一个要建立的认知就是：不能用做研究的心态做交付，要把自己当成一个工程负责人，而不是算法研究员。

1.2 交付链路里Codex的位置

那Codex在这条链路里到底扮演什么角色？我的定位是“高级自动补全+结对程序员”，而不是架构师，更不是决策者。它最擅长的是把已经想清楚的事快速落地成代码：项目脚手架、接口定义、数据模型、单元测试、Dockerfile、CI脚本、日志中间件，这些“胶水代码”和“体力活”它做起来又快又稳。

Codex也有明显的短板。凡是需要业务判断的事，比如需求优先级怎么定、分级规则怎么设计、数据合规要求是什么，它一概不负责，也不应该让它负责。你把决策权交给它，它就会自信地编造一个看似合理的方案，那个方案看起来头头是道，但很可能完全不符合你的业务场景。

我用下来最顺手的组合方式是：人来定方向和边界，Codex负责把边界内的部分快速实现。人做架构设计、写验收标准、拆任务，Codex负责按任务清单逐项生成代码。这样说可能还是抽象，下面用一个完整案例把这条链路从头到尾走一遍。

1.3 适合放大效率的典型交付场景

不是所有交付环节都适合引入Codex，我用一个表格梳理一下“ROI最高”和“ROI很低”的场景，方便你判断什么时候该用它、什么时候该靠自己。

从这个表格能看出来，Codex在“从设计到实现”这一段发挥最大价值，但在“决策”和“守护”这两端，人必须全程在场。想清楚这一点，后面用起来才不会跑偏。

2. 从需求到上线：一次完整的AI工程交付演练

理论讲再多，不如完整走一遍。我拿一个虚构但非常典型的项目举例：某售后团队每天收到几千条工单，人工分级耗时严重，而且不同人判断标准不一致。现在要做一个“工单自动分级服务”，把工单按紧急程度分成S/A/B/C四个等级，S级自动通知相关负责人，其余等级按队列处理。技术栈用的是Python、FastAPI、SQLite，分级逻辑采用“规则引擎优先+模型兜底”的策略。

2.1 先写验收标准，再让Codex动手

这是整个交付流程里最重要的一步，没有之一。很多人习惯拿到需求就立刻让Codex写代码，这是错的。越早让Codex写代码，越容易把错误的需求固化下来，后期返工成本越高。

正确的做法是先定义验收标准。我带着团队先列了一张验收清单，每一项目标都可量化：

验收标准定好之后，我再用Codex辅助需求澄清。这里有个非常实用的提示词技巧：让Codex先不要写代码，只输出需求澄清问题。

你是资深交付工程师。现在有个需求：构建一个工单自动分级服务，输入工单内容，输出S/A/B/C等级并触发对应通知。请你先不要写代码，而是列出你认为在动手前必须澄清的5个问题，并说明每个问题对交付结果的影响。

这么做有两个好处：它能用比较快的速度帮你发现需求盲区，同时能留出时间让团队对齐预期。Codex回头给出的澄清问题一般集中在数据来源、误判率容忍度、通知方式、并发量、历史数据格式这几类，这些都是真正影响方案设计的问题。先花半小时做这件事，能省下后面几天的返工。

2.2 用Codex搭出项目骨架

需求清楚了，下一步是搭项目骨架。我不建议让Codex一口气生成整个项目，而是先让它输出目录结构和每个文件的核心职责。这样团队可以在写代码之前先Review结构，把职责边界定清楚。

我用的提示词是：

用FastAPI搭建一个工单分级服务，项目结构包含： - app/main.py：应用入口，注册路由 - app/models.py：数据模型 - app/services/classifier.py：分级逻辑 - app/routers/tickets.py：工单接口 - app/config.py：配置管理 - tests/：测试目录 - Dockerfile：容器化部署 请先只输出完整的目录结构和每个文件的职责说明，不要生成具体代码。

Codex给出的结构基本符合预期，稍微调整后固定下来：

app/ ├── main.py # FastAPI入口，挂载路由，启动日志 ├── config.py # 环境变量读取，统一配置 ├── models.py # 请求/响应模型 ├── services/ │ └── classifier.py # 规则引擎 + 模型调用 ├── routers/ │ └── tickets.py # /api/v1/classify 接口 ├── core/ │ └── logging.py # 日志中间件 tests/ ├── test_classifier.py └── test_api.py Dockerfile requirements.txt README.md

先定结构再写代码，这背后的逻辑和盖房子先出图纸是一样的。目录结构本身就是一种沟通语言，团队成员看到结构就知道每个模块的边界。这个步骤千万别省，Codex生成代码的能力再强，也不能替你做模块划分和职责定义。

2.3 核心逻辑生成与人工修正

结构定了之后，我按“数据模型→规则引擎→模型调用→降级逻辑”的顺序，让Codex逐块写代码。先说数据模型，提示词要写清楚字段和类型：

基于以下字段生成Pydantic模型：ticket_id(string), content(string), channel(string), created_at(datetime)。字段限制：ticket_id必填且唯一，content最长5000字，channel可选值包括"app","web","phone"。

Codex给出模型后，我检查了一遍，没有发现明显问题。接下来是核心的分级逻辑。这里我特别强调“规则优先+模型兜底”的混合策略，并且明确告诉Codex规则的优先级高于模型：

实现分类函数classify_ticket(content, channel)，逻辑如下： 1. 先走规则引擎：content中命中紧急关键词，如"崩溃""漏发""赔付""投诉""数据丢失"，直接返回S级。 2. 规则未命中时，调用内部模型服务接口进行分类。 3. 模型调用设置2秒超时，超时或异常时降级为人工队列标记，返回C级。 4. 返回结果包含本次分类命中的规则关键词（如有）。

Codex生成的代码整体逻辑正确，但我在Review时发现两个问题。第一个问题：它把“规则引擎”和“模型兜底”的边界写糊了，在规则命中后又做了一次模型调用，白白增加了耗时。第二个问题：超时异常处理只覆盖了请求异常，没有覆盖JSON解析异常。这两处我手动修正后，逻辑才真正达到验收标准。

这个环节看起来是在“改代码”，其实是在做最重要的人工把关。我现在带团队有一个硬性要求：关键路径代码必须人工逐行Review，禁止直接信任Codex的输出。它生成的代码往往“看起来对”，但边界条件、异常路径、性能隐患这些真正决定交付质量的地方，恰恰需要人来补。

2.4 测试、部署与监控补全

核心功能完成后，继续用Codex补齐测试和部署相关文件。我给它的提示词是：

为工单分级服务生成pytest测试用例。要求： 1. 覆盖规则命中、模型兜底、模型超时降级三条路径。 2. 使用mock模拟模型服务调用，不发起真实网络请求。 3. 测试数据使用examples目录下的sample_tickets.json。

测试用例生成后，我执行了一遍，发现Codex在mock超时场景时写错了异常类型，把TimeoutError写成了一个不存在的自定义异常。这个错误在测试运行时才暴露出来，正好印证了“生成代码必须跑起来才知道行不行”的经验。

部署方面，我让Codex生成了一份基础Dockerfile和健康检查接口。Dockerfile里有一处需要特别注意：Codex默认会用比较新的基础镜像，但生产环境里基础镜像版本往往已经被安全团队固定。我要求团队把镜像版本锁死，避免“本地能跑，生产构建失败”的尴尬。

最后是监控补全。我让Codex在main.py里加了一个中间件，把所有请求的耗时、状态码、命中规则写入JSON格式日志。日志是交付后排查问题的“黑匣子”，没有日志的系统出了问题只能靠猜。这部分逻辑不复杂，但Codex可以快速帮你写出来，省去手敲的时间。

3. 把Codex用出工程味：提示词与协作规范

3.1 高质量提示词的四个要素

很多人觉得Codex“不好用”，其实是提示词写得太抽象了。我总结了一个四要素框架：角色、上下文、任务、约束。四个要素齐全，Codex的输出质量会稳定很多。

我拿“写一个接口”来对比一下：

差提示词和好提示词之间，可能只是多写了三四句话，但生成代码的可用度完全是两个级别。这里面的原理是：Codex本质上是在做概率预测，你给的信息越确定，它生成的内容就越可能落在正确方向。上下文越完整，预测空间越小，错误率自然下降。

3.2 让Codex“说人话”的拆解写法

第二个关键技巧是把大任务拆成小任务。我见过不少同事一上来就贴一整段需求，让Codex“实现一个完整的工单分级系统”，结果生成出来的代码结构混乱，变量名互相冲突，改起来比从头写还痛苦。

我自己习惯的拆解方式是：先接口后实现，先测试后代码。具体来说，先让Codex生成接口定义和数据模型，团队Review通过后，再让它写具体实现。写实现的时候，一次只生成一个函数或者一个文件，确保每个单元都能被独立验证。

另一个很实用的习惯是“先写测试再写实现”。我会先描述清楚测试用例的预期行为，让Codex生成一个会失败的测试，然后让它按测试来实现。通过这种方式，Codex的输出会被测试锚定在正确的行为上，而不是漫无边际地自由发挥。

先写一个pytest测试用例test_s_level_rule_hit()，模拟工单内容中含"崩溃"关键词，断言分类结果为S级。先不要实现classify_ticket函数，我先看测试是否正确。

这么做看起来绕了一圈，其实是在给Codex画一条“正确的轨道”。测试就是轨道，代码就是火车，火车跑得再快，也得在轨道上跑才有意义。

3.3 团队Prompt资产库的建设

既然提示词这么重要，那它就应该被当成一种资产来管理，而不是存在每个人的聊天记录里。我带的项目组现在有一套“提示词资产库”，放在项目的docs/prompts目录下，像代码一样走版本管理，任何人贡献新的高质量模板都可以提交合并。

资产库的目录结构长这样：

docs/prompts/ ├── 00_角色基座.md # 所有提示词的公共角色前缀 ├── 01_需求澄清.md # 让Codex先问问题再写代码 ├── 02_接口生成.md # 生成REST接口的标准模板 ├── 03_测试生成.md # 按行为描述生成测试用例 ├── 04_部署脚本.md # Dockerfile、CI脚本生成模板 └── 05_日志监控.md # 日志中间件、监控告警规则模板

维护提示词资产库的好处是叠加的。一个人踩过的坑，通过模板沉淀下来，整个团队都能复用。比如说“需求澄清”模板，里面明确要求Codex输出每个澄清问题对交付的影响，这个约束就是有次项目返工后总结出来的。有了模板，新人也能直接站在老经验的基础上干活，不用重新交学费。

我还给团队定了一条命名规范：提示词文件一律用“动词_场景”命名，因为文件名同时就是用途。找模板时一眼就能看出来该用哪个，不用打开文件才知道里面写得是什么。

4. 交付路上的真实坑位与排查实录

4.1 生成代码的“自信错误”

Codex最让人哭笑不得的一点是：它经常以非常笃定的语气，写出根本不存在的函数名和参数。我遇到过一次，它生成了一段代码调用一个“标准库内置函数”，我印象里没有这个函数，一查文档，果然不存在。它的逻辑大概是把几个相似函数的特征“缝合”到一起了，看起来合理，实际跑起来立刻报错。

排查这种问题没有捷径，只能靠编译检查和单元测试兜底。所以我现在有一条铁律：Codex生成的代码必须能够通过编译和单测，才允许提交Review。不管是语法错误、参数错误还是逻辑错误，单测一跑就能暴露大半。

我还习惯在让Codex生成代码时主动要求它标注“不确定的部分”：

生成代码后，请用注释标出其中你不确定是否存在或可能过时的API调用，并在代码块末尾用列表说明。

这个提示词能提前把风险点暴露出来，省去人工大海捞针式地看代码。

4.2 依赖与环境的连锁爆炸

第二个高频坑是依赖管理。Codex生成的requirements.txt经常会把依赖版本写成最新的，但生产环境里别的服务可能正依赖某个旧版本。有一次，一个服务因为升级了一个工具库，结果另一个内部SDK直接被牵连挂掉，整个排查过程花了大半天。

解决方案不复杂，关键是养成习惯：所有依赖版本必须锁定，镜像构建必须用固定基础镜像。requirements.txt里不要出现类似“numpy”这样的裸依赖，必须写成“numpy==1.26.2”。

另外强烈建议所有服务都容器化。容器化最大的价值不是“方便部署”，而是把环境差异彻底隔离掉。本地“能跑”和生产“能跑”之间，差的往往就是几个依赖版本，容器一隔离，这种问题直接消失。

4.3 上下文窗口与任务切分

第三个坑和Codex的使用方式有关。很多人开一个对话就跑完整个项目的活，结果发现聊到后面它越来越“健忘”，前面定的约束后面执行不到位，同一个变量被重复定义了好几次。这是因为它的有效上下文是有限的，早期的信息在长对话中会被冲淡。

我的建议是：每个任务开新对话，新对话开始前贴上“项目上下文摘要”。摘要不需要很长，四五行就够：

项目背景：工单自动分级服务，输入工单内容输出S/A/B/C等级 技术栈：Python + FastAPI + SQLite 已定约束：规则引擎优先，模型兜底；模型超时降级人工队列；日志JSON格式 本次任务：为/health接口补充存活探针 验收标准：GET /health返回200和JSON体{"status":"ok"}

这短短几行上下文，能让Codex把精力全部放在当前任务上，既不会被旧信息干扰，也不会遗忘关键约束。如果你觉得每次贴摘要麻烦，可以考虑把摘要模板存成提示词资产库里的“项目上下文.md”，每次开新对话直接引用，成本极低，收益非常明显。

4.4 上线的最后一公里

很多项目死在最后一步。测试环境一切正常，一上生产就各种奇怪问题：密钥没配、数据库连接池太小、内网调用模型服务的网络策略没放通。这些问题的共同特点是：它们不存在于代码逻辑里，而存在于部署配置和运维细节里。

我在上线前会固定走一遍检查清单，这里分享出来：

• 密钥是否通过环境变量或密钥管理服务注入，是否已从代码和镜像中移除
• 数据库连接池大小是否匹配预估并发量
• 模型服务调用链路的网络策略、超时时间是否在运维侧放通
• 健康检查接口是否配置到负载均衡的探针
• 日志收集和告警阈值是否已配置，关键指标是否已经在监控面板可见
• 回滚方案是否明确：镜像tag是否固定、回滚步骤是否写成文档

单子看起来长，但每一条都是真金白银买来的教训。尤其是回滚方案这条，很多团队觉得“用上一版镜像重新发布就行”，结果真出问题时，发现上一版镜像已经被覆盖清掉，只能从零重建。镜像tag固定是一种廉价的保险，务必养成习惯。

上线方式我也建议分三步走：先切1%流量，观察半小时日志和错误率，没有异常再逐步放量到10%、50%、100%。这样能把风险控制在一个很小的范围里，一旦发现问题，影响面也是可控的。

5. 交付工程师的几条军规

5.1 工具永远替代不了责任

用Codex写了几个月代码之后，我有一个很深的体会：工具越好用，越要自己心里有数。Codex生成的每一行代码，最后都会变成你在生产环境里要扛的责任。线上出了事故，不会有人去责怪Codex，只会来找你。所以对工具生成的内容保持审视态度，不是不信任工具，而是对自己负责。

我在项目组里常说一句话：把Codex当成一个能力很强但是需要盯着的实习生。你给它清晰的任务和验收标准，它的产出会给你惊喜；你什么都不交代就让它自由发挥，它也会自信地给你埋一堆雷。

5.2 交付的终点是运维

代码上线只是交付的开始，不是结束。上线之后还有成本抖动、数据漂移、模型效果衰减、流量突增等一连串问题等着你处理。所以从项目第一天起，就要把可观测性设计进去：日志打点、指标监控、告警规则，这些不是事后补充的“锦上添花”，而是交付的必备组件。

我筛选监控指标时只盯三个核心：请求量、错误率、耗时分布。这三个指标能覆盖大多数线上问题。告警规则宁可先设置得宽松一些，也不要一上来就弄一堆“狼来了”的告警——告警疲劳会让团队忽视真正重要的通知。

5.3 行动营之外，如何继续进化

如果你正在计划做AI项目的工程交付，我的建议是先挑一个足够小、足够真实的场景，把从需求到上线的完整链路走通一遍。不要一开始就奔着大而全的平台去，那只会让你陷入细节的汪洋。一个“工单分级服务”或者“报表生成工具”这样的项目，足够让你把每个环节的坑都踩一遍，又能控制在可管理的范围内。

每次交付结束后，我还建议做一个复盘：这次交付中哪些环节耗时最长、哪些问题返工次数最多、哪些提示词模板可以沉淀到资产库里。这种不断迭代的“交付过程本身”，才是行动营里最值得带走的东西。

带完这么多轮项目之后，我自己最大的变化是：不再迷恋任何一个具体工具，而是更关注需求澄清、验收标准、代码审查、部署回滚这一整套“笨功夫”。Codex确实让我写代码的速度上了一个台阶，但真正决定项目成败的，始终是这些不性感的工程细节。工具会一直迭代，而你对交付的理解和掌控力，才是那个能一直复利的底层能力。