企业官网建设流程全解析

1. 现象拆解：80%这个数字到底意味着什么

前段时间刷到一条行业消息，说某家做大模型的AI公司对外披露，他们内部代码仓库里大约80%的代码是AI自己写出来的，几乎同一时间，这家公司的负责人又公开呼吁行业给AI开发踩一脚刹车。这两个信息摆在一起，荒诞感和真实感是同时涌上来的——工具已经被用到这个程度，用工具的人反而开始担心工具跑得太快。作为一个常年泡在代码里的开发者，我第一反应不是震惊，而是好奇：这80%到底是怎么算出来的，又是哪一类活被交了出去。AI开发这件事这两年被聊得太多，真正落到日常编码的细节反而少有人讲透，所以这篇就把我看到的、试过的、踩过的东西摊开说，不管你是刚接触AI编程提示词的新手，还是已经带着AI Agent做项目的工程师，都能从里面拿到能直接抄作业的东西。

1.1 从自动补全到自主生成，AI写代码走了三级台阶

要理解80%这个数字，得先把AI参与编码的方式分个层。最早的一层是行内补全，你在编辑器里敲几个字符，它猜你接下来要写什么，本质上是加强版的自动补全，比如补一个for循环的骨架、填一个早就忘了参数顺序的库函数，这种帮助是被动的，你不动它就不动。第二层是对话式生成，你把需求描述清楚丢给它，它吐出整段甚至整个文件的代码，像“写一个读取CSV、按城市分组求平均值的函数”，它一口气连空值处理和异常捕获都给你带上。第三层是Agent，也就是常说的ai agent开发，你丢一个大任务过去，它自己读文件、改代码、跑测试、看报错、再改，循环到你点头为止，中间几乎不需要你插手。

这三层对应的是三种完全不同的信任程度。第一层你基本不用怀疑，因为最终敲进去的每一个字符都在你眼皮底下过了一遍；第二层你需要审，逻辑对不对、边界处理全不全，得自己读一遍；第三层的信任成本最高，因为它会动你的仓库、装依赖、执行命令，一旦方向跑偏，你回滚的成本可能比从头写还高。所以当一家公司说“80%的代码是AI写的”，如果没有说明白是这三层里的哪一层占主导，这个数字的含金量其实差别巨大。

1.2 别被80%唬住，先搞清楚它统计的是什么

“代码由AI生成”这句话最大的陷阱就在统计口径。我见过几个团队做过类似的内部统计，得出的数字能从15%跳到75%，区别只在于统计方式不同。下面这张表是我自己梳理的几种常见口径，你可以对照着看自己团队大概落在哪个位置。

真正有意义的指标其实是“有效逻辑行”加上“返工率”这两个组合起来看。我做过一个小实验，让AI独立生成一个中等复杂度的数据处理模块，代码行数上它写了差不多95%，看起来非常漂亮；但如果只算核心业务逻辑，比例掉到大概60%，因为大量行数是日志、参数校验、类型声明这些周边内容。更关键的是返工，那个模块我前后改了四轮，第一轮的问题是拿了一个根本不存在的方法名，第二轮是分页边界处理错了，第三轮是并发场景下没加锁，第四轮才是性能问题。把返工的时间折算进去，最终“净节省”的工时并没有行数看起来那么夸张。

这不是说AI写代码不行，恰恰相反，它的价值是真实的，只是别被一个孤立的百分比带着走。看到任何“AI写了X%的代码”的说法，先问三个问题：算的是什么口径，返工率多少，出问题谁兜底。想清楚这三个，你对这个数字的免疫力就建立起来了。

1.3 呼吁暂停的悖论：为什么踩刹车的往往是踩油门的人

比80%更有意思的是后面那半句——呼吁暂停。乍看之下很矛盾，一家把AI用到了极致的公司，反过来劝大家慢一点。但如果你真的在工程一线待过，这个动作其实一点都不难理解。工具跑得越快，留给人的评估窗口就越短，而软件的复杂度是随规模非线性增长的。AI可以在一周内给你堆出一个能跑的系统，但这个系统里埋了多少没被验证过的假设，只有出事的时候才暴露。

