企业官网建设流程全解析

把提示词扔给大模型，拿到一段能跑的代码，这件事现在谁都能干。但架构师真正要盯的是另一件事：这段代码三个月后还在不在主干上，需求变动时它会不会崩，新人接手时看不看得懂。过去半年，我把团队里用提示工程生成代码的踩坑记录逐条翻了一遍，筛出了和代码质量强相关的15个关键项，整理成这份清单。它不解决"怎么让模型听懂人话"这种基础问题，只解决一个更现实的问题：怎么让生成代码经得起代码评审、经得起长期维护、经得起生产环境。

这份清单适合三类人：天天和大模型打交道的一线开发、替团队定技术基线的架构师、以及想把AI生成代码纳入正规流程但不知道从哪下手的团队。下面我按"为什么需要、清单全貌、重点拆解、落地方法"四条线展开，尽量把每条结论背后的踩坑经历也说清楚。

1. 为什么架构师要给提示工程单独列一份代码质量清单

1.1 能跑的代码和能维护的代码是两种物种

现在几乎没有团队能绕开大模型写代码这个现实，我所在的团队也一样。但从架构角度，我关注的一直不是"能不能生成"，而是"生成的东西敢不敢合进主干"。大多数通用提示工程教程讲的是如何让模型输出更准确，而代码质量问题不在那个坐标系里。

能跑的代码像一辆能发动、能开到六十码的二手车；能维护的代码像一辆有完整保养记录、任何修理工都能上手的车。大模型默认产出的是前者——它能通过本地测试，但它不知道团队的分层约定、不知道线上环境的边界条件、不知道三个月后会有另一个需求在它旁边动刀。提示工程在代码场景里的真正作用，不是让AI写得更快，而是让AI写得"像这个团队会长期持有的代码"。

这句话说起来容易，做起来牵扯的东西很多。上下文怎么组织、需求怎么拆、约束怎么给、验收标准怎么定，每一样都直接影响最终产物的代码质量。我把它拆成15个关键项，不是为了制造流程负担，而是为了在写提示词的时候有一份"可勾选"的底稿，减少拍脑袋式地"这次让模型再试试，不行就换个说法"。

1.2 一次线上事故逼我正视清单的价值

今年年初某项目出过一次事故，现在想起来仍觉得后怕。某个内部管理系统的批量导入接口，是同事用大模型生成的代码。当时所有演示场景都跑通了，大家还挺满意。结果上线第三天，线上传了一批带空行和重复表头的Excel，接口直接把整批数据写进了数据库，还返回了成功。

排查下来发现，生成那段代码的提示词只写了"解析Excel并入库"，没有要求处理空行、重复表头、字段缺失、事务回滚这些边界情况。模型确实忠实地完成了指令，但指令本身没有代码质量的约束。那次之后，我不再相信"提示词写清楚功能就够了"，开始逐条总结哪些项必须在提示词层面约束住——这正是这份清单的由来。

所以这份清单的定位很明确：它既不是提示词的万能模板，也不是代码规范文档，而是介于两者之间的"评审接缝"。你在提示词里埋下这些要求的种子，在代码评审时就能顺着这些种子追查AI有没有遗漏。清单的价值不在"它有多全"，而在于它让"AI生成代码"从一个黑盒变成了可追踪、可追溯的过程。

2. 15个关键项全景：从提示词到大仓库的分层清单

2.1 清单的四个层级是怎么分出来的

我把15个关键项按"可控性从高到低"分成四层。第一层是提示词本身的可控变量，比如需求边界、技术栈、上下文管理；第二层是生成代码的内在质量，比如命名、错误处理、边界条件；第三层是代码进工程体系后的适配质量，比如依赖、日志、可观测性；第四层是过程控制，比如任务拆解、输出格式、人工审查。

这样分层的原因是，不同层的"责任人"不同。第一层和第二层主要靠提示词约束，第三层需要把团队已有的工程规范也喂给模型，第四层则需要人和流程介入。如果只盯着提示词技巧，忽略工程规范，生成的代码仍然会"看起来能用，其实不属于这个系统"。