我自己的体会是，AI开发带来的不是“写不出来”的问题，而是“写得太快、来不及想清楚”的问题。以前写一个模块要三天，那三天里你会不自觉地反复琢磨设计，很多坑是在敲代码的过程中被顺手填掉的。现在AI十分钟给你一版，你看着能跑就往下走了，那些原本会在慢速编码中被消化的思考，被跳过去了。所以所谓的“暂停”，很多时候不是反对工具本身，而是反对那种“因为能快速生成，所以就不加评估”的节奏。这个提醒对个人开发者也成立：你手上有了一把快刀，更需要的是刀法，而不是挥得更快。接下来的几节，我就把自己在AI辅助编程里总结出来的完整流程拆开讲，从工作流到落地细节，再到踩坑清单，尽量给到能直接复现的东西。

2. AI辅助编程的真实工作流长什么样

很多人用AI写代码，用得很累，然后得出结论说“AI不靠谱”。我观察下来，问题通常不出在模型，而出在工作流。把AI当搜索引擎用的人，得到的是一堆零散代码片段；把AI当新人带的人，得到的是一个能进仓库的模块。这两种用法之间的差别，就是下面这几个环节有没有做扎实。

2.1 上下文准备：把AI当新人带，而不是当搜索引擎用

我吃过最大的亏，就是不给上下文直接发一句话需求。比如我说“写个用户登录接口”，它给我的东西五花八门：有的用Flask，有的用Express，有的用FastAPI，密码加密方式每次都不一样。后来我改了个习惯，每次开口之前先做三件事。第一，把相关的目录结构和已有代码贴给它，让它知道项目在用哪套技术栈、命名风格是什么样。第二，把数据模型说清楚，字段名、类型、约束一个不落。第三，明确告诉它我要的输出形式，是完整文件、是补丁、还是只要核心函数。

这个习惯看起来费时间，实际上省的是后面反复返工的时间。你可以把这理解成带新人：你不会跟一个刚入职的同事说“你把登录做了”，然后指望他一次做对，你会给他看现有的代码、告诉他规范、指出参考实现。AI和新人唯一的区别是它不会累、不会不好意思问，但前提是你得把该给的背景给全。实测下来，同样一个模块，做足上下文的版本一次通过率能到七成以上，不做上下文的版本大概只有两成。

2.2 生成、审阅、验证的三段式闭环

我现在用AI写代码基本是固定套路，分成生成、审阅、验证三段，每段有明确的产出。生成阶段只管让它把东西造出来，这时候不纠结细节，因为早期版本注定要被改。审阅阶段是我花时间最多的地方，重点看四件事：依赖的库和方法是否真实存在、边界条件有没有处理、异常路径是否完整、有没有明显的性能陷阱。验证阶段就是把它扔进测试里跑，跑不过就带着报错回到生成阶段。

这个闭环的关键是不要让三个阶段混在一起。我见过有人一边让AI改、一边自己手动改、一边又跑测试，最后出了问题根本不知道是哪一步引入的。分开之后，每次出问题你都能定位到具体环节，返工效率高很多。顺带提一句，审阅阶段我完全不看它的注释，只看代码本身，因为AI写的注释有时候和代码逻辑是对不上的，信注释会把你带沟里。

2.3 代码评审与责任归属

代码是谁写的这件事，在工程里有明确的后果——谁提交，谁负责。AI生成的代码也一样。我的原则很简单：任何合进主干的代码，都必须有人能对它的逻辑负责，这个人就是提交者，不能因为它是AI生成的就把责任摘出去。所以在团队里我会要求，AI参与生成的改动，提交信息里要标注清楚哪些部分是生成的，方便事后追溯。

这不是形式主义。真出线上问题时，你回看提交记录，能快速知道这段代码是怎么来的，是有人精心设计过，还是随手让AI补的，排查方向完全不同。有些团队还会在PR里加一条检查项，要求作者说明“这段代码我验证过哪些场景”，这个动作成本很低，但能挡住大量没想清楚就提交的改动。

2.4 工具选型的几个务实判断