2.2 15项清单总表

我在代码评审时逐项对照的底稿长这样。编号即优先级顺序，越靠前越容易被忽视、也越容易翻车。

这张表最大的作用，是让每个"看起来有点虚"的质量要求都能对应到评审时的具体检查动作。比如看到函数没有错误处理，回头看提示词第6项，立刻能判断是要求漏了还是模型没执行；看到代码里出现陌生依赖，直接查第2项和第12项的约束是否传达到位。有了这张表，评审不再依赖"感觉这代码有点不对劲"，而是有一个可以逐条打勾的客观基线。

2.3 层级之间的联动关系

四层不是孤立的。第一层漏掉的需求边界，会在第二层表现为各种未处理的边角情况；第三层忽略的依赖管理，会在第四层的评审阶段引发返工。我见过一个典型案例：提示词只写了"用Python实现一个数据同步脚本"，模型自主选择了某个第三方库，结果这个库和团队基础版本冲突，光解决依赖就花了两天。如果在第2项锁定技术栈、在第12项禁止隐性依赖，这两步完全可以省掉。

所以我的建议是：不要把15项当成15个独立提示词技巧，而要把它们当成一条从"需求描述"到"代码入库"的质量链。链条上每一环的缺失，都会在后续某个环节以不同形式显现出成本，越早的环节漏掉，代价越大。

3. 逐条拆解：最容易翻车的5个条目与真实反例

3.1 第7项：边界条件与空值防护——AI最习惯性遗漏

在所有条目里，第7项是我在评审中发现问题率最高的一条。大模型非常擅长生成"理想输入下的代码"，对空值、空数组、超大输入、重复数据这些真实世界的脏数据，默认完全不设防。

真实反例来自某数据清洗脚本。当时提示词是"写一个函数去除列表中的重复元素"。模型给出的实现是典型的先排序再比较相邻元素，这个方案在常规列表上完全正确。但线上数据里混入了不可比较类型的元素，排序直接崩溃，整个清洗任务中断。很简单的需求，因为没在提示词里补一句"输入可能混入不同类型，需要先做类型判断"，就变成了生产中断的源头。

我在实际提示词里会这样写：

实现一个函数去除列表中的重复元素。 边界条件要求： - 输入为空列表时返回空列表 - 输入包含不同类型元素时，按类型分组去重，不得抛异常 - 输入为None时返回None并记录警告日志 - 列表长度超过10万时，空间复杂度不得超过O(n)

实测下来，只要把边界条件列到这个粒度，模型基本能给出像样的防护代码；不写，它默认什么都不做。你需要替模型把真实世界的样子描述出来，它对你世界的了解程度，取决于你在提示词里给了多少真实细节。

3.2 第8项：安全与输入校验——把提示词当第一道防线

安全问题是生成代码里最容易被忽视的黑洞。模型不会主动往代码里塞漏洞，但它会忠实地复现开发者在提示词里表达出的"宽松"。最常见的坑是：提示词要求"接收前端传来的用户输入并查询数据库"，模型就会生成直接拼接查询语句的代码，因为它不知道你的系统里还有注入攻击这件事。

我通常会在提示词里显式写入三类安全要求。第一，所有外部输入必须经过白名单校验，禁止使用黑名单过滤这种"亡羊补牢"思路；第二，禁止在代码中出现潜在危险的函数或写法，比如直接把用户输入传入可执行上下文；第三，如果模型认为需要绕开这些约束，必须明确注释并说明理由，而不是悄悄改掉。

这里要强调一个观点：提示词里的安全约束不是为了让模型"变成安全专家"，而是为了让审查者有据可依。AI生成的代码，本质上是一个"没有安全意识但执行能力极强的新人"，你要用提示词把团队的安全基线翻译给它听，翻译得越具体，它越不容易自由发挥。安全约束写不写，差别往往不是"有漏洞"和"没漏洞"，而是"一眼能被审查发现"和"上线三个月后才被外部触达"。

3.3 第12项：依赖与兼容性管理——隐性引入的"幽灵依赖"

这个坑非常隐蔽，因为它不在代码逻辑里，而在构建环境里。大模型训练数据里充满了各种第三方库的用法，它在不加约束时，会条件反射地引入那些"它见过很多次"的库，哪怕标准库就能解决。

某次我用提示词生成一个JSON转换工具，模型给我引了一个第三方序列化库，理由是"性能更好"。实际上团队明确要求纯标准库实现，因为那个模块要跑在受限的部署容器里。如果提示词没有锁死"只允许使用标准库"，这个隐性依赖就会像幽灵一样潜入工程，直到部署前才爆炸。

我的做法是在提示词里固定一段"依赖声明区"，内容很简单：本模块允许使用的依赖列表；禁止引入的依赖类别；新增依赖时必须说明理由并提供版本号。这段声明看起来啰嗦，但它能帮团队守住依赖边界，而且对模型来说，这个约束比"请保持简洁"这种模糊要求有效得多。依赖问题最怕的不是"用了不该用的库"，而是"用了而所有人都不知道"。

3.4 第13项：任务拆解与渐进生成——别让AI一口气写500行

让大模型一次生成完整的大模块，是提示工程里最诱人也最危险的做法。诱人在于，一次生成看似高效；危险在于，模型在长上下文中会逐渐丢失早期的约束，越写越歪，而且一旦中间某个假设错了，后面几百行代码全部作废。

我在某图像处理Demo里试过让AI一次生成"完整的图片上传、压缩、存储、缩略图生成模块"，结果代码确实齐全，但四个功能段分别采用了四种不同的错误处理风格，整个模块的代码质量惨不忍睹。后来改成渐进式生成：先让AI给出模块分层和接口定义，确认后再生成第一层的实现，逐层推进，每层都附带可以运行的最小验证。

渐进生成的附带好处是，每一层的提示词都很短，上下文环境干净，模型对你的约束遵守率明显更高。而且每一层都有人工确认的接缝，问题在交叠层就被拦住了，不会滚到最后一层集中爆发。这有点像盖房子先出施工图再浇地基，看着慢，实际省掉的是"盖完再推倒重来"的时间。

3.5 第14项：输出格式与接口契约——用结构化输出消灭解释成本

很多开发者没有意识到，和模型对话本身也是一种接口调用。你在提示词里说"给我一个函数"，模型给你一段含解释、含示例、含注意事项的长文本，这完全可以接受；但当你需要把生成结果直接接入流水线时，非结构化输出就是一种隐性成本。

我试过让模型生成20段独立函数，然后靠人工去每段文本里截取代码块，那感觉像回到了没有语法高亮的原始时代。改成结构化约束之后效果好得多：我会在提示词里附上明确的输出契约，规定它必须返回符合既定结构的JSON，包含代码片段、依赖清单、测试用例、已知限制四个字段，代码片段用指定的围栏标记包裹，禁止额外解释。

这里有经验的细节：输出契约不要只写"用JSON格式"，而要给出JSON Schema示例。模型对示例的理解比对抽象描述的理解好一个量级。给一个完整的示例，再要求"严格按此结构输出，字段缺失视为生成失败"，基本上能消灭大半手动作业。

4. 把清单落进工作流：评审、模板与自动化钩子

4.1 把15项改造成代码评审的检查表

清单只有用在评审里才有价值。我把15项映射成了评审时的三个关卡。第一关是"需求关"，在开始写提示词之前检查第1、2、3项，确认这次要生成的东西边界清楚、技术约束明确；第二关是"生成关"，在代码落地前检查第4到9项，看生成代码的内在质量；第三关是"入库关"，代码提交前检查第10到15项，看工程化和过程痕迹。

这个映射看起来是把15项又分了一遍组，但它有个实际好处：不同关卡可以交给不同角色执行。需求关由需求方和开发共同过，生成关由开发自检，入库关由评审者把守。责任清楚，才不会出现"大家都觉得AI已经写好了，于是没人认真看"的情况。我在团队里推行了两个月，最明显的变化是评审会议的争论少了，因为大部分问题在提示词阶段就被拦掉了。