工具这块我不做具体品牌推荐，列几个我判断时用的维度，你自己套。第一看它和你编辑器的集成度，能否直接读到项目上下文，这决定了它给的建议准不准。第二看它的输出可控性，能不能约束代码风格、能不能指定不要用某些库。第三看它对多文件改动的支持，单文件补全和跨文件重构是完全不同的能力层级。第四看隐私和数据策略是否满足你所在团队的要求。第五看它在出错时的表现，是干脆编一个不存在的API糊弄你，还是会承认不确定。

我的经验是，不要迷信某个工具的“全能”，大部分工具在补全类任务上表现都差不多，真正拉开差距的是跨文件理解和Agent执行能力。选型时不妨拿你自己项目里一个真实的、有点复杂的重构任务去试，比看任何宣传材料都管用。

3. 把AI生成的代码落到工程里的关键环节

工作流搭起来之后，真正决定成败的是落地细节。这一节讲几个我反复打磨过的操作要点，包括提示词怎么写、测试怎么安排、静态检查怎么接、版本怎么管，以及Agent用到什么程度就该收手。

3.1 提示词不是玄学，是约束条件

AI编程提示词这件事被讲得神乎其神，其实核心就一句：把你脑子里的约束条件写出来。大部分人写提示词只写“要什么”，不写“不要什么”和“必须满足什么”。我现在的模板大概是四段式：目标是什么、输入输出长什么样、有哪些硬约束、出问题时的降级方案。硬约束这块最容易被忽略，但对结果影响最大，比如“不要引入新的第三方依赖”“异常必须抛出自定义错误类型”“所有外部调用必须加超时”。

举个具体例子。我要一个分页查询，会这样写：

# 需求：实现按用户ID分页查询订单 # 约束： # 1. 使用已有的 db 连接对象，不新建连接 # 2. page 从 1 开始，page_size 默认 20，上限 100 # 3. 返回结构 {"items": [...], "total": int, "page": int} # 4. 查询为空时返回空列表，不抛异常 # 5. 不允许用 SELECT *，显式列出字段 def list_orders(db, user_id, page=1, page_size=20): ...

把约束写在前面的代码块里，比用自然语言劝它“注意边界”有效得多。原因很直接，结构化的约束对模型来说歧义更小，它不需要猜。你可以把这段当成模板，换成自己的业务需求，实测识别率明显提升。

3.2 测试先行：让AI先写测试再写实现

这是我个人最喜欢的一招，也强烈建议你试试：不要让AI直接写实现，先让它写测试。听起来绕，但收益很大。因为测试描述的是“行为”，是明确的输入输出，AI写测试时不容易跑偏；而实现是“手段”，它可能用一堆你没想到的方式去实现同一个行为。先有测试，再让AI去填实现，就相当于给它画好了靶子。

具体怎么操作？我先用自然语言把业务规则列清楚，让AI生成一组测试用例，覆盖正常路径、边界值、异常输入。生成完之后我自己过一遍这些测试，确认它们符合我对业务的理解，然后才让AI去写实现，目标是把这些测试跑绿。这个顺序的好处是，即使实现写得再花哨，只要测试能过，至少行为是对的。而且测试本身是资产，AI重写实现的时候它还在，相当于给你加了一层保险。

注意：AI生成的测试同样需要审。我遇到过它把错误行为写进测试，然后实现照着这个错误行为去写，两头都对上了，测试全绿，但业务逻辑本身是错的。测试断言的那部分，必须由人来把关。

3.3 静态检查与代码诊断

AI写的代码有个特点，看起来很整齐，但不一定符合你的项目规范。所以静态检查工具这块不能省，一般编辑器里的代码诊断插件就能挡住一部分问题，比如未使用的变量、类型不匹配、循环里的重复计算。更严格的做法是接上Linter和类型检查器，把它作为提交前的门禁。

# 提交前的典型检查顺序，按成本从低到高 ruff check . # 快速风格与常见错误检查 mypy src/ # 类型检查，挡住类型相关的隐患 pytest -q # 单元测试

这套东西的价值不在于它多聪明，而在于它稳定。AI每次输出的风格可能都不一样，但检查规则是固定的，它能保证不管谁写的代码，过门槛的标准是一致的。我习惯把这几步接进git的pre-commit钩子，这样AI生成的代码在提交那一刻就会被筛一遍，比事后review发现问题要高效得多。