4.2 提示词模板的分层设计

我最终沉淀了一套提示词模板，分三层：全局约束层、任务描述层、输出契约层。

# 全局约束层（固定） - 语言：Python 3.11，仅允许使用标准库 - 风格：遵循PEP8，类型标注必须完整 - 禁止：eval/exec、shell拼接、未声明的第三方依赖 - 安全：所有外部输入必须经白名单校验 # 任务描述层（每次变动） - 功能目标：…… - 输入/输出约定：…… - 边界条件：…… - 验收标准：…… # 输出契约层（固定） - 返回JSON，字段：code / deps / tests / limitations - code字段包含完整代码，禁止额外解释 - 字段缺失视为生成失败

全局约束层固定不变，对每个项目基本通用；任务描述层变动，描述本次要生成什么功能、有哪些边界条件、验收标准是什么；输出契约层统一，方便自动化解析。

三层分开写的好处是，全局约束不用每次重复思考，新人也容易上手；任务层保持灵活，不会被模板僵化；输出层格式统一，方便后续接入自动化工具。这套模板不是一次到位的，前几版很粗糙，后来根据评审中反复发现的问题不断往全局约束层里加内容，比如"禁止引入未声明的第三方依赖"就是从一次依赖事故中补进去的。

4.3 自动化校验：让机器先查一部分

人的评审精力有限，所以我尽量把能自动化检查的项交给工具。第5项命名规范、第8项安全红线、第12项依赖声明，这些都能通过静态检查和依赖扫描在本地先跑一遍。我在本地配置了一套组合命令：提交前自动跑代码风格检查、依赖审计和基础安全扫描，三项全绿才允许进入人工评审。

这么做不是要把人排除在流程外，而是把人的精力集中在机器查不了的地方——第6项错误处理逻辑是否合理、第13项拆解是否恰当、第15项有没有遗漏人工确认点。机器管语法，人管语义，各干各擅长的，评审效率提升非常明显。

有一个细节值得说：自动化校验的结果也会反馈到提示词模板里。如果检查工具多次报同一类问题，说明全局约束层少了一条对应的硬性要求，把它补进去，下一条生成代码大概率就不会再犯。等于你的质量清单会随着项目演进自我更新，而不是一张固定的死表格。

5. 使用这份清单的元注意事项

5.1 一次提示词塞满15项反而会失效

我在实际使用中最深刻的体会是：15项是给你自己的评审底稿，不是让你一次全塞进提示词的文字。如果你把15条要求一股脑写进一个提示词，模型会在长上下文里"顾此失彼"，遵守率不升反降，甚至关键约束被淹没在无关要求里。

我的经验是：一次对话中，全局约束层的固定项全部保留，任务相关的动态项一次最多挑三到五个最关键的写进任务描述。比如这次生成的是对外接口，那么安全校验、输出契约、边界条件这三项必须加强；如果这次生成的是内部工具函数，重点就放在错误处理和测试覆盖上。清单的价值是帮你做取舍，而不是逼你平均用力。

5.2 清单必须跟着团队的质量基线走

最后提醒一点：这份清单不是静态的。团队当前阶段如果还在"跑通为主"，那第6、7、8项可以放宽，重点保证第1、2、3项到位；如果已经到了"稳定发布"阶段，第10到15项就要逐渐加码。

我见过一些团队把AI生成代码的质量问题归咎于"模型不够聪明"，其实大多数时候问题出在提示词的约束密度和团队的质量基线不匹配。把这份15项清单当作一次对齐工具，和团队一起逐条过优先级，比单独追求某个提示词技巧更有意义。

我现在每周五都会花十分钟，把本周评审中出现的新问题对照清单过一遍，看有没有哪一项需要补充检查标准，有没有哪一项连续三周零问题可以降级处理。这样清单才不会变成一张贴在墙上的纸，而是真正活在代码评审里的工具。如果你也在用大模型生成代码，建议从下周开始，拿一份真实的评审记录对照这15项过一遍，我猜你会发现自己漏掉的项比想象中多。