3.4 版本管理与可追溯性

AI参与开发之后，提交粒度这件事变得更重要。以前一个功能可能一大坨提交，现在我会刻意把AI生成的部分和人工修改的部分拆开提交。原因是当出问题需要回滚时，你能精确地回滚AI生成的那部分，而不必连带把人工写的逻辑一起撤掉。

具体做法很简单，AI生成一版先提交，标注清楚这是生成版本；然后我审阅修改后再提交一版，标注修改内容；如果后续发现问题，直接看这两版之间的diff就能定位。这比把所有改动混成一个提交要好太多。另外我会给关键模块加一个简短的头注释，记录这个模块的设计意图和验证过的场景，AI很难自己写出准确的意图说明，这部分必须人补，但它的价值在半年后会体现得非常明显。

3.5 Agent化开发的甜区与边界

Agent用在什么地方最划算？我的经验是，任务边界清晰、验证方式客观、失败成本可控的场景最适合。比如批量重命名、补充类型标注、把一类写法统一替换成另一类、修一批已知模式的告警，这些活的共同点是“做错了很容易看出来，改动可以快速回滚”。反过来，涉及核心业务逻辑设计、并发安全、数据一致性、权限校验这类任务，我基本不让Agent自己拍板，只让它做辅助，最终逻辑由人来定。

原因是Agent的强项是执行和迭代，弱项是判断“这个设计是不是合理”。它能把一个错误的设计执行得很完美。所以我会给Agent明确划定操作范围，比如只允许改特定目录、只允许跑只读命令、改动必须通过测试才能继续。这些边界设定看起来限制了它的能力，但实际是在保护你的仓库不被一次跑偏的自动执行搅乱。

4. 踩坑实录：AI生成代码的高频问题与排查

这一节基本是我这两年被AI坑出来的经验集合。说出来可能不好听，但每个坑我都真实踩过，写出来是为了让你少走一遍。下面按问题类型分开讲，最后附一张速查表，排查的时候可以直接对着找。

4.1 幻觉API和根本不存在的库

这是最高频也最隐蔽的问题。AI会非常自信地调用一个不存在的方法，或者给你一个听起来很合理但实际没有的库名。它不会说“我不确定”，语气上完全看不出破绽。我第一次遇到是在orm层，它给了一个看起来很标准的链式调用，我直接用了，跑起来才发现那个方法在这个版本根本没有。

对付这个问题，我的做法是：所有AI引入的API，第一次使用前必须查官方文档确认存在，且版本匹配。听起来很笨，但这是唯一可靠的办法。更省事的版本是，让AI在生成时附带一个“用到的API清单”，然后我逐个核对。或者干脆在提示词里写清楚“只允许使用以下已存在的接口”，把它锁死在已知范围内。

4.2 边界条件与异常处理

AI写代码有一种“乐观倾向”，它假设一切顺利，空值、超长输入、并发冲突这些它经常漏掉。我统计过自己review过的一批AI生成函数，正常路径基本都对，但边界处理的缺失率相当高。最典型的是循环里的越界，分页的最后一条，还有外部调用的超时和失败重试。

解决办法有两个层次。浅层的做法是提示词里明确要求“必须处理空输入、必须处理超时、必须处理部分失败”，这能挡掉一部分。深层的做法还是回到测试，用专门的边界测试用例去逼它，比如传空列表、传极大值、传非法参数，跑不过就修。这一层更可靠，因为它是用结果验证行为，不依赖它的自觉。

4.3 性能与安全盲区

性能问题AI很少主动考虑，它能写出功能正确但效率很差的代码，比如在循环里反复查数据库，或者在内存里攒一个巨大的列表。这类问题在小数据量下完全不显形，上线以后才爆。安全上更麻烦一些，比如字符串拼接SQL、日志里打印敏感字段、对外部输入不做校验，这些AI都可能在“能实现功能”的前提下写出来。

我的应对是给关键路径加上性能和安全两条检查线。性能上，对涉及批量操作的代码做一次小规模压测，看看有没有明显的时间复杂度问题。安全上，所有外部输入必须经过校验，所有数据库操作必须参数化，日志必须过滤敏感字段，这几条我会当成硬规则写进提示词里，并且在review时逐个确认。

4.4 依赖与许可证风险

AI有时候会推荐一个“方便”的第三方库，你不知道它的来源、维护状态、许可证类型。个人项目可能无所谓，但在团队项目里，随手引入一个没人维护的依赖，后患很大。我的原则是默认不让AI引入新依赖，需要什么先在项目已有依赖里找，找不到再说。如果确实需要新库，那也必须经过选型评估，看它的活跃度、许可证、有没有已知问题，这个流程不能因为“AI推荐的”就走捷径。

4.5 常见问题排查速查表

这张表我基本是贴在显示器旁边用的，新问题出现时先对一下，命中率挺高。需要说明的是，表格里的“最可能原因”是概率判断，不是结论，真正的定位还是要看堆栈和复现步骤，别偷懒直接照表下药。

5. 对开发者意味着什么

前面讲了这么多技术细节，最后想聊聊这件事对人本身的影响。AI写了80%的代码，那剩下20%是什么？我的观察是，剩下的份额越来越集中在判断上，而不是产出上。这个变化对每个开发者都是真实的，早点想清楚自己的位置，比焦虑有用。

5.1 从写代码的人变成审代码的人

以前衡量一个开发者的水平，很多时候看他写得多快、多熟。现在这个指标在弱化，因为“写”这件事的边际成本在快速下降。真正被拉开的是审的能力：你能不能一眼看出这段代码的问题，能不能判断这个设计是否合理，能不能预判它在什么场景下会崩。这种能力没法靠刷题获得，它来自大量真实的踩坑和对系统的理解。

我现在带新人，会刻意训练他们读代码和挑毛病的能力，而不是让他们练手速。给他们一段AI生成的代码，让他们找出所有可能出问题的地方，这个练习的强度比写一百个函数都高。对个人来说，也是一样的，与其纠结“AI会不会取代我”，不如问“我审代码的水平配不配得上我拥有的生成速度”。

5.2 学习路线该怎么调

基础的语法和常见数据结构当然还得会，这是你判断的前提，看不懂代码的人谈不上审。但学习的重心可以往两个方向偏。第一个方向是系统设计，理解模块之间怎么配合、数据怎么流转、故障怎么隔离，这些是AI不太能替你做判断的地方。第二个方向是调试和排查，出了问题能不能快速定位，这是日常工作中高频且高价值的技能，而且是AI最不擅长的环节之一。

反过来，那些纯粹靠记忆的东西，优先级可以降一降。比如某个库的函数签名、某种语言的语法糖写法，这些让AI来给就行，你只要会判断对不对。把省下来的精力放到理解系统是怎么运转的上，这个投入回报比更高。

5.3 团队协作方式的变化

AI参与开发之后，团队的协作方式也在变。以前code review是一个人从头读到尾，现在很多团队改成“先让AI粗筛一遍，人只看AI标记出的可疑点”，效率提升明显。但这里有个前提，就是团队要建立统一的标注规范：哪些改动是AI生成的、哪些是人工修改的、验证过哪些场景，这些信息必须透明。

我参与过的一个项目就是这么做的，提交信息里固定几个字段，写清楚生成来源和验证情况，reviewer一眼就能知道该重点看哪里。这套规范刚推的时候有人嫌麻烦，用了两个月之后大家都回不去了，因为排查问题的速度快了不止一倍。协作方式的变化本质上是把“信任”这件事从口头承诺变成了可追溯的记录，这在人机混合协作里尤其重要。

回到开头那家公司的呼吁，我不觉得那是在否定工具，更像是在提醒节奏。工具越强，越需要配套的评估和边界，否则生成出来的东西越多，欠下的债也越多。我自己这两年的体会是，AI让写代码变快了，但让“想清楚”这件事变得更贵了，而那部分恰恰是省不掉的。你要是问我下一步最该练什么，我会说，练怎么在十分钟内看出一段代码的毛病，这个能力在接下来几年只会越来越值钱。